Enterprise Project Management mit ERP: Integration im globalen Einsatz

Eine wichtige Voraussetzung für den erfolgreichen Einsatz von Projektmanagementsystemen (PMS)  ist deren sinnvolle Integration mit dem zentralen ERP-System. Für international agierende Unternehmen müssen darüber hinaus landesspezifische Finanz- und Controlling-Aspekte berücksichtigt werden.

   

Dieser Artikel beschreibt die Voraussetzungen der Integration zwischen PMS- und ERP- Systemen, listet die wesentlichen Anwendungsfälle aus der Praxis auf und analysiert die Besonderheiten für global agierende Unternehmen. Die Ausführung sowie Beispiele und Abbildungen beziehen sich im Wesentlichen auf die Integration der Produkte von Microsoft (Microsoft Project Professional und Server) und SAP (SAP Enterprise Core Components/ ECC), sind aber inhaltlich in ähnlicher Art und Weise auf andere Systeme anwendbar.

 

 

Das wesentliche Ziel, ein PMS mit einem ERP-System zu koppeln ist der Austausch von kostenrelevanten Informationen. Dazu gehören Planarbeit, Plankosten, Erlöse, Budgets, geleistete Stunden und Ist-Kosten. Manchmal stehen neben Aufwänden und Kosten auch Termine im Mittelpunkt, wie etwa bei Instandhaltungsprojekten, die in SAP PM (Plant Maintenance) geplanten werden.

 

Ablaufinformationen können nach Microsoft Project exportiert und dort feingeplant werden, mit dem Ziel, Termin- und Ressourcenplanungsergebnisse auf die „PM-Operationen“ zurückzuspielen. Ähnliches findet sich oftmals auch im Anlagenbau, wo die Disposition und terminliche Steuerung von Materialkomponenten in Microsoft Project gesteuert werden kann.

 

Ein weiteres Ziel der Integration können auch Fortschrittsmeldungen sein, die aus dem PMS in das ERP-System übertragen werden sollen. Diesen Fall kann man auch häufig im Anlagenbau sowie generell in der Bau-Branche antreffen. Die Fortschrittsinformation kann dann für Earned Value Berichte verwendet werden.

 

Um den Austausch dieser Daten zu ermöglichen müssen Objekte auf beiden Seiten miteinander „gemappt“ werden, wie etwa PSP-Elemente aus SAP PS mit Microsoft Project Vorgängen. Die Zuordnung zwischen Objekten beider Systeme ist jedoch kein Selbstzweck, sondern lediglich eine Voraussetzungen für den Transfer von Kosten und Leistungsdaten. Generell sind folgende Voraussetzungen für die Integration sicherzustellen: 

 

• Stammdaten aus dem ERP-System werden mit dem PMS synchronisiert. Dazu gehören sowohl Ressourcenstammdaten (wie etwa Personalnummern, Kostenstelle und Leistungsart von Mitarbeitern) als auch projektbezogene Stammdaten (wie die Liste gültiger Profit-Center, Projektarten etc.).
• Als zweite Voraussetzung muss ein  sinnvolles Mapping zwischen Projekt- Objekten festgelegt werden. Dabei geht es nicht darum, jedes Detail im PMS mit Objekten des ERP-Systems zu verknüpfen! Derartige Ansätze detaillierter Direkt-Zuordnungen erweisen sich in den meisten Fällen als wenig effizient. Auch muss es sich nicht unbedingt um 1:1 Mappings handeln, wie Bild 1 verdeutlicht. Vielmehr soll der kleinste gemeinsame Nenner gefunden werden, der eine optimale Kostenintegration ermöglicht (siehe Bild 1).

 

 

Einer der wesentlichen Anwendungsfälle  für die Integration ist der Planungs- und Budgetierungsprozess für das Projektmanagement. Naturgemäß sind hier unterschiedliche Akteure auf mehreren Unternehmensebenen involviert, das Ganze vor dem Hintergrund eine kombinierten Top-Down und Bottom-Up Budgetplanung.

 

Dieser Prozess beginnt während der  Projektauswahlphase beziehungsweise (je nach Ausgestaltung) im Portfoliomanagement. Was die Projekt- und Budgetentscheidungsfindung angeht, ist zwischen der Art des Projektgeschäfts zu unterscheiden: bei internen IT Projekten sind beispielsweise die Ressourcenverfügbarkeit und -auslastung maßgeblich, während beim Kundenprojektgeschäft strategische Ziele die Entscheidungsprozesse bestimmen, wie etwa neue Märkte, Schlüsselkunden etc.

 

Die Informationsbasis ist jedoch in allen Fällen recht ähnlich: die erwarteten Kosten und (falls relevant) Erlöse der Projekte müssen  sinnvoll konsolidiert werden und als Input für die Budgetallokation dienen. IT technisch kann dabei folgendes festgestellt werden: PMS Systeme sind die Grundlage für die Aufplanung neuer Projekte mit Projektressourcen (Arbeit, Material, Fremdleistung etc.). Die daraus resultierenden Kosten- (und Erlös-) Ergebnisse werden „umgeschlüsselt“ (nach Fiskaljahr, Kostenstellen, Profit-Centern etc.) und dem ERP System zur Verfügung gestellt.

 

Der Kosten- und Erlösplanungsprozess  hört mit der Budgetgenehmigung nicht auf. Die geschätzten Gesamtkosten aus dem Projektgeschäft müssen regelmäßig ermittelt werden. Insbesondere Unternehmen mit erhöhter Publikationspflicht können es sich nicht erlauben, überholte Budgetstände für die erwartete Kostendarstellung zu verwenden.

 

In der Praxis findetman vornehmlich  quartalsbasierte Kostenplanungsprozesse. Hierbei wird die erwartete Kostensituation aus dem PMS (resultierend aus der Projektüberwachung und -fortschreibung) in entsprechende Controlling Versionen des ERP-Systems aktualisiert.

 

 

Geleistete Stunden von (Projekt-) Mitarbeitern  können sowohl im ERP-System als auch im PMS erfasst werden. Die Zeitrückmeldung im PMS bietet den Vorteil der vorgangsgenauen Eintragung von Stunden sowie der Angabe der geschätzten Arbeit bis zur Fertigstellung (ETC – Estimation to Completion). Für den Projektleiter sind das äußerst wertvolle Informationen für seine Projektüberwachung und -steuerung.

 

 

 

 

 

Diese Stunden aus dem PMS müssen dann aber zwecks Leistungsverrechnung dem ERP-System zur Verfügung gestellt werden. Das ist auch hinsichtlich des oben erwähnten Kostenplanungs- und Budgetierungsprozesses wichtig. Zu beachten ist dabei die Buchung mit der korrekten „leistenden“ Kostenstelle, dem passenden Tarif und dem „zahlenden“ Empfänger – alles Punkte, die ein Projektleiter nicht im Detail kennt und meistens auch gar nicht wissen will. Diese Umschlüsselung und Verdichtung der Ist-Arbeit nach Controlling-Aspekten kann durch die eingesetzte Schnittstellenlösung automatisch erfolgen, vorausgesetzt die Stammdaten sind synchron. Die Leistungsrückmeldung im ERP-System hat dagegen den Vorteil, dass übergreifend sowohl auf Projekte als auch auf Nicht-Projektaufträge gebucht werden kann.

 

Für das Projektgeschäft problematisch ist allerdings, aus der geleisteten Arbeit und (falls vorhanden) der Rest-Arbeit den Projektfortschritt zu ermitteln. Der Grund ist keineswegs das Fehlen von Funktionen in den ERP Systemen. Am Beispiel SAP existiert eine sehr hohe Funktionsvielfalt. Deren konsequente Umsetzung bedeutet allerdings eine hohe Detaillierung im SAP System und Mappings auf tiefer Einzelvorgangsebene. Dies hat Implikationen auf das Arbeiten im PMS, bedingt durch den „Import“ von ERP Regeln und Restriktionen.

 

Der oben beschriebene Zusammenhang zwischen Leistungsrückmeldung und Überwachung des Projektstatus ist allerdings nicht immer gegeben. Es gibt Anwendungsfälle, bei denen diese zwei Aspekte bewusst getrennt werden: Aufwandsplanung und Ist-Arbeit finden auf gesonderten „Work-Package“-Vorgängen statt, während Termine und der Projektfortschritt losgelöst geplant und überwacht werden. Hierbei reicht es aus, die Ist-Arbeit in verdichteter Form auf die speziellen Work-Package Vorgänge, oder gar nur für das Projektberichtswesen, zu extrahieren, unabhängig vom Projektfortschritt.

 

 

Die auf Projekte angefallenen Kosten sind eine wesentliche Information für die Projektteams. Dabei reichen die Ist-Kosten allein nicht aus. Es ist ebenso wichtig zu wissen, welcher Anteil vom Budget sich bereits im Obligo befindet (sprich „bestellt wurde“). Daraus lässt sich das verfügbare, also nicht verbrauchte Budget ableiten. Darüber hinaus gilt es, Informationen zu Bestellungen und Rechnungen (etwa aus dem SAPMM) zu erhalten. In der Praxis sind oft folgende Vorgehensweisen zu finden:

 

• Extraktion von Ist-Kosten und Obligo pro Fiskaljahrperiode und Empfängerobjekt (etwa SAP PSP-Element). Dies ermöglicht die Erstellung von Kostenberichten, bei denen die Ist- Kosten den Plankosten aus dem PMS gegenübergestellt werden können.
• Abruf von Kosten-Detailinformationen. Hier kann ein Projektleiter beispielsweise einen Vorgang in Microsoft Project markieren und über einen Befehl alle zugehörigen Bestellpostionen oder Rechnungen einsehen (etwa in einem Dialog oder als Excel-Export). 

In einigen Fällen wird ein detaillierter Kostenimport auf Ebene von Vorgängen und deren (Kosten-) Ressourcenzuordnung gefordert, mit dem Ziel einer ähnlich genauen Überwachung von Kosten wie bei der Arbeit. Dieses Vorgehen erfordert einen klar geregelten Aufbau der Projektpläne und strenge Regeln für die Eindeutigkeit der Ressourcenzuweisung. Um bei unserm Beispiel zu bleiben: Wie findet man aus einem SAP Kostenbuchungsbeleg die richtige Microsoft Project Ressourcenzuordnung zu einem Vorgang? Wie lässt sich beispielsweise aus der Information „PSP-Element und Kostenart“ im Buchungsbeleg der Vorgang und die Kostenressource eindeutig identifizieren?

 

Die Anforderung nach einer solchen Detaillierung ist aber eher selten. In den meisten Fällen reicht der Ist-Kostenimport auf Ebene der Kostenobjekte und Kostenarten als Input für das Projektberichtswesen aus.

 

 

Der Austausch von Kosten und Arbeit bei multinational genutzten Projektmanagementlösungen hat einige Besonderheiten, die beachtet werden müssen. Aus Projektmanagementsicht ist bei globaler Nutzung vor allem ein zentraler Ressourcenpool wichtig. Personal- und Sachressourcen aus unterschiedlichen Ländern sind in länderübergreifenden Projekten involviert. Gemischte Teams bilden hier die Regel. Auf der anderen Seite haben ERP-Systeme lokale Finanzanforderungen. So muss die Arbeit der Mitarbeiter auf die jeweilige Landesgesellschaft verrechnet werden und der Einkauf von Fremdleistungen oder Materialien findet in dem jeweiligen Standort statt.

 

Eine globale Integrationslösung ist vom Customizing und der Entstehungs-historie der ERP Landschaft abhängig. Am Beispiel SAP liegt eine optimale Situation dann vor, wenn ein Kostenrechnungskreis eingerichtet wird, in dem die unterschiedlichen, meist länderspezifischen Buchungskreise (engl. Company Codes) zusammengefasst werden. Hierbei lassen sich im Projektsystem übergreifende Projekte erzeugen: PSP-Elemente können so eingerichtet werden, dass sie sich auf einen Buchungskreis abrechnen, wie in Bild 2 dargestellt.

 

 

 

Das PMS kann diesem Aufbau recht einfach durch die Einrichtung „virtueller Mappings“ folgen. Hierbei erkennt die Schnittstellenlösung die Zuordnung zum korrekten SAP-Kostenobjekt (PSPElement oder Innenauftrag) anhand von Projekt- und Ressourcendaten. In  Bild 2 lässt sich aus den Projektdaten in Microsoft Project das SAP PS Projekt ableiten, während die Ressourcenstammdaten auf den Buchungskreis und damit auf das Empfänger PSP-Element schließen lassen.

 

 

Eine derart vorteilhafte Strukturierung  des SAP-Systems ist aber nicht sehr häufig vorzufinden. Bei vielen globalen Unternehmen erschwert zudem die ERP-Nutzung zugekaufter Firmen eine übergreifende Lösung. Das in Bild 3 gezeigte Szenario ist in ähnlichen Ausprägungen relativ häufig anzutreffen. Dabei existieren mehrere SAP-Systeme oder Mandanten und darin wiederum jeweils mehr als ein Kostenrechnungskreis. Der wesentliche Nachteil auf SAP-Seite ist die Tatsache, dass aus planerischer Sicht keine Zusammenfassung der relevanten (Projekt-)Kostenobjekte für die unterschiedlichen Buchungskreise möglich ist. Erschwerend kommt manchmal hinzu, dass am Beispiel SAP bestimmte Standorte im Projektsystem arbeiten während andere die Projekte über CO Innenaufträge abbilden.

 

 

Hier bietet ein PMS wie Microsoft  Project Server eine entsprechende Klammer für eine umfassende Planung und Projektüberwachung. Dabei lassen sich Plankosten und geleistete Stunden auf die diversen Systeme und Kostenobjekte nach SAP verteilen und die Ist-Kosten aus den SAP-Systemen zurückimportieren. Der Nutzen ist enorm, weil sich eine derart integrierte Lösung deutlich schneller und kostengünstiger implementieren lässt als ein Umbau der ERP-Landschaft. Auch dieser Integrations-Fall wird generell mit Hilfe virtuelle Mappings umgesetzt. Die Ressourcenstammdaten müssen dabei auch die Information über das SAP Systemund die Art der genutzten Kostenobjekte tragen. Die Logik für die Identifizierung des jeweiligen Kostenobjektes ist in der Schnittstellenlösung hinterlegt.

 

STAVROS GEORGANTZIS