Entwicklung und Anwendung eines Frameworks für das IT-Controlling anhand des praktischen Beispiels bei der Lufthansa-Systems

Inhalt

Abbildungsverzeichnis

Tabellenverzeichnis

Formelverzeichnis

1 Abgrenzung
1.1 Projekte
1.1.1 Allgemeine Definition
1.1.2 Softwareprojekt
1.1.2.2 Softwareproduktlebenszyklus
1.1.2.3 Softwareprojekt
1.1.3 Vorvertrag
1.1.4 Entwicklung
1.1.5 Nachvertrag
1.2 Softwareprojekt im Sinne dieser Arbeit

2 Entwicklung eines Frameworks
2.1 Begriffsdefinition Framework
2.2 Ableiten eines Frameworks
2.2.1 Was soll durch dieses Framework erreicht werden?
2.3 Entwicklungsmodelle
2.3.1 Klassische Vorgehensmodelle
2.3.1.1 „Code und Fix“
2.3.1.2 Wasserfallmodell
2.3.1.3 V-Modell
2.3.2 Agile Vorgehensmodelle
2.3.2.1 Prototyping
2.3.2.2 Spiralmodell
2.3.2.3 Evolutionäres Prototyping
2.3.2.4 Experimentelles Prototyping
2.4 Das Controlling-Gebiet
2.5 Ziele
2.5.1 Kennzahlen
2.5.1.1 Kennzahlenordnungssystem
2.5.1.2 Kennzahlensteckbrief
2.5.1.3 Kennzahlen
2.5.1.4 Kennzahlentypen
2.5.1.5 Kennzahlensysteme
2.5.1.6 Kenngrößen vs. Kennzahlen
2.6 Bewertungsschema des Projektes
2.7 Kennzahlengewichtung und Sektorenbegrenzung
2.7.1 Anpassen der Bedeutung der Kenngröße
2.7.1.1 Anpassen der Gewichtung
2.7.1.2 Veto ohne Gewichtsanpassung
2.8 Relativierung von Kennzahlen anhand des jeweiligen Sektors
2.8.1 Kennzahlen mit unterem und oberem Ankündigungssektor
2.8.1.1 Die relative Position innerhalb des Leitsektors
2.8.1.2 Die relative Position innerhalb des oberen Ankündigungssektors
2.8.1.3 Bestimmung der relativen Position innerhalb des oberen Warnsektors
2.8.1.4 Die relative Position innerhalb des unteren Ankündigungssektors
2.8.1.5 Kennzahlen ohne Warnsektoren
2.8.2 Kennzahlen nur mit oberem Ankündigungssektor
2.8.3 Kenngrößen nur mit unteren Ankündigungssektor
2.8.4 Kenngrößen ohne Ankündigungssektoren
2.9 Aggregation der Kennzahlen

3 Anwendung am praktischen Beispiel der Lufthansa Systems
3.1 Experimenteller Prototyp
3.1.1 Datenbank
3.1.1.1 Tabelle „Projekte“
3.1.1.2 Tabelle „Kennzahlen“
3.1.1.3 Tabelle „KennzahlSteckbriefe“
3.1.1.4 Tabelle „Istwerte“
3.1.1.5 Tabelle „Messwerte“
3.1.1.6 Tabelle „Kategorien“
3.1.1.7 Tabelle „Klassen“
3.1.2 Frontend
3.1.2.1 DBServer.dll und Verbindung.dll
3.1.2.2 Frontend.exe
3.1.3 Excel-Anwendung
3.2 Anwendung des Frameworks
3.3 Bewertung der Ergebnisse

4 Fazit und Ausblick
4.1 Bewertung der praktischen Anwendung des Frameworks
4.2 Kritische Betrachtung der technischen Umsetzungsfähigkeit

Literaturverzeichnis

Anhang

Abbildungsverzeichnis

Abb. 1.1: Softwarelebenszyklus

Abb. 1.2: Ablaufphase Vorvertrag

Abb. 1.3: Drei Phasen des Softwareprojektes

Abb. 2.1: Kennzahlenklassen

Abb. 2.2: Nummerierung der Kennzahlenklassen

Abb. 2.3: Darstellung im Kennzahlenordnungssystem

Abb. 2.4: Kennzahlsteckbrief

Abb. 2.5: Kennzahl „Miete“

Abb. 2.6: Kennzahl „Miete/Leasing/Pacht“

Abb. 2.7: Kennzahl „Stromkosten“

Abb. 2.8: Kennzahlensektoren

Abb. 2.9: 15 Kenngrößen mit gleicher Gewichtung

Abb. 2.10: 15 Kenngrößen, Veto einer Kenngröße nach 75% Gewichtsverteilung

Abb. 2.11: 15 Kenngrößen, Veto einer zweiten Kenngröße

Abb. 3.1: Datenbank-Prototyp

Abb. 3.2: Projekt Probetest1 nach der Auswertung

Abb. 3.3: Projekt Probetest2 nach der Auswertung

Abb. B.1: Startfenster von Frontend.Exe

Abb. B.2: Fenster „Klassen“

Abb. B.3: Fenster „Kennzahlen“

Abb. B.4: Fenster „Berechnung“

Abb. B.5: Fenster „Formel“

Abb. B.6: Geänderte Auswahl

Abb. B.7: Makro-Aktivierung

Abb. B.8: Einstieg in Assistenten

Abb. B.9: Projektnamen

Abb. B.10: Kennzahlauswahl

Abb. B.11: Formular „Kennzahlen Suche“

Abb. B.12: Formular „Baum Suche“

Abb. B.13: Projekt Assistent „Kennzahlen Steckbriefe“

Abb. B.14: Formular „Kennzahl Auswahl“

Abb. B.15: Formular „Kennzahlen Steckbrief“

Abb. B.16: Assistent „Berechnungsstart“

Tabellenverzeichnis

Tab. 2.1: Tabelle Kennzahlenperspektiven

Tab. 3.1: Tabelle „Istwerte“ mit Werten

Tab. 3.2: Sektorenwerte aus Probetest

Tab. 3.3: Abgeleitete Sektorenwerte

Tab. 3.4: Sektorenwerte Probetest

Tab. A.1: Tabelle „Projekte“, Attribute

Tab. A.2: Tabelle „Kennzahlen“, Attribute

Tab. A.3: Tabelle „KennzahlSteckbriefe“, Attribute

Tab. A.4: Tabelle „Istwerte“, Attribute

Tab. A.5: Tabelle „Messwerte“, Attribute

Tab. A.6: Tabelle „Kategorien“, Attribute

Tab. A.7: Tabelle „Klassen“, Attribute

Formelverzeichnis

Formel 2.1: Ermittlung der Gesamtgewichtung

Formel 2.2: Ermittlung der Kenngrößengewichtung

Formel 2.3: Ermittlung der Veto-Gewichtung

Formel 2.4: Ermittlung Restgewichtung

Formel 2.5: Ermittlung der neuen Gewichtung

Formel 2.6: Bestimmung der Weite des Leitsektors

Formel 2.7: Bestimmung der Distanz zum unteren Ankündigungssektor

Formel 2.8: Bestimmung der relativen Position innerhalb des Leitsektors

Formel 2.9: Bestimmung der Weite des oberen Ankündigungssektors

Formel 2.10: Bestimmung der Distanz zum Leitsektor

Formel 2.11: Bestimmung der relativen Position innerhalb des oberen Ankündigungssektors

Formel 2.12: Klassifizierung des Ankündigungssektors

Formel 2.13: Bestimmung der Weite des unteren Ankündigungssektors

Formel 2.14: Bestimmung der Distanz zum Leitsektor

Formel 2.15: Bestimmung der relativen Position innerhalb des oberen Ankündigungssektors

1 Abgrenzung

Um Controlling erfolgreich einführen zu können, sollte das Controlling-Gebiet (siehe Kap. 2.4) klar und unmissverständlich definiert werden, insbesondere in Hinblick auf die benötigten Kennzahlen, die aus einem großen Pool von möglichen Kennzahlen zu selektieren sind.

Dazu sollten zuerst die Begriffe geklärt werden, die zur Abgrenzung notwendig sind. Beim Controlling eines Softwareentwicklungsprojektes, ist zu definieren, was unter einem Softwareprojekt zu verstehen ist. Diese Abgrenzung sollte immer im Vorwege der Einführung eines Controllings erfolgen.

Weiterhin muss klar abgegrenzt sein, was unter IT-Projektcontrolling zu verstehen ist. Im Folgenden werden die Begriffe dargestellt und die Abgrenzung zu anderen Bereichen vorgenommen.

1.1 Projekte

Um zu definieren, was in dieser Arbeit unter einem Softwareprojekt verstanden wird, soll zuerst untersucht werden, was im Allgemeinen als Definition eines Projektes gelten kann und was unter Softwareprojekten im Speziellen zu verstehen ist.

1.1.1 Allgemeine Definition

Unter einem Projekt ist ein Vorgang zu verstehen, der sich durch die folgenden Eigenschaften ausweist:

- Er ist zeitlich begrenzt.

Der Vorgang hat somit einen definierten Anfang und ein definiertes Ende. Wie der Anfang bzw. das Ende definiert ist, bedarf einer entsprechenden Klärung. (Vgl. Schlingloff, 2002)

- Er ist hinsichtlich der Kosten und der Dauer abschätzbar.

Hier zeigt sich der zeitliche Bezug, wie er oben bereits angesprochen wurde. Zusätzlich kommt der Kostenfaktor hinzu, der in einem gewissen Rahmen eingrenzbar erscheint. Üblicherweise erfolgt diese Abschätzung durch eine „Schätzklausur“. (Vgl. Schlingloff, 2002)

- Er kann in Teilprojekte zerlegt werden.

Es kann eine Feingliederung eines Projektes in kleine, einzelne Projekte oder gar Tätigkeiten erfolgen. (Vgl. Pabst-Weinschenk o.J. (a))

- Er ist risikobehaftet.

Ein Projekt kann in Bezug auf das Projektgelingen oder -scheitern mit einem gewissen Maß an Risiko behaftet sein. Dies begründet sich durch die Neuartigkeit und die dadurch fehlenden Erfahrungen mit einem solchen Projekt. (Vgl. Schlingloff, 2002)

- Er erfordert die Zusammenarbeit von verschiedenen Spezialisten unterschiedlicher Bereiche.

Diese Forderung ergibt sich aus der Einmaligkeit und damit der Neuartigkeit eines Projektes. (Vgl. Schlingloff, 2002)

- Er hat einen Namen, ein definiertes Ziel, ein Projektteam und einen Projektleiter.

Ein Projekt wird durch seinen Namen eindeutig identifiziert.

Das Ziel hat für ein Projekt eine besondere Bedeutung. Es müssen die folgenden Kriterien erfüllt sein:

- Es muss einen Namen haben, der es identifiziert.
- Es muss klar definiert sein.
- Es muss einen Zeithorizont haben.
- Es muss realistisch und verwirklichbar sein.
- Es muss messbar und überprüfbar sein.

Auch sollten sich die Mitarbeiter des Projektes mit diesem Ziel identifizieren können. (Vgl. Pabst-Weinschenk o.J. (c))

Der Projektleiter trägt die Verantwortung für das Gelingen des Projektes. Diese Verantwortung gliedert sich in die Bereiche

- Projektteamführung und Personalverantwortung,
- Informationsverantwortung,
- Planungsverantwortung,
- Koordinierungsverantwortung,
- Kontrollverantwortung,
- Dokumentationsverantwortung und
- Etatverantwortung.

Der Projektleiter benötigt zur Bewältigung seiner Aufgabe einen klar definierten Aufgaben-, Kompetenz- und Verantwortungsrahmen. (Vgl. (Pabst-Weinschenk o.J. (d))

- Er hat eine klare Abgrenzung zu anderen Vorhaben.
Ein Projekt kann von anderen Vorhaben eindeutig abgegrenzt werden. (Vgl. Pabst-Weinschenk o.J.(a))
- Er weist eine projektspezifische Organisation aus.
Diese Organisation bezieht sich auf das Projektteam und die Projektleitung. (Vgl. Schlingloff, 2002)
- Er weist eine gewisse Einmaligkeit auf.
Diese gewisse Einmaligkeit setzt sich aus einer Vielzahl von Attributen zusammen. Diese sind anderen
- Zielvorgaben,
- zeitliche, finanzielle und personelle Faktoren und
- Abgrenzungen gegenüber anderen Projekten.

Die Gesamtheit aller Attribute zeigt dazu die Einmaligkeit eines Projektes an. (Vgl. Pabst-Weinschenk o.J. (b))

1.1.2 Softwareprojekt

Nachfolgend soll definiert werden, was unter einem Softwareprojekt zu verstehen ist. Dazu soll zuerst geklärt werden, was Software im Einzelnen ist.

Software

Eine Software kann in einem engeren Sinne und in einem weiteren Sinne definiert werden. Im Folgenden werden beide Definitionen aufgeführt und näher betrachtet.

1.1.2.1.1 Software im engeren Sinne

Im engeren Sinne sind unter dem Begriff Software

„Algorithmen, die in einer Programmiersprache beschrieben sind“ (Schlingloff, 2002)

zu verstehen, somit jegliche in einer beliebigen Programmiersprache geschriebenen Codezeilen. Diese Definition bezieht sich auf die immateriellen Elemente, die durch eine Programmierung erzeugt werden können. Es handelt sich hierbei um eine zusammenfassende Beschreibung von Programmen, die zur Ausführung auf einer Maschine vorgesehen sind. Dabei wird zwischen System und Anwendungssoftware sowie Entwicklungssoftware unterschieden. (Vgl. Hansen & Neumann, 2005)

1.1.2.1.2 Software im weiteren Sinne

Software im weiteren Sinne bezeichnet

„Jede Art von geistigem Artefakt, welches zur Ausführung auf einer Maschine konzipiert ist (also auch: Spezifikationen, Diagramme, Konstruktionszeichnungen, Pläne, […])“ (Schlingloff, 2002).

Das Verständnis der Software im weiteren Sinne ergänzt somit den Softwarebegriff im engeren Sinne um die zugehörige Dokumentation. Insbesondere können hierunter auch die organisatorischen Richtlinien und Verfahrensregeln verstanden werden.

1.1.2.2 Softwareproduktlebenszyklus

Der Softwareproduktlebenszyklus umfasst die Zeitspanne von der ersten Initialisierung eines Softwareentwicklungsprozesses bis hin zur Entsorgung der Software oder deren Ablösung durch ein Nachfolgeprodukt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.1: Softwarelebenszyklus

(In Anlehnung an Schlingloff 2002 (b), S.4)

1.1.2.3 Softwareprojekt

Nachdem nun die Begriffe Projekt, Software und Softwareproduktlebenszyklus definiert worden sind, kann auf dieser Grundlage ein Softwareprojekt näher beschrieben werden. Ein Softwareprojekt ist ein Projekt, dessen Ziel die Erstellung oder Wartung eben dieses Softwareproduktes ist und das sich über einen Teil oder über den gesamten Softwareproduktlebenszyklus erstrecken kann.

Wie aus der obigen Abbildung hervorgeht, lässt sich der Softwareproduktlebenszyklus in verschiedene Abschnitte unterteilen. Dabei können drei Phasen besonders herausgearbeitet werden, die im Nachfolgenden dargestellt werden.

1.1.3 Vorvertrag

Diese Phase umfasst den Softwareproduktlebenszyklus von der ersten Projektinitiierung, also dem ersten Kontakt mit dem Auftraggeber, bis zum Vertragsabschluss. In dieser Phase erfolgt die Kontaktaufnahme zwischen dem Auftraggeber – dem Empfänger der Leistung eines Softwareprojektes ­­­– und dem Auftragnehmer – dem Erzeuger der Leistung eines Softwareprojektes. Hier erfolgt die Sondierung der Wünsche des Auftraggebers, die als sogenanntes Lastenheft schriftlich niedergelegt werden. Dabei werden die Kundenwünsche in quantifizierbarer und prüfbarer Form dargestellt. Das Lastenheft dient als Ausschreibungs-, Angebots- und Vertragsgrundlage. Auch wird in dieser Phase das sogenannte Pflichtenheft erstellt, das zum einen das Lastenheft enthält und vom Auftragsnehmer mit detaillierten Realisierungsanforderungen ergänzt wird. Es dient als Basis für die Durchführung von Abnahmen und als verbindliche Vereinbarung zur Projektabwicklung.

Als Gegenpool zum Pflichten- und Lastenheft kann im Vertrag auch eine Abgrenzung der zu erbringenden Leistung erfolgen. Dabei werden die Kundenwünsche in nicht detaillierter Form vertraglich festgehalten und durch vertragliche Zusätze dahingehend ergänzt, was noch zur Projektrealisierung gehört bzw. was sich außerhalb der Projektrealisierung bewegt und ein Change-Request erfordert.

Aus dieser Phase, die als Angebots- und Nachfragephase gesehen werden kann, geht ein Softwareprojektvertrag hervor.

Nach (Schlingloff 2002(b)) betrifft dies die Bereiche „Projektinitialisierung“, „Anforderungserhebung“, „Wirtschaftlichkeits- und Marktstudie“, „Ausschreibung und Angebot“ sowie „Bestellung“.

Innerhalb der Vorvertragsphase lassen sich somit verschiedene Teilabschnitte unterscheiden:

- Initialer Start

In diesem Teilabschnitt erfolgt die erste Kontaktaufnahme. Oftmals erfolgt diese durch den Kunden.

- Erstes Gespräch

In diesem Teilabschnitt, der zeitlich durchaus mit dem initialen Start zusammenfallen kann, erfolgt eine erste grobe Anforderungsdefinition. Dabei können auch eine Spezifikation der genutzten Technologien und eine erste grobe Abschätzung des benötigten Zeitrahmens erfolgen. Auch können hier Besonderheiten oder Vorgehensmodelle spezifiziert werden.

- Ausschreibung

Nach dem ersten Gespräch erfolgt durch den Kunden die Ausschreibung des Projektes. Diese Ausschreibung kann an einen Anbieter, aber auch an eine Gruppe von Anbietern adressiert werden. In diesem Teilabschnitt erfolgt die Erstellung einer genaueren Spezifikation, möglicherweise in Form eines Lastenheftes, eines Anforderungskatalogs oder eines Grobkonzeptes.

- Angebot

Das Erstellen des Angebotes kann, besonders bei größeren Aufträgen, im Anschluss an den Teilabschnitt der Ausschreibung erfolgen. Auch wenn die Ausschreibung an mehrere Auftragnehmer adressiert ist, erfolgt eine Erstellung eines Angebotes. Das Angebot umfasst dabei fachliche Einschätzungen aus Sicht des Auftragnehmers, die die Umsetzung der aus der Ausschreibung hervorgehenden Anforderungen beinhaltet. Dazu gehört die Machbarkeitsstudie. Auch eine kaufmännische Einschätzung des Aufwands erfolgt an dieser Stelle. Hier werden die technologischen Voraussetzungen, die durch den Kunden vorgegeben sind dargestellt und das Risiko, das mit einer Entwicklung einhergeht, betrachtet. Auch die Personaleinsatzplanung und der Zeitrahmen werden hier bereits festgeschrieben. Das Angebot wird auf Einhaltung von gesetzlichen Vorschriften geprüft und enthält eine Bindungsfrist.

- Vertragsverhandlungen

Im Anschluss an die Erstellung des Angebotes kann es zu einer Angebotsannahme kommen. Dabei werden offene Punkte offensichtlich, die zu einer Rückkopplung in eine frühere Phase – an die Angebots-, teilweise sogar die Ausschreibungsphase – führen. Im besten Fall erfolgt die Leistung der Unterschriften. Anders als in der theoretischen Vorannahme erfolgt jetzt nicht zwingend die Erstellung eines Pflichtenheftes. Oftmals werden in der praktischen Umsetzung des Vertrages die Anforderungen abgegrenzt, wodurch eine Beschränkung des Softwareentwicklungsprojektes erfolgt. Dieses Vorgehen ermöglicht eine ungenaue Definition der Umsetzung, was dem Auftragnehmer entgegenkommt, da zur Zeit der Entwicklung die Umsetzung angepasst werden kann. Auch der Auftraggeber profitiert von diesem Vorgehen, da er seine Anforderungen zum Vertragsabschluss nicht detailliert formulieren muss. So wird die Softwareentwicklung innerhalb der Abgrenzungen durchgeführt, was beiderseitig Spielräume ermöglicht und die Vertragsgestaltung erheblich vereinfacht. Der Softwareerstellungsvertrag (Individualsoftware) ist derzeit ein Werk- und Liefervertrag mit Nutzungseinräumung. Nach der Entscheidung des BGH vom 23.7.2009 (Aktenzeichen VII ZR 151/08) kann sich dies jedoch bald ändern.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.2: Ablaufphase Vorvertrag

(Quelle: eigene Grafik)

1.1.4 Entwicklung

In der nachfolgenden Phase erfolgt die Umsetzung der in der Vorvertragsphase entstandenen Anforderungen an das Softwareprojekt. Dazu kann es notwendig bzw. wirtschaftlich sein, Teile des Softwareprojektes an Zulieferbetriebe auszugliedern, so dass es in Bezug auf die Zulieferbetriebe ebenfalls zu einer Vorvertragsphase kommt. Dieses erneute Eintreten in eine Vorvertragsphase erfolgt unter dem Gesichtspunkt, dass der Auftragnehmer zum Auftraggeber wird und der Zulieferbetrieb zum Auftragnehmer. Die Entwicklung dieser Teilprojekte erfolgt dann im Zulieferbetrieb, für den die Phasen der Entwicklung und des Betriebsübergang analog gelten.

Es erfolgt in dieser Phase die Implementierung der Anforderungen aus dem Pflichtenheft. An die Implementierung der Anforderungen schließt die Endabnahme durch den Auftraggeber an. Sofern im Pflichtenheft Nachbesserungen, Installationen und Schulungsmaßnahmen vorgesehen sind, gehören diese ebenfalls in die Phase der Entwicklung. In Abb. 1.1 betrifft dies die Bereiche „Entwicklung“, „Systemintegration“, „Abnahme“ und, sofern dies Bestandteil des Pflichtenheftes ist, „Erste Schulungen und Installation“.

1.1.5 Nachvertrag

Nach erfolgter Abnahme erfolgt die Nachvertragsphase. Diese Phase beinhaltet die weiterführenden Schulungsmaßnahmen und weitere Installationen, die nicht im Pflichtenheft vorgesehen sind und aufgrund weiterer vertraglicher Vereinbarungen entstehen. Der Auftragnehmer führt in dieser Phase Wartungsarbeiten durch, leistet entsprechenden Support und führt ggf. weitere Schulungen durch. Den Abschluss findet diese Phase in der Außerdienststellung der Software. In Abb. 1.1 betrifft dies die verbleibenden Bereiche „Weiterführende Installation und Anwenderschulung“, „Einsatz, Support und Wartung“ sowie „Außerdienststellung, Entsorgung“.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 1.3: Drei Phasen des Softwareprojektes

(Quelle: eigene Grafik)

1.2 Softwareprojekt im Sinne dieser Arbeit

Diese Arbeit beschäftigt sich mit dem Controlling von Softwareentwicklungsprojekten, somit stehen Softwareprojekten in der Entwicklungsphase im Mittelpunkt der Untersuchung.

2 Entwicklung eines Frameworks

Bevor spezifiziert werden kann, was das Framework leisten soll, muss definiert werden, was im Sinne dieser Arbeit unter dem Begriff Framework zu verstehen ist.

2.1 Begriffsdefinition Framework

Der Begriff Framework stammt aus dem englischen Sprachgebrauch. Ins Deutsche übersetzt bedeutet er „Bezugssystem“, „Gerippe“, „Fachwerk“, „Grundstruktur“, „Rahmen“, „Gerüst“.

Im Sprachgebrauch der Informationswissenschaften bedeutet dieser Begriff Programmiergerüst im Sinne einer komponentenbasierten Entwicklung von Software.

Im wirtschaftswissenschaftlichen Kontext wird der Begriff des Frameworks in Assoziation mit den IAS, den International Accounting Standards, gebracht, genauer dem „Framework for the Preparation and Presentation of Financial Statements“. Hier soll ein Framework eine

„[…] konzeptionelle Grundlage für die Erarbeitung und Anwendung von Rechnungslegungsvorschriften […]“

liefern. (Vgl. Wirtschaftslexikon 2000)

In Hinblick auf diese Arbeit, die Controlling als zentrales Thema hat, soll der Begriff des Frameworks in Anlehnung an die wirtschaftswissenschaftliche Interpretation des Begriffes Framework verstanden werden als

„Grundlage für die Erarbeitung und Anwendung von IT-Controlling-Maßnahmen im Bereich von Softwareentwicklungsprojekten“.

Hierfür soll das Framework einen Handlungsrahmen geben, der nicht zwingend verbindlich, aber richtungsweisend darstellen soll, wie ein IT-Projektcontrolling eingeführt werden kann.

2.2 Ableiten eines Frameworks

In den folgenden Abschnitten soll die Ableitung eines solchen Frameworks dargestellt werden.

2.2.1 Was soll durch dieses Framework erreicht werden?

Das hier vorgestellte Framework soll einen Handlungsrahmen vorgeben, der durch Anpassung eine Einführung von IT-Controlling ermöglicht, um einfach und schnell ein IT-Projekt bewerten zu können. Dabei soll bewusst darauf verzichtet werden, ein verbindliches Konzept vorzustellen, da eine Adaption des Frameworks durch Anpassung an die unternehmensspezifischen Gegebenheiten möglich sein soll. Um das so gesetzte Ziel zu erreichen, müssen zuerst die notwendigen Grundlagen zum Verständnis von Softwareentwicklungsprojekte gelegt werden, was in den folgenden Abschnitten erfolgen soll.

2.3 Entwicklungsmodelle

In der Softwareentwicklung wird zwischen agilen und klassischen Softwareentwicklungsprozessen unterschieden. Beide Prozessarten stellen unterschiedliche Anforderungen an das Projektmanagement in den verschiedenen Phasen des Softwareproduktlebenszyklus. Nachfolgend sind einige Beispiele dieser Prozessarten aufgeführt. Auf eine detaillierte Betrachtung soll an dieser Stelle jedoch verzichtet werden, da dies nicht Bestandteil dieser Arbeit sein kann.

2.3.1 Klassische Vorgehensmodelle

2.3.1.1 „Code und Fix“

„Code und Fix“-Vorgehensmodelle stammen aus der Anfangszeit der Rechnertechnologien, als Software noch von einem einzelnen Programmierer entwickelt und gewartet wurde. Die Software wird „on the fly“ zu den Anforderungen entwickelt und Fehler werden im laufenden Betrieb behoben. Dies ist ein eher unstrukturiertes Vorgehen, da direkt und ohne weitere Planung mit der Implementierung begonnen wird. (Vgl. Stein 2004)

2.3.1.2 Wasserfallmodell

Das Wasserfallmodel gliedert die Abläufe der Softwareentwicklung in mehrere Phasen auf, die stufenweise durchlaufen werden können. Dabei gehen die Ergebnisse einer Stufe in die nachfolgende über. Rückkopplungen sind hier maximal in die vorgelagerte Stufe vorgesehen. (Vgl. Hansen & Neumann, 2005, S. 246-284)

2.3.1.3 V-Modell

Das V-Modell ist eine Weiterentwicklung des Wasserfallmodells. Hier werden die Phasen V-förmig angeordnet und in verschiedene Tätigkeitsbereiche untergliedert. Dabei soll die horizontale Ebene die Zeitachse (von links nach rechts laufend) und die vertikale Ebene den Detaillierungsgrad (von oben nach unten zunehmend) angeben. (Vgl. Müller, 2002)

2.3.2 Agile Vorgehensmodelle

Agile Vorgehensmodelle ermöglichen die Rückkopplung des Softwareentwicklungs-prozesses in jede der vorhergehenden Phasen. Dabei wird diese Rückkopplung als Bestandteil der Softwareentwicklung angesehen.

2.3.2.1 Prototyping

Beim Prototyping werden verschiedene Bereiche der zu entwickelnden Software exemplarisch implementiert, ohne den vollen Funktionsumfang zu gewährleisten. Diese Prototypen erfüllen unterschiedliche Anforderungen, beispielsweise um das Design der Oberfläche darstellen zu können. Auch können nur bestimme Funktionen implementiert sein, beispielsweise um die Realisierbarkeit funktionaler Anforderungen zu bestimmen. So unterscheiden sich horizontale und vertikale Prototypen hinsichtlich der implementierten Funktionalität. Prototypen werden für Laborversuche, Demonstrationszwecke, Pilotsysteme etc. entwickelt. (Vgl. Müller, 2002)

2.3.2.2 Spiralmodell

Das Spiralmodel durchläuft verschiedene Zyklen der Softwareentwicklung mehrfach. Hierbei wird die Softwareentwicklung der aktuellen Phase durch die Ergebnisse der vorhergehenden Phase maßgeblich beeinflusst. Dabei werden zuerst die Anforderungen definiert, dann entsprechende Lösungsvarianten erarbeitet, diese implementiert und aus dieser Implementierung eine erneute Definition der Anforderungen geplant und initiiert. (Vgl. Hansen & Neumann 2005, S. 246-284)

2.3.2.3 Evolutionäres Prototyping

Evolutionäres Prototying beinhaltet die Entwicklung von Prototypen in Verbindung mit dem Spiralmodell. Dabei wird zunächst eine lauffähige Software erstellt und dem Auftraggeber zur Verfügung gestellt. Dieser erste Prototyp berücksichtigt noch kein Oberflächendesign und implementiert nur die Grundfunktionalität. In Rücksprache mit dem Auftraggeber wird dieser (lauffähige) Prototyp weiterentwickelt zu einem weiteren Prototyp. Dieser wird erneut dem Auftraggeber zur Verfügung gestellt und erneut in Rücksprache mit diesem weiterentwickelt. Dieser Prozess läuft in mehreren Iterationen ab. (Vgl. Fechter, 2007, S. 7)

2.3.2.4 Experimentelles Prototyping

Ein experimenteller Prototyp findet sich hauptsächlich im Bereich Forschung und Entwicklung. Hierbei handelt es sich um einen Prototypen, der dazu dient, neue Kenntnisse über einen bestimmten Sachverhalt zu erlangen. Dieser Prototyp ist nicht dazu gedacht, produktiv eingesetzt zu werden, da aufgrund seiner experimentellen Natur nicht davon ausgegangen werden kann, dass die zugrundeliegende Programmierung den Regeln einer sauberen Softwareentwicklung entspricht. Oftmals entstehen die Programmierschritte spontan und „aus der Situation“ heraus. Dieser Prototyp ist jedoch sehr gut geeignet, um eine Grundlage zur weiteren Entwicklung zu geben, da viele Problemstellungen bereits durch die spontane Programmierung evaluiert sind und Lösungsansätze aufzeigen. Er kann somit als „Blue-Print“ für eine Entwicklung angesehen werden. (Vgl. Kuhrmann, 2010; Wikipedia 2010)

2.4 Das Controlling-Gebiet

Im Rahmen dieser Arbeit soll als Controlling-Gebiet ein Softwareentwicklungsprojekt wie unter Kap. 1.2 beschrieben verstanden werden. Dabei beginnt die Erfassung der Kenngrößen nach dem Abschluss des Vertrages und endet mit dem Betriebsübergang. Alle Kenngrößen sollen hinsichtlich Ihrer Istgrößen (Ist) zur Projektsteuerung herangezogen werden können. Das Controlling-Gebiet umreißt damit klar die steuerungsrelevanten Kenngrößen innerhalb der Entwicklungsphase eines Softwareprojektes. Diese Definition soll gleichzeitig zur Abgrenzung herangezogen werden.

2.5 Ziele

Um ein Controlling durchführen zu können, müssen zuerst die zu erreichenden Ziele definiert werden. Für jedes Gebiet, das einem Controlling unterzogen werden soll, leiten sich die Ziele aus den Unternehmenszielen ab. Für ein Softwareprojekt können exemplarisch folgende Ziele angenommen werden:

- Budgeteinhaltung
- Zeiteinhaltung
- Kundenzufriedenheit sicherstellen
- Mitarbeiterzufriedenheit sicherstellen
- Strategische Ausrichtung des Projektes
- Know-how-Erweiterung
- …

Eine genauere Definition wie im Kap.1.1.1 würde jedoch den hier gesetzten Rahmen überschreiten.

2.5.1 Kennzahlen

Kennzahlen erfassen Zustände zu einem bestimmten Zeitpunkt in quantitativer und konzentrierter Form. Sie dienen insbesondere der Erfassung von Ist-, Soll- und Plangrößen. Ohne Kennzahlen wäre eine Steuerung in Form von Controlling nicht möglich. Eine Auswahl der benötigten Kennzahlen erfolgt gemäß der Zielsetzung des Controlling-Gebietes.

2.5.1.1 Kennzahlenordnungssystem

Bei der Betrachtung von Kennzahlen fällt schnell auf, dass die Menge aller Kennzahlen annähernd unerschöpflich ist, selbst auf einen bestimmten betrieblichen Kontext ausgerichtet finden sich schnell einige hundert mögliche Kennzahlen. Erweitert man diese Perspektive auf die Menge aller möglichen Branchen, so steigt die Kennzahlenmenge noch deutlich an. Um diese Menge von Kennzahlen zu einer einzigen aggregieren zu können, muss ein Ordnungssystem eine hierarchische Abbildung dieser Menge von Kennzahlen ermöglichen und von einer einzigen Wurzel abgeleitet sein. Dabei soll ein Kennzahlensystem die Kennzahlen in sachlogische, nicht zwingend in mathematische Zusammenhänge stellen (Vgl. Wirtschaftslexikon24.net). Ein gelungenes Ordnungssystem, das eine hierarchische Darstellung ermöglicht, ist der Kontorahmen der doppelten Buchhaltung, SKR03. In Anlehnung an dieses System soll auch hier ein Ordnungssystem erstellt werden. In Anhang C ist exemplarisch das hier vorgeschlagene System dargestellt. Die Diskussion der Zuordnung der Kennzahlen in diesem System erfordert umfangreichere Untersuchungen und würde den Rahmen dieser Arbeit überschreiten. Die vorgenommene Zuordnung dient daher nur der Erläuterung des Systems. Auch entbehrt das System jeder Vollständigkeit, da auch die Gliederung des Ordnungssystems einer genaueren Untersuchung bedarf.

Ein solches System sollte entsprechend einer Top-down-Vorgehensweise, d.h. von oben nach unten entwickelt werden. Dabei sollte ein zentraler Knotenpunkt angelegt werden, dieser ist im Anhang D durch die oberste Position „Kennzahlen-Ordnungssystem“ dargestellt. Um die darunterliegenden Klassen einem bestimmten Bereich zuordnen zu können, wird eine Klassifizierung der einzelnen Bereiche in 12 Perspektiven oder Sichten vorgenommen:

Abbildung in dieser Leseprobe nicht enthalten

Tab. 2.1: Tabelle Kennzahlenperspektiven

(Quelle: eigene Grafik)

In den Perspektiven mit der Codierung 0 bis 9 sollte jede Kennzahl eindeutig zugeordnet werden. Diese Zuordnung verhindert ein doppeltes Erfassen von Kennzahlen, da eine redundante Haltung von Kennzahlen zu unterschiedlicher Bewertung führen kann. Die Bereiche A und B enthalten hingegen keine eindeutig zuordnungsfähigen Kennzahlen. Hier finden sich nur Kennzahlen, die bereits in den Perspektiven 0 bis 9 enthalten sind. Durch dieses stringente Vorgehen wird sichergestellt, dass alle Kennzahlen einer entsprechenden Sicht sowie ggf. der Stakeholder- bzw. Shareholderperspektive zugeordnet sind. Dies lässt eine separate Auswertung der Stakeholder- und Shareholderperspektive zu, stellt aber gleichzeitig sicher, dass alle Unternehmenskennzahlen in einer Bewertung der Perspektiven 0 bis 9 enthalten sind.

Der Begriff Perspektiven bzw. Sichten dient somit der Klassifizierung der Kennzahlenklassen für eine bestimmte Sichtweise auf die Kennzahlen. Dabei wird sich auf die wichtigsten Bereiche von Unternehmen beschränkt.

Die Zuordnung der Klassen zu der jeweiligen Perspektive erfolgt in hierarchischer Rangfolge. Das Vorgehen ist top-down. Jede Kennzahlklasse hat somit einen Vorgänger, die obersten Klassenstrukturen haben als Vorgänger die Wurzel und werden den einzelnen Sichten bzw. Perspektiven zugeordnet. Eine Klassifizierung kann dabei nach den folgenden Gesichtspunkten gegliedert werden:

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.1: Kennzahlenklassen

(Quelle: eigene Grafik)

Jede Klasse kann als Zweig eines Kennzahlenbaumes betrachtet werden. Die Tiefe der Gliederung kann dabei beliebig variiert werden, jedoch sollte eine Klassifizierung bis zur „Subklassifikation 2“ angestrebt werden. Auf diese Weise lässt sich eine Zuordnung der Kennzahlen zu einem Klassenzweig leichter nachvollziehen. Die Klassenzweige sollten innerhalb eines Vorgängerzweiges fortlaufend nummeriert werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.2: Nummerierung der Kennzahlenklassen

(Quelle: eigene Grafik)

Ein solches Vorgehen lässt eine nummerische Notation zu, die das Auffinden von Klassen innerhalb des Kennzahlenordnungssystems erleichtert. Eine Notation in der Schreibweise 1.1.2.4 zeigt eindeutig, welcher Zweig angesprochen wird.

Kennzahlen werden unterhalb der Klassen angeordnet. Sie können als Blätter im Klassenbaum betrachtet werden. Um eine Kennzahl unterhalb eines Klassenzweiges zu identifizieren, sollten diese durchnummeriert werden. Dabei sollte folgende Syntax eingehalten werden: beginnend bei der ersten Kennzahl mit einer Codierung 0001 und dann fortlaufend. Die vierstellige Syntax mit führenden Nullen ermöglicht eine Kennung der Kennzahl als solche bei der Notation 1.1.2.4.0001. Hier zeigen die ersten vier Elemente einen Klassenzweig an, die letzte Ziffer eindeutig eine Kennzahl. Zusätzlich empfiehlt sich die Trennung durch ein „/“-Zeichen: 1.1.2.4/0001. Aggregierte Kennzahlen finden sich in den oberen Zweigen der Hierarchie des Kennzahlensystems. Als grafische Notation empfiehlt sich eine achteckige Darstellung der Kennzahlen und eine rechteckige Darstellung der Klassen. Ein farbliches Absetzen erhöht dabei die Lesbarkeit.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.3: Darstellung im Kennzahlenordnungssystem

(Quelle: eigene Grafik)

2.5.1.2 Kennzahlensteckbrief

Um Kennzahlen eindeutig zu beschreiben und jederzeit nachvollziehen zu können werden Steckbriefe eingesetzt (vgl. Gómez, Junker, Odebrecht 2009). Diese Steckbriefe können die Verantwortlichkeit in Form einer Rolle, Gültigkeitszeiträume, Wertekorridoren, Adressaten, Messverfahren, Berechnungswege etc. enthalten. Beispielhaft ist ein Kennzahlensteckbrief in der nachfolgenden Abbildung zu sehen. Zusätzlich zu diesen Angaben ist eine Angabe über eine Ordnungsnummer sinnvoll, da hieraus die Zugehörigkeit bei aggregierten Kennzahlen ersichtlich wird. Dazu sollte ein Kennzahlenordnungssystem wie das vorgeschlagene verwendet werden, dieses ermöglicht das „Herauslösen“ und „Einfügen“ von Kennzahlen in den betrieblichen Kennzahlenordnungsrahmen. Ein unvollständiger Vorschlag für ein solches System findet sich im Anhang C. Die vollständige Ausarbeitung dieses Kennzahlensystems liegt nicht im Rahmen der Untersuchung dieser Arbeit und soll daher nicht weiter vertieft werden. Eine Kennzahl sollte auch einer bestimmten betrieblichen Perspektive zugeordnet werden können, diese Zuordnung kann ebenfalls bereits durch das Kennzahlenordnungssystem erfolgen (siehe Anhang C). Zusätzlich sollte die betriebliche Perspektive im Kennzahlensteckbrief deutlich hervorgehoben werden.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.4: Kennzahlsteckbrief

(Quelle: eigene Grafik)

In dieser Arbeit erfolgt eine exemplarische Erstellung der Kennzahlensteckbriefe unter Zuhilfenahme eines Tabellenkalkulationsprogrammes. Empfehlenswert ist die praktische Umsetzung im größeren Umfang jedoch durch die Realisierung in einer Datenbankapplikation, da so Datenredundanz vermieden werden kann und die Daten als Metadaten abgelegt werden können. Die Erstellung einer derartigen Datenbankapplikation soll hier nicht vertieft werden, um die thematische Orientierung der vorliegenden Arbeit nicht aus dem Auge zu verlieren, da eine solche Erstellung den direkten thematischen Bezug schuldig bliebe. Jedoch wird eine Prototypenumsetzung im Rahmen eines praktischen Beispiels erfolgen. (Vgl. hierzu Kap.3.)

2.5.1.3 Kennzahlen

Um ein Verständnis der Komplexität einer Projektbeurteilung zu erlangen, sollen nachfolgend einige Kennzahlen dargestellt werden, die in einer Projektbewertung eine Rolle spielen können.

2.5.1.3.1 Projektkennzahlen

Beispielhaft sollen hier folgende Projektkennzahlen genannt werden:

- Budget
- Ausschöpfung
- Reichweite
- Ressourcen
- Anzahl der Mitarbeiter
- Auslastungsgrad
- Verfügbarkeit (Urlaub/Krankheit)
- Termine
- Bisherige Projektdauer
- Noch erforderliche Projektdauer
- Meilensteintermine
- Risiko-Management
- Anzahl der Risiken
- Noch offene Risiken
- Fertigstellungsgrad
- Fachlicher Fertigstellungsgrad
- Kostenmäßiger Fertigstellungsgrad
- Zeitlicher Fertigstellungsgrad

2.5.1.3.2 IT-Projekt-Kennzahlen

Für IT-Projekte kommen folgende Kennzahlen beispielhaft hinzu:

- Informationsbeschaffung
- Nachrichten und Informationskennzahlen
- Internetzugriffe

2.5.1.3.3 Miet- und Leasing-Kosten

Die zur Leistungserstellung benötigten Räumlichkeiten werden in dieser Kennzahl erfasst. Dabei können die Kosten für eigene Räumlichkeiten des Unternehmens oder für gemietete bzw. gepachtete Räumlichkeiten anfallen. Auch für die Miete von Hard- und Software können Mietkosten auftreten. Die Mietkosten können als aggregierte Kennzahl gehandhabt werden. Es erfolgt eine Klassifikation der Kosten in die Klassen „Grundstücke“, „Gebäude“, „Hardware“ und „Software“. Gemäß dem Kennzahlenordnungssystem entsteht die Kennzahl „Miete“ aus den Kennzahlen einer tieferen Gliederungshierarchie. Diese sind bereits hinsichtlich Erfassungsintervall und Erfassungszeitraum „normalisiert“, d. h. auf ein gemeinsam nutzbares Intervall gebracht, was ggf. in einer tieferen Gliederungshierarchie erfolgt.

Abbildung in dieser Leseprobe nicht enthalten

Abb. 2.5: Kennzahl „Miete“

(Quelle: eigene Grafik)

[...]