SW-Produkte und langfristige Kundeninteraktion

In meiner Laufbahn bin ich immer wieder IT-Unternehmen oder IT-Abteilungen begegnet, die zwar wohldefinierte SW-Projekte im Kundenauftrag durchführen, die aber dennoch Schwierigkeiten mit der „langfristigen SW-Produkt-Pflege“, einer auf Dauer angelegten Kooperation mit dem Kunden und mit Prozessen des IT-Service-Managements [ITSM] haben. Allzu oft verengt sich der Blick der Geschäftsverantwortlichen auf das Management von begrenzten, zeitlich limitierten SW-Projekten. Vielfach liegt dies auch an der Vertragsgestaltung.

Die Tatsache, dass die vom Kunden bestellten Individual-Software meist in einem Service zum Tragen kommt, der gegenüber internen oder externen Endkunden auf Dauer erbracht wird, und das sowohl Service wie auch Produkt regelmäßig an sich ändernde Anforderungen des Marktes angepasst werden müssen, gerät dabei ins Hintertreffen.

Das zeigt sich u.a. in der Ausbildungsstrategie: Der IT- und Entwickler Nachwuchs wird primär auf system-, tool- oder sprachbezogenen Kurse geschickt. Als nächstes stehen dann typischerweise (agiles) Projektmanagement [PM] und Architekturmanagement [EAM] auf dem Programm. Eine umfassendere IT- und Consulting-Ausbildung, die u.a. das ITSM berücksichtigen würde, wird hingegen unterlassen.

Man konzentriert sich auf das Projektgeschäft und das dabei vorgesehene Projekt-Produkt. Faktisch sind aber gerade diejenigen Unternehmen am SW-Entwicklungs-Markt am erfolgreichsten, die die Kunst der Erstellung qualitativ hochwertiger Software mit einer längerfristigen Beratung der Kunden verbinden und kooperativ auf das strategische IT-Service- und Produkt-Management einwirken. Zur Begründung seien folgende Punkte angeführt:

  • Kunden-Orientierung ist nicht umsonst ein essentielle Komponente der ISO 9000 in einem prozessorientierten Ansatz von Qualität. „Kundenorientierung“ erfasst dabei natürlich auch die systematische Betrachtung von Services und Produkten im Business-Kontext des Kunden:
    In welcher Form dienen die Services und zugehörige Produkte den Geschäftsinteressen des Kunden? Wie konkurrenzfähig stellen sich dabei IT-Services und IT-Produkte (u.a. SW) auf mittlere und lange Sicht im Verhältnis zu Mitbewerbern und der technischen Entwicklung dar?
  • Die Kooperation mit dem Kunden und eine laufende wie längerfristige Beratung im Sinne einer Produktverbesserung dienen nicht nur dem Kunden sondern auch der eigenen Geschäftsentwicklung des SW-Unternehmen. Die gemeinsame Beobachtung des Marktes, der Konkurrenz und auch des Gesetzgebers hilft Fehlentwicklung bei der Erstellung und Pflege von Individual-SW beim Kunden zu vermeiden und rechtzeitig Neu- oder Weiterentwicklungen einzuleiten. Kluges, vorausschauendes Consulting von SW-Entwicklungsunternehmen bzgl. mehrwert-steigernder Modifikationen der SW erzeugt eine dauerhafte Kundenbindung.

Das Projektgeschäft mit SW bindet sich langfristig immer in ein IT-Service-Management und zugehöriges Produktmanagements des Kunden ein – auch wenn mancher Kunde diese Begriffe selbst so gar nicht verwenden würde. Das Life-Cycle-Management von SW-Produkten – und im Besonderen von Individual-SW – sollte strategisch im Rahmen eines umfassenderen Service-Lifecycle-Managements betrachtet werden; das ist dann die Domäne von ITSM-Prozessen einer ISO/IEC 20000 oder von ITIL V3/V4.

SW-Entwicklungs-Unternehmen scheuen sich, diese Ebene zu betreten; verkannt wird dabei, dass modernes ITSM nicht nur den operativen Betrieb und zugehörige Prozesse wie Incident- und Problem-Management behandelt. Gerade ITIL V3/V4 betrachten die dynamische und kontrollierte Fortentwicklung von IT-Services und zugehöriger „Produkte“ als eigentliches Ziel des zyklisch anzuwendenden Prozess-Kanons. Da das IT-Projektmanagement im Rahmen von ITIL und der ISO/IEC 20000 nicht betrachtet wird, werden ITSM und Projektmanagement oft (und fälschlich) als getrennte Welten aufgefasst.

Die strategische Spielwiese einer langfristigen Betreuung von SW-Produkten sieht jedoch etwa wie folgt aus:

Die linke vertikale Achse stellt die Dauer der Service- und Produktbetreuung beim Kunden dar. Die horizontale untere Achse dagegen den Grad der Agilität, mit der neue oder laufende Änderungsanforderungen bearbeitet werden können. Komplexe Systeme erfordern heute eine Pflege über mehrere Jahre hinweg. Die Betreuung von Änderungen muss dabei wegen der hohen Komplexität und Gewährleistung einer hohen Qualität über den ganzen Entwicklungs- und Änderungsprozess hinweg mehr oder weniger agil erfolgen.

Man sollte sich bewußt machen, dass eines der Motive von agilen Vorgehensmodellen die Aufrechterhaltung von Qualität trotz und während der Konfrontation mit neuen Erkenntnissen oder Einflussfaktoren ist. Adaption und Qualität sind Eckpfeiler etwa von SCRUM. Verfahren wie das klassische V-Modell werden in einem innovativen Umfeld von KI und Cloud zugunsten von inkrementell-iterativen Methoden systematisch aussterben, da sie nicht geeignet sind, Qualität und Unwägbarkeiten bei begrenzten Planungshorizonten zu gewährleisten. SW-seitig geht der Trend ohnehin zur SW im laufenden Beta-Stadium.

Die rote Trennlinie in der obigen Skizze markiert dabei die Trennlinie zwischen Life-Cycle-Management für IT-Services/-Produkte und IT/SW-Projekten. Zwischen beiden Ebenen kommt es aber zu laufenden Übergängen nach folgendem Muster:

  • Das strategische Produkt-Management erarbeitet innovative Produktvisionen, um am Markt bestehen zu können.
  • Das Produkt-Management, der laufende Support und ggf. Änderungen in der Gesetzgebung führen zu einer Vielzahl mehr oder weniger aufeinander abgestimmter „Requests for Change“ [RfC].
  • Das strategische Release-Management bündelt RFCs unter Berücksichtigung der Ressourcenlage und von Marktanforderungen zu neuen Releases. Das mittel- und langfristige Release-Management für Produkte und zugehörige SW kann dabei einem agilen Ansatz folgen (Agiles Release-Management).
  • Übersteigen Umfang, Ressourcenbedarf und Komplexitätsgrad der Change-Bündelung bestimmte Grenzen, werden Projekte mit besonderen Steuerungsverfahren zur Durchführung definiert. (Nicht jede Änderung erfordert aber ein Projekt zur Umsetzung; die Umsetzung einzelner überschaubarer RfCs kann auch in agilen DevOP-Verfahren erfolgen).
  • Hat ein Projekt ein neues Release erstellt, so wird das in entsprechende Servcices und den zugehörigen ITSM-Lifecycle eingespeist sowie dem operativen Betrieb übergeben.

SW-Projekte sind bei langfristigen Kundenbeziehungen zur Erstellung und Pflege von Kundenprodukten daher in den strategischen ITSM-Lifecycle „eingebettet“. Kluge Projektmanager haben das immer vor Augen und streben deshalb frühzeitig eine Kooperation mit Instanzen des ITSM an. Das gewählte Vorgehensmodell zur Durchführung eines SW-Projektes wird dabei selbst auch ein integriertes, agiles Release-Management verfolgen. Einige Artikel dieses Blogs werden auf diesen Übergang zwischen ITSM-bezogenem Release-Management und projektinternem agilen Release-Management näher eingehen.

Langfristige Kundenbetreuung im Rahmen eines ITSM-Lifecycle-Managements und die Einbettung von Projekten bringen im Idealfall eine Win-Win-Situation zwischen Kunde und SW-Unternehmen mit sich. Das hat u.a. auch der öffentliche Dienst auf Bundesebene erkannt – es finden dort relativ häufig Vergabeverfahren zu langfristigen Kooperationsverträgen für IT-Systeme statt.

Ein Wort noch zu SCRUM. SCRUM ist im Kern kein Prozessmodell für Projektmanagement – obwohl es in SW-Unternehmen typischerweise dafür eingesetzt wird. Im Kern ist SCRUM ein Framework mit (time-boxed) Prozessen, Verfahren und Rollen zur kontrollierten Erzeugung und Pflege von komplexen Produkten in höchster Qualität:

Scrum (n): A framework within which people can address complex adaptive problems, while
productively and creatively delivering products of the highest possible value.

Dem sind keine zeitlichen Grenzen gesetzt; der Product Backlog kann über beliebig lange Zeit gepflegt und (zu geeigneten Zeitpunkten) einer Umsetzung in Sprints zugeführt werden. Dies unterscheidet m.E. SCRUM und auch Kanban von anderen konventionelleren PM-Modellen: Konventionelle Projekte sollten auch bei Einsatz eines Stage-Modells wie in „Prince 2“ ein definiertes Ende haben. Gerade erfahrene Manager vertreten dabei den Grundsatz, dass alles, was sich nicht in zwei Jahren umsetzen lässt, den Rahmen eines erfolgreich durchführbaren Projektes sprengt – und daher anderer Steuerungsverfahren bedarf (Programm-Management oder eben ITSM).

Man beachte den zudem den extremen Qualitätsanspruch im SCRUM-Framework; er gipfelt in der Anforderung, dass das Ergebnis eines jeden Sprints release-fähig sein muss. Wir werden diesen Aspekt in einigen Beiträgen dieses Blogs genauer unter die Lupe nehmen. Dabei werden wir auch untersuchen, wie sich ein agiles Release-Management innerhalb der SCRUM-Systematik umsetzen lässt.

Schreibe einen Kommentar

Dieser Blog verwendet Cookies. Bei weiterer Nutzung gehen wir von Ihrem Einverständnis aus. Optionen/Informationen

Die Cookie-Einstellungen auf dieser Website sind auf "Cookies zulassen" eingestellt, um das beste Surferlebnis zu ermöglichen. Wenn du diese Website ohne Änderung der Cookie-Einstellungen verwendest oder auf "Akzeptieren" klickst, erklärst du sich damit einverstanden.

Schließen