Betrachtung von Möglichkeiten zur GIS-SAP Kopplung in der Liegenschaftsverwaltung

Transkript

1 Betrachtung von Möglichkeiten zur GIS-SAP Kopplung in der Liegenschaftsverwaltung Marc Kleemann, Roland Stahl CSC Ploenzke AG Seit etwa Anfang der neunziger Jahre entstanden durch den Siegeszug des Systems R/3 der SAP AG einerseits und der GIS Technologie andererseits in vielen Unternehmen zwei unabhängige IT-Systeme, die zunehmend identische Objekte redundant und inkonsistent verwalten. Vielfach entsteht daher mittlerweile der Wunsch, die Systeme zu integrieren, denn es ist auf absehbare Zeit nicht erkennbar, dass eines der Systeme das jeweils andere gänzlich überflüssig machen könnte. Durch die Entwicklung des neuen Land Use Management Moduls (LUM) der SAP für die Liegenschaftsverwaltung entstehen jetzt auch in diesem IT- Anwendungsfeld entsprechende Integrationsanforderungen. Der vorliegende Beitrag greift diese Entwicklung auf und stellt die verschiedenen technischen Möglichkeiten der Integration vom einfachen Zugriff auf Tabellen bis hin zur High End Integration auf Basis von EAI und/oder Web Architekturen für eine vollständige Geschäftsprozessunterstützung dar. Einleitung Seit Anfang der neunziger Jahre wurden die Überlappungsbereiche zwischen GIS und SAP immer größer, weil SAP zunehmend die rein kaufmännische Sicht auf die Objekte in Richtung technischer Aspekte erweiterte, und GIS neben der rein graphischen Objektpräsentation informationstechnische Aspekte der Objekte in komplexen Datenbanksystemen verwalten. Die sich daraus ergebende Anforderung einer Systemintegration wurde zunächst im EVU-Markt sichtbar, hat aber inzwischen auch andere Branchen erreicht. So ist es nicht überraschend, dass ESRI und SAP bereits vor einiger Zeit ein Kooperationsabkommen geschlossen haben. Im SAP Lieferumfang ist heute ein ArcView enthalten, und im SAP Business Warehouse ist MapObjects integriert. Dennoch sind GIS-SAP Integrationen heute immer noch die Ausnahme. Viele Unternehmen begnügen sich mit Integrationen einfachster Art wie etwa dem Austausch auf (ASCII-)Dateiebene oder dem rein lesenden Zugriff aus dem GIS auf SAP Tabellen. Solche Lösungen sind schnell, kostengünstig und problemlos in Eigenregie der Unternehmen realisierbar, dienen aber oftmals nur als Feigenblatt der jeweiligen GIS-Abteilung, um Offenheit zu demonstrieren und so die hohen Kosten der GIS Datenerfassung gegenüber Geschäftsführung oder Amtsleitung zu rechtfertigen. Durchgehende Geschäftsprozessunterstützung und damit echte Einsparungen und Qualitätsverbesserungen zur Steigerung der Wettbewerbsfähigkeit sind damit aber kaum erreichbar. Rollenverteilung Für die Immobilienbranche stellt SAP bereits seit einiger Zeit das Modul RE (Real Estate) bereit, das kürzlich in die SAP Basis integriert wurde. Mit diesem Modul lassen sich z.t. unter Einbeziehung weiterer SAP Module wie PM, FI, FI-AA, CRE, BW u.a. - insbesondere die Aspekte der Gebäudeverwaltung von der Bauplanung und durchführung über die Vermietung und Bewirtschaftung bis hin zu Anlagenbuchhaltung, Projektentwicklung und Portfoliomanagement aus einer kaufmännisch geprägten Sicht abbilden. Die Arbeiten rund um den Grund und Boden (Flurstücke/Grundstücke, Belastungen etc.) wurden dagegen bisher nur schwach unterstützt. Aus diesem Grund hat die SAP nun das Modul Land Use Management (LUM) entwickelt (s. Abb. 1). Trotz LUM wird jedoch eine GIS-basierte Verwaltung von Liegenschaften nicht überflüssig. Die graphische Lagedokumentation, Nachbarschaftsanalysen (Topologie), räumliche Analysen und thematisch-kartographische Auswertungen, geometrische Planung (z.b. Flurstücksteilung) und andere Aufgaben können durch SAP auch zukünftig nicht abgedeckt werden. Das GIS bildet daher in vielen

2 Geschäftsprozessen der Liegenschaftsverwaltung den Start- und Endpunkt (Planung, Dokumentation) und wird auch zwischendurch es bei vielen Einzelaufgaben benötigt. Abb.1: Objekte des LUM Modul im SAP R/3 (Quelle: SAP AG) Technische Möglichkeiten Die technischen Möglichkeiten für die Umsetzung einer GIS-SAP-Kopplung sind sehr vielfältig, weshalb es wichtig ist, sich als Unternehmen frühzeitig über die eigenen Anforderungen klar zu werden. Idealerweise sollten schon beim Aufsetzen der beiden Systeme die fachlichen Prozesse modelliert sein, um die Systeme so zu implementieren, dass eine geschlossene Prozessunterstützung möglich wird. Grundsätzlich gilt dabei: am einfachsten ist die Kopplung immer dann, wenn die Objekte in den Systemen fachlogisch identisch definiert sind, so dass 1:1 Beziehungen entstehen. Das mag trivial klingen, ist aber in der Praxis aufgrund der unterschiedlichen Sichtweisen (kaufmännisch vs. technisch) gar nicht so einfach. Beispielsweise ist die im SAP sehr zentrale Objektklasse Wirtschaftseinheit in GIS vielfach nicht existent. Die Integrationstechnologien lassen sich grob in drei Klassen unterscheiden, die im folgenden näher erläutert werden: 1. Einfache systemeigene Möglichkeiten wie ODBC, RFC, BAPI und bei Windows OLE/COM. 2. Tools für sogenannte Point-to-Point Kopplungen 3. Middleware-Integrationsplattformen für unternehmensweite Systemintegrationen auch zu weiteren IT-Systemen wie Dokumenten-Management, Workflow, Data Warehouse, CRM etc. auf Basis von EAI (Enterprise Application Integration) und/oder Web Architekturen. Eine spezielle Ausprägung hiervon ist der SAP GIS-Business-Connector (GBC). Während die Möglichkeiten 1 und 2 auf eine isolierte Kopplung auf Einzelaktions- oder Datenbank- Feldebene (bei BAPIs immerhin schon auf Ebene der Business Objekte, s.u.) ausgerichtet sind, bieten die Middleware Lösungen Mehrwert in den Bereichen Transaktionssicherheit, Mehrbenutzerbetrieb, Plausibilität/Regelwerke, Messaging, Queuing etc. und sind für qualitativ wie quantitativ hohe Integrationsanforderungen (z.b Transaktionen zwischen verschiedenen Systemen pro Stunde) designed und mit entsprechenden Kosten verbunden. Ein weiteres Problem der Lösungen 1 und 2 ist die Wartbarkeit, da nahezu jedes Upgrade eines der beteiligten Systeme eine Anpassung (d.h. Programmierung) der Schnittstelle erfordert (s. Abb. 2). Tatsächlich werden

3 bereits heute nach Aussage einer Studie über 40% der IT Aufwendungen in die Pflege von Schnittstellen investiert. Die Grenze zwischen 2 und 3 verläuft mittlerweile fließend. So hat etwa die CSC Ploenzke AG mit dem Java basierten, plattformunabhängigen Tool InDI (Integrated Data Interchange) eine Lösung entwickelt, um auch in kleineren Projekten einige der wesentlichen Vorteile der Middleware Philosophie umsetzen zu können, ohne durch ein vollständiges und teures EAI Tool die finanziellen und fachlichen Ressourcen der Kunden zu überfordern. Je nach Anforderung unterstützt CSC Ploenzke insbesondere in großen Projekten auch weitergehende Lösungen z.b. auf Basis von BEA Weblogic, IBM Webshpere, Tibco und anderen Produkten. CAFM MS Office Data Warehouse Workflow MS Office CAFM Data Warehouse Middleware CRM DMS DMS CRM GIS SAP GIS SAP Workflow Abb. 2: Point-to-Point vs. Middleware basierte Integration Integrationstechnologien im Detail ODBC/ OLE-DB/ ADO Ein online Zugriff auf SAP-Daten ist auf Datenbankebene (Tabellen) per Open Database Connectivity (ODBC), Object Linking and Embeding (OLE) oder Active Document Objects (ADO) möglich. Weil aber dabei keine die Systemintegrität schützende SAP-Business-Logik genutzt wird, ist dieser Weg nur für den rein lesenden Zugriff erlaubt. Die SAP AG schließt diesen Weg für den technisch möglichen schreibenden Zugriff explizit aus. Remote Function Call Die Kommunikation mittels Remote Function Call (RFC) erlaubt es, im fernen (remote) System eine in sich geschlossene Programmeinheit mit fest definierten Schnittstellen aufzurufen (in SAP die ABAP Function Modules), die die übertragenen Daten im entfernten System verarbeitet. RFCs werden häufig benutzt, um verschiedene Basis-Systeme sowie andere Systeme miteinander zu verbinden. Unterschieden werden dabei synchrone, asynchrone, transaktionale und sogenannte Queue RFC. Business Application Programming Interfaces (BAPI) Kern dieser Technik ist das Konzept der gekapselten betriebswirtschaftlichen Objekte (Business Objects). Jedes Objekt kann dabei von außen von definierten Diensten angesprochen werden, die als Business Application Programming Interfaces (BAPI) bezeichnet werden. Der Vorteil dieses Konzeptes liegt darin, dass ein Zugriff auf ein Objekt in strukturierter Form erfolgt oder gegebenenfalls nicht zugelassen wird und relativ releasestabil ist, da die Interfaces in der Regel erhalten bleiben, auch wenn sich die Strukturen dahinter (z.b. Tabellen- oder Feldnamen) ändern. Basis ist auch hier der RFC, der aber durch das Business Objekt auf ein höheres Abstraktionsniveau angehoben wird. Application Linking and Enabling Application Linking and Enabling (ALE) ist eine Lösung, mit dessen Hilfe betriebswirtschaftliche Vorgänge über Systemgrenzen hinweg auf der Grundlage einer losen Kopplung der beteiligten Systeme abgewickelt werden können. Auf diese Weise können beispielsweise zwei - räumlich wie fachlich verschiedene - SAP-Systeme miteinander verbunden werden. Dazu verwendet ALE RFCs, die sowohl synchron als auch asynchron abgesetzt werden können.

4 GIS Business Connector (GBC) Der GIS Business Connector ist ein erweitertes Integrationsmodul zur Anbindung von Fremdsystemen (insbes. von GIS) an SAP. Der Aufruf einer Methode des GBC aus einem GIS heraus geschieht über den Actional Control Broker via COM/DCOM oder CORBA. Er stellt zwischen den Business Objekten der SAP- und der GIS-Welt eine 1:n-Beziehung her und verwaltet damit die Verknüpfung korrespondierender Business Objekte. Er stellt somit eine kontrollierte Redundanz der Daten beider Systeme her. Der GBC ist für die EVU-Branche konzipiert und (nur) im Lieferumfang des Moduls IS/U enthalten, prinzipiell aber auch für andere Belange nutzbar. Nachteil ist die Notwendigkeit zur Beschaffung des Actional Control Brokers, was erhebliche Zusatzkosten verursacht. Internet Transaction Server Der Internet Transaction Server (ITS) ist SAPs erstes HTTP(S) Gateway zum Basis System. Diese Internet-Anwendungskomponente übernimmt die Steuerung der Kommunikation eines Internet- (HTTP(S)-)Servers mit dem R/3-System. Der ITS übersetzt dynamisch Anfragen ins R/3-System, die neuerdings aus den Front-Ends WebGUI oder dem SAP Portal durch den Anwender gestellt werden. Business Connector Der Business Connector ist ein weiteres HTTP(S)-Gateway zum Basissystem. Die angebotene Funktionalität hängt von der Art des eingesetzten Dienstes ab. So kann zum Beispiel ein Dienst aufgesetzt werden, der XML über HTTP(S) akzeptiert und in einen RFC Aufruf umsetzt. Ein weiterer Dienst könnte RFC Aufrufe empfangen und diesen in ein XML-Dokument umsetzen, das via HTTP(S) an den Klienten zurückgeschickt wird. Java Application Server Der Java Application Server (JAS) ist SAPs erster Java basierter Applikationsserver. Zusammen mit JCo bietet so das Basis System ein weiteres HTTP(S)-Gateway. Web Applikation Server Der Web Applikation Server (WAS) ist SAPs neueste Internet-Komponente. In Version 6.10 ist es ein HTTP(S)-fähiges Basis System, das über sog. Business Server Pages (BSP) ähnlich ASP, JSP oder Cold Fusion die gesamte Basis Funktionalität und einiger Erweiterungen bietet. BSP verwendet Javascript oder ABAP insbesondere für das Event-Handling. Da Basis integriert ist, kann der WAS mit anderen WAS und Basis Systemen über den RFC Mechanismus und obendrein mit anderen Webservern via HTTP(S) kommunizieren. Dabei überschneidet sich manche Funktionalität mit dem Business Connector und dem ITS. Sollte mit V 6.20 in diesem Sommer ITS-Funktionalität im WAS hinzukommen, erübrigt sich vielleicht die Verwendung des Business Connectors. Gehen WAS und Java Application Server (JAS) zusammen, können BSP und JSP auf dem WAS laufen und so den JAS ablösen. Portals Nach der Ausweitung des Umfangs aller durch SAP verfügbaren Module, Techniken und FrontEnds (GUI) bietet SAP als system- und anwendungsübergreifende Plattform das SAP Portal Produkt mysap Workplace an. Durch die Verwendung von sogenannten iviews ist die Einbindung von einander unabhängigen Quellen möglich. Integrationsbeispiele in der Liegenschaftsverwaltung Einzelszenarien und Funktionen für den sinnvollen Einsatz einer GIS-SAP-Kopplung in der Liegenschaftsverwaltung gibt es viele. Einige Beispiele hierfür sind: SAP Maske zu Flurstück (oder Vertragsfläche), das im GIS räumlich selektiert wurde, anzeigen Karte mit graphisch hervorgehobenem Flurstück zu einem Flurstück, das in SAP selektiert wurde, anzeigen In einer GIS Sachdatenmaske online alphanumerische Daten aus SAP auslesen und anzeigen Im GIS eine thematische Karte auf Basis von Sachdaten aus SAP erstellen (derzeit mit ArcGIS nur bei kontrollierter Redundanz möglich) Zu einem in SAP selektierten Flurstück alle Nachbarflurstücke mittels GIS ermitteln

5 Durch GIS-Verschneidung alle Flurstücke ermitteln, die Anteile an Altlastenflächen besitzen und entsprechende Informationen in SAP eintragen Ermittlung von Grundstückswerten durch GIS-Einsatz (z.b. Verschneidung mit Reichsbodenschätzungskarte) unterstützen Automatischer Datenaustausch der Server im Hintergrund zur Konsistenzsicherung und Vermeidung von Doppelarbeiten Anhand von Veränderungsprozessen am Flurstück soll nun etwas tiefer soweit es der Platz für diesen Beitrag erlaubt beleuchtet werden, wie die Arbeit mit einem integrierten SAP-GIS System in der Liegenschaftsverwaltung aussehen kann (Abb. 3). Grundsätzlich muss davon ausgegangen werden, dass eine Verknüpfungsinformation irgend einer Art zwischen dem GIS und dem SAP Objekt existiert; das können die SAP-ID als Sachdatum im GIS oder aber andere eindeutige Identifikatoren wie etwa die Kombination aus Gemarkung/Flurnummer/Flurstücknummer sein. Ist dies gegeben, können die Systeme miteinander kommunizieren, sich z.b. gegenseitig aufrufen oder fernsteuern (aus SAP ist dies nur an den sogenannten User Exits möglich). Veränderungsprozesse mit Geometrieänderungen am Flurstück beginnen in der Regel im GIS, wo die Teilung oder Verschmelzung oder größere Veränderungen etwa im Rahmen einer Flurbereinigung geplant werden. Durch Digitalisier- und Konstruktionsfunktionen auch in Alternativen kann die Änderung optimiert werden, bevor sie durch Vermessung vor Ort durchgeführt wird. Der so im GIS entstandene neue IST-Stand muss dann in SAP automatisch nachgeführt werden. Schließlich wird der Veränderungsnachweis erstellt. Und ganz am Ende wird die Veränderung nach der Beurkundung rechtsgültig und per Veränderungsmitteilung an Katasteramt und Grundbuchamt weitergeleitet. IST Stand (alt) Prozesse mit Geometrieänderung (Teilung, Verschmelzung, ÖR Verfahren..) gegenseitiges aufrufen/anzeigen Übergabe Sachdaten IST Stand (alt) Prozesse ohne Geometrieänderung (Pachtzins, Ver- Kauf, Erwerb,...) Planungsstand (Varianten) Entscheidung IST Stand (neu) Datenübergabe (update) IST Stand (neu) Veränderungsnachweis Abb. 3: Grobe Darstellung der Abläufe in einem integrierten System Ausblick Die bisherige Darstellung hat gezeigt, dass es eine Reihe von Einzelaufgaben und Aktivitäten gibt, die eine GIS-SAP-Kopplung schon sinnvoll erscheinen lassen. Zur vollständigen Geschäftsprozessunterstützung sind jedoch vielfach noch weitere IT-Systeme einzubinden. So wird etwa der Veränderungsnachweis sinnvollerweise in einem Dokumentenmanagement- oder Archiv- System dauerhaft und revisionssicher abgelegt. Die Systemintegration macht also nicht bei GIS und SAP halt. Tatsächlich entstehen die Integrationsanforderungen in den meisten Unternehmen sogar nicht ursprünglich aus der GIS-SAP Kopplung heraus. Es ist daher sinnvoll, in der Konzeptionsphase

6 diese Aspekte bereits zu berücksichtigen und die Integration so aufzusetzen, dass sie prinzipiell offen für weitere IT-Systeme ist (s. Abb. 4). ERP CRM GIS Oracle Informix Sybase ODBC Legacy & Custom Systems Regeln Daten Validierung Daten Mapping Routing Workflow Anwendungs- Adapter Datenbank Adapter Custom Adapter Message Brokering Information Transport B2B Externer Business Process Publish Information Portale Internet Internet Wireless Portal Abb. 4: Unternehmensweites Integrationsszenario (Quelle: Tibco) CSC Ploenzke ist als einer der größten IT-Dienstleister Deutschlands in der Systemintegration zu Hause und beschäftigt sich seit 1997 auch mit der Kopplung von GIS und SAP in verschiedenen Branchen. Für weitere Informationen stehen Ihnen die Autoren gerne zur Verfügung. Die verschiedenen technischen Möglichkeiten werden - etwas detaillierter als an dieser Stelle möglich - im Rahmen eines Vortrags der Autoren auf der ESRI 2002 in Essen vorgestellt Marc Kleemann CSC Ploenzke AG Business Unit Defense West Ubierstr. 94 Ubierstr Bonn Bonn Roland Stahl CSC Ploenzke AG Business Unit ÖS West Tel.: Tel.: Mkleeman@csc.com Rstahl2@csc.com