Implementación de Epicor Kinetic: qué implica y cómo elegir un socio
Lo que la empresa decide antes del inicio del proyecto, y cómo evaluar a un socio.
Gonzalo Nuñez
Chief Technology Officer
Reemplazar un sistema heredado con Epicor Kinetic es una de las decisiones operativas más importantes que toma un fabricante. El software es capaz. La metodología existe. Lo que determina si el proyecto da resultados es lo que la empresa decide y asume como propio antes del arranque, y si el socio que elija puede ejecutar en su entorno específico.
Esta guía está escrita para la persona que firmará la declaración de trabajo. Explica qué implica realmente una implementación de Kinetic, dónde se estancan los proyectos, el trabajo de datos que solo la empresa puede hacer y cómo evaluar a cualquier socio de implementación antes de comprometerse.
Qué es una implementación de Epicor Kinetic y qué no es
Una implementación de Epicor Kinetic es el proceso de reemplazar un sistema ERP heredado o que no es de Epicor con Kinetic como columna vertebral operativa de la empresa. Abarca el alcance completo: configuración del sistema, diseño de procesos, migración de datos, integración con sistemas conectados, capacitación y puesta en marcha.
No es una actualización. Si usted ya utiliza Epicor 10 y va a pasar a Kinetic, se trata de un camino distinto, con sus propias consideraciones. Consulte De Epicor 10 a Kinetic: qué implica la actualización para conocer ese camino.
Tampoco es una decisión de producto. Si todavía está evaluando si Kinetic es la plataforma adecuada para su operación, comience con Epicor Kinetic frente a Epicor ERP: qué cambió y si conviene migrar. Esta guía supone que la decisión ya está tomada y que el proyecto se está definiendo.
Qué ofrece Epicor y qué no
Epicor le entrega la licencia, una metodología y una amplia red de socios. La ejecución diaria del proyecto recae en el equipo de implementación, y la línea entre lo que entrega Epicor y lo que entrega un socio se define en cada proyecto. Esto significa que la calidad del proyecto depende del socio que usted elija, de cómo esté conformado su equipo y de qué tan claramente la declaración de trabajo defina el alcance, el precio y la responsabilidad.
Comprender esta distinción desde el principio cambia la forma en que un comprador aborda la evaluación. Usted no solo está comprando software. Está seleccionando al equipo que dirigirá un proyecto que toca todas las áreas de su operación.
Lo que la empresa debe decidir antes del arranque
Las decisiones que determinan si una implementación de Kinetic tiene éxito se toman antes de que el socio empiece a configurar cualquier cosa. Un fabricante que aplaza estas decisiones le entrega el control del proyecto al socio por defecto. Así es como crece el alcance y se retrasan los plazos.
Asigne un responsable interno del proyecto con autoridad real
La implementación necesita a una persona dentro de la empresa que la asuma como propia. No un comité. No una responsabilidad rotativa. Una persona con capacidad de decisión, con suficiente tiempo dedicado al proyecto y con el peso organizacional para resolver desacuerdos entre departamentos.
Las implementaciones se estancan cuando nadie dentro de la empresa tiene la autoridad para tomar una decisión y hacer que se respete. El socio puede asesorar. El socio no puede decidir por usted.
Asigne un responsable de proceso para cada área funcional
Además del responsable del proyecto, cada área funcional importante necesita a alguien que entienda el proceso actual y pueda aprobar cómo funcionará en Kinetic. Las áreas que requieren cobertura son:
- De la cotización al cobro: cómo se crean, se fijan los precios y se facturan los pedidos
- Del pedido al envío: cómo se liberan y se cumplen las órdenes de producción
- Compras: cómo se crean, se reciben y se concilian las órdenes de compra
- Inventario: cómo se rastrean, se cuentan y se valoran los artículos
- Programación: cómo se planifica y se secuencia la producción
- Finanzas: cómo se estructuran la contabilidad general, las cuentas por pagar y las cuentas por cobrar
Estas no son decisiones de TI. Son decisiones operativas que tienen consecuencias en el sistema.
Decida qué modalidad de manufactura guía el diseño
Kinetic admite varias modalidades de manufactura: fabricación para inventario, fabricación bajo pedido, ingeniería bajo pedido, configuración bajo pedido y entornos mixtos. La modalidad que describe su operación guía el diseño de la configuración. Un socio que no hace esta pregunta desde el principio no está diseñando para su entorno.
Decida si adoptará procesos estándar o conservará los actuales
Esta decisión da forma a todo el proyecto, y es fácil dejarla sin mencionar hasta que el diseño ya está en marcha. Los procesos estándar de Kinetic existen por una razón. Están probados, cuentan con soporte y se pueden actualizar. Alejarse de ellos mediante personalizaciones crea un sistema más difícil de mantener y más difícil de actualizar.
La pregunta no es si se debe personalizar o no. Es cuáles brechas son realmente críticas para el negocio y cuáles son hábitos que se pueden cambiar. Esa decisión le corresponde a la empresa, no al socio.
Decida qué sistemas permanecen y se conectan
Kinetic no reemplazará todos los sistemas de la empresa. Identifique qué sistemas siguen en funcionamiento después de la puesta en marcha y qué integraciones deben construirse o mantenerse. Esto incluye sistemas de piso de producción, sistemas de calidad, gestión de almacenes y cualquier herramienta de cara al cliente.
Decida si el CRM forma parte del plan
Si la empresa utiliza un CRM, o planea hacerlo, el momento de planificar esa integración es antes de que Kinetic entre en operación, no después. El maestro de clientes y la lógica de precios se diseñan una sola vez si el plan existe desde el inicio. Diseñarlos por segunda vez después de la puesta en marcha implica reabrir decisiones sobre las que la empresa ya está operando. Para conocer cómo funciona la integración, consulte la página del servicio de integración CRM-ERP.
Dónde se estancan las implementaciones de Epicor Kinetic
Los profesionales que han pasado por implementaciones de Kinetic describen los riesgos siguientes en los hilos de sus propios proyectos. Ninguno es inevitable. Todos se pueden abordar durante la planificación, pero solo si se identifican antes de que comience el proyecto.
Alcance que crece después del descubrimiento
El descubrimiento saca a la luz requisitos que la propuesta inicial no incluía. Eso es de esperarse. El riesgo aparece cuando esos requisitos se agregan al proyecto sin un ajuste correspondiente en la declaración de trabajo, el precio o el cronograma. El crecimiento del alcance que no se controla formalmente se convierte en problema del socio sobre el papel y en problema de la empresa en la práctica.
Antes de firmar, entienda cómo maneja la declaración de trabajo los cambios. ¿Qué activa una orden de cambio? ¿Quién la aprueba? ¿Qué sucede con la fecha de puesta en marcha cuando cambia el alcance?
Limpieza de datos que comienza demasiado tarde
La migración de datos no es una tarea técnica que el socio maneja en segundo plano. Requiere que la empresa tome decisiones: qué registros están vigentes, cuáles son obsoletos, qué debe corregirse antes de migrar. Ese trabajo depende de personas dentro de la empresa y no puede comenzar hasta que la empresa se involucre.
Las implementaciones que aplazan la limpieza de datos hasta etapas avanzadas del proyecto llegan al corte con registros sin resolver. El socio no puede limpiar datos que no le pertenecen.
Reconstruir el sistema anterior mediante personalizaciones
La personalización no es mala en sí misma. El riesgo está en la personalización que recrea la lógica del sistema heredado dentro de Kinetic en lugar de evaluar si esa lógica todavía le sirve al negocio. Cada personalización agrega carga de mantenimiento, complica las actualizaciones futuras y puede crear dependencias que el socio no documentó.
La disciplina que se requiere es disciplina de negocio, no disciplina técnica. Alguien dentro de la empresa tiene que estar dispuesto a cuestionar si un proceso actual debe conservarse o si simplemente es familiar.
Usuarios clave que regresan al trabajo diario
Las implementaciones requieren tiempo sostenido de personas que además dirigen el negocio. Cuando las presiones de producción hacen volver a los usuarios clave a sus labores cotidianas, el proyecto pierde a quienes entienden los procesos que se están configurando. Las decisiones se aplazan, las pruebas se comprimen y la puesta en marcha llega con brechas que salen a la superficie después del corte.
Este es un problema de planificación de recursos, no de gestión de proyectos. Debe resolverse antes de que comience el proyecto, no manejarse sobre la marcha.
Capacitación desconectada de la puesta en marcha
La capacitación que se imparte demasiado pronto se olvida para cuando llega la puesta en marcha. La que se imparte demasiado tarde deja a los usuarios sin preparación. El momento, el formato y la profundidad de la capacitación deben definirse en la declaración de trabajo, no dejarse al enfoque estándar del socio. La capacitación por rol, impartida cerca de la puesta en marcha y reforzada durante la estabilización, mantiene lo que los usuarios aprenden conectado con el sistema que realmente operarán.
Ningún responsable interno con autoridad
Este riesgo aparece al final porque amplifica todos los demás de esta lista. Sin un responsable interno con autoridad real y tiempo asignado, las decisiones se escalan, se aplazan o las toma la persona equivocada. El socio llena el vacío con su propio criterio, que puede no reflejar las prioridades reales de la empresa.
El trabajo de datos que solo la empresa puede hacer
La migración de datos es el punto en el que los compradores pueden suponer que el socio se hace cargo. En la práctica, la empresa es dueña de las decisiones que determinan si la migración tiene éxito. El socio puede ejecutar la carga técnica. No puede decidir cómo deben verse los datos de la empresa.
Decida qué historial traer
No todos los datos del sistema heredado pertenecen a Kinetic. La pregunta no es qué se puede migrar. Es qué necesita la empresa para operar, generar reportes y auditar después de la puesta en marcha.
Los datos maestros pasan: artículos, listas de materiales, rutas, clientes, proveedores. Las transacciones abiertas pasan: pedidos de venta abiertos, órdenes de compra abiertas, órdenes de trabajo abiertas, saldos abiertos de cuentas por pagar y por cobrar. El detalle histórico de transacciones, como pedidos cerrados, órdenes de trabajo terminadas y estados financieros archivados, es una decisión aparte. Traerlo agrega alcance y complejidad a la migración. Dejarlo atrás significa que solo seguirá accesible en el sistema heredado.
Esa decisión requiere la participación de finanzas, operaciones y de quien gestione los requisitos regulatorios o de auditoría. El socio puede asesorar sobre las implicaciones técnicas. La empresa tiene que tomar la decisión.
Limpie los registros antes de que comience la migración
Los datos del sistema heredado reflejan toda la vida de ese sistema, lo que significa que también reflejan sus soluciones provisionales, inconsistencias, registros duplicados y entradas obsoletas. Maestros de artículos con campos faltantes, registros de clientes con direcciones contradictorias, listas de materiales que ya no coinciden con el producto actual, proveedores que ya no están activos: todo pasa a Kinetic a menos que la empresa lo revise y lo corrija antes.
El perfilado de datos, que consiste en examinar los datos heredados antes de que comience la migración, es el paso que hace visible el alcance de la limpieza. También es el paso que se comprime cuando el cronograma del proyecto es ajustado. El efecto de omitirlo se ve en el corte, cuando registros que debieron corregirse llegan a Kinetic sin corregir.
Asuma la aprobación de la conciliación
Antes del corte, la migración debe verificarse. Se ejecutan cargas de prueba, se comparan los conteos y se resuelven las discrepancias. Esa verificación requiere a alguien de la empresa que entienda cuáles deberían ser las cifras, no solo cuáles son.
El socio de implementación ejecuta las cargas de prueba. La empresa aprueba la conciliación. Si nadie dentro de la empresa tiene el conocimiento o el tiempo para hacerlo, la aprobación se vuelve una formalidad en lugar de una verificación. Ese es un riesgo que sale a la superficie después de la puesta en marcha, no antes.
Cómo evaluar a un socio de implementación de Epicor Kinetic
Los criterios siguientes aplican a cualquier socio. Utilícelos en cada conversación antes de firmar.
Condición verificable de socio de Epicor
Pida al socio su nivel de socio de Epicor y evidencia de que su equipo cuenta con certificaciones vigentes de productos de Epicor. Luego verifique al socio en el directorio de socios de Epicor. No son la misma pregunta. El directorio confirma que la relación existe. Las certificaciones confirman que las personas que hacen el trabajo están al día en la plataforma.
Experiencia en su modalidad de manufactura
Un socio con sólida experiencia en fabricación para inventario no es automáticamente la opción correcta para un entorno de ingeniería bajo pedido. Pida referencias de fabricantes cuyas operaciones se parezcan a la suya, no solo de fabricantes de su industria. La modalidad importa más que el sector.
Si usted es un fabricante con requisitos de captura de datos en el piso de producción, pregunte específicamente cómo ha manejado el socio la ejecución de manufactura avanzada en proyectos anteriores.
Quién integra realmente el equipo del proyecto
El equipo que presenta durante el proceso de ventas no siempre es el que dirige la implementación. Pregunte quién será asignado específicamente a su proyecto: el gerente de proyecto, los consultores funcionales, los recursos técnicos. Pregunte qué sucede si un integrante clave del equipo se va a mitad del proyecto. Obtenga la respuesta por escrito en la declaración de trabajo.
Cómo se estructuran el alcance y el precio
Entienda si el contrato es de precio fijo para un alcance definido o de tiempo y materiales. Cada modelo impone obligaciones distintas a la empresa. Con un modelo de precio fijo, la definición del alcance desde el inicio es crítica. Con tiempo y materiales, la empresa asume el riesgo del crecimiento del alcance. Ningún modelo es mejor por sí mismo, pero el comprador debe entender qué significa cada uno para su nivel de exposición.
Enfoque de migración de datos
Pregunte cómo maneja el socio las cargas de prueba y la conciliación. Pregunte quién es responsable del perfilado de datos y cuándo comienza. Pregunte qué espera el socio que la empresa proporcione y en qué formato. Un socio que no puede responder estas preguntas con detalle no ha pensado a fondo la migración.
Enfoque de capacitación
Pregunte si la capacitación es por rol. Pregunte cuándo se imparte en relación con la puesta en marcha. Pregunte qué sucede durante el periodo de estabilización posterior al corte. La capacitación que no está ligada a la fecha real de puesta en marcha ni a los roles reales de los usuarios no es un plan de capacitación.
Soporte posterior a la puesta en marcha
Pregunte cómo es el soporte después del corte. Pregunte cómo está estructurado, qué incluye y qué requiere un contrato aparte. Defínalo en el contrato antes de firmar.
Capacidad en CRM e integración
Si la integración con CRM forma parte del plan, pregunte si el socio ya ha construido esa integración, en qué sistemas y si puede dimensionarse al mismo tiempo que el ERP. Un socio que trata el CRM como un complemento posterior a la puesta en marcha no está planificando el proyecto correctamente.
Idioma y geografía
Si usted es un fabricante con plantas en varios países, pregunte si el socio puede respaldar la implementación en los idiomas y las zonas horarias donde se realizará el trabajo.
Technology Coast Partners (TCP) es un Epicor Platinum Partner que ha dirigido implementaciones de Kinetic durante más de una década, tanto en inglés como en español. Entre sus clientes se encuentran Greenpaper, Tecnas, IPSL e IMPELMEX, todos en México.
Conozca cómo TCP dirige las implementaciones de Kinetic
Hable con TCP sobre su implementación de Kinetic
Preguntas que debe hacer antes de firmar
Llévelas a cualquier reunión con un socio. No son un discurso de ventas. Son las preguntas que un comprador necesita ver respondidas antes de comprometerse con una declaración de trabajo.
Sobre alcance y responsabilidad:
- ¿Qué se incluye en el alcance fijo y qué activa una orden de cambio?
- ¿Quiénes de su equipo serán asignados a este proyecto, por nombre?
- ¿Qué sucede con el cronograma y el precio si cambia un integrante clave del equipo?
Sobre su entorno de manufactura:
- ¿Han implementado Kinetic para fabricantes en nuestra modalidad (ingeniería bajo pedido, configuración bajo pedido, fabricación bajo pedido, fabricación para inventario)?
- ¿Pueden proporcionar referencias de fabricantes cuyas operaciones se parezcan a la nuestra?
Sobre la migración de datos:
- ¿Cuándo comienza el perfilado de datos y quién es responsable de él?
- ¿Cuántas cargas de prueba están incluidas y cómo se verifica la conciliación?
- ¿Qué necesita preparar la empresa y para cuándo?
Sobre la capacitación:
- ¿La capacitación es por rol y por turno?
- ¿Cuándo se imparte en relación con la puesta en marcha?
- ¿Qué cubre el periodo de estabilización y por cuánto tiempo está definido en el contrato?
Sobre la declaración de trabajo:
- ¿La declaración de trabajo nombra al equipo del proyecto?
- ¿Define el proceso de órdenes de cambio?
- ¿Define el soporte posterior a la puesta en marcha, incluido lo que está incluido y lo que no?
- Si la integración con CRM está dentro del alcance, ¿está definida en esta declaración de trabajo o en una aparte?
Sobre el papel de Epicor:
- ¿Qué entrega Epicor directamente en este proyecto y qué entrega su equipo?
Un socio que no puede responder estas preguntas con precisión, antes de que se firme la declaración de trabajo, no está listo para dirigir el proyecto.
Si usted está planeando una implementación de Epicor Kinetic, TCP la dimensiona a precio fijo, con el CRM planificado desde el inicio y el corte planificado en función de la producción.
Preguntas Frecuentes
Verifique primero la empresa en el directorio de socios de Epicor, porque el directorio confirma que existe la relación de socio con Epicor. Después, pregunte directamente al socio por su nivel de socio de Epicor y solicite pruebas de que su equipo cuenta con certificaciones vigentes de los productos de Epicor. Las dos verificaciones responden a preguntas distintas. El directorio confirma la relación. Las certificaciones confirman que las personas que realizarán el trabajo en su proyecto están al día con la plataforma. Conviene realizar ambas verificaciones antes de firmar una declaración de trabajo con cualquier socio.
El documento de alcance de trabajo (statement of work) debe definir el alcance con el detalle suficiente para que cualquier adición requiera una orden de cambio formal. Debe nombrar al equipo del proyecto del socio, definir el proceso de órdenes de cambio, indicar cómo se gestiona la migración de datos, incluidas las cargas de prueba y la conciliación, describir la capacitación por rol y su momento respecto a la puesta en marcha, definir el soporte posterior a la puesta en marcha, con lo que se incluye y lo que no, y abordar la integración con el CRM si está dentro del alcance. Todo aquello que se deje sin definir en el documento de alcance de trabajo se resolverá más adelante, bajo presión, cuando es más difícil cambiarlo.
Bajo un modelo de precio fijo, el alcance debe definirse con precisión antes de que comience el proyecto. Cualquier adición requiere una orden de cambio, lo que significa que la empresa controla a qué se compromete. Bajo un modelo de tiempo y materiales, la empresa paga por el tiempo que dedica el socio, lo que significa que el crecimiento del alcance es una exposición financiera de la empresa. Ningún modelo elimina el riesgo. El precio fijo traslada el riesgo al socio cuando el alcance está bien definido. El modelo de tiempo y materiales traslada el riesgo al comprador cuando el alcance está abierto. El modelo adecuado depende de qué tan bien pueda la empresa definir sus requisitos antes de que el proyecto comience.
Una sola persona, con autoridad para tomar decisiones y tiempo dedicado. Esa persona debe tener la antigüedad suficiente para resolver desacuerdos entre departamentos, estar lo bastante disponible para responder a las decisiones en un plazo razonable y contar con la facultad de decir sí o no sin escalar cada decisión. Un comité no puede ser responsable de una implementación. Una persona a quien se le asigna el rol, pero no se le da el tiempo, tampoco puede serlo. Esta es una decisión de asignación de recursos que debe tomarse antes de que comience el proyecto, no cuando ya está en marcha.
Las decisiones se aplazan, las pruebas se comprimen y las brechas aparecen en el go-live. El socio implementador no puede configurar procesos que no comprende, ni puede probar escenarios que el negocio no ha revisado. Si los usuarios clave no están disponibles, el proyecto o bien se ralentiza para adaptarse a su disponibilidad o bien avanza sin su aportación. Ninguno de los dos resultados es aceptable. La solución es un plan de recursos acordado antes del inicio, con el compromiso de la dirección del negocio de proteger el tiempo de las personas de las que depende el proyecto.
Ambas opciones son válidas. La cuestión es qué brechas son realmente críticas para el negocio y cuáles son simples hábitos. Los procesos estándar de Kinetic están probados, cuentan con soporte y se pueden actualizar. Las personalizaciones añaden carga de mantenimiento y pueden complicar las futuras actualizaciones. El enfoque práctico consiste en partir del sistema estándar, identificar las brechas que afectarían de manera importante a las operaciones y personalizar únicamente esas. Las brechas que responden a una preferencia y no a una necesidad operativa son candidatas a un cambio de proceso. La empresa debe emitir ese juicio. El socio puede asesorar sobre el impacto técnico de cada personalización, pero no puede decidir qué procesos vale la pena conservar.
El detalle histórico de transacciones que la empresa no necesita para las operaciones diarias ni para los informes activos es un candidato para dejarlo atrás. Esto incluye pedidos cerrados, órdenes de trabajo completadas y períodos financieros archivados que excedan lo que exigen los requisitos de auditoría o regulatorios. El sistema heredado sigue siendo accesible después de la puesta en marcha, por lo que el historial no desaparece. Lo que se traslada son los datos maestros (artículos, listas de materiales, rutas, clientes, proveedores) y las transacciones abiertas (pedidos de venta abiertos, órdenes de compra, órdenes de trabajo y saldos abiertos de cuentas por pagar y por cobrar). La decisión sobre la profundidad del historial requiere la opinión de finanzas y de quien gestione las obligaciones de auditoría o cumplimiento de la empresa.
Acceso a las personas que entienden los procesos actuales, no solo a quienes los gestionan. Una lista de los sistemas que se utilizan actualmente y de los que permanecerán después de la puesta en marcha. Una declaración clara de los modos de fabricación en los que opera la empresa. Una visión inicial de los volúmenes y la calidad de los datos del sistema heredado. Y un responsable interno del proyecto, designado por su nombre, con autoridad para tomar decisiones. La fase de descubrimiento no puede producir un diseño útil si el socio trabaja a partir de suposiciones en lugar de hechos. Cuanto más prepare la empresa antes del descubrimiento, más útil será el resultado.
El soporte posterior a la puesta en marcha debe cubrir el período de estabilización inmediatamente posterior al cambio, cuando los usuarios operan por primera vez con el nuevo sistema y los problemas surgen rápidamente. Debe definir los tiempos de respuesta, quiénes están disponibles y qué categorías de incidencias están incluidas. También debe definir qué queda fuera del alcance del soporte y requiere un contrato aparte. La duración y el alcance del soporte deben establecerse en el contrato antes de la puesta en marcha, y no negociarse después del cambio, cuando la empresa no tiene capacidad de negociación. La duración de ese período es una decisión comercial entre la empresa y el socio.
No existe una línea divisoria clara y publicada entre lo que Epicor entrega directamente y lo que entrega un socio de Epicor. Epicor publica una metodología y ofrece servicios, pero la división entre el trabajo entregado por Epicor y el entregado por el socio varía según cada proyecto. Antes de firmar con cualquier socio, pregunte de forma específica: ¿qué entrega Epicor directamente en este proyecto y qué entrega su equipo? Exija una respuesta concreta, no una descripción de la metodología. La respuesta le indica quién es responsable de qué y a quién acudir cuando sea necesario resolver un problema.
