Metodología de modelado funcional idef0. IDEF0: modelado funcional de procesos de negocio Descripción de la metodología IDEF0

La mayoría de los involucrados en la implementación de proyectos relacionados con la creación o desarrollo de sistemas de información corporativos están de acuerdo con la tesis de que el cliente necesita un sistema de información que aumente la eficiencia de la empresa. Sin embargo, los clientes y los desarrolladores de sistemas de información todavía hablan idiomas diferentes: entienden de manera diferente lo que significa aumentar la eficiencia de una empresa.

Los desarrolladores de sistemas de información a menudo entienden un aumento en la eficiencia como un aumento en la cantidad de estaciones de trabajo en la red de área local (LAN) de una empresa, un aumento en el ancho de banda de la LAN, un aumento en la cantidad de documentos procesados ​​en estaciones de trabajo automatizadas (AWP). ), etc

Al aumentar la eficiencia de la empresa, los clientes comprenden el crecimiento de la productividad laboral, la reducción de costos y el aumento de la calidad de los productos y servicios. Recientemente, nuevas condiciones y nuevos conceptos están irrumpiendo rápidamente en la vida de los clientes: estrategia de desarrollo, competencias básicas, arquitectura comercial, reglas comerciales y mucho más.

Para que el cliente y el desarrollador del sistema de información se entiendan, es necesario que el desarrollador se reoriente desde la resolución de problemas técnicos de creación o desarrollo de un sistema de información hasta la resolución de problemas complejos para mejorar la eficiencia de la empresa del cliente. Con este enfoque, el problema de una forma efectiva de estudiar el alcance de la actividad del cliente pasa a primer plano:

• examen de la arquitectura comercial existente, procesos comerciales, reglas comerciales, flujos de información;
• identificación de problemas, "cuellos de botella" que afectan negativamente la eficiencia de la empresa;
• desarrollo e implementación de medidas para eliminar los problemas existentes y cambiar la arquitectura comercial de la empresa, reestructurando los procesos comerciales;
• desarrollo de un proyecto específico de un sistema de información corporativo, implementación de este proyecto y soporte en el futuro.

En el marco de este enfoque, se recurre a herramientas diseñadas para el modelado empresarial y la reingeniería de procesos comerciales para aumentar la eficiencia del desarrollador de sistemas de información. Uno de los representantes de esta familia de herramientas son las herramientas CASE para el modelado funcional de procesos de negocio.

Este artículo proporciona una descripción general de una clase de herramientas para el modelado funcional de procesos comerciales, centrada en el uso de la metodología IDEF0.

IDEF0 - metodología de modelado funcional

Durante la implementación del programa Integrated Computerization of Production (ICAM), propuesto en un momento por la Fuerza Aérea para la industria aeroespacial de los EE. UU., se identificó la necesidad de desarrollar métodos para analizar la interacción de los procesos en los sistemas de producción. Para satisfacer esta necesidad, se desarrolló la metodología IDEF0 (Modelado de función de definición integrada) y ahora se acepta como un estándar federal de EE. UU. La metodología ha sido aplicada con éxito en una amplia variedad de industrias, demostrándose como una herramienta efectiva para analizar, diseñar y presentar procesos de negocios. Actualmente, la metodología IDEF0 es ampliamente utilizada no solo en los Estados Unidos, sino en todo el mundo. En Rusia, IDEF0 se ha aplicado con éxito en instituciones gubernamentales (por ejemplo, en la Inspección de Impuestos del Estado), en la industria aeroespacial (en el diseño del cosmódromo de Plesetsk), en el Banco Central y los bancos comerciales de Rusia, en el petróleo y industria del gas y empresas en otras industrias.

Conceptos básicos de IDEF0

La metodología IDEF0 se basa en el concepto de un bloque que muestra alguna función comercial. Los cuatro lados del bloque tienen diferentes funciones: el lado izquierdo tiene el significado de "entrada", el lado derecho - "salida", el superior - "control", el inferior - "mecanismo" (ver Fig. 1).

La interacción entre funciones en IDEF0 se representa como un arco que representa el flujo de datos o material proveniente de la salida de una función a la entrada de otra. Dependiendo de a qué lado del bloque esté asociado el flujo, se denomina "entrada", "salida", "control" respectivamente.

Principios de modelado en IDEF0

IDEF0 implementa tres principios básicos de modelado de procesos:

• principio de descomposición funcional;
• el principio de limitación de la complejidad;
• principio de contexto.

El principio de descomposición funcional es una forma de modelar una situación típica cuando cualquier acción, operación o función se puede dividir (descomponer) en acciones, operaciones y funciones más simples. En otras palabras, una función comercial compleja se puede representar como un conjunto de funciones elementales. Representando funciones gráficamente, en forma de bloques, uno puede, por así decirlo, mirar dentro del bloque y examinar en detalle su estructura y composición (ver Fig. 2).

El principio de limitar la complejidad. Cuando se trabaja con diagramas IDEF0, la condición de legibilidad y legibilidad de los mismos es fundamental. La esencia del principio de limitación de la complejidad es que el número de bloques en el diagrama debe ser al menos dos y no más de seis. La práctica muestra que el cumplimiento de este principio conduce al hecho de que los procesos funcionales presentados en forma de un modelo IDEF0 están bien estructurados, son comprensibles y fáciles de analizar.

El principio del diagrama de contexto. El modelado de procesos de negocios comienza con la construcción de un diagrama de contexto. Este diagrama muestra solo un bloque: la función comercial principal del sistema que se está modelando. Cuando se trata de modelar una empresa completa o incluso una división grande, la función comercial principal no puede formularse como, por ejemplo, "vender productos". La principal función comercial del sistema es la "misión" del sistema, su importancia en el mundo circundante. Es imposible formular correctamente la función principal de la empresa sin tener una idea de su estrategia.

Al definir la función comercial principal, siempre debe tener en cuenta el propósito del modelado y el punto de vista del modelo. La misma empresa puede describirse de diferentes maneras, según el punto de vista desde el que se considere: el director de la empresa y el inspector fiscal ven la organización de formas completamente diferentes.

El diagrama de contexto juega otro papel en el modelo funcional. "Fija" los límites del sistema empresarial que se está modelando definiendo cómo el sistema modelado interactúa con su entorno. Esto se logra describiendo los arcos conectados a la caja que representa la función comercial principal.

Aplicación de IDEF0

Después de familiarizarse con los conceptos y principios básicos del modelado funcional de los procesos comerciales, la pregunta es natural: ¿cómo ayuda esto a mejorar la eficiencia y la calidad de la empresa?

Construyendo el modelo TAL CUAL. Una encuesta empresarial es una parte obligatoria de cualquier proyecto para la creación o desarrollo de un sistema de información empresarial. La construcción de un modelo funcional TAL CUAL le permite fijar claramente qué procesos comerciales se llevan a cabo en la empresa, qué objetos de información se utilizan en el desempeño de los procesos comerciales y operaciones individuales. El modelo funcional AS-IS es el punto de partida para analizar las necesidades de la empresa, identificar problemas y cuellos de botella y desarrollar un proyecto de mejora de procesos de negocio.

Reglas del negocio. El modelo de procesos de negocio le permite identificar y definir con precisión las reglas de negocio utilizadas en las actividades de la empresa.

En la fig. 3 muestra un fragmento del modelo funcional de flujo de trabajo. Al realizar la operación de "ordenar documentos", se utiliza la regla comercial: "el registro no está sujeto a: documentos enviados en copias para información, telegramas y cartas de permiso para viajes de negocios y vacaciones ...". Esta regla está fijada en las instrucciones para la gestión de documentos. El modelo funcional permite no solo identificar la existencia de esta regla, sino también determinar en qué operación y en qué lugar de trabajo debe aplicarse.

En el marco del modelo funcional, la regla de negocio se ve así: "si la recepción recibió un documento destinado a la gestión, está sujeto a clasificación, como resultado de lo cual, con base en la instrucción, se determina si el documento es sujetos a registro o no".

Si esta regla comercial no se tiene en cuenta al desarrollar un sistema de información, dicho sistema funcionará de manera inadecuada.

Muy a menudo, las reglas comerciales en una empresa no están escritas en instrucciones: parecen existir, pero también parecen estar ausentes. Como resultado, los intentos de cambiar algo en las actividades de una empresa o departamento pueden fallar solo porque estos cambios son contrarios a las reglas comerciales establecidas.

Objetos de información. El modelo funcional le permite identificar todos los objetos de información que la empresa opera en sus actividades. A diferencia de los modelos de información (diagramas de flujo de datos, IDEF1X), el modelo funcional IDEF0 refleja exactamente cómo se utilizan los objetos de información dentro de los procesos comerciales.

Modelismo CÓMO SER. La creación e implementación de un sistema de información corporativo conduce a un cambio en las condiciones para realizar operaciones individuales, la estructura de los procesos comerciales y la empresa en su conjunto. Esto lleva a la necesidad de cambiar el sistema de reglas de negocio utilizado en la empresa, modificar las descripciones de puestos de los empleados. El modelo funcional CÓMO SER le permite determinar estos cambios ya en la etapa de diseño del futuro sistema de información. La aplicación del modelo funcional AS NO solo reducirá el tiempo de implementación del sistema de información, sino que también reducirá los riesgos asociados con la inmunidad del personal a las tecnologías de la información.

Asignación de recursos. El modelo funcional le permite definir claramente la distribución de recursos entre las operaciones del proceso de negocio, lo que permite evaluar la eficiencia en el uso de los recursos.

Esta tarea es especialmente relevante cuando se crean nuevos procesos de negocio en la empresa. Por ejemplo, una empresa que se especializa en el desarrollo de software a la medida ha decidido crear su propia fuerza de ventas. El modelo funcional del proceso comercial para la venta de software permitirá a la gerencia de la empresa determinar claramente qué recursos deben asignarse para garantizar el funcionamiento del servicio de ventas, cuántos empleados deben ser atraídos para trabajar en el nuevo servicio, qué responsabilidades funcionales que estos empleados deben realizar, etc.

Sistemas de software IDEF0

Actualmente, existen muchas herramientas CASE que admiten el modelado funcional en el estándar IDEF0.

CONCLUSIÓN

La metodología de modelado funcional IDEF0 es una herramienta bastante sencilla que permite a los desarrolladores de sistemas de información corporativos estudiar el alcance de las actividades del cliente y resolver problemas para mejorar la eficiencia de esta actividad.

El uso del modelado funcional permite resolver no solo los problemas técnicos del cliente relacionados con la tecnología de la información, sino también los problemas relacionados con el campo de actividad del cliente. Esto le permite convertir un proyecto de sistema de información de un "paquete de papel" que el cliente no quiere pagar, en un servicio que puede tener un efecto adicional para el cliente, comparable a la automatización posterior.

El proceso de modelado de negocios se puede implementar en el marco de varios métodos, que difieren principalmente en su enfoque de lo que constituye una organización modelada. De acuerdo con diferentes ideas sobre la organización de los métodos, se acostumbra dividirlos en objetos y funcionales (estructurales).

Métodos de objetos considere la organización modelada como un conjunto de objetos que interactúan - unidades de producción. Un objeto se define como una realidad tangible, un objeto o fenómeno que tiene un comportamiento claramente definido. El propósito de aplicar esta técnica es identificar los objetos que componen la organización, y la distribución de responsabilidades entre ellos por las acciones realizadas.

métodos funcionales, la más famosa de las cuales es la metodología IDEF, considera a la organización como un conjunto de funciones que transforma el flujo de información entrante en un flujo de salida. El proceso de conversión de información consume ciertos recursos. La principal diferencia de técnica de objetos consiste en una separación clara de las funciones (métodos de procesamiento de datos) de los datos mismos.

Desde el punto de vista del modelado de negocios, cada uno de los enfoques presentados tiene sus propias ventajas. El enfoque de objetos le permite construir un sistema que es más resistente a los cambios y se adapta mejor a los existentes. estructuras organizativas. modelado funcional se muestra bien en los casos en que la estructura organizacional está en proceso de cambio o generalmente está mal diseñada. El enfoque de funciones realizadas es intuitivamente mejor entendido por los artistas intérpretes o ejecutantes cuando reciben información de ellos sobre su trabajo actual.

Metodología funcional IDEF0

La metodología IDEF0 puede considerarse la siguiente etapa en el desarrollo del conocido lenguaje gráfico para describir sistemas funcionales SADT (Técnica de Diseño y Análisis Estructurado). Históricamente, IDEF0 como estándar se desarrolló en 1981 como parte de un extenso programa de automatización industrial que llevaba la designación ICAM (Integrated Computer Aided Manufacturing). La familia de estándares IDEF heredó su designación del nombre de este programa (IDEF = Icam DEFinition), y su última edición fue publicada en diciembre de 1993 por el Instituto Nacional de Estándares y Tecnología de EE. UU. (NIST).

El propósito de la técnica es construir diagrama funcional del sistema en estudio, que describe todos los procesos necesarios con una precisión suficiente para el modelado inequívoco de la actividad del sistema.

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

(Activity Box) es alguna función específica dentro del sistema considerado. De acuerdo con los requisitos de la norma, el nombre de cada bloque funcional debe formularse en modo verbal (por ejemplo, "para producir servicios"). En el diagrama, un bloque funcional está representado por un rectángulo (Fig. 6.1). Cada uno de los cuatro lados del 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 tiene el significado de "Mecanismo" (Mechanism).

Arroz. 6.1.

Arco de interfaz(Flecha) muestra el elemento del sistema que es procesado por el bloque de funciones o que de otro modo afecta la función representada por este bloque de funciones. Los arcos de interfaz a menudo se denominan flujos o flechas.

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

Dependiendo de en qué lado del bloque funcional encaje el arco de interfaz dado, se denomina "entrante", "saliente" o "control".

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 un arco de salida. Esto es comprensible: cada proceso debe ocurrir de acuerdo con algunas reglas (que se muestran en el arco de control) y debe producir algún resultado (arco de salida), de lo contrario, su consideración no tiene ningún sentido.

La presencia obligatoria de arcos de interfaz de control es una de las principales diferencias entre el estándar IDEF0 y otras metodologías de las clases DFD (Diagrama de flujo de datos) y WFD (Diagrama de flujo de trabajo).

Descomposición( Descomposición ) es el concepto central del estándar IDEF0. El principio de descomposición se aplica cuando un proceso complejo se descompone en las funciones que lo componen. Donde nivel de detalle El proceso está determinado directamente por el desarrollador del modelo.

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

El último de los conceptos IDEF0 es glosario. Para cada uno de los elementos IDEF0 (diagramas, bloques de función, arcos de interfaz), el estándar existente implica la creación y el mantenimiento de un conjunto de definiciones, palabras clave, declaraciones narrativas, etc. apropiadas que caracterizan el objeto mostrado por este elemento. Este conjunto se llama glosario y es una descripción de la esencia de este elemento. El glosario complementa armónicamente el lenguaje gráfico visual, dotando a los diagramas de la información adicional necesaria.

El modelo IDEF0 siempre comienza con una vista del sistema como un todo: una sola unidad funcional con arcos de interfaz que se extienden más allá del área considerada. Tal diagrama con un bloque funcional se llama diagrama contextual.

En el texto explicativo de diagrama contextual debe especificarse meta(Propósito) gráficos como una descripción breve y fija punto de vista(punto de vista).

La definición y formalización del propósito de desarrollar un modelo IDEF0 es un punto sumamente importante. De hecho, la meta determina las áreas relevantes en el sistema bajo estudio, que necesitan ser enfocadas primero.

El punto de vista determina la dirección principal del desarrollo del modelo y el nivel de detalle requerido.. Una fijación clara del punto de vista le permite descargar el modelo, negándose a detallar y estudiar elementos individuales que no son necesarios, según el punto de vista elegido en el sistema. La elección correcta del punto de vista reduce significativamente el tiempo dedicado a construir el modelo final.

Separación de subprocesos. En el proceso de descomposición, el bloque funcional, que en diagrama contextual muestra el sistema como un todo, se detalla en otro diagrama. El diagrama de segundo nivel resultante contiene bloques de funciones que muestran las subfunciones principales del bloque de funciones. diagrama contextual, y se denomina child (Child Diagram) en relación con él (cada uno de los bloques funcionales pertenecientes al child diagram se denomina respectivamente child block - Child Box). A su vez, el bloque funcional: el antecesor 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 puede detallarse aún más mediante una descomposición similar de su bloque funcional correspondiente. En cada caso de descomposición de un bloque funcional, todos los arcos de interfaz que entran en el bloque dado o que salen de él se fijan en el diagrama hijo. Esto logra la integridad estructural del modelo IDEF0.

A veces no tiene sentido continuar considerando arcos de interfaz de nivel superior individuales en diagramas de nivel inferior, o viceversa, reflejar arcos de nivel inferior individuales en diagramas de niveles superiores, esto solo sobrecargará los diagramas y dificultará su lectura. Para resolver tales problemas, el estándar IDEF0 prevé el concepto de tunelización. La designación "túnel" (Túnel de flecha) en forma de dos paréntesis alrededor del comienzo del arco de la interfaz significa que este arco no se heredó del bloque principal funcional y apareció (del "túnel") solo en este diagrama. A su vez, la misma designación alrededor del final (flecha) del arco de la interfaz en las inmediaciones del bloque receptor significa que este arco no se mostrará ni se considerará en el diagrama hijo de este bloque. En la mayoría de los casos, sucede que los objetos individuales y sus arcos de interfaz correspondientes 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".

• Creación de un modelo por un grupo de especialistas relacionados con diversas áreas de la empresa. Este grupo se llama Autores en términos IDEF0. La construcción del modelo inicial es un proceso dinámico durante el cual los autores interrogan a personas competentes sobre la estructura de varios procesos, creando modelos de las actividades de los departamentos. Están interesados ​​en las respuestas a las siguientes preguntas:

  ¿Qué entra en la unidad "en la entrada"?

  • ¿Qué funciones y en qué secuencia se realizan dentro de la unidad?
  • ¿Quién es el responsable de realizar cada una de las funciones?
  • ¿Qué guía al ejecutante en el desempeño de cada una de las funciones?
  • ¿Cuál es el resultado del trabajo de la unidad (salida)?

  Con base en las disposiciones existentes, los documentos y los resultados de la encuesta, se crea un borrador (Model Draft) del modelo.

• Distribución del borrador para su consideración, aprobaciones y comentarios. En esta etapa, el borrador del modelo se discute con una amplia gama de personas competentes (en términos de IDEF0 - lectores) en la empresa. Al mismo tiempo, se critica y comenta por escrito cada uno de los esquemas del borrador del modelo, para luego trasladarlo al autor. El autor, a su vez, también está de acuerdo con la crítica por escrito o la rechaza con una declaración de la lógica de la decisión y devuelve nuevamente el borrador corregido para su posterior consideración. Este ciclo continúa hasta que los autores y los lectores llegan a un consenso.
• Homologació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 consistente de la empresa (sistema) desde un punto de vista dado y para un propósito dado.

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 demostraciones y presentaciones. En el futuro, sobre la base del modelo construido, se pueden organizar nuevos proyectos destinados a realizar cambios en el modelo.

IDEF0 es, con mucho, el estándar principal para el modelado de procesos comerciales. La descripción de un sistema usando IDEF0 se llama modelo funcional . El modelo describe lo que ocurre en el sistema, cómo se gestiona, qué entidades transforma, qué medios utiliza para realizar sus funciones y qué produce.

Al construir un modelo, uno debe establecer el propósito de la simulación, respondiendo las siguientes preguntas:

¿Por qué se debe modelar este proceso?

¿Qué debe mostrar el modelo?

¿Qué puede obtener el lector?

Ejemplos de definición de objetivos: "identificar y definir problemas actuales, permitir el análisis de mejoras potenciales", "identificar los roles y responsabilidades de los empleados para escribir descripciones de puestos", "determinar la posibilidad de automatización...", "regular el proceso.. .", etc

Punto de vista es también uno de los elementos clave en la construcción de un modelo. El punto de vista se puede representar como la vista de una persona que ve el sistema en el aspecto necesario para el modelado. El punto de vista debe ser consistente con el propósito de la simulación.

El principal principio conceptual de la metodología IDEF es la representación de cualquier sistema bajo estudio como un conjunto de bloques que interactúan e interconectan que muestran procesos, operaciones y acciones que ocurren en el sistema bajo estudio. En IDEF0, todo lo que sucede en el sistema y sus elementos se llama funciones Cada función está asociada cuadra.

Los bloques funcionales en los diagramas están representados por cuadros que representan procesos, funciones, actividades u operaciones con nombre que tienen lugar durante un cierto período de tiempo y tienen resultados reconocibles. Dentro de cada bloque se coloca su nombre y número. El nombre del bloque debe ser un verbo activo, una frase verbal o un sustantivo verbal que denote una acción.

Los bloques en IDEF0 se colocan en orden de importancia, tal como lo entiende el autor del diagrama. Este orden relativo se llama dominancia. La dominancia se entiende como la influencia que tiene un bloque sobre otros bloques del diagrama. El cuadro más dominante generalmente se coloca en la esquina superior izquierda del diagrama, mientras que el cuadro menos dominante se coloca en la esquina derecha.

Las interfaces a través de las cuales el bloque interactúa con otros bloques o con el entorno externo al sistema que se está modelando están representadas por flechas, entrar o salir del bloque. Cada lado de un bloque de funciones tiene un significado estándar en términos de la relación bloque/flecha. La disposición estándar de las flechas se muestra en la Fig.1.

Arroz. 1. Contexto IDEF0.

flechas describir la interacción de los bloques con el mundo exterior y entre sí. Las flechas representan alguna información y se llaman sustantivos o frases nominales.

IDEF0 distingue cinco tipos de flechas:

1. Entrada - material o información que es utilizada o transformada por un bloque funcional para obtener un resultado (salida). Se permite que la obra no tenga ninguna flecha de entrada.

2. Gobernanza: las reglas, políticas, procedimientos o normas que rigen la unidad. El control afecta al bloque, pero no es transformado por él.

3. Salida: material o información que produce el bloque. Un bloque sin resultado no tiene sentido y no debe modelarse.

4. Mecanismo: recursos que realizan el bloqueo, por ejemplo, personal de la empresa, máquinas, dispositivos, etc. A criterio del analista, las flechas del mecanismo no podrán visualizarse en el modelo.

5. Llamar (Llamar): una flecha especial que apunta a un modelo de trabajo diferente. La flecha de llamada se utiliza para indicar que se está realizando algún trabajo fuera del sistema simulado.

Las flechas en el diagrama de contexto se utilizan para describir la interacción del sistema con el mundo exterior. Flechas de límite- flechas que comienzan en el borde del diagrama y terminan en el trabajo o viceversa. Flechas internas unir los bloques. Hay cinco tipos de enlaces de trabajo.

1. Conexión por entrada: la flecha de la salida del bloque superior se dirige a la entrada del bloque inferior (Fig. 2).

Arroz. 2. La relación "output-input".

2. Comunicación por control - la salida del bloque superior se envía al control del inferior (Fig. 3).

Arroz. 3. Relación "salida-control".

3. Retroalimentación de control: la salida del bloque inferior se envía al control del bloque superior (Fig. 4).

Arroz. 4. Retroalimentación de control

4. Retroalimentación sobre la entrada: la salida del bloque inferior se envía a la entrada del bloque superior (Fig. 5).

Arroz. 5. Relación de retroalimentación de entrada

5. Conexión del mecanismo de salida: la salida de un bloque se dirige al mecanismo de otro (Fig. 6).

Arroz. 6 Conexión "mecanismo de salida".

En la notación IDEF0, la descripción del sistema (modelo) se organiza en forma de diagramas interconectados y ordenados jerárquicamente. En primer lugar, se realiza una descripción del sistema en su conjunto y su interacción con el mundo exterior (diagrama de contexto). El diagrama de contexto incluye un solo bloque que caracteriza todo el conjunto de procesos simulados, sin detalles.

Arroz. 7 Ejemplo de diagrama de contexto IDEF0.

Después de eso, se lleva a cabo una descomposición funcional (Fig. 8) - este bloque de actividad (gran proceso) se divide en grandes subprocesos - y cada subproceso se describe por separado (diagramas de descomposición). Luego, cada subproceso se descompone en otros más pequeños, y así sucesivamente hasta que se detalla la descripción requerida.

Fig.8 Un ejemplo de un diagrama de descomposición IDEF0.

Una imagen vale mil palabras

sabiduria popular

A menudo, en mi trabajo existe la necesidad no solo de estudiar y resolver un determinado problema, sino de identificar su ubicación en el modelo general de la empresa. No es suficiente comprender que una determinada unidad no funciona 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 es necesario estudiar el trabajo de la empresa y elaborar su modelo funcional.

Por supuesto, en teoría, el gerente debe tener un modelo funcional del trabajo de la empresa, y no importa si estamos hablando de la organización del almacén o del sistema de TI desde el plomo hasta la solicitud. Pero en realidad, casi nunca lo es, y por lo tanto, en el proceso de estudio y búsqueda de una solución a la tarea establecida por el cliente, también creo un modelo funcional de la empresa o un determinado proceso (función) en mío.

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. Y ahora me gustaría dar un par de ejemplos de la efectividad de los gráficos. ¿Por qué me estoy enfocando en esto? Probablemente, después de mi declaración sobre la necesidad de un modelo funcional del trabajo de la empresa, muchas personas pensaron que esto no era necesario y que era posible explicar con palabras cómo funciona esta o aquella función en la empresa. Esto es de lo que quiero hablar.

Y para empezar, hagamos una pequeña digresión en la historia. Volvamos al lejano 1877, durante la guerra ruso-turca. Fue entonces cuando el impresor Sytin utilizó por primera vez gráficos para describir operaciones militares. Ahora bien, todo esto nos resulta familiar, al describir cualquier batalla, aparecen cartas con flechas ante nuestros ojos, que muestran claramente el curso de la batalla. Y en aquellos días, las operaciones militares se describían con palabras. Para cada pelea, muchas, muchas palabras. Y fue muy difícil entender al final lo que estaba pasando.

Es por eso que la idea de Sytin fue verdaderamente revolucionaria: comenzó a imprimir copias litográficas de mapas con la designación de fortificaciones y ubicaciones de unidades militares. Estas tarjetas se llamaron “Para lectores de periódicos. Beneficio". La idea resultó ser tan relevante que la primera tirada de "Help" se agotó instantáneamente. Y luego tales aplicaciones tenían una gran demanda. La razón es obvia. Los gráficos ayudaron a comprender lo que era casi imposible de distinguir solo con la ayuda de las palabras.

También puedo citar un ejemplo similar de la impotencia de las descripciones verbales de mi propia práctica. Uno de mis clientes me pidió que me hiciera cargo de la implementación de un sistema ERP para su empresa. Cuando pregunté si tenían algún tipo de tarea técnica, recibí la respuesta: “Sí, lo tienen. Pero tiene 400 páginas”. Al mismo tiempo, el cliente se quejó mucho de que mis colegas, a quienes contactó anteriormente, rechazaron el proyecto por completo o llamaron precios claramente inflados. Después de ver que los términos de referencia tenían 400 páginas y consistían únicamente 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 es realmente muy difícil.

Le ofrecí a este cliente una opción alternativa: describir todo lo que es posible gráficamente en forma de notaciones. Le mostró ejemplos de modelado. Como resultado, ahora están repensando sus deseos y el diseño de los términos de referencia.

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 esto importante para mi trabajo?

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

Después de estudiar el estado actual de las cosas, yo, como cualquier otro especialista externo, elaboro una propuesta comercial en la que revelo con el mayor detalle posible mi visión de la situación actual, así como las acciones que deben tomarse para resolver la tarea y, por supuesto, el resultado esperado.

Dichos informes de encuestas de trabajo son voluminosos y ocupan más de una página, lo que, por un lado, es necesario, pero por otro lado, complica la percepción. Al principio, como muchos otros, pensé que los informes voluminosos son buenos, porque una persona paga por el trabajo y debes proporcionarle la información más detallada posible.

Errores comunes

El modelado funcional se realiza utilizando una variedad de herramientas, incluidas aquellas que no están diseñadas para el modelado. En este último caso, no hay verificación de errores y limitaciones del estándar. El afán de aumentar la visibilidad y la falta de experiencia suelen acabar en errores.

Uso de diferentes colores.

Todos los elementos del diagrama son igualmente importantes. En el modelado funcional no hay elementos más o menos importantes. La desaparición de alguno dará lugar a una interrupción del proceso y a un defecto de fabricación.

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

Su modelo debe ser legible en blanco y negro, sin esquemas de color adicionales. Este enfoque ayuda simultáneamente a evitar malentendidos y disciplina al creador del modelo, como resultado, aumenta la legibilidad y la alfabetización del modelo.

demasiados bloques

Al compilar un modelo, a menudo intentan mostrar en una hoja todos los matices del trabajo de la empresa con todos los detalles. El resultado es una gran cantidad de bloques con una gran cantidad de flechas de control. Se pierde 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 de un 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.

Violación de la estructura al hacer ajustes.

Observe atentamente para evitar confusiones o procesos sin entradas, salidas y otros elementos importantes. Por ejemplo, si en el ejemplo anterior, veo adecuado cambiar el punto de vista al redactor, eliminaré al autor del esquema. Y luego los controles "experiencia del autor y fuentes de terceros", así como el plan de publicación se vuelven innecesarios. Después de todo, el autor los usa. El redactor trabaja con el archivo de audio. Y si permanecen en el esquema general, al detallar, conducirán de manera incomprensible a dónde e introducirán confusión.

Asimismo, si decido agregar un bloque, es importante asegurarse de que también tenga todos los atributos requeridos. El cuidado es muy importante aquí, porque cuando se modelan procesos comerciales complejos, los cambios en una parte del modelo pueden generar 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. Esto se acepta en el estándar IDEF0 y este enfoque ayuda a evitar confusiones y errores.

Muy a menudo, se cometen errores al nombrar bloques. Por ejemplo, en lugar de "Crear un artículo" escriben "Crear un 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 hay "puntos débiles" en este sistema y cómo sus soluciones ayudarán a deshacerse de ellos.
• Entendimiento mutuo y falta de desacuerdo. Al discutir el trabajo de la empresa utilizando el modelo funcional, tiene bloques de tareas visuales e intuitivos con controles. Además, el modelado funcional implica la creación, si es necesario, de un glosario en el que se revelan símbolos y términos. Como resultado, usted y su cliente, gerente y otros empleados hablan el mismo idioma cuando discuten un problema.
• Simplicidad 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 súper densa de información, lo cual es muy bueno para la comprensión, pero se requiere un enfoque especial para implementar dicha presentación. El cerebro del analista actúa en este caso como una presión 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, ilustrar puntos importantes para colegas o clientes.
• Disciplina y sin errores. El estándar IDEF0 asume marcos y reglas estrictas. Este enfoque disciplina, y el hábito de actuar en el marco de la norma ayuda a evitar errores por desatención. Cualquier violación de la norma se vuelve inmediatamente perceptible.

¿Cuál es la dificultad de usar IDEF0?

Es importante comprender que solo en los casos más simples, dos analistas comerciales 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, y también, de alguna manera, su punto de vista personal sobre este negocio. Esos. una persona desarrolla un modelo de negocio desde el punto de vista del líder, como si fuera el líder.

Al mismo tiempo, creo que un analista comercial no es exactamente una profesión, todos los gerentes comerciales o desarrolladores de algunos sistemas se dedican al análisis comercial, analizan el negocio y se esfuerzan por construir el sistema más efectivo. Es para estas personas y para estos fines que está destinada la herramienta IDEF0.

Por lo tanto, es muy importante consultar constantemente con el jefe de la empresa al compilar un modelo de negocio funcional "tal cual", para no cometer errores que automáticamente implicarán errores en las etapas de descomposición. Además, en etapas posteriores, se pueden requerir aprobaciones adicionales de los jefes de las divisiones estructurales y de los empleados. Solo si su modelo funcional "tal cual" realmente reflejará el estado real de las cosas, puede hacer algunos cambios y sugerencias. Y para lograr resultados de alta calidad en dicho trabajo, en primer lugar, se requiere experiencia práctica y conocimiento de las características de un tipo particular de negocio.

Más artículos sobre este tema.

Estas recomendaciones para la estandarización están destinadas a ser utilizadas en el análisis y síntesis de sistemas productivos, técnicos y organizacionales y económicos utilizando métodos de modelado funcional en varios sectores de la economía.
Las recomendaciones contienen una descripción de un conjunto de herramientas para la representación visual de una amplia gama de negocios, producción y otros procesos y operaciones de una empresa en cualquier nivel de detalle,así como métodos organizativos y metodológicos de uso de estos fondos.

La constante complicación de los sistemas productivos, técnicos, organizacionales y económicos -empresas, empresas, industrias y otros sujetos de producción y actividad económica- y la necesidad de analizarlos para mejorar su funcionamiento y aumentar la eficiencia requieren el uso de herramientas especiales para describir y analizando tales sistemas. Este problema es de particular relevancia en relación con el surgimiento de empresas integradas de producción computarizada y automatizadas.
En los Estados Unidos, a finales de los años 70, se propuso e implementó el programa Integrated Computer Aided Manufacturing (ICAM), con el objetivo de aumentar la eficiencia de las empresas mediante la introducción generalizada de tecnologías informáticas (de información).
La implementación del programa ICAM requirió la creación de métodos adecuados para analizar y diseñar sistemas de producción y formas de intercambio de información entre especialistas que se ocupan de tales problemas. Para atender esta necesidad, en el marco del programa ICAM, se desarrolló la metodología de modelado IDEF (Definición ICAM), que permite estudiar la estructura, parámetros y características de los sistemas productivos, técnicos y organizacionales y económicos.

Metodología IDEF

La metodología general IDEF consta de tres metodologías particulares de modelado basadas en la representación gráfica de sistemas:
IDEF0 se utiliza para crear un modelo funcional que muestraestructura y funciones del sistema, así como el flujo de información y materialobjetos convertidos por estas funciones;
IDEF1 se utiliza para construir un modelo de información que muestraestructura y contenido de los flujos de información necesarios para apoyarfunciones del sistema;
IDEF2 le permite construir un modelo dinámico de variaciones en el tiempocomportamiento de funciones, información y recursos del sistema.
Hasta la fecha, las metodologías IDEF0 e IDEF1 (IDEF1X) son las más extendidas y utilizadas.
La metodología IDEF0, cuyas características y técnicas se describen en estas recomendaciones, se basa en un enfoque denominado
SADT - Técnica de Diseño y Análisis Estructurado - un método de análisis y diseño estructural. La base de este enfoque y la metodología IDEF0 es un lenguaje gráfico para describir (modelar) sistemas.

Conceptos generales

Modelo IDEF0: Una descripción gráfica de un sistema diseñado para un propósito específico y desde un punto de vista seleccionado. Un conjunto de documentos IDEF0 que describen las funciones del sistema mediante gráficos (diagramas), texto y un glosario.
Propósito: Breve exposición del motivo de la creación del modelo.
Punto de vista: una indicación del funcionario o departamento de la organización desde cuya posición se está desarrollando el modelo. Para cada modelo, solo hay un punto de vista.
Glosario: una lista de definiciones de palabras clave, frases y abreviaturas relacionadas con nodos, bloques, flechas o el modelo IDEF0 en general.
Texto: cualquier comentario de texto (no gráfico) en el diagrama gráfico IDEF0.
Nota modelo: Un comentario de texto que forma parte de un diagrama IDEF0 y se utiliza para registrar un hecho que no encontró un gráfico.
Función: una actividad, proceso o transformación (modelada por el bloque IDEF0) identificada por un verbo o forma verbal que describe lo que se debe hacer.
Descomposición: división de la función modelada en funciones componentes.

Ejemplo de diagrama de contexto

Diagrama

Diagrama: parte del modelo que describe la descomposición del bloque.
Contexto: el entorno en el que opera la característica (o conjunto de características en un diagrama).
Diagrama de contexto: diagrama con número de nodo A-n (A menos n) que representa el contexto del modelo. El diagrama A-0, que consta de un bloque, es un diagrama de contexto necesario (obligatorio); los diagramas con números de nodo A–1, A–2, ..., son diagramas de contexto adicionales (n > 0). Diagrama A–0 (A menos cero): un tipo especial de diagrama IDEF0 (contextual) que consiste en un solo cuadro que describe una función de nivel superior, sus entradas, salidas, controles y mecanismos, junto con declaraciones del propósito del modelo. y el punto de vista desde el que se construye el modelo.
Child Diagram: Diagrama que detalla el cuadro padre (parent).
Gráfico principal: el gráfico que contiene el cuadro principal.
Vínculo nodal: código asignado a un diagrama para identificarlo y determinar su posición en la jerarquía del modelo; se forma a partir del nombre abreviado del modelo y el número de nodo del diagrama con extensiones adicionales.
Número de nodo del diagrama: la parte del vínculo del nodo del diagrama que corresponde al número del cuadro principal.

Descomposición

En el diagrama de contexto A–0, el objeto de simulación está representado por un solo cuadro con flechas de límite que representan la relación del objeto de simulación.
con el medio ambiente

Una sola función presentada en un diagrama de contexto de nivel superior se puede descomponer en subfunciones principales mediante la creación de diagramas secundarios que contengan los detalles de los bloques principales.

Cuadra

Bloque: un rectángulo que contiene un nombre y un número y se utiliza para describir una función.

Número de bloque: Un número (0-6) colocado en la esquina inferior derecha del bloque que identifica de forma única el bloque en el diagrama.

Nombre del bloque: un verbo o frase verbal colocado dentro de un bloque que describe la función que se está modelando.

Child box: una caja en un gráfico child (child).

Caja principal: una caja que se describe en detalle mediante un diagrama secundario.

Los bloques tienen las siguientes reglas de sintaxis:

Los tamaños de los bloques deben ser lo suficientemente grandes para incluir el nombre y el número del bloque.

Los bloques deben ser rectangulares, con ángulos rectos;

Los bloques deben dibujarse con líneas sólidas.

Nudo

Nodo: un bloque que genera bloques secundarios; bloque padre.

Número de nodo: código asignado al bloque y que define su posición en la jerarquía del modelo; se puede utilizar como una expresión de referencia detallada.

Árbol de nodos: una representación de la relación entre los nodos principales y secundarios de un modelo IDEF0 en forma de gráfico de árbol. Tiene el mismo significado y contenido que la lista de nodos.

Lista de nodos: una lista, a menudo escalonada, que muestra los nodos del modelo IDEF0 de forma ordenada. Tiene el mismo significado y contenido que el árbol de nodos.

Flecha

Flecha: una línea dirigida, que consta de uno o más segmentos, que modela un canal abierto o un canal que transfiere datos u objetos materiales desde una fuente (punto de inicio de la flecha) a un consumidor (punto final con una "punta").Flecha de entrada: una clase de flechas que representan la entrada de un bloque IDEF0, es decir, los datos u objetos materiales que la función convierte en una salida. Las flechas de entrada están conectadas al lado izquierdo del bloque IDEF0.Flecha de salida: una clase de flechas que representan la salida de un bloque IDEF0, es decir, los datos u objetos materiales producidos por la función. Las flechas de salida están conectadas al lado derecho del bloque IDEF0.Flecha de Mecanismo: Clase de flechas que representan mecanismos IDEF0, es decir, los medios utilizados para ejecutar una función; incluye un estuche especial de llamada flecha. Las flechas del mecanismo están conectadas al lado inferior del bloque IDEF0.Flecha de control: una clase de flechas que, en IDEF0, representan controles, es decir, condiciones bajo las cuales el bloque saldrá correctamente. Los datos u objetos modelados como controles pueden transformarse mediante una función que produce la salida correspondiente. Las flechas de control están conectadas al lado superior del bloque IDEF0.

Etiqueta de flecha: Un sustantivo o frase nominal asociada con una flecha o segmento de flecha y que define su significado.

Flecha interna: una flecha de entrada, control o salida cuyos extremos conectan la fuente y el consumidor, que son bloques del mismo diagrama. Difiere de la flecha límite.Flecha de límite: una flecha con un extremo conectado a un origen o destino y el otro extremo no conectado a ningún cuadro en el diagrama. Muestra la conexión del diagrama con otros bloques del sistema y es diferente de la flecha interior.Segmento de flecha: un segmento de línea que comienza o termina en el costado de un bloque, en un punto de bifurcación o fusión, o en un límite (extremo no conectado de una flecha).Ramificación: división de una flecha en dos o más segmentos.Fusionar: fusionar dos o más segmentos de flecha en un segmento.Vinculación/desvinculación: combinación de valores de flecha en un valor compuesto (vinculación en un "paquete"), o división de valores de flecha (desvinculación de un "paquete"), expresado mediante la sintaxis de flecha de fusión o ramificación.Tilde: una pequeña línea discontinua (ondulada) que se utiliza para conectar una etiqueta a un segmento de flecha específico o una nota de modelo a un componente del gráfico.Código ICOM: código que hace coincidir las flechas del borde del diagrama hijo con las flechas del bloque padre; utilizado para enlaces (la abreviatura ICOM significa Entrada - entrada, Control - control, Salida - salida, Mecanismo - mecanismo).

Semántica de bloques y flechas.

Cada lado de un bloque de funciones tiene un propósito estándar en términos de la conexión de bloque/flecha. A su vez, el lado del bloque al que se une la flecha determina únicamente su función.

Las flechas tienen las siguientes reglas de sintaxis:- Las flechas rotas cambian de dirección solo en un ángulo de 90°;- Las flechas deben dibujarse con líneas sólidas.
Puede usar líneas de varios grosores; - Las flechas solo pueden consistir en líneas verticales u horizontales.
No se permiten segmentos diagonales; - Los extremos de las flechas deben tocar el borde exterior del bloque funcional,
pero no debe cruzarlo;

Las flechas deben adherirse al bloque por sus lados.
No se permite la conexión en las esquinas.