Cuando una decisión tecnológica sale mal, casi nunca falla la ejecución. El error suele venir de antes, del momento en que alguien decidió qué hacer sin haber entendido del todo sobre qué lo estaba haciendo. Se contrata un ERP, se pone en marcha un proyecto de digitalización, y meses después aparece la pregunta que debió hacerse al principio, ¿esto encaja con cómo funciona de verdad nuestra empresa?
La Fase 1 de MITKORE existe precisamente para darle la vuelta a ese orden. Antes de transformar nada, y desde luego, antes de comparar herramientas o pedir presupuestos, hay que comprender la organización. Hay que comprender cómo se relacionan su negocio, sus procesos y su tecnología, y en qué puntos esa relación se ha roto o directamente nunca llegó a existir. De esta fase depende que todo lo que venga después tenga sentido, en lugar de convertirse en una capa más de complejidad.
Por qué el diagnóstico empieza por el negocio, no por los sistemas
Un diagnóstico estructural no arranca preguntando qué sistemas tiene la empresa, sino qué empresa es: cómo gana dinero, qué promete a sus clientes, qué procesos sostienen esa promesa y qué decisiones toma dirección cada semana para que todo funcione. Solo entonces tiene sentido mirar la tecnología, y no para evaluarla en abstracto, sino para responder a una pregunta muy concreta, ¿está al servicio de ese modelo de negocio o vive en paralelo a él?
En la práctica, la Fase 1 trabaja sobre tres capas y, sobre todo, sobre las costuras que las unen. Por un lado el negocio, con su modelo y sus prioridades. Por otro lado, los procesos, entendidos como el trabajo tal y como se hace de verdad, que rara vez coincide con lo que dice el organigrama. Y por último la tecnología; qué sistemas existen, quién los usa y qué información producen. Lo interesante es que el hallazgo casi nunca está dentro de una de las capas, sino en los huecos entre ellas; en ese proceso comercial que el sistema no recoge, en el dato que existe en tres sitios con tres versiones distintas, o en la información que la operativa ya genera pero que nadie consolida para que dirección pueda utilizarla.
Por qué el orden del análisis cambia el resultado
Podría pensarse que da igual por dónde se empiece, pero la experiencia demuestra lo contrario. Si el análisis arranca por la tecnología, la conversación se contamina enseguida de funcionalidades, versiones y comparativas, y la empresa acaba adaptando su forma de pensar al catálogo de lo que hay disponible en el mercado.
Si arranca por el negocio, ocurre algo distinto. Primero queda claro qué necesita la organización para sostener su modelo y crecer con él; después se examinan los procesos que deberían producir ese resultado; y solo al final se evalúa si la tecnología actual sirve, sobra o falta. La tecnología deja de ser el punto de partida y pasa a ocupar el lugar que siempre debió tener: el de consecuencia.
Este orden tiene además un efecto menos visible pero decisivo, y es que obliga a dirección a participar. Un análisis que empieza por los sistemas se delega en IT con facilidad. En cambio, uno que empieza por el modelo de negocio no puede delegarse, porque las respuestas a las primeras preguntas solo las tiene quien dirige. En ese sentido, la Fase 1 es una fase de dirección, no una fase técnica.
Lo que se evita diagnosticando antes de actuar
El coste de saltarse esta fase rara vez se nota de inmediato. Suele notar en el corto o medio plazo, cuando el sistema ya está implantado y el equipo sigue trabajando fuera de él, en forma de integraciones improvisadas que nadie diseñó, de informes que hay que montar a mano cada mes porque los datos no cuadran, o de una segunda herramienta que se compra para tapar lo que la primera no resuelve.
Diagnosticar primero ahorra varios errores que comparten origen. El más frecuente es resolver el problema equivocado: muchas empresas creen tener un problema de herramientas cuando lo que tienen es un problema de proceso, o creen tener un problema de proceso cuando lo que falta es una decisión que dirección aún no ha tomado. También evita dimensionar mal, porque sin un mapa de la organización las soluciones se eligen por reputación o por precio, y lo que no encaja siempre acaba costando más que lo que costó. Y evita, en último término, acumular complejidad: cada decisión tomada sin comprender el conjunto añade una pieza que después habrá que mantener, integrar o desmontar.
Comprender antes no garantiza el acierto, pero convierte cada decisión posterior en una decisión informada, y esa diferencia se nota durante años.
Muchas empresas creen tener un problema de herramientas cuando lo que tienen es un problema de proceso, o creen tener un problema de proceso cuando lo que falta es una decisión que dirección aún no ha tomado.
Comprender es un trabajo, no una intuición
Hay una objeción frecuente y muy razonable: «nosotros ya conocemos nuestra empresa». Y es verdad solo a medias. Cada persona del equipo directivo conoce muy bien su parcela; lo que casi ninguna organización tiene es la imagen completa puesta en orden, ese mapa donde negocio, procesos y tecnología aparecen juntos y se ve con claridad dónde se sostienen mutuamente y dónde se contradicen.
Ese mapa no sale de una reunión ni de la intuición acumulada con los años. Sale de un trabajo deliberado de análisis que cruza tres versiones de la misma empresa: lo que dirección cree que ocurre, lo que los procesos muestran que ocurre y lo que los sistemas registran que ocurre. Nunca coinciden del todo, y justo en esas diferencias está la información más valiosa del diagnóstico.
Sobre esta base conceptual trabajan después las dos miradas que forman el modelo. La de orbetec, que aplica el diagnóstico del modelo de negocio, posicionamiento y objetivos empresariales, y estrategia de crecimiento. Y la de Anasinf, que lo lleva a la arquitectura tecnológica y a la integración de sistemas desde la visión de negocio. Dos lecturas del mismo mapa, cada una desde su territorio.
La pregunta que conviene llevarse
Comprender antes de transformar suena evidente cuando se formula así. Lo difícil es sostenerlo cuando hay prisa, cuando un proveedor aprieta con una oferta o cuando la competencia parece moverse más rápido. En esos momentos, dedicar unas semanas a entender la organización puede parecer una pérdida de tiempo, cuando en realidad es la única inversión que abarata todas las demás.
Quizá la pregunta que merece la pena llevarse de este artículo sea otra, algo más incómoda: de las decisiones tecnológicas que su organización ha tomado en los últimos años, ¿cuántas se tomaron comprendiendo el conjunto y cuántas porque había que decidir algo?
