Interaktive betriebswirtschaftliche Informations- und Steuerungssysteme [Reprint 2019 ed.] 9783110847055, 9783110121001

Citation preview

Studien zur Wirtschaftsinformatik 3 Herausgegeben von Karl Kurbel, Uwe Pape und Hans-Jochen Schneider

Karl Kurbel • Peter Mertens • August-Wilhelm Scheer (Herausgeber)

Interaktive betriebswirtschaftliche Informations-und Steuerungssysteme

w DE

G

Walter de Gruyter - Berlin • New York 1989

Karl Kurbel Professor Dr. rer. pol., Dipl.-Kfm., Lehrstuhl für Wirtschaftsinformatik im Fachbereich Wirtschafts- und Sozialwissenschaften der Universität Dortmund, Dortmund. Peter Mertens Professor Dr. rer. pol., Dipl.-Wirtsch.-Ing., Forschungsgruppe Informatik VIII im Fachbereich Ingenieurwissenschaften der Universität Erlangen-Nürnberg, Erlangen. August-Wilhelm Scheer Professor Dr. rer. pol., Dipl.-Kfm., Lehrstuhl für Betriebswirtschaftslehre, insbesondere Wirtschaftsinformatik, im Fachbereich Wirtschaftswissenschaften der Universität des Saarlandes, Saarbrücken.

© gedruckt auf säurefreiem Papier

CIP-Titelaufnahme der Deutschen Bibliothek Interaktive betriebswirtschaftliche Informations- und Steuerungssysteme / Karl K u r b e l . . . (Hrsg.). - Berlin ; New York : de Gruyter, 1989 (Studien zur Wirtschaftsinformatik ; 3) ISBN 3-11-012100-X NE: Kurbel, Karl [Hrsg.]; GT

Copyright © 1989 by Walter de Gruyter & Co., Berlin 30. Alle Rechte, insbesondere das Recht der Vervielfältigung und Verbreitung sowie der Übersetzung, vorbehalten. Kein Teil des Werkes darf in irgendeiner Form (durch Photokopie, Mikrofilm oder ein anderes Verfahren) ohne schriftliche Genehmigung des Verlages reproduziert oder unter Verwendung elektronischer Systeme verarbeitet, vervielfältigt oder verbreitet werden. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenbezeichnungen und dergleichen in diesem Buch berechtigt nicht zu der Annahme, daß solche Namen ohne weiteres von jedermann benutzt werden dürfen. Vielmehr handelt es sich häufig um gesetzlich geschützte, eingetragene Warenzeichen, auch wenn sie nicht eigens als solche gekennzeichnet sind. Druck: WB-Druck GmbH & Co. Buchproduktions KG, Rieden am Forggensee. - Bindung: Dieter Mikolai, Berlin. - Einband: Hans-Bernd Lindemann, Berlin. - Printed in Germany.

Inhaltsverzeichnis

Geleitwort P. Lockemann Vorwort K. Kurbel, P. Mertens, A.-W. Scheer Teil 1: Interaktive betriebswirtschaftliche Anwendungssysteme Ein Ansatz zu kooperierenden Expertensystemen bei der Produktionsplanung und -Steuerung P. Mertens, J. Helmer, H. Rose, Th. Wedel

13

Interaktive Fertigungssteuerung teilautonomer Bereiche A.-W. Scheer, R. Herterich, M. Zell

41

Engpaßorientierte Auftragsterminierung und Kapazitätsdisposition K. Kurbel, J. Meynert

69

Entwicklung und Analyse von PC-gestützten Verfahren zur interaktiven grafikorientierten Verschnittplanung M. Rode, 0. Rosenberg

89

Konzeption eines Bildschirmtext-gestützten Warenwirtschaftssystems zur Kommunikation in verzweigten Handelsunternehmungen A.-W. Scheer, U. Leismann

111

Strukturanalyse von Planungsmodellen E. Zwicker, A. Pleger

135

Konzeption und Realisierung eines Expertenunterstützungssystems im Controlling A.-W. Scheer, W. Kraemer

157

Inhaltsverzeichnis Teil 2: Methoden und Werkzeuge zur Entwicklung betrieblicher Anwendungssysteme INCOME - Methoden und Werkzeuge zur betrieblichen Anwendungsentwicklung W. Stucky, T. Nemeth, F. Schönthaler

187

Konzeption und Realisierung eines SystemanalytikerArbeitsplatzes Th. Gutzwiller, H. Österle

213

Interaktive Entwurfsmethode zur computergestützten Herstellung betriebswirtschaftlicher Anwendungssoftware D. B. Preßmar, S. Eggers, W. Reinken

235

Projektmanagementebenen bei evolutionärer Softwareentwicklung K. Kurbel, W. Pietsch

261

Teil 3: Analyse und Gestaltung betrieblicher Organisations- und Kommunikationsstrukturen Die Kommunikationsstrukturanalyse zur Konzeption einer betrieblichen Kommunikationsarchitektur H. Krallmann, L. Feiten, R. Hoyer, G. Kötzer

289

Entwurfsentscheidungen bei der Gestaltung eines Organisationsinformationssystems H. Heilmann

315

Analyse und Modellierung von Kommunikationsarchitekturen in der rechnerintegrierten Produktion H. Krallmann, B.Scholz

329

Anhang: Autorenverzeichnis Projekte des Schweipunktprogramms

349 353

Geleitwort

Die Informatik hat in den letzten zwei Jahrzehnten einen stürmischen Aufschwung genommen. Motor dieses Aufschwunges waren gleichermaßen eine ununterbrochen hohe Steigerungsrate bei der Leistungsfähigkeit von Mikroelektronik und Gerätetechnik und eine - wenngleich weniger dramatisch - zunehmende Beherrschung der Entwicklung großer und anspruchsvoller Programmpakete. Technischer Fortschritt allein kann aber diesen Aufschwung noch nicht erklären. Was hinzukommen mußte und auch hinzukam, war die wachsende Bereitschaft immer weiterer Bereiche unternehmerischen und öffentlichen Wirkens, sich der Methoden, Ergebnisse und Produkte der Informatik zu bedienen, sie in organisatorisch sinnvoller und ökonomischer Weise in die Arbeitsabläufe zu integrieren und mit den gewonnenen Erfahrungen gezielt in die Informatik zurückzuwirken. Diese Symbiose aus Entwicklung und Anwendung der Informatik hat allerdings in den siebziger Jahren in Lehre und Forschung nur sehr zögernd ihren Niederschlag gefunden, zumeist in Form der -gelegentlich etwas abfällig so bezeichneten - "Bindestrich-Informatiken". Vielleicht war man damals der Ansicht, daß sich die Informatik selbst erst einmal ein solides Fundament schaffen müsse, bevor man an die Fundierung ihrer Anwendungen herangehen könne. Politik und Wirtschaft haben damals wohl auch übersehen, daß der breite und erfolgreiche Einsatz der Informatik auch eines breiten, in Anwendung und Informatik gleichermaßen geschulten Stammes an hochqualifiziertem Personalbedarf. Heute hat sich dies alles gewandelt. Daß der Umgang mit Methoden und Produkten der Informatik der Zusammenarbeit vieler Personen bedarf, die ihre Kenntnisse und Erfahrungen aus den unterschiedlichsten Schwerpunkten von den Kerngebieten der Informatik bis hin zu unzähligen Anwendungsgebieten beziehen, ist heute allgemein akzeptiert. Daß ein ungeheurer und kaum zu deckender Bedarf an derartigem Personal besteht, belegen die Statistiken zum Arbeitsmarkt. Daß die Befriedigung dieses Bedarfs am Ausbau der Ausbildungskapazitäten anzusetzen hat, wird heute trotz der knappen Finanzen von unseren Bildungspolitikern voll gestützt DerWirtschaftsinformatik kommt in dieser Situation eine Schlüsselfunktion zu. Wie keine andere reicht sie dank ihrer betriebswirtschaftlichen Wurzeln in große Bereiche unseres wirtschaftlichen und öffentlichen Geschehens hinein. Und als Disziplin, die schon immer Informationen zu definieren, zu erfassen, auszuwerten und bereitzustellen hatte, auf denen das ordnungsgemäße Funktionieren dieses Geschehens fußte, war sie prädestiniert für ein frühes Zusammenwirken mit der Informatik. Der Unterzeichnende ist als Informatiker daher nur zu gerne der Einladung einiger führender Kollegen aus der Wirtschaftsinformatik gefolgt, als es darum ging, zu Beginn der achtziger Jahre mit Hilfe der Deutschen Forschungsgemeinschaft ein

2

Geleitwort

Schwerpunktprogramm zu begleiten, auf das alle Beteiligten hohe Hoffnungen setzten. Zwar hatte sich schon die Erkenntnis durchgesetzt, daß die Wirtschaftsinformatik einer Stärkung an den Hochschulen bedurfte, aber dies in entsprechende Maßnahmen umzusetzen, fiel damals noch schwer. Es ist der Deutschen Forschungsgemeinschaft sehr hoch anzurechnen, zu jenem Zeitpunkt eingesprungen zu sein und der Wirtschaftsinformatik an den Hochschulen Starthilfe zu leisten in der Erwartung, daß der Erfolg dieses Programms Bildungspolitiker und Hochschulen von der Notwendigkeit, aber auch den Erfolgschancen eines Ausbaus überzeugen würde. Daß man dazu zu einem Forschungsprogramm griff, war so abwegig nicht: nur so konnte schließlich erst einmal der qualifizierte Nachwuchs heranwachsen, der in den nachfolgenden Jahren die Verantwortung an den Hochschulen übernehmen würde. Als Sprecher des Gutachterausschusses habe ich das Vergnügen gehabt, zu verfolgen, wie sozusagen aus dem zarten Pflänzchen zu Beginn des Jahres 1984 im Laufe von fünf Jahren ein blühender Baum hervorgegangen ist. Wurden die Projekte anfänglich von einigen wenigen Initiatoren getragen, so ließ sich über die Jahre hinweg eine immer breitere Basis an herausragenden Vorhaben ausmachen, begleitet von einer wachsenden Zahl hochmotivierter und engagierter Wissenschaftler, die sich mit diesem Forschungsprogramm zu profilieren vermochten. Ihrer Leistung soll das vorliegende Buch ebenso Tribut zahlen wie dem Durchsetzungsvermögen der Initiatoren des Schwerpunktprogramms und der Weitsicht der Deutschen Forschungsgemeinschaft. Als aus den Kerngebieten der Informatik stammender Außenseiter, sozusagen als neutraler Beobachter der Wirtschaftsinformatik, bescheinige ich neidlos und mit Überzeugung dem Programm, daß es die Hoffnungen aller Beteiligten nicht nur erfüllt, sondern vielfach übertroffen hat Ich wünsche dem Buch viele Interessenten - nicht nur aus der Wirtschaftsinformatik selbst, sondern auch aus der Informatik, denn die Herausforderungen der Zukunft werden wir nur gemeinsam bewältigen können.

Peter C. Lockemann

Vorwort Die Wirtschaftsinformatik steht als interdisziplinäres Fachgebiet an der Schnittstelle von Betriebswirtschaftslehre und Informatik. Ihr Hauptgegenstand ist die Entwicklung und Nutzung rechnergestützter Anwendungssysteme in Unternehmen und Verwaltungen. Sie leistet damit einen wesentlichen Beitrag, das Potential der modernen Informations- und Kommunikationstechnik für die betriebliche Praxis nutzbar zu machen. Die Bedeutung der Wirtschaftsinformatik kommt auch in der Situation am Arbeitsmarkt zum Ausdruck, wo die Nachfrage nach entsprechend ausgebildeten Fachkräften das Angebot um ein Vielfaches übersteigt [1]. Wirtschaftsinformatik ist zwar an den meisten Universitäten verankert [2]; die Ausbildungskapazitäten reichen aber nicht annähernd aus, um die hohe Nachfrage nach Absolventen zu befriedigen. Auch im Forschungsbereich mußte die Wirtschaftsinformatik seit ihrer Entstehung Ende der 60er Jahre mit unzureichenden Kapazitäten kämpfen. Die staatliche Förderung der Hauptfachinformatik in den 70er und 80er Jahren ging an der Wirtschaftsinformatik (wie an anderen "Bindestrich"-Informatiken) weitgehend vorüber. Die geringen Forschungskapazitäten der Lehrstühle wurden großenteils von den betreuungsintensiven Lehraufgaben aufgesogen. In dieser S ituation rang die "Wissenschaftliche Kommission Wirtschaftsinformatik" im Verband der Hochschullehrer für Betriebswirtschaft e.V. lange Zeit um gezielte Unterstützung der Wirtschaftsinformatik. Nach mehrjährigen Bemühungen gelang es uns schließlich 1984, bei der Deutschen Forschungsgemeinschaft (DFG) ein Schwerpunktprogramm zur Förderung der Wirtschaftsinformatik-Forschung einzurichten. Das Schwerpunktprogramm wurde auf eine Dauer von 5 Jahren (1985 bis 1989) ausgelegt. Es steht unter dem Rahmenthema "Interaktive betriebswirtschaftliche Informations- und Steuerungssysteme". Ziel des Programms ist es insbesondere, die Kluft zwischen den technischen Möglichkeiten der Informationsverarbeitung und dem Stand ihrer betriebswirtschaftlichen Anwendungen zu verringern und die in der Informations- und Kommunikationstechnik liegenden Potentiale für die betriebliche Anwendung transparent zu machen. Im Rahmen des Schwerpunktprogramms werden 13 Projekte durchgeführt. Eine vollständige Aufstellung der Projektthemen ist im Anhang wiedergegeben. In den Beiträgen dieses Buchs werden ausgewählte Forschungsergebnisse beschrieben. Aus Raumgründen kann nur ein Teil der Projektergebnisse skizziert werden. In den Literaturverzeichnissen finden sich jedoch Hinweise auf weitere, im Zusammenhang mit dem Schwerpunktprogramm entstandene Veröffentlichungen. Sie erlauben es dem Leser, ihn besonders interessierende Themen zu vertiefen.

4

Vorwort

Der Band gliedert sich in die drei Teile - "Interaktive betriebswirtschaftliche Anwendungssysteme", - "Methoden und Werkzeuge zur Entwicklung betrieblicher Anwendungssysteme" und - "Analyse und Gestaltung betrieblicher Organisations- und Kommunikationsstrukturen". Darin spiegeln sich wichtige, aber bei weitem nicht alle Aufgabenfelder der Wirtschaftsinformatik wider. Im ersten Teil werden ausgewählte Anwendungssysteme beschrieben, wobei der Schwerpunkt auf dem Gebiet der Produktionsplanung und -Steuerung liegt Hier wird in den kommenden Jahren noch eine Vielzahl von sehr schwierigen Problemen zu lösen sein. In den Beiträgen erkennt man, wie neuere Entwicklungen sowohl der Hardware als auch der Methodik mit der betriebswirtschaftlichen Theorie zusammengeführt werden. Auf der Hardwareseite wurden insbesondere die enormen Leistungssteigerungen der Arbeitsplatzrechner genutzt. Sie ermöglichen es beispielsweise, sehr mächtige Leitstände zu entwickeln. Diese bieten sich wiederum an, um die in den vergangenen Jahren immer mehr sichtbar gewordenen Divergenzen zwischen einer relativ leistungsfähigen, automatischen Produktionsgrobplanung einerseits und den in der Praxis oft genug nicht brauchbaren Algorithmen der Produktionsfeinplanung bzw. Produktionssteuerung andererseits durch Mensch-Maschine-Systeme zu überbrükken. Kurbel und Meynert gehen dieses Problem in dem Beitrag "Engpaßorientierte Auftragsterminierung und Kapazitätsdisposition" an. Sie stellen heraus, daß der Weg nur dann zielführend ist, wenn die Benutzeroberfläche von Leitständen nicht nur für professionelle Datenverarbeiter tauglich ist, sondern auch einem gestandenen Praktiker, wie etwa einem Werkmeister, den leichten Zugang ermöglicht. Die nächsten Forschungsaufgaben der Wirtschaftsinformatik, die auch an deutschen Lehrstühlen schon in Angriff genommen sind, liegen einmal in der Ergänzung von Dialogen auf dem Leitstand um wissensbasierte Elemente (Scheer und Mitarbeiter) und zum anderen in der Kombination von vielseitigen Umdispositionsheuristiken, Simulationsmodellen und Expertensystemen (XPS) (Mertens und Mitarbeiter). An der gleichen Schwachstelle zwischen Produktionsplanung und Produktionssteuerung setzt auch die Abhandlung von Scheer, Herterich und Zell über "Interaktive Fertigungssteuerung teilautonomer Betriebe" an. Neben einigen grundsätzlichen Gedanken sind vor allem die pragmatischen Überlegungen zur Arbeitsteilung zwischen Mensch und Maschine wichtig, die verbunden sind mit der Zuweisung von

Vorwort

5

Aufgaben zur automatischen, d.h. weitestgehend bedienerfreien Abarbeitung in Nachtschichten bzw. zur Abarbeitung in bedienerintensiven Tagschichten. Auch Mertens, Helmer, Rose und Wedel gehen in dem Beitrag "Ein Ansatz zu kooperierenden Expertensystemen bei der Produktionsplanung und -Steuerung" einen Schritt in Richtung auf Aufgabendezentralisation: Sie ergänzen ein PPSSystem (IBM-COPICS) um drei Wissensbasierte Systeme (WBS). In diesem Beitrag zeigen sich zwei zukunftsträchtige Tendenzen, und zwar einerseits die Integration von XPS mit konventioneller Software und zum anderen das Zusammenwirken von mehreren XPS. Der erste Ansatz ist allein schon aus Gründen der ökonomischen Softwareentwicklung von großer Bedeutung, denn man wird in der Praxis nur in den seltensten Fällen die mit enormem Personalaufwand über viele Jahre hinweg eingeführten und zumindest auf Teilbereichen ausgereiften großen PPS-Pakete abschaffen und durch eine völlig neue Generation wissensbasierter Programme ersetzen wollen und können. Die zweite Tendenz, also die Kooperation mehrerer XPS, markiert nur den Anfang bzw. eine Variante unter vielen möglichen und auch hie und da andiskutierten Erscheinungsformen verteilter WBS in der Produktion. Hier wird in Zukunft u.a. an hierarchische XPS mit ganz unterschiedlichen Verhandlungsmechanismen, aber auch an neuronale Netze zu denken sein. In der Arbeit von Rosenberg und Rode zeigt sich abermals, welche neuen Möglichkeiten durch die Fortschritte im Preis-Leistungs-Verhältnis der Arbeitsplatzrechner für betriebswirtschaftliche Anwendungen eröffnet werden. Dieser Beitrag über "PC-gestützte Simulationsmodelle zur Lösung von Verschnittproblemen" ist gleichzeitig ein Beispiel für die Vereinigung mehrerer Operations-Research-Modelle "unter einem betriebswirtschaftlichen Dach". Aus den Abhandlungen von Zwicker und Pleger sowie Scheer und Kraemer erkennt man den Beitrag der Wirtschaftsinformatik zur Weiterentwicklung nicht nur von Administrations- und Dispositions-, sondern auch von Informations-, Planungs- und Kontrollsystemen. Zwicker und Pleger beschreiben die "Strukturanalyse von Planungsmodellen", ein Verfahren der sogenannten sukzessiven Kausalkettenanalyse. Dabei hat der Benutzer im Dialog festzulegen, welche Folgen von Variablenbeziehungen eines Modells untersucht werden sollen. Bei näherem Hinsehen erkennt man hier interessante Parallelen zu dem Ansatz, der von Scheer und Kraemer bei der "Konzeption und Realisierung eines Expertenunterstützungssystems im Controlling" skizziert wird. Im ersten Fall hilft das Dialogsystem, den Überblick über viele Beziehungen (von Variablen) im Rahmen eines Planungssystems zu wahren, während im zweiten Fall ein Controller dabei unterstützt wird, das komplizierte Geflecht von Abweichungen und Abweichungsursachen bei absoluten und relativen KostenWerten zu durchdringen.

6

Vorwort

Die "Konzeption eines Bildschirmtext-gestützten Warenwirtschaftssystems zur Kommunikation in verzweigten Handelsunternehmungen" von Scheer und Leismann demonstriert die Bemühungen der Wirtschaftsinformatik, neuere Entwicklungen der Datenverarbeitung auch mittelständischen Unternehmen zugute kommen zu lassen. Im Teil 2 werden Forschungsprojekte zu "Methoden und Werkzeugen zur Entwicklung betrieblicher Anwendungssysteme" vorgestellt. Die Entwicklung betriebswirtschaftlicher Informationssysteme ist ein komplexer Prozeß. Nicht nur die mit der Softwareentwicklung verbundenen hohen Kosten, sondern auch die organisatorische Bewältigung der Aufgaben erfordern den Einsatz von Methoden und Werkzeugen. Während die in der Informatik entwickelten Ansätze in der Regel keinen direkten Bezug zu betrieblichen Anwendungen haben, wird bei den hier behandelten Forschungsprojekten der Bezug zu umfassenden betriebswirtschaftlichen Informationssystemen besonders herausgestellt Der Beitrag "INCOME - Methoden und Werkzeuge zur betrieblichen Anwendungsentwicklung" von Stucky, Nemeth und Schönthaler beschreibt eine Softwareproduktionsumgebung, die alle Phasen von der Grobspezifikation bis zur Programmierung und anschließenden Wartung umfaßt. Besonderes Kennzeichen des Systems ist, daß die konzeptuelle Modellierung der Datenstrukturen sowie der auf ihnen aufsetzenden Transaktionen im Vordergrund stehen. Zur einheitlichen Darstellung aller Strukturen und Abläufe werden Petri-Netze eingesetzt. Auch dem Beitrag "Konzeption und Realisierung eines Systemanalytiker-Arbeitsplatzes" von Gutzwiller und Österle liegt ein umfassender Ansatz zur Systementwicklung zugrunde. Es wird angestrebt, einem betrieblichen Systemanalytiker nicht nur eine einheitliche Entwurfsmethodik zur Verfügung zu stellen, die alle Phasen der Softwareentwicklung abdeckt, sondern darüber hinaus diese auch unter einer einheitlichen Benutzeroberfläche zu gestalten. Eine ebenfalls alle Entwurfsphasen begleitende Datenbank enthält die in den einzelnen Phasen entstandenen Entwurfsdokumente. Hierbei wird der objektorientierten Abbildung von Datenstrukturen gefolgt. Auf einer Entwicklungsdatenbank baut auch der Beitrag "Interaktive Entwurfsmethode zur computergestützten Herstellung betriebswirtschaftlicher Anwendungssoftware" von Preßmar, Eggers und Reinken auf. Ziel des zugrunde liegenden Projekts, das von einem funktionalen Phasenschema ausgeht, ist es, aus der Systemspezifizierung, die in der Systemelemente-Datenbank abgelegt ist, durch Aufsatz von Generatoren einen ablauffahigen Programmcode zu erzeugen. Auch hier wird die Softwareentwicklung durch eine benutzerfreundliche, grafische Benutzeroberfläche weiter unterstützt

Vorwort

7

In dem Beitrag von Kurbel und Pietsch über "Projektmanagementebenen bei evolutionärer Sofiwareentwicklung" wird ebenfalls von der hohen Komplexität des Entwicklungsprozesses betriebswirtschaftlicher Anwendungssystemeausgegangen. Hier wird vor allen Dingen betont, daß eine lineare phasenorientierte Entwicklung in vielen Fällen nicht möglich ist, sondern in und zwischen den Phasen Zyklen und Überarbeitungen stattfinden, die sich auch auf vorgelagerte und nachgelagerte Arbeitsschritte auswirken. Aus diesem Grunde wird eine Methodologie zur Projektsteuerung erarbeitet, die von vornherein Zyklen und komplexe Abstimmungsprozesse zuläßt. Sie ist insbesondere für die Unterstützung von Prototyping-Ansätzen und auch zur Erstellung von Expertensystemen einsetzbar. Im Mittelpunkt des Systems steht wiederum eine Datenbank, die alle für ein Projekt wesentlichen Komponenten enthält: insbesondere die Entwicklungsstrategie, die eingesetzten Ressourcen, die innerhalb des Projekts auszufüllenden Rollen sowie Aufgaben und Abhängigkeiten zwischen verschiedenen Aufgaben, inhaltliche Beziehungen zwischen Daten und konkrete Entwicklungsaktivitäten. In Teil 3 werden Projekte zur "Analyse und Gestaltung betrieblicher Organisationsund Kommunikationsstrukturen" beschrieben. Mit der Einführung komplexer Systeme der modernen Informationstechnologie, insbesondere auf dem Gebiet der Industrieautomatisierung (CIM) oder Büroautomatisierung (Office Automation), sind auch umfangreiche ablauf- und aufbauorganisatorische Änderungen verbunden. Die klassische Betriebswirtschaftslehre stellt zur Zeit noch keine ausreichenden Methoden und Werkzeuge zur Unterstützung dieser Aufgaben bereit. In der Arbeit von Krallmann, Feiten, Hoyer und Kölzer, "Die Kommunikationsstrukturanalyse zur Konzeption einer betrieblichen Kommunikationsarchitektur" wird ein Verfahren zur Ablaufanalyse für den Bereich der Büroautomatisierung, oder allgemeiner zur Verwaltungsrationalisierung, vorgestellt. Vorgänge werden in ihrem logischen und zeitlichen Ablauf erhoben, mit Hilfe eines computergestützten Systems grafisch aufgezeigt und analysiert. Der Beitrag "Entwurfsentscheidungen bei der Gestaltung eines Organisationsinformationssystems" von Heilmann zeigt, wie die Aufbauorganisation eines Unternehmens in einer Datenbank abgebildet werden kann. Hierbei werden insbesondere die Beziehungen zwischen den Stellen und Objekten des Unternehmens dargestellt. Probleme bereiten vor allem diezeitpunkt- und zeitraumbezogene Betrachtung einer Organisationsdatenbank sowie die Wahrung von Datenintegritätsbedingungen. Analog zum Bürobereich können auch Organisationsverfahren bei der Einführung von CIM eingesetzt werden. In dem abschließenden Beitrag von Krallmann und Scholz "Analyse und Modellierung von Kommunikationsarchitekturen in der rechnerintegrierten Produktion" werden Ablaufketten, die bei der Realisierung von CIM im Vordergrund stehen, grafisch dargestellt. Neben der Abbildung von sogenannten

Vorwort

8

Referenzabläufen können auch auf die konkreten Belange eines Unternehmens bezogene Abläufe erarbeitet und in ihren Auswirkungen simuliert werden. Die Forschungsvorhaben, aus denen die Beiträge dieses Bands hervorgegangen sind, wurden durch die Gutachter der DFG einer strengen Auslese unterzogen. Zusammen mit vielen konstruktiven Vorschlägen führte dies zu einer Stabilisierung des Schwerpunktprogramms auf einem qualitativ hohen Niveau. Im Verlauf des Programms waren als Gutachter tätig: Prof. Dr. J. Griese, Universität Bern Prof. Dr. H A . Hansen, Wirtschaftsuniversität Wien Prof. Dr. L.J. Heinrich, Universität Linz Prof. Dr. H. Jacob, Universität Hamburg Prof. Dr. G. Knolmayer, Universität Bern Prof. Dr. P. Lockemann, Universität Karlsruhe (Sprecher) Prof. Dr. H. Wedekind, Universität Erlangen-Nürnberg Ihnen sei an dieser Stelle herzlich für ihre Mühe gedankt. Dank gebührt auch Frau H. Hoppe, die von Seiten der Deutschen Forschungsgemeinschaft das Programm stets tatkräftig unterstützte, sowie den Mitarbeitern der Herausgeber, die die Detailarbeit bei der Aufbereitung und Vereinheitlichung der Manuskripte leisteten. Dies waren Dipl.-Kfm. P. Dornhoff (Dortmund), Dipl.-Wirtsch.-Ing. W. Kraemer (Saarbrücken) und Dipl.-Inf. H. Rose (Erlangen). Die Schriftleitung und Manuskriptproduktion mit einem Desktop-Publishing-System lag in den Händen von P. Dornhoff. Die Publikationen aus dem Schwerpunktprogramm sowie regelmäßige Kolloquien trugen im Zeitverlauf nicht nur dazu bei, den wissenschaftlichen Gedankenaustausch zwischen den Forschungsgruppen zu fördern, sondern insgesamt auch das Fachgebiet Wirtschaftsinformatik besser zu etablieren. Vor allem für den wissenschaftlichen Nachwuchs konnte so eine Erfahrungsbasis geschaffen werden, von der die Wirtschaftsinformatik in der längerfristigen Weiterentwicklung profitieren kann.

März 1989

Karl Kurbel Peter Mertens August-Wilhelm

Scheer

Vorwort

9

Anmerkungen [1] Vgl. z.B. Stahlknecht (1988), S. 15 ff. [2] Vgl. Heinrich (1988), S. 55 ff.

Literatur Heinrich, L.J.: Lehrangebote und Forschungsschwerpunkte Wirtschaftsinformatik; in: Heinrich, Kurbel (1988), S. 55-132. Heinrich, L.J., Kurbel, K. (Hrsg.): Studien- und Forschungsführer Wirtschaftsinformatik, 3. Auflage, Berlin et al. 1988. Stahlknecht, P.: Der Arbeitsmarkt für Wirtschaftsinformatiker; in: Heinrich, Kurbel (1988), S. 10-19.

Teil 1: Interaktive betriebswirtschaftliche Anwendungssysteme

Ein Ansatz zu kooperierenden Expertensystemen bei der Produktionsplanung und -Steuerung Peter Mertens, Jan Helmer, Hans Rose, Thomas Wedel

Inhalt 1 Einordnung in das Gesamtprojekt 2 Überblick über das Projekt UPPEX 2.1 Gesamtdarstellung 2.2 Modularprogramm COPICS 2.3 Modellbetrieb und Simulator 3 Teilsysteme 3.1 DIPSEX 3.1.1 Aufgabenstellung 3.1.2 Grundlagen 3.1.2.1 Schwachstellendiagnose als Kontrollinstanz bei der Regelung des Produktionsprozesses 3.1.2.2 Methodik der Schwachstellendiagnose 3.1.3 Ausgewählte Diagnosekonzepte für DIPSEX 3.1.3.1 Interpretation von Wirkungs-Ursache-Ketten 3.1.3.2 Heuristiken in Verbindung mit Verfahren der Mustererkennung 3.2 PAREX 3.2.1 Aufgabenstellung 3.2.2 Sammlung und Klassifikation der Parameter 3.2.3 Verschiedene PAREX-Einsatzmodi 3.2.3.1 Automatische Parameterveränderung 3.2.3.2 Durch DIPSEX angestoßene Eingriffe 3.2.3.3 Parametereinstellung auf Wunsch des Disponenten 3.2.4 Weiteres Vorgehen 3.3 UMDEX 3.3.1 Aufgabenstellung 3.3.2 Basiskonzepte 3.3.2.1 Grundfunktionen 3.3.2.2 Zusammenwirken der Grundfunktionen und stufenweise Diagnose 3.3.2.3 Bereichskonzept 3.3.3 Abweichungserkennung 3.3.4 Abweichungsbeurteilung

14

Expertensysteme bei der Produktionsplanung und -Steuerung

3.3.4.1 Grundsätzliche Überlegungen 3.3.4.2 Abweichungsbeurteilung im Kapazitätsbereich 3.3.4.3 Abweichungsbeurteilung im Werkstattauftragsbereich 3.3.5 Verfügbare Maßnahmen 4 Exemplarische Darstellung des Zusammenwirkens der drei Teilsysteme 5 Ausblick Anmerkungen Literatur

1 Einordnung in das Gesamtprojekt Die Forschungen am Lehrstuhl für Betriebswirtschaftslehre, insbesondere Wirtschaftsinformatik (in Verbindung mit der Informatik-Forschungsgruppe VIII), die von der DFG gefördert werden, haben "Expertensysteme zur Unterstützung betriebswirtschaftlicher Diagnosen und Beratungen" zum Gegenstand. Zu Beginn des Projektzeitraums wurden zwar bereits große Erwartungen in die XPS-Technik gesetzt, mit wenigen Ausnahmen (z. B. XCON von DEC) mangelte es aber sowohl an Systemen als auch an Tools. Mit Hilfe des von uns speziell für den betriebswirtschaftlichen Bereich entwickelten Expertensystemtools HEXE [1] haben wir schwerpunktartig Prototypen für die Untersuchung der relativen Unternehmensentwicklung [2], für die Automatisierung der Eingangspostbearbeitung in der Bürokommunikation [3] und für die Diagnose von Schwachstellen in der Produktionsplanung und -Steuerung [4] geschaffen. Diese Prototypen wurden und werden von uns mit alternativen Entscheidungsunterstützungstechniken sowie mit menschlichen Experten verglichen [5]. Aufgrund der während unserer Arbeit gesammelten Informationen über betriebliche Expertensysteme [6] kristallisierte sich das Gebiet der Produktionsplanung und -Steuerung (PPS)/Logistik als zwar schwierig, aber zugleich auch wissenschaftlich reizvoll heraus. Dabei sind verschiedene Ansätze möglich, Wissensbasierte Systeme in die Problemlösung einzubeziehen (vgl. Abbildung 1 [7]). Ansätze, die komplette PPS innerhalb eines Expertensystems (XPS) abzubilden (vgl. Abbildung 1, Punkt "A", beispielhaft wären hier das System ISIS und dessen Nachfolger OPIS zu nennen), haben trotz großer Anstrengungen noch nicht den erwarteten Erfolg gebracht; ein Durchbruch ist auch auf absehbare Zeit nicht in Sicht. Wir verfolgen daher den gemischten Ansatz, bei dem das PPS-System um Expertensystemkomponenten ergänzt wird. An der in Abbildung 1 mit "B" markierten Stelle ist ein Vorhaben angesiedelt, die Initialisierung eines PPS-Systems (RM von SAP) bei seiner Erstinstallation zu unterstützen. Punkt "C" kennzeichnet den Bereich, in dem das im folgenden beschriebene und größtenteils von der DFG geförderte Projekt UPPEX (Unterstützung der Produktionsßlanung- und -Steuerung durch Expertensysteme') angesiedelt ist. Dabei werden die Funktionen der Schwach-

15

Expertensysteme bei der Produktionsplanung und -Steuerung

stellendiagnose, der laufenden Parametereinstellung und der Umdisposition von jeweils einem XPS wahrgenommen, die miteinander kooperieren. Auf Punkt "D" wird im Rahmen des im fünften Kapitel gegebenen Ausblicks Bezug genommen. PPS-Misere

vollständiger XPS-Ansatz

mehrere X P S

gemischter Ansatz (XPS mit P P S )

/*r\

ein X P S

hierarchisch

ein X P S pro Ebene

mehrere XPS

(?)

regionale Aufteilung

(b)

nicht hierarchisch

mehrere XPS pro Ebene

funktionale Aufteilung

ein X P S

funktionale Aufteilung

reaionale Aufteilung

produktbezogene Aufteilung

produktbezogene Aufteilung

Abb. 1: Systematisierang wissensbasierter Ansätze bei der PPS

2 Überblick über das Projekt UPPEX 2.1 Gesamtdarstellung In dem Projekt UPPEX soll schwerpunktmäßig untersucht werden, inwieweit klassische, auf der MRP-Philosophie basierende PPS-Systeme um Expertensystemkomponenten erweitert werden können. Den Überlegungen liegt eine Werkstattfertigung zugrunde. Abbildung 2 zeigt das Gesamtprojekt im Überblick. Das Vorhaben baut auf dem PPS-Paket COPICS (Customer Qriented Production Information and£ontrol System) von IBM auf. Eine Kurzdarstellung dieses Systems findet der Leser im folgenden Kapitel. Zum Aufbau einer für Forschung und Lehre geeigneten Testumgebung wurde ein Modellbetrieb erstellt, der das Geschehen einer Fahrradfabrik in etwas vereinfachter Form abbildet. Vorgesehen ist, die damit

16

Expertensysteme bei der Produktionsplanung und -Steuerung

gewonnenen Plandaten (auf Arbeitsgangebene) einem Simulator zu übergeben, der unter Berücksichtigung der in der Realität auftretenden Störungen "geeignete" IstDaten an COPICS rückmeldet (vgl. zu Modellbetrieb und Simulator auch Kapitel

Abb. 2: Projektüberblick

Die in diesem Rahmen ablaufenden Planungs- und Steuerungsvorgänge sollen durch drei Expertensysteme unterstützt werden: DEPSEX (Diagnose von Produktionsschwachstellen durch ein Expertensystem'). PAREX (Parametereinstellung durch ein Expertensystem), UMDEX (Umdisposition durch ein Expertensystem). DIPSEX analysiert Planvorgaben und Rückmeldungen der Fertigung und versucht, aus diesen Daten Schwachstellen im betrieblichen Ablauf aufzudecken. Die gewonnenen Informationen sind einerseits dem Führungspersonal zur Verfügung zu stellen, andererseits dienen sie auch als Eingabedaten für UMDEX und PAREX. Letzteres hat zum Ziel, die in COPICS zahlreich vorhandenen Parameter geeignet einzustellen. Dennoch werden im Regelfall Soll- und Ist-Werte divergieren. UMDEX unterstützt den Disponenten bei der Analyse der Abweichungen und der Suche nach geeigneten Gegenmaßnahmen. Es soll insbesondere die Informationslücke schließen, die durch die relativ großen Abstände der einzelnen Planungsläufe eines komplexen PPS-Systems entsteht

Expertensysteme bei der Produktionsplanung und -Steuerung

17

Die Entwicklung der beiden letztgenannten XPS wird durch die Deutsche Forschungsgemeinschaft im Rahmen dieses Schwerpunktprogrammes gefördert 2.2 Modularprogramm COPICS Um dem Leser eine Einordnung der im folgenden teilweise angesprochenen Module zu ermöglichen, wird in Abbildung 3 [8] deren Zusammenwirken im Gesamtsystem schematisch dargestellt 2.3 Modellbetrieb und Simulator Die Entscheidung, in dem in Aufbau befindlichen Modellbetrieb Fahrräder zu "produzieren", basiert auf der sehr guten Anschaulichkeit des Produktionsprogramms. Dennoch ist eine für Forschungszwecke hinreichende Komplexität garantiert, was aus den "Zahlen des Unternehmens" deutlich wird. Der Modellbetrieb entspricht einem realen mit ca. 350 Beschäftigten in der Fertigung und einem geschätzten Jahresumsatz von 50 - 60 Mio. DM. Auf drei Produktgruppen aufgeteilt finden sich 47 verschiedene Fahrräder, die sich mehr oder weniger stark unterscheiden. Zu ihrer Herstellung sind ungefähr 700 verschiedene Teile erforderlich, obwohl auf sog. "Kleinteile" bereits verzichtet wurde. Die Produktion erfolgt mit 120 Einzelmaschinen. Schwierigkeiten bereitet zur Zeit noch die Realisierung des Simulators. Obwohl bereits ein entsprechendes Grobkonzept vorliegt, ergeben sich aufgrund der sehr komplexen Betriebssystemumgebung, in der COPICS läuft (hier DOS/VSE und CICS), immer noch Probleme.

3 Teilsysteme 3.1 DIPSEX 3.1.1 Aufgabenstellung Pabst [9] stellte bei der Untersuchung der betriebswirtschaftlichen Auswirkungen eines PPS-Systems fest, daß allein durch ein effizienteres Planungs- und Steuerungssystem der Bilanzgewinn verdoppelt hätte werden können. Diese exakte Aussage spiegelt die in der Praxis weit verbreitete Unzufriedenheit mit den Ergebnissen computergestützter Produktionsplanung und -Steuerung wider. Kritik entzündet sich jedoch nicht allein an den oftmals nur ungenügend in die Betriebsstruktur integrierten PPS-Systemen selbst [10], sondern vielmehr auch an deren aufwendigen und nur scheinbar optimalen Planungsverfahren.

18

Expertensysteme bei der Produktionsplanung und -Steuerung

Abb. 3: COPICS im Überblick

Expertensysteme bei der Produktionsplanung und -Steuerung

19

In der Praxis geht zudem in Betrieben, die nach dem Werkstättenprinzip organisiert sind, der Überblick über den Fertigungsablauf rasch verloren. Eventuelle Schwachstellen werden deshalb in der Regel erst erkannt, wenn sie zu extremen Auswirkungen führen, wie z. B. überlaufenden Zwischenlagern oder permanent unterbeschäftigten Arbeitsplätzen. Die in konventionelle PPS-Systeme integrierten Berichtsmodule vermögen, selbst wenn sie um Diagnosefunktionen erweitert wurden, nur wenig zur Entschärfung der Situation beizutragen. Häufig werden deshalb externe Berater zur Schwachstellensuche in Produktion und Materialwirtschaft hinzugezogen. Bei diesen besteht jedoch die Gefahr, daß "gewußt wo"-Ansätze an die Stelle einer methodischen Vorgehensweise treten. Allgeyer hat aus diesem Grund das Expertensystem DIPSEX entwickelt, welches einen Betriebsanalytiker, der systematisch nach Schwachstellen und ihren Ursachen sucht, bei seiner Analysetätigkeit assistieren und so gewissermaßen als "Brain amplifier" wirken soll [11]. Unser Ziel ist es, ausgehend von dem Prototypen Allgeyers ein Expertensystem zu entwickeln, welches automatisch und in enger Anbindung an das PPS-System COPICS Schwachstellendiagnosen in einem Modellbetrieb durchfühlt. DIPSEX (das Akronym DIPSEX soll auch bei dem neuen Projekt beibehalten werden) muß dabei, wie bereits in Kapitel 2.1 ausgeführt, im Zusammenhang mit den beiden anderen Expertensystemen PAREX und UMDEX gesehen werden. 3.1.2 Grundlagen von DIPSEX 3.1.2.1 Schwachstellendiagnose als Kontrollinstanz bei der Regelung des Produktionsprozesses Will man die Einhaltung von Zielen sicherstellen, so ist Kontrolle als Gegenstück zur Planung unerläßlich. DIPSEX muß deshalb permanent die Produktion sowie alle Abläufe zu deren Planung und Steuerung analysieren. Hierbei sollen in regelmäßigen Zeitabständen Berichte erzeugt werden, die aus Zahlen, Grafiken oder Expertisen bestehen. Bei den Untersuchungen kommt es vor allem darauf an, permanente Schwachstellen aufzudecken und im Sinne eines "Frühwarnsystems" insbesondere auch auf besorgniserregende Tendenzen in der Produktion hinzuweisen. Vereinzelt auftretende Ausschläge, wie etwa kurzfristig zu lange Warteschlangen vor einer Maschinengruppe, berücksichtigt das System UMDEX. Der Rückkopplungseffekt, der durch das Aufdecken von Schwachstellen und deren Beseitigung entsteht, ermöglicht es DIPSEX, die Auswirkungen seiner Diagnosen und der darauffolgenden Therapien zu beurteilen und gegebenenfalls zu revidieren.

20

Expertensysteme bei der Produktionsplanung und -Steuerung

Die angestrebte Optimierung der Produktion und Materialwirtschaft ist somit ein kontinuierlicher Prozeß. 3.1.2.2 Methodik der Schwachstellendiagnose Die im folgenden skizzierte Vorgehensweise zur Schwachstellendiagnose, welche im wesentlichen auf der Methodik von Allgeyer beruht, soll als Grundlage für DIPSEX dienen. In einem ersten Schritt werden die Daten des PPS-Systems so organisiert und verdichtet, daß während der eigentlichen Diagnose effizient auf die erstellte Datenbasis zugegriffen werden kann. Bei diesem Vorgang werden zunächst systematisch der Ist-Zustand analysiert und Symptome für Schwachstellen ermittelt. Ausgehend von signifikanten Abweichungen der Ist-Werte von ihren Sollwerten sind weitere Untersuchungen anzustoßen. Bei der Interpretation der Schwachstellensymptome ist es nicht immer möglich, zweifelsfrei bestimmte Schwachstellen zu identifizieren. Vielmehr ergeben sich in diesem Stadium der Diagnose, der sogenannten Verdachtsgenerierung, zunächst nur Verdachtsmomente. Da unterschiedliche Schwachstellen oftmals ähnliche oder gar gleiche Symptome hervorrufen, muß noch eine Verdachtsüberprüfung stattfinden. Bereits erzielte Diagnoseergebnisse werden dabei auf ihre Stichhaltigkeit überprüft. Falls eine Schwachstelle nicht als gesichert angesehen werden kann, muß der Diagnoseprozeß unter Umständen nochmals durchlaufen werden. Wenngleich die Therapie nicht unmittelbar Aufgabe von DIPSEX ist, da ja entweder PAREX die Einstellung des PPS-Systems ändert oder UMDEX Umdispositionen vornimmt, so ist es dennoch wünschenswert, daß DIPSEX auch Vorschläge zur Behebung der Schwachstellen macht. Hierbei muß bedacht werden, daß man häufig bei der Beseitigung von Fehlerquellen nur Kompromißlösungen erzielen kann, da es oftmals nicht möglich sein wird, alle Schwachstellen simultan zu beseitigen. In einer derartigen Situation wird man sich vor allem auf solche Fehlerquellen konzentrieren, von deren Behebung man sich den größten Nutzeffekt verspricht. Als abschließende Phase der Schwachstellendiagnose bietet es sich deshalb an, eine Bewertung der Schwachstellen vorzunehmen und diese entsprechend ihrer vermuteten Auswirkung auf das betriebliche Gesamtergebnis zu ordnen. 3.1.3 Ausgewählte Diagnosekonzepte für DIPSEX 3.1.3.1 Interpretation von Wirkungs-Ursache-Ketten Bei der Interpretation des Ist-Zustandes muß aufgrund von Symptomen auf eventuelle Schwachstellen der Fertigung geschlossen werden. Die Symptome kann man als

Expertensysteme bei der Produktionsplanung und -Steuerung

21

die Phänomene von Wirkungs-Ursache-Beziehungen, oft in Form ganzer Kausalketten, verstehen. Falls es gelingt, fundiertes Wissen über die Wirkungszusammenhänge zwischen Schwachstellen und ihren Symptomen zu erhalten, lassen sich Wirkungs-Ursache-Ketten bilden. Anhand dieser Ketten kann man dann jedes Symptom auf elementare Ursachen zurückführen. Bei diesem Ableitungsprozeß wird man als "diagnostischen Mittelbau" [12] eine Reihe von Grobdiagnosen erhalten, die man bei der Suche nach weiteren Schwachstellen als partielle Interpretationen des IstZustandes verwenden kann. Folgendes Beispiel mag dies verdeutlichen: Ein nicht befriedigender Umsatz kann auf ein zu geringes Absatzvolumen zurückgeführt werden, welches seinerseits durch eine limitierte Produktionsmenge bestimmt wird. Eine weitergehende Analyse deckt als Ursache dieser Begrenzung z.B. Kapazitätsengpässe auf, die durch zu häufiges Umrüsten als Folge zu kleiner Losgrößen entstanden sein können. Allgeyer hat bei seiner Arbeit ausschließlich Wirkungs-Ursache-Ketten verwandt, da sich dieses Konzept hervorragend in das Produktionsregel-Paradigma eines Expertensystemtools einpassen läßt. Als Gedankengerüst zur strukturierten Zusammenfügung des gesammelten Wissens orientierte sich Allgeyer an einer nach typischen Details der Materialwirtschaft und Produktion ausgebauten DuPontPyramide. Diese gestattete es, die Veränderung einzelner Kennzahlen auf elementare Schwachstellen herunterzubrechen. 3.1.3.2 Heuristiken in Verbindung mit Verfahren der Mustererkennung Da es nicht immer möglich ist [ 13], mit deduktiven Ursache-Wirkungs-Analysen im Produktionsbereich zu arbeiten, muß man auch an heuristische Verfahren zur Unterstützung der Schwachstellendiagnose denken. Baitella entwickelt etwa eine sogenannte Schwachstellen-Einflußgrößen-Matrix, in der potentielle Fehlerquellen ihren jeweiligen Symptomen gegenübergestellt sind. Anhand dieser Matrix soll dann auf die Ursache von Symptomen geschlossen werden können [14]. Für DIPSEX ließe sich an eine methodische Fortsetzung dieses Konzeptes denken. Weiß man beispielsweise aus empirischen Untersuchungen oder aus Erfahrungen, die man bei der Simulation gemacht hat, daß bei einem gewissen Ist-Zustand der Fertigung eine bestimmte Therapiemaßnahme Erfolg bringt, so kann man diese Therapie auch dann anwenden, wenn man die eigentlichen Wirkungs-Ursache-Ketten nicht kennt. Diese Argumentation läßt sich an einem Analogon aus der Medizin verdeutlichen: Die Fähigkeit des bekannten Arzneimittels Aspirin, Kopfschmerzen zu lindern, ist unbestritten, obwohl niemand weiß, wie diese Wirkung genau zustande kommt Erkennt man in den Daten der Fertigung mit statistischen oder mit Verfahren der Mustererkennung (z. B. intelligenten Suchalgorithmen) ein Muster, d. h. eine bestimmte Symptomkonstellation, welches in aller Regel mit einer bekannten

22

Expertensysteme bei der Produktionsplanung und -Steuerung

Therapie erfolgreich "behandelt" werden kann, so sollte diese Therapie auch angewandt werden. 3.2 PAREX 3.2.1 Aufgabenstellung Auf dem Markt, insbesondere dem für Großrechner-Anwendungen, gibt es heute eine Reihe sehr funktionsreicher PPS-Modularprogramme. In der betrieblichen Praxis stellen sich jedoch die bei der Einführung solcher recht teuerer Systeme erhofften Nutzeffekte häufig nicht oder nur teilweise ein. Dies liegt zum einen an prinzipiellen oder individuellen methodischen Schwächen der PPS-Pakete, die in der Literatur hinlänglich diskutiert werden. Zum anderen können die Stärken des Systems wegen der schwierigen Einstellung der umfangreichen Parametersets, die der Anpassung der Standardsoftware an unternehmensspezifische Zielsetzungen dienen sollen, vom Menschen aber in ihren Wirkungen kaum zu übersehen sind, die Stärken der Systeme oft nicht ausgespielt werden [15]. Es liegt daher der Gedanke nahe, den Menschen bei der Einstellung der Parameter durch ein Wissensbasiertes System zu unterstützen. Die Aufgaben eines solchen Expertensystems zerfallen in zwei Teilbereiche, nämlich - das statische Problem der Auffindung einer auf unternehmensspezifische Anforderungen abgestimmten Initialeinstellung der Parameter bei der Installation des PPS-Systems, bei Konfigurationsänderungen hinsichtlich seiner Module oder bei erstmaliger Durchführung von Abläufen (z.B. durch die Inbetriebnahme neuer Fertigungsaggregate) und - die dynamische Parametereinstellung im laufenden Betrieb, die sich an der aktuellen Situation im Unternehmen orientiert PAREX beschäftigt sich mit Problemen der letztgenannten Art, wobei der Schwerpunkt auf dem Eigenfertigungssektor liegt, d.h., Parameter in Fremdbezugs-Funktionen des PPS-Systems werden von PAREX nicht behandelt. 3.2.2 Sammlung und Klassifikation der Parameter Das von uns betriebene PPS-System COPICS (vgl. Kapitel 2.2) mußte in einem ersten Schritt systematisch auf seine Parameter untersucht werden. Unter einem Parameter soll in diesem Zusammenhang eine Stellgröße verstanden werden, durch deren Veränderung der Mensch das Verhalten des PPS-Systems beeinflussen kann.

Expertensysteme bei der Produktionsplanung und -Steuerung

23

Dieser Prozeß der Identifikation und Grobanalyse möglichst aller Parameter gestaltete sich aufwendiger als zunächst erwartet, da das in vielen Fällen wenig aufschlußreiche Handbuchmaterial keine zweifelsfreie Erkennung parametrischer Eingriffsmöglichkeiten zuließ. Eine reine Handbuchstudie zur Ermittlung von Parametern schied damit aus. Um eine vollständige Sammlung sicherzustellen, wurden zuerst sämtliche aufrufbaren Online-Transaktionen sowie die Batch-Programme auf Stellgrößen untersucht, die einen Einfluß auf das Verhalten des PPS-Systems haben und nicht nur Eigenschaften von Stammdaten aufweisen. Bei diesem Vorgehen wurden die Parameter gewissermaßen Top-Down von jedem COPICS-Modul herab zur einzelnen Funktion ermittelt. Anschließend konnte die Vollständigkeit der Parametermenge in einem Bottom-Up-Prozeß aus den Formatbeschreibungen der einzelnen DL/I-Datenbanken, auf denen COPICS aufbaut, überprüft werden. Auf diese Weise wurden in der zugrundeliegenden COPICS-Version etwa 120 Stellen gefunden, an denen auf die Planungsergebnisse Einfluß genommen werden kann. Nach Abzug der Parameter der Fremdbezugsmodule, auf deren Einstellung im Rahmen von PAREX nicht eingegangen werden soll, verbleiben etwas mehr als 100 PPS-Parameter im Eigenfertigungsbereich, die sich auf die einzelnen Module wie folgt verteilen (Abbildung 4): COPICS-Modul Bestandsplanung und Bedarfsvorhersage (IPF) Produktionsplanung für Enderzeugnisse (MPSP) Materialbedarfsplanung (MRP) Kapazitätsbedarfsplanung (CRP) "Klassische" Fertigungsauftragsfreigabe (SOR) Belastungsorientierte Auftragsfreigabe (BOA) Terminrechnung und Belastungsanalyse (SL&R)

Parameter

7 22 23 14

6

25 23

Abb. 4: Anzahl der Parameter je dispositivem COPICS-Modul

Dabei umfaßt diese Liste nur solche Module, die dispositiven Charakter haben. Die restlichen Komponenten, wie etwa die Arbeitsplanverwaltung oder die Bestandsführung, erfüllen rein administrative Funktionen. Daß die Summe der aufgeführten Parameter deutlich über 100 beträgt, liegt daran, daß einige in mehr als nur einer COPICS-Komponente wirken, wie z.B. der Splittungsschlüssel, der in den Modulen Kapazitätsbedarfsplanung, Fertigungsauftragsfreigabe sowie Terminrechnug und Belastungsanalyse die Terminierung von Aufträgen beeinflußt Interessanterweise existieren noch einige Stellen mit quasi verstecktem parametrischen Einfluß, bei denen durch Variation logisch voneinander abhängiger Datenfel-

24

Expertensysteme bei der Produktionsplanung und -Steuerung

der beabsichtigte oder unbeabsichtigte Auswirkungen auf Planungsergebnisse entstehen. Beispielsweise gibt es im Bereich der Materialbedarfsplanung für jedes Teil eine Gesamt-Bearbeitungszeit, die bei der Berechnung von Vorlaufzeiten verwendet wird. Sie stellt an sich ein Ist-Datum dar, dessen Veränderung auf den ersten Blick nicht Ausdruck eines planerischen Willens ist. Diese Gesamt-Bearbeitungszeit braucht jedoch nicht mit der Summe der Einzel-Bearbeitungszeiten aus dem Arbeitsplan für dieses Teil identisch zu sein; auf der Ebene der Materialbedarfsplanung ergeben sich somit andere geplante Durchlaufzeiten als bei der Terminierung im Werkstattauftragsbereich. Im Grad der Abweichung beider Zeiten liegt also ein weiterer, nicht sofort ersichtlicher Parameter, dessen Nutzung von COPICS-Experten sogar ausdrücklich empfohlen wird. Um eine Beurteilung der prinzipiellen Eignung eines Parameters zur wissensbasierten Einstellung zu erleichtern und um die spätere Umsetzung des Expertenwissens zu unterstützen, wurden die einzelnen Eingriffsmöglichkeiten klassifiziert. Jeder Parameter wird nach mehreren Kriterien in eine Klasse eingeordnet. So ist für eine wissensbasierte Einstellung z.B. wichtig, auf welche Objekte sich ein Parameter bezieht, in welchen Modulen er wirkt, welche tendenziellen Auswirkungen er auf Fertigungsziele hat oder mit welcher Frequenz er in der Praxis üblicherweise geändert wird. Als Resultat dieses Schrittes kann folgendes festgehalten werden: - Rund ein Drittel der Parameter erscheint zumindest in einem ersten Schritt nicht für die Einstellung durch ein Expertensystem geeignet, da für die Entscheidung über den einzustellenden Wert Wissen nötig ist, das nicht scharf genug eingegrenzt werden kann. Ein solcher Parameter wäre z. B. die Wahl des sogenannten MPSP-Teiletyps, mit dem festgelegt wird, ob ein Teil in die langfristige Planung der MRPII-Komponente von COPICS aufgenommen werden soll. - Etwa ein weiteres Drittel legt zwar eine statische, nicht jedoch eine dynamische wissensbasierte Konfiguration nahe. Beispiele für diese Klasse sind die Terminschranke einer Maschinengruppe für die Belastungsorientierte Einplanung, die hauptsächlich in Abhängigkeit von der Leistungsfähigkeit der Kapazitätseinheit, weniger jedoch von der aktuellen Fertigungssituation errichtet werden sollte, oder die Auswahl, ob die Kapazitätsbedarfsplanung nicht nur geplante, sondern auch schon eröffnete Werkstattaufträge behandeln soll (dies empfiehlt sich nur dann, wenn das Modul Terminrechnung und Belastungsanalyse bzw. die Teilfunktionen Belastungsorientierte Auftragsfreigabe der Fertigungsauftragsfreigabe nicht installiert sind). - Das verbleibende Drittel der Parameter ist für eine dynamische wissensbasierte Einstellung geeignet und bildet somit die Basis für PAREX. Ein Beispiel hierfür ist der Mindestabstand zwischen zwei Aufträgen der Materialbedarfsplanung für das gleiche Teil, mit dem die Losgrößen von Fertigungsaufträgen beeinflußt werden können.

Expertensysteme bei der Produktionsplanung und -Steuerung

25

3.2.3 Verschiedene PAREX-Einsatzmodi Auf der Basis der für den PAREX-Einsatz geeigneten Parameter sind mehrere Betriebsarten möglich. Prinzipiell ist zu unterscheiden, ob PAREX auf eigene Veranlassung die Werte bestimmter Parameter verändert, ob dies auf Initiative des Nachbarsystems DIPSEX geschieht oder ob der menschliche Disponent das System zur Unterstützung einer Parametereinstellung hinzuzieht 3.2.3.1 Automatische Parameterveränderung In diesem Modus entscheidet PAREX ohne entsprechende Aufforderung von außen, ob und wie ein Parameter verstellt werden soll. Es liegt also kein konkreter Anlaß vor, der ein Eingreifen nötig macht, sondern es ist nur zu untersuchen, ob die eingestellte Konfiguration in der aktuellen Lage noch Sinn macht. Beispielsweise könnte PAREX erkennen, daß ein Fertigungsauftrag, der gesplittet werden soll, an der nachfolgenden Maschinengruppe wegen der zum Ankunftszeitpunkt prognostizierten Warteschlangenlänge ohnehin keine Chance hätte, zügig weiterbearbeitet zu werden. Durch die vorgesehene Splittung des Loses würden also an der aktuellen Maschinengruppe unnötigerweise erhöhte Rüstkosten erzeugt und darüber hinaus Kapazität verschenkt, die ein anderer Auftrag dringend benötigen könnte. Daher müßte PAREX in einem solchen Fall die ursprünglich geplante Splittung des Auftrags aufheben. PAREX überprüft in dieser Betriebsart quasi die Konsistenz der aktuellen Parametereinstellung mit der momentanen Fertigungssituation. Hinsichtlich der prinzipiellen Arbeitsweisen gibt es zwei Möglichkeiten: - PAREX läuft im Hintergrund ständig mit, registriert sämtliche Rückmeldungen aus der Fertigung oder vom Menschen online geänderte Planvorgaben und greift bei Bedarf in das Parametergefüge ein; dieser Modus entspricht bei Datenbanksystemen den sogenannten "Dämonen", die auf den Eintritt vorgegebener Bedingungen warten und dann aktiv werden. Es ist allerdings fraglich, ob bei einem PPS-System wie COPICS, das nur auf Tagesbasis plant, eine derartige Echtzeitreaktion überhaupt sinnvoll ist und ob im Interesse der Planungsruhe häufige marginale Parameteränderungen nicht besser unterlassen werden sollten. - COPICS isteinPPS-System.dasonlinearbeitenkann. Mittels Online-Transaktionen werden aber zumeist nur die Ergebnisse vorheriger Batch-Läufe der aktuellen Situation angepaßt oder Ausnahmesituationen behandelt, die einer schnellen Reaktion oder menschlicher Aufsicht bedürfen. Die schädliche Wirkung falsch eingestellter Parameter entfaltet sich also in besonderem Maße bei Läufen von Batch-Programmen. Daher liegt es nahe, eine Überprüfung der Plausibilität der vorliegenden Parametereinstellung und bei Bedarf deren Veränderung vor dem Lauf von COPICS-Batch-Programmen vorzunehmen. PAREX arbeitet in einem

26

Expertensysteme bei der Produktionsplanung und -Steuerung solchen Fall also selbst gewissermaßen im S tapelbetrieb die vorliegende Parameterkonfiguration ab. Da die Batch-Programme der Auftragsfreigabe ohnehin täglich ausgeführt werden sollten, stünde einem vorherigen Lauf von PAREX nichts im Wege. Probleme dürfte in einem solchen Modus hauptsächlich der Fall bereiten, daß PAREX den Menschen zur Beurteilung einer Situation hinzuziehen muß, der Spezialist aber beim nächtlichen Batch-Lauf nicht greifbar ist und damit auch der nachfolgende COPICS-Batch-Lauf nicht gestartet werden kann.

3.2.3.2 Durch DIPSEX angestoßene Eingriffe PAREX kann auch auf Initiative des Partnersystems DIPSEX tätig werden. Beispielsweise könnte DIPSEX daraufhinweisen, daß sich bei einem Engpaßaggregat Ausfälle häufen, die über das bisher angenommene Ausmaß hinausgehen und daher de facto eine Reduzierung der einplanbaren Kapazität bewirken. Darauf müßte PAREX möglichst schnell reagieren, damit COPICS die veränderte Situation bei der nächsten Ausführung von Planungsfunktionen geeignet berücksichtigt. Als ein weiteres Beispiel in dieser Betriebsart sei der Fall einer DIPSEX-Warnung angeführt, daß bei einer Maschinengruppe in letzter Zeit häufig der Nachschub an Fertigungsaufträgen abgerissen ist. Daraufhin könnte PAREX die dieser Maschinengruppe zugeordnete Belastungsschranke erhöhen. Ein dringender Handlungsbedarf besteht jedoch nicht, da ein Hochsetzen der Belastungsschranke bei einer zum Zeitpunkt der Meldung stillstehenden Maschinengruppe keine sofortige Wirkung hat; eine Reaktion braucht also erst beim nächsten Batch-Lauf (vgl. Abschnitt 3.2.3.1) zu erfolgen. 3.2.3.3 Parametereinstellung auf Wunsch des Disponenten Schließlich mag auch der Fall eintreten, daß der Mensch die Hilfe von PAREX bei der Einstellung von Parametern in Anspruch nimmt, beispielsweise die Ermittlung geeigneter Werte bei der Einplanung eines Eilauftrages. Hier kann man sich vorstellen, daß PAREX anhand grober Heuristiken online Vorschläge für auftragsspezifische Parameter macht. Eine ausführliche Betrachtung der Wirkungen auf andere Aufträge und daraus resultierende Veränderung weiterer Parameter kann dann beim nächsten Batch-Lauf vorgenommen werden. 3.2.4 Weiteres Vorgehen Die lokalen Wirkungen einer Parameteränderung unter ceteris-paribus-Bedingungen sind bekannt. Um einen gewünschten Effekt zu erzielen, müssen jedoch häufig mehrere Parameter gleichzeitig verstellt werden, wobei unerwünschte Nebenwirkungen, die manchmal erst mit einer zeitlichen Verzögerung zu erwarten sind, so gering wie möglich gehalten werden sollten. Als nächstes muß daher untersucht

Expertensysteme bei der Produktionsplanung und -Steuerung

27

werden, ob mit einer Wissensbasis, die auf einfachen Heuristiken beruht, solche Interdependenzen zwischen Parametern beherrscht werden können oder ob in das Expertensystem auch die Ergebnisse von Simulationen mit dem Werkstattsimulator zur Aufdeckung weniger offensichtlicher Abhängigkeiten einfließen müssen. Daher soll zunächst auf einer Teilmenge der für die Einstellung im Rahmen von PAREX geeigneten Parameter ein erster Prototyp entwickelt werden. Die Wissensbasis muß dann nach und nach auf alle geeigneten Parameter ausgebaut und parallel dazu vertieft werden. Möglicherweise wird im Verlauf dieses Wachstumsprozesses von PAREX eine Überarbeitung der Einteilung geeigneter Parameter aus Abschnitt 3.2.2 nötig werden. 3.3 UMDEX 3.3.1 Aufgabenbereich von UMDEX Erfahrungen in der Praxis haben gezeigt, daß trotz aufwendiger Planungsvorgänge Umdispositionen notwendig sind. Beispielsweise kam Mason in einer Untersuchung zu dem Ergebnis, daß 16% der Vorgaben nicht eingehalten werden konnten, da die notwendigen Werkzeuge nicht verfügbar waren. Brown berichtet sogar, manche Betriebe hätten bis zu 80% ihrer geplanten Produktion umzudisponieren [16]. Störungen können dabei sowohl durch Änderungen an Kundenaufträgen, durch Probleme beim Einkauf oder durch Schwierigkeiten in der Fertigung verursacht werden. Wegen des großen Datenvolumens im letztgenannten Bereich konzentrieren sich die bisherigen Überlegungen auf diesen Sektor. In diesem Zusammenhang ist festzuhalten, daß nicht die Ursachen von Störungen, sondern nur die Folgen in den Datenbeständen von COPICS auftauchen. Fällt z.B. eine Kapazitätseinheit aus, so muß man die voraussichtliche Ausfallzeit eingeben, sie kann nicht über die Ursache und entsprechende Erfahrungsdaten vom System abgeschätzt werden. Obwohl für UMDEX auch Varianten sinnvoll wären, die beispielsweise Abweichungen nachts im Batch-Lauf "vorbeurteilen", orientieren sich die folgenden Ausführungen an dem Ziel, als ersten Schritt Abweichungen online bei ihrem Auftreten zu behandeln. 3.3.2 Basiskonzepte von UMDEX 3.3.2.1 Grundfunktionen Die Aufgabe von UMDEX verteilt sich auf vier Grundfunktionen. Im einzelnen sind dies die Abweichungserkennung, die Abweichungseinschätzung, die Maßnahmenermittlung und die Maßnahmenauswahl.

28

Expertensysteme bei der Produktionsplanung und -Steuerung

Die Abweichungserkennung hat die Planvorgaben im Soll-Ist-Vergleich laufend auf ihre Einhaltung zu überprüfen. Überschreitet eine erkannte Abweichung einen festzulegenden Schwellwert, so wird sie genauer analysiert. Läßt die Abweichungseinschätzung einen Handlungsbedarf erkennen, ermittelt UMDEX geeignete Gegenmaßnahmen einschließlich ihrer potentiellen Folgewirkungen. In einfacheren Situationen ist als letzter Schritt die automatische Auswahl der geeignetsten Alternative vorstellbar, in komplexeren Situationen trifft die letzte Entscheidung der Disponent auf der Basis entsprechender System Vorschläge. Die Funktionen der Abweichungserkennung und -einschätzung lassen sich unter dem Begriff "Diagnose" zusammenfassen. Obwohl Elemente der Diagnose auch bei der Maßnahmenermittlung und -auswahl zu finden sind, gehören letztere mehr dem Bereich der "Beratung" an. 3.3.2.2 Zusammenwirken der Grundfunktionen und stufenweise Diagnose Prinzipiell könnten die vier Grundfunktionen in der oben angeführten Reihenfolge ausgeführt werden. Schwierigkeiten tauchen spätestens bei der Abweichungseinschätzung auf, wenn die Frage gestellt wird, wie weit mögliche Folgen in die Beurteilung einbezogen werden sollen. Untersucht man beispielsweise beim Verzug eines Arbeitsganges bereits die potentiellen Auswirkungen auf evtl. vorhandene Kundenaufträge, oder begnügt man sich mit den Konsequenzen für den Werkstattauftrag? Entscheidet man sich für ausführlichere Diagnosen, so tritt das Problem der "kombinatorischen Explosion" auf: Die Struktur des PPS-Bereiches ist derartig komplex, daß es viel zu aufwendig, wenn nicht sogar unmöglich wäre, alle Wirkungen einer Abweichung zu untersuchen. Eng mit diesem Problem hängt die Funktion der Maßnahmenermittlung zusammen. Stehen Maßnahmen zur Abweichungsbeseitigung zur Verfügung, deren Einsatz wenig Aufwand erfordern und kaum Folgewirkungen nach sich ziehen würde, so genügt eine reduzierte Diagnose. Maßnahmen mit hohem Aufwand werden dagegen nur dann gerechtfertigt sein, wenn ausführliche Analysen der erkannten Abweichung ihre Einsatznotwendigkeit bestätigen. Die Ergebnisse der Abweichungseinschätzung und der Maßnahmenermittlung beeinflussen sich folglich gegenseitig. Somit ergeben sich zwei Ursachen für eine stufenweise Diagnose, die gegebenenfalls zur Revidierung bisheriger Schlußfolgerungen führt; - erste Ergebnisse der Diagnose selbst erfordern eine Vertiefung, oder eine - Entscheidung über die Eignung von Maßnahmen ist nur auf der Grundlage einer breiteren Informationsbasis möglich.

Expertensysteme bei der Produktionsplanung und -Steuerung

29

3.3.2.3 Bereichskonzept Zur Begrenzung des Umdispositionsaufwandes eines Systems wie UMDEX ist es angebracht, mit möglichst lokalen Informationen und Maßnahmen zu einer guten Entscheidung zu gelangen. Abweichungen bei einem Arbeitsgang wird man innerhalb des zugehörigen Werkstattauftrags auszugleichen versuchen; ein zu spät fertiggestellter Werkstattauftrag soll nach Möglichkeit keine Auswirkungen auf Kundenaufträge nach sich ziehen. Bei der Konzeption von UMDEX wurden daher Bereiche geschaffen, in denen geeignete Beurteilungskriterien und potentielle Gegenmaßnahmen zusammengefaßt werden. Die Einteilung lehnt sich an die Struktur des Fertigungsprozesses an. Über die Stücklistenauflösung werden aus den Endproduktbedarfen Werkstattaufträge geeigneter Losgrößen bestimmt. Den verschiedenen Bearbeitungsstufen eines Werkstattauftrags entsprechen seine Arbeitsgänge, die an verschiedenen Maschinen eingelastet werden. Die fertigen Teile gehen über Zwischenläger in einen oder mehrere nachfolgende Werkstattaufträge ein, bis die Endprodukte fertiggestellt sind. Daraus leiten sich die vier Bereiche Kapazität, Werkstattauftrag, Auftragsnetz und Endprodukt ab. Im Kapazitätsbereich (KA-B) werden Kapazitätsüber- und -unterauslastungen festgestellt, beurteilt und - soweit möglich - durch angemessene Gegenmaßnahmen beseitigt. Als Einheit für die Kapazität wurde die Arbeitsplatzgruppe gewählt, da COPICS nur für sie Auslastungsdaten bereitstellt Im Werkstattauftragsbereich (WA-B) wird jeder Arbeitsgang auf Verzug und Fehlmengen überprüft, so daß eine frühzeitige Abweichungserkennung schon vor dem Abschluß des Werkstattauftrags gesichert ist. Die entsprechenden Informationen stehen in der Werkstattauftragsdatenbank. Ausweichmöglichkeiten können teilweise aus den Arbeitsplanstammdaten entnommen werden. Der Auftragsnetzbereich (AN-B) dient der erweiterten Beurteilung von Abweichungen, die im WA-B festgestellt wurden. Im AN-B werden die Auswirkungen einer Abweichung auf das Auftragsnetz untersucht. Datengrundlage ist der kurzfristige Teil der Planungsdatenbank, die durch die Materialbedarfsplanung aufgebaut wird. Sie enthält u.a. Informationen über die Bedarfsverursacher der einzelnen Werkstattaufträge. Der Endproduktbereich (EP-B) erweitert die Untersuchung um Gesichtspunkte, die den von der Abweichung betroffenen Kunden oder die Folgen für die Lieferbereitschaft in die Beurteilung mit einbeziehen.

30

Expertensysteme bei der Produktionsplanung und -Steuerung

3.3.3 Abweichungserkennung Abweichungen und Unregelmäßigkeiten in der Fertigung lassen sich einerseits an veränderten Kapazitätssituationen, andererseits am unplanmäßigen Durchlauf der Werkstattaufträge feststellen. Die Funktion der Abweichungserkennung ist - im Gegensatz zur Funktion der Abweichungseinschätzung - nur auf den Kapazitäts- und Werkstattauftragsbereich beschränkt COPICS verwendet im Rahmen des Moduls SL&R bei der Arbeitsgangterminierung geplante Warteschlangenlängen vor den jeweiligen Maschinen. Es empfiehlt sich daher eine periodische Überwachung (z. B. abends im Batch-Betrieb) der aktuellen Warteschlangen, um frühzeitig potentielle Verzögerungen zu erkennen. Überplanmäßige Warteschlangen können dabei nicht nur durch offenkundige Störungen, sondern auch z.B. durch veränderte Abarbeitungsreihenfolgen an einzelnen Maschinen verursacht werden. Eine unmittelbare und fallweise Überprüfung der Arbeitsplatzgruppensituation liegt dagegen nahe, wenn z. B. Maschinenstörungen im Rahmen der Betriebsmitteldatenverwaltung eingegeben werden. Derartige Ausfälle äußern sich in einer Reduzierung der verfügbaren Kapazität; beim Aufruf der dazu notwendigen Transaktion ist die ursprüngliche Kapazitätssituation mit der neuen zu vergleichen und bei Abweichungen, die eine festzulegende Toleranzschwelle überschreiten, im S inne einer Aktionsorientierten Datenverarbeitung [17] die Abweichungsbeurteilung anzustoßen. Zur Überwachung der Situation im Werkstattauftragsbereich verwenden wir als Planvorgaben die Auftragsmenge, den geplanten Ausschuß sowie die rückwärtsterminierten, spätesten Endtermine der einzelnen Arbeitsgänge. Die Ist-Werte sind den übermittelten Rückmeldungen beendeter Arbeitsgänge zu entnehmen, an Toleranzschwellen für Verzug und Ausschuß zu messen und gegebenenfalls der Abweichungsbeurteilung zuzuführen. 3.3.4 Abweichungsbeurteilung 3.3.4.1 Grundsätzliche Überlegungen Aufgabe der Abweichungsbeurteilung ist es, die gemeldeten Soll-Ist-Abweichungen im Gesamtzusammenhang der Situation innerhalb der Fertigung zu relativieren. Die Ergebnisse der Analysen sollen es ermöglichen, geeignet dosierte Gegenmaßnahmen zum Abweichungsausgleich einzusetzen. Analytische Verfahren zur Berechnung von "Mark und Pfennig" sind aufgrund der vielfältigen Interdependenzen in der Fertigung und der zahlreichen, in vielen Fällen nur mit großen Unsicherheiten zu quantifizierenden Einflußgrößen nicht einzusetzen. Im Rahmen der Entwicklung von UMDEX wurde daher versucht, Indikatoren für die Abweichungsbeurteilung zu

Expertensysteme bei der Produktionsplanung und -Steuerung

31

finden, die bevorzugt aus den Datenbeständen von COPICS entnommen werden können oder über Auswertungen im Rahmen von DIPSEX aus den Daten des von COPICS gesteuerten Fertigungsablaufs stammen. Eine aufwendige zusätzliche Datenerfassung für UMDEX sollte damit vermieden werden. Für eine aussagekräftige Gesamtbeurteilung ist es notwendig, die zahlreichen Indikatoren geeignet zu verdichten. Obwohl die qualitativen Zusammenhänge relativ betriebsunabhängig konzipiert werden konnten, zeigt sich bei der quantitativen Bewertung der Zwang zur betriebsindividuellen Ausprägung. Beispielsweise werden - bei identischer Häufigkeitsverteilung des Arbeitsgangverzugs - drei Tage Verspätung in einer Fertigung als gravierend, in einer anderen als tolerierbar angesehen. Aus diesen Überlegungen heraus sind die Grenzen, bei welchen Werten (z.B. Verzug) welche Beurteilungsstufe (z.B. tolerierbar, schwerwiegend) eines bestimmten Indikators ("Bedeutung Verzug") vergeben wird, vom zuständigen Disponenten im Rahmen eines Vorabdialogs zu erfassen (Systeminitialisierung). Mit wenigen Ausnahmen sind dabei pro Indikator drei Beurteilungsstufen vorgesehen. Sofem im Einzelfall nichts anderes festgelegt ist, entspricht dabei: I

mäßig,

II

mittel,

III bedeutend. Untersuchungen in einer Vorarbeit haben gezeigt, daß eine ursprünglich vorgesehene Einteilung in fünf Klassen insbesondere bei der Verdichtung kaum mehr handhabbar war. In den folgenden beiden Kapiteln sollen beispielhaft die Beurteilung im Kapazitätsbereich sowie die Beurteilung von Verzug im Werkstattauftragsbereich beschrieben werden. 3.3.4.2 Abweichungsbeurteilung im Kapazitätsbereich In Anlehnung an die Ausführungen in Kapitel 3.3.3 (Abweichungserkennung) lassen sich die periodische und die fallweise Beurteilung unterscheiden, wobei im Rahmen dieses Beitrags nur letztere vorgestellt werden soll. Sie geht von einer für einen bestimmten Zeitpunkt gemeldeten Ausfalldauer aus. Dies kann einerseits durch eine sofort wirksam werdende Störung, andererseits auch durch eine in beispielsweise zwei Tagen anfallende Wartungsarbeit verursacht werden. Maßgebend für die Beurteilung ist als erstes die Engpaßkategorie der betroffenen Kapazitätsgruppe, die im Rahmen von DIPSEX ermittelt wurde (I kaum,

Expertensysteme bei der Produktionsplanung und -Steuerung

32

II teilweise, III häufiger Engpaß). Zusammen mit dem durch den Vorabdialog vorliegenden Parameter "Ausfallzeiten" wird die "Bedeutung Ausfall" ermittelt (vgl. Abbildung 5). Ausfallzeiten in Stunden >

12

> 8

Bedeutung Ausfall > 4

Beispiel: -

8-12

4-8

2-4

0-8

0-4

0-2

-

Ausfall an E n q paß Kategorie II Ausfalldauer 7h

Bedeutung Ausfall I

I

III Engpaßkategorie

Abb. 5: Beispielhafte Ermittlung Bedeutung Ausfall

Das weitere Vorgehen hängt ab von der vergebenen Beurteilungsstufe (im folgenden als "Wert" bezeichnet) des Indikators "Bedeutung Ausfall". Bedeutung Ausfall I: Aufgrund der relativ geringen Abweichung erscheint ein Eingreifen nicht notwendig. Auf eine weitergehende Analyse der Situation (Beurteilungsausweitung) wird verzichtet. Bedeutung Ausfall II: In diesem Fall ist eine tiefergehende Diagnose angebracht. Sie umfaßt - wie im folgenden noch ausführlich erläutert wird - die Ermittlung der von der Störung betroffenen Arbeitsgänge und ihres voraussichtlichen Verzugs sowie eine anschließende Beurteilungsausweitung in den Werkstattauftragsbereich. Bedeutung Ausfall III: Das Vorgehen gleichtdem vorherigen Fall. Zusätzlich ist hier aber zu erwägen, vor einer tiefergehenden Analyse die verfügbaren Gegenmaßnahmen zu betrachten. Vielleicht läßt sich die problematische Kapazitätssituation durch Verschieben eines Wartungsauftrags relativ einfach umgehen. Ist eine Beurteilungsausweitung notwendig, so müssen die betroffenen Arbeitsgänge und ihr voraussichtlicher Verzug ermittelt werden. Neben der Ausfalldauer spielt dabei insbesondere der Zeithorizont eine Rolle, in dem die Endtermine der Arbeitsgänge liegen müssen, damit sie noch innerhalb des kurzfristigen Bereichs von UMDEX betrachtet werden. Diese Zeitspanne ist als Parameter vom Benutzer in Abhängigkeit vom betriebsindividuellen Abstand der COPICS-Planungsläufe vorzugeben. Als dritter Einflußfaktor ist für die momentane Teilaufgabe auch die Abarbeitungsreihenfolge der vor der Kapazitätsgruppe wartenden Arbeitsgänge von Bedeutung (Prioritätsregel).

Expertensysteme bei der Produktionsplanung und -Steuerung

33

Die im vorigen Teilschritt ermittelten Informationen werden nun bei der "Analyse Auftragsspektrum" einzeln der Komponente "Beurteilung Verzug" im Werkstattauftragsbereich übergeben. Dort werden der Verzug des Arbeitsganges innerhalb des zugehörigen Werkstattauftrags individuell beurteilt (vgl. Kapitel 3.3.4.3) und die ermittelte Beurteilungsstufe in den Kapazitätsbereich zurückgegeben. Neben den einzelnen Werten ist dabei insbesondere von Bedeutung, bis zu welchem Bereich die Beurteilung durchgeführt wurde (WA-B, AN-B oder sogar EP-B). 3.3.4.3 Abweichungsbeurteilung im Werkstattauftragsbereich Die folgenden Ausführungen beschränken sich dabei auf den Fall des Verzugs. Abbildung 6 zeigt die Beurteilung im Überblick.

Abb. 6: Beurteilung Verzug im WA-B

Ausgangspunkt der Betrachtung ist der absolute Verzug, wie er aus der Abweichungserkennung gemeldet wurde. Zur Ermittlung der relativen Bedeutung sind von der disponierenden Person vorher Parameter (Grenzwerte für Auftragsverzug) einzustellen. Dabei kann sie die von DISPEX gelieferte Häufigkeitsverteilung des Verzugs bei Arbeitsgängen verwenden. Sie gibt dazu den Prozentsatz der Aufträge an, die einer Beurteilungsstufe zugeordnet werden sollen. Daraus lassen sich die Grenzwerte der einzelnen Klassen ermitteln. Abbildung 7 zeigt eine exemplarische Festlegung.

Expertensysteme bei der Produktionsplanung und -Steuerung

34

Es empfiehlt sich, die Aufträge, die über Puffer verfügen, aus der Betrachtung auszuklammern, da steuernde Eingriffe zum Abbau der Puffer einerseits u.U. einen erheblichen Aufwand erfordern würden, andererseits aber im kurzfristigen Bereich kaum Gewinne (reduzierte Kapitalbindungskosten) brächten. Höufigkeit

Bedeutung Verzug

Abb. 7: Exemplarische Festlegung Parameter Verzug

Die Bedeutung des Werkstattauftrags, dessen Arbeitsgang vom Verzug betroffen ist, läßt sich mit Hilfe entsprechender Grenzwerte, die ebenfalls über geeignete Häufigkeitsverteilungen gewonnen werden könnten, aus der neunstufigen COPICS-Auftragspriorität ermitteln. Wie die gestrichelte Linie vor "Ermittlung offener Arbeitsgänge" in Abbildung 6 andeutet, hängt die Ausführung dieser Funktion von den bisherigen Ergebnissen ab. (Die erforderlichen Beurteilungsstufen sind aus Abbildung 8 ersichtlich, in der zugleich die Gesamtbeurteilung quantitativ dargestellt wird.) Sie ist Voraussetzung für die Analyse, ob ein "Verzugsausgleich ohne Eingriff' möglich (I) oder kritisch (II) ist (zweistufiger Indikator). Aufgrund der nicht exakten Zeitplanungen in COPICS kann durchaus der Fall eintreten, daß sich ein Verzug im Laufe der weiteren Arbeitsgänge ausgleicht (kürzere Warteschlangen bzw. Transportzeiten als geplant). Dabei spielen drei Faktoren eine besondere Rolle: - Anzahl offene Arbeitsgänge: Je größer die Zahl ausstehender Übergänge zwischen einzelnen Maschinen ist, desto wahrscheinlicher kommt es zu einem Ausgleich. Die Mindestanzahl offener Arbeitsgänge ist vorzugeben.

35

Expertensysteme bei der Produktionsplanung und -Steuerung

- Verhältnis Restübergangszeit/Verzug: Ein selbständiger Ausgleich wird wahrscheinlich nur dann eintreten, wenn die restliche Übergangszeit den bisher erreichten Verzug um einen festzulegenden Faktor übertrifft. - Maschinensituation Restweg: Darüber hinaus erscheint es erforderlich, daß keiner der ausstehenden Arbeitsgänge an einer Maschine der Engpaßkategorie III bearbeitet werden muß, da an einem derartigen Aggregat durch überplanmäßige Warteschlangen leicht zusätzlicher Verzug entstehen kann. Der Indikator erhält den Wert I ("Ausgleich möglich"), wenn alle drei Faktoren positiv bewertet wurden. Wird somit ein Faktor negativ bewertet, ergibt sich der Wert II ("Ausgleich kritisch") und die Ermittlung weiterer Faktoren erübrigt sich. Bedeutung Verzug

1

II

III

Bedeutung Werkstattauftrog

Ermittlung offene Arbeitsgänge

Verzugsausgleich ohne Eingriff

Gesamtbeurteilung

1 oder II

Nein

1

III

Ja

1

1 II

1

Ja

1

1

II

II

II

Ja

1

1 II

III

Ja

II

1

Ja

1 II 1

II III

II

Jo

III

Nein

II 1 II

II III II III III

Abb. 8: Gesamtbeurteilung bei Verzug im WA-B

Entsprechend dem bereits im Kapazitätsbereich beschriebenen Verfahren kann auch im WA-B die Beurteilung ausgeweitet werden. Ermittelte man eine Gesamtbeurteilung mit dem Wert II oder III, so wird angenommen, daß der vorliegende Verzug bis zum Ende des Werkstattauftrages erhalten bleibt. Die Informationen werden an den AN-B weitergeleitet, der die voraussichtlichen Auswirkungen auf übergeordnete Aufträge einschätzt, gegebenenfalls auch den EP-B zur Analyse anstößt.

Expertensysteme bei der Produktionsplanung und -Steuerung

36

3.3.5 Verfügbare Maßnahmen Neben der Diagnose sind im Rahmen der Beratung Gegenmaßnahmen auf ihre Einsatzmöglichkeit zu untersuchen. Zur Zeit werden dafür noch geeignete Indikatoren ermittelt; die prinzipiell in Frage kommenden Maßnahmen zeigt Abbildung 9. Kapazitätsbereich

Werkstattauftragsbereich

-

Oberstunden Zusatzschichten Rücknahme von Splittungen ouf Arbeitsgangebene - Verlagerung ouf Ausweichmaschinen - Reaktivierung alter Anlagen

- Reduzierung der Übergongszeit - Splitten von Arbeitsgängen - Oberlappen von Arbeitsgängen - Verwendung von Ausweicharbeitsgängen - Verwendung von Ausweichorbeitsplänen

Auftragsnetzbereich

Endproduktbereich

- Splitten von Aufträgen - Verwendung von Sicherheitsbeständen - Einsteuerung eines Eilauftrages - Veränderung von Auftragsmenge und -termin

-

Zuordnung von Fertigungs- zu Kundenaufträgen ändern - Kundenauftrogsmenge und -termin nach Rücksprache mit Kunden ändern

Bereichsübergreifende Maßnahmen -

Kurzfristige Auswortsvergabe bzw. externe Beschaffung

Abb. 9: Maßnahmen im Rahmen von UMDEX

4 Exemplarische Darstellung des Zusammenwirkens der drei Teilsysteme Im folgenden sollen die zwischen den drei Teilsystemen fließenden Informationen exemplarisch dargestellt werden. VerbindungDIPSEX - PAREX: PAREX benötigt für seine Arbeit u. a. Informationen über die an den einzelnen Arbeitsplatzgruppen angewandten Prioritätsregeln. Diese dürften in der Praxis im Regelfall nicht explizit bekannt sein, andererseits beeinflussen sie nicht unwesentlich das Ablaufgeschehen in der Fertigung und können die Ursache verschiedener fertigungstechnischer Probleme sein. DIPSEX analysiert daher die Rückmeldungen aus der Fertigung und ermittelt die an den einzelnen Maschinengruppen verwendeten Prioritätsregeln, die PAREX zur Verfügung gestellt werden.

Expertensysteme bei der Produktionsplanung und -Steuerung

37

Verbindung DIPSEX - UMDEX: Hier ist insbesondere daran zu denken, daß DIPS EX die von UMDEX benötigten Häufigkeitsverteilungen beispielsweise über den Auftragsverzug ermittelt und zur Verfügung stellt (vgl. Kapitel 3.3.4.3). Neben den Engpaßkategorien der einzelnen Kapazitätsgruppen ist auch das bereits an PAREX gelieferte Wissen über die eingesetzten Prioritätsregeln für UMDEX von Bedeutung (vgl. Kapitel 3.3.4.2). Andererseits hat UMDEX eingeleitete Umdispositionsmaßnahmen und nicht behebbare Abweichungen an DIPSEX zu melden, damit diese bei der Schwachstellendiagnose geeignet berücksichtigt werden können. Eine direkte Verbindung zwischen PAREX und UMDEX erscheint zur Zeit nicht erforderlich. Die von UMDEX gelieferten Informationen werden von DIPSEX zur Diagnose von Schwachstellen eingesetzt, letztere erhält PAREX zur Einstellung der Parameter mitgeteilt.

5 Ausblick Wie aus den Ausführungen in den vorangegangenen Kapiteln deutlich wurde, hat jedes der drei Systeme seine eigene Wissensbasis. Die Kommunikation soll zunächst über File-Transfer erfolgen, eventuell empfehlen sich auch gemeinsam genutzte Datenbanken. Im weiteren Verlauf der Forschungen wird ferner zu untersuchen sein, ob zumindest teilweise gemeinsam verwendete Wissensbasen zusätzliche Vorteile versprechen (z.B. bei der Pflege des Expertenwissens); ungeklärt ist noch die Frage der Verteilung auf unterschiedliche Hardware. Daneben sind zahlreiche Kooperationsformen zwischen Systemen denkbar, die in Abbildung 10 systematisiert werden (insbesondere zum Ast "Verhandlung i.e.S." vgl. [18]).

unverbindliche Problemanzeige (Hilferuf)

direkt

allgemein (Blackboard)

TriggerKonzept

Bearbeitung unmittelbor (Transaktion)

Bearbeitung periodisch (Batch)

Verhandlung i.e.S.

FAC-Netzwerke

Abb. 10: Systematisierung möglicher Kooperationsformen

ScientificCommunityMetapher

KontraktNetzwerke

38

Expertensysteme bei der Produktionsplanung und -Steuerung

Im Rahmen eines weiteren Projektes, welches an Stelle "D" der in Abbildung 1 gezeigten Systematik einzuordnen ist (gemischter Ansatz; mehrere hierarchisch angeordnete XPS) sollen u.a. ausgewählte Kooperationsformen untersucht werden. Anschließende Vergleiche sind notwendig, um die Vor- und Nachteile der einzelnen Ansätze herauszuarbeiten und Aussagen, beispielsweise über die Eignung der Systeme für unterschiedliche Betriebstypen, treffen zu können. Zusammenfassend läßt sich zu den hier nur relativ knapp darstellbaren Möglichkeiten [19] feststellen: Nicht am Ende steht die Forschung auf diesem Gebiet, sondern am Anfang!

Anmerkungen [1] Vgl. z. B. Allgeyer et al. (1987), Wedel et al. (1987) oder zum Vergleich mit anderen Systemen: Allgeyer (1988). [2] Vgl. Schumann et al. (1986), Büttner et al. (1988), Mertens (1988a). [3] Vgl. Schumann (1987). [4] Vgl. Allgeyer (1987), S. 62 ff. [5] Vgl. Geis et al. (1988). [6] Vgl. Mertens et al. (1988) sowie Mertens (1988b). [7] Der linke Ast der Abbildung ("vollständiger XPS-Ansatz") könnte analog zum rechten aufgefächert werden, aus Platzgründen wurde darauf allerdings verzichtet. [8] In Abbildung 3 werden aus Gründen der Übersichtlichkeit einige Module nicht aufgeführt [9] Vgl. Pabst (1985), S. 13. [10] Vgl. Diebold (1985), S. 1. [11] Vgl. Allgeyer (1987), S. 2. [12] Vgl. Puppe (1986), S. 333. [13] Vgl. dazu die Ausführungen bei Ellinger et al. (1979), S. 96. [14] Vgl. Baitella (1987), S. 63. [15] Vgl. Pabst (1985). [16] Vgl. Mason (1986) und Brown (1988). [17] Vgl. dazu Mertens et al. (1986) sowie Hofmann (1988). [18] Vgl. Hildebrand et al. (1989). [19] Vgl. Mertens (1989).

Literatur Allgeyer, K.: Das Expertensystemtool HEXE und seine Anwendung zur Schwachstellendiagnose in der Produktion, Dissertation; Nürnberg 1987. Allgeyer, K.: Eine Gegenüberstellung der Expertensystem-Shells HEXE, ESE und TWAICE; Angewandte Informatik 30 (1988) 4, S. 173-176.

Expertensysteme bei der Produktionsplanung und -Steuerung

39

Allgeyer, K., Schumann, M.: Das Expertensystemtool HEXE für betriebliche DVUmgebungen; in: Krallmann, H. (Hrsg.): Expertensysteme im praktischen Einsatz; Berlin 1987, S. 199-222. Baitella, R.: Flexibles Produktionsmanagement: Grundlagen eines Expertensystems für die Produktionsdiagnose mit PPS-Daten; Zürich 1987. Brown, M.C.: The Dynamic Rescheduler: Conquering the Changing Production Environment, Vortragsmanuskript für "The Fourth IEEE Conference on Artificial Intelligence Applications"; San Diego 1988. Büttner, U., Dräger, U., Geiß, M., Krug, P., Mertens, P., Purnhagen, J., Rauh, N., Wittmann, S.: Expertensysteme zur Jahresabschlußanalyse für mittlere und kleine Unternehmen; Zeitschrift für Betriebswirtschaft 58 (1988) 2, S. 229-251. Diebold Deutschland GmbH (Hrsg.): New Look für PPS; Diebold Management Reporto. Jg. (1985) 10, S. 1-6. Ellinger, T., Wildemann, H.: Planung und Steuerung in der Produktion; Wiesbaden 1979. Geis, W., Ludwig, H„ Straßer, N.: Vergleich von regelbasierten Expertensystemen mit Entscheidungstabellen anhand ausgewählter Beispiele; Arbeitsberichte des Instituts für Mathematische Maschinen und Datenverarbeitung (Informatik) der FAU Erlangen-Nürnberg 21 (1988) 5. Hofmann, J.: Aktionsorientierte Datenverarbeitung unter besonderer Berücksichtigung des industriellen Fertigungsbereiches; Berlin u.a. 1988. Mason, F.: Computerized Cutting-Tool Management; American Machinists & Automated Manufacturing 130 (1986) 5, S. 105-132. Mertens, P.: XPS in Management Consulting; in: Bullinger, H.-J., Protonotarios, E.N., Bouwhuis, D., Reim, F.: EURINFO '88 - First European Conference on Information Technology for Organizational Systems; Amsterdam u.a. 1988a, S. 844. Mertens, P.: Wissensbasierte Systeme im Produktionsbereich: Bestandsaufnahme; in: Mertens, P., Wiendahl, H.-P., Wildemann, H. (Hrsg.): CIM-Komponenten zur Planung und Steuerung; München 1988b, S. 7-38. Mertens, P.: Verbindung von verteilter Produktionsplanung und -Steuerung und Verteilten Expertensystemen; Information Management (1989) 1, S. 6-11. Mertens, P., Hildebrand, R. und Kotschenreuther, W.: Verteiltes wissensbasiertes Problemlösen im Fertigungsbereich, ZFB 59 (1989) 8 (in Vorbereitung). Mertens, P., Hofmann, J.: Aktionsorientierte Datenverarbeitung; Informatik-Spektrum 9 (1986) 6, S. 323-333. Mertens, P., Borkowski, V., Geis, W.: Betriebliche Expertensystem-Anwendungen - Eine Materialsammlung; Berlin u.a. 1988. Pabst, H.-J.: Analyse der betriebswirtschaftlichen Effizienz einer computergestützten Fertigungssteuerung mit CAPOSS-E; Frankfurt/M. u.a. 1985. Puppe, F.: Expertensysteme; Informatik-Spektrum 9 (1986) 1, S. 1-13. Schumann, M.: Eingangspostbearbeitung in Bürokommunikationssystemen - Expertensystemansatz und Standardisierung; Berlin u. a. 1987.

40

Expertensysteme bei der Produktionsplanung und -Steuerung

Schumann, M., Wittmann, S., Mertens, P.: Expertensysteme zur Unterstützung des Wirtschaftsprüfers; Betriebswirtschaftliche Forschung und Praxis 6 (1986), S. 517-531. Wedel, T., Allgeyer, K„ Schumann, M.: Ein pragmatischer Ansatz zur Fehlererkennung in Wissensbasen durch das Expertensystemtool HEXE; Angewandte Informatik 29 (1987) 2, S. 75-83. Weitere Veröffentlichnungen über die Ergebnisse des DFG-Schwerpunktprogrammes Dräger, U., Elmer, L.: Wissensbasiertes Logistikcontrolling; Tagungsband Künstliche Intelligenz in der Praxis der Siemens AG, München 1988, S. 207-212. Mertens, P.: Expertensysteme - Einführung und Überlegungen zum Einsatz in der Logistik; in: Pfohl, H.-C. (Hrsg.): Logistiktrends; Dortmund 1987, S. 74-107. Mertens, P.: Approaches to Expert Systems in Management Consulting; in: Hui, L. X., Zhnang, W. P. (Hrsg.): Proceedings of International Symposium on Fuzzy Systems and Knowledge Engineering; Guangzhou (VR China) 1987, S. 208215. Mertens, P.: Approaches to Expert Systems in Management Consulting; in: CSDP und IBM (Hrsg.): Enterprise-wide Information Management, Fifth International Conference; St. Louis 1987, O.S. Mertens, P.: Expertensysteme in den betrieblichen Funktionalbereichen - Chancen, Erfolge, Mißerfolge; in: Brauer, W., Wahlster, W. (Hrsg.): Wissensbasierte Systeme; 2. Internationaler GI-Kongreß, Berlin-Heidelberg 1987, S. 181-206. Mertens, P.: Expertensysteme in der Unternehmensberatung; in: Berthel, J. (Hrsg.): Mittelständische Unternehmen; Berlin-Heidelberg-New York 1988, S. 68-116. Mertens, P.: Wissensbasierte Systeme in der Produktionsplanung und -Steuerung eine Bestandsaufnahme; Information Management (1988) 4, S. 14-22. Mertens, P., Allgeyer, K., Däs, H.: Developments and Applications of Expert Systems in Germany; in: Roos, J.L. (Hrsg.): L'Economique et l'Intelligence Artificielle; Aix-en-Provence 1986, S. 251-256. Mertens, P., Allgeyer, K., Schumann, M.: Ein Tool zur Entwicklung von Expertensystemen; Online (1986) 7, S. 29-31. Plattfaut, E„ Kraetzschmar, G., Mertens, P.: STRATEX - Ein prototypisches Expertensystem zur Unterstützung der strategischen Unternehmensplanung; Strategische Planung 3 (1987) 2, S. 71-103. Rose, H„ Stengel, H.: Kurzfristige Umdisposition in verschiedenen PPS-Ansätzen; CIM Management 4 (1988) 6, S. 76-84.

Interaktive Fertigungssteuerung teilautonomer Bereiche August-Wilhelm

Scheer,

Rudi Herterich,

Michael

Zell

Inhalt 1 Problemstellung 2 Grundidee der dezentralen Fertigungssteuerung 3 Gestaltung von Planungsalgorithmen 3.1 Zielkriterien 3.2 Randbedingungen des Fertigungssteuerungssystems 3.3 Strategien zur Fertigungssteuerung 4 Aufbau des Fertigungssteuerungssystems 4.1 Konzept eines Rechnerverbundsystems für die dezentrale Fertigungssteuerung 4.2 Gestaltung des Rumpfarbeitsplans 4.3 Detaillierte Arbeitspläne 4.4 Der dispositive Spielraum 4.5 Das Prinzip der rollierenden Planung 4.6 Das Prinzip der schichtgenauen Planung 4.7 Das Zeitkonto für freigegebene Aufträge 4.8 Das Kapazitätskonto eines Betriebsmittels 5 Integration von Simulations- und Animationstechnik 5.1 Durchführung von Analysen und Experimenten 5.2 Auswertung und Präsentation der Simulationsresultate 5.2.1 Animation 5.2.2 Bewertung der Simulationsgrößen 6 Schnittstellen zwischen Simulation und Fertigungsleitstand 7 Verstärkung der Interaktion Anmerkungen Literatur

1 Problemstellung Im Bereich der Produktion haben sich in den letzten Jahren durch technologische Veränderungen neue Anforderungen an die Produktionsplanung und -Steuerung ergeben. Während bei den bisherigen PPS-Systemen die Fertigungssteuerung in Form von Batch-Läufen durchgeführt wurde, erzwingen die Anforderungen des

42

Interaktive Fertigungssteuerung

Marktes nach Flexibilität, kleinen Losgrößen, Variantenvielfalt sowie geringen Durchlaufzeiten eine zeitlich nähere Disposition im Net-Change-Verfahren, um der Anfälligkeit durch unvorhergesehene Störungen in der Fertigung zu begegnen [1], Aus diesen Anforderungen ergeben sich organisatorische Konsequenzen; so ist im Bereich der Fertigung ein Trend zur Dezentralisierung erkennbar, d.h. zur Bildung kleinerer Fertigungsbereiche, in denen ein bestimmtes Teilespektrum nach dem Objektprinzip ganzheitlich gefertigt wird und die deshalb einen gewissen Grad an Autonomie bezüglich der Disposition der zu fertigenden Aufträge besitzen. Diese dezentralen, teilautonomen Fertigungsbereiche werden nicht, wie bei der verrichtungsorientierten Werkstattfertigung, zentral gesteuert, sondern der Fertigungssteuerungsteil wird aus dem klassischen Produktionsplanungs- und -steuerungssystem herausgebrochen und je nach Fertigungsform individuell gestaltet [2], Abbildung 1 zeigt diese Unterschiede auf. Bei dezentraler Fertigungssteuerung existieren somit eigene Regelkreise zur Fertigungssteuerung; die dezentralen Bereiche erhalten nur Rahmendaten in Form von Rumpfarbeitsplänen von der übergeordneten Produktionsplanung und -Steuerung (PPS) und melden auch nur verdichtete Daten zurück. Gegenwärtig werden diese Entwicklungen durch EDV-gestützte Leitstandskonzepte realisiert Zur Planung und Steuerung der dezentralen Fertigungsbereiche müssen zunächst deren spezifische Anforderungen an ein Fertigungssteuerungssystem definiert werden. Nicht jeder Fertigungsbereich ist organisatorisch gleich aufgebaut, denn Erzeugnisspektrum, Erzeugnisstruktur, Fertigungsart und Fertigungsstruktur wirken sich auf die Organisation der Fertigung aus. Im Rahmen dieser Arbeit soll ein Schwerpunkt auf den Aspekt der flexiblen Automatisierung gelegt werden, denn gerade für die Zielgruppe der Klein- und Mittelbetriebe erweisen sich flexible Fertigungssysteme und Fertigungszellen als bedeutend [4]. Je nach Flexibilität der eingesetzten Maschinen ergeben sich daraus unterschiedliche Anforderungen an das Fertigungssteuerungssystem. Der Einsatz fertigungsgerechter Steuerungsstrategien erfordert die Entwicklung eines dialogorientierten, interaktiven Steuerungssystems, das in der Lage ist, diesen vielseitigen Anforderungen gerecht zu werden. Das System soll im Hinblick auf die Benutzerfreundlichkeit so konzipiert sein, daß es auch von dem Mitarbeiter benutzt werden kann, der nicht täglich damit umgeht bzw. für den die Fertigungssteuerung nur einen Teil des Aufgabenfeldes darstellt. Ein Beispiel dafür ist der Meister in einem teilautonomen Fertigungsbereich, der die Reihenfolge von zu bearbeitenden Aufträgen und Arbeitsgängen festlegt. Da zur Steuerung eines Fertigungsbereichs unterschiedliche Strategien denkbar sind, soll zur Unterstützung des Benutzers bei Auswahl und Ausweitung von

Interaktive Fertigungssteuerung

43

Steuerungsstrategien die Simulationstechnik eingesetzt werden. Um die Ergebnisse unterschiedlicher simulierter Strategien in einer anwendergerechten Darstellungsweise abzubilden, bietet sich eine Animation als graphische Visualisierung der geplanten Prozesse an.

c

o

N

Q < H O

H°> UJ N

Interaktive Fertigungssteuerung

63

5.2.2 Bewertung der Simulationsgrößen Die Bewertung der erfaßten Simulationsgrößen ergibt sich aus den festgelegten Zielsetzungen. Probleme ergeben sich dort, wo mehrere konkurrierende Zielsetzungen existieren, die innerhalb einer Zielfunktion gewichtet und miteinander kombiniert werden müssen. Auch sind eventuell Randbedingungen zu definieren, die nicht verletzt werden dürfen (z.B. dürfen die Endtermine von Aufträgen nicht überschritten werden, auch wenn dies zur Verschlechterung der anderen Zielerreichungsgrade führen würde). Zur Ermittlung einer einheitlichen Zielfunktion empfiehlt sich die Bewertung der Fertigungsvorgänge mit den entsprechenden Kosten. Es lassen sich folgende ablaufabhängigen bzw. dispositiven Kosten unterscheiden [19]: - Zwischenlagerungskosten: Diese entstehen durch Kapitalbindung der zwischengelagerten Werkstücke. Hierbei entsteht das Problem der Bestimmung des Werkstückwerts. Bei kurzen Zwischenlagerungszeiten bleibt die Frage, ob es sinnvoll ist, eine Verzinsung der Werkstücke vorzunehmen. - Rüstkosten: Die Rüstkosten sind insofern ablaufabhängig, als daß durch eine an den notwendigen Rüstvorgängen orientierte Einplanung von Arbeitsgängen oder durch Raffung von Arbeitsgängen Rüstzeiten und damit Rüstkosten verringert oder vermieden werden können. - Leerkosten: Bei der Nichtbelegung von Maschinen fallen Leerkosten an, die durch Änderung der Fertigungsabläufe im Hinblick auf eine bessere Kapazitätsauslastung verringert werden können. Insbesondere bei kostenintensiven Engpaßmaschinen kann eine ablaufabhängige Leerzeit zu hohen Kosten führen. - Transportkosten: Die ablaufabhängigen Transportkosten beziehen sich auf die Zahl der durchzuführenden Transportvorgänge sowie die dabei zurückgelegten Wegstrecken. - Verzugskosten: Durch Überschreitung von Endterminen können für das Unternehmen Kosten, z.B. in Form von Konventionalstrafen, auftreten. Zusätzlich können aber auch nicht in Geldeinheiten zu messende "Kosten" entstehen, wenn z.B. bei dem Kunden aufgrund einer Terminüberschreitung ein Vertrauensschwund eintritt.

64

Interaktive Fertigungssteuerung

- Kosten durch Ausweichen auf Altemativarbeitspläne: Weicht der Fertigungsablauf aufgrund von Maschinenstörungen oder sonstigen Einflüssen von dem üblichen Verlauf ab, entstehen Mehrkosten, wenn davon ausgegangen wird, daß der Standardarbeitsplan die kostengünstigste Alternative darstellt. Mittels der obengenannten Kostenkomponenten läßt sich eine Zielfunktion beschreiben, die etwa aus der Minimierung der Summe der einzelnen Kostenkomponenten besteht

6 Schnittstellen zwischen Simulation und Fertigungsleitstand Im Rahmen einer simulationsunterstützten Fertigungssteuerung besteht zwischen dem Fertigungsleitstand einerseits und der Simulation andererseits die Notwendigkeit des Austauschs von Daten. Der Leitstand muß zur Durchführung einer Simulation insbesondere folgende Daten bereitstellen: - Einzuplanende Aufträge mit Zeiten und Mengen - Terminierungsstrategien - Fertigungsunterbrechungen. Die Simulationsläufe erzeugen wiederum Daten, die vom Leitstand ausgewertet werden können: - Maschinenbelegungen - Durchlaufzeiten - Länge von Warteschlangen, Wartezeiten. Aufgrund der Interdependenzen von Simulationssystem und Leitstand ergibt sich die Notwendigkeit zur Integration. Um ein Simulationssystem in ein Leitstandskonzept zu integrieren, müssen bestimmte Anforderungen erfüllt werden [20]: - Die im Simulationsmodell beschriebenen Abläufe müssen eine den Anforderungen des Leitstandes entsprechende Abbildungsgenauigkeit besitzen. - Der Leitstand muß die von der Simulation benötigten Daten in geeigneter Form bereitstellen, ebenso müssen die im Simulationslauf erzeugten Daten vom Leitstand übernommen werden können. - Es muß eine komfortable, möglichst graphische Oberfläche existieren, die es dem Benutzer ermöglicht, von der Leitstandsebene aus auf Parameter des S imulationsmodells zuzugreifen.

Interaktive Fertigungssteuerung

65

- Es muß eine Auswahl an möglichen Strategien bereitgestellt werden, die der Benutzer mittels der Simulation testen kann. - Aktuelle BDE-Daten, wie z.B. der Ausfall einer Maschine, müssen der Simulation sofort zur Verfügung stehen. - Auswertungen des Simulationssystems müssen in geeigneter Form vom Leitstand visualisiert werden, z.B. als graphische Maschinenbelegungspläne. - Vom Leitstand müssen alternative Bewertungsmöglichkeiten für die simulierten Fertigungsabläufe bereitgestellt werden. Eine Möglichkeit der Integration ist durch Einsatz der Window-Technik denkbar, indem sich der Anwender in einem aufklappbaren Fenster zusätzlich zu der statischen Auswertung des Leitstandes, z.B. in Form einer Maschinenbelegung, die geplanten Abläufe im Rahmen einer Animation auch dynamisch visualisieren lassen kann.

7 Verstärkung der Interaktion Kennzeichen vieler heutiger EDV-Systeme ist, daß der Benutzer im Hintergrund ablaufende Algorithmen nicht direkt beeinflussen kann, wenn er keine Programmierkenntnisse besitzt. Ähnliches gilt auch für die Systeme zur Fertigungssteuerung. Oft erlauben diese Systeme nur eine Vorwärts- und/oder Rückwärtsterminierung und nehmen dabei keine Rücksicht auf die speziellen Anforderungen eines Fertigungsbereichs sowie auf bestimmte aktuelle Situationen in der Fertigung. Dies hat zur Folge, daß der Benutzer mit unbefriedigenden Ergebnissen konfrontiert wird. Oft werden z.B. Eilaufträge nicht in das Fertigungssteuerungssystem eingeplant; dennoch werden diese Aufträge gefertigt, nehmen also Kapazität in Anspruch. Damit entspricht der Fertigungsplan des Steuerungssystems nicht mehr der realen Situation, die Disponenten treffen eigene, vom System abweichende Entscheidungen. Ungenügende Akzeptanz oder zeitraubende manuelle Optimierungsbemühungen sind die Folge. Um eine flexible, anwenderorientierte Fertigungssteuerung zu ermöglichen, wird dem Fertigungssteuerer neben einem breiten Spektrum an Algorithmen zur Unterstützung unterschiedlicher Steuerungsstrategien eine Vielzahl von Interaktionsmöglichkeiten zur Verfügung gestellt. Dadurch kann er jederzeit in den Steuerungsprozeß eingreifen, sein Erfahrungswissen mit einfließen lassen und sich individuell benötigte Informationen beschaffen.

66

Interaktive Fertigungssteuerung

Die Schwerpunkte der Interaktion sind folgende: - Bestimmen der relevanten Zielsetzungen: Der Benutzer kann wählen, welche Zielsetzung der Algorithmus verfolgen soll. Dies kann auf die Gesamtheit der Aufträge wie auch auf den einzelnen Auftrag bezogen sein. Der Benutzer entscheidet nicht nur, welche Zielsetzung er ansprechen will, sondern er kann auch festlegen, in welcher Reihenfolge und mit welcher Gewichtung er diese Ziele betrachtet. Ebenso kann er Grenzwerte festlegen, die nicht überschritten werden dürfen. - Auswahl der geeigneten Steuerungsstrategien: Ausgehend von den im vorhergehenden Schritt festgelegten Zielsetzungen kann der Anwender nun Strategien auswählen, die diese realisieren. Die einzelnen Algorithmen sollten durch Parameter abänderbar sein, damit unterschiedliche Gewichtungen realisiert werden können. - Simulation von Fertigungsabläufen unter veränderten Bedingungen: Die zur Fertigungssteuerung vorhandenen Strategien können am Modell des Fertigungsbereichs simuliert werden. Damit die Ergebnisse der Simulation in der weiteren Disposition berücksichtigt werden können, ist eine benutzerfreundliche Schnittstelle zwischen Simulation und Fertigungssteuerung notwendig, die es ermöglicht, problemlos Simulationsparameter zu ändern und erhaltene Simulationsdaten sofort für weitere Dispositionen zu verwerten. - Bewertung der Terminierungsergebnisse und Alternativenvergleich: Es sind Maßgrößen festzulegen, mit deren Hilfe eine Gesamtbewertung der durch die Strategie bewirkten Situation, z.B. einer konkreten Maschinenbelegung, erfolgen kann, damit sinnvolle Vergleiche der Alternativen und eine fundierte Entscheidung ermöglicht werden. - Manuelle Korrekturen unter Anwendung eigenen Erfahrungswissens: Bestimmte Steuerungsstrategien innerhalb der Fertigung sind nicht in einem Algorithmus erfaßbar, sondern sind sinnvollerweise der Erfahrung des Fertigungssteuerers zu überlassen. So muß dieser die Möglichkeit haben, nach einer automatischen Einlastung der Aufträge manuell am Fertigungssteuerungssystem Veränderungen vornehmen bzw. auch auf unvorhergesehene Ereignisse, wie z.B. Störungen, flexibel reagieren zu können. - Auslösen individuell gestaltbarer Ausweitungen und Analysen: Zur Dispositionsunterstützung sind graphische Auswertungen und Analysen, wie z.B. Maschinenbelegungspläne, Personaleinsatzpläne, Nutzungsgrade der Maschinen oder Störstatistiken, ein wertvolles Hilfsmittel. Der Anwender hat die Möglichkeit, sich solche Auswertungen nach individuellem Bedarf selbst zu gestalten.

Interaktive Fertigungssteuerung

67

Anmerkungen [1] Vgl. Scheer (1988a), S. 248. [2] Vgl. Scheer (1988b), S. 7. [3] Vgl. Scheer (1987), S. 3. [4] Vgl. Fix-Sterz et al. (1986), S. 370. [5] Vgl. Manske et al. (1984), S. 3 ff. [6] Vgl. Manske, Wobbe-Ohlenburg (1985), S. 489 ff. [7] Vgl. Dostal (1988), S. 5. [8] Vgl. Martin, Ulich, Warnecke (1988), S. 17. [9] Vgl. Cziudaj, Pfennig (1982), S. 9 ff. [10] Vgl. Förster, Hirt (1987), S. 69 ff. [11] Vgl. Rühle (1985), S. 30 ff. [12] Vgl. Hammer (1986), S. 247 ff. [13] Vgl. Scheer (1988c), S. 75 ff. [14] Vgl. Mertins (1985), S. 99. [15] Vgl. Wiendahl (1987), S. 297. [16] Vgl. Förster, Hirt (1987), S. 74. [17] Vgl. Schlüter (1987), S. 158. [18] Vgl. Smith, Platt (1987), S. 29. [19] Vgl. Knoop (1986), S. 47 ff. [20] Vgl. Schmidt (1987), S. 524 f.

Literatur Cziudaj, M., Pfennig, V.: Arbeitsorganisation an NC-Maschinen; FIR-Mitteilungen Nr .44, Aachen 1982. Dostal, W.: Personal für CIM; CIM-Management 4 (1988) 1, S. 4 -11. Fix-Sterz, J., Lay, G., Schultz-Wild, R.: Flexible Fertigungssysteme und Fertigungszellen. Stand und Entwicklungstendenzen in der BRD; VDI-Z 128 (1986) 11, S. 369 - 379. Förster, H.-U., Hirt, K.: Entwicklung von Anforderungsprofilen flexibel automatisierter Fertigungskonzepte an die Produktionsplanung und -Steuerung; Schlußbericht zum Forschungsvorhaben Nr. 134 der Stiftung zur Förderung der Forschung für die gewerbliche Wirtschaft, Aachen 1987. Hammer, H.: Hierarchie im Rechnerverbund, FB/IE 35 (1986) 5, S. 247 - 254. Knoop, J.: Online-Kostenrechnung für die CIM-Planung; Berlin 1986. Manske, F., Wobbe-Ohlenburg, W., Mickler, O.: Rechnergestützte Systeme der Fertigungssteuerung in der Kleinserienfertigung; Bericht KfK-PFT 90 Kernforschungszentrum Karlsruhe 1984. Manske, F., Wobbe-Ohlenburg, W.: Fertigungssteuerung im Maschinenbau aus der Sicht von Unternehmensleitung und Werkstattpersonal; VDI-Z 127 (1985) 12, S. 489 - 494.

68

Interaktive Fertigungssteuerung

Martin, T., Ulich, E., Warnecke, H.-J.: Angemessene Automation für flexible Fertigung; Werkstattstechnik (wt) 78 (1988) 1, S. 17 - 23. Mertins, K.: Steuerung rechnergeführter Fertigungssysteme; München, Wien 1985. Rühle, W.: Datenkommunikation; Industrie-Anzeiger 107 (1985) 79/80, S. 30 - 34. Scheer, A.-W.: Wirtschaftsinformatik - Informationssysteme im Industriebetrieb, 2. Auflage; Berlin et al. 1988a. Scheer, A.-W.: Neues Gewicht für Planungs- und Steuerungsfunktionen; Frankfurter Zeitung, Blick durch die Wirtschaft 31 (1988b) 122, S. 7. Scheer, A.-W.: Das Ziel ist klar, jedoch der Weg dahin ist unbekannt, Frankfurter Zeitung, Blick durch die Wirtschaft 30 (1987) 10, S. 3. Scheer, A.-W.: CIM - Der computergesteuerte Industriebetrieb, 3. Auflage; Berlin etal. 1988c. Schlüter, K.: Graphischer Modellaufbau und graphische Prozeßverfolgung als Hilfsmittel der Simulation in der Fertigungstechnik; in: Biethahn, J.; Schmidt, B. (Hrsg.), Simulation als betriebliche Entscheidungshilfe; Berlin et al. 1987, S. 157-171. Schmidt, R.: Einsatzmöglichkeiten der Simulation in der Werkstattsteuerung, in: Haiin, J. (Hrsg.): Simulationstechnik; 4. Symposium Simulationstechnik, Zürich 1987, S. 520 - 538. Smith, R.L. , Platt, L.: Benefits Of Animation In The Simulation Of A Machining And Assembly Line; Simulation 48 (1987) 1, S. 28 - 30. Wiendahl, H.-P.: Belastungsorientierte Fertigungssteuerung; München, Wien 1987.

Engpaßorientierte Auftragsterminierung und Kapazitätsdisposition Karl Kurbel, Jürgen Meynert

Inhalt 1 Produktionsplanung und -Steuerung im Wandel 2 Wesentliche Einflußfaktoren der Terminierung 3 Herkömmliche Planungsverfahren 3.1 Durchlaufterminierung 3.2 Kapazitätsabgleich 3.3 Maschinenbelegungs- und Reihenfolgeplanung 4 Konzepte der engpaßorientierten Termin- und Kapazitätsdisposition 4.1 Disposition von Engpaßkapazitäten 4.2 Graphische Unterstützung von Planungsfunktionen 4.3 Graphische Kapazitätsdisposition 4.4 Graphische Reihenfolge- und Betriebsmittelbelegungsplanung 5 Elektronische Leitstände als Patentrezept? Anmerkungen Literatur

1 Produktionsplanung und -Steuerung im Wandel Informations- und Steuerungssysteme für den Produktionsbereich sind so alt wie die betriebliche Datenverarbeitung. Mit den gewandelten Marktanforderungen, denen sich die Unternehmen heute zu stellen haben, und den Fortschritten der Informations- und Kommunikationstechnologie veränderten sich auch die Anforderungen der Anwender an die Produktionsplanungs- und Steuerungssysteme (PPS-Systeme) [1]. In dem Projekt "Interaktive betriebliche Planungs- und Steuerungssysteme mit Orientierung an Arbeitsplatzrechnern und Bürokommunikationstechnologien"

70

Engpaßorientierte Auftragsterminierung

wurden neue Konzepte für die Mensch-Maschine-Interaktion entwickelt und in einem typischen betrieblichen Anwendungsbereich, der Produktionsplanung und -Steuerung, prototypisch umgesetzt. Mit den neuen Interaktionskonzepten stehen grundsätzlich neue Wege der Planung und Steuerung offen [2], Dieser Beitrag greift das Konzept der engpaßorientierten Fertigungssteuerung heraus. Er bezieht sich also primär auf die kurzfristigen PPSBereiche. Die Umsetzung der vorgestellten Konzepte wurde erst durch die heute und zukünftig verfügbaren Leistungen von graphischen Workstations möglich.

2 Wesentliche Einflußfaktoren der Terminierung Eine wichtige Aufgabe der Produktionsplanung und -Steuerung besteht darin, den zeitlichen Ablauf aller mit der Produktion verbundenen Aktivitäten zu koordinieren [3]. Die Planung wird auf verschiedenen Ebenen - für unterschiedliche Planungshorizonte und mit unterschiedlichem Detaillierungsgrad - durchgeführt [4], In einer ersten, sehr groben Planungsphase wird in Abhängigkeit vom Fertigungstyp das Produktionsprogramm festgelegt. Beispielsweise erstellt man bei anonymer Massenfertigung einen Absatzplan, während man bei kundenauftragsbezogener Fertigung Aufträge akquiriert und einplant. Beide Typen erfordern bereits in dieser Phase eine grobe Zeitplanung, im letzteren Fall zum Beispiel, weil mit einer Auftragsbestätigung in der Regel auch ein verbindlicher Liefertermin festgeschrieben wird. Im nächsten Planungsschritt, der mittelfristigen Charakter hat, folgt die Bestimmung der Durchlaufzeiten und damit der groben Start- und Endtermine für die Fertigungsaufträge. Dies geschieht üblicherweise anhand von Vorgabe-, Transportund geschätzten Liegezeiten, ohne daß die Auslastung der Produktionsressourcen berücksichtigt wird. Auf der feinsten Planungsstufe werden die grob terminierten Aufträge arbeitsgangweise den Betriebsmitteln bzw. Arbeitsplätzen zugewiesen. Für die einzelnen Kapazitätseinheiten werden Bearbeitungsreihenfolgen festgelegt und damit auch die genauen Zeitpunkte, zu denen jeder Arbeitsgang gestartet und beendet werden soll. Der Planungshorizont für diese Phase ist kurz. Er liegt in der Größenordnung der Durchlaufzeit einiger weniger Arbeitsgänge (z.B. ein bis zwei Wochen). Diese Feinplanung gehört im allgemeinen zum Aufgabenbereich der Fertigungssteuerung. Maßgeblichen Einfluß auf die Terminfindung hat auf allen Planungsstufen - neben den technologisch bestimmten Bearbeitungs- bzw. Vorgabezeiten - die Auslastung der Produktionskapazitäten. Der Konkurrenz zahlreicher Aufträge um gleiche Res-

Engpaßorientierte Auftragsterminierung

71

sourcen wird bei der Durchlaufterminierung im allgemeinen dadurch Rechnung getragen, daß hinreichend Puffer in Form von Liegezeiten eingeplant werden. Der Anteil der Puffer an der gesamten Auftragsdurchlaufzeit hängt von vielen Faktoren der individuellen Fertigungsorganisation ab. Er ist meist sehr hoch: Untersuchungen belegen Werte von 90% und mehr [5]. Die Gründe für den hohen Anteil der Liegezeiten sind vor allem darin zu sehen, daß die Auftragsfolgen für einzelne Arbeitsplätze nur unzureichend geplant werden. Die Ungenauigkeit der Planung führt zu der (mitunter berechtigten) Befürchtung, daß mangels Auftragsbestand vor einem Arbeitsplatz Stillstandszeiten entstehen könnten. Um dieser scheinbar kostenträchtigen Ausnahmesituation vorzubeugen, werden "sicherheitshalber" mehr Aufträge in die Fertigung eingesteuert, als unbedingt nötig wäre. Die Konsequenzen dieser Vorgehensweise wurden intensiv am Institut für Fabrikanlagen (IFA) der Technischen Universität Hannover unter Federführung von H. Kettner und H.-P. Wiendahl untersucht [6]. Die Quintessenz der Untersuchungen ist, daß hohe Auftragsbestände in der Fertigung auch hohe Durchlaufzeiten implizieren [7]. Insbesondere die Streuung der Durchlaufzeiten um den (im allgemeinen hohen) Mittelwert sticht hervor. Die Ursache ist einerseits häufig in der mangelnden Koordination der Prozesse zu sehen, welche die Fertigung begleiten: wenn etwa Materialien, Werkzeuge oder andere Hilfsmittel nicht rechtzeitig verfügbar sind, stockt die Fertigung. Die große Streuung spiegelt andererseits aber auch die oft zu beobachtende Mentalität der Werker wider, aus dem großen Auftragsbestand die "Rosinen" herauszupicken, unangenehme Aufträge jedoch liegenzulassen. Zu dieser Mentalität tragen vielfach Akkordlohnsysteme und ungeeignete Bewertungskriterien für die Produktionsleistung bei. Simplifizierende Aggregationen zu Tonnen oder Quadratmetern pro Tag verhindern häufig einen produktiveren Fertigungsablauf, der bei Anlegen differenzierterer Maßstäbe möglich wäre. Eine starke Streuung der Durchlaufzeiten macht eine genaue Planung schwierig, und um einen hohen Servicegrad garantieren zu können, müssen lange Durchlaufzeiten und damit wieder hohe Werkstattbestände von vornherein eingeplant werden. So schließt sich ein Teufelskreis. Zur Lösung des Problems schlägt das IFA vor, Aufträge belastungsorientiert freizugeben. Das heißt, für einen ausgewählten Arbeitsplatz werden weitere Aufträge nur dann zur Bearbeitung freigegeben, wenn der bereits freigegebene Arbeitsvorrat vor dem Arbeitsplatz ein vorher festgelegtes Volumen nicht überschreitet Auf diese Weise läßt sich die Streuung der Durchlaufzeiten gezielt beeinflussen und verringern, so daß auch die Sicherheitsmargen und damit die geplanten Durchlauf-

72

Engpaßorientierte Auftragsterminierung

zeiten reduziert werden können. Dieses Verfahren ist so wirkungsvoll wie einfach, wie die allgemeine Anerkennung und auch Untersuchungen des IFA in der Praxis belegen [8]. Die Wirksamkeit der belastungsorientierten Freigabe ist jedoch nicht unabhängig von der Fertigungsorganisation [9]. Bei reiner Fließfertigung ist sie am höchsten, weil mit der Auftragsfreigabe für den ersten Arbeitsplatz auch die Bestände und Liegezeiten an den folgenden Arbeitsplätzen bereits determiniert sind. Bei Werkstattfertigung mit sehr heterogenen Wegen des Materialflusses und unterschiedlichen Bearbeitungszeiten müssen im anderen Extrem dagegen alle Arbeitsplätze einzeln belastet werden. In diesem Fall führt auch mangelnde Koordination zu ablaufbedingten

Liegezeiten.

Abbildung 1 zeigt dazu ein einfaches Beispiel. Zwei Aufträge A und B mit je drei Arbeitsgängen sollen in entgegengesetzter Reihenfolge über die Betriebsmittel 1,2 und 3 laufen. Der mit A/l bezeichnete Kasten steht für den Arbeitsgang des Auftrags A, der auf Betriebsmittel 1 bearbeitet werden soll etc. Auftrag A A/l

A/2

A/3

B/2

B/1

Auftrag B B/3

t Abb. 1: Arbeitsgangfolgen von zwei Fertigungsaufträgen

Berücksichtigt man bei der Freigabe nur die Auslastungssituation der jeweils ersten Betriebsmittel der beiden Aufträge (Betriebsmittel 1 und 3), so kann sich die in Abbildung 2 dargestellte Situation ergeben. Wenn die ersten Arbeitsgänge der beiden Aufträge gleichzeitig gestartet werden, ohne daß die Konsequenzen für das jeweils nächste Betriebsmittel (2) beachtet werden, ergibt sich eine Liegezeit für einen der Aufträge (hier B) vor diesem Betriebsmittel. Das Dilemma wird noch größer, wenn man nicht die ersten Arbeitsgänge gleichzeitig einsteuert, sondern wenn man von gleichen Endterminen (z.B. Lieferterminen) ausgeht. Während man in der Situation aus Abbildung 2 die Liegezeiten reduzieren kann, indem man den ersten Arbeitsgang des Auftrags B später freigibt, läßt sich die ablaufbedingte Liegezeit in Abbildung 3 nicht vermeiden.

73

Engpaßorientierte Auftragsterminierung B/1

A/l B/2

A/2 B/3

A/3

Liegezeit

Abb. 2: Bearbeitungsreihenfolgen bei gleichem Starttermin

1

A/l

B/1 A/2

B/2 B/3

A/3

-??????

>1

Abb. 3: Bearbeitungsreihenfolgen bei gleichem Endtermin

Trotz des geringen Umfangs bringt das Beispiel ein zentrales Problem der Fertigungssteuerung deutlich zum Vorschein: die Engpaßkapazitäten. In beiden Abbildungen ist das Betriebsmittel 2 der Grund für die auftretenden Probleme. Dies liegt in erster Linie daran, daß es die Kapazitätseinheit mit der höchsten Auslastung darstellt und somit den Flaschenhals für den Auftragsdurchlauf. In der Praxis stellt sich das Problem, daß Liegezeiten aufgrund der Konkurrenz verschiedener Aufträge um gleiche Ressourcen entstehen, nicht so deutlich wie in dem konstruierten Beispiel. Bei der Terminierung der Aufträge werden im allgemeinen hinreichend große Puffer eingeplant, innerhalb derer sich die Konflikte häufig lösen lassen. Andererseits ist die Komplexität jedoch erheblich höher als in dem Beispiel, da sehr viel mehr als nur zwei Aufträge ein Betriebsmittel in einem vorgegebenen Zeitraum belegen. Zudem sind die Auftragsnetze meist größer und weiter verzweigt. So bleibt trotz der Unzulänglichkeiten des Beispiels die Aussage bestehen, daß die Engpaßkapazitäten für eine effiziente Planung von herausragender Wichtigkeit sind. Diese Erkenntnis wird von praktischen Erfahrungen hinreichend bestätigt Wegen ihrer Bedeutung für die Terminierung hat die Funktion des Kapazitätsabgleichs bei den PPS-Systemen lange Tradition.

74

Engpaßorientierte Auftragsterminierung

3 Herkömmliche Planungsverfahren Im Rahmen der Kapazitäts- und Zeitwirtschaft werden üblicherweise die folgenden Schritte durchlaufen: 1. Durchlaufterminierung 2. Kapazitätsabgleich 3. Feinterminierung und Reihenfolgeplanung Die Häufigkeit, mit der diese Funktionen in PPS-Systemen unterstützt werden, nimmt in der angegebenen Reihenfolge ab, nicht zuletzt deshalb, weil die Komplexität der Funktionen mit jeder Stufe erheblich steigt [10]. 3.1 Durchlaufterminierung Die Durchlaufterminierung stellt einen Kern der Produktionsplanung dar, weil sie die Ecktermine für alle weiteren Planungsaktivitäten setzt. Üblicherweise wird ein Auftrag oder ein Auftragsnetz ausgehend von einem Fertigstellungs- bzw. Liefertermin rückwärts schreitend mit Terminen versehen. Dabei werden Start- und Endtermine für einzelne Arbeitsgänge oder für Arbeitsgangfolgen sukzessiv errechnet, indem der Starttermin eines Arbeitsgangs aus dem vorgegebenen Endtermin und den voraussichtlichen Vorgabe- und Liegezeiten bestimmt wird. Dieser Starttermin dient dann wiederum als Endtermin für den zeitlich vorhergehenden Arbeitsgang etc., bis diejenigen Arbeitsgänge erreicht sind, die keine Vorgänger mehr haben. In analoger Weise kann auch vorwärts terminiert werden; bei Auftragsnetzen ist in diesem Fall zu beachten, daß anschließend wieder eine Rückwärtsterminierung folgt, damit Aktivitäten, die nicht auf dem kritischen Pfad liegen, nicht zu früh eingeplant werden und unnötig Kapital binden. Die geringe Genauigkeit in dieser Planungsphase rührt zum einen daher, daß die Liegezeiten, die den größten Teil der gesamten Durchlaufzeit ausmachen, nicht exakt bestimmbar sind, sondern oft nur grob geschätzt werden. Zum anderen macht es bei der Durchlaufterminierung keinen Sinn, genauer zu planen, weil sich aufgrund des großen zeitlichen Vorlaufs bis zur Realisierung des Plans noch viele Randbedingungen ändern können. Dies gilt um so mehr, je stärker die Produktion auf einzelne Kundenaufträge ausgerichtet ist. Bei der Durchlaufterminierung werden keine Kapazitätsschranken berücksichtigt. Dies ist auch bei den Net change-Verfahren nicht möglich, weil der zuletzt eingeplante Auftrag nicht notwendigerweise die niedrigste Priorität besitzt. Wenn ein Auftrag auf eine überlastete Kapazitätseinheit eingeplant wird, kann das also durchaus zur Folge haben, daß andere, weniger wichtige, aber bereits eingeplante Aufträge

Engpaßorientierte Auftragsterminierung

75

wieder umgeplant werden müssen. Diese Aufgabe läßt sich nicht im Rahmen der Durchlaufterminierung lösen, da sie die Komplexität unvertretbar aufblähen würde. 3.2 Kapazitätsabgleich Ein Kapazitätsabgleich kann durchgeführt werden, wenn der Auftragsbestand vollständig mit groben Terminen versehen ist. Er ist dann erforderlich, wenn der Kapazitätsbedarf, der durch die eingeplanten Aufträge verursacht wird, den Kapazitätsbestand, der durch die vorhandenen Betriebsmittel und Arbeitsplätze abgedeckt wird, überschreitet. Grundsätzlich gibt es zwei verschiedene Möglichkeiten, einen Kapazitätsabgleich durchzuführen: Entweder man paßt Kapazitätsbestand und Kapazitätsbedarf einander an, indem zum Beispiel durch Überstunden oder Sonderschichten der Kapazitätsbestand erhöht oder durch Fremdvergabe von Aufträgen der Kapazitätsbedarf erniedrigt wird. Oder man versucht, den Kapazitätsbedarf so zu glätten, daß temporäre Überlastungen in Zeiten ohne Vollauslastung verschoben werden. Die erstgenannte Technik des Abgleichs ist dann angebracht, wenn die Auftragslage generell zu Überlastungen führt, die durch zeitliche Verschiebung von Einzelaufträgen nicht abgefangen werden kann. Sie stellt weniger eine algorithmische als eine organisatorische Aufgabe dar. Erheblichen algorithmischen Aufwand erfordert dagegen das Glätten des Kapazitätsbedarfs. Diese Vorgehensweise kann eingesetzt werden, wenn die Durchlaufterminierung zufällige Überlastungen erzeugt hat und wenn Zeiten temporärer Überlastung Zeiten mit Minderauslastung gegenüberstehen. Vor allem an Arbeitsplätzen, deren Kapazität im Vergleich zur Nachfrage knapp bemessen ist, muß das Ergebnis der Durchlaufterminierung, die ja keine Kapazitätsrestriktionen berücksichtigt, oft nachgebessert werden. Das algorithmische Problem beim Kapazitätsabgleich beruht unter anderem darauf, daß ein Arbeitsgang, der zeitlich verschoben werden soll, oft Teil eines großen Auftragsnetzes ist, welches dann unter Umständen komplett umgeplant werden muß. Der Liefertermin ist jedoch meist eine harte Größe, die sich, vor allem bei kundenauftragsbezogener Fertigung, nicht ohne weiteres verändern läßt Die Konsequenzen, die eine Verschiebung nach sich zieht, können mitunter weit reichen - in dem Sinne etwa, daß Lossplittung oder überlappende Fertigung erforderlich wird. Deshalb muß vorab eine Vielzahl von Informationen bereitgestellt und ausgewertet werden. Das Problem des Kapazitätsabgleichs wurde in der Vergangenheit auf zwei grundverschiedenen Wegen angegangen. Die eine Vorgehensweise war, den Kapazitätsabgleich mit Hilfe aufwendiger Algorithmen automatisch von einem Programm durchführen zu lassen [11]. Sie erwies sich jedoch als zu (rechen-) zeitaufwendig

76

Engpaßorientierte Auftragsterminierung

und zu starr. Insbesondere waren die Ergebnisse einer automatischen Umplanung oft nicht nachvollziehbar oder sogar unsinnig, was ihre Akzeptanz nicht gerade förderte [12].

Im anderen, praktisch erfolgreicheren Fall ging man der Komplexität aus dem Weg. Die PPS-Programme begnügten sich damit, Überlastungen aufzuzeigen. Der (inkonsistente) Plan wurde an die Fertigungssteuerung weitergeleitet, die das Auftragsvolumen dann irgendwie zu bewältigen hatte. 3.3 Maschinenbelegungs- und Reihenfolgeplanung Beim letztgenannten Weg wird die Konfliktlösung auf die Fertigungssteuerung abgewälzt. Dort greifen jedoch die meisten PPS-Systeme als Planungsinstrumente nicht mehr. Sie dienen nur noch dazu, Begleitpapiere und Materialscheine auszudrucken und die Ist-Daten aus der Fertigung zu erfassen. Für die kurzfristige Planung der Fertigungsaktivitäten, deren Ablauf durch Störungen und permanente Änderungen der Randbedingungen gekennzeichnet ist, sind sie zu schwerfällig. Die Vielzahl von Daten, die beim Detaillierungsgrad dieser Planungsstufe anfallen, kann nicht mehr zeitnah und mit vertretbarem Aufwand erfaßt werden. Dies liegt nicht zuletzt an den unkomfortablen Benutzerschnittstellen (Listen und alphanumerische Terminals), die PPS-Systeme in der Vergangenheit für die Fertigungssteuerung anboten. Die Folge des ungenügenden Informationsstandes ist oft, daß Aufträge nicht in einer sachgerechten Reihenfolge bearbeitet werden. Auch zu einfache Bewertungskriterien, besonders bei Akkordlohnsystemen, können unter Umständen sinnvolle Auftragsfolgen verhindern. Wenn schließlich - oft zu spät - die Verzögerung wichtiger Aufträge erkennbar wird, peitscht man diese mit zusätzlichem Aufwand durch die Fertigung. Im Extremfall kann dies dazu führen, daß laufende Arbeitsgänge anderer Aufträge abgerüstet werden, um eine eventuelle Lieferterminüberschreitung in Grenzen zu halten. Die skizzierten Auswüchse der Fertigungssteuerung sind in zweierlei Hinsicht nachteilig. Sie stehen einerseits der Minimierung der Produktionskosten entgegen, weil Ausnahmesituationen aufgrund von Verspätungen u.a. eine zielgerichtete Gestaltung des Produktionsprozesses verhindern. Unternehmensextern schädigen Terminüberschreitungen den Ruf und die Wettbewerbsfähigkeit; sie können sich auch unmittelbar monetär in Form von Konventionalstrafen niederschlagen. Da in den letzten Jahren kurze und zuverlässige Lieferfristen wachsenden Einfluß auf die Wettbewerbsfähigkeit gewannen, wird die Forderung nach einer effizienten Unterstützung der Fertigungssteuerung immer lauter.

Engpaßorientierte Auftragsterminierung

77

4 Konzepte der engpaßorientierten Termin- und Kapazitätsdisposition Viele Ursachen für die Probleme der Fertigungssteuerung werden schon früh geschaffen. Bereits bei der Akquisition von Kundenaufträgen können durch unrealistische Lieferterminzusagen Überlastungen der Fertigung vorprogrammiert werden. Deshalb bedarf es effektiver Werkzeuge, die rechtzeitig mögliche Probleme aufzeigen und die helfen, Probleme zu vermeiden oder sie zu beseitigen. Wie bereits zu Anfang erläutert, hängt die Realisierbarkeit von Lieferterminen weniger von den technologisch bestimmten Vorgabezeiten als vielmehr von der Auslastung der Fertigung und den davon beeinflußten Liegezeiten ab. Den Durchsatz in der Produktion bestimmt weniger die Gesamtheit aller Aggregate und Arbeitsplätze als vielmehr eine kleine Zahl von Kapazitätseinheiten, die den Flaschenhals für den Materialfluß darstellen. Um die Einhaltung eines Liefertermins zu gewährleisten oder die Machbarkeit des Produktionsplans sicherzustellen, braucht man deshalb im allgemeinen nicht den gesamten Auftragsbestand hinsichtlich der Belastung aller Kapazitätseinheiten zu untersuchen. Dies verbietet sich schon angesichts des Datenvolumens. Effizienter und meist auch ausreichend ist es dagegen, gezielt die Engpässe sorgfältig zu verplanen. Die Engpässe sind im allgemeinen leicht zu erkennen. Es sind häufig Betriebsmittel, in die hohe Summen investiert wurden und die deshalb stets gut ausgelastet sein sollen. Die Engpaßkapazitäten fallen durch lange Liegezeiten und durch Sonderschichten oder durch Überstunden auf, mit denen die Liegezeiten abgebaut werden sollen. Falls die Engpaßkapazitäten von Zeit zu Zeit variieren, weil sie etwa vom jeweils aktuellen Produktmix abhängen, so können sie unter Umständen auch anhand von Belastungsdiagrammen, wie sie konventionelle PPS-Systeme erstellen, identifiziert werden. 4.1 Disposition von Engpaßkapazitäten Da automatische Verfahren zum Kapazitätsabgleich, die auf der Glättung des Kapazitätsbedarfs beruhen, wenig effizient sind und ebenso wenig akzeptiert werden, liegt es nahe, bei der Auftragsplanung von vornherein die Engpässe mit einzubeziehen, anstatt zu einem späteren Zeitpunkt zu versuchen, die Inkonsistenzen auszubügeln. Wegen der vielfältigen Abhängigkeiten in Auftragsnetzen wäre es insbesondere sinnvoll, mit der Planung bei den Engpaßkapazitäten zu beginnen (zentrale Terminierung oder Mittelpunktsterminierung), anstatt vorher durch die Verplanung von weniger kritischen Arbeitsplätzen die Freiheitsgrade da einzuschränken, wo sie dringend benötigt werden.

78

Engpaßorientierte Auftragsterminierung

Ein gewisses Problem bei dieser Vorgehensweise besteht darin, daß die Engpaßkapazitäten im allgemeinen Fall nicht von den ersten oder letzten, sondern von beliebigen anderen Arbeitsgängen eines Auftrags oder eines Auftragsnetzes belegt werden. Folglich ist es nicht trivial, bei der Terminierung mitten im Auftragsnetz zu beginnen. Man kann nicht ohne weiteres absehen, ob mit den gewählten Startwerten die ersten Arbeitsgänge in die Vergangenheit oder die letzten unvertretbar weit in die Zukunft fallen. Zudem verfügen viele PPS-Systeme nicht über die Möglichkeit, mit der Terminierung mitten im Auftragsnetz zu starten; sie sind vielmehr nur in der Lage, ein Auftragsnetz insgesamt vorwärts oder rückwärts zu terminieren. Wenn man also keine hinreichend genaue Vorstellung hat, in welchem Zeitraum ein Auftrag bei vorgegebenem Start- oder Endtermin eine Engpaßkapazität berührt, muß man sich zunächst mit den klassischen Terminierungsverfahren (vorwärts oder rückwärts) diese Informationen beschaffen. Anschließend ist die Belastung der betroffenen Engpaßkapazität dahingehend auszuwerten, ob der so terminierte Auftrag zu einer Überlastung beiträgt und ob er, falls dies zutrifft, mit weniger wichtigen Aktivitäten (z.B. mit Lageraufträgen) um die knappen Ressourcen konkurriert. Im Falle einer Überlastung müssen auf jeden Fall weitere planerische Maßnahmen getroffen werden, wenn später der Fertigungssteuerung ein termingerecht durchführbares Programm übergeben werden soll. Will man beispielsweise für einen neuen Kundenauftrag einen realistischen Liefertermin bestimmen, so wird man zunächst von einem "Wunschtermin" aus das gesamte Auftragsnetz rückwärts terminieren. Falls dabei ein Arbeitsgang auf eine Engpaßkapazität so eingeplant wird, daß er zu einer Überlastung führt, muß er zeitlich in Abschnitte mit hinreichender Kapazität verschoben und mit neuen Eckterminen versehen werden. Von den Eckterminen ausgehend wird dann der Zweig des Auftragsnetzes, in dem sich der betrachtete Arbeitsgang befindet, zur Bestimmung eines Endtermins vorwärts terminiert. Anschließend wird von dem so ermittelten Endtermin aus das gesamte Netz rückwärts terminiert, damit alle übrigen Termine auf den neuen Endtermin abgestimmt werden. Sollen dagegen die vorab ermittelten Termine des neuen Auftrags beibehalten werden, weil etwa der neue Auftrag eine besonders hohe Priorität besitzt, muß entweder der Kapazitätsbestand angepaßt oder ein anderer Auftrag in der oben beschriebenen Weise umterminiert werden. 4.2 Graphische Unterstützung von Planungsfunktionen Die wesentlichen Probleme bei der Disposition von Engpaßkapazitäten bestehen darin, daß einerseits umfangreiche Informationen vom PPS-System bereitgestellt oder ermittelt und aufbereitet werden müssen. Umgekehrt muß der Planer dem

Engpaßorientierte Auftragsterminierung

79

System viele Planungsparameter mitteilen. Die Schnittstelle zwischen dem Menschen und dem Rechner ist durch einen hohen Kommunikationsaufwand geprägt. Dieser Aufwand mag eine Erklärung dafür sein, daß die Kapazitätsabgleichsfunktionen von PPS-Systemen, die mit dem Benutzer über Listen und alphanumerische Terminals kommunizieren, wenig Akzeptanz erzielen. Graphische Darstellungsformen bieten sich an, damit die für den Umplanungsprozeß erforderlichen Datenmengen vom Planer leichter erfaßt und interpretiert werden können. Auf alphanumerischen Terminals wurden graphische Darstellungen früher ansatzweise realisiert, indem Belastungssituationen in Form von Balkendiagrammen angezeigt wurden. Die Darstellungsmöglichkeiten waren jedoch unzureichend. Erst die Entwicklung und Verbreitung von Arbeitsplatzrechnern, die über große graphische Bildschirme, Pointing devices (vor allem Maus) und Fenstertechniken verfügen, schafften die notwendige Voraussetzung für effizientere Formen der Informationsaufbereitung und Kommunikation. Im Rahmen des Projekts, in dem dieser Beitrag entstand, wurden Hilfsmittel entwickelt, die den Planer gerade bei den kommunikationsintensiven Aufgaben unterstützen sollen [13]. Die Hilfsmittel umfassen alle Funktionen von der Kundenauftragserfassung bis zur Rückmeldung aus der Fertigung, so daß eine engpaßorientierte Planung grundsätzlich auf allen Stufen möglich ist. Zwei Funktionen, die auf der Basis einer graphischen Workstation entwickelt wurden, sind die graphische Kapazitätsdisposition und die graphische Plantafel. Die beiden Funktionen decken unterschiedliche Planungsstufen ab: Die graphische Kapazitätsdisposition dient zum Aufzeigen und zum Glätten des Kapazitätsbedarfs; sie kommt in erster Linie bei den Engpaßkapazitäten zum Einsatz. Aufgrund des relativ großen zeitlichen Vorlaufs, mit dem sie gewöhnlich durchgeführt wird, hat sie eher mittelfristigen Charakter. Die graphische Plantafel dagegen gehört in den Bereich der Fertigungssteuerung; sie dient der kurzfristigen Umsetzung der Planvorgaben, die unter anderem von der Kapazitätsdisposition gesetzt werden. 4.3 Graphische Kapazitätsdisposition Der erste Schritt auf dem Weg zu den eigentlichen Dispositionsfunktionen ist die Auswahl von Betriebsmitteln oder Betriebsmittelgruppen, die Kandidaten für Engpässe sind und für die die Kapazitätsplanung durchgeführt werden soll. Da die Kapazitätsdisposition zu den gröberen Planungsstufen zählt, disponiert man hier eher auf Betriebsmittelgruppenebene, sofern mehrere gleichartige Betriebsmittel zur Erledigung einer Aufgabe bereitstehen. Der Kapazitätsbedarf und der Kapazitätsbestand für eine jeweils ausgewählte Kapazitätseinheit (Arbeitsplatz, Betriebsmittel, Betriebsmittelgruppe o.ä.) werden in

80

Engpaßorientierte Auftragsterminierung

einem Belastungsdiagramm gegenübergestellt. Mit Hilfe von Graphik und Farben lassen sich umfassende Informationen mit starker Detaillierung darstellen. Abbildung 4 zeigt als Beispiel die Auslastung einer Betriebsmittelgruppe; den verschiedenen Mustern entsprechen auf dem Bildschirm verschiedene Farben. Für jedes ausgewertete Zeitintervall (hier jeweils ein Tag) wird der Kapazitätsbestand aus dem Fabrikkalender und dem Schichtenmodell errechnet und als feine (rote) Linie in Stunden pro Zeitintervall aufgetragen. Dem Kapazitätsbestand wächst von der Zeitachse aus für jedes Zeitintervall der Kapazitätsbedarf in Form einer Säule aus farbigen Kästchen entgegen. Jedes Kästchen stellt den Kapazitätsbedarf eines einzelnen Arbeitsgangs dar. Erstrecken sich die Ecktermine eines Arbeitsgangs über mehr als ein Zeitintervall, so wird der Kapazitätsbedarf anteilsmäßig über das Intervall verteilt.

New Lügin

Zeit

Modus

Leitstand LI : Kapazitaetidiipoxition Ende BM-Auswahl Daten Unplanung Hilfe

Kapazitaet [Std] ,„

Farben A Huster

dD

terainierter AG aktueller AG feingeplanter AG freigegebener AG begonnener AG K 9 teilw. rueckgen. AGI ES9 gestoerter AG

09/88

18/88 Tag AG-NRl START I 10 7. 9.1988 15:

ENDE : 30. 9.1988 15:

BH-NR NU

Abb. 4: Graphische Kapazitätsdisposition

Bewegt man die Maus über dieses "Kapazitätsgebirge", so werden die Ecktermine des Arbeitsgangs, auf dem der Mauszeiger gerade steht, in der S tatuszeile am unteren Rand der Graphik angezeigt. Statusinformationen lassen sich unmittelbar aus den Farben der Kästchen ablesen; diese geben an, ob der zugehörige Arbeitsgang beispielsweise schon begonnen, freigegeben oder feingeplant wurde oder ob er zu

Engpaßorientierte Auftragsterminierung

81

einem Angebot gehört, für das noch ein Liefertermin bestimmt werden soll. Innerhalb einer Säule sind die Arbeitsgänge nach Status und Priorität geordnet. Diese Anordnung erleichtert die Auswahl von Arbeitsgängen, wenn durch Verschieben ein Kapazitätsabgleich durchgeführt werden soll. Weitere Informationen über einen Arbeitsgang lassen sich abrufen, indem das zugehörige Kästchen mit Hilfe der Maus markiert und die entsprechende Funktion aus einem Pull down-Menü aktiviert wird. Bei der Markierung werden alle weiteren Kästchen, die zu dem Arbeitsgang gehören, mit einem besonderen Muster versehen. Damit läßt sich, wenn die Zeitachse hinreichend fein skaliert ist, der Zeitraum, in dem der Arbeitsgang die Fertigung durchlaufen soll, grob ablesen. Wahlweise können auch die Zeitpuffer mit angezeigt oder unterdrückt werden. Die wichtigste Funktion der Kapazitätsgraphik ist die Möglichkeit der Umplanung. Ein markierter Arbeitsgang kann mit der Maus grundsätzlich an jeden beliebigen Punkt des Gebirges bewegt werden. Ausgenommen sind Arbeitsgänge, die schon feingeplant, freigegeben oder gestartet sind. Wenn man das Pull down-Menü "Umplanung" aktiviert, kann man die Daten dieser rein graphischen Manipulation wahlweise an zwei unterschiedliche Terminierungsfunktionen übergeben: Die erste Funktion versucht, den Zweig des Netzes, in dem sich der markierte Auftrag befindet, durch Veränderung der Pufferzeiten so umzuplanen, daß die Ecktermine des gesamten Auftragsnetzes (Starttermine und Liefertermin) beibehalten werden können. Gelingt dies nicht, weil etwa die graphische Verschiebung größer war als die Summe der verfügbaren Puffer, so wird die Umplanung abgelehnt. Wesentliches Merkmal dieser Funktion ist, daß sie Liefertermine respektiert, da sich diese, wenn sie einmal festgelegt sind, nur schwer verändern lassen. Der Rechenaufwand ist relativ gering, weil die Funktion nur einen Zweig eines Auftragsnetzes partiell neu terminiert. Allerdings läßt sie sich nur dann wirkungsvoll einsetzen, wenn der planerische Spielraum, der durch die verfügbaren Pufferzeiten determiniert wird, hinreichend groß ist. Dies ist um so weniger gewährleistet, je näher die umzuterminierenden Arbeitsgänge am Liefertermin liegen, weil damit die Summe der restlichen Pufferzeiten abnimmt. Die zweite Funktion startet die Engpaßterminierung, ausgehend von den Werten aus einer graphischen Manipulation. Dabei wird das gesamte Auftragsnetz neu terminiert. Allerdings werden die Arbeitsgänge von der Terminierung ausgenommen, die bereits feingeplant, freigegeben oder noch weiter im Fertigungsprozeß fortgeschritten sind. Sofern die Terminierung zu Inkonsistenzen mit den letztgenannten Typen von Arbeitsgängen führt, etwa in der Art, daß der Starttermin eines umgeplanten Arbeitsgangs vor dem Endtermin eines bereits feingeplanten Vorgängers liegt, so

82

Engpaßorientierte Auftragsterminierung

werden die Probleme aufgezeigt sowie neue Startparameter, mit denen die Engpaßterminierung erneut beginnen kann, berechnet und vorgeschlagen. Eine mögliche Anwendung dieser Funktion ist die Terminierung von potentiellen Kundenaufträgen in der Angebotsphase unter Berücksichtigung der Auslastung. Auf diese Weise kann schon zu einem sehr frühen Zeitpunkt späterer Umplanungsaufwand vermieden werden. Eine weitere wichtige Anwendungsmöglichkeit liegt vor, wenn große Lose zur temporären Entlastung eines Engpasses aufgespalten werden sollen, so daß wenigstens ein Teillos termingerecht fertiggestellt wird. Das abgespaltene Teillos wird in die Zukunft bewegt und zentral oder rückwärts neu terminiert. Schließlich ist es auch denkbar, (Lager-) Aufträge, die nicht zeitkritisch sind, der Engpaßterminierung zur Umplanung zu übergeben, um Kapazität für wichtigere Aufträge zu schaffen. Ein wesentliches Merkmal der graphischen Planungsfunktionen ist, daß die Parameter für die Planung aus der Graphik und aus der Position des Mauszeigers gewonnen werden. Eingaben über die Tastatur sind gar nicht oder nur in sehr geringem Umfang nötig. Damit reduziert sich die Komplexität der Schnittstelle zwischen Mensch und Maschine erheblich. 4.4 Graphische Reihenfolge- und Betriebsmittelbelegungsplanung Bedingt durch viele Einflußfaktoren wie Maschinenstörungen, Ausschußproduktion, Eilaufträge etc. ist der Zeithorizont für die Planung der Betriebsmittelbelegungen und der Auftragsreihenfolgen sehr kurzfristig. Den Ausgangspunkt bilden die Auftragsnetze, die im Rahmen der Durchlaufterminierung oder bei der Kapazitätsdisposition grob terminiert wurden. Die einzelnen Arbeitsgänge dieser Netze sind mit frühesten Start- und spätesten Endterminen versehen, die zugleich den dispositiven Spielraum der Fertigungssteuerung markieren. Die Wirkung der Fertigungssteuerung hängt, wie eingangs schon angedeutet, stark von organisatorischen Faktoren ab. Die sorgfältigste Disposition der Kapazitäten und die ausgefeiltesten Reihenfolgen sind wertlos, wenn sie in der Fertigung nicht durchgesetzt werden können. Ein möglicher Weg zur erfolgreichen Durchsetzung des Produktionsplans ist der, daß jeder Arbeitsgang, zumindest an den für den Gesamtablauf kritischen Arbeitsplätzen, explizit freigegeben wird. Die Freigabe könnte formal dadurch erfolgen, daß die Fertigungsunterlagen und Materialentnahmescheine mit dem Zeitpunkt der Freigabe gedruckt werden, so daß ein Arbeitsgang nicht vorher begonnen werden kann, selbst wenn alle Voraussetzungen dafür geschaffen wären. Eine wesentliche Voraussetzung für die Wirksamkeit der engpaßorientierten Fertigungssteuerung ist, daß die Produktion nach einem Plan abläuft (der durchaus

Engpaßorientierte Auftragsterminierung

83

ständig modifiziert werden kann, der aber aktuell ist). Wie bei der Kapazitätsdisposition im Rahmen der mittelfristigen Planung bedürfen die Engpaßkapazitäten auch bei der Maschinenbelegungsplanung einer besonderen Behandlung. Ist der Kapazitätsbedarf des Auftragsvolumens, das die Fertigungssteuerung bewältigen muß, größer als der Kapazitätsbestand, so besteht kaum eine Chance, daß alle Aufträge termingerecht erledigt werden. Reicht der Kapazitätsbestand, eventuell nach einem Abgleich in der Kapazitätsdisposition, grundsätzlich aus, so bedeutet dies aber noch lange nicht, daß der Produktionsplan termingerecht abgewickelt werden kann - selbst dann nicht, wenn keine unvorhergesehenen Ereignisse eintreten. Bei der Umsetzung des Produktionsplans treten ähnliche Schwierigkeiten wie bei einem Packungsproblem auf, bei dem eine Menge von Rechtecken in eine Fläche mit vorgegebener Geometrie und gleichem oder größerem Flächeninhalt eingepaßt werden soll. So wie die vorgegebene Geometrie zusätzliche Restriktionen für das Machbare setzt, müssen bei der Maschinenbelegungsplanung zusätzliche Randbedingungen berücksichtigt werden, die beispielsweise von vorhergehenden und nachfolgenden Arbeitsgängen herrühren können. Deshalb ist es wichtig, daß bei der Belegungsplanung der Engpässe nicht Freiheitsgrade durch ungeeignete Planungsreihenfolgen verloren gehen. Insbesondere ist es nicht sinnvoll, die vorhergehenden Arbeitsgänge eines Auftrags, der eine Engpaßkapazität durchläuft, zuvor auf anderen, unkritischen Betriebsmitteln einzuplanen. Vielmehr sollten die Engpässe möglichst immer einen Schritt vor den anderen Kapazitäten verplant werden. Dies bedeutet, daß für die Engpaßbetriebsmittel ein entsprechend größerer Planungshorizont gewählt wird. Da aber längerfristige Pläne aufgrund der Unwägbarkeiten in der Fertigung schwerer einzuhalten sind, ist es besonders wichtig, daß bei der Umsetzung Disziplin geübt wird; vor allem dürfen nicht zu den ohnehin vorhandenen Unsicherheitsfaktoren weitere, vermeidbare Unwägbarkeiten dadurch hinzukommen, daß die Fertigung willkürlich vom Plan abweicht. Wegen der unbedingt erforderlichen Aktualität müssen die Belegungspläne den sich wandelnden Randbedingungen rasch und ohne großen Aufwand angepaßt werden können. Noch wichtiger als bei der Kapazitätsdisposition sind deshalb effiziente, ergonomisch optimierte Benutzerschnittstellen. Ausgehend von dieser Anforderung wurde als Oberfläche die klassische Stecktafel (Plantafel) auf einem graphischen Terminal nachgebildet, wie auch Abbildung S zeigt. Funktionen, die man an einer Stecktafel manuell ausführt, können in dem elektronischen Abbild mit der Maus durchgeführt werden.

84

Engpaßorientierte Auftragsterminierung

Auf der Plantafel werden vor allem Arbeitsgänge ein-, aus- und umgeplant. Darüber hinaus können, ähnlich wie bei der graphischen Kapazitätsdisposition, Informationen über die Objekte der Grafik aus verschiedenen Menüs gewonnen werden. Leitstand LI i Plantaf»!

snlttelwahl Daten Hilfe Hanlnulation SlMulatlon Zelt // Ende B«trlebsnitteldaten iV&WlVj iWiTlTA+j^ HV003 : HE 004 BH-Nuwwr BH-Bszelohnung i Endnontag* Platz 4 HU 002 ruaehoerlge Gruppe I HE f.TT

Fabrikkalender

HE 006

i HR«

TT f.T.T.1 T.t T f.f*T,t.T.T.T.",f,f,T.1'

W&ä&MtMMMiiiiim

[y.lei.n )

HE 004 ^ HE 003

HE082 KF006 FflGNR I fr.Startteraln • 1.9.88 19143 18

so.Endtermin t 14.9.88 11|49

mmmmmmm

Abb. 5: Graphische Plantafel

Bei der Einplanung oder Umplanung eines Arbeitsgangs sind grundsätzlich nur Termine zulässig, die innerhalb der Ecktermine aus der Durchlaufterminierung liegen. Die Ecktermine sind abhängig von den Eckterminen der unmittelbaren Vorgänger und Nachfolger des Arbeitsgangs. Sofern Vorgänger und Nachfolger noch nicht verplant sind, gilt, daß der früheste Starttermin gleich dem frühesten Endtermin des Vorgängers zuzüglich der Transportzeiten und prozeßbedingten Übergangszeiten ist. Ebenso ist der späteste Endtermin gleich dem spätesten Starttermin des Nachfolgers abzüglich der Transportzeiten und prozeßbedingten Übergangszeiten. Sind Vorgänger oder Nachfolger dagegen bereits verplant, so werden den Eckterminen die feingeplanten Zeiten zugrundegelegt. Von daher ist es einsichtig, daß bei der Planung der Engpässe die benachbarten Arbeitsgänge möglichst noch nicht verplant sein sollten. Damit die in der Plantafel festgelegte Betriebsmittelbelegung auch realisiert wird, verfügt die Plantafel über eine eigene Freigabefunktion. Vor der Freigabe eines mit

Engpaßorientierte Auftragsterminierung

85

der Maus identifizierten Arbeitsgangs prüft die Freigabefunktion zunächst, ob alle benötigten Materialien, Werkzeuge etc. verfügbar sind. Wenn dies der Fall ist, druckt sie die Arbeitspapiere aus. Somit besteht die Chance, daß im Sinne einer belastungsorientierten Freigabe gezielt der Belegungsplan durchgesetzt werden kann.

5 Elektronische Leitstände als Patentrezept? PPS-Systeme werden als Standardsoftware oder Eigenentwicklung seit den 60er Jahren in zunehmendem Maße in Fertigungsbetrieben jeder Größenordnung eingesetzt. Trotz ständig wachsender Funktionalität und verbessertem Bedienungskomfort scheinen die Wünsche und Anforderungen der Anwender immer noch nicht befriedigend abgedeckt zu sein. Gegenwärtig ist der Hauptkritikpunkt, daß die PPSSysteme die Durchsetzung des Produktionsplans in der Fertigung nur unzureichend unterstützen; die für die Wettbewerbsfähigkeit wichtigen verkürzten Durchlaufzeiten und Lieferfristen können zwar geplant, aber nicht eingehalten werden. Deshalb wird der Ruf nach effizienten Werkzeugen für eine wirkungsvolle Werkstattsteuerung immer lauter. Angesichts des günstigen Preis-/Leistungsverhältnisses bei graphischen Workstations reagiert der Markt mit einem rasch wachsenden Angebot an sogenannten "graphischen" oder "elektronischen" Leitständen [14]. Von diesen Systemen verspricht man sich, daß die Probleme in der Fertigung transparenter werden und sich somit leichter lösen lassen. Im Umfeld der Fertigungssteuerung sind sehr große Datenmengen zu bewältigen, deren Aktualität sich auf konventionelle Weise nur schwer sicherstellen läßt. Für die Wirksamkeit und die Akzeptanz eines rechnergestützten Leitstandsystems ist es wichtig, daß es den Menschen unterstützt, ohne ihm zusätzliche Arbeit zu bereiten. Dazu kann eine Benutzerschnittstelle von hohem Bedienungskomfort wie die beschriebene wesentlich beitragen. Die Wirksamkeit eines Leitstandsystemen hängt jedoch auch stark davon ab, ob es gezielt eingesetzt wird und inwieweit in seinem Umfeld die ablauforganisatorischen Voraussetzungen geschaffen werden können. Die Gründe für lange Liegezeiten und für Terminüberschreitungen sind zwar zuerst bei den Engpässen in der Fertigung zu suchen; dortige Schwachstellen bilden geeignete Ansatzpunkte, von denen ausgehend mit Hilfe neuer Konzepte und Instrumente bessere Ergebnisse erzielbar sind. Die Gründe liegen jedoch nicht allein in der Fertigung, sondern auch in den vorgelagerten Bereichen, bis hin zur Auftragsakquisition. Deshalb sind ganzheitliche Konzepte erforderlich, die der Überlastung von Engpässen frühzeitig vorbeugen helfen. Ohne durchgängige Maßnahmen von der Angebotsphase bis zur Fertigungssteuerung besteht die Gefahr, daß sich mit den

86

Engpaßorientierte Auftragsterminierung

neuen Steuerungsinstrumenten die Mißstände zwar komfortabler verwalten, aber kaum beheben lassen.

Anmerkungen [1] Neue Entwicklungen in der Produktionsplanung und -Steuerung werden beschrieben bei Kurbel (1988) und Kurbel (1985). [2] Vgl. Kurbel, Meynert (1988b), S. 68 ff. [3] Die materialwirtschaftlichen Aspekte bleiben in diesem Beitrag außer Betracht; vgl. dazu z.B. Kurbel, Meynert (1987). [4] Vgl. zur Planungsphilosophie z.B. Scheer (1988), S. 17 ff.; Kurbel, Meynert (1988b), S. 62 ff. [5] Vgl. Hackstein, Strack (1987), S. 79. [6] Vgl. Kettner, Bechte (1981); Wiendahl (1987a). [7] Vgl. Wiendahl (1987b), S. 33 f. [8] Vgl. Wiendahl (1987a), S. 312 ff. [9] Vgl. Adam (1988), S. 105 ff. [10] Vgl. zum Funktionsumfang von PPS-Systemen z.B. Meynert (1985), Meynert, Kurbel (1986); Miessen u.a. (1987), S. 53 ff. [11] Vgl. z.B. Brankamp (1973), S. 106 ff. [12] Vgl. dazu auch Pabst (1985), S. 160 f. [13] Vgl. Kurbel, Meynert (1988a); Kurbel (1989). [14] Vgl. Kurbel, Meynert (1988a).

Literatur Adam, D.: Die Eignung der belastungsorientierten Auftragsfreigabe für die Steuerung von Fertigungsprozessen mit diskontinuierlichem Materialfluß; ZfB 58 (1988) 1, S. 98-115. Brankamp, K.: Ein Terminplanungssystem für Unternehmen der Einzel- und Serienfertigung, 2. Aufl.; Würzburg, Wien 1973. Hackstein, R., Strack, M.: Organisation und Effizienz der Werkstattsteuerung Ergebnisse einer umfangreichen Erhebung in 38 Betrieben; FB/IE 36 (1987) 2, S. 76-82. Kettner, H., Bechte, W.: Neue Wege der Fertigungssteuerung durch belastungsorientierte Auftragsfreigabe; VDI-Z 123 (1981) 11, S. 459-465. Kurbel, K.: Der "Elektronische Leitstand L I " für die Fertigungssteuerung; VDIBericht 723, Informatik für die industrielle Automation, Düsseldorf 1989, S. 193-201.

Engpaßorientierte Auftragsterminierung

87

Kurbel, K.: Flexible Konzeptionen für die zeitwirtschaftlichen Funktionen in der Produktionsplanung und -Steuerung; in: Hax, W., Kern, H., Schröder, H. H. (Hrsg.): Zeitaspekte in betriebswirtschaftlicher Theorie und Praxis; Stuttgart 1989, S. 189-202. Kurbel, K.: Interaktive Planung und Steuerung im Produktionsbereich; in: Ballwieser, W„ Berger, K.-H. (Hrsg.): Information und Wirtschaftlichkeit - Wissenschaftliche Tagung des Verbandes der Hochschullehrer für Betriebswirtschaft e. V. an der Universität Hannover 1985; Wiesbaden 1985, S. 501-524. Kurbel, K., Meynert, J.: Flexibilität in der Fertigungssteuerung durch Einsatz eines elektronischen Leitstands; ZwF 82 (1988a) 12, S. 571-585. Kurbel, K„ Meynert, J.: Flexibilität und Planungsstrategien für interaktive PPSSysteme; HMD 25 (1988b) 139, S. 60-72. Kurbel, K., Meynert, J.: Materialwirtschaft im Rahmen von PPS; in: Geitner, U. (Hrsg.): CIM-Handbuch; Braunschweig 1987, S. 64-74. Meynert, J.: Untersuchung des Funktionsumfangs von Standardsoftware zur Produktionsplanung und -Steuerung - Ein Vergleich; Arbeitsbericht Nr. 2 des Lehrstuhls für Betriebsinformatik, Universität Dortmund 1985. Meynert, J., Kurbel, K.: Dialogsysteme für Auftragsfertiger; Information Management 1 (1986) 1,S. 42-48. Miessen, E.D., von Loeffelholz, F.F., Roos, E.: Marktstudie: 77 PPS-Systeme im Vergleich, Teil 1; CIM Management (1987) 3, S. 53-65. Pabst, H.-J.: Analyse der betriebswirtschaftlichen Effizienz einer computergestützten Fertigungssteuerung mit CAPOSS-E in einem Maschinenbauunternehmen mit Einzel- und Kleinserienfertigung; Frankfurt et al. 1985. Scheer, A.-W.: CIM - Der computergesteuerte Industriebetrieb, 3. Aufl.; Berlin u.a. 1988. Wiendahl, H.-P.: Belastungsorientierte Fertigungssteuerung - Grundlagen, Verfahren, Realisierung; München 1987a. Wiendahl, H.-P.: Belastungsorientierte Fertigungssteuerung; technologie & management (1987b) 2, S. 28-34.

Entwicklung und Analyse von PCgestützten Verfahren zur interaktiven grafikorientierten Verschnittplanung Matthias Rode, Otto Rosenberg

Inhalt 1 Einleitung 2 Charakterisierung von Verschnittproblemen 3 Beschreibung und Analyse von Verfahren zur Lösung von zweidimensionalen Verschnittproblemen 3.1 Beschreibung der implementierten Verfahren 3.1.1 Der Next-Fit Decreasing Height Algorithmus (NFDH) 3.1.2 Der First-Fit Decreasing Height Algorithmus (FFDH) 3.1.3 Der Split-Fit Algorithmus (SFIT) 3.1.4 Der Sleator-Algorithmus (SLEA) 3.1.5 Der Modified Sleator-Algorithmus (MSLEA) 3.1.6 Der Modified First-Fit Decreasing Height Algorithmus (MFFDH) 3.2 Analyse der implementierten Verfahren 4 Interaktive Veränderung der heuristischen Lösungen 4.1 Erweiterungen von TRIMLOSS 4.2 Analyse der Interaktionsergebnisse 5 Ausblick Anmerkungen Literatur

1 Einleitung Im Rahmen des Projekts "Entwicklung interaktiver, PC-gestützter, benutzerorientierter Simulationsmodelle" sollten Simulationsmodelle zur Lösung von praxisrelevanten Problemen aus dem Logistik- und Materialbereich entwickelt werden. Bei der Konstruktion dieser Modelle wurde darauf geachtet, daß der Nutzer vielfältige Interaktionsmöglichkeiten hat, so daß er jederzeit in den Lösungsprozeß aktiv eingreifen kann.

90

Verfahren zur Verschnittplanung

Während in der ersten Förderungsphase die Modellierung und empirische Überprüfung logistischer Teilmoduln und ihre Verknüpfung zu einem logistischen Gesamtmodell im Vordergrund standen, konzentrierten sich in der zweiten Phase die Bemühungen auf die Entwicklung eines interaktiv zu nutzenden Simulationsmodells zur Lösung von Verschnittproblemen. Der hierzu erreichte Stand der Arbeiten und die bisher erzielten Ergebnisse werden in diesem Beitrag dargestellt Verschnittprobleme sind dadurch gekennzeichnet, daß ein gegebenes Material in kleinere Einzelstücke, die spezifischen produktionstechnischen oder kundenbezogenen Anforderungen entsprechen müssen, zerschnitten wird. Derartige Probleme sind komplexe kombinatorische Optimierungsprobleme, für die es keine oder nur in ganz speziellen Fällen erfolgreich einsetzbare exakte Lösungsverfahren gibt. Man beschränkt sich daher im allgemeinen darauf, mit effizienten Heuristiken möglichst gute zulässige Lösungen zu bestimmen. Im Rahmen des Forschungsprojekts wurde das Simulationsmodell TRIMLOSS entwickelt, das zur Lösung von Verschnittproblemen eingesetzt werden kann. TRIMLOSS ist modular und endnutzerorientiert aufgebaut. Mit ihm lassen sich alternative heuristische Lösungen für Verschnittprobleme ermitteln, grafisch darstellen und interaktiv verändern.

2 Charakterisierung von Verschnittproblemen Im Materialbereich vieler Industriezweige stellt sich das Problem, gegebene Gegenstände (Glas, Papier oder Pappe, Blech, Stahlrohre, Stein, Holz, Plastik, Platinen) in kleinere Einzelstücke aufzuteilen. Diese Aufteilung soll möglichst kostengünstig erfolgen. Kosten verursachen vor allem der Zuschneideprozeß und das nach der Aufteilung nicht mehr verwertbare Material, der sogenannte Abfall oder Verschnitt. Da die Verschnittkosten in vielen Fällen die dominierenden relevanten Kosten sind, wird als Zielfunktion im allgemeinen die Minimierung der Verschnittmenge gewählt Die in der Realität zu lösenden Verschnittprobleme können sehr unterschiedlich sein. Sie lassen sich nach einigen wesentlichen Merkmalen klassifizieren. Derartige Merkmale sind etwa Dimensionalität, Formate des Einsatzmaterials und der zu schneidenden Objekte sowie die Schnittechnik. Nach der Dimensionalität läßt sich folgende Einteilung vornehmen: (1) Eindimensionale

Verschnittprobleme

Nur eine Abmessung des Einsatzmaterials ist zur Problemlösung relevant. Die Problemstellung liegt somit in der Aufteilung einer gegebenen Länge eines Mate-

Verfahren zur Verschnittplanung

91

rials in vorgegebene Teillängen. Anwendungsbeispiele sind das Zerteilen von Stangen- bzw. Rohrmaterial oder von Latten. (2) Zweidimensionale Verschnittprobleme Beim zweidimensionalen Verschnittproblem sind zwei Abmessungen des Einsatzmaterials von Bedeutung. Die Aufgabe besteht hier im Zerteilen einer oder mehrerer Flächen eines Materials in kleinere vorgegebene Teilflächen. Anwendungsbeispiele sind u.a. Zuschnitte von Blechen, Glasscheiben, Platinen oder Papierbahnen. (3) Dreidimensionale Verschnittprobleme Beim dreidimensionalen Verschnittproblem sind schließlich aus einem gegebenem Volumen eines Materials verschiedene Teilvolumina zu schneiden. Als Anwendungsbeispiel sei hier das Zerteilen eines Baumstammes in unterschiedlich lange, breite und hohe Bretter genannt (4) N-dimensionale Verschnittprobleme Eine untergeordnete Relevanz besitzen N-dimensionale Verschnittprobleme, bei denen mehr als drei Dimensionen problemrelevant sind. So können dreidimensionale Verschnittprobleme unter Berücksichtigung des Zeitfaktors als vierdimensionale Verschnittprobleme definiert werden [1]. Der Problemtyp der zweidimensionalen Verschnittprobleme, bei dem größere rechteckige Flächen in kleinere rechteckige Flächen zu zerteilen sind, besitzt die größte Praxisrelevanz. Dieser Beitrag beschäftigt sich mit der Analyse und Entwicklung von PC-gestiitzten Verfahren zur Lösung derartiger zweidimensionaler Verschnittprobleme. Zur genaueren Charakterisierung werden zusätzlich das Format des Einsatzmaterials und die Schneidetechnologie herangezogen. (1) Offene zweidimensionale Verschnittprobleme Beim offenen Verschnittproblem besteht die Aufgabe darin, eine gegebene Anzahl von Rechtecken auf einer Fläche mit begrenzter Breite, aber unbegrenzter Höhe (im folgenden als "Bahn" bezeichnet) anzuordnen. Diese Anordnung soll derart erfolgen, daß die sich beim späteren Zerteilen der Bahn ergebende Restfläche, die nicht mit Rechtecken besetzt ist, minimal wird. Diese Restfläche stellt den Verschnitt dar. Abbildung la zeigt ein Beispiel für ein offenes Verschnittproblem. Der Verschnitt ist schraffiert gekennzeichnet (2) Geschlossene zweidimensionale Verschnittprobleme Im Gegensatz zum offenen ist beim geschlossenen Verschnittproblem eine gegebene Anzahl von Rechtecken auf eine oder mehrere Flächen mit begrenzter Breite und

Verfahren zur Verschnittplanung

92

begrenzter Höhe, sogenannten Tafeln, zu verteilen. Die Zuordnung der Rechtecke soll dabei derart erfolgen, daß die Anzahl der benötigten Tafeln minimal wird. Abbildung lb zeigt ein Beispiel für ein geschlossenes Verschnittproblem.

W/A -

'WM.

V/M

•

m

1 i

k 1

w/m

\

Abb. 1: Das offene und geschlossene Verschnittproblem

Das Ausschneiden von kleineren Rechtecken kann mit Guillotineschnitten oder mit verschachtelten Schnitten durchgeführt werden. Mit einem Guillotineschnitt wird die jeweils zu zerteilende Fläche und die entstehenden Teilflächen mit nacheinander erfolgenden Schnitten jeweils in zwei Teile zerteilt. Abbildung la ist ein Beispiel für ein mit Guillotineschnitten zu erzielendes Schnittmuster. Läßt sich ein Schnittmuster nicht durch Guillotineschnitte erzeugen, so ist es verschachtelt. Das Schnittmuster in Tafel 3 der Abbildung lb ist das Ergebnis einer derartig verschachtelten Schnittechnik. Dieser Beitrag konzentriert sich auf die Analyse und Entwicklung von Verfahren zur Lösung des zweidimensionalen offenen Verschnittproblems mit Guillotineschnitten. Es werden nur Verfahren entwickelt und berücksichtigt, die die Rechtecke auf Ebenen anordnen. Damit ist sichergestellt, daß alle erzeugten Schnittmuster durch Guillotineschnitte zu erzeugen sind. Durch Kombination dieser Verfahren mit Verfahren zur Lösung eindimensionaler Probleme können die Konzepte auch für geschlossene Verschnittprobleme nutzbar gemacht werden [2]. Mit den Bezeichnungen b. h N BB

- Breite des Rechtecks i [Längeneinheiten (LE)], i=l(l)N - Höhe des Rechtecks i [LE], i=l(l)N - Anzahl der zu plazierenden Rechtecke [-] - Breite der Bahn [LE]

93

Verfahren zur Verschnittplanung HB - Höhe der mit N Rechtecken besetzten Bahn [LE] SM - Schnittmuster: Bestimmte Anordnung aller N Rechtecke [-] V

- Verschnitt [LE]*[LE]

läßt sich das hier untersuchte offene Verschnittproblem wie folgt formulieren: Finde ein zulässiges Schnittmuster SM, so daß der Verschnitt N V = BB * HB - £ ( *>! * \ i=l minimiert wird.

)

Folgende Restriktionen sind zu beachten, um ein zulässiges Schnittmuster zu erhalten: (7) Die angeordneten Rechtecke dürfen sich nicht überlappen. (2) Die Anordnung der N Rechtecke darf die vorgegebene Breite der Bahn nicht überschreiten. Darüber hinaus ist darauf zu achten, daß bestimmte technisch bedingte Beschränkungen nicht verletzt werden: (3) Die anzuordnenden Rechtecke dürfen nicht (auch nicht um 90 Grad) gedreht werden (Musterproblem). (4) Alle Rechtecke sollen durch Guillotineschnitte zu erzeugen sein. Da die Breite der Bahn BB sowie die Anzahl N der Rechtecke und für jedes Rechteck i die Fläche b. * h. gegeben sind, stellt die Höhe HB der Bahn bei alternativer Anordnung aller N Rechtecke die einzige Entscheidungs variable dar. Unter Berücksichtigung dieser Aspekte läßt sich dann das offene zweidimensionale Verschnittproblem auch folgendermaßen formulieren: Finde ein zulässiges Schnittmuster SM, so daß die Höhe der Bahn HB

unter Beachtung der Restriktionen (1) bis (4) minimiert wird.

94

Verfahren zur Verschnittplanung

3 Beschreibung und Analyse von Verfahren zur Lösung von zweidimensionalen Verschnittproblemen 3.1 Beschreibung der implementierten Verfahren Da Verschnittprobleme zur Klasse der NP-harten Probleme gehören, sind sie in der Regel durch exakte Verfahren nicht in polynomial begrenzter Zeit optimal zu lösen [3]. Die Menge der einsetzbaren Lösungsverfahren ist daher gerade bei mittleren und großen Problemen, wie sie in der Praxis vorkommen, weitgehend auf effiziente heuristische Verfahren beschränkt. Ausgangspunkt der Überlegungen bilden vier bekannte heuristische Verfahren zur Lösung offener Verschnittprobleme, (1) der Next-Fit Decreasing Height Algorithmus (NFDH), (2) der First-Fit Decreasing Height Algorithmus (FFDH), (3) der Split-Fit Algorithmus (SFIT) sowie (4) der Sleator-Algorithmus (SLEA), die zunächst charakterisiert werden sollen. Danach werden zwei Verfahren, (5) der Modified Sleator-Algorithmus (MSLEA), (6) der Modified First-Fit Decreasing Height Algorithmus (MFFDH), die im Rahmen dieses Projekts entwickelt worden sind, vorgestellt. 3.1.1 Der Next-Fit Decreasing Height Algorithmus (NFDH) Dieses Lösungsverfahren ordnet die anzuordnenden Rechtecke nach nichtansteigender Höhe. Sodann werden die Rechtecke der Reihenfolge nach von links nach rechts auf die unterste Kante der Bahn verteilt. Diese untere Kante bildet den Boden der ersten Ebene des Schnittmusters. Paßt ein Rechteck nicht mehr in den verbleibenden Raum zwischen dem letzten angeordneten Rechteck und rechter Begrenzung der Bahn, so wird eine neue Ebene definiert, und zwar durch Ziehen einer horizontalen Linie entlang der oberen Kante des ersten (und somit höchsten) Rechtecks der ersten Ebene. Auf der neuen Ebene kann nun mit der Plazierung der Rechtecke fortgefahren werden. Es werden solange neue Ebenen gebildet, bis alle Rechtecke auf der Bahn angeordnet worden sind. Abbildung 2 zeigt einen durch TRIMLOSS erzeugten Bildschirmausdruck eines gemäß NFDH generierten Schnittmusters, das aus N = 25 Rechtecken zusammengesetzt ist Die Standardbreite der Bahn beträgt bei diesem Testbeispiel 300 Längen-

Verfahren zur Verschnittplanung

95

einheiten. Die Breiten und Höhen der Rechtecke wurden mittels Zufallszahlengeneratoren erzeugt. Dieses Testbeispiel wird auch zur Erläuterung der folgenden Heuristiken verwendet. Die Höhe der nach NFDH mit den 25 Rechtecken belegten Bahn beträgt 100 Längeneinheiten. •

138

8

58

188 158

280 250 300

Abb. 2: NFDH-Schnittmuster 3.1.2 Der First-Fit Decreasing Height Algorithmus (FFDH) Das FFDH-Lösungsverfahren stellt eine Weiterentwicklung des NFDH Algorithmus dar. Die anzuordnenden Rechtecke werden wiederum nach nichtansteigender Rechteckshöhe geordnet und der Reihenfolge nach von links nach rechts auf den Ebenen verteilt. Die unterste Kante der Bahn bildet dabei wieder den Boden der ersten Ebene. Jedes Rechteck wird nunmehr jedoch auf der jeweils untersten Ebene plaziert, auf der noch genügend Restbreite für dieses Rechteck zur Verfügung steht. Eine Lösung ist erreicht, wenn alle N Rechtecke angeordnet sind. Der entscheidende Unterschied zum NFDH Algorithmus besteht also darin, daß bei der Anordnung der Rechtecke gemäß FFDH wieder auf tiefere Ebenen zurückgegangen werden kann, während bei NFDH eine Zuordnung nur auf der derzeitigen bzw. nächsthöheren Ebene erfolgen kann. Im schlechtestmöglichen Fall, wenn also keine Rückspriinge vorgenommen werden können, verhält sich FFDH genauso wie NFDH.

Verfahren zur Verschnittplanung

96

Abbildung 3 zeigt einen durch TRIMLOSS erzeugten Bildschirmausdruck eines gemäß FFDH generierten Schnittmusters für das im vorhergehenden Abschnitt skizzierte Testbeispiel. Die Höhe der mit den 25 Rechtecken belegten Bahn beträgt 99 Längeneinheiten.

130

0

50

100

150

200 250 300

Abb. 3: FFDH-Schnittmuster

3.1.3 Der Split-Fit Algorithmus (SFIT) Dieses etwas komplexere Lösungsverfahren ermittelt aus den gegebenen N Rechtecken zunächst eine Hilfsvariable m. Die Variable m ist der größte ganzzahlige Wert, für den gilt, daß das breiteste Rechteck aller N Rechtecke eine Breite von kleiner oder gleich BB/m hat. Nach der Bestimmung von m werden die N Rechtecke zwei Teillisten (TL1 und TL2) zugeordnet. Die erste Teilliste TL1 setzt sich dabei aus allen Rechtecken zusammen, deren Breite größer als BB/(m+l) ist. Die zweite Teilliste TL2 beinhaltet alle Rechtecke mit einer Breite von kleiner oder gleich BB/ (m+1). Gemäß dem FFDH Algorithmus werden die Rechtecke der TL1 auf der Bahn plaziert. Nachdem alle Rechtecke der ersten Teilliste angeordnet worden sind, ergeben sich auf den verschiedenen Ebenen Blöcke mit einer Breite im linksoffenen Intervall von ] BB/(m+1), BB ]

Verfahren zur Verschnittplanung

97

Alle Blöcke mit einer Breite im Intervall von ] BB*(m+1)/(m+2), BB ] werden sodann unter solche Blöcke geschichtet, die eine Breite im Intervall von ] BB/(m+1), BB*(m+1)/(m+2) ] haben. Es bleibt somit oberhalb der breiteren Blöcke und rechts neben den schmaleren Blöcken genügend Platz, um eine Rechtecksfläche R mit einer Breite von BB/ (m+2) zu erzeugen. Die obere Begrenzung der Rechtecksfläche wird durch die obere Kante des höchsten angeordneten Rechtecks bestimmt. Die Rechtecke der zweiten Teilliste TL2 werden alsdann gemäß FFDH in der Rechtecksfläche R angeordnet. Dabei dürfen - unabhängig von bestehenden Ebenen mit Rechtecken aus TL1 - innerhalb von R neue Ebenen gebildet werden. Die obere Kante von R darf allerdings nicht überschritten werden. Die nach diesen Zuordnungen noch übriggebliebenen Rechtecke aus TL2 werden gemäß FFDH über die Ebenen von TL1 und der Rechtecksfläche positioniert Es ist zu beachten, daß alle Rechtecke aus TL2 mit einer Breite innerhalb des linksoffenen Intervalls ] BB/(m+2), BB/(m+1) ] nicht in R passen und somit immer oberhalb der Ebenen von TL1 angeordnet werden müssen. Diese Anordnung kann zum Teil zu sehr schlechten Lösungen dieser Heuristik führen. Die beschriebenen Lösungsverfahren NFDH, FFDH und SFIT wurden erstmals von Coffman et al. publiziert [4]. Abbildung 4 zeigt einen durch TRIMLOSS erzeugten Bildschirmausdruck eines gemäß SFIT generierten Schnittmusters für das Testbeispiel. Die Höhe der mit Rechtecken belegten Bahn beträgt IIS Längeneinheiten. Es ist leicht zu erkennen, daß diese Lösung verbesserungsfähig ist 3.1.4 Der Sleator-Algorithmus (SLEA) Als viertes Verfahren wurde ein von D. Sleator entwickeltes Lösungsverfahren [5] in TRIMLOSS implementiert und analysiert. Bei diesem Verfahren werden alle Rechtecke mit einer Breite, die größer als die Hälfte der Bahnbreite ist, übereinander ausgehend von der unteren Kante der Bahn plaziert. Die obere Begrenzung des letzten angeordneten Rechtecks bestimmt die

Verfahren zur Verschnittplanung

98

Höhe H. Die restlichen Rechtecke werden nach nichtansteigender Rechteckshöhe geordnet. Gemäß NFDH werden sie nun der Reihenfolge nach solange auf der Höhe H plaziert, bis entweder die Restbreite auf H kleiner ist als die Breite des nächsten zu plazierenden Rechtecks oder bis alle Rechtecke, deren Breite kleiner oder gleich 0,5 * BB ist, auf H angeordnet worden sind. •

138

SB

50

10 0

50

100 150

200 250 300

Abb. 4: SFIT-Schnittmuster

Danach wird die Bahn oberhalb von H durch eine senkrechte Linie in zwei Hälften getrennt. Gemäß NFDH werden die verbleibenden Rechtecke auf der jeweils unteren Halbebene verteilt. Ist die Restbreite einer Halbebene nicht mehr groß genug, um ein weiteres Rechteck aufzunehmen, so wird eine neue Halbebene bestimmt Die Anordnung wird auf der jeweils untersten Halbebene fortgesetzt, bis alle Rechtecke dem Schnittmuster zugeteilt worden sind. Abbildung 5 zeigt einen durch TRIMLOSS erzeugten Bildschirmausdruck eines gemäß SLEA generierten Schnittmusters des Testbeispiels. Die Höhe der mit Rechtecken belegten Bahn beträgt 95 Längeneinheiten. Diese vier Heuristiken bildeten die algorithmische Grundlage von TRIMLOSS und wurden in Form von PASC AL-Moduln kodiert. Eine eingehende simulative Analyse dieser Heuristiken anhand diverser praxisorientierter Problemfälle führte zur Aufdeckung verschiedener Schwächen der Lösungsverfahren. Im Verlauf der weiteren Arbeit wurden verbesserte Algorithmen entwickelt, die sich als Modifikationen des Sleator-Algorithmus bzw. des FFDH-Verfahrens beschreiben lassen [6].

99

Verfahren zur Verschnittplanung +

L

i)

/ /

/

/

/

/

/

/ /

0

i 50

/

i i i i 189 150 200 2 5 0

/

/

/ / y / /

300

Abb. 5: SLEA-Schnittmuster

3.1.5 Der Modified SIeator-Algorithmus (MSLEA) Dieses Verfahren stellt im wesentlichen eine Modifikation des SIeator-Algorithmus dar. Der modifizierte Algorithmus beseitigt folgende die Lösungsgüte beeinträchtigende Schwächen des Sleator Verfahrens: (1) Rechts neben den Rechtecken, deren Breite die Hälfte der Bahnbreite überschreitet, erfolgt bei SLEA keine weitere Plazierung von Rechtecken. Dadurch wird der Verschnitt in vielen Fällen unnötig erhöht. Beim modifizierten Algorithmus werden zunächst die Rechtecke mit einer Breite von mehr als 0,5 * BB gemäß SFIT (mit m=1) plaziert. Entsteht durch diese Anordnung eine noch nicht ausgefüllte Rechtecksfläche mit einer Breite von mindestens 1/3 * BB, so wird diese gemäß FFDH mit noch nicht plazierten Rechtecken belegt (2) Auf den Halbebenen werden die Rechtecke beim SLEA-Verfahren lediglich gemäß NFDH angeordnet. Der modifizierte Algorithmus plaziert die Rechtecke dagegen gemäß FFDH. Durch diese beiden Modifikationen wird die Lösungsgüte verbessert. Sie kann in keinem Fall schlechter sein als beim Original-SLEA-Verfahren. Abbildung 6 zeigt einen durch TRIMLOSS erzeugten Bildschirmausdruck des gemäß MSLEA generierten Schnittmusters des Testbeispiels. Die Höhe der mit Rechtecken belegten Bahn beträgt 94 Längeneinheiten.

Verfahren zur Verschnittplanung

100

130

90

50

10 0

50

100 150

200 250

300

Abb. 6: MSLEA-Schnittmuster

3.1.6 Der Modified First-Fit Decreasing Height Algorithmus (MFFDH) Der Modified First-Fit Decreasing Height Algorithmus baut auf dem FFDH-Verfahrens auf. Aufgrund der Ordnung der Rechtecke auf einer Ebene nach nichtansteigender Rechteckshöhe ergeben sich zwischen Rechtecken einer Ebene und der unteren Kante der nächsthöheren Ebene Freiflächen, die mit dem FFDH-Algorithmus nicht mehr gefüllt werden können. Der modifizierte Algorithmus versucht, diese Flächen zu nutzen. Auf jeder einzelnen Ebene wird, von der rechten Seite ausgehend, über den plazierten Rechtecken dieser Ebene eine Rechtecksfläche mit der Breite 0,5 * BB gebildet, die gemäß FFDH mit Rechtecken zu füllen ist. Auch diese Modifikation kann nur zu Verbesserungen, nicht aber zu Verschlechterungen der Lösungsgüte führen. Abbildung 7 zeigt einen durch TRIMLOSS erzeugten Bildschirmausdruck eines gemäß MFFDH generierten Schnittmusters für das Testbeispiel. Die Höhe der mit Rechtecken belegten Bahn beträgt 89 Längeneinheiten.

101

Verfahren zur Verschnittplanung i

130

90

/ /

r

50

r ~

H 1

¿L

10 0 Abb. 7:

50

100 150 200 250

300

MFFDH-Schnittmuster

3.2 Analyse der implementierten Verfahren Sämtliche hier vorgestellten Algorithmen wurden im Rahmen des Programmsystems TRIMLOSS implementiert und analysiert. Anhand von 400 verschiedenen Verschnittproblemen wurde die Eignung der sechs Heuristiken zur Lösung von realen Verschnittproblemen getestet. Um die Bedeutung einzelner Einflußgrößen für die Lösungsgüte abschätzen zu können, wurden die Ausprägungen der als praxisrelevant angesehenen Merkmale systematisch variiert. Die hierbei gewonnenen Erkenntnisse lassen sich in Abhängigkeit von den einzelnen Merkmalen erläutern. (1) Anzahl der anzuordnenden Rechtecke Die Heuristiken FFDH und MFFDH lösten kleinere Problemgrößen (N < 32) besser als die anderen implementierten Heuristiken. Für Probleme mit einer höheren Anzahl anzuordnender Rechtecke (N > 64) führte das MSLEA-Verfahren zu den geringsten Verschnittmengen. (2) Größe der anzuordnenden Rechtecke Es zeigte sich, daß die Lösungsgüten der Heuristiken bei der Anordnung kleinerer Rechtecke besser als bei größeren Rechtecken waren. Lediglich der SFIT-Algorithmus erzielte bei der Anordnung kleinerer Rechtecke zum Teil sehr schlechte Lösungen.

102

Verfahren zur Verschnittplanung

(3) Ausrichtung der längeren Seite der Rechtecke (horizontal bzw. vertikal) Die Analyse ergab, daß der SLEA- und der MSLEA-Algorithmus bessere Lösungen erbrachten, wenn die anzuordnenden Rechtecke eine vertikale Lagerichtung aufwiesen, d.h., wenn die Höhe der Rechtecke größer als ihre Breite war. Ebenso konnten mit SFIT bei der Anordnung von Rechtecken mit vertikaler Lagerichtung wesentlich bessere Lösungen als bei Rechtecken mit horizontaler Lagerichtung erzielt werden. Bei den anderen Algorithmen war keine Auswirkung der Lagerichtung auf die Lösungsgüte nachzuweisen. (4) Homogenität der Rechtecke Bei extremen Problemklassen, wie beispielsweise der Anordnung von vielen kleinen Rechtecken zusammen mit nur einem großen Rechteck, waren die mit den modifizierten Algorithmen MSLEA und MFFDH erzielten Lösungen signifikant besser als die mit den anderen Algorithmen erreichten Lösungen. Ordnet man die Verfahren nach der Lösungsgüte, so ergab sich bei der Analyse von 400 Testproblemen folgende Rangfolge der Heuristiken: MFFDH > FFDH > MSLEA > SFIT > SLEA > NFDH. Das Analysedesign sowie eine ausführliche Auswertung der Untersuchungsergebnisse wurden andernorts detailliert dargestellt [7].

4 Interaktive Veränderung der heuristischen Lösungen Viele grafische Aufbereitungen der numerischen Lösungen gaben Anlaß zu der Annahme, daß selbst die von den modifizierten Verfahren erzeugten Lösungen zum Teil noch verbesserungsfähig sind (vergleiche dazu die Abbildungen 2 bis 7). Aus diesem Grund wurde das Programmsystem TRIMLOSS um ein Modul erweitert, das eine interaktive Veränderung der grafisch dargestellten Lösungen in unterschiedlicher Weise ermöglicht. Eine solche Interaktionsmöglichkeit, mit der Rechtecke verschoben bzw. neu plaziert werden können, bietet zudem den Vorteil, daß die Position von Rechtecken auch aus anderen Gründen noch verändert werden kann. Dies ist beispielsweise der Fall, wenn Fehler im Material auftreten oder andere Materialeigenschaften dazu zwingen (Auswahl spezieller Muster oder Maserungen), eine gute heuristische Lösung noch einmal zu verändern. 4.1 Erweiterungen von TRIMLOSS Die weitere Verfolgung dieser Überlegungen und erste Erfahrungen mit diesem Modul führten zur Weiterentwicklung und zum Ausbau von TRIMLOSS zu einem

Verfahren zur Verschnittplanung

103

System für eine PC-gestützte, interaktive und grafikorientierte Verschnittplanung. Das System ermöglicht die Analyse von in der Literatur vorgeschlagenen heuristischen Algorithmen hinsichtlich ihrer Lösungsgüte, erlaubt die Entwicklung verbesserter Lösungsverfahren, erzeugt grafische Schnittmuster der alternativ erzeugten Lösungen und gestattet deren interaktive Modifikation. TRIMLOSS besteht nunmehr aus insgesamt fünf Moduln, die zur Problemlösung nacheinander zu durchlaufen sind. (1)

Dateneingabemodul

Dieses Modul erlaubt die manuelle Eingabe der Breite der Bahn sowie der einzelnen, kleineren Verschnittflächen. Es ist aber auch ein Datenimport bereits eingegebener Daten von einem Speichermedium (Festplatte, Diskette) möglich. Geplant ist die Option, Daten von Standardsoftwarepaketen wie Symphony, Lotus 1-2-3 oder dBase III-*- zu übernehmen. (2)

Berechnungsmodul

Nach Eingabe der Basisdaten können eine oder mehrere Ausgangslösungen des eingegebenen Problems berechnet werden. Zur Zeit stehen dafür folgende sechs Submoduln zur Verfügung: -

Berechnung Berechnung Berechnung Berechnung Berechnung Berechnung

der Lösungsgüte gemäß NFDH der Lösungsgüte gemäß FFDH der Lösungsgüte gemäß SFIT der Lösungsgüte gemäß SLEA der Lösungsgüte gemäß MSLEA der Lösungsgüte gemäß MFFDH

Die Ergebnisse werden in numerischer Form auf dem Bildschirm ausgegeben. Aufgrund der Effizienz der heuristischen Verfahren ist die Zeit zur Berechnung einer Lösung sehr kurz. (3)

Grafikmodul

Nach der Berechnung der Lösungsgüte kann ein Schnittmuster generiert werden, wobei frei gewählt werden kann, nach welchem der sechs Algorithmen es erzeugt werden soll. Anschließend wird das Schnittmuster grafisch auf dem Bildschirm dargestellt. Die generierte Grafik kann für spätere Versuche einer Verbesserung der Lösung abgespeichert werden. (4)

Interaktionsmodul

Dieses Modul erlaubt dem Benutzer, fortlaufend aktiv in den Lösungsprozeß einzugreifen und dialogorientiert zu steuern. Mit Hilfe von Pointing-Devices wie der Maus können beliebige Rechtecke des algorithmisch erzeugten und grafisch darge-

104

Verfahren zur Verschnittplanung

stellten Schnittmusters entfernt und an anderer Stelle wieder eingefügt bzw. verschoben werden, um eine verbesserte Lösung des Problems zu erreichen. Diese vom Anwender erzeugten Schnittmusteränderungen werden vom System auf ihre Lösungsgüte untersucht, vorteilhafte Lösungen können gespeichert und konstruktiv problemlösend genutzt werden. (5)

Druckmodul

Das Druckmodul erlaubt einerseits den Ausdruck der eingegebenen bzw. eingelesenen Verschnittdaten, andererseits können auch die grafischen Schnittmuster, die von den Heuristiken bzw. durch das Interaktionsmodul erzeugt wurden, auf einem Grafikdrucker ausgegeben werden. Abbildung 8 zeigt einen Bildschirmabdruck, der während einer interaktiven Verbesserung eines Schnittmusters erstellt wurde. Die Pfeile kennzeichnen das Rechteck, das momentan vom Anwender verschoben wird. Zwei Rechtecke wurden zeitweise aus dem Schnittmuster entfernt, um mehr Platz für Verschiebungen auf dem Bildschirm zu erhalten. Die Abmessungen der aus dem Schnittmuster entfernten Rechtecke sind in der Tabelle am oberen rechten Bildrand angezeigt. Diese Rechtecke können jederzeit dem Schnittmuster wieder zugefügt werden.

Die Pfeile werden in 5-er Schritten) bewegt! 1

Nr : Weite Hoehe 1 i 31 23 2 : 56 22

0

50

100 150 200 250

Uersetzen der Rechtecke Hit

300

ESC = beenden

Abb. 8: Interaktive Änderung einer Lösung

105

Verfahren zur Verschnittplanung

In Abbildung 9 wurde eine Lösung des Testbeispiels mit Hilfe des Interaktionsmoduls erzeugt. Die Höhe der mit 25 Rechtecken besetzten Bahn beträgt 84 Längeneinheiten.

138

90

0

50

190 150

208 250 300

Abb. 9: Schnittmuster einer interaktiven Lösung des Testproblems

4.2 Analyse der Interaktionsergebnisse Um die Auswirkungen der Interaktionsmöglichkeiten möglichst aussagefähig analysieren zu können, wurden in Anlehnung an die Analyse der Heuristiken 10 unterschiedliche Problemklassen gebildet. Insgesamt waren pro Testproblem 25 Rechtecke auf einer Bahn mit einer Breite von 300 Längeneinheiten (LE) anzuordnen. Die Breiten und Längen der anzuordnenden Rechtecke wurden mittels eines Zufallszahlengenerators, der gleichverteilte Zufallszahlen erzeugt, aus den in Tabelle 1 angegebenen Intervallen ermittelt. Bei den Testfeldern 3 bis 6 wurde die Breite bzw. die Höhe eines Rechtecks (bmxx = Breite des breitesten Rechtecks [LEI; hmax = Höhe des höchsten Rechtecks [LE]) auf 100 bzw. 200 LE gesetzt, um die Auswirkung von Ausreißern auf die Lösungsgüte zu simulieren. x

1

J

Die Analyse der Testprobleme ergab, daß die heuristischen Lösungen in allen Fällen durch die interaktiven Veränderungen verbessert werden konnten. Der dafür erforderliche Zeitaufwand war im Vergleich mit der für die Erzeugung der Ausgangslösung benötigten Zeit relativ hoch. Insbesondere die Beachtung der Guillotineschnitttechnik war hierfür verantwortlich. Wurde diese Restriktion vernachlässigt, verringerte sich zum einen der Zeitaufwand für das Erzeugen einer verbesserten zulässi-

Verfahren zur Verschnittplanung

106

gen Lösung erheblich, und zum anderen waren die Lösungen in vielen Fällen wesentlich besser. Diese Ergebnisse und die Tatsache, daß in der Praxis nicht alle Schnittmuster durch Guillotineschnitte ausgeführt werden müssen (Stanztechniken, Laserstrahltechnik), führten zu dem Entschluß, auch solche Lösungen interaktiv systematisch zu erzeugen, die auf die Guillotine-Restriktion verzichteten. Diese Lösungen wurden ebenfalls ausgewertet Tab. 1: Charakterisierung des Testfeldes Testfeld

1

Breite der

Höhe der

Rechtecke

Rechtecke

in LE

in LE

5

-

60

Ausrichtung

Homogenität

5 - 60

keine

homogen homogen

2

5

-

75

5 - 75

keine

3

5

-

50

b

5

-

60

5 - 50 5 - 60 5 - 50 5 - 60 5 - 40 5 - 50 5 - 80 5 -100

keine

4 5 6 7 8 9 10

keine keine keine horizontal horizontal vertikal vertikal

b

5 5 5 5 5 5

-

50 60 80 100 40 50

max =

200

LE

max =

200

LE

*W = W =

100

LE

100

LE

homogen homogen homogen homogen

Tabelle 2 zeigt die Abweichungen der besten heuristischen Lösungen sowie der interaktiven Lösungen vom jeweiligen Lower Bound für die in Tabelle 1 charakterisierten Testfelder. Der Lower Bound LB, der eine untere Grenze der Zielvariablen HB darstellt, wurde folgendermaßen festgelegt: N LB = max ( £ i=l

( b t * h4 / BB) ; h ^ )

Den in Tabelle 2 wiedergegebenen Ergebnissen ist zu entnehmen, daß durch die interaktive Veränderung der heuristisch erzeugten Schnittmuster in jedem Fall eine Verbesserung der Ausgangslösung erzielt wurde. Während die besten heuristischen Lösungen im Durchschnitt um 27,1 Prozent vom Lower Bound abweichen, sind die interaktiven Lösungen unter Berücksichtigung von Guillotineschnitten durchschnittlich um 15,3 Prozent und die interaktiven Verbesserungen mit verschachtelten Schnitten nur noch um 9,1 Prozent vom theoretischen Lower Bound entfernt Dies

107

Verfahren zur Verschnittplanung

entspricht einer Verbesserung der heuristischen Lösung um 43,73 Prozent bei Schnittmustern mit Guillotineschnitten bzw. um 66,53 Prozent bei Schnittmustern mit verschachtelten Schnitten. Abbildung 10 gibt die mittleren Abweichungen der Lösungen vom Lower Bound für jedes der 10 Testfelder grafisch wieder. Tab. 2:

Abweichungsanalyse der heuristischen und interaktiven Lösungen Lower Bound(LB) Höhe [LE]

beste heurist. Lösung Höhe [LE]

Abw.vom LB [%]

Interaktive Lösungen m i t G. -schnitten ohne G.-schnitte Höhe [LE]

Abw.vom LB [%]

Höhe [LE]

Abw.vom LB [%]

73.8 74.4 75.2

90 93 98

22.0 25.1 30.4

80

90 86

8.5 21.0 14.4

80 82 84

8.5 10.3 11.8

111.1

112.2 112.4

146 143 142

31.4 27.4 26.3

141 133 121

26.9 18.5 7.6

118 120 121

6.2

74.3 76.5 74.6

99 96 102

33.2 25.5 36.7

99 82 102

33.2 7.2 36.7

83 82 80

11.7 7.2 7.3

114.3 114.2 113.8

136 143 143

19.0 25.3 25.7

127 127 134

11.1 11.2 17.8

125 127 123

9.4 11.2 8.1

100.0 100.0 100.0

113

13.0

109

11.0

9.0

100 100 100

0.0 0.0 0.0

100 100 100

0.0 0.0 0.0

100.0 100.0 100.0

147 146 147

47.0 46.0 47.0

128 128 123

28.0 28. 0 23.0

119 123 117

19.0 23.0 17.0

75.7 76.6 74.5

90 89 96

18.8 16.3 28.9

87 87 88

14.9 13.7 18.1

79 84 83

4.3 9.7 11.4

111.4 113.5 111.9

127 136 141

14.0 19.9 26.0

124 125 131

11.3 10.2 17.0

119 123 117

6.8 8.4 4.5

73.6 76.4 75.0

97 107 97

31.8 40.0 29.3

79 90 86

7.4 17.7 14.6

78 90 82

6.0 17.7 9.3

112.5 113.0 113.8

148 145 145

31.6 28.3 27.4

124 131 129

10.2 15.9 13.4

124 125 123

10.2 10.6 8.1

111

6.9 7.6

minimale Abweichung [%]

9.0

0.0

0.0

maximale Abweichung [%]

47.0

36.7

23.0

mittlere Abweichung [%]

27.1

15.3

9.1

108

Verfahren zur Verschnittplanung

Die interaktiven Verbesserungen der heuristischen Lösungen des fünften Testfeldes führten zu Lösungen, bei denen keinerlei Verschnitt auftrat Dieses Ergebnis wurde dadurch erreicht, daß alle 24 Rechtecke neben dem Ausreißer mit der Höhe 100 plaziert werden konnten. Mit den Heuristiken konnte eine derartige Lösungsgüte in keinem Fall erzielt werden.

O l o ^^ O t - Ox t^ e Os oO ^ I e Oj cO« I» O . * O. I O O %

ULy pxinoff

XBcn.o'j

uuoa

XLBßxLnyoxanrtqY

Abb. 10: Mittlere Abweichungen der Lösungen vom LowerBound

Verfahren zur Verschnittplanung

109

5 Ausblick Da die Ergebnisse durchaus ermutigend waren, wurden die Versuche mit weiteren Testproblemen und realen Problemen fortgesetzt. Die Resultate dieser Versuche bestätigen weitgehend die dargestellten Überlegungen. Die mit den Heuristiken gefundenen Lösungen sind im allgemeinen verbesserungsfähig. Auch ein Planer mit wenig Erfahrung kann mit Hilfe des Interaktionsmoduls erfolgreich bessere Schnittmuster erzeugen. Berücksichtigt man, daß der für ein Problem zu berechnende Lower Bound eine Lösung impliziert, bei der kein Verschnitt anfällt, so kann man davon ausgehen, daß nur in sehr seltenen Fällen eine optimale Lösung mit dem Lower Bound zusammenfällt. Im allgemeinen wird die minimale Bahnhöhe größer als der Lower Bound sein. Die interaktiv erzeugten Lösungen weichen vielfach so wenig vom Lower Bound ab, daß vermutet werden kann, sie stellen eine optimale oder zumindest fast optimale Lösung dar. Die Güte der mit den Heuristiken erzielten Lösungen ist nicht immer besonders gut. Durch Ausnutzung der spezifischen Problemstruktur wird gegenwärtig versucht, verbesserte Algorithmen zu konstruieren. Varianten dieser Algorithmen sollen darüber hinaus die Drehung der Rechtecke um 90 Grad erlauben. Schwierigkeiten bereitet im Moment die Implementierung eines Moduls, das automatisch die Abweichung einer interaktiv gefundenen Lösung vom Lower Bound berechnet, diese Abweichung bewertet und bei Erreichen einer unteren Schranke dem Planer vorschlägt, den Lösungsprozeß abzubrechen. Gleichzeitig soll hierbei überprüft werden, ob alle technologisch oder organisatorisch vorgegebenen Beschränkungen auch durch die interaktiv ermittelte Lösung eingehalten werden. Schließlich wird angestrebt, den Datenaustausch mit anderen Programmen zu vereinfachen und soweit wie möglich zu automatisieren. Dadurch dürfte nicht zuletzt die Akzeptanz des Programmpaketes auch durch relativ EDV-unerfahrene Nutzer nicht unerheblich erleichtert werden.

Anmerkungen [1] [2] [3] [4] [5] [6] [7]

Vgl. Dyckhoff (1989), S. 7. Vgl. Garey, Johnson (1981), S. 167 ff. Vgl. Karp (1972), S. 85 ff. Vgl. Coffmann et al. (1980), S. 808 ff. Vgl. Sleator (1980), S. 37 ff. Vgl. Rode, Rosenberg (1987), S. 73 ff. Vgl. Rode, Rosenberg (1987), S. 75 ff.

110

Verfahren zur Verschnittplanung

Literatur Coffmann, E.G., Garey, M.R, Johnson, D.S., Tarjan, R.E.: Performance Bounds for Level-Oriented Two-Dimensional Packing Algorithms; SIAM - Journal of Computing 9 (1980) 4, S. 808-826. Dyckhoff, H.: A Typology of Cutting and Packing Problems; EJOR, to appear 1989. Garey, M.R., Johnson, D.S: Approximation Algorithms for Bin-Packing Problems: A Survey; in: Ausiello, G., Lucertini, M. (Eds.): Analysis and Design of Algorithms in Combinatorial Optimization; Wien, New York 1981, S. 147-172. Karp, R.M.: Reducibility Among Combinatorial Problems; in: Miller, R.E., Thatcher, J.W. (Eds.): Complexity of Computer Computations; New York 1972, S. 85-103. Nastansky, L.: Softwareentwicklung mit PC-basierten Enduser-Tools; in: Österle, H. (Hrsg.): Anleitung zu einer praxisorientierten Software-Entwicklungsumgebung; Halbergmoos 1988, S. 71-86. Nastansky, L.: Softwarewerkzeuge für Endbenutzer; in: Kurbel, K., Strunz, H. (Hrsg.): Handbuch der Wirtschaftsinformatik; erscheint Stuttgart 1989. Malek, M.: KANBAN-gesteuerte Fertigung - Simulative Analyse und Strukturierung eines mehrstufigen Produktionssystems; Frankfurt a. M. 1988. Rode, M., Rosenberg, O.: An Analysis of Heuristic Trim-Loss Algorithms; in: Engineering Costs and Production Economics; Amsterdam (1987) 12, S. 71-78. Rosenberg, O., Ziegler, H.: A Comparison of the Performance of Heuristic Algorithms for Cost-Oriented Assembly Line Balancing; erscheint in Zeitschrift für Operations Research 1989. Sleator, D.: A 2.5 Times Optimal Algorithm for Packing in Two Dimensions; Information Proc. Letters 10 (1980) 1, S. 37-43.

Konzeption eines Bildschirmtext-gestützten Warenwirtschaftssystems zur Kommunikation in verzweigten Handelsunternehmungen August-Wilhelm Scheer, Uschi Leismann

Inhalt 1 Einleitung 2 Konzeptioneller Aufbau 2.1 Das Modell der Freiwilligen Kette 2.2 Anforderungen an ein Warenwirtschaftssystem in einer Verbundgruppe 2.2.1 Warenwirtschaftssystem 2.2.2 Das Warenwirtschaftssystem der Freiwilligen Kette 2.3 Das Leistungsangebot von Bildschirmtext als Informations- und Kommunikationsinstrument in der Warenwirtschaft 2.3.1 Die Systemkomponenten von Bildschirmtext 2.3.2 Die Eigenschaften von Bildschirmtext als Kommunikationsinfrastruktur 3 Leistungsumfang des Softwareprototypen 3.1 Funktionsumfang des verteilten Warenwirtschaftssystems 3.1.1 Zentrale Funktionen 3.1.2 Dezentrale Funktionen 3.2 Rechnerarchitektur in der Freiwilligen Kette 4 Implementierungsstrategie 4.1 Hard- und Softwarekomponenten 4.2 Editieren des Btx-Programms 4.2.1 Das Programm im öffentlichen System 4.2.2 Das Bildschirmtext-Programm für die Geschlossene Benutzergruppe 4.3 Integration der Programmteile Anmerkungen Literatur

112

Bildschirmtext-gestütztes Warenwirtschaftssystem

1 Einleitung Bedingt durch neuere Entwicklungstendenzen zur Polarisierung und Spezialisierung der Betriebstypen und der Verbundgruppen im Groß- und Einzelhandel (Dynamik der Betriebstypen) [1] entstehen veränderte Strukturen in der Aufbau- und Ablauforganisation des Handels. Eine wesentliche Entwicklung dabei ist, daß sich insbesondere kleine Handelsunternehmen, und dabei vor allem die des Einzelhandels, in Kooperationen und Verbundgruppen, wie Freiwillige Ketten und Einkaufsgemeinschaften, zusammenschließen, um dadurch in der Beschaffung und im Absatz Wettbewerbsvorteile zu erzielen [2], Aufgrund strategischer Maßnahmen können die Mitglieder eines solchen Unternehmensverbundes ihr wirtschaftliches Überleben sicherstellen. Der Einsatz neuer Informations- und Kommunikationstechnologien, wie beispielsweise Teletex, Telefax, Bildschirmtext (Btx) oder auch der Aufbau privater herstellerspezifischer Netze, ermöglichen es, bisher konventionell abgewickelte Kommunikationsvorgänge in Schrift und Sprache durch schnellere und kostengünstigere Techniken zu ersetzen. Daraus entstehen neue Informations- und Kommunikationssysteme im Handel, die vor allem die Integration kleiner, wirtschaftlich schwacher und dezentral verteilter betrieblicher Einheiten in ein zentral aufgebautes EDVgestütztes Warenwirtschaftssystem (WWS) fördern. Die dazu erforderlichen Kommunikationsinfrastrukturen müssen mit verfügbaren Technologien realisierbar sein. Dazu erscheint Bildschirmtext in besonderem Maße geeignet, weil dieses System dann sinnvoll einzusetzen ist, wenn in Verbindung mit bestehenden EDV-Systemen wirtschaftliche Kommunikationswege geschaffen werden sollen, auf denen Daten und Informationen in kleinen Mengen an vielen dezentralen Stellen in aktueller Form jederzeit verfügbar gemacht werden sollen [3]. Unter Berücksichtigung der Tendenzen in der Dynamik der Betriebstypen des Handels und unter Berücksichtigung der spezifischen Eignung von Bildschirmtext als Kommunikationsinfrastruktur für das skizzierte Umfeld wurden die Projektziele für die Entwicklung eines Bildschirmtext-gestützten Warenwirtschaftssystems zur Kommunikation in verzweigten Handelsunternehmungen festgelegt

2 Konzeptioneller Aufbau 2.1 Das Modell der Freiwilligen Kette Eine Freiwillige Kette ist eine vertikale Kooperation von Handelsbetrieben mehrerer Handelsstufen, deren Aufgabenstellung in der Regel im gemeinsamen Einkauf liegt. Dadurch bleiben die Vorteile des Filialprinzips bei rechtlicher Selbständigkeit der

Bildschirmtext-gestütztes Warenwirtschaftssystem

113

Kooperationspartner erhalten. Besondere Kennzeichen der Freiwilligen Kette sind der Gebietsschutz für die Mitglieder, die Selektion von Betrieben durch bestimmte Aufnahmebedingungen und der Ausbau von Dienstleistungspaketen für die Mitglieder. Von besonderer Bedeutung ist die Harmonisierung der Betriebspolitik innerhalb der Kette, häufig unter Verwendung eines gemeinsamen Zeichens [4], Die Auswahl der Freiwilligen Kette als Grundlage für den Entwurf eines Bildschirmtext-gestützten Informations- und Kommunikationssystems basiert auf folgenden Bestimmungsfaktoren: 1. der Entwicklung der Betriebstypendynamik im Handel, 2. den spezifischen Nutzungseigenschaften von Bildschirmtext und 3. den warenwirtschaftlichen Anforderungsprofilen. Unter Beachtung der gegenseitigen Interdependenzen ist das Modell einer Freiwilligen Kette im Lebensmitteleinzelhandel festgelegt worden. Abbildung 1 zeigt das Modell der Freiwilligen Kette.

Abb. 1: Das Modell der Freiwilligen Kette

114

Bildschirm text-gestütztes Warenwirtschaftssystem

Die Freiwillige Kette besteht aus folgenden Elementen: 1. der Gruppe der Einzelhändler. Sie betreiben kleine, serviceorientierte Lebensmittelfachgeschäfte mit einem hochpreisigen Kernsortiment aus dem Food-Bereich, das sie ausschließlich über den Großhändler der Freiwilligen Kette beziehen. 2. dem Großhändler. Er betreibt einen Auslieferungsgroßhandel, über den die physischen Beschaffungsaktivitäten der gesamten Kette abgewickelt werden. 3. der Kooperationszentrale: Sie wird wirtschaftlich von den Unternehmen beider Handelsstufen getragen. Sie übernimmt die Aufgaben der zentralen Warenbewirtschaftung und der Bereitstellung von Unterstützungsleistungen für die Mitglieder. 2.2 Anforderungen an ein Warenwirtschaftssystem in einer Verbundgruppe 2.2.1 Warenwirtschaftssystem Warenwirtschaftssysteme [5] sind Verfahren, die darauf ausgerichtet sind, Warenbewegungsdaten in Menge und Wert rationell zu erfassen und die daraus resultierenden Informations- und Kommunikationssysteme zur Steuerung und Überwachung des Warenflusses zu tragen. EDV-gestützte Warenwirtschaftssysteme haben folgende Vorteile [6]: - Vereinfachung des Datenerfassungsaufwands bei steigendem Sortimentsumfang durch den Einsatz modemer Technologien, wie Mobile Datenerfassung und Scanning, - Gewinnung differenzierterer Informationen über den Warenfluß, - schnellere Verfügbarkeit aller Informationen. In der neueren Entwicklung besteht ein Trend zur Integration aller warenwirtschaftlichen Funktionen in einem geschlossenen Warenwirtschaftssystem. Abbildung 2 zeigt die Funktionselemente sowie funktionale und organisatorische Beziehungen in einem Warenwirtschaftssystem.

Bildschirmtext-gestütztes Warenwirtschaftssystem

115

Abb. 2: Funktionselemente eines geschlossenen Warenwirtschaftssystems

Grundlegendes Element geschlossener Warenwirtschaftssysteme ist die artikelgenaue mengen- und wertmäßige Verfolgung des Warenflusses vom Wareneingang bis zum Warenausgang. Voraussetzung für die artikelgenaue Erfassung der Waren ist

116

Bildschirmtext-gestütztes Warenwirtschaftssystem

ihre genaue Auszeichnung. Waren, die bereits vom Hersteller mit Europäischer Artikelnummer (EAN-Barcode) oder mit OCR-Normschrift ausgezeichnet sind, können mit Scannern oder Lesestiften erfaßt werden. Nicht herstellerausgezeichnete Waren müssen im Wareneingang mit maschinenlesbaren Etiketten versehen werden. Ein weiterer Bestandteil, der zur Durchgängigkeit eines geschlossenen WWS beiträgt, ist der Einsatz von Datenkassen und Datenwaagen. Konventionelle Kassensysteme sind aufgrund ihrer begrenzten Speicherfähigkeit nicht dazu geeignet, Waren artikelgenau zu erfassen. Um diesen Bruch in der artikelgenauen Warenverfolgung zu vermeiden, werden elektronische Datenkassen, die im Stand-aloneBetrieb, Master-Slave-Betrieb oder im Verbundbetrieb mit Hintergrundrechnern arbeiten, eingesetzt. Über die Artikelnummer wird auf die gespeicherten Preise zugegriffen (Price-look-up) und der Kassenzettel durch Textausdruck (Text-lookup) erklärungsfähiger gemacht. Zur Erfassung der Frischwaren im Lebensmittelhandel werden Waagensysteme eingesetzt. Mit dem Einsatz von Datenwaagen mit integriertem Strichcodedruck werden auch die artikelgenaue Erfassung und das Scannen von lose abgepackten Artikeln im Frischwarenbereich möglich. Neuere Tendenzen zielen auf die Entwicklung integrierter Warenwirtschaftssysteme, die die Beziehungen zu externen Marktpartnern wie Lieferanten, Kunden und Banken zur Abwicklung des Zahlungsverkehrs vorsehen. Eine wesentliche Rolle spielt dabei der Einsatz neuer Informationstechnologien, wobei die neuen Kommunikationsdienste der Deutschen Bundespost die Einbeziehung regional entfernter Kommunikationspartner in leistungsfähige Systeme ermöglichen. Im untemehmensinternen bzw. innerbetrieblichen Bereich ist der Integrationsgedanke in der Weise zu realisieren, daß Schnittstellen zu angrenzenden Fachabteilungen wie Kostenrechnung, Finanzbuchhaltung, Lohn- und Gehaltsabrechnung bestehen, um eine Verbindung mit anderen betrieblichen Informationssystemen zu erreichen. Für unterschiedliche Branchen des Groß- und Einzelhandels sind bereits bewährte Standardsoftwarepakete im Einsatz. Ihr modularer Aufbau ermöglicht die schrittweise Implementierung eines geschlossenen Warenwirtschaftssystems, wobei die Schnittstellen zu o. g. Fachabteilungen berücksichtigt werden müssen. 2.2.2 Das Warenwirtschaftssystem der Freiwilligen Kette Die Gestaltung des zentralen Informations- und Kommunikationssystems für die Warenwirtschaft der Freiwilligen Kette basiert auf folgender Ausgangssituation:

Bildschirm text-gestütztes Warenwirtschaftssystem

117

1. Es wird angenommen, daß die Einzelhändler mit kleiner Betriebsgröße bisher lediglich ihre Warenausgangsdaten über Registrierkassen für Warengruppen manuell erfaßt haben. Andere Daten werden in Form von Listen oder Karteikarten gehalten und manuell gepflegt. 2. Eine genaue Auswertung der Daten für S teuerungs- und Kon trollzwecke in den Bereichen Disposition/Bestellwesen, bei Aktivitäten in der Absatzpolitik oder bei der Kontrolle der Lagerpolitik erfolgt aus vorgenannten Gründen nur lückenhaft. Daher sollen im Warenwirtschaftssystem der Freiwilligen Kette die warenwirtschaftlichen Funktionen zentralisiert werden. Ein besonderer Schwerpunkt liegt dann auf den Auswertungen im Rahmen des Marketing- und Managementinformationssystems (MMIS) [7]. Die organisatorische Durchführung, die Steuerung und die Kontrolle der Aufgaben im Rahmen des Warenwirtschaftssystems liegen bei der Kooperationszentrale. Abbildung 3 gibt einen Überblick über den Aufbau des Warenwirtschaftssystems.

Abb. 3: Aufbau eines Warenwirtschaftssystems in einer Verbundgruppe

118

Bildschirmtext-gestütztes Warenwirtschaftssystem

Die Einführung eines solchen Warenwirtschaftssystems bietet den Systemmitgliedern folgende Vorteile: 1.

Die Errichtung eines zentralen Warenwirtschaftssystems ermöglicht es auch kleinen Einzelhändlern, bisher manuell bearbeitete Funktionen EDV-gestützt und somit rationeller zu erledigen.

2.

Ein ED V-gestütztes Warenwirtschaftssystem erlaubt bei entsprechender Erfassung der Warenausgangsdaten in Datenkassen die artikelgenaue Verfolgung des Warenausgangs nach Menge und Wert.

3.

Durch die zentrale Verwaltung organisatorischer Aufgaben werden die Einzelhändler von zeitraubenden Tätigkeiten entlastet und für effizientere Aufgaben im Absatzbereich ihres Betriebes frei.

4.

Bei gemeinsamer Durchführung der Bestellungen bei den Lieferanten ergeben sich wirtschaftliche Vorteile. Absatzpolitische Vorteile entstehen durch ein einheitliches Sortiment in der Verbundgruppe.

5.

Die Einzelhändler sind sowohl besser als auch schneller über ihren wirtschaftlichen Erfolg informiert und haben somit die Möglichkeit, auf Absatzschwankungen mit ihrem absatzpolitischen Instrumentarium zu reagieren.

2.3 Das Leistungsangebot von Bildschirmtext als Informations- und Kommunikationsinstrumeiit in der Warenwirtschaft 2.3.1 Die Systemkomponenten von Bildschirmtext Die Systemarchitektur von Bildschirmtext besteht aus einer hierarchischen Rechnerstruktur mit zwei Ebenen [8]. Die Leitzentrale steuert und kontrolliert den gesamten Systembetrieb, insbesondere die Zusammenarbeit mit den Btx-Vermittlungsstellen (Typ A) über das Btx-Infra-Netz. Die Anbindung Externer Rechner erfolgt über das Datex-P-Netz an die Btx-Vermittlungsstellen, der Zugang für Teilnehmer und Informationsanbieter führt über spezielle Rufnummern des Fernsprechnetzes. Den strukturellen Aufbau des Bildschirmtextsystems zeigt Abbildung 4.

Bildschirmtext-gestütztes Warenwirtschaftssystem

119

BTX-LEITZENTRALE ORIGINALE-DB

KOMMUNIKATIONSRECHNER

VERWALTUN3SRECHNER

1 NETZWERKRECHNER

VERBUNORECHNER EXTERNER RECHNER

EXTERNER RECHNER

D

c

BTX-INFRA-NETZ

FERNSPRECHNETZ

j BTX-TEILNEHMER |

f INFORMATIONSANBIETER

Abb. 4: Die Systemarchitektur von Bildschirmtext

3

120

Bildschirmtext-gestütztes Warenwirtschaftssystem

2.3.2 Die Eigenschaften von Bildschirmtext als Kommunikationsinfrastruktur Zielsetzung bei der Entwicklung dieser Architektur war, die Vorteile zentraler und dezentraler Informationssysteme zu vereinigen, ohne zugleich auch ihre Nachteile in Kauf nehmen zu müssen. Bildschirmtext war vom Systemträger, der Deutschen Bundespost (DBP), als preiswertes, interaktives Medium geplant, um eine neue Form der Textkommunikation zwischen privaten Teilnehmern zu ermöglichen. Ein weiteres Anliegen war es, kommerziellen Systemteilnehmern (Informationsanbietern) einen direkten Kommunikationsweg zu privaten Teilnehmern zu ermöglichen und damit den Teilnehmern des Dienstes ein reichhaltiges Angebot an Informationen direkt zugänglich zu machen. Sehr rasch zeigte sich jedoch, daß im privaten Nutzungsbereich die Zielsetzung kurzfristig nicht erreicht werden konnte, da sich bei den Anwendern Akzeptanzprobleme ergaben. Gleichzeitig wurde auch bei den gewerblichen Nutzern deutlich, daß Btx hinsichtlich der Massendatenübertragung in keiner Weise traditionelle Datenübertragungswege ersetzen kann, da die niedrige Datenübertragungsgeschwindigkeit und die strikten Formatanforderungen des Dienstes eine solche Entwicklung behindern [9]. Die in Abbildung 5 dargestellten systemimmanenten Eigenschaften des Bildschirmtextdienstes machen deutlich, daß Bildschirmtext dann sinnvoll einzusetzen ist, wenn in Verbindung mit bestehenden EDV-Systemen wirtschaftliche und benutzerfreundliche Datenübertragungswege geschaffen werden sollen, auf denen Daten und Informationen in kleinen Mengen an vielen dezentralen Stellen in aktualisierbarer Form jederzeit verfügbar gemacht werden sollen. Im Hinblick auf den Einsatz als Kommunikationsinfrastruktur liegt der besondere Vorteil von Bildschirmtext in der Integrationsfähigkeit in bereits vorhandene EDVSysteme. In Verbindung mit den typischen Einsatzmerkmalen erscheint Bildschirmtext in besonderem Maße geeignet, um eine zwischenbetriebliche Integration auf der warenwirtschaftlichen Ebene zu erzielen. Ein Bildschirmtext-gestütztes Warenwirtschaftssystem trägt dann zwei wesentlichen Entwicklungstendenzen im Handel Rechnung. Zum einen können preiswerte Kommunikationswege zwischen allen Partnern einer Verbundgruppe geschaffen werden; zum anderen kann der Einsatz von Bildschirmtext innovative und zweckmäßige Strukturen von Informations- und Kommunikationssystemen aufzeigen [10]. Aus der Kombination von Btx mit einem zentralen Warenwirtschaftssystem entstehen sowohl Vorteile in der EDV-Organisation als auch strategische Vorteile im Absatz- und Beschaffungsmarketing der in der Verbundgruppe zusammengeschlossenen Partner. Voraussetzung dafür ist die Aufrüstung des Warenwirtschaftsrech-

121

Bildschirmtext-gestütztes Warenwirtschaftssystem

ners zu einem Externen Rechner. Dies gestattet den direkten Dialog der Partner der Verbundgruppe mit dem Warenwirtschaftsrechner in der Kooperationszentrale. Darüber hinaus übernimmt die Kooperationszentrale im Rahmen eines sogenannten Umbrella-Service auch die Anbieterfunktion für die dem Verbund angeschlossenen Einzelhändler im Rahmen eines öffentlichen Angebots für die Einzelhändler. Ein Bildschirmtext- Angebot der Einzelhändler für ihre Kunden ermöglicht es, eine neue Vertriebsschiene (Direktvertrieb) aufzubauen.

Hohe Ausfall-

Kompatibilität

Dialogfähigkeit

Hohe Verfügbar-

Btx-typische

Einfache Aktuali-

keit

Eigenschaften

sierbarkeit

sicherheit

Preiswerte Nutzung

Abb. 5:

Integration in bestehende EDV-Systeme

Benutzerfreundlichkeit

D i e systemimmanenten Eigenschaften v o n Bildschirmtext

Zusammenfassend bietet Bildschirm text als Kommunikationsinfrastruktur eines Informations- und Kommunikationssystems der Warenwirtschaft folgende Einsatzmöglichkeiten: 1. Übernahme von Datenübertragungsfunktionen im Warenein- und -ausgang, 2. Abwicklung von Individualkommunikation zwischen Sachbearbeitern in der Zentrale und den dezentralen Einheiten, 3. Möglichkeiten der Individualkommunikation dezentraler Einheiten untereinander, 4. Nutzung der Mailbox-Funktion, 5. Einsatz von Bildschirmtext als Werbeträger für externe Marktpartner, 6. Einbeziehung von Bildschirmtext in das Vertriebssystem als Vertriebsweg, 7. Einsatz von Bildschirmtext im Beschaffungsbereich.

122

Bildschirmtext-gestütztes Warenwirtschaftssystem

3 Leistungsumfang des Softwareprototypen Zur Realisierung des Konzepts wurde am Institut für Wirtschaftsinformatik ein Prototyp entwickelt. Hauptaufgabe des Prototypen eines Btx-gestützten Waren Wirtschaftssystems ist es zu zeigen, daß die Btx-Infirastruktur in Verbindung mit konventionellen EDV-Techniken besonders geeignet ist, um die Raum- und Zeitüberbrückungsfunktionen, die sich aus der räumlichen Verteilung von Verbundgruppen ergeben, abzudecken. Weiterhin kann mit Hilfe des Btx-Systems ein für alle Funktionen und Bereiche eines WWS durchgängiges geschlossenes System errichtet werden, welches sich 1. die Vorteile der Datenintegration [11] in allen Bereichen und 2. die Vorteile der Funktionsintegration [12] in ausgewählten Bereichen, wie beispielsweise in Disposition und Bestellwesen zunutze macht. Das Leistungsspektrum des Softwareprototypen umfaßt alle warenwirtschaftlichen Funktionen innerhalb einer Freiwilligen Kette sowie die zentrale Verwaltung der Stammdaten. Dies verdeutlicht Abbildung 6.

Abb. 6: Leistungsumfang des Softwareprototypen

Bildschirmtext-gestütztes Warenwirtschaftssystem

123

Neben der Implementierung der Funktionen eines Warenwirtschaftssystems und einer dazugehörigen Warenwirtschaftsdatenbank wurden ein Bildschirmtext-Programm zur Realisierung der Bildschirmtext-Vertriebsschiene und ein Bildschirmtext-Programm innerhalb einer Geschlossenen Benutzergruppe zur Realisierung eines Bildschirmtext-gestützten Warenwirtschaftssystems aufgebaut. Btx ist im zweiten Fall ein wirtschaftliches und einfach zu installierendes Datenübertragungsinstrument [13], durch das zusätzlich eine kostengünstige und benutzerfreundliche Oberfläche zur Verfügung gestellt werden kann. Die Implementierung des Informations- und Kommunikationssystems basiert auf dem Konzept des Externen Rechners, der sog. Rechnerverbundlösung [14]. 3.1 Funktionsumfang des verteilten Warenwirtschaftssystems Bei der Entwicklung des Warenwirtschaftssystems wurde angestrebt, möglichst viele Funktionen zu zentralisieren. Dazu ist ein zentrales Datenbankkonzept primär notwendig, um alle vorhandenen Daten entsprechend der Zugriffsberechtigung aktuell im Zugriff zu halten und eine redundanzfreie Datenspeicherung zu gewährleisten. 3.1.1 Zentrale Funktionen In der zentralen WWS-Datenbank werden alle Stammdaten des Unternehmens (Artikel-, Einzelhändler- und Kundendaten) gespeichert und gepflegt. Besondere Bedeutung kommt der täglichen Übertragung der Warenbewegungsdaten aus den dezentralen Einheiten an den zentralen Warenwirtschaftsrechner zu, da nur damit gewährleistet werden kann, daß die Kooperationszentrale auf kurzfristige Veränderungen flexibel reagieren kann. Folgende Funktionen werden für alle Partner der Freiwilligen Kette zentral abgewickelt: 1. 2. 3. 4. 5. 6.

Lagerbestandsführung, Bestellabwicklung mit Btx-Kunden, Disposition und Bestellwesen, Eingangsrechnungsprüfung, Auswertungen im Rahmen eines MMIS, Logistik.

Weiterhin werden in Form von zentral erstellten Richtlinien und Formularen Hilfestellungen für dezentral zu erledigende Funktionen erbracht Bildschirmtext ergänzt die klassische DV als Instrument der Datenübertragung sowie als Benutzeroberfläche für alle weiteren Informations- und Kommunikations-

124

Bildschirmtext-gestütztes Warenwirtschaftssystem

aufgaben. Der Bildschirmtext-Einsatz wird insbesondere deshalb attraktiv, weil durch den Btx-Rechnerverbund Kompatibilität zwischen bisher nicht kompatiblen Endgeräten in EDV-Anlagen hergestellt und über den Rechnerverbund auch an unintelligenten Arbeitsplätzen Rechnerleistungen verfügbar gemacht werden können. 3.1.2 Dezentrale Funktionen Folgende Aufgaben müssen notwendigerweise bei den Einzelhändlern vor Ort wahrgenommen werden: 1. Erfassung, Prüfung und Rückmeldung des Wareneingangs, 2. Erfassung des Warenausgangs, 3. Körperliche Inventur. Im Wareneingang des Einzelhändlers werden das Auspacken der Ware, die qualitative und quantitative Warenkontrolle durchgeführt und ein Abgleich der angelieferten Waren mit dem Lieferschein auf Fehlmengen oder Falschlieferungen vorgenommen. Die Rückmeldung der korrigierten Wareneingangsdaten an die Kooperationszentrale erfolgt über Bildschirmtext. Im Warenausgang werden auf Einzelhändlerebene im wesentlichen Datensammelfunktionen an der Kasse mit Ladenkunden wahrgenommen. Die Warenausgangsdaten werden auf einem Datenträger gespeichert und einmal täglich nach Ladenschluß verdichtet und in einem Batch-Lauf über Bildschirmtext an den Warenwirtschaftsrechner der Kooperationszentrale übertragen. In der Kooperationszentrale werden aufgrund der rechnerischen Lagerbestandsführung, die für jeden Einzelhändler durchgeführt wird, zu bestimmten Stichtagen Inventurhilfen in Form von Formularen mit errechneten Sollbeständen erstellt. Davon abweichende Ist-Werte werden in einem Batch-Lauf an die Zentrale gemeldet und dort in der entsprechenden Lagerbestandsführung korrigiert. Die Auszeichnung der Waren wird bereits bei der Kooperationszentrale vorgenommen.

Bildschirmtext-gestütztes Warenwirtschaftssystem

125

3.2 Rechnerarchitektur in der Freiwilligen Kette Abbildung 7 gibt einen Überblick über die Rechnerarchitektur in der Freiwilligen Kette.

Abb. 7: Rechnerarchitektur in der Freiwilligen Kette

Wichtigste Einheit in der Kooperationszentrale ist der zentrale Warenwirtschaftsrechner mit der Warenwirtschaftsdatenbank (WWS-DB), in der alle Stamm- und Bewegungsdaten gespeichert sind. Dieser Rechner ist als Externer Rechner für den Btx-Rechnerverbund ausgerüstet und bildet die zentrale Einheit für das Bildschirmtext-gestützte Informations- und Kommunikationssystem. Darüber hinaus kann der Externe Rechner bei Bedarf auch als Btx-Inhouse-Zentrale eingesetzt werden. Um Bildschirmtext-Seiten zu editieren, muß der Rechner über eine Schnittstelle zu einer Bildschirmtext-Station verfügen. Dieser kann aus einer komfortablen Hardwarestation oder aus einem Bildschirmtext-fähigen Mikrocomputer mit Softwareunterstützung bestehen. Ein solches Terminal ist dann auch geeignet, um im öffentlichen Bildschirmtext-Netz einen Teilnehmerbetrieb zu installieren.

126

Bildschirmtext-gestütztes Warenwirtschaftssystem

Die Hardwareausstattung bei den Einzelhändlern besteht im wesentlichen aus zwei getrennten Einheiten. Die Kasse ist das wichtigste Instrument zur Erfassung und Zwischenspeicherung des Warenausgangs im Ladenhandel. Da der Warenausgang artikelgenau nach Menge und Wert erfaßt werden soll, ist es erforderlich, eine Datenkasse einzusetzen. Die bisher im kleinen Lebensmitteleinzelhandel noch verbreiteten Registrierkassen sind dann nicht mehr ausreichend. Ebenso wichtig ist die Ausstattung des Einzelhändlers mit einer Mikrocomputergestützten Btx-Teilnehmerstation. Da die Kooperationszentrale alle Funktionen eines Btx-Anbieters übernimmt, ist eine Teilnehmerstation ausreichend. Um eine Verbindung zwischen den auf einem Datenträger, i. d. R. einer Diskette, gespeicherten Warenausgangsdaten und der Datenübertragung über Btx herzustellen, ist es notwendig, die Btx-Station mit Intelligenz auszurüsten, damit eine redundante manuelle Eingabe der Warenausgangsdaten vermieden werden kann. Der Einsatz intelligenter Datenendgeräte bei den Einzelhändlern ermöglicht dann auch dezentrale Verarbeitungsvorgänge im Sinne des Distributed Data Processing (DDP) [15]. Nach der Modellkonzeption beziehen die Einzelhändler alle Waren vom Großhändler der Freiwilligen Kette. Die Abwicklung der Warenbeschaffung von verschiedenen Lieferanten kann unter Mitbenutzung des Externen Rechners der Kooperationszentrale erfolgen. Damit steht auch dem Großhändler ein Zugang zum Bildschirmtextsystem zur Verfügung. Der Großhändler kann dazu über einen Inhouse-Anschluß Zugang zum System erhalten.

4 Implementierungsstrategie 4.1 Hard- und Softwarekomponenten Bei der Implementierung des Softwareprototypen wurden die warenwirtschaftlichen Funktionen sowie die Warenwirtschaftsdatenbank und die B tx-Programme zunächst als eigenständige Teilmoduln programmiert und in einem weiteren Arbeitsschritt unter Berücksichtigung des Externen Rechnereinsatzes miteinander verbunden. Zur Abbildung Act Funktionen der Kooperationszentrale wird ein Externer Rechner online am Bildschinntextsystem der Deutschen Bundespost betrieben. Dazu steht ein IBM PC AT 02 zur Verfügung, der mit folgenden Komponenten ausgerüstet ist: 1. der PCOM-Karte: Sie besteht aus einer Einsteckkarte mit einem 80186-Prozessor, der über 256 KB Hauptspeicher verfügt Aufgabe der PCOM-Karte ist die softwaremäßige Bear-

Bildschirm text-gestütztes Warenwirtschaftssystem

127

beitung der Einheitlichen Höheren Kommunikationsprotokolle der Schichten 4 - 7 (EHKP 4 - 7) im Sinne des ISO/OSI-Referenzmodells. Eine weitere Aufgabe besteht darin, die X.25-Schnittstelle für den Datex-P-Anschluß des Externen Rechners zur Verfügung zu stellen. 2.

dem Software-Paket

BTGATE [16]:

Es stellt eine intelligente I/O-Routine, die mit Hilfe einer Schnittstelle zur höheren Programmiersprache C angeboten wird, zur Verfügung. Das eigentliche Anwendungssteuerungsprogramm, welches den Datenaustausch aus BtxSeiten und einem Anwendungsprogramm oder einer Datenbank wahrnimmt, ist frei in "Lattice-C" programmierbar. Ein lauffähiges Programm besteht aus den zusammengebundenen Anwendungsprogrammen, dem BTGATE-Modul, dem Anwendungssteuerungsprogramm und einer Btx-Seitendatenbank des Externen Rechners. Zu BTGATE gehört das Unterprogramm BTCOPY, welches die Eingabe und Verwaltung bereits vollständig editierter Btx-Seiten in eine Btx-Seitendatenbank zur Aufgabe hat. Analog zu den Vorschriften der Deutschen Bundespost im Btx-online-Betrieb werden die jeweiligen Seiten in drei Bestandteilen abgespeichert: - Seitenkopfparameter, - Aufbaufelder, - Dialogfelder. Abbildung 8 zeigt die o. g. Konfiguration. Zum Verbindungsaufbau mit dem Datex-P-Netz verfügt das Institut für Wirtschaftsinformatik (IWi) über einen Datex-P-10-Hauptanschluß mit dem entsprechenden Modem für eine Datenübertragungsrate von 2400 bit/s. Als externer Editor, der zur Einrichtung und Aktualisierung der Seitendatenbank des Externen Rechners dient, wird die Btx-Standardsoftware EDITEL/A [17] des Herstellers Cap Gemini eingesetzt Das Softwareprodukt dient dazu, die Btx-Seiten offline zu erstellen und offline zu verwalten. Nach der Erstellung können die Seiten in das Programm BTCOPY unverändert übernommen werden. Zur Nachbildung des Warenwirtschaftssystems auf dem IBM PC AT wird das Datenbanksystem dBase III eingesetzt. Das Standardsoftwarepaket mit eigener Sprache erlaubt die Implementierung der WWS-Datenbank sowie die Implementierung der warenwirtschaftlichen Funktionen.

Bildschirm text-gestütztes Warenwirtschaftssystem

128

Unter Einsatz o. g. Standardkomponenten wird der Softwareprototyp ßr Externen Rechner programmiert

den

BTCOPY Datex-P

Btx-Seitendatenbank

Ebene 1-7 nach ISO/OSI (EHKP4-7)

Steuermodul mit Taskmonitor Fehlerbehandlung

PCOM-Karte mit Software

BTGATE

I Anwendungssteuerung

C-Modul

WWS-Funktionet WWS-Datenbank

d B A S E III

Abb. 8: Konfiguration des Externen Rechners

Zur Abbildung der Vorgänge auf Einzelhändlerebene wird eine Loewe-Editierstation BBT1214 in Verbindung mit einem IBM PC XT verwendet. Zum Verbindungsaufbau wird das Automatikmodem DBT 03 eingesetzt. Zur Unterstützung der Bildschirmtext-Teilnehmer-Funktionen ist auf dem PC XT das Btx-Standardsoftwarepaket ZEIBIT implementiert. Es erlaubt die weitgehende Automatisierung von Routinevorgängen, wie beispielsweise automatische Log-on-Prozeduren, Verwaltung der Mailbox oder Auslesen von Inhalten der Btx-Seiten, und erleichtert somit das Handling des Bildschirmtext-Systems für den Teilnehmer. Um das Konzept des DDP auf Einzelhändlerebene zu verfolgen, müssen für dessen Anwendungen geeignete Standardsoftwareprogramme auf dem PC gehalten werden; ein Beispiel sind Textverarbeitungsprogramme oder Tabellenkalkulationsprogramme. Zur Realisierung der Großhändlerebene wird auf die o. g. Konfigurationen zurückgegriffen. Der Dialog zwischen Btx-Kunden der Einzelhändler und der Kooperationszentrale wird ebenfalls mit denselben simuliert. Als Btx-Monitor sowie Dekoder wird dabei die Loewe-Station BBT 1214 eingesetzt.

Bildschirmtext-gestütztes Warenwirtschaftssystem

129

4.2 Editieren des Btx-Programms Das Bildschirmtext-Programm [18] gliedert sich in zwei Teile: 1. das Programm im öffentlichen System, 2. das Programm im Rahmen der Geschlossenen Benutzergruppe. Das Bildschirmtext-Programm im öffentlichen System übernimmt die Funktionen als Werbeträger (Warenpräsentation) und als Vertriebsweg (Bestellabwicklung) an die Kunden der Facheinzelhändler. Das Bildschirmtext-Programm im Rahmen der Geschlossenen Benutzergruppe (GBG) übernimmt die Funktion eines Datenübertragungsweges im Rahmen des Kommunikations- und Informationssystems für die warenwirtschaftlichen Anwendungen. 4.2.1 Das Programm im öffentlichen System Das Bildschirmtext-Programm im öffentlichen System mit Warenangebot und Bestelldialog für die Bildschirmtext-Kunden der Facheinzelhändler wird unter folgenden Gesichtspunkten entworfen: -

Graphische Ausgestaltung (Werbewirksamkeit), Akzeptanz bei den Teilnehmern, Optimierung der Datenübertragungskosten, Optimierung der Seiteninhalte (Datenübertragungsgeschwindigkeit).

Es ist festzulegen, welche Anwendungen im Rechnerverbund ablaufen und welche über die öffentliche Bildschirmtext-Datenbank abgewickelt werden. Neben der inhaltlichen Ausgestaltung einzelner Bildschirmtext-Seiten spielt die Strukturierung des gesamten Programms eine wichtige Rolle. Unter Strukturierung ist die logische Verknüpfung der Bildschirmtext-Seiten miteinander zu verstehen. Der strukturelle Aufbau des Bildschirmtext-Programms orientiert sich an folgenden Prämissen: - Die Vorgaben der Deutschen Bundespost werden strikt befolgt. - Das Programm soll möglichst selbsterläuternd sein, um neuen Kunden den Weg zur Warenbestellung über Bildschirmtext zu erleichtern. - Das Programm soll für Bildschirmtext-erfahrene Kunden einen schnellen Weg zur Bestellung anbieten. - Die Anwendungen mit Dialog- und Verarbeitungscharakter werden vom Externen Rechner der Freiwilligen Kette abgearbeitet

130

Bildschirm text-gestütztes Warenwirtschaftssystem

Abbildung 9 zeigt die formale und inhaltliche Struktur des Bildschirmtextprogramms.

Abb. 9: Programmstruktur im öffentlichen System

4.2.2 Das Bildschirmtext-Programm für die Geschlossene Benutzergruppe Im Gegensatz zum Bildschirmtext-Programm im öffentlichen System orientiert sich das Programm für die Geschlossene Benutzergruppe strikt an den Anforderungen der einfachen und zielorientierten Abwicklung der Anwendungen und an der damit verbundenen Kosten- und Zeitoptimierung. Die in das öffentliche Programm integrierten absatzpolitischen Instrumente treten in den Hintergrund. Das Programm beinhaltet die Kommunikations- und Verarbeitungsstrukturen für die warenwirtschaftlichen Anwendungen, die die Kooperationszentrale mit den Einzelhändlern der Freiwilligen Kette abwickelt. Inhaltlich besteht das Programm aus folgenden Programmteilen: -

Bestelldisposition, Frischwarendisposition, Nachdisposition, Warenausgangsmeldungen, Wareneingang abrufen/melden, Finanzbuchführung für Einzelhändler, Abruf von Kundenaufträgen, Lagerbestandsabfragen und Inventurabwicklung, Auswertungen im Rahmen eines Marketing- und Managementinformationssystems.

Bildschirmtext-gestütztes Warenwirtschaftssystem

131

Der Zugang in das Programm für die Geschlossene Benutzergruppe erfolgt über eine Gatewayseite, die die Übergabefunktion zwischen der Bildschirmtext-Zentrale und dem Externen Rechner übernimmt Um in das Programm der Geschlossenen Benutzergruppe zu gelangen, wird eine weitere Prüfung der Zugangsberechtigung durch den Externen Rechner durchgeführt. 4.3 Integration der Programmteile Die Integration der getrennt erstellten Programmteile, dem verteilten Warenwirtschaftssystem für die Freiwillige Kette sowie der Bildschirmtext-Programme erfolgt über den Rechnerverbund (Externer Rechner) bzw. über die Schnittstelle zum öffentlichen Btx-System. Die Bildschirmtext-Programme haben dabei zwei Funktionen: 1. Die Informationsseiten aus der öffentlichen Btx-Datenbank haben absatzpolitische Aufgaben. 2.

Die Dialogseiten haben die Aufgabe, eine kostengünstige und benutzerfreundliche Oberfläche für die dezentralen Einheiten anzubieten, die auf die zentralen warenwirtschaftlichen Leistungen zugreifen möchten (Konzept des Distributed Data Processing).

Der zu entwickelnde Softwarerahmen, der die verschiedenen Programmteile integriert, ist daher als Softwarehandler zu verstehen, der den logischen und physischen Ablauf der Aufrufe und des Datenaustauschs für die einzelnen Unterprogramme steuert. Voraussetzung hierfür sind einheitliche Datenstrukturen in allen Unterprogrammen sowie eine Kompatibilität der Softwarepakete untereinander.

Anmerkungen [1] [2] [3] [4] [5] [6] [7] [8]

Vgl. Tietz (1980), S. 255. Vgl. Tietz (1979), S. 59. Vgl. Schmidt-Prestin (1986), S. 132. Vgl. Tietz (1978), S. 37. Vgl. Zentes (1988), S. 59; vgl. auch Leismann (1986), S. 185 f. Vgl. Kirchner (1984), S. 71. Vgl. Zentes (1983), o.S. Vgl. Kragler (1987), Teil 3,3.2.1 ff.; vgl. auch Meyer (1988), Teil II, S. 10 ff.; vgl. auch Danke (1985), S. 11 ff.

132

Bildschirmtext-gestütztes Warenwirtschaftssystem

[9] Vgl. o.V. (1988), S. 21. [10] Vgl. Seibt (1985), S. 5. [11] Vgl. Scheer (1988b), S. 596 ff. [12] Vgl. ebenda, S. 596 ff. [13] Vgl. Langen (1986), S. 20 ff. und S. 94 ff; vgl. auch Eder (1983), S. 62 ff.; vgl. auch Maciejewski (1985), S. 95 ff.; vgl. auch o.V. (1987), S. 35 ff. [14] Vgl. Kragler (1987), Teil 9,9.3 ff.; vgl. auch Gerhard (1983), S. 8 ff.; vgl. auch Döring (1983), S. 103 ff. [15] Vgl. Scheer (1988a), S. 77 ff.; vgl. auch Bauer (1987), S. 49. [16] Vgl. dazu o.V. (1986), o.S. [17] Vgl. dazu o.V., o.J. u. o.S. [18] Vgl. Meyer (1988), Teil IV, S. 67 ff.

Literatur Bauer, M.: Die Kunst, Daten zu verteilen und nicht zu verstreuen; Computerwoche extra, 1. Mai 1987, S. 48-52. Danke, E.: Der Bildschirmtextdienst der Deutschen Bundespost; net-special, April 1985, S. 11-19. Döring, J.: Konzepte des Rechnerverbunds und ihre Realisierung; in: Diebold (Hrsg.); Btx-Kongreß Proceedings; Frankfurt 1983, S. 91-114. Eder, T.: Bildschirmtext als betriebliches Informations- und Kommunikationssystem, Heidelberg 1983. Gerhard, W.: Realisierung von Btx über das Datex-P-Netz der Deutschen Bundespost; Vortrag anläßlich des IBM Btx-Kongresses 1983, gehalten am 30. November 1983. Kirchner, J.D., Zentes, J. (Hrsg.): Führen mit Warenwirtschaftssystemen; Düsseldorf, Frankfurt 1984. Kragler, P.: Bildschirmtext-Handbuch; 12. Nachl., 1987. Langen, B. et al.: Datenübertragungskosten in Wählnetzen der Deutschen Bundespost, Heidelberg 1986. Leismann, U.: Warenwirtschaft; Informatik Spektrum 9 (1986) 4, S. 185-186. Maciejewski, P. et al.: Bildschirmtext-Inhouse-Systeme; Bad Wörishofen 1985. Meyer, W. et al.: Bildschirmtext und seine Anwendung; 9. Ergänzungslieferung; Stand: 1. Mai 1988. o. V.: EDITEL/A; Stand: 3.2.1986. o. V.: Bis zu 85 Prozent Gebühren sparen; Btx-Praxis o.Jg. (1987) 10, S. 35-38. o. V.: Daten jeder Art; Btx-Praxis o.Jg. (1988) 9, S. 21. o. V.: Btx-Rechnerverbund mit Kommunikations-PC BTGATE; Version 3.1., o.J. Scheer, A.-W.: CIM - Der computergesteuerte Industriebetrieb, 3. Auflage; Berlin et al. 1988a.

Bildschirmtext-gestütztes Warenwirtschaftssystem

133

Scheer, A.-W.: Wirtschaftsinformatik - Informationssysteme im Industriebetrieb, 2. Auflage; Berlin et al. 1988b. Schmidt-Prestin, B.: Bildschirmtext im Unternehmen; Bergisch Gladbach, Köln 1986. Seibt, D. et al.: Nutzungspotentiale und Grundtypen von Btx-gestützten betrieblichen Informationssystemen (BTXIS); net-special, April 1985, S. 4-9. Tietz, B.: Kooperation - Aktivstrategie im Marketing; Marketing (ZFP), 1 (1979) 1, S. 59-63. Tietz, B.: Marketing, 2. Auflage; Tübingen, Düsseldorf 1978. Tietz, B.: Strategien zur Unternehmensprofilierung; Marketing (ZFP), 2 (1980) 4, S. 251-259. Zentes, J.: Konzeption und Aufbau integrierter Warenwirtschaftssysteme I; in: Sammelband der Referate des GDI-Seminars "Integrierte Warenwirtschaftssysteme"; Rüschlikon/Zürich 1983. Zentes, J.: Nutzeffekte von Warenwirtschaftssystemen im Handel; Information Management, 3 (1988) 4 , S. 58-67.

Strukturanalyse von Planungsmodellen Eckart Zwicker, Andreas Pleger

Inhalt 1 Vorbemerkung 2 Aufbau von Planungssystemen zur computergestützten Unternehmensplanung 3 Modellstrukturanalyse von Planungsmodellen 3.1 Ermittlung von reduzierten Gleichungen 3.2 Durchführung von Kausalkettenanalysen 4 Realisierung der Modellstrukturanalyse 4.1 Kausalkettenanalyse 4.2 Gleichungsreduktion 4.2.1 Steuerung durch den Benutzer 4.2.2 Zum Begriff eines vereinfachten reduzierten Terms 4.2.3 Erzeugung der vereinfachten reduzierten Gleichung 4.2.4 Der Simple-Precedence-Algorithmus und die Reduktion 4.2.5 Die symbolischen Rechenroutinen 5 Ausblick Anmerkungen Literatur

1 Vorbemerkung Der folgende Beitrag resultiert aus einem von der Deutschen Forschungsgemeinschaft im Rahmen des Forschungsschwerpunktes 'Interaktive betriebswirtschaftliche Informations- und Steuerungssysteme' geförderten Projektes. Ziel dieses Projektes war die Strukturanalyse von Planungsmodellen. Die hier beschriebenen Ergebnisse decken sich weitgehend mit dem Projektziel: es sollte die Möglichkeit eröffnet werden, im Rahmen von Planungsmodellen auf interaktive Weise die sogenannte reduzierte Gleichung einer Modellvariablen zu ermitteln. Dieses Verfahren ist anhand von Beispielen im folgenden beschrieben. Der zweite Teil des Forschungsprojektes zielt darauf ab, sogenannte interaktive Kausalkettenanalysen auf der Grundlage bestimmter Planungsmodelle vorzunehmen. Der vorliegende Beitrag beschreibt nur einen Teil dieses Projektes: es werden sukzessive Kausalkettenanalysen behandelt. Dies ist ein Verfahren, bei welchem der Benutzer im Dialog festzulegen hat, welche Folge von Variablenbeziehungen eines Modelles untersucht

136

Strukturanalyse von Planungsmodellen

werden sollen. Die im Rahmen des Projektes zu realisierende Kausalkettenanalyse sämtlicher Modellbeziehungen in einem umfassenden Kausaldiagramm wird im folgenden nicht beschrieben.

2 Aufbau von Planungssystemen zur computergestützten Unternehmensplanung Die Budget- und Finanzplanung von Unternehmen wird heute vorwiegend mit Hilfe von computergestützten Planungssystemen betrieben. Der Aufbau solcher Systeme ist in Abbildung 1 beschrieben.

Abb. 1: Aufbau computergestützter Planungssysteme

Das Benutzer-Schnittstellensystem teilt dem Steuerungssystem die Systemeingaben mit und erhält von diesem die Systemausgaben. Das Steuerungssystem ruft das Analysesystem auf, welches mit der Datenbank und dem Modellsystem kommuniziert. Das Analysesystem dient dazu, die Implikationen des im Modellsystem niedergelegten Planungsmodelles zu ermitteln. Auch kann mit Hilfe des Analysesystems das Modell unter normativen Fragestellungen analysiert werden. Das Metainformationssystem sammelt und liefert Informationen über den Prozeßablauf. Das Modellsystem enthält das eigentliche Planungsmodell. Es besteht aus einem System von Differenzengleichungen und algebraischen Gleichungen. Dieses Modellsystem dient, nachdem es entwickelt wurde, zwei Aufgaben: - der Berechnung bestimmter Modellalternativen, - der Modellstrukturanalyse.

Strukturanalyse von Planungsmodellen

137

Die Berechnung bestimmter Modellalternativen ist die Hauptaufgabe jedes Planungssystems. Sie wird von dem Analysesystem durchgeführt und besteht in der Bestimmung der Werte der endogenen Modellvariablen unter Vorgabe bestimmter numerischer Werte der Basisgrößen. Solche Modellberechnungen finden während der einzelnen Phasen eines Planungsprozesses statt. Sie bilden die Grundlage für Bottom-Up- und Top-Down-Rechnungen oder auch für die Berechnungen von Variatoren, sowie für Sensitivitäts- und Break-Evenanalysen. Die Modellstrukturanalyse ist ebenfalls eine Aufgabe des Analysesystems. Sie dient dazu, dem Benutzer Einsichten über den strukturellen Aufbau des Modelles zu vermitteln. Die Modellstrukturanalyse bleibt aber, wie sich später zeigen wird, nicht nur auf der Ebene einer reinen Aufweisung struktureller Zusammenhänge stehen. Es werden unter Umständen auch bestimmte Rechnungen durchgeführt Solche Strukturanalysen fehlen weitgehend bei den heute in der Praxis gebräuchlichen kommerziellen Planungssystemen. Im folgenden sollen zwei Verfahren der Modellstrukturanalyse anhand von jeweils einem Beispiel beschrieben werden. Es handelt sich um die Ermittlung von sogenannten reduzierten Gleichungen und die Durchführung von Kausalkettenanalysen. Diese beiden Formen einer Modellstrukturanalyse sind im Rahmen eines Planungssystems mit dem Namen INZPLA (Inkrementale Zielplanung) eingebettet [1]. Die in diesem System praktizierte Planungsprozedur soll im folgenden kurz beschrieben werden, um zu erkennen, wie die später behandelte Modellstrukturanalyse in dieses Planungssystem integriert wird. Das INZPLA-System geht von einem Planungskonzept aus, welches als eine Konkretisierung des sogenannten Management durch Zielvorgabe angesehen werden kann. Es wird zwischen bestimmten Top- und Basiszielen unterschieden. Die Topziele sind die Ziele, die von der Unternehmensleitung angestrebt werden, wie beispielsweise die Eigenkapitalrentabilität oder die Umsatzrentabilität. Die Basisziele sind die Ziele, für welche bestimmte Bereiche verantwortlich gemacht werden können. Ein inkrementales Zielplanungsmodell ist ein Modell, in welchem diese Basisziele mit den Topzielen verbunden werden. Abbildung 2 zeigt die schematische Darstellung eines Beispielmodelles, auf das im folgenden zurückgegriffen wird.

138

Strukturanalyse von Planungsmodellen

TO P Z I EL E Eigerücapitalrentabilität

Kassenbestand

Cash-Flow/ Verbindlk. - Änderung Bankverb. - Abschreibung_Anlagen - Multiplikator Fertigprod.

INKREMENTALES ZIELPLANUNGSMODELL

- Multiplikator Rchstoffe

( 44 Gleichungen ) . Tilgungsquote RücXl age_Gevinnauss. - IXirchschnittszinssatz

Anlagen- Lohnkauf Kostensatz

Verkaufs- Absatzpreis menge

LöhneEinstandsGehálter- preisMaterialw. Rohstoffe

FixeLrhn und Gehaltskosten

I¿hneLagerGehálter- uaschlag Absatz Fertigprod

LagerUmschlag Rohstoffe

Fertigung

Absatz

Materialwirtschaft

Zahlungs- LShneeingangs- Gehälterrelation Finanzen

Finanzen

IASISZIELE

Abb. 2: Beispiel eines inkrementalen Zielplanungsmodelles

Es existieren vier Verantwortungsbereiche, deren insgesamt 12 Basisziele im einzelnen angeführt sind. Darüber hinaus enthält das Modell 5 Basisgrößen, die keine Basisziele sind. Ihre Werte sind als Schätzwerte vorzugeben. Der Planung liegen 3 Topziele zu Grunde. Die Planung vollzieht sich in drei Stufen: der Bottom-Up-Planung, der Top-DownPlanung und der Bottom-Up-Top-Down-Konfrontation. Während der Bottom-Up-Planung werden diefreiwilligen Basiszielverpflichtungen der Verantwortungsbereiche zu den Topzielwerten hochgerechnet. Die Top-DownPlanung gliedert sich in zwei Schritte: Im ersten Schritt versucht die Unternehmensleitung, auf der Basis der Bottom-Up-Rechnung bestimmte Forderungen bezüglich der wünschenswerten Topziele zu formulieren. Auf dieser Grundlage bemüht sich die Unternehmensleitung (vertreten durch den Controller), Basiszielkombinationen zu finden, die die gewünschten Topziele realisieren.

139

Strukturanalyse von Planungsmodellen

Während der Bottom-Up-Top-Down-Konfrontation wird zwischen der Unternehmensleitung und der Bereichsleitung über die letztlich zu realisierenden Basisziele verhandelt Bottom-Up-Top-Do*n-Konfrontat ion Teilschritt: Verantw.-bereich: 3 ABSATZ Verantwortlich: SCHULZE

1985 11.70

a s i s z i e l

Einh.

LOEHNE_GEHAELTER_ABSATZ ABSATZMENGE DURCHSCHN_VERKAUFSPREIS LAGERUMSCHLAG_FERTIGPRODUKTE

DM Stück DM 1/Jahr

BZ-Wert 396 1000 11.50 12.35

EIGENKAPITALRENTAB. S B B S

-0.6510 7.4243 IS.9048 -0.2985

200 KASSENBESTAND S B B B

-1.9800 12.7338 53.9692 3.1405

17.32 CASHFLOW/ VERBINDLICHKEITEN S B B S

-0.2190 2.4840 6.3595 -0.0994

Abb. 3: Beispiel eines Konfrontationstableaus

Abbildung 3 zeigt ein sogenanntes Konfrontationstableau des erwähnten Modelles für den Verantwortungsbereich Absatz. Es wird während der Bottom-Up-TopDown-Konfrontation verwendet. Die Spalte 'BZ-Wert* enthält die gerade zur Diskussion stehenden Werte der Basisziele des Absatzbereiches. Die Spalten des Konfrontationstableaus korrespondieren mit den Topzielen, die durch die Eigenkapitalrentabilität, den Kassenbestand und das Verhältnis CashFlow zu Verbindlichkeiten repräsentiert werden. Die numerischen Werte in den Matrizenfeldern repräsentieren sogenannte Variatoren. Sie zeigen, um wieviel Prozent sich der Wert des betreffenden Topzieles ändert, wenn der Wert des Basiszieles um ein Prozent erhöht wird. Im Falle der Absatzmenge beispielsweise beträgtderVariatorwert bezüglich der Eigenkapitalrentabilität 7,4 Prozent Diese Situation kann, wie später gezeigt wird, den Ausgangspunkt für eine Strukturanalyse bilden.

140

Strukturanalyse von Planungsmodellen

3 Modellstrukturanalyse von Planungsmodellen Im folgenden werden die bereits erwähnten Verfahren der Strukturanalyse, d.h. die Ermittlung von reduzierten Gleichungen und die Durchführung von Kausalkettenanalysen erläutert und anhand des beschriebenen Modelles illustriert. 3.1 Ermittlung von reduzierten Gleichungen Wir beschäftigen uns, wie erwähnt, nur mit Planungssystemen, die sich durch Differenzengleichungen und algebraische Gleichungen beschreiben lassen. Diese Gleichungssysteme beschreiben bestimmte endogene Variable, wie den Gewinn oder die Eigenkapitalrentabilität. Die Erklärungsgleichungen solcher Topzielvariablen enthalten praktisch nie Modellbasisgrößen als erklärende Variable. Vielmehr werden die interessierenden Variablen zumeist nur über verschiedene Zwischenvariable von den Basisgrößen eines Modelles beeinflußt. Es lassen sich Modelle finden, in welchen solche Abhängigkeiten über mehr als 30 Stufen von Zwischenvariablen laufen. Um einen Eindruck von der Verknüpfungsstärke solcher Modelle zu geben, ist in Abbildung 4 das Kausaldiagramm eines bestimmten Verantwortungsbereiches (der Montage) in einem Industrieunternehmen angeführt. Die Verknüpfung der Variablen in diesem Subsystem erfolgt über maximal 7 Stufen. Ein Verfahren der Komplexitätsreduzierung für solche mehrstufigen Planungsmodelle besteht in der Ermittlung der reduzierten Gleichung einer Variablen. In diesem Fall versucht man, durch entsprechende algebraische Umformungen die interessierende Variable als Funktion der sie beeinflussenden Basisgrößen zu formulieren. Das Verfahren sei an einem einfachen Beispiel beschrieben. Wir gehen von dem folgenden Gleichungssystem aus

G G U K

= -

U - K Gewinn Umsatz Kosten

(1)

U = P * M P - Preis M - Menge

(2)

K = FK + VSTK * M FK - Fixe Kosten VSTK - Variable Stückkosten

(3)

141

Strukturanalyse von Planungsmodellen

\

BRSOVA

SOOSf WLlYSf

/>RNZU

a7UHT0

| flEZUU [

|POrztAI |

I AßUMTO

|ttfCK«|

|

\iB*JL>N

Abb. 4: Kausaldiagramm der Abhängigkeiten zwischen den Variablen eines Planungsmodelles im Verantwortungsbereich Montage (Variablen im Rechteck)

Die sogenannte vollsymbolische reduzierte Gleichung des Gewinnes G erhält man durch Einsetzen von (3) und (2) in (1), d.h. G = P * M - F K -

VSTK * M

(4)

Man kann verschiedene Formen einer reduzierten Gleichung unterscheiden. Eine vollsymbolisch reduzierte Gleichung beschreibt das obige Beispiel: sämtliche Basisgrößen sind symbolisch dargestellt. Bei einer nicht vollsymbolisch reduzierten Gleichung sind für bestimmte Basisgrößen numerische Werte eingesetzt. Wählt man beispielsweise im obigen Beispiel FK = 1000 und VSTK = 5, dann erhält man die nicht vollsymbolisch reduzierte Gleichung G = P * M - 1000 - 5 * M

(5)

Beide Formen sind im Rahmen einer Strukturanalyse von Interesse. Der Extremfall einer teilsymbolischen Gleichung liegt vor, wenn alle Basisgrößen numerisch

142

Strukturanalyse von Planungsmodellen

spezifiziert sind. Die Ermittlung der reduzierten Gleichung einer Variablen V würde dann zu dem Ergebnis V = 'numerischer Wert' führen. Bevor der Reduktionsprozeß an einem Beispiel demonstriert wird, soll kurz auf die Voraussetzung eingegangen werden, unter der ein solcher Prozeß ablaufen kann. Sie besteht darin, daß es sich bei dem vorliegenden Gleichungssystem um ein rekursives System handelt. Dies bedeutet, daß es möglich sein muß, die Gleichungen in einer prozeduralen Form anzuordnen [2]. Dies ist bei sogenannten simultanen Modellen gerade nicht der Fall. Modelle, welche daher simultane Subsysteme enthalten, gestatten keine Ermittlung der reduzierten Gleichung einer Variablen, wenn sich eine der Zwischenvariablen in einem simultanen Gleichungssystem befindet. Liegen solche Umstände nicht vor, dann kann die reduzierte Gleichung der deklarierten Variablen durch einen Prozeß gewonnen werden, bei welchem die erklärenden Variablen der Erklärungsgleichung sukzessiv durch die sie erklärenden Ausdrücke ersetzt werden. Die entstehenden komplexen algebraischen Ausdrücke sind dabei durch algebraische Umformung so einfach wie möglich zu gestalten [3]. Wenn die Erklärungsgleichungen der Zwischenvariablen auch nichtalgebraische Funktionen besitzen, was viele Planungssprachen zulassen, dann kann in diesem Fall keine vollständige Reduktion vorgenommen werden. Tritt bei der Reduktion beispielsweise eine Minimumsfunktion mit zwei Argumenten auf, dann erhält man als reduzierte Gleichung den Ausdruck RV = MIN (A, B) wobei A und B reduzierte algebraische Ausdrücke bilden. Entsprechendes gilt beispielsweise auch für Maximums- oder IF-THEN-ELSE-Funktionen. Wir wenden uns nunmehr dem anfänglich beschriebenen Beispielmodell zu und gehen davon aus, daß wir uns im Planungsprozeß der Bottom-Up-Top-DownPlanung befinden. Ausgangspunkt ist das Konfrontationstableau der Abbildung 3. Der Benutzer ist an der Verknüpfung der Absatzmenge mit der Eigenkapitalrentabilität interessiert. Er erfährt anhand der Konfrontationstabelle, daß der Variator 7,42 Prozent beträgt. Er hat nunmehr die Möglichkeit, die tatsächliche funktionale Verknüpfung durch das System ermitteln zu lassen. Vorab erhält der Benutzer, wie in Abbildung 5 dargestellt, eine Information über den Gliederungsbaum, welcher der Reduktion zu Grunde liegt.

143

Strukturanalyse von Planungsmodellen

MODELLSTRUKTURANALYSE - Spezifikation der Reduktionstiefe Planungsphase:BUJV Zu reduzierende Größe

Modell :ZIEH0D4 Planjahr:1985

EIGENKAPITALRENTABILITAET

Anzahl der Ebenen von Zvischengrößen , Ober die die Basisgrößen in diese Größe eingehen :

7

Anzahl der Größen, die bei der angegebenen Reduktionstiefe bearbeitet «Orden

34

Anzahl der erkürenden Größen, als deren Funktion die Größe dargestellt würde

16

Abb. 5: Übersicht zum Aufbau des Gliederungsbaumes der Reduktion

Der Reduktionsprozeß verläuft über 7 Stufen eines Gliederungsbaumes. Bei der Reduktion werden insgesamt 34 endogene Variable als erklärende Variable (Stufe für Stufe) ineinander eingesetzt. Die Zahl der Basisgrößen, welche die Eigenkapitalrentabilität beeinflussen, beträgt 16. Bis auf die Absatzmenge werden die übrigen 15 Basisgrößen numerisch konkretisiert. Die sich ergebende reduzierte Gleichung zeigt Abbildung 6. Man erkennt, daß es sich um eine relativ komplizierte Gleichung handelt. Ein direkter Erkenntniszuwachs des Benutzers ist nur insoweit gegeben, als ihn die Kompliziertheit der Verknüpfung überraschen wird. Diese Komplexität ist darauf zurückzuführen, daß das vorliegende Modell ein sogenanntes absatzgetriebenes Modell ist, d.h. ein Modell in welchem sehr viele Modellgrößen in den verschiedensten Bereichen als eine Funktion der Absatzmenge geplant werden. Als zweites Beispiel zur Berechnung einer reduzierten Gleichung soll wiederum die Eigenkapitalrentabilität als Referenzvariable gewählt werden. Als symbolisierte Basisgröße werden dagegen die Basisziele des Fertigungsbereiches gewählt. Aus Abbildung 2 ist zu erkennen, daß es sich um drei Basisziele handelt

144

Strukturanalyse von Planungsmodellen

MODELLSTRUKTURANALYSE - Reduzierte Form der Gleichung Planungsphase:BUJV

Modell :ZIEMOD4 Planjähr:1985

Reduzierte Modellgleichung EIGENKAPITALRENTABILITAET = (-31177210 +0.114692*A8SATZMENGE"4 -111.7433*ABSATZMENGE"3 +10544.35*ABSATZMENGE"2 +202485.2*ABSATZMENGE ) / (1.377363*ABSATZMENGE'3-217.9203* ABS ATZMENGE'2+8619.598*ABSATZMENGE)

Abb. 6: Ermittlung der reduzierten Gleichung der Eigenkapitalrentabilität in einem Planungsmodell. Einzige symbolisierte Basisgröße ist die Absatzmenge (VAR A X = VAR X )

MODELLSTRUKTURANALYSE - Reduzierte Form der Gleichung Planungsphase:BUJV

Modell :ZIEMOD4 Planjahr:1985

Reduzierte Modellgleichung EIGENKAPITALRENTABILITAET = 31.72648-0.019273*FIXE_LOHN UND_GEHALTSKOSTEN-19.22717*LOHNKOSTENSATZ

Abb. 7: Ermittlung der reduzierten Gleichung der Eigenkapitalrentabilität in einem Planungsmodell. Symbolisierte Basisgrößen sind die Basisziele des Verantwortungsbereiches Fertigung

145

Strukturanalyse von Planungsmodellen

Hier ist der Einfluß der Basisziele auf die Eigenkapitalrentabilität schon klar zu erkennen [4], Die Erhöhung der fixen Lohn- und Gehaltskosten vermindert die Eigenkapitalrentabilität mit einem Faktor von 0,02, und der Lohnkostensatz der Fertigung wirkt sich mit einem beachtlich hohen Faktor von 19,23 aus. 3.2 Durchführung von Kausalkettenanalysen Wie bereits erwähnt, werden bestimmte interessierende Variable nicht direkt von den Basisgrößen des Modelles beeinflußt. In ihre Erklärungsgleichungen gehen vielmehr bestimmte endogene Modellvariable ein, die wiederum von anderen Modellvariablen beeinflußt werden. Im Rahmen einer Kausalkettenanalyse ist es möglich, diese Verknüpfungen zwischen den Variablen zu verfolgen. Ein Benutzer kann daran interessiert sein zu erfahren, in welche Erklärungsgleichung einer endogenen Variablen eine Referenzvariable als erklärende Variable eingeht. Ebenso kann er daran interessiert sein zu erfahren, welche Variablen als erklärende Variablen in der Erklärungsgleichung dieser Referenzvariablen auftreten. Deklariert er beispielsweise das Topziel Eigenkapitalrentabilität als Referenzvariable, dann erhält er im Rahmen der Kausalkettenanalyse eine Ausgabe, die in Abbildung 8 wiedergegeben ist. MODELLSTRUKTURANALYSE - Kausalbaua

Planungsphase:BUJV

Modell :ZIEK0D4 Planjahr:1985

GEVINN_VERLUST EIGENKAPITAL EIGENKAPITALRENTABILITAET Ebene: 14

-[Erkllrungsgrößen]-

-[Erkürte Größen].

Abb. 8: Kausalkettenanalyse der Variable 'EIGENKAPITALRENTABILITÄT' in einem Planungsmodell

Strukturanalyse von Planungsmodellen

146

Die Eigenkapitalrentabilität fungiert, wie sich zeigt, in keinem Fall als erklärende Variable einer anderen Variable. In ihre Erklärungsgleichung aber gehen der Gewinn und Verlust, sowie das Eigenkapital als Erklärungsgrößen ein. Wir wollen annehmen, daß der Benutzer mit Hilfe eines Lichtbalkens den Gewinn und Verlust als nächste Referenzgröße deklariert In diesem Falle erhält man Abbildung 9. MODELLSTRUKTURANALYSE - Kausalbaua

UMSATZ AENDERUHG LAGERBEST FERTIGPRO ABSCHREIBUNG JUILAGEN LOEHNE GEHAELTER_GESAHT VERBRAUCH VON ROHSTOFFEN ZAHLUNG VON BANKZINSES

Planungsphase:BUJV

GEVINN VERLUST

Modell :ZIEMOD4 Planjahr:1985

UMSATZRENTABILITAET CASH_FLOti EIGENKAPITALRENTABILITAET ROI > OFFENE RUECKLAGEN

Ebene: 13

-TErklirunasaröSenl-

-[Erkürte GröSenl-

Abb. 9: Kausalkettenanalyse der Variable 'GEWINN VERLUST' in einem Planungsmodell

Die Kausalkettenanalyse einer Variablen wird durch eine 'Gleichungserklärung' ergänzt. Diese besteht darin, daß dem Benutzer die Erklärungsgleichung der betreffenden Variablen ausgegeben wird, sowie die numerischen Werte, die Variablenerklärung (Langnamen) und die Einheiten der auftretenden Variablen. Abbildung 10 zeigt die 'Gleichungserklärung' für die Variable Gewinn und Verlust.

Strukturanalyse von Planungsmodellen

MODELLSTRUKTURANALYSE - Detailinformation

Name -[Erklärte Größe]GEWINN_VERLUST [Erklärende Gröjlen]UMSATZ AENDERUNG LAGERBEST FERTIGPRO

147

Planungsphase:BUJW Langname

GEHINN VERLUST UMSATZ AENDERUNG LAGERBEST FERTIGPRO

Modell :ZIEM0D4 Planjahr:1985 Wert

Einheit

607.61

DM

11500.00 -21.53

DM DM

Modellgleichung GEVINN VERLUST.J-UHSATZ.J+AENDERUNG_LAGERBEST_FERTIGPRO.J- & ABSCHREIBUNG_ANLAGEN.J-LOEHNE_GEHAELTER_GESAMT.J- £ VERBRAUCH VON ROHSTOFFEN.J-ZAHLUNG VON BANKZINSEN.J

Abb. 10: Gleichungserkläiung der Variable 'GEWINN.VERLUST' in einem Planungsmodell

In dem Feld Erklärende Größen stehen nur zwei Zeilen für die Kennzeichnung von zwei erklärenden Modellgrößen zur Verfügung. Im vorliegenden Beispiel gibt es aber sechs erklärende Modellgrößen. Diese können aber durch Rollen in das Feld Erklärende Größen eingespielt werden. Das beschriebene Verfahren bietet dem Modellbenutzer die Möglichkeit, die Variablenbeziehungen komplexer Modelle zu durchwandern, um auf diese Weise Informationen über die Verknüpfungsweise und Einflußstärke der Variablen zu erhalten.

4 Realisierung der Modellstrukturanalyse Das Gesamtsystem zur Modellstrukturanalyse gliedert sich in zwei Teilsysteme: die Gleichungsreduktion und die Kausalkettenanalyse. Für beide Aufgaben benötigt das System detaillierte Informationen über die Größen des Modelles und deren algebraische Zusammenhänge. Diese Informationen werden aus den internen Strukturen des Modell-Precompilers gewonnen. Es wird also nicht unmittelbar auf die vom Benutzer - in der Planungssprache des INZPLA-Systems formulierten Gleichungen zurückgegriffen, sondern der Precompiler des INZPLASystems führt zunächst eine Syntax-, sowie eineKontextanalyse durch und überführt

148

Strukturanalyse von Planungsmodellen

das Modell in eine Baumstruktur [5]. Diese Baum struktur dient als Grundlage für die Routinen der Gleichungsreduktion und die Kausalkettenanalyse. Für die Kausalkettenanalyse werden optional einige System-Dateien benötigt; sie liefern zusätzliche Informationen über die Modellgrößen z.B. deren Einheiten und Klassifikationen. Wurde das Modell bereits durchgerechnet, so ist es in beiden Teilsystemen möglich, gezielt auf die Werte einer bestimmten Planungsperiode und -phase zuzugreifen. 4.1 Kausalkettenanalyse Die Kausalkettenanalyse besteht aus zwei Teilschritten. Zunächst werden die Modellgrößen bestimmten Ebenen zugeordnet. Alsdann erhält der Benutzer die Möglichkeit, über den so gebildeten Kausalbaum zu traversieren. Grundlage beider Teilschritte ist die Erstellung zweier Listen, die jeweils eine Richtung der Kausalzusammenhänge abbilden. Diese beiden Listen werden durch sequentielles Abarbeiten aller Modellgleichungen erzeugt. Sie liefern auch die Basis für die Traversion über die Kausalstruktur, wobei Zusatzinformationen aus Systemdateien eingespielt werden. Bei der Berechnung der Ebenen wird für jede Modellgröße, die von keiner anderen Modellgröße abhängt, also für alle exogenen Modellgrößen, eine rekursive Routine aufgerufen, die die von ihnen abhängigen endogenen Modellgrößen bearbeitet. Dabei überprüft die Routine alle direkt abhängigen Modellgrößen, ob deren gerade untersuchte Beeinflussung von höherer Ebene ist, als bisher festgehalten; in diesem Fall wird die Modellgröße ebenso bearbeitet, woraus sich die Rekursion ergibt 4.2 Gleichungsreduktion 4.2.1 Steuerung durch den Benutzer Ist die interessierende Modellgröße (Topziel) ausgewählt worden, so hat der Benutzer festzulegen, welche der erklärenden Basisgrößen der reduzierten Gleichung symbolisch erhalten bleiben sollen und welche numerisch zu konkretisieren sind, also durch die Werte der zuvor festgelegten Planungsperiode und -phase zu ersetzen sind. Aus diesen Benutzereingaben resultiert für jede in die Reduktion involvierte Modellgröße ein Status, der in einem Vektor abgelegt wird. Hier wird später auch festgehalten, ob eine Modellgröße als Zwischenergebnis bereits berechnet wurde, so daß keine erneute Berechnung erforderlich wird.

Strukturanalyse von Planungsmodellen

149

4.2.2 Zum Begriff eines vereinfachten reduzierten Terms Ziel der Gleichungsreduktion ist die Ermittlung einer vereinfachten reduzierten Gleichung. Darunter versteht man eine reduzierte Gleichung, deren Erklärungsausdruck ein vereinfachter reduzierter Term ist. Der Begriff des vereinfachten reduzierten Terms soll im folgenden erläutert werden. Ein reduzierter Term ist daran zu erkennen, daß er als Operanden lediglich numerische Werte enthält oder solche Modellgrößen, die Basisgrößen sind und für die der Benutzer festgelegt hat, sie symbolisch zu belassen. Bezüglich der Vereinfachung wurde ein besonderes Augenmerk auf eine übersichtliche kanonische Form gelegt. Deshalb wurde als Grundstruktur die Form einer ausmultiplizierten gebrochenrationalen Funktion gewählt. Hier läßt sich auch bei großen Termen die Struktur vom Benutzer verhältnismäßig gut erkennen. Auch für eine analytische Optimierung bietet sie erhebliche Vorteile [6]. Im einzelnen kann ein Term folgende Zustände annehmen: (1) Real-Zahl Eine Real-Zahl darf positiv und negativ sein. (2) Größe Eine Größe gilt nur dann als vereinfachter reduzierter Term, wenn es sich um eine nicht numerisch zu konkretisierende Basisgröße handelt. (3) Funktion Jede Funktion besteht aus dem sie identifizierenden Namen und einer beliebig langen Parameterliste. Dabei ist jeder Parameter für sich wieder ein vereinfachter reduzierter Term. Für eine endliche Zahl vordefinierter Funktionen soll, wenn alle Parameter Real-Zahlen (1) sind, die Funktion durch ihren Wert als Real-Zahl dargestellt werden. Sind mehr als einer, aber nicht alle Parameter Real-Zahlen, so sind diese nach Möglichkeit zusammenzufassen. Alle Ausdrücke und Konstrukte, die sonst nicht zulässig wären, werden als Funktion formuliert (z.B. IF-Statements oder Potenzen mit nicht-numerischen Exponenten). (4) Potenz Als Basis einer Potenz kommen Größen (2) und Funktionen (3) in Frage, der Exponent darf nur eine reelle Zahl größer 0 und ungleich 1 sein. Andere Potenzen sind auszumultiplizieren /-dividieren bzw. als Funktion darzustellen. (5) Produkt Jedes Produkt besteht aus mindestens zwei Faktoren, davon darf nur einer eine RealZahl (1) sein, deren Wert weder 0 noch 1 betragen darf. (Der Wert -1 ist zulässig.)

150

Strukturanalyse von Planungsmodellen

Die weiteren Faktoren können Größen (2), Funktionen (3) und Potenzen (4) sein. Dabei darf keine Größe oder Funktion mit einer Basis oder zwei Basen miteinander übereinstimmen; gegebenenfalls sind diese Faktoren miteinander zu verrechnen. Alle Faktoren sind in der Reihenfolge Real-Zahl - Größe - Funktion zu sortieren, wobei die Gruppen untereinander alphabetisch zu sortieren sind. Die Potenzen werden ihrer Basis gemäß einsortiert Produkte, die neben einer Real-Zahl (1) nur einen weiteren Faktor enthalten, werden im folgenden als Elementarprodukte bezeichnet (6) Summe Eine Summe besteht aus mindestens zwei Summanden, davon maximal eine RealZahl (1), deren Wert verschieden von 0 sein muß. Als weitere Summanden kommen Größen (2), Funktionen (3), Potenzen (4) und Produkte (5) in Betracht. Hierbei ist zu beachten, daß sich alle enthaltenen Produkte durch mehr unterscheiden als ihre RealZahl. Auch Größen, Funktionen und Potenzen müssen untereinander und zu dem entsprechenden Faktor eines Elementarprodukts verschieden sein. Die Sortierung erfolgt in der gleichen Reihenfolge, wie bei den Produkten, jedoch müssen Potenzen mit gleicher Basis (dies gibt es in Produkten nicht) nach abfallenden Exponenten sortiert werden. Während die Elementarprodukte entsprechend ihrem nicht-numerischen Faktor geordnet werden, folgen alle übrigen Produkte als weitere Gruppe. Die Sortierung dieser Produkte erfolgt nach den gleichen Kriterien, wie für die einfachen Summanden, zunächst für den ersten Faktor, dann für den zweiten usw. Die Real-Faktoren bleiben in der Sortierfolge unberücksichtigt (7) Quotient Ein Quotient besteht aus einem Zähler und einem Nenner. Der Zähler darf ein beliebiger vereinfachter reduzierter Term sein (1) - (6), jedoch kein Quotient. Sein Nenner kann eine Größe (2), eine Funktion (3), eine Potenz (4), ein Produkt (5) ohne Real-Zahl als Faktor oder eine Summe (6) sein, deren nicht-numerische Summanden, falls sie alle Produkte sind, nicht den gleichen numerischen Faktor enthalten dürfen. Weiterhin ist grundsätzlich Teilerfiremdheit zu fordern, wobei sich dies zunächst auf Identitätsvergleiche zwischen einer Größe (2), einer Funktion (3), der Basis einer Potenz (4) und den Faktoren eines Produkts (5) im Zähler bzw. Nenner des Quotienten beschränken soll. Eine weitere Möglichkeit zu kürzen, besteht dann, wenn Zähler und Nenner als Summen nur aus Produkten bestehen, deren numerische Faktoren innerhalb der Summe gleich sind, wenn sich die Summen bis auf diese numerischen Faktoren gleichen. Existieren keine numerischen Faktoren, so kann die ganze Summe verglichen werden.

Strukturanalyse von Planungsmodellen

151

4.2.3 Erzeugung der vereinfachten reduzierten Gleichung Das Grundprinzip der Erzeugung eines vereinfachten Termes ist nun, daß die Gleichungen abgearbeitet werden, als sollten sie numerisch berechnet werden, dies jedoch mit symbolischenRechenroutinen. Neben diesen wird also noch ein Algorithmus benötigt, der die Abfolge der Rechenoperationen steuert. Hierzu dient der Simple-Precedence-Algorithmus. Diese Vorgehensweise bewirkt einen vereinfachten reduzierten Term unter der Voraussetzung, daß der Berechnung nur Real-Zahlen oder Größen, die nicht weiter zu ersetzen sind (also Terme der Form (1) und (2) zugeführt werden oder auch Zwischenergebnisse, die bereits als vereinfachte reduzierte Terme (1) bis (7) errechnet wurden, womit impliziert ist, daß die Rechenroutinen aus zwei vereinfachten Termen nur einen vereinfachten Term erzeugen dürfen. 4.2.4 Der Simple-Precedence-Algorithmus und die Reduktion Zur Festlegung der Rangfolge der Operatoren und zur Steuerung des Abspeicherns von Zwischenergebnissen liegt dem Simple-Precedence-Algorithmus folgende Vorrangsmatrix zugrunde (vergleiche Abbildung 11). Anhand eines Beispieles soll in Abbildung 12 die Wirkungsweise kurz aufgezeigt werden. Der besseren Darstellbarkeit wegen wurde ein rein numerisches Beispiel gewählt. Auf der rechten Seite jedes Diagramms, ist die Eingabe in Infix-Notation dargestellt, d.h. die Operatoren befinden sich zwischen den Operanden. Die Eingabe wird nun von links nach rechts abgearbeitet, also bildlich gesehen nach links geschoben. Liegt ein Operand zur Bearbeitung vor, so wird dieser immer sofort auf den Operanden-Stack (oben im Diagramm) geschoben, weshalb dieser Schritt nicht jeweils gesondert dargestellt ist. Zeigt die Vorrangsmatrix (siehe Abbildung 11), daß der Operator auf dem Stack eine kleineren Rang hat als der gerade anstehende, so wird letzterer auf den OperatorenStack geschoben. Kann gerechnet werden, so werden die für die Berechnung benötigten Operanden vom Operanden-Stack geholt und das Ergebnis dorthin zurück geschrieben.

152

Strukturanalyse von Planungsmodellen

a k t u e l l e r

0p e r a t

0 r

V. S t a

O p e r a t o r

gr(

fk(

(

+




1.

Allgemeine Kostenstellen

2.

Kostenstellen der Konstruktion, Forschung und Entwicklung

3.

Kostenstellen des Einkaufs und Materialbereichs

4.

Kostenstellen der Fertigungsbereiche

5.

Kostenstellen der kaufmännischen Verwaltung

6.

Kostenstellen des Vertriebs

Abb. 13: Kostenstelleneinteilung des Modellunternehmens

Für die verschiedenen Kostenstellen sind auch unterschiedliche Kostenartenverdichtungen vorzunehmen. So empfiehlt es sich beispielsweise, die Personal-Kostenarten einer Fertigungs-Kostenstelle, wie dies in der Abbildung 14 verdeutlicht wird, tiefer zu gliedern, als dies bei einer Verwaltungs-Kostenstelle erforderlich ist Weiterhin ist es für den Soll-Ist-Kostenvergleich wichtig, die beeinflußbaren Kostenarten, wie z.B. Material-, Lohn-, oder Betriebsstoffkosten, im Hinblick auf die Abweichungsursachen tiefer zu gliedern. Dagegen kann bei nicht beeinflußbaren Kostenarten, wie z.B. den kalkulatorischen Kosten, Kosten für Versicherungen oder gesetzlichen Sozialkosten, auf eine differenzierte Gliederung verzichtet werden. Dementsprechend bietet der Prototyp CEUS dem Benutzer die Möglichkeit, den Grad der Informationsverdichtung [23] für den Soll-Ist-Kostenvergleich zu bestimmen. Wie aus Abbildung 15 hervorgeht, kann der Ausweis der Abweichungen in relativer und absoluter Größe auf drei Arten erfolgen. Auf diese Weise findet das Erfahrungswissen des Controllers zur Vorgehensweise der Kostenabweichungsanalyse Eingang im Aufbau des Systems. Die softwaretechnische Umsetzung dieser Konzeption erfolgt im Rahmen der Maßgaben von TWAICE. Dabei werden die einzelnen Kostenarten in der Kostenstelle als Objekte durch Frames [24] repräsentiert. Wie in Abbildung 14 verdeutlicht wird, sind die Kostenarten durch die Kontenklasse 4 des Gemeinschaftskontenrahmens definiert. Eine Darstellung der einzelnen Kostenstellen als Objekte ist hinfällig, da diese Strukturen durch Zusammenfassung der entsprechenden Kostenarten direkt abgeleitet werden können. Dazu orientiert sich das System an der in jeder Kostenart mitgeführten Kostenstellennummer. In gleicher Weise erfolgt die Zusammenfassung zu Kostenartenhauptgruppen über die mitgeführten Klassifikations-

Expertenunterstützungssystem im Controlling

174

nummern. Darüber hinaus existieren weitere Objekte, die die Funktion des Systems unterstützen, jedoch zur Kostenstellengliederung und damit zum Modell des Unternehmens keinen direkten Bezug haben. Kostenarten — hauptgruppe

Kostenarten— nummer

Kostenart

4301

Fertigungslöhne

4302

Löhne für innerbetr. Leistungen

4303

Zusatzlöhne

4310-15

Hilfslöhne

4320

Mehrarbeitszuschläge

4910

Kalk. P e r s o n a l nebenk. Arbeiter

4350

Gehälter

4911

Kalk. Personolnebenkosten

4100

Werkzeuge und Geräte

4110

Hilfs- und Betriebsstoffe

4200-10

H e i z - und Treibstoffe

4250-60

Fremdbezogene Energie

4 Innerbetr.

4510-30

Reparatur und Instandhaltung

Leistungen

4580

Ausschuß und Nacharbeit

4610-4750

Versch. Gemeinkosten

4801-4999

Kalk. Kalk. Kalk. Kalk. Kalk,

1 Personalkosten Lohnempfänger

2 Personalkosten Angestellte

3 Werkzeuge, Hilfs—

und

Betriebsstoffe

5 Versch. Gemeinkosten 6 Kalkulatorische Kostenarten

Raumkosten Stromkosten Transportkosten Leitungskosten sekundäre Fixkosten

Abb. 14: Kostenarten-Gliederung einer Fertigungs-Kostenstelle

175

Expertenunterstützungssystem im Controlling >

1.

S o l l - Ist--Kostenvergleich

Kostenstellen-Ebene

2.

Soll— Ist - K o s t e n v e r g l e i c h

Kostenortenhauptgruppen—Ebene

3.

Soll- Ist - K o s t e n v e r g l e i c h

Kostenarten-Ebene

Abb. 15: Informationsverdichtung

Die Eigenschaften einer jeden Kostenart werden in Attribut-Frames abgelegt. Eigenschaften umfassen dabei die absolute und relative Kostenabweichung, Besonderheiten der Kostenart, die für Abweichungen relevant sein können, sowie die zu ermittelnde Abweichungsursache. Im Verlauf der Konsultation nehmen diese Attribute - teils durch interaktive Angaben des Benutzers, teils durch eigene Inferenzen des Systems - Werte an, wodurch schließlich die interessierende Ursache bestimmt wird. Zusammenfassend läßt sich die Taxonomie des Problembereichs durch Abbildung 16 verdeutlichen. 3.2.2 Regelbasis Die Darstellung des zur Problemlösung notwendigen Erfahrungswissens erfolgt in CEUS in Form von Produktionsregeln. Das in Abbildung 17 dargestellte Beispiel veranschaulicht die Verknüpfung problemrelevanter Attributausprägungen zur Ursachenbestimmung der controllingrelevanten Abweichung in der Kostenart Hilfslöhne. Unsicheres und vages Wissen wird in TWAICE mit Konfidenzfaktoren dargestellt, d.h. Attribute können verschiedene Werte mit verschiedenen Konfidenzfaktoren annehmen. Der Wertebereich der Konfidenzen geht von 0 (völlig unsicher) bis 1000 (völlig sicher). Die Verwendung von Konfidenzfaktoren hat insbesondere in Bereichen, wo auf hohem Abstraktionsniveau Zusammenhänge beschrieben werden (z.B. die Darstellung von Ursache-Wirkungs-Beziehungen bei der Kostenabweichungsanalyse), besondere Bedeutung, da weder absolut sicheres Ausgangswissen noch logisch einwandfreie Schlußregeln vorausgesetzt werden können. Zur Etablierung signifikanter Abweichungsursachen können die Konfidenzfaktoren der Attribute regelübergreifend kumuliert werden. Dies ermöglicht, die für einzelne Regeln propagierten Wahrscheinlichkeiten während des gesamten Inferenzprozesses beizubehalten und weiterzuverarbeiten. Insbesondere für die Abweichungsanalyse ist diese Vorgehensweise vorteilhaft, da die Vielzahl der möglichen Suchpfade eine fortlaufende Plausibilitätskontrolle der jeweils verfolgten Ursache erfordert

Expertenunterstützungssystem im Controlling

176

Domainname

Startobjekt

Objekt n Objekt 3 Objekt 2 Objekt 1

| Attribut 1.n Attribut 1.3 | Attribut 1.2 Attribut 1.1

AttributFrame

Objekt -

Frame

D o m a i n — Frame

Taxonomie

Abb. 16: Frame-basierte Darstellung des Taxonomie-Wissens

Expertenunterstützungssystem im Controlling

177

Rul»10 IF (Kostenstelle.Einsatz unqualifizierter Arbeitskräfte-relevant AND Kostenstelle.Lohnkosten Vororbeiter=erhöht) OR (Kostenstelle.Arbeitsverzögerung« relevant AND Kostenstelle.Lohnkosten Vororbeiter/Arbeitsverteiler=erhöht) OR (Kostenstelle.techn. Schwierigkeiten=relevant AND

Kostenstelle.Einrichter/Reinigungspersonal=erhöht)

END

Rule20 IF Kostenstelle.Kostenart= Hilfslöhne AND (Kostenstelle.rein intensitötsmößige Anpassung=relevant OR Kostenstelle.zeitlich intensitätsmäßige Anpossung=relevant

END

Rule30 OR

Kostenstelle.Seriengrö6enobweichung=relevont

OR

Kostenstelle.Moschinenbelegungsobweichung-relevont

OR

Kostenstelle.6edienungsrelationsabweichung=relevont

OR

Kostenstelle.Ausbeutegradabweichungsrelevant

OR

Kostenstelle.Verrechnungsabweichung=relevont

OR

Kostenstelle.Restabweichung=relevant

THEN Kostenstelle. Verbrouchsabweichungsursache=definiert END

Abb. 17: Rückwärtsverkettete Produktionsregel in CEUS

3.3 Inferenzprozeß Kernstück des Inferenzprozesses ist die Ableitung der Problemlösung aus den vorhandenen Daten. Dabei unterscheidet man bei regelbasierten Systemen zwischen zwei grundsätzlichen Ableitungsrichtungen, der Vorwärts- und der Rückwärtsverkettung [25]. Die hier verwendete Expertensystem-Shell TWAICE unterstützt als Standardmechanismus die Rückwärtsverkettung für die Abarbeitung von Regeln.

178

Expertenunterstützungssystem im Controlling

Unter Berücksichtigung dieser Verfahren verläuft der Inferenzprozeß des Expertenunterstützungssystems CEUS interaktiv. Vor der Anwendung des Produktionssystems erfolgt eine Berechnung der Abweichungen auf der Grundlage der Daten in der Kostenrechnungsdatenbank. Ebenso werden aus diesen Abweichungen die Beschäftigungs- und Verbrauchsabweichungen in der Kostenrechnungsdatenbank bestimmt Die in einer Kostenstelle für alle Kostenarten ermittelten relativen und absoluten Abweichungen sind in der Datenbank als Ergebnis der Berechnung abgelegt und werden dem Benutzer tabellarisch visualisiert. Da für den weiteren Analyseprozeß nicht alle ermittelten Abweichungen relevant sind, erfolgt der Ausweis der Abweichungen gemäß controllingrelevanter Signifikanzgrenzen. Diese Schwellen können vom Benutzer aus dem Intervall zwischen den minimalen und maximalen Werten der in einer Kostenstelle ermittelten relativen Abweichungen gewählt werden. Die identifizierten Abweichungen dieser Kostenstelle werden in absteigender Folge des Ausmaßes ausgewiesen. Eine genauere Untersuchung kann der Benutzer durch die Auswahl der ihm relevant erscheinenden Abweichungen kontrollieren. Für diese Untersuchung verwendet das System das in Regeln gefaßte heuristische Wissen. Dieses im Prozeß des Knowledge Engineering ermittelte Erfahrungswissen ermöglicht die Identifikation von Abweichungsursachen und -zusammenhängen. Durch die selektive Untersuchung von Abweichungen und Bestimmung der relevanten Kostenverursachungsfaktoren ist eine zeitnahe Gegensteuerung möglich. Die Ursachen der abgewichenen Kostenarten in den untersuchten Kostenstellen sind in der Wissensbasis in CEUS abgelegt Im Abweichungsfall werden die Ursachen auf ihre notwendigen Voraussetzungen hin überprüft. Diese Überprüfung erfolgt interaktiv zusammen mit dem Benutzer, der die notwendigen externen Informationen zur Verfügung stellt Anhand dieser Eingaben versucht CEUS, Hypothesen über die Abweichungsursachen zu etablieren. Über eine Rückwärtsverkettung der entsprechenden Regeln für eine Abweichungsart werden die Voraussetzungen möglicher Abweichungsursachen überprüft. Dabei verfolgt das System einen einmal begonnenen Suchpfad so weit wie möglich zurück. Dies entspricht einer Strategie der Tiefensuche [26]. Gerade in einem interaktiven System mit häufigen Benutzereingaben ist diese Strategie von Vorteil, da der jeweilige Problemkontext erhalten bleibt Über die Benutzereingaben werden diejenigen Attribute der untersuchten Kostenart instanziiert, die für die aktuelle Ursache notwendig sind. Je nach der Belegung der notwendigen Attribute wird der aktuellen Ursache, wenn überhaupt etablierbar, ein Konfidenzwert zugewiesen. Im Anschluß daran untersucht das System die nächste Ursache.

Expertenunterstützungssystem im Controlling

179

Zur besseren Ergebnisfindung erfolgt der Hypothesentest unter Berücksichtigung von Konfidenzfaktoren, die eine Aussage über die Wahrscheinlichkeit des Auftretens der zugrundegelegten Zusammenhänge treffen. Somit können nach der Verarbeitung aller relevanten Daten mögliche Ursachen ausgewiesen werden. Das Ergebnis der Konsultation ist die Identifizierung der Abweichungsursachen über den mehrstufigen Inferenzprozeß. Nach dem Ausweis der möglichen Ursachen mit den zugehörigen Konfidenzwerten ist das System für die Untersuchung weiterer Abweichungen bereit Diese sequentielle Abarbeitung aufgetretener Abweichungen zusammen mit der verwendeten Strategie der Tiefensuche ist für den interaktiven Problemlösungsprozeß besonders vorteilhaft, da der Benutzer sich stets auf die wechselnden Problemkontexte konzentrieren kann.

4 Resümee und Ausblick Die vorgestellte Konzeption des Einsatzes von Expertensystem-Technologien im Bereich des Controlling bietet einen erfolgversprechenden Ansatz zur Verbesserung des innerbetrieblichen Entscheidungsprozesses für schlecht-strukturierte Probleme. Grundsätzlich sind die vorgetragenen Überlegungen auch für andere ControllingBereiche ähnlicher Problemstruktur, wie z.B. der Analyse von Leistungs- und Erlösabweichungen, denkbar [27]. Durch die stärkere Betonung der Entscheidungsunterstützung verändert sich die Kostenrechnung in Richtung eines Kosteninformationssystems. Der Einsatz von Techniken der Künstlichen Intelligenz im Controlling kann hier als Ergänzung zu herkömmlichen Daten- und Methodenbanken [28] verstanden werden. Erst die konsequente Einbeziehung der Expertensystem-Technologie führt zur vollständigen Ausnutzung des Informationspotentials der großen Zahl von KostenEinzeldaten. Dabei können Expertensysteme eine konsistente Interpretation der Wirkungszusammenhänge von Kostenabweichungen und darüber hinaus die Ableitung von Maßnahmen bei Erreichen kritischer Schwellenwerte leisten. Das Rechnungswesen muß sich diesen Entwicklungen stellen, da ansonsten die Gefahr besteht, die Gestaltungskompetenz bei der Erfassung und Quantifizierung betrieblicher Vorgänge zu verlieren [29]. Zudem ermöglicht der Einsatz eines Expertenunterstützungssystems für die Controlling-Funktion des Soll-Ist-Kostenvergleichs es den Betrieben, im Zeitablauf das Fachwissen ihrer Experten zu bewahren und zu akkumulieren. Damit wird die Unternehmung unabhängiger von einzelnen Personen, so daß deren Ausscheiden nicht mehr kritisch für die Unternehmung sein muß.

180

Expertenunterstützungssystem im Controlling

Grundsätzlich ist bei der Übertragung einer prototypenhaften Entwicklung in eine betriebliche EDV-Umgebung auf eine konsequente Integration in das Gesamtsystem der Datenverarbeitung zu achten. Eine solche Integration und somit Vermeidung von Insellösungen ist für den Nutzen einer jeden EDV-Entwicklung unabdingbar. Als Konzept auf lange Sicht wäre der Zugang des Controllers zu einer Gesamtheit von Expertensystem- und Methodenbank-gestützten Controlling-Instrumenten über seine Workstation denkbar.

Anmerkungen [1] Einen umfassenden Überblick betriebswirtschaftlicher Expertensysteme bietet eine Dokumentation von Mertens, Borkowski, Geis (1988), S. lff; vgl. auch Becker (1988), S. 115 -136; Scheer, Bock (1988), S. 46 - 55; Scheer, Steinmann (1988), S. 5 - 27; Steinmann (1987), S. 4 - 6. [2] Weitere Ausführungen zur Definitionsproblematik finden sich z.B. bei Zelewski (1986), S. 2 - 20. [3] Vgl. Simon (1977), S. 5f. [4] Vgl. Sviokla (1986), S. 7. [5] Vgl. Luconi et al. (1986), S. 12. [6] Vgl. Horvath, Kieninger (1987), S. 192; Reichmann, Krüger (1987), S. 59. [7] Vgl. Scheer (1988a), S. 508. [8] Vgl. Booker et al. (1986), S. 101; Elliot et al. (1985), S. 126; Huch (1987), S. 173; Kerschberg, Dickinson (1988), S. 111 - 1 3 3 ; O'Leary (1987), S. 85; o.V. (1987a), S. 120; Wilson (1987), S. 18. [9] Vgl. Prerau (1985), S. 26; Hayes-Roth et al. (1983), S. 241; Rauch-Hindin (1985), S. 68f; Harmon, King (1985), S. 198; Lebsanft, Gill (1987), S. 140; Savory (1987), S. 24f. [10] Vgl. Kraemer, Spang (1989). [11] Vgl. Kilger (1988), S. 536 - 541. [12] Vgl. Glaser (1986), S. 141; Kloock, Bommes (1982), S. 225; Kloock (1988), S. 423; Kilger (1988), S. 169f; Kunz (1985), S. 228; Link (1987), S. 780; Powelz (1985), S. 225. [13] Vgl. Glaser (1987), S. 41. [14] Vgl. Glaser (1986), S. 142; Haberstock (1988), S. 314; Kilger (1988), S. 559; Knoop (1986), S. 109f. [ 15] Vgl. hierzu die Beschreibung verschiedener Controlling-An wendungssysteme, z.B. Fock (1985), S. 91 - 96; Wolf (1986), S. 219 - 222; Wolf (1987), S. 19 - 24. [16] Das Aufkommen neuer EDV-Möglichkeiten wie Dialogverarbeitung, Datenbankeinsatz, Workstations, etc. ist anschaulich in den Tagungsbeiträgen der Saarbrücker Arbeitstagungen "Rechnungswesen und E D V " zu entnehmen.

Expertenunterstützungssystem im Controlling

181

[17] Diese These wurde durch Experteninterviews aus dem Bereich der EDVUnterstützung für Controlling-Funktionen anläßlich der 9. Saarbrücker Arbeitstagung bestätigt. [18] Vgl. Buchanan etal. (1983), S. 139 - 153; Noelke (1987), S. 112f. [19] Vgl. Brown (1987), S. 45; Härder, Mattos, Puppe, (1987), S. 23; Knöpfler, Sager (1987), S. 24; Turban, Watkins (1986), S. 125. [20] Eine Marktübersicht von Entwicklungstools ist dokumentiert in o.V. (1987b), S. 80 - 87. [21] Eine umfangreiche Dokumentation zu TWAICE findet sich z.B. bei Mescheder (1985), S. 57 - 90. [22] Eine detaillierte Vorgehensweise zur Implementierung externer Prozeduren und Datenbanken in TWAICE wird z.B. erläutert von Burbach et al. (1988), S. 43 - 45. [23] Weiterführende Hinweise zur Problematik und Vorgehensweise der Informationsverdichtung in konventionellen Controlling-EDV-Systemen finden sich z.B. bei Landsberg (1988), S. 101. [24] Weitere Methoden der Wissensrepräsentation sind z.B. beschrieben bei Harmon, King (1985), S. 34 - 48. [25] Eine Beschreibung dieser Verfahren findet sich z.B. bei Winston (1984), S. 177 - 182.

[26] Zur Tiefen- und Breitensuche vgl. Harmon, King (1985), S. 57. [27] Vgl. Fiedler, Wenzlaw, Ziegler (1988), S. Iff. [28] Vgl. Haun (1987), S. 182. [29] Vgl. Scheer (1988b), S. 15.

Literatur Becker, J.: Konstruktionsbegleitende Kalkulation mit einem Expertensystem; in: Scheer, A.-W. (Hrsg.): Rechnungswesen und EDV, 9. Saarbrücker Arbeitstagung Tagungsband; Heidelberg 1988, S. 115 - 136. Booker, J.A. et al.: Expert Systems in Accounting: The Next Generation for Computer Technology; Journal of Accountancy 161 (1986) 3, S. 101-104. Brown, S.: DBMS versus Expert System; The Accountant's Magazine 91 (1987) 972, S. 45-48. Buchanan, B.G.: Constructing an Expert System; in: Hayes-Roth, F. et al. (eds.): Building Expert Systems; Reading et al. 1983, S. 127-167. Burbach, B. et al.: Anforderungen der Korrosionschutztechnik an ein Expertensystemwerkzeug am Beispiel TWAICE; in: Cremers, A.B. (Hrsg.): 2. Anwenderforum Expertensysteme, Proceedings; Duisburg 1988, S. 29-56. Elliot, R.K. et al.: Micros in Accounting - Expert Systems for Accountants; Journal of Accountancy 160 (1985) 3, S. 126-148.

182

Expertenunterstützungssystem im Controlling

Fiedler, R., Wenzlaw, G., Ziegler, G.: BETREX - Ein System zur wissensbasierten Analyse des Betriebsergebnisses; in: Mertens, P. (Hrsg.): Arbeitspapiere Informatik-Forschungsgruppe VIII der Friedrich-Alexander-Universität ErlangenNürnberg; Erlangen 1988. Fock, U.: Dialog-Controlling; Kostenrechnungspraxis (KRP), o.Jg. (1985) 3, S. 9196. Glaser, H.: Zur Erfassung von Teilabweichungen und Abweichungsüberschneidungen bei der Kostenkontrolle; Kostenrechnungspraxis (KRP), o.Jg. (1986) 4, S. 141-148. Glaser, H.: Neue Möglichkeiten der Kostenkontrolle durch EDV-gestützte Abweichungsanalyse; in: Scheer, A.-W. (Hrsg.): Rechnungswesen und EDV, 8. Saarbrücker Arbeitstagung Tagungsband; Heidelberg 1987, S. 40-57. Haberstock, L.: Grenzplankostenrechnung; 7. Auflage, Hamburg 1988. Härder, T., Mattos, N., Puppe, F.: Zur Kopplung von Datenbank- und Expertensystemen; in: o. Hrsg.: Expertensysteme - State of the Art 3; München 1987, S. 2334. Harmon, P., King, D.: Expert Systems; New York et al. 1985. Haun, P.: Entscheidungsorientiertes Rechnungswesen; Berlin et al. 1987. Hayes-Roth, F. et al.: Building Expert Systems; London et al. 1983. Horvath, P., Kieninger, M.: Computerunterstütztes Controlling; Wirtschaftsstudium (WISU) 16 (1987) 4, S. 191-196. Huch, B.: EDV-Anwendungen im Controlling - Stand und Entwicklungstendenzen; in: Huch, B., Stahlknecht, P. (Hrsg.): EDV-Anwendungen im Unternehmen; Frankfurt 1987, S. 161-193. Kerschberg, L., Dickinson, J.: FINEX: A PC-based Expert Support System for Financial Analysis; in: Ernst, J.C. (ed.): Management Expert Systems; Workingham et al. 1988, S. 111-134. Kilger, W.: Flexible Plankostenrechnung und Deckungsbeitragsrechnung, 9. Auflage; Wiesbaden 1988. Kloock, J.: Erfolgskontrolle mit der differenziert-kumulativen Abweichungsanalyse; Zeitschrift für Betriebswirtschaft (ZfB) 58 (1988) 3, S. 423-434. Kloock, J., Bommes, W.: Methoden der Kostenabweichungsanalyse; Kostenrechnungspraxis (KRP) o.Jg. (1982) 5, S. 225-237. Knöpfler, S., Sager, W.: Kopplung von KI-Systemen mit Datenbank-Systemen; BTS 33 (1987) 6, S. 24. Knoop, J.: Online-Kostenrechnung für die CIM-Planung; Berlin 1986. Kraemer, W., Spang, S.: Expertensysteme im Controlling ?; Kostenrechnungspraxis (KRP) o.Jg. (1989) 1 (Veröffentlichung in Vorbereitung). Kunz, B.R.: Leistungsbedingte Abweichungen im Gemeinkostenbereich; Kostenrechnungspraxis (KRP) o.Jg. (1985) 6, S. 228-232. Landsberg, v.G.: Control Reporting - Informationsverdichtung und Abweichungserklärung; Kostenrechnungspraxis (KRP) o.Jg. (1988) 3, S. 101-106.

Expertenunterstützungssystem im Controlling

183

Lebsanft, E.W., Gill, U.: Expertensysteme in der Praxis - Kriterien für die Verwendung von Expertensystemen zur Problemlösung; in: Savory, S. (Hrsg.): Expertensysteme: Nutzen für ihr Unternehmen; München, Wien 1987, S. 135-150. Link, J.: Schwachpunkte der kumulativen Abweichungsanalyse in der Erfolgskontrolle; Zeitschrift für Betriebswirtschaft (ZfB) 57 (1987) 8, S. 780-792. Luconi, F.L. et al.: Expert Systems: The Next Challenge for Managers; Sloan Management Review 27 (1986) 4, S. 3-14. Mertens, P., Borkowski, V., Geis, W.: Betriebliche Expertensystem-Anwendungen - Eine Materialsammlung; Berlin et al. 1988. Mescheder, B.: Funktionen und Arbeitsweise der Expertensystem-Shell TWAICE; in: Savory, S. (Hrsg.), Künstliche Intelligenz und Expertensysteme, 2. Auflage; München, Wien 1985. Noelke, U.: Das Wesen des Knowledge Engineering; in: Savory, S. (Hrsg.): Expertensysteme: Nutzen für Ihr Unternehmen; München, Wien 1987, S. 109-123. O'Leary, D.E.: The Use of Artificial Intelligence in Accounting; in: Silverman, B.G. (eds.), Expert Systems for Business; Reading et al. 1987, S. 83-98. o. V.: Expert Systems for Accountants: Has their Time Come?; Journal of Accountancy 164 (1987a) 6, S. 117-125. o.V.: Marktübersicht Shells; in: o.Hrsg.: Expertensysteme - State of the Art 3; München 1987b, S. 80-87. Powelz, H.J.H.: Ansätze zum weiteren Ausbau der differenzierten Kostenabweichungsanalyse, Kostenrechnungspraxis (KRP) o.Jg. (1985) 6, S. 233-239. Prerau, D.S.: Selection for an Appropriate Domain for an Expert System; AI Magazine 6 (1985) 2, S. 26-30. Rauch-Hindin, W.: Artificial Intelligence in Business, Science and Industry, Bd.I: Fundamentals; Englewood Cliffs, New Jersey 1985. Reichmann, T., Krüger, L.: Entwicklungen im Bereich kennzahlengestützter Controlling-Konzeptionen; in: Reichmann, T. (Hrsg.): 2. Deutscher Controlling Congress Tagungsband; München 1987, S. 37-72. Savory, S.: Expertensysteme: Welchen Nutzen bringen sie für Ihr Unternehmen; in: Savory, S. (Hrsg.); Expertensysteme: Nutzen für Ihr Unternehmen; München, Wien 1987, S. 17-38. Scheer, A.-W.: Wirtschaftsinformatik - Informationssysteme im Industriebetrieb, 2. Auflage; Berlin et al. 1988a. Scheer, A.-W.: Das Rechnungswesen in den Integrationstrends der Datenverarbeitung; in: Scheer, A.-W. (Hrsg.): Rechnungswesen und EDV; 9. Saarbrücker Arbeitstagung Tagungsband; Heidelberg 1988b, S. 3-22. Scheer, A.-W., Bock, M.: Expertensysteme zur konstruktionsbegleitenden Kalkulation; CAD-CAM REPORT 7 (1988) 12, S. 46-55.

184

Expertenunterstützungssystem im Controlling

Scheer, A.-W., Steinmann, D.: Einführung in den Themenbereich Expertensysteme; in: Scheer, A.-W. (Hrsg.): Betriebliche Expertensysteme I: Einsatz von Expertensystemen in der Betriebswirtschaft - Eine Bestandsaufnahme; Schriften zur Unternehmensführung (SzU) o.Jg. (1988) 36, S. 5-27. Simon, H.A.: The New Science of Management Decision; 2. Auflage, New York 1977. Steinmann, D.: Expertensysteme in der Produktionsplanung und -Steuerung unter CIM-Aspekten; in: Scheer, A.-W. (Hrsg.): Veröffentlichungen des Instituts für Wirtschaftsinformatik, Nr. 55; Saarbrücken 1987. Sviokla, J.J.: Business Implications of Knowledge-based Systems; DATA BASE 17 (1986) 4, S. 5-19. Turban, W., Watkins, P.R.: Toward Intelligent Decision Support systems: An Artificially Intelligent Statistician; MIS Quarterly 10 (1986) 2, S. 121-136. Wilson, A.: Accounting with Expert Systems; The Accountant's Magazine 91 (1987) 971, S. 18-19. Winston, P.H.: Artificial Intelligence, 2. Auflage; Reading et al. 1984. Wolf, M.: Grundlagen und Merkmale eines EDV-gestützten Controllingsystems Teil 1; Kostenrechnungspraxis (KRP) o.Jg. (1986) 6, S. 219-222. Wolf, M.: Grundlagen und Merkmale eines EDV-gestützten Controllingsystems Teil 2; Kostenrechnungspraxis (KRP) o.Jg. (1987) 1, S. 19-24. Zelewski, S.: Expertensysteme - Übersicht über Konzeptionen und betriebswirtschaftliche Anwendungsmöglichkeit; in: Arbeitsberichte des Seminars für Allgemeine Betriebswirtschaftslehre, Industriebetriebslehre und Produktionswirtschaft der Universität zu Köln, Nr. 17, Köln; 1986.

Teil 2: Methoden und Werkzeuge zur Entwicklung betrieblicher Anwendungssysteme

INC OME - Methoden und Werkzeuge zur betrieblichen Anwendungsentwicklung Wolffried Stucky, Tibor Nemeth, Frank Schönthaler

Inhalt 1 Gegenstand des Projekts und Einordnung des Beitrags 2 Einleitung 2.1 Probleme beim Einsatz von Life-Cycle-Methoden 2.2 Prototyping 2.3 Flexible Entwicklungsstrategien 3 INCOME - eine flexible Software-Entwicklungsstrategie 4 Anforderungsanalyse 4.1 Arbeitsschritte der Anforderungsanalyse 4.2 Spezifikation der funktionalen Anforderungen 5 Konzeptuelle Modellierung und Rapid Prototyping 5.1 Überblick 5.2 Objektstrukturmodellierung 5.2.1 Das semantisch-hierarchische Objektmodell 5.2.2 Entwurf des Objektstrukturschemas 5.3 Prototyping von Objektstrukturen 5.4 Modellierung des SystemVerhaltens 5.4.1 Entwurf einer Hierarchie lokaler Verhaltensnetze 5.4.2 Entwurf des globalen Verhaltensnetzes 5.4.3 Transaktionsmodellierung 5.5 Prototyping des Systemverhaltens 6 Realisierung der Entwicklungsumgebung INCOME 7 Zusammenfassung und Ausblick Anmerkungen Literatur

188

INCOME - betriebliche Anwendungsentwicklung

1 Gegenstand des Projekts und Einordnung des Beitrags Der vorliegende Beitrag gibt einen kurz gefaßten Überblick über die SoftwareEntwicklungsumgebung INCOME. Die Umgebung unterstützt eine flexible Strategie zur Entwicklung von interaktiven betrieblichen Anwendungssystemen [1], Als Methode zum konzeptuellen Entwurf liegt die INCOME-Methode zugrunde, die seit Ende 1984 am Institut für Angewandte Informatik und Formale Beschreibungsverfahren der Universität Karlsruhe entwickelt wird. Charakteristisch für diese Methode ist die durchgängige Verwendung von Petri-Netzen als formalem Beschreibungsverfahren für alle Entwurfsaspekte. Die eindeutige Syntax und Semantik dieser Netze ermöglicht neben formalen Analysen [2] auch deren Verwendung als Basis zum Rapid Prototyping. Der Konzeption des Prototyping-Tools INCOME/PROFIT liegt primär das Ziel zugrunde, für die konzeptuelle Modellierung mit INCOME Möglichkeiten zur Integration des Endbenutzers in den Entwicklungsprozeß zu schaffen. Prototyping ist dabei in jeder Phase des Entwicklungsprozesses möglich, wobei stets alle bereits spezifizierten Aspekte im Prototyp abgebildet sind.

2 Einleitung Die Softwareentwickler sehen sich heute einer ständig steigenden Nachfrage nach individuellen Softwarelösungen in Anwendungsbereichen gegenüber, für die der Einsatz rechnergestützter Informationssysteme noch vor Jahren undenkbar war. Gefragt sind vor allem Komponenten, die sich problemlos in umfassende Softwarelösungen für ganze Unternehmensbereiche integrieren lassen. Die zu beobachtende rasche Verbreitung rechnergestützter Informationssysteme in allen Funktionsbereichen eines Unternehmens stellt erhebliche Anforderungen an die zu realisierende Software, denen der Softwareentwickler nur durch den Einsatz problemadäquater Methoden und Werkzeuge gerecht werden kann. 2.1 Probleme beim Einsatz von Life-Cycle-Methoden Der betrieblichen Softwareentwicklung liegen heute zumeist Life-Cycle-Methoden zugrunde. Diese sind charakterisiert durch eine Folge von Meilensteinen, die zu vorgegebenen Zeitpunkten erreicht werden müssen. Zu diesen Zeitpunkten sind entsprechende Entwurfsdokumente vorzulegen, die im Rahmen von Projektbesprechungen verabschiedet werden. Diese Dokumente bilden eine weitgehend unverrückbare Basis der nachfolgenden Entwicklungsschritte. Nachträglich sich ergebende Anforderungen können so zumeist nicht mehr berücksichtigt werden. Die Entwurfsdokumente weisen häufig einen informalen oder semiformalen Charakter

INCOME - betriebliche Anwendungsentwicklung

189

auf und sind deshalb formalen Analysen nur beschränkt zugänglich, wodurch sich Inkonsistenzen im Entwurf kaum vermeiden lassen. Werkzeugunterstützung liegt oft nur in Form von General-Purpose-Tools wie Text- und Diagrammeditoren vor. Die Life-Cycle-Methoden weisen neben der fehlenden Werkzeugunterstützung in den frühen Projektphasen jedoch einige weitere gravierende Nachteile auf, die vorwiegend aus der fehlenden Möglichkeit zur Integration des Endbenutzers in den Software-Entwicklungsprozeß resultieren. Der Endbenutzer ist in der Regel mit dem Studium der vorgelegten Entwurfsdokumente zeitlich oder aufgrund unzureichender Informatikkenntnisse überfordert. Die Folge ist eine fehlende Kommunikationsbasis zwischen Systementwickler und Endbenutzer, so daß Spezifikationsfehler oftmals erst nach Übernahme des Systems in die betriebliche Praxis erkannt werden. Die Problematik bei der Anwendung konventioneller Life-Cycle-Methoden machte die Suche nach alternativen Vorgehensweisen erforderlich, die eine stärkere Einbeziehung des Endbenutzers fördern. Als Ergebnis wurden Methoden und Werkzeuge entwickelt, die es ermöglichen, die Analyse- und Entwurfsentscheidungen anhand eines ausführbaren Systems zu veranschaulichen. 2.2 Prototyping Eine wichtige Gruppe solcher zur Diskussion gestellter Ansätze läßt sich unter dem Begriff Prototyping zusammenfassen. Zur Abgrenzung des Prototyping gegenüber konventionellen Life-Cycle-Methoden führt Riddle an, daß Prototyping sich mit der Produktion eines einzigen Arbeitsprodukts beschäftigt, während bei Life-CycleMethoden mehrere Arbeitsprodukte aneinandergereiht werden, die letztlich zum Endprodukt - dem ausführbaren Code des Systems - führen [3]. Ein Prototyp wird während der Systementwicklung erstellt, wobei seine Lebensdauer als sehr kurz veranschlagt wird. Wiederholte Änderungen des Prototyps werden bewußt vorgenommen. Die Erstellung von Prototypen dient dazu, Probleme bereits während der Entwicklungsphase zu erkennen und entsprechend zu berücksichtigen. Prototyping fördert in besonderem Maße die Einbeziehung des Endbenutzers in den Entwicklungsprozeß, indem durch Bereitstellung eines ausführbaren Systems bereits zu einem frühen Zeitpunkt eine geeignete Kommunikationsbasis zwischen Endbenutzer und Entwickler geschaffen wird. Hierdurch wird die frühzeitige Erkennung von Spezifikationsfehlern oder -lücken ermöglicht, die anhand interner Analysen der Spezifikation üblicherweise nicht erkannt werden könnten. Darunter lassen sich insbesondere die Spezifikationsfehler einordnen, die durch ein falsches Verständnis von Zusammenhängen der Realwelt entstehen.

190

INCOME - betriebliche Anwendungsentwicklung

Häufig werden zum Prototyping Entwicklungswerkzeuge und Sprachen moderner Datenbanksysteme (z.B. FOCUS, NATURAL, ORACLE), Logiksprachen wie PROLOG oder funktionale Sprachen wie LISP verwendet [4]. Dabei wird zumeist jedoch auf eine vorausgehende Spezifikation der Anforderungen verzichtet, oder die Prototyp-Entwicklung erfolgt unabhängig von der vorliegenden Spezifikation, bzw. diese muß explizit durch den Entwickler berücksichtigt werden. 2.3 Flexible Entwicklungsstrategien Obgleich die Bereitstellung von Prototypen zur Beteiligung des Endbenutzers am Software-Entwicklungsprozeß auch in der Literatur vorwiegend positiv beurteilt wird, sollte an dieser Stelle nicht auf einige kritische Anmerkungen verzichtet werden. So ist insbesondere die Problematik von Interessenkonflikten zwischen verschiedenen involvierten Benutzergruppen oder zwischen Management und Endbenutzer zu beachten [5], Darüber hinaus besteht die Gefahr, daß das auf der Basis von Anforderungen eines unerfahrenen Benutzers entwickelte System nicht den Anforderungen eines fortgeschrittenen Systembenutzers genügt und deshalb abgelehnt wird. Solche Überlegungen führen zu flexiblen Entwicklungsstrategien, die eine enge Verknüpfung von Life-Cycle-Methoden und Prototyping vorsehen [6]. Dem Softwareentwickler obliegt hierbei die Aufgabe, die für die Problemstellung adäquate Entwicklungsstrategie auszuarbeiten, die aus einer Kombination der zur Verfügung stehenden Life-Cycle-Methode und der Arbeit mit Prototypen des zu entwickelnden Systems besteht. Wichtige Kriterien bei der Auswahl der Strategie sind die beteiligten Benutzer- und Entwicklergruppen, das Aufgabengebiet, die Komplexität der Anwendung und nicht zuletzt die für die Entwicklungsarbeiten zur Verfügung stehende Rechnerunterstützung.

3 INCOME - eine flexible Software-Entwicklungsstrategie Den Kern der INCOME-Entwicklungsstrategie bilden die Instrumente zur konzeptuellen Modellierung und zum Rapid Prototyping der zu entwickelnden Applikationen. Auf diesen Instrumenten aufbauend wurde eine umfassende Entwicklungsstrategie konzipiert, die in Abbildung 1 schematisch dargestellt ist Die INCOME-Entwicklungsstrategie ist geprägt durch eine hohe Flexibilität beim Einsatz der verschiedenen Instrumente zur Softwareentwicklung. Für die schematische Darstellung eignet sich deshalb das in der Literatur häufig benutzte Wasserfall-

INCOME - betriebliche Anwendungsentwicklung

191

• Wartungsaufträge -

Probiemfindung Problem beschreibung

Anforderungsanalyse - Formulieren Projektauftrag

- Zlelinalftt

•

Stark- and Schwach«tellenld. Ist-Aufnahme Schwachstellenanalyse Spez. funktionaler Anforderungen

|

PrototypingProtokoU

• Schema funktionaler Anforderungen -

Konzeptuelle Modellierung

PrototypingProtokoll

• Objektstrukturmodellierung Konzeptuelles Schema

• Verhaltensmodellierung

Konzeptuelles

Schern

Systementwurf, Realisierung Implementation, Testdokumentation Schulungsunterlagen

Interpretative Ausführung Spezifikation der Benutzeroberfläche Prototyping der ObjekUtruk turen Prototyping des Systemverhalten* Benutzeroberfläche

Prototyping Prototyp der ' Implementation "

Qualitätskontrolle, Bewertung

Transformation de« konreptuellen Schema« Prototypmißige Implementation

£ Inbetriebnahme - Installation • Realtest - Schalung Abb. 1: Die INCOME-Entwicklungsstrategie

Modell nur beschränkt [7]. In der vorliegenden Abbildung repräsentieren die Rechtecke Tätigkeiten der Softwareentwicklung, wobei diese Tätigkeiten durch entsprechende Beschriftungen weiter detailliert werden. Pfeile bezeichnen Flüsse von Informationen bzw. Dokumenten. Zur Vereinfachung sind Rückkopplungen,

192

INCOME - betriebliche Anwendungsentwicklung

die in entgegengesetzter Pfeilrichtung der Informationsflüsse verlaufen, grafisch nicht berücksichtigt. Nachfolgend werden die in Abbildung 1 aufgeführten Tätigkeiten kurz erläutert: - Das Software-Entwicklungsprojekt startet üblicherweise mit der Phase Problemfindung, in der die näher zu untersuchenden Tatbestände, Arbeitsabläufe, Betriebsbereiche usw. identifiziert werden [8]. Außerdem werden die Rahmenbedingungen für die geforderten Untersuchungen festgelegt - Aus dieser Phase resultiert eine Problembeschreibung, die die Basis der Anforderungsanalyse bildet. Hier wird ein Schema erstellt, in dem die funktionalen Anforderungen an das zu entwickelnde System dokumentiert sind und welches als Ausgangspunkt der konzeptuellen Modellierung, aber auch als Basis des Systementwurfs dient. - Den Kern der INCOME-Entwicklungsstrategie bilden die konzeptuelle Modellierung und die Instrumente zum Rapid Prototyping. In der Literatur wird die konzeptuelle Modellierung häufig als Teil der Anforderungsanalyse gesehen. In dieser Arbeit wird sie jedoch als eigenständige Phase im Software-Entwicklungsprozeß eingebunden. - Der Systementwurf und die Realisierung, die in der vorliegenden Abbildung zu einer Tätigkeit zusammengefaßt wurden, werden auf der Basis des konzeptuellen Schemas, der funktionalen Anforderungen und gegebenfalls eines durch Transformation generierten Prototyps durchgeführt - Qualitätskontrollen und eine betriebswirtschaftliche Bewertung des neuen Systems erfolgen zu bestimmten, vom Projektträger festgelegten Zeitpunkten. Üblicherweise werden dies die Vorlage des konzeptuellen Schemas, des Systementwurfs oder der Implementation sein. Daraus können möglicherweise geänderte Anforderungen resultieren, die in den bereits vorliegenden Entwurfsdokumenten entsprechend berücksichtigt werden müssen. - Die im Rahmen der Realisierung erstellte Implementation, die Testdokumentation und die Schulungsunterlagen werden in den Phasen Inbetriebnahme und Wartung weiterverarbeitet. Im Rahmen der Wartung wiederum können Probleme entdeckt werden, die nach einiger Zeit zu einer Neuentwicklung führen. Anzumerken ist, daß die beschriebenen Informations- bzw. Dokumentenflüsse optional sind und somit einzelne Tätigkeiten bei bestimmten Entwicklungsprojekten entfallen können. In den folgenden Kapiteln werden nun die Haupttätigkeiten Anforderungsanalyse, konzeptuelle Modellierung und Prototyping im einzelnen erläutert.

INCOME - betriebliche Anwendungsentwicklung

193

4 Anforderungsanalyse Ausgangspunkt der Anforderungsanalyse ist ein Projektauftrag, der anhand der Problembeschreibung erstellt wird. Im Projektauftrag sind die Ziele aufgeführt, die mit dem Einsatz des zukünftigen Informationssystems erreicht werden sollen. Außerdem sollten die Randbedingungen (zeitlich, finanziell, technisch, personell) des Entwicklungsprojekts angegeben sein. 4.1 Arbeitsschritte der Anforderungsanalyse Zur Anforderungsanalyse im Rahmen der INCOME-Entwicklungsstrategie hat sich in einer Reihe von Projekten in der betrieblichen Praxis eine Vorgehensweise [9] bewährt, die auf den folgenden sechs Arbeitsschritten beruht: (0) Formulieren Projektauftrag (1) Zielanalyse (2) Stark- und Schwachstellenidentifikation (3) Ist-Aufnahme (4) Schwachstellenanalyse (5) Erstellung des Anforderungskatalogs Anzumerken ist jedoch, daß der Arbeitsschritt (5) lediglich die Spezifikation der funktionalen Anforderungen umfaßt, aber keine Datenaspekte oder dynamische Beziehungen berücksichtigt. In einem Glossar werden zusätzliche textuelle Informationen zu den Elementen dieser Spezifikation festgehalten, die in der nachfolgenden Phase der konzeptuellen Modellierung formalisiert werden. Ein vollständiger Anforderungskatalog als Basis des Systementwurfs liegt somit erst nach Abschluß der konzeptuellen Modellierung vor. 4.2 Spezifikation der funktionalen Anforderungen Ergebnis der Spezifikation der funktionalen Anforderungen ist eine Beschreibung der Funktionen des Systems zusammen mit ihren Ein- und Ausgabeflüssen, wobei organisatorische Fragen im Vordergrund stehen. Die detaillierte Beschreibung der Funktionen und Objektflüsse des Systems unter Datenverarbeitungsgesichtspunkten erfolgt dagegen erst im Rahmen der konzeptuellen Modellierung. Zur Dokumentation der funktionalen Anforderungen hat sich eine Hierarchie von Objektflußdiagrammen ähnlich SADT, SA, SSA oder ISAC [10] als geeignet erwiesen. Objektflußdiagramme stellen ein einfaches, leicht verständliches Hilfsmittel für die Beschreibung der Funktionen dar, die ein zu entwerfendes System erfüllen muß: sie enthalten rechteckige Kästchen zur Darstellung der Funktionen und Pfeile zwischen Kästchen zur Darstellung der Objektflüsse, die zwischen den

194

INCOME - betriebliche Anwendungsentwicklung

betreffenden Funktionen verlaufen. Hierarchien von Objektflußdiagrammen entstehen durch rekursives Verfeinern einzelner Funktionen gemeinsam mit ihren jeweiligen Input- und Outputflüssen durch neue Diagramme. Die Funktion der obersten Hierarchieebene stellt die Gesamtsystemaktivität dar. Abbildung 2 zeigt den Ausschnitt einer Objektflußdiagramm-Hierarchie, die im Rahmen einer von der EFIP vorgeschlagenen Fallstudie für ein Lagerverwaltungssystem entstanden ist [11]. Die den Objektflüssen des Diagramms zugeordneten Nummern stellen dabei eine Beziehung zu den hierarchisch übergeordneten Objektflüssen der detaillierten Funktion her. Dazu werden die Ein- bzw. Ausgabeflüsse der übergeordneten Funktion von oben nach unten durchnumeriert und die detaillierenden Flüsse mit diesen Nummern gekennzeichnet. StammdatenInformation Lagerstammdaten

1.1 * Verwalten ^ Lagerstammdaten

^

Lagerstammdaten

w

1.1 Verwalten Lagerstammdaten

Anzeige der 2 Lagerstammdaten ' Artikeltypen

Information-Artikeltyp Lageistammdaten

K

Lageretammdaten

Aktualisieren Artikeltypen

Lagerstamindaten

Anzeige der Artikel

*1

Artikelliste

Liste der Artikcltypcn Lagerstammdaten Artikel-Infoimation

Aktualisieren Lagerstamm-* datcn Artikel

1

Abb. 2: Ausschnitt einer Objektflußdiagramm-Hierarchie

Die Objektflußdiagramm-Hierarchie - das Schema derfunktionalen Anforderungen - wird um ein Glossar erweitert, in dem die Objektflüsse und Funktionen des Schemas detailliert beschrieben werden. Der Umfang dieses Glossars hängt zum einen von der Intensität der vorausgehenden Anforderungsanalyse-Schritte ab, andererseits aber auch vom Detaillierungsgrad der Objektflußdiagramm-Hierar-

INCOME - betriebliche Anwendungsentwicklung

195

chie. In frühen praktischen Arbeiten wurden die Objektflüsse, und entsprechend die Funktionen, überwiegend bis zur Attributebene verfeinert. Es hat sich jedoch gezeigt, daß für ein vernünftiges Arbeiten im Rahmen der konzeptuellen Modellierung die Verfeinerung etwa bis zur Formularebene durchaus genügt Die semiformale Beschreibung eines Systems im Schema der funktionalen Anforderungen und im zugehörigen Glossar ist jedoch nur beschränkt verwendungsfähig als Grundlage für die spätere Implementation, da Widersprüche, Inkonsistenzen, Unvollständigkeiten, Ungenauigkeiten bzw. Mehrdeutigkeiten nicht ausgeschlossen werden können. Vor der eigentlichen Implementation sollte daher zunächst eine Prüfung der Spezifikation durchgeführt werden. Dies ist aber nur möglich, wenn die Spezifikation formal eindeutig und damit mathematischen Analysen zugänglich ist. Wir verzichten bewußt darauf, durch die Verwendung zusätzlicher Symbole in den Objektflußdiagrammen zusätzliche Semantik einzuführen [12], damit die Diagramme auch für den Nicht-Fachmann verständlich bleiben. Stattdessen bevorzugen wir eine Vorgehensweise, in der wir von den semiformalen Objektflußdiagrammen und informalen textuellen Beschreibungen schrittweise übergehen zum formalen Beschreibungsmittel der Petri-Netze [13]. Diese bieten mit der Netztheorie einen mathematischen Formalismus an, welcher umfangreiche Analysen des zu entwerfenden Systems ermöglicht

5 Konzeptuelle Modellierung und Rapid Prototyping 5.1 Überblick Die konzeptuelle Modellierung wird in der Literatur als ein fundamentaler Schritt bei der Entwicklung zuverlässiger und robuster Software anerkannt [14]. Unter konzeptueller Modellierung wird im allgemeinen das formale Beschreiben aller relevanten Aspekte eines zukünftigen Systems verstanden, wobei von Aspekten der späteren Implementation zunächst abstrahiert wird. In einem konzeptuellen Schema sollten sowohl statische als auch dynamische Aspekte berücksichtigt werden [15]. Im Rahmen der konzeptuellen Modellierung müssen auch Integritätsbedingungen und zeitliche Restriktionen berücksichtigt werden [16]. INCOME unterstützt einen konstruktiven Ansatz zur konzeptuellen Modellierung. Ausgehend vom Schema der funktionalen Anforderungen wird durch schrittweise Formalisierung ein umfassendes konzeptuelles Schema entworfen. Das konzeptuelle Schema ist dabei in Teilschemata untergliedert, die jeweils unterschiedliche Aspekte des Systems beschreiben: die relevanten Objekttypen werden zusammen mit ihren gegenseitigen Beziehungen im Objektstrukturschema - dem statischen Teil

196

INCOME - betriebliche Anwendungsentwicklung

des konzeptuellen Schemas - beschrieben; das Verhaltensschema enthält eine Spezifikation der elementaren Benutzeroperationen (Transaktionen) und des Objektflusses zwischen diesen Operationen. Der Zeitpunkt zum Einsatz von Rapid Prototyping im INCOME-Entwicklungsprozeß hängt sowohl vom Anwendungsgebiet als auch von persönlichen Präferenzen der Projektbeteiligten ab. Üblicherweise werden die ersten Prototypen eingesetzt, wenn im Rahmen der Objektstrukturmodellierung bereits einige weitgehend vollständige Objektstrukturen entwickelt wurden. Prototyping von Objektstrukturen eignet sich vorzüglich in den frühen Phasen eines Entwicklungsprojekts. Sind jedoch bereits Teile des Verhaltensschemas vorhanden, sollten diese dynamischen Aspekte ebenfalls beim Prototyping berücksichtigt werden. Besondere Bedeutung kommt hierbei der Integration statischer und dynamischer Aspehe zu, die über die verwendete Präsentationstechnik unterstützt wird. 5.2 Objektstrukturmodellierung 5.2.1 Das semantisch-hierarchische Objektmodell Aufgabe der Objektstrukturmodellierung ist die Beschreibung der für den Entwurf relevanten Realweltobjekte und ihrer Beziehungen untereinander. Ergebnis dieses Modellierungsschritts ist ein globales Objektstrukturschema. Zur Modellierung von Objektstrukturen verwenden wir Petri-Netze mit einer speziellen Interpretation, sogenannte Objektstrukturnetze. Die dabei verwendeten Konzepte Klassifikation, Generalisierung, Aggregation und Gruppierung sind charakteristische Merkmale der meisten semantischen Objektmodelle [17]. Strukturierungskonzepte Mit Hilfe der Klassifikation können Einheiten der Realwelt zu Typen oder Klassen von Objekten zusammengefaßt werden. Der Abstraktionsmechanismus der Generalisierung erlaubt die Zusammenfassung von Objekttypen als Subtypen unter einem generischen Supertyp. In Abbildung 3 b ist der Objekttyp Lieferanteninformation der Supertyp, unter dem die Subtypen Adresseninformation und Lieferinformation subsumiert werden. Aggregation wird eingesetzt, um Komponentenbeziehungen zu definieren. In Abbildung 3 c sind dem Aggregattyp Artikel vier Komponententypen zugeordnet. Mit Hilfe der Gruppierung können Objekttypen definiert werden, deren Ausprägungen Mengen von Objekten anderer Objekttypen sind. In Abbildung 3 d besteht ein Objekt des Mengentyps Lieferantenliste aus einer Menge von Objekten des Elementtyps Lieferant.

INCOME - betriebliche Anwendungsentwicklung

197

Wertebereich Der Wertebereich eines Objekttyps im Objektstrukturschema ist entweder elementar (INTEGER, REAL, STRING,...), oder er ergibt sich aus den speziellen Vererbungsregeln [18] der einzelnen Beziehungen, in denen der Objekttyp auftritt. Mit den in der grafischen Repräsentation des Modells dargestellten Pfeilen (siehe Abbildung 3) wird die Richtung der Wertebereichsvererbung angezeigt

I

Lieferanteninformation Artikel

^ — ^ Adresseninformation

(a) Ohjc.kttypl

n Lieferinformation

(b) Generalisierung J

Lieferantenliste

ó

Artikel#

ó

ó

ArtikelMaximalbezeichnung bestand

ó

BestellZeitpunkt

(Vc) Aggregation )

Lieferant

[(d) Gruppierung

Abb. 3: Grafische Repräsentation der Konzepte des Objektmodells

5.2.2 Entwurf des Objektstrukturschemas Die Objektstrukturmodellierung - der Entwurf des konzeptuellen Objektstrukturschemas - läuft üblicherweise in drei Phasen ab [19]: (1) Entwurf lokaler Objektstrukturen, (2) Entwurf von Schemaausschnitten, (3) Integration von Schemaausschnitten. (1) Entwurf lokaler Objektstrukturen Im ersten Schritt der konzeptuellen Objektstrukturmodellierung werden die Objektflüsse der Objektflußdiagramm-Hierarchie zunächst als Objekttypen mit gleichem

198

INCOME - betriebliche Anwendungsentwicklung

Namen interpretiert; dieser Interpretationsschritt muß aber interaktiv durchgeführt werden, da die Namenswahl für Objektflüsse bei der Erstellung des Schemas der funktionalen Anforderungen uneingeschränkt erfolgen kann, während für die Phase der konzeptuellen Modellierung eindeutige Namen benötigt werden. Im nächsten Schritt werden dann lokale Beziehungen zwischen Objektflüssen mit Hilfe des Objektmodells abgebildet. Diese Beziehungen können entweder Vorgänger-INachfolgerbeziehungen auf der Ebene nicht weiter verfeinerter Funktionen des Schemas der funktionalen Anforderungen (finale Funktionen) sein oder Verfeinerungsbeziehungen von Ein- bzw. Ausgabeflüssen zwischen aufeinanderfolgenden Hierarchieebenen. Dabei werden die Objektflüsse, entsprechend den oben erwähnten Beziehungen, in vier Gruppen eingeteilt, für die jeweils spezielle lokale Strukturen gebildet werden [20]. Um in diesem Modellierungsschritt semantisch korrekte Strukturen zu erhalten, ist ein gewisses Maß an Interaktion mit dem Designer notwendig, das abhängt vom Verfeinerungsgrad (und damit vom Informationsgehalt), der im Schema der funktionalen Anforderungen erreicht wurde. In Abbildung 4 ist ein Beispiel für die Modellierung von Vorgänger-/Nachfolgerbeziehungen in lokalen Strukturen angegeben. Der Ausgabefluß der Funktion Aktualisieren Artikel wird zu den Eingabeflüssen in Beziehung gesetzt. Weitergehende Informationen, wie sie etwa in Abbildung 4 gegeben sind, können durch den Designer über die entsprechenden Editierfunktionen in die lokalen Strukturen eingebracht werden.

Abb. 4: Lokale Struktur für Vorgänger-/Nachfolgerbeziehungen

INCOME - betriebliche Anwendungsentwicklung

199

(2) Entwurf von Schemaausschnitten In der Phase 1 wurden Vorgänger-/Nachfolgerbeziehungen zwischen Objektflüssen nur auf der Ebene finaler Funktionen betrachtet Um die Vorgänger-/Nachfolgerbeziehungen auf höheren Ebenen mit Hilfe des Objektmodells abbilden zu können, muß die durch das eine Funktion verfeinernde Diagramm gegebene Semantik berücksichtigt werden. Dies wird erreicht durch die Konstruktion von sogenannten Schemaausschnitten für Ausgabeflüsse solcher Funktionen. Dabei muß bottom-up bis zur obersten Hierarchieebene für alle Ausgangsflüsse nicht finaler Funktionen die folgende Vorgehensweise angewandt werden. Für einen Ausgabefluß A einer nicht finalen Funktion werden die verfeinernden Flüsse bestimmt. Von diesen Flüssen aus werden alle zusammenhängenden Pfade von Flüssen durch das Diagramm bestimmt. Sämtliche bisher vorliegenden Strukturen, die für Flüsse auf diesen Pfaden entworfen wurden, werden zu einem Schemaausschnitt für den betrachteten Fluß A verknüpft (3) Integration von Schemaausschnitten Durch Anwendung der für die Phasen 1 und 2 vorgesehenen Vorgehensweise wird für jeden Ausgabefluß der auf der obersten Ebene der Objektflußdiagramm-Hierarchie stehenden Gesamtsystemaktivität ein Schemaausschnitt erzeugt. Um ein globales Objektstrukturschema zu erhalten, müssen diese Ausschnitte in einem gemeinsamen Schema integriert werden. Dieses Schema wird außerdem um solche lokalen Objektstrukturen und Schemaausschnitte erweitert, die bis jetzt noch nicht im globalen Schema berücksichtigt wurden. Damit erhält man für eine Objektflußdiagramm-Hierarchie ein Objektstrukturschema. Wird eine Applikation durch mehrere Hierarchien beschrieben, so müssen die jeweils entstehenden Schemata in einem weiteren Schritt integriert werden. Häufig sind neu zu entwickelnde Anwendungen in eine existierende Umgebung zu integrieren. In diesen Fällen muß das entworfene Objektstrukturschema mit der existierenden Datenbank verträglich gestaltet werden. Dazu werden zunächst die relevanten Teile der existierenden Datenbank in eine Menge von Objekttypen und Beziehungen abgebildet, um eine semantische Grundlage für die darauf aufbauende Objektstrukturmodellierung zu schaffen. Die auf diese Weise entstandenen Strukturen werden dann ebenfalls in das globale Schema integriert 5.3 Prototyping von Objektstrukturen Nachfolgend wird gezeigt, wie die Informationen des statischen Teilschemas im Prototyp repräsentiert sind und welche Möglichkeiten Prototyping der Objektstrukturen bietet Zunächst werden auf der Basis des Objektstrukturschemas Teilschemata gebildet, die die interne Struktur von Formularen darstellen. Diese Struktur wird unter

200

INCOME - betriebliche Anwendungsentwicklung

Berücksichtigung der im semantisch-hierarchischen Objektmodell definierten Vererbungsregeln generiert [21]. In dieser Weise entspricht die Formularstruktur der S truktur eines möglicherweise komplexen Objekts. Der rekursive Generierungsalgorithmus kann vollständig automatisiert werden [22]. Die externe Repräsentation des Formulars wird in einem zweiten Schritt auf der Basis der vorliegenden internen Struktur interaktiv spezifiziert. Hierzu wird eine Syntax verwendet [23], wie sie in ähnlicher Weise für das Electronic Form System [24] vorgeschlagen wird. Die Spezifikation der Repräsentation erfolgt für die Felder von Formularen separat, um so die Wiederverwendbarkeit der Feldspezifikationen sicherzustellen. Die Formularspezifikation kann nun interpretativ ausgeführt werden, wobei der Benutzer die Möglichkeit zur Anwendung von Update-, Insert-, Delete- und Retrieva/-Operationen auf komplexen Objekten hat, die durch die Formulare repräsentiert werden. Falls die präsentierten Formulare nicht den Anforderungen des Benutzers entsprechen, kann die zugrundeliegende Spezifikation geändert werden. Betreffen solche Änderungen die interne Struktur von Formularen, hat dies unmittelbar auch Auswirkungen auf das konzeptuelle Objektstrukturschema. 5.4 Modellierung des Systemverhaltens Neben der Beschreibung der statischen Eigenschaften der zu entwickelnden Anwendung im Objektstrukturschema, wird im Verhaltensschema das Systemverhalten formal beschrieben. Dabei betrachten wir das Systemverhalten auf zwei unterschiedlichen Ebenen: auf der Benutzerebene und der Datenbankebene. Der Endbenutzer des Systems arbeitet mit Hilfe von Benutzeroperationen auf der Datenbank. Diese Benutzeroperationen (Transaktionen) werden aus atomaren Datenbankoperationen (delete, update, insert, u.a.) zusammengesetzt. Zur Darstellung von Systemdynamik sind die Objektflußdiagramme des Schemas der funktionalen Anforderungen ungeeignet. Als formale Sprache zur Beschreibung des Systemverhaltens haben sich Prädikat/Transitions-Netze (Pr/T-Netze) bewährt [27]. Dieser Petri-Netz-Typ stellt eine Erweiterung des sonst gebräuchlichen Typs der Stelle/Transitions-Netze dar. In Pr/T-Netzen werden Stellen als Prädikate bezeichnet. MitPr/T-Netzen ist es möglich, sequentielle, parallele und alternative Abläufe von Benutzeroperationen grafisch zu modellieren. Der Objektfluß zwischen den Benutzeroperationen wird durch identifizierbare Marken repräsentiert, die durch Anwendung der formalen Schaltregel von Prädikat zu Prädikat wandern. Eine Beschriftung der Transitionen ermöglicht darüberhinaus die Spezifikation der Transaktionen. Den Ausgangspunkt für die Verhaltensmodellierung bilden, wie bei der Objektstrukturmodellierung, die Objektflußdiagramme des Schemas der funktionalen Anforderungen.

INCOME - betriebliche Anwendungsentwicklung

201

Die Verhaltensmodellierung läuft in drei Phasen ab: (1) Entwurf einer Hierarchie lokaler Verhaltensnetze, (2) Entwurf des globalen Verhaltensnetzes, (3) Transaktionsmodellierung. 5.4.1 Entwurf einer Hierarchie lokaler Verhaltensnetze Als Startpunkt für die Verhaltensmodellierung werden die Objektflußdiagramme des Schemas der funktionalen Anforderungen als Verhaltensnetze interpretiert: Funktionen werden zu Transitionen, Objektflüsse zu Prädikaten und Ein- bzw. Ausgabekanten der entsprechenden Transitionen. Als Beispiel für die Umsetzung von Objektflußdiagrammen in entsprechende Netze ist in Abbildung 5 das Verhaltensnetz für das Diagramm 1.1 Verwalten Lagerstammdaten (siehe Abschnitt 3.2, Abbildung 2) angegeben. Die resultierenden Netze werden so abgeändert und zum Teil weiter verfeinert, daß die formale Schaltregel für die Netze der untersten Ebene erfüllt ist. In einer Bottom-up-Vorgehensweise werden die Netze auf höheren Ebenen an die veränderten Netze der unteren Ebenen angepaßt. Ob die so entstandenen Netze das Systemverhalten korrekt darstellen, kann nur in einem interaktiven Prozeß entschieden werden. Diese Entscheidung wird durch zusätzliche Informationen über die Objektstrukturen, die den Prädikaten zugeordnet sind, unterstützt Anzeige der Artikeltypen

Liste der Artikeltypen

Lager

o

ArtikelInformation

Aktualisieren Artikel

Abb. 5: Interpretation eines Objektflußdiagramms als Verhaltensnetz

202

INCOME - betriebliche Anwendungsentwicklung

5.4.2 Entwurf des globalen Verhaltensnetzes Nachdem in einem durch umfangreiche Interaktion geprägten Schritt semantisch korrekte lokale Verhaltensnetze erzeugt wurden, kann jetzt weitgehend automatisch ein globales Verhaltensnetz konstruiert werden. Dazu werden die Netze der in Phase 1 entworfenen Hierarchie in einem Top-down-Prozeß verknüpft [28]. Im wesentlichen werden zur Verknüpfung von Netzen die Umgebungen in einem Netz durch ihre Verfeinerungen ersetzt, bis alle Netze der Hierarchie berücksichtigt wurden. Dieser Prozeß des Ersetzens von Umgebungen ist in eine Verknüpfungsstrategie eingebettet, die Verknüpfungen in Abhängigkeit der Prädikate durchführt, die die Umgebungen der verfeinerten Transitionen gemeinsam benutzen. Die Beziehungen zwischen den dabei zu betrachtenden Prädikaten und den zugehörigen Objektstrukturen resultieren zum Teil in Netzerweiterungen, bevor die eigentliche Verknüpfung durchgeführt wird. 5.4.3 Transaktionsmodellierung Die in den Phasen 1 und 2 erstellten Verhaltensnetze beschreiben Systemverhalten zunächst nur auf der Benutzerebene, d.h. auf der Ebene von Transaktionen. Mit der formalen Schaltregel für Pr/T-Netze ist es möglich, die Vor- und Nachbedingungen von Transaktionen dadurch darzustellen, daß jedes Input- bzw. I/O-Prädikat mit einer entsprechend der Kantenbeschriftung ausreichenden Anzahl von Objekten belegt ist und die Kapazitätsgrenze keines Output- bzw. I/O-Prädikats überschritten wird. Darüberhinaus können durch Beschriftung von Transitionen Vorbedingungen in Abhängigkeit vom Typ und der Ausprägung von Input-Variablen modelliert werden. Außerdem kann angegeben werden, wie Objekte in Output-Prädikaten aus Objekten von Input-Prädikaten hervorgehen. Abbildung 6 zeigt als Beispiel die Beschriftung der Transition t!2 / Aktualisieren Artikeltypen des Verhaltensnetzes aus Abbildung 5. Durch die Transitionsbeschriftung wird spezifiziert, wie aufgrund bestimmter Bedingungen ein Satz in den Lagerstammdaten aktualisiert bzw. neu eingefügt wird. Um die Spezifikation der PROLOG-Regeln zu vereinfachen, werden an anderer Stelle vordefinierte Built-in-Prädikate benutzt [29]. tj 2 / Aktualisieren Artikeltypen Lage rstammdaten

InformationArtikeltyp

A=information_artikeltyp(artikeltyp(E,F,G),_), ((member(artikeltyp(E,_,_),H), remove(artikeltyp(E,_,_),H,I), insert(artikeltyp(E,F,G) J , J)); insert(artikeltyp(E,F,Gj,H,J))), C=lagerstammdaten(J).

Abb. 6: Beispiel für eine Transitionsbeschriftung

Liste der Artikeltypen D

INCOME - betriebliche Anwendungsentwicklung

203

5.5 Prototyping des Systemverhaltens Prototyping der Systemdynamik mit INCOME basiert weitgehend auf dem Schalten von Transitionen im Verhaltensschema. Die Vorgehensweise ist sowohl auf Prädikat/Transitions-Netze anwendbar als auch auf den einfacheren Typ der Stelle/ Transitions-Netze, die keinerlei Pfeil- oder Transitionsbeschriftungen aufweisen. In diesem Fall müssen die Transaktionen, die über diese Beschriftungen spezifiziert sind, durch Benutzerinteraktion simuliert werden. Die Prototyp-Ausführung startet durch Einfügen einer Startmarkierung im Verhaltensschema. Die Marken, die in Stellen abgelegt werden, entsprechen Objekten, die intern als PROLOG-Datenstrukturen repräsentiert werden. Ihre externe Repräsentation sind Formulare, wobei das Einfügen der Objekte über die bereits erwähnte Formular-Schnittstelle erfolgt. Die Struktur der Objekte wird wie in Abschnitt 4.3 beschrieben ermittelt Zur Prototyp-Ausführung müssen die zu bestimmten Zeitpunkten aktivierten Transitionen bestimmt werden sowie mögliche Belegungen von Input-Variablen, für die die Transitionen aktiviert sind. Eine Transition ist aktiviert, wenn die Input-Stellen gemäß der Pfeilbeschriftung genügend Objekte des geforderten Typs enthalten, die Kapazität der Output-Stellen durch ein Schalten der Transition nicht überschritten wird und die Transitionsformel für mindestens eine Variablenbelegung erfüllt ist Der Benutzer hat nun verschiedene Möglichkeiten, aus der Menge der aktivierten Transitionen die im nächsten Zyklus zu schaltende(n) Transition(en) auszuwählen: (1) Direkte Auswahl einer bestimmten aktivierten Transition, (2) Auswahl einer Menge von parallel zu schaltenden Transitionen, (3) Auswahl eines im nächsten Schaltzyklus zu konsumierenden Objekts. Führt eine solche Auswahl zu einer Konfliktsituation, wird diese durch Aktivierung einer Menü-Komponente gelöst, über die vom Benutzer eine entsprechende Entscheidung angefordert wird. Die in einem bestimmten Zeitpunkt aktuell ausgeführten Schaltvorgänge können nun überprüft werden. Die konsumierten Objekte können über die FormularSchnittstelle inspiziert werden. Enthalten konsumierte Objekte als Komponenten nicht-instantiierte Variablen, unterstützt die Schnittstelle außerdem das Einfügen von entsprechenden Werten für diese Variablen. In analoger Weise ist die interaktive Modifikation von erzeugten Objekten realisiert. Diese Manipulationsmöglichkeit ist besonders dann von großer Bedeutung, wenn noch nicht alle Transaktionen vollständig spezifiziert sind.

204

INCOME - betriebliche Anwendungsentwicklung

Nachdem die Schaltvorgänge abgeschlossen sind, liegt eine neue Markierung im Verhaltensschema vor. Die Prototyp-Ausführung endet, wenn der Benutzer einen Abbruch erzwingt oder keine aktivierten Transitionen mehr gefunden werden können. Die Prototyp-Ausführung wird in einem sogenannten Logfile protokolliert. Dieses File bildet die Basis für Laufzeitanalysen und verschiedene Statistiken. Über das Logfile können vormals aktuelle Markierungen im Verhaltensschema wiederhergestellt werden. Darüberhinaus ist durch Auswertung des Logfiles auch die Wiederholung von Prototyp-Ausführungen möglich.

6 Realisierung der Entwicklungsumgebung INCOME Die in den vorangegangenen Kapiteln beschriebenen Konzepte werden zur Zeit prototypmäßig implementiert, um eine rechnergestützte Entwicklungsumgebung zur Unterstützung der INCOME-Entwicklungsstrategie zur Verfügung zu stellen.

Abb. 7: Architektur des aktuellen Prototyps der INCOME-Entwicklungsumgebung

Der Prototyp wird in MS-PASCAL auf Personal-Computern IBM-AT unter dem Betriebssystem MS-DOS implementiert. Es ist geplant, zukünftige Versionen unter

INCOME - betriebliche Anwendungsentwicklung

205

Berücksichtigung der Erfahrungen aus der Prototypentwicklung und den Praxisanwendungen in einer Workstation-Umgebung neu zu implementieren. Abbildung 7 zeigt die Architektur des aktuellen Prototyps. Den Kern der Entwicklungsumgebung bildet die INCOME-Too/io*. Sie besteht aus mehreren Werkzeugen, die den gesamten Software-Entwicklungsprozeß aufbauend auf der INCOME-Methode zur konzeptuellen Modellierung unterstützen. In der Toolbox Finden sich Werkzeuge zur Unterstützung der Spezifikation funktionaler Anforderungen sowie der konzeptuellen Modellierung der Objektstrukturen und des Systemverhaltens. Außerdem existieren diverse Dokumentations- und AnalyseWerkzeuge. Rapid Prototyping wird derzeit durch einen Formulargenerator und einen Formularhandler unterstützt. Für die konventionelle Programmentwicklung wurden zudem Werkzeuge wie Editoren, Interpreter, Compiler, Debugger, ein Linker und ein Library Manager in die Umgebung integriert. Die Entwicklungsumgebung INCOME ist als offenes System konzipiert. Daher läßt sich die Toolbox um beliebige Werkzeuge erweitern und so an projekt- oder benutzerspezifische Gegebenheiten adaptieren. INCOME stellt eine homogene Oberfläche für die Anwendung der Werkzeuge bereit und bewirkt so den Eindruck, als würden die elementaren Werkzeuge der Toolbox Teilfunktionen eines umfassenden Gesamtwerkzeugs darstellen. Durch Einsatz einer zentralen Entwicklungsdatenbank wird die sich aus der Entwicklungsstrategie ergebende notwendige Kommunikation zwischen den einzelnen Werkzeugen auf indirekte Weise ermöglicht. Über ein spezielles Konzept der Werkzeugintegration ist auch eine direkte Kommunikation zwischen den Werkzeugen möglich. Die Entwicklungsdatenbank wird über das relationale Datenbanksystem INOVIS-X86 [30] und das MS-DOS-Filesystem verwaltet. Durch das eingesetzte DBMS können eine Vielzahl von Integritätsbedingungen gewährleistet werden; zur vollen Integritätssicherung der INCOME-Entwicklungsdaten müssen jedoch zusätzliche Kontrollmechanismen zur Verfügung stehen. Insbesondere durch die typischerweise auftretenden langen Transaktionen und die Notwendigkeit, Konsistenz zwischen den Informationen in MS-DOS-Files und in der Datenbank zu gewährleisten, müssen zusätzliche Konzepte zur Integritätssicherung verwirklicht werden. Diese Konzepte basieren in der INCOME-Umgebung im wesentlichen auf drei Mechanismen: zum einen Datenkapselung durch Einsatz vordefinierter Operationen für Datenbank-Updates, desweiteren vom Benutzer ausgelöste Ausführung von Prozeduren zur Integritätsprüfung und schließlich die Integration einer wissensbasierten Integritätssicherungskomponente [31].

206

INCOME - betriebliche Anwendungsentwicklung

7 Zusammenfassung und Ausblick Die INCOME-Strategie stellt Instrumentarien zur Anforderungsanalyse, konzeptuellen Modellierung, zum Systementwurf und zum Rapid Prototyping zur Verfügung. Im Mittelpunkt des Entwicklungsprozesses steht die Konstruktion eines konzeptuellen Schemas auf der Basis eines Schemas der funktionalen Anforderungen, das als Ergebnis einer Anforderungsanalyse entstanden ist Im konzeptuellen Schema werden sowohl statische als auch dynamische Aspekte des zu entwickelnden Systems beschrieben, wobei von Aspekten der späteren Implementation zunächst abstrahiert wird. Das konzeptuelle Schema stellt eine operationale Spezifikation des Systems dar, die in jeder Phase des Entwicklungsprozesses durch einen Interpreter ausgeführt werden kann. Hierdurch wird insbesondere die Endbenutzer/Entwickler-Kommunikation gefördert. Als Übergang zur Implementation ist die Transformation der formalen Spezifikation in ein geeignetes Zielsystem vorgesehen. Die INCOME-Strategie hat sich in einigen Projekten bereits im Praxiseinsatz bewährt. Bemerkenswert hierbei sind die Breite des Anwendungsspektrums sowie die teilweise recht unterschiedlichen Zielsetzungen der Projekte. Die Strategie wird derzeit durch eine Software-Entwicklungsumgebung unterstützt, die auf PersonalComputern IBM-AT installiert ist. Die mittelfristige Planung geht jedoch dahin, diesen Prototyp als Basis für eine weitgehende Neuimplementation in einer professionellen Workstation-Umgebung zu verwenden. Über die transformative Prototyping-Komponente soll in dieser Implementation eine Verknüpfung mit verschiedenen Anwendungsentwicklungssystemen realisiert werden.

Danksagung Für wertvolle Kommentare und Anregungen während des gesamten Projektverlaufs sind wir Georg Lausen und Andreas Oberweis von der Universität Mannheim zu Dank verpflichtet. Danken möchten wir auch allen studentischen Projektmitarbeitern, die im Rahmen von Studien- und Diplomarbeiten große Teile der vorgestellten Konzepte mit Engagement mitgestaltet und realisiert haben.

INCOME - betriebliche Anwendungsentwicklung

207

Anmerkungen [1] Ergänzende Ausführungen finden sich z.B. in Lausen et al. (1988), N6meth et al. (1988a), N6meth etal. (1988b), S. 193 ff.. Oberweis etal. (1986), S. 165 ff. [2] Vgl. auch Oberweis, Schönthaler et al. (1987), S. 21 ff. [3] Vgl. Riddle (1984), S. 19 ff. [4] Einsatz von FOCUS: Zajonc, McGowan (1983), S. 217 ff., NATURAL: Mönckemeyer, Spitta (1984), S. 122 ff., ORACLE: Hesse (1987), S. 181 ff., PROLOG: Venken, Bruynooghe (1984), S. 447 ff., LISP: Kolb (1985). [5] Vgl. Kensing (1984), S. 322 ff. [6] Solche Strategien werden angeregt u.a. in Agresti (1986), S. 11 ff., Floyd (1984), S. 1 ff., Riddle (1984), S. 19 ff. [7] Zum Wasserfall-Modell vgl. Boehm (1976), S. 1226 ff. [8] Vgl. hierzu Lockemann et al. (1983), S. 68 ff. [9] Zur Vorgehensweise siehe Lockemann et al. (1983). [10] Vgl. zum Einsatz von SADT: Ross (1977), S. 16 ff., SA: DeMarco (1978), SSA: Gane, Sarson (1979), ISAC: Lundeberg (1982), S. 173 ff. [11] Vgl. hierzu Lausen et al. (1988), S. 5 ff. [12] Ansätze, die solche Erweiterungen vorsehen: Hammer et al. (1977), S. 832 ff., Kerneret al. (1985) S. 168 ff., Ward (1986), S. 198 ff. [13] Vgl. auch Krämer, Schmidt (1981), S. 310 f. [14] Vgl. dazu Olle et al. (1982), Olle et al. (1983). [15] Vgl. zur Definition von Anforderungen an konzeptuelle Modellierung Griethuysen (1982). [16] Nähere Informationen zur Behandlung dieser Themenbereiche sind zu finden in Oberweis (1988), Oberweis, Lausen (1987), S. 247 ff., Oberweis, Lausen (1988). [ 17] Vgl. zu den Konzepten semantischer Objektmodelle Brodie, Ridjanovic (1984), S. 277 ff., Schiel (1984), S. 373 ff., Smith, Smith (1977), S. 105 ff. [18] Vgl. Brodie, Ridjanovic (1984), S. 277 ff., Lausen (1987), S. 38 ff. [19] Detaillierte Darstellung in N6meth et al. (1987), S. 143 ff. [20] Detaillierte Darstellung in N6meth et al. (1987), S. 143 ff. [21] Vgl. Brodie, Ridjanovic (1984), S. 277 ff., Lausen (1987), S. 38 ff. [22] Algorithmus in N6meth et al. (1987), S. 155. [23] Vgl. Schönthaler et al. (1987), S.155 ff. [24] Zu Electronic Form System vgl. Gehani (1982), S. 71 ff. [25] Zu den Konzepten der Pr/T-Netze: Genrich (1987), S. 207 ff. [26] Algorithmus in Lausen (1987), S. 75 ff. [27] Vgl. Lausen et al. (1988), S. 59 ff. [28] Vgl. Bösze (1987), S. 465 ff., Wasserman (1986), S. 147 ff. [29] Vgl. dazu Ndmeth et al. (1988a), S. 32 f. [30] Produkt der INOVIS GmBH & Co., 7500 Karlsruhe. [31] Weitere Informationen zu den erwähnten Konzepten finden sich in Lausen (1987), S. 152 ff.

208

INCOME - betriebliche Anwendungsentwicklung

Literatur Agresti, W.W.: Framework for a flexible development process; in: Agresti W.W. (Ed.): New Paradigms for Software Development; Washington D.C. 1986, S. 11-14. Boehm.B.W.: Software engineering; IEEETrans. Computers 25(1976) 12,S. 12261241. Bösze, J., Ackermann, D., Lüthi, H.-J.: Computer-Laien als Experten?; in: Schönpflug et al. (1987), S. 465-474. Bracchi, G., Tsichritzis, D. (Eds.): Proc. of the IFIP TC8/WG 8.4 Working Conference Methods and Tools for Office Systems; Pisa, Italy, 1987. Brodie, M.L., Mylopoulos, J., Schmidt, J.W. (Eds.): On Conceptual Modelling. Perspectives from Artifical Intelligence, Databases and Programming Languages; New York 1984. Budde, R„ Kuhlenkamp, K., Mathiassen, L., Züllighoven, H. (Eds.): Approaches to Prototyping; Berlin, Heidelberg 1984. De Marco, T.: Structured Analysis and System Specification; New York 1978. Floyd, C.: A systematic look at prototyping; in: Budde et al. (1984), S. 1-18. Floyd, C., Kopetz, H. (Hrsg.): Software-Engineering - Entwurf und Spezifikation, Berichte des German Chapter of the ACM 5, Stuttgart 1981. Gane, C., Sarson, T.: Structured Systems Analysis: Tools and Techniques; Englewood Cliffs, NJ 1979. Gehani, N.H.: A study in prototyping; ACM Softw. Eng. Notes 7 (1982) 5, S. 71-74. Genrich, HJ.: Predicate/transition nets; in: Brauer, W., Reisig, W., Rozenberg, G. (Eds.): Petri Nets: Central Models and their Properties, LNCS 254; Berlin, Heidelberg 1987, S. 207-247. Gesellschaft für Mathematik und Datenverarbeitung mbH (Hrsg.): Proc. der GIFachtagung Requirements Engineering RE'87 (St. Augustin, 20.-22. Mai); GMD-Studien Nr. 121, St. Augustin 1987. Griethuysen, J.J. (Ed.): Concepts and Terminology for the Conceptual Scheme and the Information Base; Report of the ISO/TC97/SC5/WG3, Publ. No. ISO/ TC97/SC5-N695, 1982. Gutzwiller, Th., Österle, H. (Hrsg.): Anleitung zu einer praxisorientierten SoftwareEntwicklungsumgebung, Band 2: Entwicklungssysteme und 4,-GenerationSprachen; Hallbergmoos 1988. Hammer, M., Howe, W.G., Kruskal, V.J., Wladowsky, I.: A very high level programming language for data processing applications; in: Comm. of the ACM 20 (1977) 11, S. 832-840. Hansen, H.R. (Hrsg.): GI/OCG/ÖGI-Jahrestagung Wien 1985; Informatik-Fachbericht 108, Berlin, Heidelberg 1985. Hesse, W.: Eine Prototyp-Entwicklung auf der Basis eines relationalen DBMS; in: Wagner et al. (1987), S. 181-200.

INCOME - betriebliche Anwendungsentwicklung

209

Kensing, F.: Property determination by prototyping; in: Budde et al. (1984), S. 322340. Kerner, H „ Pitrik, R., Motschnig, H., Trattnig, W.: EDDA-S, eine graphische, strukturierte Datenflußsprachefürden Software-Entwurf; in: Hansen (1985), S. 168-181. Klopcic, H.G., Marty, R., Rothauser, E.H. (Hrsg.): Arbeitsplatzrechner in der Unternehmung; Berichte des German Chapter of the A C M 23, Stuttgart 1985. Kolb, D.: INTERLISP-D: Ein Werkzeug für Rapid Prototyping; in: Klopcic et al. (1985), S. 119-136. Krämer, B., Schmidt, H.W.: Interaktive Softwareentwicklung durch schrittweise Formalisierung; in: Floyd etal. (1981), S. 310-311. Lausen, G.: Grundlagen einer netzorientierten Vorgehensweise für den konzeptuellen Datenbankentwurf; Forschungsbericht 179, Institut für Angewandte Informatik und Formale Beschreibungsverfahren, Univ. Karlsruhe 1987. Lausen, G., Müller, H., N6meth, T „ Oberweis, A., Schönthaler, F., Stucky, W.: Integritätssicherung für die datenbankgestützte Software-Produktionsumgebung INCOME; in: Schek et al. (1987), S. 152-156. Lausen, G., Nemeth, T „ Oberweis. A., Schönthaler, F., Stucky, W.: The INCOME Approach for Conceptual Modelling and Prototyping of Information Systems; Forschungsbericht, Institut für Angewandte Informatik und Formale Beschreibungsverfahren, Univ. Karlsruhe 1988. Lausen, G., Oberweis, A., Schönthaler, F.: Formale Beschreibung von Anforderungen: Eine netzorientierte Vorgehensweise zur konzeptuellen Modellierung von Informationssystemen; in: Hansen (1985), S. 156-167. Lockemann, P.C., Schreiner, A., Trauboth, H., Klopprogge, M.: Systemanalyse DV-Einsatzplanung; Berlin, Heidelberg 1983. Lundeberg, M.: The IS AC approach to specification of information systems; in: Olle etal. (1982), S. 173-234. Mönckemeyer, M., Spitta, T.: Concept and experiences of prototyping in a softwareengineering-environment with N A T U R A L ; in: Buddeetal. (1984), S. 122-135. Nemeth, T., Schönthaler, F., Müller, H „ Stucky, W.: INCOME: Von der funktionalen Anforderungsspezifikation zur Prototypdatenbank - Ein methodischer Ansatz; in: Gesellschaft für Mathematik und Datenverarbeitung mbH (1987), S. 143159. Nömcth, T., Schönthaler, F., Stucky, W.: Formale Spezifikation und Rapid Prototyping - Flexible Systementwicklung mit INCOME; Forschungsbericht 191, Institut für Angewandte Informatik und Formale Beschreibungsverfahren, Univ. Karlsruhe 1988a. Nemeth, T., Schönthaler, F., Stucky, W.: Das experimentelle Entwicklungssystem INCOME; in: Gutzwiller et al. (1988), S. 193-212. Oberweis, A.: Checking database integrity constraints while simulating information system behaviour; in: Proc. 9th European Workshop on Applications and Theory of Petri Nets; Venice, Italy, June 1988.

210

INCOME - betriebliche Anwendungsentwicklung

Oberweis, A., Lausen, G.: Temporal aspects in office information systems; in: Bracchi et al. (1987), S. 247-266. Oberweis, A., Lausen, G.: On the representation of temporal knowledge in office systems; in: Rolland et al. (1988). Oberweis, A., Schönthaler, F., Lausen, G., Stucky, W.: Net based conceptual modelling and rapid prototyping with INCOME; in: Proc. of the 3rd Conference on Software Engineering; Paris 1986, S. 165-176. Oberweis, A., Schönthaler, F., Seib, J., Lausen, G.: Database supported analysis tool for predicate/transition nets; Petri Net Newsletter 28, Dec. 1987, S. 21-23. Olle, T.W., Sol, H.G., Tully, CJ. (Eds.): Information System Design Methodologies: A Feature Analysis; Amsterdam, New York, Oxford 1983. Olle, T.W., Sol, H.G., Verrijn-Stuart, A.A. (Eds.): Information Systems Design Methodologies: A Comparative Review; Amsterdam, New York, Oxford 1982. o.V.: INOVIS-X86 Benutzerhandbuch, INOVIS GmbH & Co.; Karlsruhe 1986. Riddle, W.E.: Advancing the state of the art in software system prototyping; in: Budde et al. (1984), S. 19-26. Rolland, C „ Léonard, M., Bodard.F. (Eds.): Proc. of the IFIP TC8/WG 8.1 Working Conference Temporal Aspects in Information Systems (TAIS'87) SophiaAntipolis, France 1988. Ross, D.T.: Structured analysis (SA): a language for communicating ideas; IEEE Trans. Softw. Eng. 3 (1977) 1, S. 16-34. Schek, H.-J., Schlageter, G. (Hrsg.): Datenbanksysteme in Büro, Technik und Wissenschaft; Informatik-Fachbericht 136, Berlin, Heidelberg 1987. Schiel, U.: A semantic data model and its mapping to an internal relational model; in: Stocker et al. (1984), S. 373^00. Schönpflug, W., Wittstock, M. (Hrsg.): Software-Ergonomie '87 - Nützen Informationssysteme dem Benutzer?; Stuttgart 1987. Schönthaler, F., Oberweis, A., Lausen, G., Stucky, W.: Prototyping zur Unterstützung des konzeptuellen Entwurfs interaktiver Informationssysteme; in: Wagner et al. (1987), S. 155-180. Smith, J.M., Smith, D.C.P.: Database abstractions: aggregation and generalization; A C M Trans. Database Syst. 2 (1977) 2, S. 105-133. Stocker, P.M., Gray, P.M.D., Atkinson, M.P. (Eds.): Databases - Role and Structure; Cambridge 1984. Venken, R., Bruynooghe, M.: Prolog as a language for prototyping of information systems; in: Budde et al. (1984), S. 447-458. Wagner, R.R., Traunmüller, R., Mayr, H.C. (Hrsg.): Informationsbedarfsermittlung und -analyse für den Entwurf von Informationssystemen; Informatik-Fachbericht 143, Berlin, Heidelberg 1987. Ward, P.T.: The transformation schema: an extension of the data flow diagram to represent control and timing; IEEE Trans. Softw. Eng. 12 (1986) 2, S. 198-210.

INCOME - betriebliche Anwendungsentwicklung

211

Wasserman, A.I., Pircher, P.A., Shewmake, D.T.: Building reliable interactive information systems; IEEE Trans. Softw. Eng. 12 (1986) 1, S. 147-156. Zajonc, P.C., McGowan, K. J.: Proto-cycling: a new method for application development using fourth generation languages; in: Proc. SOFTFAIR Conf. on Software Development Tools, Techniques and Alternatives; Arlington, Virginia, July 25-28,1983, S. 217-222.

Konzeption und Realisierung eines Systemanalytiker-Arbeitsplatzes Thomas A. Gutzwiller, Hubert Österle

Inhalt 1 2 3 4 5 6

Einführimg Ziele der Forschungsarbeit Die Situation in Forschung und Entwicklung Probleme des CASE Anforderungen an ein integriertes CASE Der gewählte Ansatz als Beitrag zur Problemlösung 6.1 Methodenbestandteile und Darstellungshilfsmittel 6.2 Entwicklungsdatenbank 6.3 Werkzeuge 7 Zusammenfassung Anmerkungen Literatur Beispiele

1 Einführung Innerhalb des Teilgebietes 'Entwurf betrieblicher Informationssysteme' der interdisziplinären Fachrichtung Betriebsinformatik ist in den letzten fünfzehn Jahren ein breites Spektrum an instrumentierten Methoden konzipiert und entwickelt worden. Dies gilt insbesondere für -

die strategische Informationssystemplanung die Systemanalyse den organisatorischen Entwurf den logischen Daten- und Funktionsentwurf den EDV-technischen Daten- und Funktionsentwurf die Programmierung

214

Systemanalytiker-Arbeitsplatz

Zielvorstellung ist eine vollständige Rechnerunterstützung der oben genannten Aktivitäten. Synonyme für diese Rechnerunterstützung sind heute etwa Begriffe wie -

Analytiker-Arbeitsplatz Entwicklungswerkzeuge Software-Produktions-Umgebung (SPU) Entwurfssystem CASE[1]-Werkzeuge

Die funktionalen Komponenten der Rechnerunterstützung werden 'Werkzeuge' genannt. Diese umfassen - Editoren für das interaktive Erfassen von Daten über das zu entwickelnde Informationssystem - Analysewerkzeuge für die Überprüfung der Konsistenz der erfaßten Daten - Generatoren für das Erstellen von Dokumentation, Testdaten, Datenbankdeflnitionen, Zielsprachen-Code u.v.a.m. Werkzeuge können aber nicht per se existieren. Sie müssen in einem bestimmten Umfeld integriert sein. Integrative Aspekte der Rechnerunterstützung in der Informationssystementwicklung sind in diesem Zusammenhang vor allem (siehe Abbildung 1) [2]: - die einheitliche Gestaltung der Benutzeroberfläche der Werkzeuge für den Mensch-Maschinen-Dialog - die einheitliche S trukturierung der durch die Werkzeuge zu bearbeitenden Daten in einer Entwicklungsdatenbank Ein dritter Integrationsaspekt, welcher eine wichtige Rolle spielt, ist derjenige der Methodenintegration. Die Möglichkeiten zur einheitlichen Gestaltung der Benutzerschnittstellen der Werkzeuge sowie die einheitliche Ablage der Entwurfsdaten alleine reichen nicht aus, um ein integriertes Entwicklungssystem zu erstellen. Methodenintegration bedeutet in diesem Zusammenhang, daß die in den Werkzeugen verkörperten Methodenbestandteile aufeinander abgestimmt sein müssen, insbesondere, daß sie Entwurfsinhalte miteinander kombinieren können.

215

Systemanalytiker-Arbeitsplatz

Benutzeroberflaeche

0X1 p

P

N

P

¿4 u ] ausdruck TO ausdruck [BY ausdruck] DOanweisungen ENDFOR]

if-then-else-block

IF ausdruck THEN anweisungen [ ELSE anweisungen ] ENDIF

case-block

C A S E ausdruck OF konstante {, konstante ) : Anweisung { ; konstante {, konstante} : Anweisung ) [;] { E L S E anweisungen ) ENDCASE

modulaufruf {variable > } ausdruck

Interaktive Entwurfsmethode für Anwendungssoftware

do_while-block

WHILE ausdruck DO anweisungen ENDWHILE

repeat_unil-block

REPEAT anweisungen UNTIL ausdruck;

typ

bezeichner | INTEGER [ ausdruck [ , ausdruck ] ] | FIXED [ausdruckt, aisdruck]] | FLOAT [ ausdruck f, ausdruck ] ] | STRING [ausdruck]! ARRAY [ indexbereich { , indexbereich} ] OF einfadier-typ | RECORD [ einfache-typdefinition { , einfache-typdefinition) 1 ' ausdruck: ausdruck

indexbereich ausdruck

einfacher-ausdruck [ Vergleichsoperator einfacher-ausdruck ]

Vergleichsoperator

EQ| NE | G T | L T | L E | G E

einfacher-ausdruck

[ +1 - ] term {Strichoperator term)

Strichoperator term

+1 -1 OR faktor {punktoperator faktor)

punktoperator

* | / | DIV| MOD | AND

faktor

faktorkonstante | variable | funktionsaufruf | NOT faktor | (ausdruck)

konstante

(+1 - ] vorzeichenk»e_zahl | text f

faktorkonstante

vorzeichenlose-zahl | text |

vorzeichenlose-zahl

ganze-zahl [, ganze-zahl ]

ganze-zahl

Ziffer {Ziffer}

text

' {beliebige-zeichen-auBer-gänsefüßchen | " )•

variable

bezeichner { ' bezeichner | "[ ausdruck { , ausdruck} ]

bezeichner

buchstabe {buchstabe | Ziffer | zeichen-für-unterstrich )

257

258

Interaktive Entwurfsmethode für Anwendungssoftware

A P S • S Syntax Definition jobdefinition

S Y S T E M bezeichner; aktion E N D S Y S T E M ;

aktion

programmaufruf | if-then-else-block

programmaufruf

D O P R O G R A M dateiname [ dateidefinition ] ENDPROGRAM

dateidefinition

A S S I G N dateiname W I T H ( T E R M I N A L | DISK |

)/ dateiname

PRINTER

bezeichner {bezeichner} { . (bezeichner { b e z e i c h n e r } ) )

if-then-else-block

IF ausdruck T H E N aktions-sequence [ E L S E aktions-sequence ] ENDIF

aktions-sequence

aktion { ; aktion}

ausdruck

R E T U R N C O D E vetgleichsoperator konstante

konstante

[ + 1 - ] vorzeichenlose_zahl

Vergleichsoperator

EQ|NE|GT| LT|LE|GE

bezeichner

buchstabe {buchstabe | ziffer | zeichen-fOr-unterstrich 1

Structure Chart Syntax Definition structure Chart

sc-operator id name diagram end-operator.

diagram

module {module}reference{reference) (proc-annotation).

module

module-operator id name location.

relerence

reference-operator id from-module »-module (parameter) (flag).

trom-module

source-operator id location.

to-module

dest-operator id location (location).

proc-annotiation

proc-operator id ref-operator Id (id) location (location).

Parameter

parm-operator id name location location.

Dag

flag-operator Id name location location.

location

location-operatorrealreal.

angle

angle-operator integer.

259

Interaktive Entwurfsmethode für Anwendungssoftware sc-operator

"SC.

module-operator

"MODULE"; TIB-MODULE"; "MACRO"; TIB-MACRO"; "DATA".

reference-operator

"REFERENCE".

source-operator

"FROM".

dest-operator

"TO".

proc-operator

"LOOP";"COND".

parm-operator

"INPUT; "OUTPUT; "TOANS".

dag-operator

"IN-FLAG"; "OUT-FLAG".

location-operator

"AT.

angle-operator

"ANGLE".

end-operator

"END-SC".

name

"" {lener; digit; point; special_ehar soft-hyphen) "

ident

digit {digit} point {digit (digit) point),

real

digit (digit) point digit {digit),

integer

digit (digit).

letter

B'; 'C; t)'; f ; F ; t3'; W ; T; 'J'; K'; ! ' ; Uff; TT; '0';

'Q'; W ; S'; T ; U ; V ; W ;

X ; Y ; T ; 'A'; "Û"; ÎT; 'a'; V ; 'c'; 'd'; 'e'; t ; 'g'; ti'; T; Î ; V ; T; 'm'; 'n'; 'o'; "p"; 'q'; V; 's'; T; •u'; V ; V ; V ; "y'; digit

'»'; '6'; '0"; 'fl'.

"O"; '1'; "2'; '3'; '4'; S"; "6'; T ; H'; "9'.

point spedal_char

' '; '-'; '_'.

soft-hyphen

Dataflow Diagram Syntax Definition did

dfd-operator id name diagram end-operator.

diagram

object (object) relation (relation).

object

object-operator id name location.

relation

relation-operator id name location df-typ1; df-typ2.

df-typl

[from-object] to-object (to-object).

df-typ2

from-object (from-object) [to-object].

from-object

source-operator id location (location).

to-object

dest-operator id location (location).

location

location-operator real real.

260

Interaktive Entwurfsmethode für Anwendungssoftware

dfd-operator

'DFD\

diagram-operator

•DIAGRAM'.

object-operator

•EXTERNAL'; T I E ' ; 'PROCESS'.

relation-operator

•DATAFLOW.

source-operator

•FROM'.

dest-operator

•TO'.

location-operator

•AT.

end-operator

•END-DFD'.

name

' " ' {letter; digit; point; speeial_char soft-hyphen) '

ident

digit {digit) point (digit {digit) point),

real

digit (digit) point digit (digit).

letter

•A'; •B'; 'C; TT; "E"; "F; 'G'; W; T; 'J'; K'; ! ' ; W ; N ; 'O'; "P"; 'Q'; W; S ; T ; Ü ; 'V; W ; * ; T ; T: 'A'; 'ô'; ÎT; 'a'; V ; V; 'd'; 'e'; T; 'g'; t ï ; T; T; V : T; 'm'; 'n'; 'o'; 'p'; 'q'; Y; 's';

T; 'u'; V; V; Y; y; Y; 'â'; 'ô'; 'û'; '8'. digit point speaal_char soft-hyphen

•0'; T ; '2'; S'; '4'; S'; tf; T ; '8'; V.

Projektmanagementebenen bei evolutionärer Softwareentwicklung Karl Kurbel,

Wolfram

Pietsch

Inhalt 1 Einordnung des Beitrags 2 Projektmanagement bei Softwareentwicklungsprojekten 3 Elemente eines Projektmanagementansatzes 3.1 Drei-Ebenen-Modell der Planung und Kontrolle 3.1.1 Strategische Planung des Entwicklungsverlaufs 3.1.2 Projektstrukturplanung 3.1.3 Operative Ebene 3.2 Differenzierte Modellierung der Projektstruktur 3.3 Dezentrale Planung durch Abstimmung 4 Konzeption eines Projektmanagementsystems für evolutionäre Softwareentwicklungen 4.1 Umsetzung des Projektmanagementansatzes 4.1.1 Arbeitsplatzorientierung und Drei-Ebenen-Modell 4.1.2 Differenzierte Modellierung durch Nutzung wissensbasierter Methoden 4.1.2.1 Vorteile wissensbasierter Methoden 4.1.2.2 Einbettung wissensbasierter Methoden in konventionelle Softwareumgebungen 4.1.3 Integrierter Task-Manager als Instrument für die dezentrale Planung 4.2 Systemaufbau 4.2.1 Grobarchitektur 4.2.2 Aufbau der Projektdatenbank 4.2.3 Aufbau der Wissensbasis 5 Implementierung Anmerkungen Literatur

1 Einordnung des Beitrags Ziel des Vorhabens "Konzeption und Realisierung eines wissensbasierten Projektmanagementsystems zur Planung und Kontrolle evolutionärer Softwareentwicklungen" ist die Unterstützung des Projektmanagements bei Entwicklungsprojekten, die nicht nach einem klassischen Phasenmodell ablaufen, z.B. Prototypingprojekte,

262

Projektmanagement bei Softwareentwicklung

Expertensystementwicklungen u.a. In dem Vorhaben, das eine Laufzeit von zwei Jahren (1988-1989) hat, wird ein interaktives Projektmanagementsystem für derartige Entwicklungen spezifiziert und prototypisch realisiert Der Beitrag stellt den unterschiedlichen Ansatz gegenüber dem klassischen Projektmanagement dar. Er beschreibt die Grobkonzeption des Projektmanagementsystems und gibt Hinweise zur Systemarchitektur, die auf einem Drei-Ebenen-Modell basiert.

2 Projektmanagement bei Softwareentwicklungsprojekten Die Erstellung eines größeren computergestützten Informationssystems für die betriebliche Praxis ist eine komplexe Aufgabe, die nicht nur die Lösung softwareund hardwaretechnischer Probleme beinhaltet, sondern auch adäquater Planung und Steuerung bedarf. Die traditionellen Methoden des Projektmanagements stammen aus Anwendungsgebieten wie dem Bauwesen und der industriellen Fertigung. Bei Projekten in diesen Bereichen kann auf eindeutig festgelegte Konstruktions- und Arbeitspläne zurückgegriffen werden. Anhand dieser Pläne wird ein Projekt in einzelne, klar abgegrenzte Arbeitsschritte untergliedert, die eine bestimmte Zeitdauer beanspruchen, bestimmte Ressourcen binden und in einer festen zeitlichen Relation zueinander stehen. Das Gesamtprojekt wird als Summe der einzelnen Arbeitsschritte angesehen. Als wichtigste Methode für die Planung und Kontrolle von konstruktionstechnischen Projekten gilt die Netzplantechnik [1], Die am weitesten verbreiteten Verfahren sind die Critical Path Method (CPM) und die Program Evaluation and Review Technique (PERT) [2]. Auf der Basis dieser Methoden und Verfahren entstanden zahlreiche Softwaresysteme für das Projektmanagement. Vorrangig werden die folgenden Aufgabenbereiche unterstützt [3]: - Projektplanung sowie Dokumentation der Projektstruktur und des Projektablaufs - Projektüberwachung (insbesondere Termin-, Kosten- und Ressourcenkontrolle) - Projektberichtswesen - Analyse von Projekten Die gängigen Vorgehensweisen bei der Durchführung von Softwareentwicklungsprojekten orientieren sich am klassischen Modell des Softwarelebenszyklus [4]. Dieses Modell kann als eine Konstruktionssystematik interpretiert werden: Der Softwarelebenszyklus wird in eine lineare Abfolge von Teilaktivitäten zerlegt, die

Projektmanagement bei Softwareentwicklung

263

wiederum nach funktionalen Aspekten untergliedert werden können. Wenn man Softwareentwicklungsprojekte nach einem linearen Phasenmodell wie ein konstruktionstechnisches Vorhaben konzipiert und durchführt, kann man auf die Methoden und Instrumente des traditionellen Projektmanagements zurückgreifen. Bedingt durch ihre Entwicklungsgeschichte sind die verfügbaren Projektmanagementsysteme primär auf Fertigungsprojekte ausgerichtet. Softwareentwicklungsprojekte können mit ihrer Hilfe zwar so geplant und kontrolliert werden wie Fertigungsprojekte; spezifische Eigenschaften wie die folgenden werden aber nicht berücksichtigt: - Eine eindeutige Unterteilung des Entwicklungsablaufs in disjunkte Schritte ist bei Softwareentwicklungsprojekten nur bedingt möglich. Zwischen den einzelnen Phasen bestehen Interdependenzen und Überlappungen. Teilweise erfolgt die Entwicklung in Zyklen. - Während bei konstruktionstechnischen Vorhaben viele Teilaktivitäten unabhängig voneinander geplant und gesteuert werden können, sind bei Softwareentwikklungen die meisten Aufgabenbereiche miteinander verwoben. - Die traditionellen Projektmanagementsysteme unterstützen nur den formalen Informationsaustausch zwischen den Projektbeteiligten. Erfahrungsgemäß ist aber gerade die informelle Kommunikation - u.a. wegen der vielfältigen, nicht planbaren Interdependenzen in einem Softwareentwicklungsprojekt - eine wichtige Determinante des Projekterfolgs. - Bei Fertigungsprojekten können Überlastsituationen oft durch Kapazitätsanpassung bewältigt werden, indem mehr Ressourcen eingesetzt oder Umschichtungen vorgenommen werden. Bei der Softwareentwicklung sind personelle Umdispositionen wegen des hohen Einarbeitungsaufwands und des zusätzlichen Kommunikationsaufwands nur bedingt möglich. Das "Brooks'sche Gesetz" besagt sogar, daß zusätzliches Personal bei Terminverzug kontraproduktiv ist: "Adding manpower to a late project makes it later" [5]. Ein möglicher Einwand gegen die Kritik am traditionellen Softwareprojektmanagement ist, daß die Reduktion einer Softwareentwicklung auf einen konstruktionstechnischen Prozeß in Kauf genommen werden kann, weil so zumindest eine methodische und instrumenteile Unterstützung des Projektmanagements möglich ist und es an gangbaren Alternativen mangelt Dieses Argument ist zunächst nicht von der Hand zu weisen. Die Effektivität der traditionellen Verfahren hängt jedoch insbesondere von drei Faktoren ab: - Es müssen sich Teilaktivitäten identifizieren lassen, die entweder unabhängig voneinander sind oder in einer klaren zeitlichen Relation zueinander stehen.

264

Projektmanagement bei Softwareentwicklung

- Die Aktivitätendauern müssen sich zuverlässig festlegen bzw. schätzen lassen. - Es muß möglich sein, die Anforderungen an eine Problemlösung im voraus zu spezifizieren, und die Anforderungen müssen im Zeitablauf stabil bleiben. Sind diese Voraussetzungen nicht erfüllt, weisen lineare Modelle erhebliche Schwächen auf [6], Wenn etwa die Anforderungen vorab nicht exakt festliegen oder wenn Zwischenergebnisse zu Rückkopplungen und zu einer Revision der Anforderungen führen, wird auch die Schätzung der Aktivitätendauern zwangsläufig unzuverlässig. Ein "Konstruktionsplan", der im Zeitablauf stabil bleibt, kann nicht mehr aufgestellt werden, und ein linearer Projektverlauf ist nicht sinnvoll. Damit versagen auch die auf einem streng linearen Ablauf basierenden Projektmanagementmethoden. Sie stellen nicht mehr "das geringere Übel" dar, sondern sind weitgehend nutzlos. Für Situationen, in denen das lineare Modell und damit auch das traditionelle Projektmanagement versagen, wurden viele unterschiedliche Vorgehensmodelle insbesondere zyklische sowie flexible Entwicklungsverläufe - vorgeschlagen [7]. Nur in wenigen Fällen wird jedoch neben der Entwicklungsmethodik auch ein Konzept für das Projektmanagement entwickelt, obwohl Entwicklungsmethodik und Projektmanagement voneinander abhängig sind und abgestimmt werden müssen [8]. Zur Entwicklung eines alternativen, integrierten Ansatzes sind Modifikationen der klassischen Methoden und Verfahren unzureichend. Floyd postuliert deshalb einen "Paradigm shift" im Software Engineering - von einer produktorientierten hin zu einer prozeßorientierten Vorgehensweise [9]. Softwareerstellung beschränkt sich nicht auf einen konstruktionstechnischen Ablauf. Sie ist vielmehr ein Prozeß von hoher Dynamik, bei dem vielfältige Interdependenzen zwischen Problemdefinition und Implementierung zu behandeln sind. Dazu ist häufig eine enge Rückkopplung zwischen Entwicklern und Anwendern erforderlich. Softwareentwicklung ist in vielen Fällen ein evolutionärer Prozeß, wie das Beispiel der Expertensysteme zeigt [ 10]: Im Verlauf des Erstellungsvorgangs können zu nicht vorhersehbaren Zeitpunkten sogenannte "Generationssprünge" auftreten; dies bedeutet, daß die Durchführung kleiner Änderungen eine Restrukturierung oder sogar vollständige Reimplementierung des Gesamtsystems erfordert. Dieses Phänomen tritt nicht nur bei Expertensystemen, sondern grundsätzlich bei Entwicklungsvorhaben auf, bei denen die Spezifizierbarkeit und Stabilität der Anforderungen nicht gegeben ist. Instabile oder nicht klar definierbare Anforderungen verursachen nicht-lineare, evolutionäre Entwicklungsverläufe. Es liegt in der Natur evolutionärer Prozesse, daß Wirkung und Zeitdauer einzelner Schritte nicht eindeutig vorhergesagt werden können.

Projektmanagement bei Softwareentwicklung

265

Bei evolutionären Softwareentwicklungen reicht es zur Überwindung der strukturellen Schwächen des traditionellen Projektmanagements und der darauf basierenden Systeme nicht aus, einzelne Mängel zu erfassen und punktuell zu beseitigen. Vielmehr ist eine grundsätzliche Umorientierung geboten. Dazu ist ein anderer Ansatz erforderlich, der von den besonderen Anforderungen der evolutionären Entwicklung ausgeht.

3 Elemente eines Projektmanagementansatzes Für die Verbesserung des Softwareprojektmanagements sind vielfältige Ansatzpunkte denkbar. Der hier vorgestellte Ansatz geht von folgenden Annahmen aus: (1) Eine übergreifende Planung und Kontrolle der einzelnen Entwicklungsaktivitäten ist erforderlich, um die Effektivität des Projektmanagements zu gewährleisten. (2) Softwareentwicklung ist ein kreativer Prozeß. Das Projektmanagement sollte Kreativität unterstützen und lenken. (3) Ein besonders wichtiger Erfolgsfaktor ist die adäquate Kommunikation schen den Projektteilnehmern.

zwi-

Im folgenden wird ein Drei-Ebenen-Modell für die flexible Lenkung evolutionärer Entwicklungen und "kreativer" Prozesse vorgestellt. Weiterhin wird auf die Bedeutung einer differenzierten Modellierung der Projektstruktur für das Projektmanagement eingegangen. Anschließend wird das Konzept einer dezentralen Planung der Entwicklungsaktivitäten durch Abstimmung der an der Entwicklung Beteiligten als integraler Bestandteil des Projektmanagements vorgestellt. Durch die explizite Berücksichtigung kommunikativer Prozesse soll sowohl eine erhöhte Flexibilität erreicht als auch die Selbstverantwortlichkeit der Entwickler und deren Kreativität gestärkt werden. 3.1 Drei-Ebenen-Modell der Planung und Kontrolle In der betrieblichen Praxis hat sich bei komplizierten Aufgabenzusammenhängen die Unterteilung des Planungs- und Kontrollprozesses in verschiedene Problemebenen bewährt. Zum Beispiel wird im Bereich des Finanzwesens zwischen kurz-, mittel- und langfristiger Planung unterschieden, im Marketing etwa zwischen strategischer, taktischer und operativer Planung. Durch Unterteilung der Planung und Kontrolle in verschiedene Teilprozesse mit unterschiedlichen Schwerpunkten können die Komplexität reduziert, eine erhöhte

266

Projektmanagement bei Softwareentwicklung

Transparenz erreicht und Managementziele geordnet werden. So kann die Unterteilung nach Zeithorizonten beispielsweise der Auflösung von Konflikten zwischen kurz- und langfristigen Erfolgszielen dienen; die Aufteilung nach Managementebenen ist u.a. für die Trennung globaler Politiken von Aufgaben der Steuerung und Kontrolle konkreter Aktivitäten hilfreich. Angesichts der vielfältigen Interdependenzen zwischen den Einzelaktivitäten eines Softwareentwicklungsprojekts sind erhöhte Transparenz, Reduktion der Komplexität und Auflösung von Zielkonflikten auch hier wünschenswert. Das Projektmanagement wird deshalb analog in drei Managementebenen für die Planung und Kontrolle, eine strategische, eine taktische und eine operative Ebene, unterteilt: Auf der obersten, strategischen Planungsebene wird das Gesamtprojekt im Sinne einer Entwicklungsstrategie in größere Entwicklungsabschnitte unterteilt. Auf der mittleren, taktischen Ebene werden die Entwicklungsabschnitte in einzelne Aufgaben untergliedert sowie inhaltliche Beziehungen und zeitliche Relationen dargestellt. Die Aufgaben werden auf der untersten, operativen Ebene in konkrete Aktivitäten überführt 3.1.1 Strategische Planung des Entwicklungsverlaufs Als eine wichtige Entscheidung für den Projekterfolg wird die Wahl eines geeigneten Entwicklungsmodells angesehen. Nur für ganz bestimmte Projekte ist das klassische lineare Phasenmodell mit starr sequentiellem Projektverlauf sinnvoll. In vielen Fällen ist es angebracht, den Entwicklungsverlauf durch projektspezifische Modifikationen zu flexibilisieren; in anderen Fällen ist z.B. ein Prototyping-Ansatz vorteilhaft. Welche Entwicklungsmethodik in einem bestimmten Fall vorzuziehen ist, hängt von der Zielrichtung, dem Ausgangsproblem, und - last not least - von Erfahrung und Präferenzen des Entwicklungsteams ab [11]. Da diese Faktoren von Projekt zu Projekt stark differieren können, sollte jedes einzelne individuell geplant und ein strategischer Projektplan entworfen werden. Die Phaseneinteilung des klassisch-linearen Modells oder die Stufen im Rahmen der industriellen Produktinnovation können als ein solcher strategischer Plan aufgefaßt werden. Durch die Vorgabe bestimmter Einzelphasen wird die Entwicklungsstrategie festgelegt: Zuerst soll das Problem analysiert, dann eine Lösung spezifiziert, anschließend codiert und getestet werden. Später wird das System in Betrieb genommen und im Zeitablauf gewartet Bei einer projektspezifischen Entwicklungsstrategie muß der Projektverlauf individuell geplant und eine entsprechende inhaltliche Leitlinie erst geschaffen werden.

Projektmanagement bei Softwareentwicklung

267

Dies erfolgt auf der obersten Ebene des Drei-Ebenen-Modells. Inhalte der strategischen Planung sind die Festlegung von Zielen sowie der Entwurf von Politiken und die Bereitstellung von Ressourcen zu deren Umsetzung. Die strategische Ebene bildet die Schnittstelle zur Gesamtorganisation, denn hier werden Ressourcen in Form von Personal, Rechnerkapazitäten und Sachmitteln verplant. Um diese Ressourcen konkurrieren in der Regel andere Projekte oder andere Organisationseinheiten. 3.1.2 Projektstrukturplanung Ausgehend von den Vorgaben aus der strategischen Planung wird auf der taktischen Ebene ein konkreter Projektstrukturplan entworfen und als Grundlage für die Überwachung und Steuerung des Entwicklungsablaufs eingesetzt Im Projektstrukturplan werden die einzelnen Aufgaben und die Abhängigkeiten der Aufgaben untereinander sowie in Bezug auf die verfügbaren Ressourcen dokumentiert. Auf diese Weise können komplexe Interdependenzen (z.B. zwischen Modulspezifikation, Qualitätssicherung und Implementierung) differenziert modelliert werden. Weiter ist es möglich, durch entsprechende Aufgabendefinition Zielkonflikte zwischen den verschiedenen Rollen in einem Entwicklungsprojekt offen zu legen (z.B. Konflikte zwischen der am Benutzer orientierten Erhebung der Anforderungen einerseits und der effizienten Implementierung andererseits). Bei der Steuerung des Entwicklungsverlaufs werden die Informationen aus dem Projektstrukturplan in konkrete Aktionen umgesetzt Die Abhängigkeiten der Aufgaben und Ressourcen müssen im Hinblick auf eventuelle Kommunikationsbedarfe und notwendige Steuerungsmaßnahmen untersucht werden, d.h., wichtige Kommunikationskanäle müssen ausgemacht und entsprechende organisatorische Maßnahmen veranlaßt werden. Der geregelte Austausch und die Kontrolle von Ergebnissen kann z.B. durch regelmäßige Sitzungen, Abnahme der Zwischenergebnisse und eine Projektbibliothek zur Versionsverwaltung unterstützt werden. Während der strategische Entwicklungsplan für die gesamte Entwicklung vorgegeben wird, erfolgt die Erstellung des Projektstrukturplans rollierend, d.h., er wird für einen längeren Zeitraum entworfen, vor Ende dieses Zeitraums überarbeitet und für einen weiterreichenden Zeitraum neu entwickelt Dadurch ist sichergestellt, daß auch langfristige Restriktionen in der Planung berücksichtigt werden. Gleichzeitig wird der Tatsache Rechnung getragen, daß langfristige Pläne i.d.R. durch kurzfristige Veränderungen der Ausgangsbedingungen schon vor Ende des Planungszeitraums einer grundlegenden Revision bedürfen. Die flexible Anpassung an Veränderungen ist bei evolutionärer Softwareentwicklung besonders wichtig.

268

Projektmanagement bei Softwareentwicklung

Eine gängige Vorgehens weise zur Kontrolle des Projektfortschritts ist die Überprüfung vordefinierter Ergebnisse zu festen Endterminen ("Meilensteine"). Die Fixierung auf absolute Endtermine birgt mehrere Gefahren: - schlechte Fortschrittskontrolle durch Überwachungs-"Loch" zwischen den Terminen, - Termineinhaltung gerät zum Selbstzweck; der Bezug zu den "eigentlichen" Projektzielen geht verloren, - psychologisch begründete, ineffiziente Arbeitsökonomie im Sinne des "Deadline-Effekts" nach Boehm: "The amount and energy devoted to an activity is strongly accellerated as one approaches the deadline for completing the activity" [12]. Zur Beseitigung dieser Gefahren wird eine Alternative zur absoluten Terminierung und punktuellen Überprüfung vorgeschlagen, nämlich die relative Terminierung und die ständige projektbegleitende Analyse der (relativen) Termintreue. Dazu müssen bei der Aufstellung des Projektstrukturplans Schätzungen des relativen Aufwands für die Ausführung der einzelnen Aufgaben durchgeführt werden, d.h. Schätzungen des Aufwands im Verhältnis zu bestimmten Aufgaben des gleichen Projekts, die bereits ausgeführt oder verläßlicher abschätzbar sind. Die Projektfortschrittskontrolle wird zur Qualitätssicherung aufgewertet. Sie zielt nicht auf die sklavische Einhaltung von Terminen und auf die Erfüllung von Einzelergebnissen ab; sie betrachtet vielmehr die Aufgaben im Verhältnis zueinander und gewichtet Ergebnisse in Bezug auf die Projektziele. Bei Terminkonflikten oder Engpässen kann sie einzelne Aufgaben priorisieren oder bestimmte Qualitätsvorgaben kurzfristig lockern. 3.1.3 Operative Ebene Gegenstand der Planung und Kontrolle auf der operativen Ebene ist die Tagesarbeit der Projektmitglieder. Die relativen Termine aus der taktischen Planung werden hier in absolute Termine umgesetzt und in die persönlichen Arbeitspläne für jeden Projektteilnehmer aufgenommen. Dazu werden die taktischen Aufgaben in konkrete Teilaufgaben unterteilt, Ausschüsse oder Arbeitsgruppen formiert, Sitzungstermine spezifiziert und die Einzeltermine der Projekt-Teilteams koordiniert. Der Rahmen für die Festlegung dieser konkreten Aktivitäten ist durch den Projektstrukturplan vorgegeben. Die auf der mittleren Ebene definierten Maßnahmen zur Projektsteuerung und Kontrolle werden hier umgesetzt, z.B. durch Bildung von Arbeitsgruppen mit bestimmten Aufgaben und Verantwortung. Die Ergebnisse (z.B. in Form von Vollzugsmeldungen oder Ergebnisberichten) werden wiederum an die mittlere Ebene weitergegeben.

Projektmanagement bei Softwareentwicklung

269

3.2 Differenzierte Modellierung der Projektstruktur Die traditionellen Methoden des Projektmanagements wie die Netzplantechnik stellen für die Modellierung der Projektstruktur nur bescheidene Möglickeiten zur Verfügung. Sie sind i.d.R. auf einfache Vorgänger- und Nachfolgerrelationen bei fester Zuteilung von Ressourcen beschränkt. Die Beschreibung zyklischer bzw. iterierender Abläufe, die bei evolutionären Entwicklungsprozessen üblich sind, wird nur unzureichend unterstützt. Die beschränkten Ausdrucksmittel sind für die reine Beschreibung von Projektstrukturen im Anlagenbau oder in der industriellen Fertigung meist ausreichend. Für Softwareentwicklungsprojekte ist jedoch eine Modellierung der Projektstruktur erforderlich. Der gegenseitige Austausch von Anforderungen und Ergebnissen zwischen den Aufgabenbereichen Anforderungsdefinition und Implementierung bei evolutionärem Entwicklungsverlauf ist ein B eispiel für eine komplexe Aufgabenbeziehung, die den Rahmen der klassischen Methoden sprengt. Wie bereits in Kapitel 1 erwähnt, sind die meisten Entwicklungsaktivitäten in Softwareprojekten auf irgendeine Art und Weise miteinander verwoben. Besonders wichtige Erscheinungsformen von Abhängigkeiten sind u.a. Anstoß- ("Trigger"-) bzw. Hemm-Beziehungen, zyklische Abläufe, Überlappungen, Beeinflussung einer Aufgabe durch Zwischenergebnisse einer anderen (wichtiger Spezialfall: Synergie) und positive oder negative Korrelation zwischen Aktivitätendauern. Diese Abhängigkeiten stellen, soweit sie bekannt sind, wichtige Informationen für die Planung und Kontrolle des Projektverlaufs dar. Sie müssen deshalb differenziert modelliert werden. Da die tradionellen Methoden und Techniken dazu nicht ausreichen, sind neue Ansätze erforderlich. Mit der differenzierten Modellierung der Projektstruktur wächst auch die Komplexität des Projektstrukturplans. Bereits einfache Projektpläne werden schnell unübersichtlich, denn der vollständige Projektplan enthält eine Fülle von Informationen. Nicht alle Informationen sind für die Ausführung einer bestimmten Tätigkeit erforderlich. Jeder Projektteilnehmer benötigt immer nur einen kleinen Ausschnitt aus dem Gesamtplan. Die Art und Weise, wie die Informationen aufbereitet sein sollten, ist ebenfalls von der jeweiligen Aufgabe eines Teammitglieds abhängig: So sind für die Systementwicklung spezifische Detailinformationen über Einzelaktivitäten interessant, während für die Projektsteuerung oft aggregierte Größen, z.B. über den Entwicklungsfortschritt bestimmter Teilteams, benötigt werden. Die Modellierung der Projektstruktur ist nicht Selbstzweck, sondern bildet die Grundlage für verschiedene Auswertungen. Statische Analysen der klassischen

270

Projektmanagement bei Softwareentwicklung

Netzplantechnik - wie z.B. die Angabe von Pufferzeiten und kritischen Pfaden oder einfache Soll-Ist-Vergleiche - reichen dazu nicht aus. Für die aktive Projektsteuerung und -planung ist eine dynamische Analyse der Projektablaufstruktur erforderlich, denn hier soll der Entwicklungsprozeß gestalterisch beeinflußt werden. Durch Simulation verschiedener Handlungspläne, unterstützt von Sensitivitätsanalysen, können Auswirkungen unterschiedlicher Entscheidungssituationen im Projektverlauf untersucht und flexible Strategien entworfen werden. Für die Analyse des Projektverlaufs und für andere Aufgabenbereiche des Projektmanagements wie die Aufwandschätzung sind starre Verfahren nicht ausreichend. Im Mittelpunkt wirklicher Management-Entscheidungen steht die Erfahrung. Schon seit längerem wird versucht, den Faktor Erfahrung methodisch zu erfassen und für das Projektmanagment nutzbar zu machen. Traditionelle, auf Kennzahlen basierende Ansätze - wie die von Noth vorgeschlagene Erfahrungsdatenbank [13] - sind für klassisch-lineare Projekte geeignet; evolutionäre Projekte können mit dieser Methode nicht adäquat behandelt werden. Bei der Erstellung von Kennzahlensystemen wird nämlich i.d.R. vorausgesetzt, daß die für den Projekterfolg wichtigen Kriterien bekannt, kardinal meßbar, intrapolierbar und extrapolierbar sind. Die gängigen Kriterien zur Quantifizierung des Entwicklungsaufwands, z.B. die "lines of code" oder der berühmte "mythical man month" [ 14], sind nicht besonders aussagekräftig. Für evolutionäre Softwareentwicklungen ist der Versuch einer Quantifizierung von "Projekteigenschaften" noch fragwürdiger, weil sich die Anforderungen an das Produkt und damit die relevanten Kriterien im Zeitablauf ändern können. Für die Formulierung kardinal meßbarer Kriterien fehlen damit die wichtigsten Grundlagen. Mit Hilfe wissensbasierter Systeme kann Erfahrungswissen über das Management von Softwareentwicklungsprojekten abgebildet und auf spezifische Problemsituationen, z.B. die Aufwandschätzung, angewendet werden. Die Akquisition dieses Erfahrungswissen ist jedoch sehr aufwendig; die codierten Wissensbasen sind oft nur kurzlebig, wenn sie nicht ständig durch neue Erfahrungen aus Projekten ergänzt werden. Durch neue Forschungsanstrengungen im Bereich der Künstlichen Intelligenz in Hinblick auf die Darstellung und Verarbeitung fallorientierten Erfahrungswissens eröffnen sich neue Perspektiven für die Nutzung von Erfahrungen. Jedoch steht die Forschung hier noch am Anfang, und es sind nur wenige konkrete Ergebnisse verfügbar [15].

Projektmanagement bei Softwareentwicklung

271

3.3 Dezentrale Planung durch Abstimmung Bei der Projektplanung und -kontrolle auf Basis des linearen Modells sind die einzelnen Phasen starr vorgegeben. Sie werden schrittweise in Einzelaufgaben aufgespalten, bis einzelne, ausführbare Aktivitäten übrigbleiben. Der Planungsprozeß verläuft top-down und liegt zentral in der Hand des Projektleiters oder Projektmanagers; Rückkopplungen mit bzw. zwischen den Ausführenden bilden die Ausnahme. Voraussetzung für eine solche hierarchische Projektplanung ist, daß auch die Detailplanung der Einzelaktivitäten in zentraler Hand liegt. Bei evolutionären Softwareentwicklungsprojekten ist es jedoch sehr schwierig, die einzelnen Entwicklungs- und Planungsprobleme im Detail vorab zu überschauen bzw. verläßlich abschätzen. Der Fortgang und das Ergebnis der Entwicklung kann nur bedingt langfristig vorausgeplant werden. Der Entwicklungsverlauf muß ständig an die jeweiligen Erfordernisse angepaßt werden. Die strategische Planung eines Entwicklungsprojekts im Sinne des Drei-EbenenModells muß zentral durch die Projektleitung erfolgen. Auch die Projektstrukturplanung erfordert eine globale Betrachtung des Entwicklungsverlaufs. Im Bereich der operativen Planung und Kontrolle ist jedoch eine partielle Verlagerung der Verantwortung auf dezentrale Organisationseinheiten möglich: Die einzelnen Projektteilnehmer können im Rahmen eines bestimmten Spielraums selbstverantwortlich entscheiden, wann sie welche Aufgaben ausführen. Die Koordinierung der Aktivitäten mit anderen Projektteilnehmern - unter anderem auch die Austragung von Zielkonflikten - nehmen sie in die eigene Hand. Da sie selbst verantwortlich sind, müssen sie auch selbst sicherstellen, daß Vorleistungen rechtzeitig verfügbar sind. So ist es möglich, auch die Projektkontrolle teilweise zu dezentralisieren. Dadurch wird nicht nur eine zentrale Feinplanung über die auf der mittleren Ebene initiierten Steuerungs- und Kontrollaktionen hinaus überflüssig; auch die Kreativität der Softwareingenieure wird gefördert, weil die in konventionellen Projekten oft übliche strenge Reglementierung teilweise entfällt. Die einzelnen Mitarbeiter ordnen ihre persönlichen Aktivitäten in eigener Verantwortung und in Zusammenarbeit mit anderen Projektmitgliedem. Die eigentliche Planung auf dieser Ebene erfolgt durch Abstimmung der Mitarbeiter untereinander, d.h., die Terminierung ist völlig flexibel und kann sich täglich ändern.

272

Projektmanagement bei Softwareentwicklung

4 Konzeption eines Projektmanagementsystems für evolutionäre Softwareentwicklungen Der in Kapitel 3 vorgestellte Ansatz gibt eine bestimmte Sicht der Aufgaben und Ziele des Projektmanagements wieder. Zur Anwendung auf reale Projekte müssen jedoch besondere rechnergestützte Instrumente entwickelt werden. Diese sind sehr anspruchsvoll und können nur durch Anwendung moderner Informations- und Kommunikationstechnik realisiert werden. Im weiteren wird die Umsetzung des vorgeschlagenen Ansatzes erläutert und der Aufbau eines entsprechenden Projektmanagementsystems skizziert. 4.1 Umsetzung des Projektmanagementansatzes 4.1.1 Arbeitsplatzorientierung und Drei-Ebenen-Modell Ein Projektmanagementsystem auf der Basis des Drei-Ebenen-Modells ist nicht nur auf die Informationsbedürfnisse des klassischen Projektmanagers ausgerichtet, sondern dient allen Projektteilnehmern zur Koordinierung der Aktivitäten. Die Projektdaten sind für den Projektleiter ebenso wichtig wie für den Systemprogrammierer. Allerdings sehen verschiedene Projektteilnehmer die Projektdaten bzw. die Projektstruktur aus einer anderen Perspektive. Deshalb kann das Projektmanagementsystem nicht starr und monolithisch sein, sondern muß für jeden Projektteilnehmer entsprechend seiner Aufgaben quasi maßgeschneidert werden. Ändern sich die Aufgaben im Entwicklungsverlauf, sollte das System in seiner Funktionalität angepaßt werden oder sich sogar automatisch anpassen: Das System sollte ein sogenanntes Benutzermodell verwalten [16]. Durch die direkte Anpassung des Systems an Rollen und Aufgaben werden auch die auszuführenden Funktionen für die Projektteilnehmer transparenter, und die Identifikation mit den Aufgaben fällt leichter. 4.1.2 Differenzierte Modellierung durch Nutzung wissensbasierter Methoden 4.1.2.1 Vorteile wissensbasierter Methoden Anders als bei konventionellen Computerprogrammen, die vor allem Daten verarbeiten, steht bei wissensbasierten Systemen die Behandlung und Auswertung von Wissen im Vordergrund. Dieses unterscheidet sich von konventionellen Daten durch seine von der Verarbeitung getrennte und explizite Repräsentation.

Projektmanagement bei Softwareentwicklung

273

Eine verbreitete Methode der Wissensdarstellung sind Regeln der Form WENN Bedingung DANN Konsequenz Die Regeln werden in einer Wissensbasis abgespeichert und von einer für unterschiedliche Wissensbasen einsetzbaren Abarbeitungskomponente verarbeitet. Prinzipiell wird die Reihenfolge der Abarbeitung - anders als bei konventionellen Softwaresystemen - erst zur Laufzeit bestimmt; fehlende Informationen werden vom Benutzer erfragt. Außerdem können sehr einfach weitere Regeln, die z.B. bestimmte Ausnahmefälle beschreiben, hinzugefügt werden. Oft sind derartige Veränderungen sogar noch zur Laufzeit möglich und können durch andere Regeln ausgelöst werden. Ein weiteres wichtiges Merkmal der wissensbasierten Systeme ist, daß während der Verarbeitung eine explizite Darstellung der Wissenseinheiten existiert. Falls diese z.B. als Regeln verständlich formuliert wurden, können sie zur Erklärung eines bestimmten Systemzustands herangezogen werden. Für die Modellierung der Projektstruktur in einem Projektmanagementsystem bietet die wissensbasierte Darstellung verschiedene Vorteile: - Aufgaben und Rollen sowie deren Beziehungen zueinander können differenziert beschrieben werden; durch die verarbeitungsunabhängige Darstellung des Wissens kann dieses leicht für unterschiedliche Auswertungszwecke genutzt werden. - Allgemeine Vorgaben und situative Ausnahmen können als Regeln im Projektmanagementsystem dargestellt werden; es können branchen-, Unternehmens- und projektspezifische Regelungen wie z.B. Qualitätsmaßstäbe, Richtlinien für die Durchführung und disziplinarische Maßnahmen in das Projektmanagementsystem integriert werden. - Ein großer Teil des Projektmanagementsystems wird auf der Basis projektunabhängigen Wissens entwickelt. Durch Hinzufügen der projektspezifischen Bedingungen und Ausnahmen kann das System sozusagen für jedes konkrete Projekt maßgeschneidert werden. Durch Auswertung und Abspeicherung relevanter Fakten aus erfolgreichen und nicht erfolgreichen Projekten kann im Laufe der Zeit Erfahrungswissen angesammelt werden. Wenn in einem früheren Projekt eine bestimmte Konstellation zu Problemen führte, so kann dieses Wissen vielleicht in einem späteren Projekt dazu genutzt werden, die einmal gemachten Fehler zu vermeiden.

274

Projektmanagement bei Softwareentwicklung

4.1.2.2 Einbettung wissensbasierter Methoden in konventionelle Softwareumgebungen Die Realisierung wissensbasierter Systeme erfolgt meist mit Hilfe spezieller KIProgrammiersprachen oder Werkzeuge, z.B. Expertensystem-Shells. Diese weisen für die Erstellung operativer Systeme Nachteile auf. Kl-Programmiersprachen wie Lisp oder Prolog zeichnen sich zwar durch mächtige und flexible Sprachmittel aus. Es existieren jedoch noch keine überzeugenden Ansätze für die Anbindung an bestehende Softwaresysteme und Datenbanken. Probleme ergeben sich insbesondere durch unterschiedliche Typenspektren, Anforderungen an Zugriffsoperationen sowie in Bezug auf die ErklärungsfähigkeiL Letzteres gilt insbesondere für Expertensystem-Shells. Dies sind Werkzeuge zur Entwicklung von Expertensystemen für bestimmte Problemklassen. Sie ermöglichen zwar eine hohe Produktivität, sind aber dafür i.d.R. relativ starr und nur für die Entwicklung von Insellösungen geeignet. Die Entwicklung "offener" Entwicklungswerkzeuge wird vorangetrieben [17], jedoch ist hier noch umfangreiche Forschungsarbeit zu leisten. Ein Nachteil der verfügbaren Werkzeuge ist, daß die Verarbeitung des als verarbeitungsunabhängig deklarierten Wissens nur innerhalb eines engen, durch die zur Verfügung gestellten Verarbeitungsstrategien bestimmten Rahmens beeinflußt weiden kann. Oft wäre es aber wünschenswert, problemspezifische Abarbeitungsstrategien entwickeln zu können [18]. Gegen die Realisierung einer Projektwissensbasis mit einem KI-spezifischen Werkzeug sprechen nicht nur die gegenwärtigen Beschränkungen der Softwaretechnologie; es gibt weitere, grundsätzlichere Agrúmente: - Das konzipierte Projektmanagementsystem ist sehr komplex, so daß die Anwendung von Prinzipien und Methoden des Software Engineering naheliegt. Die KIspezifischen Werkzeuge sind mit diesen jedoch nicht recht "kompatibel"; Programmierung "im Großen" wird zur Zeit nur unzureichend unterstützt - Ein großer Teil der funktionalen Anforderungen an das Projektmanagementsystem entspricht den Anforderungen an ein traditionelles Informationssystem, d.h. Verwaltung und Auswertung von Daten. Nur für spezielle Problemstellungen ist es erforderlich, "Wissen" darzustellen und Schlußfolgerungen abzuleiten. Wegen der Integrationsschwierigkeiten mit operativen Systemen ist eine Auslagerung bestimmter Aufgabenkomplexe in ein oder mehrere wissensbasierte (Sub-) Systeme nicht sinnvoll. Forschungsergebnisse am Lehrstuhl für Wirtschaftsinformatik zeigen, daß eine Einbettung wissensbasierter Techniken in konventionelle Softwaresysteme bei bestimmten Anwendungsproblemen erfolgversprechender ist:

Projektmanagement bei Softwareentwicklung

275

Kann innerhalb konventioneller Entwicklungswerkzeuge auf wissensbasierte Techniken zugegriffen werden, so ist es möglich, deren Vorteile zu nutzen und dennoch auf Software-Engineering-Knowhow nicht zu verzichten [19]. 4.1.3 Integrierter Task-Manager als Instrument für die dezentrale Planung Die Abstimmung zwischen den Teammitgliedern ist ein kritischer Faktor bei Softwareentwicklungsprojekten. Bei evolutionärer Entwicklung ist es besonders schwierig, oft sogar unmöglich, die Anforderungen an das Entwicklungsergebnis und an die Art und Weise der Realisierung exakt zu spezifizieren; deshalb besteht bei der Aufteilung von Arbeiten ein noch größeres Risiko von Mißverständnissen und Fehlinterpretationen. Werden Unstimmigkeiten zu spät erkannt, kann dies weitreichende Auswirkungen haben. Je besser die Kommunikation und Abstimmung zwischen den einzelnen Projektteilnehmern funktioniert, desto geringer ist die Wahrscheinlichkeit für das Auftreten von Problemen. Oft liegen Probleme nur darin begründet, daß die einzelnen Projektteilnehmer nicht wissen, mit wem sie sich wann und worüber abstimmen sollten. Neben den klassischen, formalen Kommunikationsformen wie Berichten (Abschluß-, Abnahme-, Mängelberichte etc.) sind informelle Formen der Kommunikation (z.B. kurzfristige Arbeitstreffen oder wichtige Mitteilungen über Änderungen in Spezifikationen oder Implementationen) wichtige Träger des Projektfortschritts. Neben der inhaltlichen Koordinierung hat die Abstimmung noch eine weitere wichtige Funktion, nämlich in Bezug auf die Arbeitseinteilung der Projektmitglieder: Wenn beispielsweise frühzeitig transparent ist, daß und ab wann ein anderes Teammitglied auf bestimmte Ergebnisse wartet, kann die Priorität der eigenen Arbeit sicherlich besser eingeschätzt werden. Ein computergestütztes System zur Unterstützung der Abstimmung muß einen Terminkalender verwalten und direkte Hilfe für formale und informelle Kommunikationsformen anbieten. Regelmäßige Berichte oder Besprechungen sowie feste Termine für Endabnahmen müssen in die Terminkalender der Projektbeteiligten eingebracht und schnelle, kontrollierte Kommunikationswege zwischen den Projektbeteiligten geschaffen werden. Ein Softwaresystem, das diese Aufgabe erfüllt, soll als Task-Manager bezeichnet werden. Man kann sich einen Task-Manager als eine Art elektronischen Terminkalender mit integrierter intelligenter Mailbox vorstellen. Der Task-Manager muß schnelle, kontrollierte Kommunikation ermöglichen und deshalb in das Projektmanagementsystem integriert werden. Er braucht also Zugriff auf die Projektdaten und trägt aktiv zur Beschreibung der Projekt-Feinstruktur bei.

276

Projektmanagement bei Softwareentwicklung

Der Task-Manager unterstützt die Teammitglieder bei der zeitlichen und inhaltlichen Koordinierung der vielfältigen Aktivitäten. Er ist primär ein Instrument für die Projektbeteiligten. Außerhalb des normalen Abstimmungsprozesses haben Projektmanagement und andere Projektteilnehmer nur beschränkte Zugriffsrechte auf die individuellen Arbeitspläne. 4.2 Systemaufbau 4.2.1 Grobarchitektur Im folgenden wird die mehrschichtige, modulare Struktur des Projektmanagementsystems beschrieben. Sie folgt der eben dargestellten Systemkonzeption und bildet die Grundlage für die Entwicklung des Prototyps. Abbildung 1 zeigt die Grobarchitektur. Die Architektur kann in drei Schichten unterteilt werden: Auf der obersten Ebene befinden sich die verschiedenen Arbeitspläne, die das Projektmanagementsystem unterstützt. Durch die leere Box rechts oben wird angedeutet, daß beliebig viele zusätzliche Arbeitsplätze definiert und gestaltet werden können. Die Verwaltung der jeweiligen Funktionalität, Benutzersichten und Zugriffsberechtigungen übernimmt ein spezieller Dialog-Manager, der zu diesem Zweck für jeden Anwender ein explizites Benutzermodell führt. Über den Dialog-Manager hat der Benutzer Zugriff auf Funktionen, die auf der mittleren Schicht zur Verfügung gestellt werden. Die Funktionen der mittleren Schicht können wiederum in drei Hauptkomponenten unterteilt werden: - Im Mittelpunkt steht der Projektstruktur-Manager für die taktische Projektplanung und -kontrolle. Er stellt Funktionen zur Verwaltung der zentralen Informationsstruktur, des Projektstrukturplans, zur Verfügung. Außerdem bietet er gezielte Unterstützung bei der Aufgaben-, Kommunikations- und Einsatzplanung. Er ermöglicht Abfragen des Projektstatus und umfassende Fortschrittsanalysen. - Der Task-Manager realisiert den oben erläuterten Ansatz einer teildezentralisierten Planung und Kontrolle auf der operativen Ebene. Er bietet Instrumente zur Planung und Kontrolle des Entwicklungsverlaufs durch Abstimmung der Projektteilnehmer. Der Task-Manager besteht aus Funktionen zur Planung und Verwaltung der konkreten Entwicklungsaktivitäten und einem intelligenten Mailboxsystem.

Projektmanagement bei Softwareentwicklung

277

- Die Projekt-Toolbox enthält Module für spezifische Projektmanagementaufgaben. Wie der Name schon andeutet, umfaßt sie einen Satz von Werkzeugen, der beliebig erweitert werden kann. Drei wichtige Module sind: "Strategische Planung" (projektindividuelle strategische Planung und Kontrolle des Projektverlaufs gemäß dem Drei-Ebenen-Modell) "Aufwandschätzung" (Unterstützung der Aufwandschätzung im Rahmen der Projektplanung) "Projektreview" (Analyse abgeschlossener Entwicklungsaktivitäten undProjekte; dieses Modul untersucht den Entwicklungsverlauf, zieht Schlüsse und wandelt sie in "Erfahrungssätze" um, z.B. in Form von Regeln für die Aufwandschätzung) Während für der Realisierung der wichtigsten Teile von Projektstruktur-Manager und Task-Manager die konventionelle Softwaretechnik auf der Grundlage prozeduraler Programmierung ausreicht, sind für die strategische Planung, Aufwandschätzung und Projektreview flexiblere Techniken erforderlich. Für die Aufwandschätzung bei Softwareentwicklungsprojekten wurden wissensbasierte Techniken bereits mit Erfolg eingesetzt [20]. Für die differenzierte Modellierung der Projektstruktur bieten sich ebenfalls flexible Methoden wie die regelbasierte Programmierung an. Die wissensbasierten Techniken werden in die konventionelle Systemumgebung eingebettet. Voraussetzung für eine operationale Integration ist, daß beide Systeme dieselben Informationen nutzen und austauschen. Wissensbasis und Datenbasis müssen also gemeinsam entwickelt und anwendungstechnisch integriert werden. Die integrierte Projektdaten- und Wissensbasis bildet die dritte und unterste Schicht in der Systemarchitektur des Projektmanagementsystems. Eine vollständige softwaretechnische Integration - etwa durch Verwaltung in einer gemeinsamen Datenbank - ist wegen der besonderen Erfordernisse der Wissensverarbeitung jedoch nicht ohne weiteres möglich. Während sich konventionelle Datenbanksysteme vor allem für die Verwaltung großer Mengen standardisierter Daten eignen und nur relativ einfache Suchoperationen unterstützen, sind für die Wissensverarbeitung ein breites und beliebig erweiterbares Typenspektrum und mächtige Suchoperationen ("Pattern matching") erforderlich [21].

278

Projektmanagement bei Softwareentwicklung

Projektmanagement bei Softwareentwicklung

279

4.2.2 Aufbau der Projektdatenbank Im weiteren wird der Aufbau der Projektdatenbank näher erläutert und anschließend ein Überblick über wichtige Elemente der Wissensbasis gegeben. Auf die Projektdatenbank greifen sowohl Projektstruktur-Manager als auch TaskManager und Module aus der Projekt-Toolbox wie die strategische Planung zu. Die Projektdatenbank enthält Informationen über -

die Entwicklungsstrategie, eingesetzte Ressourcen, insbesondere Mitarbeiter, innerhalb des Projekts auszufüllende Rollen, Aufgaben und Abhängigkeiten zwischen verschiedenen Aufgaben, inhaltliche Beziehungen zwischen bestimmten Daten, z.B. die Zuordnung von Aufgaben zu bestimmten Entwicklungsabschnitten und deren zeitliche Abfolge, - konkrete Enwicklungsaktivitäten.

In Abbildung 2 wird in einem Entity-Relationship-Diagramm ein Überblick über das Datenmodell gegeben. Dabei wurden die einzelnen Entities und Relationships den Planungs- und Kontrollebenen des Drei-Ebenen-Modells zugeordnet Im Rahmen des strategischen Entwicklungsplans wird das gesamte Projekt in verschiedene Abschnitte aufgeteilt. Jeder Abschnitt ist an einen bestimmten Termin gebunden, und jedem Abschnitt können mehrere Abschnitte inhaltlich nachgeordnet sein. Ein weitere Aufgabe auf der strategischen Ebene ist die Bereitstellung von Ressourcen und insbesondere die Auswahl von Mitarbeitern als Mitglieder des Projektteams. Die einzelnen Mitarbeiter bekleiden im Projekt bestimmte Rollen. Mit einer Rolle sind Ziele, Verantwortlichkeiten und Kompetenzen verknüpft. Eine Rolle kann mehreren Mitarbeitern zugeordnet werden, und ein Mitarbeiter kann mehrere Rollen ausfüllen. Bei der Modellierung der Projektstruktur stehen die einzelnen Entwicklungsaufgaben (Aufgaben) und deren inhaltliche Beziehungen (Au) im Mittelpunkt. Die wichtigste Beziehungsart ist eine Ergebnisrelation, die angibt, daß die Ergebnisse einer bestimmten Aufgabe für eine andere Aufgabe benötigt werden; sie entspricht den Vorgänger- und Nachfolgerrelationen aus der Netzplantechnik. Weitere mögliche Abhängigkeiten, z.B. Synergie-Beziehungen, positive Beeinflussungen etc., wurden bereits in Abschnitt 4.1.2 erläutert. Der Task-Manager setzt die allgemeinen Aufgaben in konkrete Entwicklungsaktivitäten (Aktivitäten) um. Während die Aufgaben nur durch Zuordnung zu bestimmten Entwicklungsabschnitten und durch Abhängigkeiten zu anderen Aufgaben zeitlich

280

Projektmanagement bei Softwareentwicklung

festgelegt sind (relative Terminierung), werden für die Aktivitäten konkrete Startund Endtermine festgelegt. Die Bestimmung dieser Termine erfolgt primär durch Abstimmung der Projektteilnehmer. Das Projektmanagementsystem sollte allerdings Hilfsmittel zur Ermittlung von "zulässigen" Terminintervallen und Pufferzeiten o.ä. zur Verfügung stellen. 4.2.3 Aufbau der Wissensbasis In der Projektdatenbank werden bereits viele Informationen verwaltet, die ein wissensbasierter System teil als Fakten benötigt. In der Wissensbasis müssen zusätzlich temporäre Fakten und Wissenseinheiten erzeugt und für Schlußfolgerungen bzw. zur Produktion zusätzlicher Fakten eingesetzt werden können. Für die Repräsentation "dynamischen" Wissens ist die regelbasierte Darstellung weit verbreitet. Regeln sind für das Projektmanagementsystem ein wichtiges Element der Wissensbasis. Sie dienen beispielsweise zur Darstellung von Erfahrungswerten oder von Daumenregeln für die Aufwandschätzung, die strategische Planung und die Fortschrittsanalyse. Da die einzelnen Regeln in unterschiedlichen Anwendungszusammenhängen angewendet werden sollen, müssen differenzierte Abarbeitungsstrategien für die verschiedenen wissensbasierten Systemteile entwickelt werden. Deshalb sollten allgemeine Funktionen zur Unterstützung bei der Verarbeitung, insbesondere für komplexe Suchprozesse (Pattern matching), von der untersten Systemschicht zur Verfügung gestellt werden. Diese Aufgabe könnte etwa einem dedizierten Knowledge-Manager übertragen werden. Zu seinen Aufgaben gehört unter anderem, die einzelnen Wissenseinheiten bezüglich der Anwendbarkeit in unterschiedlichen Problemkontexten zu strukturieren. Denn innerhalb einer Abarbeitungsstrategie kann es wichtig sein zu wissen, ob eine bestimmte Regel branchen-, Unternehmens-, projektspezifisch ist oder auch nur temporären Charakter hat. Während für die Verwaltung und Abarbeitung von Regelwissen erprobte Methoden und Werkzeuge verfügbar sind, müssen für die Extraktion, Verwaltung und Anwendung von Erfahrungswissen, die für das Projektreview-Modul notwendig sind, neuartige Techniken entwickelt werden. In dem Projektmanagementsystem wird dem fallorientierten (d.h. projektspezifischen) Wissen besondere Bedeutung beigemessen. Projektspezifische Regeln werden getrennt von den "allgemeinen" Regeln verwaltet. Es ist weiterhin geplant, zwischen Regeln und historischen Projektgegebenheiten einen Bezug herzustellen, damit zurückverfolgt werden kann, welche konkreten Fälle bzw. Erfahrungen zur Aufnahme einer bestimmten Regel in die Projektwissensbasis führten.

Projektmanagement bei Softwareentwicklung

Abb. 2: Basis-Datenmodell für das Projektmanagementsystem

281

282

Projektmanagement bei Softwareentwicklung

5 Implementierung Das Projektmanagementsystem wird im Rahmen des Projekts "Konzeption und Realisierung eines wissensbasierten Projektmanagementsystems zur Planung und Kontrolle evolutionärer Softwareentwicklungen" konzipiert und prototypisch realisiert. Die erste Projektphase umfaßt die explorative Entwicklung mehrerer Teilsysteme des Prototyps; in der zweiten Phase erfolgt die Übertragung in eine Zielkonfiguration. In der ersten Phase steht die Erprobung von Konzepten im Vordergrund. Da die Teilsysteme unterschiedliche Anforderungen stellen, kommen zunächst mehrere verschiedene Werkzeuge zum Einsatz: - Wegen der besonderen Eignung für das explorative Prototyping wird zur Entwicklung des Projektstruktur-Managers Smalltalk-80 verwendet. - Die wissensbasierten Komponenten werden mit dem Smalltalk-basierten Werkzeug Humble erstellt, weil dieses unter anderem die Möglichkeit bietet, die interne Darstellung und Abarbeitung der Regelbasis zu beeinflussen. - Ein Prototyp des Task- Managers wird auf einem IBM-PC AT unter MS-Windows mit MS-C entwickelt. - Der Test der Projektdatenbank erfolgt in SQL mit Oracle als Datenbanksystem. - Die Eignung unterschiedlicher Repräsentationsformen und Abarbeitungsstrategien für die Projektwissensbasis wird mit Hilfe von Common Lisp auf einer SunWorkstation untersucht. Die Erfahrungen bei der Erprobung der Konzepte gehen in der zweiten Projektphase in die Entwicklung eines integrierten Systemprototyps aufPS/2-Rechnern unter OS/ 2 ein. Diese Zielumgebung wird aus folgendem Grund gewählt: Projektmanagementsysteme werden primär von Anwendern in Unternehmen eingesetzt. In diesem Umfeld sind Rechner, die einem "Industriestandard" genügen, verbreitet, während gegenüber dedizierten Workstations oder KI-Maschinen oft Vorbehalte bestehen. Darüber hinaus sind PC's heute bereits eine verbreitete Basis von Projektmanagementsystemen. Die Fertigstellung eines lauffähigen Prototyps ist zum Jahresende 1989 vorgesehen.

Projektmanagement bei Softwareentwicklung

283

Anmerkungen [1] Vgl. zu Grundlagen der Netzplantechnik z.B. Burman (1972). [2] Verschiedene Netzplantechnikverfahren werdenn in Groh, Gutsch (1982) erläutert. [3] Eine detaillierte S tudie über den Leistungsumfang der wichtigsten Projektmanagementsysteme findet man in Dworatschek, Hayek (1987). [4] Verschiedene Phasenkonzepte werden z.B. in Seibt (1987) gegenübergestellt. [5] Brooks (1974), S. 48. [6] Weitere Voraussetzungen und Schwächen der klassischen Methodik werden u.a. in Kurbel, Pietsch (1988b), S. 6 ff., diskutiert. [7] Verschiedene Ansätze werden z.B. in Kreplin (1985), Dennis et al. (1987) und Bally et al. (1977) vorgestellt [8] Die vielfältigen Interdependenzen zwischen Entwicklungsmethodik und Projektmanagement werden am Beispiel konkreter Projekte in Kurbel etal. (1987), S. 9 ff., und Kurbel, Pietsch (1988a), S. 9 ff., verdeutlicht [9] Vgl. Floyd (1986), S. 25 f. [10] Vgl. Kurbel, Pietsch (1988b), S. 8 ff. [11] Bums, Dennis (1985), S. 20 ff., schlagen ein Kontingenzmodell für die Auswahl der geeigneten Softwareentwicklungsmethodik in Abhängigkeit von bestimmten "Projektparametern" u.a. vor. [12] Boehm (1981), S. 593. [13] Vgl. Noth (1987). [14] Brooks (1975). [15] Vgl. z.B. Bartsch-Spörl (1987), S. 34 f. [16] Aufgaben, Aufbau und Struktur von Benutzermodellen werden u.a. in Bodendorf, Wittmann (1988), S. 30 ff., erläutert [17] Vgl. u.a. Mescheder, Westerhoff (1988), S. 394 ff. [18] Der Prototyp eines solchen Werkzeugs wird zur Zeit am Lehrstuhl für Wirtschaftsinformatik der Universität Dortmund entwickelt [19] Im Rahmen eines anderen Projekts wurde beispielsweise eine Schnittstelle für wissensbasierte Programmierung in einer prozeduralen Programmiersprache (Ada) entwickelt; die Portierung nach C steht bevor. [20] Vgl. u.a. Fröhlich, Schütte (1988), S. 68. [21] Die unterschiedlichen Anforderungen an Datenbanksysteme und Expertensysteme werden u.a. in Schlageter (1987) erläutert. Möglichkeiten des Anschlusses von Expertensystemen an Datenbanksysteme diskutieren Vassiliou et al. (1985).

284

Projektmanagement bei Softwareentwicklung

Literatur Bally, L., Brittan, J., Wagner, K.H.: A Prototype Approach to Information System Design and Development; Information & Management (1977) 1, pp. 21-26. Bodendorf, F., Wittmann, S.: Benutzermodelle in Expertensystemen; Information Management 3 (1988) 1, S. 30-38. Boehm, B.: Software Engineering Economics; Englewood Cliffs, 1981. Brooks Jr., F.P.: The Mythical Man-Month; Datamation (1974) 12, pp. 44-52. Brooks Jr., F.P.: The Mythical Man-Month; Reading MA, 1975. Burman, P. J.: Precedence Networks for Project Planning and Control; London 1972. Burns, R.N., Dennis, A.R.: Selecting the Appropriate Application Development Methodology; Data Base, Fall 1985, pp. 19-23. Cremers, A.B., Becks, K.-H. (Hrsg.): Proceedings zum Anwenderforum Expertensysteme; Wuppertal 1987. Dennis, A.R., Bums, R.N., Gallupe, R.B.: Phased Design: A Mixed Methodology for Application System Development; Data Base, Fall 1987, pp. 31-37. Dworatschek, S., Hayek, A.: Marktspiegel Projektmanagement Software - Kriterienkatalog und Leistungsprofile; Gesellschaft für Projektmanagement INTERNET Deutschland e.V., Köln 1987. Floyd, C.: A Paradigm Shift in Software Engineering; ACM SIGSOFT Software Engineering Notes (1986) 2, pp. 24-38. Fröhlich, R., Schütte, R.: Wissensbasiertes Projektmanagement großer DV-Vorhaben; KI (1988) 3, S. 64-68. Groh, H., Gutsch, R. (Hrsg.): Netzplantechnik; München 1982. Kim, W„ Reiner, D.S., Batory, D.S. (Eds.): Query processing in database systems; Berlin, Heidelberg 1985. Kreplin, K.D.: Prototyping - Softwareentwicklung für den und mit dem Anwender; Handbuch der Modernen Datenverarbeitung 126,1985, S. 73-83. Kurbel, K., Labentz, M., Pietsch, W.: Prototyping und Projektmanagement bei großen Entwicklungsteams; Information Management 2 (1987) 1, S. 6-15. Kurbel, K., Pietsch, W.: Projektmanagement bei einer Expertensystementwicklung; Information Management 3 (1988a) 1, S. 6-13. Kurbel, K., Pietsch, W.: Ein Ansatz zur Integration von Entwicklungsmethodik, Organisation und Management von Expertensystemprojekten; Arbeitsbericht Nr. 15 des Lehrstuhls für Wirtschaftsinformatik, Universität Dortmund, Dortmund 1988b. Mertens, P., et al. (Hrsg.): Lexikon der Wirtschaftsinformatik; Berlin, Heidelberg 1987. Noth, T.: Unterstützung des Managements von Software-Projekten durch eine Erfahrungsdatenbank; Berlin u.a. 1987. Mescheder, B., Westerhoff, T.: Offene Architekturen in Expertensystem-Shells; Angewandte Informatik (1988) 9, S. 390-398.

Projektmanagement bei Softwareentwicklung

285

Pietsch, W., Vogel, R.: Ein Expertensystem für die Konfigurierung von Personal Computern; in: Proceedings zum Anwenderforum Expertensysteme, hrsg. von Cremers, A.B., Geisseihardt, W.; Duisburg 1988, S. 404-424. Schlageten G.: Expertensysteme und Datenbanken; in Cremers, Becks (1987), S. 78. Seibt, D.: Phasenkonzept; in Mertens et al. (1987), S. 9-12. Vassiliou, Y., Clifford, J., Jarke, M.: Database Access Requirements of KnowledgeBased Systems; in: Kim et al. (1985), pp. 156-170.

Teil 3: Analyse und Gestaltung betrieblicher Organisations- und Kommunikationsstrukturen

Die Kommunikationsstrukturanalyse (KSA) zur Konzeption einer betrieblichen Kommunikationsarchitektur Hermann Krallmann, Ludwin Feiten, Rudolf Hoyer, Georg Kölzer

Inhalt 1 Einführung 2 Die Komponenten der KSA 2.1 Das Datenmodell 2.2 Das Vorgehensmodell 2.2.1 Definition des Untersuchungsbereiches 2.2.2 Interviews mit den Führungskräften 2.2.3 Interviews mit den Beschäftigten 2.2.4 Auswertung der Daten 2.3 Das Auswertungsmodul 2.3.1 SQL-Auswertungen 2.3.2 Standardauswertungen 2.3.3 Die Simulation von Büroprozessen 2.3.3.1 Modellstruktur der Simulation 2.3.3.2 Aufbau der Steuerdatei 2.3.3.3 Simulationsergebnisse 2.3.4 Die grafische Darstellung von Büroprozessen 2.3.4.1 Organigramme 2.3.4.2 Grafische Netze 2.3.4.3 Kuchen-, Balkendiagramme, Kommunigramme 3 Würdigung des KSA-Ansatzes 3.1 Flexible Datenstruktur 3.2 Semantische Konsistenzchecks 4 Zusammenfassung Anmerkungen Literatur

290

Kommunikationsstrukturanalyse

1 Einführung Die Notwendigkeit, den Produktionsfaktor Information im Unternehmen insbesondere vor dem Hintergrund der immer schneller fortschreitenden Entwicklung der Informationstechnologie zu planen, wird mittlerweile nicht nur in der Literatur sondern auch in den Unternehmen anerkannt. Um diese Problematik, die sich durch - technologische, - organisatorische und - psycho-soziale Fragestellungen kennzeichnen läßt, umfassend und strukturiert angehen zu können, benötigt der Planer Hilfsmittel, die ihm bei der Reduktion der vorliegenden Komplexität im Untersuchungsbereich dienlich sind. Rechnergestützte Werkzeuge zur Gestaltung der Büroorganisation und -automation stehen dabei im Mittelpunkt Die Anforderungen, die an ein derartiges Tool zu stellen sind, lassen sich unter folgenden Stichpunkten subsumieren [1]: -

Top-down-Vorgehensweise Berücksichtigung prozeß-, aktoren- und datenorientierter Sichtweisen [2] Berücksichtigung der unterschiedlichen Strukturiertheit von Büroprozessen Flexibilität bzgl. der Untersuchungsebene Unterstützung bei der Beurteilung vorliegender oder geplanter Situationen Modularität des Ansatzes Technikorientierung Betroffenenorientierung Berücksichtigung der Istsituation ("Reorganisationsgedanke")

Die Entwicklung derartiger Werkzeuge steht erst am Anfang. Es ist daher nicht verwunderlich, daß die genannten Kriterien bisher nicht umfassend erfüllt werden. In diesem Beitrag wird aufgezeigt, wie das an der Technischen Universität Berlin am Fachgebiet Systemanalyse und EDV entwickelte System KSA (Kommunikationsstrukturanalyse) die genannten Forderungen unterstützt und durch welche wesentlichen Systemkomponenten es sich deutlich von den am Markt existierenden Ansätzen abhebt.

Kommunikationsstrukturanalyse

291

2 Die Komponenten der KSA 2.1 Das Datenmodell Für die Gestaltung des Datenmodells besteht die oben genannte Forderung, sowohl prozeß- als auch aktoren- und datenorientierte Sichtweisen auf den Untersuchungsbereich zu ermöglichen. Hierzu werden die Büroprozesse sowohl durch die einzelnen Arbeitsschritte der Bearbeiter (Aktoren) als auch mit den während der Abarbeitung fließenden und benutzten Informationen beschrieben. Somit waren die zentralen Objekte des Datenmodells definiert: - Aufgaben als die einzelnen Arbeitsschritte des Büroprozesses - Stellen als die Bearbeiter der jeweiligen Arbeitsschritte - Informationen, die den Aufgaben und damit auch den zugeordneten Stellen zur Verfügung stehen bzw. von ihnen erzeugt oder verändert werden. Als zusätzliche Modellelemente wurden die dem Bearbeiter zur Erfüllung der ihm zugeordneten Aufgaben zur Verfügung stehenden Techniken und angewandten Arbeitsmethoden erfaßt. Abbildung 1 verdeutlicht den Zusammenhang der einzelnen Komponenten.

Abb. 1: Zusammenhang zwischen Aufgabe, Information, Informationsfluß

Zur Erfassung aufbauorganisatorischer Strukturen lassen sich Stellen- und Aufgabenhierarchien beschreiben. Auch für Informationen ist eine detaillierte Beschreibung auf Datenfeldebene möglich.

292

Kommunikationsstrukturanalyse

Die Verbindung der einzelnen Aufgaben zu einem Gesamtprozeß erfolgt über den Informationsfluß, so daß auch zwischen Bearbeitungs- und Transporttechnik unterschieden werden kann. 2.2 Das Vorgehensmodell Grundgedanke des KSA-Ansatzes ist nicht die Neuplanung auf der berühmten "grünen Wiese", die in der Praxis ohnehin nur in den seltensten Fällen zu finden ist, sondern die Reorganisation eines bereits bestehenden Istzustandes einer Organisation. Die gewachsenen Strukturen sind vor allem in den späteren Phasen der Umsetzung von Sollkonzeptionen ein nicht zu unterschätzendes Problem. Um diesem zu begegnen, ist auf eine genaue Analyse dieser Strukturen Wert zu legen. Nur dann wird es möglich, Sollkonzeptionen - evtl. gestaffelt ("MUSS", "SOLL", "KANN") - so anzulegen, daß eine stufenweise Überführung vom Ist- zum Sollzustand keine Utopie bleibt. Vor diesem Hintergrund ergab sich für die Analysephase von KSA-Projekten folgendes Vorgehensmodell. 2.2.1 Definition des Untersuchungsbereiches Hier erfolgt die genaue Festlegung und Formulierung der Projektziele, die Abgrenzung des Erhebungsbereiches bzgl. der Erhebungstiefe (Detaillierungsgrad auf Aufgaben-, Stellen- und Informationsebene) und der einzubeziehenden Organisationseinheiten sowie die Information und Diskussion mit den betroffenen Mitarbeitern und der Mitarbeitervertretung. Es werden ein Zeitplan und ein Interviewplan aufgestellt sowie die Bereitstellung von Räumen, Ressourcen usw. geklärt 2.2.2 Interviews mit den Führungskräften Der Top-down-Vorgehensweise folgend werden zu Beginn der Ist-Erhebung die Führungskräfte aus dem zu untersuchenden Bereich befragt. Dies hat den Zweck, die Ziele des Bereiches und die zu ihrer Erreichung zu erfüllenden Aufgaben zu erfassen. Diese sollten dabei einem Ranking unterworfen werden, so daß sich das weitere Projektvorgehen auf die wesentlichen Aufgaben konzentrieren kann. Neben einer Verbesserung der Zielorientierung erwies sich die Durchführung einer ersten Interviewrunde mit Führungskräften als motivierend für die Beteiligungsbereitschaft der anschließend befragten Mitarbeiter. 2.2.3 Interviews mit den Beschäftigten Die in den Interviews mit den Führungskräften erarbeiteten Hauptaufgaben bilden den Ausgangspunkt für die Interviews mit den Mitarbeitern. Hier werden zu jeder Aufgabe die genaue Ablauflogik der einzelnen Arbeitsschritte, die verwendete

Komm unikationsstrukturanalyse

293

Technik, die benötigten und erzeugten Informationen und die beteiligten Stellen erfragt. Ergebnis ist eine Datenbasis, in der alle relevanten Informationen entsprechend dem oben erläuterten Datenmodell erfaßt sind. Neben dieser objektiven Erfassung der formalen Aufbau- und Ablaufstrukturen sollte diese Phase auch als Gelegenheit genutzt werden, allgemeine Wünsche und Kritik der Mitarbeiter kennenzulernen. Oft lassen sich erkannte Mißstände wie zu lange Bearbeitungszeiten auch durch psychologische Ursachen begründen. Zur Erfassung von Zeit- und Häufigkeitsdaten wird nach den Interviews eine Selbstaufschreibung per Strichliste durchgeführt. Da die reine Schätzung dieser Werte sich als zu fehlerbehaftet erwiesen hat, wurden insbesondere aus Zeit- und Praktikabilitätsgründen diese beiden Erhebungsinstrumente kombiniert Die Selbstaufschreibung dient hierbei zur stichprobenhaften Kontrolle der Schätzwerte. Gerade die dabei aufgetretenen Diskrepanzen betonen die geringe Zuverlässigkeit von reinen Schätzdaten. 2.2.4 Auswertung der Daten Als wesentliche Beurteilungskriterien werden bei der Schwachstellenanalyse die Durchlaufzeiten und die Komplexität der Arbeitsabläufe herangezogen. Weiterhin bietet das Auswertungsmodul der KS A (vgl. Kapitel 2.3) umfangreiche Möglichkeiten, den erfaßten Ist-Zustand nach unterschiedlichen Kriterien zu analysieren. Größen wie etwa die Arbeitszufriedenheit finden dagegen im Modell selbst keine direkte Berücksichtigung, auch wenn in den Interviews nach derartigen Faktoren gefragt wird. Es ist eine nicht zu unterschätzende Aufgabe des Organisators als Person, diese psycho-sozialen Faktoren richtig zu erkennen und ihrer Bedeutung gemäß einzuschätzen. 2.3 Das Auswertungsmodul Die Implementierung der KSA enthält als Kern eine Relationale Datenbank. Dadurch können einfache Auswertungen über das SQL-Abfragemodul der Datenbank vorgenommen werden. Für komplexere Auswertungen steht eine Schnittstelle zur Programmiersprache "Pascal" zur Verfügung. Im Rahmen der Auswertung lassen sich für Soll-Ist-Vergleiche die erfaßten Daten ändern. Beispielsweise kann so leicht die Reduzierung der Transportzeiten durch Ersetzung der Transportart "Hauspost" durch "Elektronische Post" für einzelne Teilbereiche oder auch den gesamten Untersuchungsbereich analysiert werden. Sämtliche im folgenden genannten Auswertungen sind sowohl für die Untersuchung des Istzustands als auch für die Bewertung von geplanten Systemänderungen möglich.

294

Kommunikationsstrukturanalyse

2.3.1 SQL-Auswertungen Aufgrund der sich häufig ändernden Problemstellungen sind oft unterschiedliche Auswertungen notwendig. Für diese Ad-hoc-Auswertungen besteht die Möglichkeit, auf das SQL-Modul der Datenbank zuzugreifen. Die Datenbanksprache SQL ist leicht zu erlernen und bietet auch dem ungeübten Benutzer bald die Möglichkeit umfangreicher Analysen. Im Rahmen der Praxiserprobung wurde diese Möglichkeit sehr stark genutzt. Häufig wiederkehrende Abfragen können dabei in der Datenbank abgespeichert und parametrisiert aufgerufen werden. Bezüglich des Layouts der generierten Reports zeigen sich jedoch schnell die Grenzen dieser Schnittstelle. Es lassen sich nur tabellenähnliche Reports mit eingeschränkter Zeilenbreite erstellen. Für komplexe Auswertungen mit einer Fülle relevanter Informationen mußten daher die Ausgabedaten speziell aufbereitet werden. 2.3.2 Standardauswertungen Die Entwicklung von Standardauswertungen erfolgte unter Nutzung der vom Datenbanksystem angebotenen Programmiersprachenschnittstelle zu Pascal. Neben den Auswertungen mit speziellen Layoutanforderungen wurde eine Vielzahl von Auswertungen realisiert, für die entweder aufgrund der Komplexität oder der häufigen Nutzung eine programmierte Lösung angezeigt war. Für die Zugriffe auf die Datenbank wurde ein spezielles Zugriffsmodul geschaffen, in dem allgemeingültige Anfragen an die Datenbank formuliert und über eine möglichst kleine, definierte Schnittstelle verwaltet werden. Diese Modularisierung erleichterte vor allem die Anpassungsarbeiten bei Versionswechseln der Datenbanksoftware und reduziert zudem den Änderungsaufwand beim Einsatz eines anderen Datenbanksystems. Die realisierten Auswertungen lassen sich in folgende Bereiche unterteilen: - Aufgabenbezogene Auswertungen - Abteilungs- / Stellenbezogene Auswertungen - Informationsbezogene Auswertungen. Für diese Bereiche werden z.B. Listen erzeugt, die u.a. Auskunft über die jeweils verwendeten Informationen geben. Auflistungen der angewandten Methoden und Techniken geben Aufschluß über mögliche funktionale Unterstützungen sowie einzusetzende Technologien. Die Ermittlung von Durchlaufzeiten für Büroprozesse sowie der Arbeitsbelastungen einzelner Stellen geben Hilfestellung zur quantitativen Bewertung und Neuplanung des Büros. Es werden auch Aufgabenprofile für Stellen erzeugt, wobei diese über eine Klassifizierung der ausgeübten Verrichtungen beurteilt werden können. In den Abbildungen 2 bis 6 sind die realisierten Auswertungen tabellarisch zusammengefaßt.

295

Kommunikationsstrukturanalyse

r

a

Auswertung pro Bereich - Liste aller Aufgaben - Liste der Aufgabenstruktur - Liste aller Transportarten - Liste aller Techniken • Liste aller Abteilungen, Stellen, Inhaber - Liste aller Methoden mit Aufgaben - Liste aller Informationsträger der Informationen - Liste aller Informationen • Ausnutzung der Informationskanäle (Transportarten)

J

V Abb. 2: Auswertungen pro Bereich

2.3.3 Die Simulation von Büroprozessen Bei den beschriebenen Auswertungen sind Aussagen über das Zeitverhalten nur in statischer Hinsicht möglich. Sie resultieren z.B. bei der Ermittlung von Durchlaufzeiten und der Belastung von Stellen und Kommunikationswegen aus einer Kumulierung von Bearbeitungs- und Transportzeiten. Vor allem die qualitativen und quantitativen prozeßbezogenen Aspekte lassen sich nur durch eine dynamische Simulation erkennen. Dazu gehören [3]: -

Aufdecken von prozessualen Inkonsistenzen Aufzeigen von Warte- und Liegezeiten Erkennen von bestehenden Unterkapazitäten Ermitteln von optimalen Stellenstärken Überblick über das Verhalten des Modells - beim Ausfall von Stellen - bei der Einbindung neuer Prozesse und - bei der Änderung der Bearbeitungsprioritäten.

Kommunikationsstrukturanalyse

296

r

Auswertung pro Stelle

• Liste aller Stellen, Inhaber • Liste der Aufgabenstruktur (mit Vertretungen) - Liste der Verrichtungen (klassifiziert) • Liste der Methoden (quantitativ) - Liste der Techniken (quantitativ) - Liste der Informationen im Zugriff mit Art der Verarbeitung - Liste der Informationsbeziehungen zu anderen Abteilungen (ein-, ausgehend) - Arbeitsbelastung - Vorgesetzte und Mitarbeiter (-innen)

Übersichtslisten • Liste der Aufgaben • Liste der Verrichtungen mit Aufgaben - Liste der Methoden mit Aufgaben • Liste der Techniken mit Aufgaben - Kommunikationsbeziehungen zwischen Stellen • Organigramm

V

J

Abb. 3: Ausweitungen pro Stelle

Um zusätzlich auch diese Aspekte berücksichtigen zu können, wurde ein dynamischer Modellrahmen entwickelt. Abbildung 7 zeigt diese Erweiterung der KSA. Ein der Simulation vorgelagertes Programm bildet die Daten des statischen Modells in ein Simulationsmodell ab, mit dem dann sowohl Ist- als auch Sollstrukturen simuliert werden können. Die Vorteile dieses dynamischen Modells liegen in der Aufdeckung zeitlicher Abhängigkeiten und der Erkennung von Engpässen bei der Bearbeitung konkreter Büroprozesse. Der Simulationsablauf läßt sich in drei Phasen einteilen: In der ersten Phase werden die Daten aus der Datenbank gelesen und in eine verkettete Struktur umgesetzt. Dabei werden gleichzeitig Grunddaten für eine Steuerdatei generiert. Eventuelle Fehler in der Datenbank werden protokolliert und ausgegeben. In der zweiten Phase wird die Steuerdatei vom Benutzer mit weiteren notwendigen Informationen gefüllt und eingelesen.

297

Kommunikationsstrukturanalyse

r

>V

Auswertung pro Aufgabe - Beteiligte Stellen, Abteilungen, Vertretung - Liste der Aufgabenstruktur - Liste der benutzten Techniken - Liste der benutzten Methoden - Liste der anfallenden Verrichtungen - Liste der benötigten und weitergegebenen Informationen mit Informationsträgern - Informationsbeziehungen zwischen den Teilaufgaben einer Aufgabe - Ausgangsobjekt der Aufgabenbearbeitung - Abschlußinformation - Liste der Transportarten - Medienbrüche - Durchlaufzeit einer Aufgabe (mit Schleifen und Alternativen)

V

J

Abb. 4: Auswertungen pro Aufgabe In der letzten Phase werden die Simulationen entsprechend der Steuerdatei durchgeführt und die gewünschten Ergebnisse angezeigt. 2.3.3.1 Modellstruktur der Simulation Das Datenmodell der KSA wurde für die Simulation um einige weitere relevante Elemente erweitert Die Aufbaustruktur des Simulationsmodells beinhaltet folgende Elemente (Abbildung 8) [4]: -

Elementaraufgaben Eilaufträge Objektflüsse Ablagen Warteschlangen

Kommunikationsstrukturanalyse

298

r

Auswertung pro Abteilung

- Liste aller Stellen, Inhaber - Liste der Aufgabenstruktur - Liste der Verrichtungen (klassifiziert) - Liste der Methoden (quantitativ) - Liste der Techniken (quantitativ) - Liste der Informationen im Zugriff mit Art der Verarbeitung - Liste der Informationsbeziehungen zu anderen Abteilungen (ein-, ausgehend) • Arbeitsbelastung der Abteilung

Übersichtslisten - Liste der Aufgaben - Liste der Verrichtungen mit Aufgaben • Liste der Methoden mit Aufgaben - Liste der Techniken mit Aufgaben - Kommunikationsbeziehungen zwischen Abteilungen - Organigramm

V

J

Abb. 5: Auswertungen pro Abteilung

- Stellen mit Inhaber(n) - Hilfsinformationen - Umweltschnittstellen. Die Aufbaustruktur wird intern als Graph dargestellt, wobei die Elementaraufgaben den Knoten und die Objektflüsse (Informationsflüsse) den Kanten entsprechen. Eine Aufgabe kann beliebig durch sogenannte "Eilaufträge" unterbrochen werden. Nach der Bearbeitung dieses Schnelläufers wird die unterbrochene Aufgabe wieder aufgenommen. Die Aufgaben werden durch die Objektflüsse verbunden, wobei die Möglichkeit besteht, diese durch die Einrichtung von Ablagen zeitlich genauer zu bestimmen.

299

Kommunikationsstrukturanalyse

r Auswertung pro Information - Darstellung (Daten, Text, Sprache, Grafik, Festbild, Bewegtbild) - Informationsstruktur (Ober-, Unterordnung) - Liste der ändernden, lesenden, kreierenden Aufgaben und Stellen - Liste der Informationsträger - Weg einer Information als Objekt durch eine Aufgabe - Medienbrüche

V.

y

Abb. 6: Auswertungen pro Information

Es existieren bestimmte Aufgaben, nach deren Abarbeitung die betreffenden Objekte nicht unmittelbar weiterbearbeitet werden. An diesen Elementen müssen Warteschlangen generiert werden, die die zeitlichen Verzögerungen repräsentieren. Solche Unterbrechungen können auftreten [5], wenn: - zwei hintereinanderliegende Aufgaben von unterschiedlichen Stellen bearbeitet werden - zwischen zwei Aufgaben Transportzeiten anfallen - sich zwischen zwei Aufgaben eine Ablage befindet - eine Aufgabe mehrere Informationen benötigt - sich die Aufgabe am Systemanfang befindet - eine Aufgabe mehrere Flüsse generiert

Kommunikationsstrukturanalyse

300

Abb 7.: Dynamisches Modell der KS A

Im letzten Fall tritt nicht immer eine Unterbrechung ein. Sie kann dann auftreten, wenn die Aufgabe mindestens zwei Informationen erzeugt, die beide in der gleichen Stelle weiterverarbeitet werden müssen und nur ein Stelleninhaber vorhanden ist bzw. Kapazität frei hat. Der Zugriff der Stellen auf ihre Objekte erfolgt dann nur noch über die Warteschlangen. Die Zuordnung der Inhaber zu den Aufgaben wird über die Stellenzugehörigkeit geregelt. Hilfsinformationen werden den Aufgaben direkt zugeordnet. Es existieren zwei unterschiedliche Arten. Zum einen gibt es Hilfsinformationen, die zu bestimmten Zeitpunkten geholt werden müssen ("frequentielle", z.B. einmal pro Arbeitstag werden häufig benötigte Unterlagen aus dem Aktenschrank geholt und auf den Schreibtisch gelegt), und solche, die mit einer gewissen Wahrscheinlichkeit benötigt werden ("wahrscheinlichkeitsbedingte", z.B. ist zur Beantwortung einer Anfrage manchmal eine Kontrolle von Preislisten erforderlich). Die Bearbeitungsdauer am Objekt verlängert sich um die Zeit, die für diese Holvorgänge benötigt wird. Über die Umweltschnittstelle (Eingang) wird die Einschleusung der Objekte gesteuert. Beim Erreichen der Ausgangsschnittstelle werden akkumulierte Daten des Objektes in die entsprechenden Statistiken geschrieben. 2.3.3.2

Aufbau der Steuerdatei

Die Steuerdatei wird aus der Struktur des zu simulierenden Modells abgeleitet und enthält verschiedene Blöcke. In diesen können bzw. müssen vom Anwender gewisse Angaben vorgenommen werden, die sich auf vier Klassen verteilen.

301

Komm unikationsstrukturanalyse

v J t S 01"5 l-ü-c-S« r i] < Jo-Sjj

C2 J3