Mittwoch, 28. November 2012

1992 GIGAsteps Classics: Insourcing (Teil 6)



„An dieser Stelle möchte ich hervorheben, dass jede gesellschaftliche Institution, wenn sie bei der Bewältigung von Informationen wirklich funktionieren soll, ein theoretisches Konzept vom Zweck und von der Bedeutung von Information haben muss, dass sie über Mittel verfügen muss, diesem Konzept einen klaren Ausdruck zu geben, und zwar vor allem, indem sie bestimmte Informationen unterdrückt."

Neil Postman, amerikanischer Sozialkritiker in seinem Buch „Das Technopol"

5.0 Gegen den Egoismus

5.1 In Erwartung des Unerwarteten

Ko‑Ordination. Ungeduld ist das, was sich in den neunziger Jahren kein Unternehmen mehr leisten kann. „Das größte Problem, das wir in den neunziger Jahren haben ist nicht technischer Natur, sondern das der Koordination von Menschen", befindet Laszlo Belady, Direktor des Software Research Programms bei dem Forschungs‑Konsortium Microelectronics & Computer Technology Corp. (MCC) in Austin (Texas). „Koordination von Leuten ist das Geschäftsproblem schlechthin, das Manager lösen wollen", bestätigt auch Benn Konsynsky, Professor für Management Informations‑Systeme an der Harvard Business School. Denn von den Menschen geht stets das Unerwartete aus.
Das  Datenmodell kann hier enorm helfen, das Unerwartete zu erwarten, klärt es doch zumindest die gemeinsam verwendeten Begriffe. Sie müssen eindeutig sein, wenn das funktionieren soll, was Thomas Malone, Professor am Massachusetts Institute of Technology (MIT), den „Stoffwechsel der Informationen" nennt, der nicht nur zwischen den Benutzern und dem Computer, sondern zwischen verschiedenen unternehmensweit verteilten Datenbanken ‑ und damit zwischen Menschen aus unterschiedlichen Abteilungen und Bereichen ‑ stattfindet. [1]Engstirniger Abteilungsegoismus läßt sich in den neunziger Jahren nicht mehr durchhalten. Es muss unternehmensweite Klarheit herrschen über die verwendeten Begriffe, wenn sich so etwas wie die vorgangsorientierter Arbeitsweise durchsetzen soll. Und damit sind auch die Topmanager im Boot, die allzu gerne der DV die Schuld zuweisen für organisatorische Mißstände. „Dabei waren sie es, die es versäumten, den Technologen die richtigen Fragen zu stellen", dreht Colin Lesson von der Managementberatung PA Computers and Telecommunications den Spieß um.[2] Das Thema, das damit adressiert wird, ist die Prozeßmodellierung, die gleichsam neben der  Datenmodellierung aufsetzt. Mit ihr kann der Informationsfluß vorgangsorientiert gesteuert werden und somit einen Puffer gegen den größten Störfaktor, das Unerwartete, bilden.
Dieses Unerwartete wird vor allem dann offenbar, wenn Systemwechsel anstehen ‑ und zwei Softwarewelten aufeinander stoßen:
Außer Kontrolle. So wurde im September 1991 das Auswärtige Amt Großbritanniens vom Rechnungshof, dem House of Commons Public Accounts Committee, „stark kritisiert", weil es sein Rechnungswesen softwaretechnisch miserabel unterstützte. Der Übergang von einer alten zu einer neuen Anwendung, der mit einem Jahr Verspätung im November 1989 vollzogen wurde, erwies sich als eine Katastrophe. Die neue Software produzierte einmal ganz andere Ergebnisse als die alte Anwendung, die parallel für eine Übergangszeit noch gefahren wurde. Zum anderen nutzte der Kassierer des Auswärtigen Amtes die mangelhaften Kontrollmechanismen und bereicherte sich um 31.000 Pfund. Kleinmütig musste das Außenministerium zugeben, dass es nicht in der Lage war, solch ein Projekt zu managen. „Wir waren konsterniert darüber, dass es so lange gedauert hat, bis dies erkannt wurde und ein besseres Projekt‑Management installiert wurde", schrieben die britischen Rechnungsprüfer.[3] Das Informationschaos wird zumeist in dem Augenblick offenbar, in dem Daten unternehmensweit erschlossen und integriert werden sollen. Der egoistisch angelegte Funktionalismus begrenzte den Sinn der Informationen zu stark auf Abteilungs‑ oder Fachbereichsebene. Damit zerstörte er nachhaltig den Zugang zum Rohstoff, zu den Daten, die dem Gesamtunternehmen gehören und auch von ihm erschlossen werden sollen. Das Datenchaos ist das Ergebnis. Der den Benutzeranforderungen hinterherhetzende Funktionalismus, der der Softwareentwicklung oktroyiert wurde, erstickt mit der Zeit jeden Versuch, die Daten unternehmensweit zu öffnen. Er produzierte nur spezielle Informationen, die routinemäßig einem genau definierten, eingeengten Insider‑Kreis vorbehalten waren.

5.2 Gegen die Abteilungsgrenzen

Prozeßmodellierung. Den kaum zu befriedigenden Druck in Richtung Funktionalismus erzeugen immer wieder die Abteilungsmanager, die nach höherer Produktivität strebten ‑ nicht des Gesamtunternehmens, sondern des einzelnen Mitarbeiters, für den sie Verantwortung tragen. Terrence R. Ozan, der bei der Wirtschaftsprüfung Ernst & Young in den USA den Fertigungsmarkt betreut, ermittelte aber, dass die „Arbeitskosten bislang zwar einen bedeutenden Faktor bei den Investitionsentscheidungen spielten. Doch in einigen Fällen haben wir inzwischen herausgefunden, dass die Arbeitskosten so unbedeutend sind für das gefertigte Produkt, dass es sich noch nicht einmal lohnt, sie zu messen."[4]
Nicht durch Erbsenzählen wird Produktivität erzielt, sondern durch Straffung und Ordnung der unternehmensweiten Geschäftsprozesse und Berichtswege. So folgt denn auch der  Datenmodellierung die Prozeßmodellierung auf dem Fuß. Und diese Annäherung weist deutlich über die bisherige Anwendungswirklichkeit hinaus, die sich am Egoismus von Abteilungen und Mitarbeiter orientiert. „Die Fachbereiche glaubten in der Vergangenheit, dass sie ihre Daten für sich allein gepachtet hätten. Dieses Besitzstandsdenken läßt sich heute nicht mehr aufrecht erhalten", meint CAP‑debis‑Berater Mistelbauer. „Daten müssen heute im Unternehmen optimal genutzt werden. Sie müssen deshalb entlang der neuen Prozeßketten allen verfügbar sein."
Noch verharren indes zuviele Unternehmen in diesem Abteilungsegoismus. Dies bestätigt eine amerikanische Untersuchung, die von den Wissenschaftlern Thomas Davenport, Robert Eccles  und Lawrence Prussack an der Sloan Management School bei 25 US‑Firmen durchgeführt wurde. Danach grassierte in der Hälfte der Unternehmen das, was die Experten ironisch „Informations‑Feudalismus" nennen, ein Drittel der Firmen schwelgte in einer „Informations‑Utopie" und der Rest litt unter „Informations‑Anarchie". Aussage der Wissenschaftler: „In den meisten informationsorientierten Unternehmen, die wir analysierten, waren die Mitarbeiter am wenigsten dazu bereit, Informationen untereinander zu teilen.[...] Wenn Information die primäre Währungseinheit sind, dann sollten wir nicht erwarten, dass deren Eigentümer auch bereit sind, sie einfach zu verschenken."[5]
Um diese Zustände zu durchbrechen, unter denen die Firmen offensichtlich kräftig litten, empfehlen sie den „Informations‑Föderalismus". Und wenn Information eine Währung ist, dann müßte es auch so etwas wie eine Bundesbank geben, die darüber wacht. Vorsitzender einer solchen Institution wäre dann der Chief Information Officer sein. Er sollte darüber wachen, dass „die mächtigen Barone bereit sind, Informationen mit anderen zu teilen." Firmen, die diese Strategie beherzigen, sind nach Aussage der Wissenschaftler IBM, Xerox, Kodak und Merrill Lynch. Hier stünden an der Spitze der betrieblichen  Informatik Manager, die sich weniger durch technische background auszeichneten, sondern vielmehr durch Führungsqualitäten. „Kein noch so hoher Aufwand an  Datenmodellierung, keine noch so große Zahl an relationalen Datenbanken und keine noch so große Beschwörung der `informationsbasierenden Firma' kann eine neue Informationspolitik herbeizaubern. Was man dazu benötigt, ist das, was einen Politiker auszeichnet: Verhandlungsgeschick, Ausübung von Einfluss, Arbeit im Hintergrund, Bildung von Koalitionen und gelegentlich sogar das Heraufbeschwören eines Krieges." Der Information Manager ist also eminent gefordert. Letztlich muss er mithelfen, die gesamte Unternehmensorganisation zu erneuern, damit die „Währung Information" endlich in Fluß gerät.
Drei Beispiele. Dort, wo die Macht der Barone gebrochen wurde, da wurden auch überraschende Ergebnisse erzielt:
-         Die Trustee Savings Bank (TSB) in Großbritannien hatte seit 1988 das Netzwerk ihrer 1.400 Zweigstellen völlig reorganisiert. 25 Prozent der Arbeit, die bislang vor Ort erledigt wurde, aber nichts mit einem direkten Kundenkontakt zu tun hatten, wurden zentralisiert. Gleichzeitig wurden die Zweigstellenleiter mit mehr Kompetenz ausgestattet. Mit wenigen Tastengriffen stehen den Mitarbeitern alle Informationen zur Verfügung.[6] So können sich die Mitarbeiter mit dem gesamten Unternehmenswissen dem Unerwarteten stellen.
-         Eine Versicherungsgesellschaft ermittelte, dass eine neue Police durchschnittliche 22 Tage brauchte, bis sie von allen Instanzen bestätigt war. Die tatsächliche Bearbeitungszeit aber betrug nur 17 Minuten. Der Rest der Zeit ging dafür drauf, die Police zwischen den Experten hin und her zu bewegen. Nun bearbeitet ein einziger Mitarbeiter den Vorgang, der nach eigenem Gutdünken die Experten einschaltet. Der amerikanische Versicherer Mutual Benefit Life schaltete um auf diese vorgangsorientierte Arbeitsweise und registrierte einen Produktivitätsanstieg von 60 Prozent.
-         Die IBM Credit Corp. (ICC), die für das Leasing‑Geschäft des Computerherstellers in den USA und anderen Ländern verantwortlich ist, reduzierte durch ähnliche Maßnahmen die Bearbeitungszeit von Spezial‑Verträgen von sechs Tagen auf vier Stunden. Gleichzeitig erhöhte sie den Durchsatz an Verträgen um den Faktor 10. Es werden zudem weniger Mitarbeiter gebraucht. 
Der Erfolg liegt nicht so sehr in den Produktivitätsgewinnen, die diese Beispiele dokumentieren, sondern dass sich der Mensch so dem Unerwarteten viel besser stellen kann. Er kontrolliert den „technologischen Impetus" ‑ wie es der Philosoph Hans Jonas nennt. Der Mitarbeiter koordiniert die Vorgänge so, dass deren möglicherweise überraschenden Implikationen ihre zerstörerischen Wirkungen verlieren. Und die Technologie unterstützt ihn dabei.
Sprache als Schlüssel. Das alles verlangt, dass ‑ wie bereits gesagt ‑ unternehmensweit Klarheit und Verbindlichkeit über die verwendeten Begriffe besteht. Die Worthorizonte müssen genau abgestimmt sein. Was ein „Kunde" ist, muss in seiner Bedeutung ebenso eingegrenzt sein wie der Begriff „Auftrag". So bequem es ist, Begriffe aus freiem Gutdünken mit eigenen Bedeutungen einzuführen, im Zusammenspiel eines vorgangsorientiert arbeitenden Unternehmens können sie den Sinnzusammenhalt zerstören. Dann entsteht erneut Informationschaos.
Es ist nunmal höchste Zeit, dass eine einheitliche Sicht der Daten angepackt wird. Denn die Glaubwürdigkeit der Datenverarbeitung wird längst in der Wirtschaftspresse diskutiert. So berichtete die Londoner Financial Times von folgendem Fall.
Die ganze Person... In ein Desaster geriet die Sozialversicherung in Großbritannien, die in den sechziger Jahren noch zu den Pionieren auf dem Gebiet des DV‑Einsatzes gehörte. In den frühen achtziger Jahren war das System indes völlig verrottet. In den Außenstellen der staatliche Rentenversicherung mussten die Zahlungen an 20 Millionen manuell ausgerechnet werden. Versuche, das System dann 1983 zu erneuern, scheiterten zuerst einmal kläglich im Kompetenzstreit der einzelnen Behörden. Das Sozialministerium schaltete schließlich die Beratungsfirma Andersen Consulting ein, um das Projekt neu aufzusetzen. Sieben Jahre später hatten die Berater und Mitarbeiter das 1,5 Milliarden Pfund teure Superprojekt dann gemeistert.
Managebar wurde es, weil Andersen Consulting dahinter eine Vision gesetzt hatte, die von jedem verstanden werden konnte. Es war die Idee von der whole person. Über jeden Empfänger sollte ein genau modelliertes Datenbild angelegt werden, in das all seine Bezüge eingebracht werden konnten.
... der ganze Vorgang. Im Hintergrund dieses  Datenmodells stand aber auch eine ganz andere Arbeitsweise für die rund 34.000 Mitarbeiter. Das heißt: die Prozesse wurden neu modelliert. Obwohl durchaus hervorragend ausgebildet, mussten die Sachbearbeiter bislang stupide Fließbandarbeit im Büro erledigen. Mit der Computerisierung sollte das in vorgangsorientierte Arbeitsweisen umgestaltet werden. Ein richtiger, wengleich auch sehr ehrgeiziger Ansatz, zumal viele Mitarbeiter noch nie in ihrem Leben mit einer Tastatur gearbeitet hatten. 
Die Entwickler, die an dem Projekt beteiligt waren, wußten genau, dass „ihre persönliche Karriere auf dem Spiel stand, falls es schief lief", berichtet Keith Burgess, Managing Partner bei Andersen Consulting. Genau das schreckte so manchen ab. Dennoch ‑ das Projekt wurde gemeistert, denn die meisten erkannten, dass ihnen eine Chance geboten worden war, die man nur einmal in seinem Leben bekommt.
Auf seinem Höhepunkt waren 2.000 Mitarbeiter an der Implementierung des komplexen Software‑Systems beteiligt, das 70 Mainframes an sechs Lokationen umfaßte. „Es ist ohnegleichen in der kommerziellen Welt und vielleicht sogar auch gegenüber dem Verteidigungsbereich" (Burgess), obwohl hier bereits große Erfahrungen auf dem Gebiet langjähriger Superprojekte gesammelt wurden. Doch nach Meinung von Burgess gab es bislang kein Projekt „dieser Größenordnung und Komplexität".[7] Na gut.
Das Beispiel zeigt, dass von einem einzigen Begriff, dem der whole person, Wohl & Wehe eines ganzen Projektes abhängig sein kann. Der Chemiekonzern Hoechst AG in Frankfurt, der kräftig in die  Datenmodellierung investiert, hat aus diesem Grund sogar ein „Genehmigungsgremium für Unternehmensbegriffe" gegründet. Geleitet wird es übrigens von einem Vorstandsmitglied. So wird die Flut von Synonymen, Homonymen etc. eingedämmt. Über die Sprache erschließt sich ein Unternehmen dann seine neuen und seine in den alten Infrastrukturen verborgenen Potentiale.

5.3  Der Methodenstreit

Rückendeckung vom Topmanagement. Es ist in der Tat ein Thema, das unbedingt die Rückendeckung durch das Topmanagement benötigt. Für Henkel‑Manager  Rhefus beginnt sogar alles „beim Topmanagement, das für die zentralen Unternehmensbegriffe verantwortlich sein sollte und gleichzeitig durch Grundsatzentscheidungen die Voraussetzung für ein einheitliches Vorgehen schaffen muss." So geschehen bei Henkel. Und bei der Lufthansa genießt die  Datenmodellierung ebenfalls die „erforderliche Aufmerksamkeit des Topmanagements", berichtet  Münzenberger. Hier wird auch von den Fachbereichen akzeptiert, „dass die  Datenmodellierung ein ausgezeichnetes Kommunikationsmittel zwischen ihnen und der Datenverarbeitung darstellt". Bereits Mitte der achtziger Jahre hat die Luftlinie damit begonnen, das  Vettersche `Jahrhundert‑Problem' anzugehen. Empfiehlt  Münzenberger: „Wichtig ist dabei, dass vor allem die organisatorischen Voraussetzungen geschaffen wurden, um dem Datenchaos zu Leibe zu rücken. Wir gehen nach der Reihenfolge vor: Mensch, Methoden, Tools. Also zuerst die Information, dann die Schulung und schließlich die technischen Hilfsmittel ‑ inklusive eines umfassenden Projektsupports. Das hat sich bewährt."
Die Richtigkeit dieser Vorgehensweise bestätigt auch Howard Fosdick, Präsident der Fosdick Consulting Inc. in Villa Park (Illinois): „Zum ersten Mal seit 30 Jahren entfernen wir uns von dem Codieren" als dem vorherrschende Organisationsprinzip für Anwendungsentwickler. Statt des Funktionalismus rücken Training und Methodologie an die erste Stelle.[8]
Philosophiestreit. Bei der Vorgehensweise zum Thema  Datenmodellierung stoßen natürlich immer wieder zwei Denkansätze aufeinander: top‑down oder bottom‑up. Henkel‑Manager  Rhefus stellt die beiden Methoden so vor:
„Beim top‑down‑Ansatz [...] wird zunächst der Informationsbedarf des Unternehmens in einem groben Unternehmensdatenmodell (UDM) abgebildet. Das UDM dient dann als Basis für die Erstellung detaillierter Projektdatenmodelle."
„Beim bottom‑up‑Ansatz werden die nacheinander entstehenden Projektdatenmodelle zunächst zu einem Basisdatenmodell integriert. Dieser wird dann jeweils zu einer aus mehreren Ebenen bestehenden Unternehmens‑Datenarchitektur verdichtet, deren oberste Ebene dem UDM des top‑down‑Ansatzes vergleichbar ist."
Gleichgültig, für welche Methode man sich entscheidet ‑ Pragmatismus ist bei alldem gefragt und gefordert, weshalb viele das „bottom‑up"‑Verfahren zuerst einmal bevorzugen. Denn dort, wo  Datenmodellierung im „Top‑down"‑Verfahren von einem globalen Ansatz angegangen wird, wird sie schnell „als eine theoretische Sicht" stigmatisiert, wie Alan Bignall, Vice President für Informationssysteme beim Finanzdienstleister IDS, diese Vorgehensweise bezeichnet.[9] Mit ihr können sich vor allem die Benutzer nicht identifizieren, aber auch nicht das Topmanagement, die dieser Form der Grundlagenforschung unwillig gegenüber steht. Es ist ihm suspekt und bestätigt einmal mehr die leidvollen Erfahrungen der Vergangenheit mit der Datenverarbeitung. Deshalb hat das „bottom‑up"‑Verfahren mehr Freunde. So auch bei der Lufthansa. Hier wurde zuerst eine klassische bottom‑up‑Philosophie gefahren. Das heißt aus den einzelnen, bestehenden Anwendungen wurde das  Datenmodell herausdestilliert.  Münzenberger: „Diese wird künftig vermehrt durch Top‑down‑Betrachtungen überlagert. So wurde zuerst für das Vorstandsressort Technik über projektbezogene  Datenmodelle auch ein Ressort‑ Datenmodell erstellt. Dies wiederum dient als Input für das Lufthansa‑ Datenmodell".
Insgesamt besitzt die Lufthansa etwa ein gutes Dutzend Experten auf dem Gebiet der  Datenmodellierung. Mitte der neunziger Jahre wird die Airline soweit sein, dass alle Modelle zu einem einzigen globalen Gebilde zusammenfließen.
Ein rechtzeitiges Umschalten von „Bottom‑Up" auf „Top‑Down" empfiehlt auch Adam Crescenzi, Berater bei der der amerikanische Index Group. Denn nur so kann seiner Meinung nach das mehr experimentelle Vortasten in konsistente Prinzipien umschlagen kann. Seine Sorge ist, dass mit dem reinen Bottom‑Up‑Verfahren nur die bestehende Abteilungs‑Bürokratie abgearbeitet wird, aber nicht der in den neunziger Jahren viel wichtigere Entscheidungsfindungsprozeß abgedeckt wird, der ja unternehmensübergreifende Bedeutung hat.[10]
Die Plus‑Methode. Weil indes beide Verfahren eindeutige Vorteile auf ihrer Seite haben, ist man im Rahmen einer Arbeitsgruppe der Benutzervereinigung GUIDE, die das Thema Enterprise Modelling analysiert und bewertet, zu der Überzeugung gekommen, sie miteinander zu kombinieren. Daraus entstand ein bottom‑up plus‑Verfahren und eine top‑down‑plus‑Methode.
So kann man bei der bottom‑up‑plus‑Methode, wie  Rhefus erläutert, „die Erstellung des Fundaments beschleunigen, indem man neben dem Tagesgeschäft Basissysteme modelliert (Kunde, Produkt, Anlage), deren Daten für viele Anwendungen von Bedeutung sind." Und bei deren Gegenstück, dem top‑down‑plus‑Verfahren wird zuerst ein Unternehmensdatenmodell entwickelt, deren Informationsobjekte dann unentwegt mit Projektdatenmodellen abgeglichen wird. Auf diese Weise entsteht am Ende ein unternehmensweites  Datenmodell.
Datenmodellierung verlangt aber auch, dass die Autorität der Datenverarbeitung gestärkt werden muss. Doch das gelingt nur, wenn sie sich in Übereinstimmung mit der Unternehmens‑Vision befindet. Wie das geht, macht ein Beispiel aus den USA deutlich. Bei der IDS Financial Services in Minneapolis, einer 1984 von American Express übernommenen Versicherungsgesellschaft, wird seit 1987 kein Projekt gestartet, „bevor nicht der Datenadministrator das  Datenmodell für diese Anwendung kreiert hat, das dann Eingang findet in die unternehmensweite Datenarchitektur", berichtet der verantwortliche Manager Alan Bignall. Hintergrund dieser Entscheidung war ein radikaler Strategiewechsel.
Der Finanzdienstleister hatte sich 1984 eine neue Vision gegeben. Das Topmanagement beschloß, dass das Unternehmen nicht mehr versuchen sollte, die beste Versicherung, sondern der beste Finanz‑ und Vermögensplaner am US‑Markt zu sein. Das bedeutete, dass es seine Kunden nur dann optimal bedienen konnte, wenn es über die beste Datenbasis verfügte. Und die war verteilt über funktionale Datenhäfen wie VSAM, DL/1, uralte CICS‑gebundene Assembler‑Dateien und modernes DB2. Eine Gruppe von 14  Datenmodellierern wurde 1984 aufgebaut, die bottom‑up die Datenarchitektur schuf. „Das erste  Datenmodell, das wir schufen, war der `Kunde'. Denn wir sahen ihn als das Herzstück an. Es stellte sich heraus, dass dies die richtige Vermutung war. Dann wechselten wir über zum Marketing‑Modell und diese beiden paßten dann sehr gut zusammen." Nach drei Jahren etwa stand dieser Kern. Doch so richtig komplett wird das globale  Datenmodell erst 1993 sein. Eine lange Zeit, die viel Geduld von den Beteiligten abverlangt. Dennoch ‑ die Anstrengung lohnt sich: „Solange sich unsere Vision nicht ändert, garantieren wir dafür, dass sich die Architektur nicht ändern muss", erklärt IDS‑Manager Bignall.[11]
Redundanz. Schon aus eigenem Antrieb heraus werfen deshalb die höchsten Führungskräfte ein Auge auf das gestalterische Wirken im Bereich der  Informatik. Denn: „Fast jeder Vorstand kann eine Story darüber erzählen, was passiert, wenn er zu einem Thema konsolidierte Zahlen haben möchte", berichtet Peter <$IPersonen; Kirn, Peter>Kirn, Leiter Softwaremarketing bei der IBM Deutschland GmbH in Stuttgart. In manchem Betrieb wurden schon fünf unterschiedliche Berichte erstellt, wenn zum Beispiel ein Executive nach den Kosten pro Mitarbeiter verlangt ‑ nur weil es unterschiedliche Auffassungen darüber gab, was ein Mitarbeiter ist.[12]
Hinzu kommt der Datensalat: Funktional völlig mit den Anwendungen verquickt, werden Kirns Meinung nach in vielen Unternehmen mehr als 50 Prozent der Daten redundant gehalten ‑ mit dem Problem, die Konsistenz dieser Informationen zu bewahren.
Das steigert zwar die Plattenverkäufe der Hersteller, was angesichts sinkender Preise noch zu verschmerzen wäre. Aber weitaus schwerwiegender ist, dass die Entwicklungsarbeit mit einer kaum noch beherrschbaren Komplexität überfrachtet wird, die durch den Wunsch nach Integration heterogener Systeme drastisch verschärft wird.
„Den Preis bezahlen heute die Entwickler, für die immer mehr Anwendungen immer weniger beherrschbar sind. Und die Benutzer bekommen nicht die Anwendungen, die sie sich vorgestellt haben", analysiert IBM Geschäftsführer Dorn. Radikales Umdenken wird verlangt ‑ hin zu Investitionen, die keiner sieht...


[1] Fortune, 8.6.87, Louis S. Richman: „Software catches the team spirit“
[2] Financial Times, 30.4.87: „The case for IT as a matter of life and death"
[3] Financial Times, 5.9.91, Robert Mauthner: „Foreign Office is criticised for inadequate controls" >]
[4] Datamation, 1.2.90: „Updating U.S. manufacturers bean counting" >]
[5] Financial Times, 19.10.92, Christpher Lorenz: „From feudalism to federalism"
[6] The Economist, 15.10.91: „Reinventing companies"
[7] Financial Times, 11.12.91, Alan Pike: „Benefits of a seven‑year itch"
[8] Computerworld, 2.7.90, Rosemary Hamilton: „CASE veterans say: lool before you leap"
[9] Computerworld, 18.5.87, Amy Fiore: „It hurt, but IDS built an architecture"
[10] The Economist, 15.10.91: „Reinventing companies"
[11] Computerworld, 18.5.87, Amy Fiore: „It hurt, but IDS built an architecture"
[12] Datamation, 1.1.90, Ralph Carlyle: „Is Your data ready for the repository?"

TEIL I // TEIL II // TEIL III // TEIL IV // TEIL V // TEIL VI // TEIL VII //

Keine Kommentare: