SAP ERP: Proyectos SAP con metodología RICEFW

Una vez que una empresa decide gestionar sus procesos mediante el producto de SAP ERP, existen tres grandes fases a cubrir:

A. Infraestructura y versiones

En esta fase, el equipo BASIS indica al cliente la infraestructura mínima requerida y la adecuada para poder operar la versión SAP ERP seleccionada por el cliente. Una vez que la empresa realiza la compra del equipo de infraestructura necesario y lo monta, el equipo BASIS comienza la instalación de SAP ERP sobre la nueva infraestructura. Al concluir esta etapa, se procede a la etapa dos que consiste en implementar SAP.

B. Implementación SAP

Una implementación SAP ERP completamente de 0, considera los siguientes pasos de implementación:

B.1. Preparación del proyecto

En este paso, se analizan los procesos de negocio de la empresa y se define como estos serán tratados por SAP ERP. Esto se lleva a cabo con funcionales expertos que conocen la solución Standard de SAP. La solución Standard de SAP son los módulos ya existentes dentro del sistema que requieren los datos de las empresas para poder usar la solución SAP ERP. Para ejemplificar lo antes mencionado utilizaremos un proceso que realiza cualquier empresa que es Vender.

Para poder vender, es necesario contar con productos y clientes. La solución SAP ERP dispone de un módulo llamado SD (Sales and Distribution) que se encarga del proceso de ventas. En este módulo se podrán cargar los clientes de la empresa y los materiales. Estos datos de la empresa, se utilizarán en los programas ya establecidos dentro de SAP ERP para poder emular el proceso de ventas que consta en crear un pedido de ventas, validar que existan los materiales y cantidades disponibles, y finalmente validar el cliente al cual se desea vender. Una vez que se ejecute el proceso mediante SAP, esto se registra mediante un documento.

Todo lo antes mencionado, ya está desarrollado y requiere únicamente de configuración funcional para poder utilizarlo. Es decir que una vez que SAP ERP Standard está configurado, se puede utilizar sin necesidad de tener que hacer desarrollos con código.

B.2. Business Blueprint

En este paso, se llevan los procesos de cada empresa al límite del detalle. Cada empresa realiza los mismos procesos de operación como lo es compras, cobros, contabilidad, ventas, costos entre otros. Sin embargo, cada empresa tiene su forma particular de realizar las cosas y la forma de proceder o de operar es propia de cada empresa. Esto sugiere que, aunque la etapa anterior cubra un proceso, este solo logre realizar un porcentaje del proceso real. Es necesario realizar un desarrollo ABAP (lenguaje de programación SAP) para poder cumplir con el 100% del proceso.

Para ejemplificar esto, se puede utilizar el proceso de pagos a proveedores entre SAP ERP y una entidad bancaria. SAP ERP logra contabilizar en su sistema mediante las soluciones standard los pagos masivos a proveedores. Sin embargo, la ejecución final del pago está en manos del sistema de la entidad bancaria. Sin una solución integrada entre SAP ERP y el sistema de la entidad bancaria, se debe de realizar estos pagos de forma manual en el sistema del banco, lo cual hace que el objetivo del proceso de forma automática se pierda.

Para poder lograr que este proceso se cumpla, es necesario agendar este incidente como un Proyecto SAP en la fase de desarrollo de soluciones.

B.3. Realización

Una vez que el paso de Blueprint está concluida, los funcionales expertos de cada módulo, configuran la solución standard de SAP ERP. En esta etapa se hacen pruebas de los módulos y procesos SAP de manera unitaria. Esto sugiere que cada módulo se prueba de forma individual.

B.4. Preparación

Al concluir el paso de realización, los funcionales expertos de cada módulo, configuran las integraciones entre módulos. En esta etapa se empiezan a realizar pruebas integrales entre módulos. Esta etapa permite que los procesos de los módulos queden interconectados y todo lo que pasa en un módulo se replique en otro. Inicialmente se realizan estas actividades para conectar los módulos hacia la contabilidad, sin embargo, la interacción puede viajar desde costos hacia ventas o compras, el objetivo final es automatizar los procesos para que se registre la información de forma manual en un solo punto.

B.5. Producción y Soporte

Una vez concluido el paso de preparación, la solución SAP ERP está lista para empezar a registrar la operación real de la empresa. Cada incidente que ocurra en el uso del standard que no permita la conclusión de un proceso, es reportado y soportado por un equipo de especialistas en SAP. Estos pueden ser consultores externos o internos de la empresa.

C. Desarrollo de soluciones

En esta fase, se retoman todos los puntos del paso de Business Blueprint en caso de ser una implementación de SAP ERP de 0. En caso de ser una evolución del proceso del cliente y decide desarrollar una solución, se hace un levantamiento del incidente. Al final, sin importar la procedencia de los casos, se contará con una base de datos de incidentes y estos serán atendidos por un funcional experto y un equipo de desarrollo ABAP.

Es muy importante entender en este punto que un funcional experto en la fase de Desarrollo de soluciones no es lo mismo que un funcional Experto en la fase de implementación. Un funcional experto en la fase de desarrollo de soluciones, es aquel que conoce la programación de SAP ERP. Este funcional puede especificar funciones, programas, búsquedas en tablas de SAP y conoce el reportorio de herramientas ABAP (lenguaje de programación SAP), además de conocer la configuración y procesos standard de SAP.

Los tópicos antes mencionados, permiten que este funcional experto pueda diseñar una solución al incidente que está tratando. Esta solución es documentada mediante un documento conocido como especificación funcional. Este documento contiene la descripción de lo que se requiere, la guía técnica a realizar por el programador ABAP y el caso de pruebas de esta guía técnica.

Una vez que la especificación funcional es completada, el desarrollador ABAP se apega al documento para realizar lo requerido.

Una vez que el desarrollador ABAP concluye la solución, el desarrollador en conjunto con el creador de la especificación funcional, realizan las pruebas del documento. En caso de no lograr el resultado del documento, se afina la solución para lograr el caso de pruebas. Una vez logrado el caso de pruebas, se puede presentar la solución a la persona que levanto el incidente. En caso de cumplir con lo requerido, se da por concluido el proyecto. En caso contrario, se realizan los cambios hasta culminar con la satisfacción total por parte del cliente.

Qué esperar de una consultoría de desarrollo de soluciones SAP ERP

La fase de desarrollo de soluciones SAP ERP consta de muchos retos y desafíos que pueden agobiar muchas veces aun a expertos en el campo. Sin embargo, para poder lograr el éxito en esta fase, hay cierto requisitos mínimos y conceptos básicos a entender.

Al momento de contratar al funcional que va a realizar la consultoría, este debe de saber varias cosas fundamentales que se enumeran a continuación:

Tablas de SAP

El consultor funcional experto debe de poseer la habilidad de poder encontrar los campos y tablas donde se registran las ejecuciones de las transacciones de SAP.

El funcional debe de ser capaz de poder crear una tabla identificando los campos ID.

Funciones, clases, métodos y programas de SAP

El consultor funcional experto debe de entender el concepto básico de funciones que consta de 3 elementos:

• Datos de Entrada (Import)
• Lógica (Source Code)
• Datos de Salida (Export)

Adicional a esto, se debe entender la diferencia entre elementos, estructuras y tablas tanto en los datos de entrada como en los datos de salida.

Es necesario que el recurso pueda diferenciar entre una función, una clase y un método ya que esto permitirá poder aplicarlo en diferentes casos y soluciones.

Los programas son el vehículo de interacción entre el usuario y la lógica desarrollada.

Las funciones son llamadas dentro de programas y estas ejecutan acciones mediante la información que recolecta el programa. Las clases son una macro función que llaman pequeñas funciones. Aunque se pueden crear funciones que llamen a funciones, la clase permite tener un orden de las funciones que llama ya que estas son métodos. Los métodos son utilizados para realizar los disparadores o activadores de Workflows y ayuda a la consola de API (Interfaces de aplicaciones de programación). Las API se utilizan para poder hacer aplicaciones web y conectar la interfaz de usuario con SAP.

Búsquedas y LOOPS

Al desarrollar un programa o solución, sin importar si estamos hablando de SAP o no, es necesario entender que la interfaz de usuario captura datos. Al ejecutar la pantalla de interfaz de usuario, se llaman funciones y se les pasa los parámetros de la interfaz de usuario. Las funciones realizan búsqueda de datos y posteriormente validaciones. Muchas veces las búsquedas realizadas mediante un dato, retornan varios datos asociados al primero. A esto se le conoce como estructura.

Ejemplo:

Al ingresar el DNI, este devuelve el nombre asociado, apellidos y fecha de nacimiento.

A esto se le conoce como una estructura. Los resultados son presentados en una sola línea.

Sin embargo, si requiero consultar los domicilios donde ha vivido el DNI, este puede devolverme una lista de lugares. Esta lista es conocida como una tabla.

Entender que los resultados provienen en diferentes formas como elementos, estructuras o tablas, permite que el programador entienda que herramienta va a utilizar para realizar el código. No conocer esto permite abrir la brecha a errores.

Los LOOPS sirven para poder analizar datos de una tabla, esto indica que el consultor podrá especificar que requiere ir línea por línea de la tabla a realizar una instrucción.

Casos de test y Debbug ABAP

Esta parte es obligatoria ya que el programador solo sigue instrucciones, en caso de que no se logre el resultado esperado, el consultor puede ver el código del programador e indicarle donde está el error. Posiblemente el resultado es una tabla y se tomó como estructura o se pasó mal un parámetro. Lo antes mencionado no implica que los errores son del lado ABAP, el funcional debe de poder identificar el error y brindar una solución para el programador realice los cambios necesarios. A esto se le llama Debbug.

Lectura básica de código ABAP

En muchos casos, la consultoría requiere de revisar soluciones Z, es decir fuera del standard que fueron desarrolladas por otras personas que actualmente no forman parte del cliente. Estas soluciones cumplen lo que el cliente requiere, sin embargo, es necesario ampliar las funciones de la solución. El funcional experto debe de tener la habilidad de poder extraer de una transacción, el programa, paquete, tablas que consulta el programa, funciones que ejecuta el programa y paquete del programa. En base a esta información el funcional experto puede diseñar una solución sobre lo ya creado.

La falta de uno de los atributos antes mencionados, impedirá la realización de la especificación funcional y esto pondrá en jaque las actividades en cuanto a tiempos al momento de ejecutar el proyecto.

• Requerimientos del administrador de proyectos

Es importante y necesario que el coordinador o gestor de proyectos encargado de la realización y ejecución comprenda que el diseñador de la solución es el funcional y el ABAP o programador solo sigue instrucciones. En ningún momento el programador está en la obligación de conocer tablas, funciones y procesos del módulo o módulos con los que interactúa la solución. Adicionalmente, el caso de pruebas es una herramienta provista por el funcional para guiar la programación y avance del programador, en ningún momento el programador está en la obligación de validar o proponer el caso de pruebas. La responsabilidad y guía de la solución está en manos del consultor funcional experto.

Una vez que el personal idóneo es reclutado, es momento de planificar la base de datos de incidentes. La primera actividad por parte del gerente de proyectos es definir la prioridad de cada proyecto o el orden de la lista. En caso de contar con un presupuesto abierto por parte del cliente, se puede optar por el paralelismo de proyectos.

Es obligatorio entender que los proyectos se pueden realizar en paralelo, sin embargo, los consultores funcionales expertos y desarrolladores ABAP no son de uso paralelo. Estos recursos requieren de terminar una actividad para pasar a otra.

Una vez definida la prioridad se comienza con el análisis de cada incidente y cada uno es tomado como un proyecto independiente. En este punto es terminantemente prohibido colocar una fecha de entrega por parte de la consultoría, el cliente puede colocar una fecha requerida de entrega, pero esta se validará posteriormente si es realizable en costo y duración.

Aunque la aclaración anterior es muy directa, no agendar una fecha final sin conocimiento es parte de garantizar el éxito y cumplimiento de las actividades.

Cómo afrontar proyectos de Soluciones SAP

Una vez que la base de datos de incidentes cuenta con una fecha esperada por parte del cliente y prioridades establecidas, empieza la fase de análisis de cada proyecto.

Las soluciones que requieren las empresas consisten en extensiones de código para lograr un resultado. Estas extensiones van desde automatizaciones de procesos, hasta impresiones de documentos o capturas de datos de documentos. Dependiendo de la actividad o actividades requeridas se estimará el tiempo y recurso de cada actividad. El análisis inicial requiere definir que necesita el cliente.

Ejemplo:

Una empresa necesita optimizar el proceso de cobros de cada cliente, sin embargo, descarga la información de sus clientes de un portal externo de SAP. La información es procesada manualmente en Excel y se genera un reporte. Dependiendo de los resultados del reporte, se aplican políticas de descuentos y moras. Posteriormente se generan documentos manuales en base a la política correspondiente. La empresa identificó que el proceso completo se realiza por dos áreas diferentes (cobros y contabilidad). Adicionalmente, los departamentos no tienen una comunicación efectiva y pequeños impases incurren en pérdidas para la empresa. Se busca una solución que evite que los impases ocurran y que los empleados dejen de invertir tiempo en digitación y que inviertan en análisis y toma de decisiones.

Aunque existan muchas formas para solucionar este proyecto, es necesario que el gerente de proyectos tenga una herramienta para cortar el proyecto en actividades. De no realizar el corte del proyecto en actividades, al momento de evaluar el proceso solo existirán dos respuestas, ya está concluido al 100% o no está concluido. El proyecto, aunque en palabras suene simple, en realización involucra varios recursos, varias actividades y cada actividad conlleva tiempo.

Para poder cortar el proyecto en actividades, se explorará a fondo la metodología RICEFW que utiliza SAP en los proyectos de desarrollo.

Metodología RICEFW

La metodología RICEFW utilizada por SAP, consiste en cortar un proyecto de desarrollo en actividades de desarrollo. Esto permitirá poder realizar actividades de desarrollo en paralelo y poder dar un porcentaje de avance en función del total de actividades.

Cada letra de la metodología RICEFW implica un tipo de actividad de desarrollo:

(R) Reportes

En caso de que la solución requiera presentar información sobre un proceso acorde a parámetros o filtros definidos, la opción de desarrollo a aplicar es un reporte.
Para que los reportes funcionen de una manera efectiva, es necesario que se cuente con un escenario manual de datos de entrada y resultado esperado. Este escenario es obligatoriamente compartido por el solicitante del proyecto.

(I) Interfases

En caso de que se requiera crear una solución donde se requieran pantallas para la interacción del usuario, es necesario de utilizar Interfases. Las interfases involucran todas las pantallas por las cuales el usuario planea ejecutar su nuevo proceso.

Para que las interfases funciones de manera efectiva, es necesario que se presenten maquetas de todas las pantallas que se requieren. Una vez que el cliente confirme los datos de cada pantalla, se puede empezar a trabajar en la documentación de estos captadores de datos.

(C) Conversiones

En programación existen un concepto llamado ETL (Extracción, Transformación y Carga). Este concepto busca extraer información de una o varias fuentes. Una vez extraída la información, se procede a transformar la información mediante validaciones. Finalmente, una vez que la información es transformada, está lista para ser cargada de forma automática.
Las conversiones son útiles cuando se intenta llevar grandes volúmenes de información de un sistema a otro. También aplica cuando se desee hacer un proceso automático a una base de datos extensa.

Para que la conversión tenga éxito, es necesario conocer los lugares de donde se debe de extraer la información, el proceso de transformación de los datos extraídos y la carga de los objetos transformados. En caso de que uno de los tres puntos anteriores no esté claro, conlleva al fracaso total de la actividad.

(E) Enhancements (Extensiones de código)

Los Enhancements o extensiones de códigos se utilizan para determinar cuáles son los puntos de conexión de integración de la solución. Esta actividad se destaca al momento de definir los parámetros de entrada de un proceso. De requerir varios parámetros y no contar con un punto de extensión de código que ofrezca los datos necesarios, es necesario pasar por varios puntos de extensión de código para fusionar los resultados y poder adjuntar la lógica desarrollada.

Un ejemplo de esto es la necesidad de validar 3 parámetros al momento de ejecutar una acción. Actualmente la solución puede devolver 2 parámetros en un punto de control y otro parámetro en otro punto de control. La teoría nos indica que es necesario pasar estos dos puntos de control para poder obtener los 3 parámetros para nuestra validación, por ende, la extensión de código para validar se situará después de los puntos de control antes mencionado.

Esta parte de la metodología sirve al momento de crear funciones que validen el paso de una pantalla a otra. También sirven para determinar el punto exacto donde se deben de aplicar los cambios en soluciones ya existentes.

(F) Formularios de Impresión

Los formularios de impresión se utilizan para poder imprimir el resultado de un proceso. Esto se manifiesta cada vez que se realiza una compra y se nos entrega la factura. Cada empresa cuenta con formatos distintos de impresión ya que no necesariamente esto aplica solo para facturas. Muchos procesos dentro de la empresa llevan impresiones que permite la continuidad o validación manual de un proceso.

Para que un formulario de impresión tenga éxito, es necesario construir una maqueta de los datos y posicionamiento de la impresión.

(W) Workflows (Comunicación entre áreas)

Los workflows permiten conectar diferentes áreas o personas mediante una bandeja de trabajo. La solución SAP ERP cuenta con un módulo de Workflows, sin embargo, también se puede optar otras formas de Workflows dentro de SAP sin pasar por las herramientas convencionales.

Lo importante a retener sobre esta categoría, es identificar bien las áreas involucradas en el proceso, la información que se comparten mediante el proceso y la forma de aprobación para viajar al área siguiente. Se debe recordar que por cada área que aprueba, está también puede rechazar y regresa la información al área anterior. Las aprobaciones y rechazos son informados mediante una bandeja de trabajo automática. El objetivo de esta bandeja de trabajo es mantenerla limpia para que no exista trabajo pendiente.

Aplicando la metodología RICEFW

En base al caso anteriormente mencionado, se ejemplificará como se utilizaría RICEFW para cortar el proceso.

• Se realizará un RICEFW de Interfase donde el área de Cobros carga el Excel que descarga del portal Externo.

• Se realizará un RICEFW de Interfase donde el área de Cobros actualizará las políticas de descuentos y moras. Esta tabla de mantenimiento servirá posteriormente para la generación automática cálculos para crear los documentos contables.

• Se realizará un RICEFW de Interfase donde el área de Contabilidad revise las ejecuciones automáticas del RICEFW de Conversión en el paso 5.

• Se realizará un RICEFW de Reporte para poder ejecutar la funcionalidad del RICEFW de Interfase número 3.

• Al cargar el Excel del portal Externo, se realizará un RICEFW de Conversión, donde se transformará el Excel a una base de datos que automatice el proceso de cálculo de descuentos y moras mediante la consulta del RICEFW2 de Interfase. La conversión realizará el posteo automático de los documentos contables.

En resumen, se deben de realizar 5 RICEFWS para ejecutar el proyecto: 3 interfases + 1 reporte + 1 conversión.

Gracias a la aplicación de la metodología RICEFW, ahora se puede asignar un recurso funcional y un recurso técnico ABAP a cada actividad RICEFW. En caso de querer realizar las 5 actividades en paralelo, se requieren 5 funcionales y 5 técnicos ABAP. Esto indica un mayor costo con un ritmo de trabajo al 100%.

Una vez definidos los recursos por actividad, es necesario determinar de acuerdo al criterio del funcional experto y el técnico ABAP, el grado de dificultad de cada actividad. En base al grado de dificultad, se asigna el tiempo para completar cada actividad. Adjunto una tabla para poder ejemplificar lo antes mencionado.

Al momento de presentar el costo de desarrollo para el cliente y que este sea muy elevado, la estrategia a proponer es extender el tiempo de entrega y quedarse con un solo recurso funcional experto y un solo recurso técnico ABAP. Una vez pactados los recursos y las fechas de realización, se procede a empezar con la elaboración de especificaciones funcionales. Posteriormente viene la etapa de desarrollo. Al finalizar el desarrollo se inician las pruebas en conjunto entre el funcional experto y el técnico ABAP, al concluir las pruebas se presenta el avance al cliente.

En este proyecto al contar con 5 actividades, la conclusión de cada una supone un 20% de avance en el proyecto. Estas actividades pueden ser divididas en más actividades como elaboración de especificación funcional, desarrollo, pruebas intégrales, presentación al cliente. Estos cortes adicionales de actividades representan un 4% del total del proyecto.

Muchas personas sienten que esta inversión de tiempo en la planificación no garantiza el éxito de un proyecto, sin embargo, es mejor pasar de un 20% a 28% en una semana, a decir que seguimos en 20% al final de una o dos semanas. El ir incrementando el indicador gradualmente le da un sentimiento de seguridad al cliente y un seguimiento correcto al proyecto.

En conclusión, gracias a la metodología RICEFW, se puede lograr el corte de actividades de los proyectos de soluciones. Entre más granular sea el detalle de las actividades, esto permitirá dar un mejor seguimiento de avance del proyecto y generará mayor confianza ante el avance del proyecto frente al cliente.