1. Einleitung

Seit zwei Jahrzehnten lautet das Angebot gleich, und die Rechnung sieht unwiderstehlich aus. Ein Ingenieur in Indien kostet einen Bruchteil dessen, was einer in Westeuropa oder den Vereinigten Staaten kostet, das Angebot an ihnen ist groß und gut ausgebildet, und Englisch ist die Arbeitssprache, sodass ein Unternehmen, das seine Softwarearbeit dorthin verlagert, auf dem Papier dieselbe Arbeit für viel weniger erledigen sollte. Sehr viel Arbeit ist genau aus dieser Überlegung heraus verlagert worden, und Indien hat darauf eine IT-Dienstleistungsindustrie von Weltrang aufgebaut. Und doch sind die Ergebnisse von Unternehmen zu Unternehmen auffallend ungleich: Manche Organisationen erhalten über Jahre hinweg hervorragende Software aus Indien, während andere eine steigende Rechnung, eine sinkende Lieferqualität und einen Strom von Fehlern bekommen, den die eingesparten Gehälter nie ganz decken, bis sie das Offshoring für gescheitert erklären und die Arbeit nach Hause holen, oft mit dem Schluss, das Problem sei Indien gewesen. Es war nicht Indien.

Das Problem ist, dass Unternehmen das Falsche auslagern. Die Intuition hinter dem Offshoring ist, dass Softwareentwicklung Ausführung sei, eine Menge an Arbeit, die sich in Personenstunden messen und dort einkaufen lässt, wo Personenstunden am billigsten sind, und auf dieser Intuition übergibt ein Unternehmen eine Spezifikation und einen Personalbestand und wartet auf Output. Doch Softwareentwicklung ist nicht hauptsächlich Ausführung; sie ist die Auflösung von tausend kleinen Mehrdeutigkeiten, von denen jede erfordert zu wissen, was das Geschäft tatsächlich meinte, wie dieser Teil ins Ganze passen soll und was „fertig“ hier wirklich bedeutet, und dieses Wissen lebt dort, wo das Geschäft ist, nicht dort, wo die Tastaturen sind. Wenn ein Unternehmen die Ausführung auslagert, lagert es unwissentlich auch jene Entscheidungen aus, an die Menschen, die am weitesten von dem Kontext entfernt sind, der nötig ist, um sie gut zu treffen, und das Ergebnis ist Arbeit, die lokal plausibel und global falsch ist, spät entdeckt, über eine Kluft von zwölf Stunden hinweg, und langsam behoben. Die Arbeitsarbitrage ist real; die Koordination und die Nacharbeit, die sie auslöst, sind bei schlechter Handhabung größer.

Dieses Papier handelt von dem Betriebsmodell, das den Fehler behebt, indem es ihn nicht begeht, und das Modell hat einen Namen, den wir durchgehend verwenden werden: das Onshore-Command-Centre. Die Idee besteht darin, bewusst und strukturell die beiden Dinge zu trennen, die ein naives Offshoring vermengt. Das eine ist die Ausführung, das Bauen, das sich tatsächlich dort skalieren lässt und sollte, wo Talent reichlich und erschwinglich ist, in Indien. Das andere ist Command: zu entscheiden, was und in welcher Reihenfolge gebaut wird, die Architektur und die Schnittstellen zwischen den Teilen zu besitzen, das vage Gewollte des Geschäfts in eine Spezifikation zu verwandeln, die präzise genug ist, um fern und ohne Gespräch gebaut zu werden, und zu beurteilen, ob das Zurückgekommene richtig ist. Command ist klein, hochrangig und teuer, und es bleibt onshore, neben dem Geschäft, dessen Absicht zu tragen es da ist. Die These lautet, dass der Erfolg eines Offshoring-Programms fast ausschließlich davon bestimmt wird, ob diese Command-Schicht existiert und gut ist, und kaum von der reinen Leistungsfähigkeit des Offshore-Teams, die in der Regel in Ordnung ist; und dass Unternehmen scheitern, weil sie zu wenig in Command investieren, gerade weil Command der teure, inländische Teil ist, den das Offshoring eigentlich beseitigen sollte.

Der Beitrag ist ein Argument und ein kleines Modell, kein Benchmark. Abschnitt 2 stellt die Behauptung dem Erfahrungsschatz des Offshoring und des globalen Software-Engineerings gegenüber. Abschnitt 3 diagnostiziert das eigentliche Versagen: das Auslagern von Verantwortung statt bloß von Ausführung. Abschnitt 4 beschreibt das Command Centre und was es besitzt. Abschnitt 5 liefert ein Modell dafür, wo die Grenze zwischen Command und Delivery verlaufen sollte, abhängig von Kontextlast und Spezifikationsvollständigkeit. Abschnitt 6 behandelt die Uhr und wie Follow-the-Sun zum Hebel statt zur Latenz wird. Abschnitt 7 leitet das optimale Command-Verhältnis ab. Abschnitt 8 zeichnet einen konstruierten Fall nach; die Abschnitte 9 bis 12 ziehen die Konsequenzen, beantworten Einwände, nennen Grenzen und schließen. Die durchgehende Frage lautet: Was muss ein Unternehmen im Inland behalten, und wie viel davon, damit die Arbeit, die es nach Indien schickt, richtig zurückkommt?

2. Hintergrund

2.1 Der Erfahrungsschatz des Offshoring

Das Outsourcing und Offshoring von IT verfügt über eine der größeren empirischen Literaturen der Wirtschaftsinformatik, und ihr Urteil lautet nicht, dass Offshoring sich nicht lohne, sondern dass sein Ertrag davon abhängt, wie es gesteuert wird. Lacity, Khan und Willcocks (2009) stellen in ihrer Durchsicht von zwei Jahrzehnten an Studien fest, dass die Fähigkeiten von Auftraggeber und Lieferant, die Vertragsgestaltung und das Beziehungsmanagement, und nicht allein Lohnunterschiede, die Spanne zwischen erfolgreichen und gescheiterten Engagements erklären. Carmel und Tjia (2005) lieferten die Praktikerdarstellung des Sourcings an eine globale Arbeitnehmerschaft und katalogisierten die Wege, auf denen Entfernung die Arbitrage erodiert; Sahay, Nicholson und Krishna (2003) lieferten die buchlange Darstellung der Softwareentwicklung über die Grenze Indiens hinweg, und Oshri, Kotlarsky und Willcocks (2007) zeichneten nach, wie ein führender indischer Anbieter ein globales Delivery-Modell um verteilte Expertise herum organisierte. Rottman und Lacity (2006) destillierten bewährte Praktiken heraus und stellten fest, dass die erfolgreichen Unternehmen stark in die Onshore-Arbeit des Spezifizierens, Koordinierens und Steuerns investierten, genau jene Arbeit, die dieses Papier Command nennt. Der durchgängige Befund ist, dass die Ersparnis brutto und nicht netto ist und dass zwischen beiden der Managementaufwand steht, der größtenteils im Inland verbleibt.

2.2 Warum Entfernung teuer ist

Eine zweite Literatur, zur global verteilten Softwareentwicklung, erklärt den Mechanismus. Herbsleb und Mockus (2003) zeigten in der für dieses Papier zentralsten Studie empirisch, dass Arbeitseinheiten, die Menschen an mehreren Standorten erforderten, erheblich länger bis zur Fertigstellung brauchten als vergleichbare Einheiten an einem einzigen Standort, und führten die Verzögerung auf die Kosten und die Latenz der Kommunikation zurück, die die standortübergreifende Koordination verlangt. Ramasubbu und Balan (2007) maßen in ihrer Untersuchung von zwischen Indien und den Vereinigten Staaten verteilten Projekten dieselbe Einbuße unmittelbar in der Projektleistung. Olson und Olson (2000) lieferten das allgemeine Ergebnis unter dem Titel „distance matters“: Kollokierte Arbeit profitiert von der raschen, reichen, informellen Kommunikation, die verteilte Arbeit verliert, und kein Werkzeug stellt sie vollständig wieder her. Kraut und Streeter (1995) hatten bereits gezeigt, wie viel von der Softwareentwicklung Koordination statt Codierung ist, und Brooks (1975) hatte lange zuvor den Grund genannt, warum das Hinzufügen von Menschen zu verteilter Arbeit sie verlangsamen kann: Die Kommunikationspfade wachsen schneller als die Menschen. Die Lehre ist nicht, dass verteilte Entwicklung nicht funktionieren kann, sondern dass jede Grenze, die ein Stück Arbeit überqueren muss, einen Preis hat, und der Preis wird in Zeit und Fehlern bezahlt.

2.3 Conways Gesetz und die Architektur der Grenze

Die tiefste Idee, auf die sich das Papier stützt, ist die von Conway (1968): Die Struktur eines Systems spiegelt mit der Zeit die Kommunikationsstruktur der Organisation wider, die es baut. Ihr Korollar für das Offshoring ist genau und unternutzt. Sind Offshore und Onshore zwei lose kommunizierende Gruppen, dann wird die Software am saubersten sein, wenn die Grenze zwischen ihnen entlang einer echten architektonischen Naht verläuft, einem Modul mit definierter Schnittstelle, und am problematischsten dort, wo ein einzelner, eng gekoppelter Klumpen Arbeit über die Kluft hinweg zerteilt wird. Herbsleb und Grinter (1999) bestätigten dies unmittelbar und fanden, dass verteilte Entwicklung gelingt, wenn die Architektur modular genug ist, dass jeder Standort einen Teil besitzt und die Schnittstellen zwischen den Teilen explizit sind, und sich schwertut, wenn sie es nicht ist. Parnas (1972) lieferte die Entwurfsdisziplin, das Information Hiding, die solche Module möglich macht. Die praktische Konsequenz, die in Abschnitt 4 entwickelt wird, ist, dass das Besitzen der Architektur nicht eine der vielen Aufgaben des Command Centres unter mehreren ist; es ist die Aufgabe, die alle anderen möglich macht, weil sie entscheidet, wo die teure Grenze verläuft.

3. Das eigentliche Versagen: das Auslagern von Verantwortung

Das charakteristische Versagen des Offshoring ist nicht langsames Tippen; es ist Arbeit, die zuversichtlich fertiggestellt und stillschweigend falsch ist. Eine Anforderung wird übergeben, die im Kopf des Senders vollständig und auf dem Papier mehrdeutig ist, weil der Sender einen Kontext mit dem Geschäft teilt, den der Empfänger nicht hat. Der Offshore-Ingenieur, kompetent und willig, löst die Mehrdeutigkeit auf die einzige Weise auf, die aus zwölf Zeitzonen Entfernung verfügbar ist: indem er vernünftig rät und baut. Dass die Vermutung falsch war, wird bei der Abnahme entdeckt, sofern es eine Abnahme gibt, oder in der Produktion, sofern es keine gibt, und die Korrektur überquert die Kluft zweimal, einmal zur Erklärung und einmal zur Prüfung, wobei jede Überquerung einen an die Uhr verlorenen Tag kostet. Multipliziere dies mit jeder Mehrdeutigkeit in einem realen System, und die Arbitrage ist dahin, nicht weil irgendjemand etwas Inkompetentes getan hätte, sondern weil die Entscheidungen, die Kontext brauchten, dort getroffen wurden, wo keiner war.

Was geschehen ist, in der Sprache dieses Papiers, ist, dass das Unternehmen Verantwortung ausgelagert hat, als es nur Ausführung auslagern wollte. Die Verantwortung für ein Stück Software ist die angesammelte Befugnis, ihre Mehrdeutigkeiten richtig aufzulösen: zu wissen, was das Geschäft meinte, zu entscheiden, wie der Teil dem Ganzen dient, zu sagen, was „richtig“ ist. Diese Befugnis ist untrennbar vom Kontext, und Kontext ist lokal. Die Ausführung, das Bauen einer Sache, sobald ihre Mehrdeutigkeiten aufgelöst sind, ist nicht kontextgebunden und reist gut. Der Fehler ist, beide als ein Paket zu behandeln und sie gemeinsam zu verschicken; die Abhilfe ist, sie zu trennen, die Verantwortung onshore zu halten, wo ihr Kontext lebt, und offshore nur die Ausführung zu senden, mit ihren bereits in Spezifikation aufgelösten Mehrdeutigkeiten. Alles Weitere ist eine Ausarbeitung dessen, wie diese Trennung vorzunehmen ist und wo.

4. Das Command Centre

Das Onshore-Command-Centre ist die organisatorische Heimat der Verantwortung, die nicht reisen darf. Es ist bewusst klein und bewusst hochrangig, weil sein Hebel aus der Qualität einiger weniger Entscheidungen und nicht aus der Menge des Outputs stammt, und es sitzt neben dem Geschäft, nicht neben den Tastaturen. Abbildung 1 zeichnet das Modell, und Tabelle 3 teilt die Arbeit auf. Das Command Centre besitzt fünf Dinge, und die Disziplin des Modells besteht darin, dass es alle fünf besitzt und nichts anderes zu besitzen versucht.

Von der Absicht zur Spezifikation. Das erste Produkt des Command Centres ist nicht Software, sondern Spezifikation: die Übersetzung dessen, was das Geschäft vage will, in eine Darstellung, die präzise genug ist, um von jemandem gebaut zu werden, der sich nicht herüberlehnen und nachfragen kann. Dies ist die Arbeit, die Mehrdeutigkeit dort auflöst, wo der Kontext ist, damit keine dort aufgelöst werden muss, wo er es nicht ist, und es ist die Aktivität mit dem höchsten Hebel im gesamten Modell, denn jede in einer Spezifikation belassene Mehrdeutigkeit wird später zum vollen Preis eines Hin- und Rückwegs über die Kluft bezahlt.

Architektur und Schnittstellen. Nach Conways Gesetz wird die Software entlang der Kommunikationsnähte der Organisation brechen, und so besitzt das Command Centre die Architektur gerade deshalb, um zu wählen, wo diese Nähte verlaufen: Es zerlegt das System in Module mit expliziten Schnittstellen, sodass jeder Offshore-Pod einen Teil besitzt, den er mit wenigen grenzüberschreitenden Abhängigkeiten bauen kann. Die Grenze gut zu ziehen, ist das, was Entfernung aus einer bei jeder Interaktion gezahlten Steuer in eine nur an wenigen wohldefinierten Schnittstellen gezahlte Steuer verwandelt.

Priorisierung. Was zuerst gebaut wird, ist eine geschäftliche und keine lieferbezogene Entscheidung, und sie bleibt beim Command Centre, das das einzige Backlog und seine Reihenfolge hält. Die Priorisierung an das Offshore-Team oder an mehrere Stakeholder zugleich zu verteilen, führt über die Kluft hinweg genau jene Koordination wieder ein, die einzudämmen das Modell existiert.

Abnahme und das Qualitätstor. Das Command Centre entscheidet, was „fertig“ ist, und prüft die zurückgegebene Arbeit daran, wobei es ein Tor hält, dem das Geschäft vertraut. Dies ist das Gegenstück zur Spezifikation: Nachdem es die Korrektheit im Voraus definiert hat, verifiziert es sie bei der Rückkehr, und weil es onshore und nahe am Geschäft ist, kann es Eignung beurteilen, nicht bloß Funktion.

Ein verantwortlicher Eigentümer. Schließlich ist das Command Centre der Ort, an dem die Rechenschaft ungeteilt ist: ein einzelner Eigentümer, der dem Geschäft für das Gelieferte Rechenschaft schuldet und nicht über die Kluft hinweg zeigen kann. Rechenschaft, die über die Grenze geteilt ist, ist Rechenschaft, die abhandengekommen ist, und sie an einem einzigen Onshore-Punkt wiederherzustellen, macht einen Großteil dessen aus, was das Modell steuerbar macht.

5. Die Grenze ziehen

Wenn Command onshore bleibt und die Ausführung offshore geht, hängt alles davon ab, wo die Grenze zwischen ihnen gezogen wird, Aufgabe für Aufgabe. Das Modell, das die Wahl steuert, hat zwei Achsen. Die erste ist die Kontextlast einer Aufgabe: wie viel lokales, implizites, geschäftsspezifisches Wissen ihre korrekte Auflösung erfordert, hoch für eine Änderung, die eine subtile regulatorische Regel oder eine langjährige Kundenzusage berührt, niedrig für eine gut abgegrenzte Komponente mit klarem Vertrag. Die zweite ist die Spezifikationsvollständigkeit, die das Command Centre ihr geben kann: wie vollständig ihre Mehrdeutigkeiten im Voraus, auf dem Papier, ohne ein Gespräch aufgelöst werden können. Eine Aufgabe ist sicher auszulagern, wenn die Restmehrdeutigkeit, die den Offshore-Pod erreicht, ihre Kontextlast abzüglich der auf sie angewandten Spezifikationsvollständigkeit, klein ist. Schreibt man $\kappa$ für die Kontextlast und $s$ für die Spezifikationsvollständigkeit, beide auf einer gemeinsamen Skala, so ist die Restgröße

und es ist $\alpha$, nicht die rohe Schwierigkeit der Arbeit, das die Nacharbeit vorhersagt. Das Modell hat eine scharfe betriebswirtschaftliche Lesart, gezeichnet in Tabelle 1. Eine kontextarme Aufgabe lässt sich sauber auslagern, ungeachtet ihrer technischen Schwierigkeit. Eine kontextreiche Aufgabe ist nicht ungeeignet für das Offshoring; sie ist ungeeignet für das Offshoring im unspezifizierten Zustand, und die Aufgabe des Command Centres ist es, $s$ so weit zu erhöhen, bis $\alpha$ klein genug ist, um sie zu versenden. Wo die Kontextlast wirklich nicht reduzierbar ist, wo das Wissen überhaupt nicht niedergeschrieben werden kann, bleibt die Aufgabe onshore, und dies ehrlich anzuerkennen, gehört zur Disziplin. Der Versagensmodus, den das Modell benennt, ist die kontextreiche Aufgabe, die mit einer Spezifikation geringer Vollständigkeit versendet wird: maximale Restmehrdeutigkeit, offshore durch Raten aufgelöst, bei maximaler Entfernung.

6. Die Uhr

Die Zeitdifferenz zwischen einem westlichen Geschäft und Indien, etwa neun bis zwölf Stunden, ist das Merkmal, das Praktiker am häufigsten als reine Last behandeln und das das Command Centre am saubersten in einen Vorteil verwandeln kann. Unbeachtet ist die Kluft Latenz: Eine am Ende des Offshore-Tages gestellte Frage wird am Ende des Onshore-Tages beantwortet, und eine einzelne Klärung kostet einen Kalendertag, gleich welchen Gehalts, sodass eine Kette von Klärungen eine Woche kostet, um eine Stunde echten Inhalts aufzulösen. Dies ist der Mechanismus, durch den sich schlecht geführtes Offshoring langsam anfühlt, selbst wenn alle hart arbeiten: Der kritische Pfad läuft durch die Kluft, und die Kluft fügt pro Überquerung einen Tag hinzu.

Gut geführt, ist dieselbe Kluft eine zweite Schicht. Wenn das Command Centre Arbeit übergibt, deren Mehrdeutigkeiten bereits aufgelöst sind, führen die Offshore-Pods durch die Onshore-Nacht aus und liefern Ergebnisse bis zum Onshore-Morgen zurück, und der Tag, den das Geschäft verschläft, ist ein Tag des Fortschritts statt ein Tag des Wartens. Der Unterschied zwischen den beiden Ergebnissen ist ganz und gar die Restmehrdeutigkeit $\alpha$ dessen, was übergeben wird: Eine Übergabe mit $\alpha \approx 0$ braucht keinen Hin- und Rückweg, und die Uhr ist reiner Gewinn; eine Übergabe voller ungelöster Fragen wendet die Uhr gegen einen, weil jede Frage ein ganzer Tag ist. Eine grobe Art, es zu sehen, ist, dass die effektive Beschleunigung durch die zweite Schicht

wobei $\eta$ misst, wie sauber Arbeit übergeben werden kann, und $\alpha$ die Restmehrdeutigkeit aus Gleichung (1) ist; wenn $\alpha\to 0$, nähert sich die Uhr einer echten zusätzlichen Schicht, und wenn $\alpha$ steigt, bricht der Gewinn zusammen und kehrt sich dann in die Steuer von einem Tag pro Frage um. Das Command Centre verdient sich die Uhr, indem es die Spezifikation und die Definition von „fertig“ besitzt, die $\alpha$ klein machen, weshalb Follow-the-Sun eine Folge guten Commands ist und kein Planungstrick, der sich separat kaufen lässt.

7. Das Command-Verhältnis

Wie viel Command ist genug? Die Frage hat eine echte Antwort, und sie lautet weder „so wenig wie möglich“, der Instinkt, der das Über-die-Mauer-werfen-Offshoring hervorbringt, noch „so viel wie möglich“, was onshore die Kosten wiederaufbaut, die das Offshoring eigentlich abwerfen sollte. Sei $r$ das Command-Verhältnis, die Kapazität des Onshore-Command-Centres als Anteil der Offshore-Lieferkapazität, die es steuert. Command kostet den hohen Onshore-Satz $w_c$ pro Einheit; Delivery kostet den niedrigen Offshore-Satz $w_o$ pro Einheit. Der Wert von Command besteht darin, dass es die den Pods erreichende Restmehrdeutigkeit senkt und damit die Nacharbeit, die sie leisten müssen: mehr Command bedeutet mehr Arbeit, die spezifiziert, geprüft und, vor wie nach dem Überqueren der Kluft, durch Tore geführt wird, und somit einen niedrigeren Nacharbeitsmultiplikator auf der gelieferten Arbeit. Eine brauchbare Form für diesen Multiplikator ist

wobei $a$ die Nacharbeit skaliert, die gar kein Command verursachen würde, bestimmt durch die intrinsische Mehrdeutigkeit der Arbeit, und $b$ misst, wie wirksam sich Command in aufgelöste Mehrdeutigkeit umsetzt. Die Gesamtkosten der Lieferung einer Einheit fertiger Arbeit, Command plus nachgearbeitete Lieferung, betragen dann

eine Summe aus einem steigenden Term, den Kosten des Commands, und einem fallenden, der Nacharbeit, die Command verhindert, sodass sie ein einziges inneres Minimum hat. Setzt man $C'(r)=0$, so ergibt sich das kostenminimierende Command-Verhältnis

was das zentrale quantitative Ergebnis des Papiers ist. Es sagt drei Dinge, nach denen ein Manager handeln kann. Das optimale Maß an Command ist positiv: $r^\ast > 0$, sooft $w_o a b > w_c$, das heißt, sooft Command überhaupt wirksam und Mehrdeutigkeit überhaupt real ist, sodass das Über-die-Mauer-Werfen der Arbeit ($r = 0$) nie optimal ist. Es ist endlich: Command jenseits von $r^\ast$ kostet mehr als die Nacharbeit, die es spart, sodass auch das Behalten von allem onshore nicht optimal ist. Und es bewegt sich in die richtige Richtung: $r^\ast$ steigt mit der Mehrdeutigkeit der Arbeit ($a$) und damit, wie gut Command sie auflöst ($b$), und fällt, wenn Onshore-Command im Verhältnis zur Offshore-Lieferung teuer wird ($w_c/w_o$), sodass mehrdeutige, kontextreiche Portfolios eine dickere Command-Schicht rechtfertigen und einfache, gut abgegrenzte eine dünnere. Abbildung 2 zeichnet $C(r)$ und die beiden Versagensregime zu beiden Seiten des Optimums.

8. Ein konstruierter Fall

Der Fall ist konstruiert, nicht beobachtet: Seine Zahlen sind illustrativ und in sich stimmig, und er soll zeigen, dass die Größen des Modells plausible Werte annehmen, statt ein Ergebnis zu berichten. Eine westliche Gruppe betreibt die Anwendungsentwicklung für ihre Back-Office-Systeme und lagerte vor drei Jahren den Großteil davon auf Basis einer Personalaufstockung an einen Anbieter in Indien aus: Sie behielt eine Handvoll Onshore-Projektmanager, schrieb Anforderungen in der Form, in der sie es immer getan hatte, und maß den Erfolg an den verlagerten Köpfen und dem eingesparten Tagessatz. Auf dem Papier hatte sie die Kosten eines Entwicklers halbiert. In der Praxis hatte sich die durchgängige Lieferung eines Features, von der Anforderung bis zur abgenommenen Produktionsänderung, verlängert, die Rate der in die Produktion durchrutschenden Fehler war gestiegen, und ein großer und wachsender Anteil der Stunden des Offshore-Teams floss in die Nacharbeit von Features, die zu einer vernünftigen, aber falschen Lesart einer mehrdeutigen Anforderung gebaut worden waren. Die Ersparnis war brutto; netto war sie dünn und fallend. Tabelle 2 gibt die Vorher-Spalte.

Die Gruppe baute das Engagement daraufhin um ein Command Centre herum neu auf. Sie wechselte weder den Anbieter noch holte sie Arbeit nach Hause; sie fügte eine dünne, hochrangige Onshore-Schicht hinzu, ein paar Prozent des gesamten Personalbestands, die die Verantwortung für die fünf Dinge aus Abschnitt 4 übernahm: Sie schrieb Anforderungen als Spezifikationen mit expliziten Abnahmekriterien um, schnitt die Architektur neu, sodass jeder Offshore-Pod ein Modul hinter einer definierten Schnittstelle besaß, hielt ein einziges geordnetes Backlog und betrieb ein Abnahmetor, bevor irgendetwas die Produktion erreichte. Das Offshore-Team und seine Sätze blieben unverändert; was sich änderte, war die es erreichende Restmehrdeutigkeit $\alpha$. Die Nacharbeit fiel, als Spezifikationen das Raten auflösten, das sie getrieben hatte, die Rate der durchrutschenden Fehler sank, als das Tor abfing, was die Kluft zu verbergen pflegte, und die Uhr wandelte sich von Latenz in eine zweite Schicht, als Übergaben keine Hin- und Rückwege mehr brauchten. Die Kosten des hinzugefügten Commands waren ein Bruchteil der Nacharbeit, die es beseitigte, was Gleichung (5) in der Praxis ist: Das Engagement war weit links von $r^\ast$ gelaufen, und die Bewegung darauf zu senkte die Gesamtkosten, selbst während sie die Onshore-Kosten erhöhte. Tabelle 2 zeichnet die Veränderung nach.

9. Was sich für das Betriebsmodell ändert

Die Einführung des Command Centres ändert, worin ein Unternehmen gut sein muss, und die Änderung ist unbequem, weil sie dem Instinkt zuwiderläuft, der das Offshoring motiviert hat. Die Ersparnis ist nach wie vor real, aber sie wird nur eingefahren, indem man onshore und zu Senior-Sätzen für die Command-Schicht ausgibt, die der naive Business Case als zu beseitigende Verschwendung behandelte. Tabelle 3 legt die Arbeitsteilung dar, die das Modell verlangt. Zur knappen Ressource wird die Handvoll hochrangiger Menschen, die Absicht, Architektur und Abnahme gut halten können, und die Offshoring-Kapazität eines Unternehmens ist dadurch begrenzt, wie viele solcher Menschen es hat, nicht dadurch, wie viele Offshore-Ingenieure es einstellen kann. Auch die Messgröße ändert sich: verlagerte Köpfe und eingesparter Tagessatz, die Zahlen, die das Über-die-Mauer-Werfen-Offshoring gut aussehen lassen, werden ersetzt durch Feature-Durchlaufzeit, Fehlerdurchschlag und den Anteil der Offshore-Stunden, der in Nacharbeit fließt, die Zahlen, die offenbaren, ob Command seine Arbeit tut.

Es gibt eine zweite Verschiebung, nämlich dort, wo die Seniorität sitzt. Das Über-die-Mauer-Werfen-Offshoring neigt dazu, die interessante, hochrangige Arbeit zusammen mit dem Rest offshore zu schicken und eine junior besetzte Koordinationsschicht im Inland zu behalten; das Command-Centre-Modell kehrt das um, indem es die Seniorität onshore hält, wo der Kontext ist, und das Offshore-Team in der Ausführung glänzen lässt, ohne von ihm zu verlangen, Kontext zu liefern, den es nicht haben kann. Dies wird oft als Misstrauen gegenüber dem Offshore-Team fehlgedeutet. Es ist das Gegenteil: Es ist die Anordnung, die ein fähiges Offshore-Team seine beste Arbeit leisten lässt, indem sie ihm nicht abverlangt, Mehrdeutigkeiten aufzulösen, die niemand auf seiner Entfernung gut auflösen könnte, und indem sie ihm Spezifikationen gibt, die klar genug sind, dass seine Kompetenz auf das Bauen statt auf das Raten verwendet wird.

10. Einwände und Erwiderungen

Das Command Centre fügt nur Onshore-Kosten hinzu und erodiert die Ersparnis. Es fügt Onshore-Kosten hinzu und erhöht die Nettoersparnis, was der ganze Sinn von Gleichung (5) ist: Die meisten scheiternden Engagements sitzen weit links von $r^\ast$, wo etwas mehr Command viel mehr Nacharbeit beseitigt, als es kostet. Das Command Centre ist kein Gemeinkostenaufschlag auf die Ersparnis; es ist der Mechanismus, der eine Bruttoersparnis in eine Nettoersparnis verwandelt. Ein Unternehmen, das wirklich schon bei $r^\ast$ ist, sollte kein Command hinzufügen; fast keines ist es.

Wenn man alles so präzise spezifizieren muss, warum es dann nicht gleich onshore bauen? Weil Spezifikation und Konstruktion sehr unterschiedliche Kosten und sehr unterschiedliche Knappheiten haben. Spezifikation ist eine kleine Menge hochrangiger, kontextgebundener Arbeit; Konstruktion ist eine große Menge an Arbeit, die, einmal spezifiziert, nicht kontextgebunden ist. Das Modell schickt die große, leicht zu verortende Menge dorthin, wo sie erschwinglich ist, und behält nur die kleine, kontextgebundene Menge im Inland. Beide wieder zusammenzuführen, verzichtet auf genau die Arbitrage, die real ist.

Moderne Werkzeuge und Videotelefonate haben die Entfernung irrelevant gemacht. Sie haben sie kleiner gemacht, nicht irrelevant, und die Belege dafür, dass Entfernung weiterhin zählt, sind robust (Olson & Olson, 2000; Herbsleb & Mockus, 2003). Werkzeuge senken die Kosten einer Überquerung; sie beseitigen nicht den Tag, den die Uhr einem Hin- und Rückweg hinzufügt, noch stellen sie die informelle, beiläufige Kommunikation wieder her, die kollokierte Teams nutzen, um Mehrdeutigkeit aufzulösen, ohne es zu bemerken. Das Command Centre ist die strukturelle Antwort, die Werkzeuge ergänzen, aber nicht ersetzen.

Unser Offshore-Partner ist sehr fähig und kann das Ganze übernehmen. Fähigkeit ist nicht das Problem; Kontext ist es. Ein hochfähiges Offshore-Team kann eine Mehrdeutigkeit, deren Auflösung das Wissen darüber erfordert, was das Geschäft meinte, dennoch nicht auflösen, und es darum zu bitten, setzt seine Kompetenz gegen ein Problem, das die Entfernung unlösbar macht. Das Modell hält die Verantwortung onshore, nicht weil das Offshore-Team schwach wäre, sondern weil Verantwortung an einen Kontext gebunden ist, der onshore liegt.

11. Grenzen

Dies ist ein an Praktiker gerichtetes Argument mit einem bewusst einfachen Modell, und seine Grenzen sollten klar sein. Das Modell der Abschnitte 5 bis 7 ist illustrativ: Die Restmehrdeutigkeitsform von Gleichung (1), der exponentielle Nacharbeitsmultiplikator von Gleichung (3) und das einzige optimale Verhältnis von Gleichung (5) sind um der Lesbarkeit willen gewählte Vereinfachungen, und die Konstanten $a$, $b$, $w_c$ und $w_o$ werden hier nicht gemessen; ein Unternehmen kann sie aus seinen eigenen Nacharbeits- und Satzdaten schätzen, und wir würden erwarten, dass die qualitative Gestalt, ein inneres Optimum, das sich mit Mehrdeutigkeit und relativen Kosten verschiebt, selbst dort erhalten bleibt, wo die genaue Form es nicht tut. Das Argument ist auf Arbeit beschränkt, deren Mehrdeutigkeiten sich mit Anstrengung in Spezifikation auflösen lassen; wahrhaft forschungsartige Arbeit, bei der noch niemand weiß, was richtig ist, passt schlecht zum Modell und sollte überwiegend kollokiert bleiben. Das Papier stützt sich auf Indien, weil dort die Tiefe des Angebots und der Umfang der Praxis sind, aber nichts am Modell ist landesspezifisch; es gilt für jede Onshore–Offshore-Teilung über eine reale Entfernung und Uhr hinweg. Und das Modell setzt ein Unternehmen voraus, das überhaupt in der Lage ist, eine hochrangige Command-Schicht zu besetzen; ein Unternehmen, das es nicht kann, sollte ehrlich sein, dass es noch nicht gut auslagern kann, statt schlecht auszulagern und das Ergebnis zu einem Urteil über Indien zu erklären.

12. Fazit

Das Offshoring von IT-Arbeit nach Indien enttäuscht jene Unternehmen, die das Falsche auslagern: Sie verlagern die Verantwortung zusammen mit der Ausführung nach außen, lösen die Arbeit damit von dem Kontext und dem Urteilsvermögen, die sie richtig machen, und sehen dann zu, wie Nacharbeit und die Uhr die Ersparnis auffressen, derentwegen sie gekommen sind. Die Abhilfe besteht nicht darin, die Arbeit nach Hause zu holen, sondern sie richtig zu teilen, indem das dünne, hochrangige Command onshore gehalten wird, das neben dem Geschäft bleiben muss, zu entscheiden, was gebaut wird, die Architektur und die Schnittstellen zu besitzen, Absicht in Spezifikation zu verwandeln und die Abnahme zu halten, während die Ausführung in Indien skaliert, wo Talent reichlich und erschwinglich ist. Wo die Grenze zu ziehen ist, ist eine Frage, die die Restmehrdeutigkeit einer Aufgabe beantwortet, und das Handwerk des Command Centres besteht darin, die Spezifikation so weit zu erhöhen, bis diese Mehrdeutigkeit klein genug ist, um die Kluft zu überqueren; wie viel Command zu behalten ist, ist eine Frage mit einem echten Optimum, positiv und endlich, das mit der Mehrdeutigkeit der Arbeit steigt und fällt, wenn Command teuer wird. So gemacht, hört die Entfernung auf, eine Steuer zu sein, und die Zwölf-Stunden-Uhr wird zu einer zweiten Schicht, und die Arbitrage, die immer real war, wird endlich bewahrt. Lagere das Bauen aus; steuere es von zu Hause. Ein Unternehmen, das sich daran erinnert, welches der beiden an den Kontext gebunden ist und welches nicht, kann das Offshoring nach Indien meistern; ein Unternehmen, das es vergisst, wird weiterhin fälschlich schließen, das Problem sei das andere Ende der Leitung gewesen.

Anhang A. Aufbau eines Command Centres

Die folgenden Praktiken sind es, die die Trennung aus Abschnitt 4 in der Praxis tragen. Keine ist neu; die Disziplin ist der Wert.

Literaturverzeichnis

Brooks, F. P. (1995). The mythical man-month: Essays on software engineering (Anniversary ed.). Addison-Wesley. ISBN 978-0-201-83595-3. (Original work published 1975.)

Carmel, E. (1999). Global software teams: Collaborating across borders and time zones. Prentice Hall. ISBN 978-0-13-924218-6.

Carmel, E., & Agarwal, R. (2001). Tactical approaches for alleviating distance in global software development. IEEE Software, 18(2), 22–29. https://doi.org/10.1109/52.914734

Carmel, E., & Tjia, P. (2005). Offshoring information technology: Sourcing and outsourcing to a global workforce. Cambridge University Press. ISBN 978-0-521-84355-4.

Conway, M. E. (1968). How do committees invent? Datamation, 14(4), 28–31.

Herbsleb, J. D., & Grinter, R. E. (1999). Splitting the organization and integrating the code: Conway’s law revisited. In Proceedings of the 21st International Conference on Software Engineering (ICSE) (pp. 85–95). ACM. https://doi.org/10.1145/302405.302455

Herbsleb, J. D., & Mockus, A. (2003). An empirical study of speed and communication in globally distributed software development. IEEE Transactions on Software Engineering, 29(6), 481–494. https://doi.org/10.1109/TSE.2003.1205177

Kraut, R. E., & Streeter, L. A. (1995). Coordination in software development. Communications of the ACM, 38(3), 69–81. https://doi.org/10.1145/203330.203345

Krishna, S., Sahay, S., & Walsham, G. (2004). Managing cross-cultural issues in global software outsourcing. Communications of the ACM, 47(4), 62–66. https://doi.org/10.1145/975817.975818

Lacity, M. C., Khan, S. A., & Willcocks, L. P. (2009). A review of the IT outsourcing literature: Insights for practice. Journal of Strategic Information Systems, 18(3), 130–146. https://doi.org/10.1016/j.jsis.2009.06.002

Malone, T. W., & Crowston, K. (1994). The interdisciplinary study of coordination. ACM Computing Surveys, 26(1), 87–119. https://doi.org/10.1145/174666.174668

Olson, G. M., & Olson, J. S. (2000). Distance matters. Human–Computer Interaction, 15(2–3), 139–178. https://doi.org/10.1207/S15327051HCI1523_4

Oshri, I., Kotlarsky, J., & Willcocks, L. P. (2007). Managing dispersed expertise in IT offshore outsourcing: Lessons from Tata Consultancy Services. MIS Quarterly Executive, 6(2), 53–65. https://aisel.aisnet.org/misqe/vol6/iss2/3/

Parnas, D. L. (1972). On the criteria to be used in decomposing systems into modules. Communications of the ACM, 15(12), 1053–1058. https://doi.org/10.1145/361598.361623

Ramasubbu, N., & Balan, R. K. (2007). Globally distributed software development project performance: An empirical analysis. In Proceedings of the 6th Joint Meeting of the European Software Engineering Conference and the ACM SIGSOFT Symposium on the Foundations of Software Engineering (ESEC/FSE 2007) (pp. 125–134). ACM. https://doi.org/10.1145/1287624.1287643

Rottman, J. W., & Lacity, M. C. (2006). Proven practices for effectively offshoring IT work. MIT Sloan Management Review, 47(3), 56–63. https://sloanreview.mit.edu/article/proven-practices-for-effectively-offshoring-it-work/

Sahay, S., Nicholson, B., & Krishna, S. (2003). Global IT outsourcing: Software development across borders. Cambridge University Press. ISBN 978-0-521-81604-5.