¿Qué es un Roll Out en SAP?

¿Qué es un Roll Out en SAP?

Mientras que para la Wikipedia no existe la definición de Roll-Out en el sentido que le damos en Consultoría SAP, podemos afirmar que se entiende por RollOut un tipo de implementación en el sentido de que, si la implementación ya se ha realizado en otro país, entonces la configuración de procesos generales (no de localización) será aplicado a la nueva implementación.

Respecto a la localización propia del país donde se está implementando SAP, habrá que configurar respecto a los requerimientos legales del país en cuestión, pero básicamente todo el resto de los procesos ya viene en los procedimientos generales de una implementación "padre" (si así puede llamarse).

De esa implementación, se derivan las configuraciones generales que deben hacerse al nuevo cliente, y por ello se le denomina roll-out.

El rollout pretende estandarizar los procesos a través de todas las compañías, lo que permitirá optimizar costos y centralizar el mantenimiento de los sistemas de la información.

Etapas de un Roll Out

• Antes de entrar a hablar de la primera primera etapa, se deberá decidir quiénes van a ser los recursos utilizados para implantar estos sistemas. Normalmente acaba siendo una consultoría especializada (no necesariamente debe ser una empresa internacional), junto con personal interno especializado en el proceso.
• Etapa Global: 
  1. Definción del rollout. Se definirá el ámbito del rollout (qué países del grupo empresarial van a participar o qué grupo de sociedades que se pretende incluir). El siguiente paso es decidir qué procesos de negocio pueden ser definidos como modelo común de funcionamiento para todos los países y van a ser incluidos en el rollout. Se intentará abarcar el máximo de procesos, aunque con excepción de aquellos que contengan requerimientos fiscales o de reporting obligatorios a nivel local. El conjunto de todos los procesos que van a formar el núcleo del rollout se denomina CBM (Core Business Model). Se designará así un equipo de trabajo que será el responsable a todos los niveles de este CBM y será el encargado de incluir nuevos objetos o nuevos procesos de negocio en este. Este equipo se llamará Process Office y será el responsable de gestionar el know-how del proyecto.
  2. Redacción del CBM (Core Business Model). La segunda etapa es la generación del documento (que normalmente acaba siendo una hoja excel por país y módulo de SAP) en el que contenga todos los puntos de parametrización del rollout. Esta hoja servirá posteriormente a la consultora con cada uno de los países. En la fase 0 del proyecto, los objetos básicos serán definidos por Process Office analizando los requerimientos del negocio para tener una plantilla inicial que posteriormente serán ampliados por todos los países (tipos de pedidos, clases de activos fijos a gestionar, tipos de documentos de compras, numeración de las facturas y documentos financieros, plan contable del grupo…)
• Etapa Local: 
  1. Workshops Locales (por país, generalmente). Primera fase de contacto con cada uno de los países (representados por aquellos usuarios claves determinado por el negocio como responsables del rollout del país a nivel nacional), en la que se realizan Workshops separados por cada una de las diferentes áreas del rollout (Finanzas, Ventas, Compras, HR, …). En estos Workshops, la consultora explicará cúales van a ser los procesos de negocio del CBM y cuáles son las pautas y fases del proyecto a desarrollar en implementación de nivel rollout.
  2. Fase de Diseño. El país y la consultora mantienen sesiones de trabajo para determinar aquellos puntos de su negocio local que no se pueden adaptar al modelo global. Cada uno de estos puntos se denominan GAP’s y se presentan al equipo de Process Office para que apruebe o rechace su creación. Normalmente sólo son aceptados aquellos puntos legales o fiscales específicos de cada uno de los países y temas puntuales de reporting.
     En las sesiones de trabajo se rellena el toolkit creado en la fase anterior con los objetos del país correspondientes al CBM (código de impuestos, clase de activos fijos, tipos de pedidos,…)
  3. Construcción del prototipo (Build Phase). Esta actividad debe ser realizada por consultores y consistente en la parametrización en el sistema SAP (y no SAP, dependiendo de los requerimientos) de cada país, teniendo como referencia los toolkits y los GAP’s aprobados por Process Office. Una vez construido, la propia consultora testeará el prototipo antes de que los usuarios de los países empiecen a realizar la fase de pruebas (Test User).
  4. User test. Una vez el modelo está ya construido, los países iniciarán la fase de testeo (pruebas unitarias) y la documentarán mediante alguna herramienta especializada en ello (como puede ser Mercury Quality Center, Remedy,etc). Los errores detectados por los usuarios se documentarán en esta herramienta y serán arreglados por los consultores espcializados.
  5. Regression Test. Esta fase es la última antes de la puesta en marcha y se probará que la parametrización de cada uno de los países no afecta a los otros.
  6. Puesta en Marcha del Proyecto (Go-Life). En este punto se realiza la carga de datos maestros en productivo y transporte de la parametrización al entorno de producción y la configuración manual del sistema.
• Mantenimiento pos-productivo. En las primeras semanas después del Go-Live, el equipo de mantenimiento de la aplicación es el responsable de resolver las incidencias surgidas por los errores de puesta en marcha en productivo. Transcurridas unas semanas de la puesta en produción del proyecto, empieza el mantenimiento correctivo y evolutivo del proyecto

¿Necesitas ayuda con SAP? En nuestro foro de ayuda estamos respondiendo las 24 horas, los 7 días de la semana. Es soporte gratis.

Ventajas y desventajas de Implementar SAP

A continuación analizaremos las ventajas y desventajas de implementar SAP teniendo la posibilidad de realizar un rollout:

• Ventajas
  1. Conocimiento de la situación de la empresa de inmediato, al tener sistemas unificados bajo un mismo formato.
  2. Costes de IT más reducidos, ya que este tipo de proyectos permiten un mantenimiento global para todos los países (o sociedades), lo que supone poder compartir costes con todos los países.
  3. Externalización de las tareas operacionales de otros departamentos para centrarse en las actividades del negocio. Una vez el CBM se ha definido y se unifica el funcionamiento de departamentos de administración, es posible externalizar a algún data center las tareas operacionales, lo que permite reducir costes y focalizar a la gente del negocio en actividades que aporten valor añadido.
  4. Reporting comunes a nivel de todos los países.
  5. Creación de modelos globales que permiten ahorrar impuestos para la multinacional
• Desventajas
  1. Modelo de negocio rígido y poco flexible, con pocas posibilidades de adaptar a estrategias locales y más orientado a estrategias corporativas desde el centro.
  2. Costes iniciales muy grandes, aunque normalmente amortizables a corto plazo con la reducción de costes.
  3. Normalmente acaban con la implantación de un Data Center Internacional para tareas de mantenimiento y evolutivas del sistema, lo que crea la mayoría de veces problemas por ser el servicio muy impersonal y a veces, en otro idioma.

Factores claves en los RollOuts

• Desde Dirección, se debe apoyar el proyecto y pedir máxima colaboración al resto de departamento involucrados. Si el Comité de Dirección no determina el proyecto como estratégico, en muchas ocasiones se demora el arranque.
• Involucrar al usuario en la fase de testeo. Es importante que el usuario testee profundamente la aplicación ya que es el que conoce el negocio. Si se hace adecuadamente, se evitará descubrir errores ya en Producción con los problemas que ello conlleva.
• Calidad en los datos maestros que se traspasan.
• Potenciar los conocimientos de inglés de los usuarios clave. A veces hay problemas de comunicación, ya que es muy probable que los rollouts se hagan en inglés y en España en muchas ocasiones sigue siendo un problema. Además de que si el proyecto es de gran magnitud, suele ser impersonal con utilización de herramientas como el teletrabajo, mail y call-conferences, lo que dificulta más la comunicación.
• Actitud de colaboración entre consultora y equipo local. Cada parte suele tener expectativas mayores de la otra y piensa que debería asumir más responsabilidad. Para evitar esto, debe existir una buena comunicación entre ambos e intentar potenciarla.
• Cualquier proceso de negocio debería tener un único responsable para evitar problemas de responsabilidad. Los rollouts son proyectos muy grandes y segmentados, con lo que los problemas que surgen que están entre dos equipos muchas veces cuestan de solucionarlos.
• Se debe potenciar una buena política de comunicación en el proyecto para involucrar a todas las partes participantes. Se debe intentar que todo el mundo entienda la definición del proyecto, ya que en muchas ocasiones los usuarios no entienden el alcance del proyecto y la importancia de cumplir los hitos marcados.
• Los key users y responsables de proyectos deben ser definidos de forma estratégica, teniendo en cuenta sus conocimientos del sistema y del negocio. Si la elección es buena, las probabilidades de éxito en plazo y calidad son muy grandes.
• Establecer un método de control del seguimiento del proyecto con hitos, plazos y objetivos y un plan de contingencia para rectificar errores.

Fuentes consultadas y enlaces para ampliar la información:

- Todas las etapas, las ventajas y desventajas, y los factores clave han sido tomados desde el excelente trabajo que ha realizado la gente de CUVIV, y lo han compartido aquí.

- Wikipedia: Rollout

- Nota: "894419 - Rollout Manager Troubleshooting" (MRM, Rollout manager, locked ides database, client setup, initial load, MSA, Mobile Rollout manager, LPTPROVIDER.EXE, Laptopprovider, Replacmenttool)

Otros artículos que te interesarán

Esto ha sido todo amigos., cualquier consulta pueden hacerla aquí mismo en forma de comentario. Se responderá a la brevedad.

Saludos!!