So gelingt der Wechsel von Individualentwicklung zu StandardsoftwareTransformation der IT-Aufbauorganisation
von Norbert Gronau
 Lesedauer: 4 Minuten
|
Viele Unternehmen, die auf eigenentwickelte Software setzen, verfügen über eine umfangreiche IT-Abteilung mit umfassenden Programmierkenntnissen über die – meist proprietäre – Softwarelösung. Besonders häufig tritt diese Struktur bei Nutzern der IBM iSeries auf, ist aber nicht darauf beschränkt. In einer hart umkämpften Geschäftswelt, in der Kernkompetenzen ständig verteidigt und ausgebaut werden müssen, kann die eigene Entwicklung von Anwendungssoftware nur in wenigen Fällen einen großen Beitrag zur Verbesserung der Wettbewerbsposition leisten. Zumeist ist der geschickte Einsatz von angepasster Standardsoftware vorteilhafter. Von daher stellt sich die Frage, wie eine IT-Organisation von umfassender Individualentwicklung auf die wettbewerbsorientierte Betreuung von Standardsoftware umgestellt werden kann. Dazu wird in diesem Beitrag ein praxiserprobter Weg aufgezeigt.
Die prinzipielle Aufgabe einer Transformation der IT-Organisation ist in Bild 1 dargestellt. Da trotz der Umstrukturierung der normale Betrieb weitergehen muss, muss die Betriebsfähigkeit der Altsysteme gewährleistet werden. Eine weitere sehr wichtige Anforderung ist das Halten wichtiger Kompetenzträger im Unternehmen. Es stellt schon fast einen Glücksfall dar, wenn in einer Organisation, die keine IT-Leistungen verkauft, so viel IT-Kompetenz vorhanden ist. Nach Einschätzung des Autors lässt sich ein Großteil dieser Kompetenz auch im Standardsoftwarebereich nutzen – wenn der entsprechende Mitarbeiter das möchte und ihm entsprechende Pfade der persönlichen Weiterentwicklung schmackhaft gemacht werden. An sich wünschenswerte und auch mögliche Maßnahmen zur Kostenreduzierung im IT-Bereich sollten unbedingt verschoben werden, bis die personellen Rahmenbedingungen geklärt sind und insbesondere wichtige IT-Leistungsträger für eine weitere Mitarbeit im Unternehmen vertraglich gebunden werden konnten. Nichts wäre misslicher, als in einer Situation akuten Fachkräftemangels wertvolle ausgebildete und branchenerfahrene Mitarbeiterinnen und Mitarbeiter zu verlieren, nur weil Ungeschicklichkeiten bei der Kommunikation der Transition passieren!
Die ideale IT-Organisation
Um die Transformationsaufgabe inhaltlich und zeitlich zutreffend planen zu können, ist als Erstes ein Zielbild erforderlich. Dieses Zielbild muss die beiden „Gegenpole“ der wertschöpfenden Geschäftsprozesse auf der einen Seite und der einzusetzenden Informatik-Technologien auf der anderen Seite sinnvoll miteinander verbinden. Eine mögliche Anordnung von Rollen in dieser Organisation zeigt Bild 2.
Der Leitgedanke hinter dieser Struktur ist, dass sich Prozessinnovation und Technologieinnovation gegenseitig befruchten. Dabei sollte die Trennungslinie zwischen dem Businessbereich (einschließlich der Verantwortung für die Wertschöpfung) und dem IT-Bereich (einschließlich der Verantwortung für den Betrieb der IT) aufrechterhalten werden. Beide Bereichen sollten jedoch auf die gleichen agilen Methoden und Mechanismen zur Betreuung der Key-User zugreifen, also Incident Management, Problem Management und Change Management, z. B. nach ITIL-Standard [1].
Durchführung der Transition
Für die Durchführung der Transition wird ein mehrstufiges Vorgehen vorgeschlagen (Bild 3).
In der Ramp-Up-Phase wird zunächst die neue IT-Organisation geplant und die entsprechende Rollenbesetzung verfeinert. Ein Beispiel für eine in diesem Kontext relevante Persona, mit der die neuen zu besetzenden Rollen beschrieben werden, ist in Bild 4 dargestellt.
Sobald die neue Struktur kommuniziert ist, beginnt Phase 2, in der parallel die weitere Wartung der Altsysteme und die Einführung der neuen Standardsoftwaresysteme erfolgen. Sukzessive nimmt der Bedarf an Entwicklern von Individualsoftware ab und der an Betreuern von Standardsoftware zu. Als wichtigste neue Aufgabe kommt die Zusammenarbeit mit dem Business in der neuen, agilen Organisationsform hinzu. Entsprechende Werkzeuge zur Organisation der Zusammenarbeit sollten bereits bei Beginn von Phase 2 zur Verfügung stehen. Die dritte wichtige Aufgabe in dieser Phase ist der Transfer des in den Personen gebundenen Wissens in eine explizite Form. Hierzu kann ein Wiki verwendet werden [2]. Jede Mitarbeiterin und jeder Mitarbeiter der ursprünglichen IT-Organisation wird dazu angehalten, in regelmäßigen Abständen einen Eintrag im Wiki zu verfassen, beginnend mit ihren Lieblingsthemen. Die Leitung des Steering Boards und die IT-Leitung verknüpfen diese Beiträge miteinander und fordern zum Schreiben ergänzender Einträge auf. So sorgen sie für eine kontinuierliche Auffüllung und Verdichtung des Wiki. Wenn dann auch Themen der neuen Standardsoftware-Organisation aufgenommen werden, entsteht in kurzer Zeit ein guter Zugang zum vorher nur in den Personen vorhandenen Geschäftswissen.
Phase 3 wird eingeleitet, wenn die ersten Standardsoftware-Projekte abgeschlossen sind bzw. in den Produktivbetrieb übergehen. Zu diesem Zeitpunkt wird die neue, sorgfältig vorbereitete Aufbauorganisation wirksam. Die Altsysteme werden noch punktuell gewartet, soweit erforderlich und neue Projekte werden im Rahmen der zuvor eingeführten agilen Organisation geplant, abgestimmt und durchgeführt.
Die Dauer der Überführung einer Individualsoftware-Organisation in eine Standardsoftware-Organisation kann mit neun bis 18 Monaten angegeben werden. Die hier beschriebene Transition sollte durch entsprechende Maßnahmen des Change Management und rechtzeitige, intensive Kommunikation eingeleitet werden, um erfolgreich abgeschlossen werden zu können.
Literatur
[1] Gronau, N.: Mehr Anwenderzufriedenheit durch besseren ERP-Support, ERP Management 4/2010, S. 18-20.[2] Birn, L., Müller, C.: Kollaboratives Dokumentieren mit Sozialer Software, ERP Management 2/2006, S. 36-39.
Branchen: branchenübergreifend
Das könnte Sie auch interessieren
