Desarrollo de software idef0. Uso de diferentes colores. El principio de construcción del modelo IDEFO

¡Aprenda a ver y comprender la estructura funcional de su negocio!

En la actualidad, en Rusia, el interés en los estándares de gestión generalmente aceptados en Occidente ha aumentado drásticamente, sin embargo, en la práctica de gestión real, hay un momento muy indicativo. Muchos líderes todavía pueden sentirse desconcertados por la cuestión directa de estructura organizativa empresa o sobre el esquema de los procesos comerciales existentes. Los gerentes más avanzados que leen regularmente publicaciones periódicas económicas, por regla general, comienzan a dibujar diagramas jerárquicos que solo son comprensibles para ellos, pero en este proceso generalmente llegan rápidamente a un callejón sin salida. Lo mismo se aplica a los empleados y gerentes de diversos servicios y unidades funcionales. En la mayoría de los casos, el único conjunto de reglas establecidas de acuerdo con las cuales una empresa debe operar es un conjunto de disposiciones individuales y descripciones de trabajo... La mayoría de las veces, estos documentos se redactaron hace más de un año, están mal estructurados y no están interconectados y, como resultado, simplemente acumulan polvo en los estantes. Por el momento, ese enfoque estaba justificado, ya que durante la formación de la economía de mercado rusa, el concepto de competencia estaba prácticamente ausente y no había necesidad particular de considerar los costos: el beneficio era gigantesco. Como resultado, en los últimos dos años, hemos visto un panorama completamente comprensible: las grandes empresas que crecieron a principios de los 90 están perdiendo gradualmente sus posiciones, hasta su completa retirada del mercado. Esto se debe en parte al hecho de que la empresa no implementó estándares de gestión, el concepto de un modelo funcional de actividad y misión estaba completamente ausente. Con la ayuda de la modelización de diversas áreas de actividad, es posible analizar eficazmente los cuellos de botella en la gestión y optimizar el esquema empresarial general. Pero, como saben, en cualquier empresa, solo aquellos proyectos que traen ganancias directamente son de máxima prioridad, por lo tanto, generalmente es solo durante una crisis tangible en la gestión de la empresa que estamos hablando de la encuesta de actividades y su reorganización.

A finales de la década de los noventa, cuando el mercado era suficientemente competitivo y la rentabilidad de las empresas comenzó a caer bruscamente, los gerentes sintieron enormes dificultades para tratar de optimizar los costos para que los productos siguieran siendo rentables y competitivos. Fue en este momento que se manifestó claramente la necesidad de tener ante los ojos un modelo de la actividad empresarial que reflejara todos los mecanismos y principios de interconexión de varios subsistemas en el marco de un negocio.

El concepto mismo de "modelar procesos de negocio" entró en la vida cotidiana de la mayoría de los analistas simultáneamente con la aparición en el mercado de complejos productos de software diseñado para la automatización compleja de la gestión empresarial. Estos sistemas siempre implican una profunda encuesta previa al proyecto de las actividades de la empresa. El resultado de esta encuesta es una opinión de expertos, en la que se hacen recomendaciones en párrafos individuales para eliminar "cuellos de botella" en la gestión de actividades. Sobre la base de esta conclusión, inmediatamente antes de la implementación del sistema de automatización, se lleva a cabo la llamada reorganización de los procesos comerciales, a veces bastante grave y dolorosa para la empresa. Esto, y naturalmente, un equipo que se ha desarrollado a lo largo de los años siempre es difícil de obligar a “pensar de una manera nueva”. Estas encuestas complejas de empresas son siempre tareas complejas y muy diferentes de un caso a otro. Existen metodologías y estándares bien probados para resolver tales problemas de modelado de sistemas complejos. Estos estándares incluyen las metodologías de la familia IDEF. Con su ayuda, es posible mostrar y analizar de manera efectiva los modelos de la actividad de una amplia gama de sistemas complejos en varias secciones. Al mismo tiempo, el desarrollador mismo determina la amplitud y profundidad del examen de los procesos en el sistema, lo que permite no sobrecargar el modelo creado con datos innecesarios. Por el momento, los siguientes estándares se pueden atribuir a la familia IDEF:

IDEF0 es una metodología de modelado funcional. Con la ayuda del lenguaje gráfico visual IDEF0, el sistema en estudio aparece a los desarrolladores y analistas en forma de un conjunto de funciones interrelacionadas (bloques funcionales - en términos de IDEF0). Normalmente, el modelado IDEF0 es el primer paso para aprender sobre cualquier sistema;

IDEF1: una metodología para modelar los flujos de información dentro del sistema, que le permite mostrar y analizar su estructura y relaciones;

IDEF1X (IDEF1 Extended) es una metodología para construir estructuras relacionales. IDEF1X se refiere al tipo de metodología "Entidad-relación" (ER - Entidad-Relación) y, por regla general, se utiliza para modelar bases de datos relacionales relacionadas con el sistema considerado;

IDEF2 es una metodología para el modelado dinámico de la evolución de sistemas. Debido a las gravísimas dificultades para analizar sistemas dinámicos, esta norma fue prácticamente abandonada y su desarrollo se suspendió en la etapa inicial. Sin embargo, en la actualidad existen algoritmos y sus implementaciones informáticas que permiten transformar un conjunto de diagramas IDEF0 estáticos en modelos dinámicos basados en “redes de Petri coloreadas” (CPN - Color Petri Nets);

IDEF3 es una metodología para documentar los procesos que ocurren en el sistema, que se utiliza, por ejemplo, en el estudio de procesos tecnológicos en empresas. IDEF3 describe el escenario y el flujo de trabajo de cada proceso. IDEF3 tiene una relación directa con la metodología IDEF0 - cada función (bloque funcional) se puede representar como un proceso separado por medio de IDEF3;

IDEF4 es una metodología para construir sistemas orientados a objetos. Las herramientas IDEF4 le permiten mostrar visualmente la estructura de los objetos y los principios subyacentes de su interacción, lo que le permite analizar y optimizar sistemas complejos orientados a objetos;

IDEF5 es una metodología para el estudio ontológico de sistemas complejos. Utilizando la metodología IDEF5, la ontología de un sistema se puede describir utilizando un vocabulario específico de términos y reglas, sobre la base de los cuales se pueden formar declaraciones fiables sobre el estado del sistema en consideración en un momento determinado. Sobre la base de estas declaraciones, se forman conclusiones sobre el desarrollo posterior del sistema y se lleva a cabo su optimización.
En este artículo, veremos la metodología de modelado funcional IDEF0 más utilizada.

La historia del estándar IDEF0

La metodología IDEF0 puede considerarse la siguiente etapa en el desarrollo del conocido lenguaje gráfico para describir sistemas funcionales SADT (Structured Analysis and Design Teqnique). Hace varios años, se publicó en Rusia una pequeña edición del libro del mismo nombre, que se dedicó a describir los principios básicos de la construcción de diagramas SADT. Históricamente, IDEF0 como estándar se desarrolló en 1981 como parte de un extenso programa de automatización industrial llamado ICAM (Fabricación asistida por computadora integrada) y fue propuesto por la Fuerza Aérea de los EE. UU. La propia familia de estándares IDEF heredó su designación del nombre de este programa (IDEF = ICAM DEFinition). En el proceso de implementación práctica, los participantes del programa ICAM enfrentaron la necesidad de desarrollar nuevos métodos para analizar los procesos de interacción en sistemas industriales... Al mismo tiempo, además de un conjunto mejorado de funciones para describir los procesos de negocio, uno de los requisitos para el nuevo estándar era la disponibilidad de una metodología eficaz para la interacción en el marco de “analista-especialista”. En otras palabras, Nuevo método Se suponía que proporcionaría trabajo en grupo en la creación del modelo, con la participación directa de todos los analistas y especialistas involucrados en el proyecto.

Como resultado de la búsqueda de soluciones adecuadas, nació la metodología de modelado funcional IDEF0. Desde 1981, el estándar IDEF0 ha sufrido varios cambios menores, en su mayoría de naturaleza limitante, y su última revisión fue publicada en diciembre de 1993 por el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST).

Elementos y conceptos básicos de IDEF0

El lenguaje gráfico IDEF0 es sorprendentemente simple y armonioso. La metodología se basa en cuatro conceptos principales.

El primero es el concepto de Caja de actividades. El bloque funcional se representa gráficamente en forma de rectángulo (ver Fig. 1) y personifica alguna función específica dentro del marco del sistema en consideración. De acuerdo con los requisitos de la norma, el nombre de cada bloque funcional debe formularse en el modo verbal (por ejemplo, "producir servicios", no "producción de servicios").

Cada uno de los cuatro lados de un bloque funcional tiene su propio significado específico (rol), mientras que:

El lado superior es Control;

El lado izquierdo está configurado en "Entrada";

El lado derecho está configurado en "Salida";

La parte inferior es "Mecanismo".

Cada bloque funcional dentro del marco de un único sistema considerado debe tener su propio número de identificación único.

Figura 1. Bloque funcional.

La segunda “ballena” de la metodología IDEF0 es el concepto de arco de interfaz (flecha). Además, los arcos de interfaz a menudo se denominan corrientes o flechas. El arco de la interfaz muestra un elemento del sistema que es procesado por un bloque de funciones o que afecta de otro modo la función mostrada por este bloque de funciones.

La pantalla gráfica del arco de la interfaz es una flecha unidireccional. Cada arco de interfaz debe tener su propio nombre exclusivo (Etiqueta de flecha). Como lo requiere la norma, el nombre debe ser un cambio de sustantivo.

Con la ayuda de arcos de interfaz, se muestran varios objetos que, en un grado u otro, determinan los procesos que tienen lugar en el sistema. Tales objetos pueden ser elementos el mundo real(piezas, vagones, empleados, etc.) o flujos de datos e información (documentos, datos, instrucciones, etc.).

Dependiendo de cuál de los lados sea adecuado para este arco de interfaz, se le llama "entrante", "saliente" o "control". Además, solo los bloques funcionales pueden ser la "fuente" (comienzo) y el "sumidero" (final) de cada arco funcional, mientras que la "fuente" solo puede ser el lado de salida del bloque, y el "sumidero" puede ser cualquier de los tres restantes.

Cabe señalar que cualquier bloque funcional, de acuerdo con los requisitos de la norma, debe tener al menos un arco de interfaz de control y uno saliente. Esto es comprensible: cada proceso debe seguir algunas reglas (mostradas por el arco de control) y debe producir algún resultado (arco saliente); de lo contrario, no tiene sentido considerarlo.

Al construir diagramas IDEF0, es importante separar correctamente los arcos de interfaz entrantes de los de control, lo que a menudo no es fácil. Por ejemplo, la figura 2 muestra el bloque de función "Procesar pieza".

En un proceso real, el trabajador que realiza el procesamiento recibe una pieza de trabajo e instrucciones tecnológicas para el procesamiento (o reglas de seguridad al trabajar con la máquina). Puede ser un error pensar que tanto la pieza como el documento con instrucciones tecnológicas son objetos entrantes, pero no es así. De hecho, en este proceso, la pieza de trabajo se procesa de acuerdo con las reglas reflejadas en las instrucciones tecnológicas, que deben mostrarse respectivamente en el arco de la interfaz de control.

Figura 2.

Otra cosa es cuando las instrucciones tecnológicas son procesadas por el tecnólogo jefe y se les hacen cambios (Fig. 3). En este caso, se muestran como un arco de interfaz ya entrante y el objeto de control son, por ejemplo, nuevos estándares industriales, en base a los cuales se realizan estos cambios.

Figura 3.

Los ejemplos anteriores enfatizan la naturaleza aparentemente similar de los arcos de interfaz entrantes y salientes, pero siempre hay ciertas distinciones para los sistemas de la misma clase. Por ejemplo, en el caso de considerar empresas y organizaciones, existen cinco tipos principales de objetos: flujos de materiales (partes, bienes, materias primas, etc.), flujos financieros (efectivo y no efectivo, inversiones, etc.), documento flujos (documentos comerciales, financieros y organizativos), flujos de información (información, datos de intención, instrucciones orales, etc.) y recursos (empleados, máquinas, máquinas, etc.). En este caso, en varios casos, todos los tipos de objetos se pueden mostrar mediante arcos de interfaz entrantes y salientes, que controlan solo los relacionados con los flujos de documentos e información, y solo los recursos pueden mostrarse mediante arcos-mecanismos.

La presencia obligatoria de arcos de interfaz de control es una de las principales diferencias del estándar IDEF0 con otras metodologías de las clases DFD (Data Flow Diagram) y WFD (Work Flow Diagram).

El tercer concepto básico del estándar IDEF0 es la descomposición. El principio de descomposición se utiliza cuando se descompone un proceso complejo en sus funciones constituyentes. En este caso, el nivel de detalle del proceso lo determina directamente el desarrollador del modelo.

La descomposición le permite representar de manera gradual y estructurada el modelo del sistema como una estructura jerárquica de diagramas individuales, lo que lo hace menos sobrecargado y fácil de digerir.

El modelo IDEF0 siempre comienza con la presentación del sistema como un todo: un solo bloque funcional con arcos de interfaz que se extienden más allá del área considerada. Un diagrama de este tipo con un bloque funcional se denomina diagrama de contexto y se indica con el identificador "A-0".

El texto explicativo del diagrama de contexto debe indicar el Propósito de construir el diagrama en forma de una breve descripción y fijar el punto de vista (Punto de vista).

Determinar y formalizar el objetivo de desarrollar un modelo IDEF0 es un punto extremadamente importante. De hecho, el objetivo identifica las áreas relevantes en el sistema en estudio en las que se debe enfocar primero. Por ejemplo, si modelamos las actividades de una empresa para construir un sistema de información sobre la base de este modelo en el futuro, entonces este modelo diferirá significativamente del que desarrollaríamos para la misma empresa, pero con el objetivo de optimizar las cadenas de suministro.

El punto de vista define la dirección principal de desarrollo del modelo y el nivel de detalle requerido. Una clara fijación del punto de vista permite descargar el modelo, abandonando el detalle y la búsqueda de elementos individuales que no son necesarios, en función del punto de vista elegido sobre el sistema. Por ejemplo, modelos funcionales de la misma empresa desde el punto de vista del tecnólogo jefe y director de Finanzas diferirán significativamente en la dirección de sus detalles. Esto se debe al hecho de que, al final, el CFO no está interesado en los aspectos del procesamiento de materias primas en máquinas de producción, y el tecnólogo jefe no necesita esquemas de flujos financieros. Buena elección El punto de vista reduce significativamente el tiempo dedicado a la construcción del modelo final.

En el proceso de descomposición, el bloque funcional, que en el diagrama de contexto muestra el sistema como un todo, se perfora en otro diagrama. El diagrama resultante del segundo nivel contiene bloques funcionales que muestran las subfunciones principales del bloque funcional del diagrama de contexto y se denomina diagrama hijo (diagrama hijo) en relación con él (cada uno de los bloques funcionales que pertenecen a un diagrama hijo es respectivamente llamado bloque hijo - Child Box). A su vez, el bloque de función principal se denomina bloque principal en relación con el diagrama secundario (Cuadro principal), y el diagrama al que pertenece se denomina diagrama principal (Diagrama principal). Cada una de las subfunciones del diagrama hijo se puede detallar más mediante una descomposición similar del bloque funcional correspondiente. Es importante señalar que en cada caso de descomposición de un bloque funcional, todos los arcos de interfaz incluidos en este bloque, o salientes de él se capturan en el diagrama hijo. Esto logra la integridad estructural del modelo IDEF0. El principio de descomposición se muestra claramente en la Figura 4. Se debe prestar atención a la relación entre la numeración de los bloques funcionales y los diagramas; cada bloque tiene su propia y única número de serie en el diagrama (el número en la esquina inferior derecha del rectángulo), y el símbolo en la esquina derecha indica el número del diagrama secundario para este bloque. La ausencia de esta designación significa que no hay descomposición para este bloque.

A menudo hay casos en los que los arcos de interfaz individuales no tienen sentido para continuar considerándose en los diagramas secundarios por debajo de un cierto nivel en la jerarquía, o viceversa: los arcos individuales no tienen un significado práctico por encima de un cierto nivel. Por ejemplo, un arco de interfaz que representa un "detalle" en la entrada del bloque de funciones "Proceso en torno"No tiene sentido reflexionar más sobre los diagramas niveles altos- esto solo sobrecargará los diagramas y dificultará su comprensión. Por otro lado, existe la necesidad de deshacerse de los arcos de interfaz "conceptuales" separados y no detallarlos más allá de cierto nivel. Para resolver estos problemas, el estándar IDEF0 prevé el concepto de tunelización. La designación Arrow Tunnel en forma de dos paréntesis alrededor del comienzo del arco de interfaz denota que este arco no fue heredado del bloque padre funcional y apareció (del "túnel") solo en este diagrama. A su vez, la misma designación alrededor del extremo (flecha) del arco de interfaz en las inmediaciones del bloque receptor significa el hecho de que en el diagrama secundario de este bloque este arco no se mostrará y no se considerará. Muy a menudo sucede que los objetos individuales y sus correspondientes arcos de interfaz no se consideran en algunos niveles intermedios de la jerarquía; en este caso, primero se “sumergen en el túnel” y luego, si es necesario, se “devuelven del túnel”.

El concepto final en IDEF0 es el Glosario. Para cada uno de los elementos IDEF0: diagramas, bloques funcionales, arcos de interfaz, el estándar existente implica la creación y mantenimiento de un conjunto de definiciones correspondientes, palabras clave, narrativas, etc. que caracterizan el objeto desplegado por este elemento. Este conjunto se denomina glosario y es una descripción de la esencia de este elemento. Por ejemplo, para el arco de la interfaz de control de la "orden de pago", el glosario puede contener una lista de campos correspondientes al arco del documento, conjunto requerido visas, etc. El glosario complementa armoniosamente el lenguaje gráfico, proporcionando a los diagramas la información adicional necesaria.

Figura 4. Descomposición de bloques funcionales.

Principios para limitar la complejidad de los diagramas IDEF0

Normalmente, los modelos IDEF0 llevan información compleja y concentrada, y para limitar su congestión y hacerlos legibles, se adoptan los límites de complejidad correspondientes en el estándar correspondiente:

Limitar el número de bloques funcionales en el diagrama de tres a seis. El límite superior (seis) obliga al diseñador a utilizar jerarquías al describir elementos complejos, y el límite inferior (tres) asegura que haya suficiente detalle en el diagrama correspondiente para justificar su creación;

Limitar el número de arcos de interfaz adecuados para un bloque funcional (dejando un bloque funcional) a cuatro.
Por supuesto, no es necesario seguir estrictamente estas restricciones, sin embargo, como muestra la experiencia, son muy prácticas en el trabajo real.

Disciplina del trabajo en grupo en el desarrollo del modelo IDEF0

El estándar IDEF0 contiene un conjunto de procedimientos que permiten a un gran grupo de personas de diferentes áreas del sistema modelado desarrollar y acordar un modelo. Normalmente, el proceso de desarrollo es iterativo y consta de las siguientes etapas condicionales:

Creación de un modelo por un grupo de especialistas relacionados con diversas áreas de la empresa. Este grupo se denomina Autores en términos de IDEF0. La construcción de un modelo inicial es un proceso dinámico durante el cual los autores preguntan a personas competentes sobre la estructura de varios procesos. Sobre la base de las disposiciones existentes, los documentos y los resultados de la encuesta, se crea un Borrador de modelo del modelo.

Distribución del borrador para revisión, aprobación y comentarios. En esta etapa, el borrador del modelo se discute con una amplia gama de personas competentes (en términos de lectores de IDEF0) en la empresa. Al mismo tiempo, cada uno de los diagramas del borrador del modelo es criticado y comentado por escrito y luego transferido al autor. El autor, a su vez, también está de acuerdo por escrito con la crítica o la rechaza, esbozando la lógica de la toma de decisiones y devuelve el borrador revisado para su posterior consideración. Este ciclo continúa hasta que los autores y lectores llegan a un consenso.

Aprobación del modelo. El modelo aprobado es aprobado por el jefe grupo de trabajo en el caso de que los autores del modelo y los lectores no tengan desacuerdos sobre su adecuación. El modelo final es una visión coherente de la empresa (sistema) desde un punto de vista dado y para un propósito determinado.
La visibilidad del lenguaje gráfico IDEF0 hace que el modelo sea bastante legible para personas que no participaron en el proyecto de su creación, así como efectivo para la realización de espectáculos y presentaciones. En el futuro, sobre la base del modelo construido, se pueden organizar nuevos proyectos destinados a realizar cambios en la empresa (en el sistema).

Características de la práctica nacional de utilizar modelos funcionales mediante IDEF0

V últimos años El interés por las metodologías de la familia IDEF crece constantemente en Rusia. Constantemente observo esto, mirando las estadísticas de llamadas a mi página web personal (http://www.vernikov.ru), que describe brevemente los principios básicos de estos estándares. Al mismo tiempo, yo diría que el interés en estándares como el IDEF3-5 es teórico y el IDEF0 está prácticamente justificado. De hecho, las primeras herramientas Case que permiten construir diagramas DFD e IDEF0 aparecieron en el mercado ruso en 1996, simultáneamente con el lanzamiento del popular libro sobre los principios del modelado en los estándares SADT.

Sin embargo, la mayoría de los ejecutivos todavía consideran la aplicación práctica del modelado en los estándares IDEF como un tributo a la moda, más que forma eficiente Optimización del sistema de gestión empresarial existente. Lo más probable es que esto se deba a una falta pronunciada de información sobre aplicación práctica estas metodologías y con el indispensable sesgo software de la mayoría absoluta de las publicaciones.

No es ningún secreto que casi todos los proyectos para el estudio y análisis de las actividades financieras y económicas de las empresas ahora en Rusia están de una forma u otra relacionados con la construcción de sistemas automatizados administración. Gracias a esto, los estándares IDEF, en el entendimiento de la mayoría, se han vuelto condicionalmente inseparables de la implementación de las tecnologías de la información, aunque con su ayuda a veces es posible resolver de manera efectiva incluso los pequeños problemas locales, literalmente con la ayuda de un lápiz y papel.

Al realizar proyectos complejos de encuestas empresariales, el desarrollo de modelos en el estándar IDEF0 le permite mostrar de forma visual y eficaz todo el mecanismo de las actividades empresariales en el contexto deseado. Sin embargo, lo más importante es la colaboración que brinda IDEF0. En mi actividades practicas Hubo bastantes casos en los que la construcción del modelo se llevó a cabo con la asistencia directa de empleados de varios departamentos. Al mismo tiempo, el consultor les explicó los principios básicos del IDEF0 en un tiempo bastante corto y les enseñó a trabajar con el software de aplicación correspondiente. Como resultado, los empleados de varios departamentos crearon diagramas IDEF de las actividades de su unidad funcional, que debían responder a las siguientes preguntas:

¿Qué va a la unidad "en la entrada"?

¿Qué funciones y en qué secuencia se realizan dentro de la unidad?

¿Quién es el responsable de cada una de las funciones?

¿En qué se guía el ejecutor en el desempeño de cada una de las funciones?

¿Cuál es el resultado del trabajo de la unidad (salida)?

Después de acordar los borradores de los diagramas dentro de cada departamento específico, el consultor los ensambla en un borrador del modelo empresarial, en el que todos los elementos de entrada y salida están vinculados. En esta etapa, se registran todas las discrepancias de los diagramas individuales y sus lugares controvertidos. Además, este modelo pasa nuevamente por los departamentos funcionales para una mayor coordinación y hacer los ajustes necesarios. Como resultado, en un tiempo bastante corto y con la participación de un mínimo de recursos humanos de una empresa consultora (y estos recursos, como saben, son muy costosos), se obtiene un modelo IDEF0 de una empresa de acuerdo con el “ Como es ”principio, y, lo que es importante, representa una empresa con puestos de empleados que laboran en ella y conocen a fondo todos los matices, incluidos los informales. En el futuro, este modelo se trasladará para su análisis y procesamiento a analistas de negocio que buscarán cuellos de botella en la gestión de la empresa y optimizarán los procesos clave, transformando el modelo “Como está” en la vista “Como debe ser” correspondiente. Con base en estos cambios, se llega a una conclusión final, que contiene recomendaciones para reorganizar el sistema de gestión.

Por supuesto, tal enfoque requiere una serie de medidas organizativas, principalmente por parte de la dirección de la empresa encuestada. Esto se debe a que esta técnica implica la asignación de responsabilidades adicionales a parte del personal en el dominio y aplicación práctica de nuevas metodologías. Sin embargo, al final, esto vale la pena, ya que las una o dos horas adicionales de trabajo de los empleados individuales durante varios días pueden ahorrar significativamente dinero en el pago de servicios de consultoría a una empresa externa (que en cualquier caso interrumpirá el trabajo). de los mismos empleados con cuestionarios y preguntas). En cuanto a los propios empleados de la empresa, de una forma u otra, no he encontrado ninguna oposición expresada por su parte.

La conclusión de todo esto se puede hacer de la siguiente manera: no es en absoluto necesario encontrar soluciones para problemas estándar cada vez. Siempre que se enfrente a la necesidad de analizar un sistema funcional en particular (desde un sistema de diseño de naves espaciales hasta el proceso de preparación de una cena compleja), utilice métodos que se han probado a lo largo de los años. Uno de estos métodos es IDEF0, que le permite resolver problemas complejos de la vida con la ayuda de sus herramientas simples y comprensibles.

El propósito de la metodología es construir un diagrama funcional del sistema en estudio que describa todos los procesos necesarios con una precisión suficiente para un modelado inequívoco de la actividad del sistema.

La metodología se basa en cuatro conceptos principales: bloque de funciones, arco de interfaz, descomposición, glosario.

Bloque funcional(Cuadro de actividad) representa algunos función en el marco del sistema considerado. De acuerdo con los requisitos de la norma, el nombre de cada bloque funcional debe formularse en el modo verbal (por ejemplo, "producir servicios"). En el diagrama, el bloque funcional está representado por un rectángulo (Fig. 3.).

Cada uno de los cuatro lados de un bloque funcional tiene su propio significado específico (rol), mientras que:

El lado superior es Control;

El lado izquierdo es Entrada;

El lado derecho está configurado en Salida;

El lado inferior está configurado en Mecanismo.

Arco de interfaz(Flecha) muestra un elemento del sistema que es procesado por un bloque de funciones o que afecta de otra manera función representado por este bloque de funciones. Los arcos de interfaz a menudo se denominan corrientes o flechas.

Arroz. 3. - Bloque funcional

Con la ayuda de arcos de interfaz, se muestran varios objetos que, en un grado u otro, determinan los procesos que tienen lugar en el sistema. Dichos objetos pueden ser elementos del mundo real (piezas, automóviles, empleados, etc.) o flujos de datos e información (documentos, datos, instrucciones, etc.).

Dependiendo de qué lado del bloque funcional encaja este arco de interfaz, se denomina "entrante", "saliente" o "control".

Descomposición(Descomposición) es el concepto básico del estándar IDEF0. El principio de descomposición se aplica al dividir un proceso complejo en sus partes constituyentes. función... En este caso, el nivel de detalle del proceso lo determina directamente el desarrollador del modelo.

La descomposición le permite representar de manera gradual y estructurada el modelo del sistema en forma de una estructura jerárquica de diagramas individuales, lo que lo hace menos sobrecargado y fácil de digerir (Fig. 4).

El concepto final en IDEF0 es el Glosario. Para cada uno de los elementos IDEF0 - diagramas, bloques funcionales, arcos de interfaz - el estándar existente implica la creación y mantenimiento de un conjunto de definiciones apropiadas, palabras clave, narrativas, etc. que caracterizan el objeto mostrado por este elemento. Este conjunto se denomina glosario y es una descripción de la esencia de este elemento. El glosario complementa armoniosamente el lenguaje gráfico, proporcionando a los diagramas la información adicional necesaria.

El modelo IDEF0 siempre comienza con la presentación del sistema como un todo: un solo bloque funcional con arcos de interfaz que se extienden más allá del área considerada. Tal diagrama con un bloque funcional se llama diagrama contextual.

El texto explicativo del diagrama de contexto debe indicar objetivo(Propósito) construir el diagrama como una breve descripción y fijo Punto de vista.

Arroz. 4.- Esquema de descomposición de bloques funcionales del modelo

Determinar y formalizar el objetivo de desarrollar un modelo IDEF0 es un punto de suma importancia. De hecho, el objetivo identifica las áreas relevantes en el sistema en estudio en las que se debe enfocar primero.

El punto de vista define la dirección principal de desarrollo del modelo y el nivel de detalle requerido..

Una clara fijación del punto de vista permite descargar el modelo, abandonando el detalle y la búsqueda de elementos individuales que no son necesarios, en función del punto de vista elegido sobre el sistema. La elección correcta del punto de vista reduce significativamente el tiempo dedicado a la construcción del modelo final.

Destacando subprocesos... En el proceso de descomposición, el bloque funcional, que en el diagrama de contexto muestra el sistema como un todo, se perfora en otro diagrama. El diagrama resultante del segundo nivel contiene bloques funcionales que muestran las subfunciones principales del bloque funcional del diagrama de contexto, y se llama Diagrama hijo en relación con él (cada uno de los bloques funcionales que pertenecen al diagrama hijo se llama respectivamente el diagrama hijo). Caja).

A su vez, el bloque de función principal se denomina bloque principal en relación con el diagrama secundario (Cuadro principal), y el diagrama al que pertenece se denomina diagrama principal (Diagrama principal). Cada una de las subfunciones del diagrama hijo se puede detallar más mediante una descomposición similar del bloque funcional correspondiente. En cada caso de descomposición de un bloque funcional, todos los arcos de interfaz que entran o salen de este bloque se fijan en el diagrama hijo. Esto logra la integridad estructural del modelo IDEF0.

A veces no tiene sentido seguir considerando arcos de interfaz individuales del nivel superior en los diagramas del nivel inferior, o viceversa, para reflejar arcos individuales del nivel inferior en diagramas de niveles superiores, esto solo sobrecargará los diagramas y hará son difíciles de entender. Para resolver estos problemas, el estándar IDEF0 prevé el concepto de tunelización. La notación "Arrow Tunnel" en forma de dos paréntesis alrededor del comienzo del arco de interfaz indica que este arco no fue heredado del bloque padre funcional y apareció (del "túnel") solo en este diagrama.

A su vez, la misma designación alrededor del extremo (flecha) del arco de interfaz en las inmediaciones del bloque receptor significa que este arco no se mostrará y no se considerará en el diagrama secundario de este bloque. Muy a menudo sucede que los objetos individuales y sus correspondientes arcos de interfaz no se consideran en algunos niveles intermedios de la jerarquía; en este caso, primero "se sumergen en el túnel" y luego, si es necesario, "regresan del túnel".

Normalmente, los modelos IDEF0 contienen información compleja y concentrada y, para limitar su congestión y hacerlos legibles, el estándar adopta las restricciones de complejidad adecuadas.

Se recomienda representar en el diagrama de tres a seis bloques funcionales, mientras que se supone que el número de arcos de interfaz adecuados para un bloque funcional (dejando un bloque funcional) no es más de cuatro.

El estándar IDEF0 contiene un conjunto de procedimientos que permiten a un gran grupo de personas de diferentes áreas del sistema modelado desarrollar y acordar un modelo.

Por lo general, el proceso de desarrollo es iterativo y consta de las siguientes etapas condicionales: Creación de un modelo por un grupo de especialistas relacionados con diversas áreas de la empresa. Este grupo se denomina Autores en términos de IDEF0. La construcción de un modelo inicial es un proceso dinámico, durante el cual los autores entrevistan a personas competentes sobre la estructura de varios procesos, creando modelos para las actividades de los departamentos.

Al mismo tiempo, están interesados en las respuestas a las siguientes preguntas:

¿Qué va a la unidad "en la entrada"?

Que tipo función y en que secuencia se realizan dentro de la unidad?

¿Quién es responsable de la implementación de cada uno de los funciones?

¿Qué es guiado por el intérprete al realizar cada uno de los funciones?

¿Cuál es el resultado del trabajo de la unidad (salida)?

Sobre la base de las disposiciones existentes, los documentos y los resultados de la encuesta, se crea un Borrador de modelo del modelo.

Distribución del borrador para revisión, aprobación y comentarios. En esta etapa, hay una discusión del borrador del modelo con una amplia gama de personas competentes (en términos de IDEF0 - lectores) en la empresa. Al mismo tiempo, cada uno de los diagramas del borrador del modelo es criticado y comentado por escrito y luego transferido al autor. El autor, a su vez, también está de acuerdo por escrito con la crítica o la rechaza esbozando la lógica de la toma de decisiones y devuelve el borrador revisado para su posterior consideración. Este ciclo continúa hasta que los autores y lectores llegan a un consenso.

Aprobación del modelo. El modelo aprobado es aprobado por el jefe del grupo de trabajo en el caso de que los autores del modelo y los lectores no tengan desacuerdos sobre su adecuación. El modelo final es una visión coherente de la empresa (sistema) desde un punto de vista dado y para un propósito determinado.

La visibilidad del lenguaje gráfico IDEF0 hace que el modelo sea bastante legible para personas que no participaron en el proyecto de su creación, así como efectivo para la realización de espectáculos y presentaciones. En el futuro, sobre la base del modelo construido, se pueden organizar nuevos proyectos destinados a realizar cambios en el modelo.

El modelo IDEF0 se recomienda para su uso en una empresa cuando se describen procesos comerciales en el nivel superior. Al elaborar un modelo funcional de un proceso empresarial (IDEF0), las funciones realizadas y los flujos de entrada y salida de material, recursos financieros e información (documentos, archivos).

Las convenciones de formato IDEF0 se presentan en las Tablas 2, 3.

Tabla 2. - Símbolos gráficos de notación IDEF0

Símbolo	Imagen	Descripción
Cuadra		El bloque describe el proceso. Un bloque típico se muestra en la fig. 1. Cada bloque contiene su nombre y número. El nombre debe ser un verbo activo, un cambio verbal o un sustantivo verbal. El número de bloque se encuentra en la esquina inferior derecha. Los números de bloque se utilizan para la identificación en el diagrama y en el texto correspondiente.
Flecha		Las flechas indican los objetos (datos) entrantes y salientes del proceso. Cada lado de un bloque de funciones tiene un significado estándar en términos de comunicación bloque-flecha. A su vez, el lado del bloque al que se adjunta la flecha define de manera única su función. Flechas entrando lado izquierdo bloque - entradas. Las flechas que ingresan al bloque desde arriba son controles. Las flechas que salen del proceso a la derecha son salidas, es decir. datos u objetos materiales producidos por el proceso. Las flechas conectadas a la parte inferior del bloque representan mecanismos.
Flecha de túnel		Las flechas en forma de túnel indican que los datos indicados por estas flechas no se ven en el gráfico principal y / o en el gráfico secundario. Una flecha colocada en el túnel donde se une al bloque significa que los datos expresados por esa flecha no son necesarios en el siguiente nivel de descomposición. Una flecha colocada en un túnel en el extremo libre significa que los datos que representa no están presentes en el gráfico principal.
Referencia externa		Una referencia externa es un lugar, entidad o sujeto que está fuera de los límites del sistema modelado. Se utiliza para indicar el origen o el destino de una flecha fuera del modelo. En los diagramas, la Xref se muestra como un cuadrado, junto al cual se muestra el nombre de Xref.
Enlace entre diagramas		Un elemento que designa otro gráfico. Se utiliza para indicar la transición de flechas al diagrama de otro proceso empresarial sin mostrar la flecha en el diagrama anterior (cuando se utilizan modelos jerárquicos).

Tabla 3. - Símbolos gráficos de notación IDEF0

IDEF0 es una notación de modelado gráfico que se utiliza para crear un modelo funcional que describe la estructura y las funciones de un sistema, así como los flujos de información y objetos materiales que vinculan estas funciones. El estándar IDEF0 (Definición de Integración para Modelado de Funciones) fue aprobado en los EE. UU. En 1993 como el Estándar Federal de Procesamiento de Información. En Rusia ha estado en el estado de un documento de orientación desde 2000 y actualmente no está aprobado como estándar. Sin embargo, la metodología IDEF0 es uno de los enfoques populares para describir los procesos comerciales. Entre sus características se incluyen:

usando un diagrama de contexto;

soporte de descomposición;

dominio;

selección de 4 tipos de flechas.

Diagrama contextual. El diagrama superior, en el que el objeto de modelado está representado por un solo cuadro con flechas de límite. Este diagrama se llama A-0 (A menos cero). Las flechas en este diagrama representan los vínculos entre el objeto de modelado y medio ambiente... El gráfico A-0 establece el área de modelado y su límite. Un ejemplo del diagrama A-0 se muestra en la Fig. 1.

Figura 1. Diagrama A-0 en notación IDEF0

Soporte de descomposición. La notación IDEF0 admite la descomposición secuencial del proceso al nivel de detalle requerido. El diagrama hijo creado por descomposición cubre la misma área que el proceso padre, pero lo describe con más detalle. Según la metodología IDEF0, durante la descomposición, las flechas del proceso padre se transfieren al diagrama hijo en forma de flechas de límite.

Dominación. Los bloques del modelo IDEF0 en un diagrama no contextual deben ubicarse en diagonal, desde la esquina superior izquierda del diagrama hacia la parte inferior derecha en el orden de los números asignados. Los bloques del diagrama de la parte superior izquierda "dominan" los bloques de la parte inferior derecha. Se entiende por "dominancia" la influencia que tiene un bloque sobre otros bloques del diagrama. La disposición de los bloques en la hoja del gráfico refleja la comprensión del autor del dominio. Por lo tanto, la topología del diagrama muestra qué características tienen el mayor impacto sobre las demás.

Asignación de 4 tipos de flechas. Destacar los siguientes tipos flecha: "Entrada", "Salida", "Mecanismo", "Control". Las entradas son transformadas o consumidas por el proceso para crear lo que aparece en su salida. Los controles definen las condiciones necesarias para que el proceso produzca la salida correcta. Las salidas son datos u objetos materiales producidos por el proceso. Los mecanismos identifican los medios para apoyar la ejecución de un proceso. Así, el bloque IDEF0 muestra la transformación de una entrada en una salida mediante mecanismos que tienen en cuenta las acciones de control.

La descripción del propósito de los símbolos gráficos utilizados en la notación IDEF0 se da en la Tabla 1.

Nombre	Símbolo gráfico	Descripción
		El proceso está indicado por un recuadro rectangular. Cada bloque contiene su nombre y número. El nombre debe ser un verbo activo, un cambio verbal o un sustantivo verbal. El número de bloque se encuentra en la esquina inferior derecha. Los números de bloque se utilizan para la identificación en el diagrama y en el texto correspondiente.
		Las flechas indican los objetos (datos) entrantes y salientes del proceso. Cada lado del bloque de funciones tiene un significado estándar en términos de comunicación bloque-flecha. A su vez, el lado del bloque al que se adjunta la flecha define de manera única su función. Las flechas que entran por el lado izquierdo del bloque son entradas. Las flechas que ingresan al bloque desde arriba son controles. Las flechas que salen del proceso a la derecha son salidas, es decir. datos u objetos materiales producidos por el proceso. Las flechas conectadas a la parte inferior del bloque representan mecanismos.
Flecha de túnel		Las flechas de túnel indican que los datos que fluyen a través de estas flechas no se ven en el gráfico principal y / o el gráfico secundario. Una flecha colocada en el túnel donde se une al bloque significa que los datos expresados por esa flecha no son necesarios en el siguiente nivel de descomposición. Una flecha colocada en el túnel en el extremo libre significa que los datos que representa no están presentes en el gráfico principal. Las flechas de túnel se pueden utilizar en los diagramas de proceso en las notaciones IDEF0, "Proceso", "Procedimiento".
		El elemento designa un lugar, entidad o sujeto que está fuera de los límites del sistema modelado. Las referencias externas se utilizan para indicar el origen o el destino de una flecha fuera del modelo. En los diagramas, una referencia externa se muestra como un cuadrado, junto al cual se muestra el nombre de la referencia externa. Los enlaces externos se pueden utilizar en los diagramas de proceso en cualquier notación.
		Un elemento que designa otro gráfico. Un enlace entre diagramas se utiliza para indicar la transición de una flecha a un diagrama de otro proceso sin mostrar una flecha en el diagrama anterior (cuando se utilizan modelos jerárquicos). Un diagrama de proceso en notaciones EPC y BPMN no puede actuar como una referencia entre diagramas. Los enlaces entre diagramas se pueden utilizar en los diagramas de proceso en las notaciones IDEF0, "Proceso", "Procedimiento".
		El elemento denota una referencia a un modelo de proceso típico. Los procesos que se repiten con más frecuencia dentro del modelo de procesos de negocio se pueden identificar como típicos en una carpeta separada en Navegador... El diagrama de un proceso típico se forma una vez en un solo lugar Navegador... Además, en cualquier diagrama, se puede utilizar un proceso que se vincule a un proceso típico. Los parámetros de un proceso típico se rellenan directamente Ventana de propiedades un proceso típico. También se forma una lista permanente de sujetos que participan en la implementación de un proceso típico en Ventana de propiedades un proceso típico. La lista de sujetos que participan en la implementación de un proceso típico en el marco del proceso superpuesto se forma en Ventana de propiedades enlaces de proceso a un proceso típico. Los procesos de referencia se pueden utilizar en los diagramas de procesos en cualquier notación.
		Un elemento de llamada diseñado para agregar comentarios. El elemento se puede utilizar en diagramas de proceso en cualquier notación.

Conocida hoy no solo en círculos estrechos, la abreviatura IDEF0 es la primera metodología para estandarizar el trabajo en procesos comerciales. Fue desarrollado a mediados del siglo pasado como parte de un proyecto aeroespacial en los Estados Unidos y, habiendo demostrado su efectividad, se ha convertido en un estándar federal. En nuestro país en el año 2000 se elaboró un documento " Metodología de modelado funcional IDEF0. Documento guía Metodología de modelado funcional Documento de orientación IDEF0. Edición oficial. Gosstandart de Rusia RD IDEF0 - 2000. Desarrollado por el Centro de Investigación CALS - Tecnologías "Logística Aplicada". Adoptado y puesto en vigor por la Resolución del Gosstandart de Rusia 2000, Moscú”, Pero como estándar nunca fue aprobado. Aunque esto no impidió que esta metodología se convirtiera en una de las herramientas de modelado gráfico de procesos de negocio más populares en nuestro país. En este artículo, los invito a revisar el modelo IDEF0 y evaluar la relevancia actual de este enfoque.

Conceptos básicos y abreviaturas

Entendamos un poco sobre los nombres de los elementos clave de la metodología. El estándar gráfico IDEF0 es parte de la metodología SADT (Structured Analysis and Design Technique). IDEF es una abreviatura de ICAM Definition, e ICAM se deriva de Integrated Computer Aided Manufacturing, que se traduce como informatización integrada de la producción. La metodología SADT es una familia completa de 15 diferentes modelos, que en el complejo se suponía que permitían el estudio de la estructura, parámetros y características de los sistemas productivos-técnicos y organizativos-económicos.

IDEF0 es un modelo funcional, que es el núcleo de todas las demás estructuras, vincula los flujos de información y materiales, la estructura organizativa, las acciones de control y la propia actividad de la empresa. El estándar gráfico para los procesos de modelado también se llama notación. Es decir, la notación es un sistema de requisitos y reglas para construir un modelo de actividad de una forma u otra. Por tanto, conviene llamar IDEF0 a la notación que forma parte de la metodología SADT.

La notación IDEF0 es una técnica bastante rigurosa que se desarrolló originalmente, como los estándares de diseño técnico, para el modelado manual. Por lo tanto, contiene requisitos para la ubicación de flechas, el formato de todos los elementos, el contenido del marco de información para el diagrama IDEF0, etc. Dado que las actividades de la empresa son un complejo sistema de acciones multinivel, siempre hay muchos esquemas, y se requiere una sistematización y navegación inequívocas a través de todos los elementos del modelo. Ahora bien, esto se hace principalmente por sistemas informáticos que admiten el modelado en esta notación. En el territorio de Rusia, los más famosos y disponibles en la actualidad son los sistemas AllFusion Process Modeler y Business Studio. Planeo dedicar artículos separados a la revisión de estos sistemas.

Bloque funcional

El elemento central del modelo IDEF0 es la función, que se muestra en el diagrama como bloque funcional- un rectángulo, dentro del cual se indica la acción en forma de sustantivo verbal. La acción puede ser muy diferente en escala, desde las actividades de la empresa en general hasta la manipulación específica en particular. Ejemplos: "Producción y venta de platos de cerámica" y "Dibujo de un producto".

Elementos de bloque de función obligatorios en IDEF0

Independientemente de la escala de acciones, todas las funciones se muestran de manera uniforme y necesariamente contienen 4 flujos de teclas, que se asignan rígidamente a los lados del bloque funcional:

a la izquierda, insumos o recursos utilizados para realizar la función;
a la derecha - salidas o resultados de la ejecución de la función;
en la parte superior: acciones de control que determinan cómo y cuántos resultados deben producirse;
a continuación: mecanismos que reflejan quién y con la ayuda de qué debe hacer este trabajo.

Este enfoque le permite ahorrar un poco en las explicaciones de los diagramas y lograr una ambigüedad en la visualización de los flujos, lo que hace que todo el modelo sea más delgado.

Para construir un modelo funcional, la metodología IDEF0 requiere que se observen las siguientes reglas.

Los insumos son recursos que transfieren su valor a los productos por completo, es decir, se gastan en crear un resultado en su totalidad, y los mecanismos son recursos que transfieren su valor solo parcialmente (equipos a través de la depreciación y personas a través de los salarios).
La gestión es un elemento necesario del modelo, ya que vincula todas las actuaciones al sistema normativo de la empresa, indicando claramente qué normas y requisitos deben observarse en el proceso de desempeño de la función. A menudo, este flujo se trata formalmente, pero el esquema pierde su rigor y, a veces, incluso su significado.
Cada bloque funcional debe tener al menos una flecha a cada lado (ya que no puede haber trabajo sin recursos o resultados, y una instrucción sin ejecutor o instrucción estará incompleta).

El esquema considerado es un "bloque de construcción" del enfoque IDEF0. El modelado funcional implica una transición gradual de lo general a lo particular a través de la descomposición. La descomposición es una "profundización" en la función en consideración, dividiéndola en funciones más pequeñas. Al mismo tiempo, cuando la función de nivel superior se presenta de forma generalizada y después de descomponerla, conviene llamarla proceso.

Diagrama contextual

En el nivel más alto, la empresa se presenta como una "caja negra" en la que tiene lugar alguna actividad que traduce insumos en productos. Este nivel se suele denominar "", es decir, un diagrama que describe el contexto de las actividades de la empresa. Además, el diagrama de contexto muestra las características clave de todo el modelo.

El objetivo es una formulación específica del propósito del modelo, mediante la cual se puede verificar la precisión de la construcción del modelo en el futuro.
Punto de vista: en cuya cara se construye el modelo, ya que el modelo siempre depende de su autor y foco de atención. Si construimos un modelo general de empresa, generalmente se presenta desde el punto de vista de su director.
El tipo de modelo es una indicación de la información que se muestra en los diagramas. Puede haber 2 opciones principales aquí: TAL CUAL ("como está") o POR SER ("como será"). Esta separación es necesaria, ya que podemos construir modelos tanto para analizar actividades como para transformarlas. Debemos ser claramente conscientes de lo que estamos haciendo y también transmitir esta información a los demás.

Así, el diagrama de contexto contiene en la forma más generalizada una descripción de las actividades de la empresa, que está impregnada de los flujos que conectan a la empresa con el mundo exterior. Creo que también deberíamos detenernos en ellos con más detalle.

Corrientes principales

La experiencia ha demostrado que, a pesar de la aparente sencillez y formalidad de este nivel, muchas veces es necesario permanecer en él durante mucho tiempo, ya que aquí deben reflejarse todos los resultados que son significativos para el propietario y el mercado. Un error puede llevar a la creación de modelos que no cumplan con los objetivos del negocio. Para verificar que se reflejen los flujos significativos, asegúrese de que los 4 tipos de flujo principales estén presentes en su diagrama.

Material: materiales y componentes en la entrada y productos terminados a la salida.
Cliente: un cliente potencial a la entrada y uno satisfecho a la salida.
Financiero: en la entrada, suelen ser inversiones, pagos de clientes (ingresos), préstamos y otros ingresos; el resultado son pagos a proveedores, impuestos, pagos de préstamos y ganancias.
Informativo: en la entrada, son todos los flujos de información sobre el entorno externo (condiciones del mercado, comportamiento de la competencia, innovaciones tecnológicas, etc.), y en la salida, es el flujo de información que la empresa comunica sobre sí misma al mundo (toda la información publicitaria, así como todo tipo de reportes ante las autoridades reguladoras).

Tenga en cuenta que la empresa es sistema abierto, y nada surge ni desaparece en él. Una empresa solo puede transformar flujos entrantes en flujos salientes, y si lo hace bien, entonces un adicional Flujo de efectivo(beneficio), reflejando, en cierto sentido, la calidad de todo el sistema.

(Click para agrandar)

Es bueno si resaltas cada uno de estos tipos de flujos con tu propio color para que puedas distinguir fácilmente el movimiento de recursos y no perderte puntos importantes... Por ejemplo, a menudo es posible observar la ausencia de un cliente en los flujos de la empresa, por lo tanto, trabajar con él se basa en un principio sobrante: el cliente a menudo se siente como un obstáculo para los empleados de la empresa, cuyas tareas se centran en procesar el flujo de documentos.

Las flechas de control se pueden representar mediante un solo tipo de flujo: el flujo de información, que se puede dividir en 2 subespecies. El primero son documentos como:

leyes y regulaciones;
pedidos, pedidos;
instrucciones y reglamentos;
planes;
documentación de diseño, etc.

La segunda es la información no documentada, que generalmente incluye los requisitos de los propietarios.

Y, finalmente, mecanismos: solo hay 2 tipos de flujos: equipo (material) e intérpretes (departamentos y personas). ¡No puede haber documentos aquí, al igual que no puede haber personas en los puntos de control!

El modelo proporciona numeración continua para la navegación. El diagrama de contexto está numerado "A-0". En el futuro, cada bloque funcional obtendrá su propio número, sin importar cuán profunda sea la descomposición.

Descomposición

Después de calcular los flujos del diagrama de contexto, podemos proceder a la descomposición. Pasando a un nivel inferior, como abriendo una "caja negra", primero vemos una hoja en blanco con flechas que se han adjuntado al bloque funcional.

(Click para agrandar)

Y aquí comienza el modelado funcional real: debemos comprender qué conjunto de acciones pueden conectar estos flujos y garantizar que se cumplan todos los requisitos. La dificultad radica en el hecho de que hay muchas acciones en la empresa y, en el diagrama, tenemos derecho a mostrar no más de 9 funciones, de lo contrario, el diagrama se volverá ilegible y, en consecuencia, inútil.

No siempre es fácil organizar actividades complejas de tal manera que sigan siendo visuales, legibles y al mismo tiempo completas. Muy a menudo, recurren a dividir toda la variedad de procesos en grandes bloques principales, los más importantes de los cuales son los siguientes.

Creación de un producto (resultado).
Promoción y venta: trabajar con el flujo de clientes.
El apoyo a las actividades de creación de productos son procesos secundarios que son necesarios para cumplir con los requisitos gubernamentales o para asegurar la conveniencia del trabajo (personal y contabilidad, servicios de transporte, limpieza de locales, etc.).
Creación de flujos de gestión: la actividad de desarrollar soluciones de gestión que determinarán los requisitos para todos los procesos de la empresa.

La siguiente figura muestra el diagrama de descomposición de nuestro ejemplo.

(Click para agrandar)

En el diagrama, los procesos deben organizarse en diagonal, esto se llama principio de dominio, lo que implica la disposición de bloques funcionales de izquierda a derecha y de arriba a abajo, en orden de importancia o en orden cronológico... La numeración de bloques es la misma.

El trabajo adicional en el modelo es similar al primer paso: cada bloque funcional del primer nivel se descompone. La numeración del bloque contendrá el número del primer nivel: A1.1… A1n, A2.1… A2.n, etc.

Conclusiones sobre la relevancia de la notación

En el marco de este artículo, fue posible mapear solo los conceptos básicos de la notación IDEF0 a breve ejemplo IDEF0, por el que, por supuesto, es difícil juzgar la metodología en general. Pero mucha experiencia en el uso de esta notación en la práctica me permite sacar las siguientes conclusiones.

El modelo tiene un buen potencial visualizador, pero, en mi opinión, su mayor importancia está en el efecto disciplinario. Las reglas y limitaciones incrustadas en la metodología nos obligan a desarrollar una actitud sistemática y estricta hacia los modelos, lo que repercute muy bien en la calidad del resultado final.
El modelo le permite construir flujos de comunicación entre cosas aparentemente no fuertemente conectadas: conectar los subsistemas de front y back office con la administración, lo cual es mucho peor para otras notaciones.
El enfoque es simple y directo para la mayoría de los participantes del proyecto. La construcción y lectura de diagramas en esta notación está limitada solo por el deseo de profundizar en las complejidades de los flujos comerciales.

Algunos de los argumentos anteriores hacen pensar que este enfoque es el mejor y el único para un modelado completo de actividades. Pero no olvide que el modelo funcional está diseñado solo para el nivel superior de modelado. El uso de la notación IDEF0 para el diseño del trabajo a nivel de ejecutante lleva al hecho de que los diagramas son puramente ilustrativos y sobre su base es imposible construir una regulación sensata, ya que no contienen:

concretar los eventos de inicio y parada del proceso;
condiciones para la transición de una acción a otra;
la capacidad de mostrar visualmente todos los recursos e intérpretes sin sobrecargar el diagrama con flechas.

Por lo tanto, si usa esta notación para las tareas para las que está destinada (estructurar actividades de nivel superior), IDEF0 es prácticamente la única notación actual que le permite hacer esto de manera significativa y precisa.

V gestión de proyectos este estándar de modelado es más aplicable cuando necesita vincular diferentes proyectos o procesos con flujos visuales. Al mismo tiempo, el modelo gráfico permitirá distribuir de forma más racional la responsabilidad y los recursos por tareas. La lógica de las tareas del proyecto, reflejada en los diagramas, ayudará a preparar un mejor cronograma en forma de diagrama de Gantt.

Una imagen vale mil palabras

Sabiduria popular

A menudo en mi trabajo existe la necesidad no solo de estudiar y resolver un problema específico, sino de identificar su ubicación en el modelo general de la empresa. No es suficiente comprender que una determinada unidad no está funcionando correctamente, es importante comprender cómo interactúa con otras. De lo contrario, es imposible identificar todos los problemas existentes y elegir el mejor método para resolver el problema. Y para ello se requiere estudiar el trabajo de la empresa y elaborar su modelo funcional.

Por supuesto, en teoría, el gerente debería tener un modelo funcional del trabajo de la empresa, y no importa si estamos hablando de organizar el trabajo de un almacén o de un sistema informático desde el lead hasta la aplicación. Pero en realidad casi nunca resulta, y por eso en el proceso de estudio y búsqueda de una solución al problema planteado por el cliente, también creo un modelo funcional del trabajo de la empresa o un determinado proceso (función) por mi cuenta. .

Algunas palabras sobre los beneficios de los gráficos.

Como sabes, los modelos funcionales IDEF0 son siempre diagramas gráficos. Tienen sus propias características y reglas de compilación. Hablaremos de esto un poco más tarde. Ahora me gustaría dar un par de ejemplos de la efectividad de los gráficos. ¿Por qué me estoy enfocando en esto? Lo más probable es que, tras mi aseveración sobre la necesidad de un modelo funcional del trabajo de la empresa, mucha gente pensó que todo esto no era necesario, es posible explicar con palabras cómo funciona tal o cual función en la empresa. De esto es de lo que quiero hablar.

Y para empezar, hagamos una pequeña excursión a la historia. Regresemos al lejano 1877, en el período Guerra Ruso-Turca... Fue entonces cuando el polígrafo Sytin utilizó por primera vez gráficos al describir las operaciones militares. Ahora para nosotros todo esto es familiar, al describir cualquier batalla, aparecen cartas con flechas frente a los ojos de todos, que muestran claramente el curso de la batalla. Y en esos días, las acciones militares se describían con palabras. Hay muchas, muchas palabras para cada pelea. Y fue muy difícil entender lo que estaba pasando al final.

Por lo tanto, la idea de Sytin fue verdaderamente revolucionaria: comenzó a imprimir copias litográficas de mapas que mostraban las fortificaciones y ubicaciones de las unidades militares. Estas tarjetas se llamaron “Para lectores de periódicos. Beneficio ". La idea resultó ser tan relevante que la primera edición de los "Manuales" se agotó instantáneamente. Y luego, estas aplicaciones tuvieron una gran demanda. La razón es obvia. Los gráficos ayudaron a comprender lo que era casi imposible de distinguir con la ayuda de palabras.

Puedo dar un ejemplo similar de la impotencia de las descripciones verbales de mi propia práctica. Uno de mis clientes me pidió mucho que se hiciera cargo de la implementación de un sistema ERP para su empresa. Cuando se les preguntó si tenían alguna tarea técnica, recibí la respuesta: “Sí, la hay. Pero tiene 400 páginas ". Al mismo tiempo, el cliente se quejó mucho de que mis colegas, con quienes se había puesto en contacto anteriormente, abandonaron el proyecto por completo o pidieron precios claramente inflados. Después de ver que los términos de referencia en realidad tenían 400 páginas, y consistían exclusivamente en una descripción de texto, entendí las razones del comportamiento de los desarrolladores. Leer tal volumen de texto, profundizar en él, comprender todos los matices solo para comprender la tarea y nombrar el precio, esto es realmente muy difícil.

Le ofrecí a este cliente una opción alternativa: describir todo lo que sea posible gráficamente en forma de notaciones. Le mostró ejemplos de modelaje. Como resultado, ahora están reconsiderando sus deseos y el diseño de la tarea técnica.

También conozco muchos otros ejemplos en los que el modelado gráfico de procesos comerciales ayudó tanto a mis colegas, consultores comerciales y desarrolladores, como a los propios empresarios.

¿Por qué es importante para mi trabajo?

Mi trabajo siempre está relacionado con la realización de cambios en el sistema existente. Y para realizar cambios y obtener el resultado deseado, debe estudiar lo que existe ahora. Y no importa qué hagamos exactamente: configuramos o instalamos un sistema CRM desde cero, creamos un sistema ERP eficaz, integramos varios sistemas para aumentar la automatización del trabajo en general. En cualquier caso, para empezar, debe tener una idea del esquema de trabajo existente, y solo después de eso puede proponer algunos cambios y pensar en opciones para resolver el problema.

Después de estudiar el estado actual de la situación, yo, como cualquier otro tercero especialista, creo una oferta comercial en la que expongo mi visión de la situación actual con el mayor detalle posible, así como las acciones que se deben realizar para resolver la tarea y, por supuesto, el resultado esperado.

Dichos informes sobre la encuesta del trabajo son voluminosos, ocupan más de una página, lo que, por un lado, es necesario y, por otro, complica la percepción. Al principio, como muchos otros, pensé que los informes extensos son buenos, porque una persona paga por el trabajo y necesita que se le proporcione la mayor cantidad de información detallada posible.

Errores típicos

El modelado funcional se realiza utilizando una variedad de herramientas, incluidas aquellas que no están diseñadas para modelar. En el último caso, no hay verificación de errores ni limitaciones de la norma. El deseo de aumentar la visibilidad y la falta de experiencia a menudo terminan en errores.

Usando diferentes colores

Todos los elementos del diagrama son igualmente importantes. En el modelado funcional, no hay más ni menos elementos importantes... La desaparición de cualquiera dará lugar a la interrupción del proceso y defectos de fabricación.

A menudo, al modelar en papel o en varios programas, los usuarios intentan aumentar la visibilidad utilizando Colores diferentes... Este es uno de los errores más comunes. De hecho, el uso de flechas y bloques de colores solo agrega confusión y distorsiona la percepción del diagrama.

Su modelo debe poder leerse en blanco y negro, sin ningún tipo de soluciones de color... Este enfoque simultáneamente ayuda a evitar malentendidos y disciplina al creador del modelo, lo que resulta en una mejor legibilidad y alfabetización del modelo.

Demasiados bloques

Al diseñar un modelo, a menudo intentan mostrar todos los matices del trabajo de la empresa con todos los detalles en una hoja. El resultado es una gran cantidad de bloques con una gran cantidad de flechas de control. En este caso, se pierde la legibilidad.

La mejor opción es detallar, lo suficiente para comprender el problema y nada más. Se pueden revelar detalles detallados del trabajo de cada departamento o incluso empleado al elegir una vista detallada de un proceso en particular. Y tal estructura se crea solo si es realmente necesaria para el trabajo o la toma de decisiones.

Desglose de la estructura al realizar ajustes.

Tenga cuidado de no crear confusión o procesos sin elementos entrantes, salientes y otros elementos importantes. Por ejemplo, si en el ejemplo anterior considero oportuno cambiar el punto de vista al redactor, eliminaré al autor del esquema. Y luego los controles de "experiencia del autor y fuentes de terceros" y el plan de publicación se vuelven innecesarios. Después de todo, el autor los usa. Un redactor trabaja con un archivo de audio. Y si se quedan en esquema general, luego, al detallar, llevarán a que no esté claro a dónde y causarán confusión.

Asimismo, si decido agregar un bloque, es importante asegurarme de que también tenga todos los atributos requeridos. El cuidado es muy importante aquí, ya que al modelar procesos comerciales complejos, los cambios en una parte del modelo pueden conducir a cambios en otra. Deben ser ingresados.

Reglas para nombrar controles y bloques

Es importante recordar una regla simple: las flechas de control se llaman sustantivos, los bloques se llaman verbos. Este es el estándar IDEF0 y este enfoque ayuda a evitar confusiones y errores.

La mayoría de las veces, se cometen errores al nombrar bloques. Por ejemplo, en lugar de "Crear artículo", escriben "Crear artículo". Los bloques en este enfoque son acciones y, por lo tanto, siempre deben ser verbos.

Beneficios de usar IDEF0

El primer beneficio es obvio: es la visibilidad. Usted mismo comienza a comprender cómo funciona este o aquel sistema, y también puede explicar claramente dónde están los "cuellos de botella" en este sistema y cómo sus decisiones ayudarán a deshacerse de ellos.
Comprensión mutua y falta de discrepancia. Cuando se habla del trabajo de una empresa utilizando un modelo funcional, se tienen bloques de tareas visuales e intuitivos con elementos de control. Además, el modelado funcional implica la creación, si es necesario, de un glosario en el que leyenda y términos. Como resultado, usted y el cliente, el gerente y otros empleados hablan el mismo idioma cuando discuten el problema.
Sencillez y alta velocidad de creación de modelos. Por supuesto, aprender a modelar no es tan fácil como parece. Después de todo, un esquema es, de hecho, una presentación de información ultradensa, que es muy buena para la comprensión, pero se requiere un enfoque especial para implementar dicha presentación. En este caso, el cerebro del analista actúa como una prensa muy poderosa por un lado y un filtro por el otro. Pero con la experiencia, este proceso se vuelve muy rápido. Como resultado, obtiene una herramienta que lo ayudará a descubrir qué está sucediendo en un sistema en particular y, con la ayuda de una ayuda visual creada en poco tiempo, ilustra los puntos importantes para sus colegas o clientes.
Disciplina y falta de error. El estándar IDEF0 asume marcos y reglas estrictos. Este enfoque es disciplinado y el hábito de actuar dentro del estándar ayuda a evitar errores debido a la falta de atención. Cualquier violación de la norma es inmediatamente visible.

¿Cuál es la dificultad de usar IDEF0?

Es importante comprender que solo en los casos más simples dos analistas de negocios crearán exactamente los mismos modelos funcionales para describir el trabajo de la empresa. Cualquier modelo es un reflejo de la experiencia del analista, la profundidad de comprensión del negocio que busca describir, así como, de alguna manera, su punto de vista personal sobre este negocio. Aquellos. una persona desarrolla un modelo de negocio desde el punto de vista de un líder, como si fuera el líder.

Al mismo tiempo, creo que un analista de negocios no es una profesión, todo líder empresarial o desarrollador de algunos sistemas que analiza un negocio y busca construir lo más posible. sistema eficaz... Es para estas personas y para estos fines que está destinada la herramienta IDEF0.

Por eso es muy importante, a la hora de elaborar un modelo de negocio funcional "tal cual", consultar constantemente con el responsable de la empresa, para no cometer errores, que automáticamente conllevarán errores en las etapas de descomposición. Además, en etapas posteriores, es posible que se requiera una coordinación adicional con los líderes. unidades estructurales y empleados. Solo si su modelo funcional "tal cual" refleja realmente el estado real de las cosas, puede realizar algunos cambios y sugerencias. Y para lograr resultados de alta calidad en dicho trabajo, se requiere, en primer lugar, experiencia práctica y conocimiento de los detalles de un tipo particular de negocio.

Más artículos sobre este tema.