Saltar al contenido

Blog

Cómo saber si tu ECC está listo para una conversión

Una lista de verificación que tu propio equipo de TI puede aplicar antes de llamar a un consultor. Lo que conviene revisar y por qué cada punto importa.

Equipo HICS 4 min de lectura

Antes de llamar a un consultor, tu propio equipo de TI puede revisar buena parte de lo que define si una conversión a S/4HANA va a ser tranquila o accidentada. No necesitas herramientas caras ni un experto externo para estos puntos. Necesitas tiempo y honestidad para mirar el sistema como está, no como te gustaría que estuviera. Esta es la lista.

Cómo usar esta lista

Recórrela punto por punto y marca cada uno en verde, amarillo o rojo. No busques que todo esté en verde: casi ningún ECC lo está. Busca saber dónde estás parado, porque los puntos en rojo son los que van a mover el tiempo y el costo de tu proyecto. Un consultor serio va a revisar esto mismo; llegar con la tarea hecha acorta el diagnóstico y te da con qué contrastar lo que te digan.

La lista de verificación

  1. Versión y nivel de tu ECC. Anota tu release y nivel de soporte. Cuanto más viejo, más pasos previos puede pedir la conversión.
  2. Inventario de desarrollos Z. Cuántos programas propios tienes y, sobre todo, cuántos se usan de verdad. Muchos catálogos de Z están llenos de código muerto.
  3. Uso real de esos desarrollos. Revisa estadísticas de uso. Lo que nadie ejecuta desde hace años no hay que migrarlo, hay que retirarlo.
  4. Integraciones con terceros. Lista cada sistema externo que habla con SAP: bancos, facturación, logística, portales. Cada interfaz es trabajo aparte.
  5. Modificaciones al estándar. Distingue entre desarrollos propios y modificaciones directas al código de SAP. Estas últimas complican la conversión.
  6. Calidad de los datos maestros. Busca duplicados de clientes, proveedores y materiales, y registros incompletos. Es el costo oculto más frecuente.
  7. Localización mexicana. Identifica cómo resuelves hoy facturación electrónica, Carta Porte y contabilidad electrónica, y si son de SAP o de un tercero.
  8. Documentación de procesos. ¿Existe? Si el conocimiento vive solo en la cabeza de dos personas, eso es un riesgo del proyecto.
  9. Infraestructura actual. Dónde corre tu SAP hoy y qué contrato lo sostiene. S/4HANA exige HANA y eso cambia el panorama.
  10. Disponibilidad del equipo. Sé honesto sobre cuánto tiempo real pueden dedicar tus expertos de procesos al proyecto sin soltar la operación.

Qué hacer con los puntos en rojo

Un rojo no descalifica tu proyecto. Solo te dice dónde va a estar el trabajo. Muchos desarrollos Z sin uso significan que hay que hacer una limpieza antes de migrar, y eso baja el costo. Datos sucios significan un esfuerzo de limpieza que conviene empezar ya, porque no depende del proveedor. Integraciones numerosas significan que el análisis de interfaces va a ser una parte grande del diagnóstico.

Cómo leer tu inventario de desarrollos Z

El número de programas Z asusta menos cuando lo separas en tres montones. Los que se usan seguido y son críticos: hay que llevarlos y ajustarlos. Los que se usan poco: candidatos a simplificar o reemplazar por funcionalidad estándar de S/4HANA, que trae muchas cosas que antes había que programar. Y los que no se usan desde hace años: no se migran, se retiran. Ese ejercicio de clasificación, que tu equipo puede empezar solo, muchas veces reduce el alcance real a la mitad de lo que parecía al principio.

Las integraciones son el punto ciego más común

Casi siempre hay más integraciones de las que alguien recuerda. Bancos, facturación, portales de clientes, sistemas de logística, tableros. Cada interfaz que hoy funciona hay que confirmarla en S/4HANA: si el método sigue disponible, si el tercero tiene versión compatible, y quién la prueba. Haz una lista real recorriendo lo que entra y sale de tu SAP, no la que está en la documentación vieja. Una integración olvidada es una sorpresa cara en pruebas.

Qué no vas a poder evaluar solo, y está bien

Esta lista te lleva lejos, pero no reemplaza a las herramientas de análisis que SAP y los implementadores usan para revisar la compatibilidad del código y el estado técnico del sistema. Eso es parte de un diagnóstico formal. La diferencia es que ahora llegas a ese diagnóstico sabiendo qué esperar, con tus propias respuestas para contrastar, en lugar de recibir un veredicto que no puedes cuestionar.

Convierte la lista en un plan

Cuando termines, ordena tus rojos por esfuerzo y por dependencia. La limpieza de datos y el retiro de Z sin uso los puedes empezar hoy, sin proveedor. El análisis de integraciones y la elección de ruta necesitan al consultor. Tener claro qué es tuyo y qué es del proveedor evita pagar por trabajo que tu equipo podía adelantar.

El siguiente paso

Con esta lista llena tienes la mitad de un diagnóstico. Si quieres traducir tus respuestas a un rango de tiempo y costo, la calculadora usa justo estas variables.

Estima tu migración con la calculadora.

¿Tienes este problema en tu instalación?

Platicar del proyecto

Sigue leyendo

Ver todo el tema

← Todas las entradas