Jede Dekade, in denen ich mich mit Informatik und Technologie beschäftige (also seit den 80ern) hat seine Modeerscheinungen hervorgebracht. In vielen Unternehmen kann man die Spuren dieser Moden ablesen – je nachdem, wieviel Geld in die jeweilge Mode investiert wurde, sind die Relikte in den IT-Ökosystemen noch gut ablesbar.

Nach „Offloading“ von Anwendungen auf den PC in den 80ern (Microsoft propagierte damals: „Ihr PC kann alles, was ein Mainframe kann – in allen Situationen“) kam die Zeit der 4GL Programmierung („mit einer 4th Generation Programmiersprache setzen sie ein „Rapid Application Devlopment“ in ihrer IT Abteilung um: konfigurieren Sie Anwendungen nur noch – sie pflegen nur noch ein einziges Repository ihrer Geschäftslogik, Benutzeroberflächen und Datenbank wird immer Up-to-date generiert.“) oder etwas später das Allheilmittel „Standardsoftware“ („Unser Standardsoftwarepaket liefert alle Geschäftsprozesse „out of the box“. Wo die Stdandardprozesse nicht zu ihren Geschäftsprozessen passen, können sie diese leicht an ihre Anforderungen anpassen. Das schwierigste bei unserer betriebswirtschaftlichen Standardsoftware ist die Installation, und dafür reicht ein Doppelklick auf das „setup.exe“ Icon“).

Da Unternehmen in der Regel gescheiterte Projekte – insbesondere Großprojekte – nicht an die große Glocke hängen bzw. ein episches Scheitern auf diversen Konferenzen noch als gloriosen Erfolg verkaufen, ist es oft nicht einfach, das tatsächliche Ausmaß des Schadens, der durch eine entsprechende Mode verursacht wurde, abzuschätzen. Eine relativ gute Transparenz gibt es aber für IT Projekte der öffentlichen Hand – hier kann man einen Eindruck über die Probleme von IT Projekten gewinnen. Ebenfalls ein guter Indikator für durch unreflektiert übernommene Moden entstehende Probleme ist die Entstehung von spezialisierten Beratungen, Leitfäden und Dienstleistungen, die Unterstützung im Falle von Problemen anbieten und in der Folge eine Flut von Artikeln in Fachzeitschriften, die sich abwechselnd mit den auftretenden Problemen und „innovativen“ Lösungen in Form von Dienstleistungen, Zusatztools/Zusatzsoftware oder Vorgehensmodellen/Methodiken äußert.

Wenn ich nun Google anwerfe und entsprechend suche, springen insbesondere entsprechende Angebote ins Auge, die sich mit „Offshoring“ Projekten beschäftigen. Allein die Menge der Angebote für Coaching, Project Offices, „Application Managment“, Quality Assurance, large Scale Transformation, On/Offshore Consulting etc. pp. verleitet mich zu der Auffassung, daß das Ausmaß der nach Indien verlagerten Projekte, die gescheitert sind bzw. für die deutschen Unternehmen ganz ernsthafte Probleme gebracht haben, enorm sein muß - ansonsten hätte sich eine solche auf Projektunterstützung und Qualitätsüberwachung spezialisierte Industrie nie bilden können: es gibt ein Problem, also werden Lösungen angeboten.

Selbstverständlich weist jeder Anbieter, der aus der vorherrschenden Mode einen satten Profit schlagen möchte, darauf hin, daß die Probleme meistens auf der Seite des Auftraggebers liegen, z. B. in unzureichenden Sprachkenntnisse, mangelnden Cross-Cultural Fähigkeiten oder in einem Defizit bei der Beherrschung von methodischem Vorgehen ... 

Gerade in Deutschland tendieren Manager dazu, die Probleme in ihren eigenen deutschen Organisationen und bei ihren „On-Shore“ (also heimischen) Mitarbeitern zu suchen, auch wenn diese meist nicht in der bestehenden Software oder den Fähigkeit der Mitarbeiter, sondern in verzögerten Entscheidungen, falscher organisatorischer Aufstellung oder der Entfernung von IT Entscheidern vom Kerngeschäft liegen. Sehr zur Freude der vielen Beratungsunternehmen, die entsprechende Trainings, Kurse und Coachings anbieten. Auf „manage-IT“ sprechen selbst die Anbieter von „Offshoring als einem komplizierten Prozess“, durch den nur „erfahrene Dienstleister“ lotsen können.

Vor diesem Hintergrund bin ich über einen Vortrag des ehemaligen Top-Managers Narayana Murthy der indischen Firma „Infosys“ (einer der größten Anbieter von „Offshore“ Dienstleistungen) gestoßen. In diesem Vortag ermahnt er die indische IT Industrie, daß die Faulheit, Unzuverlässigkeit und mangelnden Programmierkenntnisse der Mitarbeiter nicht nur dazu geführt hätten, daß die meisten IT Projekte verspätet und mit Qualitätsmängeln behaftet seien, sondern daß durch diese Probleme auch das in den letzten Jahren aufgebaute Image der indischen IT Industrie in Mitleidenschaft gezogen werden könnte.

Interessant ist nicht nur der deutliche Hinweis auf die massiven Mängel der indischen Dienstleister, sondern auch die Erwähnung des Faktums, daß Indien in einer bislang nie dagewesenen Werbe-Kampagne eine Marke als „IT Fabrik“ aufgebaut hat. Das Image der indischen IT Industrie ist tatsächlich das Ergebnis einer seit mehr als 15 Jahren betriebenen intensiven Marketing Kampagne, die sich auf keinerlei nachweisbare Fakten stützen kann, als die schiere Zahl von Menschen und Absolventen der indischen Ausbildungsfabriken.

Für mich ist es immer wieder erstaunlich, wie in Deutschland von einfachen Teamleitern bis hin zu Top-Managern die Werbefloskeln der indischen Offshore-Industrie wiederholt werden. Was ich da höre, könnte man in vielen Fällen fast unverändert in einen Werbeprospekt für Programmier-Roboter drucken:

• Der Inder ist fleißig und rund um die Uhr verfügbar,

• er ist top qualifiziert und mit den neuesten Technologien vertraut,

• er ist sorgfältig, auf Qualität bedacht, kann mindestens ISO 9000 und CMMI Level 5,

• er beherrscht das Englische quasi als Muttersprache
  und

• ist konsequent kundenorientiert.

Allein die Häufigkeit, mit der die immer gleichen Stereotype zu hören sind und die Wortwahl, die immer gleichen Phrasen, erzeugen in mir den Eindruck, daß hier eine phantastische Werbestrategie wunderbar aufgegangen ist. Mars macht mobil, bei Arbeit, Spaß und Spiel, im Falle eines Falles klebt Uhu einfach alles, da werden sie geholfen und in Indien programmieren Genies 24Std am Tag / 7 Tage in der Woche für einen Spottpreis.

Ich sehe es als absolute Meisterleistung der indischen Regierung an, daß sich dieser Marketing-Blitz trotz der Flut von Projekten, die gescheitert, mindestens aber ihre Ziele kaum erreicht haben, bis zum heutigen Tag hartnäckig halten kann. So erlangte das Projekt „Amarta“ der Swiss Life, bei der eine einheitliche Plattform für alle Versicherungssparten selbst programmiert werden sollte, traurige Berühmtheit, als nach 8 Jahren Entwicklungszeit und 500-800 Millionen Schweizer Franken die Entwicklung und Einführung gestoppt wurde: zum großen Teil entwicklt in Indien – die verschiedenen Altsysteme konnten in der Folge durch die noch verbliebenen Schweizer IT Experten wieder flottgemacht werden, die 200 auf „Amarta“ geführten Großkunden der Swiss Life wurden auf die bewährten Systeme zurückgeführt.

Während also die Liste der gescheiterten Indien-Projekte immer länger wird (laut tecchannel scheitern 1/3 aller Projekte mit Beteiligung indischer Programmierer, laut Channelpartner erreichen 2/3 aller Offshoring Projekte nach Indien ihre Ziele nicht, laut „manage-IT“ scheitern 50% aller deutschen Offshore-Projekte), sinkt die Zahl der Versuche IT Projekte über „Offshoring“ schneller, billiger und besser abwickeln zu können, dennoch nicht. Ich weiß nicht, ob es sich hier um ein Problem „selektiver Wahrnehmung“ handelt, um die Hybris deutscher IT Verantwortlicher oder um immer wieder „nachwachsende“ unerfahrene oder aus praxisfernen Unternehmensberatungen (die meist niemals selbst programmiert haben oder mit Softwareentwicklung intimer vertraut sind) angeworbenen Entscheider handelt: Faktum ist – die „offshoring“ Welle rollt ungebrochen.

Eine zunehmende Skepsis, insbesondere bei den erfahrenen Praktikern an der Basis der Unternehmen, scheint meiner Meinung nach aber dazu zu führen, daß die Offshore-Industrie mit immer ausgefeilteren Tricks arbeiten muß, um ihre so oft gescheiterten Programmier- und Projektleistungen an die deutschen Konzerne und Unternehmen bringen zu können.

Ich beobachte die folgenden Maschen bei den indischen Konzernen und ihren internationalen Beratungspartnern:

1. Zertifizierungen in immer neuen Methoden und Qualtitätssicherungsverfahren.
   Statt aussagefähiger Arbeitsproben oder erfolgreicher Projektreferenzen werden „Zertifizierungen“ in wohlklingenden Methoden in den Fordergrund gestellt, besonders im Bereich Qualitätsmanagement – natürlich als Gegenargument gegen Qualitätsvorbehalte. CMMI Level 5, ITIL v3, CobiT, ISO 9000 und viele andere Zertifizierungen sollen „unabhängige“ Bestätigung für Fähigkeit und Qualität sein. Doch wer bestätigt, daß eine ISO 9000 Zertifizierung in Indien wirklich dasselbe ist, wie eine ISO 9000 Zertifizierung in Deutschland? Und vor allem: die zertifizierten Methoden werden ja nicht automatisch auch im Kundenprojekt angewendet. In Kundenprojekten wird das gemacht, was der Kunde bestellt, wie er es bestellt. Im Zweifelsfalle kann sich der indische Dienstleister darauf berufen, daß an den Zuliefer- und Abnahmeschnittstellen des Kunden die Verfahren nicht eingehalten wurden.

2. Partnerschaften
   Im Kampf um die IT Budgets für große und teure Softwarepakete werden die indischen Dienstleister von den Softwareanbietern als Partner angeworben. Damit soll suggeriert werden, daß die Implementierung eines komplexen ERP Systems billig zu haben sei, eine riesige Datenbank in sehr kurzer Zeit organisiert werden könne oder eine Migration auf ein teures neues CRM System ohne massiven Datenverlust bzw. Verlust an Datenqualität vor sich gehen könnte.
   
   Die indischen Unternehmen können sich auf der anderen Seite mit einer Kollektion an Logos, Partnerschaften und Zertifizierungen schmücken – Platinpartner, Premiumpartner oder Gold-Status Partner eben genau der Softwareanbieter, die für ihre wahnsinnig überteuerten Softwarepakete billige Dienstleistungen benötigen, um bei den potentiellen Kunden in die IT Budgets zu passen.

3. „Neue“ Projektmanagement Methoden – das „double play“ der Systemintegratoren
   Die „Wunderwaffen“ der Offshoring-Magier sind neue „Vorgehensmodelle“ und neue (innovative) Projektmethoden. Hier wird ein Feuerwerk an Buzz-Wörtern abgebrannt: Agile, SCRUM, Extreme Programming, Reverse Presentations – die Liste der Anglizismen, die den deutschen Entscheidern suggerieren sollen, daß die bisherigen Versuche nur deshalb nie etwas geworden sind und nie Erfolg gehabt haben, weil man das richtige Rezept noch nicht gefunden hatte, ist lang.

Es bilden sich unheilige Allianzen. Meiner Meinung nach freuen sich die großen Systemintegratoren darüber, daß sie durch Offshoring-Partnerschaften einen Weg gefunden haben, zum einen die Implementierungsverantwortung vor Ort los zu werden, eine große Zahl von Beratern als „Offshore Links“, „Project Management Offices“, „Implementation Manager“ und „Business Designer“ zu fakturieren und gleichzeitig neue „Methoden“ als Verkaufsargument gegenüber den IT Verantwortlichen ins Feld führen zu können.

Die großen Systemintegratoren gewinnen oft sogar doppelt: zum einen in der Phase, wenn ein Projekt in Indien entwickelt werden soll, zum anderen in der Phase nach dem Scheitern des Projektes in Indien, wenn schnelle Lösungen vor Ort benötigt werden, die durch die unternehmenseigene IT Mannschaft nicht mehr aufgefangen werden können.

Ich habe mich schon häufiger gefragt: wie kommt es eigentlich, daß Softwareentwicklung in Indien in so vielen Fällen nicht die erwarteten Ergebnisse bringt. Warum laufen Offshore-Projekte mit indischen Programmierern so häufig (eigentlich fast immer) in Punkto Kosten aus dem Ruder, obwohl die Tagessätze doch um so viel niedriger sind, als die deutscher Programmierer?

Warum sind fast alle in Indien von indischen Programmierern entwickelten Projekte, von denen ich gehört habe, deutlich verspätet, verpassen Deadlines und müssen immer wieder den angekündigten Leistungsumfang reduzieren? Warum verzieht jeder europäische Entwickler das Gesicht, wenn er in Indien produzierten Code ansieht?

Und last but not least höre ich bei allen Arten von Offshore-Projekten, daß die Qualität der erstellten Anwendungen immer wieder sehr deutlich zu wünschen übrig lässt, was sich in extrem hohen Wartungs- und Pflegekosten sowie dramatischen Explosionen von Workarounds und daraus resultierend massiven Steigerungen von Prozesskosten ergeben. Der Züricher Tagesanzeiger spricht bei dem gescheiterten Projekt ELUSA für das Sozialdepartement von „unhaltbaren Umgehungslösungen“.

Um an „des Pudels Kern“ zu kommen, habe ich mich über große IT Projekte indischer Konzerne informiert. Und überraschenderweise bin ich darauf gestoßen, daß große innovative indische Konzerne wichtige IT Projekte durch US-amerikanische bzw. englische Programmierer abwickeln lassen und höchstens die Wartung und Pflege der Anwendungen bzw. den IT Betrieb durch indische Mitarbeiter erledigen lassen.

Als zweites habe ich mich über Projekte in Indien informiert: die Hälfte aller Infrastrukturprojekte der indischen Regierung sind verspätet - teilweise um Jahre. Diese Quote hat sich seit Jahrzehnten nicht verändert und zeigt die fundamentalen Probleme, die in Indien bei der Abwicklung von Projekten bestehen. Eine Studie des Kings-College aus 2011 zeigt, daß die Briten es bis 1947 geschafft hatten, durch massive Investitionen und Know-How und Management von außen, Infrastrukturen und Institutionen aufzubauen. Sobald diese allerdings in die Hände der Einheimischen gelegt worden waren und die europäischen Experten abgezogen waren, begann nicht nur der Verfall durch Mängel in Wartung und Pflege, sondern auch die massiven Probleme bei der Umsetzung der Weiterentwicklungspläne.

Auch wenn hiesige Publikationen schon oft über die sog. "kulturellen" Unterschiede" geschrieben haben. Es sind nicht nur die oberflächlichen kulturellen Unterschiede wie Hierarchiedenken, Angst vor Gesichtsverlust, Unterschiede in der Auffassung von Verbindlichkeit, Stellenwert von Dokumentation und Spezifikation oder der Stellenwert von persönlicher Beziehung: Immer öfter werden ganz fundamentale, gravierende Mängel der indischen Partner offenbar und das Argument der "Kulturunsensibilität" ist typisch um die Schuld für Versagen oder Nichterreichen von Projektzielen auf den Auftraggeber zu projizieren.

Indische Top-Manager kennen ihre Landsleute genau und wissen um die Stärken und Schwächen. Also habe ich versucht mehr über die Mentalität und die Einstellung von indischen Programmierern herauszufinden. In einem Artikel auf „Trade Chakra“ werden Geschäftspartner aus Europa und USA darauf hingewiesen, daß „The notion of time, time management, punctuality is still an anathema (ein Gräuel) in India. It is more to do with the mindset and ingrained in the Indian culture.“ In einfachen Worten: Terminplanung, Zeitmanagement und Pünktlichkeit widersprechen der indischen Mentalität und Kultur. Im Kapitel „Understanding the indian business Culture“ im Buch „Riding the Tiger“ schreibt der indische Autor Ashish Sinha: „The concept of time in the indian culture is often referred to as: IST; Indian Stretched Time. […] Employees have the habit of walking over to someone's desk and spending time talking about nonwork issues while that person is trying hard to focus on something important.“

Weiter: „Bureaucratic hurdles and a laidback (entspannt) approach to work in the government circles could result in delays in processing, overload of paperwork and a general lack of confidence in the system.“ In deutsch: „bürokratische Hürden und ein entspanntes Verhältnis zur Arbeit führen zu Verzögerungen bei der Bearbeitung, einer Flut von Papier und einem Mangel an Vertrauen in das System.“ Das Handelsblatt schrieb dazu 2006: „Indien Mühlen mahlen langsam.“ Viele Besucher in Indien merken schon an der Infrastruktur, daß es hier nur sehr langsam voran geht – egal ob privat oder staatlich organisiert, der Kern der indischen Straßen- und Schienennetze und der Energieversorgung wurde noch von den Engländern erbaut. (Siehe Beitrag auf Germany Trade & Invest aus April 2011) Eine Langsamkeit, die auch deutsche Unternehmen bei den in Indien gesourceten Projekten zu spüren bekommen, spätestens wenn Verzögerungen der Projektfälligkeiten mit Stromausfällen begründet werden ...

Aber auch das Bild vom genialen, indischen Programmierer ist wesentlich von den wenigen Top-Leuten geprägt, die es ins Silicon Valley geschafft haben und an der Seite von amerikanischen, russischen und europäischen Entwicklern die Softwarewelt von morgen prägen. Die Masse der indischen Programmierer wird von diesen Experten als „Coder“ bezeichnet. In einem Blog-Eintrag von 2007 „a myth called indian programmer“ schreibt ein intimer Kenner der indischen Outsourcingindustrie: „Die Arbeit als Coder ist repetitiv und monoton.“ und stellt fest: „das Faktum, daß Indien bis heute keinen einzigen Player wie Google, Microsoft oder SAP hat, spricht für sich selbst.“

Shekular Gulati schreibt in 2010 in seinem Blog: „Ich habe westlicher Entwicklerteams häufig sagen gehört, daß indische Programmierer nicht die Klasse haben wie sie selbst, daß indische Programmierer die Entwicklung verzögern und mehr Probleme verursachen als sie lösen. Meiner Meinung nach sind diese Aussage wahr. Ja, wir sind nicht auf Augenhöhe mit westlichen Programmierern und ja, in vielen Fällen sind wir echt beschissen.“ Als Gründe führt er die schlechte Ausbildung auch an indischen Top-Universitäten an, die mangelnde Motivation, sich nach der formalen Qualifikation weiterzubilden und die indische Mentalität als Team-Lead oder Manager überhaupt nichts mehr selbst machen zu wollen.

Tatsache ist: in Indien wird massenhaft zu billigen Preisen schlechter Code produziert. So wie chinesisches Plastikspielzeug einige Minuten nach dem Auspacken kaputt ist, ist indischer Code einige Minuten nach der Abnahme kaputt, häufig schon davor. Gerade bei großen Projekten lässt sich ohne aufwändige Verfahren eine fertige Software kaum noch umfassend testen. Im Ergebnis müssen die Anwender oder die Endkunden unter den indischen Softwareruinen leiden.

In einem Blog schreibt der indische IT Experte Krishna über das Urteil eines indischen Programmierers: „Abdu meint: Entwickler aus Europa, Russland oder Israel produzieren wirklich innovative Software. Software, die bei mir Erstaunen auslöst und mich rätseln lässt „wie haben die das geschafft?“ oder „ich wünschte ich könnte den Source Code verstehen“. Diese Entwickler sind Code-Künstler und Code-Meister. Entwickler aus Indien, und es tut mir leid, dies zu sagen, sind das, was ich „Codier-Esel“ nenne. Sie schreiben kruden, langweiligen und repetitiven Code, nichts Innovatives und meistens brauchen sie detaillierte Anweisungen, wie sie programmieren sollen, damit überhaupt etwas funktionierendes dabei herauskommt. Deshalb gibt es keine erfolgreichen Softwareprodukte oder Internet-Services aus Indien.“

Nach unzähligen schlechten Erfahrungen lernen aber auch Top-Manager dazu – so schreibt im CIO-Weblog ein einsichtiger amerikanischer Manager: „Oberflächlich betrachtet sahen die Projekte billiger aus. Am Ende jedoch war die Entwicklung teurer als es zuhause gewesen wäre“ … „wir haben [in vielen Projekten] entdeckt, daß der in Indien entwickelte Code so schlecht war, daß am Ende komplett elimiert werden musste. Entwicklung in Indien ist kein gut investiertes Geld und Zeit.“

Wieder und wieder sind es vor allem Inder, die außerhalb von Indien ausgebildet wurden und erfolgreiche IT Projekte durchführen möchten, die objektiv feststellen: indische Programmierer können keinen hochwertigen, funktionierenden und langfristig wartbaren Code produzieren. Vivek Thakur schreibt frustiert in seinem Blog: „Ich musste feststellen, daß die meisten Programmierer ihre Energie dazu verwendeten, die ihnen zugeteilte Arbeit irgendwie fertigzustellen, auch wenn dies den Code insgesamt ernsthaft verpfuschte.“ … „Ich war schockiert, daß Entwickler mit mehr als 5jähriger Erfahrung die grundlegendsten Designprinzipien, strukturierte Entwicklung, Code-Verwaltung und Kommentierungsrichtlinien nicht kannten.“

Ist ein Projekt mit viel Mühen durch eine Abnahme gekommen oder hat ein Top-Manager entschieden, daß zu einem bestimmten Zeitpunkt eingesetzt werden muß, beginnt für viele Experten in den Unternehmen der Leidensweg erst: das Sammelsurium an unstrukturiertem Code, kaum dokumentierten Konfigruationsdateien und erratisch zusammengedäuten Datenbankstatements ist ja nach den Grundsätzen eines ordnungsgemäßen IT Betriebes nicht in Produktion zu nehmen und die Wartung und Pflege erweist sich nahezu immer als ein Ding der Unmöglichkeit. Die Lösung vieler hochbezahlter Top-Manager auch hierfür: Anwendungswartung, -pflege und -betrieb wiederum nach Indien auslagern, denn die Kosten für den Betrieb in Deutschland sind für in Indien produzierte Anwendungswracks immens – was aber in der Folge weiter dazu führt, daß Produktivitäten, von den Endkunden wahrgenommene Qualität sowie die Flexibilität, auf neue Anforderungen und Marktänderungen zu reagieren immer weiter abnimmt.

Für mich steht damit so gut wie fest, daß ein Indien-Outsourcing von wichtigen Anwendungen, auf die ein Unternehmen vielleicht sogar seinen primären Unternehmenszweck abstützt, ein untragbares Risiko darstellt. Viel zu oft schon haben sich in Indien abgewickelte IT Projekte zu echten Geldvernichtern entwickelt oder die Endkunden der Auftraggeber mit echten Horrorerlebnissen konfrontiert. Über Produktivitätsvernichtung bei den Auftraggebern intern und hohe Aufwände für eine Sanierung der zunächst nach Indien verlagerten Projekte kann fast jeder IT-Experte berichten – über erfolgreich im Outsourcing abwickelte Projekte fast niemand, es sei denn es handelt sich um eine Powerpoint Präsentation eines IT-Chefs oder eines Verkäufers bei einem Beratungsunternehmen.

Die Economic-Times, das Wirtschaftsbeiblatt der India-Times, sieht wegen dieser massiven Mängel eine Trendumkehr ab 2014. Ab 2014 wird das Volumen der nach Indien ausgelagterten IT Leistungen zu schrumpfen beginnen. Innerhalb von weiteren 8-10 Jahren wird dann kein Offshoring in nennenswertem Umfang mehr vohanden sein schreibt die Economictimes am 21. März 2012. Bleibt für uns nur zu hoffen, daß die IT Verantwortlichen in Deutschland früh genug erkennen, daß Outsourcing und Offshoring nur eine teure, gefahrvolle Mode ist, bei der sich ein Ausstieg lohnt, wenn man schon in die Falle getappt ist und ein Einstieg vermieden werden muß.