Modellierung idef0. IDEF0

heim / Verdienste

IDEF0 ist eine Methodik zur grafischen Beschreibung der Systeme und Prozesse einer Organisation als eine Reihe miteinander verbundener Funktionen. Es ermöglicht Ihnen, die Funktionen einer Organisation zu erkunden, ohne sie mit den Objekten zu verknüpfen, die ihre Umsetzung gewährleisten.

Im IDEF0-Standard werden Objekte durch Eingabe dargestellt – Informations- und Materialflüsse, die in einem Geschäftsprozess transformiert werden. Mit Hilfe des Managements werden Objekte dargestellt – Material- und Informationsflüsse, die im Prozess nicht transformiert werden, aber für seine Umsetzung benötigt werden. Mithilfe von IDEF0-Mechanismen können Sie die Werkzeuge und Ressourcen anzeigen, mit denen ein Geschäftsprozess implementiert wird (z. B. technische Mittel, Personen, Informationssysteme usw.). Die Ausgabe eines im IDEF0-Standard beschriebenen Geschäftsprozesses entspricht in ihrer Bedeutung vollständig der Ausgabe eines Prozesses, der mithilfe eines DFD-Diagramms beschrieben wird.

Grundelemente eines IDEF0-Diagramms.

Die IDEF0-Methodik unterscheidet sich geringfügig vom klassischen DFD-Geschäftsprozessbeschreibungsschema. Der Hauptunterschied besteht im Vorhandensein zusätzlicher Analysen in der Sprache. Dieser Standard zur Beschreibung von Geschäftsprozessen schlägt vor, nicht nur Eingaben und Ausgaben anzuzeigen, wie dies im DFD-Format der Fall ist, sondern drei Arten von Eingaben einzuführen. Die erste Art von Eingaben wurde auch als Eingabe bezeichnet, und die anderen beiden Eingaben wurden als Steuerungen und Mechanismen bezeichnet.

Die Hauptelemente eines Diagramms in IDEF0-Notation sind:

Blöcke, in der Prozesse, Funktionen, Vorgänge, Aktionen dargestellt werden (je nach Detaillierungsgrad);
Pfeile, in der das Diagramm Informationen und materielle Ressourcen widerspiegelt, die mit Funktionen verbunden sind.

Im IDEFO-Standard bezieht sich ein Block auf Funktionen. Da sich das Konzept des Prozessansatzes im Organisationsmanagement immer weiter verbreitet hat, werden Prozesse, Teilprozesse und Abläufe in der Regel in Form von Blöcken abgebildet. Darüber hinaus wird der Begriff bei der Betrachtung der IDEF-Methodik verwendet Funktion, womit auch Prozesse, Teilprozesse, Operationen und Aktionen gemeint sein können.

Der Standardblock ist in Abb. dargestellt. 5.2. Es handelt sich um ein Rechteck, in dessen Mitte sich der Name des Blocks (Funktion) und unten rechts seine Nummer befindet. Der Titel muss als aktives Verb dargestellt werden. Zum Beispiel „Anfrage bearbeiten“, „Vereinbarung erstellen“, „Zustimmen“. In der Praxis russischer Analysten werden auch verbale Formen verwendet, beispielsweise „Bearbeitung einer Anfrage“, „Ausarbeitung einer Vereinbarung“. Allerdings verstößt diese Art der Blockbenennung etwas gegen die Anforderungen des IDEF0-Standards. Blocknummern werden bei der Funktionszerlegung und Textbeschreibung des Modells verwendet. Es ist zu beachten, dass der Block bei der Zerlegung sowohl seinen Namen als auch seine Nummer behält.

Reis. 5.2.

Die Pfeile im IDEF0-Standard zeigen nicht die Bewegung von Daten oder die Abfolge von Ereignissen wie in DFD- oder WFD-Diagrammen. Hier sollen sie angeben, welche Daten und Objekte zur Implementierung einer bestimmten Funktion erforderlich sind und was als Ergebnis ihrer Implementierung erhalten wird. Pfeile können gerade oder gebrochen sein. Im letzteren Fall sollte der Biegewinkel 90° betragen. Auf dem Diagramm sollten sie vertikal oder horizontal angeordnet sein, Diagonalen sind jedoch nicht zulässig. Die Enden der Pfeile sollten den äußeren Rand des Blocks berühren, aber nicht darüber hinausgehen. Es ist auch nicht akzeptabel, einen Pfeil an der Ecke eines Blocks anzubringen, da Sie je nachdem, von welcher Seite sich der Pfeil dem Block nähert, den Zweck des Objekts bestimmen können, das er darstellt. Im Rahmen dieser Norm gibt es vier Arten von Pfeilen: eingehende (Input), ausgehende (Output), Steuerpfeile (Control), Mechanismuspfeile (Mechanism).

Gemäß der im Standard verwendeten Kodifizierung (ICOM) werden die Pfeile im Diagramm durch die Anfangsbuchstaben des lateinischen Namens bezeichnet, d. h.: Eingang – I, Steuerung – C, Ausgang – O, Mechanismus – M.

Der eingehende Pfeil zeigt die Bewegung des Objekts in Richtung des Blocks auf der linken Seite. Dieses Objekt wird bei der Ausführung der Funktion (angegeben als Block) in ein Ausgabeobjekt umgewandelt. Das Objekt, das sich aus der Implementierung der Funktion ergibt, ist also die Ausgabe, der Ausgangspfeil, der rechts vom Block reflektiert wird. Die Ausgabe eines im IDEF0-Standard beschriebenen Geschäftsprozesses entspricht in ihrer Bedeutung vollständig der Ausgabe eines Prozesses, der mithilfe eines DFD-Diagramms beschrieben wird.

Hierbei ist zu berücksichtigen, dass, wenn Informationen am Eingang ankommen, auch Informationen am Ausgang der Funktion vorhanden sind. Wenn es sich bei der Eingabe um Materialien handelt, handelt es sich bei der Ausgabe um ein materielles Objekt. Wenn eine Person am Eingang ist, ist auch eine Person am Ausgang.

Wichtig zu merken

Bei der Beschreibung von Geschäftsprozessen mit der IDEF0-Methodik machen unerfahrene Analysten häufig den Fehler, die Regel nicht zu befolgen: „Die Entitäten der eingehenden und ausgehenden Objekte sind gleich.“

Betrachten Sie beispielsweise die Funktion „Pripyat-Mitarbeiter zur Arbeit“. Die IDEF0-Modellierungsregel besagt, dass ein Funktionsblock eine Funktion beschreiben soll, die ein eingehendes Objekt in ein ausgehendes Objekt umwandelt. Wir können also sagen, dass bei der Registrierung eines neuen Mitarbeiters ein potenzieller Mitarbeiter in einen Mitarbeiter umgewandelt wird, der eine bestimmte Position in einer bestimmten Organisation innehat. Betrachtet man den Prozess aus der Sicht eines Mitarbeiters der Personalabteilung, der die notwendigen Vorgänge mit Dokumenten durchführen muss, kann die Registrierung eines neuen Mitarbeiters ab dem Zeitpunkt beginnen, an dem er seinen Lebenslauf vorlegt und seinen Wunsch mitteilt, in diesem zu arbeiten Organisation und endet mit der beidseitigen Unterzeichnung des Arbeitsauftrags. In diesem Fall handelt es sich um die Dokumentation des Mitarbeiters. Daher ist es völlig falsch, am Eingang eine Person und am Ausgang ein Dokument anzugeben und umgekehrt (Abb. 5.3).

Reis. 5.3. IDEF0-Diagramm des Prozesses „Einstellung eines Mitarbeiters“

Der Steuerpfeil, der oben in den Block eintritt, zeigt die Bedingungen und Steuerelemente an, die zum Ausführen der Funktion erforderlich sind, z. B.

Maßnahmen: Anleitung zum Aufbau von Möbeln, Bedienungsanleitung für das Informationssystem, Regelungen zur Bearbeitung von Bürgerbeschwerden.

Der unter dem Block angezeigte Mechanismuspfeil stellt dar, was zur Implementierung dieser Funktion verwendet wird. Es gibt zwei Arten von Mechanismuszeigern:

1) ein nach oben zeigender Mechanismuspfeil, der Mechanismen, Werkzeuge und Ressourcen anzeigt, die die Ausführung einer Funktion unterstützen, zum Beispiel: ein Beamter, ein Informationssystem, eine Maschine, Ausrüstung;
2) ein nach unten zeigender Mechanismuspfeil, der dazu dient, im Diagramm den Zugriff auf einen Block anzuzeigen, der in einem anderen Modell enthalten ist (selten verwendet).

Pfeile werden Substantive oder Phrasen genannt, die beispielsweise aus einem Substantiv und einem Adjektiv bestehen, siehe Abb. 5.3, für die Funktion „Mitarbeiter einstellen“ heißt der eingehende Pfeil „Potenzieller Mitarbeiter“, der ausgehende Pfeil heißt „Mitarbeiter“.

Die IDEF0-Methodik umfasst die Entwicklung mehrerer Diagramme, die eine Funktion oder einen Prozess beschreiben: ein Kontextdiagramm; Diagramm der obersten Ebene; Eine Reihe untergeordneter Diagramme, die eine detailliertere Ansicht des Modellierungsobjekts widerspiegeln.

Kontextdiagramm stellt einen Block mit Pfeilen dar, die die Verbindungen des beschriebenen Prozesses mit der äußeren Umgebung widerspiegeln. Wir können also sagen, dass das Kontextdiagramm den Modellierungsbereich und seine Grenzen zeigt. Der Name des Blocks entspricht dem Namen der beschriebenen Funktion (Prozess). Die Kontextdiagrammnummer ist immer Null. Es wird üblicherweise mit „AO“ bezeichnet. Wenn es darum geht, die Aktivitäten einer Organisation oder Abteilung zu beschreiben, wird beim Erstellen eines Kontextdiagramms der Name des Projekts oder eine kurze Beschreibung der beschriebenen Aktivität als Titel angegeben. Zum Beispiel „Debitkarte ausstellen“ oder „Personal verwalten“. Der gleiche Ansatz wird bei der Benennung der Pfeile verwendet, die in einen einzelnen Block des Kontextdiagramms ein- und austreten. In Abb. Abbildung 5.4 zeigt ein Beispiel eines Kontextdiagramms für den Prozess „Kundenbeschwerdemanagement“. Darüber hinaus sollte das Kontextdiagramm den Zweck der Modellerstellung beschreiben und Informationen über den Standpunkt enthalten, aus dem das IDEF0-Modell erstellt wird.

Das Diagramm der obersten Ebene ist das erste untergeordnete Diagramm des Kontextdiagramms. In Abb. Abbildung 5.5 zeigt ein Diagramm der obersten Ebene des Prozesses „Kundenbeschwerdemanagement“. Es ist ein untergeordnetes Diagramm des in Abb. gezeigten Kontextdiagramms. 5.4. Die in einem Kontextdiagramm (AC) dargestellte Funktion wird in Unterfunktionen zerlegt, indem ein bestimmtes untergeordnetes Diagramm der obersten Ebene erstellt wird. Jede der dargestellten Unterfunktionen wird dann in untergeordnete Diagramme erweitert. Der Zerlegungsgrad wird in diesem Fall durch den Zweck der Modellierung bestimmt, d. h. Aufteilen einer Funktion in Unterfunktionen, Operationen usw. erfolgt so lange, bis die Ziele und Zielsetzungen der Modellierung erreicht sind.

Reis. 5.4. Kontextdiagramm des Kundenbeschwerdemanagementprozesses

Innerhalb dieser Modellierungsmethodik wird zwischen übergeordneten und untergeordneten Diagrammen unterschieden. Ihre hierarchischen Beziehungen sind in Abb. dargestellt. 5.1.

Unter übergeordnetes Diagramm bezieht sich auf ein Diagramm, das einen oder mehrere übergeordnete Blöcke enthält. Dies ist ein Diagramm der obersten Ebene im Verhältnis zu einem Diagramm, das eine Zerlegung eines seiner Blöcke (übergeordnete Blöcke) darstellt. Beispielsweise ist das Kontextdiagramm des Prozesses „Kundenbeschwerdemanagement“ das übergeordnete Element des Prozessdiagramms „Kundenbeschwerdenmanagement“ der obersten Ebene, das in Abbildung 1 dargestellt ist. 5.5. Das letzte ist das übergeordnete Diagramm für das Unterprozessdiagramm der Anspruchsregistrierung.

Die IDEF0-Methodik erfordert, dass das Diagramm mindestens drei und nicht mehr als fünf Blöcke enthält, da es sonst schwierig zu lesen und zu verstehen ist.

Die Funktionsblöcke im 1DEF0-Diagramm sollten nacheinander und in der Reihenfolge ihrer Wichtigkeit platziert werden. Sie werden normalerweise diagonal platziert (siehe Abb. 5.5).

Jede Kinderdiagramm besteht aus untergeordneten Blöcken und Pfeilen, die die notwendigen Details des übergeordneten Blocks auf dieser Ebene bereitstellen. Somit beschreibt das untergeordnete Diagramm denselben Themenbereich wie sein übergeordneter Block. Ein Beispiel ist das Zerlegungsdiagramm des Teilprozesses „Anspruch registrieren“, der in Abb. dargestellt ist. 5.6. Es handelt sich um ein untergeordnetes Diagramm des Prozessdiagramms „Kundenbeschwerdemanagement“ der obersten Ebene (siehe Abbildung 5.5), da es eine detailliertere Beschreibung eines Funktionsblocks (des ersten) des übergeordneten Diagramms darstellt. Andere Funktionsblöcke dieses übergeordneten Diagramms können auf ähnliche Weise detailliert beschrieben werden.

Reis. 5.5. Diagramm der obersten Ebene des Kundenbeschwerdemanagementprozesses

Reis. 5.6. Diagramm des Teilprozesses „Anspruch registrieren“.

Der Geschäftsmodellierungsprozess kann im Rahmen verschiedener Techniken umgesetzt werden, die sich vor allem in ihrer Herangehensweise an die modellierte Organisation unterscheiden. Entsprechend unterschiedlicher Organisationsvorstellungen werden Methoden üblicherweise in objektbasierte und funktionale (strukturelle) Methoden unterteilt.

Objekttechniken Betrachten Sie die modellierte Organisation als eine Reihe interagierender Objekte – Produktionseinheiten. Ein Objekt wird als eine greifbare Realität definiert – ein Objekt oder Phänomen, das ein klar definiertes Verhalten aufweist. Der Zweck dieser Technik besteht darin, die Objekte zu identifizieren, aus denen die Organisation besteht, und die Verantwortlichkeiten für die durchgeführten Aktionen unter ihnen zu verteilen.

Funktionelle Techniken Die bekannteste davon ist die IDEF-Methodik. Sie betrachten die Organisation als eine Reihe von Funktionen, die den eingehenden Informationsfluss in einen Ausgabefluss umwandeln. Der Prozess der Informationskonvertierung verbraucht bestimmte Ressourcen. Hauptunterschied zu Objekttechnik besteht in einer klaren Trennung der Funktionen (Methoden der Datenverarbeitung) von den Daten selbst.

Aus Sicht der Geschäftsmodellierung hat jeder der vorgestellten Ansätze seine eigenen Vorteile. Mit dem Objektansatz können Sie ein System aufbauen, das resistenter gegenüber Änderungen ist und besser zu bestehenden Systemen passt Organisationsstrukturen. Funktionale Modellierung zeigt sich gut in Fällen, in denen sich die Organisationsstruktur im Wandel befindet oder generell schlecht ausgestaltet ist. Die Vorgehensweise aus den ausgeführten Funktionen wird von den Ausführenden intuitiv besser verstanden, wenn sie von ihnen Informationen über ihre aktuelle Arbeit erhalten.

Funktionsmethode IDEF0

Die IDEF0-Methodik kann als nächste Stufe in der Entwicklung der bekannten grafischen Sprache zur Beschreibung funktionaler Systeme SADT (Structured Analysis and Design Technique) betrachtet werden. Historisch gesehen wurde IDEF0 als Standard 1981 als Teil eines umfangreichen industriellen Automatisierungsprogramms namens ICAM (Integrated Computer Aided Manufacturing) entwickelt. Die IDEF-Standardfamilie hat ihre Bezeichnung vom Namen dieses Programms geerbt (IDEF = Icam DEFinition) und ihre neueste Ausgabe wurde im Dezember 1993 vom US-amerikanischen National Institute of Standards and Technology (NIST) veröffentlicht.

Der Zweck der Methodik besteht darin, aufzubauen Funktionsdiagramm Das untersuchte System beschreibt alle notwendigen Prozesse mit einer Genauigkeit, die für eine eindeutige Modellierung der Systemaktivität ausreicht.

Die Methodik basiert auf vier Hauptkonzepten: Funktionsblock, Schnittstellenbogen, Zerlegung, Glossar.

(Aktivitätsbox) stellt eine bestimmte Funktion innerhalb des betreffenden Systems dar. Gemäß den Anforderungen des Standards muss der Name jedes Funktionsblocks in der verbalen Stimmung formuliert werden (z. B. „Dienste produzieren“). Im Diagramm ist der Funktionsblock als Rechteck dargestellt (Abb. 6.1). Jede der vier Seiten des Funktionsblocks hat ihre eigene spezifische Bedeutung (Rolle) und:

die Oberseite ist auf „Steuerung“ eingestellt;
die linke Seite ist auf „Eingabe“ eingestellt;
die rechte Seite ist auf „Ausgabe“ eingestellt;
die Unterseite hat die Bedeutung „Mechanismus“.

Reis. 6.1.

Schnittstellenbogen(Pfeil) zeigt ein Systemelement an, das von einem Funktionsblock verarbeitet wird oder die durch diesen Funktionsblock dargestellte Funktion anderweitig beeinflusst. Grenzflächenbögen werden oft als Flüsse oder Pfeile bezeichnet.

Mithilfe von Schnittstellenbögen werden verschiedene Objekte dargestellt, die in gewisser Weise die im System ablaufenden Prozesse bestimmen. Solche Objekte können Elemente der realen Welt (Teile, Autos, Mitarbeiter etc.) oder Daten- und Informationsflüsse (Dokumente, Daten, Anweisungen etc.) sein.

Je nachdem, auf welche Seite des Funktionsblocks dieser Schnittstellenbogen passt, wird er „eingehend“, „ausgehend“ oder „Steuerung“ genannt.

Es ist zu beachten, dass jeder Funktionsblock gemäß den Anforderungen der Norm über mindestens einen Steuerschnittstellenbogen und einen ausgehenden verfügen muss. Das ist verständlich – jeder Prozess muss nach bestimmten Regeln ablaufen (angezeigt durch den Kontrollbogen) und ein Ergebnis liefern (ausgehender Bogen), sonst macht seine Betrachtung keinen Sinn.

Das obligatorische Vorhandensein von Steuerschnittstellenbögen ist einer der Hauptunterschiede zwischen dem IDEF0-Standard und anderen Methoden der Klassen DFD (Data Flow Diagram) und WFD (Work Flow Diagram).

Zersetzung(Zerlegung) ist ein Kernkonzept des IDEF0-Standards. Das Zerlegungsprinzip wird angewendet, wenn ein komplexer Prozess in seine einzelnen Funktionen zerlegt wird. Dabei Detaillierungsgrad Der Prozess wird direkt vom Modellentwickler bestimmt.

Durch die Zerlegung können Sie das Systemmodell schrittweise und strukturiert in Form einer hierarchischen Struktur einzelner Diagramme darstellen, wodurch es weniger überladen und leichter verständlich wird.

Das letzte der IDEF0-Konzepte ist Glossar. Für jedes der IDEF0-Elemente – Diagramme, Funktionsblöcke, Schnittstellenbögen – erfordert der bestehende Standard die Erstellung und Pflege einer Reihe entsprechender Definitionen, Schlüsselwörter, narrativer Aussagen usw., die das von diesem Element angezeigte Objekt charakterisieren. Dieser Satz wird Glossar genannt und ist eine Beschreibung des Wesens eines bestimmten Elements. Das Glossar ergänzt die visuelle Bildsprache harmonisch und versorgt die Diagramme mit den notwendigen Zusatzinformationen.

Das IDEF0-Modell beginnt immer mit der Betrachtung des Systems als Ganzes – einer funktionalen Einheit mit Schnittstellenbögen, die über den betrachteten Bereich hinausgehen. Ein solches Diagramm mit einem Funktionsblock heißt Kontextdiagramm.

Im erläuternden Text zu Kontextdiagramm muss angegeben werden Ziel(Zweck) ein Diagramm in Form einer kurzen Beschreibung zu erstellen und aufzuzeichnen Standpunkt(Standpunkt).

Der Standpunkt bestimmt die Hauptentwicklungsrichtung des Modells und den erforderlichen Detaillierungsgrad. Eine klare Fixierung des Standpunkts ermöglicht es Ihnen, das Modell zu entlasten, indem Sie auf die Detaillierung und Untersuchung einzelner Elemente verzichten, die aufgrund des gewählten Standpunkts auf das System nicht notwendig sind. Die richtige Wahl des Standpunktes reduziert den Zeitaufwand für die Erstellung des endgültigen Modells erheblich.

Identifizierung von Teilprozessen. Bei der Zersetzung wird der Funktionsblock, der in Kontextdiagramm zeigt das System als Ganzes und wird in einem weiteren Diagramm detailliert dargestellt. Das resultierende Diagramm der zweiten Ebene enthält Funktionsblöcke, die die wichtigsten Unterfunktionen des Funktionsblocks anzeigen Kontextdiagramm und wird in Bezug darauf als Child-Diagramm bezeichnet (jeder zu einem Child-Diagramm gehörende Funktionsblock wird jeweils Child-Box genannt). Der übergeordnete Funktionsblock wiederum wird in Bezug auf das untergeordnete Diagramm (übergeordnete Box) als übergeordneter Block bezeichnet, und das Diagramm, zu dem er gehört, wird als übergeordnetes Diagramm (übergeordnetes Diagramm) bezeichnet. Jede der Unterfunktionen eines untergeordneten Diagramms kann durch eine ähnliche Zerlegung des entsprechenden Funktionsblocks weiter detailliert werden. Bei jeder Zerlegung eines Funktionsblocks werden alle in diesen Block eintretenden oder von ihm ausgehenden Schnittstellenbögen im untergeordneten Diagramm fixiert. Dadurch wird die strukturelle Integrität des IDEF0-Modells erreicht.

Manchmal macht es keinen Sinn, weiterhin einzelne Schnittstellenbögen einer höheren Ebene in Diagrammen einer niedrigeren Ebene zu berücksichtigen oder umgekehrt – einzelne Bögen einer niedrigeren Ebene in Diagrammen höherer Ebenen widerzuspiegeln – dies führt nur zu einer Überlastung der Diagramme und macht sie unbrauchbar schwierig zu verstehen. Um solche Probleme zu lösen, bietet der IDEF0-Standard das Konzept des Tunnelns. Die Bezeichnung „Pfeiltunnel“ in Form von zwei Klammern um den Anfang eines Schnittstellenbogens weist darauf hin, dass der Bogen nicht von einem funktionalen übergeordneten Block geerbt wurde und (aus dem „Tunnel“) nur in diesem Diagramm erscheint. Die gleiche Bezeichnung um das Ende (Pfeil) des Schnittstellenbogens in unmittelbarer Nähe des Empfängerblocks bedeutet wiederum, dass dieser Bogen im untergeordneten Diagramm dieses Blocks nicht angezeigt oder berücksichtigt wird. Am häufigsten kommt es vor, dass einzelne Objekte und ihre entsprechenden Schnittstellenbögen auf einigen Zwischenebenen der Hierarchie nicht berücksichtigt werden. In diesem Fall werden sie zuerst „in den Tunnel eingetaucht“ und dann, falls erforderlich, „aus dem Tunnel zurückgebracht“. .

Typischerweise enthalten IDEF0-Modelle komplexe und konzentrierte Informationen. Um ihre Überlastung zu begrenzen und sie lesbar zu machen, übernimmt der Standard entsprechende Komplexitätsbeschränkungen.

Es wird empfohlen, drei bis sechs Funktionsblöcke im Diagramm darzustellen, wobei davon ausgegangen wird, dass die Anzahl der Schnittstellenbögen, die für einen Funktionsblock geeignet sind (aus einem Funktionsblock hervorgehen), nicht mehr als vier beträgt.

Der IDEF0-Standard enthält eine Reihe von Verfahren, die es ermöglichen, ein Modell zu entwickeln und von einer großen Gruppe von Personen aus verschiedenen Tätigkeitsbereichen des modellierten Systems zu vereinbaren. Typischerweise ist der Entwicklungsprozess iterativ und besteht aus den folgenden konventionellen Phasen:

Erstellung eines Modells durch eine Gruppe von Spezialisten aus verschiedenen Unternehmensbereichen. Diese Gruppe wird in IDEF0-Begriffen als Autoren bezeichnet. Der Aufbau des Ausgangsmodells ist ein dynamischer Prozess, bei dem die Autoren kompetente Personen zur Struktur verschiedener Prozesse befragen und so Modelle für Abteilungsaktivitäten erstellen. Sie sind an Antworten auf folgende Fragen interessiert:
Was erhält die Abteilung als Input?
- Welche Funktionen und in welcher Reihenfolge werden innerhalb der Abteilung wahrgenommen?
- Wer ist für die Ausführung der einzelnen Funktionen verantwortlich?
- Wovon orientiert sich der Darsteller bei der Ausführung der einzelnen Funktionen?
- Was ist das Ergebnis der Arbeit der Abteilung (Output)?
Basierend auf bestehenden Vorschriften, Dokumenten und Umfrageergebnissen wird ein Musterentwurf des Modells erstellt.
Verteilen des Entwurfs zur Überprüfung, Genehmigung und Kommentierung. In dieser Phase wird der Modellentwurf mit einem breiten Spektrum kompetenter Personen (im Sinne von IDEF0 – Lesern) im Unternehmen diskutiert. Dabei wird jedes Diagramm des Modellentwurfs schriftlich kritisiert, kommentiert und anschließend an den Autor übergeben. Der Autor wiederum stimmt der Kritik ebenfalls schriftlich zu oder lehnt sie unter Darlegung der Logik der Entscheidung ab und gibt den überarbeiteten Entwurf zur weiteren Prüfung zurück. Dieser Zyklus wird fortgesetzt, bis Autoren und Leser einen Konsens erzielen.
Offizielle Zulassung des Modells. Das vereinbarte Modell wird vom Leiter der Arbeitsgruppe genehmigt, wenn zwischen den Autoren des Modells und den Lesern keine Meinungsverschiedenheiten über seine Angemessenheit bestehen. Das endgültige Modell ist eine kohärente Sicht auf das Unternehmen (System) aus einem bestimmten Blickwinkel und für einen bestimmten Zweck.

Die Klarheit der IDEF0-Grafiksprache macht das Modell auch für Personen, die nicht am Projekt seiner Erstellung beteiligt waren, vollständig lesbar und eignet sich hervorragend für Vorführungen und Präsentationen. Basierend auf dem erstellten Modell können in Zukunft neue Projekte organisiert werden, die darauf abzielen, Änderungen am Modell vorzunehmen.

Die wichtigste der drei von BPwin unterstützten Methoden ist IDEF0. IDEF0 gehört zur IDEF-Familie, die Ende der sechziger Jahre unter dem Namen SADT (Structured Analysis and Design Technique) erschien. Mit IDEF0 lassen sich verschiedenste Systeme modellieren. Bei neuen Systemen zielt der Einsatz von IDEF0 auf die Definition von Anforderungen und die Spezifikation von Funktionen für die spätere Entwicklung eines Systems ab, das die Anforderungen erfüllt und die ausgewählten Funktionen implementiert. Bei der Anwendung auf bestehende Systeme kann IDEF0 verwendet werden, um die vom System ausgeführten Funktionen zu analysieren und die Mechanismen abzubilden, mit denen diese Funktionen ausgeführt werden. Das Ergebnis der Anwendung von IDEF0 auf ein System ist ein Modell dieses Systems, das aus einem hierarchisch geordneten Satz von Diagrammen, Dokumentationstexten und Vokabularien besteht, die miteinander verknüpft sind. Die beiden wichtigsten Komponenten, aus denen sich IDEF0-Diagramme zusammensetzen, sind die Geschäftsfunktionen oder -aktivitäten (in den Diagrammen als Kästchen dargestellt) und die Daten und Objekte (dargestellt als Pfeile), die die Aktivitäten verbinden. In diesem Fall werden die Pfeile, abhängig davon, auf welcher Fläche des Arbeitsrechtecks sie eintreten bzw. aus welcher Fläche sie austreten, in fünf Typen unterteilt:

Eingabepfeile (auf der linken Seite der Arbeit enthalten) – stellen Daten oder Objekte dar, die sich während der Ausführung der Arbeit ändern.

Kontrollpfeile (im oberen Rand der Arbeit enthalten) – stellen die Regeln und Einschränkungen dar, nach denen die Arbeit ausgeführt wird.

Ausgangspfeile (die sich von der rechten Seite der Arbeit erstrecken) – stellen Daten oder Objekte dar, die als Ergebnis der Arbeit erscheinen.

Mechanismuspfeile (am unteren Rand der Arbeit enthalten) – stellen die Ressourcen dar, die zur Fertigstellung der Arbeit erforderlich sind, sich aber während der Arbeit nicht ändern (z. B. Ausrüstung, Personal usw.)

Rufpfeile (vom unteren Rand der Arbeit kommend) – stellen Verbindungen zwischen verschiedenen Diagrammen oder Modellen dar und zeigen auf ein Diagramm, in dem diese Arbeit ausführlicher besprochen wird.

Alle Jobs und Pfeile müssen benannt werden. Das erste Diagramm in der IDEF0-Diagrammhierarchie zeigt immer die Funktionsweise des Systems als Ganzes. Solche Diagramme werden Kontextdiagramme genannt. Der Kontext umfasst eine Beschreibung des Zwecks der Modellierung, des Umfangs (eine Beschreibung dessen, was als Komponente des Systems und was als externer Einfluss betrachtet wird) und den Standpunkt (die Position, von der aus das Modell erstellt wird). ). Typischerweise ist der Standpunkt der Standpunkt der Person oder des Objekts, die für den Betrieb des modellierten Systems als Ganzes verantwortlich ist.

Abbildung 7.1. Funktionsblock- und Schnittstellenbögen

Aktivitäten in Diagrammen werden als Rechtecke (Funktionsblöcke) dargestellt. Jeder Job stellt eine Funktion oder Aufgabe dar und wird durch ein Verb oder eine Verbphrase benannt, die die Aktion angibt, zum Beispiel „Ein Produkt herstellen“, „Kundendienst“ usw. Pfeile sind mit einem Substantiv gekennzeichnet und weisen auf Objekte oder Informationen hin, die die Werke untereinander und mit der Außenwelt verbinden.

Nach der Beschreibung des Kontextes wird eine funktionale Zerlegung durchgeführt – das System wird in Subsysteme unterteilt und jedes Subsystem wird in derselben Syntax wie das System als Ganzes beschrieben. Dann wird jedes Subsystem in kleinere unterteilt und so weiter, bis der gewünschte Detaillierungsgrad erreicht ist. Aufgrund dieser Aufteilung wird jedes Fragment des Systems in einem separaten Zerlegungsdiagramm dargestellt.

Nachdem der Kontext beschrieben wurde, werden die folgenden Diagramme in der Hierarchie erstellt. Jedes nachfolgende Diagramm ist eine detailliertere Beschreibung (Zerlegung) eines der Werke im obigen Diagramm. Ein Beispiel für die kontextbezogene Arbeitszerlegung ist in Abbildung 7.2 und Abbildung 7.4 dargestellt. Die Beschreibung jedes Subsystems erfolgt durch einen Analysten zusammen mit einem Fachexperten. Typischerweise ist der Experte die Person, die für dieses Subsystem verantwortlich ist und daher über umfassende Kenntnisse aller seiner Funktionen verfügt. Auf diese Weise wird das gesamte System mit dem erforderlichen Detaillierungsgrad in Teilsysteme unterteilt und ein Modell erhalten, das das System mit einem bestimmten Genauigkeitsgrad annähert. Nachdem der Analyst ein Modell erhalten hat, das aktuelle Geschäftsprozesse angemessen widerspiegelt (das sogenannte AS IS-Modell), kann er alle anfälligsten Punkte des Systems leicht erkennen. Anschließend ist es unter Berücksichtigung der festgestellten Mängel möglich, ein Modell einer neuen Organisation von Geschäftsprozessen (TO BE-Modell) zu erstellen.

Eines der wichtigsten Merkmale der SADT-Methodik ist die schrittweise Einführung immer größerer Detailebenen bei der Erstellung von Diagrammen, die das Modell darstellen.

Abbildung 7.2, die drei Diagramme und ihre Beziehungen zeigt, zeigt die Struktur des IDEF0.-Modells. Jede Komponente des Modells kann in ein anderes Diagramm zerlegt werden. Jedes Diagramm veranschaulicht die „interne Struktur“ eines Blocks in seinem übergeordneten Diagramm.

Abbildung 7.2 – Beispiel eines Kontextdiagramms

Wie in Abb. 7.2 zu sehen ist, können Sie mit BPwin Aktivitäten und Pfeile in verschiedenen Farben hervorheben und die Namen der Pfeile mit den Pfeilen selbst verknüpfen (ein Pfeil mit dem Namen „Berichterstellung“), was die Klarheit und Lesbarkeit erhöht Das Diagramm.

Abbildung 7.3 – Beispiel eines Zerlegungsdiagramms

Zeichnung7 . 4 - Beispiel für ein Kontextdiagramm

Abbildung 7.5 - Beispiel für ein Zerlegungsdiagramm

Diagrammhierarchie

Der Aufbau des IDEF0-Modells beginnt mit der Darstellung des gesamten Systems in Form der einfachsten Komponente – einem Block und Bögen, die Schnittstellen mit Funktionen außerhalb des Systems darstellen. Da ein einzelner Block das gesamte System als Ganzes darstellt, ist der im Block angegebene Name generisch. Dies gilt auch für Schnittstellenbögen – sie stellen ebenfalls den kompletten Satz externer Schnittstellen des Gesamtsystems dar.

Der Block, der das System als einzelnes Modul darstellt, wird dann in einem anderen Diagramm anhand mehrerer durch Schnittstellenbögen verbundener Blöcke detailliert beschrieben. Diese Blöcke stellen die Hauptunterfunktionen der ursprünglichen Funktion dar. Diese Zerlegung ergibt einen vollständigen Satz von Unterfunktionen, die jeweils als Block dargestellt werden und deren Grenzen durch Schnittstellenbögen definiert werden. Jede dieser Unterfunktionen kann auf ähnliche Weise zerlegt werden, um eine detailliertere Darstellung zu erhalten.

In allen Fällen kann jede Unterfunktion nur die Elemente enthalten, die in der ursprünglichen Funktion enthalten sind. Darüber hinaus darf das Modell keine Elemente weglassen, d. h., wie bereits erwähnt, stellen der übergeordnete Block und seine Schnittstellen den Kontext bereit. Es kann nichts hinzugefügt und nichts daraus entfernt werden.

Die Bögen, die in einem Diagramm der obersten Ebene in einen Block ein- und ausgehen, sind genau die gleichen wie die Bögen, die in einem Diagramm einer niedrigeren Ebene ein- und ausgehen, da der Block und das Diagramm denselben Teil des Systems darstellen.

Abbildung 7.6 – Struktur des SADT-Modells. Zerlegung von Diagrammen

Abbildung 7.7 – Die Einhaltung muss vollständig und konsistent sein

Einige Bögen sind an beiden Enden mit den Diagrammblöcken verbunden, während bei anderen ein Ende nicht befestigt ist. Nicht verbundene Bögen entsprechen den Eingängen, Steuerungen und Ausgängen des übergeordneten Blocks. Die Quelle oder das Ziel dieser Grenzbögen kann nur im übergeordneten Diagramm gefunden werden. Die freien Enden müssen mit den Bögen im Originaldiagramm übereinstimmen. Alle Grenzbögen müssen im übergeordneten Diagramm fortgesetzt werden, damit es vollständig und konsistent ist.

Wie bereits erwähnt, zeigen die Mechanismen (Bögen auf der Unterseite) die Mittel, mit denen Funktionen ausgeführt werden. Der Mechanismus kann eine Person, ein Computer oder ein anderes Gerät sein, das bei der Ausführung einer bestimmten Funktion hilft (Abbildung 7.8).

Reis. 7.8. Beispiel eines Mechanismus

Jeder Block im Diagramm hat eine eigene Nummer. Ein Block eines beliebigen Diagramms kann durch ein Diagramm einer niedrigeren Ebene weiter beschrieben werden, das wiederum mit der erforderlichen Anzahl von Diagrammen weiter detailliert werden kann. Dadurch entsteht eine Hierarchie von Diagrammen.

Plannummern werden verwendet, um die Position eines Plans oder Blocks in der Hierarchie anzugeben. A21 ist beispielsweise ein Diagramm, das Block 1 in Diagramm A2 detailliert beschreibt. In ähnlicher Weise beschreibt A2 Block 2 im Diagramm A0, dem obersten Diagramm des Modells. Abbildung 7.9 zeigt einen typischen Diagrammbaum.

Abbildung 7.9 – Hierarchie der Diagramme

Vorlesung 8. MethodenDFDUndIDEF3

Lernen Sie, die funktionale Struktur Ihres Unternehmens zu erkennen und zu verstehen!

Derzeit ist in Russland das Interesse an im Westen allgemein akzeptierten Managementstandards stark gestiegen, in der tatsächlichen Managementpraxis gibt es jedoch einen sehr wichtigen Punkt. Bei einer direkten Frage nach der Organisationsstruktur des Unternehmens oder der Gestaltung bestehender Geschäftsprozesse stehen viele Führungskräfte immer noch vor dem Problem. Die fortgeschrittensten Manager, die regelmäßig Wirtschaftszeitschriften lesen, beginnen in der Regel, hierarchische Diagramme zu zeichnen, die nur sie verstehen können, geraten dabei aber meist schnell in eine Sackgasse. Gleiches gilt für Mitarbeiter und Führungskräfte verschiedener Dienst- und Funktionsabteilungen. In den meisten Fällen sind die einzigen festgelegten Regeln, nach denen ein Unternehmen arbeiten muss, eine Reihe individueller Vorschriften und Stellenbeschreibungen. Meistens wurden diese Dokumente vor mehr als einem Jahr zusammengestellt, sind schlecht strukturiert und stehen in keinem Zusammenhang zueinander und verstauben daher einfach in den Regalen. Ein solcher Ansatz war vorerst gerechtfertigt, da es bei der Entstehung der russischen Marktwirtschaft praktisch keinen Wettbewerbsbegriff gab und keine besondere Kostenkalkulation erforderlich war – die Gewinne waren gigantisch. Infolgedessen haben wir in den letzten zwei Jahren ein völlig verständliches Bild gesehen: Große Unternehmen, die Anfang der 90er Jahre gewachsen sind, verlieren nach und nach ihre Positionen bis hin zum vollständigen Ausscheiden aus dem Markt. Dies ist unter anderem darauf zurückzuführen, dass im Unternehmen keine Managementstandards eingeführt wurden und das Konzept eines funktionalen Handlungs- und Missionsmodells völlig fehlte. Durch die Modellierung verschiedener Tätigkeitsbereiche können Sie Engpässe im Management sehr effektiv analysieren und das Gesamtgeschäftskonzept optimieren. Aber wie Sie wissen, haben in jedem Unternehmen nur Projekte die höchste Priorität, die direkt Gewinn bringen, so dass die Frage nach einer Überprüfung und Neuorganisation der Aktivitäten meist nur während einer erheblichen Krise in der Unternehmensführung gestellt wird.

Ende der 1990er Jahre, als der Markt wettbewerbsintensiver wurde und die Rentabilität der Unternehmen stark zu sinken begann, hatten die Manager enorme Schwierigkeiten, die Kosten so zu optimieren, dass die Produkte sowohl profitabel als auch wettbewerbsfähig blieben. In diesem Moment wurde Ihnen völlig klar, dass Sie ein Modell der Unternehmenstätigkeit vor Augen haben müssen, das alle Mechanismen und Prinzipien der Verbindung verschiedener Subsysteme innerhalb eines Unternehmens widerspiegelt.

Das eigentliche Konzept der „Geschäftsprozessmodellierung“ gelangte gleichzeitig mit dem Erscheinen komplexer Softwareprodukte auf den Markt, die für die komplexe Automatisierung der Unternehmensführung entwickelt wurden, in den Alltag der meisten Analysten. Solche Systeme erfordern immer eine eingehende Vorprojektprüfung der Unternehmensaktivitäten. Das Ergebnis dieser Untersuchung ist ein Gutachten, in dem in einzelnen Punkten Empfehlungen zur Beseitigung von Engpässen im Aktivitätsmanagement ausgesprochen werden. Basierend auf dieser Schlussfolgerung wird unmittelbar vor dem Projekt der Implementierung eines Automatisierungssystems eine sogenannte Reorganisation der Geschäftsprozesse durchgeführt, die für das Unternehmen manchmal sehr schwerwiegend und schmerzhaft ist. Das ist natürlich; es ist immer schwierig, ein Team, das über die Jahre zusammengestellt wurde, dazu zu zwingen, „neu zu denken“. Solche umfassenden Unternehmensbefragungen sind immer komplex und von Fall zu Fall sehr unterschiedlich. Um solche Probleme bei der Modellierung komplexer Systeme zu lösen, gibt es bewährte Methoden und Standards. Zu diesen Standards gehört die IDEF-Methodenfamilie. Mit ihrer Hilfe können Sie Aktivitätsmuster unterschiedlichster komplexer Systeme in unterschiedlichen Kontexten effektiv darstellen und analysieren. Gleichzeitig wird der Umfang und die Tiefe der Untersuchung von Prozessen im System vom Entwickler selbst bestimmt, wodurch es möglich ist, das erstellte Modell nicht mit unnötigen Daten zu überladen. Derzeit umfasst die IDEF-Familie die folgenden Standards:

IDEF0 – funktionale Modellierungsmethodik. Mithilfe der visuellen Grafiksprache IDEF0 erscheint das untersuchte System Entwicklern und Analysten in Form einer Reihe miteinander verbundener Funktionen (Funktionsblöcke – in IDEF0-Begriffen). In der Regel ist die IDEF0-Modellierung der erste Schritt bei der Untersuchung eines Systems;
IDEF1 ist eine Methodik zur Modellierung von Informationsflüssen innerhalb eines Systems, mit der Sie deren Struktur und Beziehungen anzeigen und analysieren können.
IDEF1X (IDEF1 Extended) – Methodik zum Aufbau relationaler Strukturen. IDEF1X gehört zum Methodentyp Entity-Relationship (ER) und wird typischerweise zur Modellierung relationaler Datenbanken verwendet, die für das jeweilige System relevant sind;
IDEF2 ist eine Methodik zur dynamischen Modellierung der Systementwicklung. Aufgrund der sehr großen Schwierigkeiten bei der Analyse dynamischer Systeme wurde dieser Standard praktisch aufgegeben und seine Entwicklung bereits in der Anfangsphase eingestellt. Derzeit gibt es jedoch Algorithmen und deren Computerimplementierungen, die es ermöglichen, einen Satz statischer IDEF0-Diagramme in dynamische Modelle umzuwandeln, die auf der Grundlage von „farbigen Petri-Netzen“ (CPN – Color Petri Nets) basieren;
IDEF3 ist eine Methodik zur Dokumentation von in einem System ablaufenden Prozessen, die beispielsweise bei der Untersuchung technologischer Prozesse in Unternehmen eingesetzt wird. IDEF3 beschreibt das Szenario und die Abfolge der Vorgänge für jeden Prozess. IDEF3 hat eine direkte Beziehung zur IDEF0-Methodik – jede Funktion (Funktionsblock) kann mit IDEF3 als separater Prozess dargestellt werden;
IDEF4 ist eine Methodik zum Aufbau objektorientierter Systeme. Mit den IDEF4-Tools können Sie die Struktur von Objekten und die zugrunde liegenden Prinzipien ihrer Interaktion visuell darstellen und so komplexe objektorientierte Systeme analysieren und optimieren.
IDEF5 ist eine Methodik zur ontologischen Erforschung komplexer Systeme. Mithilfe der IDEF5-Methodik kann die Ontologie eines Systems anhand eines spezifischen Wörterbuchs aus Begriffen und Regeln beschrieben werden, auf dessen Grundlage verlässliche Aussagen über den Zustand des betrachteten Systems zu einem bestimmten Zeitpunkt getroffen werden können. Basierend auf diesen Aussagen werden Rückschlüsse auf die Weiterentwicklung des Systems gezogen und dessen Optimierung durchgeführt.

In diesem Artikel betrachten wir die am häufigsten verwendete funktionale Modellierungsmethode, IDEF0.

Geschichte des IDEF0-Standards

Die IDEF0-Methodik kann als nächste Stufe in der Entwicklung der bekannten grafischen Sprache zur Beschreibung funktionaler Systeme SADT (Structured Analysis and Design Teqnique) betrachtet werden. Vor einigen Jahren wurde in Russland in kleiner Auflage ein gleichnamiges Buch veröffentlicht, das sich der Beschreibung der Grundprinzipien der Erstellung von SADT-Diagrammen widmet. Historisch gesehen wurde IDEF0 als Standard 1981 als Teil eines umfangreichen industriellen Automatisierungsprogramms namens ICAM (Integrated Computer Aided Manufacturing) entwickelt und von der US Air Force vorgeschlagen. Tatsächlich hat die IDEF-Standardfamilie ihre Bezeichnung vom Namen dieses Programms geerbt (IDEF=ICAM DEFinition). Im Rahmen der praktischen Umsetzung standen die Teilnehmer des ICAM-Programms vor der Notwendigkeit, neue Methoden zur Analyse von Interaktionsprozessen in industriellen Systemen zu entwickeln. Darüber hinaus war eine der Anforderungen an den neuen Standard neben einem verbesserten Funktionsumfang zur Beschreibung von Geschäftsprozessen das Vorhandensein einer effektiven Methodik für die Interaktion im „Analysten-Spezialisten“-Rahmen. Mit anderen Worten: Die neue Methode sollte eine Gruppenarbeit bei der Erstellung eines Modells unter direkter Beteiligung aller am Projekt beteiligten Analysten und Spezialisten gewährleisten.

Als Ergebnis der Suche nach geeigneten Lösungen wurde die funktionale Modellierungsmethodik IDEF0 geboren. Seit 1981 hat der IDEF0-Standard mehrere geringfügige Änderungen erfahren, die größtenteils restriktiver Natur waren, und seine neueste Ausgabe wurde im Dezember 1993 vom US-amerikanischen National Institute of Standards and Technology (NIST) veröffentlicht.

Kernelemente und Konzepte von IDEF0

Die grafische Sprache von IDEF0 ist überraschend einfach und harmonisch. Die Methodik basiert auf vier Hauptkonzepten:

Das erste davon ist das Konzept Funktionsblock (Aktivitätsbox). Ein Funktionsblock wird grafisch als Rechteck dargestellt (siehe Abb. 1) und repräsentiert eine bestimmte Funktion innerhalb des betrachteten Systems. Gemäß den Anforderungen des Standards muss der Name jedes Funktionsblocks in der verbalen Stimmung formuliert werden (z. B. „Dienste produzieren“, nicht „Dienste produzieren“).

Jede der vier Seiten des Funktionsblocks hat ihre eigene spezifische Bedeutung (Rolle) und:

Die Oberseite ist auf „Steuerung“ eingestellt;
Die linke Seite ist auf „Eingabe“ eingestellt;
Die rechte Seite ist auf „Ausgabe“ eingestellt;
Die Unterseite hat die Bedeutung „Mechanismus“.

Jeder Funktionsblock innerhalb eines einzelnen betrachteten Systems muss über eine eigene eindeutige Identifikationsnummer verfügen.

Abbildung 1. Funktionsblock.

Die zweite Säule der IDEF0-Methodik ist das Konzept Schnittstellenbogen (Pfeil). Schnittstellenbögen werden oft auch als Flüsse oder Pfeile bezeichnet. Ein Schnittstellenbogen stellt ein Systemelement dar, das von einem Funktionsblock verarbeitet wird oder die von diesem Funktionsblock dargestellte Funktion auf andere Weise beeinflusst.

Die grafische Darstellung eines Schnittstellenbogens ist ein unidirektionaler Pfeil. Jeder Schnittstellenbogen muss einen eigenen eindeutigen Namen (Pfeilbeschriftung) haben. Gemäß den Anforderungen des Standards muss der Name eine Form eines Substantivs sein.

Je nachdem, welcher Seite sich dieser Schnittstellenbogen nähert, spricht man von „eingehend“, „ausgehend“ oder „steuernd“. Darüber hinaus können die „Quelle“ (Anfang) und die „Senke“ (Ende) jedes Funktionsbogens nur Funktionsblöcke sein, während die „Quelle“ nur die Ausgangsseite des Blocks sein kann und die „Senke“ beliebig sein kann der drei verbleibenden.

Beim Erstellen von IDEF0-Diagrammen ist es wichtig, eingehende Schnittstellenbögen korrekt von Steuerbögen zu trennen, was oft schwierig ist. Abbildung 2 zeigt beispielsweise den Funktionsblock „Werkstück bearbeiten“.

Im realen Prozess erhält der bearbeitende Werker ein Werkstück und technologische Anweisungen zur Bearbeitung (bzw. Sicherheitsregeln beim Arbeiten mit der Maschine). Es mag fälschlicherweise scheinen, dass sowohl das Werkstück als auch das Dokument mit technologischen Anweisungen eingehende Objekte sind, aber das ist nicht der Fall. Tatsächlich wird bei diesem Prozess das Werkstück nach den in den technologischen Anweisungen wiedergegebenen Regeln bearbeitet, die jeweils durch den Steuerschnittstellenbogen dargestellt werden sollen.

Figur 2.

Eine andere Sache ist es, wenn technologische Anweisungen vom Cheftechnologen bearbeitet und Änderungen daran vorgenommen werden (Abb. 3). In diesem Fall werden sie durch einen bereits eingehenden Schnittstellenbogen angezeigt, und das Kontrollobjekt sind beispielsweise neue Industriestandards, auf deren Grundlage diese Änderungen vorgenommen werden.

Figur 3.

Die obigen Beispiele verdeutlichen die oberflächliche Ähnlichkeit der Eingangs- und Steuerschnittstellenbögen. Bei Systemen derselben Klasse gibt es jedoch immer gewisse Unterschiede. Bei der Betrachtung von Unternehmen und Organisationen gibt es beispielsweise fünf Haupttypen von Objekten: Materialflüsse (Teile, Waren, Rohstoffe usw.), Finanzflüsse (Bargeld und nicht zahlungswirksam, Investitionen usw.), Dokumentenflüsse (kommerziell). , Finanz- und Organisationsdokumente), Informationsflüsse (Informationen, Daten zu Absichten, mündliche Anordnungen etc.) und Ressourcen (Mitarbeiter, Maschinen, Maschinen etc.). Darüber hinaus können in verschiedenen Fällen alle Arten von Objekten durch eingehende und ausgehende Schnittstellenbögen angezeigt werden, wobei nur diejenigen verwaltet werden, die sich auf den Fluss von Dokumenten und Informationen beziehen, und nur Ressourcen durch Arc-Mechanismen.

Das dritte Kernkonzept des IDEF0-Standards ist Zersetzung. Das Zerlegungsprinzip wird verwendet, wenn ein komplexer Prozess in seine Teilfunktionen zerlegt wird. In diesem Fall wird der Detaillierungsgrad des Prozesses direkt vom Modellentwickler bestimmt.

Der erläuternde Text für das Kontextdiagramm sollte den Zweck der Erstellung des Diagramms in Form einer kurzen Beschreibung und Aufzeichnung angeben Standpunkt(Standpunkt).

Die Definition und Formalisierung des Ziels der Entwicklung des IDEF0-Modells ist ein äußerst wichtiger Punkt. Tatsächlich definiert das Ziel die relevanten Bereiche im untersuchten System, auf die man sich zuerst konzentrieren muss. Wenn wir beispielsweise die Aktivitäten eines Unternehmens mit dem Ziel modellieren, in Zukunft ein Informationssystem auf Basis dieses Modells aufzubauen, dann wird sich dieses Modell deutlich von dem unterscheiden, das wir für dasselbe Unternehmen, aber mit dem Ziel, entwickeln würden der Optimierung von Lieferketten.

Der Standpunkt bestimmt die Hauptentwicklungsrichtung des Modells und den erforderlichen Detaillierungsgrad. Eine klare Fixierung des Standpunkts ermöglicht es Ihnen, das Modell zu entlasten, indem Sie auf die Detaillierung und Untersuchung einzelner Elemente verzichten, die aufgrund des gewählten Standpunkts auf das System nicht notwendig sind. Beispielsweise werden sich Funktionsmodelle desselben Unternehmens aus Sicht des Cheftechnologen und des Finanzdirektors in der Detaillierungsrichtung deutlich unterscheiden. Dies liegt daran, dass sich der Finanzdirektor letztendlich nicht für Aspekte der Rohstoffverarbeitung auf Produktionsmaschinen interessiert und der Cheftechnologe keine gezeichneten Diagramme der Finanzströme benötigt. Die richtige Wahl des Standpunktes reduziert den Zeitaufwand für die Erstellung des endgültigen Modells erheblich.

Während des Zerlegungsprozesses wird ein Funktionsblock, der das System als Ganzes in einem Kontextdiagramm darstellt, in einem anderen Diagramm detailliert dargestellt. Das resultierende Diagramm der zweiten Ebene enthält Funktionsblöcke, die die Hauptunterfunktionen des Funktionsblocks des Kontextdiagramms darstellen, und wird in Bezug auf dieses Diagramm als untergeordnetes Diagramm bezeichnet (jeder zum untergeordneten Diagramm gehörende Funktionsblock wird entsprechend als untergeordnete Box bezeichnet). Der übergeordnete Funktionsblock wiederum wird in Bezug auf das untergeordnete Diagramm (übergeordnete Box) als übergeordneter Block bezeichnet, und das Diagramm, zu dem er gehört, wird als übergeordnetes Diagramm (übergeordnetes Diagramm) bezeichnet. Jede der Unterfunktionen eines untergeordneten Diagramms kann durch eine ähnliche Zerlegung des entsprechenden Funktionsblocks weiter detailliert werden. Es ist wichtig zu beachten, dass bei jeder Zerlegung eines Funktionsblocks alle Schnittstellenbögen, die in diesen Block eintreten oder von ihm ausgehen, im untergeordneten Diagramm fixiert werden. Dadurch wird die strukturelle Integrität des IDEF0-Modells erreicht. Das Prinzip der Zerlegung ist in Abbildung 4 deutlich dargestellt. Sie sollten auf die Beziehung zwischen der Nummerierung von Funktionsblöcken und Diagrammen achten – jeder Block hat seine eigene eindeutige Seriennummer im Diagramm (die Nummer in der unteren rechten Ecke des Rechtecks). , und die Bezeichnung in der rechten Ecke gibt die Nummer des untergeordneten Diagramms für diesen Block an. Das Fehlen dieser Bezeichnung weist darauf hin, dass es für diesen Block keine Zerlegung gibt.

Es gibt oft Fälle, in denen es keinen Sinn mehr macht, einzelne Schnittstellenbögen in untergeordneten Diagrammen unterhalb einer bestimmten Hierarchieebene weiterhin zu berücksichtigen, oder umgekehrt – einzelne Bögen sind oberhalb einer bestimmten Ebene praktisch nicht sinnvoll. Es macht beispielsweise keinen Sinn, in Diagrammen höherer Ebenen einen Schnittstellenbogen anzuzeigen, der ein „Teil“ am Eingang des Funktionsblocks „Prozess auf einer Drehmaschine“ darstellt – dies würde die Diagramme nur überladen und sie schwer verständlich machen. Andererseits besteht die Notwendigkeit, einzelne „konzeptionelle“ Schnittstellenbögen loszuwerden und sie nicht über ein bestimmtes Maß hinaus zu detaillieren. Um solche Probleme zu lösen, bietet der IDEF0-Standard das Konzept Tunnelbau. Die Pfeiltunnelbezeichnung mit zwei Klammern um den Anfang eines Schnittstellenbogens weist darauf hin, dass der Bogen nicht von einem funktionalen übergeordneten Block geerbt wurde und (aus dem „Tunnel“) nur in diesem Diagramm erscheint. Die gleiche Bezeichnung um das Ende (Pfeil) des Schnittstellenbogens in unmittelbarer Nähe des Empfängerblocks bedeutet wiederum, dass dieser Bogen im untergeordneten Diagramm dieses Blocks nicht angezeigt und berücksichtigt wird. Am häufigsten kommt es vor, dass einzelne Objekte und ihre entsprechenden Schnittstellenbögen auf einigen Zwischenebenen der Hierarchie nicht berücksichtigt werden. In diesem Fall werden sie zuerst „in den Tunnel eingetaucht“ und dann, falls erforderlich, „aus dem Tunnel zurückgebracht“. .

Das letzte der IDEF0-Konzepte ist Glossar. Für jedes der IDEF0-Elemente: Diagramme, Funktionsblöcke, Schnittstellenbögen erfordert der bestehende Standard die Erstellung und Pflege einer Reihe entsprechender Definitionen, Schlüsselwörter, narrativer Aussagen usw., die das von diesem Element angezeigte Objekt charakterisieren. Dieser Satz wird Glossar genannt und ist eine Beschreibung des Wesens eines bestimmten Elements. Beispielsweise kann das Glossar für den Steuerschnittstellenbogen „Zahlungsauftrag“ eine Liste der Felder des dem Bogen entsprechenden Dokuments, den erforderlichen Satz an Visa usw. enthalten. Das Glossar ergänzt die visuelle Bildsprache harmonisch und versorgt die Diagramme mit den notwendigen Zusatzinformationen.

Abbildung 4. Zerlegung von Funktionsblöcken.

Prinzipien zur Begrenzung der Komplexität von IDEF0-Diagrammen

Typischerweise enthalten IDEF0-Modelle komplexe und konzentrierte Informationen. Um deren Überlastung zu begrenzen und sie lesbar zu machen, werden die entsprechenden Komplexitätsgrenzen in den entsprechenden Standard übernommen:

Begrenzen Sie die Anzahl der Funktionsblöcke im Diagramm auf drei bis sechs. Die Obergrenze (sechs) zwingt den Designer, bei der Beschreibung komplexer Objekte Hierarchien zu verwenden, und die Untergrenze (drei) stellt sicher, dass das entsprechende Diagramm über genügend Details verfügt, um seine Erstellung zu rechtfertigen.
Begrenzung der Anzahl der Schnittstellenbögen, die für einen Funktionsblock geeignet sind (aus einem Funktionsblock herauskommen), auf vier.

Natürlich ist es keineswegs notwendig, diese Einschränkungen strikt einzuhalten, jedoch sind sie erfahrungsgemäß in der Praxis sehr praktisch.

Disziplin der Gruppenarbeit zur Entwicklung des IDEF0-Modells

Erstellung eines Modells durch eine Gruppe von Spezialisten aus verschiedenen Unternehmensbereichen. Diese Gruppe wird in IDEF0-Begriffen als Autoren bezeichnet. Der Aufbau des Ausgangsmodells ist ein dynamischer Prozess, bei dem die Autoren kompetente Personen zur Struktur verschiedener Prozesse befragen. Basierend auf bestehenden Vorschriften, Dokumenten und Umfrageergebnissen wird ein Musterentwurf des Modells erstellt.
Verteilen des Entwurfs zur Überprüfung, Genehmigung und Kommentierung. In dieser Phase wird der Modellentwurf mit einem breiten Spektrum kompetenter Personen (im Sinne von IDEF0-Lesern) im Unternehmen diskutiert. Dabei wird jedes Diagramm des Modellentwurfs schriftlich kritisiert, kommentiert und anschließend an den Autor übergeben. Der Autor wiederum stimmt der Kritik schriftlich zu oder lehnt sie unter Darlegung der Logik der Entscheidung ab und gibt den überarbeiteten Entwurf zur weiteren Prüfung zurück. Dieser Zyklus wird fortgesetzt, bis Autoren und Leser einen Konsens erzielen.
Offizielle Zulassung des Modells. Das vereinbarte Modell wird vom Leiter der Arbeitsgruppe genehmigt, wenn zwischen den Autoren des Modells und den Lesern keine Meinungsverschiedenheiten über seine Angemessenheit bestehen. Das endgültige Modell ist eine kohärente Sicht auf das Unternehmen (System) aus einem bestimmten Blickwinkel und für einen bestimmten Zweck.

Die Klarheit der IDEF0-Grafiksprache macht das Modell auch für Personen, die nicht am Projekt seiner Erstellung beteiligt waren, vollständig lesbar und eignet sich hervorragend für Vorführungen und Präsentationen. Zukünftig können auf Basis des erstellten Modells neue Projekte organisiert werden, die auf Veränderungen im Unternehmen (im System) abzielen.

Merkmale der nationalen Praxis der Verwendung funktionaler Modellierung mit IDEF0

In den letzten Jahren ist das Interesse an der IDEF-Methodenfamilie in Russland stetig gewachsen. Ich beobachte dies ständig, wenn ich mir die Zugriffsstatistiken auf meine persönliche Webseite (http://consulting.psi.ru) ansehe, auf der die Grundprinzipien dieser Standards kurz beschrieben werden. Gleichzeitig würde ich das Interesse an Standards wie IDEF3-5 als theoretisch und an IDEF0 als durchaus praktisch berechtigt bezeichnen. Tatsächlich erschienen die ersten Case-Tools, die die Erstellung von DFD- und IDEF0-Diagrammen ermöglichten, bereits 1996 auf dem russischen Markt, zeitgleich mit der Veröffentlichung eines beliebten Buches über die Modellierungsprinzipien in SADT-Standards.

Allerdings betrachten die meisten Manager die praktische Anwendung der Modellierung in IDEF-Standards immer noch eher als eine Hommage an die Mode denn als eine effektive Möglichkeit, das bestehende Unternehmensführungssystem zu optimieren. Dies ist höchstwahrscheinlich auf einen ausgeprägten Mangel an Informationen über die praktische Anwendung dieser Methoden und den unvermeidlichen Software-Bias der überwiegenden Mehrheit der Veröffentlichungen zurückzuführen.

Es ist kein Geheimnis, dass fast alle Projekte zur Erhebung und Analyse der finanziellen und wirtschaftlichen Aktivitäten von Unternehmen in Russland auf die eine oder andere Weise mit dem Aufbau automatisierter Managementsysteme verbunden sind. Dadurch sind IDEF-Standards nach dem Verständnis der Mehrheit bedingt untrennbar mit der Implementierung der Informationstechnologie verbunden, obwohl mit ihrer Hilfe manchmal sogar kleine lokale Probleme effektiv gelöst werden können, buchstäblich mit Bleistift und Papier.

Bei der Durchführung komplexer Unternehmensumfrageprojekte können Sie durch die Entwicklung von Modellen im IDEF0-Standard den gesamten Mechanismus der Unternehmensaktivitäten im erforderlichen Kontext klar und effektiv darstellen. Das Wichtigste sind jedoch die Kollaborationsfunktionen, die IDEF0 bietet. In meiner praktischen Arbeit kam es recht häufig vor, dass der Bau eines Modells mit direkter Hilfe von Mitarbeitern verschiedener Abteilungen durchgeführt wurde. Gleichzeitig erklärte ihnen der Berater die Grundprinzipien von IDEF0 und brachte ihnen in relativ kurzer Zeit den Umgang mit der entsprechenden Anwendungssoftware bei. Als Ergebnis erstellten Mitarbeiter verschiedener Abteilungen IDEF-Diagramme der Aktivitäten ihrer Funktionseinheit, die folgende Fragen beantworten sollten:

Was erhält die Abteilung als Input?
Welche Funktionen und in welcher Reihenfolge werden innerhalb der Abteilung wahrgenommen?
Wer ist für die Ausführung der einzelnen Funktionen verantwortlich?
Wovon orientiert sich der Darsteller bei der Ausführung der einzelnen Funktionen?
Was ist das Ergebnis der Arbeit der Abteilung (Output)?

Nachdem die Entwurfsdiagramme innerhalb der einzelnen Abteilungen vereinbart wurden, werden sie vom Berater zu einem Entwurfsmodell des Unternehmens zusammengesetzt, das alle Input- und Output-Elemente verknüpft. In dieser Phase werden alle Abweichungen in einzelnen Diagrammen und deren umstrittene Bereiche erfasst. Anschließend durchläuft dieses Modell erneut die Fachabteilungen zur weiteren Abstimmung und Vornahme der notwendigen Anpassungen. Dadurch wird in relativ kurzer Zeit und unter Einbeziehung eines Minimums an Personalressourcen des Beratungsunternehmens (und diese Ressourcen sind, wie wir wissen, sehr teuer) ein IDEF0-Modell des Unternehmens auf der Grundlage „As“ erstellt ist“-Prinzip, und, was wichtig ist, es repräsentiert das Unternehmen mit Positionen von Mitarbeitern, die darin arbeiten und alle Nuancen, auch informelle, genau kennen. Zukünftig wird dieses Modell zur Analyse und Verarbeitung an Business-Analysten übergeben, die nach „Engpässen“ in der Unternehmensführung suchen und die Hauptprozesse optimieren und das „As Is“-Modell in das entsprechende „As It Should“ umwandeln Sei“-Darstellung. Auf Basis dieser Änderungen wird ein abschließendes Fazit erstellt, das Empfehlungen zur Neuorganisation des Managementsystems enthält.

Natürlich erfordert ein solches Vorgehen eine Reihe organisatorischer Maßnahmen, vor allem seitens der Geschäftsführung des befragten Unternehmens. Dies ist auf die Tatsache zurückzuführen, dass bei dieser Technik einigen Mitarbeitern zusätzliche Verantwortlichkeiten zugewiesen werden, um neue Methoden zu beherrschen und praktisch anzuwenden. Letztendlich rechtfertigt sich dies jedoch, da ein oder zwei zusätzliche Arbeitsstunden einzelner Mitarbeiter über mehrere Tage hinweg die Kosten für Beratungsleistungen bei einem Drittunternehmen erheblich einsparen können (was in jedem Fall dieselben Mitarbeiter ablenken wird). aus der Arbeit mit Fragebögen und Fragen). Was die Mitarbeiter des Unternehmens selbst betrifft, so habe ich in meiner Praxis nie ausdrücklichen Widerstand von ihnen erlebt.

Das Fazit aus all dem lässt sich wie folgt ziehen: Es ist keineswegs notwendig, jedes Mal selbst Lösungen für Standardprobleme zu finden. Wann immer Sie vor der Notwendigkeit stehen, ein bestimmtes Funktionssystem zu analysieren (vom Designsystem eines Raumschiffs bis zum Prozess der Zubereitung eines komplexen Abendessens), nutzen Sie Methoden, die sich im Laufe der Jahre bewährt und getestet haben. Eine dieser Methoden ist IDEF0, mit der Sie mithilfe einfacher und verständlicher Werkzeuge komplexe Lebensprobleme lösen können.

In der Anfangsphase der Erstellung eines IS ist es notwendig zu verstehen, wie die Organisation funktioniert, die automatisiert werden soll. Niemand in der Organisation weiß, wie es im Detail funktioniert, das zur Erstellung des IP erforderlich ist. Der Manager kennt die Arbeit als Ganzes gut, ist jedoch nicht in der Lage, sich mit den Details der Arbeit jedes einzelnen Mitarbeiters zu befassen. Ein normaler Mitarbeiter weiß genau, was an seinem Arbeitsplatz vor sich geht, weiß aber nicht, wie seine Kollegen arbeiten. Um den Betrieb eines Unternehmens zu beschreiben, ist es daher notwendig, ein Modell zu erstellen. Ein solches Modell muss dem Fachgebiet angemessen sein und daher das Wissen aller an den Geschäftsprozessen der Organisation Beteiligten enthalten.

Die bequemste Sprache zur Modellierung von Geschäftsprozessen ist IDEF0, die vor mehr als 20 Jahren von Douglas Ross (SoftTech, Inc.) vorgeschlagen wurde und ursprünglich SADT (Structured Analysis and Design Technique) hieß. (In den frühen 1970er Jahren nutzte das US-Militär die Prozessmodellierungsteilmenge von SADT, um Projekte im Rahmen des Integrated Computer-Aided Manufacturing (ICAM)-Programms umzusetzen. Diese Teilmenge von SADT wurde später als US-Bundesstandard unter dem Namen IDEF0 übernommen. Detaillierte Spezifikationen Informationen zu IDEF-Standards finden Sie unter http://www.idef.com.

In IDEF0 wird ein System als eine Sammlung interagierender Aktivitäten oder Funktionen dargestellt. Diese rein funktionale Ausrichtung ist grundlegend – die Funktionen des Systems werden unabhängig von den Objekten analysiert, mit denen sie operieren. Dadurch können Sie die Logik und Interaktion der Prozesse der Organisation klarer modellieren.

Unter einem Modell versteht man in IDEF0 eine Beschreibung eines Systems (textlich und grafisch), die einige vorgegebene Fragen beantworten soll.

Das simulierte System wird als eine beliebige Teilmenge des Universums betrachtet. Es ist willkürlich, weil wir erstens selbst spekulativ bestimmen, ob ein bestimmtes Objekt Bestandteil des Systems sein wird oder ob wir es als externen Einfluss betrachten, und zweitens hängt es von der Sichtweise des Systems ab. Das System hat eine Grenze, die es vom Rest des Universums trennt. Die Interaktion eines Systems mit der Außenwelt wird als Input (etwas, das vom System verarbeitet wird), Output (das Ergebnis der Aktivitäten des Systems), Kontrolle (die Strategien und Verfahren, nach denen die Arbeit ausgeführt wird) und Mechanismus ( die für die Durchführung der Arbeiten erforderlichen Ressourcen). Unter Kontrolle wandelt das System mithilfe von Mechanismen Eingaben in Ausgaben um.

Der Prozess der Modellierung eines Systems in IDEF0 beginnt mit der Definition des Kontexts, also der abstraktesten Beschreibungsebene des Systems als Ganzes. Der Kontext umfasst die Definition des Modellierungsgegenstandes, den Zweck und die Sichtweise des Modells.

Das Subjekt wird als das System selbst verstanden, und es ist notwendig, genau festzulegen, was in das System einbezogen ist und was außerhalb davon liegt, mit anderen Worten, wir müssen bestimmen, was wir weiterhin als Komponenten des Systems betrachten und was als Äußerer Einfluss. Die Definition des Subjekts des Systems wird maßgeblich von der Position, aus der das System betrachtet wird, und dem Zweck der Modellierung beeinflusst – Fragen, die das konstruierte Modell beantworten soll. Mit anderen Worten: Zunächst muss der Umfang der Modellierung festgelegt werden. Eine Beschreibung des Bereichs sowohl des Systems als Ganzes als auch seiner Komponenten ist die Grundlage für die Konstruktion eines Modells. Obwohl davon ausgegangen wird, dass der Umfang im Laufe der Simulation angepasst werden kann, muss er grundsätzlich zunächst formuliert werden, da es der Umfang ist, der die Richtung der Simulation bestimmt und wann das Modell fertiggestellt werden soll. Bei der Formulierung eines Umfangs sind zwei Komponenten zu berücksichtigen: Breite und Tiefe. Bei der Breite geht es darum, die Grenzen des Modells zu definieren – wir bestimmen, was innerhalb des Systems und was außerhalb berücksichtigt wird. Die Tiefe bestimmt, mit welchem Detaillierungsgrad das Modell vollständig ist. Bei der Bestimmung der Tiefe des Systems dürfen die zeitlichen Einschränkungen nicht vergessen werden – die Komplexität des Aufbaus eines Modells wächst exponentiell mit der Tiefe der Zerlegung. Sobald die Grenzen des Modells definiert sind, wird davon ausgegangen, dass keine neuen Objekte in das modellierte System eingeführt werden sollten; Da alle Modellobjekte miteinander verbunden sind, kann die Einführung eines neuen Objekts nicht nur eine arithmetische Addition sein, sondern auch bestehende Beziehungen verändern. Solche Änderungen an einem fertigen Modell vorzunehmen ist in der Regel ein sehr arbeitsintensiver Prozess (das sogenannte „Floating Region“-Problem).

Modellierungszweck. Ohne ein klar definiertes Ziel kann kein Modell erstellt werden. Das Ziel sollte folgende Fragen beantworten:

Warum sollte dieser Prozess modelliert werden?

Was soll das Model zeigen?

Was kann der Leser bekommen?

Durch die Formulierung eines Ziels kann das Analyseteam seine Bemühungen in die richtige Richtung lenken. Beispiele für Zielaussagen sind die folgenden Aussagen: „Identifizieren und definieren Sie aktuelle Probleme, ermöglichen Sie die Analyse potenzieller Verbesserungen“, „Identifizieren Sie die Rollen und Verantwortlichkeiten von Mitarbeitern für das Verfassen von Stellenbeschreibungen“, „Beschreiben Sie die Funktionalität des Unternehmens zum Zweck des Verfassens von Informationen.“ Systemspezifikationen“ usw.

Standpunkt. Obwohl beim Erstellen eines Modells die Ansichten verschiedener Personen berücksichtigt werden, muss das Modell aus einer einzigen Perspektive erstellt werden. Ein Standpunkt kann als die Sicht einer Person dargestellt werden, die das System in dem für die Modellierung erforderlichen Aspekt sieht. Der Standpunkt muss dem Zweck der Modellierung entsprechen. Offensichtlich wird die Beschreibung der Arbeit des Unternehmens aus der Sicht eines Finanziers und eines Technologen völlig unterschiedlich aussehen, daher ist es wichtig, bei der Modellierung beim gewählten Standpunkt zu bleiben. In der Regel wird die Sichtweise des Verantwortlichen für die simulierte Arbeit als Ganzes gewählt. Bei der Auswahl einer Perspektive auf ein Modell ist es oft wichtig, zusätzliche alternative Perspektiven zu dokumentieren. Zu diesem Zweck werden üblicherweise FEO-Diagramme (For Exposure Only) verwendet.

Das IDEF0-Modell geht von einem klar formulierten Ziel, einem einzigen Modellierungsgegenstand und einem einzigen Standpunkt aus. Um Umfang, Zweck und Standpunkt zu IDEF0-Modellen in BPwin hinzuzufügen, wählen Sie den Menüpunkt aus Bearbeiten/Modelleigenschaften, wodurch das Dialogfeld „Modelleigenschaften“ angezeigt wird (Abb. 4). Mit Lesezeichen versehen Zweck Sie sollten ein Ziel, einen Standpunkt und ein Lesezeichen hinzufügen Definition- Definition des Modells und Beschreibung des Gebiets.

Mit Lesezeichen versehen Status Im selben Dialog können Sie den Status des Modells (Entwurf, Arbeit, endgültig usw.), den Zeitpunkt der Erstellung und die letzte Bearbeitung (später automatisch durch das Systemdatum nachverfolgt) beschreiben. Mit Lesezeichen versehen Quelle Die Informationsquellen für die Erstellung des Modells werden beschrieben (z. B. „Befragung von Fachexperten und Analyse der Dokumentation“). Lesezeichen Allgemein dient der Eingabe des Projekt- und Modellnamens, des Namens und der Initialen des Autors sowie des Zeitrahmens des Modells - WIE ES IST Und TO-VE.

Reis. 4. Dialog zum Festlegen von Modelleigenschaften

Modelle AS-IS und TO-BE. Normalerweise wird zunächst ein Modell der bestehenden Arbeitsorganisation erstellt – so wie sie ist. Basierend auf dem AS-IS-Modell wird zwischen den verschiedenen Geschäftseinheiten ein Konsens darüber erzielt, „wer was getan hat“ und was jede Geschäftseinheit zum Prozess beiträgt. Das AS-IS-Modell ermöglicht es uns herauszufinden, „was wir heute tun“, bevor wir zu „was wir morgen tun werden“ übergehen. Durch die Analyse des Funktionsmodells können Sie verstehen, wo die Schwachstellen liegen, welche Vorteile neue Geschäftsprozesse mit sich bringen und wie tiefgreifende Veränderungen die bestehende Struktur der Unternehmensorganisation erfahren wird. Durch die Detaillierung von Geschäftsprozessen können Sie Mängel der Organisation erkennen, selbst wenn die Funktionalität auf den ersten Blick offensichtlich erscheint. Anzeichen einer ineffektiven Aktivität können nutzlose, nicht verwaltete und doppelte Arbeit, ineffektiver Dokumentenfluss (das richtige Dokument ist nicht zur richtigen Zeit am richtigen Ort), mangelndes Feedback zum Management (die Arbeit wird durch ihr Ergebnis nicht beeinflusst), Input ( Objekte oder Informationen werden irrational verwendet) usw. Die im AS-IS-Modell festgestellten Mängel können bei der Erstellung des TO-BE-Modells (wie es sein wird) – einem Modell einer neuen Organisation von Geschäftsprozessen – behoben werden. Der TO-BE benötigt das Modell, um alternative/bessere Arbeitsweisen zu analysieren und zu dokumentieren, wie das Unternehmen in Zukunft Geschäfte abwickeln wird.

Ein häufiger Fehler, auf den man bei der Erstellung eines AS-IS-Modells hinweisen sollte, ist die Erstellung eines idealisierten Modells. Ein Beispiel wäre die Erstellung eines Modells, das auf dem Wissen des Managers und nicht auf einem bestimmten Arbeitsausführer basiert. Der Vorgesetzte weiß, wie die Arbeit gemäß Handbüchern und Stellenbeschreibungen zu erledigen ist, und weiß oft nicht, wie Untergebene Routinearbeiten tatsächlich ausführen. Das Ergebnis ist ein geschöntes, verzerrtes Modell, das falsche Informationen enthält und nicht für weitere Analysen verwendet werden kann. Dieses Modell heißt SHOULD_BE (wie es sein sollte).

Bei der IS-Design-Technologie geht es darum, zunächst ein AS-IS-Modell zu erstellen, es zu analysieren und Geschäftsprozesse zu verbessern, also ein TO-BE-Modell zu erstellen, und erst auf der Grundlage des TO-BE-Modells entsteht ein Datenmodell, ein Prototyp und dann die endgültige Version des IS gebaut. Der Aufbau eines Systems auf Basis des AS-IS-Modells führt zur Automatisierung des Unternehmens nach dem Prinzip „Alles so zu lassen, wie es ist, nur um die Computer am Laufen zu halten“, d. h. IS automatisiert unvollständige Geschäftsprozesse und dupliziert vorhandene Dokumente, anstatt sie zu ersetzen fließen. Die Implementierung und der Betrieb eines solchen Systems verursachen daher lediglich zusätzliche Kosten für die Anschaffung von Geräten, die Erstellung von Software und die Wartung beider.

Mitunter sind die aktuellen AS-IS- und künftigen TO-BE-Modelle sehr unterschiedlich, sodass der Übergang vom Anfangs- zum Endzustand nicht offensichtlich ist. In diesem Fall ist ein drittes Modell erforderlich, um den Übergangsprozess vom Anfangs- zum Endzustand des Systems zu beschreiben, da es sich bei einem solchen Übergang ebenfalls um einen Geschäftsprozess handelt.

Das Ergebnis der Modellbeschreibung kann dem Bericht entnommen werden Modellbericht. Über den Menüpunkt wird der Einstellungsdialog für den Modellbericht aufgerufen Bericht/Modellbericht. Im Einstellungsdialog sollten Sie die erforderlichen Felder auswählen und die Reihenfolge, in der die Informationen an den Bericht ausgegeben werden, wird automatisch angezeigt (Abb. 5).

Reis. 5. Modellbericht

IDEF0-Diagramme. Die IDEF0-Methodik basiert auf einer grafischen Sprache zur Beschreibung von Geschäftsprozessen. Ein Modell in IDEF0-Notation ist eine Sammlung hierarchisch geordneter und miteinander verbundener Diagramme. Jedes Diagramm stellt eine Beschreibungseinheit des Systems dar und befindet sich auf einem separaten Blatt.

Das Modell kann vier Arten von Diagrammen enthalten:

Kontextdiagramm (jedes Modell kann nur ein Kontextdiagramm haben);

Zerlegungsdiagramme;

Knotenbaumdiagramme;

Exposure-only-Diagramme (FEO).

Das Kontextdiagramm steht an der Spitze der Baumstruktur von Diagrammen und stellt die allgemeinste Beschreibung des Systems und seiner Interaktion mit der externen Umgebung dar. Nachdem das System als Ganzes beschrieben wurde, wird es in große Fragmente unterteilt. Dieser Vorgang wird als funktionale Zerlegung bezeichnet, und die Diagramme, die jedes Fragment und die Interaktion der Fragmente beschreiben, werden als Zerlegungsdiagramme bezeichnet. Nach der Zerlegung des Kontextdiagramms wird jedes große Fragment des Systems in kleinere zerlegt usw., bis der gewünschte Detaillierungsgrad der Beschreibung erreicht ist. Nach jeder Zerlegungssitzung werden Prüfungssitzungen durchgeführt – Fachexperten zeigen die Übereinstimmung realer Geschäftsprozesse mit den erstellten Diagrammen an. Eventuell festgestellte Unstimmigkeiten werden korrigiert und erst nach bestandener Prüfung ohne Kommentar kann mit der nächsten Zerlegungssitzung begonnen werden. Dadurch wird sichergestellt, dass das Modell auf jeder Ebene des Modells mit realen Geschäftsprozessen übereinstimmt. Die Syntax zur Beschreibung des Systems als Ganzes und jedes seiner Fragmente ist im gesamten Modell gleich.

Ein Knotenbaumdiagramm zeigt die hierarchische Abhängigkeit von Aktivitäten, nicht jedoch die Beziehungen zwischen Aktivitäten. Das Modell kann beliebig viele Knotenbaumdiagramme enthalten, da der Baum bis zu einer beliebigen Tiefe und nicht unbedingt von der Wurzel aus aufgebaut werden kann.

Belichtungsdiagramme (FEO) werden zur Veranschaulichung von Teilen eines Modells, zur Veranschaulichung einer alternativen Sichtweise oder für spezielle Zwecke erstellt.

Ein Beispiel für die Erstellung eines Funktionsmodells.

Als Beispiel werden die Aktivitäten des fiktiven Unternehmens „Computer Word“ betrachtet. Das Unternehmen montiert und verkauft hauptsächlich Desktop-Computer und Laptops. Das Unternehmen stellt selbst keine Komponenten her, sondern montiert und testet lediglich Computer.

Die Haupttätigkeitsarten im Unternehmen sind folgende:

Verkäufer nehmen Kundenbestellungen entgegen;

Bediener gruppieren Bestellungen nach Computertyp;

Bediener montieren und testen Computer;

Bediener verpacken Computer gemäß den Anweisungen;

Der Ladenbesitzer versendet Bestellungen an Kunden.

Das Unternehmen nutzt ein lizenziertes Buchhaltungsinformationssystem, das es Ihnen ermöglicht, eine Bestellung aufzugeben, eine Rechnung auszustellen und Rechnungszahlungen zu verfolgen.

Methode zur Ausführung der Arbeit

1. Führen Sie BPwin() aus.

2. Wenn ein Dialog erscheint ModelMart-Verbindungsmanager, klicken Sie auf die Schaltfläche Stornieren(Stornieren).

3. Klicken Sie auf die Schaltfläche. Es erscheint ein Dialogfeld Ich möchte(Abb. 6). Geben Sie Text in das Feld ein Name Modellname „Unternehmensaktivität“ und wählen Sie Typ – Geschäftsprozess (IDEF0). Drück den Knopf OK.

Reis. 6. Benennen des Modells und Auswahl des Modelltyps

4. Ein Dialogfeld wird geöffnet Eigenschaften für neue Modelle(Eigenschaften des neuen Modells) (Abb. 7). Geben Sie in das Textfeld ein Autor(Autor) Name des Autors des Modells und im Textfeld Initialen des Autors seine Initialen. Drücken Sie die Tasten nacheinander Anwenden Und OK.

5. Es wird automatisch ein leeres Kontextdiagramm erstellt (Abb. 8).

6. Beachten Sie die Schaltfläche in der Symbolleiste. Mit dieser Schaltfläche können Sie das Browsing- und Navigationstool ein- und ausschalten. Modell-Explorer(Modellbrowser). Modell-Explorer hat drei Registerkarten - Aktivitäten (), Diagramme() Und Objekte(). In der Registerkarte Aktivitäten Wenn Sie im Modellbrowser mit der rechten Maustaste auf ein Objekt klicken, können Sie Optionen zum Bearbeiten seiner Eigenschaften auswählen (Abb. 9).

Reis. 8. Leeres Kontextdiagramm

Reis. 9. Wenn Sie auf der Registerkarte „Aktivitäten“ mit der rechten Maustaste auf ein Objekt klicken, können Sie dessen Eigenschaften über das Kontextmenü bearbeiten

7. Gehen Sie zum Menü Modell/Modelleigenschaften. In der Registerkarte Allgemein Dialogbox Modelleigenschaften zum Textfeld Modellname Sie sollten den Namen des Modells „Unternehmensaktivitäten“ eingeben und in das Textfeld eingeben Projekt der Name des Projekts „Modell der Unternehmensaktivitäten“ und schließlich im Text Zeitfenster(Zeitabdeckung) - WIE ES IST(Wie es ist) (Abb. 10).

Reis. 10. Fenster zum Festlegen von Modelleigenschaften

8. Auf der Registerkarte Zweck Dialogbox Modelleigenschaften zum Textfeld Zweck(Ziel) Geben Sie Daten über den Zweck der Modellentwicklung ein – „Modellierung aktueller (AS-IS) Geschäftsprozesse des Unternehmens“ und in das Textfeld Standpunkt(Standpunkt) - „Direktor“ (Abb. 11).

Reis. 11. Eingabe von Daten zum Zweck der Modellierung und zum Standpunkt

9. Auf der Registerkarte Definition Dialogbox Modelleigenschaften zum Textfeld Definition(Definition) Geben Sie in das Textfeld „Dies ist ein Schulungsmodell, das die Aktivitäten eines Unternehmens beschreibt“ ein Umfang(Berichterstattung) – „Allgemeine Führung des Unternehmens: Marktforschung, Beschaffung von Komponenten, Montage, Prüfung und Verkauf von Produkten“ (Abb. 12).

10. Gehen Sie zum Kontextdiagramm und klicken Sie mit der rechten Maustaste auf das Rechteck, das in der Notation dargestellt ist IDEF0, herkömmliche grafische Bezeichnung der Arbeit. Wählen Sie im Kontextmenü die Option aus Name(Abb. 13). In der Registerkarte Name Geben Sie den Namen „Unternehmensaktivitäten“ ein (Abb. 14).

11. Auf der Registerkarte Definition Dialogbox Aktivitätseigenschaften zum Textfeld Definition(Definition) Geben Sie „Aktuelle Geschäftsprozesse des Unternehmens“ ein (Abb. 15). Textfeld Notiz(Notizen) leer lassen.

Reis. 12. Eingabe zusätzlicher Daten zur Definition des Modells

Reis. 13. Kontextmenü zum Arbeiten mit der ausgewählten Namensoption

Reis. 14. Benennung der Arbeit

Reis. 15. Eingabe zusätzlicher Daten zum Werk

12. Erstellen I COM-Pfeile im Kontextdiagramm (Tabelle 1).

Tabelle 1 – Pfeile des Kontextdiagramms

Pfeilname (PfeilName)	Pfeildefinition (PfeilDefinition)	Pfeiltyp (PfeilTyp)
Kundenanrufe	Informationsanfragen, Bestellungen, technischer Support usw.
Regeln und Verfahren	Verkaufsregeln, Montageanleitungen, Prüfverfahren, Leistungskriterien usw.
Verkaufte Produkte	Desktops und Laptops
Abrechnungssystem	Erstellung von Rechnungen, Bezahlung von Rechnungen, Bearbeitung von Bestellungen

13. Geben Sie über die Schaltfläche Text in das Diagrammfeld ein – Standpunkt und Ziel (Abb. 16).

Reis. 16. Eingeben von Text in ein Diagrammfeld mit dem Textblock-Editor

14. Erstellen Sie einen Bericht über das Modell. Auf der Speisekarte Tools/Berichte/Modellbericht(Abb. 17) Legen Sie die Optionen für die Berichterstellung fest (aktivieren Sie die Kontrollkästchen) und klicken Sie auf die Schaltfläche Vorschau(Vorschau) (Abbildung 18).

Reis. 17. Einstellungsoptionen für die Erstellung eines Modellberichts

Reis. 18. Vorschau des Modellberichts

Zerlegung von Produktionsprozessen nach MethodikIDEF0

Werke (Aktivität)

Aktivitäten beziehen sich auf benannte Prozesse, Funktionen oder Aufgaben, die über einen bestimmten Zeitraum ablaufen und erkennbare Ergebnisse haben. Werke werden als Rechtecke dargestellt. Alle Werke müssen benannt und definiert werden. Der Name des Werks muss als Verbalsubstantiv ausgedrückt werden, das die Aktion bezeichnet (z. B. „Ein Teil herstellen“, „Eine Bestellung entgegennehmen“ usw.). Die Arbeit „Herstellung eines Teils“ kann beispielsweise die folgende Definition haben: „Die Arbeit bezieht sich auf den gesamten Herstellungszyklus eines Produkts von der Qualitätskontrolle der Rohstoffe bis zum Versand des fertig verpackten Produkts.“ Beim Erstellen eines neuen Modells (Menü Datei/Neu) wird automatisch ein Kontextdiagramm mit einem einzelnen Werk erstellt, das das System als Ganzes darstellt (Abb. 1).

Um einen Jobnamen einzugeben, klicken Sie mit der rechten Maustaste auf den Job und wählen Sie aus dem Menü aus Namenseditor und geben Sie im erscheinenden Dialog den Namen des Werkes ein. Um andere Eigenschaften des Werkes zu beschreiben, nutzen Sie den Dialog Aktivitätseigenschaften(Abb. 2).

Reis. 1. Beispiel eines Kontextdiagramms

Reis. 2. Editor zum Festlegen von Jobeigenschaften

Zerlegungsdiagramme enthalten verwandte Arbeiten, d. h. untergeordnete Jobs, die einen gemeinsamen übergeordneten Job haben. Um ein Zerlegungsdiagramm zu erstellen, klicken Sie auf die Schaltfläche.

Es entsteht ein Dialog Anzahl der Aktivitätsboxen(Abb. 3), in dem Sie die Notation des neuen Diagramms und die Anzahl der Arbeiten darauf angeben sollten. Wählen wir eine Notation IDEF0 und klicken Sie auf OK. Es erscheint ein Zerlegungsdiagramm (Abb. 4). Der akzeptable Bereich für die Anzahl der Jobs liegt zwischen 2 und 8. Es macht keinen Sinn, Arbeit in eine Aufgabe zu zerlegen: Diagramme mit mehr als acht Aufgaben erweisen sich als übersättigt und schwer lesbar. Um Klarheit und ein besseres Verständnis der simulierten Prozesse zu gewährleisten, wird empfohlen, drei bis sechs Blöcke in einem Diagramm zu verwenden.

Reis. 3. DialogAnzahl der Aktivitätsboxen

Reis. 4. Beispiel eines Zerlegungsdiagramms

Sollte sich herausstellen, dass die Anzahl der Werke nicht ausreicht, kann das Werk zum Diagramm hinzugefügt werden, indem man zunächst auf die Schaltfläche in der Werkzeugpalette und dann auf eine leere Stelle im Diagramm klickt.

Aktivitäten in Aufschlüsselungsdiagrammen sind normalerweise diagonal von links oben nach rechts unten angeordnet.

Diese Ordnung wird Dominanzordnung genannt. Nach diesem Anordnungsprinzip befindet sich in der oberen linken Ecke die wichtigste bzw. zeitlich zuerst erledigte Arbeit. Weiter unten rechts sind weniger wichtige oder spätere Aufgaben aufgeführt. Diese Anordnung erleichtert die Lesbarkeit der Diagramme und das darauf aufbauende Konzept der Arbeitsbeziehungen.

Jede der Aktivitäten im Zerlegungsdiagramm kann der Reihe nach zerlegt werden. In einem Aufschlüsselungsdiagramm werden die Arbeiten automatisch von links nach rechts nummeriert. Die Auftragsnummer wird in der unteren rechten Ecke angezeigt. In der oberen linken Ecke befindet sich eine kleine diagonale Linie, die darauf hinweist, dass dieses Werk nicht zerlegt wurde. So hat beispielsweise die Arbeit „Zusammenbau eines Produkts“ die Nummer 3 und wurde noch nicht zerlegt. Die Arbeit „Qualitätskontrolle“ (Nummer 4) weist einen geringeren Zersetzungsgrad auf

Pfeile

Die Interaktion der Werke mit der Außenwelt und untereinander wird in Form von Pfeilen beschrieben. Pfeile stellen einige Informationen dar und werden als Substantive bezeichnet (z. B. „Produkt“, „Produkt“, „Bestellung“).

In IDEF0 gibt es fünf Arten von Pfeilen:

Eingang- Material oder Informationen, die durch Arbeit verwendet oder umgewandelt werden, um ein Ergebnis (Output) zu erzielen. Es ist zulässig, dass das Werk keinen einzigen Eintragspfeil hat. Jeder Pfeiltyp nähert sich einer bestimmten Seite des das Werk darstellenden Rechtecks oder verlässt diese. Der Eintrittspfeil wird so gezeichnet, dass er am linken Rand des Werks eintritt. Bei der Beschreibung technologischer Prozesse (daher wurde IDEF0 erfunden) gibt es keine Probleme, Eingaben zu identifizieren. Tatsächlich sind „Rohstoffe“ in Abb. 1. ist etwas, das während des „Produktherstellungsprozesses“ verarbeitet wird, um ein Ergebnis zu erzielen. Bei der Modellierung einer IP ist nicht alles so offensichtlich, wenn es sich bei den Pfeilen nicht um physische Objekte, sondern um Daten handelt. Beispielsweise kann bei einem „Patientenempfang“ die Karte des Patienten sowohl am Eingang als auch am Ausgang liegen, wobei sich die Qualität dieser Daten ändert. Mit anderen Worten: Um den Zweck zu rechtfertigen, müssen in diesem Beispiel die Eingabe- und Ausgabepfeile genau definiert sein, um anzuzeigen, dass die Daten tatsächlich verarbeitet wurden (z. B. lautet die Ausgabe „Abgeschlossene Patientenakte“). Es ist oft schwierig zu bestimmen, ob es sich bei den Daten um Eingabe- oder Kontrolldaten handelt. Ein Anhaltspunkt kann in diesem Fall sein, ob die Daten im Werk verarbeitet/verändert werden oder nicht. Wenn sie sich ändern, handelt es sich höchstwahrscheinlich um eine Eingabe; wenn nicht, handelt es sich um Kontrolle.

Kontrolle- Regeln, Richtlinien, Verfahren oder Standards, die die Arbeit leiten. Jeder Job muss mindestens einen Kontrollpfeil haben. Der Kontrollpfeil wird so gezeichnet, dass er in die Oberkante des Werkstücks eintritt. In Abb. 1 Pfeile „Aufgabe“ und „Zeichnung“ – Steuerung für die Arbeit „Herstellung eines Produkts“. Das Management beeinflusst die Arbeit, wird aber durch die Arbeit nicht verändert. Wenn das Ziel eines Jobs darin besteht, ein Verfahren oder eine Strategie zu ändern, dann ist dieses Verfahren oder diese Strategie der Input für den Job. Wenn der Status eines Pfeils (Kontrolle oder Eingabe) unsicher ist, wird empfohlen, einen Kontrollpfeil zu zeichnen.

Ausgabe- das Material oder die Informationen, die durch die Arbeit erzeugt werden. Jeder Job muss mindestens einen Exit-Pfeil haben. Arbeit ohne Ergebnisse hat keinen Sinn und sollte nicht modelliert werden. Der Ausgangspfeil wird so gezeichnet, dass er vom rechten Rand des Werks ausgeht. In Abb. 1 Pfeil „Fertigprodukt“ ist die Ausgabe für die Arbeit „Produktherstellung“.

Mechanismus- Ressourcen, die die Arbeit ausführen, zum Beispiel Unternehmenspersonal, Maschinen, Geräte usw. Der Mechanismuspfeil ist am unteren Rand der Arbeit eingezeichnet. In Abb. 1 Pfeil „Unternehmenspersonal“ ist ein Mechanismus für die Arbeit „Produktherstellung“. Es liegt im Ermessen des Analysten, die Pfeile des Mechanismus möglicherweise nicht im Modell darzustellen.

Anruf- ein spezieller Pfeil, der auf ein anderes Betriebsmodell hinweist. Der Rufpfeil ist so gezeichnet, dass er vom unteren Rand des Werkes ausgeht. In Abb. 1 Pfeil „Anderes Arbeitsmodell“ ist eine Ausschreibung für die Arbeit „Produktherstellung“. Ein Aufrufpfeil wird verwendet, um anzuzeigen, dass einige Arbeiten außerhalb des modellierten Systems ausgeführt werden. In BPwin werden Aufrufpfeile im Mechanismus zum Zusammenführen und Aufteilen von Modellen verwendet.

Randpfeile. Die Pfeile im Kontextdiagramm dienen zur Beschreibung der Interaktion des Systems mit der Außenwelt. Sie können am Rand des Diagramms beginnen und am Werk enden oder umgekehrt. Solche Pfeile werden Grenzpfeile genannt.

So fügen Sie einen Grenzeingabepfeil hinzu:

Steuerung, Ausgabe, Mechanismus und Ausgabepfeile werden ähnlich dargestellt. Um beispielsweise einen Ausgangspfeil zu zeichnen, klicken Sie auf die Schaltfläche mit dem Pfeilsymbol in der Werkzeugpalette, klicken Sie auf der rechten Seite des Werks auf die Ausgangsseite (wo der Pfeil beginnt) und bewegen Sie den Cursor auf die rechte Seite des Bildschirms, bis die Die erste gestrichelte Linie wird angezeigt. Klicken Sie einmal entlang des gestrichelten Streifens.

Die Namen neu hinzugefügter Pfeile werden automatisch in das Wörterbuch eingetragen ( Pfeilwörterbuch).

ICOM-Codes. Zur detaillierten Darstellung der Arbeiten dient ein Aufschlüsselungsdiagramm. Im Gegensatz zu Modellen, die die Struktur einer Organisation darstellen, stellt die Arbeit am Diagramm der obersten Ebene in IDEF0 keine Kontrolle über die Arbeit darunter dar. Die Arbeit auf der unteren Ebene ist die gleiche wie die Arbeit auf der oberen Ebene, jedoch detaillierter. Folglich sind die Grenzen einer Arbeit der obersten Ebene dieselben wie die Grenzen eines Zerlegungsdiagramms. I COM(Abkürzung für Eingabe, Steuerung, Ausgabe und Mechanismus) – Codes zur Identifizierung von Grenzpfeilen. Code I COM enthält ein Präfix, das dem Pfeiltyp entspricht ( ICH,MIT,UM oder M) und Seriennummer. BPwin trägt ICOM-Codes automatisch ein. Um ICOM-Codes anzuzeigen, aktivieren Sie auf der Registerkarte die Option ICOM-Codes anzeigen Präsentation Dialog Modelleigenschaften.

Das Pfeilwörterbuch wird mit einem speziellen Editor bearbeitet Pfeil-Wörterbuch-Editor, in dem der Pfeil definiert und ein dazugehöriger Kommentar eingetragen wird (Abb. 6). Das Pfeilwörterbuch löst ein sehr wichtiges Problem. Diagramme werden von einem Analytiker erstellt, um eine Untersuchungssitzung durchzuführen, d. h. das Diagramm mit einem Fachspezialisten zu besprechen. In jedem Fachgebiet wird Fachjargon gebildet, und sehr oft haben Fachausdrücke eine unklare Bedeutung und werden von verschiedenen Spezialisten unterschiedlich wahrgenommen. Gleichzeitig muss der Analyst – der Autor der Diagramme – die Ausdrücke verwenden, die für Experten am verständlichsten sind. Da formale Definitionen oft schwer zu verstehen sind, ist der Analytiker gezwungen, Fachjargon zu verwenden, und um mehrdeutige Interpretationen zu vermeiden, kann im Pfeilwörterbuch jedem Begriff eine erweiterte und bei Bedarf formale Definition gegeben werden.

Der Inhalt des Pfeilwörterbuchs kann als Bericht ausgedruckt werden (Menü Bericht/Pfeilbericht...) und erhalten dadurch ein erklärendes Wörterbuch der im Modell verwendeten Domänenbegriffe.

Reis. 5. DialogPfeileigenschaften

Reis. 6. Vokabelpfeile

Unverbundener Randpfeil. Bei der Zerlegung eines Werkes erscheinen die hinein- und hinausgehenden Pfeile (mit Ausnahme des Rufpfeils) automatisch im Zerlegungsdiagramm (Migration der Pfeile), berühren das Werk jedoch nicht. Solche Pfeile werden als nicht verknüpft bezeichnet und in BPwin als Syntaxfehler behandelt. Um Eingabe-, Steuer- oder Mechanismuspfeile zu verknüpfen, müssen Sie in den Pfeilbearbeitungsmodus wechseln, auf die Pfeilspitze klicken und auf das entsprechende Arbeitssegment klicken. Um einen Ausgabepfeil zu verknüpfen, müssen Sie in den Pfeilbearbeitungsmodus wechseln, auf das Arbeitsausgabesegment und dann auf den Pfeil klicken.

Innere Pfeile. Um die Werke untereinander zu verbinden, werden interne Pfeile verwendet, d. h. Pfeile, die den Rand des Diagramms nicht berühren, beginnen bei einem Werk und enden bei einem anderen.

Um einen internen Pfeil zu zeichnen, müssen Sie im Pfeilzeichnungsmodus auf ein Segment (z. B. Ausgang) eines Werks und dann auf ein Segment (z. B. Eingang) eines anderen klicken. IDEF0 unterscheidet fünf Arten von Arbeitsbeziehungen.

Output-Input-Kommunikation, wenn der Ausgangspfeil des übergeordneten Werkes (im Folgenden einfach als Ausgang bezeichnet) auf den Eingang des untergeordneten Werkes gerichtet ist.

Steuerkommunikation (Ausgangssteuerung), wenn die Ausgabe einer Operation auf höherer Ebene zur Steuerung der Operation auf niedrigerer Ebene gesendet wird. Die Managementkommunikation zeigt die Dominanz der übergeordneten Arbeit. Die Daten bzw. Ausgabeobjekte der übergeordneten Arbeit werden in der untergeordneten Arbeit nicht verändert.

Output-Input-Feedback, wenn die Ausgabe eines Werks einer niedrigeren Ebene an die Eingabe eines Werks einer höheren Ebene gesendet wird. Eine solche Beziehung wird üblicherweise zur Beschreibung von Zyklen verwendet.

Rückmeldung zur Ausgangssteuerung, wenn die Ausgabe einer Operation auf niedrigerer Ebene an die Steuerung einer Operation auf höherer Ebene gesendet wird. Management-Feedback zeigt häufig die Wirksamkeit eines Geschäftsprozesses an.

Verbindung zwischen Ausgabemechanismus und Ausgabemechanismus, wenn die Ausgabe eines Jobs an den Mechanismus eines anderen gesendet wird. Diese Beziehung wird seltener verwendet als andere und zeigt, dass eine Aktivität die Ressourcen vorbereitet, die für die Ausführung einer anderen Aktivität erforderlich sind.

Explizite Pfeile. Ein expliziter Pfeil hat einen einzelnen Job als Quelle und einen einzelnen Job als Ziel.

Verzweigende und verschmelzende Pfeile. Dieselben Daten oder Objekte, die von einem Job generiert wurden, können in mehreren anderen Jobs gleichzeitig verwendet werden. Andererseits können in verschiedenen Werken erzeugte Pfeile gleiche oder homogene Daten oder Objekte darstellen, die an einem Ort weiterverwendet oder verarbeitet werden. Um solche Situationen zu modellieren, verwendet IDEF0 Verzweigungs- und Zusammenführungspfeile. Um einen Pfeil zu verzweigen, klicken Sie im Pfeilbearbeitungsmodus auf das Pfeilfragment und auf den entsprechenden Arbeitsabschnitt. Um zwei Ausgangspfeile zusammenzuführen, klicken Sie im Pfeilbearbeitungsmodus zunächst auf das Arbeitsausgangssegment und dann auf das entsprechende Pfeilfragment.

Die Bedeutung sich verzweigender und verschmelzender Pfeile wird durch die Benennung der einzelnen Zweige der Pfeile deutlich. Für die Benennung solcher Pfeile gelten bestimmte Regeln. Schauen wir sie uns am Beispiel verzweigter Pfeile an. Wenn ein Pfeil vor dem Zweig benannt wird, nach dem Zweig jedoch keine Zweige benannt werden, wird davon ausgegangen, dass jeder Zweig dieselben Daten oder Objekte modelliert wie der Zweig vor dem Zweig.

Wenn ein Pfeil vor einem Zweig benannt ist, nach dem Zweig aber keiner der Zweige benannt ist, wird davon ausgegangen, dass diese Zweige mit der Benennung übereinstimmen. Wenn ein Zweig nach dem Zweig unbenannt bleibt, wird davon ausgegangen, dass er dieselben Daten oder Objekte modelliert wie der Zweig vor dem Zweig.

Die Situation ist inakzeptabel, wenn der Pfeil vor dem Zweig nicht benannt wird und nach dem Zweig keiner der Zweige benannt wird. BPwin erkennt einen solchen Pfeil als Syntaxfehler.

Die Regeln für die Benennung verschmelzender Pfeile sind völlig ähnlich – ein Pfeil, der nach der Fusion nicht benannt wurde und einer seiner Zweige vor der Fusion nicht benannt wurde, wird als Fehler betrachtet. Um einen separaten Zweig aus verzweigten und zusammengeführten Pfeilen zu benennen, wählen Sie nur einen Zweig im Diagramm aus, rufen Sie dann den Namenseditor auf und weisen Sie dem Pfeil einen Namen zu. Dieser Name stimmt nur mit dem ausgewählten Zweig überein.

Pfeiltunnelbau. Neu eingeführte Grenzpfeile werden im Zerlegungsdiagramm der unteren Ebene in eckigen Klammern angezeigt und erscheinen nicht automatisch im Diagramm der obersten Ebene.

Um sie nach oben zu „ziehen“, müssen Sie zunächst die Schaltfläche in der Werkzeugpalette auswählen und auf die eckigen Klammern des Rahmenpfeils klicken. Es erscheint ein Dialog Randpfeil-Editor(Abb. 7).

Reis. 7. DialogRandpfeil-Editor

Wenn Sie auf die Schaltfläche klicken LösenGrenzePfeil, wandert der Pfeil zum Diagramm der obersten Ebene, wenn die Schaltfläche „ChangeToTunnel“ verwendet wird – der Pfeil ist getunnelt und landet nicht in einem anderen Diagramm.

Durch Tunnelung können unwichtige Pfeile dargestellt werden. Wenn in einem Diagramm einer niedrigeren Ebene unwichtige Daten oder Objekte dargestellt werden müssen, die von der Arbeit auf der aktuellen Ebene nicht verarbeitet oder verwendet werden, müssen diese an eine höhere Ebene (an das übergeordnete Diagramm) gesendet werden. Wenn diese Daten nicht im übergeordneten Diagramm verwendet werden, müssen sie noch höher gesendet werden usw. Dadurch wird auf allen Ebenen ein unbedeutender Pfeil gezeichnet, der es schwierig macht, alle Diagramme zu lesen, in denen er erscheint. Die Lösung besteht darin, den Pfeil auf der untersten Ebene zu tunneln. Dieses Tunneln wird als „Not-in-Parent-Diagram“ bezeichnet.

Beispiel für die Erstellung eines Zerlegungsdiagramms

1. Wählen Sie in der Werkzeugpalette und im Dialogfeld die Schaltfläche „Ab“ aus Anzahl der Aktivitätsboxen(Abb. 8) Stellen Sie im unteren Diagramm die Anzahl der Jobs ein – 3 – und klicken Sie auf die Schaltfläche OK.

Reis. 8. Dialogfeld „Anzahl der Aktivitätsfelder“.

2. Es wird automatisch ein Zerlegungsdiagramm erstellt (Abb. 9).

Reis. 9. Zersetzungsdiagramm

Klicken Sie mit der rechten Maustaste auf das Werk in der oberen linken Ecke des Modellbearbeitungsbereichs und wählen Sie die Option im Kontextmenü aus Name und geben Sie den Jobnamen ein. Wiederholen Sie den Vorgang für die verbleibenden zwei Jobs. Geben Sie dann die Definition, den Status und die Quelle für jedes Werk ein, wie in Tabelle 1 gezeigt.

Tabelle 1. Arbeiten des A0-Zerlegungsdiagramms

Das Zerlegungsdiagramm wird die in Abb. gezeigte Form annehmen. 10.

Abb. 10 Zerlegungsdiagramm nach der Benennung der Werke

3. Um die Eigenschaften von Jobs zu ändern, nachdem sie in das Diagramm aufgenommen wurden, können Sie das Jobs-Wörterbuch verwenden (Abb. 11). Der Aufruf des Wörterbuchs erfolgt über den Hauptmenüpunkt Wörterbuch/Aktivität.

Reis. 11. WörterbuchAktivitätswörterbuch

Wenn Sie den Namen und die Eigenschaften des Werks im Wörterbuch beschreiben, können Sie es später über eine Schaltfläche in der Werkzeugpalette zum Diagramm hinzufügen. Es ist nicht möglich, ein Werk aus dem Wörterbuch zu entfernen, wenn es in einem Diagramm verwendet wird. Wenn ein Werk aus der Tabelle entfernt wird, wird es nicht aus dem Wörterbuch entfernt. Der Name und die Beschreibung dieser Arbeit dürfen später verwendet werden. Um ein Werk zum Wörterbuch hinzuzufügen, gehen Sie zum Ende der Liste und klicken Sie mit der rechten Maustaste auf die letzte Zeile. Es erscheint eine neue Zeile, in der Sie den Namen und die Eigenschaften des Jobs eingeben müssen. Um alle Jobnamen zu löschen, die nicht im Modell verwendet werden, klicken Sie auf die Schaltfläche ( Säubern(Sauber)).

4. Wechseln Sie in den Pfeilzeichnungsmodus und verknüpfen Sie die Begrenzungspfeile mit der Schaltfläche auf der Werkzeugpalette, wie in Abb. 12.

Reis. 12. Verbundene Grenzpfeile im A0-Diagramm

5. Klicken Sie mit der rechten Maustaste auf den Steuerpfeilzweig der Arbeit „Computer erstellen und testen“ und benennen Sie ihn in „Regeln erstellen und testen“ um (Abb. 13). Geben Sie eine Definition für den neuen Zweig ein: „Build-Anweisungen, Testverfahren, Leistungskriterien usw.“ Klicken Sie mit der rechten Maustaste auf den Pfeilzweig des Arbeitsmechanismus „Vertrieb und Marketing“ und benennen Sie ihn in „Bestellsystem“ um (Abb. 14).

Reis. 13. Pfeil „Regeln erstellen und testen“

Reis. 14. Pfeil „Bestellsystem“

6. Eine alternative Methode zur Eingabe von Namen und Eigenschaften von Pfeilen ist die Verwendung des Pfeilwörterbuchs (rufen Sie das Wörterbuch-Menü auf). Wörterbuch/Pfeil). Wenn Sie den Namen und die Eigenschaften des Pfeils in das Wörterbuch eingeben (Abb. 15), kann er später zum Diagramm hinzugefügt werden.

Reis. 15. Vokabelpfeile

Ein Pfeil kann nicht aus dem Wörterbuch entfernt werden, wenn er in einem Diagramm verwendet wird. Durch das Entfernen eines Pfeils aus einem Diagramm wird dieser nicht aus dem Wörterbuch entfernt. Der Name und die Beschreibung eines solchen Pfeils können später verwendet werden. Um einen Pfeil hinzuzufügen, gehen Sie zum Ende der Liste und klicken Sie mit der rechten Maustaste auf die letzte Zeile. Es erscheint eine neue Zeile, in der Sie den Namen und die Eigenschaften des Pfeils eingeben müssen.

7. Erstellen Sie neue interne Pfeile, wie in Abb. gezeigt. 16.

Reis. 16. Innere Pfeile des A0-Diagramms

8. Erstellen Sie einen (Management-)Feedbackpfeil für Build- und Testergebnisse von der Aktivität „Computer Build and Test“ zur Aktivität „Sales and Marketing“. Ändern Sie bei Bedarf den Pfeilstil (Linienstärke) und stellen Sie die Option ein Zusätzliche Pfeilspitze(Zusätzliche Pfeilspitze) (aus dem Kontextmenü). Methode ziehen und loslassen Verschieben Sie die Namen der Pfeile, damit sie besser lesbar sind. Bei Bedarf über das Kontextmenü installieren Kringel(Zagogulin). Das Ergebnis möglicher Änderungen ist in Abb. dargestellt. 17.

Reis. 17. Ergebnis der Bearbeitung der Pfeile im Diagramm A0

9. Erstellen Sie einen neuen Ausgangsbegrenzungspfeil für Marketingmaterialien, der aus dem Job „Vertrieb und Marketing“ kommt. Dieser Pfeil fällt nicht automatisch in das Diagramm der obersten Ebene und hat an der Spitze eckige Klammern (Abbildung 18).

Reis. 18. Arrow-Marketingmaterialien

10. Klicken Sie mit der rechten Maustaste auf die eckigen Klammern und wählen Sie den Menüpunkt aus Pfeiltunnel(Abb. 19).

Im Dialogfeld Randpfeil-Editor(Grenzpfeil-Editor) Option auswählen Lösen Sie es auf „Grenzpfeil“ auf(Als Grenzpfeil zulassen) (Abb. 20).

Reis. 19. AbsatzSpeisekartePfeiltunnel

Reis. 20. DialogFensterRandpfeil-Editor

Wählen Sie für den Pfeil „Marketingmaterialien“ die Option aus Trimmen(Anordnen) aus dem Kontextmenü. Das Ergebnis der Laborarbeit ist in Abb. dargestellt. 21.

Reis. 21. Ergebnis der Zersetzung

Grundelemente eines IDEF0-Diagramms.

Funktionsmethode IDEF0

Die Wahl des Herausgebers