Hohe Entwicklungskosten Also Standard Software
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Ein DenkFehler, der häufiger zu beobachten ist. Ein Schauspiel in 4 Akten.
Der typische Ablauf geht etwa so:
- 1. Akt: Eine größere (Nicht-Software-)Firma entwickelt mit der eigenen EDV-Abteilung eine Software für den eigenen Bedarf. Die Komplexität ist höher als erwartet, die Entwicklungszeit und die Kosten laufen davon. Es ist Feuer am Dach, das Projekt droht zu kippen, Anstellungen sind bedroht.
- 2. Akt: DenkFehler: "... wenn wir schon so etwas Komplexes entwickeln, dann ist es kaum mehr Aufwand eine Standardsoftware zu entwickeln, die wir dann 50-100 mal, aber sicher mindestens 10-mal verkaufen können, so dass sich die Kosten und die zusätzlichen Entwicklungsjahre sicher wieder hereinspielen ..." Super. Alles wieder im Lot. Projekt wird neu ausgerichtet. Ziel: Fertigstellung in 2 Jahren.
- 3. Akt: Der Fertigstellungstermin bleibt immer ca. 2 Jahre in der Zukunft. Die Komplexität wächst weiter. Um die Kosten niedrig zu halten, setzt man Entwicklungskapazitäten aus Indien oder dem Ostblock ein. Die eigenen Entwickler machen nur mehr die Analyse und die Koordination. Konkrete Aquisitionserfolge (man ist ja keine Marketingfirma) bleiben weitgehend aus, aber man entwickelt ja auch noch ...
- 4. Akt: Nach etlichen Jahren wird auch dem Letzten klar, dass es sich um einen Sack ohne Boden handelt. Die Anforderungen ändern sich, während die Entwicklung noch nicht einmal die alten Anforderungen umgesetzt hatte. Vielleicht gibt es jetzt auch schon akzeptable Alternativen am Markt. Das Projekt wird gestoppt.
Übersehene Probleme:
- Standard-Software zu entwickeln ist immer ein vielfacher Aufwand von Individual-Software (meine Schätzung: Faktor 4), egal wie universell man schon zu programmieren glaubt.
- Firmeninterne EDV-Abteilungen besitzen fast nie die Qualität in Analyse und Entwicklung und die Härte im Projektalltag, um eine konkurrenzfähige Software auf den Markt bringen zu können.
- Das Problem der Komplexität wird falsch behandelt. Nicht durch Reduktion der Komplexität, sondern durch Übertragung und Verstärkung der Komplexität in der Software.
Erlebte Beispiele:
- Ein Apotheker mit mehreren Niederlassungen entwickelt eine Apotheken-Software ... und geht fast in Konkurs.
- Eine Schuhproduktionsfirma entwickelt die universale Schuh-Handels- und Verwaltungs-Software ... 10 Jahre später produziert sie keine Schuhe mehr.
- Ein Verlagshaus mit Buchhandlungen produziert die universale Standard-Buchhandels-Software ... das Projekt stirbt.
Beitragende: HelmutLeitner
KategorieDiskussion
StartSeite | Neues | TestSeite | ForumSeite | Teilnehmer | Kategorien | Index | Hilfe | Einstellungen | Ändern
Text dieser Seite ändern (zuletzt geändert: 28. Februar 2003 14:27 (diff))