Der Weg ist das Ziel: Zur Integration von "Microsoft Project" mit SAP

Inhalt dieses Artikels:
Stammdaten verwalten | Planung und Budgetierung | Rückmeldung | Integration über "TPG PSLink" und "ResourceLink"

Dem Wunsch einer Integration von Microsoft Project und SAP gehen üblicherweise Prozess- und Rollenüberlegungen voraus, die diese Kombination als eine optimale Lösungsmöglichkeit des Enterprise Project Management herausstellen. In der jüngsten Ausgabe des Spezial-Magazins S@PPORT werden die geschäftsbezogenen Überlegungen beleuchtet:

Die Strukturierung eines Projektes aus Sicht der Projektabwicklung ist nicht immer kongruent mit der Sichtweise des Controllings. Während Projektleiter eher eine phasen- oder funktionsorientierte Vorgehensweise anstreben, suchen Controller das Projekt in Kostenträger zu gliedern und sind damit an einer objektorientierten Hierarchie interessiert. Im Angelsächsischen wird diesbezüglich gerne zwischen der work und cost breakdown structure unterschieden – zu deutsch: Projektstrukturplan versus Kostenstrukturplan.

Hinsichtlich der Integration der beiden Tools würde der Strukturplan aus SAP (PSP-Elemente) die Kostenträgerhierarchie abbilden. Dieser Kostenstrukturplan muss aber auch in Microsoft Project zur Verfügung stehen, so dass Kosten und Arbeit den Kostenträgern zugeordnet werden können. Hierbei stehen zwei Möglichkeiten zur Verfügung:

Die Schnittstelle muss in der Lage sein, beide Herangehensweisen zu unterstützen.

Für gewöhnlich obliegt die Verwaltung der Stammdaten nicht nur einem der beiden Werkzeuge. Die Schnittstelle muss in der Lage sein, das führende System auf Feldebene festzulegen, um den unterschiedlichen Anforderungen von Unternehmen gerecht werden zu können.

Neben den Projektstammdaten gilt es auch, die Ressourceninformationen des Microsoft Project Enterprise Resource Pools mit SAP synchron zu halten. Im Gegensatz zu Projektstammdaten geht es hier aber um die Synchronisation in nur eine Richtung – von SAP nach Microsoft Project. Dazu gehört sowohl das Anlegen neuer Mitarbeiter beziehungsweise Deaktivieren nicht mehr verfügbarer Personen aus "SAP HR" als auch die Aktualisierung von deren Daten, die später für die Planung benötigt werden. Wichtige Felder in diesem Zusammenhang sind etwa die zugehörige Organisationseinheit, Kostenstelle, Leistungsart, Werk usw.

Bei strukturbezogenen Daten wie Organisationseinheiten oder Skills muss die Schnittstelle in der Lage sein, diese Metastrukturen in Ressourcen-Enterprise-Gliederungscodefeldern abzubilden und aktuell zu halten. Speziell das letzte Gliederungscodefeld, das den Namen RSP trägt (Ressourcen Strukturplan), sollte die Organisation aus SAP widerspiegeln, da Microsoft Project diese Hierarchie für die Berechtigungen auf Projekte und Ressourcen nutzen kann.

Neben Personen aus HR ist es auch denkbar, SAP-Arbeitsplätze oder Kombinationen aus Kostenstellen/Leistungsarten als Microsoft Project-Ressourcen zu importieren. Das ist vor allem für Unternehmen wichtig, die kein HR haben und/oder Buchungen auf dieser Ebene benötigen.

Des Weiteren stellt sich die Frage der Detailliertheit dieser Daten. Während der Projektleiter in seinem prozessorientierten Denken die Arbeit und Kosten auf Vorgangsbasis plant und überwacht, reicht in SAP die Zuordnung zu Controllingindikatoren wie Kostenstellen, Kostenträger etc. Aus diesem Grund muss die Schnittstelle die Möglichkeit bieten, Daten nach beliebig konfigurierbaren Faktoren zu aggregieren, um diese in das SAP-System zu übertragen.

So wird etwa die Arbeit der Ressourcen auf eine Kombination von PSP-Element, Kostenstelle und Leistungsart pro Fiskaljahrperiode verdichtet und in die SAP-Leistungserfassung übertragen. Die Verdichtungskriterien stellen dabei Microsoft Project-Vorgangs- und Ressourcenfelder dar, die im Rahmen der Stammdatenpflege die erforderlichen SAP-Informationen enthalten müssen.

Anders als die Planung, findet die Budgetierung von Projekten normalerweise in SAP statt. Bezogen auf die Schnittstelle liefert Microsoft Project einerseits den planerischen Input für die Budgetbestimmung und -erteilung, zum anderen müssen die in SAP genehmigten Budgetwerte wieder in das Microsoft Project-Projekt übertragen werden, um die Budgetverfolgung zu ermöglichen.

In den meisten Anwendungsfällen verwendet SAP eine geringere Detaillierung als Microsoft Project, sodass die Budgets auf der Ebene von Sammelvorgängen, die PSP-Elementen entsprechen, oder sogar auf Gesamtprojektebene importiert werden. Für die Budgetüberwachung ist das normalerweise ausreichend.

Rückmeldung in Projekten und allgemeine Zeitrückmeldung haben gemeinsam zum Ziel, die geleistete Arbeit von Mitarbeitern aufgabenbezogen zu erfassen. Die Projektrückmeldung interessiert sich aber darüber hinaus für den Fortschritt der Projekte. Ein wichtiger Faktor zur Fortschreibung von Projektvorgängen ist der ETC (Estimated To Completion), also die Angabe der Restarbeitszeiten – ein Wert, der sich auf die Gesamtarbeit (EAC = Estimated At Completion) und die geschätzten Fertigstellungstermine von Projektvorgängen auswirkt.

In einer Konstellation bestehend aus verschiedenen Rollen und Tools ist die optimale Vorgehensweise für den Rückmeldeprozess, der noch dazu Projekte und Nicht-Projekttätigkeiten umfasst, keine leicht zu lösende Aufgabe. Die Fragen, die sich hierbei stellen, lauten:

	Wie kann Mitarbeitern ein Tool für die Rückmeldung geboten werden?
	Wie lässt sich die Projektüberwachung mit ETC-Daten sicherstellen?
	Was muss die Projektplanung berücksichtigen hinsichtlich der Rückmeldeanforderungen?

Generell können für die Rückmeldung sowohl "Microsoft Project Web Access" (PWA) als auch SAP-Tools wie „CATS“ (Cross Application Time Sheet) eingesetzt werden. PWA eignet sich vor allem für vorgangsnahe Zeiterfassung, bei der eine Vorgangsplanung auf Personenebene vorausgesetzt wird. Projektfremde Tätigkeiten müssten dabei in gesonderten Projekten (etwa Administrationsprojekte) erfasst werden, so dass auf diese auch zurückgemeldet werden kann.

Oft werden aber projektunabhängige Aufgaben im SAP-System über Aufträge zugewiesen ("CO"-Innenaufträge, "SD"-Aufträge etc.), auf die dann auch gebucht werden soll. Daher liegt der Gedanke nahe, die Zeiten über CATS zu erfassen, um eben Projekten und Nicht-Projekten mit einer Oberfläche besser Rechnung zu tragen. Beide Tools – CATS und PWA – haben ihre Vor- und Nachteile, auf die hier nicht im Detail eingegangen werden soll. Die bessere Lösung ist situationsbedingt zu bestimmen.

Für die Integration ist es dabei wichtig, wie die Daten in das jeweils andere System gelangen. Werden sie in Microsoft Project erfasst, kann die Schnittstelle die Daten verdichten (etwa auf Personalnummer, Auftrag, Kostenstelle usw.) und diese nach CATS weiterreichen oder über die Leistungsverrechnung direkt in das SAP-System einspeisen. Dabei muss SAP nicht dieselbe Detaillierungstiefe haben wie Microsoft Project.

Wird dagegen in SAP zurückgemeldet, so stellt sich die Frage, in welcher Detaillierungsebene gebucht wird und ob auch Restarbeit erfasst wird. Ein häufiger Use Case ist der, dass in SAP wenig Details benötigt werden (also etwa keine Netzplanvorgänge) und gemäß der Zuordnung von Kostenstellen und Leistungsarten auf Aufträge bzw. PSP-Elemente gebucht werden soll. Diese Tatsache lässt sich normalerweise nicht mehr auf Microsoft Project-Einzelvorgänge herunter brechen. Für die Überwachung der Projekte ist es aber oft ausreichend, diese Informationen in Benutzerfelder auf der Ebene von Sammelvorgängen zu erhalten, die den "SAP PSP"-Elementen entsprechen. Die Diskussion der Abweichungen im Detail ist dann Sache der Projektteams.

Die hier beschriebenen betriebswirtschaftlichen Überlegungen stellen einige der wichtigsten Grundlagen der Entwicklung von TPG PSLink und TPG ResourceLink dar. Während TPG ResourceLink die Aktualisierung der Ressourcenstammdaten sicherstellt (nicht nur aus SAP), konzentriert sich TPG PSLink auf die Synchronisation zwischen Microsoft Project und SAP PS und CO. Das umfangreiche Konfigurationsinstrumentarium von PSLink ermöglicht es, unterschiedlichste Anwendungsfälle abzubilden. Die in diesem Artikel aufgeworfenen Fragestellungen lassen sich damit kundenbezogen konfigurieren.

Nähere Informationen in der jüngsten Ausgabe von S@PPORT.
Der Verlag GmbH behält sich alle Rechte am Artikel vor. © 2005 MarkIT Communication