Las transiciones a servicios compartidos figuran entre los programas de simplificación que más se prometen en el inventario de business cases, y entre los productores más confiables de complejidad organizacional una vez que la simplificación prometida se contrasta con lo que la organización realmente opera después de que la transición se estabiliza. El patrón se sostiene entre industrias, geografías y alcances funcionales. Los equipos de finanzas distribuidos se consolidan, los equipos de recursos humanos distribuidos se consolidan, los equipos de compras distribuidos se consolidan, y dos o tres años más tarde la organización consolidada emplea a más personas en coordinación, gestión de interfaces y gobernanza de escalamiento que las que la organización distribuida a la que reemplazó empleaba en las funciones que se consolidaron. El business case cumple en sus términos declarados, ya que esos términos medían la reducción de dotación en las funciones consolidadas y no el cambio neto de dotación en la organización más amplia. La realidad diverge del business case, ya que la dotación que el business case nunca midió era la dotación que la consolidación volvió necesaria.

El business case de servicios compartidos, en su forma estándar, descansa sobre un conjunto de supuestos que la literatura trata como resueltos: que la consolidación produce economías de escala en las operaciones funcionales, que la estandarización reduce la varianza en la calidad del servicio, que la concentración de talento especializado produce una pericia que el modelo distribuido no puede igualar, y que la inversión en tecnología en la estructura consolidada produce una capacidad que la estructura distribuida no puede justificar. Cada supuesto describe algo real, y cada uno, tomado por separado, es defendible. El business case que los agrega trata la consolidación misma como el logro organizacional, bajo la premisa de que sus implicancias operativas se resolverán solas mediante el ritmo operativo estándar de la nueva estructura. Esa agregación produce proyecciones numéricas cuyo intervalo de confianza no refleja la varianza que la resolución operativa efectivamente introduce. Las proyecciones modelan la organización consolidada como la organización distribuida con las funciones distribuidas removidas, que no es como opera la organización consolidada, y la brecha entre el estado operativo modelado y el realizado es donde se acumula el crecimiento de la coordinación.

Contrastemos una transición con el patrón, para aterrizarlo. Eliminó 340 puestos distribuidos de finanzas, recursos humanos y compras en una empresa de tamaño mediano y, en el plazo de tres años, dotó una organización de servicios compartidos de 410 personas: el personal del centro de servicios más los gestores de relaciones, los coordinadores de entrega de servicio, los líderes de gobernanza de escalamiento y los roles de gestión de interfaces que no existían antes de la consolidación. La organización que se suponía más simple ahora tiene más gente gestionando coordinación que la que tenía haciendo el trabajo distribuido. La dotación neta corrió en dirección opuesta a la del business case, y la complejidad organizacional, medida en capas de coordinación, interfaces de autoridad y foros de gobernanza, subió de manera decisiva. Este no es un resultado inusual. Es uno recurrente, visible en suficientes transiciones a servicios compartidos como para contar como la firma estructural del modelo tal como se implementa habitualmente.

La explicación es sencilla una vez enunciada. Las transiciones a servicios compartidos redistribuyen la complejidad en lugar de eliminarla, ya que el trabajo que antes absorbían los equipos distribuidos mediante el conocimiento local, la proximidad física y la coordinación informal se traslada a una estructura centralizada que debe formalizar lo que antes era tácito. Los derechos de decisión que eran implícitos pasan a ser disputados. La gobernanza que resultaba innecesaria cuando las funciones estaban cerca del negocio se vuelve crítica cuando quedan en una organización aparte. La carga de coordinación que parecía ausente en el modelo distribuido estuvo presente todo el tiempo, simplemente absorbida de manera informal por las personas que hacían el trabajo. Cuando esas personas se reubican en una estructura consolidada, la carga se reubica con ellas, despojada de los mecanismos informales que la volvían invisible, y se vuelve visible, formalizada y dotada.

Lo que el modelo distribuido producía gratis

Tres cosas que el modelo distribuido producía sin costo aparente se vuelven, en el modelo consolidado, caras de reemplazar: el conocimiento local, la autoridad de decisión informal y la proximidad. Cada una era un insumo de gobernanza sobre el que la organización distribuida funcionaba sin tener que construirlo, mantenerlo ni presupuestarlo. Cada una se convierte, bajo la consolidación, en un producto de gobernanza que la organización centralizada tiene que generar mediante un diseño deliberado o pagar a través de la demanda de coordinación que su ausencia genera. Las tres no son independientes, y se potencian entre sí, ya que el conocimiento local sostenía las decisiones informales, la proximidad sostenía el conocimiento local, y la eliminación simultánea de las tres suprime un mecanismo integrado en lugar de tres mecanismos separados.

El conocimiento local importa primero, ya que carga el contexto operativo que los equipos distribuidos usaban para hacer su trabajo efectivo. Un equipo de finanzas de una unidad de negocio que ha trabajado codo a codo con los equipos de operaciones durante años carga una comprensión de los procesos de la unidad, sus prioridades, sus patrones estacionales, sus jerarquías informales y las personalidades específicas de los gerentes operativos cuyos pedidos atiende. Nada de esto está documentado en ninguna parte. La mayor parte no es conocimiento explícito que los integrantes del equipo pudieran articular si se les preguntara. Sin embargo, moldea cada decisión que el equipo toma sobre cómo priorizar pedidos, cómo interpretar instrucciones ambiguas, cómo manejar excepciones y cómo enrutar la información al gerente operativo correcto. Cuando el equipo se consolida en un centro de servicios compartidos, las personas que cargan este conocimiento se consolidan con él, mientras que el contexto relacional que volvía utilizable ese conocimiento no lo hace, ya que el contacto operativo diario que mantenía ese contexto al día deja de ocurrir. En el plazo de dieciocho meses la mayor parte de ese contexto se ha degradado, y lo que reemplaza al conocimiento local es la estandarización de procesos, que maneja los casos rutinarios con eficiencia y genera excepciones en todos los lugares donde el conocimiento local solía resolver sin que se notara.

La autoridad de decisión informal es la segunda cosa que la consolidación redistribuye, y la redistribución es más trascendente de lo que el business case reconoce. Los equipos distribuidos toman a diario incontables decisiones pequeñas que nunca afloran como decisiones: qué pedidos priorizar cuando la capacidad está restringida, qué excepciones acomodar y a cuáles oponerse, cómo manejar el pedido que no encaja en el proceso estándar, cuándo romper una regla que el contexto operativo ha vuelto inadecuada. Personas con suficiente contexto organizacional tomaban estas decisiones correctamente, y esa corrección se sostenía porque quienes las tomaban respondían ante los gerentes operativos cuyo trabajo afectaban las decisiones. La consolidación traslada las decisiones a una estructura de gobernanza donde la autoridad informal ya no aplica, ya que el equipo consolidado ya no está dentro de la cadena de accountability en la que estaba el equipo distribuido. La estructura de gobernanza que reemplaza a la autoridad informal tiene que ser explícita sobre quién decide, sobre qué base, mediante qué proceso, con qué mecanismo de escalamiento cuando la decisión de primer nivel se disputa. Decisiones que antes se tomaban sin que se vieran ahora requieren rutas de escalamiento, comités de excepciones y negociaciones de nivel de servicio, y cada una genera un trabajo de coordinación que el modelo distribuido nunca requirió.

La proximidad, el tercer insumo que la consolidación elimina, hacía un trabajo fácil de pasar por alto hasta que desaparece. Las funciones distribuidas estaban físicamente cerca de las unidades de negocio a las que servían, y esa cercanía volvía la coordinación libre de fricción de un modo que escalaba con la calidad de las relaciones, ya que una conversación en un pasillo resolvía lo que de otro modo habría requerido un correo, luego un correo de seguimiento, luego una reunión, luego un escalamiento, luego un foro de gobernanza. Coordinar a través de la distancia cuesta sustancialmente más, ya que la distancia introduce errores de interpretación, fricción de agenda, rezagos de atención y el sobrecosto de traducción de convertir el contexto operativo tácito en comunicación explícita sobre la que un equipo distante pueda actuar. La consolidación crea un límite donde no existía ninguno, y luego construye la capa de gestión de relaciones para gestionar a través de él. El rol de gestor de relaciones existe para dotar una brecha estructural que la consolidación abrió, y su costo es la respuesta organizacional a un problema de gobernanza que la consolidación creó, un problema que el modelo distribuido al que reemplazó nunca planteó.

Vale la pena nombrar directamente la potenciación entre las tres, ya que las conversaciones de diseño de servicios compartidos las tratan como problemas de gobernanza separados que se gestionan con mecanismos separados, cuando su operación simultánea en el modelo distribuido es exactamente lo que hacía funcionar ese modelo sin gobernanza formal. El conocimiento local habilitaba las decisiones informales, ya que las decisiones solo eran defendibles ante quienes cargaban el contexto operativo que había detrás de ellas. La proximidad sostenía el conocimiento local, ya que el contacto diario con las unidades de negocio mantenía el contexto al día. La autoridad informal descansaba en la confianza de que el conocimiento local de los equipos distribuidos producía decisiones alineadas con las prioridades de los gerentes operativos. Cada una de las tres sostenía a las otras dos, y la simplicidad del modelo distribuido era el producto de su integración, no de ninguna de ellas por sí sola. La consolidación remueve las tres a la vez, y el diseño de gobernanza que tiene que reemplazarlas tiene que abordar su integración además de las tres individualmente, que es un problema de diseño que la mayoría de las metodologías de servicios compartidos nunca fueron construidas para manejar.

La brecha de gobernanza en la interfaz

La interfaz entre un centro de servicios compartidos y las unidades de negocio a las que sirve es un punto de negociación de gobernanza permanente, y las conversaciones de diseño de servicios compartidos rara vez la tratan como tal. Se concentran en la estandarización de procesos, la selección de la plataforma tecnológica, los acuerdos de nivel de servicio y los foros de gobernanza a nivel ejecutivo, mientras que la interfaz misma, donde las operaciones formales del centro se encuentran con las necesidades operativas de las unidades de negocio, recibe comparativamente poca atención de diseño, bajo el supuesto de que los acuerdos de nivel de servicio y los foros ejecutivos cubrirán lo que allí ocurra. No lo cubren. Cada excepción al proceso estándar, cada conflicto de prioridad cuando la capacidad está restringida, cada pregunta de nivel de servicio que cae entre las categorías definidas y cada pedido operativo que no existía cuando se negoció el acuerdo produce una decisión sobre quién tiene autoridad, con qué criterios y mediante qué proceso. La mayoría de estas decisiones tienen que tomarse más rápido de lo que los foros de gobernanza pueden reunirse para tomarlas.

La capa de gestión de relaciones existe para llenar la brecha. Cuando la gobernanza no especifica quién decide sobre las excepciones, el gestor de relaciones decide, o escala hasta que alguien lo bastante alto decide, o devuelve la decisión a la unidad de negocio mientras el centro sigue corriendo su proceso por defecto. Cuando surgen conflictos de prioridad sin un proceso de arbitraje definido, el gestor de relaciones negocia entre las restricciones de capacidad del centro y los reclamos de prioridad de la unidad de negocio, o escala el conflicto por ambas cadenas organizacionales hasta que se resuelve solo por agotamiento o por una intervención ejecutiva que ninguna de las dos cadenas quería. Cada pregunta de gobernanza sin resolver genera una demanda de coordinación continua, ya que la pregunta reaparece en forma ligeramente alterada la próxima vez que aflora una excepción, un conflicto o una ambigüedad similar. El gestor de relaciones atiende la demanda sin resolver la pregunta de fondo, ya que resolverla no está dentro de la autoridad del gestor de relaciones. La pregunta persiste, generando el siguiente requerimiento de coordinación, y la carga de trabajo crece.

Sigamos un devengo a lo largo de cuatro trimestres. El cierre de fin de mes de una unidad de negocio requiere que el equipo de finanzas del centro procese un conjunto de devengos que caen fuera del proceso estándar de fin de mes, ya que la unidad carga una obligación de reporte trimestral que el nivel de servicio estándar nunca anticipó. La primera vez, el gestor de relaciones negocia una acomodación puntual entre el líder de finanzas de la unidad y el gerente de entrega del centro, que ambos lados aceptan como una excepción. La excepción reaparece al trimestre siguiente, y al siguiente, y en el plazo de cuatro trimestres la acomodación se ha vuelto una parte de facto del nivel de servicio de la unidad sin haberse agregado nunca formalmente al acuerdo, y sin aflorar nunca como una pregunta de gobernanza que el foro ejecutivo resolvería. La carga de trabajo del gestor de relaciones absorbe la coordinación continua que la acomodación requiere, hasta que el volumen de tales acomodaciones informales a lo largo de las unidades que atiende excede su capacidad, momento en el cual el centro contrata a otro gestor de relaciones para absorber los compromisos acumulados. La pregunta de gobernanza que lo habría zanjado de forma permanente, si el acuerdo de nivel de servicio debería cubrir el ciclo de reporte trimestral o si el centro debería correr sobre excepciones para él, nunca llega al foro que la respondería.

La capa de coordinación se expande exactamente a través de esta acumulación de preguntas de gobernanza de interfaz sin resolver. Las organizaciones no contratan gestores de relaciones que no necesitan. Los contratan porque la demanda de coordinación que la brecha de gobernanza genera ha excedido la capacidad de los coordinadores existentes. Los nuevos coordinadores absorben la demanda temporalmente, produciendo la apariencia de resolución durante un trimestre o dos, hasta que la demanda supera su capacidad y la siguiente contratación se vuelve necesaria. Las personas son el síntoma de una condición que es, en su origen, un problema de diseño de gobernanza y no de dotación. La respuesta de dotación trata el síntoma sin tocar la condición, de modo que la condición sigue produciendo síntomas nuevos a un ritmo que la respuesta de dotación no logra seguir.

Lo que vuelve tan duradera a la dinámica es que las preguntas que la interfaz genera son operativas, y los foros que podrían resolverlas se sitúan en niveles de la organización enfocados en preocupaciones estratégicas. Los escalamientos que llegan al foro de gobernanza ejecutivo son los severos, el puñado de conflictos que los gestores de relaciones no pudieron resolver y que la unidad de negocio y el centro no pudieron zanjar entre sí. Las brechas de gobernanza rutinarias se quedan con la capa de coordinación hasta que se vuelven severas, y la mayoría nunca se vuelve lo bastante severa como para llegar al foro ejecutivo, lo que significa que la mayoría nunca se resuelve al nivel del diseño de gobernanza, lo que significa que siguen produciendo demanda de coordinación indefinidamente. Para cuando una pregunta se ha vuelto lo bastante severa como para escalar, la gestión informal de ella ya se ha institucionalizado y el rol que la gestiona ya se ha vuelto permanente.

Por qué la capa de coordinación sigue creciendo

Las organizaciones responden a la creciente carga de coordinación agregando capacidad de coordinación: más gestores de relaciones, más rutas de escalamiento, más foros de gobernanza, más roles dedicados a gestionar las interfaces que la transición original creó. Cada adición gestiona la demanda inmediata sin abordar su fuente estructural. Las preguntas de gobernanza siguen sin resolverse, la demanda de coordinación persiste, y los nuevos roles la absorben temporalmente, comprando la apariencia de resolución hasta que la demanda crece más allá de su capacidad y la siguiente adición se vuelve necesaria. El patrón aparece en transiciones de tamaño y sector variados, y la curva de crecimiento de la capa de coordinación es más o menos consistente a lo largo de la muestra. La dotación en roles de coordinación y gestión de interfaces crece aproximadamente al ritmo al que crece la demanda de la brecha de gobernanza, con un rezago de cerca de un trimestre, que es el intervalo entre que un problema se vuelve inmanejable y que un nuevo rol se aprueba.

La capa crece por la misma razón por la que la brecha de gobernanza persiste. Resolver preguntas en la interfaz requiere una autoridad que se sitúa por encima tanto del centro como de las unidades de negocio, y los foros a ese nivel rara vez se enfocan en las preguntas operativas que la interfaz genera, ya que esas preguntas se presentan, ante los líderes senior que tendrían que asistir, como asuntos operativos que corresponden al nivel operativo. Corresponderían allí, bajo una arquitectura de gobernanza diseñada para manejarlas operativamente. Bajo una arquitectura que no las diseñó, o bien escalan a niveles inadecuados, donde se rechazan por demasiado operativas, o bien las gestiona una capa de coordinación que carece de la autoridad para resolverlas, lo que significa que reaparecen.

Tres años después de una transición típica, la dotación en la capa de coordinación normalmente ha alcanzado o superado la reducción de dotación que el business case entregó en las funciones distribuidas, y el business case se ha entregado técnicamente en el sentido de que eliminó los puestos distribuidos. Los roles de coordinación que la estructura requirió compensaron esas eliminaciones, y el resultado neto no es simplificación en ningún sentido significativo. Es una distribución distinta del mismo trabajo organizacional, con menos proximidad a las unidades de negocio, más formalización, mayor costo de coordinación y menor adaptabilidad a condiciones que la estandarización de procesos original no anticipó. La organización corrió un programa para simplificarse y produjo, tres años más tarde, una estructura más compleja que la que reemplazó, con un business case entregado en sus términos medidos y un modelo operativo que no lo fue.

El diseño de gobernanza que la metodología se salta

El rasgo contraintuitivo de las transiciones a servicios compartidos que entregan simplificación real es que requieren sustancialmente más diseño de gobernanza que las transiciones que producen el patrón de crecimiento de la coordinación. Esto invierte el supuesto con el que la mayoría de las conversaciones de servicios compartidos comienzan. El modelo distribuido funcionaba con una gobernanza formal mínima, ya que la proximidad, el conocimiento local y la autoridad informal suministraban la coordinación que la gobernanza tendría que especificar de otro modo. El modelo consolidado no puede funcionar sobre el mismo sustrato, ya que la proximidad, el conocimiento local y la autoridad informal han sido todos dispersados, y algo tiene que reemplazarlos. El reemplazo tiene que diseñarse, ya que la organización centralizada no lo producirá de forma espontánea como lo hacía la organización distribuida. Lo que las conversaciones de diseño de servicios compartidos se saltan, o subponderan, es exactamente el trabajo de diseño requerido para reconstruir el sustrato de gobernanza que la consolidación removió.

Ese trabajo de diseño corre a lo largo de varios registros, y cada uno necesita el rigor que suele reservarse para las capas de proceso y tecnología de la implementación. Los derechos de decisión en la interfaz requieren una especificación explícita: quién decide sobre las excepciones, con qué criterios, mediante qué ruta de escalamiento cuando la decisión de primer nivel se disputa, y qué autoridad tiene el centro cuando la demanda de la unidad de negocio excede la capacidad. Toda organización tiene respuestas a estas preguntas. En la mayoría de las implementaciones las respuestas no se diseñan por adelantado, sino que se descubren a través de la fricción operativa y se zanjan de manera informal, de formas que se vuelven institucionales antes de que nadie reconozca que se están volviendo institucionales. La conversación de diseño de gobernanza tiene que producir las respuestas en la etapa de diseño, ya que la alternativa es zanjarlas bajo presión operativa en formas que la organización después tendrá que deshacer.

Vale la pena incorporar una restricción a la metodología de manera explícita. Por cada nuevo mecanismo de coordinación que se introduce, preguntar qué mecanismo existente reemplaza. Si el rol de gestor de relaciones es necesario, ¿qué coordinación informal formalizó, y qué retira esa formalización? Si se requiere un nuevo foro de escalamiento, ¿qué problema de gobernanza resuelve que la estructura anterior no podía? La restricción no impide que existan roles de coordinación, ya que algunos son genuinamente necesarios bajo el modelo consolidado y el modelo distribuido nunca los requirió. Exige que su adición reduzca la complejidad de gobernanza en otra parte en lugar de sumar en términos netos, lo que obliga a la conversación de diseño a especificar tanto qué hace el nuevo mecanismo como qué retira. La mayoría de los diseños de servicios compartidos no pasan esta restricción. Agregan mecanismos de coordinación sin retirar ninguno, y el efecto agregado es el patrón de crecimiento de la coordinación.

La revisión de gobernanza de interfaz, ejecutada como una función permanente separada de las revisiones de nivel de servicio que los centros de servicios compartidos ya realizan, suministra el diagnóstico continuo que la etapa de diseño no puede anticipar del todo. Las revisiones de nivel de servicio miden el desempeño de entrega contra los niveles de servicio acordados. Las revisiones de gobernanza de interfaz identifican las preguntas que generan demanda de coordinación y las traen a la superficie para resolverlas al nivel correcto antes de que la capa de coordinación requerida para gestionarlas se vuelva permanente. La revisión hace preguntas específicas. ¿Qué excepciones han reaparecido con suficiente frecuencia como para que deban rediseñarse como casos estándar? ¿Qué escalamientos han llegado repetidamente al gestor de relaciones porque nadie por encima del gestor de relaciones ha resuelto la pregunta de fondo? ¿Qué conflictos de prioridad se han gestionado mediante negociación informal porque no existe un mecanismo de arbitraje explícito? Las respuestas suelen estar en los registros operativos de la capa de coordinación, que nadie lee al nivel del diseño de gobernanza, ya que a nadie le han dicho que lo haga.

Un equipo pequeño conduce la revisión, y su composición refleja la interfaz misma: un representante del liderazgo de operaciones del centro, uno del liderazgo de finanzas u operaciones de las unidades de negocio, y un especialista en gobernanza cuyo trabajo es traducir los patrones a nivel operativo en preguntas de diseño de gobernanza sobre las que el foro ejecutivo pueda actuar. El equipo se reúne trimestralmente, lee los registros operativos de la capa de coordinación, identifica los patrones recurrentes que marcan preguntas de gobernanza sin resolver, y produce un briefing que enmarca las preguntas en términos de diseño y no como escalamientos operativos. El encuadre es lo que importa, ya que el foro ejecutivo que rechazaría un escalamiento operativo por estar por debajo de su nivel sí abordará una pregunta de diseño de gobernanza como algo que le corresponde. El producto de la revisión no es un programa de remediación. Es un conjunto de decisiones de diseño de gobernanza que, una vez tomadas, retiran una clase de demanda de coordinación que la organización de otro modo iba a absorber mediante contrataciones adicionales.

La inversión en diseño de gobernanza se paga a través de la dotación que no hace falta contratar en la capa de coordinación durante los dos o tres años siguientes. Los ahorros son difíciles de atribuir con limpieza, ya que se presentan como contrataciones que no ocurrieron y no como contrataciones que se recortaron, lo que vuelve difícil justificar la inversión frente a inversiones comparables cuyos retornos son visibles. Esto se repite en la inversión en gobernanza en general. El retorno lo producen ausencias, las ausencias son contrafactuales, y las convenciones presupuestarias bajo las que funcionan la mayoría de las organizaciones no ponderan los ahorros contrafactuales frente a los costos visibles del modo en que la economía del diseño de gobernanza lo exigiría.

De dónde viene realmente la simplificación

La simplificación que las transiciones a servicios compartidos prometen es real, y puede producirse. El camino hacia ella pasa por una arquitectura de gobernanza más deliberada, no menos, que es la conclusión que la mayoría de las conversaciones de servicios compartidos están menos preparadas para alcanzar, ya que enmarcar la transición como un programa de simplificación conspira contra reconocer que la simplificación del tipo aparente requiere complejidad de otro tipo por debajo. La gobernanza informal del modelo distribuido era su fortaleza, ya que absorbía el trabajo de coordinación de manera invisible mediante mecanismos que no necesitaban diseño explícito. La gobernanza formal del modelo centralizado es su requisito, ya que los mecanismos que absorbían ese trabajo de manera invisible han sido dispersados, el trabajo de coordinación tiene que aterrizar en algún lugar, y el único mecanismo disponible bajo la consolidación es la gobernanza explícita.

Las organizaciones que intentan la centralización mientras conservan los hábitos de gobernanza informal del modelo distribuido descubren la brecha a través de la capa de coordinación que crece para llenarla, trimestre tras trimestre, contratación tras contratación, hasta que el business case que la transición se suponía debía entregar se ha revertido en la práctica. El liderazgo por lo general no reabre el business case, ya que reabrirlo requeriría admitir que la transición produjo lo opuesto de lo que prometió, una conversación que la gobernanza de la organización no está montada para alojar. La alternativa, diseñar la gobernanza de la interfaz desde el inicio con el mismo rigor que reciben las capas de proceso y tecnología, produce un resultado materialmente distinto, y en cualquier comparación razonable del esfuerzo de implementación contra el costo operativo a tres años es el enfoque sustancialmente más barato. La mayoría de las organizaciones no lo toman, ya que el trabajo de diseño es invisible para los foros ejecutivos que aprueban la transición, y el diseño de gobernanza invisible es difícil de encargar cuando la alternativa visible es contratar más coordinadores a medida que surge la necesidad.

Los 410 roles que gestionan coordinación donde 340 alguna vez hicieron el trabajo son la expresión organizacional de una gobernanza que nunca se diseñó. No son una falla de las personas que los ocupan, ni del modelo de servicios compartidos como concepto. Son el producto predecible de una transición que trató el proceso y la tecnología como los sujetos de diseño y la gobernanza como una idea tardía, y la capa de coordinación que esa idea tardía generó es la cuenta que la transición paga por haber supuesto que la nueva estructura produciría su gobernanza por su cuenta.