Murmurar, murmurar... ¿ERP?

¿Qué hacen los consultores y los programadores?

Fuera de los consultores y los jefes de proyecto (interesados), es muy difícil explicar mi trabajo. ¿Para qué se necesita un consultor en una integración de ERP y por qué es simplemente mucho mejor cuando el consultor y el desarrollador son la misma persona? ¿Por qué existen tantas fricciones y malentendidos cuando demasiadas personas están involucradas en la cadena de transferencia? Bueno... Imaginemos cómo se representa un proceso en proyectos clásicos, por ejemplo, proyectos SAP.

División del trabajo en proyectos ERP

Un consultor entrevista a un empleado sobre, digamos, la entrada de pedidos. Y quiere/debe obtener más información sobre la determinación de precios.
El empleado a menudo no podrá explicar completamente el% del proceso de determinación de precios. Y el entrevistador/consultor tampoco sabrá qué preguntar: él mismo es un extraño en esta empresa. Por lo tanto, aquí prácticamente siempre se crea una brecha, un delta, entre los procesos preguntados y documentados y la realidad. Estas brechas, por supuesto, no solo ocurren en la determinación de precios, sino también en los procesos de aprobación, en la facturación de representantes, en la reserva de existencias, etc., etc.

Típicamente, el director del proyecto por el lado del ERP (consultor) no realiza todas las entrevistas por motivos de tiempo y coste. Por lo tanto, cuenta con personal de apoyo que realiza partes de los procesos de la misma manera (entrevista, documentación). Cada empleado individual tiene una cierta forma de trabajar, una forma de preguntar y, por supuesto, una comprensión propia de los procesos (flujos de trabajo) explicados por los empleados. E incluso los empleados ya tienen una influencia aquí en la profundidad de los detalles de los flujos descritos por el respectivo empleado en la entrevista y los antecedentes asociados.

Documentación de procesos, especificación de requisitos, pliego de condiciones

Ahora el entrevistador/consultor tiene una documentación de flujo para 1 a n procesos. En parte autogenerada, en parte recibida de aportaciones. Estas diferentes documentaciones son ahora (generalmente) redactadas por el jefe de proyecto de EPR (consultor, independientemente de si es para Navision/Business Central, SAP, Baan, Great Plains, AS/400 (AS400) o lo que sea). Si este jefe de proyecto es bueno, notará discrepancias que se pedirán aclarar. Por otro lado, las interpretaciones y malentendidos de las transcripciones también empeorarán la calidad de las grabaciones. Aquí, por lo tanto, ya tiene lugar la tercera vez (1.: representación de los procesos por parte de los empleados. 2.: comprensión y documentación de los procesos/flujos de trabajo descritos) un cambio cualitativo (en su mayoría: un empeoramiento) en la documentación del proceso.

Esperamos que esta documentación del proceso se revise una vez más con el cliente. Sin embargo, a menudo este se entrega simplemente al cliente (generalmente a cambio de dinero), y el cliente puede decir „sí“ o „no“. La mayoría de las veces el cliente dice „sí“, porque se siente abrumado por la complejidad de los procesos en su propia empresa, ahora documentada. Normalmente, no hay retroalimentación con los empleados. Puede haber muchas razones para ello:

Retroalimentación del cliente

• No lo entienden de todos modos. Una evaluación bastante arrogante, pero lamentablemente a menudo correcta.
• Hay demasiados detalles internos allí, no podemos entregar esta totalidad a todos los empleados.. Totalmente comprensible y a menudo correcta, pero lamentablemente contraproducente (perjudicial) apreciación.
• Eso cuesta demasiado tiempo/dinero si repasamos todo esto de nuevo ahora.. Esta es, sin duda, la argumentación (justificación) más utilizada.
• Seguro que sí, son los expertos.. Hay mucho respeto y esperanza en esto... lamentablemente, en su mayoría infundados. Desafortunadamente, los „expertos“ no tienen experiencia con los procesos, solo repiten (por lo general) lo que dicen los empleados del cliente... tan bien como lo hayan entendido.

Discontinuidad mediática en el camino hacia el programador desarrollador

Si el cliente dice „Sí“, el folleto resultante (libro grueso, folleto) se entregará a uno o varios programadores. Y aquí es donde suele producirse la mayor ruptura de medios. El o los programadores, en su mayoría, no han realizado las entrevistas ni han visto las notas originales. Solo saben lo que encuentran ahora en este pliego de condiciones/descripción de requisitos. Y además, tienen la presión del tiempo y el costo en su cuello. „Haz esto en 6 semanas, o estaremos en números rojos“ es una frase que se suele decir. Así que los programadores se ponen a trabajar para convertir los requisitos encontrados en el pliego de condiciones/descripción de requisitos en bits y bytes. Y estos programadores/desarrolladores, cada vez con mayor frecuencia, tienen una formación como programadores, pero en la gran mayoría de los casos, carecen de conocimientos comerciales.

Ahora volvemos a Navision / Business Central. El proceso descrito anteriormente es universal y afecta a casi todas las instalaciones de ERP, o incluso a la mayoría de los proyectos de TI en general. La parte que sigue es más específica para integraciones de ERP, a menudo reemplazos de sistemas antiguos como AS400, SNI Quattro Pro Comet, JD Edwards, Baan y muchos más.

Problema en el caso especial de ERP/Gestión de inventario

Los sistemas ERP, a menudo integrados (conectados) de alguna manera con la contabilidad financiera, cubren muchos aspectos parciales de la gestión empresarial (ERP = Enterprise Resource Planning, Planificación de Recursos Empresariales). Por ejemplo, la contabilidad financiera ya mencionada, la gestión de inventario, la adquisición (compras), la gestión de ofertas (a menudo conectada con la gestión de clientes, CRM (Customer Relationship Management, Gestión de Relaciones con Clientes)), la determinación de precios, la liquidación de representantes, los cálculos de precios, la determinación del margen de contribución, la gestión de procesos (control de flujos de operaciones) con auditorías, controles de plausibilidad, bloqueos, derechos de acceso y mucho más.

Estos detalles suelen ser ajenos a los programadores clásicos, al menos con una profundidad de detalle útil. Los programadores piensan en clases, objetos, excepciones, declaraciones, funciones. No en inventarios, balances y saldos.

Debe y Haber

Estos programadores se centran ahora, por ejemplo, en un sistema de gestión de inventario que está -en principio- terminado, como Navision o Business Central, y utilizan sus conocimientos de programación para implementar todo según su interpretación de la documentación de los asesores/consultores. Él (o ella) recreará funciones existentes simplemente porque no las conoce. Él (o ella) modificará funciones existentes, y de vez en cuando las dañará. Y él (o ella) tiene poca comprensión del uso real de las funciones que exige, y menos aún de los posibles errores de operación y entrada de datos.

Y la primera prueba general se realiza, por supuesto, con entradas que tienen „sentido“. ¡Pero mucho más importantes son las pruebas con datos „sin sentido“!

Los programas/personalizaciones creados de esta manera se entregan ahora a los clientes, a veces por el consultor o asesor, a veces por el programador. Aquí es donde los usuarios vuelven a entrar en juego por primera vez.

Desarrollador / programador y consultor en una sola persona

¿Todavía recuerdas la pregunta inicial? ¿Por qué es mejor que un programador/desarrollador sea también un consultor o asesor?Muchas de las bucles anteriores simplemente desaparecen. Esto ya reduce enormemente el esfuerzo de recopilación/comprensión/implementación de los requisitos. Sin embargo, y lo que es aún más importante: en caso de dudas durante la implementación, puede dirigirse directamente al empleado responsable para hacer preguntas. A la inversa, durante la revisión, el empleado también puede dirigirse directamente al desarrollador / programador de Navision o Business Central ya conocido para solicitar definiciones adicionales, cambios o detalles olvidados, para subsanar especificaciones olvidadas previamente.

Entender con un ejemplo práctico

Estos bucles de retroalimentación, ensayo, prueba y error, son manifestaciones muy importantes del desarrollo ágil. Y eso es mucho más difícil de entender para la gran mayoría de las personas que la forma de trabajar antigua descrita anteriormente. Para aquellos que quieran profundizar un poco más aquí:
Simplemente mira este video aquí. Se trata del desarrollo —completamente ajeno al ERP— de una máquina de música con canicas. Sin embargo, lo interesante de este video es algo completamente diferente: ¿Cuántos detalles hay que considerar en un proyecto, cuántos ajustes y sutilezas posteriores hay que tener en cuenta? ¿Y cómo se detectan y corrigen o mejoran mejor? ¿Qué bellezas (¡Sí! ¡El software puede ser „bello“!) se pueden descubrir e incorporar mediante el retrabajo? ¿Cuánto amor por el detalle se puede tener? Déjese impresionar por el video...