Im Folgenden gebe ich einen Überblick über die Entstehungsgeschichte unseres comPASS-Portals und liefere Einblicke in die von PASS verwendete Construction Line.
Den Begriff der Verfahrenstechnik verwendet man üblicherweise in der industriellen Produktion. Wir sehen bei PASS auch Softwareentwicklung als einen industriellen Produktionsprozess, wobei insbesondere dessen Vorbereitung (Requirements Management, Spezifikation), aber auch die Standardisierung und Automatisierung der “Produktionsmethoden” sehr viel Kreativität und Wissensarbeit erfordern.
Das Portal comPASS beschreibt unsere Verfahrenstechnik für verschiedene Bereiche, in denen wir tätig sind. Ich möchte an dieser Stelle den herausforderndsten Bereich daraus kurz vorstellen: komplexe Kundenprojekte. Das “komplex” bezieht sich dabei auf die Vielfalt der unterschiedlichen Leistungstypen, d.h., es geht dabei selten wirklich nur um Softwareentwicklung. Vorstellen möchte ich insbesondere, wie wir diesen Herausforderungen seit mehreren Jahrzehnten begegnen.
Der Ursprung von comPASS – ein Ausflug in die Geschichte von PASS
PASS hat seine Wurzeln in der Softwareentwicklung. Die Gründungsidee, individuelle Software zum Preis von Standardsoftware zu entwickeln, erforderte bereits vor über 40 Jahren ein strukturiertes Vorgehen, die geschickte Wiederverwendung von Software und das Selbstverständnis permanenter Verbesserung als höchstes Ziel. Eigene Vorgehensmodelle sicherten die Lösungsqualität eines wachsenden Unternehmens und waren dabei auch Basis für die Beratung vieler Kunden. Anfang 2010 flossen die bis dahin zahlreichen Dokumente und Foliensätze in ein erstes Portal namens comPASS ein. Mit seiner zentralen Verfügbarkeit innerhalb des Unternehmens, abgestimmten Prozessbeschreibungen, Methoden, Good Practices, Tools usw. entwickelte sich comPASS schnell zu einer bedeutenden Wissensbasis.
Die Bandbreite unseres Geschäfts
In den letzten Jahren haben wir immer häufiger die Erfahrung gemacht, dass unsere Kunden neben der Entwicklung von Individualsoftware und den klassischen Beratungsleistungen auch noch viele andere Arten von Leistungen benötigen. Neu entwickelte Software musste regelmäßig auch in eine frische Systemlandschaft integriert werden. Oft war dabei eine der Anforderungen, dass auch Daten aus einem alten System übernommen werden. Immer mehr Kunden waren daran interessiert, dass PASS die neu entwickelte Software auch gleich selbst betreibt. Neben den Neuentwicklungen kamen bald auch das Hosting von Fremdsystemen hinzu sowie immer mehr Standardlösungen, die PASS selbst erfolgreich am Markt positioniert hat. Auch die Vereinbarungen zur Wartung und Nutzung der PASS Systeme wurden immer aufwendiger, insbesondere in den Geschäftszweigen, welche von der Finanzaufsicht reguliert werden. Branchen, in denen PASS sehr erfolgreich war und ist.
Der Irrtum von Konrad Zuse
Gehen wir zeitlich noch einen kleinen Schritt zurück in die Zeit der Erfindung des Computers. Konrad Zuse war Bauingenieur sowie Fabrikant und baute 1941 mit seinem Z3 als vermutlich Erster einen funktionstüchtigen Computer. Aufgrund seiner Erfahrungen als Fabrikant konnte er sich sehr gut vorstellen, dass man mit der industriellen Fertigung einer durch Software steuerbaren Maschine, d.h. hauptsächlich mit der Hardware, gutes Geld verdienen konnte. Die Software selbst sah er jedoch nur als “Mittel zum Zweck”, als ein notwendiges Anhängsel, das sich nicht kommerziell vermarkten lies. Erst IBM und andere korrigierten nach dem Kauf der Rechte diesen Irrtum.
Verschiedene Lines definieren Prozesse
Auch PASS war zunächst sehr fokussiert auf die Softwareentwicklung. Heute bedienen wir unsere Kunden jedoch mit einer breiten Palette zusätzlicher, ergänzender Leistungen, die wir im Laufe der Jahre professionalisiert haben. Die heutige Verfahrenstechnik, wie sie im comPASS-Portal beschrieben ist, unterteilt das Projektgeschäft bereits bei den ersten Vorgesprächen in sechs Leistungskategorien, von denen jede mit einer Analyse, der Erstellung einer Spezifikation und der Abstimmung vertraglicher Vereinbarungen beginnt. Davon ist Softwareentwicklung nur eine Kategorie – wir sprechen von der Construction Line oder kurz cLine.
- Die Migration von Daten ist in der Migration Line (mLine),
- die Übernahme von Fremdsystemen in die Betriebsverantwortung von PASS in der Transition Line (tLine) und
- die Integration eines PASS Standardsystems in die Arbeitsabläufe eines Kunden in der Integration Line (iLine) festgehalten.
- Die Aufbauleistungen für Betrieb und IT-Servicemanagement finden sich in der Service Line (sLine) und
- die Abstimmung von Vereinbarungen zur Nutzung von PASS Software sind in der Licensing Line (lLine) beschrieben.
Diese Lines finden sich bildlich in der Pyramide wieder, die als Symbol der comPASS-Verfahrenstechnik verwendet wird. Sie hat eine Wabe als Grundfläche und jede Stirnseite der Pyramide stellt eine dieser Lines bzw. Leistungskategorien dar.
Die langsame Auflösung der Silos
Das erste, in 2010 begonnene comPASS-Portal war sicherlich ein wichtiger Meilenstein. Prozesse und Methoden zur Neuentwicklung von Software, auch das zugehörige Projektmanagement sowie konstruktive und analytische Qualitätssicherung, waren dort mit gutem Detaillierungsgrad beschrieben. An den Schnittstellen dieser Prozesse beispielweise zum Vertragswesen, zu vertrieblichen Themen oder auch zu Wartung und Betrieb fanden sich meist nur Verweise auf Informationsquellen in anderen Systemen, die hinsichtlich ihrer Ausprägung und Nutzbarkeit “anders” waren. Selbstverständlich waren auch in diesen Unternehmensbereichen Prozesse und Verfahren beschrieben. An dieser Stelle finde ich jedoch den Vergleich mit einer Landschaft voller Silos sehr passend: Aufgrund der (mehr oder weniger) Isolation in diesen Silos haben sich die Unternehmensbereiche für sich alleine gesehen gut, aber aus einer gewissen Distanz betrachtet völlig unterschiedlich entwickelt.
Heute gibt es diese Silos nicht mehr. Man kann nicht sagen, dass Silos “eingerissen” wurden, wie es ein beliebter Sprachgebrauch in der IT ist. Vielmehr handelt es sich um eine natürliche Entwicklung der Unternehmenskultur, die zu einer immer engeren Integration und Verzahnung von Prozessen geführt hat. Beschleunigt wurde diese Entwicklung endgültig durch den Digitalisierungsschub als Nebeneffekt der Corona-Pandemie.
Um zwei Beispiele aus comPASS zu nennen: Projektmanager füllen Leistungsscheine auf Vorlagen des Vertragscontrollings mit Inhalten, die für Angebote des Vetriebs oder für das mit dem Kunden abzustimmende – selbstverständlich digitale – Vertragswerk verwendet werden. Das Management für IT-Services und für den geplanten Systembetrieb wird bereits in der Analysephase aktiv in jedes Projekt eingebunden, so dass die zu erwartenden Kosten passend eingepreist und alle notwendigen Aufbauleistungen bei der Gesamtplanung berücksichtigt werden können.
Der Wert von Information
Die in comPASS beschriebene Vorgehensweise für Projekte basiert auf einer hohen Wertschätzung für jede im Projekt gewonnene Information. Daher wurden die ersten Vorgespräche mit einem potenziellen Auftraggeber, die erste Analyse seiner Ideen und deren Machbarkeit, zu einer eigenen Projektphase deklariert. Eine Projektphase, in der bereits mit der Erstellung von Spezifikationen begonnen wird. Die dort erarbeiteten und dokumentierten Informationen ergeben die Versionen 0.1 der Leistungsspezifikationen auf die wiederum in Angeboten für Folgephasen referenziert wird. In den folgenden Projektphasen werden dann genau diese Spezifikationen weiter fortgeschrieben und ergänzt, was einem Verlust oder einer “Korrosion” der Informationen vorbeugt.
Bei Projekten mit einem hohen Anteil an Neuentwicklung ist es die Regel, dass der Gesamtaufwand noch nicht bereits nach den Vorgesprächen fest und verlässlich ermittelt werden kann. Deshalb gibt es in der Vorgehensweise nach comPASS eine optionale Phase, die wir Vorprojekt oder Scope-Phase nennen. Sie dient hauptsächlich dem Ziel, die Annahmen und Prämissen, auf denen unsere erste Planung und Aufwandsschätzung basiert, zu verfeinern. Der Kunde erhält im Anschluss daran ein Angebot für alle nachfolgenden Phasen, für das sogenannte Hauptprojekt, das von deutlich weniger Unsicherheiten ausgeht. Das ist sowohl für PASS als auch für den Kunden von Vorteil. Ergeben die nachfolgenden Analysephasen dann schließlich ein vollständiges und schlüssiges Bild des Auftrags, wird das noch mit Unsicherheiten behaftete Angebot durch einen Projektvertrag mit exakten und verbindlichen Parametern ersetzt.
Ist ein Phasenmodell nicht old-fashioned?
Wir werden oft gefragt, ob ein Phasenmodell heute noch zeitgemäß ist und ob man Projekte nicht besser vollständig agil durchführen sollte. Bei der Antwort muss man berücksichtigen, dass es nicht “das agile Vorgehen” gibt, sondern dass Agilität in der Softwareentwicklung ein Set von Werten und Praktiken ist, die alle nur unter bestimmten Rahmenbedingungen nutzenbringend sein können. Die Verfahrenstechnik nach comPASS basiert durchaus auf mehreren agilen Werten:
- Enge Zusammenarbeit mit dem Auftraggeber.
- Die iterative Fortschreibung von Spezifikationen (in den ersten Projektphasen).
- Verfeinerung der Auftragsprämissen (in den ersten Projektphasen).
- Inkrementelle Entwicklungsprozesse.
- Regelmäßige Retrospektiven und abgeleitete Verbesserungsmaßnahmen der Prozesse und der gesamten Organisation.
Andere agile Methoden wie beispielsweise auf einem Backlog basierende kurze Sprints oder Time Boxing sind dagegen schwer mit der Erfüllung werkvertraglicher Lieferverpflichtungen zu vereinbaren. Sie können jedoch in anderem Kontext zum Einsatz kommen, beispielsweise wenn es um die interne kreative und marktgetriebene Entwicklung innovativer Softwareprodukte geht oder auch um exploratives Vorgehen ohne ein vorgegebenes und zu erreichendes Ziel.
Was ist nun comPASS wirklich?
Unser comPASS wird oft (neben der bildhaften Darstellung als Pyramide) durch einen Kompass symbolisiert, der dem Suchenden die richtige Richtung weist. Diese Symbolik passt gut, denn die Vorgehensmodelle, wie ich eines davon exemplarisch für komplexe Kundenprojekte angerissen habe, sollen den involvierten Kolleginnen und Kollegen auf Grundlage unseres in 40 Jahren erworbenen Wissens einen für ihre Aufgabe vorteilhaften Weg zeigen. Dabei ist comPASS kein Regelwerk der Geschäftsleitung, das unter allen Umständen einzuhalten ist. comPASS steht auch für kooperative Verantwortung des gesamten Unternehmens für Projekte und Produkte als gemeinsame (common) Verantwortung von PASS für unsere geschäftlichen Aktivitäten. In diesem Sinne ist jeder Mitarbeiter aufgefordert, sich in den Wissenspool comPASS einzubringen und an seiner Weiterentwicklung mitzuarbeiten.
Titelbild: Shutterstock
