Cours : Développement d'un modèle de serre en utilisant les méthodologies de conception IDEF0, DFD et IDEF3. Création du modèle IDEF0 La méthodologie IDEF0 sur l'exemple de test

15.05.2020

Ouvrez le projet dans lequel vous souhaitez créer le modèle. Si vous n'avez pas encore créé de projet, vous pouvez utiliser le projet DEMO, disponible immédiatement après l'installation de Cradle, ou créer votre propre projet.

Pour entrer dans le DÉMO utilisation du projet Nom d'utilisateur — GESTIONNAIRE, mot de passe - GESTIONNAIRE

Comment créer votre projet est montré en détail dans cette vidéo

Après avoir créé un nouveau projet, vous pouvez également utiliser pour vous connecter Nom d'utilisateur — GESTIONNAIRE et mot de passe - GESTIONNAIRE

Création de modèle

Pour créer un modèle IDEF0, activez Panneau de projet et allez dans la section simulation Domaine Essentiel

Noter : De même, vous pouvez créer des modèles dans la section Modélisation du domaine d'implémentation, ainsi que dans n'importe quelle section configurée par l'utilisateur. La section de modélisation est en fait un espace de noms dans lequel les threads peuvent être réutilisés.

Pour créer un modèle de contexte IDEF0, cliquez avec le bouton droit sur la section IDEF0 et sélectionnez Nouveau-> Élément

Veuillez noter qu'il s'agit du nom de l'ensemble du modèle, et non du bloc fonctionnel sur A0.

Cela ouvre la zone de dessin et vous pouvez commencer à créer le modèle de contexte.

Création d'un bloc fonction

Pour cela, sélectionnez le symbole du bloc fonction sur la palette

et cliquez une fois sur la zone de travail où vous souhaitez créer le bloc fonction.

Une boîte de dialogue apparaît dans laquelle vous devez entrer le nom du bloc fonction, puis cliquez sur OK.

En conséquence, un bloc fonctionnel avec le nom que vous avez spécifié sera créé.

Vous pouvez sélectionner la bordure d'un bloc et modifier son échelle

Création de fils

Pour créer des flux, sélectionnez le symbole de flux dans la palette (sans tunnel ou avec tunnel)

puis cliquez sur le côté du bloc fonction avec lequel vous souhaitez créer un flux et cliquez sur n'importe quelle zone du bloc fonction

après cela, une boîte de dialogue pour entrer le nom du flux apparaîtra. Entrez un nom de flux court et cliquez sur OK

Noter: Vous pourrez entrer Description détaillée flux alors dans sa spécification.

Après cela, par analogie, vous pouvez créer tous les flux nécessaires

Enregistrez le modèle en appuyant sur le bouton de la disquette ou en appuyant sur CTRL+S. Lors de l'enregistrement, des spécifications de symbole seront créées que vous pourrez modifier pour donner une description plus détaillée des éléments du modèle.

Après avoir enregistré le modèle, vous pourrez voir les spécifications créées dans le panneau de projet dans la même section où vous avez créé le modèle. Deux types de spécifications seront créés - Fonction et Flux.

Décomposition du modèle

dans la boîte de dialogue qui apparaît, laissez les paramètres par défaut et cliquez sur OK

Après cela, un diagramme enfant A1 sera créé et tous les flux du diagramme A0 lui seront transférés.

Vous pouvez maintenant renommer le bloc fonctionnel créé en blanc (avec une question au lieu d'un nom) et en créer d'autres, de la même manière que nous les avons créés précédemment.

Pour renommer un préréglage de bloc fonction, sélectionnez-le et sélectionnez Renommer dans le menu contextuel

et entrez le nom requis

Par analogie, créer d'autres blocs fonction correspondant à ce niveau de décomposition

Pour créer des flux entre ces blocs fonctionnels, vous devez d'abord cliquer sur la source, puis sur le point intermédiaire pour créer un virage, puis sur la destination, par exemple, comme ceci :

En conséquence, vous obtiendrez un flux avec deux virages.

Vous pouvez ajuster la position des coudes en sélectionnant le flux et en faisant glisser les points de pliage à l'emplacement souhaité

Regardez le clip vidéo pour le voir en action

Pour supprimer (ou ajouter) un point de pliage, appuyez sur la touche MAJ de votre clavier et cliquez sur le point que vous souhaitez supprimer ou à l'endroit où vous souhaitez le créer dans le flux

Enregistrez le diagramme et assurez-vous que les spécifications appropriées sont créées

Par analogie, il est possible de décomposer les blocs fonctionnels A1.

Connue aujourd'hui non seulement dans des cercles restreints, l'abréviation IDEF0 est la première méthodologie qui standardise le travail sur les processus métier. Il a été développé au milieu du siècle dernier dans le cadre d'un projet aérospatial aux États-Unis et, après avoir montré son efficacité, est devenu une norme fédérale. Dans notre pays, en 2000, un document « Méthodologie de modélisation fonctionnelle IDEF0. Document d'orientation Méthodologie de modélisation fonctionnelle Document d'orientation IDEF0. Édition officielle. Norme d'État de Russie RD IDEF0 - 2000. Développé par le Centre de recherche pour CALS - technologies "Applied Logistics". Adopté et mis en vigueur par le décret de la norme d'État de Russie 2000 Moscou”, mais en tant que norme, il n'a jamais été approuvé. Bien que cela n'ait pas empêché cette méthodologie de devenir l'un des outils les plus populaires pour la modélisation graphique des processus métier dans notre pays. Dans cet article, je vous propose de considérer le modèle IDEF0 et d'évaluer la pertinence de cette approche à l'heure actuelle.

Concepts de base et abréviations

Parlons un peu des noms des éléments clés de la méthodologie. La norme graphique IDEF0 fait partie de la méthodologie SADT (Structured Analysis and Design Technique). IDEF est une abréviation de la définition ICAM, et ICAM est dérivé de la fabrication assistée par ordinateur intégrée, qui se traduit par l'informatisation intégrée de la production. La méthodologie SADT est une famille entière de 15 différents modèles, qui dans un complexe aurait dû permettre d'étudier la structure, les paramètres et les caractéristiques des systèmes de production, techniques, organisationnels et économiques.

IDEF0 est un modèle fonctionnel, qui est au cœur de la construction de toutes les autres structures, il relie les informations et flux de matières, l'organisation, les actions de contrôle et les activités mêmes de l'entreprise. Une norme graphique pour la modélisation de processus est également communément appelée notation. Autrement dit, la notation est un système d'exigences et de règles permettant de construire un modèle d'activité sous une forme ou une autre. Par conséquent, IDEF0 est approprié pour appeler la notation qui fait partie de la méthodologie SADT.

La notation IDEF0 est une technique assez rigoureuse qui a été développée à l'origine, comme les normes de conception technique, pour la modélisation manuelle. Par conséquent, il contient des exigences pour le placement des flèches, le format de tous les éléments, le contenu de la trame d'informations pour le diagramme IDEF0, etc. Les activités de l'entreprise étant un système complexe d'actions à plusieurs niveaux, il y a toujours beaucoup de schémas, et une systématisation et une navigation sans ambiguïté à travers tous les éléments du modèle sont nécessaires. Maintenant ils le font surtout systèmes informatiques, supportant la modélisation dans cette notation. Les systèmes AllFusion Process Modeler et Business Studio sont aujourd'hui les plus connus et les plus disponibles sur le territoire russe. Je prévois de consacrer des articles séparés à l'examen de ces systèmes.

Bloc fonction

L'élément central du modèle IDEF0 est la fonction , qui est affichée dans le diagramme sous la forme bloc fonction- un rectangle à l'intérieur duquel l'action est indiquée sous la forme d'un nom verbal. L'action peut être d'une ampleur très différente - des activités de l'entreprise en général à des manipulations spécifiques en particulier. Exemples : "Production et vente de vaisselle en céramique" et "Dessin sur le produit".

Éléments de bloc de fonction requis dans IDEF0

Quelle que soit l'échelle des actions, toutes les fonctions sont affichées de manière uniforme et contiennent nécessairement 4 flux clés qui sont assignés de manière rigide aux côtés du bloc fonctionnel :

à gauche - entrées ou ressources utilisées pour exécuter la fonction ;
à droite - sorties ou résultats de l'exécution de la fonction ;
d'en haut - actions de contrôle qui déterminent comment et combien de résultats doivent être produits ;
ci-dessous - des mécanismes qui reflètent qui et avec quoi devrait faire ce travail.

Cette approche permet d'économiser un peu sur les explications dans les schémas et d'obtenir une absence d'ambiguïté dans l'affichage des flux, ce qui rend l'ensemble du modèle harmonieux.

Pour construire un modèle fonctionnel, la méthodologie IDEF0 nécessite le respect des règles suivantes.

Les intrants sont des ressources qui transfèrent complètement leur valeur aux extrants, c'est-à-dire qu'ils sont entièrement dépensés pour créer le résultat, et les mécanismes sont des ressources qui ne transfèrent leur valeur que partiellement (l'équipement par l'amortissement et les personnes par les salaires).
La gestion est un élément nécessaire du modèle, car elle lie toutes les actions au système de réglementation de l'entreprise, indiquant clairement quelles règles et exigences doivent être respectées dans le processus d'exécution d'une fonction. Souvent, ce flux est traité de manière formelle, mais en même temps, le schéma perd de sa rigueur, et parfois même de son sens.
Chaque bloc fonction doit avoir au moins une flèche de chaque côté (car il ne peut y avoir de travail sans ressources ni résultats, et une instruction sans exécuteur ou instruction sera incomplète).

Le schéma considéré est la « brique » de l'approche IDEF0. La modélisation fonctionnelle implique une transition progressive du général au particulier par la décomposition. La décomposition est un «approfondissement» de la fonction considérée, la divisant en fonctions plus petites. En même temps, lorsque la fonction de niveau supérieur est présentée de manière généralisée puis décomposée, il convient de l'appeler un processus.

Diagramme de contexte

Au plus haut niveau, l'entreprise est considérée comme une « boîte noire » dans laquelle se déroule une activité qui traduit les intrants en extrants. Ce niveau est généralement appelé "", c'est-à-dire un schéma qui décrit le contexte des activités de l'entreprise. De plus, le diagramme de contexte affiche principales caractéristiques l'ensemble du modèle.

L'objectif est une formulation spécifique de l'objectif du modèle, selon laquelle l'exactitude de la construction du modèle peut être vérifiée à l'avenir.
Point de vue - à partir duquel le modèle est construit, car le modèle dépend toujours de son auteur et du centre d'attention. Si nous construisons modèle général entreprise, elle est généralement présentée du point de vue de son dirigeant.
Le type de modèle est une indication des informations affichées sur les diagrammes. Il peut y avoir 2 options fondamentales ici : AS IS ("as is") ou TO BE ("as will be"). Cette séparation est nécessaire car on peut construire des modèles aussi bien pour l'analyse de l'activité que pour sa transformation. Nous devons être clairs sur ce que nous faisons et communiquer cette information aux autres.

Ainsi, le schéma de contexte contient sous sa forme la plus généralisée une description des activités de l'entreprise, qui sont imprégnées des flux qui relient l'entreprise au monde extérieur. Je pense qu'ils devraient aussi être un peu plus détaillés.

Principaux flux

L'expérience a montré que, malgré l'apparente simplicité et formalité de ce niveau, il est souvent nécessaire de s'y attarder longtemps, car tous les résultats significatifs pour le propriétaire et le marché doivent s'y refléter. Une erreur peut conduire à la création de modèles qui ne remplissent pas les tâches définies pour l'entreprise. Pour vérifier que des flux significatifs sont affichés, assurez-vous que les 4 principaux types de flux sont présents dans votre diagramme.

Matière : matières et composants en entrée et produits finisà la sortie.
Client : un client potentiel à l'entrée et un client satisfait à la sortie.
Financière : à l'entrée, il s'agit généralement d'investissements, de paiements de clients (revenus), de prêts et d'autres revenus ; la production correspond aux paiements aux fournisseurs, aux impôts, aux remboursements de prêts et aux bénéfices.
Informationnel : en entrée, ce sont tous les flux d'informations sur environnement externe(conditions du marché, comportement des concurrents, innovations technologiques, etc.), et le résultat est le flux d'informations que l'entreprise rapporte sur elle-même au monde (toutes les informations publicitaires, ainsi que tous les types de rapports aux autorités réglementaires).

Veuillez noter que l'entreprise est système ouvert, et rien n'y apparaît ou ne disparaît. L'entreprise n'est capable que de convertir les flux entrants en flux sortants, et si elle le fait bien, alors il y a un supplément des flux de trésorerie(bénéfice), reflétant en quelque sorte la qualité de l'ensemble du système.

(Cliquez pour agrandir)

C'est bien si vous mettez en évidence chacun de ces types de flux avec une couleur différente afin que vous puissiez facilement distinguer le mouvement des ressources et ne pas manquer les points importants. Par exemple, il est souvent possible de constater l'absence d'un client dans les flux de l'entreprise, donc, travailler avec lui est basé sur un principe résiduel - le client se sent souvent comme une gêne pour les salariés de l'entreprise, dont les tâches sont centrées sur le traitement de la flux de documents.

Les flèches de contrôle peuvent être représentées par un seul type de flux - informationnel, qui peut être divisé en 2 sous-types. Le premier est constitué de documents tels que :

lois et règlements;
commandes, commandes;
instructions et règlements;
des plans;
documentation de conception, etc.

La seconde est l'information non documentée, qui comprend le plus souvent les exigences des propriétaires.

Et, enfin, les mécanismes - il n'y a que 2 types de flux : les équipements (matériel) et les exécutants (divisions et personnes). Il ne peut y avoir aucun document ici, tout comme il ne peut y avoir personne sur les flèches de contrôle !

Une numérotation continue est fournie pour la navigation dans le modèle. Le diagramme de contexte est numéroté "A-0". À l'avenir, chaque bloc fonctionnel recevra son propre numéro, quelle que soit la profondeur de la décomposition.

Décomposition

Après avoir élaboré les flux du diagramme de contexte, nous pouvons passer à la décomposition. En descendant un niveau plus bas, comme si on ouvrait une "boîte noire", on voit d'abord Feuille blanche avec des flèches qui ont été attachées au bloc fonction.

(Cliquez pour agrandir)

Et c'est là que commence la modélisation fonctionnelle proprement dite - nous devons comprendre quel ensemble d'actions peut connecter ces flux et nous assurer que toutes les exigences sont satisfaites. La difficulté réside dans le fait qu'il y a beaucoup d'actions dans l'entreprise, et nous avons le droit d'afficher pas plus de 9 fonctions sur le schéma, sinon le schéma deviendra illisible et, par conséquent, inutile.

Il n'est pas toujours facile d'agencer une activité complexe de manière à ce qu'elle reste visuelle, lisible et en même temps complète. Le plus souvent, ils ont recours à la division de toute la variété des processus en grands blocs principaux, dont les plus importants sont les suivants.

Création d'un produit (résultat).
Promotion et vente - travaillez avec un flux de clients.
Veiller à ce que les activités de développement de produits soient des processus secondaires nécessaires à la conformité exigences de l'état ou la commodité du travail (personnel et comptabilité, services de transport, nettoyage des locaux, etc.).
Création de flux de contrôle - activités de développement décisions de gestion, qui déterminera les exigences pour tous les processus de l'entreprise.

La figure ci-dessous montre le diagramme de décomposition de notre exemple.

(Cliquez pour agrandir)

Dans le diagramme, les processus doivent être situés en diagonale - c'est ce qu'on appelle principe de domination, ce qui implique la disposition des blocs fonctionnels de gauche à droite et de haut en bas - par ordre d'importance ou par ordre chronologique. La numérotation des blocs est la même.

Les travaux ultérieurs sur le modèle sont similaires à la première étape - la décomposition de chaque bloc fonctionnel du premier niveau est effectuée. La numérotation des blocs contiendra le numéro du premier niveau : A1.1 ... A1.n, A2.1 ... A2.n, etc.

Conclusions sur la pertinence de la notation

Dans le cadre de cet article, il a été possible d'afficher uniquement les concepts de base de la notation IDEF0 à l'aide d'un court exemple d'IDEF0, par lequel, bien sûr, il est difficile de juger la méthodologie dans son ensemble. Mais une assez grande expérience de l'utilisation de cette notation dans la pratique me permet de tirer les conclusions suivantes.

Le modèle a un bon potentiel de visualisation, mais, à mon avis, sa plus grande valeur réside dans l'effet disciplinaire. Les règles et contraintes imposées par la méthodologie obligent à développer une attitude systématique et stricte vis-à-vis des modèles, ce qui a un très bon effet sur la qualité du résultat final.
Le modèle vous permet de construire des flux de communication entre des éléments externes peu liés : pour connecter les sous-systèmes du front et du back-office avec la gestion, ce qui est bien pire pour les autres notations.
L'approche est simple et compréhensible pour la plupart des participants au projet. La construction et la lecture de diagrammes dans cette notation ne sont limitées que par le désir de se plonger dans les subtilités des flux commerciaux.

Certains des arguments ci-dessus conduisent à penser que cette approche est la meilleure et la seule pour une modélisation complète de l'activité. Mais il ne faut pas oublier que le modèle fonctionnel est conçu uniquement pour le niveau supérieur de modélisation. L'utilisation de la notation IDEF0 pour concevoir des travaux au niveau des exécutants conduit au fait que les schémas sont purement illustratifs et qu'il est impossible de construire une réglementation explicative sur leur base, car ils ne contiennent pas :

spécifier les événements de démarrage et d'arrêt du processus ;
conditions de passage d'une action à une autre ;
la possibilité d'afficher visuellement toutes les ressources et les interprètes sans surcharger le schéma avec des flèches.

Par conséquent, si vous utilisez cette notation pour les tâches auxquelles elle est destinée (activités de structuration de niveau supérieur), alors IDEF0 est pratiquement la seule notation aujourd'hui qui vous permet de le faire de manière significative et précise.

En gestion de projet, cette norme de modélisation est particulièrement applicable lorsque vous devez lier différents projets ou processus dans des flux visuels. Dans le même temps, le modèle graphique permettra une répartition plus rationnelle des responsabilités et des ressources entre les tâches. La logique des tâches du projet, reflétée dans les diagrammes, aidera à préparer une meilleure plan de calendrier sous forme de diagramme de Gantt.

Apprendre à voir et à comprendre structure fonctionnelle votre entreprise!

À l'heure actuelle, l'intérêt pour les normes de gestion généralement acceptées en Occident a fortement augmenté en Russie, cependant, dans la pratique réelle de la gestion, il y a un moment très important. De nombreux dirigeants peuvent encore être déconcertés par la question directe de structure organisationnelle entreprise ou sur le schéma des processus commerciaux existants. En règle générale, les gestionnaires de périodiques économiques les plus avancés et les lecteurs réguliers commencent à dessiner des schémas hiérarchiques compréhensibles pour eux seuls, mais dans ce processus, ils s'arrêtent généralement rapidement. Il en va de même pour les employés et les chefs de divers services et unités fonctionnelles. Dans la plupart des cas, le seul ensemble de règles déclarées en vertu desquelles une entreprise doit fonctionner est un ensemble de réglementations et les descriptions d'emploi. Le plus souvent, ces documents ont été compilés il y a plus d'un an, ils sont mal structurés et sans rapport les uns avec les autres et, par conséquent, ils prennent simplement la poussière sur les étagères. Pour le moment, une telle approche était justifiée, car lors de la formation de l'économie de marché russe, le concept de concurrence était pratiquement absent et il n'était pas particulièrement nécessaire de compter les coûts - le bénéfice était gigantesque. En conséquence, au cours des deux dernières années, nous avons vu une image tout à fait compréhensible : grandes entreprises, qui ont grandi au début des années 90, perdent progressivement leurs positions, jusqu'à un retrait complet du marché. Cela est dû en partie au fait que les normes de gestion n'ont pas été introduites dans l'entreprise, le concept d'un modèle fonctionnel d'activité et de mission était complètement absent. Par simulation divers domaines activités, il est possible d'analyser efficacement les « goulots d'étranglement » dans la gestion et d'optimiser le schéma d'affaires global. Mais, comme vous le savez, dans toute entreprise, seuls les projets qui génèrent directement des bénéfices ont la plus haute priorité, il s'agit donc généralement d'examiner les activités et de les réorganiser uniquement lors d'une crise tangible dans la gestion de l'entreprise.

À la fin des années 1990, alors que le marché commençait à devenir concurrentiel et que la rentabilité des entreprises commençait à s'effondrer, les dirigeants éprouvaient de grandes difficultés à essayer d'optimiser les coûts pour que les produits restent à la fois rentables et compétitifs. Juste à ce moment, la nécessité d'avoir sous les yeux un modèle de l'activité de l'entreprise, qui refléterait tous les mécanismes et principes d'interconnexion des différents sous-systèmes au sein d'une même entreprise, s'est clairement manifestée.

Le concept même de « modélisation des processus métier » est entré dans la vie de la plupart des analystes en même temps que l'apparition sur le marché de processus complexes. produits logiciels conçu pour l'automatisation complexe de la gestion d'entreprise. De tels systèmes impliquent toujours une étude approfondie des activités de l'entreprise avant le projet. Le résultat de cette enquête est un avis d'expert, dans lequel des recommandations sont formulées dans des paragraphes séparés pour éliminer les « goulots d'étranglement » dans la gestion des activités. Sur la base de cette conclusion, immédiatement avant la mise en œuvre du système d'automatisation, la soi-disant réorganisation des processus métier est effectuée, parfois assez grave et douloureuse pour l'entreprise. C'est, bien sûr, une équipe qui s'est développée au fil des années est toujours difficile à faire "penser d'une manière nouvelle". Ces enquêtes exhaustives sur les entreprises sont toujours complexes et diffèrent considérablement d'un cas à l'autre. Il existe des méthodologies et des normes bien établies pour résoudre ces problèmes de modélisation de systèmes complexes. Ces normes incluent la famille de méthodologies IDEF. Avec leur aide, vous pouvez afficher et analyser efficacement les modèles d'activité d'un large éventail de systèmes complexes dans différentes sections. Dans le même temps, l'étendue et la profondeur de l'examen des processus du système sont déterminées par le développeur lui-même, ce qui permet de ne pas surcharger le modèle créé avec des données inutiles. Actuellement, les normes suivantes peuvent être attribuées à la famille IDEF :

IDEF0 est une méthodologie de modélisation fonctionnelle. A l'aide d'un langage graphique visuel IDEF0, le système à l'étude apparaît aux développeurs et aux analystes comme un ensemble de fonctions interdépendantes (blocs fonctionnels - en termes d'IDEF0). En règle générale, la modélisation IDEF0 est la première étape de l'apprentissage de tout système ;

IDEF1 - méthodologie de modélisation flux d'informations au sein du système, permettant d'afficher et d'analyser leur structure et leurs relations ;

IDEF1X (IDEF1 Extended) est une méthodologie de construction de structures relationnelles. IDEF1X appartient au type de méthodologies Entité-Relation (ER) et est généralement utilisé pour modéliser des bases de données relationnelles pertinentes pour le système considéré ;

IDEF2 est une méthodologie de modélisation dynamique de l'évolution des systèmes. En raison des difficultés très sérieuses de l'analyse des systèmes dynamiques, cette norme a été pratiquement abandonnée et son développement a été suspendu au tout début. Cependant, il existe actuellement des algorithmes et leurs implémentations informatiques qui permettent de transformer un ensemble de diagrammes statiques IDEF0 en modèles dynamiques construits sur la base de « réseaux de Petri colorés » (CPN – Color Petri Nets) ;

IDEF3 est une méthodologie de documentation des processus se produisant dans un système, qui est utilisée, par exemple, dans l'étude des processus technologiques dans les entreprises. IDEF3 décrit le scénario et la séquence des opérations pour chaque processus. IDEF3 a une relation directe avec la méthodologie IDEF0 - chaque fonction (bloc fonctionnel) peut être représentée comme un processus séparé à l'aide des outils IDEF3 ;

IDEF4 est une méthodologie de construction de systèmes orientés objet. Les outils IDEF4 vous permettent d'afficher visuellement la structure des objets et les principes sous-jacents de leur interaction, vous permettant ainsi d'analyser et d'optimiser des systèmes complexes orientés objet ;

IDEF5 est une méthodologie pour l'étude ontologique des systèmes complexes. En utilisant la méthodologie IDEF5, l'ontologie d'un système peut être décrite à l'aide d'un certain vocabulaire de termes et de règles, sur la base desquels des déclarations fiables sur l'état du système considéré à un moment donné peuvent être formées. Sur la base de ces déclarations, des conclusions sont tirées sur le développement ultérieur du système et son optimisation est effectuée.
Dans le cadre de cet article, nous considérerons la méthodologie de modélisation fonctionnelle IDEF0 la plus couramment utilisée.

L'histoire de la norme IDEF0

La méthodologie IDEF0 peut être considérée comme la prochaine étape dans le développement du langage graphique bien connu pour décrire les systèmes fonctionnels SADT (Structured Analysis and Design Teqnique). Il y a quelques années, une petite édition d'un livre du même nom a été publiée en Russie, consacrée à la description des principes de base de la construction de diagrammes SADT. Historiquement, IDEF0 en tant que standard a été développé en 1981 dans le cadre d'un vaste programme d'automatisation entreprises industrielles, qui portait la désignation ICAM (Integrated Computer Aided Manufacturing) et a été proposé par le Département américain de l'Armée de l'Air. La famille de normes IDEF elle-même a hérité sa désignation du nom de ce programme (IDEF=ICAM DEFinition). Dans le processus mise en œuvre pratique, les participants au programme ICAM ont été confrontés à la nécessité de développer de nouvelles méthodes d'analyse des processus d'interaction dans les systèmes industriels. Dans le même temps, outre un ensemble amélioré de fonctions de description des processus métier, l'une des exigences de la nouvelle norme était la disponibilité d'une méthodologie efficace d'interaction au sein de «l'analyste-spécialiste». Autrement dit, nouvelle méthode devait assurer un travail de groupe sur la création du modèle, avec la participation directe de tous les analystes et spécialistes impliqués dans le projet.

À la suite de la recherche de solutions appropriées, la méthodologie de modélisation fonctionnelle IDEF0 est née. Depuis 1981, la norme IDEF0 a subi plusieurs modifications mineures, pour la plupart restrictives, et sa dernière révision a été publiée en décembre 1993 par le National Institute of Standards and Technology (NIST) des États-Unis.

Éléments et concepts de base d'IDEF0

Le langage graphique IDEF0 est remarquablement simple et harmonieux. La méthodologie repose sur quatre concepts principaux.

Le premier d'entre eux est le concept d'une boîte d'activité. Le bloc fonctionnel est représenté graphiquement par un rectangle (voir Fig. 1) et représente une fonction spécifique au sein du système considéré. Selon les exigences de la norme, le nom de chaque bloc fonctionnel doit être formulé dans le mode verbal (par exemple, « produire des services », et non « produire des services »).

Chacun des quatre côtés du bloc fonctionnel a sa propre signification spécifique (rôle), tandis que :

Le côté supérieur est "Contrôle" ;

Le côté gauche est "Entrée" ;

Le côté droit est réglé sur "Sortie" ;

La face inférieure a la signification « Mécanisme » (Mécanisme).

Chaque unité fonctionnelle au sein du système unique considéré doit avoir son propre numéro d'identification unique.

Figure 1. Bloc fonctionnel.

La seconde « baleine » de la méthodologie IDEF0 est le concept d'arc d'interface (Flèche). De plus, les arcs d'interface sont souvent appelés flux ou flèches. Un arc d'interface représente un élément système qui est traité par un bloc fonction ou affecte autrement la fonction affichée par ce bloc fonction.

L'affichage graphique de l'arc d'interface est une flèche unidirectionnelle. Chaque arc d'interface doit avoir son propre nom unique (étiquette de flèche). Selon la norme, le nom doit être un chiffre d'affaires d'un nom.

À l'aide d'arcs d'interface, divers objets sont affichés qui, à un degré ou à un autre, déterminent les processus se produisant dans le système. Ces objets peuvent être des éléments du monde réel (pièces, wagons, employés, etc.) ou des flux de données et d'informations (documents, données, instructions, etc.).

Selon le côté auquel l'arc d'interface donné s'approche, il est appelé « entrant », « sortant » ou « contrôlant ». De plus, la « source » (début) et le « récepteur » (fin) de chaque arc fonctionnel ne peuvent être que des blocs fonctionnels, tandis que la « source » ne peut être que le côté sortie du bloc, et le « récepteur » peut être n'importe quel bloc. des trois restants.

Il est à noter que tout bloc fonctionnel, selon les exigences de la norme, doit avoir au moins un arc d'interface de commande et un arc sortant. C'est compréhensible - chaque processus doit se dérouler selon certaines règles (affichées par l'arc de contrôle) et doit produire un résultat (arc sortant), sinon sa prise en compte n'a aucun sens.

Lors de la construction de diagrammes IDEF0, il est important de séparer correctement les arcs d'interface entrants des arcs de contrôle, ce qui n'est souvent pas facile. Par exemple, la figure 2 montre le bloc fonctionnel « Usiner la pièce ».

Dans un processus réel, le travailleur effectuant le traitement reçoit une pièce et des instructions technologiques pour le traitement (ou des règles de sécurité lors du travail avec la machine). Il peut sembler erroné que la pièce et le document avec les instructions technologiques soient des objets entrants, mais ce n'est pas le cas. En fait, dans ce processus, la pièce est traitée selon les règles reflétées dans les instructions technologiques, qui doivent être respectivement représentées par l'arc d'interface de commande.

Figure 2.

Une autre chose est lorsque les instructions technologiques sont traitées par le chef technologue et que des modifications y sont apportées (Fig. 3). Dans ce cas, ils sont déjà affichés par l'arc d'interface entrant, et l'objet de contrôle est, par exemple, de nouvelles normes industrielles, sur la base desquelles ces modifications sont apportées.

figure 3

Les exemples ci-dessus mettent l'accent sur la nature apparemment similaire des arcs d'interface entrants et de contrôle, mais il existe toujours certaines distinctions pour les systèmes de la même classe. Par exemple, dans le cas des entreprises et des organisations, il existe cinq principaux types d'objets : les flux de matières (pièces, marchandises, matières premières, etc.), les flux financiers (espèces et non monétaires, investissements, etc.), les flux de documents flux (documents commerciaux, financiers et organisationnels), flux d'informations (informations, données d'intention, commandes verbales, etc.) et ressources (employés, machines, machines, etc.). Dans ce cas, dans divers cas, les arcs d'interface entrants et sortants peuvent afficher tous les types d'objets qui ne gèrent que ceux liés au flux de documents et d'informations, et seules les ressources peuvent être affichées sous forme d'arcs-mécanismes.

La présence obligatoire d'arcs d'interface de contrôle est l'une des principales différences entre le standard IDEF0 et les autres méthodologies des classes DFD (Data Flow Diagram) et WFD (Work Flow Diagram).

Le troisième concept de base de la norme IDEF0 est la décomposition. Le principe de décomposition est appliqué lors du partitionnement procédure complexeà ses fonctions composantes. Dans ce cas, le niveau de détail du processus est déterminé directement par le développeur du modèle.

La décomposition vous permet de représenter progressivement et de manière structurée le modèle du système sous la forme structure hiérarchique diagrammes individuels, ce qui le rend moins encombré et plus facile à digérer.

Le modèle IDEF0 commence toujours par une vue du système dans son ensemble - une seule unité fonctionnelle avec des arcs d'interface s'étendant au-delà de la zone considérée. Un tel diagramme avec un bloc fonctionnel est appelé diagramme de contexte et est désigné par l'identificateur "A-0".

Dans le texte explicatif du diagramme de contexte, le but (Purpose) de la construction du diagramme sous la forme brève description et point de vue fixe (Viewpoint).

La définition et la formalisation de l'objectif de développement IDEF0 - modèles est extrêmement point important. En fait, l'objectif détermine les domaines pertinents du système à l'étude, sur lesquels il convient de se concentrer en premier. Par exemple, si l'on modélise les activités d'une entreprise pour construire l'avenir sur la base de ce modèle Système d'Information, alors ce modèle sera sensiblement différent de celui que nous développerions pour la même entreprise, mais dans le but d'optimiser les chaînes d'approvisionnement.

Le point de vue détermine la direction principale du développement du modèle et le niveau de détail requis. Une fixation claire du point de vue vous permet de décharger le modèle, en refusant de détailler et d'étudier des éléments individuels qui ne sont pas nécessaires, en fonction du point de vue choisi sur le système. Par exemple, des modèles fonctionnels de la même entreprise du point de vue du technologue en chef et directeur financier différeront considérablement dans la direction de leurs détails. Cela est dû au fait qu'au final, le directeur financier ne s'intéresse pas aux aspects de transformation des matières premières sur les machines de production, et le chef technologue ne s'intéresse pas aux schémas dessinés des flux financiers. Bon choix point de vue réduit considérablement le temps consacré à la construction du modèle final.

Dans le processus de décomposition, le bloc fonctionnel, qui dans le diagramme de contexte affiche le système dans son ensemble, est détaillé dans un autre diagramme. Le diagramme résultant du deuxième niveau contient des blocs fonctionnels qui affichent les principales sous-fonctions du bloc fonctionnel du diagramme de contexte et est appelé diagramme enfant (Child diagram) par rapport à celui-ci (chacun des blocs fonctionnels appartenant au diagramme enfant est respectivement appelé un bloc enfant - Child Box). À son tour, le bloc fonctionnel - l'ancêtre est appelé le bloc parent par rapport au diagramme enfant (Parent Box), et le diagramme auquel il appartient est appelé le diagramme parent (Parent Diagram). Chacune des sous-fonctions du diagramme enfant peut être détaillée davantage par une décomposition similaire de son bloc fonctionnel correspondant. Il est important de noter que dans chaque cas de décomposition d'un bloc fonctionnel, tous les arcs d'interface inclus dans ce bloc ou sortant de celui-ci sont fixés sur le schéma enfant. Cela permet d'atteindre l'intégrité structurelle du modèle IDEF0. Le principe de décomposition est clairement illustré à la figure 4. Vous devez faire attention à la relation entre la numérotation des blocs fonctionnels et des diagrammes - chaque bloc a son propre numéro de série unique sur le diagramme (le numéro dans le coin inférieur droit du rectangle) , et la désignation dans le coin droit indique le numéro du diagramme enfant pour ce bloc . L'absence de cette désignation indique qu'il n'y a pas de décomposition pour ce bloc.

Il y a souvent des cas où il n'est pas logique de continuer à considérer les arcs d'interface individuels dans les diagrammes enfants en dessous d'un certain niveau dans la hiérarchie, ou vice versa - les arcs individuels n'ont pas de sens pratique au-dessus d'un certain niveau. Par exemple, un arc d'interface représentant un « détail » à l'entrée du « Process on tour” n'a pas de sens de réfléchir sur les graphiques plus que niveaux élevés- cela ne fera que surcharger les diagrammes et les rendre difficiles à lire. D'autre part, il est nécessaire de se débarrasser des arcs d'interface "conceptuels" séparés et de ne pas les détailler plus profondément qu'un certain niveau. Pour résoudre de tels problèmes, la norme IDEF0 prévoit le concept de tunneling. La désignation du « tunnel » (Flèche Tunnel) sous la forme de deux parenthèses autour du début de l'arc d'interface signifie que cet arc n'a pas été hérité du bloc parent fonctionnel et n'apparaissait (du « tunnel ») que sur ce schéma. A son tour, la même désignation autour de l'extrémité (flèche) de l'arc d'interface à proximité immédiate du bloc récepteur signifie que cet arc ne sera pas affiché et ne sera pas pris en compte dans le schéma enfant de ce bloc. Le plus souvent, il arrive que des objets individuels et leurs arcs d'interface correspondants ne soient pas pris en compte à certains niveaux intermédiaires de la hiérarchie - dans ce cas, ils "plongent d'abord dans le tunnel", puis, si nécessaire, "reviennent du tunnel".

Le dernier des concepts IDEF0 est le glossaire. Pour chacun des éléments d'IDEF0 : schémas, blocs fonctions, arcs d'interface, la norme existante implique la création et la maintenance d'un ensemble de définitions appropriées, mots clés, énoncés narratifs, etc., qui caractérisent l'objet affiché par cet élément. Cet ensemble s'appelle un glossaire et est une description de l'essence de cet élément. Par exemple, pour l'arc d'interface de contrôle « ordre de paiement », le glossaire peut contenir une liste de champs correspondant à l'arc du document, le jeu de visas requis, etc. Le glossaire complète harmonieusement le langage graphique visuel, fournissant aux schémas les informations complémentaires nécessaires.

Figure 4. Décomposition des blocs fonctionnels.

Principes pour limiter la complexité des diagrammes IDEF0

Typiquement, les modèles IDEF0 véhiculent des informations complexes et concentrées, et afin de limiter leur congestion et de les rendre lisibles, les restrictions de complexité correspondantes sont adoptées dans la norme correspondante :

Limitation du nombre de blocs fonctionnels dans le diagramme à trois à six. La limite supérieure (six) oblige le concepteur à utiliser des hiérarchies lors de la description de sujets complexes, et la limite inférieure (trois) garantit que le diagramme correspondant a suffisamment de détails pour justifier sa création ;

Limitation du nombre d'arcs d'interface approchant un bloc fonctionnel (quittant un bloc fonctionnel) à quatre.
Bien sûr, il n'est pas du tout nécessaire de suivre strictement ces restrictions, cependant, comme le montre l'expérience, elles sont très pratiques dans le travail réel.

La discipline du travail de groupe sur le développement d'un modèle IDEF0

La norme IDEF0 contient un ensemble de procédures qui vous permettent de développer et de convenir d'un modèle grand groupe personnes appartenant à différents domaines d'activité du système modélisé. En règle générale, le processus de développement est itératif et se compose des étapes conditionnelles suivantes :

Création d'un modèle par un groupe de spécialistes liés à divers domaines de l'entreprise. Ce groupe est appelé Auteurs en termes IDEF0. La construction du modèle initial est un processus dynamique au cours duquel les auteurs interrogent des personnes compétentes sur la structure des différents processus. Sur la base des dispositions existantes, des documents et des résultats de l'enquête, une ébauche (ébauche de modèle) du modèle est créée.

Distribution du projet pour examen, approbation et commentaires. A ce stade, le projet de modèle est discuté avec un large éventail personnes compétentes (en termes de lecteurs IDEF0) dans l'entreprise. Dans le même temps, chacun des schémas du projet de modèle est critiqué et commenté par écrit, puis transféré à l'auteur. L'auteur, à son tour, est également d'accord avec la critique par écrit ou la rejette avec une déclaration de la logique de la décision et renvoie à nouveau le projet corrigé pour un examen plus approfondi. Ce cycle se poursuit jusqu'à ce que les auteurs et les lecteurs parviennent à un consensus.

Approbation du modèle. Le modèle approuvé est approuvé par le responsable groupe de travail dans le cas où les auteurs du modèle et les lecteurs n'ont pas de désaccord sur son adéquation. Le modèle final est une vue cohérente de l'entreprise (système) d'un point de vue donné et pour un objectif donné.
La visibilité du langage graphique IDEF0 rend le modèle assez lisible pour les personnes qui n'ont pas participé au projet de sa création, ainsi qu'efficace pour les démonstrations et les présentations. À l'avenir, sur la base du modèle construit, de nouveaux projets pourront être organisés visant à apporter des changements dans l'entreprise (dans le système).

Caractéristiques de la pratique nationale d'utilisation de la modélisation fonctionnelle à l'aide des outils IDEF0

Ces dernières années, l'intérêt de la Russie pour les méthodologies de la famille IDEF n'a cessé de croître. Je l'observe constamment lorsque je consulte les statistiques de visites sur ma page Web personnelle (http://www.vernikov.ru), qui décrit brièvement les principes de base de ces normes. Dans le même temps, j'appellerais l'intérêt pour des normes telles que IDEF3-5 théorique, et dans IDEF0, il est pratiquement justifié. En fait, les premiers outils Case permettant de construire des diagrammes DFD et IDEF0 sont apparus sur le marché russe en 1996, en même temps que la sortie d'un livre populaire sur les principes de la modélisation dans les normes SADT.

Cependant, la plupart des managers considèrent encore l'application pratique de la modélisation dans les normes IDEF plus comme un hommage à la mode que comme un moyen efficace d'optimiser le système de gestion d'entreprise existant. Cela est probablement dû à un manque prononcé d'informations sur application pratique de ces méthodologies et avec un biais logiciel indispensable de la grande majorité des publications.

Ce n'est un secret pour personne que presque tous les projets d'enquête et d'analyse de données financières et activité économique entreprises en Russie sont maintenant d'une manière ou d'une autre liées à la construction systèmes automatisés la gestion. De ce fait, les normes IDEF dans la compréhension de la majorité sont devenues conditionnellement indissociables de la mise en œuvre technologies de l'information, bien qu'avec leur aide, il soit parfois possible de résoudre efficacement même de petits problèmes locaux, littéralement avec un crayon et du papier.

Lors de la réalisation de projets d'enquête complexes auprès d'entreprises, le développement de modèles dans la norme IDEF0 vous permet d'afficher visuellement et efficacement l'ensemble du mécanisme des activités de l'entreprise dans la bonne section. Le plus important, cependant, est la capacité de collaboration fournie par IDEF0. Dans mon activités pratiques il y a eu de nombreux cas où le modèle a été construit avec l'aide directe d'employés de divers départements. Dans le même temps, le consultant leur a expliqué en un temps assez court les principes de base d'IDEF0 et leur a appris à travailler avec le logiciel d'application correspondant. En conséquence, les employés de différents services ont créé des diagrammes IDEF des activités de leur unité fonctionnelle, censés répondre aux questions suivantes :

Qu'est-ce qui entre dans l'unité « à l'entrée » ?

Quelles fonctions et dans quel ordre sont exécutées au sein de l'unité ?

Qui est responsable de chaque fonction ?

Qu'est-ce qui guide l'exécutant dans l'exercice de chacune des fonctions ?

Quel est le résultat du travail de l'unité (output) ?

Après avoir coordonné les projets de diagrammes au sein de chaque département spécifique, ils sont assemblés par un consultant dans un projet de modèle d'entreprise, dans lequel tous les éléments d'entrée et de sortie sont liés. À ce stade, toutes les incohérences des diagrammes individuels et leurs emplacements controversés sont corrigés. De plus, ce modèle passe à nouveau par les départements fonctionnels pour une coordination plus poussée et faire les ajustements nécessaires. De ce fait, en un temps assez court et avec l'implication d'un minimum de ressources humaines de la société de conseil (et ces ressources, comme vous le savez, sont très coûteuses), on obtient un modèle IDEF0 d'une entreprise selon le « As est” principe, et, surtout, il représente une entreprise avec des postes d'employés qui y travaillent et en connaissent parfaitement toutes les nuances, y compris celles informelles. À l'avenir, ce modèle sera transféré pour analyse et traitement aux analystes commerciaux qui rechercheront les «goulots d'étranglement» dans la gestion de l'entreprise et optimiseront les principaux processus, transformant le modèle «tel quel» en le modèle «comme il se doit» correspondant. " représentation. Sur la base de ces changements, une conclusion finale est formulée, qui contient des recommandations pour réorganiser le système de gestion.

Bien entendu, une telle approche nécessite un certain nombre de mesures organisationnelles, principalement de la part de la direction de l'entreprise enquêtée. Cela est dû au fait que cette technique implique l'imposition à certains employés de responsabilités supplémentaires pour le développement et l'application pratique de nouvelles méthodologies. Mais au final ça se justifie, puisqu'une ou deux heures de travail supplémentaires employés individuels en quelques jours, ils peuvent économiser considérablement sur le paiement des services de conseil d'une société tierce (qui, dans tous les cas, interrompra le travail des mêmes employés avec des questionnaires et des questions). Quant aux salariés de l'entreprise eux-mêmes, d'une manière ou d'une autre, je n'ai rencontré aucune opposition exprimée de leur part dans ma pratique.

La conclusion de tout cela peut être tirée comme suit : il n'est absolument pas nécessaire de trouver à chaque fois des solutions pour des problèmes standards. Chaque fois que vous êtes confronté à la nécessité d'analyser un système fonctionnel particulier (du système de conception vaisseau spatial, avant le processus de préparation d'un dîner complexe) - utilisez des méthodes éprouvées depuis des années. L'une de ces méthodes est IDEF0, qui permet d'utiliser sa boîte à outils simple et compréhensible pour résoudre des problèmes complexes de la vie.

Une image vaut mille mots

la sagesse populaire

Bien sûr, en théorie, le manager devrait avoir un modèle fonctionnel du travail de l'entreprise, et peu importe qu'il s'agisse de l'organisation de l'entrepôt ou du système informatique (du prospect à la demande). Mais en réalité, cela ne s'avère presque jamais être, et donc, dans le processus d'étude et de recherche d'une solution à la tâche fixée par le client, je crée également un modèle fonctionnel de l'entreprise ou un certain processus (fonction) sur le mien.

Quelques mots sur les avantages des graphiques

Comme vous le savez, les modèles fonctionnels IDEF0 sont toujours des diagrammes graphiques. Ils ont leurs propres caractéristiques et règles de compilation. Nous en reparlerons un peu plus tard. Et maintenant, je voudrais donner quelques exemples de l'efficacité des graphiques. Pourquoi est-ce que je me concentre là-dessus ? Très probablement, après ma déclaration sur la nécessité d'un modèle fonctionnel du travail de l'entreprise, beaucoup de gens ont pensé que ce n'était pas nécessaire, et il était possible d'expliquer avec des mots comment telle ou telle fonction fonctionne dans l'entreprise. C'est de cela que je veux parler.

Et pour commencer, faisons une petite digression dans l'histoire. Remontons au lointain 1877, pendant la guerre russo-turque. C'est alors que l'imprimeur Sytin a utilisé pour la première fois des graphiques pour décrire des opérations militaires. Maintenant, tout cela nous est familier, lors de la description d'une bataille, des cartes avec des flèches apparaissent devant nos yeux, qui montrent clairement le déroulement de la bataille. Et à cette époque, les opérations militaires étaient décrites avec des mots. Pour chaque combat - beaucoup, beaucoup de mots. Et c'était très difficile de comprendre à la fin ce qui se passait.

C'est pourquoi l'idée de Sytin était vraiment révolutionnaire - il a commencé à imprimer des copies lithographiques de cartes avec la désignation des fortifications et des emplacements des unités militaires. Ces cartes s'appelaient « Pour les lecteurs de journaux. Bénéficier à". L'idée s'est avérée si pertinente que le tout premier tirage de "l'aide" s'est vendu instantanément. Et puis de telles applications étaient très demandées. La raison est évidente. Les graphiques ont aidé à comprendre ce qui était presque impossible à comprendre à l'aide de mots seuls.

Je peux également citer un exemple similaire de l'impuissance des descriptions verbales de ma propre pratique. Un de mes clients m'a demandé de prendre en charge la mise en place d'un système ERM pour son entreprise. Quand j'ai demandé s'ils avaient une sorte de tâche technique, j'ai reçu la réponse : « Oui, ils en ont. Mais il a 400 pages. Dans le même temps, le client s'est beaucoup plaint du fait que mes collègues, qu'il avait contactés plus tôt, avaient soit refusé le projet, soit appelé des prix clairement gonflés. Après avoir vu que les termes de référence faisaient effectivement 400 pages et consistaient uniquement en une description textuelle, j'ai compris les raisons du comportement des développeurs. Lire un tel volume de texte, s'y plonger, comprendre toutes les nuances juste pour comprendre la tâche et nommer le prix est vraiment très difficile.

J'ai proposé à ce client une option alternative - décrire graphiquement tout ce qui est possible sous forme de notations. Lui a montré des exemples de modélisation. En conséquence, ils repensent aujourd'hui leurs souhaits et la conception des termes de référence.

Je connais également de nombreux autres exemples où la modélisation graphique des processus métier a aidé à la fois mes collègues, consultants et développeurs métier, et les hommes d'affaires eux-mêmes.

Pourquoi est-ce important pour mon travail

Mon travail est toujours lié à apporter des modifications au système existant. Et pour apporter des modifications et obtenir le résultat souhaité, vous devez étudier ce qui existe déjà. Et peu importe ce que nous faisons exactement - nous configurons ou installons un système CRM à partir de zéro, nous créons un système ERP efficace, nous intégrons divers systèmes pour augmenter l'automatisation du travail en général. Dans tous les cas, pour commencer, il est nécessaire de se faire une idée du schéma de travail existant, et seulement après cela, il est possible de proposer des modifications et de réfléchir à des options pour résoudre la tâche.

Après avoir étudié le statu quo, comme tout autre spécialiste tiers, je crée offrir, dans lequel je révèle le plus en détail possible ma vision de la situation actuelle, ainsi que les actions à entreprendre pour résoudre la tâche, et, bien sûr, le résultat attendu.

Ces rapports d'enquête sur le travail sont volumineux, occupent plus d'une page, ce qui, d'une part, est nécessaire, mais d'autre part, complique la perception. Au début, comme beaucoup d'autres, je pensais que les rapports volumineux étaient bons, car une personne paie le travail et vous devez lui fournir le plus d'informations détaillées possible.

En fait, il est important de ne pas fournir de volume, mais de transmettre l'essentiel le plus rapidement et le plus complètement possible. De gros volumes de texte demandent du temps, dont les hommes d'affaires disposent souvent très peu. Et les graphiques me permettent de réduire le volume de ma proposition et de montrer clairement, sous une forme compréhensible, la solution. En conséquence, mes propositions ont été considérablement réduites, des graphiques y sont apparus et les décisions sur le début de la coopération ont commencé à être prises plus rapidement.

C'est pour cette raison que j'utilise des modèles visuels. Comme vous le savez, une image vaut mille mots. Et dans le cas de la description des processus métier et des options de modernisation du travail d'une entreprise, c'est vrai. Et les notations IDEF0 sont très bien adaptées ici.

Mais d'abord, comprenons les concepts de base de ce que sont les notations, pourquoi elles sont nécessaires, ce qu'est IDEF0, quelles sont les caractéristiques et les avantages de cette méthode

Qu'est-ce que la notation de description de processus métier

Une notation est un format pour décrire un processus métier, qui est un ensemble d'objets graphiques utilisés dans la modélisation, ainsi que des règles de modélisation.

En fait, les notations sont un langage graphique spécial qui vous permet de décrire le travail d'une entreprise, de démontrer visuellement l'interaction entre différents services, c'est-à-dire décrire les processus métier. Les notations peuvent être utilisées pour la modélisation de processus ou fonctionnelle.

En général, les notations peuvent être qualifiées de langage de programmation dans l'analyse commerciale.

Qu'est-ce qu'IDEF0 ?

IDEF0 est une méthodologie de modélisation fonctionnelle et de notation graphique conçue pour formaliser et décrire les processus métier. Particularité IDEF0 met l'accent sur la subordination des objets. IDEF0 considère les relations logiques entre les tâches, et non leur séquence temporelle (workflow). Wikipédia

La norme IDEF0 a été développée en 1981 par le département américain de l'armée de l'air pour l'automatisation industrielle. En phase de développement Logiciel les développeurs sont confrontés à la nécessité de développer de nouvelles méthodes d'analyse des processus métier. En conséquence, la méthodologie de modélisation fonctionnelle IDEF0 est apparue, dans laquelle des notations IDEF0 spéciales sont utilisées pour l'analyse.

Modèle fonctionnel de l'entreprise

Le modèle fonctionnel IDEF0 est un ensemble de blocs, dont chacun est une "boîte noire" avec des entrées et des sorties, des commandes et des mécanismes qui sont détaillés (décomposés) au niveau requis. La fonction la plus importante est située dans le coin supérieur gauche. Et les fonctions sont reliées les unes aux autres à l'aide de flèches et de descriptions de blocs fonctionnels. De plus, chaque type de flèche ou d'activité a sa propre signification. Ce modèle permet de décrire tous les principaux types de processus, tant administratifs qu'organisationnels.

Les flèches peuvent être :

Boîte de réception - introduction, qui définit une tâche spécifique.
Sortant - affiche le résultat de l'activité.
Gestionnaires (de haut en bas) - mécanismes de contrôle (postes, instructions, etc.).
Mécanismes (de bas en haut) - ce qui est utilisé pour produire le travail nécessaire.

Il serait plus précis d'appeler les flèches entrantes et sortantes input et output, puisqu'en anglais elles s'appellent respectivement Input et Output. Mais les caractéristiques de la traduction et les noms usuels ressemblent déjà à ce qu'ils sont. Et pourtant, pour une compréhension correcte des termes, il est important de se souvenir de leur signification dans ce cas. Ceci est également confirmé par le fait que cette notation a été créée principalement pour le développement de logiciels, et il est plus correct de traduire les termes de ce point de vue.

Les flèches sont signées à l'aide de noms (expérience, plan, règles) et les blocs sont signés à l'aide de verbes, c'est-à-dire ils décrivent les actions qui sont réalisées (créer un produit, conclure un contrat, effectuer une expédition).

IDEF0 est un langage très simple et en même temps visuel pour décrire les processus métier. Avec l'aide de cette norme, le transfert d'informations entre développeurs, consultants et utilisateurs est possible. La norme a été développée très soigneusement, elle est pratique pour la conception, universelle. Il existe de nombreux outils pour travailler avec, par exemple, VISIO, BPWIN, ERWIN, Bussines studio, etc.

De plus, utiliser IDEF0 pour créer des modèles commerciaux n'est pas seulement pratique, c'est aussi juste. Cet outil a été conçu pour l'informatique décisionnelle, il a subi un débogage et un polissage longs et approfondis. Par conséquent, utiliser IDEF0 pour créer un modèle fonctionnel sans erreurs est beaucoup plus facile que sans utiliser cette norme.

Comme vous le savez, il est préférable de marteler les clous avec un marteau. Bien sûr, vous pouvez utiliser d'autres outils pour cela, mais un marteau est le plus fonctionnel et il est plus facile de marteler un clou proprement et avec précision. Ainsi, avec l'utilisation d'IDEF0 - cet outil a été créé pour la modélisation fonctionnelle, et avec son aide, vous pouvez obtenir le résultat souhaité beaucoup plus rapidement et avec plus de précision.

Un exemple de création d'un modèle fonctionnel IDEF0

Afin de comprendre comment travailler avec la modélisation fonctionnelle, je vais donner un exemple du processus d'écriture d'un article.

Le bloc principal est "Ecrire un article".

Flèches entrantes - "Expérience", "Informations provenant de sources tierces". Ce sont les entrées dont vous avez besoin pour commencer.

Les guides pour la rédaction d'un article sont le «plan de publication», les «exigences de l'éditeur», les «règles de la langue russe».

Et dans le rôle de "Mécanismes" se trouvent l'auteur, le rédacteur, le correcteur et le logiciel. Dans ce cas, l'auteur crée un matériel audio dans lequel il rassemble toutes les pensées et idées qui devraient être reflétées dans l'article. Un rédacteur est une personne qui crée, sur la base de ce matériel, guidée par les exigences de l'éditeur, le plan de publication et les règles de la langue russe, le texte fini de l'article. Le correcteur vérifie le matériel pour les erreurs. Et les logiciels sont les outils que tous les participants au processus utilisent dans leur travail.

Ainsi, j'ai défini les principaux paramètres du processus, son entrée, sa sortie, ainsi que tout ce qui est nécessaire pour couronné de succès traiter. Mais ce n'est que le cadre de base du processus. Celui-ci décrit le schéma général de l'entreprise dans son ensemble.

En fait, le processus de création d'un article, comme tout processus métier, peut et doit être détaillé. Pour ce faire, je décompose le bloc général "écrire un article" en éléments interconnectés.

Dans notre cas, le travail se décompose en 4 grandes étapes :

Préparez le son.
Préparer le texte
Préparer le texte pour la publication.
Placer un article dans une publication.

Le diagramme montre clairement à quel stade quels éléments de contrôle et quels mécanismes sont impliqués.

Ainsi, lors de la création audio, l'auteur utilise ses connaissances et son expérience, tout en étant guidé par le plan de publication et les exigences de l'éditeur. Le rédacteur reçoit un enregistrement audio en entrée, à partir duquel, guidé par les règles de la langue russe, il crée un texte. Le correcteur reçoit le texte et le vérifie, également guidé par les règles de la langue russe. Pour placer un article dans une publication, un logiciel spécial est requis.

Lors de la création d'un modèle fonctionnel paramètres clés sont le but et le point de vue. Sur cette base, la modélisation des mêmes processus peut sembler quelque peu différente. Par exemple, dans mon cas, le but est « de parler du processus d'écriture d'un article ». Et le point de vue du rédacteur est "l'écriture et la publication d'un article du point de vue du gestionnaire de processus".

Donc, si le même processus était décrit du point de vue d'un rédacteur, alors l'entrée serait une expérience et un fichier audio de l'auteur. De plus, dans ce cas, l'expérience signifierait l'expérience d'un rédacteur, mais pas celle d'un leader ou d'un auteur. Par conséquent, la première chose à déterminer lors de la création d'un modèle de processus métier est de choisir un point de vue et d'articuler clairement l'objectif.

Une telle modélisation est non seulement visuelle, mais aussi très pratique pour prendre des décisions de gestion efficaces. Par exemple, dans le processus métier décrit ci-dessus, il y a deux spécialistes distincts - un rédacteur et un correcteur. Si je fixe la tâche d'optimiser le financement du projet, alors grâce au programme, je verrai immédiatement où il en est et comment cela peut être fait. Ainsi, un rédacteur et un correcteur utilisent approximativement les mêmes règles, mais le rédacteur reçoit l'audio et donne le résultat sous forme de texte, tandis que le correcteur accepte et donne le texte. Et donc, si nécessaire, je peux, disons, pour la moitié du coût des fonctions d'un correcteur, proposer un rédacteur. Je vais donc économiser de l'argent et du temps sur l'interaction de différents spécialistes. Bien sûr, je comprends tous les mérites des relecteurs et pourquoi il est préférable de travailler avec des spécialistes individuels. Mais je vous rappelle que j'ai une tâche : l'optimisation des coûts.

Sans un tel outil visuel, il serait plus difficile de déterminer lequel des blocs peut être enlevé et ainsi optimiser le travail.

Comment créer des notations IDEF0

Il existe de nombreux produits logiciels différents qui peuvent être utilisés pour créer des notations. Certains sont conçus spécifiquement pour la modélisation fonctionnelle, d'autres sont conçus pour tout travail avec des éléments graphiques. Où et comment vous construisez ces modèles dépend de vous.

Je pense personnellement qu'à la première étape il n'y a rien de mieux que du papier ordinaire, un simple crayon et une gomme pour faire des ajustements en cas d'erreurs.

Afin de créer une notation pour les processus métier existants, c'est-à-dire pour décrire le fonctionnement actuel de l'entreprise, il est nécessaire d'étudier les principes de travail. Un tiers spécialiste (consultant, développeur) réalise pour cela un entretien. Dans un premier temps, le chef d'entreprise répond aux questions, puis, dans le cadre du processus de détail de la notation, des entretiens sont menés avec les salariés responsables des différentes étapes du travail.

Il est important de comprendre qu'en conséquence, 2 notations seront nécessaires. Le premier affichera les processus métier tels qu'ils sont. Vous le créez sur la base d'un entretien et coordonnez chaque détail avec les employés de l'entreprise et le responsable. Il est très important que votre vision des processus existants coïncide avec la réalité, et c'est ce qui nécessite une confirmation à tous les niveaux.

La deuxième notation est "comme il se doit". Il est créé sur la base du premier et des modifications que vous proposez d'apporter à la structure de travail pour optimiser et automatiser le travail de l'entreprise dans le cadre de la tâche.

Exigences IDEF0

Les exigences de base de la norme IDEF0, en principe, j'ai décrit ci-dessus et montré avec un exemple.

Dans le coin supérieur gauche se trouve toujours l'élément principal.
Tous les éléments doivent avoir des flèches entrantes et sortantes, car pour l'exécution, il est nécessaire de recevoir quelque chose à l'entrée (commande, tâche), et après traitement à la sortie, il est nécessaire de transférer le produit fini. Les flèches entrantes sont toujours à gauche, les flèches sortantes sont toujours à droite.
Ci-dessus se trouvent les éléments de contrôle, ci-dessous se trouvent les mécanismes nécessaires pour terminer le processus.
S'il y a plusieurs blocs sur une feuille (écran), chaque bloc suivant est situé à droite et en dessous du précédent.
Il faut s'efforcer de créer des schémas de manière à ce que l'intersection des flèches soit réduite au minimum nécessaire.

Erreurs fréquentes

La modélisation fonctionnelle est effectuée à l'aide d'une variété d'outils, y compris ceux qui ne sont pas destinés à la modélisation. Dans ce dernier cas, il n'y a pas de vérification des erreurs et des limites de la norme. Le désir d'augmenter la visibilité et le manque d'expérience se terminent souvent par des erreurs.

Utilisation de différentes couleurs

Tous les éléments du diagramme ont la même importance. Dans la modélisation fonctionnelle, il n'y a pas d'éléments plus ou moins importants. La disparition de tout entraînera une perturbation du processus et un défaut de fabrication.

Souvent, lors de la modélisation sur papier ou dans différents programmes, les utilisateurs essaient d'augmenter la visibilité en utilisant différentes couleurs. C'est l'une des erreurs les plus courantes. En fait, l'utilisation de flèches et de blocs multicolores ne fait qu'introduire une confusion supplémentaire et déforme également la perception du schéma.

Votre modèle doit être lisible en noir et blanc, sans aucun jeu de couleurs supplémentaire. Cette approche permet simultanément d'éviter les malentendus et de discipliner le créateur du modèle, en conséquence, la lisibilité et l'alphabétisation du modèle augmentent.

Trop de blocs

Lors de la compilation d'un modèle, ils essaient souvent d'afficher sur une seule feuille toutes les nuances du travail de l'entreprise avec tous les détails. Le résultat est un très grand nombre de blocs avec un grand nombre de flèches de contrôle. La lisibilité est perdue.

La meilleure option est de détailler suffisamment pour comprendre le problème, et rien de plus. Les détails détaillés du travail de chaque département ou même d'un employé peuvent être révélés lors du choix d'une vue détaillée d'un processus particulier. Et une telle structure n'est créée que si elle est vraiment nécessaire pour le travail ou la prise de décision.

Violation de la structure lors des ajustements

Surveillez attentivement pour éviter toute confusion ou processus sans éléments entrants, sortants et autres éléments importants. Par exemple, si dans l'exemple ci-dessus, je juge bon de déplacer le point de vue vers le rédacteur, je supprimerai l'auteur du schéma. Et puis les contrôles "expérience de l'auteur et sources tierces", ainsi que le plan de publication deviennent inutiles. Après tout, l'auteur les utilise. Le rédacteur travaille avec le fichier audio. Et s'ils restent dans le schéma général, alors en détaillant, ils mèneront de manière incompréhensible où et introduisent de la confusion.

De même, si je décide d'ajouter un bloc, il est important de s'assurer qu'il possède également tous les attributs requis. La prudence est très importante ici, car lors de la modélisation de processus métier complexes, des modifications dans une partie du modèle peuvent entraîner des modifications dans une autre. Ils doivent être saisis.

Règles de nommage des contrôles et des blocs

Il est important de se souvenir d'une règle simple : les flèches de contrôle sont appelées des noms, les blocs sont appelés des verbes. Ceci est accepté dans la norme IDEF0, et cette approche permet d'éviter les confusions et les erreurs.

Le plus souvent, des erreurs sont commises lors de la dénomination des blocs. Par exemple, au lieu de "Créer un article", ils écrivent "Créer un article". Blocs dans cette approche sont des actions, et donc ils doivent toujours être des verbes.

Avantages de l'utilisation d'IDEF0

Le tout premier avantage est évident - c'est la visibilité. Vous commencez vous-même à comprendre comment fonctionne tel ou tel système, et vous pouvez également expliquer clairement où se trouvent les «points faibles» dans ce système et comment vos solutions aideront à les éliminer.
Compréhension mutuelle et absence de désaccord. Lorsque vous discutez du travail de l'entreprise à l'aide du modèle fonctionnel, vous disposez de blocs de tâches visuels et intuitifs avec des contrôles. De plus, la modélisation fonctionnelle implique la création, si nécessaire, d'un glossaire dans lequel les symboles et les termes sont révélés. Par conséquent, vous et votre client, responsable et autres employés parlez le même langage lorsque vous discutez d'un problème.
Simplicité et haute vitesse création de modèle. Bien sûr, apprendre à modéliser n'est pas aussi facile qu'il n'y paraît. Après tout, un schéma est en fait une présentation super dense d'informations, ce qui est très bon pour la compréhension, mais une approche particulière est nécessaire pour mettre en œuvre une telle présentation. Le cerveau de l'analyste agit dans ce cas comme une presse très puissante d'une part, et un filtre d'autre part. Mais avec l'expérience, ce processus devient très rapide. En conséquence, vous obtenez un outil qui vous aidera à comprendre vous-même ce qui se passe dans un système particulier, et avec l'aide du créé dans court instant aides visuelles pour illustrer des points importants à des collègues ou à des clients.
Discipline et pas d'erreurs. La norme IDEF0 suppose des cadres et des règles strictes. Cette approche discipline, et l'habitude d'agir dans le cadre de la norme permet d'éviter les erreurs dues à l'inattention. Toute violation de la norme devient immédiatement perceptible.

Quelle est la difficulté d'utiliser IDEF0

Il est important de comprendre que ce n'est que dans les cas les plus simples que deux analystes commerciaux créeront exactement les mêmes modèles fonctionnels pour décrire le travail de l'entreprise. Tout modèle est le reflet de l'expérience de l'analyste, de la profondeur de sa compréhension du métier qu'il cherche à décrire, et aussi, en quelque sorte, de son point de vue personnel sur ce métier. Ceux. une personne développe un modèle d'entreprise du point de vue du leader, comme s'il était le leader.

En même temps, je crois qu'un analyste commercial n'est pas tout à fait une profession, chaque chef d'entreprise ou développeur de certains systèmes est engagé dans l'analyse commerciale, qui analyse l'entreprise et s'efforce de construire le plus système efficace. C'est à ces personnes et à ces fins que l'outil IDEF0 est destiné.

Par conséquent, il est très important de consulter en permanence le chef d'entreprise lors de l'élaboration d'un modèle d'entreprise fonctionnel «tel quel», afin de ne pas commettre d'erreurs qui entraîneront automatiquement des erreurs aux étapes de décomposition. De plus, à des étapes ultérieures, des approbations supplémentaires de la part des gestionnaires peuvent être requises. divisions structurelles et employés. Ce n'est que si votre modèle fonctionnel "tel quel" reflète vraiment l'état réel des choses que vous pouvez apporter des modifications et des suggestions. Et pour atteindre des résultats de qualité un tel travail nécessite avant tout une expérience pratique et une connaissance des caractéristiques d'un type particulier d'entreprise.

Gennady Vernikov

À l'heure actuelle, l'intérêt pour les normes de gestion généralement acceptées en Occident a fortement augmenté en Russie, cependant, dans la pratique réelle de la gestion, il y a un moment très important. De nombreux managers peuvent encore être déconcertés par une question directe sur la structure organisationnelle de l'entreprise ou sur le schéma des processus métier existants. En règle générale, les gestionnaires de périodiques économiques les plus avancés et les lecteurs réguliers commencent à dessiner des schémas hiérarchiques compréhensibles pour eux seuls, mais dans ce processus, ils s'arrêtent généralement rapidement. Il en va de même pour les employés et les chefs de divers services et unités fonctionnelles. Dans la plupart des cas, le seul ensemble de règles énoncées en vertu desquelles une entreprise doit fonctionner est un ensemble de réglementations et de descriptions de poste distinctes. Le plus souvent, ces documents ont été compilés il y a plus d'un an, ils sont mal structurés et sans rapport les uns avec les autres et, par conséquent, ils prennent simplement la poussière sur les étagères. Pour le moment, une telle approche était justifiée, car lors de la formation de l'économie de marché russe, le concept de concurrence était pratiquement absent et il n'était pas particulièrement nécessaire de compter les coûts - le bénéfice était gigantesque. En conséquence, au cours des deux dernières années, nous avons vu une image tout à fait compréhensible : les grandes entreprises qui ont grandi au début des années 90 perdent progressivement du terrain, jusqu'à un retrait complet du marché. Cela est dû en partie au fait que les normes de gestion n'ont pas été introduites dans l'entreprise, le concept d'un modèle fonctionnel d'activité et de mission était complètement absent. En modélisant différents domaines d'activité, il est possible d'analyser efficacement les "goulots d'étranglement" dans la gestion et d'optimiser le schéma commercial global. Mais, comme vous le savez, dans toute entreprise, seuls les projets qui génèrent directement des bénéfices ont la plus haute priorité, il s'agit donc généralement d'examiner les activités et de les réorganiser uniquement lors d'une crise tangible dans la gestion de l'entreprise.

Le concept même de "modélisation des processus métier" est entré dans la vie de la plupart des analystes en même temps que l'apparition sur le marché de produits logiciels complexes conçus pour une automatisation complexe de la gestion d'entreprise. De tels systèmes impliquent toujours une étude approfondie des activités de l'entreprise avant le projet. Le résultat de cette enquête est un avis d'expert, dans lequel des recommandations sont formulées dans des paragraphes séparés pour éliminer les "goulots d'étranglement" dans la gestion des activités. Sur la base de cette conclusion, immédiatement avant la mise en œuvre du système d'automatisation, la soi-disant réorganisation des processus métier est effectuée, parfois assez grave et douloureuse pour l'entreprise. C'est, bien sûr, une équipe qui s'est développée au fil des années est toujours difficile à faire "penser d'une manière nouvelle". Ces enquêtes exhaustives sur les entreprises sont toujours complexes et diffèrent considérablement d'un cas à l'autre. Il existe des méthodologies et des normes bien établies pour résoudre ces problèmes de modélisation de systèmes complexes. Ces normes incluent la famille de méthodologies IDEF. Avec leur aide, vous pouvez afficher et analyser efficacement les modèles d'activité d'un large éventail de systèmes complexes dans différentes sections. Dans le même temps, l'étendue et la profondeur de l'examen des processus du système sont déterminées par le développeur lui-même, ce qui permet de ne pas surcharger le modèle créé avec des données inutiles. Actuellement, les normes suivantes peuvent être attribuées à la famille IDEF :

IDEF1 - une méthodologie de modélisation des flux d'informations au sein d'un système qui vous permet d'afficher et d'analyser leur structure et leurs relations ;

IDEF1X (IDEF1 Extended) - une méthodologie pour la construction de structures relationnelles. IDEF1X appartient au type de méthodologie Entity-Relationship (ER) et est généralement utilisé pour modéliser des bases de données relationnelles pertinentes pour le système en question ;

IDEF2 est une méthodologie de modélisation dynamique de l'évolution des systèmes. En raison des difficultés très sérieuses de l'analyse des systèmes dynamiques, cette norme a été pratiquement abandonnée et son développement a été suspendu au tout début. Cependant, il existe actuellement des algorithmes et leurs implémentations informatiques qui permettent de transformer un ensemble de diagrammes IDEF0 statiques en modèles dynamiques construits sur la base de "réseaux de Petri colorés" (CPN - Color Petri Nets) ;

L'histoire de la norme IDEF0

La méthodologie IDEF0 peut être considérée comme la prochaine étape dans le développement du langage graphique bien connu pour décrire les systèmes fonctionnels SADT (Structured Analysis and Design Teqnique). Il y a quelques années, une petite édition d'un livre du même nom a été publiée en Russie, consacrée à la description des principes de base de la construction de diagrammes SADT. Historiquement, IDEF0 en tant que standard a été développé en 1981 dans le cadre d'un vaste programme d'automatisation industrielle, qui portait la désignation ICAM (Integrated Computer Aided Manufacturing) et a été proposé par le département de l'US Air Force. La famille de normes IDEF elle-même a hérité sa désignation du nom de ce programme (IDEF=ICAM DEFinition). Au cours du processus de mise en œuvre pratique, les participants au programme ICAM ont été confrontés à la nécessité de développer de nouvelles méthodes d'analyse des processus d'interaction dans les systèmes industriels. Dans le même temps, outre un ensemble amélioré de fonctions de description des processus métier, l'une des exigences de la nouvelle norme était la disponibilité d'une méthodologie efficace d'interaction au sein de «l'analyste-spécialiste». En d'autres termes, la nouvelle méthode était censée fournir un travail de groupe sur la création du modèle, avec la participation directe de tous les analystes et spécialistes impliqués dans le projet.

Éléments et concepts de base d'IDEF0

Le langage graphique IDEF0 est remarquablement simple et harmonieux. La méthodologie repose sur quatre concepts principaux.

Le premier d'entre eux est le concept d'une boîte d'activité. Le bloc fonctionnel est représenté graphiquement par un rectangle (voir Fig. 1) et représente une fonction spécifique au sein du système considéré. Selon les exigences de la norme, le nom de chaque bloc fonctionnel doit être formulé dans le mode verbal (par exemple, "produire des services" et non "produire des services").

Chacun des quatre côtés du bloc fonctionnel a sa propre signification spécifique (rôle), tandis que :

Le côté supérieur est "Contrôle" ;

Le côté gauche est "Entrée" ;

Le côté droit est réglé sur "Sortie" ;

La face inférieure a la valeur "Mécanisme" (Mécanisme).

Chaque unité fonctionnelle au sein du système unique considéré doit avoir son propre numéro d'identification unique.

Figure 1. Bloc fonctionnel.

La deuxième "baleine" de la méthodologie IDEF0 est le concept d'arc d'interface (Flèche). De plus, les arcs d'interface sont souvent appelés flux ou flèches. Un arc d'interface représente un élément système qui est traité par un bloc fonction ou affecte autrement la fonction affichée par ce bloc fonction.

Selon le côté auquel l'arc d'interface donné s'approche, il est appelé "entrant", "sortant" ou "contrôle". De plus, la "source" (début) et le "récepteur" (fin) de chaque arc fonctionnel ne peuvent être que des blocs fonctionnels, tandis que la "source" ne peut être que le côté sortie du bloc, et le "récepteur" peut être n'importe quel des trois restants.

Il est à noter que tout bloc fonctionnel, selon les exigences de la norme, doit avoir au moins un arc d'interface de commande et un arc sortant. C'est compréhensible - chaque processus doit suivre certaines règles (affichées par l'arc de contrôle) et doit produire un résultat (arc sortant), sinon sa prise en compte n'a aucun sens.

Lors de la construction de diagrammes IDEF0, il est important de séparer correctement les arcs d'interface entrants de ceux de contrôle, ce qui n'est souvent pas facile. Par exemple, la figure 2 montre le bloc de fonction "Usiner la pièce".

Figure 2.

figure 3

Le troisième concept de base de la norme IDEF0 est la décomposition. Le principe de décomposition s'applique lorsqu'un processus complexe est décomposé en ses fonctions constitutives. Dans ce cas, le niveau de détail du processus est déterminé directement par le développeur du modèle.

La décomposition vous permet de représenter progressivement et de manière structurée le modèle du système sous la forme d'une structure hiérarchique de diagrammes individuels, ce qui le rend moins surchargé et facilement digestible.

Le modèle IDEF0 commence toujours par une vue du système dans son ensemble - un seul bloc fonctionnel avec des arcs d'interface s'étendant au-delà de la zone considérée. Un tel diagramme avec un bloc fonctionnel est appelé diagramme de contexte et est désigné par l'identificateur "A-0".

Dans le texte explicatif du diagramme de contexte, le but (Purpose) de la construction du diagramme sous la forme d'une brève description doit être indiqué et le point de vue (Viewpoint) doit être fixé.

La définition et la formalisation de la finalité du développement d'un modèle IDEF0 est un point extrêmement important. En fait, l'objectif détermine les domaines pertinents du système à l'étude, sur lesquels il convient de se concentrer en premier. Par exemple, si nous modélisons les activités d'une entreprise afin de construire un système d'information basé sur ce modèle dans le futur, alors ce modèle sera sensiblement différent de celui que nous développerions pour la même entreprise, mais dans le but d'optimiser des chaînes d'approvisionnement.

Le point de vue détermine la direction principale du développement du modèle et le niveau de détail requis. Une fixation claire du point de vue vous permet de décharger le modèle, en refusant de détailler et d'étudier des éléments individuels qui ne sont pas nécessaires, en fonction du point de vue choisi sur le système. Par exemple, les modèles fonctionnels de la même entreprise du point de vue du technologue en chef et du directeur financier différeront considérablement dans le sens de leurs détails. Cela est dû au fait qu'au final, le directeur financier ne s'intéresse pas aux aspects de transformation des matières premières sur les machines de production, et le chef technologue ne s'intéresse pas aux schémas dessinés des flux financiers. Le choix correct du point de vue réduit considérablement le temps consacré à la construction du modèle final.

Dans le processus de décomposition, le bloc fonctionnel, qui dans le diagramme de contexte affiche le système dans son ensemble, est détaillé dans un autre diagramme. Le diagramme résultant du deuxième niveau contient des blocs fonctionnels qui affichent les principales sous-fonctions du bloc fonctionnel du diagramme de contexte et est appelé diagramme enfant (Child diagram) par rapport à celui-ci (chacun des blocs fonctionnels appartenant au diagramme enfant est respectivement appelé un bloc enfant - Child Box). À son tour, le bloc fonctionnel - l'ancêtre est appelé le bloc parent par rapport au diagramme enfant (Parent Box), et le diagramme auquel il appartient - le diagramme parent (Parent Diagram). Chacune des sous-fonctions du diagramme enfant peut être détaillée davantage par une décomposition similaire de son bloc fonctionnel correspondant. Il est important de noter que dans chaque cas de décomposition d'un bloc fonctionnel, tous les arcs d'interface inclus dans ce bloc ou sortant de celui-ci sont fixés sur le schéma enfant. Cela permet d'atteindre l'intégrité structurelle du modèle IDEF0. Le principe de décomposition est clairement illustré à la figure 4. Vous devez faire attention à la relation entre la numérotation des blocs fonctionnels et des diagrammes - chaque bloc a son propre numéro de série unique sur le diagramme (le numéro dans le coin inférieur droit du rectangle) , et la désignation dans le coin droit indique le numéro du diagramme enfant pour ce bloc . L'absence de cette désignation indique qu'il n'y a pas de décomposition pour ce bloc.

Il y a souvent des cas où il n'est pas logique de continuer à considérer les arcs d'interface individuels dans les diagrammes enfants en dessous d'un certain niveau dans la hiérarchie, ou vice versa - les arcs individuels n'ont pas de sens pratique au-dessus d'un certain niveau. Par exemple, un arc d'interface représentant un "détail" à l'entrée du bloc fonction "Usinage sur un tour" n'a pas de sens pour réfléchir sur des schémas de niveaux supérieurs - cela ne fera que surcharger les schémas et les rendre difficiles à lire. D'autre part, il est nécessaire de se débarrasser des arcs d'interface "conceptuels" séparés et de ne pas les détailler plus profondément qu'un certain niveau. Pour résoudre de tels problèmes, la norme IDEF0 prévoit le concept de tunneling. La désignation "tunnel" (Flèche Tunnel) sous la forme de deux parenthèses autour du début de l'arc d'interface signifie que cet arc n'a pas été hérité du bloc parent fonctionnel et n'apparaissait (du "tunnel") que sur ce schéma. A son tour, la même désignation autour de l'extrémité (flèche) de l'arc d'interface à proximité immédiate du bloc récepteur signifie que cet arc ne sera pas affiché et ne sera pas pris en compte dans le schéma enfant de ce bloc. Le plus souvent, il arrive que des objets individuels et leurs arcs d'interface correspondants ne soient pas pris en compte à certains niveaux intermédiaires de la hiérarchie - dans ce cas, ils "plongent d'abord dans le tunnel", puis, si nécessaire, "reviennent du tunnel".

Le dernier des concepts IDEF0 est le glossaire. Pour chacun des éléments IDEF0 : schémas, blocs fonctions, arcs d'interface, la norme existante implique la création et la maintenance d'un ensemble de définitions, mots-clés, énoncés narratifs, etc. correspondants, qui caractérisent l'objet affiché par cet élément. Cet ensemble s'appelle un glossaire et est une description de l'essence de cet élément. Par exemple, pour l'arc d'interface de contrôle "instruction de paiement", le glossaire peut contenir une liste de champs correspondant à l'arc du document, le jeu de visas requis, etc. Le glossaire complète harmonieusement le langage graphique visuel, fournissant aux schémas les informations complémentaires nécessaires.

Figure 4. Décomposition des blocs fonctionnels.

Principes pour limiter la complexité des diagrammes IDEF0

La discipline du travail de groupe sur le développement d'un modèle IDEF0

La norme IDEF0 contient un ensemble de procédures qui permettent le développement et l'approbation d'un modèle par un grand groupe de personnes appartenant à différents domaines d'activité du système modélisé. En règle générale, le processus de développement est itératif et se compose des étapes conditionnelles suivantes :

Distribution du projet pour examen, approbation et commentaires. A ce stade, le projet de modèle est discuté avec un large éventail de personnes compétentes (en termes de lecteurs IDEF0) dans l'entreprise. Dans le même temps, chacun des schémas du projet de modèle est critiqué et commenté par écrit, puis transféré à l'auteur. L'auteur, à son tour, est également d'accord avec la critique par écrit ou la rejette avec une déclaration de la logique de la décision et renvoie à nouveau le projet corrigé pour un examen plus approfondi. Ce cycle se poursuit jusqu'à ce que les auteurs et les lecteurs parviennent à un consensus.

Approbation du modèle. Le modèle approuvé est approuvé par le chef du groupe de travail dans le cas où les auteurs du modèle et les lecteurs n'ont pas de désaccord sur son adéquation. Le modèle final est une vue cohérente de l'entreprise (système) d'un point de vue donné et pour un objectif donné.
La visibilité du langage graphique IDEF0 rend le modèle assez lisible pour les personnes qui n'ont pas participé au projet de sa création, ainsi qu'efficace pour les démonstrations et les présentations. À l'avenir, sur la base du modèle construit, de nouveaux projets pourront être organisés visant à apporter des changements dans l'entreprise (dans le système).

Caractéristiques de la pratique nationale d'utilisation de la modélisation fonctionnelle à l'aide des outils IDEF0

Cependant, la plupart des managers considèrent encore l'application pratique de la modélisation dans les normes IDEF plus comme un hommage à la mode que comme un moyen efficace d'optimiser le système de gestion d'entreprise existant. Cela est probablement dû à un manque prononcé d'informations sur l'application pratique de ces méthodologies et à l'indispensable biais logiciel de la grande majorité des publications.

Ce n'est un secret pour personne que presque tous les projets d'enquête et d'analyse des activités financières et économiques des entreprises en Russie sont désormais liés d'une manière ou d'une autre à la construction de systèmes de contrôle automatisés. Grâce à cela, les normes IDEF dans la compréhension de la majorité sont devenues conditionnellement indissociables de l'introduction des technologies de l'information, bien qu'avec leur aide, il soit parfois possible de résoudre efficacement même de petits problèmes locaux, littéralement avec un crayon et du papier.

Lors de la réalisation de projets d'enquête complexes auprès d'entreprises, le développement de modèles dans la norme IDEF0 vous permet d'afficher visuellement et efficacement l'ensemble du mécanisme des activités de l'entreprise dans la bonne section. Le plus important, cependant, est la capacité de collaboration fournie par IDEF0. Dans ma pratique, il y a eu de nombreux cas où la construction du modèle a été réalisée avec l'aide directe d'employés de différents départements. Dans le même temps, le consultant leur a expliqué en un temps assez court les principes de base d'IDEF0 et leur a appris à travailler avec le logiciel d'application correspondant. En conséquence, les employés de différents services ont créé des diagrammes IDEF des activités de leur unité fonctionnelle, censés répondre aux questions suivantes :

Qu'est-ce qui entre dans l'unité « à l'entrée » ?

Quelles fonctions et dans quel ordre sont exécutées au sein de l'unité ?

Qui est responsable de chaque fonction ?

Qu'est-ce qui guide l'exécutant dans l'exercice de chacune des fonctions ?

Quel est le résultat du travail de l'unité (output) ?

Après avoir coordonné les projets de diagrammes au sein de chaque département spécifique, ils sont assemblés par un consultant dans un projet de modèle d'entreprise, dans lequel tous les éléments d'entrée et de sortie sont liés. À ce stade, toutes les incohérences des diagrammes individuels et leurs emplacements controversés sont corrigés. De plus, ce modèle passe à nouveau par les départements fonctionnels pour une coordination plus poussée et faire les ajustements nécessaires. En conséquence, dans un délai assez court et avec l'implication d'un minimum de ressources humaines de la société de conseil (et ces ressources, comme vous le savez, sont très coûteuses), un modèle IDEF0 d'une entreprise est obtenu selon le " Tel quel" principe, et, surtout, il représente une entreprise avec des postes d'employés qui y travaillent et en connaissent parfaitement toutes les nuances, y compris celles informelles. À l'avenir, ce modèle sera transféré pour analyse et traitement aux analystes commerciaux qui rechercheront les "goulots d'étranglement" dans la gestion de l'entreprise et optimiseront les principaux processus, transformant le modèle "Ainsi" en le "Comme il se doit" correspondant. " représentation. Sur la base de ces changements, une conclusion finale est formulée, qui contient des recommandations pour réorganiser le système de gestion.

Bien entendu, une telle approche nécessite un certain nombre de mesures organisationnelles, principalement de la part de la direction de l'entreprise enquêtée. Cela est dû au fait que cette technique implique l'imposition à certains employés de responsabilités supplémentaires pour le développement et l'application pratique de nouvelles méthodologies. Cependant, au final, cela se justifie, car une ou deux heures de travail supplémentaires par chaque employé sur plusieurs jours peuvent permettre d'économiser considérablement sur le paiement des services de conseil d'une société tierce (ce qui interrompra de toute façon le travail de les mêmes employés avec des questionnaires et des questions). Quant aux salariés de l'entreprise eux-mêmes, d'une manière ou d'une autre, je n'ai rencontré aucune opposition exprimée de leur part dans ma pratique.

La conclusion de tout cela peut être tirée comme suit : il n'est absolument pas nécessaire de trouver à chaque fois des solutions pour des problèmes standards. Chaque fois que vous êtes confronté à la nécessité d'analyser un système fonctionnel particulier (du système de conception de l'engin spatial au processus de préparation d'un dîner complexe), utilisez des méthodes éprouvées et rodées au fil des ans. L'une de ces méthodes est IDEF0, qui permet d'utiliser sa boîte à outils simple et compréhensible pour résoudre des problèmes complexes de la vie.

Derniers articles

2022-06-08 17:49:00
Tarifs et équipements pour Skylink Internet Equipement pour se connecter à Internet depuis SkyLink
2022-05-28 07:46:52
Résoudre certains problèmes de la version Android de Mortal Kombat X Mobile
2022-05-28 07:46:52
Comment apprivoiser un perroquet ?

Articles populaires

Le choix des éditeurs

2022-05-16 11:43:03

Que faut-il pour ouvrir une entreprise individuelle ?
Salutations, chers lecteurs! Aujourd'hui, nous allons parler de la façon d'ouvrir une adresse IP par vous-même en 2020 rapidement et facilement. Dans cet article, je vais vous expliquer étape par étape...
2022-05-16 11:43:03

Évaluation de la productivité du travail des gestionnaires et des spécialistes en gestion du personnel Règles de base de la rémunération
L'activité de travail est un effort visant à atteindre un certain résultat. C'est la principale caractéristique de l'œuvre. Il * verb * toujours...
2022-05-16 11:43:03

Exigences de qualité
On peut dire que les exigences de base pour la qualité des produits ou services fournis sont une combinaison de ses caractéristiques et propriétés, qui en ...
2022-05-16 11:43:03

Ressources en tourbe Extraction de tourbe de broyage
Tolkacheva Elizaveta Sergeevna 9 "G" classe MOU "École secondaire n ° 58" Pertinence du sujet De nombreux pays étrangers ont une économie développée, grâce à un puissant ...
2022-05-07 03:07:16

Société par Actions Fermée Transtelecom
TTK est l'un des cinq principaux opérateurs de télécommunications russes. Le principal actionnaire de TTK est Russian Railways, qui détient 99,99 % des actions de la Société. Compagnie...