¿Por qué debe usar el modelado de procesos empresariales?
Las organizaciones utilizan el modelado de procesos empresariales (modelado de BP) para documentar, comprender y mejorar visualmente sus procesos. Como parte de la gestión de procesos de empresariales (BPM), el modelado de BP se ha utilizado como una herramienta organizativa para determinar lo cuáles son los puntos de partida y para determinar el futuro con las mejoras integradas. El modelado de BP representa visualmente todas las actividades, los eventos y los recursos de conexión del proceso de un producto o servicio para hacerlo más eficiente. El modelado de BP suele combinar las disciplinas de asignación de procesos, descubrimiento de procesos, simulación de procesos, análisis de procesos y mejora de procesos. Dentro de un evento de rediseño de procesos empresariales (BPR), el modelado de BP se utiliza para esclarecer qué procesos ya están en uso y para representar nuevos procesos. Algunas de las otras razones para usar el modelado de BP son las siguientes:
- Para crear modelos visuales de procesos: La documentación basada en Word a menudo no es suficiente para que los empleados entiendan la forma en que se lleva a cabo un proceso. Respaldarlo con representaciones visuales ayuda a proporcionar un panorama completo.
- Alinear las operaciones: Con cualquier nueva estrategia empresarial, mantener procesos consistentes después de un cambio requiere descubrir cómo mantenerse dentro de la estrategia general de la organización. También se realizan análisis para identificar cuellos de botella e ineficiencias, y permitir la agilidad de los procesos.
- Mejorar la comunicación de procesos: La comunicación es la clave de todas las tareas siguientes: formalizar los procesos existentes (que una vez fueron conocimientos informales), hacer procesos coherentes, eliminar las conjeturas con las reglas empresariales, gestionar las excepciones, proporcionar cumplimiento normativo, garantizar que los empresarios estén a cargo y apoyar nuevas iniciativas (como Lean Six Sigma).
- Mejorar la eficiencia operativa: El modelado de los procesos promueve la optimización al permitir la simulación y esclarecer las mejoras necesarias. Esto reduce el tiempo del ciclo y promueve una mejor utilización de los recursos.
- Obtener una ventaja competitiva: Un proceso es mejor, en líneas generales, cuando se refina y se alinea constantemente con las estrategias de su empresa. Esta eficiencia coloca a la empresa en una posición orientada hacia el futuro para ser mejor que la competencia.
Modelado de procesos empresariales en el desarrollo de software
El desarrollo de software es un campo arriesgado. Hace veinte años, el informe CHAOS de 1995 del Grupo Standish informó que el 90 % de los proyectos de software fracasan. Hoy en día, las cifras son más bajas, pero siguen reflejando que hay trabajo por hacer. En el informe de 2015 del mismo grupo, la tasa de éxito de los proyectos de desarrollo de software todavía era solo del 29 %. Las recomendaciones del grupo para mejorar estas cifras a lo largo de los años han fluctuado con nuevas tendencias, pero una recomendación principal es: comunicarse con todas las partes interesadas, en especial con los usuarios finales, ya que los usuarios finales son los que terminan definiendo los requisitos en primer lugar. Los expertos recomiendan desarrollar modelos claros con notación comprensible desde el principio de los proyectos para validar los requisitos del software. El modelado de BP permite a los ingenieros de software negociar con las partes interesadas para determinar el sistema que debe construirse, en función de lo que sea óptimo para ambos grupos.
La mayoría de los modelos de BP se han desarrollado como parte de las arquitecturas empresariales existentes, lo que muestra que la intención durante el desarrollo es representar al usuario final. Sin embargo, estos modelos se han hecho desde una serie de perspectivas diferentes, incluidas la funcional, la conductual, la organizativa y la informativa. Los expertos coinciden en que la combinación de estas perspectivas en el diseño de procesos es el mejor método.
- La perspectiva funcional muestra qué elementos del proceso se están realizando y qué información es relevante para ellos.
- La perspectiva conductual (o dinámica) demuestra la secuencia de interacción y cómo se llevan a cabo los elementos del proceso.
- La perspectiva organizativa muestra quién lleva a cabo los elementos de un proceso y dónde lo hace.
- La perspectiva informativa representa el origen de la información que se produce o analiza.
Lenguajes de modelado de procesos empresariales en el software de modelado de procesos empresariales
Todos los lenguajes de modelos de procesos empresariales existentes provienen de diferentes facetas de la tradición científica y se han creado para adaptarse a una perspectiva o a otra. Hay una superposición significativa en los lenguajes, pero hay cuatro categorías generales de lenguajes de modelado de procesos empresariales.
- Lenguajes tradicionales de modelado de procesos: De la tradición del sistema de información de gestión (MIS) a la ingeniería de la información, estos lenguajes están destinados a entenderse y no suelen ser formales. Incluyen IDEF, Petri Nets, EPC, Diagramas de actividad de roles, REA y BPML.
- Lenguajes de modelado de flujos de trabajo: Estos lenguajes de scripting son para describir los flujos de trabajo de un sistema de gestión de flujos de trabajo (WfMS). Estos lenguajes muy formales incluyen el lenguaje de descripción de procesos de flujos de trabajo (WPDL) y los formatos de intercambio propuestos (PIF, PSL).
- Lenguajes de integración de procesos: Estos lenguajes tienen el propósito de integrarse entre empresas y capturar diferentes niveles de la semántica en los procesos. Estos incluyen RosettaNet, ebXML y BPEL4WS.
- Lenguajes orientados a objetos: Destinados a ser entendidos tanto por expertos en TI como por expertos en dominios, estos lenguajes representan el dominio del software. La mayoría del modelado orientado a objetos tiene en cuenta las perspectivas funcional, conductual e informativa.
Hafedh Mili et al recomiendan que los equipos usen un lenguaje central para modelar y, luego, usen diferentes partes de otros lenguajes que se adapten al proceso. En este campo, parece que los expertos coinciden en que incluso los lenguajes deben estar impulsados por las tareas.
Cómo abordar un proyecto de modelado de procesos empresariales
Elegir un enfoque para el modelado de BP es tan esencial como realizarlo. El enfoque, basado en la tarea real en sí, no es el mismo para todos los casos. Algunas clasificaciones deben realizarse antes de llevar a cabo un proyecto. Según Bider, los profesionales deben tener en cuenta tres factores: los procesos empresariales reales, las características del entorno de modelado y el uso previsto del modelo. Estos tres factores pueden dividirse en consideraciones empresariales específicas.
- Los procesos empresariales: Las empresas deben tener en cuenta a sus participantes activos y pasivos, lo cerca que están cumpliendo sus objetivos operativos, lo cerca que el proceso interactúa con su entorno, y la naturaleza y el orden del flujo del proceso.
- Las características del entorno de modelado: Para el entorno de modelado, las empresas deben tener en cuenta la madurez de sus procesos existentes y si hay o no personal disponible que entienda la notación muy formal.
- El uso previsto del modelo: Las empresas deben tener en cuenta sus objetivos para el diseño de modelos y qué base utilizan para crear modelos. Por ejemplo, podrían intentar mejorar los procesos actuales, proporcionar análisis o rediseño, o construir un nuevo sistema informático.
Dado que no existe un enfoque universal del modelado de BP, los expertos recomiendan tener en cuenta todos los factores empresariales únicos. Algunos profesionales recomiendan un enfoque formal especificado que reúna toda la información antes de elegir herramientas, mientras que otros recomiendan herramientas específicas que han funcionado para ellos en el pasado. Dos de nuestros expertos hacen sus recomendaciones a continuación.
Según Dani Peleva, director general de Local Fame Ltd:
“When approaching a business process modeling task, I’d always break it through the prism of project management as it helps me get an idea of the objective of the system that needs engineering, the time the process needs to be completed for, as well as the resources available. Once you know what the requirements are, i.e. the purpose of the process is, what the deliverables are, the budget/resource constraints and so forth, it is a lot easier to approach the design/engineering stage.
When it comes to process engineering at Local Fame, we always have efficiency and effectiveness in mind - the most cost-effective, timely and optimized manner that a process can flow. For this purpose, I always approach the task from a few different angles - from the start of the process, as well as from the end of the process backwards. When you do not limit yourself with the direction of the process flow you can identify gaps and possible flaws in the strategy and implementation, as well as possible bottlenecks. Once I come up with a few different models I test those applying different scenarios in order to understand how sustainable those are in turbulent environment. This is when usually you sift through the best models and shortlist one or two successful ones.
Additionally, an intrinsic part of business process modelling for me is risk management, more specifically, identifying the potential flaws of the model and where and under what circumstances the model can fail. Identifying those weaknesses of the process helps you create contingency plans and backups, and as you often may find yourself, you get to optimize the process even further and scrap some of the chunks you initially considered essential, but later on realized you could go without. When thinking about risk management, however, one should know a risk could be both a positive and a negative, risk can create opportunities for the process to fail or get delayed, but also speed up and become more efficient, which again leads to the process optimisation and potential changes in the model. Tools I often use when doing business process modelling are Gliffy, Activiti Modeller, and Gantt charts.
To conclude, when modelling a process or re-engineering an existing one, I usually approach the task from a project management perspective analysing the requirements fully before moving to the design stage. After design stage, I test the model numerous times in different scenarios and if needed I return to different stages to optimise and tweak it further. Lastly, I always think about risk management and contingency to make sure that the process is resilient and sustainable.”
Ray McKenzie, Founder and Principal, Red Beach Advisors, recommends, “As a management and business consultant for small- to medium-sized companies, a primary duty of mine is to develop efficient and optimized process for every organization to be productive. I always start with examining the problem and finding out the history of the problem, the different parts of the problem, and the effect the problem has on the business. Understanding the problem and components are core pieces to developing an effective process model to improve. Start with the problem. Examine the parties involved. Understand the current performance and measurements. Define the performance improvement goals. Outline an efficient process which drives results and displays success.”
Flujos de trabajo y enfoque orientado a servicios empresariales (BSOA)
Algunos expertos consideran que el modelado de BP para el desarrollo de software es un antes y un después que gira en torno a la introducción de servicios web. Antes del desarrollo de la Web, el enfoque principal para desarrollar procesos eran los flujos de trabajo. En el enfoque de flujo de trabajo, los procesos empresariales están predeterminados. Los lenguajes más adecuados son el lenguaje de ejecución de procesos empresariales (BPEL) y el lenguaje de definición de flujo (FDL). El enfoque del flujo de trabajo fue criticado por no ser muy flexible en un entorno moderno.
Después del desarrollo de servicios web, el enfoque del modelado de BP para el desarrollo de software se enfocó e identificó más como el enfoque orientado a los servicios empresariales (BSOA). El modelado de procesos se basa en la composición flexible de los servicios empresariales. El enfoque se puede adaptar para abordar cuáles son los objetivos y requisitos del diseñador en el desarrollo de la arquitectura mediante el uso de bloques de construcción. Los servicios llevan a cabo pequeñas tareas, como el desarrollo de datos o procedimientos de servicio simples. En conjunto, el BSOA fabrica un sistema extremadamente reutilizable que se puede arreglar y actualizar con regularidad. Este enfoque se acredita como Agile y se aplica a muchos tipos diferentes de organizaciones.
Diferentes formas de modelar los procesos empresariales
Entre todos los estándares y los lenguajes estandarizados, algunos profesionales piensan que se está esfumando la creatividad en el diseño de procesos. Los enfoques alternativos pueden restaurar parte de esa creatividad. Algunas de las técnicas más populares que pueden ser independientes o incluso complementar enfoques más formales son las siguientes:
- Técnica del diagrama de flujo
- Diagramas de flujo de datos: Técnica de Yourdon
- Diagramas de actividad de roles (RAD)
- Diagramas de interacción de roles (RID)
- Gráfico de Gantt
- Definición integrada para el modelado de funciones (IDEF)
- Redes de Petri coloreadas (CPN)
- Métodos orientados a objetos (OO)
- Técnica de flujo de trabajo
- Simulación
- Notación de modelado de procesos empresariales (BPMN)
- Diagrama de actividades UML
- Modelos de procesos transformacionales
- Narración
- Modelos de procesos jerárquicos
- Visualización:
According to Bernard Lee, President of Charlotte Search Engine Consultants, there are other ways to model your projects visually. He points out that, “As a lifelong entrepreneur who started my first business at 20, I am now 53 and am considered a ‘college dropout.’ It has always been about systems, automation, and measuring risks to achieve our stated goals. This has been true in my career as a wealth manager, a Healthcare IT executive, and now as the founder of a digital marketing agency that specializes in SEO. Yes, SEO is about metrics, analytics, and CTR (click-through rate). Nevertheless, I've found the creative aspects is what separates the pretenders from the achievers. We are Google partners so we believe in the usual success measurements, but get there differently. YouTube, Geo-Tagging, and unorthodox combinations of our client's digital properties consistently land multiple properties on page one for the most important keywords. The visual of multiple positions on page one always has an immediate impact on our client’s brand, traffic, and conversions while moving competitors to page two.”
Asignación de procesos vs. Modelado de procesos
La asignación de procesos es una revisión general de una organización como una sola entidad con partes interconectadas. Se revisa el flujo de procesos empresariales a través de la organización para aclarar quién hace qué, cómo se llevan a cabo los procesos y según qué estándar se juzgan. En el modelado de procesos, los profesionales se centran más en lo eficientes que son los procesos, utilizando las mejores prácticas empresariales y económicas. Aunque ambos representan los procesos gráficamente, el modelado de procesos es una inmersión más profunda en las relaciones que producen los servicios y los resultados.
Marco para el Modelado y Evaluación de Procesos de Software (FMESP)
Una de las cuestiones complicadas que se derivaron del desarrollo de procesos empresariales estandarizados es la noción de que debe determinarse su eficacia. En otras palabras, ¿qué tan exitosos son los procesos empresariales? El FMESP se presenta como un conjunto de métricas para evaluar los modelos conceptuales de los procesos empresariales: qué hacen y qué no hacen. El FMESP mide la complejidad estructural de los modelos de procesos de software y, luego, las actividades, las funciones y los productos de trabajo. Este marco está destinado a proporcionar a las empresas información objetiva sobre la capacidad de mantenimiento de sus modelos.
Desarrollar buenos modelos de procesos empresariales
¿Cómo comienza un profesional con un modelo de BP? Uno de los enfoques comunes promueve la elección de un problema, la selección del método y luego la resolución del problema. Mantener un enfoque simple garantiza que todo lo relevante esté en el modelo y que todo en el modelo sea relevante.
Otros consejos profesionales incluyen:
- Asegúrese de saber quiénes serán sus recursos. Desarrolle listas de tareas, personas y el tiempo necesario para completar el modelo.
- Realice sus entrevistas en el orden en que aparezcan las funciones en el modelo del proceso.
- Registre absolutamente todo.
- Vuelva a verificar todos sus símbolos, asegúrese de que hay una clave y siga cada paso para asegurarse de que el camino lo lleve de vuelta o hacia adelante.
- Conozca el resultado deseado con anticipación.
- Determine sus puntos de salida y llegada.
- Obtenga con anticipación los documentos y formularios que forman parte del proceso.
- Utilice plantillas siempre que pueda.
Según Steve Wallis, cofundador/analista/consultor de ASK MATT, Foundation for the Advancement of Social Theory (FAST) - Teoría para un mundo mejor:
“BPM is incredibly useful for showing ‘what goes on’’ within a business organization. However, it can also create a false sense of comfort. When the map says, ‘You are here’ we feel a sense of security. However, unless the map shows how to get from ‘here’ to ‘there’ it is not going to be very useful. More importantly for the ever-shifting world of business, a map needs to show multiple paths so that leaders can take advantage of new options when unanticipated problems arise (and you know they will). Research in this area suggests that models (maps) which are more complex and have more interconnections are more useful for understanding how organizational processes work, and how they might be changed when the need arises. What does NOT work is a simple, linear model such as:
Fuente de la imagen: Steve Wallis
Oh, si solo la vida fuera tan fácil y predecible, pero no lo es. Por lo tanto, buscamos un enfoque ligeramente diferente para el modelado de procesos empresariales. Al llamarlo Mapa estratégico del conocimiento (SKM), nos centramos en los aspectos transformacionales del modelado. En lugar de modelar lo que está sucediendo a nivel de la “superficie” (por ejemplo, la investigación proporciona información a la fabricación), alentamos a nuestros clientes a ver qué cambios se producen en todos los pasos interconectados del proceso. A partir de nuestra investigación y experiencia, hemos desarrollado dos técnicas sencillas para desarrollar buenos modelos.
En primer lugar, para comprender una transformación en un modelo, debe haber más de una flecha que señale hacia cada cuadro. Por ejemplo, si hablamos de elaboración de panificados, el proceso de creación requiere de materia prima (harina, huevos, azúcar, chocolate, etc.), equipos (horno, estanterías, batidoras, etc.) y cocineros (con cierto nivel de experiencia). Por lo tanto, para comprender mejor la transformación, creamos un modelo que muestra cómo se combina cada una de esas “entradas” para crear la “salida” transformada. Para algunos, eso puede parecer obvio. Sin embargo, aquí aparece la información oculta (por ejemplo: relleno de chocolate): Si tiene un modelo en el que solo hay una flecha que apunta a algo, la falta de flechas adicionales indica una brecha en el modelo. Para gestionar el proceso, falta una ruta alternativa.
El segundo consejo para crear modelos efectivos es entender que cada flecha es “causal”. Este es uno de los grandes fragmentos de “conocimientos olvidados” en el mundo de los negocios. La causalidad es la esencia de la comprensión científica. Para comprender el proceso de transformación y los procesos empresariales en general, no basta con decir simplemente: “El cocinero mezcla los ingredientes y hace los pasteles”. Un buen gerente entiende que tener más materias primas, más equipo y más experiencia generará la transformación en un producto (o servicio) comercializable. Y, para gestionar ese proceso, puede haber algunas compensaciones entre ellos (un buen experto podría estirar un poco la materia prima), pero cada flujo es necesario para crear el producto final. Sin materias primas, ¡no tendré un pastel para acompañar mi café!”
Notación y modelado de procesos empresariales (BPMN)
Business Process Management Initiative (BPMI) desarrolló la BPMN como un estándar abierto del sector y Object Management Group (OMG) ahora la mantiene. Ninguna empresa de software o consultoría la posee. Es una notación gráfica para crear modelos de procesos, similar a los diagramas de flujo, que se utiliza y comprende en toda la industria. Muchas herramientas de software admiten la BPMN. Sin embargo, el significado de las formas y los símbolos son independientes de esas herramientas, y esos significados son precisos. La BPMN es una parte central de la gestión de procesos empresariales (BPM), una iniciativa de la arquitectura empresarial. La versión de la BPMN que se utiliza actualmente es v2.0, actualizada por última vez en 2011. Los profesionales pueden obtener la certificación en BPMN v2.0 a través del proceso de examen de OMG. La OMG también ofrece guías que muestran cómo la notación se divide en grupos de eventos, actividades, flujos, datos, artefactos, etc. Los elementos se clasifican en cuatro grupos principales que se conocen como objetos de flujo, objetos de conexión, carriles y artefactos.
Fuente: OMG
La intención de la BPMN es que los usuarios técnicos y los usuarios empresariales puedan entender un lenguaje diagramático común. La BPMN se basa en una técnica de diagrama de flujo similar a la desarrollada a partir del Lenguaje unificado de modelado (UML), y puede asignarse directamente al Lenguaje de Ejecución de Procesos de Negocios (BPEL), un lenguaje basado en XML que se utiliza para definir los servicios empresariales dentro de los servicios web.
Crítica de la BPMN
La opinión del sector varía sobre el uso de la BPMN para el modelado de BP. Los críticos argumentan que la BPMN es mucho más compleja y avanzada de lo que debe ser para las partes interesadas que pueden no estar muy cercanas al proceso real. Además, con tantos símbolos es fácil cometer errores, lo que va contra el propósito de su uso.
Los defensores de la BPMN dicen que la mayoría de los profesionales solo utilizan un puñado de símbolos, por lo que el conocimiento de símbolos poco claros es innecesario. Algunas empresas internacionales requieren la consistencia de la BPMN, especialmente cuando los lenguajes pueden ser variados. Comprender los procesos con una notación estandarizada no resulta tan desafiante.
Otros tipos de notaciones y diagramas
En 2012, Cristina Venera realizó un estudio de dos lenguajes de notación populares, BPMN y Diagrama de actividades UML (UML AD). Entre profesionales y bibliografía, descubrió que ambos lenguajes son igualmente fáciles de entender para las partes interesadas en el modelado de BP, y que, de hecho, ambos proporcionaron soluciones similares. Sin embargo, la diferencia fue que la BPMN puede asignarse a (WS)BPEL, mientras que UML AD no puede asignarse automáticamente a ningún BPEL.
Otros tipos de notaciones incluyen la Cadena de procesos controlados eventos (EPC), diagramas de flujo de trabajo y mapas conceptuales. La EPC se utiliza con mayor frecuencia para procesos empresariales de alto nivel, consta de cinco elementos y reglas, y siempre comienza y termina con un evento. Hay reglas intermedias: “OR”, “AND” o “XOR” representados como conectores gráficos.
Los diagramas de flujo de trabajo ilustran las etapas y las relaciones entre todas las partes de una empresa. En los diagramas de flujo de trabajo, no hay un conjunto de símbolos acordados (estándar). Es más difícil comparar los modelos realizados en toda una organización, pero ofrece más libertad para la creatividad.
Los mapas conceptuales son los menos restrictivos de cualquiera de las técnicas que se mencionan aquí. Aunque por lo general son jerárquicos, se pueden hacer a mano en una servilleta de un bar, si es necesario. Los mapas conceptuales son una forma de mostrar las relaciones en torno a un solo concepto, así como asociaciones. Fluyen libremente y permiten la máxima creatividad.
Fuente: Jennifer Frith
Qué buscar en el software de modelado de procesos empresariales
De todas las opiniones e investigaciones de los expertos, no parece haber una herramienta que se ajuste a todas las necesidades de una organización. Los principales requisitos que se recomiendan para una herramienta o un conjunto de herramientas son que sean rápidas (de aprender) y económicas. La página de inicio de BPMN enumera 74 herramientas que cumplen con BPMN. Si el cumplimiento de BPMN es un requisito, la búsqueda ya está limitada. De lo contrario, los usuarios deben especificar sus objetivos y requisitos, qué herramientas satisfacen sus requisitos, cuáles son los criterios más significativos y cuáles podrían ser las herramientas potenciales para su uso. Luego, PROBARLAS. Encontrar la herramienta adecuada puede ser un proceso, pero no será uno del que se arrepienta.
Según Norbert Nogrady, director general y copropietario de JCM Ltd: norbert.nogrady.bpralumni@gmail.com, Twitter: @kgordos
“I started to reorganize organizational units more than 15 years ago. At the time, the number of available process modeling tools was very limited, much less their functionality. However, as time went by, I witnessed the evolution of such tools. In the beginning, I used large sheets, then Microsoft Word and Visio. However, I had a number of serious issues with these tools. The biggest problem is that BPR projects tend to be lengthy and thus overwhelming. The usual routine at the large corporations I worked for was (one of the following):
- El equipo directivo le encargó al departamento de TI que encontrara una herramienta para la gestión de procesos empresariales (flujo de trabajo) que se ajuste a los requisitos de TI.
- Los líderes del equipo directivo, junto con ingenieros de BPR, crearon sus respectivos procesos
- Los diagramas de procesos se habían creado utilizando varias herramientas.
- Luego, los procesos se transfirieron al departamento de TI, para que pudieran evaluar si los procesos se ajustan al sistema de flujo de trabajo de su elección.
- Después de una serie de iteraciones, la mayoría de las cuales se traducen en concesiones con respecto a los procesos, el departamento de TI comenzó a programar los procesos en el sistema de flujo de trabajo.
- Los procesos se implementaron en la organización, con la necesidad inmediata de rediseñar muchos de ellos.
- Los puntos del dos al seis se han repetido durante mucho tiempo hasta que se creó un conjunto un tanto aceptable de procesos empresariales.
De lo anterior queda claro que implementar BPR de esta manera no fue fácil, sino que consumió mucho tiempo y recursos. Además, enseguida me di cuenta de que los departamentos debían crear sus propios procesos, en lugar de iterarlos con TI; de esta manera, podrían evitarse una serie de concesiones en los procesos. Además, llevó mucho tiempo implementar los procesos creados en el sistema de flujo de trabajo mediante programación. Ambos problemas me molestaron tanto que comencé a buscar una solución que se adaptara a los requisitos habituales de TI y respaldara plenamente mis actividades de BPR”.
Después de mucho ensayo y error, Nogrady finalmente encontró una solución que funcionó para él. Después de su búsqueda exitosa, sugiere buscar un sistema de flujo de trabajo que tenga una herramienta editora de procesos y flujos de trabajo integrada con una interfaz gráfica, lo que hace que la programación de procesos sea obsoleta. La ventaja es que una vez que se ha creado un proceso en el editor de flujo de trabajo gráfico, solo se necesita hacer clic en un botón para que se ejecute de inmediato en el sistema de flujo de trabajo. Por lo tanto, todos los departamentos pueden crear sus propios procesos empresariales, sin la necesidad de programación. Seguir esta ruta significa que hay pocas concesiones, si las hay, en los flujos de trabajo y, lo que es más importante, se podría ahorrar mucho tiempo y recursos de esta manera. Por último, una buena solución hará que las pruebas de los procesos tomen mucho menos tiempo y esfuerzo. De esta manera, si un proceso necesitara alguna mejora, cualquier persona del departamento puede hacer sugerencias, y si el líder del departamento las aprueba, el proceso modificado debería poder ejecutarse en el sistema de flujo de trabajo en un par de horas.
El futuro del modelado de procesos empresariales
Un área crítica de preocupación para el futuro del modelado de BP incluye cómo se podrían estandarizar los enfoques de modelado. Muchas empresas se están trasladando a una plataforma más Agile, y el modelado de BP no necesariamente va de la mano con los procesos Agile. Un enfoque de modelado solo puede considerarse Agile para algunos tipos de procesos, según un estudio reciente de Nancy Alexopoulou.
Como señala Ian Gotts, fundador y director ejecutivo de Elements.cloud y columnista de Digital Business, “hay grandes problemas en el espacio de modelado de BP. Los proveedores de software BPM, automatización y flujo de trabajo han secuestrado BPM, de modo que la B de BPM ha desaparecido. El modelado ha llegado a significar definir los flujos de trabajo por TI para TI. Sin embargo, la visualización de procesos (modelado de procesos empresariales) es valiosa para los usuarios finales. Utilizan los diagramas de procesos empresariales para acordar cómo se realiza el trabajo. Esto proporciona la perspectiva de TI entre bastidores. Sin embargo, intentar usar la notación de BPMN como modelo para todos es difícil de lograr; tiene tantos símbolos que parece intrincado, y los empresarios se desligan rápidamente y se preguntan por qué están haciendo esto.
“There is a notation - Universal Process Notation (UPN) - that works for business people, that has been very successful. It is outlined in Chapter two of the e-book, Analysis, Automation & Adoption for #AwesomeAdmins. The first principle that is relevant here is that we are not building a huge flowchart, but a hierarchical process map, where every diagram is easier to follow. For example, at a bank, there may be 10,000 diagrams for all of the processes, but they are organized in a hierarchy so no diagram is overwhelming. Second, the notation is a simple model using an activity box or step with inputs and output, resources identified (or swimlanes), and hyperlinks to supporting information. This process map is useful for end users, but it is also valuable for compliance, IT, and management where metrics can be viewed in the context of a process. Using this approach is valuable for app vendors to improve adoption. An end-to-end process can make sense of the detailed flow of apps.”
Más información sobre el modelado de procesos empresariales
¿Le interesa obtener más información sobre el modelado de BP y cómo implementarlo en su empresa? Las siguientes son listas de recursos adicionales que pueden ser útiles.
Libros y libros electrónicos
- Analysis, Automation & Adoption for #AwesomeAdmins - Manual de software de UPN gratuito
- A Pragmatic Guide to Business Process Modelling, de John Holt
- Essential Business Process Modeling, de Michael Havey
- Business Process Modeling, Simulation and Design, Segunda edición, de Manuel Laguna y John Marklund
Documentos técnicos
- Strategic Knowledge Mapping For Improved Policy and Strategic Planning, de Steven E. Wallis y Bernadette Wright.
- Strategic Knowledge Mapping: The Co-Creation of Useful Knowledge, de Steven E. Wallis y Bernadette Wright.
Software
- Una lista de software gratuito de modelado de procesos de empresariales
- Comparación de las herramientas de notación de modelado de procesos empresariales
- Guía de mercado para el análisis de procesos empresariales - de Gartner
Otros tipos de diagramas
Cómo Smartsheet puede ayudar a mejorar los procesos de negocios
Empodere a sus empleados para que vayan más allá gracias a una plataforma flexible, diseñada para satisfacer las necesidades de su equipo y capaz de adaptarse cuando esas necesidades cambien. La plataforma Smartsheet facilita la planificación, la captura, la gestión y la creación de informes sobre el trabajo, desde cualquier lugar, lo que ayuda a su equipo a ser más eficiente y lograr más. Cree informes sobre las métricas claves y obtenga visibilidad en tiempo real acerca del trabajo en curso gracias a informes, paneles y flujos de trabajo automatizados diseñados para ayudar a su equipo a mantenerse conectado e informado. Cuando los equipos tienen claridad sobre el trabajo en curso, pueden lograr mucho más en el mismo tiempo. Pruebe Smartsheet gratis hoy mismo.