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