Sind Eure Arbeitsabläufe auch weitestgehend durch IT-Systeme bestimmt? Das ist gut so! Nein? Ihr würdet viele Dinge eigentlich anders machen wollen? Wie kann das denn sein? Diese Systeme wurden doch extra für Euch entwickelt, um Eure fachlichen Prozesse und Aufgaben bestmöglich zu unterstützen. Wart Ihr denn nicht an der fachlichen, inhaltlichen Ausgestaltung beteiligt, hat die IT-Abteilung Eure Anforderungen nicht verstanden oder sich (ggf. unter dem Deckmantel der technischen Machbarkeit) vielleicht sogar darüber hinweggesetzt?
Das Dilemma
Letzteres ist gar kein so seltenes Szenario. ITler sind oft Künstler mit dem Anspruch, tolle technische Lösungen umzusetzen. Dabei bleibt leider manchmal das Verständnis für die Fachanwender auf der Strecke. Eigentlich sollte es zum Selbstverständnis der IT gehören, sich als Dienstleister für die Fachbereiche zu begreifen. Für Künstler natürlich keine ganz einfache Sache. Die Fachabteilungen stellen immer nur abstruse, unschlüssige Anforderungen und haben gar keine Ahnung, was eigentlich technisch dahinter steckt. Das muss die IT ja irgendwie in geregelte Bahnen bringen. Umgekehrt stellt sich die IT für die Fachabteilungen oft als Spielverderber dar: ständig stellen sie die fachlichen Anforderungen in Frage und erklären, warum dieses und jenes ja so überhaupt gar nicht geht. Die (technischen) Argumente, die sie dabei anführen, sind für die Fachbereiche oft wenig verständlich, wenn nicht sogar uninteressant, denn schließlich wollen sie ja nur ihre Fachlichkeit umgesetzt wissen. Und zu guter Letzt setzt die IT dann doch das um, was sie für richtig hält.
Schon haben wir das Dilemma! Fachbereiche und IT werden zu Gegenspielern, von Business-IT-Alignment keine Spur, weder auf inhaltlich/technischer noch auf sozialer Ebene. Das Wissen über die Fachprozesse verlagert sich immer mehr in die IT und die eigentlichen Fachexperten müssen damit zurechtkommen. Ich übertreibe? Ja, mag sein. Aber vielleicht steckt ja doch ein Fünkchen Wahrheit in diesem Szenario. Und wie kommen wir dann aus dieser Sackgasse wieder raus?
Interdisziplinäre Zusammenarbeit – von Anfang an!
Ein Schlüssel liegt zunächst sicherlich in der grundsätzlichen Art, wie IT-Projekte abgewickelt werden. Werden nach Wasserfall-Methodik zuerst umfangreiche Fachkonzepte entwickelt und bis ins Detail ausspezifiziert, die dann der IT zur Umsetzung vorgelegt (oder um es anders zu sagen: über den Zaun geworfen) werden, ist o.g. Szenario vorprogrammiert. Besser ist es, nach agiler Art gleich von Anfang an auf eine interdisziplinäre Zusammenarbeit von Fachbereichen und IT zu setzen und gemeinsam iterativ-inkrementell an der Ausarbeitung der Anforderungen und der dazugehörigen Lösungen zu arbeiten. Dadurch wird das gegenseitige Verständnis gefördert und die Gefahr des „Not-Invented-Here“-Syndroms reduziert.
Eine gemeinsame Sprache
Wenn Fachbereiche und IT an einem Tisch sitzen, müssen sie aber natürlich auch lernen, eine gemeinsame Sprache zu sprechen, um Missverständnisse und Fehlinterpretationen bei der Diskussion um Anforderungen und der (gemeinsamen!) Spezifikation der umzusetzenden Lösung zu vermeiden. Eine Dokumentation als reiner Prosa-Text ist dabei meist wenig geeignet. Besser, man verständigt sich von vornherein auf eine gewisse Menge von wohldefinierten Notationen und Formaten, die für alle Beteiligten schnell und leicht verständlich, dabei aber auch möglichst konkret sind und wenig Spielraum für (ggf. falsche) Interpretationen bieten. Besonders geeignet sind dabei graphische Visualisierungen. Ihr ahnt es schon, worauf ich hinaus will: BPMN ist hervorragend dazu geeignet, gemeinsam Fachprozesse zu erarbeiten, die die IT dann direkt so technisch implementieren kann. Aber nicht nur Prozesse lassen sich mit BPMN beschreiben. Man kann gut und gerne auch die Fachlogik, die in Form von Services bereitgestellt wird, damit spezifizieren. In Kombination mit DMN für Geschäftsregeln, einem gemeinsam definierten Template für Usecase-Beschreibungen und ggf. UML-Klassendiagrammen für die Facharchitektur der Geschäftsobjekte hat man ein gutes Vokabular beisammen.
Anforderungen, nicht Lösungsvorgaben!
Generell empfiehlt es sich auch, zunächst wirklich nur auf der Ebene von Anforderungen zu diskutieren. Eine „Anforderung“, die z.B. formuliert ist als „… wenn ich unten rechts auf den Button ‚Daten erfassen‘ klicke, öffnet sich ein Fenster mit einem Formular. Nach dem ‚Speichern‘ wird eine E-Mail an die Abteilung XYZ geschickt…“ ist eigentlich schon keine Anforderung mehr, sondern bereits eine relativ konkrete Lösungsvorgabe. Die darunter liegende Anforderung wäre vielleicht viel eher: „Wenn neue Daten eingegangen sind, soll Abteilung XYZ darüber informiert werden“. Aber warum soll eine solche abstraktere Formulierung besser sein als die erstgennante konkretere Beschreibung? Ganz einfach: unterhält man sich zunächst über die wirkliche Anforderung, lässt man sich einen größeren Lösungsraum offen. Die Beteiligten können gemeinsam überlegen, was die beste Lösung für die Anforderung ist und unterschiedliche Ideen einbringen. Vielleicht ist die beste Lösung gar kein Eingabeformular und/oder auch keine E-Mail. Vielleicht lässt sich hier z.B. etwas automatisieren, vielleicht benötigt man gar keine manuelle Erfassung, vielleicht muss es gar keine isolierte E-Mail sein, sondern die Informationen können direkt an andere am Prozess beteiligte Systeme weitergegeben werden. Macht man sich immer wieder bewußt, was die eigentliche Anforderung ist und geht gemeinsam dazu ggf. auch einen Schritt zurück, fördert das wiederum das gemeinsame Verständnis und wirkt wiederum dem „Not-Invented-Here“-Syndrom entgegen. In jedem Fall können die Qualität des zu entwickelnden Systems und dessen Anwender davon nur profitieren.
Die richtigen Verantwortlichen
Ein weiteres Muster, das uns in der Praxis immer wieder über den Weg läuft, ist das Konzept des „Applikationsverantwortlichen“. Dieser kommt in der Regel aus der IT und wurde meist auch erst nach der Einführung eines neuen Systems benannt. Wie gut sich diese Person dann tatsächlich mit den zugrundeliegenden Geschäftsprozessen und der Fachlichkeit auskennt, ist meist fraglich. Dennoch ist er oder sie dann der erste Ansprechpartner, wenn es um Fehlerbehebung, Wartung und Weiterentwicklung geht. Hmmm… das kann nicht wirklich gut sein, oder?
Die Aufgabe lautet also: Findet die richtigen Verantwortlichen – und zwar von Anfang an! Diese sollten in der Regel aus den Fachbereichen kommen, denn sie sind die Fachexperten. Eigentlich muss man nicht wirklich lange nach den entsprechenden Personen suchen. Schließlich muss es ja Leute geben, die ein ureigenstes Interesse daran haben, dass ihre Fachprozesse durch IT unterstützt werden. Mitarbeiter, die sich dafür verantwortlich zeigen, dass ihre Arbeit gut, effektiv und effizient ausgeführt wird. Dies sind die Personen, die als Product-, Process- und Service-Owner am besten geeignet sind. Sie sollten als inhaltlich Verantwortliche ein IT-System über dessen gesamten Lebenzyklus begleiten – von der Idee über die Projektphase bis in den produktiven Betrieb und darüber hinaus.
Fällt es schwer, solche Personen zu finden, sollte man sich ggf. noch einmal Gedanken über die Sinnhaftigkeit oder die Erfolgsaussichten des aktuellen Projektvorhabens machen. Gelingt es jedoch, diese Rollen mit motivierten Fachexperten zu besetzen und beherzt man durchgängig die oben genannten Punkte, so ist die Gefahr gebannt, dass man sich plötzlich in einer Volksrepublik IT wiederfindet, in der allseitige Unzufriedenheit herrscht und IT (zumindest in Teilen) zum Selbstzweck geworden ist.
