La mayoría de las empresas tienen al menos un sistema del que todo el mundo se queja. Es viejo, parece anticuado y solo una o dos personas lo entienden realmente. La reacción natural es querer eliminarlo. A veces es la decisión correcta. A menudo no lo es, o al menos no todavía.
La pregunta que intento responder no es '¿es viejo este sistema?', sino '¿sigue este sistema cumpliendo su función a un costo que la empresa pueda asumir?'.
Empezar por lo que realmente está fallando
Me gusta empezar con los problemas que la gente puede describir con sus propias palabras. Un cambio sencillo tarda semanas. Los informes no coinciden con lo que hay en el estante. Todo se detiene cuando una persona en particular está de vacaciones, porque es la única que sabe cómo funciona el cierre de mes. El sistema se cayó dos veces el trimestre pasado y los pedidos se acumularon.
Esos datos son útiles porque vinculan el software con tiempo y dinero reales. 'Es viejo' no está en esa lista. Un sistema de diez años que rara vez necesita cambios puede ser más barato de mantener que de reemplazar. Y un sistema construido hace dos años ya puede ser un problema si el negocio ha cambiado a su alrededor.
Sumar lo que realmente cuesta mantenerlo
El costo de un sistema antiguo es mucho más que la factura del alojamiento. Incluye:
- las horas que la gente dedica a soluciones improvisadas y a escribir lo mismo dos veces
- proyectos que se retrasan porque el sistema es difícil de cambiar
- el tiempo de inactividad y el caos que conlleva
- el riesgo de seguridad si el sistema ya no puede actualizarse
- lo difícil que es encontrar a alguien que pueda encargarse de su mantenimiento
Estos costos suelen estar repartidos entre varios departamentos, por lo que nadie ve el total completo. Una revisión breve soluciona eso. Enumere las tareas más importantes que realiza el sistema, quién depende de él, qué sigue fallando y qué espera necesitar la empresa en los próximos dos o tres años. Las cifras aproximadas están bien. Solo sea honesto sobre cuáles son suposiciones.
Tiene más de dos opciones
Rara vez se trata de elegir directamente entre no hacer nada y reconstruirlo todo. En medio, podría:
- corregir la parte que causa la mayor parte del problema
- reemplazar una sola pieza, como los informes o el enlace con su software de contabilidad
- colocar una capa limpia y moderna alrededor de la parte difícil de cambiar para que las herramientas más nuevas puedan trabajar con ella
Sin embargo, los pasos pequeños no siempre son la respuesta. Si no se puede confiar en los datos del sistema, o si el sistema simplemente no puede hacer lo que el negocio necesitará a continuación, parchearlo puede simplemente prolongar el problema. El punto es elegir deliberadamente en lugar de por hábito.
Las reglas no escritas son la parte difícil
Cuando se reemplaza un sistema, reconstruir las pantallas es la parte fácil. Lo difícil son todas esas pequeñas reglas que nadie escribió: el cliente que recibe un precio especial, el pedido al que se le permite saltarse un paso, la exportación de la que alguien en contabilidad depende cada viernes. Esos detalles suelen ser el verdadero corazón del sistema.
Antes de pasar a algo nuevo, quiero saber dónde residen los datos confiables, cómo se manejarán los duplicados y los registros antiguos, y cómo demostraremos que el nuevo sistema da las mismas respuestas correctas. También vale la pena planificar cómo volver atrás si algo sale mal, y si conviene ejecutar los sistemas antiguo y nuevo en paralelo durante un tiempo. Un buen plan explica cómo sabrá que los datos son correctos, no solo cómo se copian.
Cinco preguntas antes de decidir
Antes de recomendar nada, quiero respuestas a cinco preguntas:
- ¿Qué problema específico estamos resolviendo?
- ¿Cuánto cuesta y cuál es el riesgo si dejamos las cosas como están?
- ¿Qué límites son realmente inamovibles, como el presupuesto, los plazos o las normativas?
- ¿Cómo comprobaremos que el nuevo enfoque funciona correctamente?
- ¿Cuál es el paso útil más pequeño que reduce el riesgo sin limitarnos para el futuro?
Si esas respuestas son difusas, el siguiente paso correcto suele ser una revisión breve con una fecha de finalización fija, en lugar de un gran proyecto. Debería salir de ella con un mapa claro de sus sistemas, los principales riesgos ordenados, opciones realistas y un orden sensato para abordarlos.
En conclusión
Actualizar el software antiguo no se trata de perseguir nuevas tecnologías. Se trata de asegurarse de que el sistema pueda seguir apoyando al negocio. A veces eso significa una reconstrucción. Más a menudo significa unas pocas correcciones específicas, mejor visibilidad y un camino más seguro a seguir.