El estándar SAP no ofrece procesos

Debido a la frecuente presencia de la palabra "proceso", se ha producido un fuerte efecto de habituación. Casi nadie piensa todavía en lo que significa este término para el software y su uso. El siguiente artículo se centra en los procesos empresariales y su implementación o soporte en el estándar SAP ERP.

Proceso de entrada de mercancías

Uno de los procesos empresariales más destacados de SAP ERP es el proceso de entrada de mercancías. Consta de los siguientes pasos: se activa una orden de compra y se crea como documento en SAP, se envía la orden de compra al proveedor, se entregan las mercancías, se registran y se crea un documento de entrada de mercancías en SAP ERP.

Este ejemplo muestra todas las características esenciales de un proceso empresarial: el proceso tiene un curso temporal, una dirección, un progreso que puede medirse. El proceso tiene un estado definido en cada momento.

Existen diferentes procesadores: pueden funcionar en serie o en paralelo. Cada proceso lleva un registro y los estados anteriores del proceso deben poder recuperarse en caso necesario. Se pueden incluir o crear documentos SAP e incluir documentos físicos (formularios) (por ejemplo, albarán, pedido).

Existe un gran número de procesos empresariales similares que suelen gestionarse a través de SAP ERP. Algunos ejemplos son: la recepción de facturas, la recepción de reclamaciones, el proceso de ventas (consulta del cliente - oferta - pedido) y el inventario.

Como procesos de negocio, sin embargo, estos procesos sólo existen a nivel organizativo en SAP ERP. El estándar SAP sólo proporciona los documentos entre los que se ejecutan los procesos. En el caso de la entrada de mercancías, por ejemplo, son el documento de pedido y el documento de material los que se crean en el transcurso del proceso.

La gestión del proceso se deja exclusivamente en manos del usuario. Los plazos, el progreso, el estado, los agentes implicados, los documentos deben ser gestionados por el usuario.

No existe un lugar central donde el usuario pueda obtener una visión general de los procesos en curso. El seguimiento de los procesos lleva mucho tiempo, es engorroso y poco fiable, ya que hay que consultar multitud de fuentes de datos (documentos) para evaluarlos.

Son frecuentes las discontinuidades de los medios de comunicación en la tramitación de los procesos: La comunicación se realiza por correo electrónico, teléfono o servicios de mensajes cortos. Esta comunicación queda sin documentar. Por tanto, a posteriori es difícil reconstruir las decisiones. Es evidente que la norma SAP deja aquí un vacío de proporciones asombrosas, intencionadamente o no.

Herramienta de gestión del proceso de requisitos

Si desea crear una herramienta de software para apoyar la gestión de procesos empresariales, resulta útil hacer abstracción de casos de uso específicos. Esto significa, por ejemplo, examinar los casos de uso "recepción de facturas" y "recepción de mercancías" e intentar aislar las características y requisitos comunes.

Objeto de negocio proceso: Ha resultado útil considerar el propio proceso como un objeto de negocio. Este objeto de negocio debe tener las propiedades 1-8 mencionadas en la introducción.

Tiempo de ejecución del proceso: los procesos pueden avanzar manualmente, es decir, controlados por el usuario en una operación de diálogo, pero también pueden progresar automáticamente. En los procesos empresariales habituales suelen darse ambas formas de "avance". De ello se deduce que se necesita una especie de "tiempo de ejecución del proceso" para impulsar los procesos automáticamente.

Supervisión frente a cabina: Debe ser posible supervisar el estado y el progreso del proceso. Para ello, se necesita una operación de supervisión que muestre todos los ratios esenciales y ofrezca una visión de los datos detallados del proceso.

Si la transacción de monitorización también permite el control del proceso, es decir, conducir el proceso y cambiar los datos del proceso, hablamos de cockpit de proceso. Desde el punto de vista del software, monitor y cockpit pueden ser la misma transacción autorizada de forma diferente.

Arquitectura de software

Asumimos el desarrollo en Abap OO, ya que hay ventajas decisivas del runtime Abap, como veremos más adelante.
Clase handler: La base de todos los procesos de aplicación es un proceso abstracto sin referencia a la aplicación. Esto se implementa como una simple clase Abap-OO (clase handler) con unas pocas propiedades:

• La clase no es definitiva
• La clase proporciona su propia persistencia, es decir, se lee a sí misma de la base de datos o se escribe en ella.
• La clase proporciona un mecanismo de bloqueo para que sólo se permita un cambiador a la vez
• La clase escribe su propio protocolo
• La clase tiene un método de devolución de llamada dedicado que se llama para el procesamiento "oscuro" desde el tiempo de ejecución del proceso

Todas las clases específicas de la aplicación derivan de esta clase abstracta de proceso. Éstas amplían la persistencia de la clase base con sus datos de aplicación sobrescribiendo los métodos de persistencia. También puede haber extensiones funcionales.

Tiempo de ejecución: el tiempo de ejecución del proceso busca en una tabla de registro, en tiempo de ejecución, la clase manejadora que pertenece al proceso respectivo (por ejemplo, la clase manejadora para el proceso de recepción de mercancías). La clase handler se instancia en tiempo de ejecución y su método callback es llamado por el runtime.

Este concepto de enlace tardío se basa en el principio del Modelo de Objetos Componentes (COM), establecido por Microsoft ya en 1992 y que se sigue utilizando hoy en día, por ejemplo, en el nuevo Windows 10 Runtime (WinRT). También en este caso, una DLL (objeto COM) solo se carga en tiempo de ejecución a través de un GUID de objeto cuya ruta de archivo de la DLL se almacena en el Registro de Windows. El principio de la vinculación tardía puede aplicarse con especial facilidad en Abap mediante el concepto de clases globales.

Desde el punto de vista de Abap, el runtime no es más que un programa que recoge todos los procesos no finalizados y llama en serie a su método callback. Este programa se ejecutará periódicamente en segundo plano y puede programarse varias veces si es necesario para aumentar el rendimiento. Las colisiones se resuelven de forma eficaz mediante el mecanismo de bloqueo incorporado.

Monitorización/Cockpit: La monitorización proporciona al usuario toda la información necesaria sobre el progreso, el número y el estado de los procesos. El registro de cada proceso individual debe ser visible desde el monitor básico. Además, el monitor básico debe permitir el reinicio y la depuración de un proceso individual, por lo que ya cumple algunas funciones de cabina.

La monitorización está completamente desacoplada del tiempo de ejecución y de la clase manejadora. Puede implementarse en cualquier técnica de interfaz de usuario (SAPGUI, WebDynpro, UI5, Windows). Desde el punto de vista de la reutilización, sin embargo, la SAPGUI es la técnica de interfaz de usuario de elección, ya que un estricto concepto MVC puede ser implementado más estrictamente con la SAPGUI.

Toda la lógica de la interfaz de usuario puede subcontratarse fácilmente a una clase de controlador global o local reutilizable. En este sentido, SAPGUI es más moderno que cualquier otra tecnología de interfaz de usuario.

Cabina de aplicación: el contenido de la cabina de aplicación se basa en el monitor, pero también ofrece vistas de los datos de la aplicación y proporciona funciones específicas de la aplicación. La interfaz de usuario es una extensión del monitor básico.

En SAPGUI (también en el caso de WebDynpro), la clase controladora puede derivarse de la clase controladora del monitor. De esta forma, el cockpit "hereda" toda la funcionalidad del monitor básico sin ningún esfuerzo adicional. De este modo, la implementación de un cockpit puede realizarse en muy poco tiempo.

Conclusión

A las empresas les puede resultar muy rentable cerrar la "brecha del proceso" de este modo. Las razones son numerosas: por ejemplo, el software se adapta al proceso empresarial y no al revés.

Se crea un punto de entrada central desde la perspectiva del proceso, que a menudo corresponde también a la perspectiva departamental. Los tiempos de ciclo de los procesos se acortan y pueden medirse, y los errores quedan totalmente registrados. Los procesos se vuelven transparentes: los informes pueden implantarse como una simple extensión de la supervisión.

El alto grado de reutilización de los componentes de software existentes optimiza los plazos de ejecución de los proyectos. El concepto está preparado para el futuro, ya que se adapta a las nuevas tecnologías de interfaz de usuario con un esfuerzo mínimo. Por último, cabe señalar que este principio también puede aplicarse, por supuesto, a procesos técnicos como migraciones o actualizaciones masivas asíncronas y paralelas.