Drucken

ERP-Einführung mit Implementierungspartnern – Herausforderungen des Projektmanagements

ErfolgProjekte zur Einführung eines ERP (Enterprise Ressource Planning)-Systems werden häufig von einem externen Partner begleitet. Neben Kenntnissen der Software bringt dieser auch methodische Erfahrungswerte zum Projektmanagement mit – Verlassen sollten Sie sich darauf allerdings nicht: Ein Praxisleitfaden für Projektmanagement mit Implementierungspartnern.

Der Beauty-Contest: Drum‘ prüfe, wer sich lange bindet

Vorausgesetzt, Sie haben ausreichend erfahrene MitarbeiterInnen in Ihrer EDV-Abteilung und ausreichende Kapazitäten in Ihrer sonstigen Belegschaft, kann die Einführung eines ERP-Systems theoretisch auch ohne Implementierungspartner erfolgen. In der Praxis wird es jedoch kaum möglich (und auch nicht erwünscht) sein, die Verantwortung für die Einführung ausschließlich auf interne Personen zu bündeln. Somit kommen eine Vielzahl an Freiberuflern, Beratungs-, und Systemhäusern als mögliche Implementierungspartner in Betracht. Folgende Kriterien sollten bei der Auswahl einbezogen werden:

  • Dauer der Geschäftstätigkeit des Partners
  • Anzahl bereits durchgeführter Installationen Ihres ausgesuchten ERP-Systems
  • Nennung von Referenzkunden in Ihrer Branche, welche einem Besuch und Begutachtung des Systems zustimmen
  • Bei Standardsoftware: Ist Partner durch den Softwarehersteller zertifiziert?
  • Kapazitäten des Partners für Ihr Projekt und Anzahl Mitarbeiter gesamt
  • Bonität des Partners z. B. über Auskunfteien erfragen; Haftpflichtversicherung vorhanden mit Deckung bis zu welcher Höhe?
  • Eindruck des Partners bei einer Präsentation des ERP-System mit von Ihnen zur Verfügung gestellten Daten und Aufgabenstellungen. Lassen Sie sich nicht nur idealisierte Online-Präsentationen des Systems mit Daten des Partners vorführen.
  • Erfahrung, Vorschläge und eingesetzte Werkzeuge des Partners zu
    • Projektaufbau (z. B. Rollen und Gremien, Teilnehmer; siehe Kapitel Der Projektaufbau)
    • Projektablauf (z. B. Projektpläne, Gantt-Diagramme, Ressourcenplanung intern/extern)
    • Leistungsstand und Budgetstand (z. B. Budgetstand: Transparenz der Zeiterfassung; Leistungsstand: Nachvollziehbare Kennzeichnung des Abschlusses von Einzelaktivitäten aus Projektplan; Umgang mit auftretenden Änderungen, so genannten Change Requests CR; siehe Kapitel Der Vertrag)

Denken Sie daran, dass eine ERP-Systemeinführung nicht nur ein hohes Kostenrisiko mit sich bringt, sondern auch hinsichtlich Motivation der MitarbeiterInnen und Lauffähigkeit des Tagesgeschäfts von enormer Bedeutung ist. Binden Sie bei der Vorstellungsrunde potentieller Partner auch Ihre Mitarbeiter/Key User und die interne Projektleitung ein.

Der Vertrag: Kein Bund für’s Leben, aber…

… auch von langer Dauer. Die Einführung eines ERP-Systems wird – abhängig von der Komplexität – zwischen 9 und 15 Monaten dauern. Grundlage eines Vertrags wird in der Regel ein Lastenheft (von Ihrer Seite oder dem Implementierungspartner mit Ihnen gemeinsam erstellt) und ein darauf basierendes Pflichtenheft sein. Mit dem ausgesuchten Leistungspartner sind mindestens die folgenden Themengebiete zu regeln:

  • Leistungsgegenstand
    • Auch unter bilanziellen Aspekten sollte geprüft werden, ob Sie einen so genannten Werkvertrag (Anspruch auf einen definierten Erfolg im Sinne eines Gewerks/Gegenstand) oder einen Dienstleistungsvertrag (Anspruch auf eine Leistung/Dienstleistungserbringung ohne geschuldeten Erfolg) abschließen.
    • Zeitpunkt der Umstellung (Going Live). Hier empfiehlt es sich einen günstigen Zeitpunkt zu wählen z. B. einen Quartalsabschluss.
    • Ansonsten sind folgende Leistungen/Kostenpositionen zu definieren:
      • Anzahl und Höhe Lizenzkosten bei Standardsoftware
      • Implementierungskosten (Analyse, Konzeption, Programmierung, Tests, Debugging/Fehlerbehebung und Inbetriebnahme inkl. Altdatenübernahme) als Tagessatz oder Festpreis
      • Art und Umfang Schulungen
      • Art und Umfang Dokumentation
      • Support/Service/Gewährleistung unmittelbar nach Going Live
  • Änderungsmanagement/Change Request (CR)
    • In jedem Projekt gibt es unvorhergesehene Änderungen, die im ursprünglichen Pflichtenheft nicht vorgesehen waren. Achten Sie darauf, dass ein klares Procedere geregelt ist, wie solche CR dokumentiert, kalkuliert und im Vorfeld der Umsetzung freigegeben werden. Hier liegt das größte Risiko für eine Überschreitung Ihres Budgets. Eventuell lassen sich die Auswirkungen durch Vereinbarung eines geringeren Stundensatzes für die CR-Umsetzung abdämpfen.
  • Art und Höhe der Vergütung/Pönale
    • Sofern von Ihrem Partner zugebilligt, empfiehlt sich für eine Erhöhung der Planungssicherheit, einen Festpreis zu vereinbaren. Sie können mit an Sicherheit grenzender Wahrscheinlichkeit davon aus gehen, dass dieser Festpreis wegen notwendiger, aber nicht vorhersehbarer Änderungen / Change Requests überschritten wird. Planen Sie daher in Ihrer internen Kalkulation einen Sicherheitspuffer von mindestens 15% ein.
    • Bei Überschreitung des Going Live Zeitpunkts wegen auftragnehmerseitiger Mängel, kann außerdem eine Pönale/Konventionalstrafe verankert werden (z. B. X EUR pro Woche)
  • Zeitpunkt Rechnungsstellungen und Abnahme System
  • Mitwirkungspflichten Auftraggeber
    • Gerade bei vermeintlichen Randthemen wie z. B. Dokumentation, Tests, Schulungen sollte klar geregelt sein, was der Partner an Zuarbeit von Ihnen verlangen kann und darf.
  • Rechte an der programmierten Lösung
    • Überlassung Quellcode der programmierten Lösung
    • Bei notwendigen Anpassungen von Standardsoftware oder erstmaliger Erstellung eines Best Practice-/Branchenmodells mit entsprechenden höheren Anpassungskosten für Ihr Unternehmen lassen Implementierungspartner Sie als Referenzkunden/Entwicklungspartner auch an zukünftigen Vergütungen bei anderen Unternehmen aus diesem Branchenmodell teilhaben (Kick-Backs).

Der Projektaufbau: Klare Rollenverteilung der Partner

In allen Projektmanagementhandbüchern ist zu lesen, dass eine klare Definition der Rollen von essentieller Bedeutung für den erfolgreichen Projektabschluss ist. Trotzdem passiert es immer wieder, dass im Laufe des Projektes der interne Projektleiter selbst Tests im neues System durchführt, weil der zuständige KeyUser gerade mit dem Alltagsgeschäft beschäftigt ist und doch dringend eine Teilabnahme vom Partner gewünscht wird. Vermeiden Sie unter allen Umständen solche Situationen. Halten Sie zu Beginn des Projekts ein Kick Off Meeting mit allen internen und externen Beteiligten ab. Erstellen Sie eine Projektfibel, in der die Rollen und auch organisatorischen Details wie z. B. Stellvertretung, geplante Abwesenheit der Beteiligten, Termin-/Projektplan oder Pfade zu gemeinsam genutzten Laufwerken enthalten sind.

Folgende Gremien und Rollen sind sinnvoll:

  • Lenkungskreis
    • Besteht aus internem und externem Projektleiter und Sponsoren
    • Klärt Konflikte Auftraggeber und Auftragnehmer und verabschiedet Meilensteine
  • Interner Projektsponsor: Geschäftsführung bzw. Leitungsfunktion
    • Mitglied des Lenkungskreises
    • Trifft Entscheidungen z.B. zu Ablehnung Change Requests
    • Höchste Eskalationsstufe: klärt auftraggeberseitige Ressourcenkonflikte im Tagesgeschäft
  • Externer Projektsponsor: Leitungsfunktion des Implementierungspartners
    • Mitglied des Lenkungskreises
    • Trifft Entscheidungen
    • Höchste Eskalationsstufe: klärt auftragnehmerseitige Ressourcenkonflikte im Multiprojektmanagement
  • Interne Projektleitung (PL)
    • Mitglied des Lenkungskreises
    • Einhaltung Termin und Kosten, Sicherstellung der Zuarbeit von Seiten Auftraggeber, lässt ggf. Eskalieren
    • sammelt CR bzw. Zusatzanforderungen der KeyUser und stimmt diese mit ext. PL ab
    • pflegt Projektfibel
    • macht keine KeyUser Aufgaben
  • Externe Projektleitung (PL)
    • Mitglied des Lenkungskreises
    • Einhaltung Termin und Kosten, Sicherstellung der Zuarbeit von Seiten Auftragnehmer, lässt ggf. Eskalieren
    • Nimmt CR vom internen PL entgegen, kalkuliert Aufwand und stimmt diesen mit internen PL ab zwecks Freigabe
    • macht keine Programmierer Aufgaben
  • KeyUser
    • trägt Verantwortung für korrekte Prozessbeschreibung und definiert Anforderungen
    • beantragt CR bei internem Projektleiter
    • Testet System und nimmt dieses in seinem Bereich ab
  • Programmierer
    • Umsetzung Pflichtenheft
    • nimmt abgestimmte CR-Anforderungen vom externen PL entgegen
    • setzt nicht eigenmächtig Anforderungen der KeyUser um

Auch wenn es schmerzhaft ist und eine Lücke im betrieblichen Alltag erzeugen kann: Setzen Sie als interne Projektleitung keinen Mitarbeiter Ihrer EDV-Abteilung ein, sondern eine starke, meinungsbildende Persönlichkeit, die schon viel Erfahrung in Ihrem Unternehmen gesammelt hat und ein hohes Ansehen genießt. Ebenso sollten die KeyUser der jeweiligen Bereiche gestandene Persönlichkeiten und/oder erfahrene und ehrgeizige Personen der zweiten Reihe sein. Für jeden KeyUser und Projektleiter sollte eine Stellvertreterfunktion definiert sein.

(Robert Murmann, seniorprofis.de)

(Bildnachweis: © alphaspirit – Fotolia.com)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *


*

Hinweis:
Bitte beachten Sie unsere Blogregeln. Es besteht grundsätzlich kein Anspruch auf die Veröffentlichung Ihres Kommentars. Je nach Inhalt behalten wir uns vor, von einer Veröffentlichung abzusehen. Mit dem Absenden Ihres Kommentars stimmen Sie der Veröffentlichung auf dieser Website zu. Auf Wunsch des Absenders können Kommentare auch wieder gelöscht werden. Bitte senden Sie in diesem Fall eine E-Mail an den Administrator.