Tema 4.9 — Fronteras organizacionales
Ruta académica
Programa: Business Administration
Bloque 1: Fundamentos de administración
Unidad 2: La empresa como sistema
Tema 4: Pensamiento sistémico aplicado a empresas
Subtema: Fronteras organizacionales
Objetivos de aprendizaje
Al finalizar este subtema deberás ser capaz de:
- Explicar qué representa una frontera en análisis sistémico.
- Distinguir fronteras jurídicas, económicas, operativas, tecnológicas e informacionales.
- Comprender que las fronteras dependen de la pregunta analítica.
- Analizar decisiones make-or-buy, outsourcing y plataformas desde la perspectiva de fronteras.
- Identificar riesgos de fronteras demasiado estrechas o demasiado amplias.
- Diseñar un mapa de frontera para un proceso empresarial.
1. Para estudiar un sistema necesitamos decidir dónde empieza y dónde termina
Todo análisis sistémico requiere una frontera.
La frontera distingue:
DENTRO DEL SISTEMA
↕
FRONTERA
↕
ENTORNO
Pero esa frontera no siempre coincide con el límite legal de la empresa.
Una organización puede depender profundamente de proveedores, plataformas y partners que jurídicamente son externos, pero operacionalmente forman parte de su capacidad de entregar valor.
2. La frontera es una decisión analítica
Supongamos que analizamos retrasos en soporte.
Frontera estrecha
Solo equipo de soporte
Frontera amplia
Producto → Onboarding → Documentación → Soporte → Customer Success
Si muchos tickets se originan por bugs de producto o mala documentación, la frontera estrecha conduce a un diagnóstico equivocado.
La pregunta determina qué debe incluirse.
3. Frontera jurídica
Separa entidades legales.
Ejemplos:
- sociedad A;
- proveedor B;
- cliente C.
Es importante para:
- responsabilidad;
- contratos;
- impuestos;
- propiedad;
- gobierno corporativo.
Pero no explica necesariamente el flujo operativo completo.
4. Frontera económica
Desde una perspectiva económica, una empresa decide qué actividades coordina internamente y cuáles compra en el mercado.
Esta pregunta está vinculada a la teoría de costos de transacción desarrollada por Ronald Coase y posteriormente Oliver Williamson.
¿HACER INTERNAMENTE?
vs.
¿COMPRAR EN EL MERCADO?
La frontera de la firma cambia con esa decisión.
5. Make or buy
Una empresa puede decidir producir internamente o contratar externamente.
Factores:
- costo;
- calidad;
- control;
- conocimiento;
- escala;
- riesgo;
- flexibilidad;
- capacidad crítica.
Ejemplo:
Desarrollo de software propio
vs.
SaaS externo
La opción más barata no siempre es la mejor si crea dependencia crítica.
6. Outsourcing
Externalizar desplaza una actividad fuera de la frontera organizacional formal.
Pero la responsabilidad por el resultado puede permanecer.
Ejemplo:
Una empresa externaliza soporte.
El proveedor opera el proceso, pero el cliente sigue asociando la experiencia con la marca contratante.
Actividad externa
≠
consecuencia externa
7. Integración vertical
La empresa puede ampliar sus fronteras adquiriendo actividades upstream o downstream.
Upstream
hacia proveedores.
Downstream
hacia distribución o cliente.
Ejemplo:
Fabricante
→ adquiere proveedor
→ controla insumo crítico
La integración reduce algunas dependencias y crea nuevas necesidades de gestión interna.
8. Ecosistemas y fronteras permeables
Las empresas digitales funcionan dentro de ecosistemas.
EMPRESA
↔ APIs
↔ marketplaces
↔ partners
↔ developers
↔ customers
La frontera se vuelve permeable porque recursos y capacidades atraviesan continuamente el límite formal.
9. Frontera tecnológica
Define qué sistemas están bajo control directo y cuáles pertenecen a terceros.
Ejemplo:
Aplicación propia
↓
Cloud externo
↓
API de pagos
↓
Red bancaria
El usuario percibe una sola experiencia, aunque técnicamente intervengan múltiples organizaciones.
10. Shared responsibility
En cloud computing, la responsabilidad se divide entre proveedor y cliente.
El principio general es útil más allá del cloud:
externalizar una capacidad no elimina la necesidad de definir quién responde por cada parte.
Deben quedar claros:
- disponibilidad;
- seguridad;
- backups;
- datos;
- soporte;
- incidentes.
11. Frontera de datos
Los datos atraviesan fronteras distintas a las físicas.
Preguntas:
- ¿quién captura?;
- ¿quién almacena?;
- ¿quién procesa?;
- ¿quién puede acceder?;
- ¿en qué jurisdicción?;
- ¿cuándo se elimina?
La frontera informacional puede ser más relevante que la ubicación física.
12. Frontera de autoridad
Una organización necesita definir dónde termina la capacidad de decisión de un rol.
Ejemplo:
Sales Rep
puede descontar hasta 5%
Manager
hasta 15%
Director
excepciones superiores
La frontera de autoridad reduce ambigüedad y permite delegación controlada.
13. Frontera del proceso
Todo proceso necesita un inicio y un final definidos.
Ejemplo:
¿Dónde empieza “Order to Cash”?
- cuando se firma el contrato;
- cuando se genera la orden;
- cuando se recibe el pedido.
¿Dónde termina?
- al facturar;
- al cobrar;
- al conciliar el pago.
La definición cambia métricas y responsabilidades.
14. Fronteras demasiado estrechas
Una frontera estrecha puede ocultar causas.
Ejemplo:
Problema: churn alto.
Si analizamos solo Customer Success, podemos ignorar:
- mala venta;
- producto deficiente;
- pricing;
- soporte;
- onboarding.
El síntoma aparece en una unidad, pero la causa está fuera de la frontera elegida.
15. Fronteras demasiado amplias
También existe el problema contrario.
Si incluimos todo:
empresa + industria + economía + sociedad + planeta
el análisis puede volverse inmanejable.
Una frontera útil incluye elementos necesarios para responder la pregunta sin introducir complejidad irrelevante.
16. Boundary spanning roles
Algunos roles conectan organización y entorno.
Ejemplos:
- ventas;
- procurement;
- legal;
- partnerships;
- customer success;
- government affairs.
Estos roles actúan como sensores y traductores entre sistemas distintos.
17. API como frontera explícita
En arquitectura de software, una API define una frontera contractual.
Servicio A
↓
API
↓
Servicio B
Permite que los sistemas evolucionen con cierto grado de independencia siempre que respeten el contrato.
La claridad de interfaces reduce acoplamiento accidental.
18. Dominios y bounded contexts
En diseño de software, conceptos como bounded context ayudan a delimitar modelos y significados.
La analogía empresarial es poderosa:
una palabra como “cliente” puede significar cosas diferentes en:
- CRM;
- facturación;
- soporte;
- contabilidad.
La frontera debe especificar qué modelo es válido dentro de cada contexto y cómo se traduce entre ellos.
19. Fronteras y accountability
Cuando una actividad cruza varias organizaciones puede aparecer un vacío:
“eso le corresponde al proveedor”.
“eso era responsabilidad del cliente”.
Un buen diseño define:
- owner del resultado;
- responsables parciales;
- mecanismos de escalación;
- evidencia.
20. Caso aplicado: agencia + proveedor externo
Una agencia vende una reserva creada en el motor de un proveedor externo.
El proceso completo puede ser:
Cliente
↓
Agencia
↓
Motor de proveedor
↓
Hotel / aerolínea
↓
Confirmación
↓
Agencia
↓
Cliente
Aunque el proveedor sea externo, debe incluirse dentro de la frontera analítica al estudiar experiencia de reserva.
Si se analiza únicamente “lo que hace la agencia”, se pierde una parte crítica del sistema.
21. Cambiar fronteras como decisión estratégica
Una empresa puede rediseñar sus límites.
Ejemplos:
- desarrollar tecnología que antes compraba;
- externalizar nómina;
- adquirir un proveedor;
- vender una unidad;
- abrir marketplace a terceros.
Cada decisión modifica:
- control;
- costos;
- riesgos;
- conocimiento;
- coordinación.
22. Preguntas de reflexión
- ¿Qué proveedor externo forma parte de facto de la experiencia del cliente?
- ¿Qué problema ha sido analizado con una frontera demasiado estrecha?
- ¿Qué capacidad conviene mantener dentro de la empresa?
- ¿Dónde termina la autoridad de un rol?
- ¿Qué datos cruzan fronteras organizacionales?
- ¿Qué actividad externalizada sigue generando responsabilidad reputacional?
23. Ejercicio aplicado
Selecciona un proceso y dibuja tres fronteras:
A. Frontera jurídica
¿Qué entidades participan?
B. Frontera operativa
¿Qué actores hacen trabajo necesario para el resultado?
C. Frontera tecnológica
¿Qué sistemas intervienen?
Después identifica una responsabilidad que podría quedar ambigua entre dos fronteras.
24. Ideas clave
- Toda frontera es una elección analítica.
- La frontera jurídica no coincide necesariamente con la operativa.
- Make-or-buy modifica la frontera de la empresa.
- Outsourcing traslada ejecución, pero no siempre responsabilidad.
- Datos, autoridad y tecnología tienen sus propias fronteras.
- Fronteras claras e interfaces explícitas reducen ambigüedad.
25. Videos recomendados en YouTube
-
MIT OpenCourseWare — Systems Thinking and Modeling for a Complex World
https://www.youtube.com/watch?v=o-Yp8A7BPE8 -
CrashCourse — How to Seek Help and Find Key Partners (#9)
https://www.youtube.com/watch?v=-KjqyqQAZ3A
26. Bibliografía y fuentes verificables
- Coase, R. H. (1937). The Nature of the Firm. Economica, 4(16), 386–405. https://doi.org/10.1111/j.1468-0335.1937.tb00002.x
- Williamson, O. E. (1985). The Economic Institutions of Capitalism. Free Press.
- Scott, W. R., & Davis, G. F. (2007). Organizations and Organizing. Pearson.
- Thompson, J. D. (1967). Organizations in Action. McGraw-Hill.
- Meadows, D. H. (2008). Thinking in Systems: A Primer. Chelsea Green Publishing.
<!-- oone-academy-navigation -->
Navegación
← Anterior: Interdependencia · Índice del Tema 4 · Siguiente: Complejidad →