1. Die ERP-Landschaft hat sich in Ihrem Unternehmen über Jahre heterogen funktional und technisch weiterentwickelt und ist nun durch einen Mix von Standardfunktionen und individuellen Zusatzentwicklungen sehr  komplex geworden

2. Die Stammdaten (Kunden, Lieferanten, Produkte etc) sind bei Ihnen in verschiedenen IT-Systemen enthalten und müssen permanent zusammengeführt werden. Ein eindeutig „führendes System“ bzw. ein zentrales Masterdata-Management ist nicht vorhanden. Dieses führt zu Risiken, Redundanzen und unklaren Verantwortlichkeiten für die Datenqualität.

3. Aufgrund von Unternehmensveränderungen (z.B. Zukäufe) sind verschiedene ERP-Systeme (oder verschiedene Version desselben ERP-Systems) im Einsatz, die technisch verbunden oder inhaltlich zusammengeführt werden müssen. Ohne eine solche Zusammenführung ergeben sich Datenredundanzen oder Aufwand durch manuelle Zusammenführung, die zusätzlich mit neuen Risiken verbunden sind.

4. Bilanzierungsrichtlinien (z.B. SOX-Anforderungen) haben sich verschärft und Sie müssen die Systemdurchgängigkeit und Datenintegrität garantieren. Dieses ist in einem konsolidierten System erheblich einfacher und kostengünstiger als in einer heterogenen Systemlandschaft.

5. Aufgrund der Globalisierung haben Sie neue Geschäftspartner bekommen, die einen automatisierten Datenaustausch mit Ihren Systemen erwarten. Hier sind internationale und mehrsprachige Lösungen erforderlich, die zudem klare Schnittstellen und Abläufe garantieren.

6. Die Reporting-Anforderungen haben sich bei Ihnen erhöht, so dass Sie stets verlässliche, vollständige und aktuelle Informationen über Erlöse, Kosten und Ergebnisse „auf Knopfdruck“ benötigen.

7. Für operative und strategische Planungen benötigen Sie jederzeit aktuelle Geschäftsinformationen (Planung, Disposition, Forecasting, Ist-Daten etc), häufig auf Basis von adhoc – Anforderungen.

8. Die ERP-Landschaft einschl. Infrastruktur ist aus operativer Notwendigkeit über Jahre gewachsen ohne das strategische Überlegungen berücksichtigt worden sind. Das Ergebnis ist eine komplexe, häufig nicht dokumentierte IT-Lösung mit unklarer Gesamtarchitektur.

9. Die Schnittstellen zwischen Ihrem ERP-System und den „zuliefernden Systemen“ sind heterogen gewachsen, ohne das eine einheitliche Technologie oder ein funktionales Gesamtkonzept umgesetzt wurde.

10. Die Gesamtkosten des ERP-Systems sind zu hoch, nicht nur die reinen IT-Kosten für Betrieb und Software-Wartung, sondern auch für nicht optimale Geschäftsprozesse , z.B. durch Medienbrüche, Papierschnittstellen, manuelle Arbeiten oder Datenredundanzen.

11. Zur Reduzierung Ihrer ERP-Kosten sind auch neue Modelle, wie „Software as a Service“ oder „onDemand“ interessant.

12. Ihr Unternehmen ist international aufgestellt und Ihre länderspezifischen Organisationen haben unterschiedliche ERP-Systeme im Einsatz. Oder die Geschäftsprozesse sind länderspezifisch unterschiedlich und Sie möchten die Prozesse (und die Systeme) vereinheitlichen.

13. Häufig stehen IT-seitige Konsolidierungsthemen im Zusammenhang mit veränderten Prozessen auf der Business-Seite, z.B. durch Einführung von Shared Service Strukturen. Für die optimale Unterstützung von Prozessen in Shared Service Centern sind einheitliche, klar strukturierte IT-Systeme erforderlich.

14. Häufig sind die bestehenden IT-Lösungen nur unzureichend dokumentiert. Dieses ist ein erhebliches Risiko, sowohl aus Sicht von Compliance-Anforderungen als auch für veränderte Support-Strukturen (z.B. durch teilweise Erbringung von IT-Leistungen in einem globalen Modell).
In vielen Unternehmen ist es häufig ein Mix aus Anforderungen, die sich aus der jeweiligen Situation der Infrastruktur, der Applikationen oder der Geschäftsprozesse, die zum Start von Konsolidierungsaktivitäten führen.

Welche konkrete Ziele werden mit der Konsolidierung verfolgt?

Ziele der Konsolidierung sind entweder verbesserte Unterstützung der Geschäftsprozesse (Effizienzerhöhung), Risikominimierungen oder eine direkte Kostenreduzierung (z.B. durch Zusammenlegen der Infrastruktur) oder indirekte Kostenreduzierung durch Verringerung der Komplexität bzw. des Applikationsumfangs (und daraus zu erzielende Kostenvorteile). Im einzelnen ist darunter zu verstehen:

1. Reduzierung der Betriebskosten (Infrastruktur) durch Optimierung der Hardware bzw. der gesamten Infrastruktur (Server, Kommunikation, Firewalls, Lizenzen, Strom etc).

2. Reduzierung der Lizenzkosten an die Software-Lieferanten (z.B. SAP, Oracle) durch Reduzierung der Software-Vielfalt oder ggf. preisliche Nachverhandlungen.
3. Reduzierung der Kosten für die Wartung der Software-Landschaft durch die Reduzierung der Komplexität bzw. der Vielfalt der Systeme.

4. Reduzierung des Aufwands zur Implementierung bzw. Wartung der Systemschnittstellen zwischen den Systemen (bei einheitlichen Systemen entsteht weniger Schnittstellen-Aufwand).

5. Reduzierung des Aufwandes zum manuellen bzw. maschinellen Zusammenführen der Daten bezüglich des Reportings. Aus nicht konsolidierten ERP-Systemen ist ein einheitliches automatisches Reporting kaum möglich.
6. Durch Reduzierung der Datenredundanzen bzw. durch das Verhindern von Auswertungen aus verschiedenen Systemen gibt es keine Abweichungen im Reporting. Ansonsten entstehen Abweichungen in Auswertungen, die analysiert und geklärt werden müssen.

7. Verbesserung der Transparenz und dadurch Verhindern von zusätzlichen Kosten: Konsolidierte Systeme können besser überwacht und die Prozessdurchgängigkeit kann einfacher sichergestellt werden.
8. Reduzierung der Kosten, um „Compliance-Anforderungen“ abzudecken. Insbesondere im Hinblick auf SOX-Anforderungen muss die Datenintegrität und Prozessdurchgängigkeit sichergestellt sein.

9. Reduzierung der Kosten bei Release-Wechseln. In einem konsolidierten System fallen erheblich weniger Kosten für neue Releases bzw Patches an, da nicht mehrfach Upgrades und die damit verbundenen Analysen und Tests bzw. Fehlerkorrekturen erforderlich sind.
In einem global agierenden konsolidierten ERP-System sind sicherlich zusätzliche Aufwände für sog. Governance-Aufgaben notwendig (z.B. zentrale Steuerung der Weiterentwicklung, UserGroups, übergreifende Release-Planung etc), diesen zusätzlichen Kosten steht jedoch ein erheblicher Kostenvorteil gegenüber.

Wie kann neusta enterprise services bei solchen Projektaktivitäten unterstützen?

neusta enterprise services betrachtet bei allen Aktivitäten immer die Geschäftsprozess-Sicht als auch die IT-Lösung. Der Mehrwert für Ihr Unternehmen ergibt sich dadurch zunächst durch die Optimierung der Geschäftsprozesse und im zweiten Schritt zusätzlich durch die optimale IT-Lösung für diese Prozesse. Wie kann neusta enterprise services diesen Mehrwert konkret sicherstellen?
 
1. neusta enterprise services stellt Berater mit jahrelanger Erfahrung mit verschiedenen ERP-Systemen (SAP, Oracle E-Business Suite) zur Verfügung. Diese Berater werden produktunabhängig bei der Prozessanalyse beraten und aktive praxisnahe Verbesserungsvorschläge einbringen.

2. Die Kompetenz dieser Berater ist nicht auf IT beschränkt, sondern sie haben immer an der Nahtstelle zwischen IT und Business gearbeitet und verstehen den Zusammenhang zwischen Geschäftsprozessen und IT.

3. Das Wissen basiert auf praktischen Projekterfahrungen in diversen Konsolidierungsprojekten in den vergangenen Jahren. Neben dem methodischen Handwerkszeug zur Vorgehensweise in solchen Projekten ist daher auch ein reichhaltiges Branchenwissen (z.B. Touristik, Travel & Transport, Baugewerbe, Ver- / Entsorger, Warenwirtschaft) entstanden.

4. Wir bringen Erfahrungen aus Konsolidierungs- und Standardisierungsprojekten aus großen internationalen Konzernen als auch bei mittelständischen deutschen Unternehmen mit.

5. Wir verfügen über langjährige Erfahrung in der Projektleitung und unterstützen Sie sowohl methodisch bei Konsolidierungsvorhaben als auch inhaltlich bei Schwachstellenanalysen, der Definition der Konsolidierungsziele und bei der Umsetzung der Konsolidierungsaktivitäten.

6. Zur Modellierung und Dokumentation der Geschäftsprozesse übernehmen wir gern Ihre Standardtools. Sofern gewünscht können wir auch jederzeit auf unsere eigenen Standards zurückgreifen.

7. neusta enterprise services unterstützt Sie pragmatisch und kundenspezifisch und arbeitet eng  mit den Business- und IT Experten in Ihrem Unternehmen zusammen.

8. neusta enterprise services wird Sie stets flexibel unterstützen: Wir übernehmen gern Projektverantwortung, können aber auch zur individuellen Beratung mit Ihren Experten zusammen arbeiten oder Sie können uns als „Sparringspartner“ nutzen.

9. Im Rahmen der neusta-Gruppe bietet neusta enterprise services individuelle Beratungsleistungen an, die bei Bedarf durch Software-Entwicklungsarbeiten oder BI-Lösungen ergänzt werden können. Alles bei Bedarf auch gern „alles aus einer Hand“.

Projektreferenzen

Bei Interesse nennen wir Ihnen gern die Referenzen unserer erfolgreichen Projekte. Bitte melden Sie sich unter:

Dirk Kabus
neusta enterprise services GmbH
Borselstr. 26, Haus I
22765 Hamburg
E-Mail: d.kabus@neusta.de
Tel: +49 (0) 40 3999903-01

Welche Kriterien müssen erfüllt sein, um erfolgreich Software in einem Globalen Delivery Modell zu entwickeln?

An welchen (messbaren) Parametern kann die Eignung zur Offshore-Software-Entwicklung festgemacht werden?

Wenn von einem Globalen Delivery Modell gesprochen wird, dann ist damit ein über den Globus verteiltes Entwicklungsteam gemeint, das im gleichen Projekt arbeitet, aber an geographisch weit auseinanderliegenden Standorten. Ein Teilteam befindet sich normalerweise in Kundennähe („onsite“), ein oder mehrere andere Teilteams dagegen an weit entfernten Standorten. Alle Teilteams arbeiten im Rahmen des Software-Entwicklungsprozesses auf Basis vordefinierter Rollen und Prozesse eng zusammen.

Dabei wird von „Offshore-Teams“ gesprochen, die sich an Standorten in anderen Zeitzonen, in Ländern mit einem deutlich geringeren Lohnniveau befinden (z.B. Indien, China, Mexiko). „Nearshore-Teams“ dagegen befinden sich ebenfalls an einem geographisch anderen Ort, allerdings deutlich näher beim Kunden, - häufig in derselben Zeitzone -, z.B. Polen, Rumänien oder Tunesien.

Was ist die Motivation für IT-Firmen, ein bestehendes lokales Software-Entwicklungsteam in mehrere Gruppen und dazu noch an verteilten Standorten aufzuteilen? Hier sind im wesentlichem folgende Gründe / Zielsetzungen zu nennen:

• Kostenreduktion
• Reduzierung der Fixkosten für das interne IT-Team
• Verbesserung „go-to-market“, schnellere Entwicklungszeiten (durch Einsatz zusätzlicher Experten)
• Qualitätsverbesserungen (durch Nutzung zertifizierter Prozesse in der Offshore-Organisation)
• Flexibilisierung der Kapazität („atmende Organisation“)
• Behebung des lokalen Fachkräftemangels
• Internationalisierung des Teams; Verbesserung der Fremdsprachenfähigkeit
• Schaffen von mehr Prozesstransparenz
• Wettbewerber machen es auch…

Der Start zu einem Offshore-Vorhaben ist meistens eine Kombination aus diesen Gründen. Verschärfter Wettbewerb, auch dadurch dass im Rahmen der Globalisierung Firmen aus z.B. Indien auf den deutschen Markt drängen und so zusätzlicher wirtschaftlicher Druck und terminliche Anforderungen an die „Lieferfähigkeit“ für die lokalen IT-Anbieter entsteht.

Dieser Artikel beschäftigt sich im folgendem mit zwei sehr wichtigen Aspekten der Offshore-Software-Entwicklung:

1. Welche Kriterien sind zu berücksichtigen, um die „Offshore-Fähigkeit“ eines Entwicklungsprojektes zu beurteilen ? Nicht jede Art von Software-Lösungen ist hier gleich einzustufen.

2. Welche Voraussetzungen an Prozesse und Organisation müssen für ein erfolgreiches Vorhaben in diesem global verteilten Entwicklungsteam geschaffen werden?

Weitere Aspekte, die für den Erfolg einer Offshore-Entwicklung relevant sind, z.B.:

• Handhabung kultureller Unterschiede und Vermeidung von Kommunikationsproblemen
• Service-Steuerung vs. Resourcen-Steuerung
• Anbieterauswahl und Verträge mit dem Offshore-Anbieter
• Versteckte Kosten (Overhead, Koordination, Übersetzungen, QS,….)
• Transitions-Kosten
• Produktivität
• Motivation der verbleibenden lokalen Mitarbeiter
• Eskalationsregeln

werden an dieser Stelle nicht betrachtet.

Um die Eignung einer Software-Entwicklung für ein Offshore-Modell zu beurteilen, ist auch die Erwartungshaltung des Kunden wichtig. Wie wird das IT-Team aus Sicht des Kunden gesehen?

In vielen Fällen wird das IT-Team nicht als reiner Technologie-Provider gesehen, sondern darüberhinaus gibt es aus Sicht des Auftraggebers (externer Kunde oder interner Fachbereich) weitere Anforderungen:

• Verständnis der Geschäftsprozesse des Kunden
• Der Kunde möchte seine Vorgaben möglichst kurz und knapp beschreiben, trotzdem soll es aber keine Missverständnisse der fachlichen Anforderungen im IT-Team geben
• Hohe Verlässlichkeit im Sinne von Termin-, Qualitäts- und Budgettreue
• Transparenz und Dynamik in der SW-Entwicklungsphase; häufig auch bei agilen Vorgehensweisen
• Partnerschaftliches Vorgehen, direkte und offene Kommunikation, pro-aktives Handeln
• Verantwortungsvolles Handeln des IT-Teams
• Mehrwert des IT-Teams auch durch aktive Beratungsleistungen für den Kunden
• Innovation

Was bedeuten diese Erwartungen für die Einschätzung der Offshore-Fähigkeit einer Software-Entwicklung? Prinzipiell ist zu sagen, dass der Ansatz mit globalen Delivery Teams einschl. Offshore-Komponenten eine Reihe der vorn genannten Vorteilen bieten kann, jedoch in Abhängigkeit der individuellen Projektsituation. Welche Kriterien sind daher zu berücksichtigen? Im folgendem sind eine Reihe von relevanten Aspekten dargestellt. Je mehr der folgenden Fragen mit „ja“ beantwortet werden, desto weniger geeignet ist das Vorhaben für einen Offshore-Ansatz:

Die folgende Tabellen sind gekürzt. Sofern Interesse an den gesamten Kriterien besteht, wenden Sie sich bitte an:

neusta enterprise services GmbH

Dirk Kabus

Borselstr.26, Haus I

22765 Hamburg

+49 40 3999903-01

+49 151 2301 8789

d.kabus@neusta.de

1. Geschäftsspezifisches Wissen

2. Standard- / Individualsoftware

3. Gesteuerte Produktentwicklung

4. Vorhergehnsmodell

5. Formales Pflichtenheft

6. Arbeitsvolumen

7. Technologie

8. Sprache

9. Projektumfeld

Auch wenn eine Reihe von Fragen mit „ja“ beantwortet werden, bedeutet das nicht, dass ein erfolgreiches Offshore-Vorgehen nicht möglich ist. Es ist dann allerdings umso wichtiger, individuelle Steuerungsmaßnahmen zur Reduzierung von Projektrisiken oder – problemen aufzusetzen. Dieses sind aber immer individuelle Maßnahmen, z.B.:

• Detailliertere Projektplanung
• Formale Reviews
• Formale Pflichtenhefte und Change-Prozeduren
• Regelmäßige Kommunikation für alle Projektbeteiligten durch Dokumentation, Protokolle, Telefon- / Videokonferenzen
• Regelmäßige Onsite / Offshore – Aufenthalte von Team-Mitgliedern
• Zusätzliche Übersetzungsmaßnahmen
• Zusätzlicher Wissenstransfer für Hintergrundwissen („Geschäftsprozesse“)
• Aufbau und Pflege von vollständigen Testszenarien

Aus all diesen Maßnahmen ergibt sich zusätzlicher Projektaufwand, der sich in verlängerten Projektlaufzeiten bzw. zusätzlichen Projektkosten darstellt. Bei einem Projektumfeld, dass für ein Offshore-Vorgehen prinzipiell geeignet ist, muss bereits von einem zusätzlichen Aufwand für Kommunikation, „Schleifen durch Missverständnissen“, Reviews und zusätzliche Qualitätssicherung von 20 – 30 % ausgegangen werden. Zusätzliche Maßnahmen erhöhen den Aufwand entsprechend.

Sofern die o.g. Fragen überwiegend mit „ja“ beantwortet wird, dann ist das ein sicheres Indiz dafür, dass ein Offshore-Vorgehen keine erheblichen Vorteile bringen wird…

Neben der Art und dem Umfeld der eigentlichen Software-Applikation ist die Organisation des Software-Entwicklungsprozesses sowie die Struktur der verteilten Teams sehr wesentlich für den Projekterfolg.
Für die Umsetzung einer Software-Entwicklung in einem Offshore-Modell gibt es nicht genau die eine Lösung für ein solches Vorgehen, sondern prinzipiell müssen die Rollen und Verantwortlichkeiten der Teams in dem globalen Delivery-Modell im Einzelfall  analysiert und definiert werden. Grundsätzlich gilt aber immer:

In geographisch verteilten Teams muss der Prozess der Software-Entwicklung einschl. der Schnittstellen sehr klar strukturiert, definiert und kommuniziert sein. Ein Nachfragen „beim Kollegen im Nebenzimmer“ ist nicht möglich und es wird immer eine gewisse Scheu bleiben, per Telefon aus Indien beim Projektkollegen in Deutschland anzurufen und Verständnisfragen zu stellen. Aus diesem Grund muss vor Projektstart geklärt sein, wer für die einzelnen Projektphasen / Aktivitäten zuständig bzw verantwortlich ist (z.B. mit einer RACI-Matrix – Responsible, Accountable, to be consulted, to be informed) und wie die Schnittstellendokumente aussehen. In Offshore-Teams ist es üblich, dass jede Person sehr genau seinen eigenen Aufgabenbereich kennt (einschl. Schnittstellen vorn / hinten), allerdings keinerlei Gesamtüberblick besitzt. Man muss sich darauf verlassen können, dass der Gesamtprozess lückenlos auf einzelne Aufgaben heruntergebrochen wurde, die dann eine individuelle Person ausführen kann. Ein weiterer Aspekt in der Zusammenarbeit mit indischen Offshore-Teams ist das Einhalten von Hierarchien. Diese sind sehr viel strikter definiert und es wird erwartet, dass diese in der Zusammenarbeit eingehalten werden, insbesondere bei der Aufgabenzuordnung und Eskalation.
Eine übliche Rollenverteilung im Rahmen der Software-Entwicklung ist im folgenden Schema dargestellt:

Der gesamte Prozess muss definierten Regeln folgen („Roles & Responsibilities“). Alle Projektdokumente müssen vorab hinsichtlich Namenskonventionen, Ablagestruktur, inhaltliche Struktur und erwarteten Inhalten (z.B. Detaillierungsebene) festgelegt werden. Die Phasenübergänge sollten sehr stark gesteuert werden, d.h. ein formaler Phasenabschluß mit Review der Zielerreichung ist die Basis für den Übergang in die nächste Phase. Ein formales Projektvorgehen analog PRINCE2 ist sehr hilfreich in einem Projekt mit verteilten Teams.

Eine weitere Erfahrung zeigt, dass trotz technischer Hilfsmittel wie email, Telefon-konferenzen und Videokonferenzen der persönliche Kontakt wichtig ist. Aus diesem Grunde ist es für Projekte risikominimierend, wenn möglichst permanent ein Mitarbeiter des Offshore-Teams onsite, d.h. beim lokalen IT-Team präsent ist. Dasselbe gilt auch für einen Mitarbeiter des lokalen IT-Teams, der idealerweise ständig beim Offshore-Team sitzt. Kommunikation wird einfacher, Missverständnisse werden früher identifiziert und durch schnelle und direkte Kommunikation werden offene Punkte und Rückfragen sehr viel schneller geklärt.

Es ist wichtig, dass in der internen (Kunden-)Organisation genügend IT-Wissen vorhanden bleibt, um Design- / Architekturvorgaben zu entwickeln sowie Qualitätssicherung und Review von Aufwandsschätzungen zu verantworten.
Dieses gilt prinzipiell sowohl für das Outsourcing von Applikationsentwicklung, als auch für globale Delivery-Modelle mit nearshore oder offshore – Komponenten.

Die Möglichkeiten, möglichst große Vorteile zu erreichen steigen mit der Veränderung von einem zentralen lokalen Projetteam zu Outsourcing – Nearshoring – Offshoring – Modellen. Die Risiken allerdings auch. Zusätzliche formale Projektprozesse (Planung, Review, Qualitätssicherung etc) sind unabdingbar.

Nachhaltige Vorteile (bei den Kosten oder der Qualität) sind nur bei einem stabilen Team mit eingeschwungenen Rollen und Prozessen zu erreichen. Das ist frühestens nach einem Zeitraum von 2 Jahren realistisch.

Abschließend jeweils einige Thesen zur Klassifizierung von Software-Projekten als „geeignet“ bzw „nicht geeignet“ für ein globalen Delivery-Modell mit Offshore-Komponenten. Diese Thesen basieren auf den Inhalten dieses Dokumentes bzw eigenen praktischen Erfahrungen mit mehreren indischen und tunesischen IT-Dienstleistern in den Jahren 2002 –bis 2008:

„Geeignet“:

• Technische Produktentwicklung auf Basis von langfristig geplanten Release- und Produktzyklen auf Basis eines detaillierten technischen Pflichtenheftes
• Migrationen einer bestehenden Software auf eine neue Technologie bei unveränderter Funktionalität
• Technischer Support für eine Software, die auch bereits vom Offshore-Team entwickelt wurde
• Durchführen von inhaltlichen Tests / Lasttests auf Basis von vordefinierten Testfällen
• Rollout einer bestehenden Applikation ohne kundenspezifische Erweiterungen
• Große Projektvolumen

„nicht Geeignet“:

Entwicklung individueller Software-Services auf „Zuruf“; Anforderungen ohne mittel- / langfristig planbare Arbeitspakete oder ständig wechselnde Skillanforderungen
Einmaliges Umsetzen von fachlichen Anforderungen ohne anschließende Weiterentwicklung / Wartung
Individuelle Software-Lösungen, die bei nur einem Kunden eingesetzt werden
Arbeiten mit Schwerpunkten in der Kundenberatung und Analysetätigkeiten
Kleine Projektvolumen

Zusammenfassend bedeutet das, das ein Offshore-Team am besten als Technologie-Competence-Center eingesetzt werden kann. Dieses kann als Provider im Rahmen einer planbaren Produktentwicklung bzw Produktbetreuung sein oder als technisches Center für sich wiederholende Aufgabenstellungen, z.B. technische Migrationen. Weniger Möglichkeiten bestehen für den Einsatz als Innovationsprovider oder Tätigkeiten mit den Schwerpunkten Analyse oder Beratungsthemen.

Dirk Kabus

Termine

7.12.2011 - 9.12.2011
LeWeb - Paris