Hay problemas que son fáciles de detectar.
Las ventas están cayendo.
Los costos aumentaron.
Los equipos están sobrecargados.
Los clientes reclaman.
Los pagos se atrasan.
La información llega tarde.
Un proyecto no avanza como debería.
Un proceso depende demasiado de una persona.
El problema es que detectar el síntoma no significa entender la causa.
Y cuando la causa no está clara, aparece una situación bastante habitual en las empresas: comienzan a aparecer explicaciones.
“Necesitamos más personas.”
“El problema es el sistema.”
“Hay que controlar más.”
“Ventas está fallando.”
“Operaciones no está funcionando.”
“Tenemos que automatizar.”
“Necesitamos cambiar el ERP.”
Cada explicación puede parecer razonable.
Pero una explicación no necesariamente es un diagnóstico.
Y cuando se toma una decisión importante sobre una causa que no ha sido suficientemente entendida, existe el riesgo de invertir tiempo, dinero y esfuerzo para terminar resolviendo algo distinto del problema real.
El problema que todos ven, pero nadie logra explicar
Uno de los escenarios más complejos para una empresa no es necesariamente cuando existe un problema desconocido.
Es cuando todos saben que algo está mal, pero cada persona tiene una explicación diferente sobre por qué ocurre.
La gerencia ve una caída en los resultados.
Operaciones ve problemas de productividad.
Finanzas ve mayores costos.
Tecnología ve sistemas antiguos.
Las personas sienten sobrecarga.
Y los clientes perciben demoras o errores.
Todos están viendo una parte del problema.
Pero eso no significa que alguien esté viendo el problema completo.
Aquí aparece una pregunta que muchas veces se posterga:
¿Estamos tratando el problema o solamente sus síntomas?
Síntoma → Hipótesis → Evidencia → Causa → Decisión
Un problema puede aparecer en un lugar y comenzar en otro
Imaginemos una empresa donde los pagos a proveedores están demorando demasiado.
El síntoma es evidente: proveedores reclamando, facturas pendientes y equipos financieros dedicando mucho tiempo a revisar casos.
La primera reacción podría ser contratar más personas para procesar documentos.
Pero al revisar el proceso completo pueden aparecer otras situaciones:
La información de la compra llega incompleta.
La recepción no queda registrada oportunamente.
La factura debe ser revisada nuevamente.
La aprobación depende de una persona específica.
Existen diferencias entre la información operacional y la contable.
Algunas excepciones se gestionan por correo.
Y determinados casos requieren intervención manual varias veces.
En ese escenario, incorporar personas podría aliviar temporalmente el síntoma, pero no necesariamente resolver la causa.
El problema podría estar en el diseño del proceso, en las responsabilidades, en los controles, en la información o en la interacción entre personas y sistemas.
Este tipo de situaciones aparece en prácticamente cualquier industria.
En salud: cuando el problema parece estar en el sistema
En una experiencia de análisis de procesos para el reemplazo de un ERP en una institución de salud, el desafío no consistía simplemente en identificar qué funcionalidades debía tener el nuevo sistema.
Había que entender primero cómo funcionaba realmente la organización.
Eso implicaba revisar procesos clínicos y administrativos, responsabilidades, información, sistemas y necesidades de los usuarios.
En este tipo de organizaciones, un problema que aparece como “el sistema no funciona bien” puede tener múltiples orígenes.
Puede existir una funcionalidad que efectivamente falta.
Pero también puede haber un proceso mal definido, una responsabilidad poco clara, información que se genera demasiado tarde o una actividad que se realiza de determinada manera simplemente porque siempre se ha hecho así.
Por eso, antes de traducir un problema a una especificación tecnológica, es necesario entender el proceso.
En ese trabajo se analizaron más de 60 subprocesos y alrededor de 600 requerimientos funcionales y user stories.
La tecnología era importante.
Pero el punto de partida no era la tecnología.
Era entender qué necesitaba realmente la organización para funcionar mejor.
En minería: el síntoma puede estar al final del proceso
Algo similar puede ocurrir en procesos de cierre operacional y contable.
Cuando la información para la gestión llega tarde, la reacción natural puede ser pensar que existe un problema en Finanzas, Contabilidad o en los sistemas de información.
Pero el origen puede estar mucho antes.
En una experiencia relacionada con procesos de cierre en una operación minera, el análisis involucró procesos asociados al cierre operacional y contable, buscando adelantar y mejorar la oportunidad con que la información estaba disponible para la gestión.
La pregunta no era solamente:
“¿Cómo hacemos el cierre más rápido?”
También había que entender
qué información se generaba,
cuándo se generaba,
quién la necesitaba,
qué actividades dependían de otras,
dónde existían esperas,
qué información debía consolidarse
y qué podía mejorarse mediante procesos, herramientas o gestión.
Cuando se mira el proceso completo, una demora que parece “contable” puede comenzar mucho antes.
Ese es precisamente el valor de mirar la cadena y no solamente el punto donde aparece el problema.
En una fábrica: cuando todos trabajan, pero la operación no fluye
También puede ocurrir en una planta.
Las personas están ocupadas.
Las máquinas están funcionando.
Hay producción.
Pero los resultados no son los esperados.
Aparecen horas adicionales, urgencias, movimientos innecesarios, diferencias de inventario, problemas de coordinación o personas que deben intervenir permanentemente para destrabar situaciones.
Entonces surge otra pregunta frecuente:
“¿Necesitamos más gente?”
Antes de responderla, conviene mirar cómo está diseñado el trabajo.
¿Dónde comienza el proceso?
¿Dónde termina?
¿Quién entrega la información?
¿Quién decide?
¿Dónde espera el trabajo?
¿Cuántas veces se repite una actividad?
¿Cuántas veces se corrige?
¿Qué depende de una persona específica?
¿Qué información está disponible cuando se necesita?
Y, especialmente:
¿Qué parte del esfuerzo que hoy realiza el equipo existe solamente para compensar una deficiencia del proceso?
A veces una organización no necesita más personas.
Necesita eliminar trabajo innecesario.
Otras veces sí necesita recursos adicionales.
Pero esa debería ser una conclusión del análisis, no el punto de partida.
En servicios: cuando el cliente ve una demora, pero la causa está detrás
En una empresa de servicios puede ocurrir algo parecido.
Un cliente reclama porque una respuesta demora demasiado.
El área comercial piensa que operaciones es lenta.
Operaciones sostiene que necesita más información.
Tecnología dice que el sistema está disponible.
Administración señala que faltan aprobaciones.
Y el cliente simplemente espera.
Desde fuera parece un problema de servicio.
Pero al seguir el flujo completo puede aparecer otra realidad: la información entra por distintos canales, algunos datos deben volver a solicitarse, existen aprobaciones que no agregan valor, la información se transfiere manualmente, hay actividades que dependen de una persona específica y el sistema registra solamente una parte del proceso.
Entonces el problema que el cliente percibe como “demora” puede ser consecuencia de una cadena de pequeñas ineficiencias.
Ninguna necesariamente explica el problema por sí sola.
Pero juntas sí pueden explicar el resultado.
La causa no siempre está donde aparece el síntoma
Esta es una de las ideas más importantes cuando se analiza un problema de negocio.
El lugar donde aparece el problema no necesariamente es el lugar donde se origina.
Una caída de rentabilidad puede comenzar en los precios, pero también en costos, productividad, procesos, mix de clientes o condiciones comerciales.
Un atraso puede parecer un problema de personas, pero tener su origen en aprobaciones, información o sistemas.
Una necesidad de tecnología puede esconder un problema de procesos.
Un problema de productividad puede ser consecuencia de retrabajo.
Y una sobrecarga del equipo puede estar relacionada con un diseño de trabajo que obliga a las personas a compensar permanentemente las deficiencias del sistema.
Por eso, antes de decidir qué hacer, conviene separar tres cosas:
1. Lo que observamos, el síntoma;
Lo que creemos que está ocurriendo, las hipótesis; y
Lo que podemos demostrar, la evidencia.
El diagnóstico comienza precisamente cuando dejamos de confundir estas tres cosas.
¿Cómo empezar cuando no está claro dónde está el problema?
No siempre se necesita un proyecto enorme.
Muchas veces conviene comenzar por el dolor concreto: un proceso que genera demasiadas demoras, una actividad con mucho retrabajo, una aprobación que bloquea la operación, un flujo de información que nadie logra explicar completamente, un indicador que empeora o una parte de la operación que depende demasiado de una persona.
Desde ahí se puede reconstruir el proceso y observarlo desde distintas dimensiones:
Personas.
¿Quién hace qué? ¿Qué decisiones toma? ¿Dónde se producen dependencias?
Procesos.
¿Qué actividades existen? ¿En qué secuencia? ¿Dónde hay esperas, duplicidades o retrabajo?
Sistemas.
¿Qué información se registra? ¿Qué se automatiza? ¿Qué se hace manualmente?
Gestión.
¿Qué indicadores existen? ¿Cómo se controla? ¿Qué decisiones se toman y con qué información?
Resultados.
¿Qué está ocurriendo realmente con tiempos, costos, productividad, calidad o servicio?
La combinación de estas perspectivas permite pasar de una conversación basada en opiniones a una conversación basada en evidencia.
Antes de automatizar, hay que entender
Existe una presión creciente por digitalizar, automatizar e incorporar inteligencia artificial.
Y la tecnología puede generar enormes beneficios.
Pero hay una pregunta que conviene hacer antes:
¿Estamos automatizando un buen proceso o estamos haciendo que un mal proceso ocurra más rápido?
Si un proceso tiene actividades innecesarias, responsabilidades confusas, información duplicada o controles que no agregan valor, automatizarlo sin revisarlo puede simplemente digitalizar la ineficiencia..
Primero hay que entender.
Después rediseñar cuando corresponda.
Y recién entonces decidir qué tecnología tiene sentido.
La misma lógica aplica a incorporar personas, cambiar sistemas, modificar estructuras o lanzar grandes proyectos de transformación.
Antes de mejorar, hay que medir
También es difícil mejorar algo que no sabemos medir.
No todos los procesos necesitan decenas de indicadores.
Pero normalmente necesitamos alguna forma de observar qué está ocurriendo.
Por ejemplo:
tiempo de ciclo;
cumplimiento de plazos;
errores;
retrabajo;
volumen;
productividad;
costo;
nivel de servicio;
tiempos de espera.
Medir no significa burocratizar.
Significa tener una referencia para saber si una decisión realmente produjo una mejora.
Porque si no podemos observar el problema antes y después, es difícil saber si realmente lo resolvimos.
Diagnosticar no es buscar culpables
Cuando un problema lleva tiempo, es fácil que la organización termine buscando responsables.
“Operaciones no cumple.”
“Finanzas demora.”
“TI no responde.”
“Ventas promete demasiado.”
“Las personas no están capacitadas.”
A veces puede existir efectivamente un problema de desempeño individual o de capacidad.
Pero comenzar buscando culpables puede impedir que veamos algo más importante:
¿Qué sistema de trabajo está haciendo que las personas actúen de esa manera?
Un buen diagnóstico no busca simplemente señalar quién falló.
Busca entender por qué el resultado se está produciendo de esa forma.
Y eso permite tomar decisiones más precisas.
No siempre necesitamos la solución todavía
Cuando una empresa llega con un problema importante, muchas veces ya existe una solución en mente.
“Necesitamos un ERP.”
“Necesitamos automatizar.”
“Necesitamos contratar.”
“Necesitamos cambiar el proceso.”
“Necesitamos una nueva estructura.”
Puede ser.
Pero también puede no serlo.
La primera conversación debería permitirnos responder preguntas más básicas:
¿Qué está pasando?
¿Dónde ocurre?
¿Desde cuándo?
¿Qué impacto tiene?
¿Qué variables están involucradas?
¿Qué evidencia tenemos?
¿Qué hipótesis existen?
¿Cuál parece ser la causa?
Y solamente después:
¿Qué conviene hacer?
El diagnóstico no es el final
En SolverBiz entendemos el diagnóstico como el comienzo de una decisión mejor informada.
Nuestro trabajo puede terminar en una recomendación.
Pero también puede continuar en el rediseño de procesos, la implementación de un sistema de control, la evaluación de una solución tecnológica, el acompañamiento de un proyecto o la transformación de una parte del negocio.
Porque encontrar la causa no siempre es el final.
A veces es recién el comienzo.
La diferencia está en no confundir velocidad con avance.
Una empresa puede implementar muy rápido una solución equivocada.
También puede tardar un poco más en entender el problema y después avanzar con mucha mayor claridad.
Por eso, frente a un problema importante de negocio, hay una pregunta que vale la pena hacerse antes de preguntar “¿qué hacemos?”:
¿Sabemos realmente qué está pasando?
En SolverBiz ayudamos a empresas y organizaciones a entender qué está ocurriendo, encontrar dónde está la causa y convertir ese diagnóstico en decisiones y cambios concretos.
No partimos por la solución. Partimos por entender el problema.
