Antes de diseñar el ERP, miremos primero los procesos

Durante muchos años los proyectos ERP han empezado casi siempre igual.

Reuniones con usuarios, entrevistas, cientos de requerimientos, Excel, documentos, demos y después la gran discusión:

¿El ERP puede hacer esto?

¿Tiene esta pantalla?

¿Podemos poner este campo aquí?

¿Esto viene estándar o hay que desarrollarlo?

Y ojo, todas esas preguntas son importantes.

Pero para mi vienen después.

La primera conversación debería ser otra:

¿Cómo funciona realmente el negocio y cómo debería funcionar?

Porque un ERP no va realmente de pantallas. Va de comprar, vender, planificar, producir, almacenar, entregar, facturar, cobrar, pagar, mantener activos, controlar costes y finalmente tomar mejores decisiones.
Las pantallas vienen después

No tenemos que inventar todo desde cero

Aquí hay algo que me parece muy interesante y de lo que quizás hablamos poco.

Los grandes fabricantes de ERP llevan años construyendo sus propios catálogos de procesos de negocio, modelos de referencia o Best Practices.

• Microsoft tiene el Dynamics 365 Business Process Catalog.

• SAP trabaja con SAP Signavio Process Navigator y SAP Best Practices.

• Oracle tiene Oracle Modern Best Practice.

• Infor dispone de su Industry Process Catalog.

• IFS mantiene sus Business Models.

Los nombres cambian, las estructuras también, pero el concepto detrás es bastante parecido:

no empezar cada proyecto ERP desde una hoja en blanco. Expondré un pequeño resumen de los fabricantes que he nombrado.

El caso de Microsoft

Microsoft, por ejemplo, está trabajando su Dynamics 365 Business Process Catalog desde una lógica bastante interesante.

No empieza diciendo:

Finance.

Sales.

Supply Chain.

Manufacturing.

CRM.

Empieza mucho más arriba, desde procesos completos de negocio.

Por ejemplo:

Forecast to Plan.

Source to Pay.

Plan to Produce.

Inventory to Deliver.

Order to Cash.

Project to Profit.

Record to Report.

Hire to Retire.

Y desde ahí va bajando.

Proceso end-to-end.

Área de proceso.

Proceso.

Escenario.

Proceso de sistema.

Y finalmente incluso casos de prueba.

Para mi esto cambia bastante la conversación.

Porque ya no estamos mirando solamente qué hace Dynamics 365.

Estamos mirando cómo debería funcionar un proceso empresarial completo y dónde entra la tecnología para soportarlo.

SAP lleva mucho tiempo con esta filosofía

SAP seguramente es uno de los fabricantes que más ha trabajado históricamente este concepto de procesos estándar y Best Practices.

Hoy, con SAP Signavio Process Navigator, una empresa puede partir de procesos de referencia, escenarios, variantes y contenidos ya desarrollados.

Y aquí aparece una pregunta que personalmente me gusta mucho hacer en proyectos ERP:

¿Por qué tenemos que hacerlo diferente?

No digo que no se pueda hacer diferente.

Claro que sí.

Cada empresa tiene particularidades.

Pero hay una diferencia enorme entre decir:

“Necesitamos trabajar así porque esto es parte de nuestra ventaja competitiva”.

Y decir:

“Lo hacemos así porque llevamos 20 años haciéndolo así”.

No es lo mismo.

Infor tiene otro enfoque que también me gusta

Infor mete un componente adicional muy interesante:

la industria.

Su Industry Process Catalog incluye procesos orientados a sectores específicos.

Manufacturing.

Automotive.

Food & Beverage.

Chemicals.

Distribution.

Aerospace & Defense.

Engineering & Construction.

Y esto tiene bastante sentido.

Porque aunque dos compañías tengan un proceso llamado Order to Cash, claramente no es igual vender maquinaria industrial que alimentos, productos químicos o piezas para automoción.

Aquí el catálogo de procesos empieza a bajar de verdad al terreno.

Y para mi es donde estos modelos empiezan a tener mucho valor.

Oracle también parte de Best Practices

Oracle tiene su propia filosofía con Oracle Modern Best Practice, especialmente alrededor de Oracle Fusion Cloud.

Otra terminología, otra arquitectura, pero la pregunta vuelve a ser muy parecida:

¿Qué parte de nuestro proceso necesita realmente ser diferente del estándar?

Y esa pregunta puede ahorrar muchísimo dinero.

Aquí aparece el famoso Fit-to-Standard

Se habla mucho de Fit-to-Standard. A veces incluso demasiado.

Pero para mi el concepto es bastante sencillo. No significa obligar a una empresa a trabajar como dice Microsoft, SAP, Oracle o quien sea. Eso sería absurdo.

Significa partir de una referencia y preguntar:

¿Esto me sirve?

Si sirve, seguimos.

Si no sirve:

¿por qué no?

Y ahí aparece el verdadero análisis.

Puede ser porque existe una regulación.

Porque el cliente obliga a trabajar de determinada forma.

Porque nuestro producto es diferente.

Porque existe una particularidad industrial.

Porque ese proceso nos da una ventaja competitiva.

Perfecto.

Entonces probablemente tenemos un gap real que merece atención.

Pero otras veces aparece aquella famosa respuesta:

“Aquí siempre lo hemos hecho así”.

Y probablemente esa frase ha financiado miles de personalizaciones ERP completamente innecesarias.

No todo gap merece un desarrollo

Este punto para mi es fundamental. Cuando encontramos una diferencia entre el proceso estándar y el proceso actual de una empresa, no significa automáticamente:

desarrollo.

Puede significar configuración.

Cambio de proceso.

Extensión.

Integración.

Automatización.

Power Platform.

Otra aplicación especializada.

O simplemente dejar de hacer algo que realmente ya no aporta nada.

Y esto es precisamente lo que debería hacer una buena consultoría ERP.

No vender horas de desarrollo.

Ayudar a decidir qué merece realmente ser diferente.

El catálogo tampoco sustituye al consultor

También hay que decirlo. Que un fabricante de ERP tenga miles de procesos documentados no significa que podamos descargar un catálogo y ya tenemos hecha una implantación.

Ojalá fuera tan fácil.

1. El catálogo aporta la referencia.
2. El consultor aporta experiencia.
3. El cliente aporta la realidad del negocio.

Y entre los tres hay que construir la solución.

Porque siempre existen personas, datos históricos, excepciones, integraciones, política interna, clientes importantes, procesos heredados y cosas que simplemente no aparecen en ningún diagrama bonito. Eso también es ERP.

Cambiaría el orden de las conversaciones

Yo personalmente intentaría llevar un proyecto ERP más o menos por esta lógica.

Primero entender:

¿Qué proceso queremos mejorar?

Después:

¿Cómo funciona hoy?

Después:

¿Cuál es el proceso de referencia que propone la plataforma?

Después:

¿Dónde hacemos Fit?

Después:

¿Dónde tenemos Gap?

Y la pregunta más importante:

¿Ese Gap genera realmente valor para el negocio?

Solo entonces empezaría a discutir seriamente configuraciones, desarrollos, integraciones y pantallas.

Porque ERP no significa copiar lo que ya tenemos

Para mi uno de los mayores errores en una transformación ERP es utilizar una plataforma nueva para reconstruir exactamente la empresa vieja.

Mismos procesos.

Mismas excepciones.

Mismos controles.

Mismos Excel.

Mismos problemas.

Pero ahora dentro de un ERP nuevo.

Eso no es transformación.

Es simplemente cambiar de tecnología.

Microsoft, SAP, Oracle, Infor, IFS y otros grandes fabricantes llevan décadas participando en miles de proyectos empresariales.

Todo ese aprendizaje poco a poco está terminando convertido en catálogos, modelos de procesos, Best Practices y aceleradores.

No significa que ellos siempre tengan razón.

Pero quizás sí significa que antes de inventar nuevamente Order to Cash, Procure to Pay o Plan to Produce, vale la pena mirar cómo lo han resuelto otros miles de compañías.

Y después decidir qué parte de nuestro negocio realmente merece ser diferente.