2  /  82

Frank  Schmidt,  1071154

Inhaltsverzeichnis   

Seite   

1  Erläuterung und Abgrenzung des Themas  4

1.1  Aufgabe und Ziel der Arbeit  4

1.2  Ausgangssituation und Aufgabenabgrenzung  4

1.3  Darstellung der persönlichen Stellung des Verfassers zum KMU „Industrie-  

holz  Krieger, Kufstein“  7

2  Verwendete Methoden und Verfahren  7

2.1  Die Phasen der Softwareentwicklung  7

2.2  Werkzeuge bei der Analyse und Anforderungsdefinition  12

2.2.1  Die Theorie des Geschäftsprozesses und genutzte Darstellungsmethoden  12

2.2.2  Das Lastenheft und das Pflichtenheft  16

2.2.3  Die Entity-Relationship-Modellierung  17

2.3  Die Begriffe Individual - und Standardsoftware  19

2.4  Die Dateiverwaltung „Microsoft ACCESS“  22

3  KMU und ihre Bedeutung in einer Marktwirtschaft  24

3.1  Die Abgrenzung des Begriffes „KMU“  24

3.2  Die volkswirtschaftliche Bedeutung von KMU in Österreich  25

3.3  Die Bedeutung von Informationstechnologien für KMU  26

3.4  Geschäftsaktivitäten des Unternehmens „Industrieholz Krieger, Kufstein“  28

4  Die Geschäftsprozessanalyse im KMU „Industrieholz Krieger“ als Basis  

f  ür die Anforderungsdefinition  29

4.1  Der Bereich „Einkauf“  30

4.2  Der Bereich „Lagerwirtschaft“  39

4.3  Der Bereich „Verkauf“  39

4.4  Der Bereich „Kaufmännische Verwaltung “  41

5  Das Lastenheft „Holzfirma“  44

6  Das Pflichtenheft „Holzfirma“  48

7  Darstellung wichtiger ER-Modelle  60

7.1  Der Wareneingang  60

7.2  Der Warenausgang  63

7.3  Die Debitoren  65

7.4  Die Kreditoren  65

7.5  Das Rechnungswesen  65

3 / 82 Frank Schmidt, 1071154

8 Das MS-ACCESS-Programm „Holzfirma“ - ein Ausblick auf das Anwendungsprogramm 66

9 Die grundsätzliche Beurteilung des Einsatzes von Individualsoftware in KMU 70

Anlagen 75

Abkürzungsverzeichnis 77

Literaturverzeichnis 78

Anlagenverzeichnis 81

Eidesstattliche Erklärung 82

4 / 82 Frank Schmidt, 1071154

1 Erläuterung und Abgrenzung des Themas

1.1 Aufgabe und Ziel der Arbeit

Das mittelständische Tiroler Unternehmen „Industrieholz Krieger, Kufstein“ (nachfolgend „IHK“ genannt) möchte die betrieblichen verwaltungstechnischen Tätigkeiten durch die Einführung einer einfachen und preisgünstigen IT-Lösung rationalisieren. Auf der Grundlage einer bereits erfolgten Teilanalyse von ausgewählten Geschäftsprozessen (vgl. dazu SCHMIDT 2002) und den am Markt verfügbaren Softwareprodukten wurde innerbetrieblich entschieden, dass eine Individualsoftware eingeführt werden soll. Die vorliegende Diplomarbeit wird ein Lasten- und ein Pflichtenheft für dieses Projekt „Holzfirma“ erarbeiten. Neben diesem zentralen Punkt werden die benutzten Methoden und Werkzeuge des Software Engineering bei der Zielerreichung vorgestellt sowie die besondere wirtschaftliche Bedeutung von KMU diskutiert. Mittels Vorgangskettendiagrammen und Funktionsbäumen werden Ergebnisse der Geschäftsprozessanalyse als Basis für die anschließende Definitionsphase dargestellt. Nach Vorliegen von Lasten- und Pflichtenheft werden einige zentrale Entity-Relationship-Modelle definiert sowie ein kurzer Ausblick auf die Benutzeroberfläche des Programms „Holzfirma“ gegeben.

1.2 Ausgangssituation und Aufgabenabgrenzung

Für eine nachhaltige Entwicklung von Unternehmen spielen n eben der fachlichen Seite im Geschäftsprozess immer mehr das Informationsmanagement und eine effiziente Verwaltung eine entscheidende Rolle. Wenn sich Qualität und Preis der angebotenen Produkte infolge der Konkurrenz immer ähnlicher werden, so gilt es nun Wege zu finden, um sich dennoch vo n den Mitbewerbern zu unterscheiden. Ein schnelles Reagieren auf Kundenwünsche und eine fehlerfreie Abwicklung aller „Bürotätigkeiten“ sind erfolgversprechende Wege dazu. Im Zusammenhang mit einem umfassenden Customer Relationship Management heißt es dazu : „Oft wird übersehen, dass es nur weniger unzufriedenstellender Reak-

5 / 82 Frank Schmidt, 1071154

tionen seitens des Unternehmens und seiner Mitarbeiter bedarf, um den Entschluss zur Beendigung von Geschäftsbeziehungen reifen zu lassenspeziell seit das Internet die Konkurrenz gleich frei Haus liefert. ...Nicht mehr die Produkte sind das Zentrum der Geschäftstätigkeit, sondern die Kunden.“ (o. V. IN : NOVUM 2002, 17). Insbesondere für KMU heißt das, dass Stärken wie Meisterschaft, Flexibilität und Individualität auf fachlicher Ebene durch Professionalität bei der Kundenbetreuung, d.h. im Verwal-tungssektor, abzurunden sind. Zwar umfasst der Begriff des CRM viel mehr als nur die büromäßige Verwaltungstätigkeit des betrieblichen Leistungsprozesses, aber als wesentliches Kernelement beim Eingehen auf Kundenbedürfnisse stellt genau diese Verwaltungstätigkeit einen entscheidenden Ansatzpunkt unter den Bedingungen eines Käufermarktes dar. Eine falsch ausgestellte Rechnung, eine fehlerhafte Auftragsbearbeitung oder versäumte Termine werden seitens des Kunden nicht toleriert, weil die Primärleistung (also das eigentliche Produkt oder die Dienstleistung) relativ schnell von einem Mitbewerber erbracht werden könnte. Folglich liegt auch in der Sekundärleistung (das sind die den Leistungsprozess unterstützenden Verwaltungstätigkeiten) ein Schlüssel zum nachhaltigen Unternehmenserfolg.

Die Ausführung von verwaltungstechnischen Bürotätigkeiten kann durch den Einsatz der Computertechnologie wesentlich unterstützt werden. Der Einsatz von Computern hat z.B. Einfluss auf die Qualität und Schnelligkeit der Erledigung der anstehenden Bürotätigkeiten, und er beeinflusst auch den Produktionsfaktor „Personal“. Einerseits werden bestimmte Mindest-anforderungen an die Ausbildung und das fachliche Grundwissen des Personals gestellt. Andererseits ist der Einsatz von Computertechnologie geeignet, menschliche Arbeitskraft rationeller einzusetzen und stellt somit einen Intensivierungsfaktor mit hohem Rationalisierungspotenzial dar.

Um dieses Rationalisierungspotenzial sinnvoll und zielgerichtet auch in KMU einzusetzen, ist ein absolutes Augenmerk auf die personellen und finanziellen Mindestanforderungen des Computereinsatzes zu richten. Ein zu teures System, das die Einsatzmöglichkeiten im konkreten Unter- nehmen technisch weit übertrifft, immense Wartungskosten verschlingt

6 / 82 Frank Schmidt, 1071154

oder den Einsatz hochqualifizierten Personals erfordert, stellt keine Rationalisierungsquelle dar, sondern kann den Einsparungseffekt von Ressourcen im Unternehmen negativ beeinflussen.

Gerade für KMU bis zu einer bestimmten Größe, Mitarbeiteranzahl oder Finanzkraft ist deshalb der Einsatz von am Markt erhältlichen professionellen Systemen, Hard- oder Softwarekomponenten nicht realisierbar. Diese Komponenten sind entweder zu teuer, erfordern hochqualifiziertes Personal oder widerspiegeln nicht in erforderlichem Maße das abzubildende Betriebsgeschehen. Einen Ausweg bietet der Einsatz von individuell erstellter betrieblicher Software, die auf handelsüblichen und preisgünstigen Standard-Office-Paketen basieren ( z.B. von Microsoft oder Lotus). Diese Lösungen können relativ preiswert selber erarbeitet werden, laufen auf normalen „Kaufhaus-PC´s“ und sind auch von Personal mit PC-Grundlagenwissen anwendbar. Ein weiterer Vorteil solcher Lösungen ist es, dass z.B. branchenunübliche Betriebsabläufe, Organisationsstrukturen oder sonstige Besonderheiten softwaremäßig abgebildet werden können, was bei Nutzung von neutraler Standardsoftware nicht oder nur nach erheblichem finanziellen Anpassungsaufwand möglich wäre. Nachteilig dagegen ist die Begrenzung des Multi-User-Einsatzes, fehlende Schnittstellen zu Outside-Solutions und technische Grenzen der Software hinsichtlich Datenbestandsvolumen und -verarbeitung.

Die vorliegende Diplomarbeit befasst sich schwerpunktmäßig mit Elementen der Anforderungs- und Definitionsphase im Prozess des Software Engineering von Individualsoftware für das Tiroler KMU „IHK“. Es wird zunächst auf die theoretischen Grundlagen bei der Erstellung von Software eingegangen und der Begriff der „Klein- und Mittelunternehmen“ im Zusammenhang mit der österreichischen Volkswirtschaft diskutiert. Die Darstellung von Geschäftsprozessen des KMU „IHK“ bildet anschließend die Grundlage für die Erarbeitung eines Lastenheftes sowie eines Pflichtenheftes für das Softwareprojekt „Holzfirma“ des Unternehmens . Die Geschäftsprozessanalyse basiert dabei teilweise auf der entsprechenden Hausarbeit des Verfassers im Frühjahr 2002. Das im Rahmen der Di- plomarbeit zu erstellende Lasten- und Pflichtenheft soll die praxisrelevante

7 / 82 Frank Schmidt, 1071154

Grundlage für die weitere Arbeit bei der Erstellung des eigentlichen Programms bilden. Aufbauend auf den Anforderungen des Pflichtenheftes werden für einige wichtige Geschäftsprozesse Entity-Relationship-Models generiert. Den Abschluss der Diplomarbeit bilden Darstellungen der Benutzeroberfläche des Programms „Holzfirma“ sowie eine grundsätzliche Einschätzung von Individualsoftware für KMU´s.

1.3 Darstellung der persönlichen Stellung des Verfassers zum KMU „Industrieholz Krieger, Kufstein“

Der Verfasser dieser Diplomarbeit ist als Betriebswirt in dem genannten Unternehmen tätig. Neben allen kaufmännischen Belangen des Unternehmens ist er auch für alle Fragen der Informationstechnologie verantwortlich. Aus dieser besonderen Situation als Angestellter leitet sich die tiefe Durchdringung des Betriebsgeschehens ab : für Außenstehende schwer erkennbare Besonderheiten im täglichen Leistungs- und Verwaltungsablauf des Unternehmens können infolge der eigenen Betroffenheit im Arbeitsprozess identifiziert und auf ihre Zweckmäßigkeit hin beurteilt werden. Da andererseits die Tätigkeit in dem Unternehmen noch nicht lange besteht, ist die Gefahr der „Betriebsblindheit“ sowie die Scheu vor der Hinterfragung von Geschäftsprozessen auf ihre Effizienz und ihren Sinn und die nachfolgende Erarbeitung von Veränderungsvorschlägen bis hin zum Business Reengineering oder Change Management ausgeschlossen.

2 Verwendete Methoden und Verfahren

2.1 Die Phasen der Softwareentwicklung

Die Entwicklung von Software ist ein Prozess, bei dem es darum geht, für ein existierendes Problem der realen Welt ein funktionierendes Computerprogramm zu schaffen und erfolgreich zu installieren. Das Programm muss dabei zieldefiniert sein, bestimmten Qualitätsanforderungen genü- gen und sich auf seine Wirtschaftlichkeit - sowohl in Bezug auf die Ent-

8 / 82 Frank Schmidt, 1071154

wicklung als auch in Bezug auf den tagtäglichen Betrieb - überprüfen lassen. „Die Softwarekosten dominieren inzwischen die Kosten der Hardware bei weitem.“ (PAGEL / SIX 1994, 43). Diese Aussage stammt zwar aus dem Jahre 1994, trifft aber heutzutage mehr denn je zu. Eine Einteilung von IT-Projekten zur Softwarebeschaffung aus dem Jahre 1999 gibt als untere Größenordnung für ein einfaches Projekt (z.B. eine Abteilungsanwendung) ein Investitionsvolumen bis zu Euro 15.000 vor. Mittlere Investitionssummen für Software bewegen sich bis zu Euro 150.000, von der oberen Größenordnung wird ab Euro 250.000 gesprochen (vgl. GRUPP 1999, 43 f.). Woher kommen diese Kosten ? Und was haben diese Kosten mit den Phasen der Softwareentwicklung zu tun ? Der Prozess der Softwareentwicklung ist ein hochgradig komplexes und arbeitsteiliges Gebilde, das neben einem materiell-technischen Ressourceneinsatz auch einen ganz erheblichen Aufwand an hochqualifiziertem Personal und Arbeitszeit verursacht. Um diesen Vorgang beherrschen zu können, hat es sich als effektiv erwiesen, den Gesamtprozess zu unterteilen, zu strukturieren und Zielvorgaben zu fixieren. Diese Phaseneinteilung im Prozess der Softwareerstellung ermöglicht es, Arbeitspakete, Ziele, Meilensteine und Verantwortlichkeiten zu definieren, Arbeitsgruppen zu ko-ordinieren, Zeitrahmen und materielle sowie finanzielle Ressourcen festzulegen und zu kontrollieren. Die Phaseneinteilung hat demnach zwei Zielrichtungen : einmal die fachliche und zum anderen eine wirtschaftliche Seite. Alle im Zusammenhang mit der Erstellung von Software ablaufenden Aktivitäten können unter Beachtung von diversen Kriterien wie z.B. Zeit, Zwischenergebnis usw. in Phasen zusammengefasst werden. Das schafft eine organisatorisch-theoretische Grundlage, den Gesamtprozess transparenter zu machen und ihn fachlich und finanziell aktiv zu beherrschen.

Folgende Grobeinteilung ist allgemein anerkannt :

(1) Analysephase (Problemanalyse und Planung)

(2) Definitionsphase (Anforderungsdefinition und Sys temspezifikation) (3) Entwurfsphase (System- und Komponentenentwurf) (4) Implementierungsphase (Implementierung und Tests)

9 / 82 Frank Schmidt, 1071154

(5) Abnahme- und Einführungsphase (Einführung beim Anwender) (6) Wartungsphase (Fehlerbehebung, Änderungen, Anpassungen) (vgl. STANIEROWSKI o. J., a, 17 f.).

Dieses 6-Phasen-Modell basiert weitgehend auf dem Vorgehensmodell zur Anwendungsentwicklung von RIEMANN, der Vorschlagsphase, Definitionsphase, Konzeptphase, Entwurfsphase, Realisierungsphase, Einführungs- und Implementierungsphase unterscheidet (RIEMANN 1996) ¹ . Vielfach ist auch eine Zusammenfassung der genannten Einzelphasen anzutreffen. So werden z.B. die beiden ersten Phasen unter dem englischen Begriff „requirements engineering“ oder „requirements analysis and specification“ als „A&D-Phase“ (Anforderungs- und Definitionsphase) zusammengefasst. Danach beginnt diese A&D-Phase bei der Ermittlung und Analyse der Aufgabenstellung und endet mit der Anforderungsdefinition für das System (vgl. KÜHNEL et al. 1987, 334 - 335). Wieder andere Einteilungen berücksichtigen die interessengeprägte Sicht auf die eigene Involvierung in den Prozess des SE, so dass z.B. die Abnahme- und Einführungs- sowie die Wartungsphase nicht zur eigentlichen Softwareentwicklung gehören, sondern bereits dem weiteren Software-Lebenszyklus zuzuordnen wären. Wichtig ist, dass eine Phaseneinteilung ein theoretisches Grundgerüst sein kann, um den Arbeitsablauf der Softwareentwicklung zu fördern.

Nachfolgend werden die Ergebnisse genannt, mit denen die einzelnen Phasen abschließen können (teilweise sind auch synonyme Begriffe gebräuchlich).

¹ RIEMANN 1996 (zitiert nach SCHUMANN o.J., 16)

10 / 82 Frank Schmidt, 1071154

Tab. 1: Ziele und Ergebnisse der einzelnen Software-Entwicklungsphasen (vgl. STANIE -ROWSKI o. J., a, 17 f.)

Die Anforderungs- und die Definitionsphase sollen kurz näher erläutert werden, weil sie die vorliegende Arbeit besonders betreffen. Es wird anerkannt, dass ein Scheitern eines Softwareprojektes zum größten Teil bereits in der A&D-Phase verursacht wird. So sollen ca. 60% des Gesamtrisikos bei der Softwarebeschaffung auf unzureichende oder fehlerhafte An-forderungsdefinitionen entfallen (vg. GRUPP 1999, 28). In einer europaweiten Marktuntersuchung durch das IT-Beratungsunternehmen Diebold wurde festgestellt, dass in der Praxis etwa ein Viertel aller IT-Projekte scheitern; bei jährlichen Gesamta usgaben in Europa von 140,5 Milliarden Dollar sind das immerhin ca. 35 Mrd. Dollar Verlust ! Als wesentliche Ursache dafür wird ein Basieren des Projekts auf falschen Geschäftsmodellen identifiziert (vgl. o. V., a, 2002). Die Universität Dublin kommt in einer anderen Studie zu dem Ergebnis, dass sogar jedes zweite IT-Projekt misslingt oder zum Abbruch führt. Von den verbleibenden erfolgreichen Projekten werden 40% nur unter beträchtlichen Folgeinvestitionen zum Erfolg geführt (vgl. o. V., b, 2002). Welche Zahlen auch immer richtig sind, eine Grundaussage ist erkennbar : IT-Projekte sind mit einem enormen Risiko verbunden ! Die finanzielle Belastung des Unternehmens durch ein misslungenes Projekt kann dabei gewaltige Ausmaße annehmen. So musste z. B. ein gemeinsames Projekt der Hotelketten Hilton und Marriott mit der Mietwagenfirma Budget im Jahre 1994 abgebrochen werden, übrig blie-

11 / 82 Frank Schmidt, 1071154

ben Stranded Costs von 125 Millionen Dollar ! Die britische Child Support Agency verlor durch den Abbruch eines Projektes 1997 allein 600 Millionen Pfund (vgl. o. V., b, 2002). Leider sind keine genauen Angaben verfügbar, inwieweit diese gescheiterten IT-Projekte softwarebedingt waren, auch ist nicht belegt, welche Bedeutung letztendlich eine mangelhafte A&D-Phase für die genannten Fehlschläge hatte . Wenn jedoch die o. g. Aussagen zu den „falschen Geschäftsmodellen“ usw. auch nur ansatzweise zutreffen, dann muss man die besondere Bedeutung der A&D-Phase anerkennen !

Während in der Entwurfs-, Implementierungs-, Einführungs- und Wartungsphase ein Qualifikationsschwerpunkt des verantwortlichen Personals auf informatikspezifischem Gebiet liegt, so sind insbesondere in der A&D-Phase Fähigkeiten gefragt, die es ermöglichen, die im späteren Programm abzubildende Realität zu durchschauen und modellhaft zu beschreiben. Zwei Fragen sind dabei signifikant :

a) Wie sieht die Ausgangssituation aus, was läuft derzeit wie, wann, wo und womit ab ?

b) Was ist das Wunschziel, was will der Anwender zukünftig eigentlich mit der IT-Lösung machen, was soll sie ihm bringen ?

Hier geht es um ein „...Analysieren des Problems und das Definieren (bzw. Spezifizieren) des Produkts.“ (PAGEL / SIX 1994, 77). Auf der Basis dieser Informationen kann dann die eigentliche Umsetzung des Problems erfolgen. Zusammenfassend kann man festhalten :

1) Die A&D-Phase beschäftigt sich mit den realen Prozessen, die beim Anwender stattfinden.

2) Die A&D-Phase schafft die Grundlage für die weitere Tätigkeit des IT-Spezialisten.

3) Die A&D-Phase wird vorrangig nicht vom IT-Spezialisten, sondern vom Analytiker und Anwender geprägt.

4) Damit der IT-Spezialisten zielführend arbeiten kann, muss die A&D- Phase qualitativ ausreichende Ergebnisse bereitstellen.

12 / 82 Frank Schmidt, 1071154

5) Sind die Ergebnisse der A&D-Phase unvolls tändig oder anderweitig mangelhaft, so sind Spätfolgen in Form von unzureichenden Lösungen zu erwarten.

6) Nur so exakt, wie das Produkt und seine zu erfüllenden Aufgaben definiert werden, kann auch die Umsetzung erfolgen.

Beendet ist die A&D-Phase, „...we nn die Anforderungen an das Produkt in der Produktdefinition 2 (synonym: Anforderungsdefinition, Aufgabendefinition, Pflichtenheft, Requirementkatalog) dokumentiert und verabschiedet sind. ...Adressaten der Produktdefinition sind neben den Entscheidungsträgern bei Auftraggeber und Auftragnehmer auch die Entwurfsspezialisten, die auf Basis der Produktdefinition das Innenverhalten und die Architektur der Software festlegen.“ (PAGEL / SIX 1994, 85).

Es muss an dieser Stelle aber erwähnt werden, dass das phasenstrukturierte Vorgehen in der Softwareentwicklung auch kritisch diskutiert wird. Als Schwachpunkte werden vor allem unscharfe Phasengrenzen, Probleme bei der Beurteilung von Phasenergebnissen, zu starke Formalisierung und Bürokratisierung des Gesamtentwicklungsprozesses und unzureichende Einflussmöglichkeiten der Anwender auf das Endprodukt und daraus resultierende hohe Wartungskosten genannt. Als Alternativen zum Phasenmodell gelten Werkzeuge wie z.B. Prototyping, Objektorientierung oder der Einsatz von CASE-Tools (vgl. SCHUMANN o. J., 21 ff.).

2.2 Werkzeuge bei der Analyse und Anforderungsdefinition

2.2.1 Die Theorie des Geschäftsprozesses und genutzte Darstellungsmöglichkeiten

Um ein komplexes System zu beschreiben, werden Modelle benutzt. Dabei abstrahiert man von für den Betrachtungszweck unwesentlichen Seiten der Gesamtheit und führt eine „...Datenreduktion auf die wesentlichen systemrelevanten Schlüsselkomponenten.“ durch (VESTER 1999, 183).

² PAGEL / SIX 1994, im Original kursiv

13 / 82 Frank Schmidt, 1071154

Ein betriebliches Unternehmen stellt sich theoretisch zunächst einmal als ein Gebilde dar, das unterschiedliche Komponenten technischer, personeller, sozialökonomischer, finanzieller sowie vieler weiterer Arten in sich vereint. Je nach Zielstellung der Untersuchung und Modellierung eines Betriebes werden die interessierenden Seiten herausgestellt, die nicht interessierenden Seiten werden negiert. Ein im Software Engineering (insbesondere in der Analysephase) verbreitetes Modellierungsverfahren der betrieblichen Realität ist die grafische Darstellung von Geschäftsprozessen.

Ein Geschäftsprozess (engl.: business process) stellt eine Kombination von innerbetrieblichen Aktivitäten und Tätigkeiten dar, die mit einem bestimmten Eingang (Input) beginnen und mit einem geplanten Ergebnis (Output) abschließen. „A process is a specific ordering of work activities across time and place, with a beginning, an end, and clearly identified inputs and outputs: a structure of action.” (DAVENPORT 1993) ³ . Dabei geht es aber immer um die Erfüllung der betrieblichen Gesamtaufgabe, also um die Befriedigung eventueller Marktbedürfnisse. So können Geschäftsprozesse - je nach Abstraktionsniveau - einen direkten Bezug zum externen Kunden (also zum Markt) aufweisen. Genauso können sie aber auch Prozesse sein, deren Ergebnis wiederum die Voraussetzung für einen nachfolgenden innerbetrieblichen Prozess darstellt. Dieser nachfolgende innerbetriebliche Prozess stellt seinerseits auch einen Kunden dar : den „internen“ Kunden. Ein interner Kunde existiert nicht zum bloßen Selbstzweck, sondern ist im Leistungserstellungsprozess ein notwendiger Zwischenschritt auf dem Weg zum externen Kunden. „Die Summe aller miteinander verketteten Geschäftsprozesse einer Unternehmung bildet den Leistungserstellungsprozess (Wertschöpfungskette).“ (STANIEROWSKI o. J., 16). Mit dieser „Verkettung“ kommt der Bezug zum externen Kunden klar zum Ausdruck : ein Prozess findet nach dem Effektivitätsprinzip marktwirtschaftlicher Bedingungen nur dann statt, wenn es eine Möglichkeit der Realisierung der Gesamtleistung am Markt gibt. Die nachfolgende Abb.1 zeigt den Bezug von Geschäftsprozessen zu jeweils einem internen und einem externen Kunden. Doch wie kann man nun eine sinnvolle Ge-

³ DAVENPORT 1993 (zitiert nach BALZERT 1998, 695)

14 / 82 Frank Schmidt, 1071154

schäftsprozesseinteilung realisieren, wo beginnt, wo endet ein Geschäftsprozess im konkreten Beispiel ? ALBRECHT versteht unter einem Geschäftsprozess „...die Zusammenfassung von sachlich zusammengehörigen, einzelnen Funktionen, z.B. Warenbeschaffung. Die Definition bzw. Identifizierung von Geschäftsprozessen kann in Unternehmen bewirken, dass eine funktions- oder abteilungsorientierte Sicht durch eine zielorientierte Sicht abgelöst wird. Geschäftsprozesse lassen sich sehr genau beschreiben, da es einen definierten Anfangs- und Eckpunkt und eine Aufgabe gibt, die zu erfüllen ist. J e einfacher Geschäftsprozesse sind, desto schneller können sie ablaufen.“ (ALBRECHT et al. 1999, 47).

Abb. 1: Geschäftsprozesse mit internem und externen Kunden

Eine Unternehmung kann grundsätzlich in eine Aufbau- und eine Ablauforganisation unterschieden werden. Während die Aufbauorganisation die Struktur des Unternehmens betrifft und somit einen relativ stabilen oder auch statischen Charakter trägt, sollen mit der Ablauforganisation die dynamischen Prozesse - also die eigentlichen Geschäftsprozesse - erfasst werden (vgl. BALZERT 1998, 694 f.). Für die Modellierung von Geschäfts- prozessen kommen dabei diverse grafische Verfahren und Diagramme

15 / 82 Frank Schmidt, 1071154

zum Einsatz. Wichtige Vertreter sind u.a. das Interaktions- und Vorgangs-Schema „SOM“ von Ferstl und Sinz, das Aufgabenkettendiagramm „PRO-MET“ von Institut für Wirtschaftinformatik der Hochschule St. Gallen, Petri-Netz-basierte Modelle sowie die ereignisgesteuerten Prozessketten (EPK) und Vorgangsketten-Diagramme (VKD) im Rahmen des ARIS -Systems (Architektur integrierter Informationssysteme) von Scheer (vgl. RUMP 1999, 23 - 32 und Scheer 1997). Die angesprochene Aufbauorganisation dagegen kann z.B. mittels Organigrammen visualisiert werden.

Abb. 2: Beispiel für ein ARIS -Vorgangskettendiagramm (VKD) (SCHEER 1997, 18)

Die im Betrieb ablaufenden Prozesse vollziehen sich zwischen dem Beschaffungs- und dem Absatzmarkt. Grundsätzlich kann dabei nach güterwirtschaftlichen, finanzwirtschaftlichen und informationellen Prozessen unterschieden werden (vgl. OLFERT / RAHN 1994, 27 ff.). Wie diese drei Seiten der betrieblichen Aktivitäten miteinander in Beziehung stehen, kann relativ einfach und dabei doch sehr anschaulich mittels der genannten ARIS -Werkzeuge dargestellt werden (siehe Abb. 2). Aus diesem Grunde wurden für die Geschäftsprozessmodellierung des KMU „Industrieholz Krieger“ Techniken des ARIS -Modells verwendet.

16 / 82 Frank Schmidt, 1071154

2.2.2 Das Lastenheft und das Pflichtenheft

Der Schwerpunkt der vorliegenden Arbeit betrifft - unter Zugrundelegung des 6-Phasen-Modells - Ergebnisse der ersten beiden Phasen : Analyse-und Definitionsphase (siehe Tab. 1 auf Seite 9 - 10). Zunächst soll ein Lastenheft erstellt werden, das die anwenderseitigen Wünsche und Anforderungen an das Programm „Holzfirma“ beschreibt. Dabei wird von der Ist-Situation im Unternehmen ausgegangen und eine „Vision“ der vom späteren Programm zu erfüllenden Aufgaben entwickelt. Das Lastenheft, auch als Produktskizze bezeichnet, stellt eine systematische , strukturierte Aufzählung der Wünsche und Anforderungen des Anwenders an das neue System dar. Ausgehend vom Bedarf des Anwenders werden innerhalb einer sogenannten Vorstudie die meist noch vagen Vorstellungen eruiert und aufgezeichnet. Ein Lastenheft ist die „Zusammenstellung aller Anforderungen des Auftraggebers hinsichtlich Liefer- und Leistungsumfang. Im Lastenheft wird definiert, WAS und WOFÜR ⁴ zu lösen ist. Es dient als Ausschreibungs-, Angebots- und/ oder Vertragsgrundlage. Hier sollten das Thema und die Ziele der Projektarbeit deutlich werden.“ (THORSTENT 2002).

Darauf aufbauend wird ein Pflichtenheft erarbeitet, das die Anforderungen des Lastenheftes berücksichtigt und eine Produktdefinition liefert, die als verpflichtendes Dokument den weiteren Prozess der Softwareerstellung begründet. Dieses Pflichtenheft kann dabei - je nach Umfang des zu erstellenden Programms - große Dimensionen annehmen. „Die Größe und Komplexität heutiger Softwareentwicklungen ziehen umfangreiche und komplizierte Produktdefinitionen nach sich, welche das menschliche Be-urteilungsvermögen...überfordern.“ (PAGEL / SIX 1994, 47). Das Pflichtenheft als sehr komplexes Dokument dient dabei zunächst einmal als fachlicher Wegweiser bei der Realisierung des Softwareprojektes. Außerdem besitzt es auch Bedeutung als juristische Vertragsgrundlage zwischen Auftraggeber und Auftragnehmer. Sollte es nämlich im Zusammenhang mit dem Projekt zu Streitigkeiten kommen, so kann anhand des von den Vertragsparteien unterzeichneten Pflichtenheftes überprüft wer-

⁴ THORSTENT 2002, im Original Großbuchstaben

17 / 82 Frank Schmidt, 1071154

den, ob eine Vertragsverletzung vorliegt oder nicht. Im Punkt 2.1 wurden einige Beispiele für gescheiterte IT-Projekte mit ihren finanziellen Auswirkungen geschildert. Bei diesen Dimensionen wird deutlich, welche immense Bedeutung einem Pflichtenheft für die Klärung einer eventuellen Schuldfrage nebst Schadensersatzforderung zukommen kann.

Als das zentrale Dokument des Gesamtprojekts besitzt die Produktdefinition, also das Pflichtenheft, eine entscheidende Bedeutung (vgl. PAGEL / SIX 1994, 47 und 79 f.). Es ist eine „Beschreibung der Realisierung aller Anforderungen des Lastenheftes. Im Pflichtenheft wird definiert, WIE und WOMIT ⁵ die Anforderungen zu realisieren sind. Es dient als verbindliche Vereinbarung für die Realisierung uns Abwicklung des Projektes für Auftraggeber und Auftragnehmer. Das Pflichtenheft enthält das Lastenheft. Die Ergänzung beinhaltet insbesondere einen Verlaufsplan.“ (THOR-STENT 2002). Inwieweit den Vorstellungen zur Einbeziehung des Lastenheftes und des Verlaufsplanes in der betrieblichen Praxis gefolgt wird, bleibt dem Anwender überlassen. GRUPP beispielsweise kombiniert Lasten- und Pflichtenheft als Ausschreibungsgrundlage zur externen Softwarebeschaffung unter dem Gesamtbegriff „Pflichtenheft“ und gibt nur einen zeitlichen Realisierungsrahmen vor (vg l. GRUPP 1999, 124 ff.). Entscheidend ist, dass das Pflichtenheft Anforderungen nach Vollständigkeit, Eindeutigkeit und Widerspruchsfreiheit genügen muss. Inwieweit formale Spezifikationen integriert werden, hängt vom jeweiligen Einzelfall ab. Alle Angaben müssen weiterhin nachvollziehbar und validierbar sein (vgl. PA-GEL / SIX 1994, 85 f.). Für weitere Informationen wird auch auf die VDI / VDE-Richtlinien 2519 und 3694 verwiesen (siehe Anlage 1 und 2).

2.2.3 Die Entity-Relationship-Modellierung

Ausgehend von der Anforderungsanalyse für ein zu erschaffendes Datenbanksystem wird im Rahmen des konzeptionellen Entwurfs ein semantisches Datenmodell erstellt. Die Datenmodellierung beinhaltet dabei die Erfassung und Beschreibung von Objekten (als Erscheinungen der realen

⁵ THORSTENT 2002, im Original Großbuchstaben