Nicht zuletzt das Scheitern zahlreicher ambitionierter IT-Projekte in den Unternehmen rückt das Thema Software-Implementierung immer wieder in den Blickpunkt. Und bereits die Entscheidung nach dem „make or buy“ wirft etliche Fragen auf.
„The secrets of government, like the secrets of men, are always their defects.“
Thomas Paine
Die Spezifikation im Entwicklungsprozess
Im Rahmen der Neufassung der Qualitätsnorm DIN EN ISO 9001 ist der Prozess in den Mittelpunkt des Interesses gerückt. Alle Tätigkeiten innerhalb eines Unternehmens sollen als Prozesse organisiert [14,21] werden. Der große Vorteil für die Unternehmensleitung liegt darin, dass damit die Prozessleistung sichtbar und messbar wird. Dies gilt besonders für Prozesse, die zur Wertsteigerung im Unternehmen beitragen. Daneben existieren allerdings eine Reihe von Prozessen, die dem innerbetrieblichen Support zuzurechnen sind und nicht unmittelbar zum Erfolg beitragen. Trotzdem sind sie unverzichtbar, wenn das Unternehmen seine Aufgaben erfüllen soll.
Viele Software-Projekte scheitern, weil das Management seiner Aufgabe nicht gewachsen ist oder seine Pflichten nicht wahrnimmt. Wir wollen deshalb zuerst untersuchen, welche Modelle es zur Entwicklung gibt. Es ist auch zu fragen, was bei einem Projekt zu tun ist, wenn die vorgeschlagene Technologie so neu ist, dass noch niemand in der Branche Erfahrung mit ihr vorweisen kann.
Wenn wir die Prozesse zur Software-Entwicklung kennen, richten wir den Fokus auf den Beschaffungsprozess und fragen uns, wie wir ihn optimal gestalten können. Hier wird nicht für jedes Unternehmen und jede Art von Software der gleiche Prozess zur Anwendung kommen können.
Standard-Software oder individuelle Entwicklung
Eine wichtige Frage, die am Anfang jedes Projekts entschieden werden muss, ist die Frage nach der individuellen Entwicklung. Im Branchenjargon könnte man fragen: make or buy?
Wenn wir auf dem Markt ein Produkt finden, das unsere Anforderungen erfüllt, kommen wir schneller zum Ziel. Unsere Kosten werden niedriger sein als bei einer eigenen Entwicklung.
Dem stehen allerdings einige Nachteile gegenüber: Wir müssen das Design des Standard-Produkts akzeptieren und sind nicht in der Lage, unsere Vorstellungen durchzusetzen. Das Standard-Produkt ist unter Umständen gar nicht im Stande, unsere Anforderungen abzudecken, weil wir uns in einer Marktnische bewegen. Es könnte auch sein, dass wir zwar Standard-Software für unsere Zwecke anpassen können, dass wir uns damit aber zu wenig von Wettbewerbern im Markt unterscheiden würden.
Bei Webprojekten ist zu bedenken, dass wir viele eigene Inhalte einbringen wollen. Daher können wir das wenigste Material direkt übernehmen, sondern müssen es für das Internet aufbereiten. Eine enge Zusammenarbeit zwischen Entwicklern, Designern und eigenen Mitarbeitern wird deshalb anzustreben sein, wenn unser Auftritt im World Wide Web (WWW) auf Anhieb ein Erfolg werden soll.
Es könnte folglich zweckmäßig sein, Standard-Produkte einzusetzen, aber dennoch auf die Bedürfnisse unseres Unternehmens da einzugehen, wo es notwendig ist. Grundsätzlich ist es auch möglich, die Entwicklung im eigenen Haus vorzunehmen. In diesem Fall handelt es sich um einen internen Kunden, dessen Wünsche, Forderungen und Bedürfnisse durch eine Abteilung im Haus behandelt werden.
Wenn es darum geht, Software oder ein System zu entwickeln, das es vorher so noch nie gegeben hat, gehen wir bei der Entwicklung ein großes Risiko ein. Vielleicht handelt es sich um ein innovatives Produkt, vielleicht wissen wir bereits, dass wir mit der Leistung unseres Systems mit hoher Wahrscheinlichkeit an Grenzen stoßen werden.
Es könnte auch sein, dass der in Aussicht genommene Auftraggeber das Projekt eher als Routine ansieht, dass es aber politisch umstritten ist. Dies ist häufig bei Entwicklungsvorhaben für Kommunen der Fall. Wenn diese Umstände vorliegen sollten, kann es durchaus zweckmäßig sein, das Projekt nicht mit der Spezifikation als erstem Produkt zu beginnen, sondern zunächst eine Machbarkeitsstudie vorzunehmen.
„If at first you do succeed, hide your astonishment.“
Lucille S. Harper
Eine Machbarkeitsstudie ist sowohl auf der Ebene des geplanten Systems als auch beschränkt auf die Software möglich. Im amerikanischen Sprachraum ist dafür die Bezeichnung Feasability Study gebräuchlich. Natürlich sind in unserem technologiegläubigen Zeitalter grundsätzlich alle Vorhaben möglich. Wenn wir einen Mann zum Mond schicken können, sollten uns Projekte auf der Erde keine unüberwindlichen Schwierigkeiten bereiten. Es fehlt meist nur an der notwendigen Zeit und an finanziellen Mitteln. Da diese beiden wichtigsten Ressourcen in der Regel nur in begrenztem Umfang zur Verfügung stehen, ist eine Machbarkeitsuntersuchung zum frühest möglichen Zeitpunkt eine sehr vernünftige Sache. Sie kann viel Geld sparen, unnötig verschwendete Entwicklungskosten und nicht zuletzt Ärger und Prestigeverlust vermeiden.
Eine Machbarkeitsstudie sollte diese vier Bereiche vordringlich untersuchen.
a) Wirtschaftlichkeit des Projekts: Es werden die erwarteten Erträge bzw. Einsparungen oder anderweitige Nutzen mit dem Aufwand für die Erstellung des Systems verglichen.
b) Technische Machbarkeit: Es werden die Funktionen, die Leistung und mögliche Einschränkungen bei der Realisierung untersucht.
c) Realisierbarkeit unter rechtlichen Gesichtspunkten: Es stehen mögliche Patente oder Schutzrechte anderer Anbieter im Mittelpunkt des Interesses.
d) Alternativen: Es wird geprüft, ob die formulierten Ziele des Vorhabens sich auch auf anderem Wege erreichen lassen.
Eine Machbarkeitsstudie ist nicht angebracht, wenn die Wirtschaftlichkeit offensichtlich ist, wenn die technische Realisierung keine Schwierigkeiten macht und rechtliche Probleme nicht zu erwarten sind.
Die Machbarkeitsstudie sollte bei größeren und politisch umstrittenen Projekten nicht von der Firma durchgeführt werden, die für den Hauptauftrag in Frage kommt. Es besteht sonst die Gefahr, dass die Studie nicht mit der notwendigen Objektivität vorgenommen wird.
Der wirtschaftliche Teil der Machbarkeitsstudie zielt vor allem auf die Frage ab, ob sich das System für das Unternehmen rechnet, ob also bei dessen Einsatz unter dem Strich eine Einsparung zu erzielen ist.
Davon ausgenommen sind nur Systeme, bei denen das nationale Prestige ins Spiel kommt oder ein Bereich gefördert werden soll, weil es langfristig im nationalen Interesse liegt. Beispiele wären das Überschallflugzeug Concorde oder das Airbus-Programm. Bei der Concorde war der Vertrag so gestaltet, dass ab einem bestimmten Zeitpunkt während der Entwicklung ein Ausstieg aus dem Projekt für die beiden Nationen Frankreich und Großbritannien genauso teuer wie die Fertigstellung geworden wäre. Unter diesen Umständen zogen es die Regierungen in Paris und London vor, die Maschinen bauen zu lassen, obwohl abzusehen war, dass die Wirtschaftlichkeit im Betrieb nicht erreichbar sein würde.
Fragen wir uns also, welche Themen unbedingt in eine Machbarkeitsstudie gehören. Die Untersuchung der technischen Realisierbarkeit ist in dieser Phase oft am schwierigsten, da man sich auf Neuland begibt. Es liegen einfach keine gesicherten Erkenntnisse vor, und gemachte Annahmen könnten sich später als allzu optimistisch erweisen. Im Einzelnen kann man drei Problembereiche unterscheiden:
– Das Entwicklungsrisiko: Kann das System oder die Software mit ihren notwendigen Funktionen und der geforderten Leistung entwickelt werden, wenn man die erkannten Beschränkungen berücksichtigt?
– Die Verfügbarkeit von Ressourcen: Sind geschulte und motivierte Mitarbeiter verfügbar, oder können sie rechtzeitig eingestellt werden? Sind andere notwendige Ressourcen im Bereich der Hard- und Software verfügbar, oder können sie rechtzeitig beschafft werden?
– Stand der Technik: Ist die Technologie wirklich so weit fortgeschritten, dass alle Funktionen des Systems realisierbar sind?
Die Entwickler von Software sind ihrer Natur nach eher Optimisten. Wären sie das nicht, würden sie viele Projekte gar nicht erst beginnen. Trotzdem sollte man bei der Durchführung einer Machbarkeitsstudie eher mit konservativen Annahmen arbeiten. Blinder Zukunftsglaube ist nicht angebracht.
Neben der technischen Realisierbarkeit spielt bei Software in der jüngeren Vergangenheit der rechtliche Aspekt eine wichtige Rolle. Das Nichtbeachten von Patenten oder die Verletzung des Urheberrechts eines Konkurrenten können dem eigenen Unternehmen teuer zu stehen kommen. Dazu ein Fall aus den USA.
Das Nichtbeachten von Schutzrechten Dritter kann also teuer werden, wie Microsoft auf die harte Tour erfahren musste. Nun war dieses Unternehmen angesichts sprudelnder Gewinne und großer Nachfrage in der Lage, Stac angemessen zu entschädigen. Bei einem weniger finanzstarken Unternehmen kann ein derartiger Prozess durchaus das wirtschaftliche Aus bedeuten.
Wenden wir uns den einzelnen Elementen unserer Machbarkeitsstudie zu. Bei der Untersuchung der Wirtschaftlichkeit geht es darum, Aufwand und Nutzen einander gegenüberzustellen. Natürlich wird dies bei manchen Faktoren schwierig werden. Zum Beispiel ist der Nutzen, den ein Unternehmen an Ansehen und Prestige in der Öffentlichkeit durch den Einsatz eines neuartigen Systems gewinnt, kaum in Euro und Cent zu fassen. Trotzdem sollte man versuchen, eine Bewertung vorzunehmen. Bei der Software könnte man etwa die folgenden Kriterien wählen.
– Kostenreduzierung beim Einsatz des Systems
– Vermiedene Fehler durch den Ersatz ermüdender Tätigkeiten, falls eine Lösung mittels EDV gefunden wird
– Gewonnene Flexibilität bei der Durchführung der Tätigkeiten
– Zeiteinsparung und Reduzierung der Zahl der Mitarbeiter
– Bessere und schnellere Information für das Management
– Die Chance, schneller auf Veränderungen im Markt reagieren zu können
Wenn durch das EDV-Projekt ein existierendes System ersetzt werden soll, kann man die Kosten für die Durchführung der Tätigkeiten vergleichen. Der Gewinn ergibt sich als Überschuss der Kosten der neuen Lösung gegenüber dem alten Verfahren. Diese Differenz muss mit den Kosten für die Erstellung der Software oder des Systems verglichen werden. Natürlich lässt sich dann noch berechnen, nach welcher Zeit sich die Investition rentiert.
Bei der technischen Analyse kann man sich, wenn die Größe des Projekts es rechtfertigt, auch der Simulation bedienen. Mittels dieser Technik ist man in der Lage, ein geplantes System auch dynamisch und in seinem betrieblichen Verhalten analysieren zu können. Wie so oft kommt es auch bei der Simulation darauf an, ob die getroffenen Annahmen zutreffen, und ob das Modell in seinen kritischen Parametern die Wirklichkeit gut trifft. Ist dies der Fall, so kann man damit sicherlich Kosten sparen und die spätere Entscheidung auf eine vernünftige Grundlage stellen.
Schließlich sollte man zuletzt – wie immer die Empfehlung am Schluss der Machbarkeitsstudie lauten mag – die Alternativen nicht vernachlässigen. Zu den meisten Lösungen gibt es alternative Vorschläge, die zunächst übersehen werden. Sie sind es wert, untersucht und beurteilt zu werden.
Alternativen sind auch deswegen wichtig, weil bei innovativen Projekten die zunächst eingesetzte Technik möglicherweise nicht zu dem erwarteten Ergebnis führt. Das kann dazu führen, dass mitten im Projekt für ein Subsystem oder eine Komponente eine andere Technologie eingesetzt werden muss. In einem solchen Fall ist das Unternehmen im Vorteil, das im Rahmen der Machbarkeitsstudie die Alternativen gründlich untersucht hat.
Der Beitrag ist ein Auszug aus der Publikation
„Software-Anforderungen für Webprojekte. Vorgehensmodelle, Spezifikation, Design“ von Georg Erwin Thaller erschienen im Galileo Computing Verlag.
