Vernetzte Systeme – Ein mögliches Zusammenspiel zwischen Planview Enterprise und SAP ERP

Datenerfassung in einer vernetzten Systemlandschaft

Der Grundsatz, dass Menschen keine Inseln sind, trifft auch auf Unternehmen zu. Beiden gemein ist die unabdingbare Vernetzung zu anderen Systemen nach Innen und Außen. So wie natürliche Personen unabdingbar miteinander kommunizieren müssen, um Ihr Verhalten zu validieren und anzupassen, genauso müssen auch unterschiedliche Bereiche innerhalb eines unternehmerischen Systems regelmäßig oder auch anhaltend miteinander kommunizieren, um einen effizienten Datenaustausch zu ermöglichen. Diesen komplexen Prozess möchte ich mit diesem Beitrag etwas entzerren und Ihnen einen Überblick über die Datenerfassung in einer vernetzen Systemlandschaft am Beispiel der Projektmanagement Enterpriselösung Planview und SAP.

Die Effizienz einer Systemlandschaft ist in großem Maße abhängig von den individuellen unternehmerischen Anforderungen und einem effizienten Informationsaustausch zwischen den einzelnen Komponenten auf Basis von Datenschnittstellen. Die einzelne Systeme sind hierbei jeweils als führende „Erfasser“ für bestimmte Informationen zu sehen. Datenschnittstellen sind solche Verknüpfungen, die für den Informationsaustausch zwischen Programmen dienen. In der Regel werden hierbei sowohl eher statische Stammdaten (auch Bestandsdaten) als auch dynamische Bewegungsdaten ausgetauscht.

Welche Daten entstehen wo?

Die Vielfalt der Daten möchte ich an einigen “einfach” nachzuvollziehenden Beispielen verdeutlichen. Nehmen wir Daten, die den Personalbereich zugeordnet werden können, das sind z. B. klassischerweise die Erfassung von Mitarbeiter-Stammdaten (Name, Kennung, Kontaktinformationen, Standort, etc.). Im Bereich Projektmanagement wird eine Projektmanagement-Software dazu verwendet, Projekt-Stammdaten (Projektziele, Risiken, Termine, etc.) festzuhalten. Im Finanz- und Controllingbereich dient ein Finanzmodul/System dazu, Daten über Rechnungen bereit zu halten.

Weite Teile der erfassten Daten sind für das gesamte vernetzte System, oder zumindest für mehrere Werkzeuge, von Bedeutung und sind entsprechend auf die Systemlandschaft zu verteilen bzw. dieser zur Verfügung zu stellen. Bei statischen Bestandsdaten wird dies in vielen Unternehmen vom sogenannten Stammdatenmanagement zentral gesteuert.

Erfolgt eine Verteilung der Daten zur Laufzeit, beispielsweise durch den direkten Zugriff auf die Datenbestände, ist es sogar möglich, eine redundante Datenhaltung zu vermeiden.

Wie kann ein Datenaustausch prinzipiell aussehen?

Die Vielfalt an Datenschnittstellen ist groß und stark abhängig von der Architektur der jeweiligen Tools. Der einfachste, aber wenig vernetzte Weg ist ein Austausch über Dokumentenex- und -importe (z. B. .csv, .txt oder Excel). Eine bessere Vernetzung ist durch „echte“ Interfaces, mit direkter technischer Verknüpfung der Anwendungen möglich.

Client-Server-Architektur

In einer Client-Server-Architektur gibt es oft die Möglichkeit, per Linked Server einen direkten Austausch auf Datenbankebene durchzuführen. Datenbankobjekte eines Fremdsystems können somit wie eigene Objekte aufgerufen und in Auswertungen verwendet werden (mit Einbußen im Bereich der Performance). Oder klassischerweise bei einem verarbeitenden Wartungslauf als Datenquelle eingebunden sein. Typisches Beispiel hierfür ist die Synchronisierung von Benutzerstammdaten wie Benutzerkennungen, Personennamen, Telefonnummern, und E-Mail-Adressen.

Webservices

Vielen Anwendungen nutzen aber auch Webservices zum Datenaustausch über das HTTP(S)-Protokoll. Diese „Webdienste“ sind oft Teil des Anwendungsumfangs und somit meist systemnah umgesetzt. Sie ex- und importieren demnach direkt in das bestehende Datenmodell bzw. liefern direkte Daten in der vorgegebenen Formatierung des Datenmodells.

Sind Informationen lediglich als nicht weiter zu verarbeitende Stammdaten gefordert, so ist der Zugriff auf Schnittstellen nicht selten auch zur Laufzeit möglich. Ist eine Verarbeitung notwendig, so kann diese ggf. aus der Anwendung heraus erfolgen und/oder zeitgesteuert implementiert werden (über einen Nachtlauf bzw. ein Wartungsfenster). Auch eine Zwischenhaltung der im ersten Schritt nicht verarbeiteten Daten hat je nach Anforderungen, implementierten Geschäftsprozessen oder sonstiger unternehmerischer Strategie seine Berechtigung. Zumal eine Änderungsbetrachtung oder Historisierung dadurch ebenfalls einfacher umzusetzen ist. Gleiches gilt für die unter Umständen notwendige Validierung oder Filterung der Import-Daten, bevor diese in das Zielsystem überführt werden können.

Denkbar wäre hierbei auch, dass Daten noch nicht in ein System importiert werden können, da andere Daten aus einem dritten Fremdsystem oder dem Zielsystem selbst noch nicht vorhanden sind. Ein Zielsystem könnte z. B. eine Rechnung importieren, die einem Planungsobjekt zugeordnet werden soll, welches zum Zeitpunkt des Import noch nicht existiert.

Welche Möglichkeiten bietet Planview, welche SAP?

Planview

Planview verfügt für über integrierte Webservices, die es ermöglichen, viele Informationen im bestehenden Datenmodell auszutauschen. Hierbei arbeitet Planview an manchen Stellen auch mit Übergabetabellen vor der eigentlichen Datenverarbeitung. Außerdem bietet die Portfoliomanagement-Software die Möglichkeit, individuelle Berichte über den Microsoft SQL Report-Builder bereit zu stellen.

Gehen die Anforderungen an ein Interface in den stark individuellen Bereich, führt allerdings kein Weg an eigenständigen Schnittstellen-Implementierungen vorbei. Die bestehende 3-Tier-Architektur ermöglicht die Entwicklung verschiedener Datenschnittstellen: Von der einfachen Anbindung an das Datenbanksystem (Oracle oder MS-SQL) in allen Varianten über Webservices bis hin zum Dateiaustausch.

SAP

Die Anbindung eines SAP-Systems an ein Fremdsystem erfolgt in der Regel über sogenannte Remote Function Calls (RFCs), also über den entfernten Aufruf eines Funktinsbausteins, welcher Daten an das aufrufende System exportiert oder über dieses System Daten nach SAP importiert.

Im Zusammenspiel zwischen Planview und SAP hat sich bei vielen unserer Kunden der Weg des Aufrufs eines RFC-Bausteins über eine Visual Basic Script etabliert. Ein konkretes Beispiel ist im folgenden Kapitel aufgeführt.

Konkrete SST-Umsetzung per RFC

Gegebenheiten

In diesem Beispiel sollen im Modul SAP-FI erfasste Rechnungen externer Dienstleister per RFC-SST zur Zuordnung in der Ausgabenplanung in einem Nachtlauf nach Planview importiert werden.

Gegeben ist ein durch SAP bereitgestellter RFC-Baustein, der die zu übertragene Datensätze als virtuelle Tabelle liefert sowie ein technischer SAP-Benutzer, der zum Aufruf dieses Bausteins zur Verfügung gestellt wird und über alle notwendigen Berechtigungen verfügt.

Gegeben ist außerdem ein bestehender Nachtlauf in Form eines DB-Jobs über den ein auf dem Server hinterlegtes Programm (in diesem Fall Visual Basic Script) aufgerufen werden kann. Bei diesem Nachtlauf handelt es sich nicht um Planview-Standard, sondern eine individuelle Implementierung, welche einzelne Datenschnittstellen in fachlich sinnvoller Reihenfolge aufruft und entsprechend loggt.

Installation der Programmbibliothek

Um einen SAP-Aufruf erfolgreich durchzuführen ist die entsprechende SAP-RFC-Programmbibliothek auf dem Server zu installieren. Der einfachste Weg ist die Installation einer SAP-Logon-GUI unter Auswahl der „Unicode RFC Libraries“. Gegebenenfalls ist außerdem eine bidirektionale Firewall-Freischaltung für die Server und Ports („33XX“, „XX“ steht für die Instanznummer des SAP-Systems) der beteiligten Systeme vorzunehmen. Wichtig ist hierbei und auch beim späteren Aufruf des Skripts per CScript (Windows Server) die technisch korrekte Prozessorarchitektur (32 Bit oder 64 Bit) zu verwenden, da sonst ein Erzeugen der benötigten SAP-Function-Objekte nicht möglich ist.

Weiteres Vorgehen bei der Realisierung

Im Skript wird im ersten Schritt eine Verbindung zu SAP hergestellt. Für die Herstellung dieser ADODB-Verbindung sind Adresse, Instanznummer/Systemnummer, Client, Benutzer und Passwort erforderlich. Ist die Verbindung etabliert, ist der Aufruf von SAP-RFC-Bausteinen möglich.

Ein SAP-Function-Objekt erhält per „Add“ die Bezeichnung des Bausteins. Vor dem „Call“ des Bausteins sind per „Exports“ mögliche Übergabeparameter zu setzen. Im Beispiel könnte es das Trennzeichen (Delimiter) der Datensätze oder ein Stichtagsdatum, welches dem Baustein als Datenfilter dient, sein.

Der Aufruf liefert ein Dataset zurück. Dieses wird im nächsten Schritt durchlaufen und die Rechnungsdaten (konvertiert und bearbeitet) in eine Inflow-Tabelle in Planview geschrieben. Eine Verbindung zu Planview ist selbstverständlich obligatorisch. Die Daten werden nach erfolgreicher Übertragung durch den Aufruf eines weiteren Moduls als „bereits exportiert“ markiert. Dadurch wird sichergestellt, dass bei einem erneuten Aufruf die gleichen Datensätze nicht ein weiteres Mal übertragen werden.

Die weitere Verarbeitung der Rechnungsdaten und die Zuordnung zur Ausgabenplanung eines Planungselements erfolgen nicht im Zuge des Schnittstellenlaufs, sondern in einem eigenständigen, selbst entwickelten Modul, welches an das Planungswerkzeug angekoppelt ist. In diesem Modul können sämtliche individuellen Anforderungen eines Kunden berücksichtigt werden. Selbst eine am PM-Markt etablierte, weit verbreitete Software wie Planview kann eine solch individuelle Möglichkeit nicht bieten. Die Vielfalt der Anforderungen der Unternehmen ist hierbei zu groß um über „Bordmittel“ abgedeckt zu werden.

Ausblick

Die Lösung innerhalb der vernetzten Systemen bilden individuelle Anpassungen/Erweiterungen der Projektmanagement-Software. Spätestens an dieser Stelle kommen viele Kunden auf uns als Dienstleister zu und fragen nach Möglichkeiten der Etablierung ihrer Anforderungen sowie der sinnvollen Vernetzung ihrer Anwendungen, um die bestehenden Geschäftsprozesse zu etablieren oder zu optimieren.

Weitere Informationen zu unserer Software Engineering Lösung, mit der Sie Ihre Standard Projektmanagement-Software an Ihre individuellen Bedürfnisse anpassen können, finden sie hier.

Weitere Beispiele für den bereits von uns umgesetzten Datenaustausch zwischen Planview und SAP:

  • die Einbindung von Mitarbeiterstammdaten nach Planview (ebenfalls im Rahmen eines Nachtlaufs)
  • das Exportieren von Zeitrückmeldung nach SAP zur Steuerung der internen Leistungsverrechnung (zur Laufzeit aus der Planview-Programmoberfläche heraus)

Denkbar sind alle Varianten des Datenaustauschs: Import und Export. Zur Laufzeit oder im Rahmen eines Wartungsfensters. Direkt im System oder unter Verwendung von Übergabe-Tabellen.


   One Comment


Schreibe einen Kommentar

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