ERP-Backsourcing

Aus Winfwiki

Wechseln zu: Navigation, Suche
Name des Autors / der Autoren: Markus Hemp (Matr.-Nr. 224724), Daniel Lübke (Matr.-Nr. 235505), Sven-Erik Pannek (Matr.-Nr. 219425)
Titel der Arbeit: ERP-Backsourcing
Hochschule und Studienort: FOM Berlin
Semester: 5. Fachsemester
Betreuer: Prof. Dr. Vladimir Stantchev


Inhaltsverzeichnis

1 Einleitung

1.1 Motivation

Im Studienfach "ERP-Systeme" haben die Studenten Daniel Lübke und Markus Hemp bereits umfassend das Thema des ERP-Outsourcings behandelt. Es wurde eine Analyse der strategischen Überlegungen zur Auslagerungsentscheidung der ERP-Abteilung eines Unternehmens durchgeführt. Es ist der Wunsch entstanden, diesen Themenkomplex weitergehend zu behandeln und anhand einer praktischen Betrachtung den entgegen gerichteten Prozess, das Backsourcing, im Rahmen des ERP-Systembetriebs zu untersuchen.

Strategisches Sourcing gewinnt in Unternehmen zunehmend an Relevanz. Gerade im Bereich der IT führen die Komplexität der Materie und die hohe Priorität des effektiven Betriebs dazu, dass hochspezialisiertes Fachpersonal für den entscheidenden unternehmerischen Vorteil am Markt notwendig wird. Bei gleichzeitig notwendigen Kostensenkungs- und Effizienzsteigerungsprogrammen entsteht ein Zielkonflikt, den es soweit wie möglich aufzulösen gilt. Die Entscheidung zu "Make-or-Buy" muss getroffen werden.

Die Autoren der vorliegenden Arbeit beobachten zudem einen gewissen Zyklus am Markt. Unternehmen treffen Entscheidungen zum Outsourcing und holen später die ausgelagerten Geschäftsbereiche wieder zurück. Es gibt Outsourcing-Programme, die scheitern oder aus mannigfaltigen Gründen abgebrochen werden. Auch Unternehmen, zu denen die Autoren Kontakt haben, sind von diesen Entscheidungen betroffen. Dies hat das Interesse an dem Themengebiet zusätzlich bestärkt. Es macht den Anschein, das Thema des Sourcings sei sehr dynamisch und die Entscheidungen passten sich den wechselnden Markt- und Wettbewerbsbedingungen an.

Das Fach "ERP-Technologie" bietet nun die ideale Grundlage, diesen Themenkomplex näher zu beschreiben und zu verstehen. Es entstand der Wunsch, eine praxisbezogene und realistische Untersuchung des Zurückholens des ERP-Betriebs ins eigene Unternehmen durchzuführen und ein Vorgehensmodell dieses Prozesses zu entwickeln. Des Weiteren soll die vorliegende Arbeit die logische Weiterführung der Überlegungen der Arbeit im vorangegangenen ERP-Seminar darstellen.

1.2 Ziel

Ziel dieser Arbeit ist es, eine umfassende Betrachtung einer konkreten strategischen Backsourcing-Entscheidung anzustellen. Dabei knüpft das Thema direkt an die theoretische Betrachtung der Arbeit "ERP-Outsourcing - Fluch oder Segen?"[1] an. Es sollen ebenso die Gründe für das Zurückholen des ERP-Betriebs und die Erbringung der Leistung aus dem eigenen Unternehmen heraus betrachtet werden. Im Rahmen dieser Überlegung dürfen die Risiken dieses Prozesses nicht ignoriert werden und finden daher in dieser Arbeit ebenfalls Anerkennung. An einem konkreten Szenario soll beschrieben werden, welche Aspekte bei einem Backsourcing-Projekt zwingend zu beachten sind, sowie welche Aufwände für ein erfolgreiches Projekt und den späteren Betrieb zu kalkulieren und welche Voraussetzungen zu schaffen sind.

Ein weiteres Ziel ist die Erprobung des Rational Unified Process (RUP) Vorgehensmodells aus der Softwareentwicklung an einem Integrationsprojekt wie dem Backsourcing der ERP-Lösung. Die Verfasser der vorliegenden Arbeit möchten das phasenweise Vorgehen aus RUP konsequent an die Anforderungen des Backsourcing-Prozesses anpassen und zeigen, wie sich solch ein bewährtes Vorgehensmodell auch auf andere Projekte als die Softwareentwicklung anwenden lässt und welche Mehrwerte daraus generiert werden können.

1.3 Abgrenzung

Ganz offensichtlich betrachten wir in dieser Arbeit den Prozess des Backsourcings im Rahmen einer ERP-Abteilung. Gleichzeitig wollen wir keine theoretische Betrachtung unter Zuhilfenahme theoretischer Modelle durchführen, sondern ein konkretes Vorgehen beschreiben, welches realistisch die zuvor von extern bezogenen Leistungen des ERP-Systems einer Unternehmung "zurück holt".

Ebenfalls soll in dieser Arbeit keine Diskussion hinsichtlich der Entscheidung zum Backsourcing erfolgen. Dieses Thema wurde bereits ausführlich in der Arbeit "ERP-Outsourcing - Fluch oder Segen?" erörtert und soll hier nicht erneut Beachtung finden. Vielmehr wird von einer bereits getroffenen Entscheidung ausgegangen, ohne auf den Prozess der Entscheidungsfindung einzugehen.

1.4 Methodisches Vorgehen

Unser methodisches Vorgehen sieht aufgrund der praxisbezogenen Art dieser Arbeit einen pragmatischen Ansatz vor. Neben Fachliteratur zum Stützen unserer Erkenntnisse liegt das Augenmerk auf logischen Schlüssen, die sich aus den konkreten Annahmen des vorliegenden Szenarios ableiten. Der Fokus liegt auf den Ergebnissen, welche Aspekte im Backsourcing-Prozess beachtet werden müssen.

2 Grundlagen

2.1 ERP

Enterprise-Resource-Planning-Systeme (ERP, „Planung [des Einsatzes/der Verwendung] der Unternehmensressourcen“) sind betriebswirtschaftliche Softwarelösungen, welche die Funktionen aus verschiedenen Bereichen eines Unternehmens abbilden und sich dadurch auszeichnen, dass sie zahlreiche operative und dispositive Geschäftsprozesse in einer zentralen Datenbank, in der auch Stammdaten von Kunden und Lieferanten, Materialien oder Konditionen zur Nutzung abgelegt sind, abbilden und zwischen den verschiedenen Geschäftsprozessen ein hoher Grad der Integration besteht.[2] Mit den Funktionen eines ERP-Systems ist eine unternehmensweite Planung, Steuerung und Kontrolle möglich.[3]

Abbildung 1: ERP-Konzept
Abbildung 1: ERP-Konzept[4]
Die nebenstehende Grafik zeigt das Zusammenspiel der verschiedenen Module innerhalb der zentralen Datenbank auf. Durch die überaus hohe Integration der einzelnen Module lassen sich komplexe Prozesse innerhalb der Unternehmensstruktur sehr gut programmseitig abbilden. Zudem können beispielsweise die Fakturierung und Aktualisierung der Unternehmensstatistiken automatisiert erfolgen und etwa die Datenbanken eines „Business Intelligence“ Systems füllen.

Innerhalb eines ERP-Systems gibt grundsätzlich zwei verschiedenen Arten von Daten: Stamm- und Bewegungsdaten.[5] Stammdaten beinhalten beispielsweise Informationen zu Kunden, Fertigungsorten oder Mitarbeitern. Bewegungsdaten dagegen werden erst bei der Auftragsabwicklung generiert. Dies impliziert eine Fülle von Vorgängen. Bewegungsdaten entstehen beim gesamten Wertschöpfungsprozess, von der Bestellung über den Einkauf, die Produktion und den Vertrieb.

In jedem ERP-System ist ein sehr fein granulares Berechtigungskonzept implementiert, mit dem den Nutzern verschiedene Berechtigungen zugewiesen werden können. Üblicherweise werden diese Berechtigungssätze in Rollen zusammengefasst, die dann den verschiedenen Benutzern zugewiesen werden können.

Für Unternehmen stellt das ERP-System häufig das Rückgrat dar. Alle unternehmenskritischen Informationen sind in diesem System hinterlegt, daher ist es unerlässlich, dass dieses System zuverlässig vor Kompromittierung oder Datenverlust (Hardwareschaden, böswilliges Verändern oder Löschen) geschützt wird. Dies ist typischerweise eine der Kernaufgaben einer ERP-Abteilung. Diese stellt neben der Datensicherheit auch die Weiterentwicklung des Systems, die Betreuung der Anwendungslandschaft und den Mitarbeitersupport sicher. Die vielfältigen Aufgaben, die eine ERP-Abteilung zu erfüllen hat, machen es unerlässlich, dass dort nur entsprechende Spezialisten tätig sind, um die Systemsicherheit und damit die Produktivität des Unternehmens zu gewährleisten.

2.2 Was ist Backsourcing?

Während beim Outsourcing interne Dienstleitungen an einen externen Provider ausgelagert wurden, werden beim Backsourcing nun genaue diese Dienste ins Unternehmen zurückgeholt, also wieder intern erbracht. Es findet ein Wechsel von der Fremd- zurück zur Eigenerstellung statt. Es wird zwischen dem selektiven und totalen Backsourcing differenziert. Letzteres beschreibt die Zurückholung aller extern erbrachten Dienstleistungen, das selektive Backsourcing hingegen besschreibt die Wiedereingliederung einzelner, ausgewählter Prozesse.

Die Bedeutung des Begriffs Insourcing wird oftmals fälschlicherweise mit der des Begriffs Backsourcing gleichgesetzt. Insourcing steht jedoch für die Eingliederung von bisher extern erbrachten Dienstleistungen. Der Unterschied zum Backsourcing ist, dass die Dienste zuvor nie im Unternehmen selbst betrieben wurden, also erstmalig eingegliedert werden.[6][7]

Der Prozess des Backsourcings bedeutet für Unternehmen eine enorme Herausforderung, da sich dieses an zahlreichen Stellen auswirkt. Prozesse beispielsweise im Support oder dem Verkauf müssen ebenso Berücksichtigung finden wie die Compliance der zurückzuholenden Leistungen. Zudem beinhaltet dies Anpassungen bei Personal, einzusetzenden Technologien und Geschäftsprozessen.[8]

Das Backsourcing ist stets eine strategische Unternehmensentscheidung und sollte daher auch entsprechend tief im Unternehmen verankert sein. Über alle Managementebenen müssen die Mehrwerte kommuniziert werden, um diese geplante Strategie nicht durch eine der zahlreichen Risiken zu gefährden.

2.3 Gründe

Gründe, warum Unternehmen die Dienstleistungen nach vorheriger Auslagerung wieder in den eigenen Betrieb integrieren wollen, gibt es viele. Im Nachfolgenden werden einige der Beweggründe aufgelistet:[9][10][7][11][12][13][14]

  • Durchführung einer Restrukturierung und Schrumpfung der Unternehmensprozesse, sodass die Aufwände wieder mit internen Ressourcen bewältigt werden können.
  • Reduktion des Einsatzes teurer, externer Mitarbeiter. Die Aufgaben werden vermehrt auf die eigenen Mitarbeiter übertragen.
  • Wirtschaftliche Schwierigkeiten oder gar die Insolvenz des Providers. Dem Unternehmen bleibt in diesem Fall nur ein Providerwechsel oder das Backsourcing.
  • Kontrollverlust: Die Unternehmen sind darauf bedacht, eine möglichst weitgehende Kontrolle über wichtige Ressourcen zu haben.
  • Fehlende Flexibilität: In vielen Auslagerungsverträgen basiert die Flexibilität auf der Annahme, dass die Nachfrage nach den Services des Anbieters steigt. Geht sie jedoch zurück, kann der Provider nicht einfach die IT-Stückkosten konstant halten. Er muss auf den mit dem Auftraggeber vereinbarten Abnahmeverpflichtungen bestehen, um nicht in die Verlustzone zu geraten.
  • Bei dem Verkauf eines Unternehmens, kann es sein, dass der Käufer eine Backsourcing-Strategie verfolgt. Auch dann wird ein Backsourcing erforderlich.
  • Manche Unternehmen haben ihr Outsourcing aus rein taktischen Gründen und zeitlich begrenzt realisiert, um unter anderem kurzfristige Finanzeffekte oder einen Know-how-Transfer in einem wichtigen Bereich zu erzielen. Dabei kann ein späteres Backsourcing schon zu Beginn des Outsourcing-Vorhabens geplant worden sein.
  • Fehlende Flexibilität des Providers bei sich verändernden Zielen des Unternehmens. Im Laufe der Jahre können sich die Prozesse ändern. Kann der Provider sich nicht darauf einstellen, führt dies zum Scheitern des Projektes.
  • Viele Outsourcing-Projekte scheitern auch an Kommunikations- und Verständnisproblemen zwischen den Vertragspartnern.
  • Keine Kostenreduktion und ungeplante Mehrkosten. Viele Projekte sind deutlich teurer als erwartet und bringen somit nicht die gewünschten Ersparnisse.
  • Ungenügende Planung. Das Management eines Unternehmens versucht oft, ein Outsourcing möglichst schnell zu realisieren – entsprechend groß ist der Zeitdruck in der Vorbereitung.
  • Der Kostenvorteil ist durch gestiegene Löhne in den beliebten Outsourcing-Regionen deutlich geringer geworden.
  • Mangelnde Qualität: Die Qualität der vom Provider erbrachten Dienstleistungen ist nicht zufriedenstellend.
  • Technischer Fortschritt. Themen wie Cloud-Computing werden immer populärer. Die Unternehmen können durch Software-as-a-Service-Angebote die Aufwände in der IT gering halten.
  • Kosten für einen Anbieterwechsel: Unternehmen, die mit dem aktuellen Partner unzufrieden sind haben die Möglichkeit, den Anbieter zu wechseln. Dieser Wechsel ist jedoch häufig sehr kostenintensiv, so dass die Unternehmen ein Backsourcing vorziehen.
  • Inkompetenz des Anbieters

2.4 Rational Unified Process

Der Rational Unified Process (RUP) ist ein objektorientiertes, aktivitäts-getriebenes Vorgehensmodell zur Entwicklung von Anwendungen. Das RUP-Modell ist eine Best-Practices-Sammlung, die als Vorgehensmodell des Software-Engineering konzipiert ist.[15] RUP selbst ist in der Modellierungssprache UML (Unified Modeling Language) beschrieben. Das RUP-Modell berücksichtigt die wesentlichen Aspekte der Softwareimplementierung und legt einen Fokus auf die Definition des Projektumfangs sowie die Planung und Spezifikation der zu implementierenden Softwarekomponenten.

Die vorliegende Grafik zeigt die vier Projektphasen des RUP auf sowie die Einstiegs- bzw. Abschlussphase inklusive der Hypercare (Support) Phase.

Abbildung 2: Die vier Phasen nach RUP
Abbildung 2: Die vier Phasen nach RUP[16]

Folgende Phasen sind im Vorgehensmodell implementiert:[17]

  • Konzeptionsphase (inception phase)
    • In der Konzeptionsphase wird die Vision des durchzuführenden Projektes festgelegt und der generelle Rahmen der Durchführung definiert. [18] Auch müssen die Projektrisiken identifiziert werden. In dieser Phase wird im Wesentlichen gedankliche Arbeit geleistet.
  • Entwurfsphase (elaboration phase)
    • In der Entwurfsphase (elaboration phase) werden die Zieleigenschaften festgelegt, die Systemarchitektur entworfen sowie die Aktivitäten der folgenden Phasen spezifiziert und die benötigten Ressourcen definiert.[19]
  • Konstruktionsphase (construction phase)
    • In der Konstruktions- oder Entwicklungsphase (construction Phase) findet die eigentliche Produktentwicklung bzw. Projektumsetzung statt. [18] Das Ergebnis dieser Phase, die neben der Implementierung auch die Verifikation der ordnungsgemäßen Funktionalität beinhaltet, ist ein funktionstüchtiges übergabefähiges Produkt.
  • Übergabephase (transition phase)
    • In der Übergabephase finden alle administrativen Tätigkeiten statt, die notwendig sind, um das finale Produkt beim Kunden in Betrieb zu nehmen. Dies inkludiert natürlich auch Schulungen und die Dokumentationen.[19]

Bis auf die Konzeptionsphase handelt es sich bei allen Phasen um iterative Phasen. Einzelne Schritte in diesen Phasen können bei Bedarf, also wenn das Ergebnis noch nicht zufriedenstellend ist, wiederholt werden. Die Ergebnisse dieser einzelnen Phasen stellen für die Projektplanung Meilensteine dar: [17]

  • Lifecycle Objectives
    • Der erste Meilenstein stellt eine Vision dar, in der die wesentlichen Funktionalitäten der zu erstellenden Software (oder des durchzuführenden Projektes) definiert werden. Daraus lässt sich ein Anwendungsfallmodell ableiten. Bereits in dieser Phase sollten die verschiedenen Projektrisiken identifiziert werden und mit entsprechendem Risikomanagement minimiert werden.
  • Lifecycle Architecture
    • Mit Erreichen dieses Meilensteins wird eine detaillierte Arbeitsplanung für die folgende Konstruktionsphase verlangt, aus der sich einzelne Arbeitspakete ableiten lassen. Zudem ist das initiale Anwendungsfallmodell weiter zu verfeinern.
  • Initial Operational Capability
    • Mit Erreichen dieses Meilensteins steht eine erste funktionsfähige Version der zu entwickelnden Software (Beta-Version, Testversion) zur Verfügung. Auf das Backsourcing-Projekt adaptiert, welches im Folgenden betrachtet wird, bedeutet dies eine funktionsfähige, aber noch nicht fehlerfreie ERP-Umgebung, mit der finale Funktionstests und Fehlerkorrekturen durchgeführt werden können.
  • Product Release
    • Der Product Release stellt die Veröffentlichung der finalen Version der erstellten Software dar. Bei dieser Version handelt es sich um eine marktfähige und verkaufsfähige Softwarelösung. Bei der Übertragung auf das Backsourcing werden in dieser Phase alle Aktivitäten zusammengefasst, die sich mit der Produktivschaltung beschäftigen. Das Ergebnis ist in diesem Fall das „Going-Live“ des ERP-Systems und die produktive Nutzung dieser Umgebung.

Die einzelnen Phasen und deren Iterationen werden matrixartig von Arbeitsprozessen überlagert. Dabei werden Kern-Arbeitsprozesse (Core Workflow)

  • Geschäftsprozessmodellierung (Business Analysis / Business Modeling)
  • Anforderungsmanagement (Requirements)
  • Analyse und Design (Analysis & Design)
  • Implementierung (Implementation)
  • Test
  • Verteilung (Deployment)

und unterstützende Arbeitsprozesse (Core Supporting Workflow)

  • Konfigurationsmanagement und Änderungsmanagement (Configuration & Change Management)
  • Projektmanagement (Project Management)
  • Entwicklungsumgebung (Environment)

unterschieden.[17]

Die vorliegende Grafik zeigt die vier Projektphasen des RUP auf sowie die unterstützenden Prozesse und die entsprechenden Aktivitäten innerhalb dieser Prozesse und Phasen.

Abbildung 3: Phasen und Arbeitsprozesse des RUP-Modells
Abbildung 3: Phasen und Arbeitsprozesse des RUP-Modells[20]

Im Rahmen dieser Arbeit soll der Fokus weniger auf den Arbeitsprozessen von RUP oder dem Notationssystem UML liegen. Vielmehr sollen das Vorgehensmodell und die dynamischen Aspekte der Projektphasen des RUP dazu genutzt werden, das Backsourcing-Projekt systematisch und koordiniert durchzuführen. Die einzelnen Phasen nach dem RUP können sehr gut adaptiert werden, um dieses Projekt gestützt durch ein bewährtes Verfahrensmodell durchzuführen.

3 Szenario

Das nachfolgende Szenario ist als fiktiv zu betrachten und soll einen Größenordnungsrahmen darstellen. Dies ist notwendig, da eine pauschale Skalierung nicht trivial und ein definiertes Szenario zudem greifbarer als eine theoretische Abhandlung ist.

3.1 Beschreibung des Ist-Zustandes

In dem für diese Seminararbeit definierten Szenario wird das mittelständische Unternehmen AluXY GmbH mit 250 Mitarbeitern betrachtet. Der Betriebszweck des in der Metallbranche ansässigen Unternehmens ist die Produktion von hochspezialisierten Aluminiumrohren. Die vorangegangene Wirtschaftskrise hat AluXY unbeschadet überstanden und konnte sogar von ihr profitieren. Momentan befindet sich die Firma im Wachstum.

Die EDV der AluXY GmbH ist historisch gewachsen und heterogen. Die ERP-Prozesse wurden bei der Unternehmensgründung noch intern betrieben. Sie wurden jedoch vor einigen Jahren an einen externen Dienstleister ausgelagert, mit der Hoffnung auf Kosteneinsparungen, einer Steigerung der IT-Effizienz und einer bessere Servicequalität. Der regionale Outsourcing-Dienstleister setzt eine ERP-Standardlösung ein, welche sich jedoch gerade bei speziellen Kundenwünschen als unflexibel und träge herausgestellt hat. Die AluXY GmbH ist inzwischen nicht mehr zufrieden mit der Qualität der erbrachten Dienstleistungen und der aktuellen ERP-Lösung.

Aus dieser Unzufriedenheit heraus ist die Idee entstanden, durch eine Harmonisierung der IT-Infrastruktur eine Maximierung der Wertschöpfung durch IT-gestützte Geschäftsprozesse zu erreichen.

3.2 Zieldefinition

Das Ziel ist es, den Marktvorteil durch Backsourcing des ERP-Systems auszubauen.

Hierzu soll ein zuvor evaluiertes ERP-System bei der AluXY GmbH implementiert werden. Die abgeschlossene Evaluierung des ERP-Systems wird in dieser Seminararbeit vorausgesetzt. Durch die Eingliederung der ERP-Prozesse zurück ins Unternehmen werden mehrere Ziele verfolgt. Dazu gehört unter anderem der Schutz des geistigen Eigentums des Unternehmens, welches meist einen sehr hohen immateriellen Wert darstellt. Weiterhin sollen die speziellen Kundenwünsche, die durch die ERP-Standardlösung des externen Dienstleisters nur unzureichend erfüllt werden konnten, durch eine bessere Geschäftsprozessabbildung bestmöglich realisiert werden. Zudem soll eine deutlich schnellere Reaktionszeit für Systemanpassungen erreicht werden.

3.3 Sollkonzept

Zur Realisierung des Backsourcings wurde von der AluXY GmbH ein grobes Solllonzept erstellt, welches die grundlegenden zu erreichenden Ziele festlegt.

Zum Betrieb des ERP-Systems im Unternehmen ist die Einrichtung eines internen Rechenzentrums essentiell. Dazu soll beispielsweise ein komplett neuer Serverraum eingerichtet sowie Speichersysteme, Archiv- und Backuplösungen etabliert werden. Insgesamt soll die IT-Infrastruktur für einen effizienten Einsatz harmonisiert werden.

Einen wichtigen Bestandteil des Soll-Konzepts stellt die Implementierung des evaluierten ERP-Systems dar. Die Basisinstallationen des ERP-Systems werden an die individuelle Unternehmensstruktur angepasst. Hierbei soll eine Maximierung der IT-Unterstützung, Integration und Automatisierung erreicht werden. Es soll möglichst viel im ERP-System abgebildet werden.

Weiterhin müssen im Unternehmen die organisatorischen Strukturen für den ERP-Betrieb geschaffen werden. Dazu gehört die Schaffung bzw. Definition von Prozessen, des Personals und der Technik. Die bestehenden extern betriebenen Prozesse müssen migriert werden. Zusätzlich besteht die Notwendigkeit, Supportprozesse zu definieren und zusätzliche individuelle Prozesse zu implementieren. Auch Arbeitsabläufe sollen automatisiert werden. Beim Personal werden verschiedene Rollen wie z.B. ein Basis-Admin, ein Sicherheitsverantwortlicher und ein Architekt geschaffen.

3.4 Projektumsetzung

Die Planung und Ausgestaltung der Projektumsetzung soll einem bewährten methodischen Vorgehen folgen. Wir wählen hierzu das Rational Unified Process (RUP) - Modell aus der Softwareentwicklung, da dieses die wesentlichen Aspekte der Softwareimplementierung berücksichtigt und einen Fokus auf die Definition des Projektumfangs sowie die Planung und Spezifikation der zu implementierenden Softwarekomponenten legt. Wir konzentrieren uns hierbei weniger auf die unterstützenden Softwarekomponenten zu RUP und das Notationssystem UML, sondern nutzen vielmehr das Vorgehensmodell und die dynamischen Aspekte der Projektphasen des RUP. Diese Projektphasen sind die Folgenden und werden in den kommenden Kapiteln hinsichtlich dieses ERP-Projekts detailliert beschrieben:

  • Konzeptionsphase (inception phase)
  • Entwurfsphase (elaboration phase)
  • Konstruktionsphase (construction phase)
  • Übergabephase (transition phase)

Auf die einzelnen Arbeitsprozesse, die diese Phasen überlagern, wird nicht im Detail eingegangen. Dies würde zum einen den Rahmen dieser Arbeit zum einen übersteigen und zum anderen wäre dies an dieser Stelle nicht zielführend.

3.4.1 Konzeptionsphase

Die Konzeptionsphase innerhalb des RUP soll hauptsächlich das Ziel und den Umfang des Projekts definieren. Auf dieser Basis werden Budgetplanung, Use Case-Modelle, Projektpläne sowie Erfolgsfaktoren festgelegt und mit den Stakeholdern abgestimmt. Hauptsächlich die Definition und Modellierung der zu unterstützenden Geschäftsprozesse sowie die beginnende Anforderungsanalyse stehen im Fokus der Aktivitäten. Wir empfehlen zudem die Definition eines Mottos für das Projekt. Dieses soll die Identifikation und Motivation der Mitarbeiter unterstützen sowie das Kernziel des Projekts umschreiben.

An diesem Punkt ist die Konzeptionsphase durch die Festlegung des Sollkonzepts und die Abgrenzung der Projektaktivitäten bereits abgeschlossen. Das Ziel war schon im Vorfeld festgelegt. Es empfiehlt sich jedoch, die konkreten Projektziele und Abgrenzung zu anderen Aktivitäten oder Projekten an dieser Stelle vorzunehmen. Dies stellt sicher, dass im weiteren Projektverlauf keine Fragestellungen hinsichtlich Abhängigkeiten, Verantwortlichkeiten und Aufgabenpaketen aufkommen. Das Projektteam kann mithilfe dieser schriftlichen Fixierung jederzeit potenziellen Dead-Lock-Situationen aus dem Weg gehen.

3.4.1.1 Das Projektmotto

Das folgende Motto wurde für das Projekt festgelegt:

'Wir bauen ein zukunftssicheres ERP-System für den nachhaltigen Wettbewerbserfolg unseres Unternehmens'

Die Begriffe "zukunftssicher", "nachhaltig" und "Wettbewerbserfolg" stehen hier als Erfolgsfaktoren des Projekts. Sie sollen unterstreichen, dass das ERP-System sowohl skalierbar als auch leistungsstark für das stetige Wachstum des Unternehmens ausgelegt sein soll. Nachhaltig, im Sinne von langfristig und beständig, soll durch Optimierung, Integration und Harmonisierung der IT-unterstützten Prozesse ein Vorteil am Markt erreicht werden, sodass sich die AluXY GmbH gegenüber ihren Wettbewerbern behaupten und absetzen kann.

Dieses Motto soll verdeutlichen, dass die Projektteammitglieder für einen wesentlichen strategischen Schritt zur Unterstützung der Geschäftsprozesse durch das zu implementierende ERP-System verantwortlich sind und die Bedeutsamkeit ihrer Leistung für den langfristigen Unternehmenserfolg klarer machen.

3.4.1.2 Die Projektziele

Die folgenden Projektziele wurden identifiziert:

  • Aufbau einer Plattform zum Inhouse-Betrieb der zukünftigen ERP-Lösung
  • Aufbau der ERP-Lösung und Customizing gemäß den Geschäftsprozessen
  • Aufbau geeigneter Supportprozesse und einer Organisation zur schnellen und flexiblen Reaktion auf sich ändernde Marktanforderungen

Des Weiteren gilt als Ziel, dass der Schutz des geistigen Eigentums des Unternehmens erhöht werden soll. Dies geschieht allein dadurch, dass die ERP-Lösung wieder aus der Unternehmung heraus betrieben wird. Die hochspezialisierten und einzigartigen Produktionsverfahren der AluXY GmbH gelten als einer der wesentlichen Erfolgsfaktoren des Unternehmens.

3.4.1.3 Projektabgrenzung

Es wurde eine Abgrenzung von weiteren Projektaktivitäten, die zum Zeitpunkt der Implementierung der ERP-Lösung stattfinden, vorgenommen. Diese sind insbesondere folgende:

  • Einrichtung des internen Rechenzentrums
  • Harmonisierung der IT-Infrastruktur und Anpassung von Drittsystemen

Zu diesen Punkten zählen neben dem Aufbau eines Rechenzentrums gemäß der Anforderungen des BSI-Grundschutzkatalogs der Austausch von Netzwerkkoppelelementen zur Umsetzung eines umfangreichen Sicherheitskonzepts, der Aufbau einer Virtualisierungsplattform für die schnelle Bereitstellung neuer Rechenressourcen sowie die Etablierung einer sicheren Archiv- und Backuplösung. Diese Aktivitäten sind vielmehr als Abhängigkeiten zu identifizieren, da sie die notwendigen Voraussetzungen für den sicheren Betrieb der ERP-Lösung darstellen.

Des Weiteren kann die Anpassung aller betriebenen Drittsysteme nicht Teil dieses Projektes sein, da hier zum Teil Spezialwissen vonnöten sein wird, um erforderliche Änderungen vorzunehmen. Das ERP-System wird jedoch Schnittstellen bereitstellen, um diese Drittsysteme komfortabel gemäß Industriestandards in die Geschäftsprozesse einzubinden.

3.4.2 Entwurfsphase

Die Entwurfsphase dieses Integrationsprojektes dient der Definition der unterschiedlichen Teilaufgaben und derer Zieleigenschaften. Hierzu gehört auch der Entwurf der Zielarchitektur hinsichtlich der ERP-Lösung und auch der ERP-Organisation.

Ziel ist es, die Aktivitäten der nachfolgenden Phasen zu spezifizieren, zu strukturieren und die benötigten Ressourcen zu definieren. Es finden in dieser Phase alle Vorüberlegungen und Vorbereitungen statt, sodass innerhalb der Konstruktionsphase die festgelegten Aktivitäten durchgeführt werden können.

Die nachfolgenden Abschnitte beschreiben die Strukturierung der Projektaktivitäten. Es wurden die folgenden Teilaufgaben festgelegt:

  • IT-Infrastruktur
  • Aufbauorganisation
  • Ablauforganisation
  • Schnittstellendefinition

3.4.2.1 IT-Infrastruktur

Der Aufbau der notwendigen IT-Infrastruktur wurde von den Projektzielen zum Aufbau eines ERP-Systems ausgeschlossen, da sich ein Parallelprojekt um diese Aktivitäten kümmert. Die relevanten technischen Anforderungen werden jedoch in den nachfolgenden Abschnitten aufgezeigt, da sie eine Abhängigkeit zum ERP-Projekt darstellen. Ziel dieser Phase ist es, eine genaue und umfangreiche Liste aller notwendigen Anforderungen an die IT-Infrastruktur zu definieren und auch die zeitliche Abhängigkeit zu klären. Dies kann dem jeweiligen Projektteam vorgelegt und gemeinschaftlich zur Nachverfolgung der Aktivitäten in Form einer Projektanforderungen genutzt werden. Es lohnt sich, dieser Phase viel Sorgfalt zu widmen, da sie die Basis für alle zukünftigen Projektschritte darstellt.

3.4.2.1.1 Bauliche Anforderungen

Das neu zu etablierende Rechenzentrum, welches die beiden historisch gewachsenen Serverräume ablösen soll, muss natürlich aktuellen Standards entsprechen. Dabei bietet sich die Orientierung an den IT-Grundschutzkatalogen des BSI[21] an. Baulich soll dabei der Maßnahmenkatalog M 1.49 (Technische und organisatorische Vorgaben für das Rechenzentrum [22]) umgesetzt werden.

Das Rechenzentrum befindet sich im ersten Obergeschoss des Gebäudes. Damit ist ein vernünftiger Kompromiss zwischen den verschiedenen externen Risiken (Feuer, Wasser, Einbruch) gewährleistet. Bei der Umsetzung des Rechenzentrums soll sichergestellt werden, dass die Stromversorgung des Rechenzentrums redundant über zwei verschiedene Stromleitungen realisiert wird. Die Klimaanlage ist ebenfalls redundant ausgelegt, wobei die zweite Anlage nur im Fehlerfall aktiv wird und sich ansonsten im Stand-By befindet. Auf eine Feuerlöschanlage wird bewusst verzichtet, da Löschwasser meist mehr Schaden anrichtet als das eigentliche Feuer. Die installierte Brandmeldeanlage hat eine direkte Verbindung zur nächstgelegenen Feuerwache und stellt so eine schnelle Alarmierung zum schnellstmöglichen Eintreffen der Einsatzkräfte sicher. Der Zugang in das Rechenzentrum soll über ein chipkartengestütztes elektronisches Schließsystem realisiert und jeder Zugang entsprechend protokolliert werden.

3.4.2.1.2 Hardwareanforderungen

Jeder physikalische Server soll mit einer Online-USV[23] gegen Stromausfälle abgesichert werden. Diese USVs liefern eine Stützzeit von wenigstens 15 Minuten, um im Ernstfall die Server kontrolliert herunterfahren zu können. Weitere Netzwerkkoppelelemente wie Switches oder Router werden über eine USV pro Rack mit Strom versorgt. Da diese Geräte typischerweise nur eine geringe Stromaufnahme haben, können problemlos mehrere Netzwerkelemente über eine USV gestützt werden. Alle Netzwerkkoppelelemente müssen vollständig redundant ausgestattet sein. Dies impliziert zwar automatisch einen höheren Bedarf an Material und Technik und damit höhere Kosten, senkt aber im Gegenzug das Ausfallrisiko des IT-Systems.

Die physikalischen Server des Serverraumes sollen der Virtualisierung dienen. Die Virtualisierungsserver greifen über ein eigenes Netzwerk auf einen zentralen redundanten Speicher zu. Dies ermöglicht es, die virtualisierten Computer zwischen den Virtualisierungsservern hin- und herzuschieben, ohne dass die Endnutzer dies bemerken. Dies erhöht die Verfügbarkeit des Gesamtsystems erheblich und minimiert gleichzeitig das Risiko eines Datenverlustes.

3.4.2.2 Aufbauorganisation

Hinsichtlich der Aufbauorganisation erscheint es notwendig, die neu zu schaffende ERP-Abteilung sinnvoll in die Betriebshierarchie einzugliedern, um Kompetenzstreitigkeiten vermeiden und Weisungsbefugnisse klar definieren zu können. Zudem kann so die Wertigkeit dieser Abteilung für das Gesamtunternehmen herausgestellt werden. Darüber hinaus ist die Ernennung eines ERP-Verantwortlichen sinnvoll, der für die Geschäftsleitung und die Abteilungen erster Ansprechpartner sein sollte. Dem ERP-Verantwortlichen obliegt auch die Bereitstellung geeigneter Support-Strukturen, um die Mitarbeiter optimal in der Benutzung des neuen Systems unterstützen zu können.

Für den Betrieb der Inhouse-ERP-Abteilung müssen geeignete Mitarbeiter rekrutiert werden, um genügend Know-how bündeln zu können. Da dies nicht aus dem Mitarbeiterstamm realisierbar ist, müssen diese Mitarbeiter auf dem Arbeitsmarkt gefunden oder bei anderen Unternehmen abgeworben werden. Mitarbeiter, die bereits für die AluXY GmbH tätig sind und grundsätzlich in die ERP-Abteilung passen könnten, müssen geschult werden, um ihre neuen Aufgaben verantwortungsvoll und kompetent bewältigen zu können.

Innerhalb des ERP-Systems müssen zahlreiche Rollen für eine granulare Rechtevergabe definiert und erstellt werden. Aus administrativer Sicht wird daher festgelegt, dass neben der Rolle des Basis-Administrators die Rolle eines ERP-Sicherheitsverantwortlichen und eines ERP-Architekten umgesetzt werden muss, um Verantwortlichkeiten feiner zu steuern zu können. Auf Benutzerebene müssen für die verschiedenen Fachabteilungen Rollen angelegt werden, die nur einen Zugriff auf die tatsächlich benötigten ERP-Module ermöglichen. Darüber hinaus wird festgelegt, dass Gruppen wie Auszubildende oder Praktikanten maximal lesende Zugriffe auf das ERP-System erhalten.

Ziel dieser Phase sind die folgenden Ergebnisse:

  • Bestellung des ERP-Verantwortlichen, welcher in sämtliche nachfolgenden Projektphasen aktiv involviert wird
  • Diskussion und Vorschläge zur Eingliederung der ERP-Abteilung in die Unternehmenshierarchie. Eine Gleichstellung mit den übrigen Geschäftseinheiten erscheint ob der hohen Relevanz für den Unternehmenserfolg sinnvoll
  • Definition der ERP-Aufbauorganisation und der zu besetzenden Rollen
  • Ressourcenplanung für die Konstruktionsphase

Diese Ergebnisse bereiten die notwendigen Aktivitäten innerhalb der Konstruktionsphase vor.

3.4.2.3 Ablauforganisation

Ziel dieser Teilaktivität soll es sein, die zu implementierende Ablauforganisation zu definieren sowie die Aktivitäten für die Konstruktionsphase vorzubereiten und zu definieren. Die nachfolgenden Teilaktivitäten wurden zur Implementierung in der Konstruktionsphase identifiziert:

  • Definition der erforderlichen Supportprozesse für das zukünftige ERP-System
  • Entwicklung von Migrationswegen der bestehenden Prozesse nach intern
  • Implementierung von zusätzlich notwendigen Prozessen und Customizing der ERP-Lösung
  • Automatisierung von Arbeitsabläufen (Workflows)
  • Aufgabenverteilung und Zuordnung zu den Rollen der ERP-Abteilung
  • Ressourcenplanung für Aktivitäten der Konstruktionsphase

Nachfolgend werden die oben genannten Teilaktivitäten näher beschrieben.

3.4.2.3.1 Definition der Supportprozesse

Diese Aktivität soll während der Konstruktionsphase alle notwendigen Supportprozesse festlegen. Diese Supportprozesse richten sich an den bestehenden Geschäftsprozessen aus und sollen hinsichtlich der Projektziele die Flexibilität sowie schnelle Anpassung an sich ändernde Marktverhältnisse abbilden.

Die Supportprozesse richten sich nicht ausschließlich nach den Supportanforderungen der ERP-Nutzer, vielmehr geht es auch um die Anpassung des ERP-Systems hinsichtlich sich ändernder Unternehmensstrukturen, Produktionsprozesse, Vertriebsprozesse und Änderungen innerhalb der Supply Chain. Diese Teilaktivität bereitet den notwendigen Grundstein für die folgenden zwei Teilaktivitäten, die sich mit den bestehenden Prozessen auseinandersetzen und neue Prozesse definieren.

3.4.2.3.2 Entwicklung von Migrationswegen

Die aktuell bestehende extern betriebene ERP-Lösung berücksichtigt natürlich alle bestehenden ERP-unterstützten Prozesse. Diese müssen während der Konstruktionsphase auf Plausibilität geprüft und gegebenenfalls hinsichtlich des Backsourcings angepasst werden. Möglich ist es auch, dass sich einige der Prozesse als abbildbar auf die internen Strukturen erweisen. Dies spart wertvolle Ressourcen innerhalb des Projektes.

3.4.2.3.3 Implementierung neuer Prozesse

Ebenso kann ein Ergebnis der ersten Teilaktivität der Aktivität der Ablauforganisation sein, dass es neue Prozesse zu definieren gibt. Diese sollten in diesem Arbeitspaket entworfen werden. Hierzu zählen alle Supportprozesse der ERP-Basis und der Betriebskomponenten, welche zuvor transparent von dem ERP-Dienstleister abgebildet wurden.

3.4.2.3.4 Automatisierung von Arbeitsabläufen

Auch die Automatisierung von Arbeitsabläufen in sogenannte Workflows ist eine Teilaktivität in der Definition der Ablauforganisation. Hierzu zählen die Identifikation der potenziell zu automatisierenden Abläufe und die Abbildung dieser in einem Workflow. Gerade im Bereich der Produktion gibt es viele Abläufe, die sich automatisieren lassen und durch die sich eine Steigerung der Qualität und Minimierung der Durchlaufzeit realisieren lässt. Durch Automatisierung und Harmonisierung lassen sich zudem Ressourcen optimal einsetzen sowie Warte- und Rüstzeiten minimieren.

3.4.2.4 Schnittstellendefinition

Beim Entwurf der ERP-Umgebung wird festgehalten, dass sowohl Lieferanten als auch Kunden Schnittstellen zum ERP-System erhalten sollen. Dadurch sollen die komplette Supply Chain des Unternehmens abgebildet und die unternehmensübergreifende Kommunikation ohne Medienbrüche vollständig digital vollzogen werden können. Darüber hinaus wird festgelegt, dass Exports aus dem System mit Hilfe von Industriestandards erfolgen, um bei der Weitergabe dieser Daten die Vorteile von standardisierten Formaten nutzen zu können. Dies inkludiert selbstverständlich auch die Möglichkeit des Datenimports in das ERP-System.

Außerdem wird vorgegeben, dass Drittanwendungen, deren Funktionalität nicht im ERP-System abgebildet werden können, hinsichtlich ihres Look-and-Feel der ERP-Lösung anzupassen. Dadurch bleibt die gesamte Benutzeroberfläche einheitlich und die Effektivität der nutzenden Mitarbeiter kann erheblich gesteigert werden.

Eine weitere Schnittstelle soll ein Kunden- und Lieferanten-Onlineportal sein. Dieses Onlineportal zu planen ist Aktivität innerhalb dieser Teilaufgabe.

Konkrete Ziele dieser Teilprojektphase sind die folgenden:

  • Definition der notwendigen Schnittstellen und die Integrationstiefe der Supply Chain-Partner
  • Festlegung der notwendigen zu implementierenden Industriestandards
  • Sammlung der zu integrierenden Drittanwendungen sowie Analyse und Abschätzung des Integrationsaufwands. Die tatsächliche Anpassung der Drittanwendungen zur Integration in die ERP-Lösung soll nicht Gegenstand dieses Projekts sein.
  • Definition der Anforderungen, des Layouts und Inhalte eines Online-Portals für Kunden und Lieferanten
  • Ressourcenplanung für die Umsetzung in der Konstruktionsphase

Mit diesen Ergebnissen kann die Konstruktionsphase starten und die Durchführung der entsprechenden Aktivitäten beginnen.

3.4.3 Konstruktionsphase

Diese Phase gilt der Umsetzung innerhalb der Teilaufgaben, die in der Entwurfsphase festgelegt wurden. Voraussetzung ist der erfolgreiche Abschluss der Entwurfsphase inklusive Definition der benötigten Ressourcen, Abhängigkeiten und Aktivitäten.

Ziel dieser Phase ist die Implementierung der ERP-Lösung inklusive Verifikation der ordnungsgemäßen Funktionalität aller Teilkomponenten und der erfolgreichen Datenmigration. Des Weiteren findet die Eingliederung der ERP-Abteilung innerhalb der Unternehmenshierarchie statt und es werden sämtliche involvierten Prozesse festgelegt und vom Management bestätigt.

Die Gliederung entspricht gemäß RUP der identifizierten Teilaufgaben aus der Entwurfsphase. Diese werden im Oberbegriff "Projektumsetzung" zusammengefasst. Zusätzlich wird innerhalb dieser Phase die Datenmigration durchgeführt, welche bereits in der Entwurfsphase vorbereitet wurde, jedoch zeitlich nach Abschluss der Projektumsetzung stattfindet.

3.4.3.1 Projektdurchführung

3.4.3.1.1 Schaffung der IT-Voraussetzungen
Abbildung 4: Aufbau des Rechenzentrums
Abbildung 4: Aufbau des Rechenzentrums[24]
Die Grundlagen dieser Aktivitäten wurden bereits in der Entwurfsphase geplant und vorbereitet. Es existieren umfangreiche Anforderungslisten und Abhängigkeitsdefinitionen der zu liefernden Ergebnisse. Durchgeführt werden diese Aktivitäten von einem Projektteam, das parallel zum ERP-Projekt agiert. Die Ergebnisse werden vom ERP-Projektteam aufgegriffen, um die nachfolgenden Aktivitäten durchzuführen.

Als Grundlage für das zu etablierende ERP-System muss die historisch gewachsene EDV-Landschaft der AluXY GmbH auf die neuen Anforderungen vorbereitet werden. Das neue Rechenzentrum wird gemäß den Vorgaben des BSI, die im Maßnahmenkatalog M 1.49 der IT-Grundschutzkataloge aufgeführt werden, umgesetzt. [22] Das Rechenzentrum befindet sich im ersten Obergeschoss des Gebäudes. Damit ist ein vernünftiger Kompromiss zwischen den verschiedenen externen Risiken (Feuer, Wasser, Einbruch) gewährleistet. Bei der Umsetzung des Rechenzentrums ist sichergestellt worden, dass die Stromversorgung des Rechenzentrums redundant über realisiert wurde. Die Klimaanlage ist ebenfalls redundant ausgelegt, wobei die zweite Anlage nur im Fehlerfall aktiv wird und sich ansonsten im Stand-By befindet. Auf eine Feuerlöschanlage wird bewusst verzichtet, da Löschwasser meist mehr Schaden anrichtet als das eigentliche Feuer. Die installierte Brandmeldeanlage hat eine direkte Verbindung zur nächstgelegenen Feuerwache und stellt so eine schnelle Alarmierung sicher. Der Zugang in das Rechenzentrum wird über ein chipkartengestütztes elektronisches Schließsystem realisiert und jeder Zugang entsprechend protokolliert. Alle verwendeten Netzwerkkoppelelemente sind ebenfalls redundant ausgelegt und werden über unabhängige Stromversorgungsanlagen (USV) auch bei einem Stromausfall mit Energie versorgt.

Für das zu etablierende ERP-System werden Server aufgesetzt, auf denen eine Virtualisierungsplattform eingerichtet wird. Die Virtualisierungsserver greifen über ein eigenes Netzwerk auf einen zentralen redundanten Speicher zu. Dies erhöht die Verfügbarkeit des Gesamtsystems erheblich und minimiert gleichzeitig das Risiko eines Datenverlustes.

Die Ergebnisse dieser Tätigkeiten können genutzt werden, um die ERP-Lösung zu installieren und anzupassen.

3.4.3.1.2 ERP-Installation und Customizing

Die Installation sowie das Customizing der ERP-Lösung gemäß der in der Entwurfsphase definierten Prozesse und Strukturen übernimmt ein externer spezialisierter Dienstleister. Wichtig hierbei ist, dass die internen Mitarbeiter eng in dessen Tätigkeiten integriert werden, um sowohl frühzeitig Fehler aufzudecken und Missverständnisse zu vermeiden als auch parallel eine gewisse Schulung und einen Wissenstransfer der Experten zu realisieren. Ziel dieser Aktivitäten ist es, ein fertiges ERP-System mit auf die Unternehmung angepassten Strukturen bereitzustellen.

Eine zusätzliche Aufgabe ist die Implementierung von Industriestandards, die während der Entwurfsphase definiert wurden. Hierzu zählen XML und EDI. Das implementierte ERP-System liefert hierfür Module, die durch geeignetes Customizing in die Geschäftsprozesse eingebunden werden können. Diese Industriestandards bilden die Grundlage für die zukünftige Integration in die Supply Chain sowie die Kommunikation mit Lieferanten und Kunden. Ein weiterer Punkt dieser Aktivität ist die Entwicklung eines Online-Portals, das zusätzliche Schnittstellen für Marketing-Aktivitäten und die Integration in die Kunden- und Lieferantenkommunikation bereitstellt.

Weitere Aktivitäten dieser Teilaufgabe sind die Bereitstellung notwendiger Voraussetzungen für die Integration und das Wrapping von Drittsystemen zur Einbindung in ein einheitliches ERP-System und -Layout. Explizit ausgeschlossen wurde für diese Teilaktivität die Anpassung dieser Drittsysteme; es wird lediglich eine Schnittstelle bereitgestellt, die weitere Projekte zur Integration nutzen können.

Des Weiteren wird innerhalb dieser Teilprojektphase die Datenmigration vorbereitet. Es werden notwendige Voraussetzungen geschaffen, um die Bestandsdaten in die neue ERP-Lösung zu transferieren. Diese Voraussetzung beinhaltet geeignete Speichersysteme, ein entsprechendes Datenbanklayout und Module zum Datenimport.

3.4.3.1.3 Prozessanpassungen

Aktivitäten dieser Projektaufgabe sind die Anpassung bzw. Neugestaltung der identifizierten Prozesse aus der Entwurfsphase. Hierzu zählen folgende Teilaufgaben:

  • Modellierung neuer Prozesse gemäß der bestehenden Geschäftsprozesse und sowie unterstützender Prozesse wie Endbenutzerunterstützung, Anpassung an sich ändernde Unternehmensstrukturen, Änderungen an der Supply Chain oder Änderungen an Prozessen rund um die Produktion
  • Anpassung existenter Prozesse bzw. Migration von Prozessen, die derzeit in der Hand des externen Dienstleisters liegen oder diesen tangieren
  • Customizing der ERP-Lösung gemäß diesen Prozessmodellen. Dies wird von einem externen Dienstleister vollzogen. Ziel ist es zudem, die involvierten ERP-Mitarbeiter voll in den Customizing-Prozess einzubinden, um gleichzeitig Wissen zu transferieren und frühzeitig nachzusteuern.
  • Definition der Verantwortlichkeiten innerhalb der ERP-Abteilung und unterstützenden Abteilungen wie IT-Support. Eingliederung der definierten Ablauforganisation in die Unternehmenshierarchie und Verknüpfung mit der bestehenden Ablauforganisation

Ziel dieser Aktivität ist es, die definierten Prozesse zum einen in der designierten ERP-Lösung abzubilden und zum anderen die Organisation hinsichtlich der Betriebsabläufe umzugestalten. Am Ende gibt es Dokumente, die Prozesse definieren und die Verantwortlichkeiten innerhalb der Organisation festlegen. Diese Dokumente sind mit dem Management abgestimmt und von diesem akzeptiert.

Als nächsten Schritt sieht das Projekt eine Schulung derjenigen Mitarbeiter vor, die in diese Prozesse involviert sind, sowie die Schulung der Multiplikator-User, die innerhalb der Fachbereiche des Unternehmens als Experten für das neue ERP-System dienen sollen. Dies wird innerhalb des Aufgabenpaketes "Pilotbetrieb" durchgeführt.

3.4.3.1.4 Organisatorische Anpassungen

Die folgenden Aktivitäten stehen im Fokus dieses Aufgabenpaketes:

  • Implementierung der Struktur der ERP-Abteilung und der Rollen der ERP-Mitarbeiter
  • Eingliederung der ERP-Abteilung in die Unternehmenshierarchie
  • Rekrutierung/Schulung des ERP-Personals
  • Gleichstellung mit anderen Geschäftseinheiten

Ziel dieser Aktivitäten soll es sein, die ERP-Abteilung hinsichtlich seiner Aufbauorganisation zu definieren, dieses zu dokumentieren und vom Management bestätigen zu lassen. Dazu gehören neben der Definition der notwendigen Rollen innerhalb der Abteilung auch die Rekrutierung neuer Mitarbeiter und/oder die Weiterbildung vorhandenen Personals, welches für diese Rollen eingesetzt wird. Der bestellte ERP-Verantwortliche begleitet diesen Prozess und führt die Einstellungsgespräche. So kann frühzeitig die geforderte Strategie an die neuen Mitarbeiter vermittelt und ein neues Team gegründet werden.

Nach Abstimmung und Akzeptanz durch das Management findet die Eingliederung innerhalb der Unternehmenshierarchie statt. Es ist wichtig, dass eine Gleichstellung mit anderen Geschäftseinheiten stattfindet, sodass die ERP-Abteilung ob ihrer Relevanz für den Unternehmenserfolg selbstständig agieren und notwendigerweise flexibel und schnell handeln kann.

Nach Abschluss des Aufgabenpaketes ist die ERP-Abteilung fest in die Unternehmenshierarchie eingegliedert und Verantwortlichkeiten und Rollen sind bekannt. Wir empfehlen eine unternehmensweite Kommunikation oder sogar ein Event zur Vorstellung der neu erschaffenen Abteilung. So wird die Sichtbarkeit erhöht und die neuen Ansprechpartner bekommen "ein Gesicht". Die persönliche Vorstellung jedes Einzelnen fördert zudem die Akzeptanz unter der Belegschaft.

3.4.3.2 Pilotbetrieb

Das Teilpaket "Pilotbetrieb" beschäftigt sich mit zweierlei Aspekten:

  • Migration von Bestandsdaten in das neu geschaffene Zielsystem
  • Pilotphase inklusive Schulung von Multiplikator-Usern.
3.4.3.2.1 Datenmigration

Zu der Migration der Bestandsdaten, die sich beim externen Dienstleister befinden, gehört zunächst die Entwicklung geeigneter ETL-Logiken (Extract-Transform-Load) und Migrationsskripte, die den vorhandenen Datenbestand konsistent und integer in das interne Zielsystem überführen. Diese Logiken müssen sich in den in der Entwurfsphase entworfenen Migrationsplan einfügen und die Schritte der Migrationsplanung abbilden. Gegebenenfalls ist es notwendig, einen Migrationszeitraum zu definieren, in dem keine weiteren Änderungen mehr am System durchgeführt werden, sodass der Datenbestand in seiner Vollständigkeit im internen ERP-System in Betrieb genommen werden kann. Datenverifikationen und Test bestätigen im Zielsystem die Vollständigkeit und Unversehrtheit der Daten, bevor in die Transition Phase übergegangen werden kann.

Abhängigkeiten bestehen zum Teilprojekt der Implementierung des technischen ERP-Systems, da in diesem Aufgabenpaket die notwendigen Voraussetzungen für die Datenhaltung geschaffen werden.

Ziel dieses Pakets ist die erfolgreiche Migration von Bestandsdaten. Dabei ist es nicht erforderlich, den Gesamtbestand migriert zu haben. Es muss ein sicherer Migrationsweg festgelegt werden, sodass innerhalb eines definierten Zeitraums die Produktivschaltung durchgeführt werden kann. Mit den bereits migrierten Daten kann auch der Pilotbetrieb gestartet werden, welcher als nächstes Aufgabenpaket beschrieben wird.

3.4.3.2.2 Durchführung des Pilotbetriebs

Dieses Aufgabenpaket ist abhängig von der erfolgreichen Fertigstellung der Implementierung des ERP-Systems. Des Weiteren ist es abhängig von der erfolgreichen Datenmigration der Bestandsdaten. Es müssen nicht alle Daten migriert worden sein, jedoch die erforderlichen für die designierten Pilotbenutzer.

Ein Pilotbetrieb ist notwendig, um die erarbeiteten Prozesse, Konzepte und auch die erfolgreiche Datenmigration zu erproben. Dabei bezieht sich die Pilotphase explizit auf Produktivdaten und -prozesse, jedoch in einem eingeschränkten Benutzerkreis. Dieser Benutzerkreis wurde bereits in der Entwurfsphase definiert. Alle wieder eingegliederten sowie neu geschaffenen Prozesse werden in dieser Phase durch die Nutzung von Echtdaten geprüft. Es muss sichergestellt werden, dass das System und die einzelnen Komponenten jederzeit erreichbar sind, die Performance stimmt, keine kritischen Fehler vorhanden sind und keine logischen Probleme in den Prozessen selber auftreten. Das Ergebnis der Funktionalitätstests der Pilotphase muss ein stabiles, den Anforderungen entsprechendes System sein. Das erfolgreiche Abschließen des Pilotbetriebes ist die Voraussetzung für die Übergabephase.

Ein weiterer essentieller Bestandteil der Pilotphase ist die Schulung und Einweisung der Multiplikator-User (auch Key User genannt). Ihnen kommt in der Übergangsphase eine tragende Rolle zu, da sie währenddessen Ansprechpartner für die Mitarbeiter bei Fragen bezüglich des ERP-Systems sind. Die Key User müssen also ein entsprechend umfangreiches und detailliertes Wissen über die ERP-Anwendung und die einzelnen Prozesse haben. Ein weiterer Aspekt für die Einbindung dieser Spezialisten der Fachabteilungen ist, dass sie schon frühzeitig Werbung für das neue System machen können und die Einstellung der Belegschaft positiv beeinflussen.

3.4.4 Übergabephase

Nach der erfolgreichen Pilotphase, in der am Produktivsystem mit Echtdaten die finalen Funktionalitätstests durchgeführt wurden, kann das Gesamtsystem den Produktivbetrieb aufnehmen. Schon während der Pilotphase beginnt die Schulung der Mitarbeiter. Neben dem externen Dienstleister, der die Einführung für die Mitarbeiter vornimmt, kommt den Multiplikator-Usern eine tragende Rolle zu. Sie sollen die Fragen der Mitarbeiter nach Möglichkeit beantworten, bevor die ERP-Abteilung deren Support-Team kontaktiert. Darüber hinaus stellt die ERP-Abteilung einen zeitlich begrenzten Transition-Support zur Verfügung. In dieser Hypercase-Phase werden, auch mit externer Unterstützung, erhöhte Kapazitäten zur Beantwortung von Support-Anfragen bereitgestellt. Dadurch wird die Ausfallzeit der Mitarbeiter, in der sie auf eine Lösung ihres Problems warten, minimiert und deren Produktivität gesteigert.

Während der Übergabephase beginnt für die ERP-Architekten bereits die Stabilisierungs- und Optimierungsphase. In dieser Phase, die sich über die Übergabe hinaus erstrecken kann, werden nur Anpassungen am System vorgenommen, die Fehler ausbessern oder das Gesamtsystem stabilisieren. Ausgeschlossen sind progressive Änderungen, also Weiterentwicklungen. Diese sind in einem eigenen Projekt nach der Einführung durchzuführen. Nachdem alle Mitarbeiter ausreichend geschult worden sind, können die inzwischen überhöhten Supportkapazitäten abgebaut und die Unterstützung durch externe Dienstleister beendet werden. Der ERP-Abteilung obliegt nun die Sicherstellung des reibungslosen und möglichst fehlerfreien Betriebs des ERP-Systems.

3.5 Risiken

Wie bereits am Anfang dieser Arbeit erwähnt, gibt es zahlreiche Gründe für Unternehmen, ein Backsourcing zu betreiben. Die zuvor ausgelagerten Dienste wieder ins Unternehmen einzugliedern ist jedoch ein Prozess, der abhängig von Anzahl der Dienste und Größe des Unternehmens sehr komplex sein kann. Dementsprechend sind mit einer „Wiedereingliederung“ auch viele Risiken verbunden, wovon nachfolgend einige zu betrachten sind:[11][12]

  • Die Reduktion externer Arbeitskräfte wird größtenteils zur Reduktion der Kosten durchgeführt. Zusätzlich ist meist die interne IT nicht voll ausgelastet. Durch ein Backsourcing sind aber meist intern nicht die Kapazitäten vorhanden, die vorher durch die die externen Mitarbeiter gestemmt wurden. Kurzfristig ist die zusätzliche Belastung des Stammpersonals meist tragbar, aber nicht, wenn die Zusatzbelastung zum Dauerzustand wird. Ressourcenmangel stellt ein großes Risiko dar.
  • Sehr problematisch ist es, wenn die externen Fachkräfte über Qualifikationen und Wissen verfügen, das bei den internen Mitarbeitern nicht oder zu selten vorkommt. Viele langjährige externe Mitarbeiter haben sich über die Jahre „Kopfmonopole“, also spezifisches geschäftskritisches Wissen, aufgebaut.
  • Es ist nicht selbstverständlich, dass ehemalige Mitarbeiter bereit sind, wieder zurückzukommen beziehungsweise erneut zu wechseln. Die Karrierechancen können beim Outsourcing-Anbieter besser sein oder die Rückkehr gestaltet sich trotz entsprechender Verträge schwierig, weil keine eindeutige Zuordnung zum ausgelagerten Betriebsteil mehr möglich ist.
  • Der gesamte Backsourcing-Prozess ist sehr kostenintensiv. Es müssen also die nötigen liquiden Mittel vorhanden sein. Zudem trägt das Unternehmen alle finanziellen Risiken.
  • Hat der Kunde Hardware an den Anbieter übertragen, ist diese Angelegenheit in vielen Outsourcing-Verträgen detailliert geregelt. Es gibt sogenannte Assetlisten mit Aussagen über Eigentums- und Besitzverhältnisse, Miet- und Leasingverträge. Diese Listen werden beim Beginn des Outsourcings erstellt. Sie werden jedoch selten weitergepflegt, so dass beim Backsourcing veraltete unbrauchbare Listen existieren. Meist ist schon nach wenigen Jahren der Großteil der Hardware ersetzt worden – Liste und Realität haben dann nichts mehr gemein.
  • Problematisch kann auch die Rückübertragung von Software von Drittherstellern sein. Hier muss der Kunde häufig an den Dritthersteller für die Rückübertragung bezahlen. Das ist meistens der Fall, wenn der Outsourcer bei Abschluss des Vertrages mit dem Dritthersteller nicht vereinbart hat, dass die Lizenz nach dem Outsourcing kostenfrei übertragen werden kann.
  • Als schwierig kann sich auch die Übergabe der gespeicherten Kundendaten erweisen. Es gilt zu klären, wie und an wen die Daten zu übergeben und dann beim alten Anbieter zu löschen sind. Auch über eine Datenmigration muss nachgedacht werde, wenn sich das Format durch die Nutzung neuer Systeme ändert.
  • Wichtig ist ebenfalls die Kooperation und Unterstützung des bisherigen Outsourcers, auch nach dem eigentlichen Vertragsende. Neben den schon beschriebenen Unterstützungsleistungen zur Übertragung von Know-how, Assets, Daten und Verträgen ist es oft erforderlich, dass der alte Anbieter für einen Übergangszeitraum noch Ressourcen vorhält, um den Betrieb auch bei Verzögerungen in der Übergangsphase zu sichern.
  • Für die Eingliederung der zuvor extern betriebenen Dienstleitung muss im Unternehmen die entsprechende IT-Infrastruktur vorhanden sein. Ist diese nicht gegeben, steht das Unternehmen vor großen Problemen. Auch eine Fehleinschätzung der Leistungsfähigkeit der vorhandenen Struktur kann große Risiken bergen, wenn die vorhandenen Systeme die Auslastung beispielsweise nicht tragen können.
  • Ein Backsourcing kann ein sehr komplexer und aufwändiger Prozess sein. Die Aufwände können von Unternehmen leicht unterschätzt werden, so dass es zu Problemen bei der Aufrechterhaltung der Prozesse kommt.

4 Zusammenfassung

Ziel dieser Arbeit war die umfassende Beschreibung eines Backsourcing-Prozesses. Dies haben wir anhand des praktischen Beispiels eines sich im Wachstum befindlichen mittelständischen Unternehmen dargestellt. Das Unternehmen bezog eine extern betreute ERP-Lösung, entschied sich jedoch aufgrund seines starken Wachstums und der hochspezialisierten Produktionsverfahren für die Rückholung dieser ERP-Dienste. Als Ziele dieser Entscheidung wurden flexiblere und schnellere Anpassungen der ERP-Prozesse, eine Individuallösung sowie der Schutz des geistigen Eigentums gesehen. Insgesamt fügt sich dieser Prozess in die Strategie des Unternehmens, seine gesamte IT-Lösung zu harmonisieren und durch IT-gestützte Prozesse eine Maximierung seiner Wertschöpfung zu erreichen.

Wir haben ein Vorgehensmodell entwickelt, wie dieses Projekt des Backsourcings durchgeführt werden kann. Hierbei orientierten wir uns an einem bewährten Modell, dem Rational Unified Process aus der Softwareentwicklung. In RUP wird mit großer Sorgfalt die Zieldefinition und die Projektabgrenzung vorgenommen sowie die Planung der Projektaktivitäten strukturiert erreicht und umgesetzt. Wir haben das Modell konsequent auf die Erreichung des Ziels, der Implementierung des ERP-Systems im eigenen Unternehmen, ausgerichtet und angepasst. Ergänzt wurde die Projektdefinition durch eine ausführliche Vorbetrachtung und Betrachtung der involvierten Risiken. Unser Vorgehen lässt sich wie folgt gliedern:

  • Vorbetrachtung
    • Erklärung der IST-Situation
    • Definition des SOLL-Konzepts
  • Eingliederung in RUP
    • Definition des Projektziels und Abgrenzung
    • Entwurf der konkreten Ziel-Architektur
    • Umsetzung der Ziel-Architektur in Arbeitspaketen
    • Aktivierung des Betriebs der internen ERP-Lösung
  • Betrachtung der Risiken des Backsourcings

5 Fazit

Die vorliegende Arbeit zeigt einen strukturierten Projektplan und konkrete Aufgabenpakete für den Prozess des Backsourcings einer ERP-Abteilung. Diese Aufgabenpakete sind für das vorliegende praktische Beispiel vollständig und beschreiben alle relevanten Aktivitäten und Ziele. Eine Organisation kann dieses Fallbeispiel nutzen, eigene Projekte vorzubereiten und umfassend zu planen. Es werden sicherlich Anpassungen und/oder Erweiterungen von Teilaktivitäten notwendig sein, um die spezifischen Geschäftsprozesse abzubilden. Jedoch wird empfohlen, dem Modell von RUP zu folgen und die Projektphasen nach diesem Schema konsequent zu durchlaufen. Auch wenn das Modell RUP sich an der Softwareentwicklung ausrichtet und genau dafür entworfen wurde, konnten wir aufzeigen, dass sich die Prinzipien auch auf andere Implementierungsvorhaben anwenden lassen.

Es ist vorstellbar, dass auch weitere Projekte, insbesondere im Kontext des Backsourcings, Gebrauch von den Methoden und Vorgehensmodellen RUP machen können. Gerade die hier nicht näher erläuterten unterstützenden Aktivitäten des Projekt-, Umwelt-, und Change & Releasemanagements können Integrationsprojekten sehr dienliche Werkzeuge sein. Bereits bestehende Werkzeuge in Form von Software können zudem unterstützend wirken und die Erreichung der Projektziele begünstigen.

6 Fußnoten

  1. Hemp, Lübke (2010): ERP-Outsourcing - Fluch oder Segen?, URL: http://winfwiki.wi-fom.de/index.php/ERP-Outsourcing_-_Fluch_oder_Segen%3F, Abruf am 20.02.2011
  2. Jacob, O. (Hrsg.): ERP Value: Signifikante Vorteile mit ERP-Systemen, Springer 2008, S. 1f.
  3. Görtz, M., Hesseler, M.: Basiswissen ERP-Systeme, W3L 2007, S. 6
  4. entnommen aus: Abts, D., Mülder, W., Grundkurs Wirtschaftsinformatik, 5. Aufl., Wiesbaden 2004, S. 165
  5. Siegenthaler, M., Schmid, C.: ERP für KMU - Leitfaden für ERP Evaluation & Einführung, BPX 2005, S. 6
  6. Praxis der Wirtschaftsinformatik, URL: http://hmd.dpunkt.de/glossar/glossar_245.html, Abruf am 19.12.2010
  7. 7,0 7,1 ResourceBridge, URL: http://resourcebridge.de/definition_backsourcing.htm, Abruf am 19.12.2010
  8. Cutter Consortium (2005), "Backsourcing: Why, When, And How To Do It", URL: http://www.cutter.com/research/2005/edge050621.html, Abruf am 20.02.2011
  9. Computerwoche, URL: http://www.computerwoche.de/management/it-services/1898605/index4.html, Abruf am 19.12.2010
  10. acive sourcing, URL: http://www.active-sourcing.com/backsourcing, Abruf am 19.12.2010
  11. 11,0 11,1 evodion, URL: http://www.evodion.de/opencms/export/evodionIT/Infocenter/newsletter/backsourcing.html, Abruf am 19.12.2010
  12. 12,0 12,1 heise online (resale), URL: http://www.heise.de/resale/artikel/Alles-auf-Anfang-Zurueckholen-ausgelagerter-Dienstleistungen-273682.html, Abruf am 19.12.2010
  13. heise online, URL: http://www.heise.de/newsticker/meldung/Kostenvorteile-durch-Outsourcing-schwinden-161084.html, Abruf am 19.12.2010
  14. Bewertung von Backsourcing-Entscheidungen im Umfeld des Cloud Computing, URL: http://www.uwi.uni-osnabrueck.de/martens/2010%20Martens%20Teuteberg%20Backsourcing-Entscheidungen%20im%20Cloud%20Computing.pdf, Abruf am 19.12.2010
  15. infforum.de (o.J.): Rational Unified Process, URL: http://www.infforum.de/themen/anwendungsentwicklung/thema_SE_rup.htm
  16. Quelle:http://thewill.in
  17. 17,0 17,1 17,2 Kuhrmann, M. (o.J.), “Rational Unified Process (RUP)”, URL: http://www.enzyklopaedie-der-wirtschaftsinformatik.de/lexikon/is-management/Systementwicklung/Vorgehensmodell/Rational-Unified-Process-%28RUP%29
  18. 18,0 18,1 Hoffmann, Dirk W.: Software-Qualität, Springer 2008, S. 505
  19. 19,0 19,1 Hamilton, P.: “Wege aus der Softwarekrise”, Springer (2008), S. 54
  20. Quelle: http://www.infforum.de
  21. Bundesamtes für Sicherheit in der Informationstechnik (BSI), URL: https://www.bsi.bund.de/cln_156/DE/Themen/weitereThemen/ITGrundschutzKataloge/itgrundschutzkataloge_node.html
  22. 22,0 22,1 Bundesamtes für Sicherheit in der Informationstechnik (BSI), URL: https://www.bsi.bund.de/cln_156/ContentBSI/grundschutz/kataloge/m/m01/m01049.html
  23. AKI, URL: http://www.aki-usv.com/usv-technik/usv-klassifizierung/vfi.html, Abruf am 18.01.2011
  24. Quelle: http://www.stulz.de
Persönliche Werkzeuge