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.