In Unternehmen spielt sich regelmäßig die gleiche Szene ab: Es wird gefragt: „Warum setzen wir nicht eine Standardplattform ein?“. Langjährige Mitarbeiter haben diese Frage schon des Öfteren gehört und winken sie mit einem müden Lächeln ab. Woher kommt dies und warum wird die Frage nach einer Standardplattform immer wieder gestellt? Bevor man sich mit diesen Fragen auseinandersetzt, sollte man den Kontext der Fragestellungen besser verstehen.
Ein Teil des Kontextes ergibt sich aus der Vergangenheit des Unternehmens, ein anderer aus den möglichen zukünftigen Bedrohungsszenarien, ein dritter aus den Ressourcen des Unternehmens und ein vierter aus dem Einsatz einer Plattform.
Status-Quo
Unter einem Anwendungssystem (AWS) versteht man ein soziotechnisches System, das die applikative Software und soziale Elemente enthält, die notwendig sind, das AWS einzusetzen und aufrecht zu erhalten. Folglich zählt zu einem AWS neben der eigentlichen Anwendung auch Software zur Wartung und Weiterentwicklung, darunterliegende Strukturen wie Datenbanken, Archive oder Monitore. Als soziale Elemente kommen Entwickler, Vorgehensmodelle, Governance, Know-how, Richtlinien etc. hinzu. Auf der Nutzerseite wird zu diesem System neben dem eigentlichen User auch der Geschäftsprozess, der Informations- und Datenhaushalt gezählt. Die eigentliche Anwendung hingegen ist die Software und die in ihr enthaltenen Daten. Das AWS ist in der Regel über Jahre hinweg in den jetzigen Zustand evolviert, d.h. die unterschiedlichen Bestandteile haben sich strukturell und begrifflich stark aufeinander abgestimmt. Die Abstimmung ist das Resultat diverser Weiterentwicklungszyklen. Hierbei werden immer mehr unternehmensspezifische Begrifflichkeiten, Prozess-, Kommunikations- und Entscheidungsstrukturen in das AWS eingebracht und zu einem großen Teil in Code „gegossen“. Es finden sich in der Struktur der Anwendungssoftware neben fachlichen Blöcken auch deutliche Spuren der sozialen Struktur des Entwicklungsteams. Die Isomorphie zwischen der Softwarearchitektur und den sozialen Strukturen des Unternehmens wird durch das Gesetz von Conway beschrieben. Diese Verbundenheit der sozialen Strukturen mit dem über Jahre entwickelten System führt zur Entstehung eines „Standards“, der so weit führen kann, dass für das AWS eine eigene Begriffswelt entsteht, die für Außenstehende nur schwer verständlich ist.
Die langjährige Anwesenheit des AWS führt dazu, dass seine Existenz nicht in Frage gestellt wird und Wissen über die internen Strukturen des sozioökonomischen Systems verloren geht. Das AWS ist für die Beteiligten nicht mehr objektiv beobachtbar, da sie selbst Teil des Systems sind. Hinzu kommt die Größe solcher Systeme, die es unmöglich macht, dass Einzelne sie vollständig verstehen können. Das Wissen über das System wird fragmentierter und es entstehen Kopfmonopole; auch in Fachbereichen! Auf Dauer stellt sich ein Gleichgewicht in dem AWS ein. Hier wird Veränderung durch Kopfmonopole kontrolliert und jede Veränderung, die das Gleichgewicht bedroht, zeigt exorbitante Kosten oder Risiken auf. Das AWS „wehrt“ sich auf allen Ebenen dagegen seine Struktur stark zu verändern. Parallel verbraucht es aber zum Erhalt des aktuellen Status Quo Ressourcen des Unternehmens, d.h. das AWS kostet, selbst wenn es nicht verändert wird. Ein Symptom dieses Gleichgewichts sind immense Aufwände, die notwendig werden, um geringe strukturelle Veränderungen vorzunehmen; der Grund liegt darin, dass das AWS sein Gleichgewicht verlassen muss, um ein neues zu erreichen und dieser Weg meist sehr kostspielig ist.
Äußere Kräfte
Hat das AWS ein stabiles Gleichgewicht erreicht, dann kann es sich nicht mehr – aus sich selbst heraus – strukturell verändern. Der Impuls zu einer Veränderung muss von außerhalb des AWS kommen. Typische äußere Kräfte, die einen solchen Impuls formen können, sind:
- Regulatorische Anforderungen,
- Marktveränderungen,
- größere Reorganisationen,
- Wegfall von Hard- und Software.
Hierbei ist das AWS nicht mehr in der Lage sich auf die Veränderung anzupassen ohne seine Identität, d.h. seine grundsätzlichen Merkmale, zu verlieren. Für das AWS ist ein Zielzustand durch inkrementelle Veränderungen nicht erreichbar, mit der Folge, dass eine revolutionäre Veränderung notwendig wird: Die Einführung eines neuen soziotechnischen Systems! Eine Migration zu einer Standardplattform ist ein möglicher Schritt zur Schaffung eines neuen soziotechnischen Systems. Jede Form von massiver Veränderung kann nur von außerhalb des bestehenden soziotechnischen Systems initiiert werden und wird, in der Regel, vom AWS boykottiert. Diese Zweiteilung von Personen – in- und außerhalb des AWS – erklärt die Anfangsszene. Die Outgroup ist in der Lage sich ein „Leben“ ohne das AWS vorzustellen, die Ingroup nicht. Vom AWS wegzugehen fällt umso leichter, je weniger der Entscheider Teil des Systems ist, in den meisten Fällen identisch damit, nicht Teil der Historie des AWS zu sein Folglich kann ein Impuls zum Wechsel am Einfachsten durch Entscheider produziert werden, die von außerhalb des Unternehmens kommen.
Die Entscheidung
Ist die Entscheidung gefallen, vom bestehenden AWS wegzugehen, dann stellen sich sofort zwei Fragen: Was und Wie? Meist existiert auf dem Markt für kommerzielle Software kein Produkt, das die Software im bestehenden AWS direkt ersetzen kann. Zu viele Eigentümlichkeiten sind im Laufe der Historie in die Software gewandert. Ein vollständiger Ersatz bestehender Prozesse wird hingegen als so bedrohlich empfunden, dass die Prozesse nicht fundamental überdacht werden können. Konfrontiert mit dem Dilemma Änderungen durchführen zu müssen, aber gleichzeitig die bestehenden Mechanismen nicht zu verändern, erscheinen Standardplattformen ein Ausweg. Der Begriff Standard suggeriert Allgemeingültigkeit und Stabilität. Der Zusatz Plattform erweckt Assoziationen in Richtung Ausbaufähigkeit und Veränderbarkeit. Forciert wird dies durch Hersteller, die behaupten, dass durch Konfiguration die Plattform beliebige Funktionalitäten abdecken kann. Meist sind Hersteller auch noch so „hilfreich“ und haben Partner, die die Anpassungen vornehmen können; für beide, Hersteller und Partner, ein gutes Geschäft, da zum einen der vorgebliche Standard nie in Frage gestellt wird – oft zitieren die Hersteller Kundenzahl als einen „Beweis“ für die Existenz und die Einhaltung eines Standards – und für die Partner, welche Maleabilität der Software in Aussicht stellen. Die Verkaufsargumente werden durch Success-Stories „untermauert“, Projekte, die die Standardplattform erfolgreich eingesetzt haben. Was hierbei erfolgreich bedeutet, ist meist fragwürdig, da die Beteiligten so intensiv mit dem Erfolg des Projekts verbunden sind, dass sie nicht in der Lage sind, sich einen Misserfolg einzugestehen. Im Unternehmen beginnt ein intensives Marketing. Dem Management erscheint der Einsatz der Standardplattform zukunftsweisend. Diese Nachricht wird intensiv reiteriert und bekommt mit zunehmender Wiederholung immer mehr subjektiven Wahrheitsgehalt. Die Mitglieder der Ingroup (sozialer Bestandteil des AWS) liefern schnell Risiken, um den Wechsel zu verhindern:
- Die gesamte fachliche Funktionalität AWS ist unbekannt, daher ist unklar, was passiert, wenn es abgeschaltet wird. Wir werden Daten verlieren.
- Die Historie lässt sich nicht abbilden, aber die Wirtschaftsprüfer fordern dies für die letzten 12 Jahre.
- Die Schnittstellen zu den anderen Systemen sind unbekannt.
- Es fehlen fachliche Funktionen, welche sehr viel Zeit einsparen.
Beide Lager kämpfen um die Meinung innerhalb des Unternehmens. Um die Risiken abzuschwächen und die scheinbar benötigte Funktionalität zu liefern, wird angekündigt, auf der Standardplattform die entsprechenden Veränderungen vorzunehmen – zur Freude des Partners. Parallel hierzu wird klar, dass das vorhandene AWS so lange existiert, bis die letzte Schnittstelle ersetzt wurde; was mehrere Jahre dauert – zur Freude der Entwickler. Am Ende verschwindet das AWS oft nicht, es bleiben Reste übrig, deren Ablösung teuer ist, ohne einen Mehrwert zu bieten, so dass jeder die entsprechende Investition scheut.
Die Realität
Bei dem Vergleich zwischen der bestehenden Software (Altsoftware) und einer aus der Veränderung einer Standardplattform resultierenden Software (Neusoftware) ist man geneigt, die Neusoftware in Hinsicht auf Pflegbarkeit, Architektur, Lebensdauer und Stabilität, für überlegen zu halten. Neusoftware hat zwei Quellen, welche ihre Struktur stark beeinflussen: Zum einen die Plattform und zum anderen die Adaption der Plattform. Die Plattform muss a priori eine gewisse funktionale Reife haben, sonst kann sie für Nutzer kaum sinnvoll eingesetzt werden. Diese Reife kann aber nur über eine längere Evolution erreicht werden, so dass die Software stets ein gewisses Alter besitzt. Zwar wird sie meist jünger sein als die Altsoftware, trotzdem kann sie durchaus 10-20 Jahre aufweisen. Daneben finden sich in der Plattform Strukturen, die ein Abbild der Herstellerorganisation darstellt, das Gesetz von Conway! Daher müssen die Strukturen in der Software nicht zu den Strukturen des Unternehmens, sprich Prozessen und Kommunikationswegen, passen. Diese Verwerfungen werden meist durch eine spezielle Form der Implementierung überbrückt, mit der Konsequenz, dass die implizit vorhandenen Architekturen in der Plattform in der Neusoftware verwässert erscheinen. Der theoretisch beste Weg, die Adaption der eigenen Prozesse, findet selten statt, da im Vorfeld die Veränderbarkeit der Plattform einen Adaptionsprozess ausgeschlossen hat.
Der Partner nutzt als Modell seine eigene Unternehmensstruktur und die Struktur des Unternehmens, für das er die Neusoftware schaffen soll, mit dem Resultat, dass nun diverse Strukturen abgebildet wurden. Die Neusoftware ähnelt oft der Altsoftware in bestimmten Aspekten und ist meist nicht sehr viel besser wartbar. Es entsteht ein neues soziotechnisches AWS nun allerdings mit dem Partner und der Neusoftware als Teile des Systems. Das System findet einen Gleichgewichtszustand und entwickelt ein Eigenleben anlog dem alten AWS. Neben dem Ersatz einzelner AWS zeigen Standardplattformen ein anderes Phänomen auf: Sie bilden ein Schwerkraftzentrum im Unternehmen. Oft wird mehr als ein AWS auf der Plattform realisiert, mit der Konsequenz, dass das entstehende soziotechnische System sprunghaft wächst. Das neue System verankert sich noch stärker im Unternehmen und ist allein durch seine Größe und Komplexität weniger beherrschbar.
Lösungen
Was kann man tun? Der Fehler liegt im Festhalten an den bestehenden Prozessen. Jede Form von Ersatz eines AWS muss mit der Frage nach der Sinnhaftigkeit der bestehenden Prozesse beginnen. Wenn diese Prozesse nicht wirklich differenzierend sind, dann müssen sie in der bestehenden Form auch nicht aufrechterhalten werden. Dann können auch die Prozesse aus einem Standardsoftwarepaket genutzt werden. Dieser Schritt ist schwierig und erzeugt Widerstände, führt aber zu einer Konzentration auf wichtige Prozesse. Selbst wenn ein Prozess nötig ist, stellt sich die Frage, ob die Form noch sinnvoll ist und welche Parameter wirklich gebraucht werden.
Hier empfiehlt sich simultanes Design, d.h. die parallele Entwicklung des Systems auf der Prozess- als auch auf der Softwareebene. Insofern ist klar, was eine Standardplattform leisten muss: Sie muss genügend Freiheit für simultanes Design liefern. Für alle anderen Einsatzformen gibt es meist Standardsoftware! In der Governance ist es wichtig für Mechanismen zu sorgen, die erlauben, das System tatsächlich vollständig abschalten zu können. In den meisten Fällen gibt es für das Abschalten keinen Business Case, der sich auf kurze Dauer rechnet, dies führt langfristig zu einer Proliferation an nichtabschaltbaren Systemen.
