Comprenda la gestión de procesos y BPM, cómo organizar procesos de extremo a extremo, definir responsabilidades, medir el desempeño y mejorar flujos en empresas de ingeniería.
¡Descúbrelo!
La gestión de procesos es la disciplina utilizada para identificar, comprender, organizar, controlar y mejorar la forma en que actividades interdependientes transforman entradas en resultados. Su objetivo no es producir diagramas de flujo por obligación, sino asegurar que el trabajo genere valor, cumpla requisitos, mantenga responsabilidades claras y pueda medirse y mejorarse.
En empresas de ingeniería, este enfoque conecta actividades técnicas, administrativas, contractuales y documentales que normalmente atraviesan distintas áreas. Solicitudes de diseño, revisiones de documentos, cambios de alcance, RFIs, inspecciones, mediciones, aprobaciones y criterios de aceptación son ejemplos de procesos que dependen de interfaces bien definidas para funcionar.
¿Qué es la gestión de procesos?
La gestión de procesos es la gestión sistemática de los procesos y de sus interacciones. Establece qué resultados deben alcanzarse, qué actividades son necesarias, quién participa, qué reglas deben respetarse, qué recursos se utilizan y cómo se supervisará el desempeño.
El enfoque por procesos adoptado por ABNT NBR ISO 9001 considera la organización como un sistema de procesos interrelacionados. Cada proceso recibe entradas, ejecuta actividades, produce salidas y se conecta con procesos anteriores y posteriores. Los controles y puntos de medición varían según el contexto, los requisitos y los riesgos implicados.
Un proceso bien gestionado debe dejar claro qué resultado se pretende alcanzar, qué inicia y finaliza el flujo y qué entradas son necesarias para producir las salidas esperadas. También debe explicitar quién ejecuta, verifica, aprueba y responde por el resultado.
Además, el diseño debe registrar las reglas y los criterios de decisión, los sistemas y documentos utilizados, los riesgos que pueden comprometer la ejecución y la forma en que se medirán el plazo, la calidad, la capacidad y la eficiencia. Las excepciones, los cambios y las oportunidades de mejora también necesitan un tratamiento definido.
De la gestión de procesos a la implantación de workflows. A3A estructura procesos técnicos, responsabilidades, reglas de aprobación, SLA, evidencias y trazas de auditoría, con implantación en plataformas existentes o en ENGiOS.
¿Por qué deben gestionarse los procesos?
Muchas organizaciones tienen procesos, pero no los gestionan. El trabajo ocurre mediante experiencia individual, mensajes, reuniones, hojas de cálculo paralelas y acuerdos informales. Mientras el volumen es pequeño, este modelo puede parecer suficiente. A medida que aumenta la cantidad de proyectos, proveedores, documentos y decisiones, aparecen retrasos, retrabajo y pérdida de trazabilidad.
La gestión de procesos busca reducir esta dependencia del conocimiento tácito. Hace que el trabajo sea comprensible y repetible sin eliminar el análisis técnico ni la autonomía profesional.
En la práctica, la gestión de procesos busca asegurar el cumplimiento consistente de los requisitos y reducir variaciones que generan retrabajo. Al hacer explícitas las responsabilidades y los niveles de autoridad, mejora la coordinación entre áreas, proveedores y proyectos que dependen del mismo flujo.
Otro objetivo es producir información fiable para la toma de decisiones, preservar registros y evidencias y tratar riesgos y excepciones de forma estructurada. Con ello, la organización gana previsibilidad de plazo y capacidad y pasa a identificar con mayor claridad dónde simplificar, estandarizar o automatizar.
El resultado esperado no es un proceso estático, sino un sistema de trabajo que pueda supervisarse y mejorarse continuamente.
Proceso, proyecto, procedimiento y workflow: ¿cuál es la diferencia?
Estos conceptos están relacionados, pero no son equivalentes.
Proceso
Es un conjunto recurrente o repetible de actividades relacionadas que transforma entradas en salidas. Un proceso puede ejecutarse muchas veces, aunque cada ocurrencia tenga particularidades.
Ejemplos: aprobación de documentos técnicos, tratamiento de RFIs, gestión de cambios, medición de contratos y control de no conformidades.
Proyecto
Es un esfuerzo temporal realizado para alcanzar objetivos definidos. Tiene inicio y fin, organización propia, entregables y restricciones. ABNT NBR ISO 21502 caracteriza el proyecto por su naturaleza temporal.
Un proyecto utiliza procesos organizativos, pero no se confunde con ellos. Varios proyectos pueden utilizar el mismo proceso de aprobación documental o de gestión de cambios.
Procedimiento
Es la forma especificada de ejecutar una actividad o proceso. Puede definir instrucciones, criterios, secuencia, documentos y responsabilidades. No todos los procesos necesitan un procedimiento extremadamente detallado, pero los procesos críticos generalmente requieren orientación documentada proporcional al riesgo.
Workflow
Es la representación ejecutable u operativa del flujo de trabajo. Define etapas, transiciones, responsables, plazos, condiciones, notificaciones y registros. Puede existir en papel o en una hoja de cálculo, pero normalmente se asocia a la implantación digital en una plataforma.
Gestión funcional y gestión por procesos
En la gestión funcional, el trabajo se organiza principalmente por departamentos: Ingeniería, Compras, Contratos, Finanzas, Operaciones y Calidad. Esta estructura es necesaria para concentrar competencias, pero puede crear silos.
La gestión por procesos observa el flujo de extremo a extremo. En lugar de analizar únicamente el desempeño de cada departamento, se acompaña cómo una demanda atraviesa diferentes funciones hasta producir el resultado esperado.
Un proceso de cambio de ingeniería, por ejemplo, puede implicar:
- identificación de la necesidad por Operaciones o Ingeniería;
- registro y clasificación de la solicitud;
- análisis técnico y evaluación de riesgos;
- estimación de impactos en plazo, coste y contratos;
- aprobación según nivel de autoridad;
- actualización de documentos y baselines;
- implantación;
- verificación y cierre.
Ninguna área aislada controla todo este resultado. Por ello, la gestión por procesos exige integración entre responsabilidades funcionales y una visión transversal.
Tipos de procesos organizativos
Una clasificación sencilla ayuda a organizar la cartera de procesos.
Procesos principales
Entregan directamente productos, servicios o resultados al cliente o usuario. En una empresa de ingeniería, pueden incluir desarrollo de diseños, supervisión, puesta en marcha, inspecciones, estudios y emisión de dictámenes técnicos.
Procesos de apoyo
Proporcionan recursos y capacidades a los procesos principales. Ejemplos: gestión documental, tecnologías de la información, compras, recursos humanos, infraestructura y gestión del conocimiento.
Procesos de gestión y gobernanza
Dirigen, controlan y evalúan la organización. Incluyen planificación estratégica, gestión de cartera, riesgos, desempeño, auditoría, revisión por la dirección, priorización y toma de decisiones.
La clasificación debe apoyar la gestión. No es necesario crear debates excesivos sobre fronteras conceptuales cuando el objetivo, el responsable y las interfaces ya están claros.
¿Qué elementos definen un proceso?
Un proceso no está suficientemente definido solo porque exista un diagrama de flujo. La descripción debe combinar una visión gráfica, reglas e información operativa.
Todo proceso debe tener un objetivo, un evento de inicio y un conjunto conocido de entradas. A partir de ellas, las actividades transforman información, requisitos o recursos en salidas verificables.
El diseño también debe representar las decisiones que alteran el recorrido del flujo y los roles responsables de ejecutar, verificar, aprobar, apoyar y rendir cuentas. Las salidas deben indicar qué se ha producido y quiénes son los clientes o partes interesadas afectadas.
Los requisitos técnicos, legales, contractuales y organizativos determinan las condiciones que deben cumplirse. Los controles reducen riesgos y aseguran la conformidad, mientras que los recursos abarcan personas, competencias, herramientas e infraestructura.
Por último, los indicadores muestran desempeño y resultado; los registros preservan evidencias de ejecución, decisión y aprobación; y las interfaces explican cómo el proceso se conecta con otros flujos, sistemas y organizaciones.
Etapas de la gestión de procesos
La gestión de procesos es cíclica. El diseño inicial debe validarse, implantarse, supervisarse y revisarse. Una secuencia práctica puede organizarse en nueve etapas.
1. Comprender el contexto y los objetivos
Antes de mapear actividades, es necesario comprender el problema. El trabajo debe partir de la estrategia, de las necesidades de las partes interesadas, de los requisitos aplicables y de los resultados previstos.
El diagnóstico debe identificar qué problema se resolverá, qué resultado debe mejorar y qué requisitos no pueden verse comprometidos. También debe delimitar las áreas, los proyectos y los proveedores afectados, además de los riesgos y las restricciones que condicionan el cambio.
Es igualmente importante evaluar la capacidad de absorción de la organización. Un proceso técnicamente correcto puede fracasar cuando exige demasiados cambios simultáneos, recursos inexistentes o un nivel de madurez que todavía no se ha desarrollado.
2. Identificar y priorizar procesos
No es eficiente mapear toda la organización de forma simultánea. Los procesos deben inventariarse y priorizarse según impacto y necesidad.
Posibles criterios:
- criticidad para clientes y operaciones;
- exposición a riesgos técnicos o contractuales;
- volumen de ocurrencias;
- cantidad de áreas implicadas;
- frecuencia de retrasos y retrabajo;
- impacto financiero;
- exigencia de trazabilidad;
- potencial de estandarización o automatización.
3. Mapear el estado actual — AS-IS
El mapeo AS-IS registra cómo ocurre realmente el trabajo. No debe reproducir únicamente el procedimiento formal. Entrevistas, análisis de documentos, observación, datos de sistemas y muestras de casos ayudan a identificar el flujo efectivamente practicado.
El mapa del estado actual debe revelar:
- actividades y decisiones;
- responsables reales;
- documentos y sistemas utilizados;
- tiempos de ejecución y espera;
- controles paralelos;
- devoluciones y retrabajo;
- excepciones recurrentes;
- puntos sin responsabilidad clara;
- divergencias entre áreas o unidades.
4. Analizar problemas, riesgos y causas
Después de comprender el estado actual, es posible separar síntomas de causas. Un retraso puede deberse a capacidad insuficiente, información incompleta, nivel de autoridad inadecuado, exceso de aprobaciones o ausencia de criterios.
El análisis debe observar dónde se forman cuellos de botella y colas, qué actividades no agregan valor y dónde existen duplicidades o transferencias excesivas entre áreas. Los fallos de comunicación, los conflictos de responsabilidad y los sistemas desconectados suelen explicar una parte relevante de los retrasos.
También es necesario examinar los riesgos y controles existentes, la disponibilidad de datos y evidencias y las causas de no conformidades y retrabajo. El objetivo es comprender por qué falla el proceso antes de proponer una solución.
ABNT NBR ISO 31000 refuerza que los riesgos deben integrarse en las actividades y en la toma de decisiones. Por tanto, el rediseño no debe buscar únicamente rapidez; debe mantener controles proporcionales a las consecuencias de los fallos.
5. Diseñar el estado futuro — TO-BE
El TO-BE describe cómo deberá funcionar el proceso. El diseño futuro debe resolver las causas prioritarias y preservar los requisitos técnicos, legales, contractuales y de seguridad.
El rediseño puede eliminar etapas redundantes, combinar verificaciones compatibles y ajustar niveles de autoridad que concentran decisiones sin necesidad. Los criterios objetivos de entrada y salida ayudan a impedir que solicitudes incompletas avancen y regresen repetidamente.
También puede ser necesario estandarizar formularios y datos, anticipar validaciones, reducir transferencias entre áreas y crear rutas propias para excepciones. La automatización entra después, apoyando notificaciones, tareas repetitivas, integraciones, indicadores y alertas.
6. Definir roles, reglas y documentación
El proceso futuro debe ser operativo. Esto exige definir quién ejecuta, quién decide, qué información es obligatoria y cómo se preservarán las evidencias.
Los principales productos de esta etapa pueden incluir:
- diagrama del proceso;
- matriz de responsabilidades;
- reglas de negocio;
- niveles de aprobación;
- procedimientos e instrucciones;
- formularios y plantillas;
- criterios de aceptación;
- catálogo de datos y documentos;
- indicadores y objetivos;
- reglas de excepción y escalado.
7. Planificar y realizar la implantación
La aprobación del diseño no significa que el proceso haya sido implantado. Es necesario preparar sistemas, documentos, personas, datos y estructuras de apoyo.
La implantación puede comenzar mediante un proyecto piloto, utilizado para validar el flujo, los roles, los formularios y los indicadores en condiciones reales. En paralelo, se configuran las herramientas y se preparan los datos que deberán migrarse o depurarse.
Después de la formación y la comunicación, es recomendable mantener un periodo de operación asistida. En esta fase, el equipo supervisa la adherencia, corrige problemas identificados en el uso cotidiano y solo entonces amplía el proceso a otras áreas, contratos o unidades.
8. Supervisar desempeño y conformidad
Los indicadores deben demostrar si el proceso entrega su resultado y si los controles funcionan. Medir únicamente la cantidad de actividades puede incentivar volumen sin valor.
La supervisión debe combinar resultado, eficiencia, calidad, riesgo y capacidad.
9. Mejorar continuamente
La gestión de procesos no termina después de la implantación. Los cambios en requisitos, tecnología, contratos, estructura y volumen pueden hacer que el modelo deje de ser adecuado.
El ciclo PDCA ofrece una estructura sencilla:
- planificar: establecer objetivos, métodos, recursos y controles;
- hacer: operar el proceso según lo planificado;
- verificar: medir resultados, analizar desviaciones y evaluar riesgos;
- actuar: corregir causas, adaptar controles y mejorar el desempeño.
¿Cómo representar un proceso?
La representación debe ser adecuada al público y al objetivo. Un mapa ejecutivo puede mostrar solo macroetapas e interfaces. Un flujo operativo debe detallar actividades, decisiones y responsabilidades.
Los formatos habituales incluyen:
- SIPOC, para visualizar proveedores, entradas, proceso, salidas y clientes;
- diagrama de flujo funcional o swimlane, para mostrar actividades por área o rol;
- BPMN, para modelar eventos, actividades, decisiones, mensajes y participantes;
- mapa de cadena de valor, para representar macroprocesos;
- procedimiento textual, para reglas e instrucciones que no caben en el diagrama;
- matriz RACI, para aclarar responsabilidades y rendición de cuentas.
La notación no sustituye la comprensión. Los diagramas sofisticados pero incompatibles con la práctica no mejoran el proceso.
Roles y responsabilidades en la gestión de procesos
La gobernanza del proceso debe evitar la idea de que todos son responsables de todo.
Patrocinador
Autoriza la iniciativa, elimina impedimentos y apoya cambios que atraviesan distintas áreas.
Propietario del proceso
Responde por el desempeño de extremo a extremo, por las interfaces y por la evolución del proceso. No necesariamente ejecuta todas las actividades.
Gestores funcionales
Aseguran recursos, competencias y adherencia en las áreas bajo su responsabilidad.
Ejecutores, verificadores y aprobadores
Realizan actividades y decisiones según criterios definidos. La segregación entre elaboración, verificación y aprobación puede ser necesaria en procesos críticos.
Analista o equipo de procesos
Facilita el diagnóstico, el mapeo, el análisis, el rediseño, la documentación y la implantación.
Tecnologías de la información y administradores de sistemas
Configuran plataformas, integraciones, permisos, automatizaciones, datos y trazas de auditoría.
Las responsabilidades deben ser explícitas. La Matriz RACI complementa el diseño del proceso al distinguir quién ejecuta, responde, es consultado y debe ser informado en cada actividad o decisión.
Indicadores de gestión de procesos
Un conjunto equilibrado de indicadores puede incluir:
- tiempo de ciclo: periodo entre inicio y finalización;
- tiempo de espera: parte del tiempo en que la demanda permanece detenida;
- cumplimiento de plazo o SLA: ocurrencias finalizadas dentro del plazo;
- tasa de aprobación a la primera: elementos aceptados sin devolución;
- índice de retrabajo: ocurrencias devueltas o rehechas;
- backlog: volumen pendiente;
- antigüedad de las pendientes: tiempo acumulado de los elementos abiertos;
- capacidad y productividad: volumen tratado por periodo y recurso;
- tasa de excepciones: casos que salen del flujo estándar;
- no conformidades: fallos respecto de requisitos o controles;
- satisfacción del cliente interno o externo: percepción sobre resultado y atención;
- exposición a riesgos: riesgos abiertos y eficacia de los controles.
El objetivo debe considerar criticidad, recursos y variabilidad. Reducir el tiempo de aprobación sin evaluar la calidad puede aumentar errores y costes posteriores.
Automatización y digitalización de procesos
La automatización es una etapa posible de la gestión de procesos, no su punto de partida obligatorio. Digitalizar un flujo mal definido solo acelera los problemas y hace que las excepciones sean más difíciles de gestionar.
Antes de la implantación tecnológica, conviene definir:
- evento de inicio y criterios de entrada;
- datos obligatorios;
- roles y permisos;
- etapas y transiciones;
- reglas condicionales;
- plazos y escalados;
- documentos y evidencias;
- integraciones;
- traza de auditoría;
- indicadores;
- tratamiento de excepciones.
La automatización puede generar tareas, validar campos, controlar plazos, emitir alertas, encaminar aprobaciones y consolidar indicadores. Sin embargo, las decisiones técnicas complejas siguen exigiendo juicio profesional y una adecuada atribución de responsabilidades.
Cuando el proceso formal existe, pero los retrasos, el retrabajo y la pérdida de información siguen repitiéndose, el problema debe diagnosticarse antes de automatizar. El análisis debe localizar causas, interfaces, cuellos de botella, niveles de autoridad, indicadores y oportunidades de rediseño antes de cualquier decisión tecnológica.
Conozca el Diagnóstico y Optimización de Procesos de Ingeniería
Gestión de procesos en empresas de ingeniería
Las empresas de ingeniería combinan trabajo intelectual, requisitos normativos, contratos, documentación controlada e interfaces multidisciplinares. Los procesos deben reflejar esta realidad.
En el frente comercial y de movilización, la gestión de procesos puede abarcar la cualificación de oportunidades, el análisis de requisitos, la elaboración de propuestas y la planificación inicial de los proyectos. El objetivo es evitar que información crítica se pierda en la transición entre Comercial, Ingeniería y Contratos.
Durante la ejecución, cobran importancia los procesos de emisión, verificación y aprobación de documentos, control de revisiones, gestión de requisitos e interfaces, tratamiento de RFIs, riesgos, cambios, inspecciones, pruebas y no conformidades.
En la etapa de entrega, entran los flujos de medición, aceptación técnica, cierre, gestión de proveedores, puesta en marcha, transferencia a operaciones y registro de lecciones aprendidas. Estos procesos están conectados y, por ello, no deben estructurarse como rutinas aisladas.
El diseño debe considerar que distintos contratos pueden exigir flujos, niveles de autoridad y documentos específicos. La estandarización debe crear una base común con reglas de adaptación, en lugar de imponer un único flujo rígido a cualquier proyecto.
Ejemplo práctico: aprobación de un documento técnico
Considere el proceso de emisión y aprobación de una memoria descriptiva.
Entradas
- alcance contractual;
- requisitos del cliente;
- normas aplicables;
- datos de levantamiento;
- interfaces con otras disciplinas;
- plantilla y codificación documental.
Flujo básico
- el responsable elabora la primera revisión;
- un profesional designado realiza la verificación técnica;
- las inconsistencias vuelven para corrección;
- el documento aprobado internamente se presenta al cliente o a la supervisión;
- los comentarios se registran y clasifican;
- el documento se revisa sin perder el historial;
- la aprobación final se registra;
- la revisión vigente se libera para su uso.
Controles
- segregación entre elaboración y verificación;
- identificación inequívoca de la revisión;
- checklist de requisitos;
- registro de comentarios y respuestas;
- aprobación según nivel de autoridad;
- bloqueo de versiones obsoletas;
- traza de auditoría.
Indicadores
- tiempo medio de elaboración y aprobación;
- porcentaje aprobado en la primera presentación;
- cantidad de ciclos de revisión;
- documentos vencidos respecto del SLA;
- causas más frecuentes de comentarios;
- uso indebido de revisiones obsoletas.
Este ejemplo muestra que el proceso no es solo la secuencia de tareas. También incluye requisitos, responsabilidades, documentos, controles, riesgos e indicadores.
Riesgos y controles en los procesos
La mejora no debe retirar controles sin evaluar su finalidad. Algunos controles parecen burocráticos porque fueron mal implantados, pero pueden existir para evitar consecuencias relevantes.
Una revisión independiente, por ejemplo, reduce el riesgo de error técnico; la definición de niveles de autoridad financiera evita compromisos no autorizados. El control de versiones impide el uso de información obsoleta, mientras que el registro de aceptación reduce disputas contractuales.
Del mismo modo, la segregación de funciones ayuda a controlar conflictos de interés y la validación de requisitos reduce la probabilidad de que una entrega incompleta avance a etapas posteriores.
El rediseño debe preguntarse si el control es necesario, si está situado en el punto correcto y si existe una forma más eficiente de alcanzar el mismo objetivo.
Errores comunes en la gestión de procesos
Mapear el proceso ideal e ignorar la práctica
El AS-IS debe retratar el trabajo real, incluidos atajos, hojas de cálculo y excepciones.
Empezar por la herramienta
Elegir software antes de comprender el proceso, los datos y las responsabilidades suele generar personalizaciones excesivas y baja adopción.
Confundir documentación con gestión
Los procedimientos son importantes, pero no sustituyen responsables, indicadores, revisión por la dirección y mejora.
Crear aprobaciones en exceso
Cada aprobación debe tener finalidad, criterio y autoridad. Las aprobaciones sin análisis real aumentan el tiempo de ciclo sin reducir riesgos.
Ignorar excepciones
Los procesos reales tienen urgencias, rechazos, cancelaciones y casos incompletos. El diseño debe prever cómo tratarlos.
Medir únicamente volumen
La cantidad de elementos finalizados no demuestra calidad, plazo, valor ni riesgo.
No designar propietario del proceso
Sin responsabilidad de extremo a extremo, cada área optimiza su etapa y los problemas permanecen en las interfaces.
Tratar la implantación como formación aislada
El cambio exige apoyo del liderazgo, sistemas configurados, recursos, seguimiento y corrección de problemas después del inicio de la operación.
Madurez en la gestión de procesos
La madurez puede evolucionar de forma gradual:
- informal: ejecución dependiente de personas y acuerdos locales;
- documentada: flujos y procedimientos básicos definidos;
- estandarizada: responsabilidades, criterios y datos comunes;
- controlada: indicadores, riesgos y conformidad supervisados;
- integrada: procesos conectados con estrategia, proyectos, contratos y sistemas;
- optimizada: mejora continua, automatización y decisiones basadas en datos.
La organización no necesita llevar todos los procesos al mismo nivel. Los procesos críticos, regulados o de alto impacto exigen mayor control que las rutinas simples y de bajo riesgo.
Relación entre gestión de procesos, PMO y gobernanza
La gestión de procesos organiza cómo se ejecuta el trabajo recurrente. El PMO estructura o apoya capacidades para gestionar proyectos, programas y carteras. La gobernanza define dirección, autoridad, supervisión y rendición de cuentas.
Estas capas se complementan. La gobernanza establece políticas, niveles de autoridad y criterios de decisión; el PMO convierte parte de estas directrices en métodos, servicios y controles aplicados a los proyectos; y la gestión de procesos organiza los flujos utilizados por los equipos en el trabajo cotidiano.
Los sistemas actúan como infraestructura de registro y ejecución, conectando tareas, documentos, decisiones e indicadores. Cuando una de estas capas se trata de forma aislada, surgen lagunas entre dirección, método y operación.
Un PMO depende de procesos claros para planificación, riesgos, cambios, informes y cierre. Del mismo modo, los procesos técnicos necesitan gobernanza para resolver conflictos de prioridad, autoridad y responsabilidad.
Conclusión
La gestión de procesos es una capacidad organizativa para transformar actividades dispersas en flujos comprensibles, controlados y mejorables. Su valor reside en conectar personas, requisitos, decisiones, documentos, riesgos y sistemas para producir resultados consistentes.
En empresas de ingeniería, el mayor beneficio surge cuando los procesos técnicos, administrativos y contractuales se tratan de extremo a extremo. El trabajo comienza por la comprensión del contexto y del estado actual, avanza hacia el diseño futuro y solo entonces llega a la estandarización, implantación y automatización.
La tecnología puede acelerar el proceso y aportar trazabilidad, pero no sustituye objetivos claros, responsabilidades, criterios técnicos y gestión continua.
Referencias técnicas
[1] ABNT. ABNT NBR ISO 9001:2015 — Sistemas de gestión de la calidad — Requisitos. Correspondiente a ISO 9001:2015. Disponible en: ISO 9001:2015.
[2] ABNT. ABNT NBR ISO 31000:2018 — Gestión de riesgos — Directrices. Correspondiente a ISO 31000:2018. Disponible en: ISO 31000:2018.
[3] ABNT. ABNT NBR ISO 21502:2021 — Gestión de proyectos, programas y carteras — Directrices sobre gestión de proyectos. Correspondiente a ISO 21502:2020. Disponible en: ISO 21502:2020.
Preguntas frecuentes
Es la gestión sistemática de procesos y de sus interacciones para asegurar resultados, responsabilidades, controles, indicadores y mejora continua.
La gestión de procesos trata flujos recurrentes o repetibles de la organización. La gestión de proyectos trata esfuerzos temporales creados para alcanzar objetivos definidos. Los proyectos utilizan procesos organizativos, pero no se confunden con ellos.
Es un enfoque que acompaña el trabajo de extremo a extremo, atravesando departamentos y proveedores, en lugar de analizar únicamente el desempeño aislado de cada área funcional.
AS-IS representa cómo funciona actualmente el proceso. TO-BE representa cómo deberá funcionar después del rediseño, incluidas mejoras, responsabilidades, reglas, controles e indicadores.
No. La automatización debe aplicarse cuando agrega valor, reduce esfuerzo repetitivo o mejora el control y la trazabilidad. Los procesos mal definidos deben comprenderse y rediseñarse antes de digitalizarse.
Tiempo de ciclo, tiempo de espera, cumplimiento de SLA, aprobación a la primera, retrabajo, backlog, antigüedad de pendientes, capacidad, excepciones, no conformidades, satisfacción y exposición a riesgos.
Conviene designar un propietario del proceso responsable del desempeño de extremo a extremo. Gestores funcionales, ejecutores, verificadores, aprobadores, especialistas de procesos y TI tienen responsabilidades complementarias.
No. BPM es la disciplina de gestión de procesos de negocio. BPMN es una notación utilizada para representar procesos gráficamente. La notación puede apoyar BPM, pero no sustituye el análisis, la gobernanza, la implantación y la mejora.
Materiales técnicos complementarios
Soluciones relacionadas
- Gestión de Procesos, Workflows y Aprobaciones Técnicas
- Implantación y Estructuración de PMO de Ingeniería
- Indicadores, Dashboards e Informes Ejecutivos de Ingeniería
- ENGiOS — Plataforma de Gestión para Empresas de Ingeniería
Servicios relacionados
Contenidos principales sobre el tema
- PMO: qué es, tipos, funciones y cómo estructurar una oficina de proyectos
- Matriz RACI en Proyectos de Ingeniería
