Sollte es zumindest sein. Leider erlebt man viel zu häufig das es nicht beachtet wird.
Da wird eine Software schon damit beworben das sie total intuitiv zu bedienen ist und ganz einfach und schnell die Effizienz steigert, aber die Botschaft ist Werbung und die Zielgruppe sind die Entscheider auf Käuferseite. Die Menschen die so eine Software später benutzen sollen sitzen in der Regel gar nicht im Raum. Natürlich trifft das auch auf andere Produktkategorien als Software zu, aber bei der Software haben wir die Chance sie von Beginn an zielgerichtet zu gestalten. Wir nutzen sie nur nicht.
Das Problem
In jeder Organisation gibt es feste Abläufe zu den Dingen die nun mal zu erledigen sind. Eine mehr oder weniger große Anzahl an Menschen hat sich an die Abläufe gewöhnt und arbeitet danach. Es etabliert sich eine Kultur und ein Sprachgebrauch rund um diese Abläufe. Wohl jeder kennt die Formulierung „Das liegt in unserem SAP/Outlook/Jitsi, Jira, …“ um nur ein par bekanntere Beispiele zu nennen. Schon allein die Formulierung „unserem“ spricht an der Stelle Bände. Fast als wäre die Software teil der Unternehmensfamilie.
Interessant ist das sich drei Konstanten immer wieder beobachten lassen:
Egal wie gut oder schlecht die Abläufe organisatorisch vorgegeben wurden, es spielen sich immer eigene Mechanismen ein. Im völligen Chaos finden die Mitarbeitenden Wege die dann zum Standard etabliert werden. In der komplett regulierten Umgebung finden sie Wege von den Regularien abzuweichen und auch diese werden irgendwann zum Standard. Gruppen neigen dazu Rollen abzubilden und eine eigene Organisation zu schaffen.
Egal wie gut oder schlecht die Abläufe insgesamt funktionieren, es wird immer kritisiert. Keine Organisation funktioniert so gut das sie sämtlich Grenzfälle an allen beteiligten Stellen perfekt abbildet. Es wird Fälle geben die an der einen oder anderen Stelle nicht ganz passen und zu Reibung führen. Was aus der einen Perspektive gut gelöst wurde erzeugt auf der anderen Seite Missfallen. Wie etwas gut oder schlecht geregelt wird ist eine Frage der Perspektive.
Egal wie gut etwas neues ist, alles was die gewohnte Stabilität gefährdet wird abgelehnt. Da kann eine bestehende Vorgehensweise noch so kompliziert sein und noch so kritisiert werden. Wenn eine neue Lösung um die Ecke kommt stellt man fest das die alten Wege kompliziert aber immerhin bekannt waren. Die menschliche Umstellung dauert oft länger als die technische und es wird immer mal wieder von dem „guten alten …“ gesprochen. Es ist beinahe so als würde man mit der alten Software ein Mitglied der Unternehmensfamilie abschaffen.
Was machen wir daraus?
Egal ob es um die Einführung einer fertigen Standard-Software oder um die Entwicklung einer neuen Individual-Software geht, es macht immer Sinn möglichst früh in der Kette anzufangen. Dort wo mit dem System gearbeitet werden soll. Um zu ermitteln wie man effektiven Mehrwert schaffen kann muss man verstehen wie eigentlich gearbeitet wird. Was tun die Menschen? Was wollen sie erreichen? Wie tun die das bisher? Welchem Zweck folgt eigentlich die gesamte Organisation und/oder dieser Teil der Organisation? Wie können wir das unterstützen? Was glauben die einzelnen Beteiligten wo der Schuh drückt?
Kurz gesagt wir müssen den IST-Stand erheben. Niemand kann einen guten Weg finden ohne den Startpunkt zu kennen. Parallel mit der Erhebung werden sich automatisch die erste Verbesserungen ergeben. Viele werden eine Idee dazu haben was besser laufen könnte oder was derzeit echt schlecht läuft. Beides ist gut, denn wir wollen die schlechten Dinge nicht wiederholen und die guten Dinge möglichst berücksichtigen.
Dabei sollte die Erhebung sich nicht auf alte IT-Systeme beschränken sondern die Arbeitsweise generell betrachten. Ich habe in den oben angeführten Fragen nicht einmal das Wort Software stehen. Es geht eben darum den eigentlichen Zweck der Arbeit zu ermitteln und danach zu prüfen wie er mit Software unterstützt werden kann. Was wir auf keinen Fall wollen ist die Erhebung der bisherigen Prozesse nur um diese dann blind zu digitalisieren. Wie man so schön sagt: schlechte Prozesse zu digitalisieren führt zu schlechten digitalen Prozessen. Es kann auch sein das wir den Bedarf einer Überarbeitung der Arbeitsweise erkennen, und erstmal keine Software brauchen. Dann ist das so. Das ist besser als die Alternative.
Damit sind wir in der Analyse der Optionen. Was können wir tun, wo können wir helfen, was davon macht wirklich Sinn und was lassen wir lieber. Wird ein komplett neues System entwickelt oder eine Standardsoftware angepasst? Gibt es eine große Ablösung oder ersetzen wir Teile nacheinander? Wie können wir das alles möglichst schmerzfrei für die Menschen machen? Stecken wir lieber mehr Arbeit in ein längeres Projekt und können es damit für die Betroffenen angenehmer machen? An dieser Stelle muss man oft die brauchbare Mitte finden. Nicht alle Wünsche lassen sich umsetzen, schon gar nicht gleichzeitig. Genau so wie in der Organisation die Frage nach einer guten Regelung auch eine Frage der Perspektive ist werden wir auch in der Software nicht immer alle Sichtweisen abdecken können.
Während des gesamten Prozesses sollte man nach wie vor versuchen die Betroffenen mitzunehmen. Eine offene Kommunikation über Planungen und Entscheidungen ist hilfreich, wo immer es Sinn macht. Nicht jedes hin- und her oder für- und wieder wollen die Menschen wissen, aber was auf sie zukommt wollen sie bestimmt wissen. Dabei wird sich vermutlich auch die ein oder andere Stelle ergeben an der es Sinn macht anzufangen. Dank agiler Methoden kann man schon früh ein paar interessierte Personen einsammeln und an den ersten Prototypen beteiligen. Die internen early adopter sozusagen. Sobald erste Menschen begeistert sind ergibt sich automatisch eine gewisse Neugier, man will ja nichts verpassen. Wenn die Neugier der early majority einsetzt hat man eigentlich schon gewonnen. Und zwar gewonnen im Sinne eine Gewinns, nicht eines Sieges.
Fazit
Wenn man früh in der Kette der Beteiligten beginnt und ein gutes Bild von dem IST-Stand bekommt dann kann man auch die Kultur der Organisation einfangen. Wenn man die Beteiligten in dem Prozess mitnimmt und die richtigen Personen dafür findet dann fließt auch die Kultur in die Software und die Ideen der neuen Software frühzeitig zurück in die Kultur. Je besser das gelingt desto geringer der Schmerz des Wandels. Deswegen ist IT ein Kulturprojekt.
Man kann aber auch einfach ein Stück Software einkaufen und in die Organisation werfen. Dann müssen die Menschen sich eben damit abfinden und neue Wege entwickeln wie man damit arbeitet. Dabei werden Arbeitsweisen geändert, Daten migriert, Prozesse angepasst, Schulungen gegeben. Es wird eine Zeit des Chaos geben und diese Phase wird Geld kosten. Viele der Kosten wird man nicht sehen, sie entstehen einfach durch den Reibungsverlust im Alltag.
Ein Kulturprojekt klingt auf den ersten Blick anstrengend. Auf den zweiten Blick wird man aber feststellen das es langfristig die bessere Idee ist. Natürlich ist es einfacher eine Software zu kaufen und natürlich wird sie die versprochene Effizienz steigern. Aber eben erst wenn sie richtig eingespielt ist, und die Daten migriert sind, und die Mitarbeiter geschult sind, und die Prozesse alle wieder eingespielt sind. Dann, ja dann wird sie Effizienz steigern. Und in der Zwischenzeit trauern alle der alten Software hinterher, obwohl die so viele Macken hatte, aber irgendwie hatte man sie ja doch lieb gewonnen, …
Am Ende geht es nicht um Software, sondern um eine gut funktionierende Organisation bestehend aus Menschen die man mit guten Hilfsmitteln in ihren Tätigkeiten unterstützen möchte. Deswegen ist es immer ein Kulturprojekt, so oder so, ob man das nun berücksichtigt oder nicht.