Mittwoch, 12. November 2014

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

Kommentare:

  1. Thanks for the reference. The latest approach to this "enterprise specification" issue is capabilities based planning. http://www.slideshare.net/galleman/capabilities-based-planning-v2

    In this approac, we define the needed capabilities in units of measure of effectiveness, performance, key parameters and other "mission" focused description. Then development elicits requirements that fulfill the mission capabilities in a "trade space" manner, where technical, financial, temporal, and other attributes are "traded" to assure the best value is delivered for the cost and time.

    The project is "managed" through these "trades." This is a System of Systems paradigm found in space and defense that is applied in the IT domain

    AntwortenLöschen
    Antworten
    1. Thanks Glen for your hint to capability-based planning.

      Löschen