Todos tienen razón. No están hablando de lo mismo.

En una reunión de seguimiento, alguien pregunta cuántos proyectos tiene abiertos la empresa.

Ventas responde doce.

Operaciones dice quince.

Finanzas tiene nueve centros de costos activos.

Legal encuentra once contratos vigentes.

Nadie está improvisando. Nadie está usando información falsa. Cada respuesta puede justificarse con los registros de su propia área.

El problema aparece cuando alguien hace una segunda pregunta:

¿Cuál de esos números es el correcto?

Entonces empieza una conversación extraña. Un proyecto vendido pero todavía no iniciado cuenta para Ventas, pero no para Operaciones. Dos frentes de entrega bajo un mismo contrato son dos proyectos para el equipo que los ejecuta, pero continúan siendo uno para Finanzas. Una ampliación de alcance puede recibir presupuesto propio sin generar un nuevo contrato. Una iniciativa cerrada comercialmente puede seguir abierta porque quedan obligaciones pendientes.

Después de veinte minutos, la reunión ya no está discutiendo cuántos proyectos existen.

Está descubriendo que nunca había definido con suficiente precisión qué significaba un proyecto.

Esta clase de desacuerdo suele confundirse con un problema de datos.

No siempre lo es.

Una organización puede producir cada vez más información y seguir careciendo de algo fundamental: un referente común.

Tener una palabra no significa tener un referente

Las organizaciones reutilizan nombres porque hacerlo simplifica la coordinación.

Cliente. Proyecto. Pedido. Caso. Incidente. Contrato. Cuenta. Solicitud.

La palabra permite que muchas personas hablen con rapidez sobre algo que aparentemente todos reconocen.

Pero compartir una palabra no significa estar refiriéndose a la misma cosa.

Para Ventas, un cliente puede existir desde que aparece una oportunidad suficientemente seria.

Para Finanzas, quizá solo cuando existe una relación facturable.

Para Legal, la entidad relevante puede ser la contraparte contractual.

Para Operaciones, puede importar la organización específica para la que debe producirse un resultado.

Imponer una representación idéntica a todas esas funciones podría destruir información útil. Cada una observa dimensiones distintas porque necesita hacer cosas distintas.

La legibilidad no exige que todos describan el mundo de la misma manera.

Exige que, cuando dos áreas afirman estar hablando de la misma cosa, la organización pueda determinar si realmente lo están haciendo.

La representación puede variar.

El referente no puede variar silenciosamente.

Ese silencio es donde empieza buena parte de la confusión.

Debajo puede existir algo más elemental:

no sabemos qué estamos contando.

Proyecto Atlas

Supongamos que una empresa firma un contrato para ejecutar Proyecto Atlas.

Al comienzo, la identidad parece evidente. Existe una promesa comercial, un contrato, un presupuesto y un equipo de entrega. Todo cabe razonablemente bajo un mismo nombre.

Meses después, la ejecución se divide en dos frentes.

Uno depende de infraestructura. El otro, de desarrollo de software. Cada frente tiene responsables diferentes y empieza a planearse de manera independiente.

Finanzas conserva un único centro de costos.

Legal conserva el contrato original.

El cliente sigue hablando simplemente de Atlas.

Después, uno de los frentes cambia de alcance. Se renegocia su presupuesto, recibe un equipo estable y comienza a extenderse varios meses más allá del otro.

Dentro de Delivery empieza a tratarse como un proyecto separado.

En Finanzas sigue siendo Atlas.

En Legal continúa siendo una obligación dentro del mismo contrato, modificada mediante una adenda.

¿Qué ocurrió?

No necesariamente un error.

Puede que cada representación siga siendo útil para la función que la utiliza.

Pero ahora existe una pregunta que la organización necesita poder responder:

¿seguimos teniendo un proyecto con dos componentes o ya existen dos proyectos relacionados?

La dificultad no está en determinar cuál fase atraviesa Atlas.

Está en determinar si Atlas sigue nombrando una sola entidad.

“Atlas necesita presupuesto.”

“Atlas va atrasado.”

“Atlas ya se entregó.”

“Atlas todavía tiene obligaciones abiertas.”

La etiqueta sobrevivió.

Lo que pudo haber cambiado fue la geometría de aquello que nombraba.

La organización siguió hablando de una cosa después de que quizá ya existían varias.

La identidad también tiene límites

¿Qué hace que dos actividades pertenezcan al mismo proyecto?

¿Qué diferencia dos clientes de dos unidades de negocio dentro del mismo cliente?

¿Cuándo una nueva solicitud sigue siendo parte del caso original y cuándo constituye otro caso?

Estas preguntas no describen progresión.

Intentan establecer qué cuenta como una unidad.

Un cambio de responsable no crea necesariamente un nuevo proyecto.

Tampoco un ajuste de presupuesto, una nueva fecha o una modificación de alcance.

Pero hay cambios que pueden alterar algo más profundo que sus atributos.

En algún punto, aquello que la organización seguía tratando como una sola cosa puede haber dejado de serlo.

Una etiqueta puede sobrevivir a esa fractura.

También puede ocurrir lo contrario: una misma cosa puede dispersarse en varios nombres.

Una adquisición puede dejar la misma cuenta duplicada en sistemas distintos. Un cliente puede aparecer bajo su razón social en Finanzas, una marca comercial en Ventas y una unidad operativa en Delivery.

Por eso usar los mismos nombres no resuelve el problema.

Dos nombres pueden apuntar a una cosa.

Un nombre puede esconder varias.

Lo importante es que la organización pueda reconocer cuál de las dos situaciones tiene delante.

Cuando un ticket no es un incidente

El problema se ve todavía más claro en soporte y tecnología.

Un cliente informa que no puede completar una operación crítica.

Se crea un ticket.

Soporte investiga.

El equipo técnico identifica un defecto.

Al mismo tiempo, una caída parcial del servicio se registra como incidente.

Estas cosas pueden estar relacionadas:

la experiencia del cliente,

el ticket de soporte,

el incidente de servicio,

el defecto técnico.

Pero relación no significa identidad.

Cerrar el ticket puede significar que Soporte respondió al cliente.

Resolver el incidente puede significar que el servicio volvió a estar disponible.

Corregir el defecto puede requerir una modificación posterior del producto.

Y recuperar completamente el resultado que el cliente necesitaba puede exigir todavía otra acción.

Si la organización utiliza la palabra incidente para todas esas cosas, puede producir una apariencia de coherencia que no existe.

Un informe dirá que el incidente fue cerrado.

Otro equipo seguirá trabajando en el defecto.

El cliente seguirá esperando una solución a su problema original.

Las personas pueden discutir con absoluta convicción y todas tener evidencia de lo que dicen.

Una señala el ticket cerrado.

Otra muestra el servicio restablecido.

Otra explica que el bug continúa abierto.

El desacuerdo parece ser sobre el estado de “el incidente”.

En realidad, nadie notó que cada uno estaba defendiendo una cosa diferente.

A veces una reunión no se prolonga porque falte información.

Se prolonga porque el lenguaje hizo parecer común un referente que nunca lo fue.

El registro maestro no agota el problema

Parte de esta dificultad pertenece legítimamente al territorio de la gestión de datos.

Prácticas de Master Data Management, modelado semántico, identificadores canónicos, gobierno de datos y resolución de entidades pueden ayudar a establecer relaciones entre representaciones y reducir duplicidades.

Pero una organización puede tener un registro maestro técnicamente impecable y seguir utilizando de manera inconsistente aquello que ese registro representa.

Una función puede tratar una relación comercial como cliente, otra como cuenta facturable y otra como contraparte contractual. La infraestructura puede representar esas diferencias.

No puede, por sí sola, determinar cuáles necesita conservar la organización para operar y cuándo deben entenderse como una misma cosa.

Eso aparece en cómo se asigna trabajo, qué se cuenta y qué se considera una unidad.

También en qué se asume que permanece igual a través del tiempo.

La resolución, en este sentido, no es únicamente poder unir dos registros.

Es poder responder una pregunta organizacional sencilla:

cuando Finanzas dice una cosa y Operaciones dice otra, ¿están hablando de la misma entidad?

Y si no lo están, ¿qué relación existe entre ambas?

Integrar sistemas sin responder esa pregunta puede conectar representaciones sin resolver la ambigüedad que las produjo.

La automatización pierde una capacidad humana silenciosa

Las personas son sorprendentemente buenas reconstruyendo referentes ambiguos.

Entienden que “Atlas” significa una cosa cuando habla Legal y otra ligeramente distinta cuando habla Delivery.

Reconocen que un ticket cerrado no implica necesariamente que desapareció el problema que lo originó.

Recuerdan que dos nombres en dos sistemas corresponden al mismo cliente.

Interpretan frases incompletas mediante historia y contexto.

Esa capacidad permite que una organización opere durante mucho tiempo sin resolver explícitamente muchas de estas relaciones.

La automatización reduce esa tolerancia.

No porque una máquina sea incapaz de trabajar con múltiples representaciones.

Puede hacerlo.

El problema es que necesita alguna forma de saber qué representa cada una y cómo se relacionan.

Un sistema puede ejecutar perfectamente una instrucción sobre todos los “proyectos activos” y producir un resultado equivocado si Finanzas y Delivery utilizan proyecto para unidades diferentes.

Puede cerrar automáticamente “incidentes resueltos” cuando el criterio de resolución pertenece al ticket y no al incidente de servicio.

Puede combinar información de clientes y duplicar exposición, obligaciones o actividad porque dos representaciones fueron interpretadas como entidades independientes.

En todos esos casos, la automatización puede estar funcionando exactamente como fue diseñada.

Lo que falla ocurrió antes.

La organización nunca estabilizó suficientemente el referente sobre el cual esperaba que el sistema actuara.

Por eso la legibilidad no comienza necesariamente con más datos.

Tampoco siempre con un dashboard mejor.

Existe una pregunta anterior.

Antes de saber algo

Una organización puede conocer con enorme detalle sus proyectos, tickets y clientes y seguir sin distinguir consistentemente qué unidad representa cada registro.

Nada de esto exige una definición universal e inmutable de cada cosa.

Un referente suficientemente estable no es uno que nunca cambia.

Es uno cuya identidad no cambia sin que la organización pueda reconocer que cambió.

La legibilidad no exige congelar la realidad para poder describirla.

Exige conservar suficiente continuidad para que distintas personas y sistemas sepan cuándo siguen hablando de la misma cosa.

Porque antes de medir algo, hay que saber qué se está contando.

Antes de describirlo, hay que saber a qué se refiere la descripción.

Y antes de preguntar qué sabe un sistema sobre algo, la organización necesita poder responder una pregunta mucho más simple:

¿qué es exactamente ese algo?