ERFAHRUNG 21 projektManagementaktuell | AUSGABE 1.2016 Nach dem Kauf eines Unternehmens ist häufig die Harmonisierung der IT-Systeme eine der größten Herausforderungen. Bei dem Immobiliendienstleister PlanetHome war dies der Fall, als die österreichische Firma PlanetHome Immobilien Austria (PH-IA) in die bestehende IT-Landschaft eingegliedert werden sollte. Mithilfe der Consileon Business Consultancy GmbH wurde die PH-IA in das bestehende Provisionsabrechnungs- und Controllingsystem ConProv integriert. 1. Herausforderungen Das Projekt wurde vor folgende Herausforderung gestellt: • Es gab einen relativ straffen Zeitplan, da ein Go-Live nur zum Jahreswechsel (d. h. sieben Monate Umsetzungszeit) möglich war. • Der Umsetzungsaufwand sollte möglichst gering gehalten werden, wobei keine Qualitätseinbußen akzeptabel waren, da die Gehaltsabrechnung und Provisionsberechnung sehr sensible Themen sind. • Das Projekt sollte dazu genutzt werden, um die PlanetHome-IT in das Customizing des Softwareprodukts ConProv einzuarbeiten. • Das Produktionssystem wurde permanent weiterentwickelt und an neue Anforderungen angepasst. Der Betrieb und die Entwicklung durften durch das Projekt nicht beeinträchtigt werden. • Eine Anbindung an das Objektverwaltungssystem und das Buchhaltungssystem der Tochterfirma mussten erfolgen. Wie konnte unter diesen Voraussetzungen ein erfolgreiches Projekt realisiert werden? Zur Eingliederung in das bestehende System haben der Dienstleister und der Kunde gemeinsam ein spezielles iteratives Vorgehensmodell gewählt, das hier vorgestellt werden soll. 2. Vorgehensmodell Im Gegensatz zum klassischen Wasserfallmodell gab es keine Feinkonzeption; stattdessen wurde direkt nach der Grobkonzeption mit der iterativen Umsetzung begonnen. Dabei konnte bewusst auf die Kenntnis einiger Detailaspekte des Altsystems verzichtet werden, weil das Zielsystem ConProv zum Teil andere und effizientere Mechanismen als das Altsystem bereitstellt. Das gewählte iterative Vorgehen ist durch zwei Grundprinzipien gekennzeichnet, die sich auch auf andere Projektsituationen übertragen lassen. Die Iterationen wurden zuerst in zwei Phasen unterteilt. Durch die Iterationen der ersten Phase wurden alle Änderungen implementiert, die Modifikationen in bestehenden Prozessen erforderten. Nach Abschluss der ersten Phase erfolgte bereits eine erste Produktivnahme. Hierdurch konnte die Zeit minimiert werden, in der konkurrierend in zwei unabhängigen Arbeitssträngen - dem Migrationsprojekt und der normalen Weiterentwicklung des Systems - am gleichen Code gearbeitet wird. Die Iterationen der zweiten Phase bestanden ausschließlich aus Funktionen, die nur die zu migrierende Gesellschaft betrafen. Deshalb war am Ende der zweiten Phase kein aufwendiger Merge und Regressionstest des Restsystems mehr erforderlich. Das zweite Grundprinzip war die Konzentration auf horizontale (thematische) Teilbereiche in jeder einzelnen Iteration, die durch die Iteration vollständig realisiert wurden. Es wurde auf vertikale Schnitte über mehrere Themen verzichtet, um einen bestimmten Aspekt vollständig und umfassend umsetzen zu können und eine hohe Fokussierung der Projektmitarbeiter zu erreichen. Dadurch wurden auch zwischen den einzelnen Iterationen Live-Gänge möglich, ohne das Risiko von späterer Datenbereinigung einzugehen. Im Folgenden sollen die einzelnen Iterationsstufen betrachtet werden: 1. Iterationsstufe - Anpassen des Bestandssystems an neue Basisanforderungen: Im konkreten Fall musste die Mandantenstruktur umgestaltet werden, damit sich die neue Gesellschaft in die Struktur einfügt. 2. Iterationsstufe - Anpassungen der Oberfläche: ConProv verfügt über eine klassische Client-Server-Architektur, wobei die Oberfläche über XML-Dateien und Datenbank- Erfolgreiche Projektmethodik zur Harmonisierung der IT-Landschaft Integration in ein individuell angepasstes Softwareprodukt Autoren: Stefan Kallinich, Stefanie Brock >> Für eilige Leser Die speziellen Anforderungen konnten bei der Integration einer Tochtergesellschaft in das bestehende IT-System nicht mit klassischen Projektvorgehensmodellen realisiert werden. Weder ermöglichten klassische Modelle eine Umsetzung im strengen Zeitplan, z. B. weil eine Feinkonzeption einen zu hohen Zeitaufwand am Projektanfang benötigt, noch waren etablierte agile Methoden wie Scrum für die Realisierung geeignet, da hierbei weder das Budget noch der genaue Realisierungsumfang zu Beginn des Projekts bekannt sind. Stattdessen wurde ein spezielles iteratives Vorgehensmodell entwickelt und verwendet. Das Projekt konnte dadurch zum erfolgreichen Abschluss geführt werden. Das Verfahren ist für ähnliche Projekte in anderen Unternehmen sehr gut anwendbar. PM-aktuell_1-2016_Inhalt_01-68.indd 21 29.01.2016 8: 18: 30 Uhr projektManagementaktuell | AUSGABE 1.2016 22 ERFAHRUNG stehende System nicht mehr verändert werden musste, sondern nur neue zusätzliche Aspekte (in diesem Fall in einem gekapselten Mandanten) hinzukamen. Die Entwicklungen der nachfolgenden Iterationsstufen zogen insgesamt keine weiteren Änderungen der produktiven Systemteile nach sich, wodurch die Projektrisiken stark minimiert werden konnten. 2. Vor dem Live-Gang fand ein ausführlicher Test aller Systemkomponenten statt. Dazu wurde der aktuelle Monatsabschluss mit allen Aktivitäten auf dem Testsystem wiederholt und es wurde überprüft, ob die gleichen Ergebnisse ermittelt werden. 2. Durch die relativ lange Testphase von zwei Wochen musste auch währenddessen mit der nächsten Iteration fortgefahren werden. Gefundene Fehler mussten zeitnah behoben verwaltet werden. Des Weiteren wurde in diesem Schritt die Berechnung der Mehrwertsteuer flexibilisiert, um verschiedene Steuersätze in Österreich und Deutschland besser abbilden zu können. 2. Nach diesen Schritten erfolgte ein erster Live- Gang der bisher umgesetzten Teilaspekte. Der Hauptbeweggrund dafür war, dass die Entwicklungs- und die Produktivumgebung nicht zu weit auseinanderlaufen. Das bestehende System ist fortlaufend neuen Anforderungen (beispielsweise durch neue Kooperationspartner) unterworfen und muss deshalb stetig angepasst werden. Durch den Live- Gang konnten die Änderungen direkt auf der angepassten Architektur entwickelt werden, eine spätere Korrektur war nicht nötig. Nach der dritten Iterationsstufe war die Umsetzung so weit abgeschlossen, dass das beobjekte konfiguriert wird. Dabei wurden nur zwingend notwendige Änderungen ausgeführt; zum einen, um für die Wartbarkeit möglichst geringe Abweichung zwischen den Mandanten zu erzeugen, zum anderen, um den Umsetzungsaufwand so gering wie möglich zu halten. 3. Iterationsstufe - Anpassung des bestehenden Vertragsberechnungsschemas: Die Verträge (konkret Immobilienvermittlungen) durchlaufen verschiedene Prozessschritte (primär: Forderung, Zahlungseingang, Abrechnung, Korrektur und Storno). Ein Großteil der Berechnungen konnte auch für die PH-IA genutzt werden. Dafür waren einige Anpassungen notwendig. Beispielsweise wurde vorher die Gesellschaft (PlanetHome) fest hinterlegt; nun musste diese berechnet werden, weil auch PH-IA-Verträge Abb. 1: Schematische Darstellung des Systems: In ConProv (das Vorbuchhaltungssystem der PlanetHome) wurde eine neue Tochtergesellschaft - die PH-IA - integriert. Diese fügt sich in die bestehende Mandantenstruktur ein und kann dadurch Daten (z. B. Bereichsstruktur) und Einstellungen (z. B. Berechnungsregeln) von dem bestehenden System nutzen. Das Hauptobjekt in dem von PlanetHome genutzten ConProv-System sind die Verträge (konkret: Immobilienvermittlungen), die vereinfacht gesprochen alle Akteure und Berechnungen beinhalten. Der Datenimport erfolgt von einem parallel betriebenen Objektverwaltungssystem, welches ähnlich dem bestehenden System gestaltet wurde. Die bestehende relationale Datenbank konnte unverändert weiterverwendet werden, während neue Reporte sowie ein angepasster Buchhaltungsexport nötig waren. PM-aktuell_1-2016_Inhalt_01-68.indd 22 29.01.2016 8: 18: 38 Uhr ERFAHRUNG 23 projektManagementaktuell | AUSGABE 1.2016 portiert. Die offenen Altverträge werden weiterhin im Altsystem berechnet und die Monatsabrechnung wird anschließend manuell zusammengeführt. Dies war möglich, weil das Gehaltsmodell ohne die alten Verträge die richtigen Werte ermitteln kann und weil die Anzahl der offenen Verträge übersichtlich war. 2. Der ungefähre monatliche Mehraufwand von 3 bis 5 Stunden während einer überschaubaren Interimszeit ist damit deutlich geringer als der geschätzte Migrationsaufwand. Zumal nur durch diese Einschränkung eine Realisierung zum Jahreswechsel möglich war. Insgesamt stellt sich die Migration in vielen Projekten als eine große Herausforderung dar, insbesondere bei schlechter Datenqualität und umfangreichen Prozessanpassungen. Ein temporärer Parallelbetrieb von Alt- und Neusystemen, eventuell gekoppelt mit einer pauschalen Abgeltung, kann in bestimmten Fällen eine interessante Alternative darstellen. Damit war das Projekt erfolgreich abgeschlossen und der zweite Live-Gang konnte erfolgen. Nach jeder Iterationsstufe wurden die jeweils umgesetzten Aspekte getestet. Vor dem Live- Gang fand ein weiterer ausführlicher Abnahmetest statt. Die Detailabstimmungen waren jeweils Teil der aktuellen Iterationsstufe, was einen erheblich geringeren Aufwand bedeutet im Vergleich zu einer vorgelagerten Feinkonzeption. Die zessen zur Abrechnung (separat für Mitarbeiter und externe Vermittler) auch die Berechnungslogik für die Abrechnung der beiden Zielgruppen erstellt. 6. Iterationsstufe - Abfragen und Reporte: Die mit ConProv erstellten Daten mussten für Kunden (Rechnungen), Vermittler (Abrechnungen) und Management (Auswertungen) nutzbar gemacht werden. Hierfür wurden neue Abfragen und Reporte erstellt und alte modifiziert. 7. Iterationsstufe - Erstellung der Schnittstellen: Das Hauptbuchhaltungssystem wird gemeinsam von PlanetHome und der PH-IA verwendet. Deshalb mussten ausschließlich die zu exportierenden Buchungen konfiguriert werden. Die bestehenden Buchungen dienten dabei als Vorlage. Die eigentliche Schnittstelle konnte weiterverwendet werden. 2. Die Datenlieferung erfolgt aus einem separaten Objektverwaltungssystem, welches ähnlich dem existierenden Datenlieferungssystem aufgestellt ist. An dieser Stelle wurde zwar aus technischen Gründen eine separate Schnittstelle benötigt, welche aber viele Teile der existierenden Schnittstelle verwenden konnte. 8. Iterationsstufe - Migration: Eine Besonderheit in diesem Projekt war, dass auf eine Migration der alten Verträge verzichtet wurde. Stattdessen wurden ausschließlich die bestehenden Makler mit ihren Gehaltsregeln imwerden, um den Live-Gang sicherzustellen. Hierbei galt es, ein besonderes Augenmerk auf die verschiedenen Versionen zu richten, damit bereits behobene Fehler nicht erneut auftreten. In dieser Phase erwiesen sich die fachlichen Ressourcen des Kunden als Engpass. Diese mussten neben dem Tagesgeschäft sowohl Testen als auch die weitere Feinabstimmungen für das Projekt begleiten. Dieser Herausforderung wurde begegnet, indem relativ sichere Teilaspekte aus der 4. Iterationsstufe bereits umgesetzt wurden und die vollständige Konzeption somit nicht am Anfang der Projektphase stand. Im Nachhinein wären alternativ auch ausführliche Absprachen bereits während der 3. Iterationsstufe sinnvoll gewesen. 4. Iterationsstufe - neue Berechnungslogik für Verträge: Zusätzlich zu den Änderungen an der bestehenden Berechnungslogik waren einige neue Berechnungen notwendig. Die Anforderungen richteten sich insbesondere nach den buchhalterischen Anforderungen, dem geplanten Reporting und dem Provisionsabrechnungsmodell der Mitarbeiter. Dazu müssen alle (Zwischen-)Rechenschritte im System festgehalten werden, die später ausgelesen werden sollen - z. B. auch Prozentwerte, die erläutern, wie ein bestimmter Euro-Auszahlungsbetrag ermittelt wurde. 5. Iterationsstufe - Abrechnungsprozess: Hierbei wurde neben den eigentlichen Pro- Abb. 2: Übersicht des Vorgehensmodells PM-aktuell_1-2016_Inhalt_01-68.indd 23 29.01.2016 8: 18: 44 Uhr projektManagementaktuell | AUSGABE 1.2016 24 ERFAHRUNG Schlagwörter Harmonisierung, Iteration, Projektmanagement, Projektmethodik, Scrum, Softwareprodukt, Tochtergesellschaft, Wasserfall Kompetenzelemente der ICB 4.0 3.05 Organisation, Information und Dokumentation, 3.04 Ablauf und Termine, 3.13 Change und Transformation Autoren Stefan Kallinich, Spezialist für Vertriebssteuerung und Provisionssysteme bei der Consileon Business Consultancy GmbH; duales Bachelorstudium an der HWR Berlin in Wirtschaftsinformatik mit dem Praxispartner IBM Deutschland GmbH, Graduate Diploma of Commerce in Economics an der Victoria University of Wellington, Neuseeland Anschrift: Consileon Business Consultancy GmbH, Maximilianstraße 5, 76133 Karlsruhe, Tel.: 0173/ 6 12 50 22, E-Mail: Stefan.Kallinich @consileon.de Stefanie Brock, Teamleiterin Vertriebscontrolling bei der PlanetHome AG; Bankfachwirtin an der Frankfurt School of Finance & Management Anschrift: PlanetHome AG, Apianstraße 8, 85774 München/ Unterföhring, Tel.: 089/ 76 77 42 41, E-Mail: Stefanie.Brock@planet home.com gemeinsam von einem Mitarbeiter des Dienstleisters und einer Mitarbeiterin aus der Fachabteilung übernommen. Als Erfolgsfaktor für das Projektergebnis hat sich zum einen die Zusammenarbeit zwischen Auftragnehmer und Auftraggeber gezeigt. So ist es wichtig, Verständnis für die Ziele und Belange des jeweils anderen zu entwickeln und damit zu rechnen, dass sich Anforderungen auch mal ändern. Zum anderen war das Anforderungsmanagement ein Schlüsselbereich. Es wurde von Anfang an darauf geachtet, die Prozesse möglichst identisch zum bestehenden System zu gestalten. Außerdem wurde bei speziellen Anforderungen immer eine Abwägung zwischen Aufwand und Nutzen durchgeführt und zum Beispiel einige Modalitäten an das bestehende Modell angeglichen. 4. Fazit Mit dem iterativen Vorgehen ohne vorgelagerte Feinkonzeption musste nicht auf eine Budgetplanung oder eine genaue Planung des Projektumfangs verzichtet werden. Sowohl der zeitliche als auch der budgetäre Rahmen wurde während der gesamten Projektlaufzeit nicht überschritten. Selbst die finanziellen Reserven, die aufgrund der iterativen Vorgehensweise sicherheitshalber eingeplant wurden, mussten letztlich nicht angetastet werden. Durch die Grobeinteilung der Themen in zwei Blöcke, solche, die das bestehende System beeinflussen, sowie weitere Zusatzanforderungen, wurde ein zweiteiliger Live-Gang möglich. Dadurch konnten die Wartbarkeit und die parallele Weiterentwicklung des Produktivsystems massiv vereinfacht werden. Wie bei vielen Projekten hat sich auch in diesem Projekt das Anforderungsmanagement als einer der wichtigsten Erfolgsfaktoren herauskristallisiert. Mit dem Live-Gang und dem erfolgreichen Betrieb konnte des Weiteren bewiesen werden, dass es durchaus Konstellationen gibt, bei denen auf den aufwendigen und risikoreichen Block der Migration verzichtet werden kann. Insgesamt hat das Projekt gezeigt, dass eine ausführliche Feinkonzeption nicht zwangsläufig notwendig ist. Das spezielle iterative Vorgehen mit einer Einteilung in die verschiedenen Themenbereiche hat zu einem schnelleren und kostengünstigeren Projekt geführt, bei gleichzeitig optimaler Qualität.  Fachabteilung war dadurch während des gesamten Verlaufs in das Projektgeschehen integriert. Dies gewährleistete zum einen aufgrund des schnellen Zwischen-Feedbacks eine hohe Qualität. Zum anderen war auf diese Weise der projektbedingte Mehraufwand für die Fachabteilung gleichmäßiger verteilt als bei einer engen Einbindung in die Feinkonzeption und einem einmaligen Abnahmetest. Dies erst hat die parallele Bearbeitung von Tagesgeschäft und Projekttätigkeit ermöglicht. Während jeder Phase wurden für die IT-Ressourcen des Kunden Schulungen und Coachings zu den aktuellen Themen der Iterationsstufe durchgeführt. Dadurch konnte das erworbene Wissen gleich bei der darauffolgenden Umsetzung angewendet und verinnerlicht werden. Grundsätzlich waren die Iterationen darauf angelegt, nacheinander ausgeführt zu werden. Allerdings wurden einige Aktivitäten parallelisiert, wodurch insbesondere die Experten (z. B. für Schnittstellen) gleichmäßiger über den Projektverlauf integriert werden konnten und sich dadurch die Projektzeit noch etwas verkürzte. Dieses spezielle Vorgehensmodell wich in einigen Punkten von den etablierten agilen Methoden ab, insbesondere war die Phasendauer flexibel. Jede Iteration wurde zwar durch den Anwender getestet, zusätzliche Live-Gänge (nach jeder Iteration wie z. B. bei Scrum üblich) waren nicht eingeplant. Außerdem wurden aus Budgetierungsgründen der Projektumfang und die Aufteilung zwischen Consileon und PlanetHome größtenteils vorab definiert, anstatt, wie sonst oft üblich, vor den einzelnen Iterationen. Dieses speziell entwickelte Projektvorgehen hatte anfangs Akzeptanzschwierigkeiten, weil sich die Risiken mit einer vorgelagerten Feinkonzeption i. d. R. besser abschätzen lassen. Ausschlaggebend für die Entscheidung, dieses Vorgehen trotzdem zu wählen, waren die erwartete Fertigstellung zum Jahresende, was anders nicht möglich gewesen wäre, und der geringere Gesamtaufwand als bei den Alternativen. 3. Projektorganisation Die Größe und Zusammensetzung des Teams wurde mit jeder Phase an den Bedarf angepasst. Im Schnitt waren zwei bis vier Experten des Dienstleisters und bis zu drei IT-Mitarbeiter des Kunden eingebunden. Zusätzlich gab es zwei Mitarbeiter der Fachabteilung, die fest in das Projekt integriert waren. Die Projektleitung wurde PM-aktuell_1-2016_Inhalt_01-68.indd 24 29.01.2016 8: 18: 44 Uhr