Tema 4.3 — Procesos de transformación

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: Procesos

Objetivos de aprendizaje

Al finalizar este subtema deberás ser capaz de:

1. Definir un proceso como mecanismo de transformación dentro de un sistema.
2. Distinguir proceso, actividad, tarea, evento y procedimiento.
3. Explicar la diferencia entre procesos funcionales y end-to-end.
4. Identificar capacidad, cuello de botella, tiempo de ciclo, espera y retrabajo.
5. Analizar cómo los procesos conectan departamentos y sistemas de información.
6. Mapear un proceso empresarial básico desde sus inputs hasta sus outputs.

1. La empresa transforma

Una empresa crea valor porque transforma algo.

La transformación puede ser física, informacional, financiera, intelectual o relacional.

INPUTS
   ↓
TRANSFORMACIÓN
   ↓
OUTPUTS

Una fábrica transforma materiales. Un despacho transforma información y conocimiento en asesoría. Un banco transforma información, capital y riesgo en servicios financieros. Una plataforma digital transforma datos y reglas en experiencias y transacciones.

El conjunto de actividades que realiza esa transformación forma un proceso.

2. Proceso, actividad y tarea

Conviene distinguir niveles.

Proceso

Conjunto de actividades relacionadas que producen un resultado para un cliente o usuario.

Actividad

Unidad de trabajo dentro del proceso.

Tarea

Acción concreta ejecutada por una persona o sistema.

Ejemplo:

PROCESO
Onboarding de cliente

ACTIVIDAD
Validar identidad

TAREA
Comparar documento con datos capturados

La distinción ayuda a decidir qué nivel queremos mejorar o automatizar.

3. Evento y procedimiento

Evento

Algo que ocurre y puede iniciar, detener o modificar un proceso.

Ejemplos:

• llega una orden;
• se recibe un pago;
• vence un plazo;
• falla un servicio.

Procedimiento

Describe cómo debe ejecutarse una actividad o conjunto de tareas.

Por tanto:

EVENTO → inicia o modifica
PROCESO → produce resultado
PROCEDIMIENTO → especifica cómo actuar

4. Procesos funcionales

Un proceso funcional ocurre principalmente dentro de un área.

Ejemplos:

• conciliación bancaria;
• evaluación de candidatos;
• mantenimiento de inventario;
• revisión de código.

Son útiles para especialización, pero la experiencia del cliente rara vez termina dentro de un solo departamento.

5. Procesos end-to-end

Un proceso end-to-end atraviesa funciones para generar un resultado completo.

Ejemplos clásicos:

LEAD TO CASH
Lead → Venta → Entrega → Factura → Cobro

PROCURE TO PAY
Necesidad → Compra → Recepción → Factura → Pago

HIRE TO RETIRE
Vacante → Contratación → Desarrollo → Separación

RECORD TO REPORT
Transacción → Registro → Cierre → Reporte

Pensar end-to-end evita que cada área optimice solamente su fragmento.

6. El cliente del proceso

Todo proceso debe producir algo valioso para alguien.

El cliente puede ser:

• externo;
• interno;
• regulador;
• otro proceso;
• un sistema.

Preguntar “¿quién utiliza este output?” ayuda a detectar actividades que existen por costumbre pero ya no agregan valor.

7. Flujo

Un proceso puede verse como flujo de:

• materiales;
• información;
• dinero;
• decisiones;
• documentos;
• trabajo.

Ejemplo:

PEDIDO
  ↓
VALIDACIÓN
  ↓
INVENTARIO
  ↓
PREPARACIÓN
  ↓
ENVÍO
  ↓
ENTREGA

La calidad del proceso depende no solo de cada actividad, sino también de las transiciones.

8. Tiempo de ciclo y lead time

Cycle time

Tiempo empleado realmente en ejecutar una actividad o proceso.

Lead time

Tiempo total transcurrido desde la solicitud hasta la entrega.

Ejemplo:

Trabajo efectivo: 2 horas
Esperas: 3 días

Cycle time ≈ 2 horas
Lead time ≈ 3 días + 2 horas

Muchos procesos lentos no tienen demasiado trabajo; tienen demasiada espera.

9. Espera

La espera aparece cuando una unidad de trabajo no puede avanzar.

Causas frecuentes:

• aprobación;
• falta de información;
• dependencia de otra área;
• cola;
• falta de capacidad;
• prioridad conflictiva.

La espera suele ser invisible en organigramas, pero muy visible para el cliente.

10. Capacidad

La capacidad es la cantidad de trabajo que un recurso o proceso puede manejar durante un periodo.

Ejemplo:

Equipo puede procesar 40 casos/día
Demanda = 55 casos/día

Backlog crece 15 casos/día

Si demanda supera capacidad de manera sostenida, el sistema acumula trabajo.

11. Cuello de botella

El cuello de botella es el recurso que limita el throughput del sistema.

A: 100/h
B: 40/h   ← cuello de botella
C: 90/h

Aumentar capacidad en A no mejora el output total mientras B siga limitando el flujo.

Esta idea es central en Theory of Constraints y en análisis sistémico de operaciones.

12. Throughput

Throughput es la tasa a la que el sistema genera unidades completadas o valor terminado.

Puede medirse como:

• pedidos entregados por día;
• casos resueltos por semana;
• productos terminados por hora;
• clientes incorporados por mes.

El throughput debe analizarse a nivel de sistema, no solo por actividad.

13. Trabajo en proceso

El work in progress (WIP) es trabajo iniciado pero no terminado.

Un WIP excesivo puede producir:

• colas;
• pérdida de visibilidad;
• multitarea;
• cambios de contexto;
• errores;
• lead time alto.

Mucho WIP
   ↓
Más espera
   ↓
Lead time ↑

Limitar WIP puede mejorar flujo aun sin contratar más personas.

14. Retrabajo

Retrabajo es trabajo que debe repetirse porque el resultado anterior no fue aceptable.

Causas:

• requisitos ambiguos;
• errores de entrada;
• mala calidad;
• cambios tardíos;
• handoffs deficientes.

El retrabajo consume capacidad sin generar nuevo valor.

15. Variabilidad

Un proceso con alta variabilidad requiere más capacidad de adaptación.

Ejemplo:

Caso A: 5 minutos
Caso B: 4 horas
Caso C: 20 minutos

El promedio puede ocultar una distribución problemática.

Por ello, la administración debe observar:

• rango;
• percentiles;
• excepciones;
• mezcla de casos.

16. Procesos y controles

Los procesos incorporan controles para reducir riesgos.

Ejemplos:

• aprobación de pagos;
• segregación de funciones;
• validación de datos;
• revisión de calidad;
• autorizaciones.

El desafío es equilibrar:

CONTROL
↔
VELOCIDAD

Más control no siempre significa mejor proceso si el control no reduce un riesgo significativo.

17. Automatización

Automatizar significa trasladar parte de la ejecución a tecnología.

Antes:
Persona recibe → valida → registra → notifica

Después:
Sistema recibe → valida → registra → notifica
Persona resuelve excepciones

Pero automatizar un proceso mal diseñado puede acelerar errores.

Primero debe entenderse:

• propósito;
• reglas;
• excepciones;
• inputs;
• outputs;
• responsables.

18. Process mining

Las plataformas digitales generan logs que permiten reconstruir cómo se ejecutan realmente los procesos.

El process mining utiliza eventos registrados para analizar:

• rutas reales;
• cuellos de botella;
• retrabajo;
• desviaciones;
• tiempos.

Esto ayuda a comparar el proceso diseñado con el proceso efectivo.

19. Proceso diseñado vs. proceso real

Documentación:

A → B → C → D

Realidad:

A → B → C → B → Excel → correo → D

La diferencia entre ambos suele revelar deuda operativa.

Un análisis serio debe observar conducta real, no solo manuales.

20. Caso aplicado: venta de servicio

Proceso actual:

Lead
 ↓
Asesor cotiza
 ↓
Cliente acepta
 ↓
Asesor manda correo a administración
 ↓
Administración captura datos
 ↓
Finanzas genera factura
 ↓
Operaciones recibe otro correo
 ↓
Servicio inicia

Problemas:

• doble captura;
• múltiples handoffs;
• correos como integración;
• ausencia de fuente única de verdad;
• poca trazabilidad.

Rediseño:

CRM
 ↓ oportunidad ganada
Workflow
 ↓
ERP / Facturación
 ↓
Operaciones
 ↓
Estado compartido

El software sirve al proceso cuando elimina fricción y conserva trazabilidad.

21. Mapear antes de mejorar

Una secuencia útil es:

1. definir inicio y fin;
2. identificar cliente;
3. registrar inputs;
4. describir actividades;
5. localizar handoffs;
6. medir tiempos;
7. identificar espera;
8. detectar retrabajo;
9. localizar cuello de botella;
10. proponer intervención.

22. Preguntas de reflexión

1. ¿Qué diferencia existe entre proceso y departamento?
2. ¿Por qué lead time puede ser mucho mayor que cycle time?
3. ¿Qué actividad limita el throughput de un proceso conocido?
4. ¿Qué handoff produce más pérdida de contexto?
5. ¿Qué proceso está automatizado sin haber sido rediseñado?
6. ¿Dónde existe retrabajo evitable?

23. Ejercicio aplicado

Selecciona un proceso de principio a fin y documenta:

Después propone una sola mejora y explica qué efecto sistémico esperas.

24. Ideas clave

• El proceso transforma inputs en outputs.
• Los procesos end-to-end atraviesan departamentos.
• La espera puede explicar más del lead time que el trabajo efectivo.
• El cuello de botella limita el throughput global.
• WIP y retrabajo consumen capacidad.
• Automatizar no sustituye el diseño de procesos.

25. Videos recomendados en YouTube

1. MIT OpenCourseWare — Systems Thinking and Modeling for a Complex World
   https://www.youtube.com/watch?v=o-Yp8A7BPE8

2. CrashCourse — The Core of a Business: Key Activities & Resources (#8)
   https://www.youtube.com/watch?v=8bu1Ltpeiu4

26. Bibliografía y fuentes verificables

• Slack, N., Brandon-Jones, A., & Burgess, N. (2022). Operations Management (10th ed.). Pearson.
• Goldratt, E. M., & Cox, J. (2014). The Goal: A Process of Ongoing Improvement (30th anniversary ed.). North River Press.
• Dumas, M., La Rosa, M., Mendling, J., & Reijers, H. A. (2018). Fundamentals of Business Process Management (2nd ed.). Springer. https://doi.org/10.1007/978-3-662-56509-4
• Hammer, M., & Champy, J. (1993). Reengineering the Corporation. HarperBusiness.
• Sterman, J. D. (2000). Business Dynamics. Irwin/McGraw-Hill.

Navegación

← Anterior: Inputs — Entradas del sistema · Índice del Tema 4 · Siguiente: Outputs — Salidas y resultados →