Methodik der ERP-Einführung für Großunternehmen und Holdinggesellschaften

Methodik der ERP-Einführung für Großunternehmen und Holdinggesellschaften

Für Großunternehmen und Holdings.

Diese Methodik ist für Migrationen von SAP und Oracle auf 1C konzipiert. Sie eignet sich auch für die Migration von älteren 1C-Systemen auf modernere (zum Beispiel von 1C:UPP auf 1C:ERP).

*Nicht geeignet für den öffentlichen Sektor und kleine Unternehmen.

Die meisten Einführungsprojekte scheitern, weil der Kunde die Notwendigkeit nicht versteht oder nicht bereit ist, dem Projekt ausreichend Zeit zu widmen und zügig daran mitzuarbeiten. Ein Team kann leider nicht einfach kommen, alles einrichten und wieder gehen. Der Kunde muss die Informationen liefern, Anpassungen vornehmen, die Ergebnisse testen, im Projektverlauf die wesentlichen Entscheidungen treffen und die abgeschlossenen Arbeiten abnehmen. Unsere Methodik ermöglicht es uns, das Projekt bis zum Ergebnis zu begleiten; der Kunde ist dabei in jeder Phase eingebunden, bleibt informiert und kann den Prozess beeinflussen – und erhält so genau das, was er wollte.

Jedes Projekt muss Termine und Budget einhalten und seine Ziele erreichen.

Das Ziel jedes Kunden ist es,

1) termin- und budgetgerecht auf das neue System umzusteigen,

2) die zentralen, geschäftskritischen Prozesse ohne Effizienzverlust zu erhalten,

3) kundenspezifische Anpassungen im neuen System auf ein Minimum zu beschränken, da sie immer zusätzliche Entwicklungs- und spätere Supportkosten bedeuten.

Die Einführung eines neuen Systems ist in erster Linie Beratung. Früher wurden Einführungen von Entwicklern getragen, heute leisten Analysten den Großteil der Arbeit. Je besser die Analyse, desto weniger kundenspezifische Anpassungen sind nötig.

Zentrale Projektaufgaben:

Phase 1: Konzeption.

- Die aktuellen Geschäftsprozesse des Unternehmens analysieren und dokumentieren, damit Implementierungspartner und Kunde ein gemeinsames Bild aller Prozesse haben.

- Diese Prozesse im neuen System abbilden. Dazu nehmen wir reale Dokumente und Prozesse und versuchen, sie im neuen System nachzubilden. Wir führen dem Kunden eine Demo vor und halten auf Grundlage der Ergebnisse die „Engpässe“ (funktionalen Lücken) fest, die einen korrekten Betrieb des Systems verhindern würden.

Müssen Daten aus dem Altsystem in das neue System übernommen werden, ist der Umfang der zu migrierenden Daten abzustimmen, und es sind Migrationswerkzeuge zu entwickeln.

Phase 2: Entwicklung.

Sobald kritische Lücken identifiziert sind, entwickeln wir Lösungen und stimmen sie mit dem Kunden ab. Dabei zeigen wir ihm jede Woche die Ergebnisse unserer Arbeit, damit er versteht, was er bekommt, und die Entwicklung auch mitsteuern kann.

Phase 3: Pilotbetrieb.

Ein häufiges Problem: Die Entwicklung ist abgeschlossen und die Daten sind geladen, aber das System funktioniert wegen Fehlern nicht. Deshalb sind umfassende Tests nötig.

Wir führen 3 Arten von Tests durch:

Interner Test: ein vollständiger Durchlauf des Systems (End-to-End) im eigenen Haus unter Leitung der technischen und funktionalen Architekten.

Externer Test: derselbe Durchlauf, diesmal gemeinsam mit dem Kunden. Zu diesem Zeitpunkt kann der Kunde Anpassungen anfordern.

Abnahmetest: Wir bereiten Schritt-für-Schritt-Testfälle vor, und der Kunde durchläuft den gesamten Prozess selbstständig, um die Funktionsweise des Systems zu prüfen.

Auf Grundlage der Ergebnisse beheben wir Fehler, erstellen Benutzerhandbücher und schulen die Mitarbeiter.

Phase 4: Produktivbetrieb.

Nach dem Produktivstart (Go-live) begleiten wir das Projekt stets noch 3–6 Monate, bis sich die Mitarbeiter an das System gewöhnt haben.

Alle Projektinformationen (Pläne, Terminpläne, Ziele und Ergebnisse) stellt man dem Kunden am besten als Präsentation vor. So bekommt der Kunde einen ersten Eindruck vom Ergebnis. Kunden machen sich meist nicht bewusst, dass auch sie bestimmte Arbeiten leisten müssen. Eine Präsentation macht das deutlich.

Die Einführung kann nicht allein dem Team des Implementierungspartners überlassen werden. Indem wir den Umfang der gemeinsamen Arbeit aufzeigen, legen wir faktisch die Regeln fest, von denen der Projekterfolg abhängt. Unten finden Sie eine Tabelle, die zeigt, wie die Mitarbeiter des Kunden eingebunden sind.

Der Projektsponsor genehmigt die endgültigen Entscheidungen, stellt das Budget bereit und nimmt das Projekt insgesamt ab.

Der Projektleiter übernimmt die Administration des gesamten Projekts. So hat der Implementierungspartner beispielsweise keine Weisungsbefugnis im Unternehmen des Kunden, deshalb wird ein interner Projektleiter benötigt, der von seinen Mitarbeitern die erforderliche Disziplin einfordern kann.

Key-User sind die Verantwortlichen für die wichtigsten Bereiche, für die wir das System einführen. In der Regel sind das Abteilungsleiter. Bei der Einführung des Finanzmoduls ist das zum Beispiel der CFO, und so weiter.

Experte für das System, aus dem wir migrieren. Das ist ein technischer Spezialist, der die Daten im bestehenden System für die Migration in das neue aufbereitet.

IT-Spezialisten, die mit externen Systemen arbeiten, die erforderlichen Zugriffe einrichten, interne Tools bereitstellen und die notwendigen Serverarbeiten durchführen.

Bei der Einführung müssen wir stets Termine und Budget einhalten. Meist möchte man jedoch das über viele Jahre angepasste Altsystem vollständig in das neue übertragen und dabei neue Anforderungen hinzufügen – mit anderen Worten: aus 1C ein SAP machen. Seien wir aber realistisch: Was über viele Jahre und mit riesigen Budgets aufgebaut wurde, lässt sich nicht in sechs bis zwölf Monaten nachbilden. In solchen Fällen übersteigen die Kosten für kundenspezifische Anpassungen das Budget um das 3- bis 4-Fache.

Wie entscheidet man also, was zu tun ist, um im Budget zu bleiben?

So lösen wir diesen Konflikt.

Wir schlagen vor, alle Geschäftsprozesse nach ihrer Kritikalität zu ordnen.

• Hoch: Prozesse, ohne die das Unternehmen „zusammenbricht“ und nicht arbeiten kann.
• Mittel: Prozesse, deren Fehlen die Arbeit verlangsamt.
• Niedrig: Wunschlisten-Punkte, Komfortfunktionen und wünschenswerte Verbesserungen (Nice-to-have).

Das Budget deckt in der Regel die Prozesse mit hoher Priorität und einen Teil der Prozesse mit mittlerer Priorität ab. Punkte mit niedriger Kritikalität werden auf die spätere Weiterentwicklung des Systems verschoben.

Unsere Erfahrung zeigt: Man kann die Einführung termin- und budgetgerecht abschließen, wenn man die Punkte mit hoher und mittlerer Priorität umsetzt. Zum Produktivstart sind jedoch in der Regel nur die hochkritischen Punkte umgesetzt. Erst nach dem Produktivstart wird das System weiter verfeinert – ein Jahr, zwei oder sogar 10 Jahre lang.

Wenn man versucht, alles auf einmal zu machen, gerät das Projekt ins Stocken, und wir halten weder den Zeitplan noch das Budget ein.

Deshalb gehen wir in dieser Reihenfolge vor:

1. zuerst die Punkte mit hoher Priorität umsetzen;
2. die Punkte mit mittlerer Priorität im Produktivbetrieb abschließen;
3. danach das System bei Bedarf über Jahre weiter verfeinern.

Dieses schrittweise Vorgehen bietet die besten Chancen, das gewünschte Ergebnis zu erreichen.

Unsere zehnjährige IT-Erfahrung hat uns geholfen, eine Methodik zu entwickeln, die die zentralen Projektfragen beantwortet: wie sich die Automatisierung termin- und budgetgerecht, mit minimalen kundenspezifischen Anpassungen und unter Erhalt der kritischen Geschäftsprozesse und der Effizienz einführen lässt.

ERP-Fallstudien