¿Qué tan importante es documentar los procesos de negocios para el éxito de una implementación de ERP?

Imagine que necesita preparar una especificación para un nuevo sistema, pero la persona que conocía los pormenores del sistema actual ya se ha ido de la empresa. En la solución existente, hay varios módulos complejos y muchas solicitudes de cambio implementadas sin la documentación adecuada. Cuando los usuarios comienzan a probar la nueva solución, descubres que un grupo completo de usuarios no tiene acceso a una función crítica.

El “por qué” detrás de una restricción, decisión, cambio o anomalía ya que esta es la información más olvidada en la documentación del sistema y la causa de prácticamente todos los dolores de cabeza, exceso de costos o incluso fallos al mejorar o reemplazar un sistema heredado.

El contexto y el fundamento de las decisiones previas son necesarios para distinguir entre los aspectos de la solución que se deben preservar y las decisiones cuestionables que solo disminuirán el valor entregado por el nuevo sistema.

Saber no solo qué, sino también por qué las prácticas actuales están en su lugar es fundamental para que un analista de negocios tome las decisiones correctas durante el descubrimiento de los requisitos. Armado con esta información, un BA puede validar con las partes interesadas clave para garantizar la eficiencia del nuevo sistema.

Cómo recuperarse cuando la información ya está perdida u olvidada

Paso 1: mapee el proceso “tal como está” utilizando un software de descubrimiento de procesos automatizado como Minit Process Intelligence Software. Esto proporcionará un gran comienzo ya que los mapas de proceso incluirán todos los matices del proceso, sus variantes, excepciones de procesos, transacciones inusuales, cuellos de botella, desviaciones y riesgos potenciales. Minit puede descubrir procesos sin conocimiento previo o un modelo de proceso específico y crear mapas de proceso a partir de datos registrados durante la ejecución normal del proceso.

Paso 2: Reclute usuarios, desarrolladores de software y otras personas con conocimientos para analizar el mapa del proceso “tal como está”. Pregúnteles sobre los motivos por los cuales el proceso sigue un camino particular, por qué ocurren las desviaciones y descubra las razones por las cuales las cosas se hacen de cierta manera.

Paso 3: investigue más profundamente las áreas de conocimiento que tienden a crear problemas cada vez que un sistema heredado se está mejorando o reemplazando, busque cosas como:

  • reglas comerciales explícitas o implícitas que deberían ser aplicadas por el sistema
  • reglas de permiso que deben ser preservadas
  • características especiales de filtrado o clasificación que deben estar disponibles para cortar y cortar datos
  • consideraciones especiales con respecto a la retención de datos
  • consideraciones especiales con respecto a las preguntas que consumen mucho tiempo
  • consideraciones especiales con respecto a la cardinalidad o jerarquía de objetos en el sistema
  • cualquier atributo de calidad (rendimiento, confiabilidad, escalabilidad, seguridad, interoperabilidad, etc.) que deba mantenerse o mejorarse

Paso 4: Programe un tiempo con las partes interesadas clave del negocio y TI para compartir sus hallazgos principales. Es muy posible que al ver los resultados de su proceso de descubrimiento, alguien recuerde limitaciones o dependencias adicionales que nadie había mencionado aún.

Conozca más sobre las capacidades de descubrimiento de procesos de Minit

Creo que es muy importante. La razón principal es asegurarse de que la empresa realmente se comprometa a establecer cómo funcionan ahora y cómo podrían funcionar idealmente (si fuera diferente). Muy a menudo, la forma en que la empresa realmente hace las cosas es un poco diferente a la forma en que los gerentes piensan que las cosas están hechas.
Es probable que este documento de proceso cambie a medida que evolucionen las nuevas ideas sobre cómo podrían funcionar los trabajos, por lo que suele ser un documento “vivo”. Esto significa que la gerencia del proyecto también debe ser bastante ágil para mantenerse al tanto de un objetivo móvil (a menudo). La forma en que hicimos las cosas y cómo haremos las cosas facilita que los usuarios localicen cómo han hecho las cosas de la forma en que se realizarán en el nuevo sistema. Esto no solo hace que la transición sea más fácil, también significa que pueden ver si las cosas se han perdido o son incorrectas al principio del proyecto.

Esto también es muy importante para establecer un plan de prueba y planificar el entrenamiento en contra. Una vez que el proyecto ha comenzado, realmente ayuda al departamento de soporte a entender cómo los usuarios trabajan en el software; brindando un servicio de soporte mucho más eficiente y personal.

Primero, resalta las ineficacias del sistema actual. Dos, establece objetivos para el nuevo ERP. Tres, enfoca las demostraciones en áreas relevantes de la función ERP. Cuatro, comunica a los proveedores de ERP exactamente lo que el cliente está tratando de lograr.

Y puede ir de muy general a extremadamente detallado: como en un cliente, lo hicimos en tres semanas. En otro, un importante fabricante de productos farmacéuticos (18 meses), pero descubrimos muchos problemas de GMP y el proceso de documentación para la tarea de validación de la FDA, por lo que varía.