« zurück zur Übersicht

Bettina Wenzel, Projektmitarbeiterin der HDP GmbH, schildert, wie der Cusa-Hersteller in Hamburg aufgenommen wurde und die Einführung der Branchen­lösung erfolgreich gestaltet werden konnte.

Die Cusa-Einführung ist größtenteils durch Mitarbeiter der Berufs­genossenschaft für Fahr­zeug­haltungen (BGF) durchgeführt worden. Was war Ihre Aufgabe im Projekt­team der HDP GmbH?

Ich habe den Bereich der technischen Installation und die Koordination der Dritt­partner betreut. Wir haben mehrere Produkte im Einsatz: SmartDCI der Firma PKS, WebTa für die grafische Oberfläche von der Firma Fujitsu Siemens Computers (FSC), und das Zusammen­spiel der Oracle- und Adabas-Datenbanken. Durch­geführt wurde die Einführung von Mit­arbeitern der Software AG, FSC und PKS. Ich habe zudem das Produktfeld Renten­zahl­verfahren koordiniert.

Wie wurden Sie als „Hersteller“ aufgenommen und wie war die Zusammen­arbeit mit bei der BGF?

Hervorragend! Wenn man mit den jeweiligen Zuständigen gesprochen hat, waren alle kooperativ und haben sich eingesetzt. Anfangs waren viele etwas verhalten, sie merkten aber schnell, dass wir von HDP ein offenes Ohr haben und unter­stützen wollen. Unsere Zusammen­arbeit lief auf Augen­höhe ab und alle Beteiligten waren extrem motiviert.

Das klingt sehr positiv. Wie kann man sich Ihre Arbeit im Detail vorstellen?

Ich habe immer mit Einzel­personen, zwei oder drei Leuten gearbeitet. Wir haben uns oft im Rechen­zentrum zusammen gesetzt. Nachdem wir gemeinsam mit unserem Dritt­partner die technischen Installationen erfolg­reich abgeschlossen hatten, haben wir mit der Software-Installationen von Cusa begonnen. Ich habe dabei die Installation für das Renten­zahl­verfahren betreut.

Des Weiteren musste Cusa auf den Kunden angepasst werden. Diese Adaption setzte sich aus vielen Einzel­teilen zusammen, wie z.B. dem objekt­basierten Regel­werk. Für diesen Bereich war eine Arbeits­gruppe zuständig, dies sich aus bis zu 15 BGF-Experten zusammenstellte. Diese Gruppe wurde von Gabriele Barth betreut. Die Teams wiederum setzten sich aus bis zu 15 Multi­plikatoren zusammen.

Nach der Daten­migration hat diese Gruppe auch die Qualitäts­prüfung der Daten aus der Daten­migration durchgeführt.  

Sie sprechen die Daten­migration an. Was genau ist das Rentenzahlverfahren und welche Daten mussten umziehen?

Der Prozess des Renten­zahl­verfahrens ist vom Rentenservice vorgegeben. Die Datenmigration sah dabei so aus, dass der Renten­service den aktuellen Bestand zur Verfügung stellte, und diese Daten in die Bestands­daten geladen wurden. Dabei handelte es sich um circa 30.000 bis 40.000 Renten. Ein Datensatz für diesen Prozess setzte sich dabei u.a. aus dem Namen, der Adresse, dem Zahlungs­empfänger und dem Berechtigten zusammen. Diese Daten liegen beim Renten­service vor. Die Zahlung findet anschließend ebenfalls über den Renten­service statt.

Worauf musste bei einer Daten­migration besonders geachtet werden?

Beim Renten­zahl­verfahren haben wir das Problem, das bestimmte Termine fest vorgegeben sind. Diese müssen eingehalten werden, ansonsten werden Renten nicht pünktlich gezahlt. Man muss während des laufenden Betriebes den Daten­bestand abziehen und danach wieder einspielen. Innerhalb einer Woche musste der Kunde mit diesem Bestand produktiv arbeiten, um die nächsten Forderungen an den Rentenservice weiterreichen zu können. Das haben wir mehrmals geprobt. Dann wurde die Maschine abgestellt, die Stamm­daten genutzt und die Migration für das Renten­zahl­verfahren gestartet. Dabei mussten neue Fälle ein paar Tage auf die Bearbeitung warten. Innerhalb von nur drei Tagen konnten die ganzen an­stehenden Änderungen für das Renten­zahl­verfahren eingepflegt werden, und an den Renten­service termin­gerecht gemeldet werden. Das Vertrauen unseres Kunden, dass das alles klappen wird, war vorhanden, und dementsprechend hat auch alles funktioniert.

Das klingt recht einfach. Gab es Probleme und wie ist das in vergleichbaren Projekten abgelaufen?

Alles lief so gut wie nach Plan. Aus­gehend vom vorliegenden Daten­volumen von ein paar Millionen Unfällen ist die Migration innerhalb eines kurzen Zeit­raumes abgelaufen. Die sehr gute Datenqualität aus der Migration ist ein Indiz dafür, dass diese Migration die HDP betreut hat, im Vergleich zu anderen Firmen und anderen Daten­migrations­projekten richtig gut verlief.

bei der BGF wird nun seit Dezember 2008 mit Cusa gearbeitet. Gibt es bereits erste Erfahrungen mit dem Einsatz von Cusa?

Im Renten­zahl­verfahren hatten wir keine Probleme und die BGF hat das sehr gut im Griff. Die Hälfte der Support-Anfragen sind Know-how-Anfragen, was ganz normal ist, wenn ein neues System eingeführt wird. Rück­meldungen zu Fehlern gab es nur wenige. Circa ein Drittel der gemeldeten Probleme, können zu Neu­anforderungen gezählt werden.

Ein sehr umfangreiches Projekt ist gut abge­schlossen worden. Welches Fazit ziehen Sie nach dieser erfolg­reichen Cusa-Einführung?

Das Besondere für mich war, dass die Daten­migration so problemlos funktioniert hat und dass die BGF mit einer sehr guten Daten­qualität produktiv starten konnte. Die fehler­bedingten Rückmeldungen fielen dem­entsprechend gering aus. Dass dieses Projekt generell so vorbildlich gelaufen ist, lag auch an Gabriele Barth. Sie war oft in Hamburg und hat immer den persönlichen Kontakt aufrecht erhalten. Zusammen­fassend kann man sagen, dass die positive Ein­stellung von beiden Seiten die wichtigste Basis dafür war, dass dieses Projekt so toll gelaufen ist.

Interview drucken

Podcast-Feature

100 Tage Cusa: Das gesamte Projekt in 20 Minuten
» Podcast anhören

Die Firmen

Kontakt

Bei Fragen zu „100-Tage-Cusa“ wenden Sie sich bitte an:

BGF: Frank Hellwig
Telefon: 040 3980 - 0
E-Mail: Info@BGF.de

HDP: Gerulf Ketz
Telefon: 06731 990 - 545
E-Mail: KetzG@HDPGmbH.de

Im Überblick