Willkommen in Manus Zeitforum
InformationenAnmelden Registrieren

Erweiterte Suche

Über die Komplexität heutiger Software-Systeme

Thema erstellt von Grtgrt 
Beiträge: 1.566, Mitglied seit 11 Jahren
 
Vor kurzem ging eine Meldung durch die Presse, in der man las:

"Das Milliarden-SAP-Projekt der Deutschen Bank:

Die Deutsche Bank schmeißt ihr selbstgestricktes Kernbankensystem raus. Es folgt SAP-Software. Rund 1200 Mitarbeiter arbeiten voraussichtlich bis 2015 an dem Mammutprojekt. Am Ende will die Bank damit 250 Millionen Euro pro Jahr sparen."


Das eigentlich Interessante daran ist nun, wie ich (grtgrt) finde, dass Wolfgang Gaertner, CIO Retail der Deutschen Bank AG, sagt:

SAP bietet großen Banken eine bewährte Plattform. "Wir brauchen daher nur zu parametrisieren und müssen nicht Software entwickeln".


Als staunender Leser frägt man sich da nun:

Wie komplex muss Software sein, wenn allein um sie geeignet zu konfigurieren und in Betrieb zu nehmen 1200 Mitarbeiter 3 Jahre lang beschäftigt sind?

Und wieviel Fehler mag diese Anwendung dann zunächst mal enthalten?


 
[Gäste dürfen nur lesen]
Beiträge: 2.998, Mitglied seit 15 Jahren
Grtgrt schrieb in Beitrag Nr. 1957-1:
... Rund 1200 Mitarbeiter arbeiten voraussichtlich bis 2015 an dem Mammutprojekt.
.
.
Wie komplex muss Software sein, wenn allein um sie geeignet zu konfigurieren und in Betrieb zu nehmen 1200 Mitarbeiter 3 Jahre lang beschäftigt sind?

Wir sollen froh sein, dass mal was entwickelt wird, das Arbeitsplätze schafft und nicht vernichtet
3 Jahre und 1200 Menschen, die ihren Lebensunterhalt verdienen können......

Zitat:
Am Ende will die Bank damit 250 Millionen Euro pro Jahr sparen.

... und hoffentlich dann nicht auf Kosten von Entlassungen
Signatur:
Wer jung ist, meint, er müsste die Welt retten :smiley8:
Der Erfahrene erkennt, dass er nicht alle Probleme lösen kann
:smiley3:
[Gäste dürfen nur lesen]
Beiträge: 2.998, Mitglied seit 15 Jahren
Ich hätte da mal ´ne rechtliche Frage:

Ich habe in unserem Betrieb auch schon Software geschrieben, z.B für die Regeleung und Visualisierung unserer Klimaanlagen.

Darf ich diese Software mit einem "Verfallsdatum" programmieren, so dass sie nur bis zu einem bestimmten Datum funktioniert.
Dann müsste ich die Lizenz verlängern, was ich natürlich nur kann, wenn ich dort noch beschäftigt bin. Ihr versteht, was ich meine :idea:
Signatur:
Wer jung ist, meint, er müsste die Welt retten :smiley8:
Der Erfahrene erkennt, dass er nicht alle Probleme lösen kann
:smiley3:
[Gäste dürfen nur lesen]
Beiträge: 1.566, Mitglied seit 11 Jahren
 
Hans-m schrieb in Beitrag Nr. 1957-3:
Ich habe in unserem Betrieb auch schon Software geschrieben, ,,,

Darf ich diese Software mit einem "Verfallsdatum" programmieren, so dass sie nur bis zu einem bestimmten Datum funktioniert.
Dann müsste ich die Lizenz verlängern, was ich natürlich nur kann, wenn ich dort noch beschäftigt bin. Ihr versteht, was ich meine :idea:

Hi Hans,

wenn du jene Software auf Kosten deines Arbeitgebers geschrieben hast, gehört sie — und auch das Nutzungsrecht — alleine ihm.

Ausnahmen bestehen (meines beschrankten Wissens nach) nur, wenn du im Zuge dieser Arbeit eine patentierte Erfindung gemacht hast. In diesem Fall ist dein Arbeitgeber verpflichtet, dir dieses Patent irgendwie zu vergüten.

Ich weiß das, weil ich mal mitbekommen habe, wie ein mittelständisches Unternehmen von seinem Eigentümer an einen Investor verkauft werden sollte. Dessen Wirtschaftsprüfer haben, um den Wert des Unternehmens feststellen zu können, danach gefragt, ob die Firma Patente hält, die den Arbeitnehmern, auf die sie zurückgingen, noch nicht vergütet worden sind.

Gruß,
grtgrt
 
[Gäste dürfen nur lesen]
Beiträge: 1.566, Mitglied seit 11 Jahren
 

Zu hohe, nicht mehr beherrschbare Komplexität kann teure Folgen haben:



Das Projekt, den neuen Flughafen in Berlin zu bauen, ist keineswegs das einzige, das an zu hoher Komplexität zu scheitern droht.
Die Fachzeitschrift "Computerwoche" berichtet:

"Die US Air Force hat die Arbeiten an einem erfolglosen ERP-Projekt gestoppt. Die Kosten hatten sich auf über eine Milliarde Dollar summiert, bislang ohne erkennbares Ergebnis (!).

Bereits seit 2005 arbeitet die US-Luftwaffe an der Logistiklösung "Expeditionary Combat Support System" (ECSS) und hat seitdem 1,03 Milliarden Dollar in das Vorhaben investiert. Nun wurden die Arbeiten endgültig eingestellt, weil eine Fertigstellung zu viel kosten würde, der erreichbare Nutzen indes überschaubar bliebe. In den vergangenen drei Jahren wurde das Vorhaben bereits drei Mal neu aufgesetzt, offenbar ohne Erfolg."

Dieses so dramatisch schief gegangene Projekt ist durchaus nicht das einzige. Es gibt weitere ...


Ich frage mich deswegen:

Wird es nicht langsam Zeit, sich mehr Gedanken über Komplexität zu machen

und über geeignete Wege, sie beherrschen?



 
Beitrag zuletzt bearbeitet von Grtgrt am 17.11.2012 um 00:27 Uhr.
[Gäste dürfen nur lesen]
Beiträge: 1.503, Mitglied seit 17 Jahren
Grtgrt schrieb in Beitrag Nr. 1957-1:
Als staunender Leser frägt man sich da nun:

Wie komplex muss Software sein, wenn allein um sie geeignet zu konfigurieren und in Betrieb zu nehmen 1200 Mitarbeiter 3 Jahre lang beschäftigt sind?

Und wieviel Fehler mag diese Anwendung dann zunächst mal enthalten?


 

Ich stelle nicht in Frage die Komplexität der Software. Dennoch finde ich deine Frage verkehrt. Die 1200 Mitarbeiter arbeiten nicht an die Software (sie ist doch grundsätzlich fertig). Sie arbeiten an der Umsetzung dieser Software in einem komplexen Funktionsnetz des Großunternehmens. Vereinfacht könnte es durch folgende Analogie wiedergeben: die Architekten planen ein virtuelles Haus. Dafür verwenden sie eine Software. Der Ziel ist, das ein Anwender in dem virtuellen Raum könnte sich bewegen wie in den wirklichen. Die Wände, Dach und Öffnungen zu erzeugen ist nur ein Teil der Arbeit. Es müsste die Abnutzungsspuren berücksichtigt werden, es müsste der virtuellen Stromzähler, Wasserzähler, andere Meß- und Empfangsgeräte angebaut, die auf ihre Schaltung reagieren, wie es etwa im normalen Leben ist. Ich kann sagen, dass es schon ein statische Gebäde zu planen genug kompliziert ist, wenn es auch für die Funktionalität des virtuellen Anwenders berücksichtigt werden müsste, steigt die Komplexität des Projekts um vielfaches.

Wenn wir denken, dass es nicht ein Anwender, bzw. Familie berücksichtigt müsste, es geht mindestens um eine Stadt mit vielen Bewohnern, dann "Mammuthaftigkeit" des Projekt anschaulich wird.

Am Ende zurück zur deiner Frage. Die Arbeit der Programmierer, der die Software erstellt hat, ist nicht mit dem Architekten, der mit dieser Software ein Haus plant, zu vergleichen. Ich kann in dem Pojekt relativ einfachen Softwaren benutzen. Dennoch Projekt selbst kann viele Arbeitsstunden und viele Planer benötigt. So dass Projekt ggb. teuerer als die Softwareerstellung ist, sein kann. Daher die Arbeit der Planer nicht unterschätzen ;-)
Beitrag zuletzt bearbeitet von Irena am 19.11.2012 um 19:10 Uhr.
[Gäste dürfen nur lesen]
Beiträge: 1.566, Mitglied seit 11 Jahren
 
Ja, Irena,

du hast da völlig recht.

Mir kam es nur darauf an, zu zeigen, wie hoch komplex — und deswegen auch fehler-anfällig — Software-Systeme heute sein können.

Und natürlich ist auch das Ergebnis solch langwieriger Entwurfs- und Konfigurationsarbeiten fehleranfällig (es ist ja letztlich auch Software, Code also).

Beste Grüße,
grtgrt
 
[Gäste dürfen nur lesen]
Beiträge: 2.998, Mitglied seit 15 Jahren
Grtgrt schrieb in Beitrag Nr. 1957-7:
Mir kam es nur darauf an, zu zeigen, wie hoch komplex — und deswegen auch fehler-anfällig — Software-Systeme heute sein können.

Hierzu muss ich sagen, dass nicht nur Software immer komplexer und störanfälliger wird.

Denk mal an´s Auto, Wo früher ein mechanischer Vergaser und ein mechanischer Verteiler war, da ist heute eine komplizierte Elektronik mit Lamda-Sonde und Abgasregelung etc. Wenn früher die Karre ihren Geist aufgab, dann konnte man, als Bastler, dass Ding meist wieder irgendwie ans Laufen bringen. Heute wirft selbst der Pannendienst des ADAC bei manchen PKW das Handtuch.

Fernseher und Radios hatten früher 5 Verstärker-Röhren, und heute ein Wirrwarr aus IC´s und sonstigen Bauteilen.

Die simple Schlagbohrmaschine hat heute elektronischen Rechts-Linkslauf, Drehmomentstabilisierung und sonstiges.

Ich könnte die Reihe beliebig fortfahren. Die Technik macht vieles möglich, aber mit jeder neuen Option ist auch wieder ein Teil mehr, das kaputtgehen kann, eingebaut.

Übrigens, ich hab noch gelernt Landkarten und Stadtpläne zu lesen, weil es früher keine Navi´s gab. Die Dinger, falsch eingestellt, haben schon so manchen auf den Holzweg geführt. Wenn die Elektronik aufrüstet, dann sollte das Hirn nicht in gleichem Maße abrüsten.
Signatur:
Wer jung ist, meint, er müsste die Welt retten :smiley8:
Der Erfahrene erkennt, dass er nicht alle Probleme lösen kann
:smiley3:
Beitrag zuletzt bearbeitet von Hans-m am 21.11.2012 um 09:21 Uhr.
[Gäste dürfen nur lesen]
Beiträge: 1.503, Mitglied seit 17 Jahren
Grtgrt schrieb in Beitrag Nr. 1957-7:
Mir kam es nur darauf an, zu zeigen, wie hoch komplex — und deswegen auch fehler-anfällig — Software-Systeme heute sein können.

Es ist der Stoff zum Überlegen. Die Evolution berüht sich auf den genetischen Fehlern. Unsere Kommunikation berüht sich auf Fehlern (Fehlinterpretationen, Missverständnisse, die du auch in besonderen Therad angesprochen hast). Ich würde wagen zu behaupten, dass unsere s. g. Willenfreiheit berüht sich auf den Fehlern der zellularen, bzw. molekularen Ebene.
[Gäste dürfen nur lesen]
Beiträge: 1.128, Mitglied seit 13 Jahren
Nicht genetische Fehler machen die Evolution, die Integration von Gen-bruchstücken führt zu Änderungen und die Funktion oder Nichtfunktion des Ergebnisses entscheidet über weitere Nutzung oder Kollabs.
Signatur:
1=(h/s³)*(h/t) und 1/cc>0
[Gäste dürfen nur lesen]
Beiträge: 2.998, Mitglied seit 15 Jahren
Wrentzsch schrieb in Beitrag Nr. 1957-10:
Nicht genetische Fehler machen die Evolution, die Integration von Gen-bruchstücken führt zu Änderungen und die Funktion oder Nichtfunktion des Ergebnisses entscheidet über weitere Nutzung oder Kollabs.

Der Ausdruck genetischer Fehler ist bereits eine Abwertung des Ereignisses. Der vermeintliche Fehler kann letztendlich sogar eine Verbesserung des Erbgutes bewirken. Ich würde es daher nicht als Fehler sondern als genetische Veränderung bezeichnen.

Bedenke, dass wir Menschen auch das Produkt zahlloser Fehler sind, die sich seit der Entstehung der Einzeller bis heute in die DNA eingeschlichen haben.
(Naja, so betrachtet war der Mensch für die Umwelt vielleicht wirklich ein Fehler.)
Signatur:
Wer jung ist, meint, er müsste die Welt retten :smiley8:
Der Erfahrene erkennt, dass er nicht alle Probleme lösen kann
:smiley3:
Beitrag zuletzt bearbeitet von Hans-m am 22.11.2012 um 09:13 Uhr.
[Gäste dürfen nur lesen]
Beiträge: 1.503, Mitglied seit 17 Jahren
Hans-m schrieb in Beitrag Nr. 1957-11:
Ich würde es daher nicht als Fehler sondern als genetische Veränderung bezeichnen.

Die Fehler kommen aus deklarierten Kopienerstellenden-Mechanismus der Evolution. Dann logisch, dass die genetische Veränderungen als Fehler aufgefasst werden.

Dennoch bin ich - ausnahmsweise ;-) - ganz mit dir, was die Fehler angeht. Aber aus anderem Grund. Ich verstehe die Zelle nicht als eine Kopienerstellende Maschine. Die Zelle ist eher eine Protein-Gemeinschaft mit der Gen-Kultur, die stetig auf Umweltanforderungen anpassen muss.

Es geht hier aber über die Empfindlichkeit eines komplexen Systems, die auch "eine Kultur" (die zu erschaffende Datei/Lösung eines Problems) schafft und die Umwelt (den Mensch) hat. Die Umwelt gibt Anforderungen an, die das System ggbf. hält nicht statt - erzeugt Fehler. Wobei ist "die Kultur" als Nebenprodukte des "Stoffwechsels" (Funktion) einer Software und nicht mit unsre oder genetische Kultur zu vergleichen, die mit ihren Erzeuger ein Ganzes bildet. Hier bildet noch der Mensch, die Software und ihre Lösung ein Ganzes. Dennoch kann durchaus werden, dass einmals die Software sich emanzipiert bzw. verselbständigt. Dennoch auch hier, glaube ich, wird es nicht auf der Basis einer Software passieren. Es muss eine statistische Menge relativ unabhängigen komplexen Softwaren in einem Netz verbunden werden. Nur ein globales digitales Netz kann m. E. solche Ansprüchen genügen, keine einzelne Software.
[Gäste dürfen nur lesen]
Beiträge: 1.566, Mitglied seit 11 Jahren
 
Irena schrieb in Beitrag Nr. 1957-12:
Dennoch kann durchaus werden, dass einmals die Software sich emanzipiert bzw. verselbständigt.

Das, Irena, ist absolut unmöglich,

denn selbst wenn ein Software-Programm P1 ein anderes Software-Programm P2 erzeugt, kann P2 nicht mehr Semantik enthalten, als in P1 schon vorgedacht (dort also auch schon enthalten) ist.

Gruß,
grtgrt
 
[Gäste dürfen nur lesen]
avatar
Beiträge: 1.375, Mitglied seit 16 Jahren
Irena schrieb in Beitrag Nr. 1957-12:
Hier bildet noch der Mensch, die Software und ihre Lösung ein Ganzes. Dennoch kann durchaus werden, dass einmals die Software sich emanzipiert bzw. verselbständigt. Dennoch auch hier, glaube ich, wird es nicht auf der Basis einer Software passieren. Es muss eine statistische Menge relativ unabhängigen komplexen Softwaren in einem Netz verbunden werden. Nur ein globales digitales Netz kann m. E. solche Ansprüchen genügen, keine einzelne Software.

Hallo Irena,

Software kann sich nicht verselbstständigen. Du kannst das globale digitale Netz noch so komplex machen, es wird kein menschliches Bewusstsein oder eine menschliche Intention entwickeln. Warum?

Weil jede Software eine Hardware voraussetzt, um dort ablaufen zu können. Mehr Operationen, als diese Hardware zulässt, kann die Software nicht prozessieren. Und diese Hardware muss ständig vom Menschen gewartet werden, damit es überhaupt weitergeht.

Wenn du die Software-Komplexität weiter erhöhst, dann kann das globale digitale Netz immer fehleranfälliger werden. Dann können allerdings Dinge passieren, die der Mensch nicht vorausgesehen hat.

Zum Beispiel Fehlalarme bei den kernwaffenbesitzenden Mächten.

M.f.G. Eugen Bauhof
Signatur:
Der Kluge lernt aus allem und von jedem,
der Normale aus seinen Erfahrungen,
und der Dumme weiß alles besser.
Sokrates.
[Gäste dürfen nur lesen]
Beiträge: 1.566, Mitglied seit 11 Jahren
 
Bauhof schrieb in Beitrag Nr. 1957-14:
 
Mehr Operationen, als diese Hardware zulässt, kann die Software nicht prozessieren.

Hi Eugen,

dieses Argument kann ich nicht gelten lassen, da die in Hardware implementierten Operationen (funktional gesehen) ja nur die unteilbaren Bausteine sind, aus denen Software dann beliebig komplexe Operationen zusammenbauen kann — und damit auch beliebig viele unterschiedliche Operationen.

grtgrt
 
[Gäste dürfen nur lesen]
Beiträge: 1.566, Mitglied seit 11 Jahren
 
Bauhof schrieb in Beitrag Nr. 1957-14:
 
Zum Beispiel Fehlalarme bei den kernwaffenbesitzenden Mächten.


Genau so ein Fehler war 1983 nahe dran, einen 3. Weltkrieg auszulösen:

In 1983, Soviet early warning satellites picked up sunlight reflections off cloud-tops and mistakenly interpreted them as missile launches in the United States. Software was in place to filter out false missile detections of this very nature, but a bug in the software let the alerts through anyway. The Russian system instantly sent priority messages up saying that the United States had launched five ballistic missiles. Protocol in such an event was to respond decisively, launching the entire soviet nuclear arsenal before any US missile detonations could disable their response capability.

The duty officer for the system, one Lt Col Stanislav Petrov, intercepted the messages and flagged them as faulty, stopping the near-apocalypse. He claimed that he had a “funny feeling in my gut” about the attack, and reasoned if the U.S. was really attacking they would launch more than five missiles.

Result - Thankfully nothing. However, the world was literally minutes away from “Global Thermal Nuclear War”. Any retaliatory missile launched by the Soviets would have triggered a like response from the U.S., eventually leading to a total launch of all systems from both sides.

Quelle: Top Ten Most Infamous Software Bugs Of All Time

 
[Gäste dürfen nur lesen]
Beiträge: 1.503, Mitglied seit 17 Jahren
Grtgrt schrieb in Beitrag Nr. 1957-13:
 
Irena schrieb in Beitrag Nr. 1957-12:
Dennoch kann durchaus werden, dass einmals die Software sich emanzipiert bzw. verselbständigt.

Das, Irena, ist absolut unmöglich,

Ich denke, dass ihr die Verselbständigung etwas anders versteht als ich. Man müsste eiegentlich immer das Wort "relativ" nutzen. Z.B. nach mein Verständnis das Leben hat sich von der klassischen Welt emanzipiert, in dem er eigene Funktionsregeln erschaffen hat. Es blieb aber trotzdem ein Teil der stofflichen - klassischen - Welt mit alle ihrer Gesetzen. Deswegen die verselbständigung ist relativ. Es betrifft neue Funktionsebene - die Zelle, innerhalb deren die Gesetze klassischen welt bleiben unberüht. Das gleieche gilt für klassische Welt, die - nach mein Verständnis - mvon der Quantenwelt sich abgesondert hat, in dem sie eigene Regeln auf IHRE FUNKTIONSEBENE geschafft hat. Die Quanten gesetze bleiben dabei unberüht.

Wenn ich meine, dass ein globales digitales Netz sich verselbständigen könnte, meine ich damit nur, dass es KÖNNTE (spekulative Annahme!) eine Ebene schaffen, die sich von der Zivilisation emanzipiert. Es würde nicht etwa einen künstlichen Bewusstsein geschafft, der mit des Menschen konkurrrieren, bzw kommunizieren würde. Diese Vorstellung ist völlig falsch. Der Mensch würde nicht mal merken, wie etwa die Einheiten der Quantenebene "merken" nicht von der Stoffen, die sie erzeugen, oder die Zelle ist für ihre Moleküle "diffus".

Ja, und ich spreche nicht von einem Programm, wie auch komplex sie sein könnte. Ich spreche über ein globales Netz, in dem alle diese Programme vernetzt sind. Gerade diese Vernetzung, bzw. Quantität, durch die die Vernetzung entsteht, kann die enzelnen Fehler nivellieren, denen entgegen wirken (hatten wir schon mal in Bezug Robert Laughlin das Thema diskutiert). Vor allem aber entgeht die Kontrolle über das Netz dem einzelnem Menschen, bzw. Menschengruppe. So kann er seine Selbstorganisationspotential entfalten.
[Gäste dürfen nur lesen]
Beiträge: 1.566, Mitglied seit 11 Jahren
 


Payroll Systeme in Kalifornien und New York zeigen

völlig unerwartete Grenzen moderner Software-Entwicklungs-Methodik



Mitte 2006 vergab der Staat Kalifornien ein Projekt, dessen Inhalt es sein sollte, ein damals schon 30 Jahre altes Payroll System auf SAP-Basis neu zu implementieren.
Solche Neuentwicklung sollte das Problem beseitigen, dass kaum noch Programmierer zu finden waren, die die alte Technologie gut genug verstanden, volle Funktionsfähigkeit der Anwendung auf Jahre hinaus zu garantieren.

Die Kosten für die Neuentwicklung wurden auf 69 Mio. US-Dollar geschätzt,
und nach einer immerhin 3-jährigen Projektlaufzeit sollte das neue System 2009 einsatzfähig sein:

Zitat:
 
BearingPoint Inc. will put in place a new payroll and personnel system for California under a $69 million contract awarded by the state controller's office.

The McLean consulting company will work with SAP Public Services Inc. on an initiative the state calls the 21st Century Project.
The goal is to replace a 30-year-old system with one that is state of the art.

SAP will furnish software, maintenance and training for state employees to run the software, while BearingPoint will adapt SAP's software and implement it in state agencies.

The state selected SAP in April 2005 for the payroll and personnel software, and subsequently picked BearingPoint to handle the implementation. BearingPoint signed the contract in June 2006.

The system is scheduled to be online by November 2007, with full implementation expected by June 2009.


Nachdem sich dann aber 2009 (zum ursprünglich geplanten Projektende) herausstellte, dass BaringPoint mit dem Projekt hoffnungslos überfordert war, hat der Staat Kalifornien das Projekt abgebrochen und es dann erneut direkt an SAP vergeben.

Inzwischen vorsichtig geworden, sollte das Projekt unter dem neuen Auftragnehmer — SAP — in 5 Schritten implementiert werden. Schon der erste von ihnen — die sog. Pilotphase — ging so gründlich daneben, dass auch SAP gefeuert werden musste: Der durch SAP abgelieferte Prototyp versagte völlig, obgleich er doch nur gut ein halbes Prozent der Gesamtfunktionalität abzudecken hatte:


Der Umfang, in dem selbst SAP versagt hat, macht sprachlos:

Zitat von State Controller John Chiang:
 
One fact is particularly troubling with respect to SAP’s lack of progress:

The pilot phase only covers 1,300 SCO employees and two bargaining agreements with fairly simple payroll requirements. After eight months and little progress, the SCO cannot responsibly proceed to the second phase as requested by SAP and expose thousands more State employees to payroll errors. Nor can the SCO have any confidence that SAP can scale the failed system to cover the State’s 240,000 employees, operating out of 160 different departments, under 21 different bargaining units.

The errors in the SAP system affect everyday lives: Not only have SCO employees been paid too much, or too little, they and their family members also have been denied medical services despite paying for the insurance coverage. Payments to the State’s dental, vision and deferred compensation partners have been incorrect and delivered late. Improper deductions have been taken, payments have been made to the wrong payee, payroll and pensionable wages have been incorrectly calculated, and union deductions incorrectly determined.

To stabilize payroll for its employees, the SCO is rolling back its 1,300 employees to the legacy system that is currently and reliably paying all other 240,000 State employees.


Es ist noch nicht mal klar, ob irgend ein Teil von SAPs Projektergebnis im neuen System Verwendung finden kann:

Zitat von State Controller:
 
On February 8, 2013, the State Controller’s Office (SCO) terminated its contract with SAP as the system integrator for the MyCalPAYS system, the largest payroll modernization effort in the nation.

At the same time, the Secretary of the California Technology Agency (CTA) suspended further work until ... an independent assessment of SAP’s system to determine whether any of SAP’s work can be used in the SCO’s go-forward plan to address the State’s business needs.


Dieses Projekt-Fiasko erinnert an einen ganz ähnlichen Fall in New York, in dem sich IBM fast so überfordert sah, wie SAP oben:

Zitat von März 2011:
 
... the New York CityTime project was planned in 1998 to cost around $63 million and take five years to complete.

It is now (March 2011) estimated to cost some $720 million before it is finished sometime this summer

Zitat von 2012:
 
CityTime originally had a $63 million budget, but costs since skyrocketed astonishingly, with total estimates reportedly reaching $760 million.


An beiden Fällen ist interessant, dass hier lediglich existierende, schon Jahrzehnte alte Systeme neu implementiert werden sollten, und dass
  • im einen Fall gleich 8 Jahre mehr als geplant benötigt wurden (mit 12 mal so hohen Kosten wie geplant),
  • man im anderen aber nach nunmehr 7 Jahren immer noch genau dort steht, wo man begonnen hat (obgleich schon jetzt 254 Mio USD ausgegeben wurden, also schon fast das 4-fache des ursprünglich angesetzten Bugdets).


Wie also kommt es, dass so extrem schwierig erscheint,

mit heutiger Technologie und Methodik zu erreichen, was man mit längst überholter doch schon mal erreicht hatte?



Muss man da nicht glauben, dass moderne Projektteams nicht mehr systematisch genug arbeiten?


Ein drittes Beispiel, dort mit IBM als Hauptverantwortlichen, scheint diesen Verdacht zu bestätigen.

 
Beitrag zuletzt bearbeitet von Grtgrt am 02.03.2013 um 23:12 Uhr.
[Gäste dürfen nur lesen]
In diesem Forum dürfen nur Mitglieder schreiben. Hier kannst du dich anmelden
Zum Seitenanfang Nach oben