Guía para el Project Manager SAP

Introducción

En el mundo de consultoría, muchos aspiran a llegar hasta el puesto de Project Manager, sin embargo, existe una rama de este puesto que cada día cobra mayor fuerza y es la de SAP.

El ERP de SAP está compuesto por módulos que permiten emular hasta un 60% de los procesos de empresas multinacionales.

Este indicador, atrae a muchas empresas a optar por el uso de SAP para la administración empresarial.

La popularidad de este ERP dentro de las grandes firmas consultoras, obliga a los Project Managers a asumir el reto de convertirse en Project Manager SAP.

Inicialmente, este cargo requiere de previamente tener conocimiento de administración de proyectos como:

• Definición del alcance y objetivos del proyecto
• Construcción de un cronograma de actividades (Prioridad de actividades, tiempo y recursos)
• Ruta crítica y estrategias de intensificación

Sobre las bases anteriormente mencionadas se aplicarán los diferentes proyectos SAP que afrontará el Project Manager SAP.

Incidencias del Standard

El ERP de SAP cuenta con una base llamada standard. Esta base se sitúa en el uso de módulos configurables y no requiere de desarrollos para funcionar. De esta parte estar, existen situaciones en las cuales no se puede completar una operación y es aquí donde es necesaria una plataforma de incidencias.

Las incidencias de procesos standard, se resuelven a través de funcionales expertos en el módulo donde ocurre el problema. Esto indica que un problema de logística difícilmente será atendido por un funcional de FI. Para manejar las incidencias de procesos standard, es necesario contar mínimo con 3 recursos:

• El primer recurso debe de ser experto en FI (Contabilidad) y CO (Costos)
• El segundo recurso debe de ser experto en SD (Ventas) y MM (Compras y Materiales)
• El tercer recurso debe de ser un experto en HR (Planilla y datos de empleados)

Las incidencias pueden ir desde datos maestros, mala ejecución o uso del sistema, hasta falta de configuración.

En ocasiones, la base de datos de incidencias se acumula y es necesario definir quien atenderá que casos y cuales se resolverán primero. Es en este punto, en donde la administración de proyectos es necesaria y el alcance es resolver la base de datos.

Implementaciones SAP

Ya que el ERP de SAP está destinado a llevar la administración empresarial de un grupo corporativo, es normal que, con el paso del tiempo, nuevas empresas se registren en el sistema. Sin embargo, previo a este escenario siempre existe un punto de partida en el cual no existe nada de SAP. Este escenario se conoce como “Greenfield” y conlleva la instalación de SAP y configuración del ERP para el uso de procesos empresariales.

Lo primero que el Project Manager de SAP debe de manejar son las etapas de una implementación.

Ambiente, mandantes y rutas de transportes

Inicialmente el equipo de BASIS, definirá un ambiente para utilizar el ERP. En este ambiente se crearán 3 mandantes, uno de desarrollo (DEV), uno de pruebas (QAS) y uno productivo (PRD).

El ambiente de productivo es en donde se realizará la actividad diaria de la empresa y con ella se presentarán los informes a entidades fiscales. En cuanto al ambiente de desarrollo, es en este en donde los funcionales realizarán las configuraciones del ERP y las registrarán en ordenes de transporte. Estas órdenes de transporte se llevarán al ambiente de calidad donde se liberarán y posteriormente se realizarán pruebas. En caso de que las pruebas sean las esperadas, las ordenes de transporte serán liberadas en productivo.

Es necesario que el Project Manager lleve un registro de las ordenes creadas y liberadas en Productivo para poder determinar si ciertas incidencias nacen a raíz de un transporte. Estas órdenes deben de transportarse en un orden ya que la falta del mismo, o la omisión de una orden puede involucrar DUMPS.

Los DUMPS son errores que detienen un proceso y muestran una pantalla con aspecto de códigos de programación. Inicialmente son impactantes, pero la generación de DUMPS son debido a falta de configuración o a la activación de un error que interrumpe el proceso.

Módulos pilares

Una vez que el equipo BASIS construye el ambiente, mandantes y rutas de transporte, es momento de que el equipo funcional comience la etapa de configuración del ERP. El paso inicial de configuración es el módulo FI. Todo proceso de cualquier módulo, termina generando un proceso contable. Esto indica que todo módulo se integra a FI. Una vez que FI configura su estructura y el catálogo de cuentas está montado, se puede proceder a los procesos de cuentas cobrar y cuentas por pagar.

Cuando ambos procesos funciones adecuadamente, el módulo de Ventas SD y el módulo de Compra y administración de materiales MM pueden conectarse a FI. Adicionalmente, el módulo de costos CO, se integrará con FI mediante clases de costos, con SD mediante centros de beneficios y con MM mediante centros de costos.

Los cuatro módulos antes mencionados, permiten operar los procesos contables y logísticos básicos. En caso de incluir la estructura organizativa empresarial y el pago de planillas de empleados, es necesario contar con el módulo HR.

Los módulos se configurarán de la siguiente forma:

• Estructura del módulo
• Creación de datos maestros para pruebas
• Pruebas unitarias del módulo
• Pruebas integradas entre módulos
• Capacitación de usuarios
• Pase a Productivo
• Carga de datos maestros a Productivo

Rollouts SAP

Posterior a la etapa de implementación, las empresas crecen y requieren de adicionar nuevas empresas al ERP o de adicionar nuevos módulos. A este caso, en el cual se extienden las funcionalidades del ERP a usuarios que ya usan SAP se le conoce como “Bronwfield”. No se requiere construir de 0 la estructura y el paso de capacitación no es requerido ya que los usuarios dominan el proceso.

Soluciones Z

El proceso de implementación y Rollouts, está diseñado para cubrir el 60% de los procesos de una empresa. El 40% restante, se debe de solventar mediante la creación de soluciones personalizadas de acuerdo a las necesidades del cliente. Estas soluciones requieren del equipo ABAP (programadores SAP) y por lo general, se utiliza la letra Z al inicio de los nombres de estas soluciones para determinar que son soluciones personalizadas y no standard.

Para que el Project Manager pueda hacer frente a este 40%, es necesario que cuente con los siguientes conocimientos:

• Diseño de soluciones de IT
• Lógica de Frontend
• Lógica de Backend
• Construcción de base de datos
• Minería de base de datos
• Workflows

Los conocimientos anteriormente descritos, se apegarán a la metodología RICEFW de SAP para la creación de soluciones personalizadas.

Metodología RICEFW

Al momento de construir una solución personalizada, el Project Manager de SAP debe de apegarse a la metodología RICEFW. Esta metodología indica un tipo de desarrollo dependiendo la letra:

R (Reportes)

Los reportes consisten en extraer información de la base de datos del ERP. Este diseño requiere de parámetros de entrada y parámetros de salida que son definidos por el cliente.

I (Interfaces)

Para poder disponer de una interfaz de usuario, es necesaria la creación de un programa. Este programa contara con pantallas, validaciones dentro y entre pantallas y culminarán en el registro del proceso mediante un numero correlativo.

Todo lo antes descrito, debe de ser validado y aprobado por el cliente mediante diseños y maquetas.

C (Conversiones)

Es normal que sistemas diferentes a SAP funcionen dentro del grupo. El cliente buscará la integración entre estos sistemas y el ERP, para ello se construirán programas de carga de información del sistema legado hacia SAP. También se crearán programas que construyan data warehouse para que el sistema legado pueda consumir datos de SAP.

E (Enhancements)

Toda interfaz de SAP, ya sea standard o personalizada, requiere de validaciones, búsqueda de información y ejecución de funciones por detrás. El enhancement son actividades realizadas por detrás mediante código y son ejecutadas desde User Exits o Enhancement Spots. Estos conceptos son los disparadores mediante las nuevas lógicas de backend serán ejecutadas.

F (Formularios de impresión)

En cada finalización de proceso, se produce documentación física. Dicha documentación física lleva un formato en cual debe de imprimirse (boletas de entrada, boletas de salida, cheques, etc). Estos formularios de impresión pueden ser Smartforms o SAP script. Los Smartforms permiten imprimir sobre una hoja en blanco y poder ver los recuadros y texto que el cliente requiera. Los SAP script son impresiones de texto por posición y sirven para imprimir sobre formatos pre impresos.

Un ejemplo de SAP script es un cheque, el papel de un cheque ya está pre impreso, el sistema buscará imprimir el nombre del proveedor, el monto, la fecha entre otros elementos sobre este cheque. Es importante manejar la diferencia de estos tipos de herramientas para poder cumplir con los requerimientos del cliente.

W (Workflows)

Muchos procesos involucran a un gran número de personas, acciones y automatización de procesos. Adicionalmente se requiere de notificaciones cuando una actividad culmine y cuando una actividad está lista para procesarse. Cuando estos elementos se combinan, se puede utilizar la herramienta de Workflow que tiene SAP. Esta herramienta permite utilizar al módulo HR para identifica a donde debe de viajar la notificación, en caso de no contestarse pasar esto al jefe después de cierto tiempo. Esta notificación llegará a la bandeja de mensajes del usuario correspondiente. Adicionalmente los mensajes de notificaciones pueden ejecutar funciones como aprobaciones y rechazos y dependiendo de lo seleccionado el Workflow ejecutará acciones hasta culminar el proceso.

Gracias a la metodología RICEFW, se pueden identificar la cantidad de Reportes, Interfaces, Conversiones, Enhancements, Formularios y Workflow que requiere una solución. Posteriormente se puede asignar el recurso para cada actividad y finalmente crear un cronograma de actividades. Con el cronograma de actividades ya definido, se pueden aplicar la metodología de AGILE y SCRUM para evitar la metodología WATEFRALL y retrasar el proyecto de creación de soluciones personalizadas.

Migraciones de R3 a HANA

En cierto punto, las necesidades del grupo que cuenta con ERP de SAP, requieren de un módulo preconfigurado que no aplica a la versión con la que cuentan. En este punto, se analiza que es más factible, si mejorar la versión de SAP para poder activar una función de negocios y configurar el nuevo módulo, o realizar una solución personalizada. En caso de mejorar la versión, es necesario consultar la guía de pase de la versión actual a la versión que deseamos. Este manual es conocido como la simplification list.

En ciertos casos, hay opciones que se encuentran en S4 HANA y no están disponibles en el R3. En este caso, si se opta por la mejora de versión, es necesario mejorar a la última versión del R3 y después migrar de R3 a HANA. Este paso de migración cuenta con su propia guía y no es un proceso para tomar a la ligera. El impacto principal radica en el cambio de tablas del sistema. Esta migración requiere configuraciones, aplicación de notas y ajustar todas las soluciones personalizadas para que busquen información en las nuevas tablas de HANA.

Eventualmente, todos los ERP de SAP R3 deberán de migrar a HANA y el Project manager de SAP debe de tener este proyecto como una realidad más que una posibilidad.

En caso de pasar de R3 a HANA, siempre se debe de seguir este orden para el proceso, pasar la versión R3 actual a la última versión del R3 1501, y posteriormente migrar a S4 HANA y actualizar a la penúltima versión del mercado.

El pase a HANA permitirá el uso de nuevas herramientas tanto funcionales, como ABAP y BASIS. En cuanto a los funcionales, se abrirá la nueva interfaz de usuario llamada FIORI. La interface de SAP ahora será accedida desde WEB y se ejecutará mediante aplicaciones.

Estas aplicaciones están disponibles en la librería de aplicaciones Fiori y el BASIS es el encargado de habilitar estas aplicaciones. En cuanto a la parte ABAP, se pondrá a disposición herramientas como BRFplus, CDS views y conexiones a Webservices.

Contratación de personal idóneo

El Project manager de SAP debe de entender que requiere del siguiente equipo:

Consultor funcional

Este consultor domina el módulo standard a nivel de configuración, procesos y datos maestros. Este consultor puede definir qué proceso es standard y qué proceso requiere de programación ABAP.

Este consultor debe poder utilizar la metodología RICEFW para poder crear soluciones, especificaciones funcionales y casos QAS para el programador ABAP.

Consultor Basis

El consultor BASIS maneja la herramienta SOLUTION MANAGER para llevar la administración de incidencias, Transportes entre mandantes, Documentación y casos de prueba, actualización de versiones y notas.

Consultores ABAP

Este consultor domina el stack ABAP, y debe de poder integrar su conocimiento para realizar la metodología descrita por RICEFW.

En orden de mando, el funcional sugiere los pasos a realizar y el equipo BASIS y ABAP ejecutan las instrucciones del funcional. En resumen, la ruta es trazada desde el equipo funcional y son los responsables. El Project Manager de SAP se encontrará en un terreno conocido, si este inicialmente fue consultor funcional técnico. En caso de no tener experiencia SAP, la guía anterior permitirá tener una base teórica del día a día de un Project Manager SAP.