Projektbeschreibung         .

Schadensminderungstrategien für vom Kauf überdimensionierter und unzureichend angepasster Software betroffene mittelständische Unternehmen und Verwaltungen

Inhalt

Kurzfassung

Eines der längeren Gespräche aus der 1. Hotline (zusammengefasst)

Erste Ergebnisse (Juli 2002)


Kurzfassung

Seit Mitte der 90er Jahre die meisten Großkunden ihre IT-Systeme auf eine neue Softwaregeneration, Datenbanken und grafische Benutzeroberflächen umgestellt hatten und der Markt ausgereizt schien, wurden immer mehr Mittelständler mit überdimensionierten Software-Komplettpaketen „beglückt“. Besonders während des Booms der New Economy kamen sog. „e-Business-Versionen“ hinzu. Jeder Klempner sollte nach Möglichkeit seinen Leistungskatalog ins Internet stellen. Ob bei SAP, Baan oder Bäurer: ein Heer von auf Messen angeworbenen, in hastigen Crashkursen qualifizierter Berater wurde im Vertrieb eingesetzt und versprach den Kunden das Blaue vom Himmel herab.

Die beim Mittelstand, aber auch zunehmend in öffentlichen Einrichtungen wie Hochschulen implementierte „Komplettsoftware“ ist oft oversized und überkomplex, featurereich und schwer zu pflegen, kaum an betriebliche Bedürfnisse und Branchenspezifika angepasst und verursacht hohe Fixkosten. Es fehlt zudem oft an qualifizierten betrieblichen Experten, die mit hohem Aufwand nachgeschult werden müssen. Eine wirklich herstellerunabhängige Beratung wurde in den seltensten Fällen in Anspruch genommen, zumal die Zahl der Alternativen auf den ersten Blick scheinbar gering war: es gibt wenige Softwareunternehmen, die angepasste Lösungen für den Mittelstand zu vernünftigen Konditionen implementieren. Lange Zeit verhehlten die betroffenen Firmen ihre Probleme, weil sie die Fehler allein bei sich und in ihren unzureichenden Kompetenzen suchten. Erst der Niedergang der New Economy hat den Blick für die damaligen Beratungsfehler geöffnet. „Weniger ist mehr“ – diese Devise setzt sich nun langsam durch. Allerdings gibt es auch eine Reihe objektiver Probleme für die Misere: der deutsche Softwaremarkt ist zersplittert, Branchenpakete erreichen nicht die notwendigen Installationszahlen.

Das von IUK durchgeführte Projekt dokumentiert und analysiert die Vertriebsstrategien und –argumente und die oft problematischen Resultate herstellerabhängiger Beratung. Wir beraten hardware-unabhängig und versuchen, Alternativen zu den oder Ausstiegsstrategien aus den Komplettpaketen oder für „e-Business-Geschädigte“ aufzuzeigen.


Fragen zum Projekt:

Frage: Oft verändern Softwareprojekte ihre Ziele im Projektverlauf, oder es werden neue Tools eingesetzt, die es bei Erstellung des Pflichtenhefts noch gar nicht gab. Gibt es Möglichkeiten, die regelmäßig drohenden Streitigkeiten um die Erfüllung von Anforderungen an die Software von vornherein zu entschärfen?

Antwort: Mit dem Typ des kundenspezifischen Softwareprojekts ist die Verbreitung eines neuen Konflikttyps zu verzeichnen, der sich paradoxerweise gerade aus der intensiven Interaktion der Projektpartner – Anbieter und Kunde – ergibt. Diese typische Konfliktsituation entsteht immer dann, wenn sich Kunde (Anwender) und Anbieter nicht einigen können, ob ein Projekt vereinbarungsgemäß abgeschlossen wurde und ob die im Verlauf des Projekts entwickelte bzw. installierte Software die Anforderungen erfüllt:

Im allgemeinen ist es für den Anwender schwer, Ansprüche an den Anbieter geltend zu machen. Erstens ist der tatsächliche Schaden nachzuweisen. Leichter fällt das beim Nachweis der Kosten durch Betriebsunterbrechungen, in bezug auf entgangene Umsätze bzw. Erlöse ist das schon schwieriger. Zweitens ist dem Anbieter eine Vertragsverletzung, ggf. eine schuldhafte nachzuweisen. Und schließlich ist der Kausalzusammenhang zwischen der Vertragsverletzung und dem Schaden aufzuzeigen; d.h. der Einfluss anderer Ursachen ist auszuschließen. Und gerade hier liegt das Problem: Aufgrund der engen und lang anhaltenden Interaktion zwischen Anbieter und Kunde ist oft nicht auszuschließen, dass es Fehler, Unterlassungen oder gar Weisungen der eigenen Mitarbeiter sind, die das nicht vertragskonforme Verhalten des Anbieters ausgelöst, begünstigt oder in irgend einer Weise beeinflusst haben – oder die nicht zur rechtzeitigen Schadensminimierung beigetragen haben.

Eine Konfliktprophylaxe ist daher in jedem Softwareprojekt angesagt. Sie beginnt bei der Aufsetzung des Vertrages bzw. des Pflichtenhefts. Auch ist jede Veränderung der Projektziele oder der eingesetzten Mittel sorgsam zu protokollieren. Es sind genügend Spielräume für die Erprobung und gemeinsame Bewertung von Teilllösungen einzuplanen. An diesem Prozess sollte der Anwender nicht nur den Projektmanager, sondern auch Juristen und Informatiker beteiligen. Deeskalationsmechanismen (z.B. Mediation durch externe Experten) sollten fest vereinbart werden. Auch mögliche Nachwirkungen scheinbar gelöster Konflikte sollten über einen längeren Zeitraum hinweg beobachtet werden.

Prof. Dr. H.-J. Weißbach


Erste Ergebnisse (Juli 2002)

Untersucht wurden bisher 5 Unternehmen (Branchen: Maschinenbau, Metall) und eine Verwaltungseinrichtung mit durchschnittlich 230 Mitarbeitern. Die durchschnittliche Investitionssumme für kaufmännische, Dispositions-, Materialwirtschafts- und z.T. PPS-Standardsoftware betrug ca. 300.000 Euro, die eigenen Aufwendungen im ersten Jahr nach der Implementation (ohne Schulungsaufwand) beliefen sich noch einmal auf knapp 200.000 Euro. Insgesamt waren drei verschiedene Hersteller involviert, darunter der Marktführer mit drei Installationen. Die Erstinstallationen erfolgten in den Jahren 1995-2001. Keines der Systeme enthielt aufwändige Grafik- oder e-Commerce-Komponenten, nur eines besaß keine Datenbank, ebenfalls eines eine CAD-Kopplung.

Folgende Mängel wurden von den Anwendern benannt (Zahl der Nennungen in Klammern):

 

Geringe Flexibilität des Systems (3)

 

Zugesagte Funktionalität wurde nicht erreicht (2)

 

Übergroße Komplexität des Systems (2)

 

Aufwändige Pflege (2)

 

Probleme mit Office-Schnittstellen (2)

 

Mangelhafte Erweiterungsmöglichkeiten (1)

 

Ungenutzte Features (1)

 

Unzureichende Abbildungsmöglichkeiten detaillierter Prozesse (1)

 

Unmöglichkeit, kurzfristige Prozesse / Änderungen abzubilden (1)

 

Beendigung der Wartung für eine relativ „neue“ Software durch den Hersteller (1)

 

Bedienerunfreundlichkeit (1)

 

Mangelnde Online-Beauskunftung (1)

 

Zwei der Unternehmen gaben allein je vier Mängel an. Auch bei neueren Installationen ist keine Abnahme der Zahl der geäußerten Mängel festzustellen. 

Die Kooperation in der Implementationsphase wurde im allgemeinen als problemarm beschrieben, vielleicht wegen der hohen Fremdwissensabhängigkeit der Anwender in dieser Phase. Probleme wurden meist erst später registriert. Wurde der Hersteller dann wiederholt auf die Problemlösung angesprochen, waren die Erfahrungen immerhin in vier von sechs Fällen überwiegend negativ: 

Notwendigkeit des nachträglichen Einsatzes zusätzlicher Fremdprodukte, steigende Heterogenität, mangelnde Systemintegration (2)

 

Inkompetenz des Herstellerservice, falsche Informationen (1)

 

Übertragung des Service auf lokalen, weniger kompetente Partner (1)

 

Erhebliche finanzielle Nachforderungen für Nachbesserungen (1)

 

Kontroverse Diskussionen um die Auslegung der Anforderungen an das System (1)

 

 

Als eigene Fehler werden von den Anwendern angegeben:

 

Orientierung an einer zentral vorgegebenen Kaufempfehlung (1)

 

Mangelnde Prüfung der eingesetzten Technik (1)

 

Unterschätzung des Schulungsaufwands (1)

 

Zu geringe Qualifikation der eigenen DV-Abteilung (1)

 

Wahl eines überdimensionierten Systems (1)

 

Überzogene Anforderungen an Detaillierungs- und Auflösungsgrad der Prozesse (1)

 

Zu langes Festhalten am System statt Totalersatz (1)

Wir stellen Ihnen die laufend erweiterte Studie zur Verfügung, wenn Sie uns durch Ausfüllen eines Fragebogens bei der Erhebung helfen, den Sie bei uns per email anfordern können!