Termina el trimestre y cada director presenta sus resultados; casi todos cumplieron. Operaciones entregó a tiempo, ventas llegó a su número, compras bajó el costo unitario, recursos humanos cubrió las vacantes, pero… el resultado del negocio no llegó.

Nadie hizo mal su trabajo. Lo que ocurre es que todos midieron su tramo y nadie midió el recorrido completo. El cliente experimentó otra cosa: un pedido que se atoró cuatro días entre ventas y producción, una devolución que ninguna de las dos áreas se sintió obligada a resolver, una queja que rebotó tres veces antes de llegar a quien podía decidir.

Cuando esto pasa, la reacción habitual es mirar el organigrama. Y ahí no está la respuesta.

El organigrama responde otra pregunta

Un organigrama dice a quién le reporta cada uno. Es una pregunta legítima y hace falta contestarla: define la línea de autoridad, la evaluación del desempeño, a quién se le pide permiso para tomar vacaciones.

Lo que no dice es quién responde por un resultado que atraviesa varias áreas.

Y esa es la pregunta que importa, porque el valor no se entrega de arriba hacia abajo. Se entrega de izquierda a derecha: alguien recibe una solicitud, alguien la convierte en algo, alguien la entrega, alguien cobra. El organigrama divide la organización en vertical; el trabajo ocurre en horizontal. Y entre una caja y la siguiente hay una frontera que el dibujo no muestra.

En esas fronteras es donde se cae el trabajo. No dentro de las áreas.

Por qué reorganizar no lo arregla

La respuesta intuitiva, cuando la coordinación falla, es cambiar la estructura. Juntar dos áreas que no se hablan. Crear una gerencia que coordine. Mover un departamento de una dirección a otra.

A veces mejora, y casi siempre de forma temporal. Seis meses después el mismo problema reaparece en una frontera nueva, porque mover cajas no elimina las fronteras: las cambia de lugar.

Cada reorganización deja además un costo que no se contabiliza. Se pierden meses de productividad mientras la gente averigua a quién preguntarle, se rompen relaciones de trabajo que funcionaban, y se instala en la organización la idea de que la estructura es inestable. Después de dos o tres rondas, cuando se anuncia una cuarta, nadie se mueve hasta ver quién queda.

El problema no es dónde está cada caja. Es que nadie respondió quién es dueño del resultado completo.

He visto el patrón más de una vez con el mismo desenlace. En una empresa se reorganizaron Compras, Almacén y Finanzas para hacer más eficiente el abastecimiento. La estructura quedó clara y cada área cumplía sus indicadores, mientras el inventario seguía creciendo. Nadie respondía por el resultado completo, y el resultado completo era justamente el inventario.

En otra se creó una dirección nueva para mejorar la experiencia del cliente. Se contrató gente y se movieron funciones, y las decisiones siguieron dependiendo de varias áreas.

La reorganización cambió quién hacía el trabajo, pero no quién respondía por el resultado.

El orden en que se suele diseñar

La mayoría de las empresas diseña su organización así: primero el organigrama, después las funciones de cada área, después los puestos y, si alcanza el tiempo, los procesos.

Fíjate en lo que significa ese orden. Se decide la estructura antes de entender cómo se entrega valor. El resultado es una organización que agrupa especialidades y reparte el trabajo por conveniencia histórica: así se acomodó cuando la empresa tenía veinte personas, y así se quedó con ciento veinte.

Los procesos, cuando llegan, tienen que acomodarse a una estructura que ya se fijó. Y como la estructura no se diseñó para ellos, aparecen los rodeos: aprobaciones que existen porque el área quedó en otra dirección, duplicidades porque dos gerencias resuelven lo mismo por su cuenta, huecos porque nadie quedó a cargo de un pedazo que no era de nadie.

El orden que sí funciona

Al revés.

Primero, cómo entregas valor. Cuáles son los flujos de trabajo de los que depende que el cliente reciba lo que compró. Basta con el nivel alto: tres, cuatro o cinco macroprocesos, con sus objetivos y sus fronteras.

Después, quién responde por cada resultado. Un nombre por proceso, no un área. Alguien que responda por el recorrido completo, incluso por los tramos que no le reportan.

Después, los roles y los puestos. Qué papeles hay que ejercer para que esos procesos funcionen, y cómo se agrupan en puestos.

Y al final, el organigrama. Que entonces ya no es una decisión, sino una consecuencia.

La regla que ordena el trabajo cabe en una línea: ningún puesto se crea sin una actividad de proceso que lo justifique, y ninguna actividad crítica queda sin alguien que responda por ella.

Es una regla incómoda, porque al aplicarla aparecen puestos que existen por historia y actividades críticas que no tienen dueño. Las dos cosas son información valiosa y ninguna sale de mirar el organigrama.

La buena noticia

Todo esto suena a reestructura, y al principio casi nunca lo es.

Una parte importante de los problemas de coordinación se resuelve acordando quién responde por qué, sin cambiar a nadie de lugar. La persona sigue reportando donde reportaba, con el mismo jefe y el mismo puesto, y además queda como dueña de un proceso que cruza áreas. Son dos cosas distintas y conviven.

Cambiar la estructura es el último recurso, no el primero. Y cuando se llega a él, se llega con un criterio: la estructura cambia porque el proceso lo exige, no porque alguien propuso una configuración que se ve mejor en la lámina.

Dos casos que ilustran hasta dónde llega esto.

En una empresa el proceso de atención a clientes cruzaba Ventas, Operaciones y Servicio, y cada área culpaba a la otra por los retrasos. La propuesta sobre la mesa era crear una gerencia nueva. En su lugar se nombró un dueño del proceso con autoridad transversal, y los tiempos mejoraron sin modificar la estructura.

En otra, la incorporación de empleados involucraba a Recursos Humanos, Tecnología, Seguridad y Administración. Cada área cumplía su parte, y aun así los nuevos llegaban sin equipo, sin accesos o sin la información completa. Se nombró un dueño del proceso de onboarding, que coordinó a las cuatro áreas y estableció un indicador común.

Ese indicador común es la mitad del asunto. Mientras cada área mide su tramo, nadie mide el recorrido, y cuatro áreas al cien por ciento producen un empleado nuevo sentado frente a un escritorio vacío.

Dos cosas que el organigrama esconde

El nivel que no está dibujado. En empresas familiares y en empresas donde el fundador sigue operando, hay un nivel jerárquico real que no aparece en el dibujo. Mientras toda decisión relevante pase por una persona, la estructura tiene un escalón más de los que están pintados, y todos en la empresa lo saben aunque nadie lo diga.

Esa conversación es la más difícil de cualquier proyecto de diseño organizacional, y es el mejor predictor de si va a funcionar. Un organigrama impecable sobre un fundador que no suelta decisiones es un dibujo.

Las personas que hacen de todo. En una empresa de cuarenta personas, una misma persona lleva compras, controla el inventario y atiende a dos clientes grandes. El error frecuente es diseñar como si no fuera así: copiar la estructura de una corporación y esperar que la gente se comporte como si hubiera quinientos empleados.

El diseño no consiste en impedir el multi-rol. Consiste en nombrar cada rol por separado, decir cuál tiene prioridad cuando los tres compiten por el mismo martes en la tarde, y saber cuál se suelta primero el día que haya presupuesto para contratar. Un puesto con tres roles nombrados es manejable; un puesto con tres roles invisibles es una persona quemada.

La pregunta antes de mover una caja

Cuando alguien me plantea que necesita reorganizar, pregunto lo mismo:

¿Cuáles son los tres o cuatro procesos de los que depende tu resultado, y quién responde hoy por cada uno de principio a fin?

Si la respuesta a la segunda parte es un área y no una persona, o si dos directores dan respuestas distintas, el problema no es la estructura.

El organigrama es el último paso del diseño organizacional, no el primero. Cuando se dibuja al inicio, se congela una forma de trabajar que nadie revisó. Cuando se dibuja al final, es el reflejo de una conversación que ya se tuvo.

Carlos Orrante trabaja en transformación de procesos de negocio y formación de consultores internos.

Dos frases de un mismo reglamento interno:

• "Todo el personal debe portar su gafete en la parte superior izquierda del pecho siempre que se encuentre dentro de las instalaciones."

• "Todo el personal deberá portar su gafete en un lugar visible siempre que se encuentre dentro de las instalaciones."

Dicen casi lo mismo. La primera es una regla; la segunda, una política.

La diferencia parece de redacción y es algo diferente: en la primera, alguien ya decidió dónde va el gafete. En la segunda, esa decisión se le dejó al colaborador, dentro de un criterio.

Ninguna de las dos está mal. Las dos son válidas y las dos se pueden establecer como política. Lo que hay que tener claro es que al elegir entre una y otra se está decidiendo cuánto criterio se delega, y esa decisión tiene consecuencias que aparecen mucho después.

La escalera completa

Antes del detalle conviene ordenar cuatro términos que se usan de forma intercambiable y no son lo mismo.

• Los objetivos señalan las metas por alcanzar.

  • Las políticas indican el camino para llegar a esas metas.

    • Los procesos y procedimientos muestran, paso a paso, cómo realizar las actividades que las políticas trazaron.

Es una escalera y el orden importa. Una política que no se puede rastrear hasta un objetivo del negocio es una preferencia de alguien. Un procedimiento que no responde a ninguna política es una costumbre que alguien escribió.

Y dentro de las políticas viven las dos formas que abrieron este artículo:

• Una regla es un mandato preciso. Determina la disposición, la actitud o el comportamiento que el colaborador debe seguir o evitar en una situación específica. No admite interpretación, y esa es su función.

• Un lineamiento orienta la toma de decisiones sobre las situaciones que se van presentando. Establece el criterio y deja el juicio a quien está ahí.

Quien redacta la política decide si será un conjunto de reglas, de lineamientos, o una combinación de ambos.

Para qué sirve una política, en realidad

Una política no existe para controlar a la gente. Existe para que la gente pueda decidir sin preguntar.

Su propósito es exponer los lineamientos directivos que le facilitan al colaborador tomar decisiones. Y de ahí se desprende lo demás: facilita la delegación de autoridad, le da a los líderes un marco para entender sus responsabilidades, reduce los tiempos de consulta entre jefe y colaborador, aumenta la cooperación entre departamentos y produce uniformidad en las respuestas que reciben clientes y colaboradores.

Ese punto —reducir la consulta al jefe - es el problema que veo en casi toda organización que creció rápido: todas las decisiones suben, y el director se convierte en el cuello de botella de su propia empresa.

Una política bien escrita es el mecanismo más barato que existe para desmontar eso. No requiere sistema, ni reorganización, ni presupuesto. Requiere que alguien se siente a decidir de antemano lo que hoy se decide caso por caso.

Cuando una organización no tiene políticas, no es que tenga libertad. Es que tiene un cuello de botella con nombre y apellido.

Cuándo regla y cuándo lineamiento

No hay una respuesta general, pero sí un criterio.

La regla conviene cuando la variación es un riesgo. Seguridad, cumplimiento legal, manejo de dinero, datos personales, cualquier cosa donde una interpretación creativa tiene consecuencias graves. También cuando la decisión es frecuente y no requiere contexto: si hay una respuesta correcta y se puede escribir, escríbela.

El lineamiento conviene cuando el contexto cambia y quien está ahí lo conoce mejor que quien redactó la política. Cuando intentar cubrir todos los casos produciría un documento de cincuenta páginas que nadie va a consultar. Y cuando lo que se busca es desarrollar criterio en la gente, no solo obediencia.

El error habitual es escribir reglas por comodidad. Redactar una regla es más rápido: no hay que pensar en los casos límite ni confiar en nadie. El costo llega después, cuando aparece la situación que la regla no previó y la organización descubre que nadie sabe decidir sin ella.

El error opuesto también existe: escribir lineamientos vagos para evitar la conversación difícil de definir el criterio. "Actuar con responsabilidad" no es un lineamiento; es una manera elegante de no decidir.

Dos formas de equivocarse

Caso 1: Cuando la regla no previó el caso.

Una política de vacaciones dice: "Los colaboradores deberán utilizar sus días de vacaciones dentro del año calendario correspondiente."

En la práctica se aplica como regla: "Los días no utilizados al 31 de diciembre se eliminan automáticamente." Y así queda configurada en el sistema.

Entonces llega el caso que nadie previó. Un colaborador estuvo incapacitado durante los últimos meses del año y por esa razón no pudo tomar sus vacaciones. El 31 de diciembre el sistema elimina sus días.

La regla hizo lo que se le pidió. Nadie decidió que a esa persona se le quitaran las vacaciones; simplemente no había nadie decidiendo. Y como la regla vivía en el sistema, tampoco había dónde detenerla.

Ese es el costo de convertir una política en regla sin revisar los casos límite: se gana consistencia y se pierde la posibilidad de que alguien aplique criterio cuando hace falta.

Caso 2: Cuando el lineamiento no dio criterio.

Para la contratación se establece que "toda persona contratada deberá contar con documentación de identidad vigente antes de ser dada de alta en nómina".

Alguien la reescribe en términos más flexibles: "El área de Recursos Humanos procurará validar la documentación de los nuevos colaboradores antes de su incorporación."

Llega entonces un colaborador extranjero, ya contratado, cuya documentación migratoria está en proceso de renovación. Tiene que empezar a trabajar.

Un responsable de Recursos Humanos interpreta que "procurará validar" permite continuar con el alta. Otro considera que no debería hacerse.

Los dos están aplicando la misma política. Y esa es la falla: el lineamiento no estableció el criterio, solo suavizó la regla. Cuando una política admite dos lecturas opuestas de buena fe, no está delegando criterio — está delegando el problema.

La diferencia entre los dos casos es instructiva. En el primero, la organización quitó el juicio y luego lo necesitó. En el segundo, lo dejó sin definir y cada quien puso el suyo.

Proceso y procedimiento tampoco son lo mismo

Otra confusión que aparece en toda organización.

Un proceso es una secuencia de actividades que van añadiendo valor a una entrada para generar un resultado destinado a un cliente, interno o externo. Tiene un dueño responsable de que se cumpla su misión, se alcancen sus objetivos y se ejecute lo que lo detalla.

El procedimiento es otra cosa: establece las tareas para ejecutarlo.

Dicho corto: el proceso define y da guía; el procedimiento establece las tareas.

Por eso un proceso puede tener varios procedimientos, y por eso cambiar un procedimiento no siempre implica cambiar el proceso. Cuando las dos cosas se confunden, cualquier ajuste operativo se convierte en un proyecto de rediseño, y la organización deja de ajustar nada.

Por qué las políticas no se cumplen

Tener políticas escritas y tener políticas que operan son cosas distintas. La diferencia suele estar en cuatro cosas.

• No se conocen. Una política que no llegó a todos los niveles donde se va a interpretar y aplicar no existe. Publicarla en una carpeta compartida no es comunicarla.

• No son aplicables. Si en la práctica cumplirla impide hacer el trabajo, la gente encuentra la vuelta y aprende que las políticas son decorativas. Ese aprendizaje después se aplica a todas las demás.

• Se contradicen entre sí. Cuando dos políticas apuntan en direcciones distintas, el colaborador elige la que le conviene, o pregunta al jefe — y volvimos al problema del principio.

• Nadie las revisa. Una política que se escribió hace seis años y nunca se tocó ya no describe cómo opera el negocio. Una fecha de revisión y un responsable resuelven esto, y casi nunca se ponen.

A eso agregaría algo que se subestima: el sistema de consecuencia. Una política que no aclara qué pasa si no se cumple está pidiendo un favor, no estableciendo un criterio.

La pregunta antes de escribir

Cuando alguien va a redactar una política, la conversación suele empezar por el formato: objetivo, alcance, referencias, definiciones, vigencia, historial de cambios. Todo eso hace falta.

Pero la pregunta que determina si va a servir es anterior, y es la misma que abrió este artículo:

¿Cuánta decisión le estoy quitando a quien va a aplicarla, y por qué?

Si la respuesta es "toda, porque el riesgo es alto", escribe una regla. Si es "toda, porque no confío en el criterio de la gente", tienes un problema distinto y la política no lo va a resolver.

Carlos Orrante trabaja en transformación de procesos de negocio y formación de consultores internos.

Hay un momento en la vida de una empresa que se reconoce desde afuera y casi nunca desde adentro. La empresa creció:

• Vende más que hace tres años.

• Contrató gente.

• Abrió una sucursal o una línea nueva.

Y sin embargo, cada vez cuesta más trabajo que las cosas salgan.

• Los pedidos grandes generan pánico en lugar de celebración.

• La misma pregunta llega tres veces al director porque nadie más sabe responderla.

• Un empleado clave se va de vacaciones y algo se detiene.

Al interior de la empresa esto se explica como falta de gente, o como un mal trimestre, o como que el equipo todavía no agarra el ritmo. Desde afuera es otra cosa: la empresa llegó al límite de lo que puede sostener el modelo con el que nació y creció.

Lo que funcionó es lo que dejó de funcionar

Las empresas jóvenes crecen con su fundador: alguien que sabe. Esa persona tiene el negocio completo en la cabeza — sabe qué se le promete a cada cliente, qué proveedor cumple, dónde se pierde dinero, quién hace bien qué cosa.

Ese modelo es eficiente al principio. No hay reuniones de coordinación porque la coordinación ocurre en una sola mente. No hay procesos escritos porque no hacen falta: se pregunta y se resuelve. Las decisiones son rápidas porque las toma quien tiene todo el contexto.

Lo llamo "caos controlado". Es una etapa natural, y hay empresas que la aprovechan bien.

El problema es que la etapa no se supera sola, y la razón es aritmética: la capacidad de una persona para sostener contexto es finita, mientras que la complejidad crece con cada cliente, cada empleado y cada producto nuevo. En algún punto las dos curvas se cruzan.

Cuando se cruzan, la empresa no se detiene de golpe. Se degrada despacio, y por eso es difícil de ver. Un cliente me lo dijo así en nuestras primeras conversaciones: "Carlos, ya viene Navidad y no sé por dónde empezar para estar listo para la temporada".

Cómo se ve la degradación

En la práctica se manifiesta casi siempre igual, sin importar el giro.

Todo escala hacia arriba. Las decisiones que deberían resolverse en el piso suben al director, porque nadie más tiene la autoridad ni la información para tomarlas. El director se convierte en el cuello de botella de su propia empresa. He visto implementar buzones de sugerencias en distintas modalidades para que la gente proponga mejoras, y he visto también cómo esas sugerencias terminan en el escritorio del jefe, para que él decida qué se mejora.

Cada quien hace lo mismo distinto. Dos vendedores cotizan de forma diferente. Dos plantas producen con criterios distintos. No porque alguien esté haciendo mal su trabajo, sino porque nunca se acordó una sola forma y cada quien resolvió como pudo.

El conocimiento es una persona, no un activo. Si esa persona renuncia, se enferma o se toma dos semanas, la operación se resiente. La empresa carga un riesgo que no está registrado en ningún lado y lo nombra con frases cotidianas: "es que Fulano sabe mucho", "es el único", "el experto".

Capacitar toma meses. Un empleado nuevo aprende viendo a otro, porque no hay nada escrito. Eso hace que cada contratación sea cara y lenta, justo cuando más se necesita contratar.

Se mide, pero no se decide con lo medido. Hay números en algún reporte, y las decisiones se siguen tomando por intuición, que es lo que siempre funcionó.

Si tres o cuatro de estas te suenan, no tienes un problema de personal. Tienes un problema de estructura.

La confusión que hay que evitar

Unas deciden que la solución es tecnología, y de ser posible la más nueva. En mi experiencia el error más frecuente es dejar que el proveedor del ERP construya e implemente la solución out of the box — una solución genérica que no está alineada a las necesidades de la empresa. Compran el sistema, lo implementan, y descubren seis meses después que automatizó el desorden que ya tenían. Un ERP no ordena una operación: la refleja. Si el proceso no está definido, el sistema hereda la indefinición y además la vuelve rígida.

Otras deciden que la solución es documentar. El escenario se parece al anterior: se asigna a un equipo de analistas y consultores a escribir manuales y procedimientos sin conversar con los usuarios que viven el día a día. El resultado son manuales que nadie lee, formatos que nadie revisa y capas de aprobación que hacen todo más lento. Confunden orden con control.

Ninguna de las dos ataca el problema, que es más simple de enunciar que de resolver: la empresa nunca decidió explícitamente cómo se hace el trabajo. Solo lo fue resolviendo.

Por dónde empieza

Antes de rediseñar nada, hay preguntas que casi ninguna empresa en esta etapa puede responder con precisión, y responderlas cambia la conversación.

¿Cuáles son tus procesos clave? No las áreas ni el organigrama. Los tres o cuatro flujos de trabajo de los que depende que el cliente reciba lo que compró.

¿Qué tan bien se desempeñan hoy? Con números, no con impresiones. Cuánto tarda, cuánto cuesta, cuántas veces se rehace.

¿Cuánto de lo que ocurre es predecible? Un negocio que opera apagando fuegos gasta su energía en excepciones. La pregunta es qué proporción del trabajo es impredecible de verdad y qué proporción solo lo parece porque nunca se ordenó.

¿Quién decide qué? No quién manda: quién tiene la autoridad para decidir sin preguntar. Cuando esto no está definido, o todo sube o cada quien decide distinto.

En mi experiencia, la conversación en la que un equipo directivo intenta responder estas cuatro preguntas es más reveladora que cualquier diagnóstico formal. Es común que dos directores den respuestas incompatibles sobre cuál es el proceso clave del negocio, y que sea la primera vez que lo notan.

Ordenar no es burocratizar

La resistencia a todo esto viene envuelta en un par de frases:

• "Es que aquí somos muy dinámicos, no queremos volvernos una empresa lenta".

• "Aquí es una empresa distinta, única, no hay nadie como nosotros".

Es una preocupación legítima y mal dirigida. Lo que vuelve lenta a una empresa no es tener procesos definidos; es que cada decisión tenga que pasar por la misma persona. Un proceso bien diseñado hace lo contrario: reparte la capacidad de decidir hacia donde está la información, con criterios claros.

Dicho de otra forma, el objetivo no es que la empresa haga más trámites. Es que el fundador pueda irse dos semanas y a nadie le pase nada.

Eso no se logra con un manual. Se logra decidiendo, con el equipo y de forma explícita, cómo va a funcionar cada proceso clave, quién es responsable de qué, y cómo se va a saber si está funcionando. Es menos glamoroso que comprar un sistema, y funciona.

Volvamos al cliente de Navidad

Recorrimos las cuatro preguntas con su equipo. La lista de pendientes de temporada — revisar las ventas del año anterior, presupuestar, comprar con anticipación, negociar volumen, contratar temporales, capacitarlos — no era el problema. Esa lista él la tenía en la cabeza desde agosto.

El problema apareció en la cuarta pregunta. Todas las decisiones de la temporada pasaban por él. Y en temporada alta eso significaba que la operación se detenía cada vez que estaba en una reunión, en la carretera o con un proveedor.

Lo que decidió fue repartir esas decisiones: qué tareas suyas pasaban a quién, con qué criterios, y una sesión diaria de seguimiento para revisar lo que se había decidido sin él.

El resto de la lista avanzó. No porque la lista fuera mejor, sino porque ya había alguien “más” que la ejecutara sin preguntarle.

El caos controlado no es un error. Es una etapa. Lo que sí es un error es intentar crecer al doble sin haberla dejado atrás.

Carlos Orrante trabaja en transformación de procesos de negocio y formación de consultores internos.

Hay una frase que aparece después de cada implementación y que se dice sin medir el impacto de lo que significa: "Es que el sistema no lo permite."

Antes de la implementación, cuando algo se atoraba, la explicación era otra: "es que Fulano es el único que sabe". Se cambió una frase por otra y se sintió como progreso. Pero el problema persiste: el conocimiento de cómo funciona la operación sigue viviendo en un lugar que nadie puede examinar ni discutir. Antes era la cabeza de una persona; ahora es la configuración de un sistema que nadie recuerda haber acordado.

Un sistema no ordena una operación. Escala sus efectos, formaliza sus reglas y revela su realidad.

¿Por qué la promesa de comprar tecnología es tan atractiva?

Comprar tecnología resuelve algo real, y hay que reconocerlo antes de criticarlo.

Un proyecto de sistema tiene fecha, presupuesto, proveedor, entregables y se puede presentar al consejo. Tiene un botón que se enciende el día del arranque. Por otro lado, un proyecto de rediseño de procesos es un montón de conversaciones difíciles con gente que no quiere tenerlas, y su resultado es que unas decisiones se toman distinto o no se toman. Es más difícil de vender y más difícil de celebrar.

Por eso, cuando una organización siente que está perdiendo el control de su operación, la opción de comprar un sistema no es solo la más publicitada; es la que se ve como un proyecto.

Lo que un sistema hace

• Escala. Si el proceso está definido, lo ejecuta miles de veces sin variación. Si no lo está, reproduce la indefinición a la misma escala. Un proceso confuso que antes afectaba a cincuenta transacciones al mes ahora afecta a cincuenta mil, y con evidencia registrada.

• Formaliza. Lo que antes se resolvía con una llamada, ahora requiere un cambio de configuración, una solicitud, una autorización y una ventana de liberación. Esa rigidez es deseable cuando el proceso es el correcto, y es un problema serio cuando no lo es.

• Revela. Este es el efecto útil y el menos aprovechado. Un sistema obliga a decidir cosas que nadie había decidido: qué campos son obligatorios, quién aprueba qué, qué pasa si el dato no llega. Las conversaciones más productivas de una implementación ocurren en la fase de configuración, y no porque el software las provoque, sino porque por fin alguien pregunta.

 La diferencia entre una implementación que sirve y una que no, está en si esas preguntas se responden antes o durante.

Dónde está el trabajo de verdad

En un programa regional de ciclo de vida del empleado que coordine, documentamos 300 + elementos, entre los que se encuentran:

• Macroprocesos. Procesos. Subprocesos. Grupos de tareas. Procedimientos, políticas y manuales. Catálogos de datos maestros y reglas de negocio.

Casi una tercera parte del trabajo documentado fueron reglas: qué pasa cuando el monto excede un umbral, qué se hace si el dato no llega, quién autoriza en cada caso, cuándo aplica una excepción. El diagrama del flujo se resuelve en semanas. Las reglas toman meses, porque cada una es una decisión que alguien tiene que tomar y defender.

Se cree que implementar un sistema es un proyecto de tecnología con un componente de procesos. Es al revés: es un proyecto de decisiones con un componente de tecnología.

Estándar o adaptado

El error que he visto es dejar que el proveedor implemente la solución out of the box sin que nadie del negocio decida qué se adopta tal cual y qué no. Se entrega una solución genérica que no está alineada a cómo opera la empresa, y el desajuste se descubre en producción, con usuarios reales.

El error opuesto es igual de caro y menos discutido: configurar todo a la medida de cómo se trabaja hoy. Eso convierte el sistema en un espejo del desorden, con la agravante de que ahora el desorden cuesta mantenerlo. Cada personalización se paga en cada actualización, en cada país nuevo, en cada persona que hay que capacitar.

La pregunta correcta no es "estándar o a la medida". Es: ¿Qué parte de cómo trabajamos es diferenciadora, y qué parte es solo la forma en que lo hemos venido haciendo?.

La respuesta suele ser que la mayor parte cae en la segunda categoría.

Lo que se estandariza no es la ejecución

Cuando el mismo proceso tiene que funcionar en varios países, esta discusión se vuelve el centro del proyecto. Y el resultado al que llegamos contradice lo que casi todos suponen.

En el programa que mencioné, diversos procesos operando en seis países, revisamos cada uno en cuatro dimensiones: quién lo gobierna, quién lo ejecuta, quién sostiene la tecnología y quién da el soporte.

En todos los procesos, la gobernabilidad quedó central. La tecnología, central. El equipo de soporte, central.

Lo único que varió fue la ejecución. Algunos procesos se operan localmente, otros se reparten entre el centro y el país, unos pocos se operan desde el centro.

Es lo contrario de lo que se intenta normalmente. Cuando una organización dice "vamos a estandarizar", casi siempre quiere decir que todos van a hacer las cosas de la misma manera — mismos pasos, mismos tiempos, misma gente. Eso es lo que genera resistencia, y con razón, porque las condiciones locales son distintas y quien opera lo sabe.

Lo que sí tiene que ser común es otra cosa: las reglas, los datos maestros, la plataforma y quién decide cuándo algo cambia. Con eso fijo, la ejecución puede adaptarse al país sin que el proceso se fragmente.

Hay una distinción que ayuda a separar las dos cosas. Está lo que cambia porque la ley lo obliga —contratación, nómina, datos personales, terminación— y eso se respeta sin discusión. Y está lo que cambia porque cada sitio lo resolvió a su manera cuando no había un estándar. Confundir las dos es lo que convierte un programa regional en la suma de seis proyectos locales.

Una regla en el sistema vale más que una en el manual

Antes del programa, uno de los hallazgos del diagnóstico era que las reglas de negocio no se respetaban. Estaban escritas, y aun así cada equipo y cada país resolvía a su manera.

Después, las reglas quedaron dentro de las herramientas. Y hubo una decisión que ilustra bien la diferencia: el equipo de nómina dejó de tener acceso para modificar salarios.

Esa no es una decisión técnica. Es una decisión de control que se discutió, se acordó, y se implementó configurando permisos. En un manual habría sido una línea que alguien podía ignorar; en el sistema es una condición del trabajo.

Esa es la forma útil de usar tecnología: no para automatizar lo que ya se hacía, sino para hacer imposible lo que se acordó que no debía pasar.

El arranque no es la meta

En ese programa, el análisis y diseño tomó seis meses. El despliegue y la capacitación, ocho. El soporte y la estabilización, dieciocho.

La estabilización duró más que el diseño y el despliegue juntos.

No fue una desviación del plan; estaba planeado así. Y esa proporción es la que casi nunca aparece en los planes que veo. Se presupuesta el diseño, se presupuesta el arranque, y la fase que más dura se trata como si fuera garantía del proveedor.

La capacitación da una idea del volumen: doscientos cuarenta y nueve materiales para ocho procesos, poco más de diez horas de contenido, y más de tres mil usuarios formados en sesiones presenciales y remotas. Nada de eso ocurre antes del arranque. Ocurre después, durante meses, y hay que tener quién lo haga.

Quién se queda con el proceso

Cuando montamos el equipo de soporte de ese programa, la primera justificación en el documento no era técnica. Era esta: cerrar el proyecto y entregar el proceso a la operación.

Un proyecto termina. Un proceso no. Y entre esas dos cosas hay un hueco por el que se cae la mayoría de las implementaciones.

Ese equipo no era una mesa de ayuda. Su definición de trabajo empezaba con algo que vale la pena copiar: una incidencia es cualquier desviación a lo establecido por el proceso. No un error del sistema, no una queja del usuario. Una desviación del proceso.

Con esa definición, el trabajo del equipo deja de ser reactivo. Monitorea la ejecución, identifica riesgos antes de que se materialicen, administra los catálogos de datos maestros que mantienen la integridad entre herramientas, mantiene la documentación viva, capacita a los usuarios nuevos, y consolida las mejoras para proponer la siguiente versión del proceso.

Ese último punto es el que más me interesa. El equipo de soporte no solo sostiene la versión uno: es quien tiene la información para diseñar la versión dos. Las incidencias, bien registradas y clasificadas, son el mejor diagnóstico que una organización puede tener de su propio proceso, y llega gratis.

Sin ese equipo pasa lo previsible. En unos meses la operación se llena de excepciones manuales fuera del sistema —hojas de cálculo paralelas, correos de autorización, acuerdos verbales— y la organización concluye que el sistema no sirvió.

El sistema sirvió. Lo que faltó fue la parte que no venía en la licencia.

En resumen

Un sistema es una herramienta buena para ejecutar decisiones y mala para tomarlas.

Si la organización llega a la implementación con las decisiones tomadas, la tecnología multiplica su capacidad. Si llega sin tomarlas, las va a tomar el proyecto: por default, en una mesa de configuración, con criterios técnicos, y sin que nadie del negocio se entere hasta que sea caro cambiarlas.

La pregunta antes de firmar no es qué sistema comprar. Es qué decisiones vamos a tener tomadas antes de que llegue el consultor.

Carlos Orrante trabaja en transformación de procesos de negocio y formación de consultores internos.