Bundesagentur stoppt millionenschweres IT-Projekt

Spiegel:Bundesagentur stoppt millionenschweres IT-Projekt

Ich weiß ja nicht wie der Staat das immer Schaft, massig Geld zu verbrennen.

Wenn ich Sätze lese wie:
“Es habe sich gezeigt, das nachträgliche Änderungen, etwa die Korrektur einer Kontonummer, in dem System nicht möglich sei. Um eine solche Angabe dennoch korrigieren zu können, habe man sämtlich Leistungs- und Vermittlungsdaten in das System neu eingegeben müssen.
Da eine Behebung des Fehlers zu aufwendig und zu teuer sei, werde das System nun doch nicht in der Praxis eingesetzt.“
Verstehe ich die Welt nicht.
Ich hab ja schon eine Ansicht, in der ich die Kontonummer editieren kann, ich muss doch einfach nur die andern Daten wenn vorhanden Laden und in die Felder füllen.
Selbst wenn ich eine komplett neue View machen muss, wenn ich da eine saubere Architektur habe, einen Tag maximal 2. Selbst wenn es schlecht Programmiert ist eine Woche.

Ich hab auch keine Ahnung wie man bei den Projekt, einigermaßen vernünftig auf 60Millionen kommt.
Ich hab zum Spaß mal ein paar Überschlagsrechnungen gemacht (gut die genauen Anforderungen kenne ich jetzt nicht, und muss da grob raten was das Arbeitsamt da so brauch). Ich bin da nicht auf 60Millionen gekommen. Selbst wenn ich meinen neuen Lamborghini (man muss ja angemessen vorfahren) und meine neu Luxus Villa mit einrechne.

Ich hatte seinerzeit mit einem Berater zu tun, der zu der Zeit zwischen dem Arbeitsamt und der Softwareschmiede für AL II vermittelt hat (er kam zu der Zeit in das Boot als da schon die Fetzen flogen).

Kurzum es ist ein hochkomplexes System mit einem riesigen Regelwerk um die sich ständig ändernde Rechtslage (und deren Interpretation) wo jeder seinen Senf dazugibt und es täglich Änderungen zu den Änderungen, die schon mal geändert wurden und jetzt auch noch nicht passen.

Wer jetzt denkt, dass ist ja wie beim BER - Recht hat er.

Das mit der Kontonummer muss man sich jetzt so vorstellen, dass dieses Regelwerk die Kontonummer als Identifikationsmerkmal verwendet um z.B. einem Missbrauch vorzubeugen.

Mehrfachbezüge/Anträge auf die gleiche Kontonummer sind somit systemtechnisch gar nicht möglich, bzw. fallen sofort auf. Klar, kann man einfach mehrere Konten anlegen und diese Kontonummern angeben, dann haben wir aber auch einen recht gut nachweisbaren Vorsatz und der ist strafrechtlich gesehen schon ein Brett.

Soweit so schlecht, wenn man einfach nur diese Kontonummer ändern möchte, die aber durch das ganze System als absolut schützenswert und unveränderlich angesehen wird. Da hat man die Torte im Auge.

Ich war vor einiger Zeit eher indirekt als direkt an einem Projekt beteiligt, das auf 8 Mio geplant und nach 5 Jahren Entwicklungszeit bei 33 Mio war - und noch lange nicht fertig.
Da gibts soo viel was schief gehen kann in solchen Größenordnungen, das nicht nur auf fachlicher sondern auch auf persönlicher Ebene zu suchen ist.
Besonders Projekte in den "alten Welten", die immer noch nach Lasten- und Pflichtenheften erstellt werden, sind sehr anfällig für solche Kostenexplosionen.

Soweit so schlecht, wenn man einfach nur diese Kontonummer ändern möchte, die aber durch das ganze System als absolut schützenswert und unveränderlich angesehen wird. Da hat man die Torte im Auge.

Naja ich denke mal für die Annahme, das sich eine Kontonummer mal ändern kann muss man kein Genie sein.
Das sollte man eigentlich in die Entwicklung mit einplanen. Grade wenn es ein zentrales Identifikationsmerkmal ist.

Kurzum es ist ein hochkomplexes System mit einem riesigen Regelwerk um die sich ständig ändernde Rechtslage (und deren Interpretation) wo jeder seinen Senf dazugibt und es täglich Änderungen zu den Änderungen, die schon mal geändert wurden und jetzt auch noch nicht passen.

Was Änderungen durch Gesetzte angeht, meine erste Anstellung war für eine Firma, die Software für Apotheken programmiert hat. Grundlegend was Ähnliches.

Und die waren wirklich das schlimmste, was ich je erlebt habe. Vom Management und auch von der Entwicklung. (Um ehrlich zu sein, ich hatte jetzt schon angefangen nieder zu schreiben was das nur vom Chef aus Katastrophal lief. Da hab ich schon eine halbe Seite für gebraucht. Und bin nicht ins Detail gegangen. Wenn es wirklich jemanden interessiert, kann ich mal dazu was schreiben.)

Grundlegend die waren richtig Sch... . Die hätten es aber auch hin bekommen.

@Abt

Besonders Projekte in den "alten Welten", die immer noch nach Lasten- und Pflichtenheften erstellt werden, sind sehr anfällig für solche Kostenexplosionen.

Sehe ich genau so.

Aber wenn man das mal Überbord schmeißt, denke ich dass man das Projekt deutlich unter 60 Millionen umsetzen kann.

Das "Ändern" der Kontonummer ist ja nicht unmöglich aber eben aufwändig. Es ist also vorgesehen aber wohl als seltenes Ereignis deklariert worden, wo man auch alles komplett neu erfassen muss. Dafür gibt es aber mehr Sicherheit.

Alle haben genickt und gut.

Das ist wie mit den Unit-Tests und Beispielen. Die meisten testen/zeigen nur die allereinfachsten Positiven. Die ungewöhnlichen Ausnahmen bekommt man nur mit spitzen Fingern aus den Nasen herausgezogen.

Ich kann mir kaum vorstellen dass keiner der Fachleute etwas zur Kontonummer als ID gesagt hat.

Was im aktuellen Fall ist kann ich nicht wissen aber überlegen wir mal was wir aus dem Alltag kennen. Entscheider und Geldgeber sind oft weder die fittesten in der Materie IT, noch bedienen sie das Produkt später selbst. Wer kennt den Fall dass der Entwickler etwas anmerkt oder zu bedenken gibt - und keinen interessiert es?
Dann bekommt man gesagt den Fall brauchen wir nicht, der andere kommt kaum vor, den lassen wir weg.
Nicht bedienbar? Doch das wollen alle so haben wie ich.
Haben wir schon immer so gemacht.
Das muss so aussehen, andere Infos braucht man da nicht.
Nein das muss nicht konfigurierbar sein. Den halben Tag Entwicklungszeit sparen wir uns.
Daran gewöhnen die User sich schnell.
Usw.

Siehe da, kaum ist das System raus, schon schreien alle nach Änderungen. Der ach so seltene Fall ist eben doch häufiger, die Ansicht die alle "so" haben wollten bringt keinem etwas, wie man etwas richtig bedient weiß auch keiner und und und ...
Schuld ist die Software und ihre Hersteller. Dass von Anfang an Mist bestellt wurde will keiner hören.

Ich kann mir kaum vorstellen dass keiner der Fachleute etwas zur Kontonummer als ID gesagt hat.

Mei, auf der anderen Seite - wie oft änderst du deine Kontonummer? Und denk einfach auch mal daran, wieviele Onlineshops die Emailadresse als UniqueID haben... Und eine EMailadresse ändere ich öfters als meine Kontonummer...

Von daher sehe ich die Kontonummer als UniqueID gar nicht mal so kritisch...

Hallo Palin,

ich denke, Sir Rufo hat das Problem schon ganz gut beschrieben. Ich denke, die Ursache - auch wenn in der Praxis verschiedene Dinge zusammen kommen, z.B. das Zwischenmenschliche - kann man in einem Wort zusammenfassen: Komplexität. Und als Außenstehender macht man sich kein Bild davon, wie komplex die Anforderungen sein oder werden können. Und weil vieles auf gesetzlichen Regelungen basiert, kann man die Komplexität auch nur begrenzt reduzieren.

Das Problem bei Komplexität (und Umfang) ist, dass man deutlich mehr Leute braucht als bei weniger komplexen Aufgaben. Mehr Leute führen aber - man ahnt es schon - zu mehr Komplexität (vor allem der Kommunikations- und Abstimmungsprozesse). Für diese Komplexitätssteigerung braucht man noch mehr Mitarbeiter. Bei einer gewissen Komplexität kommt man an den Punkt, wo jeder weitere Mitarbeiter die Komplexität stärker steigert als seine eigene Produktivität. Und dann scheitert das Projekt. Denn auf die zusätzlichen Mitarbeiter zu verzichten ist auch nicht die Lösung, da es auch in dieser Situation die Komplexität - wie erinnern uns - schon höher war als mit der Produktivität der Mitarbeiter zu bewältigen.

Man kann nur versuchen, die Komplexität reduzieren. So weit es nur geht. Wenn ein Problem schon von Anfang komplex ist, gleich auf allen unnötigen Schnickschnack verzichten.

Auch den eigentlichen Aufgabenumfang reduzieren. Zumindest für den ersten Schritt. Damit man überhaupt zu einem Ergebnis kommt.

Und alles in möglichst unabhängige und eigenständige Aufgaben zerlegen. Das ist vielleicht der wichtigste Schlüssel. Nichts reduziert die Komplexität der Gesamtaufgabe stärker. Die Komplexität entsteht ja gerade dadurch, wenn alles mit allem zusammenhängt. Jede Änderung an einer Stelle x Änderungen an anderen Stellen verursacht, von denen jede wiederum ihrerseits zu x Änderungen an anderen Stellen führt, so dass man sich irgendwann mit jeder Änderung sich vom Ziel stärker entfernt als man sich nähert.

Also eigenständige Aufgaben und klare, möglichst feste(!) Schnittstellen dazwischen.

Klar braucht man, weil sich die Anforderungen später so oder so ändern werden, auch ein flexibles Design, aber das sagt sich leicht. Und die Leute, die solche Projekte angehen, werden sich auch darum bemühen. Wichtiger sind aber trotzdem die o.g. Punkte.

herbivore

Das "Ändern" der Kontonummer ist ja nicht unmöglich aber eben aufwändig. Es ist also vorgesehen aber wohl als seltenes Ereignis deklariert worden, wo man auch alles komplett neu erfassen muss. Dafür gibt es aber mehr Sicherheit.

An der Stelle bekommen, die Leute nur eine 2. Chance einen Tip Fehler zu machen.
Es sind muss ja nicht 2x ein Password eingegeben werden.
(Wie es kling machen, die da eine komplette neu Erfassung)

Und denk einfach auch mal daran, wieviele Onlineshops die Emailadresse als UniqueID haben... Und eine EMailadresse ändere ich öfters als meine Kontonummer...

Bei Amazon z.B. kann ich aber auch meine E-Mail Adresse ändern.

@herbivore
Zu Komplexität fallt mir ein schöner Spruch ein.
Ein schlechter Programmierer findet für ein einfaches Problem eine komplexe Lösung.
Ein guter Programmierer findet für komplexes Probleme eine einfache Lösung.

Das Problem mit der Komplexität ist ja schon lange bekannt. Es gibt da ja grundlegende Prinzipien wie SOLID, KISS, YAGNI und DRY die eine da Leiten können und Fachbücher wie Clean Code, Code Complete u.s.w.

Auch das Problem mit denn Benötigten Leute, ist auch schon lange Bekannt. Brooks hat es in den 70zigern im Vom Mythos des Mann-Monats schon beschrieben.

Wenn man sich an bekannte Regeln und Sofware Architekturen hält, ist es meines Erachtens schon verdammt schwer 4 Jahre und 60Millionen in eine Software zustecken, die dann komplett über den Haufen geworfen wird.

Ich würde ja gerne mal den Quellcode sehen.

Hallo Palin,

klar ist das mit der Komplexität bekannt und an den Mythos des Mann-Monats musste ich vorhin auch denken, auch wenns lange her ist, dass ich das Buch gehört habe. Allerdings sind die von dir genannten Prinzipien eher Low-Level-Prinzipien. Also z.B. wenn man eine Klasse oder sogar nur eine Methode schreibt. Ich bezog die Notwendigkeit der Vereinfachungen auf das gesamte Projekt, die Projektstruktur und die Aufteilung der Arbeit. Und es ist schon nicht so einfach, das so hinzubekommen, dass einfach ist bzw. wird.

ist es meines Erachtens schon verdammt schwer 4 Jahre und 60Millionen in eine Software zustecken, die dann komplett über den Haufen geworfen wird.

Die Wahrscheinlichkeit, dass 4 Jahre und 60 Millionen über den Haufen geworfen werden, ist jedenfalls größer, als dass man bei kleineren und damit überschaubareren Projekten wegen unüberwindlicher Schwierigkeiten aufgeben muss. Ich finde, es liegt auf der Hand, dass man sich um so leichter verrennen kann, je größer das Projekt ist. Und ich denke, in derart großen Projekten retten einen die "bekannten Regeln und Software-Architekturen" alleine eben auch nicht.

Die Probleme mit der Kontonummer alleine scheinen mir hier auch nicht die alleinige Ursache zu sein, sondern eher der Tropfen, der das Fass zum Überlaufen gebracht hat. Die werden sich wohl so festgefahren haben, dass sie auch dann, wenn sie das mit der Kontonummer noch irgendwie in den Griff bekommen hätten, keine generelle Perspektive gesehen haben.

Du musst dir mal überlegen, welche Codemengen die in vier Jahren und vermutlich richtig vielen Mitarbeiter angehäuft haben. Da wird - vor allem im Zusammenspiel - einfach keiner mehr wirklich durchblicken. Selbst dann nicht, wenn die Teile für sich einigermaßen strukturiert sind.

Und die Frage ist auch, wieviel Geld man in der Lebens- bzw. Wartungsphase einer anscheinend sehr schlecht wartbaren Software unnötig verbrennen würde, wenn man das Projekt nicht beendet hätte.

Ich hab ja schon eine Ansicht, in der ich die Kontonummer editieren kann, ich muss doch einfach nur die andern Daten wenn vorhanden Laden und in die Felder füllen.

Es wird da nicht um eine Ansicht gehen, die man neu füllen muss und nicht nur die Stammdaten, sondern auch um alle über die Zeit stattgefundenen Vorgänge, die ganze Historie und noch alles mögliche andere, was da dranhängen wird. Und neu Eingeben (und vielleicht sogar automatisch Übernehmen), ist vermutlich schon wegen der Grundsätze der ordnungsgemäßen Buchführung nicht möglich. Das wird ohnehin nicht mit dem neue Ausfüllen einer einzelnen Maske abzufrühstücken sein.

Es ist dann eben im Detail doch schwieriger als es beim Lesen eines solchen Artikels auf den ersten Blick aussieht.

herbivore

Wer glaubt, dass da nur naive, nichts-könnende Entwickler und Architekten am Werk waren denkt arg naiv.
Bei solchen Projekten spielt neben der Komplexität auch ganz arg die "Politik" mit...also Kompetenz- und Machtgerangel.
Da zählen auch keine ach so guten und perfekten Regeln..

@herbivore
Ich zu Vorgehens hätte da jetzt auch Scrum oder Kanaban angeben können. (Hätte da aber noch Kritik, das ist dann aber eher ein anderes Thema)
Das es was staatliches werden sie da aber wohl nach dem V-Model vorgehen müssen. Aber auch hier gibt es Möglichkeiten Agile Prozesse mit einzubinden.

Ich muss gestehen, ich persönlich wäre die Sache vollkommen anders angegangen. (Vor allem wenn ich es richtig verstanden habe und die Abteilung kurzfristig für das Projekt erweitert wurde)
Grundlegend geht es ja darum 14 Verschiedene Anwendungen zu vereinen.
Mein Ansatz wäre gewesen, erst mal mit 3-4 guten Leuten, die 14 Programme zu Analysieren. Wo sind ähnlich Funktionen, was wird immer/oft zusammen Gebraucht u.s.w.
Dann hätte ich erst mal eine Auswahl von 2-3 Programmen genommen, die ich zusammen Führe.
Da kann ich dann auch das V-Model drauf anwenden.
Das Team hätte ich dann auf ca. gute 10 Leute erweitert. Wobei ich geschaut hätte, das jemand die QS macht, der Produktive mit den Programmen gearbeitet hätte. Um dann erst mal in den „Programmiereralltag“ her einzufinden. Die Leute müssen sich Kennen lehren, man muss einfach, man muss sich auf Ablaufe einigen u.s.w. . Mann muss einfach einen gemeinsamen Workflow finden der Funktioniert. Wenn ich dann ein „eingespieltes“ Team habe, kann ich zusätzliche Leute heranholen und vielleicht 2 Teams a 10 Leute haben. Wobei das „alte“ Team grob 5 zu 5 Aufgeteilt würde. Aber auch direkt klären, das wenn es was gibt sie gerne auf die Anderen zurückgreifen könnten. Neue Leute müssen natürlich auch eingearbeitet werden, bringen aber auch eigene Ideen mit was man besser machen könnte. Also wider schauen das der Gemeinsamen Workflow klappt.
Und so nach und nach die Abteilung auf eine passende Größe bringen.

Die 2-3 Programme sind im Gegensatz zu 14 Programmen, erst mal über schau barer. Ich/Wir kann/können hier schon mal Erfahrung sammeln wo es Probleme gibt. Was man nächstes mal besser machen kann u.s.w.
An dem Punkt kann ich dann auch das Programm ausliefern. Bekomme Erfahrungen was für Probleme es beim Rollout gibt, wie die Nutzer mit dem Programm zurechtkommen, welche Bugs im Programm sind u.s.w.
Wenn dass Programm, dann soweit „läuft“, wäre man dann einmal mit dem V-Model durch.
Und könnte die nächste Phase wider nach dem V-Model Planen.
Hier könnte man dann schauen, welche Programme man als nähtest Integriert. Je nach dem wie es gelaufen ist, kann man schauen. Ob man Programme Integriert, die eher schwer zu Integrieren sind, um zu schauen ob es auch da läuft. Oder besser Programme nimmt, die wahrscheinlich leichter zu Integrieren sind. Je nach dem wie groß das Entwicklungsteam ist kann man vielleicht beides machen, ein Teil kümmert sich um die schweren Sachen und der andere Teil um die Leichteren.

Ja mit dem Vorgehen, würde ich es wohl nicht in 4 Jahren schaffen. Es würde aber auch nicht 60 Millionen kosten, die ich in den Sand setze. Und es kann auch gut sein das sich die 14 Programme nicht zu einem zusammen fassen lassen, sondern ich dann 3 oder 4 hätte. Wäre aber besser als der Ist Zustand.

@Abt
Politisch Zwänge kenne ich nur zu gut. Ich bin SPD Mitglied und war mal recht aktive.
Ums in kurz zusammen zufassen. Als Entwickler hatte ich bei uns im Ortsverein die Homepage gemacht, die auch insgesamt die meisten Besucher hatte, bei uns in der Stadt mehr sogar als die Hauptseite in der SPD in der Stadt. Lag nicht an mir, sondern daran das wir jemand hatten der besonders gute Inhalte gemacht hat. (Das Prinzip haben meines erachten aber noch immer nicht aller Verstanden). Deshalb wurde ich zum Ausschuss zu Neugestaltung der Homepage SPD (Stadt) einladen, wir haben dann grob 1,5 Jahre an dem Konzept gearbeitet (1 bis 2 mal im Monat) und ich fand unser Konzept auch nicht so schlecht. Und als wir es dann umsetzen wollten (kostenlos), ist der Chef von der SPD (Stadt) der auch im Landtag sitzt gekommen und hat gesagt das ja ein Kollege aus dem Lanttagt einen Sohn hat der Internetseiten macht. Der soll es doch umsetzen weil wir ja nicht so viel Ahnung haben. Er hat es dann auch umgesetzt, von unseren Konzept ist dann glaube ich nur die Farbe Rot als Grundfarbe für die Homepage übergeblieben und was ich gerüchteweise gehört hab was er dafür bekommen haben soll will ich hier nicht sagen.

Ich möchte da jetzt auch keinem direkt die Schuld zuweisen. Kann ich auch nicht, da ich nicht genau weiß wie das Projekt abgelaufen ist.
Aber wenn ich höre 4 Jahre Arbeit und 60 Millionen kosten, für Nichts. Ist bei dem Projekt grundlegend was schief gelaufen. Man kann natürlich versuchen es schön zu reden. Aber man muss doch zugeben, das Ergebnis ist Sch....

Damit war nicht die Politik im Sinne von gesellschaftlicher Politik gemeint, sondern zB. der Machtkampf zwischen verschiedenen Personen mit unterschiedlichen Interessen und Ansichten im Projekt, zB. Fachbereich und IT, was jetzt kein besonderes Verhältnis ist.

Wie oft macht man Vorschläge und sie werden dann vom Ober gestochen. Die fahren dann gegen die Wand, was als Vorschlagender offensichtlich war, aber man nichts dagegen tun konnte ohne, die Hierarchie zu verletzten...? Täglich!

Mein Ansatz wäre gewesen, erst mal mit 3-4 guten Leuten, die 14 Programme zu Analysieren.

Das ist auch mit Sicherheit passiert....

Kleine Anekdote:

Eine öffentliche Institution, in der ich als Freelancer arbeitete, setzte eine Sitzung an um über den Neubau zu sprechen. Darum war auch ich dazu geladen, denn ein TOP war die EDV (natürlich der letzte auf der Liste und ich musste mir trotz allem die ganze Sitzung antun).

Ein TOP betraf die Nummerierung der Büros. Ich warf dann einfach - direkt nach Verkünden des TOPs - in den Raum: "So wie bei den Hausnummern im Allgemeinen üblich: An einer Seite anfangen und dann die Büros auf den Seiten durchnummerieren, dass man auf der einen Seite die geraden und auf der anderen Seite die ungeraden Nummern hat. Die Etagennummer setzen wir davor. Nächster TOP."

Das zwang sich durch das Baukonzept förmlich auf. 2 Geschosse mit jeweils einem langen Flur und die Büros jeweils links und rechts. Von einem Mittelbau kam man seitlich in diesen Trakt und hatte zur Rechten 1/3 und zur Linken 2/3 der Büros.

Dem Obermufti gefiel das aber nicht, denn mich hatte er von seinem Vorgänger geerbt und nicht in sein Herz geschlossen. Lag wohl an meinem chronischen Rücken- und Knieproblemen aufgrund derer ich nur aufrecht daherwandeln konnte.

Die Diskussion über die Nummerierung betrug eine gute Stunde und man einigte sich unisono (mich ausgenommen) darauf, die Büros entgegen dem Uhrzeigersinn zu nummerieren.

Ich habe natürlich brav gewartet, dass der Protokollführer diesen Erguss zu Papier bringen konnte und dann laut über den Vorschlag sinniert:

"Das ist ja für jeden gut nachvollziehbar. Wenn jetzt jemand kommt und nach einem Büro sucht, dann erzählt man ihm, dass er nur da in den Trakt gehen muss und für die Büros 1-3 und 19-23 wendet er sich nach rechts und für die Büros 4-18 wendet er sich nach links."

Es folgte ein betretenes Schweigen und gottlob wurde dann doch mein Vorschlag genommen.

Diese Stunde war einfach verbrannte Zeit und es ging nur um die Nummerierung von Büros. Wenn man das hochrechnet, dann wundert man sich auch nicht mehr.

Mein Ansatz wäre gewesen, erst mal mit 3-4 guten Leuten, die 14 Programme zu Analysieren.
Das ist auch mit Sicherheit passiert....

Will ich doch hoffen, das sind eigentlich mindeste Anforderungen.

Grundlegend kann man natürlich nur Spekulieren was genau passiert ist.
Im Grunde haben haben wir eine Blackbox, aber auch da kann man wenn man sieht was reingeht und was rauskommt drüber Mutmaßungen anstellen was darin passiert.

Schauen wir doch mal.
Erstmal haben wird die Rahmenbedingung das 14 Programme in 4 Jahren zusammen gelegt werden sollen. Ohne die Programme jetzt zu kennen halte ich das für eine sehr sportliche Vorgabe. Die werden ja schon was machen die Programme.

Außer dem wissen wir das zwischen 2011 und 2016 4,5 Milliarden in Betrieb und Entwicklung ihrer IT gesteckt wurden. Als größere Investitionen in einem kurzen Zeitraum. Für mich liegt hier die Vermutung nahe das sie Leute eingestellt haben um das knappe Zeitlimit von 4 Jahren zu halten. Seit Brooks wissen wir, dass das keine gute Idee ist.

Dann wissen wir noch, das von dem 60Millionen 42Millionen für Externe Experten ausgegeben wurden (2/3 sind schon ein hoher Anteil). Gegen Externe Experten hab ich nichts, wenn ich das wissen nicht hab es es gut einen Externen Experten zu holen. Was aber wichtig ist, das das Wissen was er mitbringt auch im Haus bleibt. Sonst hab ich später wenn es Änderungen gibt, ich sie nicht selbst oder nur sehr Aufwendig durchführen kann. Und das der Experte vielleicht grade keine Zeit hat, weil er an einen anderen Projekt sitzt. Und es kostet ja auch jedes mal mehr Geld den Experten zu bezahlen als es selber zu Ändern.
Dazu Passt meines Erachtens der Satz: "Die Defizite hätten nicht zeitnah und wirtschaftlich behoben werden können"

Ergebnis: 4Jahre Arbeit und 60Millionen für die Katz.

Es sind natürlich nur Spekulationen. Aber ich finde sie passen ganz gut zu dem was wir wissen.

Die Informationen gibt es hier: heisse:60 Millionen Euro versenkt: Bundesagentur für Arbeit stoppt IT-Projekt ROBASO

Genau, der ganze Beitrag ist eigentlich als Aussenstehender nur reine Spekulation und wird kein Ergebnis liefern.. 😉
Nur, dass da nur Anfänger am Werk seien...was durchaus als Vorwurf im Raum steht: nicht gerechtfertigt.

Ich hab ja nicht gesagt, das da nur Anfänger am Werk seien. Ich kann mir auch gut vorstellen, das da aktuell einige Frustrierte Entwickler herumlaufen.

Aber tatsche ist doch das nach 4 Jahren Arbeit und 60 Millionen €, das Projekt komplett eingestampft wurde. Und ich denke, da kann man auch mal drüber spekulieren, was da schief gegangen ist.

Und wie es so schwer sein soll eine Kontonummer (KTN) zu ändern.
Ich hab bei uns mal Überlegt was sich so ziemlich durch, die ganze Software zieht und das ist ein Bauteil Barcode. Auch dem kann ich aktuell nicht ändern, wenn ich ihn ändern möchte muss ich ihn neu Einlagern und alle Felder neu ausfüllen. (Kling jedenfalls sehr Ähnlich). Wenn ich den jetzt Editierbar machen müsste, gibt es bei uns eine Stelle an der die einige andere Werte des Bauteils geändert werden können (Sollte es in deren Software eigentlich auch geben, den Nachnamen einer Person muss ich ändern können. Und wenn die KTN ID für die Person ist sollte sie da Angezeigt werden). An der Stelle brauche ich dann nur das Feld Editierbar zu machen und gegebenen falls prüfen ob bei DTO auch der Barcode auf die Entety gemappt ist. (Da jetzt wohl auch nicht jeder das Feld Editieren soll würde ich da wohl noch ein Rechteprüfung mit machen und da es ein neues Recht ist müsste ich dass Recht noch anlegen) Also grob 10-20min Arbeit.

Also grob 10-20min Arbeit.

Du steltst dir das zu einfach vor - hier gibt es einige Sicherheitsrichtlinien zu beachten. Die Kontonummer darf/soll auch gar nicht zu einfach geändert werden. Stichwort: Missbrauch/Betrug...

Ich glaube es ist als Ausenstehender hier sehr schwierig eine seriöse Beurteilung abzugeben. Alles andere ist für mich Stammtischg'wätz...

Sorry Palin, aber da sind sehr naive Aussagen und sehr unberechtigte Anschuldigungen als Außenstehender... meine Meinung.

@Palin

Kann man deine Aussage jetzt als Angebot ansehen? Ich kann gerne mal schauen ob mein Kontakt da noch involviert ist und einen Kontakt für dich herstellen kann.

Die würden sich bestimmt freuen, wenn einer das in 10-20 Min. lösen kann.

Hallo Palin,

eigentlich wollte ich nach deinem Beitrag von heute 00:27 nicht mehr schreiben, weil ich den Eindruck hatte, es hätte eh keinen Sinn, da es mir schien, als würdest du sowieso alles besser wissen, aber jetzt will ich mich doch nochmal zu Wort melden.

Und wie es so schwer sein soll eine Kontonummer (KTN) zu ändern.

Ich hab ja oben schon geschrieben, was ich denke, was da alles dranhängt (technisch, organisatorisch und rechtlich) und warum es eben doch nicht so einfach ist. Es ist doch, wie Abt schon mehrfach sagte, naiv anzunehmen, als gäb es in dem Projekt nur Unfähige. Wenn also eben doch Fähige dort gibt und wenn sich das Problem tatsächlich mit vertretbarem Aufwand lösen lassen würden, dann sehe ich keinen Grund, warum sie das Problem nicht gelöst haben. Da es offensichtlich nicht so ist, scheint es tatsächlich wirklich schwer zu sein - aus welchen Gründen auch immer und egal wie schwer dir das zu akzeptieren scheint. Außerdem war die Kontonummer - wie schon gesagt - sicher nicht der einzige Grund für das Scheitern.

Ich kann mich des Eindrucks nicht erwehren, dass alles du schlecht reden willst und dich gar nicht für (mögliche) Gründe interessierst oder sogar selber nach diesen suchst. Ich hoffe, ich irre mich in diesem Punkt.

Mit ist übrigens aufgefallen, dass du in jedem Beitrag Kosten und Dauer des Projektes nennst. Mir ist nicht klar warum. Entweder das hat wirklich nachhaltig traumatisiert oder es steckt eine Absicht dahinter.

Wie allgemein bekannt, gibt es drei Faktoren für eine erfolgreiche Manipulation:

1. Wiederholung
2. Wiederholung
3. Wiederholung

Ich hoffe, ich irre mich auch hier. Jedenfalls befürchte ich, dass ich einen Rappel bekomme, wenn diese Zahlen nochmal genannt werden.

herbivore

Du steltst dir das zu einfach vor - hier gibt es einige Sicherheitsrichtlinien zu beachten. Die Kontonummer darf/soll auch gar nicht zu einfach geändert werden. Stichwort: Missbrauch/Betrug...

„Es habe sich gezeigt, das nachträgliche Änderungen, etwa die Korrektur einer Kontonummer, in dem System nicht möglich...“
„Da eine Behebung des Fehlers zu aufwendig und zu teuer sei „
Es war wohl ein Anwendungsfall, die Möglichkeit zu haben die KTN zu ändern.
Da ich in meinen Fall, ja auch die Rechte mit eingebunden habe, kann es auch nicht einfach jeder machen, sondern nur dazu Autorisierte Mitarbeiter.
Missbrauch oder Betrug kann, das System an der Stelle nicht feststellen. Nur ob es die KTN schon mal Existiert (das macht unser System auch Doppelte Barcodes sind nicht möglich).

Sorry Palin, aber da sind sehr naive Aussagen und sehr unberechtigte Anschuldigungen als Außenstehender... meine Meinung.

Ich hab hier keine Anschuldigung getätigt.
Ich hab mich dazu gesäuert, das ich manche Probleme nicht nachvollziehen kann (z.B: ändern der KTN).
60 Millionen € für zu teuer halte und 4 Jahre zu wenig für das Projekt.
Und darüber Spekuliert was das/die Probleme sein könnten.

Zu dem wie so Ausstehender. Das Projekt wurde aus Steuermitteln finanziert. Ich zahle Steuern und damit habe ich „gezwungenermaßen“ (ich muss ja an dem Punkt gestehen, ich zahle eigentlich gerne Steuern, da davon auch sinnvolle Sachen wie Schulen usw. Bezahlt werden) in das Projekt investiert (Wenn auch wirklich nur einen Bruchteil).

Machst du das bei deinen Kunden auch so?
Die Software ist so zwar jetzt nicht zu gebrauchen und Änderungen sind viel zu kompliziert. So das es sich nicht lohnt die Software weiter zu entwickeln. Aber danke das sie mich die letzten 4 Jahre bezahlt haben.

@Sir Rufo
[Spaß] Wenn du da einen Kontakt hast. Sag ihm du hast da einen Entwickler an der Hand, der zu dem gleichen Ergebnis schon nach 2 Jahren und für nur 10 Millionen € kommt. Das bekomme ich sicher hin. 😉 [/Spaß]

An dem Punkt, auch wenn ich schon wider spekuliere. (Ich hab mir halt weiter um das Problem Gedanken gemacht.)
Halte ich es für möglich, das sie die KTN als ID in der Datenbank verwendet haben und dann auch als Fremdschlüssel in anderen Tabellen. (Was wir bei uns mit dem Barcode nicht haben. Nach „außen ist er zwar die ID“, intern hat die Tabelle aber eine eigene ID. So das ich den Barcode einfach ändern kann).
Die grundlegende Entscheidung, dahinter kann ich sogar verstehen, Ich erspare mir den join auf die „KontoTabelle“ um die KTN zu bekommen (ja den haben wir bei unseren Barcode immer mit drin).
Wenn es so ist gibt es zwar mindestens eine Quick & Dirty Lösung. Ich denke aber wenn man es sauber machen will muss mal den DAL komplett neu erstellen. Was natürlich auch Zeit braucht.

@herbrivore
(Erstmal Entschuldigung ich hab jetzt ein bisschen länger für die Vorangegangen Ausführungen gebraucht. Und habe grade eben die Seite aktualisiert so das ich deine Anmerkungen nicht direkt berücksichtigen konnte)

Und ja du wirst wohl einen Rappel bekommen, da ich schon wieder die Zahlen erwähne. Ich hab sie ja schon erwähnt und werde sie jetzt auch noch mal erwähnen.
Direkt Traumatisiert bin ich von den Zahlen nicht. Aber sie ärgern mich schon Gewaltig.
60 Millionen halte ich für so ein Projekt für viel zu Teuer und 4 Jahre für einen zu kurzen Zeitraum.
Und meines Erachtens sind die 60 Millionen zustanden gekommen, weil probiert wurde das Projekt in in 4 Jahren umzusetzen. Wir beide kennen Brooks und es passt zu seinem Theorem. Wenn du eine bessere Erklärung hast bitte, es kann nie schaden dazu zu lernen.

Das Außenstehend war wohl eher darauf bezogen, dass deine "Beispiele" für die Tonne sind. Keiner von uns kennt auch nur ansatzweise die Architektur des ganzen Projekts, von technischen Details mal ganz zu schweigen. Es ist daher etwas arg naiv zu glauben, dass man das mal eben auf seine Wald&Wiesen-Projekte adaptieren und am Ende ein "Das ist doch total leicht" anhängen kann.

Quick&Dirty als möglicher Lösungsweg? Das erlaubt durchaus Rückschlüsse darauf, wie du an solchen Projekten arbeiten und sie damit am Ende auch zu Fall bringen würdest. Genau mit sowas fängt das Scheitern nämlich an. Das nicht mögliche Ändern einer Kontonummer ist nur ein Symptom einer vermutlich vergurkten Architektur. Da waren keine Amateure am Werk, aber Projekte dieser Größenordnung sind IMMER risikobehaftet. Und ja, das ist auch schon oft genug bei Kunden vorgekommen. Die wissen in der Regel aber schon vorher Bescheid, dass so ein Projekterfolg nicht zu 100% garantiert werden kann.

60 Millionen mögen für einen einzelnen Menschen viel Geld sein. Aber, so hart das auch klingt, je nach Projektgröße sind das Peanuts.

Hallo,

An dem Punkt, auch wenn ich schon wider spekuliere. (Ich hab mir halt weiter um das Problem Gedanken gemacht.)
Halte ich es für möglich, das sie die KTN als ID in der Datenbank verwendet haben und dann auch als Fremdschlüssel in anderen Tabellen. (Was wir bei uns mit dem Barcode nicht haben. Nach „außen ist er zwar die ID“, intern hat die Tabelle aber eine eigene ID. So das ich den Barcode einfach ändern kann).

Dann spekuliere ich jetzt mal, dass das etwas zu kurz gedacht ist. Vor allem folgender Aspekt wird dabei nicht berücksichtigt:

Das Projekt, das auf einer einzigen Plattform 14 verschiedene Anwendungen bündeln sollte,

Stell Dir also vor, Du hast 14 verschiedene Anwendungen, jede hat Ihre eigene Datenbank und funktioniert im Standalone-Betrieb so wie sie soll. Einige teilen sich vielleicht schon gewisse Datenbereiche, andere wiederum nicht.
Dann hast Du nicht nur das Problem, dass Du mit verschiedenen Schlüsseln hantierst, sondern das ganze über verschiedene DBs von verschiedenen Anwendungen die voneinander erstmal nix wissen. Diese in Einklang zu bringen (ich mutmaße hier auch nur) ist wahrscheinlich einer der Hauptpunkte des verworfenen Projekts gewesen.
Dann bist Du zusätzlich davon abhängig, wie diese ganzen Systeme die Daten verarbeiten und was sie können oder auch nicht können.
Und dann ist man ganz schnell da, dass es wirklich sehr komplex werden kann.

Warum allerdings gerade bei der Kontonummer scheinbar von vorneherein angenommen wurde, dass eine Änderung ein sehr selten auftretender Ausnahmefall ist - was ja im speziellen Fall der Kontonummer erst zu dem Desaster geführt hat, kann ich persönlich auch nicht nachvollziehen.

Gruß, MarsStein

@MarsStein
Da stimme ich dir zu.
Was mich aber an der ganze Sache wundert, dass jemand das Projekt ohne genaue Prüfung der Machbarkeit angefangen hat.
Gerade ein solches Vorhaben 14 Anwendungen quasi zu einer zusammen zufassen hätte erst einmal eine Machbarkeitsprüfung unterzogen werden müssen.

Erst dann hätte man das Konzept aufstellen und auch per entsprechender Analyse sowie Umsetzungen von entsprechenden Diagrammen (UML) und auch Ablaufplänen die Machbarkeit des ganzen Projekts prüfen müssen.

Zwar hätte dafür auch schon Geld ausgeben werden müssen, aber man hätte sicher einige Millionen an Steuergeldern gespart, da man früh genug gemerkt hätte das sich das ganze nicht realisieren lässt.

Die Verlierer sind wieder einmal mehr die Bürger die wieder ihr Geld in Form von Steuern versenken und somit für das Scheitern eines weiteren Projekts zahlen dürfen.

Ich sehe es aktuell schon als ziemlich übel an, wieviele solcher Staatlichen Großprojekte ohne Sinn und Verstand gegen die Wand gefahren werden.
Das Geld, was hier versenkt wurde, wäre in Bildung und Infrakstruktur sicherlich besser investiert gewesen.

T-Virus

Was mich aber an der ganze Sache wundert, dass jemand das Projekt ohne genaue Prüfung der Machbarkeit angefangen hat.

Mein Job in der Cloud-Welt ist es zu 90% bestehende Anwendungen bzw. ein Anwendungspark zu vereinheitlichen und daraus eine Plattform zu schaffen.
Das ist ganz ähnlich dieser Aufgabenstellung.

Ich kann Dir sagen, dass eine Machbarkeit sicherlich mit einem Prototyp gemacht wird. Ich kann mir nicht vorstellen, dass sowas auch vor 10 Jahren nicht gemacht wurde. Cloud hin oder her.
Aber ich habe noch nie gesehen, dass ein Auftraggeber so eine Machbarkeit mit allen User Stories und allen abzudeckenden Applikationen macht.
Es bleibt immer ein sehr großes Restrisiko.

Oft hat man mit Legacy Systemen zutun, deren Schnittstellen man nicht kennt - und auch der Auftraggeber nicht.
Manchmal gibts nicht mal Schnittstellen, weil man einen proprietären Monolithen vor sich hat, sondern muss sich selbst welche schaffen. Oft genug hat man auch gerade bei Behörden mit Tools zutun, deren Hersteller nicht mal mehr existiert.
Dann hat man Anwendungslogik, die man extrahieren muss, zB. anhand des Datenbankschemas weil man auf den Ursprungscode keinen Zugriff mehr hat.
Sowas ist alles nicht in einer Machbarkeit mit einem 1% Aufwand abzudecken. Nie.

Man kann auch nicht am Anfang ein Konzept erstellen. Das macht niemand mit solchen Plattformen; jedenfalls nicht am Anfang in einem genauen Detailgrad.
So ein Konzept ist genauso agil bzw. sollte es sein, wie eine Architektur oder wie Code. UML Diagramme macht auch keiner mehr (weswegen es auch reihenweise aus den Entwicklertools geschmissen wird; as nächste is VS2017).
Unnötig hunderte Grafiken anfertigen ist genau das, was nichts bringt und Geld kostet.
Spätestens ein Sprint später müssten alle Grafiken angepasst werden. Von den vielen Variablen und schwarzen Löchern: die sind sowieso nicht grafisch darstellbar. Ist ja keine grüne Wiese.

Man muss an so ein Ding hoch-agil vorgehen. Anders hat man bei den vielen schwarzen Löchern überhaupt keine Chance.
Man kann es nicht voll durchplanen, man kann es nicht perfekt schätzen und man kann vor allem nicht hellsehen.

Und wie jeder in der Software-Entwicklung weiß reicht es nicht, dass die Entwickler und Architekten agil sein müssen, sondern auch das drum herum.
Da können noch die besten Entwickler dran sitzen: wenn das drum herum das Agile stört, knallts.