Agile Einführung von ERP, DMS & Co.: die Rollen des Scrum-Modells ändern sich kräftig!

Die IT und hier wiederum der Bereich der Entwicklung ist zur ständigen Quelle neuer Ideen und neuer Rollenmuster geworden. Hier wurden zuerst die agilen Methoden wie Scrum, Kanban entworfen, erprobt, verbreitet. Kein Grund, diese Methoden hier einzusperren. Die Übertragung auf andere Bereiche bis hin zur Agilisierung ganzer Unternehmen ist eine spannende Vision. Das Wort „Übertragung“ aber trifft es nicht ganz: einige Konzepte zum Beispiel von Scrum müssen dabei sorgfältig angepasst werden.


Organisationsentwicklung umfasst viele verschiedene Aufgaben, durch die ein Unternehmen sich verbessert und erneuert: Prozessmanagement gehört dazu, Methoden der Strategieentwicklung usw. Wir wollen hier als Beispiel das Thema „Einführung von Unternehmenssoftware“ wählen.
Im Vergleich zu Projekten der Softwarenentwicklung, bei denen ein Produkt speziell für einen Kunden erstellt wird, geht es hierbei um Einführung von Standardprodukten. Der Kunden formuliert Anforderungen, geht mit diesen an den Softwaremarkt und beschafft eine Standardsoftware. Und diese Software wird dann an die konkreten Bedarfe der Kundenabteilungen angepasst („customized“).

Solche Projekte gehen erfahrungsgemäß mit besonders vielen Risiken einher. Viele Projekte scheitern, weil die Anwender mit der neuen Software nichts anfangen können. Können agile Methoden diese Risiken vermindern?

Softwareprojekte sind OE-Projekte

 

Das ist schon unsere erste These, die wir aus unseren Projekten abgeleitet haben:

„Projekte der Einführung von Unternehmenssoftware (ERP, CRM, DMS …) sind keine IT-Projekte, sondern Projekte der Organisationsentwicklung. Die betroffenen Fachabteilungen müssen das Heft in der Hand haben, nicht die IT-Abteilungen.“

Warum führt man ein ERP oder ein DMS ein? Um einen Nutzen in den Prozessen der Anwender zu erzielen. Wer kann beurteilen, in welchen Prozessen welches Potenzial schlummert und wie dieses zu realisieren ist? Richtig, die Anwender. Während für die IT jeder Prozess gleich wichtig scheint, können die Anwender die Prozesse priorisieren.

Scrum ist wie gesagt aus der Softwareentwicklung entstanden. Will man es auf die Einführung von Standardsoftware anwenden (oder auf andere OE-Projekte), so ergeben sich einige deutliche Änderungen gegenüber dem Grundmodell:

1. Das Scrum-Team erledigt die Projektaufgaben neben der Routinearbeit. Also nicht 40 Std. die Woche, sondern vielleicht nur 8 Stunden oder gar nur 2 Stunden – und das je nach Teammitglied unterschiedlich.
2. Die Timeboxen der verschiedenen Scrum-Meetings (Daily Scrum, Review, Retrospektive usw.) müssen entsprechend angepasst (gekürzt) werden.
3. Die Spezialisierung des Scrum-Teams ist höher. Ein Anwendervertreter im Team (siehe unten) kann auch nicht ansatzweise die Aufgabe des IT-Vertreters wahrnehmen und umgekehrt.
4. Oft sind in den Scrum-Teams verschiedene Hierarchiestufen vertreten. Die Gleichberechtigung im Team ist dann nicht spontan gegeben und vielleicht auch gar nicht herstellbar. Der Scrum-Master muss besonders fit sein im Umgang mit daraus resultierenden Blockaden.

Daneben gibt es die „üblichen“ Probleme, die auch aus dem traditionellen Scrum-Umfeld bekannt sind: Führungskräfte, die mit der Selbstorganisation des Teams noch nicht gut umgehen können, usw.

Die Herausforderungen sind also beträchtlich.

Kunden werden Teil des Teams

 

Aber die Chancen sind es auch. Eine der wichtigsten besteht darin, von vornherein die Projektkunden (nämlich die künftigen Anwender) in die Entwicklungsarbeit einzubeziehen.
In der Regel wählt man eine Reihe (2 oder 3) repräsentative Abteilungen aus, die das Projekt am Anfang begleiten. Aus diesen Abteilungen wiederum werden einige Mitarbeiter für das Projekt ausgewählt bzw. werden eingeladen, sich freiwillig im Projekt zu engagieren.

Abb. 1: Vertreter der Pilotabteilungen definieren Strukturen

Diese Anwendervertreter werden von Anfang an Teil des Scrumteams. (Wir verwenden in unseren Projekten meist das Wort „Umsetzungsteam“. Herkömmliche Abteilungen sind in der Regel nicht so englisch-affin, wie dies in IT-Sektionen schon gang und gäbe ist.)

Abb. 2: Fachabteilungen bringen unternehmensweite Standards ein

Zu diesen Anwendervertretern gesellen sich Vertreter der IT und, falls vorhanden, der Organisationsabteilung oder des Qualitätsmanagements. Diese bringen Kenntnisse zu den zu beachtenden Rahmenbedingungen ins Projekt ein: IT-Umgebung, Qualitätsstandards usw. Sie sorgen dafür, dass das Projekt über den Tellerrand der Pilotabteilungen hinaus blickt.

Abb. 3: Der Vertreter des ERP/DMS-Herstellers bildet die Strukturen in der Software ab

Zu einem späteren Zeitpunkt wird auch der Vertreter des Software-Herstellers in das Umsetzungsteam aufgenommen – natürlich erst, wenn diese beschafft ist.

Abb. 4: Das agile Umsetzungsteam setzt sich aus allen drei Gruppen zusammen

Im Unterschied zur Softwareentwicklung beschränkt sich die Rolle der Anwendervertreter nicht darauf, Anforderungen zu definieren. Vielmehr sind sie aktiv an der Produktion des Ergebnisses beteiligt. Sie definieren die Strukturen, die die Software abbilden soll, und schaffen dafür Informationen herbei. In DMS-Projekten z. B. sind sie es, die den künftigen Ordnerplan erarbeiten, die Metadaten für Ordner und Dokumente festlegen, Normwortlisten incl. Synonymen zur Hinterlegung in Value Sets bereitstellen usw. Das kann vom Aufwand her durchaus dem des Customizing durch den Software-Herstellers entsprechen.

Deutlich verminderte Projektrisiken

 

Was nach unserer Erfahrung in solchen Projekten völlig fortfällt, ist der „Widerstand“ der Anwender. Die Anwender selbst bauen am künftigen System – wo sollte da Widerstand herkommen. Ganz wichtig auch: die Schulung der Mitarbeiter, die nicht am Projekt beteiligt waren, werden von den Anwendervertretern durchgeführt – nicht von der Herstellerfirma. Nur so können die Prozesse in der neuen Anwendung so gezeigt werden, wie sie im Unternehmen wirklich ablaufen. Kein IT’ler kann das.

Ein Seminar zum Thema

 

Am 23. und 24. Februar 2016 führen wir von Common Sense Team in Karlsruhe unser nächstes Seminar über agiles Projektmanagement. Darin werden die Scrum-Methoden vermittelt, aber nicht mit dem Fokus auf Softwareentwicklung geht, sondern auf Organisationsprojekte. (Titel „Agiles Management von OE-Projekten. Am Beispiel ‚DMS in einer Organisation einführen‘“).
Dabei kommen auch andere Anpassungen als nur die der Rollen zur Sprache, die notwendig sind, um agile Projekte erfolgreich zu gestalten.