Geschäftsprozessmodellierung - stivenraso.destivenraso.de/fom/GPM/2017_WS_FOM_GPM.pdf ·...

Stiven Raso | Geschäftsprozessmodellierung 1

Stiven RasoM.A. IT | Dipl. Wirt.-Ing.

Geschäftsprozessmodellierung

B.Sc. Wirtschaftsinformatik

Stiven Raso | Geschäftsprozessmodellierung

1998-2005 Studium Dipl. Wirt.-Ing. / Mittelständisches Unternehmen ca. 250 MA

Diplomarbeit: Analyse von Auftragsabwicklungsprozessen

Mai.-Nov. 2005 Berater Geschäftsprozessanalyse/-optimierung

2005-heute Dr. Glinz COViS GmbH, ca. 60 MA

Mitglied der Geschäftsleitung

Partner | Prokurist

2008-2010 Studium Master IT-Management

2010 SAP Deutschland AG & Co KG, ca. 53.000 MA

Master Thesis: „Combining CRM & social media to grow

the customer life time value of telecommunication customers“

seit 2011 Lehrbeauftragter FOM in Köln, Düsseldorf, Duisburg, Essen, Neuss)

Software Engineering, Projekt- und IT-Management, E-Business,

Geschäftsprozessmanagement, Digitalisierung

seit 2016 Lehrbeauftragter EUFH

Betriebliche IT-Anwendungssysteme

(seit 2016) Lehrbeauftragter FHDW

Methoden im IT-Consulting, E-Commerce, Geschäftsprozesse &

betriebliche Anwendungssysteme, Grundlagen der Wirtschaftsinf.

Stiven Raso

Vorstellung

2


Veranstaltungskomponenten

Seminaristischer Unterricht/Vortrag

Beispiele aus der Unternehmenspraxis zur Verdeutlichung

Übungen/Fallstudien zur Bearbeitung durch die Studenten

Interaktivität: Diskussionen und aktive Beiträge sind erwünscht

Prüfung und Benotung

Klausur im Umfang von 90 Minuten

Kontakt

Bei Fragen: [email protected]

Konzept der Veranstaltung

3


Agenda

Motivation/Grundlagen

Grundlagen Modellierung

Ereignisgesteuerte Prozessketten

UML (ausgewählte Modellierungen)

Business Process Management Notation

Swimlane

4


Modellierungssprachen | Modellierungssichten

Anforderungsdokumentation

Modellierung

5


Repräsentation eines Realitätsausschnitts

Festgelegte Detaillierungstiefe

Abbildung einer bestimmen Perspektive

Momentaufnahme

Zweckorientierung

Die Prozessmodellierung

dient der Gestaltung der Ablauforganisation in Unternehmen

stellt den Kontrollfluss in den Mittelpunkt

zeigt die zeitlich-logische Abfolge der Funktionen (Aktivitäten)

zeigt wir häufig organisatorische Wechsel erfolgen

dient der Identifizierung von Schwachstellen


Modellierung


Dokumentation der Prozesse

Übersichtlichkeit und Verständlichkeit erhöhen

Transparente Darstellung der Beteiligten Ressourcen (Personen und

IT-Systeme)

Prozessorientierte Reorganisation

Basis für kontinuierliche Verbesserungen

Erleichterung bei der Schwachstellenidentifikation (im Sinne der

Zeit-, Mengen und Kostendaten):

Unzureichende Kapazitätsauslastung

Lange Liegezeiten

Personalengpässe

Prozesscontrolling

Erfassung und Abgleich der Soll-Ist Situation der definierten Prozesse


Ziele der Prozessmodellierung (1)


Zertifizierung

Möglichkeit die Prozessdokumentation im Rahmen der Zertifizierung ISO

900x zu nutzen

Bsp. Dokumentation der Herstellungs- und Entwicklungsprozesse

Benchmarking

Vergleich der Performanz mit internen/externen Organisationseinheiten

Wissensmanagement

Basis zur Einarbeitung betrieblicher Sachverhalte (auch Schulungen)

Festigt die im Unternehmen eingesetzten Fachbegriffe

Prozesskostenrechnung

Erfassung der anfallenden Kosten und Leistungen im Rahmen der

Prozessabwicklung

Auswahl ERP-System

Unterstützt die Vorauswahl bei der Einführung möglicher IT-Systeme




Softwareentwicklung

Beschreibt die Anforderungen an ein IT-System bzw. zeigt welche

fachlichen Funktionen IT-seitig abgebildet werden müssen

Hebt wiederverwendbare Komponenten hervor, vermeidet dadurch

Redundanzen im Entwicklungsprozess

Fördert die Testbarkeit der Software und unterstützt die Validierung

Workflow-Management

Dient zur Entscheidungsfindung bzgl. Automatisierung von Abläufe




Diagrammbasierte

Methoden

Datenflussorientiert

IDEF

SSA

SADT

Kontrollfluss-orientiert

Petri-Netze

Swimlane

BPMN

eEPK

Objekt-orientiert

Activity Diagr. (UML)

Use Case Diagr. (UML)

Interaktions-diagr. (SOM)

Vorgangs-ereignis (SOM)

10

Datenflussorientierte

Methoden: Verknüpfung

von Funktionen durch

Datenflüsse

Kontrollflussorientierte

Methoden: Zeitlich

logischer Ablauf von

Funktionen steht im

Vordergrund

Objektorientierte

Methoden: Aufhebung der

Trennung zwischen Daten

und Funktionen durch

Verwendung von Objekten

(Grundlage für

Softwareprogrammierung)

IDEF: Integration Definition for Function Modeling

SSA: Structered Systems Analysis

SADT: Structered Analysis Design Technic

Grafisch orientierte Prozessmodellierung



Quelle: In Anlehnung an Gadatsch

9,500%

2,600%

3,400%

16,400%

21,600%

38,800%

43,100%

,00% 5,00% 10,00% 15,00% 20,00% 25,00% 30,00% 35,00% 40,00% 45,00% 50,00%

SOM

IDEF

Petri-Netze

BPMN

UML

Swimlane

eEPK


Nutzungshäufigkeit der Notationen



Aspekte der Modellierung


Ausprägungs- Ereignistyp Funktionstyp Ereignistyp

ebene

Abstraktions- Ereignis Funktion Ereignisebene

Antragsdaten

erfassen

Antrag

eingetroffen

Antragsdaten

erfasst

Peter Becker aus

Klingenbach hat einen

Kreditantrag

gestellt

Name: Peter

Becker Ort: Klingenbach

Alter: 36

Kredit: 150.000in Datei eintragen

Die Daten über

Peter Becker aus Klingenbach sind

in der

Kundendatei enthalten


Betriebswirtschaftlich orientierte Prozessmodellierung


1. Ebene: Hauptprozesse (z. B. Logistik)

2. Ebene: Geschäftsprozesse (z. B.

Beschaffung)

3. Ebene: Arbeitsvorgänge

(z. B. Bestellanforderung bearbeiten)

4. Ebene: Arbeitsschritte

(z. B. Bedarfsanforderung freigeben)

5. Ebene: Elementarfunktionen

(z. B. Freigabestatus setzen)

Darstellung

Prozess-

überblick


Prozessebenen der Modellierung


Funktionen sind fachliche

Aufgaben bzw. Tätigkeiten an

einem (Informations-) Objekt zur

Unterstützung der (Unternehmens-)

Ziele.

Funktionen transformieren Input-

in Outputdaten.

Eine Funktion enthält die Ent-

scheidungskompetenz über den

weiteren Ablauf.

Funktionen können soweit unter-

teilt werden, bis sie einen

betriebswirtschaftlich nicht weiter

sinnvoll unterteilbaren Vorgang

darstellen.

Kundenanfrage

prüfen

Informationsobjekt

Verrichtung

Funktion

EPK – Notationselemente


Funktionsbäume zeigen

die Abhängigkeit von Funktionen eines Systems untereinander

wie Funktionen in Teilfunktionen aufgeteilt bzw. modularisiert werden können

welche Funktionsfolge im System vorliegt (Ablauf/Aufruf von

Folgefunktionen)

Modellierung eines Funktionsbaums ist bei komplexen Funktionen sinnvoll

Funktionenbaum

Strukturierung der Funktionen anhand eines Funktionenbaums


Gliederungskriterium Charakterisierung Beispiele

Verrichtung Gruppierung von

Funktionen mit gleichen

oder ähnlichen

Transformationsvorschriften

Debitorenrechnung

buchen

Kreditoren buchen

Lohnzahlungen

buchen

Bearbeitungsobjekt Gruppierung von

Funktionen, die die

gleichen Objekte

bearbeiten

Auftrag erfassen

Auftrag stornieren

Auftrag ausliefern

Geschäftsprozess Gruppierung der an einem

Prozess beteiligten

Funktionen

Lieferanten auswählen

Anfrage erstellen

Bestellung schreiben

Gliederungskriterien zur Strukturierung eines Funktionsbaums

Strukturierung der Funktionen anhand eines Funktionenbaums


passive Komponente

Repräsentiert Zustand eines

Informationsobjekts

löst Funktionen aus

ist Ergebnis von Funktionen

ist auf einen Zeitpunkt

bezogen

beeinflusst weiteren Ablauf

des Geschäftsprozesses

Bedarfsanforderung

ist entstanden

Ergebnisse

Zusätzlich zu den Funktionen werden im Rahmen der Modellierung mit EPK

Ereignisse verwendet

EPK – Notationselemente


Eine EPK

ist ein gerichteter

Graph

Knoten sind

Funktionen,

Ereignisse,

Konnektoren

Kanten beschreiben

Daten- und

Kontrollfluss,

sowie Zuordnungen


Ereignisgesteuerte Prozesskette


Ereignis

Passive Komponente,

löst Funktionen aus oder sind Ergebnisse von Funktionen

Funktion

Aktive Komponente, führt etwas durch

Erzeugen Ergebnisse (Ereignisse)

Kante

Verkettet Objekte (Funktionen, Ereignisse, Operatoren)

Verknüpfungsoperatoren

Ermöglichen die Modellierung von Verzweigungen in Prozessen

E

F


Grundobjekte der EPK


Ereignisse lösen Funktionen

aus

Funktionen erzeugen

EreignisseAntragsdaten

erfassen

Kreditantrag

eingetroffen

Antragsdaten

erfasst

Eingangs-

bestätigung

schicken

Eingang bestätigt

Verknüpfungen: Sequenz

EPK – Verknüpfungen


Nach der Funktion treten

zwei Ereignisse auf

F

E1

E2

F1 F2

E

Ein Ereignis ist Auslöser

für zwei Funktionen

AND-Split



F

E

E

F F

E

AND-Join

Zwei Ereignisse sind

Auslöser für die Funktionen Das Ereignis tritt nach

zwei Funktionen auf



Faktura bearbeiten

Faktura A

erstellt

Faktura B

erstellt

Auftrag

freigeben

Auftrag

drucken

Auftragsdaten

sind ermittelt

OR-Split

Nach der Funktion sind

mehrere Fortsetzungen

möglich

Nicht erlaubt

Ereignisse haben keine

Entscheidungskompetz



Arbeitsgang

freigegeben

Arbeitsplan

ist verfügbar

Ressourcen

sind geprüft

Artikel

anfertigen

Artikel

bestellen

Artikel ist

im Lager

OR-Join

Das Ereignisse tritt nach

mindestens einer Funktion

auf

Mindestens ein Ereignis

ist Auslöser für die

Funktionen



Rechnung prüfen

Rechnung

freigegeben

xor

Rechnung

nicht freig.

xor

Auftrag

freigeben

Auftrag

drucken

Auftragsdaten

sind ermittelt

XOR-Split

Nicht erlaubt

Analog zum OR-Split

Nach der Funktion ist

genau eine Fortsetzung

möglich



Fertigungsauftrag

bearbeiten

Fertigungs-

auftrag ist teil-

freigegeben

XOR

Fertigungs-

auftrag ist

freigegeben

XOR

Artikel

produzieren

Artikel aus

Lager

anfordern

Artikel vorhanden

XOR-Join

Das Ereignis tritt nach

genau einer der beiden

Funktionen auf

Genau ein Ereignis ist

Auslöser der Funktion



Operatoren

Ereignisverknüpfungen Funktionsverknüpfungen

Auslöse-

ereignisse

Bereitstellungs-

ereignisse

Auslöse-

ereignisse

Bereitstellungs-

ereignisse

Konjunktion

(UND)

Adjunktion

(Inklusives

ODER)

Disjunktion

(Exklusives

ODER)

XOR

XOR

XOR

„Ereignisse (passiv) haben keine

Entscheidungskompetenz“)

Übersicht EPK-Verknüpfungen


Jede EPK beginnt und

endet mit mindestens

je einem Ereignis

Ausnahme: Verweis auf

eine andere EPK

Sicherheiten

unzureichend

Kreditantrag

eingetroffen

XOR

Kundendaten

erfassen

Kundendaten

erfasst

Sicherheiten

prüfen

Sicherheitenunzureichend

Sicherheitenvorhanden

XOR

Ablehnungbegründen

Kreditantragabgelehnt

Vertragerstellen

Konditionenfestlegen

Kreditantraggenehmigt

EPK – Regel 1

EPK – Notationsregeln


Jede Kante verbindet zwei

Knoten von jeweils

unterschiedlichem Typ

Ausnahme: Auf einen

Konnektor darf ein

Konnektor folgen

…

F

E F

E …

EPK – Regel 2



Kontrollfluss verzweigt

und vereinigt sich nur

an Konnektoren

E F

… …

EPK – Regel 3



Auf Ereignisse dürfen keine

OR- bzw. XOR-Konnektoren

folgen

OR

und/oder

AND

und

XOR

entweder/oder

E

XOR

F F

E

AND

F F

E

OR

F F

F F F F F F

XOR AND OR

E E E

EPK – Regel 4



Alle Ein-/Ausgänge der

Konnektoren sind vom

gleichen Typ

E

F

E

…

…

F F


EPK – Regel 5


Konnektoren verbinden stets

Ereignisse mit Funktionen

bzw. Funktionen mit

Ereignissen

E

…

F F E

…

F

E

EPK – Regel 6



Eine Funktion kann durch eine

weitere EPK verfeinert werden

I1

E1

F1

E2I2

I2 F2

E3

O1

O2

O3

VW

F1

E1

F1.1I1 O1

E1.1

F1.2

E2

VW

F1

I1 O2

I2

EPK – Regel 7



Ressourc

ensic

ht

Organisationssicht

Datensicht

Herr Muster

Funktionssic

ht

Einkauf

Herr MusterMaterial ist

eingetroffen

Material und

Begleitschein

prüfen

Material ist

geprüft

Bestelldaten

abgleichen

Liefer-

schein

Liefer-

schein

Bestellung

Einkauf

36

Sichten auf das Prozessmodell

EPK – Sichtenmodell


DV-Konzept

Fachkonzept

DV-Konzept

Implementierung

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

Implementierung

DV-Konzept

Fachkonzept

ImplementierungLeis

tun

g

Ste

ue

run

g

Da

ten

Fu

nk

tio

n

37

ARIS Haus

Architektur integrierter Informationssysteme (ARIS)


• Alle Funktionen

• Siehe z. B. FunktionenbaumFunktionssicht

• Alle Organisationseinheiten

• Alle Ressourcen (z. B. Menschen, Maschinen, Hardware)

Organisationssicht

• Alle Ereignisse (die Daten generieren) und Umfelddaten (z. B. Fachbegriffe)

• Schriftverkehr, DokumenteDatensicht

• Prozess Output/Produkt

• Dienst-, Sach- und finanzielle LeistungenLeistungssicht

• Integration aller Sichten

• Logischer und zeitlicher AblaufplanSteuerungssicht

Beschreibungssichten - Sichtenkonzept

ARIS Haus – Beschreibungssichten


• Strukturierte Darstellung eines Prozesses mittels DV-fremden Beschreibungsmodellen

• z. B. ERM, EPK, Funktionsbaum, Organigramm

Fachkonzept

• Umsetzung des Fachkonzepts in DV-nahe Beschreibungsmodelle

• z. B. RelationenDV-Konzept

• DV-technische Realisierung der beschriebenen Prozessteile

• z. B. mittels Erstellung Programmcode, Datenbanksystemen

Implementierungs-ebene

Beschreibungssichten - Sichtenkonzept



erweiterte

ereignisgesteuerte Prozesskette (eEPK)

erweitertes Entity-

Relationship-Modell (eERM)

Organigramm

Zieldiagramm, Funktions-

baum

Datensicht Steuerungssicht Funktionssicht

Organisationssicht

40

ARIS – Ebenen der Prozesszerlegung auf Fachkonzeptebene



• Relationale Datenbankmodelle in betriebswirtschaftlichen IT-Systemen weit verbreitet

• ERM ist Standardnotation zur Beschreibung von Datenmodelle

Entity RelationshipModell (ERM)

• Objektorientierung hat sich als wesentliches Prinzip in der Programmierung durchgesetzt

• UML (UML Klassendiagramme) ist Standardnotation zur Modellierung objektorientierter Systeme

Unified Modeling Language (UML)

• Notationen werden von Nicht-Informatikern als zu komplex angesehen

• In der Praxis daher häufig Nutzung (Hierarchisch strukturierter) Fachbegriffe

Fachbegriffe

ARIS – Modellierung der Datensicht



Prozesswegweiser

Organisationseinheit

Informationsobjekt

Dokumente

Zuordnung von Organisationseinheiten

Der Prozesswegweiser zeigt die Verbindung von einem bzw. zu einem anderen Prozess (Navigationshilfe).

Die organisatorische Einheit beschreibt die Gliederungsstruktur eines Unternehmens.

Das Informations-/Material-/ Ressourcenobjekt ist eine Abbildung eines Gegenstandes der realen Welt.

Dokumente beschreiben die in einem Prozess verwendeten Dokumente bzw. unstrukturierte Informationen.

Diese Zuordnung vonSystemorganisationseinheitenbeschreibt, welcheEinheit (Mitarbeiter) die Funktion bearbeitet

Zusammenführung der Sichten

Erweiterte ereignisgesteuerte Prozessketteweiterführende Notationselemente


Input-Output-Beziehung von

Daten

Verbindung von Funktionen

mit Organisationseinheiten

Medien für Kommunikation,

Speicherung usw. (z. B. Fax,

Drucker, ...)

Materielle und immaterielle

Leistungen, Ergebnisse

Kundenauftrag

eingetroffen

Kunden-auftragerfassen

Vertrieb

Kundenauftrag

erfasst

Kunden-auftragtechn. prüfen

Kunden-

auftrag

techn.

Vertrieb

KA technisch

nicht machbar

KA technisch

machbar

XOR

Produkt-

daten

Kunden-

auftrag

Erweiterte ereignisgesteuerte Prozessketten (eEPK)

Erweiterte ereignisgesteuerte ProzessketteBeispiel


Kundenauftrag

bearbeiten

Kundenauftrag

liegt vor

Innenauftrag

ist erstellt

Materialbedarf

bestimmen

Fertigungsauftrag

einplanen

Fertigungs-

auftrag liegt vor

Fertigungsauftrag

ist eingeplant

Bedarfsanfor-

derung liegt vor

Einkauf

Kundenauftrag

Innenauftrag

Stückliste

Lagerbestand

Bedarfs-

anforderung

Fertigungs-

auftrag

Disposition

Vertrieb

Fertigungs-

steuerung

Fertigungs-

plan

Fertigungs-

auftrag

Beispiel für eine eEPK

Erweiterte ereignisgesteuerte Prozessketteweiterführende Notationselemente


Prozess Personal – Bewerbung bearbeiten

Der Prozess beginnt mit dem Eintreffen einer Bewerbungsmappe in der Personalabteilung. Die

zuständige Sekretärin legt einen neuen Datensatz im ERP System an, danach leitet sie die

Bewerbungsunterlagen an die zuständige Personalreferentin weiter.

Die Personalreferentin prüft die Unterlagen zunächst auf Vollständigkeit. Bei fehlenden Dokumenten

wird eine E-Mail an den Bewerber gesendet, der gebeten wird diese nachzuliefern. Danach endet der

Prozess.

Sind die Unterlagen vollständig, führt die Personalreferentin ein Telefoninterview mit dem Bewerber

durch.

Erweist sich der Bewerber als geeignet, wird ein gemeinsamer Termin zu einem persönlichen

Vorstellungsgespräch vereinbart. Anschließend bucht die Personalreferentin einen Raum im internen

ERP-System und versendet eine Terminbestätigung per E-Mail an den Bewerber.

Entspricht das Bewerberprofil nicht den Anforderungen, erstellt die Personalreferentin ein

Ablehnungsschreiben, das sie im Anschluss versendet, woraufhin der Prozess nach diesem Schritt endet.

Erweiterte ereignisgesteuerte ProzessketteÜbungsaufgaben


Prozess Bibliothek – Buch ausleihen

Der Prozess beginnt mit dem Betreten der Bibliothek. Darauf folgt die Literaturrecherche im Bibliotheksverwaltungssystem.

Ist das Buch nicht verfügbar, endet der Prozess. Ist das Buch verfügbar, notiert sich der Student den Ablageort. Im Anschluss sucht er sich das Buch aus den Regalen heraus und prüft den Buchinhalt.

Wird der Inhalt für nicht gut befunden so wird das Buch an der Sammelstelle abgegeben und der Prozess endet. Wird der Inhalt für gut befunden, soll das Buch ausgeliehen werden.

Sofern ein Bibliotheksausweis vorhanden ist, scannt der Student das Buch ein. Er erhält vom System eine Mail über seine Leihe und ein Rückgabedatum. Daraufhin verlässt er die Bibliothek.

Ist kein Bibliotheksausweis vorhanden, muss er diesen beantragen. Dafür füllt der Student einen Antrag aus. Danach legt der Student den Personalausweis vor.

Die Mitarbeiterin in der Verwaltung erfasst dessen Daten im Bibliotheksverwaltungssystem und erhebt eine Einrichtungsgebühr.

Erfolgt die Zahlung in bar, nimmt die Mitarbeiterin den Betrag entgegen und erstellt eine Quittung für den Studenten.

Zahlt der Student per EC-Karte, erhält er zunächst eine Zahlkarte von der Mitarbeiterin. Im nächsten Schritt bezahlt er die Einrichtungsgebühr am dafür vorgesehen Bezahlautomaten. Nachdem die Zahlung erfolgreich abgewickelt wurde, erhält der Student eine Quittung, die er der Mitarbeiterin in der Verwaltung vorlegt.

Im Anschluss bekommt er einen Ausweis ausgestellt woraufhin er das Buch ausleihen kann.




Bedarfsanforderungen Materialwirtschaft



Arbeitsvorgang Bestellanforderung bearbeiten

Wenn Bedarf an Material/ext. Dienstleistungen vorliegt, wird vom Bedarfsanforderer eine

Bedarfsanforderung angelegt. Zusätzlich muss er dabei die Dokumente Lastenheft und Weitere

Vorgaben als Input beachten, um als Ergebnis die Bedarfsanforderung in Dateiform zu erhalten.Damit ist die Bedarfsanforderung angelegt.

Anschließend prüft der jeweilige Entscheider den Beschaffungsweg und braucht dafür als Inputeinen Kriterienkatalog zusätzlich zur dateimäßig gespeicherten Bedarfsanforderung. Ist die

Prüfung beendet, steht fest, ob der Bedarf zentral oder dezentral zu decken ist.

Bei zentraler und bei dezentraler Bedarfsdeckung bearbeitet ein Einkäufer die

Bedarfsanforderung unter Mitwirkung des Bedarfsanforderers. Dabei kann auch der Fall eintreten,

dass als Ergebnis der Bearbeitung die Bedarfsanforderung storniert wird.

Im Fall der erfolgreichen Bearbeitung wird gemeinsam vom Einkäufer und vom fachlichen

Experten ein bestehendes Beschaffungsvorhaben zugeordnet oder ein neues dateimäßigangelegt. Dann wird dieses vom Einkäufer unter Berücksichtigung von Pflichtenheft und

Kriterienkatalog terminiert.

Wenn dabei die die Einleitung der Beschaffung noch nicht sinnvoll erscheint, wird der Vorgang

zurückgestellt und später wiederholt terminiert. Andernfalls ist der Arbeitsvorgang

„Bestellanforderung bearbeiten“ erfolgreich beendet.Der nächste Arbeitsvorgang „Bezugsquelle ermitteln“ wird dann durch das

Beschaffungsvorhaben (Fachbegriff) angestoßen.



Arbeitsvorgang Bezugsquelle ermitteln (1/2)

Wenn die Einleitung der Beschaffung als sinnvoll erachtet worden ist, schlägt der Einkäufer auf

Basis des Beschaffungsvorhabens die Vergabeart vor, nämlich

Abruf aus Rahmenvertrag, Öffentliche Ausschreibung oder

Freihändige Vergabe.

Dies wird in einem Dokument schriftlich festgehalten.Anschließend wird die Vergabeart vom Mitzeichner Vergabeart genehmigt oder abgelehnt.

Bei Ablehnung wird der Vorgang zur Funktion Vergabeart vorschlagen zurückgegeben.

Wenn ein Abruf aus Rahmenvertrag oder eine freihändige Vergabe genehmigt wird, ist das

Modell hier beendet und wird im Folgemodell Einkauf durchführen fortgesetzt.

Bei öffentlicher Ausschreibung sind eine Reihe weiterer Tätigkeiten auszuführen: Der Einkäuferveröffentlicht die Ausschreibung auf der Grundlage des Beschaffungsvorhabens.

Wenn danach der Bewerber Unterlagen angefordert hat, wird die Bewerberanfrage vomEinkäufer bearbeitet. Dazu benutzt er neben der Bedarfsanforderung eine Liste unzulässiger

Bewerber und erstellt ein Lastenheft als Dokument, Leistungsunterlagen als Dokument und die

Anfrage als Datei.Anschließend gibt ein Entscheider die Anfrage frei, wobei er dies in einer Bewerberliste notiert.

Nach der Freigabe übermittelt der Einkäufer auf Basis der Anfrage und der Bewerberliste eine

Angebotsaufforderung.



Arbeitsvorgang Bezugsquelle ermitteln (2/2)

Wenn dann nach einiger Zeit das Angebot eingeht, wird dies von einem Angebotsprüfer formalgeprüft, wobei eine als Datei bestehende Liste unzulässiger Bewerber zu beachten ist und ggf.aktualisiert werden kann.Ist das Angebot formal ungültig, endet der Prozess hier.

Andernfalls werden jetzt notwendige Stellungnahmen erarbeitet. Dabei sind Fachliche Experten,Preisverhandler und Bedarfsanforderer involviert, die auf der Grundlage von Anfrage, Angebot undLastenheft ohne Systemunterstützung die Stellungnahmen als Dokument erstellen.

Danach folgt auf Basis der Stellungnahmen die Angebotsbearbeitung des Einkäufers.Schließlich wählt der Einkäufer das präferierte Angebot aus, wobei es sich um ein Angebot mit und

ohne Rahmenvertrag handeln kann. Ohne Rahmenvertrag kann sofort der Arbeitsvorgang„Einkaufsdurchführung“ auf der Grundlage des Angebotes erfolgen, andernfalls muss zuerst derRahmenvertrag unter Berücksichtigung von Angebot und Lastenheft bearbeitet werden.

An dieser Stelle ist der Arbeitsvorgang „Bezugsquelle ermitteln“ beendet und es können weitereArbeitsvorgänge folgen: Rahmenverträge bearbeiten mit Input Angebot und Lastenheft und Output Rahmenvertrag

Einkauf durchführen mit Input Angebot, Handkauf, Abruf aus Rahmenvertrag, Rahmenvertragund Output Bestellung

Wenn nach einiger Zeit die bestellten Waren geliefert bzw. die Dienstleistungen erbracht sind,erfolgen:

Wareneingang bearbeiten mit Input Wareneingangsbeleg und Output Rücklieferungsauftragsowie Wareneingangsbeleg

Leistungserfassung durchführen mit Input Dienstleistungsabnahme und Output Leistungsbericht.

Rechnungsprüfung durchführen mit Input Rechnung/Gutschrift, Leistungsbericht,Rücklieferungsauftrag, Wareneingangsbeleg und Output Zahlungsbeleg


Verhaltensperspektive

Anforderungen

z. B. UML Aktivitäts-diagramme

Integration

z. B. Statecharts

Integration

z. B. UML Klassen-diagramme

Systemkontext

festlegen

Anforderungen

erfassen

Anforderungen

dokumentieren

Anforderungen

prüfen & abstimmen

Anforderungen

verwalten

Die drei Perspektiven der Anforderungsdokumentation - technisch



Strukturperspektive (Datenperspektive)

Es wird eine statisch-strukturelle Perspektive auf die

Anforderungen eingenommen (Datentypen, deren

Attribute sowie Beziehungen zwischen den

Datentypen)

Es wird die Struktur der Ein- und Ausgabedaten sowie

statisch-strukturelle Aspekte von Nutzung und

Abhängigkeitsbeziehungen des Systems im

Systemkontext dokumentiert

Beispiel: Die zu nutzenden Dienste eines externen

Systems

Systemkontext

festlegen

Anforderungen

erfassen

Anforderungen

dokumentieren

Anforderungen

prüfen & abstimmen

Anforderungen

verwalten




Funktionsperspektive

Es wird dokumentiert, welche Informationen bzw.

Daten aus dem Systemkontext durch das zu

entwickelnde System bzw. dessen Funktionen

manipuliert werden

in den Systemkontext fließen

Nach Bedarf wird auch die Systematik der

Funktionsführung zur Verarbeitung der Eingabedaten

dokumentiert

Die Funktionsperspektive fokussiert sich demnach auf

die Transformation von Eingabedaten aus der

Umgebung des Systems in Ausgabedaten in die

Umgebung

Systemkontext

festlegen

Anforderungen

erfassen

Anforderungen

dokumentieren

Anforderungen

prüfen & abstimmen

Anforderungen

verwalten




Verhaltensperspektive

Dokumentation der Einbettung des Systems in den

Systemkontext (zustandsorientiert)

Es wird z. B. die Reaktion des Systems auf Ereignisse im

Systemkontext, Bedingungen eines Zustandswechsels

sowie Effekte definiert (bspw. wenn das betrachtete

System für ein weiteres System ein Ereignis darstellt,

externe Stimulation)

Die Definition eines endlichen Automaten umfasst eine

Menge von Zuständen und Zustandsübergängen, die,

abhängig vom aktuellen Zustand des Automaten,

durch das Eintreten eines Ereignisses ausgeführt

werden

Systemkontext

festlegen

Anforderungen

erfassen

Anforderungen

dokumentieren

Anforderungen

prüfen & abstimmen

Anforderungen

verwalten




Unified Modeling Language

Sprache zur

Modellierung

Dokumentation

Spezifizierung

Visualisierung

komplexer Softwaresysteme

In den 90ern von der Object Management Group entwickelt –

mittlerweile ISO standardisiert

Dominierende Sprache (de facto Standard) in der SE

Besteht aus einer Sammlung vorwiegend grafischer Sprachen zur

Erstellung von Anforderungs- und Entwurfsmodellen aus

verschiedenen Perspektiven


Unified Modeling Language


Diagramme der UML

Strukturdiagramme Verhaltensdiagramme

Klassendiagramm Interaktionsdiagramme

Paketdiagramm Use-Case-Diagramm Sequenzdiagramm

Objektdiagramm Aktivitätsdiagramm Kommunikationsdiagramm

Kompositionsstrukurdiagramm Zustandsautomat Timingdiagramm

Komponentendiagramm Interaktionsübersichtsdiagramm

Verteilungsdiagramm

13 Diagramme

6 Strukturdiagramme

7 Verhaltensdiagramme

davon 4 Interaktionsdiagramme

UML – Übersicht der Diagramme



Diagrammtyp Diese zentrale Frage be-

antwortet das Diagramm

Stärken

Klassendiagramm Aus welchen Klassen besteht mein

System und wie stehen diese

untereinander in Beziehung?

Beschreibt die statische Struktur des zu

entwerfenden oder abzubildenden

Systems

Enthält alle relevanten

Strukturzusammenhänge und Datentypen

Bildet die Brücke zu den dynamischen

Diagrammen

Paketdiagramm Wie kann ich mein Modell so

schneiden, dass ich den Überblick

bewahre?

Organisiert das Systemmodell in größere

Einheiten durch logische

Zusammenfassung von Modellelementen

Modellierung von Abhängigkeiten

Objektdiagramm Welche innere Struktur besitzt mein

System zu einem bestimmsten

Zeitpunkt zur Laufzeit

(Klassendiagrammschnappschuss)

Zeigt Objekte und deren

Attributsbelegungen zu einem bestimmten

Zeitpunkt

Wird nur beispielhaft zur

Veranschaulichung verwendet

Detailniveau wie im Klassendiagramm

Sehr gute Darstellung von

Mengenverhältnissen

AnforderungsdokumentationStrukturdiagramme




Stärken

Kompositionsstrukturdiagramm Wie sieht das Innenleben einer

Klasse, einer Komponente, eines

Systemteils aus?

Ideal für die Top-down-Modellierung

des Systems

Mittels Detailniveau, zeigt Teile eines

„Gesamtelements“ und deren

Mengenverhältnisse

Komponentendiagramm Wie werden meine Klassen zu

wieder verwendbaren,

verwaltbaren Komponenten

zusammengefasst und wie

stehen diese miteinander in

Beziehung?

Zeigt Organisation und

Abhängigkeiten einzelner technischer

Systemkomponenten

Modellierung angebotener und

benötigter Schnittstellen möglich

Verteilungsdiagramm Wie sieht das Einsatzumfeld

(Hardware, Server,

Datenbanken, …) des Systems

aus?

Wie werden die Komponenten

zur Laufzeit wohin verteilt?

Zeigt das Laufzeitumfeld des Systems

mit den „greifbaren“ Systemteilen

(meist Hardware)

Hohes Abtraktionsniveau, kaum

Notationselemente

AnforderungsdokumentationStrukturdiagramme




Stärken

Use-Case –Diagramm Was leistet mein System für seine

Umwelt (Nachbarsysteme,

Stakeholder) ?

Präsentiert die Außensicht auf ein System

Geeignet zur Kontextabgrenzung

Hohes Abtraktionsniveau, einfache

Notationsmittel

Aktivitätsdiagramm Wie läuft ein bestimmter

flussorientierter Prozess oder ein

Algorithmus ab?

Sehr detaillierte Visualisierung von Abläufen

mit Bedingungen, Schleifen, Verzweigungen,

Parallelisierung und Synchronisation möglich

Zustandsautomat Welche Zustände kann ein

Objekt, eine Schnittstelle, eine

Use Case, … bei welchen

Ereignissen annehmen?

Präzise Abbildung eines Zustandsmodells mit

Zuständen, Ereignissen, Nebenläufigkeiten,

Bedingungen, Ein- und Austrittsaktionen

Schachtelung möglich

Sequenzdiagramm Wer tauscht mit wem welche

Informationen in welcher

Reihenfolge aus?

Stellt den zeitlichen Ablauf des

Informationsaustausches zwischen

Kommunikationspartnern dar

Schachtelung und Flusssteuerung

(Bedingungen, Schleifen, Verzweigungen)

möglich

AnforderungsdokumentationVerhaltensdiagramme




Stärken

Kommunikationsdiagramm Wer kommuniziert mit wem? Wer

„arbeitet“ im System zusammen?

Stellt den Informationsaustausch

zwischen Kommunikationspartnern

dar

Überblick steht im Vordergrund

(Details und zeitliche Abfolge

weniger wichtig)

Timingdiagramm Wann befinden sich

verschiedene Interaktionspartner

in welchem Zustand?

Visualisiert das exakte zeitliche

Verhalten von Klassen,

Schnittstellen, …

Geeignet für Detailbetrachtungen,

bei denen es überaus wichtig ist,

dass ein Ereignis zum richtigen

Zeitpunkt eintritt

Interaktionsübersichtsdiagramm Wann läuft welche Interaktion

ab?

Verbindet Interaktionsdiagramme

(Sequenz-, Kommunikations- und

Timingdiagramme) auf Top-Level-

Ebene

Hohes Abtraktionsniveau

Gut geeignet als Strukturierung der

Interaktionsdiagramme

AnforderungsdokumentationVerhaltensdiagramme


UMLKlassendiagramm

Beispiel Klassendiagramm (Strukturperspektive)


UMLKlassendiagramm

Beispiel KlassendiagrammGerichtete Assoziation:

Ein Kunde kauf ein oder mehrere

Bücher. Die Bücher haben keinen

Bezug zum Käufer.

Beispiele:

Ungerichtete Assoziation:

Ein Kunde hat ein oder mehrere

Konten, ein Konto gehört immer

genau einen Kunden.

Kunde Bücher1 1…*

Kunde Konto1 1…*

Aggregation:

Ein Rad ist Teil eines Autos. Ein Rad

kann problemlos unabhängig vom

Auto existieren.

Auto Rad1 1…*

Komposition:

Eine Wohnung ist Teil eines

Wohnhauses. Ohne Wohnhaus kann

die Wohnung nicht existieren.

W.-Haus Wohn.1 1…*


stellt Anwendungsfälle dar zeigt das externe Verhalten eines

Systems aus der Sicht der Nutzer

kapselt eine in sich geschlossene Sammlung von Aktionen die in einer

spezifizierten Reihenfolge ablaufen

es werden Nutzer, Use-Cases und deren Beziehung zueinander

werden dargestellt - nicht welche Klassen und Operationen an den

Aktionen beteiligt sind

keine Detailierung – dient der Skizzierung von Anwendungsfällen

UMLUse Case Diagramm

Use Case Diagramm (Strukturperspektive)

Was soll mein geplantes System eigentlich leisten?



Beispiel Use Case Diagramm

Include Beziehung:

Eine Include Beziehung besagt, dass der

referenzierte Use Case immer mit ausgeführt wird. Es

handelt sich somit um eine Beziehung, die nicht

optional, sondern verpflichtend ist. In der Notation

einer Programmiersprache könnte es sich um den

Aufruf eines Unterprogramms handeln

Extend Beziehung:

Eine Extend Beziehung meint eine Erweiterung eines

Use Cases in einem bestimmten Fall, bzw. wenn eine

bestimmte Bedingung eintrifft bzw. erfüllt wird. Eine

extended Beziehung kann somit analog zu einer if-Anweisung gesehen werden gelten die

vorgegebenen Bedingungen, werden die

entsprechenden Anweisungen durchlaufen



Notation Use Case Diagramm


Eine Aktivität

ist eine Menge von potentiellen Abläufen die sich in der Realität

unter Randbedingungen abspielen

Ein Aktivitätsdiagramm

zeigt den Rahmen und die Regeln von Verhaltensabläufen auf

detailliertem Niveau

zerlegt Aufgaben in Einzelschritte

dient der Modellierung von Abläufen es werden komplexe

Verläufe unter Berücksichtigung von Nebenläufigkeiten sowie

alternative Entscheidungswege im Detail dargestellt

UMLVerhaltensdiagramm

Aktivitätsdiagramm (Funktionsperspektive)

Wie realisiert mein System ein bestimmtes Verhalten



Beispiel Aktivitätsdiagramm



Notation Aktivitätsdiagramm


zeigt den Informationsaustausch zwischen beliebigen

Kommunikationspartnern (innerhalb eines Systems oder zwischen

verschiedenen Systemen)

ermöglicht die Modellierung von:

festen Reihenfolgen

zeitlichen und logischen Ablaufbedingungen

Schleifen

Nebenläufigkeiten

zeigt Interaktion in zwei Dimensionen:

vertikal zeitliche Abfolge der Kommunikationsschritte

horizontal die miteinander kommunizierenden Partner

UMLSequenzdiagramm

Sequenzdiagramm (vergleichbar mit einem Entscheidungsbaum)

Wie läuft die Kommunikation in meinem System ab?


UMLSequenzdiagramm

Beispiel Sequenzdiagramm


UMLSequenzdiagramm

Notation Sequenzdiagramm


UMLSequenzdiagramm



BPMNNotation

Notation Business Process Management Notation


BPMNNotation

Aufgabe Business Process Management NotationDer Beschaffungsprozess startet mit einer automatisierten – auf 9 Uhr terminierten – Mail aus dem des

Lagerverwaltungssystems an den zuständigen Mitarbeiter im Einkauf. Der Sacharbeiter Einkauf prüft die darin

beschriebenen Informationen zu den aktuellen Vorräten.

Sind die Lagerbestände ausreichend, archiviert er die Mail im Mailsystem.

Werden die Lagerbestände mit einem Bestand im Bereich 20-30% ausgewiesen, legt er sich die Mail auf

Wiedervorlage für den nächsten Tag.

Sind die Lagerbestände unter 20% gesunken, erfasst er umgehend einen Bestellauftrag im System,

anschließend prüft er die Lieferkonditionen mit den Lieferanten im hauseigenen EDI-System.

Ist eine Lieferung bis zum Folgetag möglich, leitet er den Bestellauftrag über das EDI-System zur Freigabe an

den Leiter des Einkaufs weiter.

Dauert die Lieferung laut EDI länger als einen Werktag, kontaktiert der Sachbearbeiter weitere Lieferanten

per Telefon.

Wird er fündig, protokolliert er die Gesprächsinformationen in einer Mail und sendet diese an den Lieferanten

und den Leiter des Einkaufs.

Hat die Suche nach einem neuen Lieferanten keinen Erfolg, eskaliert er den Vorgang im EDI-System an den

Leiter des Einkaufs.

Im Eskalationsfall kontaktiert der Einkaufsleiter die Standardlieferanten per Mail und weist auf die Dringlichkeit

hin. Die Korrespondenz legt er im EDI System ab und setzt sich eine Wiedervorlage für denselben Tag.

Geschäftsprozessmodellierung - stivenraso.destivenraso.de/fom/GPM/2017_WS_FOM_GPM.pdf ·...

Documents

Transcript of Geschäftsprozessmodellierung - stivenraso.destivenraso.de/fom/GPM/2017_WS_FOM_GPM.pdf ·...