Direkt zum Hauptbereich

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.

Kommentare

  1. Dieses wird und ist heute möglich da sich viele Programme sehr stark anpassen lassen. Nehmen wir mal Office; Excel, Word und Outlook. Diese Programme können sehr individuell angepasst werden und so kann eine Basis geschaffen werden, für Programme die nur das an Funktionen anbieten was das Unternehmen, die Abteilung oder die einzelne Aufgabe erfordert. Excel kann sowohl als dynamische Eingabemaske oder zum visualisieren von Daten verwendet werden. Es ist notwendig auf Dateiebene eine Trennung zwischen Eingabemaske und Datenbank zu realisieren. Word oder Excel lassen sich hervorragend einsetzten um den Schriftverkehr, Rechnungen, Angebote zu erstellen. https://www.youtube.com/watch?v=XSnk_NmgzWc
    Heute ist es möglich aus Exceldateien kleine individuelle Apps für Android und OS2 zu erstellen. Datenbanken können in webbasierten Dashboards schnell und individuell angezeigt und aufbereitet werden. Onlinedatenbanken oder Ordnerstrukturen lassen sich in zertifizierten Cloudsystemen zum einen sicher speichern und GoB konform archivieren und auch auf den verschiedensten Endgeräten anzeigen und zugreifen. Es gibt mittlerweile auch schon Dienstleister die Dienste in der Cloud erledigen. So kann eine Aufgabe auch komplett an einen externen Anbieter ausgelagert.
    Technisch ist heute durch einen technischen Bausteinansatz sehr viel möglich.

    AntwortenLöschen

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Tooling #4: Die gute alte Augenhöhe

Manchmal werde ich gefragt, was für meine Arbeit die wichtigsten Tools und Herangehensweisen sind. Ein paar habe ich die letzten Wochen bereits vorgestellt ( hier findest du sie ). Heute geht es um ein weiteres, enorm wichtiges und wirksames Basiswerkzeug: Die gute alte Augenhöhe.