Fachentwurf für DV-Anwendungssysteme [2., ergänzte Auflage. Reprint 2018] 9783486783384, 9783486218169

Citation preview

Fachentwurf für DV-Anwendungssysteme Von Universitätsprofessor

Dr. Herbert Kargl 2., ergänzte Auflage

R. Oldenbourg Verlag München Wien

CIP-Titelaufnahme der Deutschen Bibliothek Kargl, Herbert: Fachentwurf für DV-Anwendungssysteme / von Herbert Kargl. - 2., erg. Aufl. - München ; Wien : Oldenbourg, 1990 ISBN 3 - 4 8 6 - 2 1 8 1 6 - 6

© 1990 R. Oldenbourg Verlag GmbH, München Das Werk außerhalb lässig und filmungen

einschließlich aller Abbildungen ist urheberrechtlich geschützt. Jede Verwertung der Grenzen des Urheberrechtsgesetzes ist ohne Zustimmung des Verlages unzustrafbar. Das gilt insbesondere fur Vervielfältigungen, Übersetzungen, Mikroverund die Einspeicherung und Bearbeitung in elektronischen Systemen.

Gesamtherstellung: Rieder, Schrobenhausen

ISBN 3-486-21816-6

Inhaltsverzeichnis Vorwort

VII

1.

Betriebliche DV-Anwendungssysteme

1

2.

Die Entwicklung von betrieblichen DV-Anwendungssystemen

11

2.1 2.1.1 2.1.2 2.2

Grundlagen Organisationsplanung Die systemtheoretische Orientierung als methodische Leitlinie Die Systemgestaltung

11 11 13 21

2.3 2.3.1 2.3.2 2.3.3 2.3.4

Die Prozeßgestaltung Anforderung an die Prozeßgestaltung Vorgehensmodelle Konstruktionsmethodik Qualitätssicherung

28 28 30 39 44

2.4

Die Träger der Systementwicklung

52

2.5 2.5.1 2.5.2

Benutzerpartizipation Gründe für die Benutzerpartizipation Der Partizipationsumfang

58 58 61

3.

Die Entwicklung der Fachkonzeption

65

3.1 3.1.1 3.1.2 3.1.2.1 3.1.2.2 3.1.2.3 3.1.2.4 3.1.2.5 3.1.2.6

Die Situationsstudie Das Gestaltungsobjekt Aktivitäten und Aktivitätenunterstützung Situationsbeurteilung Zielbildung Kritische Erfolgsfaktoren Erarbeiten von Maßnahmen Wirtschaftlichkeitsprüfung Dokumentation

65 65 68 68 77 85 86 87 89

3.2 3.2.1 3.2.2 3.2.3 3.2.3.1 3.2.3.2 3.2.3.3 3.2.3.4 3.2.3.5 3.2.3.6 3.2.3.7

Die Anforderungsermittlung Das Gestaltungsobjekt Die Vorgehensmethode Aktivitäten und Aktivitätenunterstützung Abgrenzung des Untersuchungsbereichs Zielrevision Aufgabenspezifische Anforderungen Technikspezifische Anforderungen Benutzerspezifische Anforderungen Überprüfung der Anforderungen Dokumentation

94 94 99 102 102 102 111 135 135 136 139

VI

Inhaltsverzeichnis

3.3 3.3.1 3.3.2 3.3.3 3.3.3.1 3.3.3.2 3.3.3.3 3.3.3.4 3.3.3.5 3.3.3.6 3.3.3.7

Die Anforderungsspezifizierung Das Gestaltungsobjekt Die Vorgehensmethode Aktivitäten und Aktivitätenunterstützung Definition der Schnittstellen und der Schnittstelleninhalte Erstellen der Informationsstruktur Strukturierung und Beschreibung der Vorgänge Gestalten der Schlüsselsysteme Entwurf der Benutzerschnittstelle Überprüfung der Spezifizierung Dokumentation

145 145 149 153 153 153 160 176 179 187 189

4.

Prototyping

209

5.

Wirtschaftlichkeitsermittlung

213

5.1 5.2 5.2.1 5.2.2 5.3 5.4 5.5

Wirtschaftlichkeitskriterien für DV-Projekte Verfahren zur Wirtschaftlichkeitsermittlung Verfahren zur Ermittlung der quantitativen Wirtschaftlichkeit Verfahren zur Ermittlung der qualitativen Wirtschaftlichkeit Risiko-Analyse von DV-Projekten Projektbegleitende Wirtschaftlichkeitsfortschreibung Tendenzen in der Wirtschaftlichkeitsargumentation

213 217 217 221 229 231 233

6.

Die Auswahl von Standard-Anwendungssoftware

237

7.

Literaturverzeichnis

245

8.

Stichwortverzeichnis

251

9. 9.1 9.2

Anhang: Praktischer Leitfaden

259

Praktischer Leitfaden für den Fachentwurf von DV-Anwendungssystemen Zusammenfassung der Analyse- und Entwurfsschritte

259 272

Vorwort zur ersten Auflage Die Entwicklung von DV-Anwendungssystemen kann unter zwei Sichtweisen betrachtet werden: aus der fachlichen Sicht der zukünftigen Benutzer in den Fachabteilungen und aus der konstruktiven Sicht der Systementwickler. Gegenstand der fachlichen Sicht sind die aufgaben- und organisationsspezifischen Probleme im Benutzerbereich sowie die applikatorische Lösung dieser Probleme durch das zu entwickelnde DV-Anwendungssystem; Gegenstand der konstruktiven Sicht ist die Gestaltung der Software- und Hardware-Infrastruktur des DV-Anwendungssystems nach Maßgabe des Entwurfs der applikatorischen Lösung. Dieses Buch befaßt sich mit der fachlichen Sicht, und es beschreibt diejenigen Schrittfolgen des Entwicklungsprozesses für DV-Anwendungssysteme, in denen die Benutzer (in der Rolle als "Bauherr") und die Systementwickler (in der Rolle als "Architekt") gemeinsam den Fachentwurf erarbeiten. Leitlinie dazu ist ein Phasenkonzept mit den für die fachliche Sichtweise relevanten Phasen Situationsstudie, Anforderungsermittlung und Anforderungsspezifizierung. Die Darstellung der Phaseninhalte orientiert sich an der in der industriellen Fertigung üblichen Form der Fertigungsbeschreibung: Produktbeschreibung, Arbeitsgangfolgen und zu verwendende Werkzeuge oder Vorrichtungen; Ubertragen auf die Phasen des Entwicklungsprozesses von DV-Anwendungssystemen bedeutet dies für deren Inhalt: Ergebnisbeschreibung (das Gestaltungsobjekt einer Phase als herzustellendes "Zwischenprodukt"), Vorgehensmethode, Aktivitätenfolge zur Herstellung des jeweiligen "Zwischenproduktes" und Aktivitätenunterstützung durch die zweckmäßigerweise anzuwendenden Verfahren oder Hilfsmittel. Diese Gliederung liegt dem Hauptteil dieses Buches (Kapitel 3) zugrunde.

VIII

Vorwort

Ein besonderes Anliegen dieses Buches gilt der Verständigung zwischen Fachabteilung (Benutzern) und Systementwicklern hinsichtlich der Vorgehensweise im Entwicklungsprozeß, um dadurch Reibungsverluste aufgrund von MißVerständnis oder Nichtverstehen bei der Projektarbeit zu reduzieren. Deshalb wird großer Wert auf eine strukturierte und benutzerverständliche, aber zugleich auch entwurfsgerechte Darstellung der Phasenergebnisse gelegt; dies gilt besonders für die Spezifizierung der Anforderungen an ein DV-Anwendungssystem aus fachlicher Sicht. Das Buch entstand aus den Materialien zu der Vorlesung "Planung und Entwicklung von betrieblichen DV-Anwendungssystemen", die Bestandteil der Lehrveranstaltungen zum Pflichtwahlfach "Betriebsinformatik" für die Studierenden der Wirtschaftswissenschaften an der Universität Mainz ist, sowie aus Praxisseminaren, in denen Benutzer und Systementwickler vor Beginn ihrer Arbeit an DV-Projekten in Vorgehensmethode und "gemeinsamer Sprache" geschult wurden. Deshalb wendet sich dieses Buch als Lehrbuch an Studenten und als Leitfaden zur Unterstützung der praktischen Projektarbeit an die Benutzer in den Fachabteilungen und an die als Systementwickler tätigen Mitarbeiter der Abteilung "Organisation und DV/Information und Kommunikation" in Unternehmen. Der Text wurde geschrieben mit dem Textsystem HIT auf dem Siemens-Mikrocomputersystem MX-2; ein Teil der Abbildungen ist auf dem Siemens-Bürosystem 5800 erstellt worden. Für die kritische Durchsicht des Manuskripts und für Vorschläge zur inhaltlichen Änderung und Ergänzung danke ich meinen Mitarbeitern, Herrn Dipl.-Math. V. Lorenz und Frau cand.rer.oec. B. Orben. Besonderen Dank für die vielen fachlichen Anregungen, die ich in persönlichen Gesprächen und aus Praxisseminaren gewinnen konnte, schulde ich den Herren V. Barak (Ringier St Co AG), L.

Vorwort

IΧ

Baugatz (CIBA-GEIGY AG, Basel), Dr.N.Grau (Honeywell GmbH, Merz S. Co), G.R. Mannl (BAYER do Brasil), W.Schelldorfer (CIBA-GEIGY AG, Basel), Dr. R. Winkelmann (SIEMENS AG, München) und Η. Wülfert (CIBA-GEIGY do Brasil, CIBA-GEIGY AG, Basel). Schließlich danke ich Herrn Dipl.-Volkswirt M. Weigert vom R. Oldenbourg Verlag dafür, daß das Manuskript innerhalb kurzer Zeit als Buch veröffentlicht werden konnte. Herbert Kargl

Vorwort zur zweiten Auflage Die zweite Auflage wurde um einen praktischen Leitfaden für das Erarbeiten des Fachentwurfs und um eine Zusammenfassung der Analyse- und Entwurfsschritte ergänzt (s. Anhang S. 259 ff.). Herbert Kargl

1. Betriebliche DV-Anwendungssysteme Betriebliche DV-Anwendungssysteme dienen zur Unterstützung von ressortspezifischen Aufgaben im Unternehmen; das sind diejenigen Aufgaben, die sich aus den betrieblichen Funktionen ergeben: z.B. Vertrieb, Beschaffung, Produktion, Rechnungswesen, Personalwesen usw. Untergliedert man die ressortspezifischen Aufgaben in Planungs-, Vollzugs- und Kontrollaufgaben, so ergibt sich daraus eine Leitlinie für eine qualitätsbezogene Stufung von DV-Anwendungssystemen: - Operationssysteme - Informationssysteme - Planungssysteme Operationssysteme unterstützen die ressortbezogenen Administrations- und Dispositionsvorgänge: sie sind auf die Bearbeitung einer großen Zahl von gleichartigen, sich wiederholenden Ereignissen (z.B. Bearbeitung von Kundenaufträgen, Führung von Lagerbeständen, Freigabe von Produktionsaufträgen usw.) ausgerichtet und bilden damit die Basis für weitere DV-Unterstützungen im Unternehmen. Informationssysteme unterstützen ressortbezogene Planungsund Kontrollaufgaben und basieren auf den Daten, die im Rahmen von Operationssystemen angelegt, bearbeitet und abgelegt werden. Im Gegensatz zu Operationssystemen, die vollstrukturierte, routinehafte Entscheidungsprobleme weitgehend vollautomatisiert lösen können, sind Planungssysteme vorrangig auf die Unterstützung von nicht-vollständig strukturierbaren, nichtroutinehaften Entscheidungsproblemen ausgerichtet. Aufgaben werden im Unternehmen wegen der natürlichen Kapazitäts- und Leistungsgrenzen des Menschen arbeitsteilig durchgeführt; der sachliche Zusammenhang einer arbeitsteiligen

2

1. Betriebliche

DV-Anwendungssysteme

Aufgabenabwicklung bleibt aber dessen ungeachtet erhalten. Ein Beispiel aus dem Bereich der industriellen Fertigung diene zur Erläuterung: Die Teilaufgaben - Angebotsabgabe, - Auftragsbearbeitung, - Arbeitsvorbereitung, - Materialbewirtschaftung, - Produktionsplanung, - Fertigungsauftragsfreigabe, - FertigungsSteuerung, - Fertigwarenlagerverwaltung, - Versand, - Debitorenbuchhaltung, - Vertreter-Provisionierung, sind einerseits Ausdruck der Arbeitsteilung, andererseits sind sie durch die Ereignisse "abgegebenes Angebot" und "erhaltener Kundenauftrag" wegen der dadurch ausgelösten Vorgänge zu einer Vorgangs- bzw. Integrationskette verbunden. Werden diese Teilaufgaben jeweils einzeln dv-unterstützt, so erhält man Datenverarbeltungs-Inseln, die durch die Merkmale - Mehrfachexistenz gleichartiger Datenbestände, - wiederholte Dateneingabe, - unzureichende Datenabstimmung und damit mangelhafte Aktualität von Daten, - eingeschränktes Reaktionsvermögen auf Änderungen und - beschränkte Auskunfts- und Informationsmöglichkeiten, eingeengt auf das jeweilige Sachgebiet, gekennzeichnet sind. Diese Nachteile vermeidet eine integrierte Datenverarbeitungskonzeption, die die Zusammenfassung von arbeitsteilig durchgeführten Aufgaben zu Vorgangsketten ermöglicht. Für den Bereich von Operationssysteeen ist diese Integration innerhalb von Funktionalbereichen und Ubergreifend Uber Funktio-

1. Betriebliche D V-Anwendungssysteme

3

nalbereiche möglich; sie stellt die horizontale Integration dar. Nach einer solchen Konzeption kann sich die erforderliche Eingabe von Daten auf einen einmaligen Primärdateninput beschränken (z.B. Eingabe der Daten eines Kundenauftrags); die weitere Bearbeitung erfolgt dann gewissermaßen durch systeminternes "Weiterreichen" des auslösenden Ereignisses an die entsprechenden Programmfunktionen, und die Aktivitäten des Benutzers eines so konzipierten DV-Anwendungssystems können sich auf die Bearbeitung von Ausnahmefällen beschränken (Abb.1). Informationssysteme basieren auf den Daten von Operationssystemen; aufgrund der hierarchischen Gliederung von Aufgaben im Unternehmen sind für den routinehaften, vorstrukturierbaren Informationsbedarf stufenweise Informationsverdichtungen, aber auch gleichzeitig Informationsdetai11ierungen erforderlich (Abb.2); beides setzt die Existenz integrierter Operationssysteme voraus. Die Verdichtung und die fallweise Detaillierung von Informationen soll ohne gesondertes Umsetzen von Daten zwischen Operations- und Informationssystemen erfolgen können; dazu ist die vertikale Integration dieser Systeme erforderlich. Für den nicht-routinehaften, spontan auftretenden und demzufolge schwer vorstrukturierbaren Informationsbedarf ist der gezielte Zugriff des Benutzers sowohl zu verdichteten Daten wie auch zu unverdichteten Daten der Operationssysteme erforderlich. Planungssysteme sind als eine qualitätsgesteigerte Fortführung von Informationssystemen anzusehen; sie setzen gewissermaßen darauf auf und sind deshalb mit diesen integrativ zu verknüpfen. Voraussetzung dazu und insbesondere für jegliche Art von horizontaler und vertikaler Integration von Anwendungssystemen ist die Existenz einer gemeinsamen Datenbasis, auf die die diversen Programme der Anwendungssysteme zugreifen können (Abb.3). Aus den Erfordernissen nach Integration ergibt sich, daß Ope-

4

1. Betriebliche

DV-Anwendungssysteme

>ο η
£

00 S

C

117

118

3. Die Entwicklung der Fachkonzeption

Primäre Aufgabennerkmale:

Sekundäre Aufgabennerkaale:

1. 2. 3. 4.

Planbarkeit Komplexität Determiniertheit Kommunikationsintensität 5. Kooperationsintensität 6. Konstanz

Menge Zeit Ort Maßnahmen Aufgabenträger

Objekt (Woran?)

Verrichtung (Was?,Wie?)

Abb. 63: Aufgabenmerkmale

maß der Verknüpfungen von Aufgabenmerkmalen untereinander (Objekte, Verrichtungen, Menge, Zeit, Ort, Aufgabenträger); es ist z.B. Ausdruck für das Ausmaß der zu verknüpfenden Einzelaktivitäten, die für die Erfüllung einer Aufgabe erforderlich sind. Die Determiniertheit beschreibt das Ausmaß der Transparenz der Aufgabe; diese wird durch den Grad der Bestimmungen darüber geprägt, welche Ressourcen in welchem Umfang zur Aufgabenerfüllung einzusetzen sind (z.B. Problemlösungsalternativen, geeignete Maßnahmen, Informationsbedarf, Kenntnis der Konsequenzen von Problemlösungsverfahren usw.). Die Kommunikationsintensität gestattet Aussagen darüber, in welchem Ausmaß inner- oder außerbetriebliche Kommunikation nach Partnern, Wegen und Inhalt zur Aufgabenerfüllung erforderlich ist. Durch die Kooperationsintensität einer Aufgabe

3. Die Entwicklung

der

119

Fachkonzeption

wird ausgedrückt, in welchem Ausmaß die aktive, arbeitsteilige Partizipation anderer Stellen im Unternehmen zur Aufgabennerfüllung erforderlich ist. Das Merkmal Konstanz einer Aufgabe ist Ausdruck für die Stabilität des Sachziels (Aufgabe) selbst, der Komplexität, der Determiniertheit und sämtlicher weiterer Aufgabenmerkmale. Zur

Dokumentation der Analyseergebnisse Kommunikationsinten-

sität und Kooperationsintensität eignen sich

Interaktionsta-

bellen und Interaktionsdiagramme (Abb.64 u.65); die Analyse-

K o m m u n i k a t i o n s b e z i e h u n g e n der Stelle Verkauf Inland (t = M i n / M o n a t )

Informationsarten

Η φ ΐ ΐ !

Fertigungsvorbereitung

Auftragsabwicklung

!

4

Η φ ΐ ΐ ΐ

Η

φ ι ΐ ι

Η

φ ΐ ί ΐ

Η

κ

29 2 «

Fertigung

7

Lager

1 9 »

Fakturenstelle

2 7 2

Sonstiges

5 3 2

J

Sonstiges

Formalitäten

Finanzierungen

Sonderausstattung

n

Konditionen

Termin

Kommunikationspartner (berührte Stellen)

S

Σ t A b b . 6 4 : K o m m u n i k a t i o n s t a b e l l e ( S c h m i d t , G . , S. 1 8 4 )

Φ\Σ\

Η

Φt —t

120

3. Die Entwicklung

der

Fachkonzeption

Ohi-isifv 1 cnunfNntpan ki>nsiiuliir>n « Lnn*uklunji Fm» uLlunji kon-lruknon Patentbüro 7f n-hnung-jH hi\ l· ΐ'Πΐ^|||)|ί AihfiK\ofh«teiiuntf Bi'inrhslriiuny U nk/fufhJu lehn

Revision

Finkauf Maicnallapf Wrlaui ffriijila^fr « Vir^and U erhuny V erkauf Inland fc\pOM kundf njirnsi \tt* ahunjr BiKhhaliunj! f man/cn Planung Pfr>.onalhu'o Allgfm Diente

Abb. 65: Kommunikationsdiagramme (Schmidt, G., S. 186, 187)

3. Die Entwicklung der Fachkonzeption

121

ergebnisse nach den weiteren primären Aufgabenmerkmalen Planbarkeit, Komplexität, Determiniertheit und Konstanz sind zweckmäßigerweise in einer die Strukturdarstellungen von Aufgaben ergänzenden verbalen Merkmalsbeschreibung zu dokumentieren. Die modellorientierte Aufgabenanalyse geht von der Interpretation des Aufgabengefüges als System aus. Ein System wird allgemein aus Elementen und den Beziehungen zwischen Elementen gebildet. Für die modellhafte Abbildung eines Aufgabengefüges als System interessieren i.d.R. nicht die einzelnen Elemente, sondern Klassen gleichartiger Elemente, die als Elementemengen bezeichnet werden. Für die Beziehungen gilt das gleiche: nicht die individuelle Beziehung zwischen einzelnen Elementen interessiert, sondern die Klassen gleichartiger Beziehungen, die Beziehungstypen. Ein Aufgabenmodell ist demnach zunächst abstrakt durch Elementemengen und Beziehungstypen beschreibbar (Abb.66). Aus fachlicher Sicht läßt sich ein reales Aufgabengefüge modellhaft reduzieren auf Ereignisse, Zustände und Vorgänge (vgl. Wedekind/Ortner, 57). Ereignisse (Abb.67) sind Auslöser für Vorgänge (z.B. ein Kundenauftrag oder eine mündliche Anweisung zur Erstellung eines Verkaufsberichts) oder sie sind das Ergebnis abgeschlossener Vorgänge (z.B. ein geschriebener Lieferschein oder der erstellte Verkaufsbericht). Ereignisse finden im Unternehmen i.d.R. nicht frei schwebend statt, sondern sie sind an bestimmte "Bezugspunkte" gekoppelt; für die Ereignisse "Kundenauftrag", "Lieferschein" und "Verkaufsbericht" sind die zugehörigen Bezugspunkte z.B. "Kunde" und "Produkt". Gegenüber den Ereignissen stellen diese Bezugspunkte Zustände dar. Im Vertriebsbereich eines Unternehmens repräsentieren z.B. Kunde, Vertreter, Produkt, Lagerort, Lagerkonto, Debitorenkonto, Lieferant, Lieferantenkonto usw. Zustände, die Bezugspunkte für Ereignisse und Vorgänge sein können. Vorgänge beschreiben den Bearbeitungsprozeß, den Ereignisse erfahren (z.B. den Kundenauftrag prüfen und disponieren oder den Verkaufsbericht erstellen). Auch Vorgänge

122

3. Die Entwicklung der Fachkonzeption

Abb. 66: Zustandstypen und Beziehungstypen als Komponenten von Aufgabenmodellen

finden nicht freischwebend statt; sie benötigen ebenfalls Bezugspunkte. Direkte Bezugspunkte für Vorgänge sind die Ereignisse, denn Vorgänge werden dadurch ausgelöst oder haben Ereignisse als Ergebnis zur Folge. Bezugspunkte für die Ereignisse sind wiederum die Zustände, weshalb diese für die Vorgänge nur indirekte Bezugspunkte sind. Ereignisse, Vorgänge und Zustände bilden die Grundlage für zwei unterschiedliche, aber sich gegenseitig bedingende Sichtweisen auf ein Aufgabengefüge: die Informationssicht und die Vorgangssicht. Ereignisse und Zustände repräsentieren als Informationen die Informationssicht und die Vorgänge, die zu deren Verarbeitung erforderlich sind, repräsentieren die Vorgangssicht. Unter diesen beiden Sichtweisen ist die modellorientierte Aufgabenanalyse durchzuführen.

3. Die Entwicklung

Auslöseereignis

α Beispiel:

Abb. 67:

123

Ergebnisereignis

Vorgang

Ο Auftragsbestätigung

Kundenauftrag

o-

der Fachkonzeption

K.-Auftrag Prüfen + Disponieren

Ό

Ereignisse u n d V o r g ä n g e als K o m p o n e n t e n v o n A u f g a b e n m o d e l l e n

Zur modellhaften Abbildung des Aufgabengefüges als Systea sollen zunächst die Zustände und wegen den unmittelbaren Beziehungen dazu die Ereignisse herangezogen werden. Die Zustände - oder verallgemeinernd die Zustandstypen - sind aus fachlicher Sicht die elenentaren Bausteine für ein AufgabenSystem. Zustandstypen stehen i.d.R. in einem Beziehungszusammenhang untereinander; für die Zustandstypen "Kunde" und "Produkt" läßt sich dieser Beziehungszusammenhang z.B. beschreiben durch die Aussagen "Kunde bezieht Produkte", "Kunde hat Produkte bestellt" oder "Kunde wird mit Produkten beliefert". Diese Aussagen kennzeichnen die Beziehungstypen, durch die Zustandstypen miteinander verbunden werden. Der Beziehungstyp "Kunde hat Produkte bestellt" wird durch einen Kun-

124

3. Die Entwicklung der Fachkonzeption

denauftrag, also durch ein Ereignis, repräsentiert; diese Art von Beziehungen soll als evidenter Beziehungstyp bezeichnet werden. Demgegenüber ist der Beziehungstyp "Kunde bezieht Produkte" (der Kunde ist also zunächst nur als Mitglied des Kundenkreises dokumentiert) ein latenter Beziehungstyp, denn es fehlt noch an einer Konkretisierung der Beziehung in Form von Ereignissen; dieser latente Beziehungstyp wird dann zu einem evidenten Beziehungstyp, wenn z.B. das Ereignis "Verkauf sbericht", das auf der Beziehung "Kunde bezieht Produkte" basiert, oder das Ereignis "Kunde hat Bestellung erteilt", vorliegt (Abb.68). Für die Anforderungs-Ermittlung sind zu-

Abb. 68: Evidente und latente Beziehungstypen

nächst die Ereignisse in einem Aufgabengefüge von vorrangigem Interesse; deshalb beginnt die modellorientierte Aufgabenanalyse mit einer Strukturierung des Aufgabengefüges nach Zustandstypen und nach evidenten Beziehungstypen, den Ereignisstypen (Abb.69).

3. Die Entwicklung der

-

Fachkonzeption

125

Anfrage Besuchsankündigung Auftrag Mitteilung über Produktinformation EREIGNISSTYP

Abb. 69: Aufgabenmodell (Zustandstypen, Ereignistypen dargestellt am Beispiel des Bereiches „Auftragsbearbeitung und Vertrieb")

Die bisher dargestellten Beziehungstypen sind noch einfach, denn sie beziehen sich ausschließlich und direkt auf zwei Zustandstypen. Neben diesen einfachen Beziehungstypen gibt es auch komplexe Beziehungstypen, die sich sowohl auf mehrere Zustandstypen beziehen als auch untereinander in Beziehung stehen können und somit die zugehörigen Zustandstypen indirekt verbinden. Ein Beispiel für einen latenten komplexen Beziehungstyp ist die Aussage "Kunde bezieht Produkte und ist Lieferant und Anteilseigner"; die dadurch referierten Zustandstypen sind Kunden, Lieferant und Anteilseigner. Ein

126

3. Die Entwicklung

der

Fachkonzeption

Beispiel für einen evidenten komplexen Beziehungstyp ist ein Kundenauftrag, der je nach den speziellen Gegebenheiten eine Auftragsbestätigung, einen Lieferauftrag, einen Verpackungsauftrag und ein Verzeichnis der Auslieferungsrückstände als Folge-Ereignistypen induziert, die untereinander in Beziehung stehen. Abb.70 stellt diese Beziehungsstruktur in Form eines Graphen , Abb.71 in Form einer praktikableren Matrix dar. Nach der Strukturierung des Aufgabengefüges in Zustandstypen und in evidente und latente Beziehungstypen ist eine Strukturierung der Vorgänge erforderlich. Vorgänge beschreiben den Bearbeitungsprozeß, den Ereignisse erfahren; der geeignete Ansatzpunkt für das Erarbeiten einer Vorgangsstruktur sind deshalb die Ereignisse. Diese sind in Auslöse-Ereignistypen und Ergebnis-Ereignistypen zu gruppieren; damit ist die Voraussetzung für eine Wirkungsanalyse des Realitätsausschnitts nach der Black-Box-Betrachtung geschaffen, wozu die AuslöseEreignistypen als Input und die Ergebnis-Ereignistypen als Output zu definieren sind. Die sich daran anschließende Strukturanalyse führt dann zu einem ersten Umriss der Vorgänge, die für die Transformation der Auslöse-Ereignistypen in in Ergebnis-Ereignistypen erforderlich sind. Dazu ist es zweckmäßig, den Transformationsprozeß gedanklich in Abiaufschritte zu zerlegen und daraus zunächst die wichtigsten Vorgänge zu formulieren. Die Darstellung der so erarbeiteten Vorgänge kann sich zu Zwecken der Anforderungsermittlung auf eine tabellarische Aufzählung beschränken; allfällige Präzisierungen dazu werden zweckmäßigerweise in der nachfolgenden Stufe der Anforderungsspezifizierung vorgenommen. In Abb.72 und 73 ist diese Vorgehensweise an einem Beispiel dargestellt. Neben Ereignissen und Vorgängen sind die aufgabenspezifischen Bedingungen für die geplante DV-Unterstützung zu definieren. Unter dem Aspekt der qualitativen Aufgabenerfüllung sind es die Bedingungen, die sich aus gesetzlichen Vorschriften, insbesondere z.B. aus den Vorschriften zur Ordnungsmäßigkeit der

3. Die Entwicklung

der Fachkonzeption

^ K u n d ^

Θ

1

Θ I

©

Θ

Θ r

6

Erläuterung: 1 2 3 4 5 6

= = = = = =

Kunden-Auftrag Auftragsbestätigung Lieferauftrag Lieferschein Verzeichnis der Auslieferungsrückstände " P r o d u k t . . liegt auf L a g e r . . ' " L a g e r . . hat.. Produkte auf Lager" (latender Beziehungstyp)

A b b . 70:

Komplexe Beziehungstypen

J

127

128

3. Die Entwicklung der Fachkonzeption

JX

Zustandstyp en

Ere qnistype η

Κ u η d e

Au Lf. Lf. V ftr. Au sch ZΒ ftr. ein R S e st

Ρ r ο d.

L a 9 e r

Kunde Ζ τ

Kd. A u f tr. X

Produkt Lager

X X

X

KD-Auftr. Ε Auftr.Best. Τ

X X

LF-Auftr. LF-Schein VZRS

X

X X

X X

X X

X

X

X X

X

A b b . 7 1 : Matrix der Beziehungsstruktur bei komplexen Beziehungstypen

3. Die Entwicklung der Fachkonzeption

I Ν Ρ U Τ (Auslöse -Ereignistypen) Kunden-Anfragen Verteter-Aufträge Retouren Auftrags-Abrufe

Kunden-Aufträge Auftragsänderungen Neukunden-Zugänge Ad-hoc-Informationsbedarfe

1

A b b . 7 2 : Wirkungsanalyse

129

130

3. Die Entwicklung der

Fachkonzeption

I Ν Ρ 0 Τ (Auslöse- Ereigni.stypen) Kunden-Anfragen Verteter-Aufträge Retouren Auftrags-Abrufe

I

Kunden-Aufträge Auftragsänderungen Neukunden-Zugänge Ad-hoc-Informationsbedarfe

AUFTKAGSBEASBEITUNG UND VERTRIEB: Routine-Vorgänge: Angebote bearbeiten

Auftragsbestätigung erstellen

Auslieferung - Lieferschein schreiben - Versanddokumente sehr. - Auslieferung rückmeld.

Aufträge bearbeiten - Bonität prüfen - Verfügbarkeit pr. - Reservieren Aufträge verwalten - Fälligkeit überw. - Rückstände überw. - Zuteilen - Auslieferung freig. - Auftragsänderungen bearbeiten Auftragsabrechnung - Faktura erstellen - Aufträge nachkalk.

Nicht-Routine-Vorgänge: - Kundenanfragen - Sachbearbeiteranfragen

i 0 ü Τ Ρ υ τ (Ergebnis- Ereignistypen) Angebote an Kunden Liste reservierter Produkte Lieferfreigaben Faktura Zahlungsüberweisungs belege

Auftragsbestätigung Liste der Auslieferungsrückstände Versanddokumente Provisionsabrechnung Auftragseingangsstatistik

Abb. 73: Strukturanalyse

3. Die Entwicklung

der

Fachkonzeption

131

Rechnungslegung und aus den Vorschriften zum Datenschutz ergeben. Daneben können es £achspezi£ische Bedingungen sein, die aus der Einbindung des geplanten DV-Anwendungssystems in eine bestehende Infrastruktur von DV-Anwendungen oder aus den anwendungsspezifischen Gegebenheiten anderer geplanter DVVorhaben resultieren. Unter QuantitätsaspeXten zur Aufgabenerfüllung sind die gegenwärtigen und die zukünftig zu erwartenden Mengen an Ereignissen und Zuständen sowie die gegenwärtigen und zukünftigen Häufigkeiten von Vorgängen in Form eines Mengengerüstes zu definieren. Die modellorientierte Aufgabenanalyse führt implizit auch zu einer modellhaften Ermittlung des Informationsbedarfs, denn Ereignisse und Zustände sind Träger von Informationen. Für die Zwecke der Anforderungs-Ermittlung genügt es i.d.R., den Informationsbedarf zunächst der Art nach, aber noch nicht dem Inhalt nach zu definieren. Die Art des Informationsbedarfs wird durch die evidenten Beziehungstypen (Ereignistypen) dargestellt (z.B. Kunden-Anfrage, Verzeichnis der verfügbaren Lagerbestände). Die inhaltliche Darstellung dieses Informationsbedarfs erfolgt entsprechend dem Grundsatz der schrittweisen Verfeinerung in der Phase der Anforderungs-Spezifizierung; dazu sind die Ereignis- und Zustandstypen in ein Datenmodell zu Uberführen. Außer dieser Methode zur modellhaften Ermittlung des Informationsbedarfs bieten sich noch folgende Wege an: - Ermittlung des Informationsbedarfs aus Ziel-Mittel-Beziehungen, - Ermittlung des Informationsbedarfs aus der Regelkreisanalogie von Aufgaben. So wie Ziel-Mittel-Beziehungen eine Eingrenzungshilfe für das Erarbeiten von geeigneten Maßnahmen zur Zielerreichung geben, so geben sie auch eine Eingrenzungshilfe für die Ermittlung zielrelevanter Informationen: Ziele induzieren Maßnahmen (Mittel) und Maßnahmen induzieren Informationen. In Abb.74 ist dieser Sachverhalt an einem Beispiel erläutert.

132

3. Die Entwicklung

der

Fachkonzeption

Beispiel:

ΙZIEL:

"Steigerung des Deckungsbeitrags in Produktgruppe χ um 10% in Planperiode y"

Maßnahae: Produkte mit DB > a forcieren

—I HaQnahae: | Marktsegmentierung verfeinern

Inf onationen: - Umsatz - Deckungsbeitrag - ausgabewirksame Kosten - nicht-ausgabewirksame Kosten Informationen: - demographische Marktdaten - psychographische Marktdaten

Abb. 74: Kausalketten von Zielen/Maßnahmen/Informationen

3. Die Entwicklung der Fachkonzeption

133

Die Ermittlung des Informationsbedarfs aus der Regelkreisanalogie von Aufgaben setzt an der als Regelkreis interpretierten Abfolge der Schritte Planung, Entscheidung, Vollzug und Kontrolle an; ein solcher Regelkreis besteht aus (Abb.75): - der Regelstrecke als Bezeichnung für die Aufgabe (Sachziel), - dem Aufgaben-Input und dem Aufgaben-Output (Auslöse-Ereignisse und Ergebnis-Ereignisse) , - dem Ziel für die Aufgabe (Formalziel), - dem Regler als Bezeichnung für den Aufgaben träger (Mensch und/oder Maschine), - den Kontrollinforaationen, die als Feedback zur Regelung des Prozesses der Aufgabenerfüllung benötigt werden und - den Entscheidungen, die im Prozeß der Aufgabenerfüllung erforderlich sind.

o:

A b b . 7 5 : Regelkreisanalogie des Prozesses der Aufgabendurchführung

134

3. Die Entwicklung der Fachkonzeption

Für die Ermittlung des Informationsbedarfs sind zunächst die Regelstrecke, der Input und der Output durch eine Aufgabenanalyse modellhaft darzustellen; danach sind folgende Fragen zu stellen: "Welche typischen Entscheidungen sind in dem Aufgabenfeld zu treffen?" "Welche typischen Informationen sind zur Vorbereitung und Kontrolle dieser Entscheidungen erforderlich?" Durch Gegenüberstellung dieser Fragen vor dem Hintergrund eines Aufgabenmodells in Form von Ereignissen und Vorgängen ergeben sich Orientierungshilfen für die Ermittlung relevanter Informationen (Abb.76).

Regelstrecke

: Führung von Lagerbeständen

Ziel

: Bedarfskonforme Lagerverfügbarkeit bei Minimierung der Kapitalbindung und der Lagerhaltungskosten

Entscheidungen:

Stützende Informationen-.

- E. Uber Bestellmengen und Bestelltermine

- Bestand: verfugbar, reserviert. - Bedarf : Bestand, Zugang, prognostiziert. - Eindeckung - Bestell-Aussenstände - Kapitalbindung im Lager - Bestellkosten - Bestellmengenvorschlag (wirtsch. Losgröße)

- E. Uber Eilbeschaffung

- Kosten für Eilbeschaffung - Fehlmengenkosten - Lieferfähigkeit der Lieferanten

- E. bei Qualitätsmängeln

- betroffene Mengen - betroffene Produkte - eigenes Lieferobligo der betroffenen Produkte (Mengen, Kosten) - Ausweichmaterialien - Ersatz-Lieferanten

A b b . 7 6 : Beispiel z u r E r m i t t l u n g des I n f o r m a t i o n s b e d a r f s aus der Regelkreisanalogie von Aufgabenprozessen

3. Die Entwicklung

der

Fachkonzeption

135

3.2.3.4 Technikspezifische Anforderungen Die technikspezifischen Anforderungen können sich zu Zwecken des Erarbeitens der fachlichen Leistungen entsprechend dem Grundsatz der Trennung von Essenz und Inkarnation i.d.R. auf folgende rudimentäre Aussagen über die benötigte technische Infrastruktur beschränken: - grober Umriss der Hardware-Konfiguration hinsichtlich der benötigten Speicher- und Verarbeitungskapazitäten sowie Art und Anzahl der erforderlichen DV-Arbeitsplätze, abgeleitet aus dem Mengengerüst, - Realtime-Erfordernisse, die sich aus den aufgabenspezifischen Anforderungen ergeben: - Aufgabenart (Stapel/Dialog), - max. System-Antwortzeiten, - geforderte Systemverfügbarkeit während und ausserhalb der üblichen Arbeitszeit, - max. tolerierbare Systemausfallzeiten bei zeitkritischen Aufgaben, - Vorgaben über technische Ersatzmaßnahmen, die bei Systemausfällen zu ergreifen sind. 3.2.3.5 Benutzerspezifische Anforderungen Die benutzerspezifischen Anforderungen beziehen sich auf die Gestaltung der Schnittstelle zwischen Benutzer und DV-Anwendungssystem, auf die Gestaltung der Nutzungsberechtigung und auf die Einbindung des DV-Anwendungssystems in das personelle Umfeld im Unternehmen. Für die Schnittstelle Benutzer - DV-Anwendungssystem ist aus fachlicher Sicht die Gestaltung der Benutzeroberfläche von Bedeutung. Die Vorgaben dazu können sich erstrecken auf die aufgabenspezifisch bedingte Art von Eingabe und Ausgabe (Da-

136

3. Die Entwicklung

der

Fachkonzeption

ten, Text, Bild, Sprache) und auf die arbeitsplatzspezifischen Hardware-Komponenten. Je nach den Aufgabenerfordernissen lassen sich hierzu unterscheiden universelle und spezielle Benutzer-Hardware. Die universelle Benutzer-Hardware umfaßt generell verwendbare Komponenten für die Ein- und Ausgabe (z.B. Datensichtstationen, lokale Drucker) und für die Datenverarbeitung vor Ort (z.B. Mikrocomputer); zur speziellen Benutzer-Hardware zählen diejenigen Hardware-Komponenten, die für fachspezifische Aufgabenstellungen erforderlich sind (z.B. CAD-Terminals, Plotter, Geräte zur Betriebsdatenerfassung) . Durch die Gestaltung der Nutzungsberechtigung werden Aussagen darüber gemacht, welche Benutzer auf welche Teile des DV-Anwendungssystems in welcher Form und in welchem Umfang Zugriff sberechtigt sind. Die Details dazu sind zweckmäßigerweise in der Phase Anforderungsspezifizierung zu regeln. Die benutzerspezifischen Anforderungen hinsichtlich der Einbindung des DV-Anwendungssystems in das personelle Umfeld können sich beziehen auf Aufgabenträger und Stellen, denen bestimmte fachliche Leistungen des DV-Anwendungssystems zugeordnet werden sollen, und auf die zukünftigen Benutzer selbst; dies können sein - Anforderungen an die Qualifikation der Benutzer: - fachliche Qualifikation, - physische Qualifikation, - geistige Qualifikation und - Anforderungen an die Aus- und Weiterbildung, der sich die zukünftigen Benutzer unterziehen müssen. 3.2.3.6 Überprüfung der Anforderungen Im Anschluß an das Erarbeiten der Anforderungen sind diese einer kritischen Prüfung zu unterziehen, die sich auf das

3. Die Entwicklung

der

Fachkonzeption

137

Prüfen formaler Mängel und auf das Prüfen inhaltlicher Mängel erstreckt. Gegenstand der Prüfung auf formale Mängel ist die Dokumentation zum fachlichen Basiskonzept, die auf Vollständigkeit und Verständlichkeit zu überprüfen ist, und das Phasen-Management, bei dem die Verwendung der dazu vorgeschriebenen Unterlagen (Zeitplan, Mitarbeiter-Einsatzplan, Verantwortungsmatrix usw.) zu prüfen ist. Ansatzpunkte zur Prüfung auf inhaltliche Mängel sind die Problemursachen, die Ziele und die kritischen Erfolgsfaktoren, denen die bisher erarbeiteten Lösungsvorschläge zu einem kritischen Review gegenübergestellt werden. In Bezug auf die Problemursachen sind die ermittelten aufgaben-, technik- und benutzerspezifischen Anforderungen darauf zu überprüfen, welchen Beitrag sie zu deren Behebung leisten. Ein geeignetes Instrument dazu sind die sog. Prüfmatrizen, in denen existierende oder vermutete Mängel den möglichen Mängelursachen gegenübergestellt werden. Nach einem allgemeinen Gliederungsschema lassen sich dazu unterscheiden (vgl. Schmidt 260): MÄNGEL : - Mängel in der Aufgabenerfüllung - überflüssige Aufgaben, - notwendige Aufgaben: - nicht erfüllt, - schlecht erfüllt, - Mängel in der Wirtschaftlichkeit der Aufgabenerfüllung (Kosten/Leistungen), - Mängel im Arbeitsumfeld. MANGELURSACHEN: - der Prozeß der Faktorkombination und - die eingesetzten Faktoren. Eingesetzte Faktoren (Input) zur Aufgabenerfüllung sind Information (Ereignis) und Aufgabenträger (Mensch und/oder Technik) ; Komponenten des Prozesses der Faktorkombination (Input-Transformation) sind Zustände, Vorgänge (i.e.S. Vorgangstyp, methodische Unterstützung und Ablaufgestaltung), Stellenbildung, Stellengliederung, Kompetenz und Kommunikation. Verfolgt man in einer so gebildeten Matrix je Zeile

138

3. Die Entwicklung

der

Fachkonzeption

(Mängelart) die zugehörigen Spalten ( Bereiche möglicher Mängelursachen) , so erhält man dadurch eine Hilfe für das systematische Eingrenzen der tatsächlichen Mängelursachen (Abb.77); an diesen sind dann die Lösungsvorschläge zu messen. Mögliche Mängelursachen

Sachmittel

Input

Information

Raum-/zeitliche Strukturierung (Ablauforganisation)

Kombination der Stellen (Hierarchie und allgemeine Kommunikation

Kombination der Stellenaufgaben (Stellenbildung)

Transformation und Kombination

Aufgabenträger

Mögliche Mängel

Aufgabenerledigung Wirtschaftlichkeit Unerwünschte Auswirkungen

Abb. 7 7 : Prüfmatrix (Schmidt, G „ S. 263)

Hinsichtlich der Ziele und der kritischen ErfolgsfaXtoren für den Gestaltungsbereich ist zu überprüfen, welche Bedeutung der erarbeitete Lösungsvorschlag für deren Erfüllung hat. Dazu eignen sich wertanalytische Fragestellungen wie z.B.: - Sind die geforderten fachlichen Leistungen prinzipiell nötig? - Wer ist der Adressat der fachlichen Leistungen? - Wozu dienen die fachlichen Leistungen? - Welchen Nutzen haben die fachlichen Leistungen für den Adressaten?

3. Die Entwicklung der Fachkonzeption

- Welche Kosten verursacht der fachlichen Leistungen?

139

das Erstellen

- Können die geforderten fachlichen Leistungen in anderer Form und zu niedrigeren Kosten erbracht werden? - Gibt es andere fachliche Leistungen, durch die das Anspruchsniveau des Adressaten besser erfüllt werden kann? - Welche Konsequenzen ergeben sich aus dem Verzicht auf die geforderten fachlichen Leistungen? Zur Unterstützung dieser Fragestellungen kann das Schema der Nutzwertanalyse herangezogen werden (s.Kap.5). Die inhaltliche AnfOrderungsüberprüfung erfolgt zweckmäßigerweise in Form von strukturierten Gruppengesprächen. Das Ergebnis der Überprüfung ist in einem Prüfprotokoll ("Reviewbericht") zu dokumentieren, in dem u.a. die wichtigsten festgestellten Mängel sowie Empfehlungen zu deren Beseitigung enthalten sein sollen.

3.2.3.7 Dokumentation Das Ergebnis der Phase "Anforderungsermittlung" sind die fachlichen Leistungen des geplanten DV-Anwendungssystems, dargestellt durch Ereignisse, Vorgänge und Bedingungen (Muss/Kann-Bedingungen), die die Grundlage für das fachliche Basiskonzept sind. Für die Projektarbeit ist es zweckmäßig, dieses Konzept in die Teile fachliche Basislösung, technische Basislösung und organisatorische Basislösung zu unterteilen, die dann als Entscheidungsgrundlage für das weitere Projektprocedere dienen. Die Gliederung des formellen Rahmens dazu ist in Abb.78 dargestellt. Ein Beispiel zur inhaltlichen Gestaltung des fachlichen Basiskonzepts enthalten in den we-

140

3. Die Entwicklung der

Fachkonzeption

1. Veranlassende Stelle 2. Bezeichnung des Vorhabens 3. Kategorie des Vorhabens: - Anwendungs-Neuentwicklung - Anwendungs-Ergänzung - Anwendungs-Ersatz 4. Ziele (revidierte Zielvorstellungen) 5. Kritische Erfolgsfaktoren

6. Basislösung: (1) Fachliche Basislösung (2) Technische Basislösung (3) Organisatorische Basislösung 7. Bedingungen, die bei der Realisierung der Basislösung zu berücksichtigen sind: (1) fachspezifische Bedingungen (2) technikspezifische Bedingungen (3) benutzerspezifische Bedingungen 8. Projekt-Kosten - Entwicklungskosten - Folgekosten 9. Pro j ekt-Nutzen - quantitativer Nutzen - qualitativer Nutzen 10. Projekt-Priorität

A b b . 78: Gliederung des formalen Rahmens für das Fachliche Basiskonzept

3. Die Entwicklung

der Fachkonzeption

141

sentlichen Auszügen die Abb. 79 und 80. Neben dieser Produktdokumentation zesses

i.d.R.

fallen

noch als Dokumente des Produktionspro-

Zielstrukturen (z.B. Abb.55),

(Zustandstypen,

Ereignistypen,

Vorgänge;

73), definierte Bedingungen sowie

die

zur

Abb.69, 72,

Ergebnisse der Bewer-

tung von verschiedenen Lösungsalternativen mentation eines Beispiels

Aufgabenmodelle

z.B.

an. Auf die Doku-

organisatorischen Basislösung

wurde verzichtet.

( Analysebereich AUFTRAGSBEARBEITUNG und VERTRIEB

Abb. 79: Schnittstellen zum Umsystem

142

3. Die Entwicklung der

Fachkonzeption

1. Veranlassende Stelle: Leitung Vertrieb 2. Bezeichnung des Vorhabens: Reorganisation von Auftragsbearbeitung und Vertrieb 3. Kategorie des Vorhabens: Anwendungs-Ersatz 4. Ziele:

Zielgewicht:

(1) Verbesserung der Lieferbereitschaft - Durchlaufzeit In der Fertigung um 20% reduzieren, - Durchlaufzeit für Fremdbezugsaufträge um 10% reduzieren, - offene Bestellaufträge laufend überwachen, - Wareneingänge tagfertig den Lägern zuordnen, - Fertigprodukte und Teile bedarfskonform disponieren, - bei Produkten der Kategorie A i9t ein Servicegrad von 80% zu halten

40 %

(2) Verbesserung des innerbetrieblichen Informationsflusses: - Vermeidung von wiederholtem Primärdaten- Input, - Vermeidung von Medienbrilchen, - Zugriff zu permanent aktualisierten und konsistenten zentralen Datenbeständen, - Erhöhung der Erreichbarkeit der innerbetrieblichen Kommunikationspartner.

60 \

5. Kritische Erfolgsfaktoren: -

Termintreue und Mengentreue bei den Auslieferungen, Qualitätstreue bei den Produkten, Flexibilität gegenüber Kundenwünschen, Reaktionsschnelligkeit auf Kundenanfragen und Auftragsänderungen.

A b b . 8 0 : Beispiel für ein fachliches Basiskonzept

3. Die Entwicklung

der

Fachkonzeption

6. Basislösung: 6.1 Fachliche Basislösung: 1. Schnittstellen zu· Uasyste·: - Lagerhaltung, - Fertigungsdisposition, - Debitorenbuchhaltung, - Vertreterabrechnung, - Speditionsdisposition. 2. Vorgänge A. DV -Unterstützung von Routine-Vorgängen: 2. 1 Angebote bearbeiten 2. 2 Aufträge bearbeiten - Bonität prüfen - Verfügbarkeit prüfen - Lagerbestände reservieren 2.3 Auftragsbestätigung erstellen 2.4 Aufträge verwalten - Fälligkeiten überwachen - Rückstände überwachen - Zuteilen - Auslieferung freigeben - Auftragsänderungen bearbeiten 2. 5 Auslieferung - Lieferschein schreiben - Versanddokumente schreiben - Auslieferung rückmelden 2.6 Aufträge abrechnen - Faktura erstellen - Aufträge nachkalkulieren B. DV-Untersttltzung von situationsbedingten Vorgängen: - Kundenanfragen Uber - das Liefersortiment, - die Lieferfähigkeit, - den Auslieferungsstand von erteilten Aufträgen, usw. - Sachbearbeiteranfragen über - Lieferobligo für bestimmte Kunden, - Bonität bestimmter Kunden, - selektierte Bestellstatistiken, usw.

A b b . 80: Beispiel für ein fachliches Basiskonzept (Fortsetzung)

143

144

3. Die Entwicklung

der

Fachkonzeption

3. Mengenangaben: (Zustandstypen, Ereignistypen) Anzahl der Aufträge : ca. 100 pro Tag Anzahl der Kunden : ca. 1.500 Anzahl der Produkte : ca. 1000 usw. 4.Informations- und Kouunikationbeziehungen: (s. gesonderte Darstellung) 6.2 Technische Basislösung: - vernetzbares Mehrplatz-Mikrocomputersystem mit 6 Arbeitsplätzen, das als Abteilungsrechner mit Kopplungsmöglichkeit an den Zentralrechner betrieben werden kann - Arbeitsspeicherkapazität: 4 MB - Externspeicherkapazität : 200 MB - 1 Abteilungsdrucker - 2 Hardkopy-Drucker - Mailboxsystem für die interne Nachrichtennübermittlung. 6.3 Organisatorische Basislösung: (s. gesonderte Dokumentation) 7. Bedingungen: 7.1 Fachspezifische Bedingungen: - Gestaltung der DV-Unterstiitzung als System integrierter Vorgangsketten, - viersprachige Fakturierung, - Fakturierung wahlweise in Inlands- oder Auslandsvaluten, - bedarfsgesteuerte Lagerhaltung nach einem saisonalmodifizierten Verfahren der exponentiellen Glättung erster Ordnung, da die Bedarfsschwerpunkte saisonal anfallen, - Plausibiltätskontrollen für sämtliche Dateneingaben. 7.2 Technikspezifische Bedingungen: Für das nationale und internationale Geschäft sind die Standardisierungsvorschriften für ΕΑΝ und EDI zu berücksichtigen, Antwortzeitverhalten < 2 sec. 8. Pro J ektkosten: (s. gesonderte Aufstellung) 9. Projektnutzen: (s. gesonderte Aufstellung)

Abb. 80: Beispiel für ein fachliches Basiskonzept (Fortsetzung)

3. Die Entwicklung der Fachkonzeption

145

3.3 Die Anforderungsspezifizierung 3.3.1 Das Gestaltungsobjekt In diesem Schritt der Systemgestaltung werden die aufgabenspezifischen, technikspezifischen und benutzerspezifischen Anforderungen, die zusammen das fachliche Basikonzept bilden, zum fachlichen Detailkonzept verfeinert. Gestaltungsobjekte sind hierbei Informationsstrukturen und Vorgangsstrukturen, die Benutzerschnittstelle zum DV-Anwendungssystem und das Konzept zur Einbettung des zu entwickelnden DV-Anwendungssystems in das organistorische Umfeld. Informationsstrukturen sind das Ergebnis der Transformation von Zustandstypen und Ereignistypen in Informationsobjekte, Beziehungen und Attribute, und sie beschreiben dadurch die Art und den Zusammenhang der Objekte, die einer Bearbeitung durch Vorgänge unterliegen. Vorgangsstrukturen beschreiben den statischen und dynamischen Zusammenhang der fachspezifischen Vorgänge, die auf die Bearbeitung der Informationsobjekte anzuwenden sind. Die Benutzer-Schnittstelle wird durch die Dialogführung, die Bildschirmmasken und den Listenoutput eines DV-Anwendungssystems gebildet. Komponenten des Konzeptes der Einbettung des DV-Anwendungssystems in das organisatorische Umfeld sind der Arbeitsfluß sowie die Gliederung von Aufgaben und Stellen. Das Ergebnis der Phase "Anforderungsspezifizierung" wird in Form der fachlichen und organisatorischen Detaillösung dokumentiert (Abb.81). Der Inhalt dieser Phase ist in Abb.82 dargestellt; die wichtigsten Instrumente und Unterstützungshilfen, die für die Phasenaktivitäten benötigt werden, sind in Abb.83 zusammengestellt. Die technische Detaillösung, für die aus der Phase Anforderungsermittlung die Basislösung vorliegt, kann aufgrund der hierzu notwendigen weiteren Angaben (z.B. Uber das Programmsystem, das Datensystem, die Datenübertragungsraten etc.) sinnvollerweise erst in der nachfolgenden Entwicklungsstufe der Systemkonzeption erstellt werden.

146

3. Die Entwicklung

der

1. Phasenergebnis:

Fachkonzeption

Fachliches Detailkonzept

2. Beschreibung durch: (1) Fachliche Detaillösung - Schnittstellen und Schnittstelleninhalte zum Umsystem - Informationsstruktur - Informationsobjekte - Beziehungen - Attribute - Vorgangsstruktur: - statisch - dynamisch - Vorgangsbeschreibung: - Vorgangs-Input - Vorgangs-Output - Verarbeitungsvorschrift - Vorgangsauslöser - Vorgangsart - Datenmengen - Bewegungsdaten - (Ereignisse) - Stammdaten (Zustände) - Schllisselsysteme - Benutzerschnittstelle: - Bildschirmmasken-Layout - Listen-Layout - Dialogstruktur (2) Organisatorische Detaillösung -

Belegflußplan Aufgabengliederungsplan Stellengliederungsplan Umstellungs- und Einführungsplan - Schulungsplan

Abb. 81:

Ergebnisbeschreibung für die Projektphase „ANFORDERUNGSSPEZIFIZIERUNG"

3. Die Entwicklung der Fachkonzeption

1. Phasenziel

überprüfen und Transformieren des fachlichen Basiskonzepts in das fachliche Detailkonzept

2. Phasenmanagenent

Voraussetzung: genehmigter Projektauftrag Zeitplan, Mitarbeiter-Einsatzplan, Zuständigkeiten

3. Phasenergebnis

(1) Fachliche Detaillösung (2) Organisatorische Detaillösung

4. Phasenaktivitäten

Untersuchungsbereich abgrenzen, Schnittstellen und Schnittstelleninhalte zum Umsystem definieren, Informationsstruktur erstellen, Statische Vorgangsstruktur erstellen, Vorgangsbeschreibung erstellen, BS-Maskenlayout entwerfen, Listenlayout entwerfen, BS-Maskenfolgen entwerfen, Dynamische Vorgangsstruktur erstellen, Datenmengen definieren, Schlüsselsysteme erstellen, organisatorische Detaillösung erarbeiten, Akzeptanz prüfen, Nutzen begründen.

5. Phasenkontrolle

Qualitätsprüfung: formale und inhaltliche Ergebnisprüfung

6. Phasenentscheidung

Genehmigung, Ablehnung oder Rückverweis des fachlichen Detailkonzepts; bei Genehmigung: Erteilen eines Auftrages zur Erstellung der Systemkonzeption

Abb. 82: Inhalt der Projektphase „ A N F O R D E R U N G S S P E Z I F I Z I E R U N G

147

148

3. Die Entwicklung

der

Fachkonzeption

Phase SITUATIONSSTUDIE

Phase - Outside-in-Ansatz - funktionsorientierter und variablenorientierter Ansatz - Objekttypen-BeziehungenAnsatz - Black-Box-Technik - Hierarchisches Strukturieren - Baumstrukturen -Tabellenstrukturen - Netzstrukturen - IPO/EVA-Dokumentation - Entscheidungstabellen - Präzedenz-Matrizen - Prototyping - Data Dictionary

ANFORDERUNGS ERMITTLUNG

Abb. 83: Instrumente/Unterstützungshilfen für die Phase ANFORDERUNGSSPEZIFIZIERUNG

3. Die Entwicklung

der Fachkonzeption

149

3.3.2 Die Vorgehensmethode Die Vorgehensmethode zur Spezifizierung der Anforderungen ist in besonderem Maße durch die systemtheoretische Orientierung geprägt; dies zeigt sich in der konsequenten Abfolge von schrittweiser Verfeinerung und hierarchischer Strukturierung beim Spezifizieren der Anforderungen. Weiter ist nach dem funktionsorientierten und variablenorientierten Ansatz vorzugehen; für diese Phase bedeutet dies, daß die Anforderungsspezifikation aus der Vorgangssicht und der Informationssicht auf das Aufgabengefüge des Benutzers zu erstellen ist. Dazu sind Informationsstrukturen und Vorgangsstrukturen zu erstellen. Da der Benutzer in der Fachabteilung aus der Sicht der von ihm durchzuführenden Aufgaben vorrangig in Tätigkeiten und damit in Vorgängen denkt, wird der Einstieg in die Spezifizierung der Anforderungen i.d.R. Uber die Strukturierung der Vorgänge erfolgen. Parallel dazu ist die Informationsstruktur zu entwickeln, denn aufgrund der Interdependenz von Informationssicht und Vorgangssicht lassen sich nur so schlüssige und konsistente Anforderungsspezifikationen erarbeiten. Durch diese Vorgehensweise entstehen i.d.R. zunächst Vorgangs-Teilstrukturen (Abb.84), die danach zu einer Vorgangs-Gesamtstruktur zusammenzufassen sind (s.z.B. Abb. 108 und 109). Von besonderer Bedeutung ist in dieser Phase die Beachtung des Prinzips der Trennung von Essenz und Inkarnation. Im Rahmen der Anforderungsspezifizierung sind die bisher ermittelten fachlichen Anforderungen durch eine Reihe weiterer entwurfsrelevanter Merkmale zu ergänzen. Entsprechend diesem Prinzip sind hier jedoch nur solche Merkmale zu spezifizieren, die für den Entwerfer eines DV-Anwendungssystems aus fachlicher Sicht erforderlich sind; darüber hinausgehende Verfeinerungen sind in den nachfolgenden Gestaltungsschritten Systemkonzeption und Systemrealisierung vorzunehmen. Merkmale

dieser

Art sind z.B. der Input und Output von Vor-

150

3. Die Entwicklung der Fachkonzeption

Legende:

Ο : Informationsobjekt

: Beziehung : Vorgang

Abb. 84: Interdependenzen von Informations- und Vorgangsstrukturen

3. Die Entwicklung

der

Fachkonzeption

151

gängen sowie die Verarbeitungsvorschrift für die Transformation des Inputs eines Vorgangs zum Output des Vorgangs. Diese Merkmale sind nur soweit zu spezifizieren, wie sie aus fachlicher Sicht erforderlich, d.h. benutzerrelevant sind. Ein benutzerrelevanter Vorgangs-Output ist z.B. eine erstellte Auftragsbestätigung; der benutzerrelevante Input dazu sind z.B. die Daten, die unmittelbar dem Kundenauftrag zu entnehmen sind, der den Vorgang "Aufträge bestätigen" auslöst. Deshalb beinhalten die Vorgangsstrukturen hier nur benutzerrelevante Vorgänge und keine Funktionen der DV-Infrastruktur wie z.B. Selektieren und Sortieren von Datensätzen oder das Verwalten von Bildschirmmasken. Die Vorgangsbeschreibung erfolgt entsprechend jeweils durch den benutzerrelevanten Vorgangs- Input, den benutzerrelevanten Vorgangs-Output und die benutzerrelevante Verarbeitungsvorschrift, die die Anweisungen für die Durchführung des Vorgangs aus fachlicher Sicht beinhaltet. Die Vorgänge sind dazu solange zu dekomponieren, bis eine "Logische Verarbeitungseinheit· (LVE) vorliegt; dies ist der Teilschritt des Aufgabenvollzugs, der aus dem fachlichen Kontext des Aufgabengebietes und aus Benutzersicht nicht mehr weiter unterteilt werden soll. Durch die Beschränkung des Spezifizierens nur auf fachliche, d.h. benutzerrelevante Merkmale wird ein überfrachten dieses Gestaltungsschritts mit den hier noch weitgehend irrelevanten Entwurfsmerkmalen der Systemkonzeption (Programmsystem, Datensystem, Hardwaresystem) vermieden, und es resultiert daraus ein eindeutig definiertes Abbruchkriteriua für das fachbezogene Spezifizieren der Anforderungen. Weiter kommt der verfahrenstechnischen Unterstützung eine besondere Bedeutung zu, denn in der Phase "Anforderungsspezifizierung" müssen die zukünftigen Benutzer eines DV-Anwednungssystems - gewissermaßen als "Bauherren" - sehr intensiv mit den Mitarbeitern des DV-Bereiches - zu sehen in der Rolle des "Architekten" - kooperieren. Daraus folgt als vorrangige Anforderung an eine verfahrenstechnische Unterstützung die Be-

152

3. Die Entwicklung

der

Fachkonzeption

nutzerfreundlichkeit. Deshalb sind nur solche Hilfsmittel geeignet, die die für das fachliche Detailkonzept spezifizierten Merkmale in Terminologie, Symbolik und Art der Visualisierung einfach und für den Nicht-DV-Fachmann in verständlicher Form darstellen und die dadurch die Kommunikation zwischen "Bauherren" und "Architekten" erleichtern. In materieller Hinsicht ergibt sich die Forderung nach Vollständigkeit der Spezifizierung; d.h., sämtliche fachlich relevanten Sachverhalte sind in dem fachlichen Detailkonzept zu dokumentieren. Aus Gründen der Arbeitserleichterung und der Transparenz der Fachkonzeption ist weiter Flexibilität in Bezug auf Änderungen und Erweiterungen der erarbeiteten Ergebnisse zu fordern. Weiter ist die Forderung nach übertragbarkeit zu stellen; dadurch soll sichergestellt werden, daß die nach einem bestimmten Vorgehen und in einer bestimmten Form dokumentierten Ergebnisse des fachlichen Detailkonzeptes eindeutig und anschluflgerecht an die nachfolgende Phase des Systementwurfs übertragen werden können, ohne dadurch bestimmte Vorgehensweisen für den Systementwurf im voraus festzuschreiben. Schließlich ist die Forderung nach ÜberprUfbarkeit der Spezifikation zu nennen, denn durch gezieltes und systematisches Revidieren der Entwicklungsschritte wird die Qualität des Software-Entwurfs maßgeblich beeinflußt.

3. Die Entwicklung der Fachkonzeption

153

3.3.3 Aktivitäten und Aktivitätenunterstüzung 3.3.3.1 Definition der Schnittstellen und der Schnittstelleninhalte Die Spezifizierung der Anforderungen beginnt zweckmäßigerweise mit dem überprüfen und ggf. Ergänzen der aus einer ersten Abgrenzung des Untersuchungsbereichs erarbeiteten Schnittstellen zum Umsystem, um dadurch diejenigen Systemteile auszugrenzen, die zunächst nicht Gegenstand weiterer Detaillierungen sein sollen. Damit die Detaillierung des so abgegrenzten Untersuchungsbereichs anschlußgerecht zum Umsystem erfolgen kann, sind jetzt die wichtigsten Schnittstelleninhalte zu definieren, die vorrangig den Austausch benutzerrelevanter Informationen zwischen Untersuchungsbereich und Umsystem, aber auch ggf. zwischen den Teilen des Umsystems beschreiben (s. z.B. Abb.107). 3.3.3.2 Erstellen der Infornationsstruktur Informationen werden in der Betriebswirtschaftslehre als "zweckorientiertes Wissen" (Wittmann) bezeichnet. Daten sind das zweckneutrale "Ausgangsmaterial" für Informationen. Informationen sind also in diesem Sinne den Daten begrifflich übergeordnet. Deshalb ist die Informationsstruktur einer Datenstruktur, die Ausdruck des zweckneutralen "Vorhaltens" von Daten in Datenbanken ist, vorgelagert. In der Phase "Anforderungsermittlung" führte die modellorientierte Aufgabenanalyse durch die Informationssicht auf ein reales Aufgabengefüge zu dessen modellhafter Abbildung in Form von Zustandstypen und Ereignistypen (Abb.66 und 69). Zweck dieser Sichtweise ist es, über Ereignistypen (evidente Beziehungstypen) die zu deren Bearbeitung erforderlichen Vorgänge zu definieren und sonstige Beziehungen zwischen den Zustandstypen (latente Beziehungstypen) zu dokumentieren. Im Hinblick auf die Merkmale, die zur "Produktbeschreibung" in der Phase "Anforderungsspezifizierung" erforderlich sind, ist

154

3. Die Entwicklung der

Fachkonzeption

das Ergebnis dieser Sichtweise noch zu rudimentär, denn es fehlt die Beschreibung der Zustands- und Ereignistypen durch Attribute, und die Beziehungsstruktur ist noch zu komplex und zu unpräzise. Deshalb lassen sich die bisher erarbeiteten Vorgänge, die aus der zur Informationssicht korrespondierenden Vorgangssicht abgeleitet wurden, auch noch nicht eindeutig beschreiben. Zur Strukturierung und Spezifizierung des Informationsmodells (vgl. Mtiller-Merbach) soll der Begriff Informationsobjekt (Oestreich, 10-6) verwendet werden. Informationsobjekte sind Träger von Informationnen; Attribute sind die Informationseinheiten, durch die ein Informationsobjekt beschrieben wird (Abb.85).Für die Zwecke der Anforderungsspezifizierung interAttribute

IOT = Typ (Klasse) v o n I n f o r m a t i o n s o b j e k t e n

A b b . 85: Beschreibungsschema v o n I n f o r m a t i o n s o b j e k t e n

.?. Die Entwicklung der Fachkonzeption

155

essieren hier analog zum Begriff Elementemenge nicht die einzelnen

Informationsobjekte, sondern Klassen oder

Typen

Informationsobjekten. Informationsobjekte sind z.B.

von

Zustände

und Ereignisse, denn beide sind Träger von Informationen. Informationsobjekte in dem

Aufgabenmodell

onsobjekt das

können

"Kunde"

untereinander in Beziehung stehen:

nach Abb.69 steht z.B. das Informati-

mit dem Informationsobjekt "Produkt" über

Informationsobjekt "Auftrag" in Beziehung; aber auch die

Informationsobjekte ferauftrag" usw.

"Auftrag",

"Auftragsbestätigung", "Lie-

stehen untereinander in Beziehung (Abb.70).

Damit ist die Struktur eines Systems von Informationsobjekten gegeben. Zur Unterscheidung von Datenstrukturen, die auf der Ebene des Datensystems zu entwerfen sind, werden als Notation der Informationsstruktur Kreise zur Darstellung von Informationsobjekten und Quadrate zur Darstellung der Beziehungen verwendet (Abb.86) . Soll das Aufgabenmodell unter der Informationssicht zu einem System von Informationsobjekten strukturiert werden, so ist entsprechend der allgemeinen Systemtheorie zu beachten, daß - Beziehungen nur zwischen Elementen und nicht auch zwischen Beziehungen bestehen können, - Attribute nur den Elementen und nicht den Beziehungen zugeordnet werden können. Daraus folgt, - daß in einem Aufgabenmodell, bei dem noch Interdependenzen der Beziehungen bestehen, diese durch Einfügen von Elementen auf Beziehungen zwischen Elementen zu reduzieren sind, - daß Beziehungen, die in diesem Modell noch durch Attribute beschrieben werden müssen, in Elemente umzuwandeln sind. - daß zwischen Elementen letztlich nur noch

156

3. Die Entwicklung der Fachkonzeption

A b b . 86: Aufgabenmodell (Ausschnitt)

3. Die Entwicklung der Fachkonzeption

157

"dimensionslose" Zugehörigkeiten als Beziehungen bestehen (z.B. "besteht aus", "gehört zu", "ist verantwortlich für" usw.). Sind diese Bedingungen erfüllt, so liegt die Informationsstruktur bereits in der ersten Normalform vor. Für das Aufgabenmodell nach Abb.69 hat dies zur Konsequenz, daß die Interdependenz des evidenten Beziehungstyps (Ereignistyp) "Auftrag", bestehend zwischen "Kunde" und "Produkt", aber auch zu "Vertreter" (Abb.86), durch Umwandlung dieses Beziehungstyps in ein Informationsobjekt "Auftrag" beseitigt wird (Abb.87). Damit ist gleichzeitig die Forderung erfüllt, wonach Beziehungen, die noch durch Attribute beschrieben werden müssen, ebenfalls in Informationsobjekte umzuwandeln sind (so z.B. für Auftrag, Auftragsbestätigung, Faktura etc.). Dadurch wird aus dem Aufgabenmodell sukzessive die Informationsstruktur erarbeitet. Die Beziehungen zwischen den Informationsobjekten von unterschiedlicher Komplexität sein: 1:1 Beziehung: jedem Informationsobjekt 0 Ε ist nur ein Informationsobjekt 0' Ε C>2 zugeordnet und umgekehrt (z.B. Verkaufsgebiet - Verkauf sgebietsleiter, wenn ein Verkaufsgebietsleiter nur ein Verkaufsgebiet betreut) . 1:n, n:1 Beziehung: jedes Informationsobjekt 0 Ε 0 1 steht in Beziehung mit mehreren Informationsobjekten vom Typ 0^· aber jedes Informationsobjekt vom Typ 0 2 steht nur in Beziehung zu einem Informationsobjekt vom Typ 0 1 und umgekehrt für n:1 Beziehungen (z.B. Vertreter - Kunden innerhalb eines Verkauf sgebietes).

können

158

3. Die Entwicklung

der

Fachkonzeption

Abb. 8 7 : Informationsstruktur (Informationsobjekte, Beziehungen)

n : m Beziehung: einem nen C>2

Informationsobjekt vom Typ 0 1

kön-

mehrere Informationsobjekte vom

Typ

zugeordnet sein, und umgekehrt können

einem Informationsobjekt vom Typ 0 2

meh-

rere Informationsobjekte vom Typ 0 1

zuge-

ordnet sein (z.B. ein mehrere Artikel und ein

Lieferant

liefert

Artikel kann von

mehreren Lieferanten bezogen werden).

3. Die Entwicklung der Fachkonzeption

159

Treten bei der Informationsstrukturierung m:n Beziehungen auf, so sind an diesen Stellen i.d.R. fachliche Präzisierungen erforderlich; diese können durch Einfügen eines neuen Informationsobjektes mit den zugehörigen 1:n Beziehungen erfolgen. So wird im Beispiel der Abb.88, die zwischen "Auf-

4-CH

= in

f Q — • = n:m

Abb. 88:

Informationsstruktur ( I n f o r m a t i o n s o b j e k t e , Beziehungen)

160

3. Die Entwicklung

der

Fachkonzeption

trag" und "Produkt" eine n:m Beziehung enthält und die zudem noch durch Attribute beschrieben werden muß, ein Informationsobjekt "Auftragposition" mit zwei Beziehungen vom Typ 1:n eingeführt, die keine Attribute mehr benötigen (Abb.89). In dieser Detaillierungsstufe der Informationsstruktur können den Informationsobjekten die Vorgänge zugeordnet werden, die darauf anzuwenden sind (z.B. "Auftrag bearbeiten", "Verfügbarkeit prüfen"). Dazu sind die Vorgänge nach fachspezifischen Erfordernissen zu strukturieren und durch VorgangsInput, Vorgangs-Output und Verarbeitungsvorschrift für jeden Vorgang zu beschreiben; dabei werden die Attribute definiert, die die Informationsobjekte für die Vorgänge bereitstellen müssen oder die sie als Ergebnis der Vorgänge erhalten. Im Zuge der Strukturierung der Vorgänge kann als Folge der dadurch erzielten schrittweisen Präzisierung der'aufgabenspezifischen Anforderungen die Aufteilung bereits definierter Informationsobjekte oder das EinfUgen neuer Informationsobjekte erforderlich werden (so z.B. in Abb.90 die Aufteilung des Informationsobjektes "Produkt" in zwei selbständige Informationsobjekte "Produkt-Stamm" und "Produkt-Lagerkonto" oder in Abb.91 das zusätzliche Einfügen der Informationsobjekte "Sachbearbeiter" und "Kunden-Konto"). Damit konsistente Informations- und Vorgangsstrukturen entstehen, sind deshalb beide Strukturen parallel zu entwickeln. Ein ausführliches Beispiel zur Entwicklung von Informationsstrukturen findet sich in Lorenz/Grüning.

3.3.3.3. Strukturierung und Beschreibung der Vorgänge Als Ergebnis der Phase "Anforderungsermittlung" liegen diejenigen Vorgänge vor, die Gegenstand des zu entwerfenden DV-Anwendungssystems sein sollen. Diese Vorgänge sind i.d.R. noch unstrukturiert hinsichtlich von Sachzusammenhang und zeitlicher Abfolge; sie sind dehalb lediglich als "rohe Komponentengruppen" für das zu gestaltende DV-Anwendungssystem anzu-

3. Die Entwicklung

der

A b b . 89: Informationsstruktur (Fortsetzung)

Fachkonzeption

161

162

3. Die Entwicklung der Fachkonzeption

Abb. 90: Informationsstruktur (Fortsetzung)

3. Die Entwicklung

der Fachkonzeption

Einzelpreis

Abb. 91: Informationsstruktur (Fortsetzung)

163

164

3. Die Entwicklung der Fachkonzeption

sehen. Damit die für das fachliche Detailkonzept erforderlichen Merkmale (Abb.81) schlüssig erarbeitet werden können, sind die Vorgänge nach sachlicher und zeitlicher Zusammengehörigkeit zu ordnen und gleichzeitig so zu detaillieren, daß für jeden Vorgang der Input, der Output und die Beschreibung benutzerrelevant nach Maßgabe der erarbeiteten Anforderungen definiert werden können. Durch das hierzu anzuwendende Prinzip des hierarchischen Dekomponierens wird die rudimentäre Sammlung von Vorgängen in eine geordnete Struktur von Vorgängen transformiert. Diese Vorgangsstruktur beinhaltet diejenigen Teilmengen von Aufgaben, die aus fachlicher Sicht für eine schrittweise Aufgabendurchführung, gestützt auf die Möglichkeiten der DV-UnterStützung, erforderlich sind. Dazu zählen Vorgänge, die vollständig dv-unterstützt werden sollen, aber auch solche, die einer manuellen Ausführung vorbehalten sein sollen, wie z.B. vor- und nachbereitende manuelle Tätigkeiten an Aufgaben. Durch das Konzentrieren auf benutzerrelevante Vorgänge, zu denen auch manuell auszuführende Vorgänge gehören, unterscheiden sich Vorgangsstrukturen von Funktionsstrukturen, die durch Verfeinern der spezifizierten fachlichen Anforderungen in Richtung auf die Anforderungen zur Gestaltung der DV-Infrastruktur entstehen, und die dadurch dann die Basis für den Entwurf von Programmsystemen und Datensystemen bilden. Vorgangsstrukturen können grundsätzlich durch folgende Diagrammarten dargestellt werden: - durch Ablaufdiagramme und - durch Baumdiagramme. Die Darstellung von Vorgangsstrukturen in Form von Ablaufdiagrammen ermöglicht eine Beschreibung des sachlichen und zeitlichen Zusammenhangs der einzelnen Vorgänge; dieser Zusammenhang kann rein linear, aber auch netzartig sein (Abb.92). Rein lineare Ablaufdiagramme sind zur Darstellung von Vorgangsstrukturen von geringer praktischer Relevanz, denn die dadurch abbildbaren Strukturen sind entweder Ausdruck von ho-

3. Die Entwicklung der Fachkonzeption

165

Linear - Struktur

Netz-Struktur

Baum - Struktur

A b b . 92: Darstellung v o n Vorgangsstrukturen

her Aggregation (z.B. " Beschaffen > Produzieren > Ausliefern"), oder sie beschreiben Teile einer Vorgangsstruktur auf niedriger Dekompositionsebene (z.B. " Erfassen Auftragsleitdaten > Erfassen Auftragskopfdaten > Erfassen Auftragspositionsdaten"). Zur realistischen Darstellung von Aufgabengefügen eignen sich Vorgangsnetze, durch die sachliche und zeitliche Zusammenhänge sequentiell und parallel verknüpft dargestellt werden können. Der gravierende Nachteil dieser Darstellungsart von Vorgangsstrukturen ist aber der

166

3. Die Entwicklung der Fachkonzeption

Sachverhalt, daß Vorgangsnetze mit zunehmender schrittweiser Verfeinerung über mehrere Dekompositionsebenen sehr schnell unübersichtlich werden und sich deshalb nur sehr eingeschränkt als Hilfsmittel für die Kommunikation mit dem Benutzer eignen. Werden Vorgangsstrukturen in Form von Bauediagraeeen dargestellt, so läßt sich dadurch der Nachteil mangelnder Übersichtlichkeit vermeiden, denn bei dieser Darstellungsart bleibt auch Uber mehrere Dekompositionsebenen bzw. Hierarchiestufen die Transparenz der Vorgangsstruktur gewahrt. Der Nachteil dieser Darstellungsart ist jedoch der, daß zeitliche Abfolgen, Querverknüpfungen und insbesondere Parallelitäten von Vorgängen nur sehr beschränkt dargestellt werden können. Deshalb lassen sich dynamische Vorgangsstrukturen durch Baumdiagramme nur unvollständig abbilden (Abb.93). Zu einer vollständigen Vorgangsstruktur gehört aber auch der dynamische Strukturaspekt; daher sind Vorgangsstrukturen, die zunächst vereinfacht durch Baumdiagramme dargestellt werden, durch eine Darstellung des dynamischen Zusammenhangs der Vorgänge zu ergänzen. So wie die Interdependenzen in einem Netzplan auch in Matrizen abgebildet werden können (Abb.94), so läßt sich der dynamische Aspekt von Vorgangsstrukturen durch Präzedenzdiagramme in Matrizenform, vorzugsweise als Vorgangs2 verbindungs-Matrizen oder Ν -Charts, darstellen (Abb.95, 96). Die Dekomposition von Vorgangsstrukturen wird solange fortgesetzt, bis die logische Verarbeitungseinheit (LVE) und damit der benutzerrelevante Vorgangs-Output und Vorgangs-Input eindeutig definiert werden können; dies ist dann der Fall, wenn von der Outputseite her aus fachlicher Sicht kein Bedarf mehr nach weiterer Unterteilung (z.B. in selbständige Bildschirmmasken) besteht. Vorgangs-Output und Vorgangs-Input sind die wichtigsten Merkmale zur fachlichen Vorgangsbeschreibung, denn sie repräsentieren die System-Ausgabe und System-Eingabe aus der Sicht des Benutzers eines DV-Anwendungssystems. Die Schrittfolge für diese Vorgangsbeschreibung wird zweckmäßi-

3. Die Entwicklung der Fachkonzeption

167

3. Die Entwicklung

168

der

Fachkonzeption

Vorgangsstruktur als Netz

VG

NF

A

Β

C

D

A Β

Χ

Ε

F Χ

D

Χ

G

J

κ

Χ Χ

F

I Χ

C

Ε

Η

G

Χ Χ Χ

Η

χ

I

χ

J

χ

Κ

Abb. 94: Vorgangsstruktur als Netz und als Präzedenzmatrix V G : Vorgang NF: unmittelbarer Nachfolger

3. Die Entwicklung der Fachkonzeption

Abb. 95: Dynamische Vorgangsstruktur („Vorgangsverbindungs-Matrix")

169

170

3. Die Entwicklung

der

Fachkonzeption

Statische Vorgangsstruktur

V1

V2

I

-

o

externer Einstieg

V3

c κJ

V4

Abb. 96: Dynamische Vorgangsstruktur („N 2 -Chart")

gerweise wie folgt gewählt: Da in der Vorstellungswelt des Benutzers die Ergebnisse eines dv-gestützten Verarbeitungsprozesses vorrangig sind, ist zuerst der benutzerrelevante Output eines Vorgangs zu definieren; das kann zunächst durch eine Sammlung der Output-Daten (Abb.97) erfolgen, deren Layout dann in einem gesonderten Schritt (Gestaltung der Benutzerschnittstelle) entworfen wird. Dieser Output determiniert dann den zu seiner Erzeugung erforderlichen Input, weshalb als ZMeiter Schritt der benutzerrelevante Vorgangs-Input zu definieren ist, der als unmittelbar vom Benutzer getätigte Dateneingabe i.d.R. nur eine Teilmenge des gesamten erforder-

3. Die Entwicklung der Fachkonzeption

interne Auftrags-Nr. Kunden-Auftrags-Nr. Kunden-Adresse Rechnungs-Adresse Bestell-Datum Vertreter Auftragsart

171

externe Priorität Liefertermin Versandart Verpackungsart Rabatt Zahlungsbedingungen var. Bestelltext

A b b . 97: Sammlung von benutzerrelevanten Output-Daten (zugehörig zu Vorgang „Erfassen Auftragskopfdaten", Abb. 113)

liehen Dateninputs für den Vorgang ist. Der weitere Dateninput (zur Unterscheidung zum benutzerrelevanten Vorgangs-Input in den folgenden Beispielen als Systeminput bezeichnet) ist dann anhand der Informationsstruktur und des Attribute-Katalogs (s. z.B. Abb.121), die die Vorgangsstruktur ergänzen, zu definieren. Sind Output und Input für den Vorgang festgelegt, so kann als dritter Schritt die Verarbeitungsvorschrift formuliert werden, die die Regeln für die Transformation des Vorgangs-Input zum Vorgangs-Output aus fachlicher Sicht beinhalten (Abb.100). Zur Beschreibung eines Vorgangs gehört weiterhin die Angabe, ob dieser dv-unterstützt durchgeführt werden soll, oder ob dafür eine manuelle Bearbeitung vorgesehen ist. Vorgänge, die manuell ausgeführt werden sollen, sind dann u.a. Gegenstand der organisatorischen Basislösung. Zur Unterscheidung dieser beiden Arten der Vorgangsausführung werden hier die Kennzeichnungen "M" für manuelle Vorgangsart und "D" für dv-gestützte Vorgangsart in der Vorgangsstruktur vermerkt (Abb.98). Zusätzlich zu dieser Kennzeichnung von Vorgängen ist die Vorgangsbeschreibung durch den Auslöser des Vorgangs zu ergänzen; dies kann ein Ereignis sein (z.B. ein zu bearbeitender Kundenauftrag oder eine telefonische Anfrage eines Kunden über die Lieferbarkeit von Produkten) oder ein Termin (z.B. jeweils zum Monatsultimo sind Kontenabschlüsse vorzu-

172

3. Die Entwicklung der Fachkonzeption

"Ο Ε

>ο CO Ο) -Ο -Q
> >> >> >>

Modell-Nr. zuschnitt-Art Farbe Größe

In vertikal strukturierten Klassifizierungsschlüsseln stehen die verschlüsselten Merkmale in hierarchischer Abhängigkeit voneinander; deshalb ist das einzelne verschlüsselte Merkmal nicht in andere Klassen von Informationsobjekten übertragbar: z.B. "Kunden-Nr.": XX.XX•XX•XXX >> >> >> >>

Land Verkaufsbezirk Kundenkategorie Kunde

Innerhalb der einzelnen Klassifizierungbereiche können numerische Schlüssel als reine Zählnummern oder aber auch alphabetische oder alphanumerische Schlüsselwerte verwendet werden. Schlüssel dieser Art werden auch sprechende Schlüssel genannt, denn daraus können Informationen Uber einige Merkmale der Informationsobjekte entnommen werden. Für die Dimensionierung der Teile des Schlüssels ist der Bestand und der Zuwachs an Merkmalen zu beachten. Sonderformen

der

Verschlüsselung sind der Matchcode und der

3. Die Entwicklung der

Fachkonzeption

179

Parallelschlüsssel. Der Matchcode entsteht durch Kompression von Merkmalen und wird i.d.R. als Identifizierungsschlüssel verwendet: z.B. Identifizierung eines Kunden: Name: Huber PLZ : 8035 Ort : Gauting Str.: Starnbergerstr. 123 Matchcode: HBR8035GS123 Die Merkmalkompression kann automatisch durch einen Algorithmus erfolgen, z.B. bei Anlegen des entsprechenden Datenbestandes , oder er kann benutzerindividuell durch Vergabe von signifikanten, mnemotechnisch geeigneten Kurzbezeichnungen definiert werden. ParallelschlUssel entstehen dadurch, daß einem Klassifizierungsschlüssel zusätzlich ein Identifizierungsschlüssel in Form einer reinen Zählnummer zugeordnet wird: XX.XX.XXX.X.XXX.xxxx (Klass.Schlüsssel)

XXXXX (Zähl-Nr.)

Diese Art der Verschlüsselung wird häufig deshalb verwendet, um die eindeutige Zuordnung zwischen Schlüssel und Objekt zu sichern und um dv-interne Verarbeitungsroutinen (Adressieren, Sortieren usw.) zu erleichtern.

3.3.3.5 Entwurf der Benutzerschnittstelle Die Schnittstelle zwischen einem DV-Anwendungssystem und seinen Benutzern besteht aus den Medien zur System-Eingabe und zur System-Ausgabe. Aus fachlicher Sicht interessieren hier die Gestaltung von Bildschirmmasken als Eingabe- und AusgabeMedium, die Gestaltung von Listen als Ausgabe-Medium und die

180

3. Die Entwicklung

der

Fachkonzeption

Gestaltung der Maskensteuerung; weitere Schnittstellenkomponenten wie z.B. die verschiedenen Techniken zur Dateneingabe (Tastaturen, Lichtgriffel, Roller-Scanner, Touch-Screen etc.) seien der Spezifizierung des Hardware-Systems vorbehalten, die Gegenstand der Phase Systemkonzeption ist. Durch Bildschimasken wird der Bildschirm in konstante und variable Datenfelder untergliedert, die sich in Art, Anzahl, Formatierung und Anordnung nach den vorgangsspezifischen Gegebenheiten richten. Die Maskentechnik ist dem Arbeiten mit Formularen entlehnt, die das Bearbeiten von routinehaften, immer wiederkehrenden Vorgängen erleichtert; auch dort dienen konstante Datenfelder ("Formularfelder") als Uberschriften und zur Bezeichnung von variablen Datenfeldern, deren Inhalt vom Bearbeiter vorgangsabhängig ausgefüllt wird. Ebenso wie die Gestaltung von Formularen nach bestimmten Regeln erfolgt, sind auch auf Bildschirmmasken Gestaltungsregeln anzuwenden; z.B. die Unterteilung der Bildschirmmaske in (Abb.101): -

Identifikationsbereich, Arbeitsbereich, Bereich für Steuerungsinformationen, Bereich für Fehlermeldungen.

Der Indentifikationsbereich beinhaltet die Kennzeichnung des aktuellen Dialogschritts, bestehend z.B. aus der Bezeichnung von Anwendung, Aufgabe, Teilaufgabe und gewähltem Vorgang. Im Arbeitsbereich, dessen Gestaltung aus fachlicher Sicht das besondere Interesse gilt, sind die vorgangsabhängigen konstanten und variablen Datenfelder anzuordnen. Deren Strukturierung richtet sich im wesentlichen danach, ob ein EingabeBildschirm oder ein Ausgabe-Bildschirm gestaltet werden soll. Die Gestaltung des Arbeitsbereichs von Eingabe-Bildschiraasken, die zur Datenerfassung und Datenänderung dienen, sollte sich grundsätzlich am Aufbau der dazu verwendeten Belege orientieren. So soll die Reihenfolge der einzugebenden Daten der Feldanordnung auf den Belegen entsprechen, d.h., die Felder für die Dateneingabe sind auf der Bildschirmmaske gemäß dem

3. Die Entwicklung der Fachkonzeption

181

ARBEITSBEREICH

BEREICH FÜR S T E U E R U N G S I N F O R M A T I O N E N

A b b . 1 0 1 : Bereichsunterteilung für den Entwurf von Bildschirmmasken

dabei üblichen Arbeitsfluß von rechts nach links und von oben nach unten anzuordnen. Aus Gründen der Übersichtlichkeit sind die Eingabe-Daten in links- oder rechtsbündige Blöcke zu strukturieren, wobei die variablen Datenfelder (Eingabe-Datenfelder) i.d.R. rechts von den konstanten Datenfeldern (Feldbezeichnungen) angeordnet werden und die Feldlänge durch Visualisierungshilfen (Unterstreichung, inverse Leerfelddarstellung u.a.) gekennzeichnet werden kann. Durch bildschirmtypographische Hilfsmittel (inverse Darstellung, Felder in unterschiedlichen Farben, voll- oder halbhelle Darstellung, Unterstreichung, Einrahmung usw.) können besonders wichtige Datenfelder (z.B. Muß-/Kannfelder) hervorgehoben werden. Ein

182

3. Die En twicklung der

Fachkonzeption

weiteres Hilfsmittel ist die Fenstertechnik, die es gestattet, in die Bildschirmmaske eines Vorgangs Daten aus anderen Vorgängen auschnittsweise einzublenden. Ausgabe-Bildschir·masken zeigen das Ergebnis von Verarbeitungsprozessen an. Masken dieser Art sind wie Eingabe-Bildschirmmasken als Formulare zu gestalten, wenn das Verarbeitungsergebnis ebenfalls Formularcharakter hat (z.B. Faktura, Lieferschein usw.); die genannten Gestaltungsempfehlungen sind entsprechend anzuwenden. Ist das Verarbeitungsergebnis eine Tabelle, so sind für die Maskengestaltung dazu folgende Empfehlungen hilfreich: - Untergliederung in Kolonnen, - Kolonnen-Überschriften Bildschirmzeile,

die

in

gesonderter

bei

vertikalen

Scrollen erhalten bleibt, - durch

Leerzeilen oder Einrückungen abge-

setzte Ergebnisse von Gruppenwechseln, - vertikales

Verschieben

von ganzen Daten

gruppen. Auch bei Masken dieser Art kann durch die Anwendung geeigneter bildschirm-typographischer Hilfsmittel die Übersichtlichkeit der Darstellung gesteigert werden. Der Bereich für Steuerinformationen enthält Hinweise über weitere abrufbare Vorgänge bzw. Folgemasken, Hinweise zur Unterbrechung oder für den Abbruch eines aktuellen Vorgangs sowie Hinweise zum Aufruf von Hilfestellungen. Im Bereich für Fehlermeldungen werden Fehlerarten und ggf. Hinweise zur Fehlerkorrektur angezeigt; die Gestaltung dieses Bereichs erfolgt wegen der dazu erforderlichen weiteren Detaillierungen zweckmäßigerweise in der Phase Systemkonzeption. Zur Gestaltung von Listen als Ausgabe-Medium sind die üblichen Gestaltungsregeln für Formulare und tabellarische Darstellungen anzuwenden. Zur Gestaltung der Maskensteuerung sind zu unterscheiden die Gestaltung der Maskensteuerung zu Dialogbeginn und die Gestaltung des Wechsels von Masken. Die Gestaltung der Maskensteuerung zu Dialogbeginn ist von der Struktur des Dialogs

3. Die Entwicklung der

Fachkonzeption

183

abhängig: der Dialog besteht aus einzelnen Dialogschritten, die wiederum jeweils aus mehreren Transaktionen bestehen können; den Transaktionen werden einzeln oder gemeinsam Bildschirmmasken zugeordnet, anhand derer sie seitens der Benutzer bearbeitet werden (Abb.102). Aus Benutzersicht entspricht

Dialog

entspricht

Aufgabe

Dialogschritt

entspricht

Teilaufgabe

Transaktion

entspricht

Vorgang (LVE)

Abb. 102: Dialogstruktur

der Dialog der Benutzer-Aufgabe (z.B. Auftragsbearbeitung), die Dialogschritte den Teilaufgaben (z.B. Auftrags-Leitteil bearbeiten, Auftrags-Kopfteil bearbeiten), und die Transaktionen entsprechen den Vorgängen ("Logische Verarbeitungseinheit", z.B. Erfassen Auftrag, Ändern Auftrag, Löschen Auftrag) . So gestufte Dialoge werden durch die Nenu-Technik gehandhabt: der Benutzer wählt aus einem Katalog vorgegebene

184

3. Die Entwicklung

der

Fachkonzeption

Aufgaben oder Vorgänge aus und wird entsprechend der hierarchischen struktur der Aufgaben- und Vorgangsgliederung i.d.R. Uber mehrere Stufen in Art eines Suchbaums zur gewünschten Vorgangsmaske geführt, mit der dann die Bearbeitung beginnen kann. Diese Art der Maskenansteuerung ist für ungeübte oder gelegentliche Benutzer vorzusehen. Für geübte Benutzer ist eine direkte Maskenansteuerung über den vollständigen Transaktionscode vorzusehen, der i.d.R. aus einer mnemotechnisch geeigneten Folge derjenigen Vorgangsabkürzungen bestehen sollte, die den Zugriffspfad auf die gewünschte Vorgangsmaske bilden. Durch Funktionstasten ist ebenfalls eine direkte Maskenansteuerung möglich, wenn darunter der vollständige Transaktionscode abgelegt wurde; pro Funktionstaste ist i.d.R. nur der Aufruf einer Maske möglich. Der Wechsel von Masken kann auf Transaktionsebene kontinuierlich durch "Blättern" (vorwärts/rückwärts) erfolgen, das durch eine Funktionstaste ausgelöst wird, oder gezielt in Sprüngen durch Eingabe des entsprechenden Transaktionscodes. Letzteres ist charakteristisch für das Arbeiten mit integrierten Anwendungssystemen: ausgehend von einer Stamm-Maske (z.B. Erfassung von Auftragsdaten) muß vorgangsabhängig in Folge-Masken (z.B. Bonitätsprüfung, Verfügbarkeit von Lagerbeständen) verzweigt und wieder in die Stamm-Maske zurückgekehrt werden können. Der hierzu erforderliche Transaktionscode kann in der Stamm-Maske entweder im Bereich für Steuerungsinformationen ausgewiesen oder durch ein Bildschirmfenster eingeblendet werden. Bei tief gestuften Dialogen besteht die Gefahr, daß ungeübte oder nur gelegentliche Benutzer in den Dialogzweigen die Orientierung verlieren. Deshalb ist es erforderlich, von unteren Dialogebenen direkt auf signifikante Verzeigungspunkte zurückspringen zu können; dies kann erfolgen Uber spezielle Rücksprungscodes, die im Bereich für Steuerinformationen ausgewiesen werden, durch Bildschirmfenster, die das entsprechende Verzweigungs-Menü in die Arbeitsmaske einblenden oder durch Funktionstasten. Darüber hinaus muß gewährleistet sein, daß der Benutzer selektiv den Dialog unterbrechen oder abbrechen kann.

3. Die Entwicklung

Der

Entwurf

von

der

Bildschirmmasken kann durch spezielle Ent-

wurf sformulare , die ein Blanko-Raster der Zeilentenaufteilung

185

Fachkonzeption

und

des Bildschirms sind, unterstützt oder

Spaldirekt

durch Prototyping durchgeführt werden (Kap.4). Zur Dokumentation des Entwurfs

der

Dialogstruktur eignen sich tabellari-

sche Darstellungen

(Abb.103), Ablaufdiagramme

Matrix-Darstellungen

(Abb.105); der letzteren Darstellungsart

ist d a n n

der

(Abb.104)

und

Vorzug zu geben, wenn in einem Dialog Querein-

stiege, Querverbindungen und Kellerungen erforderlich sind.

A b b . 1 0 3 : Tabellarische Darstellung der Dialogstruktur

186

3. Die Entwicklung der Fachkonzeption

A b b . 104: Dialogstruktur in Form eines Ablaufdiagramms

3. Die Entwicklung der Fachkonzeption

187

externer Einstieg

Ο

ο

Erfassen Α.-Leitteil Erfassen

Bonitäts-

A.-Kopf-

prüfung

teil Erfassen A.-Pos.teil Bestandsanzeige

Bestandsreservierung

Abb. 105: Dialogstruktur in Matrix-Form („N 2 -Chart")

3.3.3.6 Überprüfung der Spezifizierung Auch bei der Überprüfung der Spezifizierung ist eine formale Prüfung und eine inhaltliche Prüfung zu unterscheiden. Die formale Prüfung erstreckt sich auf die Prüfung - der Vollständigkeit und der Verständlichkeit der Dokumentation des Phasenergebnisses und

188

3. Die Entwicklung

der

Fachkonzeption

- der Vollständigkeit und Verständlichkeit der Dokumente, die für das Phasenmanagement benötigt werden (Zeitplan, Mitarbeiter-Einsat zplan, Verantwortungsmatrix usw.). Im Rahmen der inhaltlichen Prüfung sind entsprechend der Vorgehensweise zur Anforderungsspezifizierung vorrangig zu prüfen - die Vollständigkeit der Informationsstruktur aus fachlicher Sicht, - die Konsistenz der Informationsstruktur nach den dafür relevanten Kriterien, - die Vollständigkeit der Vorgangsstruktur aus fachlicher Sicht, - die Redundanzfreiheit der Vorgangsstrukturen, - die Korrespondenz der Vorgangsstruktur zu der Informationsstruktur (jedes Informationsobjekt muß eine Bearbeitung erfahren) - die Widerspruchsfreiheit in Vorgangs-Präzedenzmatrizen, - der fachliche Inhalt des benutzerrelevanten System-Outputs, - die ergonomische Gestaltung schirmmasken-Layouts ,

des

Bild-

- die Vollständigkeit der Vorgangsbeschreibung, orientiert an den Erfordernissen der Transformation von benutzerrelevantem System-Input zu benutzerrelevantem System-Output, - die Benutzerfreundlichkeit der Dialogstruktur (Einstieg über Suchbäume für den nicht professionellen Benutzer, Einstieg über Vorgangscode für den professionellen Benutzer; automatische Anbieten von sachlich sinnvollen Folge-Bildschirmmasken;

3. Die Entwicklung der Fachkonzeption

189

Riicksprung zur Bildschirmmaske der letzten Verzweigung; Rücksprung zum Ausgangsmenu) sowie - die applikatorische Logik der geplanten organisatorischen Detaillösung (Belegbzw. Informationsfluß, Aufgabenund Stellengliederung) und - deren Auswirkungen auf die Betroffenen des Reorganisationsvorhabens. Die inhaltliche Prüfung der Aufgabenspezifizierung sollte gemeinsam mit dem Benutzer vorgenommen werden; die geeignete Form dazu sind Einzelgespräche oder strukturierte Gruppengespräche. Das Ergebnis der Überprüfung ist in einem Prüfprotokoll zu dokumentieren, das die diagnostizierten Mängel des fachlichen Detailkonzeptes sowie Hinweise auf deren Beseitigung enthält.

3.3.3.7 Dokumentation Das Ergebnis der Phase "Anforderungsspezifizierung" ist die fachliche Detaillösung und die organisatorische Detaillösung. Die fachliche Detaillösung wird durch folgende Darstellungen dokumentiert: - Schnittstellen zum Umsystem, - Schnittstelleninhalte zum Umsystem, - Informationsstruktur, - Vorgangsstruktur, - Vorgangsbeschreibung, - Bildschirmmasken-Layout, - Listen-Layout, - Dialogstruktur/BS-Maskenfolgeplan, - Zuordnungsmatrix Vorgangsauslöser/Vorgänge, - Vorgangs-Präzedenzmatrix, - Attribute-Katalog, - Struktur der Schlüsselsysteme, - Datenmengengerüst.

190

3. Die Entwicklung der Fachkonzeption

Die Abb.106 bis 122 beinhalten - z.T. in Auszügen - Beispiele dazu, die in Fortführung des Beispiels zur Situationsstudie und zur Anforderungsermittlung entwickelt wurden. Die Dokumentation der organisatorischen Detaillösung erfolgt i.d.R. durch - Belegflußplan, - Aufgabengliederungsplan, - Stellengliederungsplan sowie durch Umstellungs- und Einführungsplan und Schulungsplan für die Mitarbeiter. In Abb.123 ist ein Vorgangskettenund Belegflußplan dargestellt, der im Rahmen der Anforderungsspezifizierung des Beispiels "Auftragsbearbeitung und Vertrieb" entwickelt wurde. Daraus sind die geplanten computerunterstützten Vorgangsketten zu erkennen und diejenigen Stellen oder Abteilungen zu ersehen, die in den Belegfluß eingebunden sind. Auf weitere Abbildungen zur organisatorischen Detaillösung wurde verzichtet. Weiterhin gehört zur Dokumentation der Ergebnisse dieser Phase die Fortschreibung der Nutzenbegründung durch die Daten, die durch die Spezifizierung der Anforderungen gewonnen wurden (Kap.5.4).

3. Die Entwicklung der Fachkonzeption

Lagerhaltung

Analysebereich (Speditions-U V Dispos. J

AUFTRAGSBEARBEITUNG und VERTRIEB

Debitoren Buchhalt.

(VertreterV Abrechnung

Abb. 106: Schnittstellen zum Umsystem

Fertigungs-J Dispos. J

191

nach

^^^

Bearbeitg.stand von Aufträgen

KontenInfo rmat.

Fertigungsdisposition

Debitorenbuchhaltung

»1

i-a

t i tc U t £

Speditionsdisposition

ι

Reservierungen

Primärbed.

Auftragseingänge, Ersatzbed.

Fertigungsdisposition

Lagerhai tung

Fakturasurnnen

Speditionsdisposition

Umsätze lt. Zahlung

Umsätze lt. [ SpeditionsLieferung Soll

VertreterDebitoren buchhaltung abrechnung

3. Die Entwicklung der

Belieferung plan

Bestandsvorschau

Auftragsbearbeitg. U.Vertrieb

Lagerhaltung

Auftragsbearbeitg. und Vertrieb

von

192 Fachkonzeption

-Q α

.ο -Ο