Unsere Welt zu verstehen:  Software KONSENS

 

 
Wie schwierig kann Software-Sanierung sein?

— hmsgnr0516z

 
 
KONSENS: Die 2007 begonnene Vereinheitlichung der Software der deutschen Steuerbehörden:

Ziele des Vorhabens KONSENS (Koordinierte neue Software-Entwicklung der Steuer-verwaltung) sind die Entwicklung und der Einsatz einer bundesweit einheitlichen Software für die Steuerverwaltung.
 
Bund und Länder arbeiten hierzu seit 2007 zusammen. Bis 2019 sind dabei Ausgaben von rund 1,2 Mrd. € angefallen, sie werden sich bis zum Jahr 2024 auf 2 Mrd. € erhöhen.
 
Bund und Länder wollen mit KONSENS ihre Steuereinnahmen von jährlich 638 Mrd. Euro (Stand 2020) besser verwalten als bisher möglich ist.
 
Derzeit (2020) werden für KONSENS 19 (Haupt-)Verfahren entwickelt. Obgleich fertiggestelle Module weitestgehend sofort zum Einsatz kommen, werden in den Ländern in unterschiedlichem Umfang immer noch insgesamt 193 Nicht-KONSENS-Anwendungen mit z.T. recht ähnlichem Funktionsumfang betrieben. Für zunächst nur 118 hiervon ist eine Ablösung durch ein KONSENS-Verfahren vorgesehen. Nach derzeitigen Planungen (Stand 2020) wird man dieses erste wichtige Teilziel aber sicher nicht vor 2029 erreicht haben.
 
Quelle: Bayerischer Oberster Rechnungshof (eine beratende Äußerung vom Nov. 2020)

 
 
Die "Autobahn GmbH" des Bundes wird nicht am 1. Januar 2021 im Regelbetrieb starten können. Der Grund: fehlende IT-Infrastruktur und juristische Probleme bei laufenden Projekten.

Zwar geht die Autobahngesellschaft mit zehn Niederlassungen und 41 Außenstellen zum Jahresbeginn an den Start, dennoch ist die neue Mammutbehörde mit Zentrale in Berlin bis auf weiteres nicht allein zuständig für die 13.000 Kilometer Autobahnen in Deutschland. Grund sind ungelöste Probleme. So dauere die Harmonisierung von 1.400 Softwaresystemen der Landesstraßenbauverwaltungen noch bis Anfang 2024, so das Verkehrsministerium.
 
Quelle: Scheuers Fehlstart - noch lange kein Regelbetrieb für "Autobahn GmbH" (Bericht im ZDF, Dez 2020)

 
 
Über bisher erfolglose Versuche, Gehaltsabrechnungssysteme auf neue Technologie zu portieren:
 
Wie schnell man beim Versuch, Gehaltsabrechnungssysteme der öffentlichen Hand auf aktuelle Technologie zu portieren Dollarbeträge zwischen 0,4 und 1,2 Milliarden Dollar in den Sand setzen kann (und das ganz ohne, dass man dann ein brauchbares neues System hätte), zeigen Projekte in Kalifornien einerseits und Australien andererseits:

(1) Kaliforniens Payroll System, mit dessen Hilfe 250.000 Bedienstete monatlich neu ihr Gehalt berechnet und überwiesen bekommen, versucht man schon seit 1999 neu zu implementieren: Bisher ohne jeden Erfolg — aber mit Kosten, die sich 2020 schon auf gut 400 Mio. US Dollar Lehrgeld aufsummiert haben.
 
Man lese: Nun hin zum dritten Anlauf
 
 
(2) Noch dramatischer schief gelaufen ist zwischen 2010 und 2018 — da hier nicht nur Software-Entwickler, sondern vor allem auch Politiker ganz unglaublich naiv gehandelt haben — in Queensland (Australien) ein erster Versuch, das Payroll System für den Gesundheitssektor (ca. 85.000 Bedienstete) neu zu implementieren.
 
Der Auftragnehmer (IBM Australia) hatte sich nur 2 Wochen Zeit genommen, die Sollfunktionalität der Anwendung zu dokumentieren. Kein Wunder also, dass die neue Lösung jede dritte Gehaltsabrechnung mit z.T. höchst gravierenden Fehlern errechnet hat. Die zuständigen Entscheidungsträger haben die Anwendung — aus politischen Gründen — dennoch in Betrieb genommen. Konsequenz: Man hat hinterher über längere Zeit hinweg 1600 Beschäftigte benötigt, die vielen ständig vom neuen System errechneten Fehler mit Hilfe manueller Work Arounds zu korrigieren oder zu viel bezahlte Gelder wieder zurückzufordern und einzusammeln. Zahlreiche Angestellte haben gekündigt, da sie wochenlang der fehlerhaften neuen Anwendung wegen gar kein Gehalt erhielten.
 
Auf diese Weise ist — bei einem Auftragswert von nur knapp 7 Mio. australischer Dollar — später (in den 3 Jahren nach dem fahrlässigen Rollout) für den Steuerzahler ein Gesamtschaden von ingesamt 1.2 Milliarden australischer Dollar entstanden. [ Man ist an das 2019 mindestens so fahrlässige Handeln des deutschen Verkehrsministers Andreas Scheuer in Sachen PKW-Maut erinnert. ]
 
Quelle: The Queensland Health Payroll Fiasco + /short + /BPr
 
 
Note: Dass in Kalifornien und Queensland eine erfolgreiche Portierung der Altanwendung auf SAP scheiterte, wird wohl daran gelegen haben, dass die SOLL-Funktionalität des jeweiligen Altsystems nicht ausreichend genug dokumentiert war.
 
Bei Lidls abgebrochenem Versuch, das eigene Warenwirtschaftssystem nach SAP zu portieren, war der Grund aber (mindestens teilweise) ein ganz anderer: Basis aller Kalkulation in SAP sind Einkaufspreise. Lidls propietäres System aber kalkuliert auf Basis der Verkaufspreise. Am alten Geschäftsprozess konnte man mit Standard-SAP-Software also gar nicht festhalten. Man hat sozusagen eine zweite Variante der SAP-Plattform benötigt. Sie fertig zu implementieren erachtete Lidl dann aber als zu teuer.
 
Details hier: 7 Jahre, 500 Millionen EUR — mehr wollte man nicht riskieren + /M

 
 
Man lese auch:

 

• Beispiele schiefgelaufener großer IT-Projekte (auch solche einzelner Unternehmen)
   
• Understanding and Managing Your Project’s Complexity
   
• Project Failure Case Studies — Lessons learned
   
• The following excuses for total project failure will never work in court:
   
  
  " I thought the buyer or supplier knew what they were doing " or
   
  " I thought the buyer or supplier was doing it, not me ".
  
   
  If you are the buyer and you do not have all the necessary skills and experience to be able to define and control important projects (which is perfectly understandable as in most companies they don’t happen very often), there is an easy fix for this problem:
   
  Hire a very experienced interim executive to act on your behalf, even if the supplier will still do most of the project management and other work. You can delegate authority for doing the project management to the supplier but you cannot delegate responsibility.
   
  But keep in mind: Responsibility for the project — including responsibility for it failing — always rests ultimately with you, the buyer.
   
  And never forget:

Risk are  known  unknowns
 
Uncertainty are  unknown  unknowns.