La especialización del Grupo de Empresas Abazhur es la implementación de diversos proyectos de construcción basados ​​en contratos EPC/EPCM... Pero para aquellos que están en búsqueda y aún no saben qué son EPC y ERSM, ofrecemos una colección de materiales que, Esperamos que sirva de ayuda para nuestros socios y clientes a la hora de trabajar con instrumentos relativamente nuevos para la práctica nacional como los contratos EPC, EPC (M).

Estructuración, celebración y ejecución de contratos EPC y EPC(M)

El Grupo de Empresas Abazhur se especializa en la implementación de diversos proyectos de construcción basados ​​en contratos EPC/EPCM, así como otros contratos de construcción con condiciones individuales. , aplica soluciones de sistemas en la construcción utilizando modelado BIM, crea diseños de edificios que logran una baja intensidad de capital.

Los contratos EPC/EPCM son el tipo de contrato más común en la industria de la construcción.

Al elegir una forma u otra, es importante recordar que el tipo de contrato puede conducir a un cambio significativo en el nivel de costos y riesgos asociados con la construcción de estructuras grandes y grandes. El nivel de costes es proporcional a los riesgos asumidos por el cliente. A medida que disminuyen los riesgos comerciales asumidos por el propietario, aumentan los costos de construcción de la instalación y su gestión. En cualquier negocio, esto se ve lógicamente confirmado por la relación riesgo-recompensa.

Las obligaciones asumidas por el contratista general suelen incluir la prestación de cuatro tipos de servicios:

• Ingeniería– trabajos de estudio, creación de proyectos, aprobación de documentación;
• Obtención– selección, compra y suministro de equipos y materiales necesarios para completar todo el trabajo;
• Construcción de un objeto– trabajos de construcción, montaje y puesta en servicio;
• Gestión de todos los procesos constructivos (Construction Management).

Estrategia contractual para la implementación de grandes proyectos de construcción.

A menudo es posible reducir el tiempo de construcción debido a que el contratista EPC, siendo la única persona responsable ante el cliente, puede desarrollar y emitir la documentación de diseño y trabajo en paralelo con la compra de materiales y equipos, así como con los trabajos de construcción e instalación.

Por ejemplo, el contratista EPC no tiene que esperar el desarrollo y aprobación de toda la documentación del proyecto para comenzar a contratar equipos con un ciclo de fabricación largo.

El uso eficaz del diseño paralelo permite en algunos casos reducir significativamente el tiempo total de construcción. Esto es especialmente cierto para algunos proyectos de gas, especialmente proyectos asociados de procesamiento/tratamiento de gas de petróleo, donde puede haber un pico en la producción en cuyo momento se debe construir una instalación de tratamiento de gas; de lo contrario, la rentabilidad general del proyecto se verá seriamente afectada. En tales casos, está justificado utilizar el modelo EPC para la ejecución del proyecto, que, a pesar del mayor coste, permite completar la construcción en menos tiempo.

Cada estrategia de contrato (el modelo "tradicional" de gestión de las fuerzas del cliente y el modelo EPC) tiene sus propias fortalezas y debilidades. A modo de comparación, proporcionamos tablas que sistematizan los aspectos negativos y positivos de cada estrategia.

Contrato EPC(M)

EPC(M): la estructura es una solución de contrato que, desde el punto de vista de la distribución de riesgos, se encuentra a medio camino entre los modelos de contrato multilote y EPC. Cabe señalar de inmediato que no existe una comprensión única e inequívoca de lo que se considera un contrato EPC(M). Un acuerdo de este tipo puede entenderse, por ejemplo, como una situación en la que el contratista EPCM actúa únicamente como consultor y no celebra ningún acuerdo de subcontratación en nombre propio.

Del mismo modo, un contrato EPC(M) puede denominarse contrato general de ciclo completo, pero en el que el precio se determina según el principio “ libro abierto"(libro abierto) o "reembolso" (coste + tarifa, reembolsable)*. La complejidad en la terminología también se debe al hecho de que ninguna de las principales organizaciones internacionales (FIDIC, ICC Orgalime) ha emitido un acuerdo EPC(M) proforma.

* En nuestra opinión, es más correcto llamar a este tipo de contratos.
EPC a libro abierto y EPC reembolsable o costo más tarifa respectivamente

EPC(M) es la abreviatura en inglés de Engineering Procurement Construction Management. Al mismo tiempo, la traducción correcta de esta abreviatura al ruso es "Diseño, suministro, gestión de la construcción". En el modelo EPC(M), la palabra gestión suele referirse específicamente a la construcción en el sentido estricto de la palabra, es decir, para realizar la construcción, instalación y otros trabajos en el sitio.

Sujeto a las reservas expresadas anteriormente sobre ambigüedad en la terminología:

Un contrato EPCM suele entenderse como tal estructura cuando el contratista EPC(M) por nuestra cuenta o por la fuerza compañía subsidiaria realiza el diseño, realiza de forma independiente la contratación de equipos y materiales, pero en cuanto a los trabajos de construcción e instalación realiza únicamente la gestión, es decir. no contrata contratistas de construcción e instalación por cuenta propia, sino que solo gestiona a los contratistas contratados por el cliente en nombre del cliente.

La diferencia fundamental entre el acuerdo EPC(M) y el contrato EPC es que el contrato EPC es un acuerdo sobre "aceptación de responsabilidad y riesgos"

Al celebrar un contrato EPC, el cliente transfiere en gran medida los riesgos y la responsabilidad al contratista EPC, que debe dotar a esta responsabilidad de bienes líquidos. El contrato EPC(M) es un acuerdo sobre servicios profesionales, el cliente “compra” competencias, la responsabilidad del contratista EPC(M) por el calendario y el presupuesto del proyecto está ausente o es insignificante en comparación con el coste del proyecto y, por tanto, tiene un carácter exclusivamente estimulante.

Posible varias opciones estructuración de precios en el contrato EPC(M), pero nunca se fija. A menudo, el precio es una combinación de tarifas de tiempo (para aquellas funciones que el contratista EPCM realiza personalmente: diseño, gestión de adquisiciones, gestión de la construcción) y el principio de "libro abierto".

Este principio significa que

• la subcontratación se realiza de forma transparente para el cliente y con la participación de sus representantes;
• el contratista divulga su propia estructura de costos generales, así como el monto de la ganancia esperada y dichos gastos generales/beneficio se fijan en una cantidad específica o se agregan como un margen porcentual al costo de cada contrato de suministro.

Como ya se ha señalado, la responsabilidad del contratista EPC(M) es muy limitada y recuerda más a la responsabilidad de un ingeniero consultor (que sólo es responsable de la prestación deshonesta o incompetente de sus propios servicios) que a la responsabilidad de un contratista general. .

Al mismo tiempo, muy a menudo en los contratos EPC(M) existen mecanismos para estimular al contratista utilizando los principios bonus/malus (el llamado reparto de ganancias / reparto de dolores).

Por ejemplo, el contrato podrá prever que la puesta en servicio de la instalación en más fecha temprana el contratista recibe una remuneración adicional; si hay un retraso, el contratista, por el contrario, pierde parte de las ganancias.

De manera similar, se pueden construir incentivos en relación con lo general: las partes pueden establecer un presupuesto objetivo determinado y si, al gestionar eficazmente la construcción, el contratista logra ahorros, entonces dichos ahorros se dividen entre las partes en una proporción acordada. Sin embargo, el contratista EPC(M), al acordar un bono/malus, normalmente no está dispuesto a arriesgar toda la recompensa y, por lo tanto, este mecanismo no brinda al cliente total tranquilidad con respecto al costo y el momento de la construcción, sino que solo está dirigido a creando un interés material para el contratista en implementación exitosa proyecto.

Una de las ventajas del contrato EPCM en comparación con el modelo EPC es el hecho importante de que la licitación para la selección del contratista EPCM puede prepararse y realizarse mucho más rápido que la licitación para la adjudicación del contrato EPC a tanto alzado. El hecho es que en el primer caso se requiere un menor nivel de certeza por parte del cliente sobre el alcance del trabajo, los límites de entrega y los riesgos; y el contratista sólo necesita preparar una propuesta de precio para los tiempos, los gastos generales y sus propios beneficios; no está obligado a preparar una propuesta de precio firme para el coste total del proyecto.

Por el contrario, al licitar según el modelo de suma global EPC, el cliente debe preparar tarea técnica y requisitos (si el nivel de elaboración es insuficiente, los contratistas pueden negarse a presentar propuestas con un precio fijo o evaluar los riesgos a un nivel muy alto); Asimismo, el contratista necesita un orden de magnitud más de tiempo para preparar una propuesta con un precio firme que tenga en cuenta todos los riesgos.

Métodos modernos construcción, materiales y tecnologías de alta calidad, funciones de control de construcción y contratista general, edificios industriales y comerciales, instalación de estructuras prefabricadas. ¡Construcción de objetos de cualquier complejidad!

Términos:

Contratista EPC- es una persona que realiza el volumen principal de trabajo de un proyecto de inversión por un precio fijo y asume todos los riesgos de su implementación desde el momento del diseño hasta el momento de la transferencia del objeto terminado al cliente (incluido el cumplimiento de la garantía). obligaciones), por lo que asume la responsabilidad financiera ante el Cliente.

Se utiliza, por regla general, en aquellos proyectos en los que puede estimar con suficiente precisión el tamaño de sus gastos, así como el grado de riesgos.

El contrato EPC requiere que el contratista EPC realiza la mayor parte del trabajo por su cuenta, por lo tanto no se proporciona remuneración especial para organizar y gestionar el trabajo de los contratistas de nivel inferior involucrados.

contratista EPSM puede celebrar contratos con subcontratistas por cuenta propia o gestionar contratos celebrados por el cliente con ejecutores de trabajos específicos.

El contrato EPSM proporciona y el coste total del proyecto, teniendo en cuenta la remuneración del contratista EPSM, y un plazo fijo para la puesta en funcionamiento de la instalación, alcanzando los principales parámetros técnicos de la instalación. El método (enfoque) EPSM le permite gestionar un proyecto y no un trabajo específico. Los trabajos específicos son realizados por profesionales. La tarea de EPSM es evaluar las propiedades requeridas (capacidades, profesionalismo, recursos, etc.) de los contratistas/proveedores seleccionados y distribuir correctamente el trabajo y las áreas de responsabilidad entre ellos. A continuación, coordinar sus acciones, resolver cuestiones controvertidas, planificar el esquema general del proyecto, cambiar los planes en caso de cambios críticos con consecuencias mínimas y luego con todas sus fuerzas.

La práctica mundial de implementación de proyectos de inversión destaca los contratos EPC y EPSM como las estrategias más prometedoras para implementar proyectos industriales complejos, que representan alrededor del 80% de los proyectos implementados.

Lea con más detalle la publicación elaborada por.

Si tiene alguna pregunta o comentario, puede hacerlo; todos serán considerados con gratitud.

Un diagrama de función EPC debe comenzar con al menos un evento de inicio (el evento de inicio puede seguir a la interfaz del proceso) y terminar con al menos un evento de finalización (el evento de finalización puede preceder a la interfaz del proceso).

Los eventos y funciones deben alternarse a medida que avanza el proceso. Las decisiones sobre el curso posterior del proceso se toman por funciones.

El número recomendado de funciones en el diagrama no es más de 20. Si el número de funciones en el diagrama excede significativamente 20, entonces existe la posibilidad de que los procesos en el nivel superior estén identificados incorrectamente y sea necesario ajustar el modelo.

Los eventos y funciones deben contener estrictamente una conexión entrante y una saliente, reflejando el progreso del proceso.

Los eventos y declaraciones que rodearon la función en el diagrama anterior deben ser los eventos y declaraciones iniciales/resultantes en el diagrama de descomposición de la función.

El diagrama no debe contener objetos sin una única conexión. Cada operador de fusión debe tener al menos dos enlaces entrantes y solo un enlace saliente, y cada operador de sucursal debe tener solo un enlace entrante y al menos dos enlaces salientes. Los operadores no pueden tener múltiples conexiones entrantes y salientes al mismo tiempo. Si un operador tiene una conexión entrante desde el elemento "evento", entonces debe tener una conexión saliente con el elemento "función" y viceversa. Un único evento no debe ir seguido de un operador OR o XOR. Los operadores pueden fusionar o bifurcar solo funciones o solo eventos.

Arroz. 2.62 Ejemplo de un diagrama de proceso en notación EPC

Arroz. 2.63 Ejemplo de situación aceptable 3	Arroz. 2.64 Ejemplo de situación aceptable 4

Un ejemplo de una situación inaceptable.

Arroz. 2.65 Ejemplo de situación inaceptable

métodos de estadística gestión de proceso

Se dan ejemplos de los métodos más populares de análisis estadístico y se propone un mecanismo para su evaluación.

Análisis del diagrama de Pareto

En empresas industriales Constantemente surgen todo tipo de problemas: defectos, mal funcionamiento del equipo, etc. En la mayoría de los casos, la abrumadora cantidad de defectos y pérdidas asociadas surgen debido a un número relativamente pequeño de razones, y la proporción de los costos de material es de aproximadamente el 70 al 80%. Para saber cuáles de estos motivos o factores son los principales se construye un diagrama de Pareto.

El diagrama de Pareto es una herramienta que permite presentar e identificar objetivamente las principales causas que afectan el problema en estudio. Hay dos tipos de diagramas de Pareto: por resultados de actividades y por causas.

El gráfico de desempeño está diseñado para identificar el problema principal y refleja los siguientes resultados de desempeño indeseables:

· Costo: volumen de pérdidas, costos;

· Seguridad: accidentes, averías;

· Plazos de entrega: incumplimiento de plazos, falta de inventario.

El diagrama de causas de Pareto refleja las causas de los problemas que surgen durante la producción:

· Ejecutor del trabajo: turno, equipo, etc.;

· Equipos: máquinas, unidades, herramientas, etc.;

· Métodos de trabajo: secuencia de operaciones, condiciones de producción;

· Medidas: precisión, reproducibilidad, estabilidad.

La construcción de un diagrama de Pareto consta de los siguientes pasos.

Paso 1. Determinar qué problemas deben investigarse y cómo recopilar datos; cómo clasificarlos. Establecer el método y el período de recopilación de datos.

Paso 2: Desarrollar una lista de verificación de registro de datos que enumere los tipos de información que se recopilarán.

Paso 3. Complete la hoja de registro de datos y calcule los totales.

Paso 4. Desarrolle una hoja de cálculo para las verificaciones de datos, que incluya un gráfico de los totales de cada artículo verificado por separado, la suma acumulada del número de defectos, el porcentaje del total y el interés acumulado. Al mismo tiempo, ordene los datos por orden de importancia.

Tabla 3.1.1 Construcción del diagrama de Pareto

Paso 5: dibuja un eje horizontal y dos verticales. Ejes verticales: en el eje izquierdo, coloque una escala con un intervalo de 0 al número correspondiente al gran total; en el eje derecho, una escala con un intervalo de 0 a 100%. Divida el eje horizontal por el número de funciones controladas.

Arroz. 3.1.1 Diagrama de Pareto

Etapa 6. Construya una gráfica de barras donde cada tipo de matrimonio tenga su propio rectángulo.

Paso 7. Dibuja una línea acumulativa.

Al construir un diagrama, debes prestar atención a los siguientes puntos:

· El diagrama resulta más eficaz si el número de factores es 7 – 10;

· Al procesar datos, es necesario estratificarlos según parámetros individuales (momento de selección de datos, tipo de productos, lote de materiales, operador, etc.);

· Si el “otro” factor resulta ser demasiado grande, se debe repetir el análisis del contenido de este factor;

· El cuadro debe realizarse de forma sistemática. Pareto para el mismo proceso, lo que permitirá seguir la tendencia en el número de defectos para cada factor (Fig. 3.1.1).

Partituras para negocios.

La música nos ha atado
Se ha convertido en nuestro secreto.

Todos los epígrafes de este artículo están tomados de la canción “Music Has Connected Us” de la banda Mirage.

En la música clásica, el músico es un instrumento en manos del compositor y toca según las notas. En la música popular, los músicos suelen escribir la música ellos mismos y el arte de la improvisación no implica notas en absoluto. Es cierto que las improvisaciones famosas que se han convertido en clásicos se traducen luego en partituras y tienen nueva vida: el arreglo cambia, se agrega un nuevo sonido y estado de ánimo.

Así es el negocio que ha crecido como una hábil improvisación para trasladarse a nuevo nivel requiere poner los hechos en papel para analizar lo que está sucediendo y tomar decisiones de mejora.

Recientemente, cada vez es más frecuente encontrar descripciones de procesos de negocio (BP), realizadas, como suele decirse, "por tu cuenta". Fue esta circunstancia la que motivó la redacción del artículo. Desafortunadamente, la mayoría de estos documentos que vi fueron de poca utilidad para negocios serios. Esto no quiere decir que fueran fundamentalmente incorrectos, pero una serie de omisiones los estropearon tanto que quise olvidarme inmediatamente de su existencia. Qué tipo de omisiones son y cómo abordarlas, lo descubriremos a lo largo de este artículo, acercándonos gradualmente a la esencia del problema. Intentaremos evitar una gran cantidad de detalles técnicos, pero no podemos evitarlos por completo, porque... el tema de la conversación lo requiere.

¿Soy realmente yo?
No puedo encontrar la respuesta a todo

Este artículo está dirigido a quienes quieren ahorrarse la descripción de los procesos de negocio confiando la elaboración del documento a especialistas internos. Después de todo, una descripción de los procesos comerciales no es obligatoria para una empresa y todo funciona sin ella. Pero en toda empresa estable existe un mecanismo de transferencia de autoridad, se llama " descripciones de trabajo"Si el negocio es complejo y el puesto es clave, entonces es útil dibujar descripciones de puestos para que sea más fácil de entender. Acumulación de procesos de negocio en descripción general necesario para hacer más transparente el negocio, especialmente para su venta.

El documento "Descripción de BP" adquiere especial relevancia tan pronto como surge la necesidad de reorganizar (o, como ahora está de moda decir, reingeniería) de la empresa. En este caso, el documento se utiliza para:

1. En él, como en un mapa de batalla, marque la esencia de las transformaciones planificadas,
2. Actualizar al participante de la transformación,
3. Utilice un bolígrafo y no los dedos para asignar tareas a los jefes de departamento y especialistas externos.

Hay ventajas de preparar el documento usted mismo:

• Resulta más barato;
• Especialista interno, mejor versado en las prácticas de su negocio natal.

Un consultor externo primero tendrá que estudiar la terminología y características clave tema, estándares de la industria. Esto lleva tiempo. Es cierto que él sabe mejor cómo y qué se debe describir. Existen ciertas reglas, notaciones generalmente aceptadas y software especial. Un ejemplo de dicha notación se puede ver en la Fig. 1 y fig. 2.

Notación IDEF0

Un ejemplo de descripción de una fuente de alimentación utilizando IDEF0

No nos sermonees

No me sermonees
Mamá, esto es inútil.

Realmente necesitamos esto? - preguntará el director, asumiendo razonablemente que el cumplimiento de todos los estándares aumentará significativamente el coste del resultado. Uno de los directores que conozco razonó así: "Invitar a un especialista externo es un negocio costoso, pero nuestras tareas son simples: ¿por qué necesitamos todas estas notaciones? Y el especialista, a veces dibuja algo con sus ganchos, no hay nada". Claro, no conviene admitirlo, así que todavía está atrasado. Esto es por lo que tienes que pagar ".

Estoy de acuerdo, si las tareas son sencillas, ¿para qué molestarse? Y si son complejos, entonces es necesario simplificarlos y no complicarlos con notaciones sofisticadas. Después de todo, no existen ventajas obvias al utilizar hermosos anzuelos. Si no los hay obvios, esto no significa que no los haya. Estas reglas y notaciones no fueron inventadas para que el consultor no se aburriera... Cualquiera que se dedique a los negocios sabe bien que no todo lo útil es obvio. Bueno, busquemos lo positivo oculto y, para ello, echemos un vistazo a la historia del problema.

El mercado de descripción de fuentes de alimentación existe desde hace mucho tiempo. Sin embargo, durante la última década y media, ha logrado un rápido avance gracias al surgimiento de una nueva industria: la automatización de la contabilidad y la gestión en las empresas. El mercado en crecimiento brindó a los recién llegados que idearon nuevas notaciones la oportunidad de abrirse paso y marcar su lugar. Por ejemplo en mercado ruso en algunas años recientes Las campañas masivas de publicidad e información por parte de IDS Scheer (el principal proveedor de ARIS, ver Fig. 3) crearon una capa de especialistas en la descripción de procesos automatizados.

El uso de la notación ARIS requiere un gran detalle de los procesos comerciales.

La implementación de sistemas como ERP (gestión de recursos), CRM (relación con el cliente), MRP (planificación de la producción) conlleva inevitablemente cambios en los procesos, y si esto no se planifica con antelación, el resultado puede ser peor de lo deseado. Además, la automatización trabaja con información, lo que significa que es útil saber qué información genera quién, de dónde viene y adónde va. Pero las notaciones especiales para introducir la automatización nunca se han arraigado aquí y rara vez se utilizan.

La descripción de los procesos de negocio en Rusia es una tendencia relativamente reciente, a pesar del impresionante número de GOST en este ámbito (3.1109, 34, ISO, etc.). Ahora, con la calidad de la descripción de sus propios procesos de negocio, las cosas van mejor en los bancos. El caso es que, a diferencia de otras estructuras comerciales, un banco es una organización de infraestructura y, por tanto, se encuentra dentro del estricto marco de las normas definidas por la ley. El banco opera según el principio de gestión diaria. Como resultado, incluso una descripción simplificada de los procesos comerciales del Banco (en ruso sin el uso de anotaciones) resulta más detallada, porque se basa en una base construida sobre volúmenes de regulaciones que definen estándares, terminología, roles y reglas. Estos estándares son el lenguaje generalmente aceptado en el entorno bancario y la descripción de los procesos comerciales será fácil de leer para cualquier especialista.

EN estructuras comerciales La descripción de los procesos de negocio requiere un diccionario preliminar de términos. Y al empezar a prepararlo y coordinarlo, muchos se enfrentan al hecho de que las mismas cosas se llaman de forma diferente en distintos departamentos. Entrando en detalles, resulta que diferentes nombres en realidad tienen diferentes matices de significado. La coordinación de la terminología es uno de los procesos que requiere más mano de obra a la hora de describir un proceso empresarial. Es importante poner en marcha este proceso. Puedo asumir la mayor parte del trabajo desde las propias divisiones de la empresa, porque la necesidad de regular sus actividades conlleva una mayor organización de procesos y procedimientos.

Cuando se requiere una descripción para la automatización, también es posible la secuencia inversa. El cambio de los procesos de negocio se realiza en paralelo con la implementación del sistema de información, y la descripción de los nuevos procesos de negocio se lleva a cabo "pisándole los talones" y es parte integral de la documentación del sistema.

Personal

Yo olvidé todo
Nos han enseñado durante tantos años.

Curiosamente, la elección de la notación y la exactitud de la descripción son más críticas para las pequeñas y medianas empresas. Grandes compañias suelen tener una mayor elasticidad del proceso debido a la intercambiabilidad de los empleados. Para una pequeña empresa, donde la ejecución de los puntos críticos depende de 2 o 3 tomadores de decisiones, una indicación incorrecta de la ruta del proceso puede dar lugar a un concepto fundamentalmente incorrecto de la solución. Dado que el resultado es crítico, entonces la herramienta es importante, pero ¿cómo elegirla?

Cada notación está adaptada para una gama específica de tareas. Consideraremos que la tarea más urgente es cambiar los procesos de negocio en el marco de un proyecto de automatización de la gestión. Para estos fines, existe un buen conjunto de herramientas que están bastante extendidas: se trata de los GOST rusos, y los mismos ARIS, IDEF y EPC (Fig. 4 y Fig. 5).

notación EPC

Descripción de un proceso de negocio utilizando EPC

Si un libro está escrito en un idioma determinado, lo más importante es tener un lector que conozca ese idioma y pueda leerlo. En base a esto, el estándar más común para describir la PA es el mejor.

Al elegir una notación, otro criterio importante es la capacidad de utilizar una herramienta de software familiar. Por ejemplo, Microsoft Business Solution ofreció en 2002 la notación On-Target para el sistema de información Navision, acompañada de una solución de software especial. Este es precisamente el caso en el que es mejor elegir otra cosa: no sólo nadie conoce la notación On-Target, sino que además el entorno del software requerirá tiempo para estudiarla. Un ejemplo positivo lo llamaría el uso de la notación IDEF y el programa Visio, que está muy extendido y cuenta con el conjunto de herramientas necesario para dibujar diagramas IDEF (Fig. 6).

Procesos de negocio IDEF realizados en Visio

Por supuesto, la descripción de la fuente de alimentación se puede hacer simplemente con palabras, además de utilizar varios símbolos (de su propia invención) ya que parece comprensible. Tener esa descripción es mejor que nada, pero mantener los estándares sigue siendo útil.

Plenitud y profundidad del sonido.

No sé qué me atrae aquí

1. tomará mucho tiempo
2. Algunos detalles cambiarán durante la creación del documento.

Un error común es intentar ajustar las descripciones a la notación. Por ejemplo, intentar describir procedimientos en formato ARIS, es decir lograr una aparente redundancia en la descripción cuando no es necesaria.

Pero más Error común La profundidad del documento es insuficiente. Como resultado, el resultado es un documento formal que no es apto para el trabajo, porque Todos los detalles importantes deben aclararse en el proceso.

Una melodía es una secuencia de sonidos, no notas.

Olvídate de este día
Nadie necesita un argumento

Esto significa que la fuente de alimentación se puede describir simplemente con palabras, sin anotaciones. Por supuesto, la notación es más correcta, pero eso no es lo importante. Descripción BP no es un producto final, sino sólo una herramienta para nuevos logros. Esto significa que debe adaptarse para un uso activo posterior. El principal problema de la mayoría de los documentos que puede hacer usted mismo es que resultan incómodos de utilizar. Por ejemplo, uno de esos documentos consistía en una descripción de lo hecho en Microsoft Word y dibujos realizados en PowerPoint; saltar de un programa a otro era terriblemente inconveniente, tenía que gastar un gran número de Es hora de ponerlo todo en un solo documento. Resulta que el documento debe tener las siguientes propiedades:

1. Tener un orden y agrupación claros de las secciones, es decir ser conceptualmente holístico (normalmente esto significa que si tienes un concepto, entonces has aprendido a utilizarlo);
2. Identificar claramente las unidades de negocio y darles nombres y numeraciones claros;
3. Resalte claramente los procesos comerciales y déles también un nombre y una numeración claros;
4. Los elementos deben numerarse de tal manera que se evite confusión (esto facilita mucho la búsqueda): por ejemplo, el Departamento No. 1 debe tener el número Dept.001 en el documento y el Proceso de Negocio No. 1 debe tener el número BP001. ;
5. El documento debe tener una sección de contenidos con estructura de árbol;
6. Una empresa es un organismo integral y ningún proceso de negocio queda en el aire: siempre está conectado con otras unidades de negocio, unidades de negocio y departamentos. Para reflejar estas conexiones, puede utilizar hipervínculos; esto facilitará la búsqueda de información y el paso de un objeto a otro.

Cualquier cosa se puede utilizar para los negocios. editor de texto hipervínculos de soporte.

Algunos creen que en el ámbito profesional. Grupo de musica Basta con tener uno o dos músicos de verdad. Ningún conocedor de música sincero estará de acuerdo con esto. Estas conversaciones surgen por la falta de profesionales y personas creativas.

Las empresas tienen dificultades similares. Hay pocos buenos especialistas que conozcan su empresa de pies a cabeza y están muy ocupados. Al analizar los procesos de negocio por nuestra cuenta, ahorramos dinero y quizás tiempo. Pero no siempre es posible seleccionar los mejores para describir la fuente de alimentación. Puede confiar la rutina a artistas de menor rango, pero existe el riesgo de retrasar el proceso. El desconocimiento de los principios de elaboración de dichos documentos conlleva el riesgo de ineficacia (el resultado es inutilizable, es lo mismo que su ausencia).

La mejor calidad y rapidez en la preparación de documentos es posible en alianza con un especialista clave y un consultor experimentado. El resultado será un lenguaje acordado para describir los procesos de negocios (es decir, la terminología del negocio de la empresa) y la descripción misma con suficiente detalle para resolver problemas adicionales.

Repito en respuesta a toda persuasión.
No nos separarán, no.

Te recordamos que todos los epígrafes de este artículo están tomados de la canción “Music Connected Us” del grupo Mirage.

Un consultor externo redactará un documento en un lenguaje de notación que sea comprensible para otros consultores y, a menudo, más adecuado para el caso. ¿No entiendes todos estos ganchos? Pero estas notaciones no son nada complicadas, ¿tal vez valga la pena aprenderlas?

Un modelo de proceso representa un conjunto coherente e integrado de perspectivas funcionales, conductuales, informativas y organizativas, pero muchos modelos utilizados hoy en día en la práctica de la reingeniería no satisfacen esto.

12/10/2011 Ígor Fedorov

Un modelo de proceso es un conjunto integrado interrelacionado de perspectivas funcionales, conductuales, informativas y organizativas; sin embargo, muchos modelos utilizados hoy en día en la práctica de la reingeniería no cumplen con los requisitos de los modelos de procesos y no pueden llamarse modelos de procesos, ya que proporcionan una imagen incompleta del proceso. objeto modelado y no contienen toda la información necesaria para crear un modelo ejecutable.

Las disputas sobre la elección de la notación para modelar procesos de negocios aún no disminuyen. Se analizan las capacidades de las notaciones EPC (Event-driven Process Chains) y BPMN (Business Process Modeling Notation), sintaxis, conjunto de primitivas del lenguaje de descripción, etc.. Sin embargo, es incorrecto comparar notaciones y lenguajes para describir un proceso de negocio mediante el análisis de su funcionalidad: si el modelo es funcional o el proceso está determinado no solo por la notación, sino también por la metodología. A menudo, la metodología de modelado se reemplaza por la notación, lo que conduce a errores graves en el diseño de los procesos de negocio y a la aparición de modelos de baja calidad.

Modelos y perspectivas

Modelo- se trata de una representación material o mental de un objeto o fenómeno, repitiendo algunas propiedades que son esenciales para los fines de un modelado particular y omitiendo otras propiedades sin importancia en las que el modelo puede diferir del prototipo. Un objeto complejo, por ejemplo un proceso de negocio, se describe mediante un conjunto de modelos, cada uno de los cuales muestra un conjunto limitado de propiedades, y juntos describen el objeto modelado por completo. Cada uno de los modelos particulares está asociado a una pregunta principal que el modelo correspondiente debe responder. Se identifican cuatro perspectivas del modelo de procesos de negocio (ver figura).

Funcional:“¿Qué están haciendo los participantes?” Describe el alcance del trabajo realizado.

Comportamiento:“¿Cómo trabajan los participantes?” Describe la secuencia, cronograma de ejecución, reglas comerciales.

Informativo:“¿Qué están procesando los participantes?” Describe las entidades comerciales del dominio del proceso.

Organizativo:"¿Quién hace el trabajo?" Describe la composición y estructura de los intérpretes.

Un modelo que describe una determinada perspectiva responde a varias preguntas, pero entre ellas siempre hay una principal, a la que el modelo debe dar una respuesta exhaustiva, y puede que no responda completamente a otras adicionales. En este último caso, hay que tener especial cuidado: la perspectiva del modelo está determinada precisamente por la pregunta principal y no por la auxiliar.

Perspectiva funcional

Un modelo funcional describe un sistema en un estado estático y ayuda a responder la pregunta "¿qué se debe hacer para lograr el objetivo?" La respuesta es una lista de todas las acciones que deben realizarse para lograr el resultado planeado. Ampliamente utilizado en la gestión de proyectos. estructura de desglose del trabajo(Estructura de desglose del trabajo): las acciones enumeradas en él no están conectadas por una secuencia de tiempo. De manera similar, al modelar procesos, es muy útil crear un desglose estructural que ayude a comprender la lógica del proceso y recordar realizar cualquier función importante. Si dos organizaciones diferentes realizan el mismo proceso, entonces su división funcional del trabajo será la misma, aunque el orden de ejecución del trabajo puede cambiar teniendo en cuenta sus diferencias. estructura organizativa. Por tanto, el modelo funcional depende débilmente de la estructura organizativa y puede considerarse como un modelo de referencia.

A menudo, un modelo funcional se denomina erróneamente mapa de procesos; por ejemplo, los modelos SCOR (modelo de referencia de operaciones de la cadena de suministro) y ETOM (mapa mejorado de operaciones de telecomunicaciones) contienen jerarquías de funciones y cadenas de valor, pero no procesos. Incluso las directrices del TeleManagement Forum exigen distinguir entre un proceso como una secuencia de acciones realizadas y un proceso como la dirección de las actividades de una empresa.

Aspectos de la perspectiva conductual

La perspectiva conductual, que describe la dinámica del sistema, responde a la pregunta "¿cómo se desempeñan los participantes?" Para modelarlo se utiliza un diagrama de flujo de control. La pregunta principal es "¿cómo?" se puede dividir en tres: “¿En qué orden se realizan las operaciones que componen el proceso? ¿A qué hora se realiza la operación? ¿Por qué las operaciones se realizan en un orden determinado?

La respuesta a la primera pregunta la da la lógica empresarial, que representa una descripción procedimental del orden de ejecución del trabajo; se utiliza un diagrama de flujo de trabajo para mostrarlo gráficamente. La respuesta a la segunda la da el cronograma de ejecución del proceso, que determina cuándo se realiza tal o cual trabajo, el tiempo dedicado a no realizarlo y las acciones tomadas en caso de incumplimiento del cronograma de ejecución. La respuesta a la tercera pregunta la proporcionan las reglas comerciales, que son una descripción declarativa de las restricciones impuestas al proceso.

Lógica empresarial del proceso.

La secuencia de operaciones que forman un proceso generalmente se denomina lógica de negocios y para describirla se utilizan diagramas de flujo de trabajo (UML, EPC, ABC Flowchart - descripciones basadas en diagramas de flujo). La lógica empresarial contiene información explícita y prescriptiva sobre la ruta de ejecución del proceso, pero sólo indirectamente tiene en cuenta los criterios para tomar decisiones relevantes.

El diagrama del proceso incluye un elemento de "ramificación", que le permite dirigir la ejecución del proceso a lo largo de una de las rutas predefinidas de acuerdo con condiciones predeterminadas. La bifurcación es un elemento de la lógica empresarial y la condición mediante la cual se lleva a cabo la bifurcación es una regla empresarial. A menudo, los analistas de negocios no separan la lógica y las reglas y colocan un elemento de bifurcación en el diagrama, sino que omiten la regla de bifurcación asociada.

Los diagramas que describen la lógica empresarial parecen visualmente simples y claros porque no incluyen reglas comerciales, cronogramas de ejecución y acciones correctivas tomadas cuando los indicadores de proceso caen fuera de los rangos aceptables, por lo que muchos analistas los usan para coordinar con los representantes comerciales. Sin embargo, la simplicidad es engañosa: los desarrolladores de sistemas de TI tienen que recuperar la información que falta y su comprensión del proceso puede ser muy diferente de la opinión del analista. Como resultado, el modelo no describe completamente el proceso; los detalles no están claramente registrados, sino que sólo existen en la cabeza de los programadores. Como resultado, el modelo de proceso en papel no se corresponde con la lógica del sistema de TI: son estas imprecisiones en la descripción inicial del proceso de negocio las que conducen a numerosas modificaciones que surgen en la etapa de implementación de los sistemas de información.

Reglas del negocio

Una regla de negocio generalmente se entiende como una declaración que define o limita algún aspecto de un negocio. A diferencia de una descripción procesal, las reglas postulan restricciones a la ejecución de un proceso, pero no especifican cómo exactamente se pretende lograr el resultado. El experto en reglas comerciales Ronald Ross ofrece la siguiente clasificación de reglas comerciales:

• las reglas de comportamiento determinan la necesidad de realizar la acción adecuada e implementar acciones de control;
• las reglas de definición establecen el criterio para la aplicabilidad de cualquier concepto empresarial denominado hecho;
• las reglas de cálculo ayudan a descubrir los valores de las cantidades deseadas, llamadas hechos; por ejemplo, un descuento comercial puede determinarse por el volumen total de compras durante un período determinado, etc.;
• las reglas de clasificación ayudan a verificar la verdad de los hechos; por ejemplo, un cliente se considera VIP si tiene una determinada cantidad en su cuenta y no tiene pagos pendientes.

La ramificación del proceso se realiza sobre la base de una regla de comportamiento que cambia de ruta de acuerdo con el valor del argumento, que toma los valores "verdadero" o "falso", pero qué es "verdadero" y qué es “falso” está determinado por la regla de clasificación, que, a su vez, debe recibir como entrada algún valor obtenido utilizando la regla de cálculo. Por ejemplo, imagine la siguiente secuencia de acciones: calcular el importe del descuento en función del tamaño del pedido actual (regla de cálculo); clasificar el tamaño del descuento: grande, mediano, bajo (regla de clasificación); presentar la transacción para su aprobación a un gerente con el nivel apropiado de autoridad (regla de conducta). Sin embargo, se ha generalizado la práctica viciosa de colocar un elemento “ramificado” en un diagrama con las reglas de comportamiento y las reglas de definición directamente incluidas en él, lo que hace que el diagrama sea inflexible y la descripción incompleta. Por lo tanto, todas las reglas deben separarse explícitamente en construcciones separadas en el diagrama de flujo de trabajo, lo que ayudará al analista a localizar claramente la lógica correspondiente.

Calendario de ejecución

En el campo de la producción de materiales, se utiliza un programa de trabajo ampliamente utilizado para calcular el tiempo dedicado a la producción de un producto. Para los procesos de negocio, el cronograma de trabajo tiene más mirada compleja, ya que cada operación se puede completar a tiempo, pero todo el proceso puede retrasarse debido a devoluciones para reprocesamiento.

La ontología del tiempo utilizada para describir los procesos de negocio contiene dos conceptos básicos: eventos e intervalos. Un evento es un punto en una escala de tiempo que no tiene duración. Los eventos se utilizan para coordinar la ejecución de diferentes procesos o ramas de un mismo proceso. Se entiende por intervalo un segmento en una escala de tiempo entre los eventos iniciales y finales. Los intervalos le permiten determinar el límite de tiempo asignado para la ejecución de una operación individual o grupo de operaciones.

Al comparar notaciones de modelado de procesos de negocio, se debe analizar si operan con los conceptos básicos de "evento" e "intervalo de tiempo". Esto ayuda a comprender si la notación le permite modelar las características temporales de un proceso y coordinar la ejecución de los procesos y sus ramas. Nuestras observaciones muestran que muchas notaciones de modelado de procesos de negocio no utilizan estos conceptos básicos.

Grado de detalle de la lógica empresarial.

Para responder a la pregunta “¿cómo?”, el diagrama de control debe contener tantos Descripción detallada acciones que componen el proceso. Muchos analistas se limitan a enumerar funciones, sin especificar los detalles de su ejecución, asumiendo que quien las ejecuta sabe cómo debe realizarse el trabajo. Sin embargo, en la práctica, los empleados tienden a realizar el trabajo basándose en su experiencia individual, lo que conduce a una alta variabilidad en la ejecución del proceso. Las notaciones de modelado no determinan el nivel de detalle de la descripción, dejando esta cuestión al analista. Definamos los criterios de detalle.

El documento rector de la norma estatal rusa, "Metodología de modelado funcional IDEF0", introduce los conceptos de "acción" y "operación". Una acción se define como "la transformación de cualquier propiedad de un material u objeto de información en otra propiedad", y una operación se define como "un conjunto de acciones realizadas de forma secuencial y/o paralela".

Aclaremos estas definiciones para el caso del modelado de procesos. Acción llamaremos al trabajo realizado por un participante en un objeto de proceso que cambia este objeto, pero no conduce a un cambio en su estado; por ejemplo, un participante ha introducido nuevos datos, pero esto no significa el final de la tramitación de la solicitud. Operación llamaremos a un conjunto de acciones que conducen a un cambio en el estado de un objeto; por ejemplo, una vez completadas todas las comprobaciones, se puede aprobar la solicitud.

Un diagrama de flujo de trabajo generalmente se limita al nivel de actividad. Se cree que el exceso de detalles dificulta la comprensión de la lógica del proceso. El diagrama de control debe dar una respuesta integral a la pregunta de cómo se ejecuta el proceso y tener niveles detallados de acciones. Como resultado, estos diagramas resultan demasiado detallados y corren el riesgo de estar sobrecargados de detalles. Sin embargo, esto es más bien una cuestión de estilo de modelado: los modelos estructurados de varios niveles pueden combinar la simplicidad de la lógica empresarial en el nivel superior del diagrama y la descripción detallada de acciones individuales en el inferior.

Grado de integridad de la lógica empresarial del proceso.

La mayoría de los diagramas de flujo de trabajo describen un conjunto limitado de escenarios de ejecución, identificando sólo las rutas más obvias. No incluyen escenarios raramente ejecutados e ignoran situaciones especiales y excepcionales. Una descripción tan incompleta de la implementación tiene derecho a existir cuando se planea desarrollar un sistema funcional. sistema de informacion, donde una persona determina el orden de ejecución de las operaciones. Sin embargo, al construir un sistema orientado a procesos, el orden de las operaciones lo determina el propio sistema, por lo tanto, el modelo debe cubrir todos los escenarios de ejecución posibles, incluidos los retornos de control al paso anterior o las transiciones de adelantamiento que evitan ciertos pasos de procesamiento, tomar en cuenta la posibilidad de escalar el problema, manejando situaciones excepcionales, de lo contrario el funcionamiento del sistema resultará imposible.

Análisis comparativo de notaciones EPC y BPMN.

Hemos demostrado que se debe hacer una distinción entre diagramas de flujo de trabajo, diagramas de flujo de control y diagramas de modelo de procesos. Un diagrama de flujo de trabajo define la lógica empresarial, el orden de ejecución de las operaciones, tiene detalles a nivel de actividad, no incluye un cronograma de ejecución del proceso y puede no definir completamente las reglas comerciales del proceso. El diagrama de flujo de control aclara el diagrama de flujo de trabajo en términos del cronograma de ejecución y reglas de negocio, tiene un nivel detallado de acciones, debe describir todas las opciones de ejecución, en otras palabras, describe una tecnología que garantiza el logro del resultado planeado en el evento de la ejecución exacta de un conjunto predeterminado de acciones. En ausencia de al menos un componente, la descripción estará incompleta y no se seguirá la tecnología. Un modelo de proceso es una colección de perspectivas interrelacionadas, cada una de las cuales describe aspectos individuales del comportamiento del proceso y juntas forman una visión integrada, integral y completa del proceso y su ejecución. Entre otras cosas, un diagrama de flujo de control describe la perspectiva de comportamiento de un modelo de proceso de negocio.

La notación EPC es un medio para describir la lógica empresarial de un proceso. Como muestra la comparación, la notación le permite implementar patrones básicos de lógica empresarial sin ser inferior a otras notaciones de descripción de procesos. Los diagramas EPC muchas veces no incluyen reglas de negocio, pero esta deficiencia no debe atribuirse a la notación per se, sino a la metodología de aplicación. En cuanto al cronograma de ejecución, cabe señalar que no existen herramientas para modelar las características del tiempo de ejecución. La notación EPC contiene una construcción de "evento", pero se utiliza para describir el estado de un objeto de control y no para sincronizar la ejecución. La metodología EPC no se centra en el grado de detalle y completitud de los diagramas resultantes, dejando esta cuestión al analista. En ausencia de una regulación estricta, los analistas se esfuerzan por garantizar la simplicidad y legibilidad de los diagramas, por lo que se limitan a describir el nivel de operaciones y no se esfuerzan por identificar todas las rutas de ejecución. La notación EPC se utiliza a menudo para la automatización mediante sistemas orientados a funciones, donde una persona desempeña un papel principal y directivo, por lo que la ausencia de un script de ejecución no es peligrosa. Todo ello nos permite clasificar los modelos EPC como diagramas de flujo de trabajo.

Las notaciones incluidas en ARIS tienen capacidades de modelado de procesos extremadamente poderosas, pero no están respaldadas por metodologías abiertas y accesibles para el usuario. El documento "Metodología ARIS" no describe la metodología, sino las reglas para usar la notación, lo que permite amplias posibilidades de "interpretación" de los métodos de modelado.

El problema del EPC es el intento de adaptar esta herramienta para resolver una gama demasiado amplia de problemas, sin explicar las reglas de aplicación para un caso específico. Como resultado, los analistas aplican muchos diseños y mecanismos de forma intuitiva e inconsciente. A veces, su intención puede entenderse a partir del contexto del problema, pero es poco probable que una computadora moderna pueda analizar el contexto mismo al convertir el diagrama a un formato ejecutable.

La notación BPMN describe la lógica del proceso. Un poco mejor soporte Los patrones de lógica de negocios, en comparación con EPC, no son una ventaja decisiva. La notación opera con los conceptos de "evento" e "intervalo de tiempo" y contiene medios para sincronizar ramas de procesos entre sí y procesos entre sí. La notación en sí no recomienda separar la lógica de las reglas, pero las pautas para un estilo de modelado adecuado sí incluyen dicha recomendación. La notación BPMN se utiliza para crear sistemas orientados a procesos, donde una persona desempeña un papel subordinado y el sistema desempeña un papel principal, por lo que saltarse uno, incluso el escenario más raro, no permitirá que el trabajo se complete y, por lo tanto, es inaceptable; en consecuencia, los modelos BPMN cubren todos los escenarios de ejecución. Los modelos BPMN son modelos ejecutables, por lo que describen todos los detalles, hasta las acciones más básicas. Todo lo anterior nos permite clasificar el diagrama BPMN como un modelo de flujo de control.

Los problemas con la notación BPMN están relacionados con el hecho de que los diagramas, por regla general, están sobrecargados de detalles y detalles y, por lo tanto, son difíciles de leer. La solución parece ser el desarrollo de una metodología para construir estructuras jerárquicas. modelos multinivel, donde el nivel superior describe el contexto de ejecución de todo el proceso, el nivel medio describe la lógica de ejecución y el nivel inferior describe los detalles de la implementación de operaciones individuales.

El interés por BPM y BPMS (Business Process Management Suite) ha alcanzado un nivel de madurez en el que ya no es necesario hablar de moda. Además, la guerra de estándares terminó y la notación BPMN recibió el reconocimiento de todos los actores principales, convirtiéndose en un estándar de facto. La importancia de este evento se puede comparar con la aparición de SQL, que se convirtió en la base de los sistemas de información modernos.

BPMS finalmente ha surgido como una clase software para soporte modelado grafico procesos de negocio, ejecución de modelos de procesos de negocio, seguimiento y análisis (Business Activity Monitoring, BAM). Sin embargo, diferentes productos implementan esta funcionalidad de diferentes maneras y al elegir un BPMS específico, primero debe considerar lo siguiente.

• Soporte BPMN.¿Qué versión de BPMN es compatible (1.x o 2.0)? ¿Qué tan completa es la implementación? ¿Se admiten mensajes, señales y subprocesos de transacciones?

• Tipo de motor de procesos BPMN. Es preferible la ejecución directa a la traducción a alguna otra representación; solo en este caso es posible implementar la mejora continua de los procesos comerciales en la práctica.
• Comunicación entre procesos y datos. Es preferible almacenar atributos sobre
proceso al máximo formulario abierto– en tablas y columnas de un DBMS relacional, que proporciona integridad referencial, altas características operativas y libertad de acceso a los datos desde el exterior, en lugar de, por ejemplo, almacenar atributos como una cadena XML.
• Interfaz de usuario. La interfaz debe ser funcional y ergonómica.
y desarrollarse rápidamente, posiblemente sin programación. El sistema debería permitir a un analista de negocios crear una interfaz de usuario funcional que, si se desea, puede modificarse con la participación de un programador.
• Plataforma del sistema. Dependiendo de la política técnica de la empresa, la elección
puede estar limitado a la plataforma Java o. Net: los BPMS que admiten ambas plataformas son raros.
• Esquema de licencias. Los sistemas shareware te permiten ahorrar dinero
licencias, pero requieren grandes recursos de desarrollo; Algunos sistemas comerciales son caros incluso con configuraciones mínimas.
• Disponibilidad de una oficina de representación o socio en Rusia.

No hay que olvidar que BPMS es sólo uno de los componentes del BPM, y para el éxito de un proyecto de creación de un sistema de gestión de procesos de negocio también se requieren competencias en metodología y en gestión ágil de proyectos.

Anatoly Belaychuk ([correo electrónico protegido]) – Presidente de la empresa “Business Console” (Moscú).

Problemas al traducir un diagrama EPC a un formato ejecutable

Los resultados del modelado en notación EPC no siempre conducen a la creación de un modelo que pueda convertirse a un formato BPM ejecutable sin modificaciones significativas.

Enumeremos los errores típicos de modelado.

Para los analistas novatos, el modelo EPC describe la opción de ejecución más probable, omitiendo rutas alternativas poco utilizadas: en sus diagramas rara vez se ven descripciones de acciones en situaciones excepcionales y no estándar.

Muy a menudo, los modelos no reflejan plenamente todos los criterios de toma de decisiones. Como resultado, es necesario volver a desarrollar el modelo para perfeccionar las reglas comerciales.

Los analistas no prestan atención a los cambios en el objeto de control del proceso. Imaginemos una descripción. proceso tecnológico, incluida la producción de componentes. Si los componentes se producen por pedido, entonces puede incluir una descripción de su producción en el proceso principal, pero si los componentes se producen de forma asincrónica con la parte principal, entonces su producción debe ser un proceso separado con su propio objeto de control. El analista debe monitorear cuidadosamente el objeto de control del proceso, ya que su cambio es un signo de una posible división del proceso de un extremo a otro en una cadena de procesos que interactúan.

Un grado insuficiente de detalle en el proceso conduce a la necesidad de volver a aclarar y describir los detalles faltantes en la etapa de preparación de los requisitos para el sistema de TI que se está desarrollando.

Los diagramas EPC no describen cronogramas de ejecución y omiten cuestiones de sincronización de ramas de un proceso entre sí y con otros procesos externos.

Así, se puede decir que los problemas de EPC radican en el ámbito de la metodología de su aplicación, y con la presencia de un acuerdo de modelado que definiría todos los detalles del modelo que se está desarrollando, la mayoría de los problemas, con podrían evitarse, a excepción de los parámetros temporales de ejecución.

No es la notación, sino la metodología la que determina si un modelo es funcional o de proceso. Un modelo de proceso es una descripción de múltiples capas que incluye descripciones interrelacionadas de perspectivas funcionales, conductuales, informativas y organizativas. Para describir la perspectiva conductual, se debe utilizar un diagrama de flujo de control, que brinde una respuesta integral a la pregunta "¿cómo se ejecuta el proceso?", incluyendo la definición de la secuencia de operaciones, las reglas de negocio, el cronograma de ejecución, detallando el nivel de acciones y describiendo todos los escenarios de ejecución posibles. Un diagrama de flujo de trabajo, llamado injustificadamente modelo de proceso, no describe todos los detalles del comportamiento del proceso y no es un diagrama de proceso.

Muchos modelos que se utilizan en la práctica de la reingeniería no satisfacen todos los requisitos enumerados y, por lo tanto, no pueden denominarse modelos de procesos. Surge la pregunta: ¿tal vez aquí radica el fracaso de estos proyectos de reingeniería de procesos de negocio?

Literatura

1. B. Curtis, M. Kellner, J. Over. Modelado de procesos, 1992.
2. eTOM, Flujos de procesos representativos. UIT. s.l.: Sector de Normalización de las Telecomunicaciones de la UIT, 2004.
3. R. Ross. Principios del enfoque de reglas de negocio. Addison-Wesley Profesional (2003).
4. C. Pedrinaci, Domingue, A. Alves de Medeiros. Una ontología central para el análisis de procesos empresariales, Actas de la quinta conferencia europea sobre web semántica sobre La web semántica: investigación y aplicaciones, Springer-Verlag Berlín, Heidelberg, 2008.
5. Metodología de modelado funcional IDEF0. Moscú: Gosstandart de Rusia, 2000.
6. N. Russell, A. ter Hofstede, W. M. P. van der Aalst, N. Mulyar, Patrones de flujo de control del flujo de trabajo.
7. Métodos ARIS 7.0. Sarrebruck: IDS Scheer AG, 2005.
8. B. Plata, Método y Estilo BPMN. Prensa Cody-Cassidy, 2009.

Igor Fedorov ([correo electrónico protegido]) – Director del Centro de Competencia en Gestión de Procesos de MESI (Moscú).

Modelado de procesos de negocio, perspectiva de modelado, modelado funcional y de procesos.

"Cometas, gallina ciega y etiqueta
Escondite, pelotas, saltos y cuerdas para saltar,
Y simple, y simple, y solo saltar la cuerda,
Bueno, simple, simple, ¡¡¡salten la cuerda!!!”

A. Vratarev

Mientras preparaba este artículo, descubrí un dato increíble: sobre la notación EPC, tan simple y tan popular (hay opiniones de que es incluso más popular que BPMN), hay artículos en Wikipedia en solo 4 idiomas: inglés, alemán, checo. y uzbeko. Además, estos artículos son bastante breves. Quizás al final del artículo usted y yo, querido lector, entendamos por qué.

Permítanme comenzar con el hecho de que la notación EPC se desarrolló a principios de los años 1990. durante el desarrollo de la metodología ARIS, como, por ejemplo, su componente de proceso. Se considera que el padre fundador del EPC es el profesor Wilhelm-August Scheer, cuyo nombre por sí solo inspira asombro en el ciudadano medio (dígalo en voz alta y siéntase inspirado). ¿Qué podemos decir del nombre de la facultad donde trabajaba este respetado chico? Institut für Wirtschaftsinformatik de la Universidad Universität des Saarlandes.

El propósito de crear la notación EPC fue la capacidad de describir procesos de modo que las funciones realizadas dentro de ellos tengan una semántica global dentro del diagrama, lo que significa que la ejecución de una función en los diagramas EPC no está necesariamente claramente definida, sino que puede depender de la Estado de otros nodos del diagrama, a veces muy alejados entre sí.

El nombre de la notación significa Cadena de procesos impulsada por eventos, lo que indica claramente que el elemento central de los diagramas de notación EPC son los eventos. Los eventos dan lugar a la realización de determinadas acciones por parte de determinados participantes. La finalización de las acciones, a su vez, genera otro evento, y así sucesivamente, hasta que el sistema alcanza un estado, cuya aparición dentro del proceso se considera el evento final.

Para demostrar claramente las capacidades de la notación, usaré un ejemplo cotidiano, inspirado en unas vacaciones recientemente terminadas en climas más cálidos. El recepcionista de un respetable hotel, Ivo Petkov, recibe de uno de los huéspedes una petición para que se reponga urgentemente el material de aseo de su habitación. Está bastante claro que su tarea es cumplir con la solicitud del cliente y, en términos de EPC, llevar el sistema del estado "Recibió una solicitud del cliente para cambiar los lavabos" al estado "La solicitud del cliente ha sido satisfecha".

Mostramos los dos estados indicados en el borrador del diagrama e inmediatamente notamos lo fácil que será leer nuestro diagrama, porque cada uno de sus elementos no solo tiene su propia forma, sino también su propio color. Así, los eventos son hexágonos rojos, las funciones son rectángulos verdes con bordes redondeados y los artistas se representan como óvalos amarillos.

Así que volvamos al ejemplo. Inmediatamente después de recibir una solicitud de un cliente, Ivo debe enviar una solicitud para cumplir con la solicitud del cliente a la empleada doméstica, lo que lleva el sistema al estado "Solicitud de cumplimiento enviada". La criada, utilizando los suministros disponibles en el almacén, cumple el pedido de Ivo. Y aquí, por primera vez, aparece el paralelismo de nuestro proceso: si la criada se da cuenta de que los artículos de lavado necesarios (por ejemplo, gel de ducha) no están actualmente en stock, entonces ella misma, quizás sin querer, transfiere el sistema a la "Cumplimiento de los requisitos". la solicitud es imposible”, de lo que se deduce naturalmente que Ivo tendrá que tener una conversación no muy agradable con el cliente, y el estado al que llegará el sistema depende sólo de la disposición del cliente y su tendencia a pelear. Si el almacén tiene todos los suministros necesarios para el huésped, entonces la criada cumple con éxito la solicitud que se le ha transferido e informa del cumplimiento a Ivo, quien a su vez informa de esto al cliente. Y todos viven felices para siempre y mueren el mismo día.

Este sencillo proceso se refleja en un diagrama rojo, verde y amarillo que parpadea alegremente como en la Figura 1.

Arroz. 1. Diagrama EPC del proceso de procesamiento de la solicitud de un cliente en un hotel.

Y ahora, según la tradición, las ventajas y desventajas de la notación.

Cuando encontré por primera vez los diagramas EPC, como mencioné anteriormente, quedé muy satisfecho con lo fáciles que eran de leer: cada bloque está resaltado en forma y color, es muy fácil ver a los artistas, los materiales necesarios, resaltar la lista. de posibles estados del sistema, la lista de aquellos que se realizan durante el proceso de funciones. Esto es sin duda una gran ventaja: el cliente no tendrá dificultades para leer el diagrama del proceso de negocio cuando implementación de EDMS, si se presenta exactamente en la notación EPC. Sin embargo, tal vez el cliente se sienta confundido por un número tan gigantesco de estados, porque de hecho, gracias a ellos, el circuito crece enormemente. Incluso en nuestro ejemplo: unas 4 funciones generaron hasta 5 estados (sin contar el inicial). A veces uno se pregunta: ¿por qué señalarlos todos? Déjanos decirte por qué es necesario después de acordar el contrato. director general indicar en un bloque separado "Acuerdo acordado", y después de firmar - "Acuerdo firmado", si además el proceso sigue siendo lineal. Francamente, no es necesario, a menos que seas el Capitán Obvio.

Y a veces no está claro cómo identificar el estado al que la función transferirá el sistema. Mientras preparaba este sencillo ejemplo, experimenté ciertas dificultades asociadas precisamente con este momento.

La ventaja de los diagramas EPC es el hecho de que, al igual que los diagramas IDEF0, pueden indicar los datos de entrada y salida de cada función y rastrear la lógica del movimiento de los datos de entrada y salida de un bloque a otro. Además, a diferencia del mismo IDEF0, fue posible paralelizar el proceso dirigiéndolo solo a lo largo de una de las ramas alternativas (en IDEF0, si agregamos paralelismo en la ejecución, todas las funciones paralelas se ejecutarán simultáneamente). También me pareció una ventaja poder especificar el intérprete para cada etapa (léase: función).

¡Pero! En IDEF0, el ejecutor se indica una vez en cada nivel de descomposición y se dibujan flechas en su nombre a todos los bloques ejecutados por él. En EPC, para calcular cuántas acciones realiza un ejecutor, debemos revisar todos los bloques de acciones y verificar si el ejecutor que necesitamos está indicado en ellos.

Esta notación me pareció muy conveniente desde el punto de vista del seguimiento de la ejecución del proceso: cada función ciertamente transfiere el sistema a un nuevo estado, de lo que se deduce que después de ejecutar cada función, se puede verificar si el sistema ha cambiado al estado deseado. efectivamente se llevó a cabo el estado. Pero inmediatamente surgió la pregunta: ¿es esto realmente necesario? Por ejemplo, rara vez tengo ese deseo =)

Entonces, en general, la notación EPC me parece inconveniente para describir procesos de negocios: demasiada atención a los eventos, muy poca atención a las acciones y especialmente a su agrupación en función del ejecutante o los materiales utilizados. Sí, es sencilla, sí, es hermosa y sí, lamentablemente, eso es todo lo que puedo decir de ella, como probablemente de muchas otras personas. =)

Y los artículos sobre notaciones UML y BPMN están cada vez más cerca.

(4,14 - valorado por 21 personas)