Die Ursachen für dieses hilflos und unkonstruktiv erscheinende Verhalten waren vielfältig. Der IT Bereich gehörte häufig zum Finanzressort und wurde im Sinne von kurzfristiger Kostenoptimierung und weniger von mittel- bis langfristiger Prozessoptimierung geführt. Ein qualifiziertes Anforderungsmanagement gegenüber den Fachbereichen existierte nicht: Es fehlte an qualifiziertem Personal und - was noch schlimmer ist - zugleich an der notwendigen Erkenntnis, dass dies erforderlich ist. Das IT-Management war durch Entrepreneure der IT-Frühzeit besetzt: Charaktere, die eher Goldgräbermentalität als Organisationskompetenz in sich bargen und deren technische und methodische Kompetenzen bei genauerer Betrachtung bereits vor Jahren als veraltet gegolten hätten. Diese fundamentale Inkompetenz stieß auf eine IT-Landschaft, die durch schnelles Wachstum, insbesondere auch anorganischer Natur, extrem diversifiziert war.
Wen wundert es, dass in einem solchen Umfeld eine Schatten-IT gedieh? Mitarbeiter versuchten, in dem Gefühl im Stich gelassen worden zu sein, sich selber zu helfen. In der Regel führten diese Ansätze über komplexe Excel-Tabellen nicht hinaus. Dennoch bauten schnell komplexe Geschäftsprozesse darauf auf, wobei die Systematik in der Tiefe nur von wenigen Einzelkämpfern verstanden wurde. Hieraus entstand im Verein mit minimaler Skalierbarkeit ein echtes unternehmerisches Risiko, welches dann - im Prinzip zu Recht aber im Hinblick auf die Ursachen eher paradoxerweise - von der internen IT angeprangert wurde.
Ich spreche von Vorgängen, die in meiner Erfahrung z.T. zehn Jahre zurück liegen. Haben sich die Zeiten seit dem maßgeblich geändert? Dem Augenschein nach ja, da die Technologieentwicklung und die methodischen Ansätze in der Softwareentwicklung riesige Fortschritte verzeichnen konnten. Die Organisationen hinken dem jedoch dramatisch hinterher. Wem wird heutzutage in der Mehrzahl der Unternehmen zugetraut, das eigene Geschäftsmodell auf die nächste Ebene der Digitalisierung zu heben? In der Regel nicht der institutionalisierten Bestands-IT, die seit Jahren an der Vereinfachung der internen Abläufe - mit mehr oder minder großem Erfolg - arbeitet. Vielmehr versuchen gerade die großen Unternehmen hierfür separate und neue Teilorganisationen ins Leben zu rufen, die eine möglichst geringe Überschneidung mit den Bestandsinstitutionen aufweisen. Die Gründe hierfür dürften - von Unternehmen zu Unternehmen in Nuancen variierend - jedoch im Kern dieselben sein, die in der Vergangenheit zu meiner regelhaften Wahrnehmung der geringen Leistungsfähigkeit interner IT-Organisationen führte.
Um diesem Problem Herr zu werden gibt es zwei mögliche Ansätze. Der erste liegt trivialerweise auf der Hand: Restrukturierung und Modernisierung der internen IT, um diese zeitgemäß und ggf. erstmals serviceorientiert aufzustellen. Auf die Herausforderungen dieses Weges möchte ich in der Folge nicht weiter eingehen.
Gerade für mittelständische Unternehmen eröffnen sich Alternativen, die dem gestandenen IT-Leiter bei erster Betrachtung Schauer des Entsetzens bescheren. Wie wäre es, wenn man die Schatten-IT aus ihrer Schmuddelecke hervorzieht und ebenso legitimiert wie professionalisiert? Ist das ein denkbarer Weg?
Dies ist es. In mehrerlei Hinsicht sind die Voraussetzungen für ein solches Vorgehen heutzutage gegeben. Erstens gibt es mittlerweile zahlreiche rapid development Umgebungen, die hinreichend mächtig sind, um durchaus auch komplexe fachliche Anwendungen flexibel abzubilden (Microsoft Access, Filemaker, caspio, oracle APEX, ninox, etc.).
Zweitens hat sich die mittlere Affinität der Mitarbeiter zu IT-basierten Medien massiv erhöht, so dass die Einstiegshürde in der Auseinandersetzung mit diesen Entwicklungsumgebungen viel niedriger ist als früher. Zu guter letzt bieten mittlerweile bewährte, agile Vorgehensmodelle in der Softwareentwicklung ein Grundgerüst, welches bei richtiger Anwendung der Denkweise der Fachabteilungen sehr entgegenkommt. Damit das Vorhaben gelingt, muss man allerdings einige wichtige Randbedingungen im Blick behalten:
- Die Mitarbeiter müssen eine Grundidee für die Formulierung und Verarbeitung von Anforderungen gewinnen. Wer diesen Weg geht wird feststellen, dass die Mitwirkungsbereitschaft der Fachabteilung an dieser Stelle viel ausgeprägter ist, wenn die Mitarbeiter die Entwicklung in eigener Hand halten.
- Pro Fachabteilung sind wenigstens zwei Kollegen erforderlich, die in der Lage sind, sich mit der erwählten rapid development Umgebung auseinanderzusetzen und in hinreichender Tiefe einzuarbeiten. Das Argument "dafür haben meine Leute keine Zeit" gilt nicht: sie werden beobachten, dass bei den Mitarbeitern verblüffende Kapzitätsreserven mobilisiert werden (bis hin zum privaten Engagement), sobald sie merken, dass sie die Chance erhalten, wirksam und selbstbestimmt ihren Arbeitsalltag zu optimieren.
- Die Schnittstellen zu relevanten Umsystemen müssen abgestimmt werden. Hier spielt wiederum der zentrale IT-Bereich eine wesentliche, teils beratende, teils mitwirkende Rolle.
- Die Betriebsfrage muss geklärt werden. Die Fachabteilung sollte in die Verantwortung für den reinen Applikationsbetrieb treten, Plattform- und Infrastrukturkomponenten müssen jedoch durch den zentralen IT-Bereich übernommen werden.
- Die Mitarbeiter des Fachbereichs müssen eine Vorstellung eines "minimum viable products" (MVP) entwickeln. Dies ist die Mindestentwicklung, die erforderlich ist, um erste Erleichterungen für ihre Fachbereichskollegen zu erzielen. Davon ausgehend kann in regelmäßigen Releasezyklen sukzessiv eine Anreicherung von Fachlichkeiten erfolgen. Dies ist elementar, da gerade unerfahrene Organisationen dazu neigen, ihre Erstentwicklung mit Feature-Wünschen so zu überfrachten, dass eine Fertigstellung in einem realistischen Zeitfenster nicht mehr möglich ist.
- Bei den Mitarbeitern muss das Bewusstsein geweckt werden, dass sie Anteil an geschäftskritischen Entwicklungen haben. Dem zur Folge ist Qualität ein maßgebliches Kriterium, welchem man nur durch eine hinreichende Testkultur - sei es automatisiert oder per Testfallkatalog - gerecht werden kann.
- Es sollten feste Releasezyklen definiert werden. Diese sind im agilen Sinne zu begreifen und bedeuten keine zwingend langfristig vorgeschriebene Roadmap. Es gilt das Motto: "Kleinvieh macht auch Mist" - auch geringe Fortschritte sind es immer wert für alle Kollegen produktiv bereitgestellt zu werden.
- Bei zunehmender Reifung der Organisation kann dann auch über komplexere, nicht funktionale Anforderungen nachgedacht werden: Applikationssicherheit und Skalierbarkeit. Da der Anwenderkreis in erster Instanz klein ist, sollte dies jedoch stets vor dem Hintergrund des Istzustands und des sinnvoll Machbaren bewertet werden. Gerade für das Thema Sicherheit heißt dies stets: stellt der neue Zustand eine reale Verschlechterung gegenüber dem alten dar? Diese Frage dürfte in der Regel mit "Nein" beantwortet werden.
Dies erscheint auf den ersten Blick für ein mittelständisches Unternehmen ohne besondere IT-Affinität recht aufwändig und kompliziert zu sein. Doch nicht alle Rahmenbedingungen sind im ersten Schritt zu erfüllen und es bleibt stets die Möglichkeit, sich für einen begrenzten Zeitraum einen Berater mit entsprechenden Know-How an Bord zu holen. Hierbei ist jedoch sorgfältig darauf zu achten, dass derjenige nicht darauf abzielt alles selbst zu entwickeln sondern gemeinsam mit den Mitarbeitern tragfähige Strukturen für die Zukunft etabliert.
Geht man diesen Weg, so ist viel zu gewinnen. Ich erlebte, wie ein Mittelständler binnen zwei Jahren so über vier Fachabteilungen hinweg eine konsolidierte Systemlandschaft beginnend bei der Personalverwaltung bis hin zum CRM aufbaute.
Die Einstiegshürden und Startrisiken sind gering (wo nichts Funktionsfähiges ist, kann man auch nichts kaputt machen). Probieren Sie es aus!
Keine Kommentare:
Kommentar veröffentlichen