Operaciones y procesosGrowth Transformation
Lo que hoy hace funcionar tu empresa puede ser lo que mañana le impida escalar
Los procesos que sostienen una etapa de crecimiento no siempre sostienen la siguiente. Qué revisar antes de que se conviertan en un límite.
La empresa vende más que nunca. Incorporó personas, sumó un CRM, contrató una herramienta de gestión de proyectos y empezó a usar inteligencia artificial. Sin embargo, los plazos de entrega se alargan, las aprobaciones se acumulan en la bandeja de dos o tres directivos y los equipos parecen cada vez más ocupados sin que el trabajo salga más rápido. Nadie está trabajando menos. El problema no es de esfuerzo.
Es de diseño. Las prácticas que permitieron crecer (decidir rápido desde arriba, coordinar con una conversación, resolver con una planilla, tener a todos al máximo de su capacidad) funcionaban bajo ciertas condiciones de tamaño, volumen y variedad. Cuando esas condiciones cambian, algunas de esas prácticas dejan de ser una ventaja y pasan a ser el límite. No porque estuvieran mal, sino porque su costo crece más rápido que la operación.
Una empresa puede volverse menos eficiente justamente cuando empieza a crecer, sin que nadie haya hecho nada mal.
Ideas clave
- Crecer es aumentar volumen; escalar es aumentarlo sin que el costo, el plazo y la calidad se deterioren en la misma proporción o más.
- Algunos costos crecen más rápido que el volumen: los canales de coordinación, los tiempos de espera cerca de la capacidad máxima y la carga de decisiones sobre pocas personas.
- El desempeño de una operación está limitado por su restricción. Mejorar una etapa que no es la restricción no mejora el resultado del sistema.
- El objetivo no es tener más ni menos procesos, sino estructura que habilite el trabajo en vez de solo controlarlo.
- Automatizar una etapa antes de la restricción puede aumentar el trabajo acumulado en lugar de aumentar la capacidad.
- La evidencia disponible sugiere que la IA amplifica el sistema donde se instala: rinde más cuando se rediseña el trabajo y menos cuando se agrega sobre procesos sin revisar.
Crecer no es escalar
Conviene separar conceptos que suelen usarse como sinónimos. La eficiencia es la relación entre los recursos usados y el resultado obtenido. La productividad, la relación entre lo que se produce y lo que se consume para producirlo. La capacidad, el volumen que una operación puede procesar o entregar bajo determinadas condiciones. La resiliencia, su capacidad de absorber perturbaciones y recuperarse. Y la escalabilidad, la capacidad de un sistema para responder a más demanda o más alcance manteniendo niveles aceptables de desempeño, calidad y economía.
Un proceso puede ser eficiente y no ser escalable. Ocurre cuando su eficiencia depende de condiciones que el crecimiento modifica: pocas personas que se conocen, poca variedad de casos, un volumen que deja margen de capacidad, alguien que concentra el conocimiento y decide en el momento. En esas condiciones, la informalidad es barata y rápida. Al cambiar las condiciones, el mismo proceso puede volverse lento y costoso sin que nadie lo haya modificado.
La razón de fondo es que algunos costos no crecen en proporción al volumen. Frederick Brooks lo observó en proyectos de software: si cada persona tiene que coordinarse con todas las demás, los canales de comunicación crecen según la fórmula n(n−1)/2.4 Cinco personas tienen 10 canales posibles; quince, 105; cincuenta, 1.225. No todas las organizaciones necesitan que todos se coordinen con todos, y por eso existen estructuras y procesos. Pero la cifra muestra por qué la coordinación informal que funcionaba con un equipo pequeño no escala sola. Algo parecido ocurre con los tiempos de espera cuando un recurso se acerca al límite de su capacidad, como veremos más adelante.
Panel 1: Brooks (1975). Panel 2: resultado clásico de teoría de colas para una cola simple con llegadas y tiempos de atención aleatorios (M/M/1), donde la espera media es ρ/(1−ρ) veces el tiempo de atención. Operaciones reales tienen otros supuestos; la forma de la curva es lo relevante. Elaboración: Advisent®.
El problema de multiplicar lo que funciona
Robert Sutton y Hayagreeva Rao, de la Universidad de Stanford, estudiaron durante años cómo distintas organizaciones intentaban extender prácticas excelentes de un grupo pequeño a muchos más. Llamaron a ese desafío the problem of more: llevar lo que funciona a más personas y lugares sin degradarlo en el camino.1 Su conclusión central es que multiplicar una práctica no garantiza multiplicar sus resultados. Una metodología que funciona con cinco personas puede necesitar cambios para funcionar con cincuenta; un proceso de entrega diseñado para diez clientes puede dejar de ser viable con cien.
Los autores plantean una tensión que toda empresa en crecimiento enfrenta. Por un lado, replicar con precisión lo que funciona, una lógica que llaman catolicismo. Por otro, transmitir una forma de pensar y permitir que cada equipo la adapte a su contexto, que llaman budismo. Ninguna opción es superior en abstracto. Una operación financiera regulada puede necesitar controles idénticos en todas partes; un proceso creativo o de diseño de soluciones puede necesitar margen para adaptarse. El error es aplicar el mismo grado de estandarización a todo.
Sutton y Rao agregan dos advertencias útiles. La primera es que el crecimiento suma personas, reglas, herramientas e interacciones, y con ellas carga cognitiva: llega un punto en que la gente pierde capacidad para concentrarse y decidir bien. La segunda es que mejorar no siempre consiste en agregar. A veces exige quitar: reglas, reuniones, pasos o herramientas que ya no aportan. Rao lo resumió con una recomendación práctica: antes de agregar una reunión nueva, eliminar una existente.24
Pero hay un límite que su trabajo no resuelve por sí solo: una empresa puede replicar con éxito un proceso que ya no es adecuado para su nueva escala. Replicar lo que funcionó no garantiza que siga funcionando cuando cambian las condiciones. Para eso hace falta otra pregunta.
Cuando mejorar una parte no mejora el sistema
Esa pregunta la planteó Eliyahu Goldratt en The Goal, la novela de gestión que escribió con Jeff Cox y que dio origen a la teoría de las restricciones.2 Su idea central es simple y exigente a la vez: el desempeño de un sistema está limitado por una o pocas restricciones. Una hora ganada en la restricción es una hora ganada para todo el sistema; una hora ganada en cualquier otra parte no cambia el resultado global. Mejorar todas las áreas por igual no mejora la empresa por igual.
Goldratt formuló cinco pasos para gestionar ese límite: identificar la restricción del sistema, decidir cómo aprovecharla al máximo, subordinar todo lo demás a esa decisión, elevar su capacidad y, cuando la restricción se rompe, volver a empezar sin dejar que la inercia se convierta en la nueva restricción.3 El último paso es el más olvidado: al resolver un cuello de botella, el límite se desplaza a otra parte. Una empresa que amplía su capacidad comercial puede descubrir que el límite pasó a delivery; cuando resuelve delivery, puede aparecer en facturación o en la capacidad de supervisión.
La teoría usa términos propios que conviene no confundir. El throughput es la velocidad a la que el sistema genera dinero a través de las ventas, no la cantidad de unidades procesadas ni la utilización de los recursos. El inventario es el dinero invertido en cosas que el sistema pretende vender, una definición económica distinta del trabajo en curso que usan Lean o Kanban. Y el gasto operativo es el dinero que se gasta para convertir inventario en throughput. La consecuencia práctica es que un indicador local (productividad de un área, horas facturadas, propuestas enviadas) puede mejorar mientras el resultado del sistema empeora.
Combinadas, las dos perspectivas producen la tensión central de este artículo, que es una interpretación de Advisent® y no de sus autores: replicar no siempre es escalar, optimizar no siempre es mejorar, y aumentar la capacidad de una parte no siempre aumenta la capacidad del todo.
El costo invisible de coordinar una organización más grande
Una parte creciente del trabajo de una empresa que crece no produce nada para el cliente: existe para coordinar otro trabajo. Reuniones de seguimiento, actualizaciones de estado, aprobaciones, traspasos entre áreas, conciliación de información entre sistemas. Nada de eso es inútil en sí mismo, pero su volumen crece con las interdependencias, no con las ventas.
La teoría de la organización explica por qué. James Thompson distinguió tres tipos de interdependencia: compartida, cuando las unidades usan recursos comunes; secuencial, cuando el trabajo de una alimenta a la siguiente; y recíproca, cuando se alimentan mutuamente. Cada una se coordina de una manera distinta (con reglas y estándares, con planificación o con ajuste mutuo), y cada una es más costosa que la anterior.9 Jay Galbraith agregó que cuanto mayor es la incertidumbre de una tarea, más información hay que procesar para coordinarla, y que la organización tiene dos caminos: reducir esa necesidad (con unidades más autónomas o con holguras) o aumentar su capacidad de procesarla (con sistemas de información o relaciones laterales entre áreas).8 Detrás de ambos está Herbert Simon: las personas tienen una capacidad limitada para procesar información y decidir.7
El problema se agrava porque tendemos a subestimarlo. Chip Heath y Nancy Staudenmayer llamaron coordination neglect a la tendencia a dividir el trabajo con cuidado y a pensar mucho menos en cómo volver a integrarlo: se subestiman las interdependencias y se comunica de menos entre las partes.10 Una empresa que crece dividiendo equipos y especializando funciones, sin rediseñar cómo se integran, acumula fricción sin saberlo.
¿Qué proporción del trabajo de nuestros equipos crea valor para el cliente y qué proporción existe solo para coordinar otro trabajo?
Ni más procesos ni menos procesos: estructura que habilita
Una organización con poco proceso depende de la improvisación, del conocimiento tácito y de unas pocas personas: los errores se repiten, el retrabajo es habitual y nadie sabe exactamente cómo se hizo algo la última vez. Una organización con demasiado proceso sufre lo contrario: aprobaciones redundantes, documentación que nadie usa, controles superpuestos y decisiones que tardan semanas. Ambos extremos reducen la capacidad. La pregunta no es cuántos procesos tener, sino qué tipo de estructura.
Paul Adler y Bryan Borys propusieron una distinción que sigue siendo útil: la burocracia puede ser habilitante, cuando los procedimientos ayudan a las personas a hacer bien su trabajo y a resolver problemas, o coercitiva, cuando existen principalmente para controlarlas.11 El mismo manual de procedimientos puede ser una cosa o la otra según cómo se diseñe y se use. Y la evidencia muestra que la estandarización no es necesariamente enemiga de la flexibilidad: Adler, Barbara Goldoftas y David Levine estudiaron cómo una planta de Toyota lograba ser eficiente y, a la vez, flexible ante cambios de modelo, gracias a rutinas diseñadas precisamente para gestionar lo no rutinario.12
De ahí se desprenden criterios para decidir qué estandarizar. Tiene sentido cuando la actividad es repetible, cuando la variabilidad genera errores costosos, cuando hay requisitos regulatorios, cuando el impacto en el cliente es alto o cuando se necesita capacitar a muchas personas. Tiene menos sentido cuando la tarea exige criterio, cuando cada caso es distinto o cuando la adaptación es parte del valor que se entrega. Estandarizar lo que requiere juicio produce rigidez; dejar librado al juicio lo que debería ser estándar produce errores.
Los procesos también acumulan deuda
Buena parte de la complejidad de una empresa no fue diseñada: se acumuló. Una planilla paralela que alguien creó para resolver un problema puntual y que nunca se reemplazó. Una aprobación adicional agregada después de un error y que nadie revisó. Dos sistemas que no se hablan y una persona que copia datos de uno a otro. Una excepción que se volvió la forma habitual de trabajar. Una reunión semanal que existe porque el proceso no funciona. Cada solución tuvo sentido en su momento; el conjunto, no necesariamente.
En ingeniería de software, Antonio Martini y sus colegas propusieron el concepto de deuda de procesos, por analogía con la deuda técnica: atajos que generan un beneficio inmediato y un costo que se paga más adelante, con intereses.14 La expresión no tiene una definición académica establecida fuera de ese campo, pero la analogía describe bien lo que ocurre en muchas operaciones: los atajos se acumulan, interactúan entre sí y terminan siendo más costosos que el problema que resolvían.
La minería de procesos (process mining) ofrece una forma de verlo con datos. A partir de los registros de eventos que dejan los sistemas, reconstruye cómo fluye realmente el trabajo, no cómo dice el manual que fluye: cuántas variantes tiene un proceso, dónde se repiten pasos, dónde esperan los casos.15 No reemplaza el criterio de quienes conocen la operación, y requiere sistemas que registren eventos, pero suele revelar la distancia entre el proceso diseñado y el proceso real.
¿Qué parte de nuestra complejidad operativa fue diseñada y qué parte simplemente se acumuló?
El cuello de botella suele tener nombre propio
Un ejemplo hipotético, frecuente en empresas de servicios, muestra cómo se mueve la restricción. Con diez clientes, el fundador aprueba presupuestos, asigna tareas y revisa cada entregable. Funciona bien: decide rápido, conoce a cada cliente y garantiza la calidad. Con cuarenta clientes aparecen las primeras demoras; hay más proyectos, más revisiones y más reuniones, y las decisiones empiezan a esperar. Con cien clientes, la cantidad de decisiones supera lo que una persona puede procesar. Los equipos esperan aprobaciones, se acumula trabajo en curso, se alargan los plazos. La empresa contrata más personas, pero el cuello de botella sigue en el mismo lugar.
La pregunta deja de ser cuántas personas más hacen falta y pasa a ser qué parte del sistema limita la capacidad. En este caso, la restricción no es la cantidad de gente, sino la arquitectura de decisiones. La respuesta tampoco es delegar todo. Algunas decisiones deben seguir centralizadas, porque su riesgo o su impacto lo justifican. Lo que cambia es el diseño: qué decisiones se toman en cada nivel, con qué criterios, qué casos se resuelven con un procedimiento estándar, qué excepciones se escalan y cuándo, y quién responde por el resultado. Distribuir decisiones sin criterios explícitos produce inconsistencia; centralizarlas todas produce colas.
Es también una cuestión de supervivencia del modelo. En América Latina, donde según la CEPAL las grandes empresas llegan a ser hasta 33 veces más productivas que las microempresas (frente a una brecha de entre 1,3 y 2,4 veces en los países de la OCDE), buena parte de esa distancia se juega en la capacidad de pasar de una operación que depende de personas a una que depende de sistemas.25 Es una interpretación de Advisent®: la brecha tiene muchas causas, pero la dependencia del fundador es una de las más frecuentes en empresas que intentan crecer.
La trampa del 100% de utilización
En muchas empresas de servicios, tener a todos ocupados al máximo parece la definición de eficiencia: cada hora no facturada es una pérdida. La teoría de colas sugiere que operar demasiado cerca del límite de capacidad tiene un costo que no aparece en el reporte de utilización. La ley de Little establece que, en un sistema estable, el trabajo acumulado es igual a la tasa de llegada multiplicada por el tiempo promedio que cada unidad pasa en el sistema.5 Si entra más trabajo del que se termina, o si se acumulan proyectos en curso con la misma capacidad, los plazos se alargan.
John Kingman mostró además que, cuando la utilización de un recurso se acerca al 100%, los tiempos de espera crecen de forma no lineal.6 En el caso más simple, con llegadas y tiempos de atención aleatorios, pasar del 70% al 95% de utilización multiplica la espera promedio por más de ocho. Las operaciones reales no siguen exactamente esos supuestos, pero la forma de la curva se mantiene: con variabilidad, cerca del máximo, cualquier urgencia, error o pedido inesperado genera una cola. Donald Reinertsen lo aplicó al desarrollo de productos: las colas son uno de los costos ocultos más grandes, porque no se ven en el balance pero retrasan todo lo demás.16
Esto no significa que la utilización deba ser baja. Significa que la holgura tiene valor económico, especialmente en la restricción y en entornos variables. Un equipo de delivery al 100% factura todas sus horas y, al mismo tiempo, entrega más tarde, absorbe peor las urgencias y tiene menos espacio para corregir errores. La pregunta no es cuál es la utilización máxima posible, sino cuál es la utilización que permite cumplir plazos y calidad con la variabilidad real de la operación.
Un equipo al 100% de su capacidad puede facturar todas sus horas y, al mismo tiempo, entregar cada vez más tarde.
Automatizar una etapa puede trasladar el problema
Michael Hammer lo planteó en 1990 con una consigna que sigue vigente: no automatizar, eliminar.13 Automatizar un proceso mal diseñado produce el mismo proceso, más rápido. La teoría de las restricciones agrega una consecuencia menos evidente: automatizar una etapa que no es la restricción puede empeorar el sistema.
Un ejemplo hipotético lo muestra. Una empresa automatiza la generación de propuestas comerciales y pasa de preparar doce por semana a preparar treinta. Pero el área legal sigue revisando ocho, operaciones tarda lo mismo en asignar recursos y el fundador sigue aprobando cada contrato. La empresa no cierra más contratos: acumula más propuestas en espera, más seguimientos, más presión sobre legal y más clientes que esperan respuesta. La automatización aumentó el flujo hacia la restricción, no la capacidad del sistema.
Ejemplo hipotético; capacidades por semana. La restricción (revisión legal) determina el resultado del sistema. En una empresa de productos, la misma lógica aparece cuando se acelera la toma de pedidos sin ampliar producción, despacho o atención posventa. Fuente: Advisent®.
La evidencia sobre inteligencia artificial apunta en una dirección similar. En la encuesta de McKinsey a 1.000 ejecutivos de empresas con ingresos de al menos USD 500 millones, casi el 90% decía estar al menos experimentando con IA, pero solo el 7% reportaba haberla escalado en toda la organización. Las empresas con mayor madurez en excelencia operacional mostraban más del triple de retorno sobre el capital invertido a tres años que las menos maduras, una correlación que la propia consultora aclara que no demuestra causalidad.17 En su encuesta sobre el estado de la IA de 2026, el 80% de los participantes declaró mejoras de productividad individual, pero solo el 37% atribuyó a la IA algún impacto en el EBIT; casi tres cuartas partes de las empresas de mejor desempeño habían rediseñado sustancialmente sus flujos de trabajo, frente a una cuarta parte del resto.18 La productividad de una persona no se convierte automáticamente en capacidad del sistema.
Los resultados, además, son heterogéneos. En una encuesta de McKinsey a 334 líderes de desarrollo de producto e ingeniería, solo el 25% de los directivos reportó una aceleración significativa y el 30% dijo que la productividad de su equipo había caído; los equipos que rediseñaron sus procesos antes de incorporar IA tenían más del doble de probabilidad de reportar ganancias superiores al 20%.19 El informe DORA sobre equipos de software describió la IA como un amplificador de las fortalezas y las disfunciones que la organización ya tiene.20 Son datos del desarrollo de software, que no se trasladan directamente a toda la operación, pero ilustran el punto: la tecnología rinde según el sistema donde se instala.
La distinción entre tecnologías también importa. Digitalizar es representar información en formato digital. Automatizar es ejecutar tareas mediante reglas. La automatización robótica de procesos (RPA) ejecuta tareas repetitivas con datos estructurados, a menudo sobre interfaces existentes. La IA que asiste a personas mejora su trabajo sin reemplazar su criterio. Y los agentes de IA pueden planificar y ejecutar acciones dentro de límites definidos, con supervisión humana.22 Cuantos más agentes se incorporan, más importa la orquestación y el gobierno: quién los coordina, con qué permisos y quién responde por sus decisiones.23 Gartner predice que más del 40% de los proyectos de IA agéntica se cancelará antes de fines de 2027, por costos crecientes, valor poco claro o controles de riesgo insuficientes.21 La IA puede eliminar restricciones; también puede crear otras nuevas, como la revisión de sus resultados o la integración entre sistemas.
En la región, la adopción todavía es mayormente superficial. En España, el 21,1% de las empresas con diez o más empleados usaba IA en 2025, según el INE.26 En Chile, un estudio encargado por AWS encontró que el 45% de las empresas la usa, pero que el 58% de ellas lo hace solo con herramientas básicas y que apenas el 14% confía en poder medir su retorno.27 Usar IA y rediseñar la operación con IA no son lo mismo.
Empresas de productos y de servicios: restricciones diferentes
Las operaciones no son solo fábricas. Las empresas de servicios también tienen operaciones, aunque sus restricciones suelen estar en lugares menos visibles: en las personas que concentran conocimiento, en la capacidad de revisión, en la asignación de equipos o en las decisiones que esperan aprobación. La tabla resume diferencias frecuentes, que no son reglas universales.
| Dimensión | Empresas de productos | Empresas de servicios | Pregunta de escala |
|---|---|---|---|
| Capacidad | Producción, abastecimiento y logística | Horas de personas con conocimiento específico | ¿Qué recurso limita lo que podemos entregar? |
| Inventario y trabajo en curso | Stock, materiales y pedidos pendientes | Proyectos abiertos, propuestas y revisiones pendientes | ¿Cuánto trabajo empezado está esperando? |
| Variabilidad | Demanda, proveedores y calidad | Alcance, pedidos de cambio y cada cliente distinto | ¿Cuántas excepciones absorbe el proceso? |
| Conocimiento | Incorporado en el producto y la planta | Concentrado en personas clave | ¿Qué pasa si falta una persona? |
| Costo marginal | Tiende a bajar con el volumen | Puede crecer casi en proporción a cada cliente | ¿Cada cliente nuevo exige proporcionalmente más horas? |
| Calidad | Control estadístico y especificaciones | Revisión de entregables y criterio profesional | ¿La revisión depende de pocas personas? |
| Automatización | Planificación, inventario, despacho | Propuestas, informes, asignación, facturación | ¿Estamos automatizando la restricción o antes de ella? |
En servicios profesionales, la pregunta de fondo es qué ocurre cuando cada cliente nuevo exige proporcionalmente más horas de trabajo. Las respuestas habituales (estandarizar partes del delivery, convertir servicios en ofertas definidas, crear servicios compartidos, usar IA para preparar y revisar) pueden reducir esa dependencia, pero no todas aplican a todos los servicios. Productizar lo que en realidad requiere criterio puede destruir el valor que el cliente compraba. El objetivo no es eliminar la personalización, sino separar lo que debe ser personalizado de lo que solo se repite. Cómo se conecta esto con el sistema comercial lo desarrollamos en nuestro artículo sobre rentabilidad de la relación comercial, y su relación con la expansión a nuevos mercados en el costo de crecer sin estrategia.
Qué revisar antes de la siguiente etapa de crecimiento
Para ordenar ese diagnóstico proponemos dos herramientas conceptuales de Advisent®. No son modelos académicos validados, sino formas estructuradas de hacer las preguntas correctas. La primera, The Scalability Stress Test by Advisent®, evalúa si un proceso puede soportar la siguiente etapa a partir de seis dimensiones observables.
Framework conceptual de Advisent®, no un modelo validado. Cualquier puntuación (por ejemplo, un semáforo por dimensión) es ilustrativa y debe construirse con datos de la propia operación. Fuente: Advisent®.
La segunda, The Process Redesign Decision by Advisent®, ordena qué hacer con un proceso. No es una secuencia lineal. Empieza siempre por identificar la restricción, sigue por preguntarse si el proceso debe existir y, recién entonces, elige un camino según el tipo de problema.
Framework conceptual de Advisent®, no un modelo validado. Regla central: no automatizar antes de la restricción, porque solo aumenta el trabajo que espera frente a ella. Fuente: Advisent®.
Ninguna de las dos herramientas resuelve por sí misma los contraargumentos que conviene tener presentes. Algunas organizaciones escalan con éxito replicando con precisión un modelo probado. La estandarización puede ser una ventaja competitiva. Cierta burocracia reduce riesgos, y algunas decisiones críticas deben seguir centralizadas. A veces la restricción se resuelve simplemente agregando capacidad, y no todo exige un rediseño profundo. Y en operaciones con alta incertidumbre, la resiliencia puede valer más que la eficiencia. El criterio no es rediseñar todo, sino saber qué conservar, qué cambiar y qué no tocar.
Lo que permitió llegar hasta aquí
Las organizaciones son sistemas. Cuando crecen, cambian sus restricciones: lo que limitaba a una empresa de diez personas no es lo que limita a una de cien. Las prácticas que fueron eficientes en una etapa (la decisión centralizada, la coordinación informal, la utilización máxima, la planilla que resolvía todo) no fallan porque fueran malas, sino porque su costo crece más rápido que la operación. Agregar personas, herramientas o automatización sin identificar dónde está el límite suele producir más actividad, no más capacidad.
Escalar exige decidir cómo deben evolucionar los procesos, la capacidad, las decisiones, la coordinación, la estructura, las personas, la tecnología y la economía de la operación. Y exige, sobre todo, una pregunta incómoda para cualquier equipo que tuvo éxito: qué de lo que nos trajo hasta aquí ya no nos sirve para lo que sigue.
¿Está nuestra empresa diseñada para la escala que queremos alcanzar, o todavía funciona con los mecanismos que nos permitieron llegar hasta aquí?
La siguiente etapa de crecimiento no siempre exige hacer más de lo mismo. A veces exige dejar de hacer lo que funcionó.
Preguntas frecuentes sobre cómo escalar una empresa
¿Cuál es la diferencia entre crecer y escalar?
Crecer es aumentar el volumen de ventas, clientes u operaciones. Escalar es aumentarlo sin que el costo, los plazos y la calidad se deterioren en la misma proporción o más. Una empresa puede crecer y volverse menos eficiente al mismo tiempo, cuando algunos costos (coordinación, esperas, decisiones concentradas) crecen más rápido que el volumen.
¿Qué es un cuello de botella en una empresa?
Un cuello de botella es la etapa, el recurso o la persona que limita el flujo de todo el sistema. Puede ser un área operativa, una revisión, un sistema o un directivo que concentra aprobaciones. Mejorar cualquier otra etapa no aumenta el resultado global mientras la restricción siga en el mismo lugar; al resolverla, el límite suele desplazarse a otra parte.
¿Qué es la teoría de las restricciones?
Es un enfoque de gestión desarrollado por Eliyahu Goldratt, popularizado en la novela The Goal (1984), según el cual el desempeño de un sistema está limitado por una o pocas restricciones. Propone cinco pasos: identificar la restricción, decidir cómo aprovecharla, subordinar todo lo demás a esa decisión, elevar su capacidad y, cuando se rompe, volver a empezar sin dejar que la inercia se convierta en la nueva restricción.
¿Cuándo conviene estandarizar un proceso?
Conviene estandarizar cuando la actividad es repetible, cuando la variabilidad genera errores costosos, cuando hay requisitos regulatorios, cuando el impacto en el cliente es alto o cuando hay que capacitar a muchas personas. Conviene menos cuando la tarea exige criterio, cuando cada caso es distinto o cuando la adaptación forma parte del valor que se entrega.
¿Cómo saber si una empresa tiene demasiada burocracia?
Algunas señales son aprobaciones que no cambian decisiones, controles superpuestos, documentación que nadie usa, reuniones que reemplazan procesos y decisiones simples que tardan semanas. La distinción útil, propuesta por Adler y Borys, es entre burocracia habilitante, que ayuda a las personas a hacer bien su trabajo, y coercitiva, que existe principalmente para controlarlas.
¿Qué procesos conviene automatizar?
Conviene automatizar tareas repetibles, basadas en reglas y con datos estructurados, preferentemente en la restricción del sistema o después de ella. Automatizar una etapa anterior a la restricción puede aumentar el trabajo acumulado sin aumentar la capacidad. Antes de automatizar conviene preguntarse si la actividad debe existir y si puede simplificarse.
¿Qué es process mining?
Process mining, o minería de procesos, es un conjunto de técnicas que analizan los registros de eventos de los sistemas de una empresa para reconstruir cómo fluye realmente el trabajo. Permite ver variantes de un proceso, pasos repetidos y tiempos de espera, y comparar el proceso real con el diseñado. Requiere sistemas que registren eventos y no reemplaza el conocimiento de quienes operan el proceso.
¿Cómo escalar una empresa de servicios?
Escalar una empresa de servicios suele exigir reducir la dependencia de que cada cliente nuevo requiera proporcionalmente más horas de personas clave. Las palancas habituales son distribuir decisiones con criterios claros, estandarizar lo que se repite, separarlo de lo que requiere criterio, evitar operar al 100% de utilización, gestionar el trabajo en curso y usar IA para preparar y revisar. No todos los servicios deben productizarse.
Fuentes y lecturas
Fundamentos académicos
- Sutton, R. I. y Rao, H. (2014). Scaling up excellence: Getting to more without settling for less. Crown Business.
- Goldratt, E. M. y Cox, J. (2014). The goal: A process of ongoing improvement (ed. 30.º aniversario). North River Press. (Obra original publicada en 1984).
- Goldratt, E. M. (1990). What is this thing called theory of constraints and how should it be implemented? North River Press.
- Brooks, F. P., Jr. (1975). The mythical man-month: Essays on software engineering. Addison-Wesley.
- Little, J. D. C. (1961). A proof for the queuing formula: L = λW. Operations Research, 9(3), 383–387. doi.org/10.1287/opre.9.3.383
- Kingman, J. F. C. (1961). The single server queue in heavy traffic. Mathematical Proceedings of the Cambridge Philosophical Society, 57(4), 902–904. doi.org/10.1017/S0305004100036094
- Simon, H. A. (1947). Administrative behavior. Macmillan.
- Galbraith, J. R. (1974). Organization design: An information processing view. Interfaces, 4(3), 28–36. doi.org/10.1287/inte.4.3.28
- Thompson, J. D. (1967). Organizations in action: Social science bases of administrative theory. McGraw-Hill.
- Heath, C. y Staudenmayer, N. (2000). Coordination neglect: How lay theories of organizing complicate coordination in organizations. Research in Organizational Behavior, 22, 153–191. doi.org/10.1016/S0191-3085(00)22005-4
- Adler, P. S. y Borys, B. (1996). Two types of bureaucracy: Enabling and coercive. Administrative Science Quarterly, 41(1), 61–89. doi.org/10.2307/2393986
- Adler, P. S., Goldoftas, B. y Levine, D. I. (1999). Flexibility versus efficiency? A case study of model changeovers in the Toyota production system. Organization Science, 10(1), 43–68. doi.org/10.1287/orsc.10.1.43
- Hammer, M. (1990). Reengineering work: Don’t automate, obliterate. Harvard Business Review, 68(4), 104–112.
- Martini, A., Besker, T. y Bosch, J. (2020). Process debt: A first exploration. En 2020 27th Asia-Pacific Software Engineering Conference (APSEC) (pp. 316–325). IEEE. doi.org/10.1109/APSEC51365.2020.00040
- van der Aalst, W. (2016). Process mining: Data science in action (2.ª ed.). Springer. doi.org/10.1007/978-3-662-49851-4
- Reinertsen, D. G. (2009). The principles of product development flow: Second generation lean product development. Celeritas.
Investigación empresarial e institucional
- de Kroon, D., de Boer, E., Hou, F., Kleine Büning, M., Shahani, R., Heuss, R., Rosendahl, M. y Muthiah, S. (19 de junio de 2026). Putting AI to work: The operational excellence imperative. McKinsey & Company. mckinsey.com
- Krivkovich, A., Weddle, B., Price, H. y Sohoni, V. (5 de octubre de 2026). AI is changing work. Now it has to change the organization. McKinsey Quarterly. mckinsey.com
- Relyea, C., Lunawat, G., Palaniappan, J., Harrysson, M., Linderman, M. y Dixit, P. (21 de agosto de 2026). Beyond the copilot: Scaling the agentic product development life cycle. McKinsey & Company. mckinsey.com
- Google Cloud DORA. (2025). 2025 state of AI-assisted software development. blog.google
- Gartner. (25 de junio de 2025). Gartner predicts over 40% of agentic AI projects will be canceled by end of 2027. gartner.com
- Deloitte AI Institute. (6 de julio de 2025). The rise of AI agents and collaborative automation. deloitte.com
- Ammanath, B. y Comstock, A. (13 de octubre de 2025). The dawn of agentic AI: Orchestration, governance, and best practices. Deloitte. deloitte.com
- Stanford Graduate School of Business. (7 de enero de 2014). Hayagreeva Rao and Robert Sutton: How do you scale excellence? gsb.stanford.edu
América Latina y España
- CEPAL. (s. f.). Acerca de las microempresas y pymes. cepal.org
- Instituto Nacional de Estadística. (22 de octubre de 2025). Encuesta sobre el uso de TIC y del comercio electrónico en las empresas 2024–2025. ine.es
- Pauta. (25 de septiembre de 2026). El 45% de las empresas chilenas usa inteligencia artificial, pero la mayoría aún la ocupa para tareas básicas [estudio de Strand Partners para AWS]. pauta.cl
The Scalability Stress Test by Advisent® y The Process Redesign Decision by Advisent® son desarrollos propios y conceptuales. La integración entre el trabajo de Sutton y Rao y la teoría de las restricciones es una interpretación editorial de Advisent®. Los conceptos de the problem of more y la tensión entre budismo y catolicismo (Sutton y Rao), la teoría de las restricciones y sus cinco pasos (Goldratt), coordination neglect (Heath y Staudenmayer), burocracia habilitante y coercitiva (Adler y Borys) y deuda de procesos (Martini, Besker y Bosch) pertenecen a sus autores. Las encuestas de McKinsey, DORA y AWS reflejan percepciones declaradas y correlaciones, no relaciones causales.
Última actualización:
