Zieldynamik erfordert integriertes Lifecycle - Management für eGovernment - Lösungen (Organisation & IT) - Teil A

    21. Mai 2001 von Dipl.-Inf. Thomas Off, Dipl.-Ing. Lutz Tünschel

    Abgestimmte Konzepte, Methoden, Werkzeuge und Ergebnisse für ein verändertes gesellschaftliches und wirtschaftliches Umfeld.

    "Die größten Wachstumschancen liegen für uns dort, wo durch
    die Erweiterung des Wissens neue Verfahren und Produkte
    erschlossen werden.    "
    Dr. Manfred Schneider
    Vorstandsvorsitzender der Bayer AG

    "Das 21. Jahrhundert wird das Jahrhundert der Software!"
    Prof. Dr. Norbert Walter
    Chefvolkswirt der Deutschen Bank Gruppe

     

    Zieldynamik steuert Organisation und IT-Einsatz

    Im veränderten gesellschaftlichen und wirtschaftlichen Umfeld wird der Einsatz der IT-Technologie für die öffentliche Verwaltungen zum maßgeblichen Erfolgsfaktor für Effizienzsteigerung und Verbesserung der Bürgernähe insbesondere über das Internet. Der zielorientierten Neuausrichtung der Geschäftsprozesse, sowie der Absicherung des in IT-Lösungen (eGovernment-Lösungen) abgebildeten verfahrensrelevanten Wissens, kommt daher eine zunehmend wachsende Bedeutung zu.

    Die Prozesse der öffentlichen Verwaltung zeichnen sich durch eine hohe Komplexität und Verflechtung aus. Die Gestaltung der erforderlichen Veränderung, sowie die Erstellung und Einführung der eGovernment-Lösungen, erfordern Millionenbeträge und sind teilweise mit erheblichen Risiken behaftet. Ursache hierfür sind neue bzw. veränderte Zielsetzungen für die Führungs- und Mitarbeiterebene.

    Von den Auftraggebern wird häufig unterschätzt bzw. verkannt, dass neben den gesetzlichen Zielen zunehmend äußere Ziele den durch die Geschäftsprozesse und die eGovernment-Lösung abgedeckten Leistungsumfang bestimmen.

    Zu nennen sind hier Ziele, die aus der Wirtschaft bzw. aus der Gesellschaft auf die Verwaltung (z.B. Steigerung der Effizienz und Sicherung bzw. Ausbau von Wettbewerbsvorteilen des Wirtschaftsstandortes) wirken, ebenso wie Ziele, die aus der rasanten Entwicklung der Informations- und Kommunikationstechnik resultieren (z.B. Steigerung der Bürgernähe über das Internet).

    Um diese Ziele zu erreichen, muss das in den Köpfen der Mitarbeiter aller Ebenen vorhandene Wissen um die Möglichkeiten der Zielerreichung so dokumentiert und aufbereitet werden, dass es die Entwicklung, die Einführung und den Betrieb einer Gesamtlösung (bestehend aus Organisation und IT) ermöglicht. Um Verbesserungspotenziale zu lokalisieren, müssen auch die Schnittstellen optimiert werden. Hier muss Vorsorge getroffen werden und ggf. der öffentlichen Verwaltung die veränderten Anforderungen an die Schnittstellen zu vor- und nachgelagerten Behörden bzw. zu den Geschäftsprozessen von Industrie, Handel und Dienstleistungsbetrieben bewusst gemacht werden.

    Gleichzeitig sollen eGovernment-Lösungen in immer kürzerer Zeit verfügbar sein und auf durchgängigen Nutzen für den gesamten Lifecycle ausgelegt sein. Der Investitionserfolg wird damit abhängig von Voraussetzungen wie:

    V1

    Existieren eindeutige Ziele für die Gesamtlösung (Organisation und IT)?

    V2

    Tragen die Geschäftsprozesse auf wohldefinierte Art und Weise den Zielen (z.B. dem gesetzlichen Auftrag, Forderungen nach mehr Bürgernähe sowie höherer Effizienz) Rechnung?

    V3

    Sind die Prozesse auf zu erwartende Trends im Umfeld ebenso ausgelegt, wie auf veränderte Anforderungen an oder aus Schnittstellen? Stellt die Lösung sicher, dass sich Auswirkungen von Gesetzes- bzw. Verfahrensänderungen auf Prozesse und Software leicht nachvollziehen lassen? Ist die Architektur der Lösung offen für eine wirtschaftliche Berücksichtigung von Änderungen bzw. Erweiterungen? (Zieldynamik)

    V4

    Existiert eine mitlaufende und konsistente Dokumentation des für die Zielerreichung notwendigen Wissens? Kann diese Dokumentation über alle Phasen des Lebenszyklus und für alle Projektbeteiligten transparent angewendet werden? Können Änderungen, die aus der Zieldynamik resultieren gezielt, jederzeit konsistent in die Dokumentation eingearbeitet werden? (Vgl. Abbildung 1)

    Abbildung 1 - Klassische Lücke im Lebenslauf von Organisations- und IT-Lösungen

    Erforderlich hierfür ist die Erweiterung der vorhandenen klassischen Konzepte der Geschäftsprozessgestaltung und der Softwaretechnik, sowie deren Integration in einer werkzeugunterstützten Metamethodik. Diese kann dann projektbezogen in einem Vorgehensmodell konkretisiert werden, das zielorientiert die Schwächen traditioneller Ansätze (vgl. Abbildung 1) zu Gunsten eines integrierten Lifecycle Managements überwindet.

    Traditionelles Vorgehen

    Traditionelle Vorgehensweisen trennen in der Regel die Organisationssicht von der IT-Sicht. Daraus resultiert ein Bruch zwischen der Organisationsgestaltung und der Softwareentwicklung, sowie der Einführung der Gesamtlösung, bestehend aus Organisation und IT-Anteilen (eGovernment-Lösung). Im folgenden wird kurz auf die für die geschäftsprozessorientierte Organisationsgestaltung und die Softwaretechnik eingesetzten Konzepte, Methoden und Werkzeuge eingegangen. Unter Konzepten werden die Elemente verstanden, die Basis für die Beschreibung der Lösungsmodelle sind. Die Methoden liefern die für den Einsatz der Konzepte erforderlichen Schritte und Regeln. Unter Werkzeugen sind Hilfsmittel zur Umsetzung der Konzepte und deren Notation zu verstehen.

    Geschäftsprozessmanagement

    Geschäftsprozesse beschreiben einen Leistungsverbund von Kunde und Lieferant (externe/interne), der sich an der Wertschöpfung und dem Kundennutzen orientiert. Hiervon zu unterscheiden ist die Beschreibung funktionaler Abläufe ohne den Kunden-Lieferanten-Bezug. Die Steuerung von Kundennutzen und Wertschöpfung erfolgt über das Geschäftsprozessmanagement.

    Konzepte/Elemente: Das zentrale Konzept der Geschäftsprozessmodellierung und -optimierung ist der Geschäftsprozess. In der Regel wird ein Geschäftsprozess als eine Folge von Aktivitäten, mit konkretem Ausgangszustand und definiertem Ergebnis definiert. Darüber hinaus liefert ein Geschäftsprozess einen konkreten Kundennutzen - er liefert somit einen messbaren Beitrag zur Erreichung verabschiedeter Ziele. Weitere Elemente, die aus den Eigenschaften der Geschäftsprozesse resultieren, sind u.a. Aktivitäten, Rollen, Produkte bzw. Dienstleistungen, Aufträge (z.B. gesetzliche) bzw. Ziele, Ressourcen (z.B. Personal, Informationen, Dokumente) und die Aufbauorganisation (vgl. Tabelle 1).

    Methoden/Notation: Für die Geschäftsprozessmodellierung liegen unterschiedliche Methoden vor. Zu unterscheiden sind hier die ereignisorientierte Modellierung (nach Scheer) und die ergebnisorientierte Modellierung (IUM / Fraunhofer Institut IPK, Berlin; URMEL / PSI AG). Besonderheit von IUM (Integrierte Unternehmensmodellierung) und URMEL (Unternehmensreferenzmodellierung) sind die Objektorientierung und hier speziell die Ausrichtung der Modellierung am "Produkt". Die verwendete Notation wird durch die eingesetzte Methode oder das zu verwendende Werkzeug bestimmt. Eine Standardisierung der Notation - ähnlich der UML (Unified Modeling Language) für die Softwareentwicklung - existiert bisher nicht.

    Wodurch sind Prozesse charakterisiert?

    Prozesse ...

    • ... laufen quer zur traditionellen Organisation
    • ... transformieren ein Arbeitsergebnis unter Verwendung bestimmter Regeln in ein Produkt
    • ... haben einen/mehrere "Kunden", die das Produkt des Prozesses anfordern, erhalten und davon einen konkreten Nutzen haben
    • ... einen oder mehrere Lieferanten, die die für das Arbeitsergebnis erforderlichen Ressourcen (z.B. "Vor-Produkte", Information) bereitstellen
    • ... einen Prozessverantwortlichen, der für das Arbeitsergebnis verantwortlich ist, nach Leistung, Zeitaufwand, Kosten, Termin und Qualität

     

    Tabelle 1 - Eigenschaften von Prozessen

    Werkzeuge: Das Angebot an Werkzeugen zur Geschäftsprozessmodellierung ist reichhaltig. Neben der Funktionalität zur graphischen Darstellung von Geschäftsprozessen bzw. von Abhängigkeiten zwischen deren Elementen, werden in unterschiedlichem Umfang und Komfort textuelle Auswertungsfunktionen über die Elemente, Möglichkeit zur Simulation sowie Schnittstellen (z.B. zu Workflow-Management-Systemen) geboten. Lebenszyklusbezogene Ergebnisdokumentationen fehlen in der Regel ebenso wie auf den Werkzeugeinsatz abgestimmte Methoden.

    Das Geschäftsprozessmanagement wird in der Regel durch singuläre Sichten von Organisationsberatern oder Softwareentwicklern bestimmt. Insbesondere die zielorientierte Sicht auf Geschäftprozesse wird selten beherrscht, wodurch versäumt wird, das Wissen um Möglichkeiten zur Erreichung der Ziele strukturiert zu erfassen und zu dokumentieren (s.o. V1, V2, V4). Damit ist zwangsläufig verbunden, dass die Konsistenz der Gesamtlösung über die Phasen des Lebenszyklus gefährdet ist (s.o. V3).

    Softwareentwicklung - Anforderungsanalyse, Analyse/Design und Realisierung

    Während der Softwareerstellung werden Konzepte, Methoden und Werkzeuge mit dem Ziel der ingenieurmäßigen Entwicklung von Softwaresystemen eingesetzt. Dazu werden in der Regel Anforderungen strukturiert erfasst und mit Hilfe von definierten Leistungsmerkmalen des realisierten Softwaresystems abgedeckt.

    Konzepte und Notation: In der Praxis der Softwareentwicklung haben sich dazu die objektorientierten Konzepte durchgesetzt. Objekt, Klasse, Nachrichten, Vererbung und Polymorphie sind z.B. Konzepte, die in allen Phasen der Softwareentwicklung angewendet werden können. Zu den erweiterten Konzepten, die spezifisch nur in einer oder möglicherweise mehreren Phasen eingesetzt werden, gehören z.B. Use Cases. Neben den objektorientierten Konzepten gewinnen komponentenorientierte Konzepte (z.B. Business Object, Fachkomponente) immer mehr an Bedeutung. Durchgesetzt hat sich die Unified Modelling Language (UML) als Standardnotation für die objekt- und komponentenorientierte Entwicklung.

    Den großen Vorteilen der Objektorientierung (Durchgängigkeit während der Softwareerstellung und Kombination objekt- und komponentenorientierter Konzepte) steht als wesentlicher Nachteil das Fehlen definierter Regeln für die Transformation bzw. Abbildung von Konzepten der Softwareentwicklung zu vor- und nachgelagerten Phasen (z.B. Geschäftsprozessmanagement, Einführung, Betrieb) gegenüber. Dieser Bruch kann Ursache für zusätzliche Kosten und für erhebliche Verzögerungen der Inbetriebnahme sein. Isolierte Ansätze zur Überwindung dieser Schwächen wie z.B. die Aktivitätsdiagramme der UML können allein nicht weiter führen, da der Bezug zu den Zielen der Gesamtinvestition und damit für das Verständnis, für die Bedeutung und für den Nutzen der Lösung fehlen.

    Methoden: Die Methoden orientieren sich vor allem an den Phasen der Softwareentwicklung mit den verwendeten Konzepten und erstellten Ergebnistypen. Alle bekannten Methoden (z.B. Rational Unified Process, V-Modell) setzen auf einer fundierten konzeptionellen Basis auf und profitieren von der Durchgängigkeit der Objektorientierung. Bei den Methoden wird jedoch der Bezug zu den vor- und nachgelagerten Methoden anderer Phasen vernachlässigt. Inkrementelles, iteratives Vorgehen bei der Softwareentwicklung setzt jedoch die Konsistenz der Anforderungen, die aus Geschäftsprozessen gewonnen wurden, über alle Abschnitte der Softwareentwicklung bis zur Einführung und zum Betrieb voraus. Beispielsweise können nur so Erkenntnisse aus vorangegangenen Iterationen und Inkrementen bei der Umsetzung von weiteren Geschäftsprozessen eingebracht werden.

    Werkzeuge : Bei dem breiten Angebot an Werkzeugen für die Softwareentwicklung fällt eine klare Zuordnung ihres Einsatzspektrums zu einer oder mehreren Phasen der Softwareentwicklung schwer. Jedes Werkzeug hat in der Regel seinen Einsatzschwerpunkt in einer Phase. Grob kann zwischen Upper-CASE- (für die frühen Entwicklungsphasen), Lower-CASE- (für die späten Entwicklungsphasen) und CARE-Werkzeuge (für Reverse- und Reengineering) unterschieden werden. Die Ausweitung des Einsatzspektrums basiert jedoch in den seltensten Fällen auf einer durchgängigen konzeptionellen oder methodischen Grundlage.

    Die Abbildung von zu erreichenden Zielen, sowie die Anwendung von verfahrensrelevantem Wissen in Elementen der Software, wird von keiner (der marktrelevanten) Methoden derart unterstützt, dass die Umsetzung der Ziele nachvollziehbar wäre (s.o. V1, V2, V4). Dadurch kann beispielsweise beim Aufdecken von Konflikten zwischen mehreren Anforderungen während des Entwurfs oder der Realisierung methodisch nicht sichergestellt werden, dass Anforderungen gemäss ihrer Zielwirkung berücksichtigt werden. Weiterhin kann die Unkenntnis von Auswirkungen, die Zieländerungen (z.B. aufgrund von Gesetzesänderungen, gesellschaftlichen und wirtschaftlichen Trends) auf die Anforderungen an Software haben, zu einer inflexiblen Architektur führen, die die Investitionen in die eGovernment-Lösung nicht auf Dauer sichern kann (s.o. V3).

    Einführung und Betrieb/Wartung

    Für die technische Systemeinführung gibt es vielfältige praktische Erfahrungen. Ein möglicher Standardisierungsprozess, der praktisch Konzepte und Methoden für die organisatorische Umsetzung der Veränderungsprozesse hervorbringen könnte, hat jedoch (noch) nicht eingesetzt. Gleiches gilt für Betrieb und Wartung. Hier stehen in der Praxis Systemhandbücher sowie zentrale Datenbanken und pragmatische Methoden für das Änderungsmanagement zur Verfügung. Standardisierungsbemühungen fehlen völlig. Handlungsbedarf besteht auch bei Betriebskonzepten bzgl. deren Kopplung zu den Geschäftsprozessen. Werkzeugtechnisch völlig entkoppelt von anderen Phasen stehen für die Einführung und Betrieb/Wartung hochspezialisierte Werkzeuge (z.B. Performance-Messung und -Optimierung) zur Verfügung.

    Weder der Zusammenhang zwischen den Zielen und dem Wissen um die Zielerreichungsmöglichkeiten, noch der Umgang mit dynamischen Zieländerungen, werden während Einführung, Betrieb und Wartung beherrscht.

    Fazit

    Für alle Phasen des Lebenszyklus stehen isoliert tragfähige, teilweise vor allem pragmatisch motivierte Konzepte, Methoden und Werkzeuge zur Verfügung. Es gelingt mit klassischen Ansätzen jedoch nicht, vereinbarte Ziele, relevantes Wissen und dynamische Änderungen in der Entwicklung von Gesamtlösungen, bestehend aus Organisation und IT-Anteil (eGovernment-Lösung), zu berücksichtigen:

    Dem zielorientierten Zusammenspiel von Organisation und IT-Einsatz wird nicht hinreichend bzw. durchgängig über alle Phasen des Lifecycle Rechnung getragen.

    Die Zieldynamik, der eine Organisation (mit all ihren Elementen) natürlicherweise unterliegt, wurde nicht beachtet.

    Konzepte, Methoden und Werkzeuge für die organisatorische und softwaretechnische Lösung, sowie für Einführung und Betrieb wurden nicht zielorientiert aufeinander abgestimmt, sondern isoliert und phasenbezogen eingesetzt.

    Verfahrensrelevantes zielorientiertes Wissen wurde nicht konsistent über alle Phasen des Lebenszyklus dokumentiert und fortgeschrieben, Zusammenhänge waren nicht transparent.

    Ausgehend von diesen Erfahrungen hat die PSI AG den integrierten Lifecycle Ansatz entwickelt.

Kommentare

Das Kommentarsystem ist zurzeit deaktiviert.