Lo que hay detrás
Detrás de cada nodo hay más que una caja
Cada unidad organizativa del modelo de organización TAOM puede describirse en términos de negocio y enriquecerse con su contexto operativo. Además de estructura y asignación, las tareas, responsabilidades, requisitos de calidad, sistemas, salidas y controles se mantienen directamente en el objeto de organización.
Así un organigrama se convierte en un modelo de organización vivo: no solo se ve quién está dónde, sino también qué aporta una unidad, de qué responde y qué requisitos rigen para su trabajo.
Dos vistas separadas, porque son dos preguntas distintas: ¿Qué hace la unidad? y ¿bajo qué condiciones es aceptable el resultado?
Un ejemplo del modelo anterior
Resumen
Objetivo
Crear y mantener las condiciones técnicas para la operación.
Sistemas
SAP Fiori
Transacciones
IW21 CAT2
Salida
Informe técnico · configuración del sistema
Bajo qué condiciones cuenta el resultado
Riesgos
datos maestros incompletos · información contradictoria · especificaciones técnicas obsoletas
Controles
Integridad · plausibilidad · versión y estado
Evidencias
Certificados de ensayo · CoA · aprobaciones técnicas
Aprobación
Solo con los defectos de calidad resueltos y las evidencias completas.
De qué depende la unidad
Personas Roles RACI
Procesos Sistemas Requisitos
Decisiones Conocimiento Pruebas
Si cambia una de estas conexiones, el efecto se produce donde se trabaja, no solo en la imagen.
El mismo modelo, otra organización
Como una unidad organizativa es un objeto del gemelo digital y no un dibujo, la misma estructura sirve también fuera de un proyecto:
Program Management → PMO → Streams → Teams
Dirección → Operations → Supply Chain → Producción → Calidad
Global Process Owner → Process Owner → Process Expert → Key User
Personas · socios externos · personal de IA, en la misma cadena y con una persona al final.