Die Anschaffung von neuen Softwarelösungen ist häufig ein komplexer Vorgang. Der Bedarf erscheint nur auf den ersten Blick klar und eindeutig. Kosten und Nutzen müssen bewertet werden – auch wenn nicht alle Aspekte tatsächlich bewertbar sind. Die Budgetfrage muss geklärt werden. Und noch wichtiger: die betroffenen Mitarbeiter wollen gehört und ihre Anforderungen ebenfalls berücksichtigt werden!
Die meisten von uns haben bereits Einführungsprojekte erlebt, die ihre Ziele, gelinde gesagt, nicht erreicht haben. Und bei Individuallösungen ist das gefühlte Risiko im Vergleich zu Standardlösungen sogar noch größer. Herausforderungen bleiben aber auch nach erfolgreicher Inbetriebnahme bestehen, die Lösung muss schließlich über sehr viele Jahre ihren Zweck erfüllen, obwohl sich wesentliche Randbedingungen kontinuierlich verändern.
All diesen Herausforderungen können Sie besser begegnen, wenn Sie sich die Phasen im Lebenszyklus mit den jeweiligen spezifischen Eigenschaften und Aufgaben klar machen.
Eigentlich noch keine Phase – wie der Bedarf entsteht
Ein Bedarf kann viele Ursachen haben. Neue Aufgaben müssen bewältigt werden. Das Unternehmen muss aufgrund externer Verpflichtungen neue Prozesse auf- und umsetzen. Die bisherige Lösung, vielleicht sogar aus eigener Herstellung, erfüllt die gestiegenen Anforderungen nicht mehr.
In jedem Fall entsteht der Bedarf aus fachlichen Gründen, wobei fachlich sowohl die tatsächliche fachliche Domäne (der Markt) als auch spezifische Arbeitsbereiche, wie z.B. die eigene IT, umfassen kann.
Konkret hat also ein Fachexperte die Idee zu einer neuen Lösung, die die Arbeit erleichtern oder erst möglich machen könnte. Er sucht also Mitstreiter, die ihn unterstützen und helfen, Klarheit über den Bedarf zu gewinnen. Zu einem geeigneten Zeitpunkt wird dann auch das Thema Investition diskutiert – schließlich erwartet spätestens der eigene Chef eine Rechtfertigung zu Kosten und Nutzen.
Die Spezifikation regelt alles. Oder doch nicht?
Eigentlich ist alles klar. Im Kopf ist die neue Lösung unseres Fachexperten bereits im Betrieb. Alle wichtigen Eigenschaften sind eindeutig benannt und hervorragend umgesetzt. Wäre da nur nicht die Aufgabe, diese eigene Vision zu Papier bringen zu müssen. Und zwar so, dass der Hersteller idealerweise ohne Rückfragen (kosten Zeit und Nerven) und ohne Abweichungen zu den eigenen Erwartungen (verursachen Frustration) seine Aufgabe bewältigen kann – und zwar in der vorgegebenen Zeit und einer sehr guten Qualität.
Der Blick eines Kollegen auf den Entwurf der Spezifikation offenbart, dass ganze Anforderungsbereiche ausgespart wurden und bei zu vielen Details gibt es Diskussionsbedarf – andere Anforderungen könnten doch noch ein besseres Ergebnis versprechen. Zu viele Anforderungen sollen es aber auch nicht werden, denn sonst wird die Lösung zu teuer. Und genügt es, ganze Themenbereiche mit „marktüblichen Eigenschaften“ abzuhandeln?
Dieses Beispiel zeigt, dass eine Spezifikation niemals „vollständig“, „richtig“ oder „eindeutig“ sein kann. Vielmehr geht es darum, den richtigen Kompromiss in Tiefe und Breite zu finden. Schließlich wird auch der Hersteller seinen Beitrag leisten und seine eigenen Erfahrungen zum Wohle des Kunden einsetzen wollen. Leider werden Fachexperten bei der Erstellung von Spezifikationen häufig alleine gelassen. Die mangelnde Erfahrung führt dann zu unvollständigen Ergebnissen, die schnell fehlerhaft interpretiert werden können. Zusammen mit dem Wettbewerb im Angebotsprozess der möglichen Hersteller sind damit Konflikte vorprogrammiert.
Die individuelle Softwarelösung entsteht
Der Auftrag ist erteilt, die Umsetzung kann beginnen. Je nach Hersteller und eigenen Wünschen findet diese Produktion nach ganz unterschiedlichen Vorgehensmodellen statt.
Die meisten Hersteller favorisieren mittlerweile agile Vorgehensmodelle, bei denen der Kunde idealerweise kontinuierlich mit festen Kundenvertretern in die Produktion einbezogen werden kann. So können Unklarheiten und notwendige Entscheidungen „zum Wohle des Kunden“ getroffen werden und Konflikte und Probleme früher gelöst werden.
Allerdings tritt häufig die Situation auf, dass unser Fachexperte nach der intensiven Phase der Spezifikationserstellung eigentlich wieder die liegengebliebenen Aufgaben des Tagesgeschäfts bearbeiten sollte. Es war nie oder zumindest nicht in ausreichendem Maße eingeplant, die Produktion auf Herstellerseite intensiv zu begleiten. Außerdem sollte unser Fachexperte auch noch die seltene Fähigkeit besitzen, die Bedürfnisse und Herausforderungen bei der Erstellung von Softwarelösungen einschätzen zu können – denn nur so kann er angemessene Entscheidungen treffen und damit den Projekterfolg stark positiv beeinflussen.
Es gibt aber auch immer noch die andere Art Hersteller. Hier geschieht die Produktion im Verborgenen, um dann „plötzlich“ ein Ergebnis zur Abnahme bereitzustellen. Die Erfahrungen in vielen Projekten dieser Art sollten mittlerweile eigentlich jedem klar gemacht haben, dass die Vorteile dieses Vorgehens von den unkalkulierbaren Risiken mehr als wettgemacht werden!
Und dann gibt es noch den Faktor Zeit. Tatsächlich ist es nicht wahr, dass ziemlich alle Projekte verspätet abgeschlossen werden – die Wahrnehmung der Verzögerungen ist einfach deutlich intensiver als die Wahrnehmung der erfolgreichen, d.h. wie geplanten Projekte. Pünktliche Projekte haben aber typischerweise eine Gemeinsamkeit. Diese besteht darin, dass sowohl Kunde als auch Hersteller mindestens einen Projektbeteiligten haben, dem der Zeitfaktor wichtig ist. Das Fazit muss also lauten, von Anfang bis Ende diesen Punkt aktiv zu bearbeiten…
Go–Live
Man könnte den Go-Live als Höhepunkt im Lebenszyklus bezeichnen. Nach langer und aufwändiger Vorbereitung kann die neue Lösung zum ersten Mal ihren Geschäftszweck erfüllen. Dieser Meilenstein erfordert allerdings häufig Kompromisse, denn selten ist eine Lösung zu diesem Zeitpunkt vollständig ausgereift. Wichtig ist es, hier zwischen „gesunden“ und „ungesunden“ Kompromissen zu unterscheiden.
„Gesunde“ Kompromisse können dabei zum Beispiel fehlende oder fehlerhafte fachliche Funktionen sein, die anderweitig kompensiert werden können. „Ungesunde“ Kompromisse“ betreffen prinzipiell alle grundlegenden Betriebsthemen wie Stabilität, technische Konfiguration oder auch Monitoring. Solch ein Kompromiss verursacht schnell wochen- oder monatelange Aufwände auf beiden Seiten und verschlechtert die subjektive Wahrnehmung der Leistungsfähigkeit enorm. Aus diesem Grund helfen klare Akzeptanzkriterien für den Go-Live, „ungesunde“ Kompromisse gar nicht erst einzugehen.
In Betrieb – Zeit zum Verschnaufen?
Der Zeitraum des Betriebs erstreckt sich hoffentlich über viele Jahre. Damit ist klar, dass auch in diesem Zeitraum eine kontinuierliche Pflege und Weiterentwicklung stattfinden sollte. Der Einfachheit halber teilen wir die Betriebszeit in drei Phasen auf:
In der Startphase sinkt oft der Fokus des eigenen Managements auf die Lösung. Ist der Go-Live erst einmal absolviert, scheint die Lösung in der virtuellen Schublade „alles fertig“ zu verschwinden, weitere Aufwände oder gar Kosten zur Erreichung eines optimalen Betriebs werden abgeblockt. Dabei würde gerade jetzt die Korrektur von suboptimalen Eigenschaften den größten Nutzen erbringen, da diese Korrekturen viele Jahre lang wirken. Es gibt aber auch rühmliche Ausnahmen, die ein Budget für die Startphase explizit in der Auftragsvergabe als Abrufkontingent verankert haben.
Nach der Startphase folgt dann tatsächlich eine ruhige Phase, in der die Lösung ihren Zweck erfüllt. Zugrundeliegende Geschäftsprozesse werden angemessen abgedeckt, die Nutzer der Lösung haben sich vollständig mit der Lösung vertraut gemacht und sind sich häufig auch der Gründe für die tatsächliche Ausgestaltung der Lösung bewusst – hier entsteht eine positive Grundhaltung.
Doch mit zunehmendem Alter der Lösung müssen mehr und mehr Zugeständnisse gemacht werden. Die Technologie und darauf aufbauende (Bedien-) Konzepte altern und die Geschäftsprozesse ändern sich. Wenn jetzt keine Pflegemaßnahmen eingeleitet werden, dann fühlt sich die Lösung bald „alt“ an und die Zufriedenheit der Nutzer sinkt rapide.
Ende und Neuanfang
In der letzten Phase findet keine operative Nutzung der Lösung mehr statt. Trotzdem bleibt die Lösung häufig noch in Betrieb, da Funktionen, Daten oder auch Darstellungen der Lösung immer noch benötigt werden bzw. von den Nutzern als notwendig empfunden werden. Dass dieses Szenario betriebswirtschaftlich äußerst ungünstig ist, versteht sich von selbst. Deshalb empfiehlt es sich, die Ausmusterung einer Lösung als eigenständiges Projekt aufzusetzen und die Abschaltung mit Archivierung der Lösung zügig und mit klaren Zielen durchzuführen.
Spezifikation
- Ein gemeinsames Verständnis der Ziele bei der Spezifikationserstellung sind entscheidend für die Qualität der Spezifikation
- Eine gute Spezifikation beinhaltet immer mehrere Perspektiven auf die Problemstellung
Betrieb
- In der Startphase sollten Verbesserungen explizit eingeplant sein
- Eine passende Pflegestrategie über die mehrjährige Betriebsphase erhöht den Nutzen
Produktion
- Kunde und Lieferant sollten die Produktion aktiv gestalten wollen
- Die Produktion sollte niemals „laufen gelassen“ werden
Bedarf
- Änderungen im Arbeitsumfeld lassen den Bedarf entstehen
- Eine erste Kosten-Nutzen-Analyse zeigt, ob eine IT-Lösung den Bedarf abdeckt
Go-Live
- „Ungesunde“ Kompromisse sollten auf jeden Fall vermieden werden
- Klare Akzeptanzkriterien sichern die notwendige Reife
Ausmusterung
- Wie die Einführung sollte auch die Ausmusterung aktiv als Projekt gestaltet sein und nicht einfach nur „passieren“
Und jetzt?
Die Kenntnis der Phasen im Lebenszyklus macht uns bewusst, dass die Aufgaben und Herausforderungen in der Betreuung unserer Softwarelösung vielfältig und teilweise recht aufwändig sein können. In den weiteren Artikeln dieser Blogreihe sollen deshalb spezifische Aspekte, unter anderem zu konkreten Maßnahmen der Softwarepflege, aber auch zur Einbindung der von der Lösung „betroffenen“ Kollegen, beleuchtet werden.
0 Kommentare