Scrum für ERP-Projekte (oder DMS oder CRM ...)

Viele Mitarbeiter können Horrorgeschichten über die Einführung von Unternehmenssoftware erzählen. Selbst nach 10 Jahren bekommen neuen Mitarbeiter oder IT-Dienstleister über die Einführung von "WAAN Titan" oder "SLAP EBB" zu hören. Solche Projekte wurden oft von Grund auf falsch aufgesetzt. Aber es gibt gute Alternativen.

Was ist Unternehmenssoftware?

Als Unternehmens-IT  oder Unternehmenssoftware bezeichnen wir Softwareprodukte, die an vielen Arbeitsplätzen in einer Firma installiert werden, damit Mitarbeiter sie für ihre Aufgaben benutzen.

Der Kauf von einem Office-Produkt ist keine Unternehmenssoftware. Das ist Funktions-IT. Sie erleichtert die Ausführung einzelner Aufgaben. Andrew McAfee schreibt über Unternehmenssoftware, dass sie Geschäftsprozesse festlegt, den Mitarbeitern Identitäten und Rollen zuweist, dass es eine bestimmte Bearbeitungsreihenfolge und feste Datenformate gibt. Alle Mitarbeiter sind dazu verpflichtet, die Software zu benutzen /1/.

Warum scheitern Projekte zur Einführung von Unternehmenssoftware

Bent Flyvbjerg und Alexander Budzier untersuchten fast 1.500 IT-Projekte auf ihre geplante Leistungsverbesserung und die tatsächlichen Kosten /2/. Im Durchschnitt überschritten die Projekte die Plankosten „nur“ um 27%. 27%. (Aber nach Sam Savage befindet sich ein Betrunkener auf der Autobahn im Durchschnitt auch nur auf der Mittellinie.) Tatsächlich fanden Flyvbjerg und Budzier eine große Anzahl Projekte mit gigantischen Überschreitungen. Sie bieten zum Schluss zwei Fragen für einen Selbsttest an:

1. "Ist das Unternehmen stark genug, den Rückschlag abzufedern, wenn sein größtes IT-Projekt die veranschlagten Kosten um 400 Prozent oder mehr überschreitet und wenn es nur 25 bis 50 Prozent des geplanten Nutzens erzielt?
2. Kommt das Unternehmen auch damit zurecht, wenn 15 Prozent seiner mittelgroßen IT-Projekte (nicht jene, die alle Aufmerksamkeit des Topmanagements auf sich ziehen, sondern die kleineren, die oft übersehen werden) die geschätzten Kosten um 200 Prozent übersteigen?" /2/

Solche Projekte haben die Saat zum Scheitern schon in sich, wenn man sie als IT-Projekte bezeichnet. Im Business-Kontext sind alle Projekte Business-Projekte. Niemals darf die IT-Abteilung solch ein Projekt vorantreiben. Es muss immer einen Auftraggeber von der Businessseite geben. (Es gibt historische Gründe, warum die IT-Abteilungen Softwareprojekte machen. Aber die müssen wir hinterfragen.)

Viele Unternehmen glauben, die Einführung von Unternehmenssoftware sei ein planbares Vorhaben, in dem es keine Änderungen gibt. Sie erwarten zu Beginn ein Commitment von allen Beteiligten zum Plan. Glen Alleman fasst in einem Artikel über agile Methoden für ERP-Systeme zusammen /3/:

• Es ist menschlich nicht möglich einen Plan zu erstellen, bei dem man nur noch die einzelnen Aufgaben ausführen muss.
• Es ist nicht möglich, solche Projekte gegen Änderungen abzusichern. Es gibt immer Änderungen, auch späte.

Letztlich sind Projekte, bei denen ein ERP-System oder andere Unternehmens-IT eingeführt wird, Projekte mit einem anderen Unsicherheitsprofil. Solche Projekte brauchen viel früher Feedback. Wenn Sie bis zur Testphase warten, um Feedback zu bekommen, kommen Sie in große Zeitnot. Denn oft müssen Sie nach dem Testen noch viel anpassen. Das hat nichts mit schlechter Arbeit zu tun, sondern damit, dass Sie in solchen Projekten viel früher Feedback brauchen.

Warum eignet sich Scrum besser zur Projektsteuerung?

Scrum ist ein Vorgehen, das Wert auf frühes Feedback legt. Scrum ist eine Feedbackmaschine. Bei der Einführung von Unternehmens-IT geht es nie um die Software, sondern um ein Anpassen von wesentlichen Arbeitsweisen /siehe 4 und 5/. Um die zu testen, brauchen Sie nicht auf die fertige Software zu warten. sie können dies mit kleinen Tools auch schon vorher tun.

Bei Scrum trifft sich das Umsetzungsteam in regelmäßigen Abständen (z. B. alle 1-4 Wochen) und bespricht die nächsten Ziele (Sprint Planning). Das Sprint Planning wird durch das sog. Refinement soweit vorbereitet, dass das Team während des Sprint Plannings fundierte Entscheidungen treffen kann.

Einerseits lernen alle Beteiligten ihre eigenen Prozesse besser kennen. Zum anderen bieten diese Besprechungen die Chance, Probleme auch ohne Software zu lösen. Einige Geschäftsprozesse haben vielleicht so viele Varianten und Ausnahmen, dass das Gießen in Software zu teuer wäre. Diese Entscheidung treffen das Team und der Auftraggeber (Product Owner) gemeinsam und nicht die IT.

Durch das regelmäßige und stückweise Liefern von Bausteinen bekommt das Unternehmen echten Mehrwert. Alle Betroffenen können über die Zeit immer besser einschätzen, wie die neue Software helfen kann.

Das wäre doch ein Versuch wert, oder?

Anmerkungen

• /1/ Andrew McAfee : Keine Angst vor IT-Management,  erschienen im Harvard Business Manager, Januar 2007, http://www.harvardbusinessmanager.de/heft/d-49837715.html
• /2/ Bent Flyvbjerg, Alexander Budzier: Software läuft - Unternehmen pleite, erschienen im Harvard Business Manager, Dezember 2011, http://www.harvardbusinessmanager.de/heft/d-81902036.html
• /3/ Glen B. Alleman: Agile Project Management Methods for ERP: How to Apply Agile Processes to Complex COTS Projects and Live to Tell about It, erschienen in Williams, Lauris ; Wells, Don: Extreme Programming and Agile Methods - XP/Agile Universe 2002 : Second XP Universe and First Agile Universe Conference Chicago, IL, USA, August 4-7, 2002.Proceedings. 2002. Aufl.. Berlin Heidelberg: Springer Science & Business Media, 2002, S. 70-88, abrufbar unter http://www.niwotridge.com/PDFs/AgileMethodsforERP.PDF
• /4/ Jan Fischbach: Ein Weg aus dem Wahnsinn der IT-Projekte, Initiative Wirtschaftsdemokratie, erschienen am 13. Mai 2014, abrufbar unter http://wirdemo.buergerstimme.com/2014/05/ein-weg-aus-dem-wahnsinn-der-it-projekte/ 
• /5/ Fischbach, Jan: Die zwei wichtigsten Regeln für IT-Projekte, Wie Sie mit zwei Regeln mehr Erfolg und weniger Stress haben, erschienen in HR Performance, S. 60-63, Ausgabe 6/2014, abrufbar unter http://www.commonsenseteam.de/publikationen/