El ERP llega. Los consultores hacen la demo. Todo parece encajar. Seis meses después, el equipo sigue trabajando en Excel y el sistema acumula customizaciones que nadie pidió en el contrato original. Lo que falló no fue el software: fue no haber hecho el rediseño de procesos antes de elegir la herramienta. En KCP Dynamics lo vemos en casi cada proyecto que llega con problemas: la tecnología amplificó una forma de trabajar que ya era ineficiente.
Por qué informatizar un proceso malo lo hace peor
Hay una frase que usamos internamente en KCP Dynamics y que resume años de trabajo en proyectos de LATAM: si la empresa tiene problemas por un diseño incorrecto de sus procesos, al informatizarlos tendrá problemas informatizados. No es una metáfora: es lo que ocurre cuando un flujo de aprobación con cinco pasos redundantes se programa en el ERP tal cual existe hoy.
El software no cura ineficiencias. Las fija. Y una vez que un proceso roto queda codificado en la lógica del sistema, sacarlo cuesta dinero, tiempo y voluntad política. Por eso el rediseño de procesos no es una fase opcional del proyecto: es el requisito previo que determina si la implementación tendrá ROI o simplemente tendrá facturas.
La resistencia al cambio es el factor que más entorpece este replanteamiento desde el inicio. Los equipos defienden sus flujos actuales no porque sean buenos, sino porque son conocidos. Rediseñarlos —o más precisamente, acometer la reingeniería de esos flujos— antes de que llegue el ERP, cuando todavía no hay presión de go-live, es la ventana más barata que tendrá la empresa para hacerlo bien.
El coste oculto de saltarse este paso
Cuando una empresa llega a KCP Dynamics con un proyecto de Dynamics 365 que ya lleva meses de retraso, la causa suele ser la misma: empezaron a configurar el sistema antes de saber cómo querían trabajar. El resultado es una cascada de customizaciones que adaptan la herramienta al proceso ineficiente en lugar de al revés.
Customización como síntoma, no como solución
Cada customización tiene un precio en el momento de la implementación y un precio mayor en cada actualización futura. Modificar intensamente un ERP integrado complica las actualizaciones a versiones futuras y reduce la vida útil y el ROI de la inversión. Dicho de otro modo: pagar por adaptar el software a un proceso que nunca debió existir es pagar dos veces por el mismo error.
Una parte relevante de las organizaciones que implementan un ERP opta por automatizar los procesos existentes o modificar el software para que encaje con lo que ya hacían, en lugar de acometer la transformación y mejora de sus flujos para aprovechar la funcionalidad del nuevo sistema. Esa decisión es la raíz de la mayoría de los sobrecostes. Según Panorama Consulting, los fallos organizativos internos —definición deficiente de requisitos, gestión del cambio insuficiente y desconexión ejecutiva— están presentes en casi todos los proyectos que fracasan.
El coste que no aparece en el presupuesto
Lo que se ahorra con un buen rediseño previo no se mide solo en euros o dólares. Se mide en tranquilidad operativa: que los equipos puedan cerrar el día a su hora, sin horas extra que se pagan en salario económico o en desgaste emocional. Un proceso bien diseñado antes del ERP significa que el go-live no se convierte en una crisis de tres meses donde todo el mundo trabaja el doble para compensar lo que el sistema no hace bien.
Ese coste invisible —el de las horas extra, los workarounds, la moral del equipo— rara vez aparece en el análisis de ROI inicial. Pero es el que más duele cuando el proyecto sale mal. La ausencia de un rediseño estructurado de los flujos críticos es, en la mayoría de los casos, la causa directa de ese sufrimiento.
Cómo priorizar qué procesos rediseñar sin paralizar el negocio
Ver los datos
- Impacto en el negocio: ¿Afecta al margen, al cliente o al cumplimiento regulatorio?
- Frecuencia de ejecución: Alta frecuencia con pasos sin valor equivale a rediseño urgente.
- Riesgo de no cambiarlo: ¿Qué ocurre si el proceso sigue igual durante los seis meses de implementación?
- Coste de customización: Estima las horas de desarrollo que requeriría adaptar el ERP al proceso tal como está hoy.
El error más frecuente al plantearse la transformación de flujos es querer cambiarlo todo a la vez. Eso paraliza. La clave está en identificar los procesos que más impactan en el ciclo operativo y atacarlos primero, antes de tocar el software. Para hacerlo de forma sistemática, en KCP Dynamics aplicamos cuatro criterios en este orden:
- Impacto en el resultado de negocio: ¿Este proceso afecta directamente al margen, al cliente o al cumplimiento regulatorio? Si la respuesta es sí, es candidato prioritario para su rediseño.
- Frecuencia de ejecución: Un proceso que ocurre cien veces al día con tres pasos innecesarios genera más desperdicio acumulado que uno complejo que ocurre una vez al trimestre. Alta frecuencia + pasos sin valor = rediseño urgente.
- Riesgo operativo de no cambiarlo: ¿Qué pasa si este proceso sigue igual durante los seis meses de implementación? Si la respuesta implica errores, retrasos o pérdida de clientes, el riesgo de no actuar supera al riesgo de cambiar.
- Coste de customización si no se rediseña: Estima cuántas horas de desarrollo requeriría adaptar el ERP a este proceso tal como está hoy. Ese número, multiplicado por el coste hora del partner, es el ahorro directo de rediseñar antes.
Siempre se hace un estudio detallado de requerimientos basado en tres fuentes: la experiencia de la dirección, la perspectiva de los trabajadores que ejecutan los flujos a diario, y un benchmarking con las mejores prácticas del sector. Sin esas tres voces, el rediseño queda incompleto: la dirección ve el qué, los trabajadores ven el cómo, y el benchmarking muestra el cuánto es posible mejorar.
Secuencial vs. paralelo: la decisión que más divide a los equipos
Hay dos enfoques posibles: rediseñar primero y luego implementar el ERP (secuencial), o hacer ambas cosas al mismo tiempo (paralelo). La respuesta honesta es que el enfoque paralelo tiene un riesgo alto que la mayoría de las organizaciones subestima.
Cuando el equipo está aprendiendo el nuevo sistema a la vez que intenta cambiar cómo trabaja, la carga cognitiva y operativa se dispara. Los plazos se incumplen, las decisiones de diseño se toman con prisas y el resultado es un sistema que refleja el caos del proceso de transición, no el proceso ideal. El enfoque secuencial es más lento en papel, pero casi siempre más rápido en la práctica: el ERP se configura sobre procesos ya validados y la curva de adopción es mucho más corta.
El caso de la distribuidora: 40% menos de ciclo sin una sola customización
Una distribuidora de consumo masivo en Colombia llegó a KCP Dynamics con un proyecto de Dynamics 365 ya iniciado y paralizado. El problema no era técnico: era que nadie había acordado cómo debían funcionar los tres procesos más críticos antes de empezar a configurar el sistema.
Antes de reanudar la implementación, facilitamos una serie de workshops de mapeo de procesos con los equipos de operaciones, finanzas y logística. El objetivo era documentar el estado actual, identificar los pasos sin valor añadido y definir el estado objetivo. Los tres flujos que se sometieron a rediseño fueron picking en almacén, facturación a clientes y reorden de inventario.
El resultado: una reducción del 40% en el ciclo operativo de esos tres procesos, medida antes del go-live del ERP. Cuando Dynamics 365 se implementó, se configuró sobre esos flujos ya validados. No hubo customizaciones de fondo. El sistema estándar encajó porque los procesos rediseñados ya estaban alineados con las mejores prácticas que el ERP tiene incorporadas por defecto.
Ese es el punto que más cuesta transmitir: los ERP maduros como Dynamics 365 incorporan mejores prácticas de industria acumuladas durante años. Cuando una empresa llega con sus flujos renovados y alineados con esos estándares, la implementación es más rápida, más barata y con mayor adopción. Cuando llega con sus procesos tal como están, el proyecto se convierte en un ejercicio de customización que erosiona el ROI desde el primer día.
Herramientas y notaciones para el mapeo de procesos
Hablar de workshops de mapeo sin mencionar con qué herramientas se trabaja deja el método a medias. Existen tres notaciones principales, y elegir la correcta depende del perfil del equipo y del objetivo del análisis, no de la preferencia del consultor.
BPMN, swimlane y VSM: cuándo usar cada una
- BPMN (Business Process Model and Notation): Es el estándar internacional para modelar procesos de negocio con precisión técnica. Usa símbolos normalizados (eventos, tareas, compuertas, flujos) que cualquier analista o desarrollador puede leer. Es la notación más adecuada cuando el proceso modelado va a configurarse directamente en el ERP, porque permite mapear con exactitud las reglas de negocio, las condiciones de bifurcación y las integraciones entre sistemas. En los proyectos de Dynamics 365, el diagrama BPMN del proceso «to-be» se convierte en el documento de referencia para la configuración tras el rediseño.
- Swimlane (diagrama de carriles): Organiza el flujo por responsable o departamento en carriles horizontales o verticales. No tiene la precisión técnica del BPMN, pero es mucho más legible para equipos no técnicos. Es la herramienta ideal para los workshops iniciales con la dirección y los equipos operativos: permite ver de un vistazo quién hace qué, dónde se producen los handoffs entre áreas y dónde se acumulan los cuellos de botella. En KCP Dynamics lo usamos en la fase de diagnóstico «as-is» antes de pasar al BPMN para el «to-be».
- VSM (Value Stream Mapping): Originaria del lean manufacturing, el VSM añade una dimensión que BPMN y swimlane no tienen: el tiempo. Cada paso del proceso lleva asociado el tiempo de proceso y el tiempo de espera, lo que permite calcular el lead time total y el porcentaje de tiempo con valor añadido. Es especialmente útil en procesos de operaciones, logística y producción donde el ciclo temporal es el KPI crítico. En el caso de la distribuidora colombiana, el VSM fue la herramienta que permitió identificar que el 60% del tiempo del proceso de picking era tiempo de espera, no tiempo de trabajo, y orientar así el rediseño hacia donde más impacto tendría.
El mapeo de procesos como herramienta concreta, no como teoría
El mapeo de procesos —o process mapping— no es un ejercicio académico. Es la herramienta que permite ver, en un diagrama que cabe en una pantalla, todos los pasos que hoy se necesitan para completar una tarea y cuáles de esos pasos no aportan valor al cliente ni al negocio. Sin este diagnóstico visual, cualquier intento de rediseño opera sobre suposiciones en lugar de sobre hechos.
Qué se hace en un workshop de mapeo
En los workshops que KCP Dynamics facilita antes de cada implementación, el proceso es sistemático. Primero se documenta el flujo actual —el «as-is»— con las personas que lo ejecutan, no con los managers que creen saber cómo funciona. Esa diferencia es crítica: el proceso real casi siempre difiere del proceso oficial en pasos relevantes que solo afloran cuando se observa el trabajo real.
Luego se analiza cada paso con una pregunta simple: ¿este paso existe porque aporta valor o porque siempre se ha hecho así? Los pasos que sobreviven a ese filtro se incorporan al flujo objetivo —el «to-be»—, que es el que se configura en el ERP. Los que no sobreviven se eliminan antes de que nadie los programe. Este proceso de depuración es, en esencia, el núcleo operativo del rediseño.
El rol de la dirección y de los trabajadores
Una revisión de flujos que solo involucra a la dirección produce un proceso teóricamente correcto pero operativamente imposible. Uno que solo involucra a los trabajadores tiende a conservar los hábitos existentes. La combinación de ambas perspectivas, más el benchmarking sectorial, es lo que genera un proceso que la gente adopta porque lo entiende y porque es mejor que lo que tenía antes.
Según investigación publicada en estudios sobre factores críticos de éxito en ERP, involucrar a los usuarios en el diseño y rediseño de procesos antes de la implementación es uno de los predictores más sólidos de adopción real post go-live. No es un detalle de gestión del cambio: es arquitectura del proyecto.
Métricas de línea base: cómo medir el estado actual antes de rediseñar
No se puede mejorar lo que no se mide. Antes de entrar en cualquier workshop de rediseño, es imprescindible capturar las métricas del proceso actual. Sin una línea base documentada, el ROI del rediseño es una promesa; con ella, es un número. Estos son los cuatro indicadores que KCP Dynamics recoge en todos los proyectos:
- Tiempo de ciclo (cycle time): Tiempo total desde que el proceso empieza hasta que termina, incluyendo esperas. Es el indicador más directo de eficiencia. En el caso de la distribuidora colombiana, el tiempo de ciclo del proceso de picking era el punto de partida que permitió medir la reducción del 40% tras el rediseño.
- Tasa de errores o retrabajo: Porcentaje de veces que el proceso genera un resultado incorrecto que hay que corregir. Un proceso con alta tasa de retrabajo es candidato inmediato al rediseño, independientemente de su frecuencia.
- Número de handoffs (traspasos entre personas o áreas): Cada traspaso es un punto de fricción donde la información puede perderse, deformarse o quedarse atascada. Más de tres handoffs en un proceso operativo habitual suele ser señal de fragmentación innecesaria.
- FTE involucrados (Full-Time Equivalents): Cuántas personas participan en el proceso y en qué proporción de su jornada. Este dato conecta directamente con el coste operativo y permite calcular el ahorro potencial en horas-persona tras el rediseño.
Documentar estas cuatro métricas antes del workshop toma entre dos y cuatro horas por proceso. El tiempo invertido se recupera en la primera sesión: los participantes dejan de discutir sobre percepciones y empiezan a trabajar sobre datos.
Cómo encaja el rediseño en la metodología Success by Design de Microsoft
Los proyectos de Dynamics 365 bien ejecutados no empiezan en la configuración: empiezan en el diagnóstico. La metodología Success by Design de Microsoft —el marco de referencia oficial para implementaciones de Dynamics 365— estructura el ciclo de vida en cinco fases: Discover, Initiate, Implement, Prepare y Operate. El rediseño de procesos pertenece a las dos primeras.
Ver los datos
| Cuándo | Qué | Detalle |
|---|---|---|
| Fase 1 | Discover | Se documenta el estado actual (as-is) con los equipos que ejecutan los procesos. |
| Fase 2 | Initiate | Se valida el estado objetivo (to-be) antes de que empiece cualquier configuración. |
| Fase 3 | Implement | Se configura el ERP sobre los flujos ya rediseñados y validados. |
| Fase 4 | Prepare | Pruebas, formación y preparación del go-live. |
| Fase 5 | Operate | El sistema arranca con procesos alineados a las mejores prácticas del ERP. |
Una solución orientada a procesos permite definir, diseñar, construir, probar y dar soporte a la implementación de Dynamics 365 usando los procesos de negocio extremo a extremo como marco de referencia. En la práctica, esto significa que la fase Discover es el momento de documentar el «as-is» y la fase Initiate es donde se valida el «to-be» antes de que empiece cualquier configuración. Completar esas dos fases con rigor equivale a completar el ciclo de rediseño antes de que arranque el desarrollo.
FastTrack para Dynamics 365 es el programa de éxito del cliente gestionado por el equipo de ingeniería de producto de Dynamics 365 en Microsoft, cuyo objetivo es ayudar a los clientes a implementar Dynamics 365 y obtener valor de negocio más rápidamente. Cuando un partner como KCP Dynamics trabaja alineado con este marco, el rediseño previo no es un extra: es la condición que hace posible aprovechar la funcionalidad estándar del sistema sin customizaciones innecesarias.
Cómo KCP Dynamics integra el rediseño en cada implementación de Dynamics 365
En KCP Dynamics no vendemos el rediseño de procesos como un servicio adicional. Lo tratamos como un requisito previo no negociable para que la implementación de Dynamics 365 funcione. Un ERP implementado sobre procesos sin revisar es una deuda técnica y operativa que el cliente pagará durante años.
Por eso cada proyecto comienza con una fase de diagnóstico donde se mapean los procesos críticos, se identifican las brechas respecto a las mejores prácticas de Dynamics 365 y se define el alcance real de la implementación. Ese diagnóstico determina qué se puede configurar con funcionalidad estándar —que es siempre la opción preferida— y qué requeriría una customización que habría que justificar con un análisis de coste-beneficio explícito.
El objetivo es que cuando el sistema arranque, el equipo trabaje mejor que antes, no igual que antes pero con una pantalla diferente. Esa es la diferencia entre una implementación exitosa y una que acumula tickets de soporte durante dieciocho meses. Y esa diferencia, en casi todos los proyectos que hemos visto fracasar, se decide en la fase de rediseño: o se hace bien al principio, o se paga caro al final.
Preguntas frecuentes
¿Cuánto tiempo lleva rediseñar procesos antes de implementar un ERP?
Depende del número de procesos críticos y de la madurez documental de la empresa. En proyectos medianos con tres o cuatro procesos clave, un ciclo de workshops de mapeo y validación suele completarse en cuatro a ocho semanas. Ese tiempo se recupera con creces en la fase de configuración del ERP, que es más rápida y genera menos incidencias.
¿El rediseño de procesos es lo mismo que el business process reengineering (BPR)?
El business process reengineering es el enfoque formal que implica rediseñar procesos desde cero, cuestionando su razón de ser. El rediseño de procesos en el contexto de una implementación de ERP puede ser más incremental: no siempre hace falta reinventar todo, sino eliminar los pasos sin valor y alinear los flujos con las mejores prácticas que el software ya incorpora. En KCP Dynamics aplicamos el nivel de profundidad que cada proceso necesita, no uno fijo para todos.
¿Qué pasa si rediseñamos procesos y luego el ERP no los soporta?
Es una pregunta legítima, y la respuesta es que el orden correcto es el inverso: primero se entiende qué soporta el ERP de forma estándar, y luego se diseñan los procesos para aprovechar esa funcionalidad. Dynamics 365 tiene una cobertura funcional muy amplia para manufactura, distribución y servicios financieros. Cuando el rediseño se hace con conocimiento de esa cobertura —como ocurre en los workshops que facilita KCP Dynamics—, la necesidad de customización se reduce drásticamente.
¿Cómo se gestiona la resistencia al cambio durante el rediseño?
La resistencia al cambio es el principal obstáculo en cualquier proceso de rediseño. La forma más eficaz de reducirla es involucrar a los equipos operativos desde el primer día: que sean ellos quienes identifiquen los pasos inútiles, no consultores externos que llegan a decirles cómo trabajar. Cuando el equipo co-diseña el proceso nuevo, la adopción posterior es significativamente mayor porque el cambio es suyo, no impuesto.
¿Se puede medir el ROI del rediseño de procesos antes del go-live?
Sí, y es recomendable hacerlo. El punto de partida es documentar métricas del proceso actual: tiempo de ciclo, tasa de errores, número de pasos, personas involucradas. Una vez definido el proceso objetivo, se pueden proyectar las mejoras esperadas y compararlas con el coste del rediseño. En el caso de la distribuidora colombiana que trabajó con KCP Dynamics, la reducción del 40% en el ciclo operativo se midió sobre esas métricas de línea base antes de arrancar el ERP.
¿Qué notación de mapeo es mejor: BPMN, swimlane o VSM?
Depende del objetivo. BPMN es la más precisa para documentar el proceso «to-be» que se va a configurar en el ERP. Los diagramas swimlane son más accesibles para equipos no técnicos y son ideales en los workshops de diagnóstico. El VSM (Value Stream Mapping) es la mejor opción cuando el tiempo de ciclo es el KPI crítico, especialmente en procesos de operaciones y logística. En la práctica, un buen proyecto de rediseño combina las tres: swimlane para el diagnóstico, BPMN para el diseño técnico y VSM cuando hay que cuantificar el desperdicio de tiempo.