Zitat – Digitale Transformation, wer transformiert?

Standard

„Wir arbeiten in Strukturen von gestern mit Methoden von heute an Problemen von morgen vorwiegend mit Menschen, die die Strukturen von gestern gebaut haben und das Morgen innerhalb der Organisation nicht mehr erleben werden.“

Knut Bleicher, Ehrenpräsident der Gesellschaft für integriertes Management

Advertisements

Geschäftsprozesse versus Softwarequalität – a bisserl a Satire

Standard
Aber nur a bisserl a Satire.
Vorneweg, es gibt Software und Software. Die eine ist weniger von Geschäftsprozessen betroffen, das Paket ist so, wie es ist. Man kann es in bestimmtem Umfang customizen (anpassen, konfigurieren), zahlt dafür Lizenzen, hat dafür eine feste Funktionalität. Der Stakeholder (Prozess / IT) verbiegt sich, um die Geschäftsprozesse halbwegs darin abzubilden und wundert sich, dass die Anwender murren. Über diese Art Software möchte ich hier nicht sprechen.
Dann gibt es Software, die kundenspezifisch erstellt, nach den Anforderungen des Kunden maßgeschneidert wird (aber natürlich wenig kosten soll). Also unser Metier bei Z&P. Hier ist die Spielwiese, hier kann sich der prozessorientierte Anwender erst einmal wiederfinden und die Jahre vorher in zig Besprechungen ermittelten Anforderungen an die Software stellen (Phase der enthusiastischen Begeisterung).
Der Stakeholder kann sich austoben, seine Wünsche äußern, neue Prozessvarianten erfinden. Am besten während der Realisierung ständig Verfeinerungen einbringen oder auch mal alles umwerfen oder erkennen, das man in der jahrelangen Vorarbeit irgendwie nicht wirklich was entscheidendes formuliert hat (einsetzende plötzliche Verwirrung). Das ist die Phase, in der der Product Owner (Entwicklungsseite) nicht mehr versteht was der Stakeholder (Auftraggeber) will (Phase der totalen Verwirrung).
Denn, der eine Anwenderkreis arbeitet so und möchte gerne diese Unterstützung und hat eine andere Sicht auf die Dinge wie der andere Anwenderkreis. Und bitteschön, da wir heutzutage nicht mehr kommunizieren können (In der Tat ist die telefonische Erreichbarkeit im Zeitalter von Handys schlechter als früher, da man in Besprechungen nun mal nicht auf Anrufe reagiert), dann bitte automatische Benachrichtigungen. => „Ich habe nichts bekommen, deshalb habe ich nichts gemacht.“ Hmm. Also wieder ein Protokollsystem für das Verschicken der Mails eingebaut. Aha, man kann’s nun beweisen. Wirklich? Wichtig, die Anwender müssen gesteuert werden, damit der Prozess funktioniert (manche verlernen dabei das Denken).
Wichtig in dieser Phase: die ständige Anpassung des Terminplans, die ja am nächsten Tag wegen neuer Anforderungen nicht mehr gilt. An irgendwas muss man ja seine Key Performance Indicators festmachen.
Tja, schon ist es nichts mehr mit dem Motto: „Einfacher ist besser“.
Schön ausgedachte Algorithmen werden nun geändert. Neue kommen hinzu. Die Zeit wird knapper, auch weil man eigentlich fertig werden müsste, aber der Stakeholder nicht mit seinen Vorstellungen und Entscheidungen aus den Puschen kommt und das Budget in der Regel schon durch die Besprechungen aufgebraucht wurde. Also entscheidet die Entwicklung sich für die Notbremse, Vereinfachungen, das Machbare (Phase der totalen Ernüchterung).
Unbestreitbar, nun ist es vorbei mit einer guten Softwarequalität, -strukturierung, – dokumentation,…
Termindruck. Da testet man halt was geht und macht keinen Plan mehr. Hatte man am Anfang zwar mal, ist aber voll agil über den Haufen geworfen worden.
Keyuser Test. Wenn da mal was getestet würde. Keiner hat Lust, keiner hat Zeit. Ausnahmen bestätigen die Regel. Alles ok, wir gehen produktiv.
2 Jahre später oder noch später. Unglaubliche Fehler enthüllen sich. Anwender melden komische Verhaltensweisen. Inzwischen wurden schon viele AddOns entwickelt, sogenannte Rucksäckchen. Neue Abläufe, basierend auf den Dingen der Vergangenheit, realisiert.
Und wer ist schuld? Na, die Software!