Forster_Aust_T_Punkt_ShopDB_Summary_v6 - Opal
Werbung
T-Punkt Shop-DB: Standortauswahl mit Workflow und Geomarketing; Migration von MS Access auf Apex 2.2 Michael Forster T-Punkt Vertriebsgesellschaft mbH, Bonn Dietmar Aust Opal-Consulting, Köln Schlüsselworte: Application Express 2.2, Workflow, Geomarketing, ODBC, MS Access Einleitung Die T-Punkt Vertriebsgesellschaft (TPG) ist der konzerneigene stationäre Vertriebskanal der Deutschen Telekom in Deutschland. Mehr als 6.000 Mitarbeiter und rund 1.400 Auszubildende betreuen jährlich rund 60 Millionen Privatkunden und 2,5 Millionen mittelständische Geschäftskunden. Das Unternehmen betreibt derzeit 700 T-Punkte in Deutschland und eröffnet laufend weitere Standorte. Bis zum Ende des Jahres sind insgesamt 786 T-Punkte geplant. Die Analyse zur Erreichung dieses Expansionszieles hat einige Mängel im Prozess der Standortfindung und -eröffnung (fehlende Abstimmung, Transparenz, Schritte dauern zu lange) sowie Mängel technischer Natur ergeben (Medienbrüche, redundante und fehlerhafte Adressen, kein zentrales Repository der Standorte). Der Aufbau einer „Shop Datenbank“ wurde als zentrales Handlungsfeld der Prozessoptimierung identifiziert. Anforderungen Kernziele waren der Aufbau einer zentralen Standortdatenbank/Shop DB sowie die Implementierung eines Workflow Management Tools zur Reduzierung der Durchlaufzeiten im Shop Rollout, d.h Implementierung einer zentralen Shop-Datenbank mit allen relevanten Daten inkl. Geo-Kodierung aller erfassten Standorte Umsetzung und Detaillierung des „neuen“ Shop Roll-Out Prozesses. Implementierung eines Workflow Management Tools zur prozessualen Unterstützung der Roll-Out Factory. Konsolidierung und Vereinheitlichung des Shop-Monitoring. Die vorhandene MS Access Datenbank FM DB soll weiterhin genutzt werden. Die MS Excel VP-Nummernliste mit deren Funktionalitäten (u.a. automatischer Mailversand) soll in die FM DB integriert werden. Der Zeitrahmen von der ersten Anforderungsaufnahme (März), dem Projektstart (April) bis zur Lieferung des ersten Prototypen (Mai) und der Wirkbetriebsaufnahme (Version 0.6 am 13 Juni und Version 1.0 am 10 August) war extrem ambitioniert. Viele Details der Realisierung waren bei Projektstart unklar Für die Umsetzung haben wir daher ein extrem iteratives Vorgehen mit wöchentlichen Prototypen gewählt, um die Fachbereiche möglichst nah in den Entwicklungsprozess einzubinden. Realisierung Die technische Infrastruktur besteht dabei aus den folgenden Komponenten: Abb. 1: Systemarchitektur Zwei Hardware Load Balancer verteilen die Anfragen auf zwei redundant ausgelegte Applikationsserver (Linux Redhat 4 mit Oracle Internet Application Server 10.1.3). Die beiden Applikationsserver greifen dann über das Apache Modul mod_plsql auf die beiden RAC Knoten der Oracle Datenbank zu (Oracle 10.2.0.1 auf Solaris 10). Die Integration der Geokomponenten erfolgt dabei aus der Datenbank heraus, sie fungiert dabei als Proxy für die Anfragen. Als Visualisierungskomponente wird die MapSuite 2.6 von der Fa. Infoware eingesetzt. Die Shapefiles (Geometrien und Metadaten) werden durch die Fachabteilung bereitgestellt und können durch die Applikation dynamisch aktiviert werden. Zur Geokodierung von Adressen wird die Software JCoder Business Server 2.2 der Fa. Infas Geodaten eingesetzt. Beide Systeme werden als Windows-Dienste auf einem Windows 2003 Server betrieben und über http angesprochen. Die MS Access Applikationen werden vorerst weiter genutzt und greifen über ODBC auf den migrierten Datenbestand zu. MS Access Applikationen weiter nutzen Dieser Teil war eine der größten Herausforderungen im Projekt. Es musste ein neues Datenmodell entwickelt und die existierenden Daten aus MS Access dahin migriert werden. Die existierenden Applikationen sollten jedoch ohne größere Umbauten weiter genutzt werden, da aufgrund des engen Zeitplanes nur eine schrittweise Ablösung der MS Access Clients möglich war. Weiterhin sollte die Downtime für die Datenübernahme niedrig gehalten werden und bis zuletzt wurden Änderungen am System vorgenommen. Daher haben wir uns für folgendes Vorgehen entschieden: Glättung der Tabellen- und Spaltennamen mit Hilfe eines VBA – Skriptes. Wie in Access üblich werden die Namen in gemischter Groß-/Kleinschreibung und mit Sonderzeichen versehen, gerne >30 Zeichen. Mit Hilfe von Oracle Heterogenous Services wurde ein Datenbank-Link auf die ODBC Datenquelle eingerichtet. Über den Datenbank-Link konnte dann ein normaler ETL-Prozess in PL/SQL umgesetzt werden, der die Daten direkt aus MS Access in Oracle überführt. In Oracle wurden Views bereitgestellt, um das Datenmodell in MS Access zu emulieren. In MS Access wurden die Oracle Views über ODBC verlinkt und Abfragen darauf erstellt, die der ursprünglichen Namenskonvention entsprachen. Somit war für die existierenden Applikationen transparent, dass sie nunmehr auf Oracle anstatt auf die internen MS Access Tabellen zugreifen. Als ODBC Layer wurde der Oracle Instant Client auf den entsprechenden Rechnern von einem gemeinsamen Netzlaufwerk genutzt. Die Übernahme selbst hat nur wenige Minuten in Anspruch genommen. Workflow – Umsetzung Der Workflow wurde mit Hilfe der Open Source PL/SQL engine pl/flow umgesetzt (http://plflow.sourceforge.net/) . Diese hat zwar kein GUI für die Prozessdefinition, eignet sich jedoch sehr gut für eine direkte Integration in eine Applikation. Es wurden zwei nichtlineare Workflow-Prozesse umgesetzt, einen für die Eröffnung eines Partner-Standortes und einen für die Eröffnung eines Own-Shops der TPG. Geokodierung Zur Geokodierung von Standorten wird der JCoder Business Server 2.2 der Fa. Infas Geodaten eingesetzt. Damit wird sichergestellt, dass die Schreibweise von Standorten immer eindeutig ist. Durch die Geokodierung können die Standorte auf der Karte eingezeichnet werden. Weiterhin kann auch so vermieden werden, dass Standorte nur in einem gewissen Abstand zu existierenden Standorten eingereicht werden. Visualisierung Für die Visualisierung wurde die Software MapSuite 2.6 der Fa. Infoware eingesetzt. Dies ist keine fertige Lösung, sondern liefert als Toolkit nur die Bausteine, um die Karten darzustellen. So genannte Shapefiles können Flächen (z.B. Konsumschwerpunkte, PLZ-Gebiete, etc.) als auch Punkte (z.B. T-Punkte, geplante Expansionsstandorte, Konkurrenz) darstellen. Abb. 2: T-Punkte und Konkurrenz Diese Shapefiles können statisch oder auch dynamisch verwendet werden. Sie können auch abhängig von der dargestellten Auflösung der Karte eingeblendet werden. Z.B., in der Gesamtsicht von Deutschland werden die T-Punkte nicht angezeigt, sondern erst, wenn man die Karte auf die Darstellung der Städte vergrößert. Dann erst werden auch die Namen kleinerer Orte angezeigt. Über eine URL-basierte API wird der Kartenserver angesprochen und liefert die Kartendarstellung als PNG-Grafik sowie die Metadaten in XML über http. Abb. 3: Visualisierung von Flächen Fazit In einem extrem kurzen Zeitrahmen wurde dieses Projekt zur vollsten Zufriedenheit der Fachbereiche umgesetzt. Bereits nach wenigen Wochen der Realisierung konnte die Version 0.6 produktiv geschaltet werden, in der Kernfunktionalitäten umgesetzt wurden, so dass der Expansionsprozess strukturiert und transparent begleitet wurde. Mittlerweile ist der Umfang der Version 1.0 vollständig umgesetzt. Die wesentlichen Erfolgsfaktoren dabei waren: Wöchentliche Prototyp-Zyklen Nutzung von Oracle Application Express Stufenweise Ablösung der MS Access Clients Kontaktadressen: Michael Forster Landgrabenweg 147 D-53227 Bonn Dietmar Aust Am Weißen Stein 10 D-51143 Köln Telefon: Fax: E-Mail Internet: Telefon: Fax: E-Mail Internet: +49(0)228-92723410 +49(0)228-92723419 [email protected] http://www.t-punkt.de +49(0)173-5322955 +49(0)2203-800431 [email protected] http://www.opal-consulting.de
