Divide et impera

Ha escrito Julen este domingo sobre la aplicación de las reglas de simplicidad del diseño de John Maeda aplicadas al management. Tirando de la hebra llego a una versión anterior de la primera de esas diez leyes, ilustrada con la ruedecita del iPod, y que concluye con la siguiente formulación:

A complex system of many functions can be simplified by carefully grouping related functions.

First law of simplicity, John Maeda, Enero 2005

Como bien dice Julen, esto es perfectamente aplicable a las organizaciones, que no dejan de ser un sistema complejo -y además no lineal, como debatía hace poco con Telémaco. Pues bien, no sólo no estoy de acuerdo sino que abogo por la unificación de funciones poniendo el ojo más en el proceso, que en la tarea.

He visto muchas veces, y lo he comentado por aquí, que a menudo se interpreta erróneamente la simplificación y se confunde con unificación y homogenización. Ya di mi opinión sobre la homogeneización en el post mencionado y, desde mi punto de vista, la unificación no sólo no elimina la complejidad sino que frecuentemente la fuerza.

Un lugar donde impera la unificación es precisamente en relación con la naturaleza de las tareas que se realizan dentro de una empresa, donde la lógica dominante dicta que hay que organizarse más en torno a un conjunto homogéneo de actividades (ventas, marketing, contabilidad, facturación, operaciones, logística, etc.) que en torno a un conjunto homogéneo de clientes que requieren de procesos que son más o menos homogéneos.

Pero cuando dividimos por funciones o tareas, estamos creando silos funcionales donde cada cual buscará optimizar su propio cuello de botella, y esto es como tratar de arreglar el tráfico de Madrid por barrios. Goldratt ya advierte sobre los peligros de la búsqueda de óptimos locales y es algo a lo que he hecho referencias varias veces en este blog, pero de esto hay quien sabe muchísimo más que yo, así que me limitaré a enumerar tres consecuencias negativas que a mi juicio tiene el abusar de la división del trabajo:

  1. Resta flexibilidad. Es decir, al trabajar en compartimentos estancos, no podemos balancear la capacidad disponible de manera que podamos reforzar las áreas con una mayor demanda de esfuerzo. Por ejemplo, nunca he entendido los restaurantes que tienen dividido sus camareros entre los de las bebidas y los de la comida. Esto es típico de los chiringuitos de la playa. ¿Qué ocurre al principio del turno en un día de calor cuando todos llegamos pidiendo una cerveza bien fría como agua de Mayo? Pues que tenemos a los de los “sólidos” dando vueltas diciendo que no, que ellos sólo toman nota de la comida, mientras que los pobres de los líquidos no dan abasto.
  2. Obliga a establecer criterios artificiales para la asignación de las tareas a uno u otro departamento. Siendo raro que estos criterios puedan quedar tan claros como que sean blanco o negro, siempre habrá una zona gris, un área de solapamiento donde corremos el riesgo de duplicar el esfuerzo o que no se haga nada -ya se sabe, el uno por el otro y la casa por barrer. Por ejemplo, siguiendo el ejemplo anterior y forzándolo un poco (lo reconozco): ¿el gazpacho se considera comida o bebida? ¿y la cuenta quien la trae, el de la comida o el de la bebida? ¿o hay uno específico para cobrar? A lo mejor hay uno para cobrar y otro para traer el cambio. O uno para cobrar en efectivo y otro para cobrar con tarjeta….
  3. Genera conflictos. En efecto, cuando seguimos el flujo del proceso de negocio y viajamos a través de la cadena de valor nos vamos encontrando intersecciones en las que hacemos una transferencia de la responsabilidad. En estos “traspasos de poder” cotidianos es habitual que surjan rechazos y devoluciones por no venir en la forma adecuada, en el momento adecuado o simplemente porque se niega la responsabilidad. Además, con el número de interfaces aumentan las necesidades de coordinación y también las esperas. Para evitar o minimizar los conflictos, se recurre entonces a detallar procedimientos muy exhaustivos y densos que traten de cubrir toda la casuística posible, lo cual a menudo resulta harto complicado. Lo peor es que siempre el mayor perjudicado es el cliente. Porque, ¿qué ocurre si nos traen la comida antes que la bebida? ¿O cuando le pedimos la cocacola al camarero de la sopa?

En definitiva, cuando unificamos por tareas, dividimos el proceso y aumentan las situaciones en las que surgen conflictos, errores, rigideces y retrasos que restan eficiencia y le complican la vida a nuestro cliente. Y, además, para minimizar las fricciones surge la necesidad de definir muy detalladamente esos interfaces, con procedimientos muy exhaustivos y con numeros puntos de control, que no hacen sino hacer más compleja la operación, añadir más retardos e incrementar las necesidades de coordinación.

Lo que yo propongo es unificar por procesos, dividiendo los equipos funcionales, creando un número menor de departamentos, pero con más personas y mayor variedad de tareas. Creo que de este modo simplificamos las operaciones, eliminamos la necesidad de elaborar procedimientos y especificaciones de interfaces que deban agotar todas las posibilidades, ganamos en flexibilidad para balancear la dedicación de las personas y moverlas dinámicamente allí donde se necesite en cada momento y, a la postre podremos hacer más -en el sentido global, pensando en el cliente- con el mismo número de personas.

Es por esto que, cuando Julen ilustra su entrada con un 1+1=2, yo iría más lejos y diría:

 

1 > 2

 

4 thoughts on “Divide et impera

  1. Por no mencionar los beneficios que este enfoque proporciona en la motivación y el desarrollo, ya que nos permite crear puestos de trabajo con más contenido, más posibilidades de desarrollo y con mayor sentido de responsabilidad sobre el resultado global.
    Estupenda anotación, Antonio.

  2. Es tan obvio que cuesta entender como la inmensa mayoría de las empresas siguen segmentando sus recursos.
    Se deben segmentar los mercados pero no los recursos. Como explicas estupendamente, segmentar recursos únicamente hace que aumente la complejidad y la ineficiencia.
    Es curioso, porque el argumento que más se suele oír a favor de segmentar recursos es que aumenta la agilidad de la empresa, porque alegan que esta es inversamente proporcional al tamaño de la estructura. Pero en mi opinión, a lo que es realmente inversamente proporcional es al número y al grosor de los “interfaces” que la información tiene que atravesar.
    Estoy totalmente de acuerdo con lo que expones. Sólo hay un pequeño matiz con el que discrepo. Y es que comentas como un inconveniente que segmentar impide balancear la capacidad disponible. En mi opinión no es bueno balancear la capacidad disponible, hacerlo aumenta el rendimiento en los informes contables, pero a costa de aumentar la inestabilidad del sistema y hacerlo inmanejable e impredecible.

  3. César, siempre he pensado que si se conoce el porqué y, sobre todo, el paraqué de lo que hacemos, no sentiremos mucho más inclinados a hacerlo, y además de una manera racional. Dentro de un equipo que tiene la responsabilidad de un proceso global, aunque la tarea propia sea muy especializada, se tiene la visibilidad sobre el resultado y por lo tanto se entiende el paraqué, por eso creo que tienes toda la razón.
    Telémaco, yo sin embargo creo que un cierto nivel de balanceo, siempre y cuando el sistema sea suficientemente flexible (y eso implica que no se desestabilice al mover los recursos de un sitio a otro) es saludable. La segmentación puede imponer esta rigidez y, entonces, intentar balancear la capacidad efectivamente puede acarrearnos más problemas que beneficios. Pero depende de cómo segmentemos y, sobre todo, de cuánto. Yo no digo que no lo hagamos, sino que pensemos muy bien en los criterios. Unos de los criterios más habituales es el de la especialización por tareas (ventas, marketing, …) y yo pienso que es mejor hacerlo por procesos.
    Saludos,

  4. Estamos de acuerdo.
    Tampoco quería yo decir que no se deba hacer “ningún” esfuerzo por balancear la capacidad.
    Lo que pienso es que no se debe perseguir el balanceo “total”, una cierta cantidad de capacidad “sobrante” es buena como buffer para mantener la estabilidad del sistema. Pero pienso que es imprescindible “reservar” una pequeña cantidad de capacidad para esto. ¿Cuanta?…
    Eso depende del nivel de incertidumbre y variabilidad que tenga el sistema, a mayor incertidumbre mayor necesidad de capacidad sobrante reservada.

Leave a Reply

Your email address will not be published. Required fields are marked *