El problema puede comenzar antes de comprar el sistema
Un ERP.
Una plataforma.
Una automatización.
Una solución de inteligencia artificial.
Cuando una empresa tiene problemas de información, procesos, control u operación, es natural comenzar a buscar tecnología.
Y ahí puede aparecer una pregunta que parece lógica:
¿Qué sistema necesitamos?
Pero quizás la pregunta anterior debería ser otra:
“¿Qué problema necesitamos resolver?”
Porque cuando la tecnología empieza a definir el problema, la conversación puede terminar girando alrededor de funcionalidades, proveedores y demos, antes de entender qué necesita realmente cambiar en el negocio.
Y eso puede ser costoso.
La tecnología puede ser correcta y la decisión, equivocada
No porque la tecnología sea mala.
Todo lo contrario.
Un ERP puede ser fundamental para integrar información.
Una automatización puede reducir trabajo manual y errores.
Una plataforma puede transformar una operación.
El problema aparece cuando se compra una buena tecnología para resolver un problema que no estaba suficientemente entendido.
Entonces pueden ocurrir cosas conocidas:
se mantienen planillas paralelas;
las personas terminan trabajando para el sistema;
se utilizan pocas de las funcionalidades adquiridas;
aparecen procesos manuales alrededor de la herramienta;
la organización pierde tiempo adaptándose;
y el problema original sigue ahí.
En ese momento aparece una pregunta incómoda:
¿Realmente faltaba tecnología?
O quizás faltaba entender mejor cómo debía funcionar el negocio.
Antes del ERP, hay una decisión más importante
En proyectos de implementación de ERP, los requerimientos funcionales cumplen un papel fundamental.
No son simplemente una lista de funcionalidades que se entrega a los proveedores.
Para construirlos bien, primero hay que entender cómo funciona —y cómo debería funcionar— la organización.
¿Cómo se realiza una compra?
¿Qué información se necesita?
¿Quién participa?
¿Qué controles existen?
¿Qué ocurre cuando algo sale de lo esperado?
¿Cómo se recibe?
¿Cómo se valida?
¿Cómo se factura?
¿Cómo se paga?
¿Qué información necesita cada área?
Estas preguntas obligan a mirar el negocio antes de mirar el software.
Y esto es importante porque el rediseño de procesos no necesariamente termina antes de seleccionar el ERP.
En proyectos complejos, parte del rediseño continúa durante la implementación: la configuración del sistema obliga a tomar decisiones, aparecen nuevas alternativas y los usuarios descubren necesidades que no siempre eran evidentes al inicio.
Pero hay una diferencia fundamental:
“Una cosa es seguir rediseñando durante la implementación. Otra es comenzar a implementar sin haber entendido suficientemente qué se necesita.”
Ahí los requerimientos funcionales se convierten en un puente entre el negocio y la tecnología.
Tres experiencias muestran por qué esto importa
En un proyecto de reemplazo de ERP para un hospital de Viña del Mar, el trabajo partió mucho antes de hablar de una solución tecnológica.
Fue necesario levantar procesos, entender cómo funcionaba la organización y traducir esas necesidades en requerimientos funcionales y user stories.
El trabajo involucró más de 60 subprocesos y alrededor de 600 requerimientos funcionales, además de procesos críticos asociados a ventas y facturación.
La tecnología era parte de la solución.
Pero primero había que entender qué debía resolver.
En otro contexto, al analizar los sistemas de una operación minera en Perú, se construyó un mapa de sistemas y procesos.
El objetivo no era simplemente saber qué aplicaciones existían.
Al relacionar sistemas y procesos apareció algo más relevante: la fragmentación.
Procesos que atravesaban distintas aplicaciones, información distribuida y dependencias que no necesariamente eran evidentes cuando cada sistema se observaba por separado.
El mapa de sistemas terminó siendo también una forma de mirar el negocio.
La pregunta dejó de ser solamente:
“¿Qué sistema tenemos?”
para pasar a ser:
“¿Cómo está soportando realmente la tecnología la forma en que funciona la organización?”
Y en una organización de salud con múltiples áreas y procesos, el análisis de procesos y sistemas permitió abordar no solamente la operación, sino también aspectos como seguridad informática y planes de mejora de sistemas..
Porque tecnología, procesos, información y gestión no funcionan como mundos separados.
Un problema que aparece en un sistema puede tener su origen en un proceso.
Un problema de información puede comenzar en la forma en que se registra.
Y una dificultad operacional puede terminar pareciendo un problema tecnológico.
El lugar donde aparece el problema no necesariamente es donde se origina.
Entonces, ¿qué debería estar claro antes de comprar?
No es necesario tener todo resuelto.
Pero sí debería existir claridad sobre cinco cosas:
¿Qué problema queremos resolver?
“Necesitamos un ERP” no es el problema.
Es una posible solución.
¿Por qué importa para el negocio?
¿Afecta costos, ingresos, control, productividad, servicio, riesgo o capacidad de crecimiento?
¿Qué debería cambiar?
Aquí aparecen los procesos, las responsabilidades, los controles y la información.
¿Qué debería hacer la tecnología?
Ahora sí tiene sentido comparar alternativas, proveedores y funcionalidades.
¿Cómo sabremos que funcionó?
Porque una implementación exitosa no es simplemente un sistema funcionando.
Es una tecnología que ayuda a producir el cambio que justificó la inversión.
La pregunta que debería acompañar la inversión
Antes de comparar ERP, plataformas, automatizaciones o soluciones de IA, quizás conviene hacerse una pregunta más ejecutiva:
“¿Cómo esta decisión ayudará a alcanzar nuestros objetivos de negocio o a resolver una causa raíz bien identificada?”
Si la respuesta es clara, la tecnología puede convertirse en un poderoso habilitador.
Si todavía no lo es, quizás todavía falta una parte importante del trabajo.
No necesariamente otro estudio de meses.
A veces basta con entrar por el problema concreto: un proceso que no funciona, información que llega tarde, sistemas que no conversan, controles que no funcionan o una operación que consume demasiado esfuerzo.
Entender antes de decidir.
Ese puede ser el verdadero comienzo de una transformación tecnológica.
Tecnología después de entender. No necesariamente antes.
No se trata de retrasar la transformación.
Tampoco de asumir que la tecnología es el problema.
Se trata de algo más simple:
que la tecnología responda a una necesidad real del negocio.
Porque comprar un sistema puede ser relativamente sencillo.
Lo difícil es conseguir que la organización trabaje mejor gracias a él.
Y por eso, antes de preguntar:
“¿Qué tecnología deberíamos comprar?”
quizás convenga preguntar:
“¿Qué debería cambiar en nuestro negocio para que esa tecnología realmente haga una diferencia?”
En SolverBiz
No partimos por la solución.
Partimos por entender el problema.
Si estás evaluando un ERP, una automatización, una plataforma o una transformación tecnológica y todavía no está completamente claro qué debería cambiar, conversemos.
