Cómo evolucionó la administración de empresas: de Taylor a la estructura consciente

El problema que sentís es viejo y tiene buena compañía

Si dirigís una empresa de servicios de 15, 30 o 60 personas, probablemente convivas con alguna versión de esto: la operación funciona, el equipo se esfuerza, los problemas se resuelven… pero se resuelven pasando por vos. Aprobás compras, destrabás excepciones comerciales, definís prioridades. Te tomás dos semanas y volvés a trescientos mensajes y tres decisiones congeladas. Si esa escena te resulta familiar, ya la desarmamos en detalle cuando nos preguntamos si tu empresa sigue funcionando cuando te tomás vacaciones.

Lo interesante es que esa tensión no es nueva. Es prácticamente la misma que empujó a la administración de empresas a inventarse a sí misma hace más de un siglo: cómo hacer que una organización siga funcionando bien cuando ya no cabe entera en la cabeza de una persona.

Conocer cómo se respondió esa pregunta en cada etapa sirve para algo muy concreto: la mayoría de las PyMEs tiene, superpuestas y sin haberlo elegido, capas de varias de esas respuestas conviviendo al mismo tiempo. Entender de dónde viene cada una permite decidir cuál usar para qué.

La evolución de la administración de empresas, etapa por etapa

Esto no es una carrera donde cada corredor supera al anterior. Es una secuencia de respuestas bien construidas para preguntas distintas.

1911-1922: Taylor, Fayol y Weber, el desafío era la previsibilidad

Frederick Taylor publicó Principios de la administración científica en 1911, con la idea de que el método de trabajo podía estudiarse y mejorarse en vez de quedar librado a la costumbre. Henri Fayol, en Administración industrial y general (1916), ordenó por primera vez la función de dirigir: prever, organizar, mandar, coordinar y controlar. Max Weber describió la burocracia como una forma de autoridad basada en reglas conocidas y no en el criterio personal del dueño, un avance civilizatorio enorme frente a la arbitrariedad.

Lo que aportaron: el método estandarizado, la jerarquía explícita y la regla impersonal. Una fábrica pudo crecer sin que cada operario inventara su propio procedimiento.

Lo que su contexto no les exigía resolver: trabajaban en organizaciones grandes, estables, de producción repetitiva, donde la información tardaba días en subir y bajar. Concentrar la decisión arriba no era una limitación conceptual: era la única arquitectura posible cuando el dato tardaba en llegar.

1924-1950: la escuela de relaciones humanas, entró en escena la persona

Los estudios realizados en la planta Hawthorne de Western Electric entre 1924 y 1932, y la lectura que hizo de ellos Elton Mayo, instalaron una idea que hasta entonces no tenía lugar: la productividad se mueve también por factores sociales y de grupo, no solo por método y remuneración.

Nota de honestidad intelectual: la evidencia original de Hawthorne fue muy cuestionada. Un reanálisis de los datos de los experimentos de iluminación publicado por Levitt y List en 2011 encontró que los patrones espectaculares que se le atribuyeron durante décadas no aparecen con claridad en los registros originales. La conclusión conceptual, que las personas no son piezas intercambiables, sobrevivió; la evidencia que se cita habitualmente para sostenerla, mucho menos.

Lo que aportó: la organización informal existe y explica cosas que el organigrama no.

Lo que quedó pendiente: la relación entre clima y diseño. Un buen equipo dentro de un flujo mal diseñado se desgasta igual.

1954-1970: Drucker y el enfoque de sistemas, apareció la dirección

Peter Drucker, en La gerencia de empresas (1954), planteó dirigir por objetivos: acordar el resultado en vez de controlar la tarea. En paralelo, la teoría de sistemas trajo una idea que sigue siendo central: la organización es un sistema abierto, y sus partes se explican por sus relaciones, no aisladas.

Lo que aportaron: el foco pasó del cómo hacés la tarea al qué resultado buscamos, y con eso se hizo pensable la delegación.

Lo que quedó pendiente: un objetivo no explica todavía cómo se decide para alcanzarlo. Aparece un fenómeno que sigue vigente: áreas que cumplen sus metas individuales mientras el resultado global se deteriora. Es el mismo mecanismo que analizamos en por qué el problema suele ser el KPI mal elegido y no el mal definido.

1950-1988: Deming, Ishikawa y Toyota, la calidad y el flujo

El ciclo de mejora que hoy conocemos como PDCA nació con Walter Shewhart en los laboratorios Bell en los años 20 y 30. W. Edwards Deming lo modificó y lo llevó a Japón en 1950, invitado por la JUSE; fueron los ingenieros japoneses quienes le dieron la forma Plan-Do-Check-Act que se popularizó. Vale un dato poco conocido: el propio Deming rechazaba esa versión y prefería PDSA (Plan-Do-Study-Act), porque check en inglés sugiere verificar y no comprender. La diferencia no es semántica: es exactamente la distancia entre controlar y aprender.

Kaoru Ishikawa aportó herramientas de análisis de causa accesibles para cualquier operario. Y Toyota, con Taiichi Ohno como figura central, construyó a lo largo de décadas un sistema donde el flujo, la reducción de desperdicio y la mejora desde el piso reemplazaron a la planificación exclusivamente descendente. El término lean llegó bastante después: lo acuñó John Krafcik en un artículo de 1988 en el MIT Sloan Management Review, y se volvió global con The Machine That Changed the World (Womack, Jones y Roos, 1990). Si querés la versión aplicada, escribimos una guía paso a paso para aplicar Lean en un proceso.

Lo que aportaron: la idea, todavía revolucionaria, de que la mayor parte de los errores pertenece al sistema y no a la persona. Y la simplicidad como valor operativo.

Lo que quedó pendiente: el modelo se construyó sobre volumen, repetición y una cultura industrial muy particular. Trasladar las herramientas sin el sistema de pensamiento que las sostiene rinde poco, algo que la propia literatura lean señala desde hace años.

1987-2000: ISO 9001 y la reingeniería, la mirada por procesos

ISO 9001 se publicó por primera vez en 1987, construida sobre la británica BS 5750, en un mundo donde hacía falta un lenguaje común de aseguramiento de la calidad entre empresas de distintos países que no se conocían entre sí. Su primera versión era marcadamente procedimental, organizada en veinte elementos. El enfoque basado en procesos llegó recién con la revisión del año 2000, y el pensamiento basado en riesgos con la de 2015. Hay una nueva revisión prevista para 2026. Sobre cómo se aplica hoy esa mirada en una empresa chica, escribimos gestión por procesos en PyMEs.

En paralelo y desde una lógica casi opuesta, Michael Hammer publicó en 1990 en Harvard Business Review un artículo cuyo título merece leerse dos veces: Reengineering Work: Don’t Automate, Obliterate. Su tesis, ampliada con James Champy en el libro de 1993, era que informatizar un proceso malo solo lo consolida, y que había que rediseñarlo atravesando las áreas.

Lo que aportaron: trazabilidad, responsabilidades explícitas, control de cambios y la visión del trabajo que cruza departamentos.

Lo que quedó pendiente: la reingeniería se convirtió en moda de consultoría a gran escala y sufrió las consecuencias; el propio Thomas Davenport, uno de sus impulsores, escribió después una crítica dura sobre en qué se había transformado. Y en muchas organizaciones la norma se leyó como requisito de auditoría más que como herramienta de diseño.

2004-2015: BPM y agilidad, el proceso como algo vivo

BPMN nació como notación en 2004 en el seno de BPMI, pasó a la órbita de OMG en 2005 y llegó a su versión 2.0 en 2011, publicada como norma internacional ISO/IEC 19510 en 2013. Detrás de la notación, la disciplina BPM aportó algo más importante que los símbolos: la idea de ciclo de vida. Un proceso no se dibuja una vez; se diseña, se ejecuta, se monitorea, se mejora y se gobierna. El mundo ágil, desde el desarrollo de software, sumó iteración corta y equipos con autonomía real. Sobre por qué conviene graficar antes de tocar cualquier herramienta, está este artículo sobre BPMN.

Lo que aportaron: el proceso dejó de ser una foto colgada en la pared.

Lo que quedó pendiente: la autonomía necesita reglas explícitas para no degradarse en criterio individual, y ese diseño de reglas quedó, en general, fuera del alcance de ambas corrientes.

2015 a hoy: digitalización, no-code e inteligencia artificial

Software de gestión accesible, automatizaciones sin programar, asistentes de IA. Por primera vez una empresa de doce personas accede a capacidades que hace veinte años eran de corporación.

Lo que aporta: el costo de ejecutar cayó a una fracción de lo que era.

La tensión nueva que introduce: cuando ejecutar es barato, la tentación es ejecutar antes de diseñar. Y un proceso automatizado sin diseñar no se corrige, se acelera y se vuelve menos visible. Es, curiosamente, la misma advertencia que hacía Hammer en 1990. La diferencia es que hoy cualquiera puede automatizar un martes a la tarde. Dónde conviene dejar una persona decidiendo lo discutimos en human in the loop.

Lo que cambió en las condiciones (y por qué eso mueve el foco)

Poner las etapas en fila muestra algo que no es un reproche sino una constatación: casi todas se ocuparon con enorme profundidad de cómo se ejecuta el trabajo, y ese era el problema correcto para su contexto. Con información lenta, mercados estables y organizaciones grandes, diseñar la ejecución era donde estaba el valor.

Hoy las condiciones de una PyME en crecimiento son otras:

• La información está disponible en el momento, no a fin de mes.
• Los equipos son chicos, mixtos y muchas veces distribuidos.
• El contexto cambia más rápido de lo que se actualiza un procedimiento.
• Ejecutar dejó de ser caro.

Cuando ejecutar es barato y la información es inmediata, el cuello de botella se corre. Ya no está en la tarea: está en el momento en que aparece una situación concreta y alguien tiene que definir quién decide, con qué información, dentro de qué límites, y qué pasa cuando la situación se sale de esos límites.

Por eso es tan común encontrar empresas ordenadas, con procedimientos, tablero y software, donde el dueño sigue siendo el punto de paso obligado. No les falta método. Les falta diseñada la parte que ninguna etapa anterior necesitó diseñar con este nivel de detalle.

Qué es una estructura consciente

Es una organización capaz de tres cosas, y las tres se pueden verificar con evidencia:

No reemplaza a nada de lo anterior. Al contrario: lo ordena. SIPOC para comprender, BPMN para modelar, SMART para medir, ISO 9001 para dar trazabilidad, BPM para gestionar el ciclo, Lean para simplificar después de haber diseñado. Cada herramienta en la etapa donde rinde, ninguna como identidad.

En MetrikPro trabajamos con una secuencia que ordena ese uso: eliminar, simplificar, estandarizar, automatizar. La idea de fondo no es original nuestra y conviene decirlo: es hija directa de aquel no automatices, rediseñá de 1990. Lo que cambió es la urgencia, porque ahora automatizar está a un clic.

Y cambia el rol de quien dirige. La estructura consciente no busca sacar al dueño del sistema: le cambia la función. Deja de estar dentro de la máquina resolviendo cada caso y pasa a trabajar sobre la máquina, definiendo dirección, reglas, límites, autoridad y mecanismos de aprendizaje.

De ahí sale el criterio más útil de todo el enfoque, y también el más incómodo: si todos cumplieron las reglas y el resultado igual fue malo, el problema no es de las personas. Es de diseño. Deming lo venía diciendo desde 1950.

Caso hipotético: la distribuidora que aprobaba todo

Caso ilustrativo construido con fines didácticos. No corresponde a un cliente real.

Una distribuidora de insumos gastronómicos, 26 personas, tres años de crecimiento sostenido. El dueño aprueba el 100% de las órdenes de compra y todos los descuentos por encima de lista. Su diagnóstico inicial: necesito un ERP.

Antes de comprar nada, registraron durante tres semanas cada decisión que subía hasta él. Resultado: 214 decisiones escaladas, de las cuales 187 (87%) se aprobaron exactamente como venían propuestas. No estaba decidiendo. Estaba firmando.

Diseñaron reglas y límites explícitos:

• Compras a proveedor homologado hasta $800.000: decide el jefe de depósito, con stock y orden de compra como evidencia.
• Descuento de hasta 8%: decide el vendedor.
• Descuento entre 8% y 15%: decide el jefe comercial, con el margen del pedido a la vista.
• Descuento mayor a 15%, proveedor nuevo o compra fuera de plan: escala al dueño.

A los 90 días: los escalamientos bajaron de 214 a 31 cada tres semanas (-85%), el tiempo promedio de aprobación de una compra pasó de 2,4 días a 4 horas, y aparecieron 3 rupturas de regla. Esas tres fueron lo más valioso: dos revelaron que el umbral de $800.000 había quedado desactualizado por inflación, y una expuso un cliente mal calificado.

El ERP se compró seis meses después. Pero ya sabían qué reglas cargarle.

Cómo aplicarlo esta semana, paso a paso

No hace falta un proyecto de tres meses. Empezá por un solo punto de decisión.

1. Elegí una decisión real y recurrente que pase por vos. Compras, descuentos, excepciones de entrega, prioridad de trabajos. Si no sabés cuál, empezá por detectar el cuello de botella.
2. Medí una semana. Cuántas veces te llegó, cuánto tardaste y, el número clave, en cuántas cambiaste algo respecto de lo propuesto.
3. Contestá diez preguntas: objetivo de la decisión, quién decide (el rol, no la persona), con qué autoridad, con qué información, bajo qué reglas, qué riesgo mitiga, qué alternativas tiene, qué evidencia debe quedar, quién recibe el resultado y cómo sabemos si fue buena.
4. Escribí la regla y el umbral. Un número, no un adjetivo. Hasta X monto, no compras chicas.
5. Definí la excepción. Qué obliga a escalar aunque el monto esté dentro de la regla: proveedor nuevo, cliente moroso, plazo crítico, riesgo reputacional.
6. Definí un control por excepción. Una vez por mes: total de decisiones, cuántas dentro de regla, cuántas escaladas correctamente, cuántas la rompieron y por qué. Nada más.
7. Revisá a los 60 días. Si nadie escaló nunca, el umbral está alto. Si escalan todo, está bajo o falta información.

El error más común: automatizar antes de decidir

El error clásico es entrar por la herramienta. Comprar el software, contratar la automatización, poner el bot. Y el problema no es la herramienta: es que se está automatizando una decisión que nunca se definió. Sobre esto tenemos una guía específica de qué hacer antes de implementar un sistema nuevo.

Hay un segundo error, más sutil y más caro: confundir robustez con complejidad. Empresas que reaccionan al desorden con cuarenta procedimientos, doce formularios y cuatro niveles de aprobación. Terminan con un sistema tan pesado que la gente lo esquiva por WhatsApp para poder trabajar.

La regla es la contraria, y acá Lean tiene la última palabra: tan sólido como sea necesario y tan simple como sea posible. Primero se diseña para que sea claro y trazable. Después se lo revisa para sacar todo lo que no aporte control real, aprendizaje o valor.

Conclusión

Ciento quince años de administración de empresas produjeron un repertorio extraordinario de herramientas. Ninguna de ellas está equivocada; cada una responde bien a la pregunta para la que fue construida.

Lo que conviene revisar es cuál de esas preguntas es hoy la tuya. Porque una empresa puede tener procedimientos, tablero, software y certificación, y seguir dependiendo de que una persona esté disponible para decidir. La madurez organizacional no está en la cantidad de estructura acumulada: está en la capacidad de observarse, entender por qué se obtiene lo que se obtiene y modificar el propio diseño cuando deja de funcionar.

La pregunta con la que conviene cerrar no es qué me falta implementar. Es más simple: si mañana no estuvieras disponible durante dos semanas, ¿cuántas decisiones se detendrían, y qué le falta a tu sistema para que no se detengan?

Preguntas frecuentes

Fuentes de las referencias históricas: F. W. Taylor, The Principles of Scientific Management (1911); H. Fayol, Administration Industrielle et Générale (1916); estudios Hawthorne 1924-1932 y el reanálisis de Levitt y List, American Economic Journal: Applied Economics 3(1), 2011; P. Drucker, The Practice of Management (1954); R. Moen, Foundation and History of the PDSA Cycle (Deming Institute); J. Krafcik, “Triumph of the Lean Production System”, MIT Sloan Management Review, 1988; Womack, Jones y Roos, The Machine That Changed the World (1990); M. Hammer, “Reengineering Work: Don’t Automate, Obliterate”, Harvard Business Review, julio-agosto 1990; Hammer y Champy, Reengineering the Corporation (1993); historial de revisiones de ISO 9001 (ASQ / ISO); especificación BPMN de OMG e ISO/IEC 19510:2013.