Eines der größten Probleme in der Entwicklung von Softwarelösungen war die mangelnde und teilweise mißverständliche Kommunikation zwischen EDV- und Fachbereich. Diese Probleme löst im kaufmännischen Bereich ein PC- Anwendungsprogramm für Einkaufssysteme, entwickelt vom Rationalisierungs-Kuratorium der Deutschen Wirtschaft (RKW). Vor Veröffentlichung der Prototyp-Programmvorgabe soll die Implementierung bei Pilotanwendern getestet werden. Die wesentlichen Entwicklungsschritte der Methode sind:
- Die Mitarbeiter des Fachbereichs arbeiten unter Anleitung eines Kollegen, der das Modell im Seminar kennengelernt hat, mit der Software am PC. Dadurch wird eine von allen Mitarbeitern getragene Entscheidungsgrundlage geschaffen.
- Wird diese Softwareanwendung akzeptiert, kann der EDV-Bereich nach einer vom RKW veröffentlichten Programmvorgabe, die unabhängig von der jeweiligen Hard- und Software ist, das Modell als Prototyp in kurzer Zeit implementieren. Der Prototyp enthält alle üblichen Anwendungsfunktionen und deckt je nach den unternehmensspezifischen Gegebenheiten 60 bis 80 Prozent der hausinternen Anforderungen ab.
Der Experte aus dem Fachbereich kann die betriebswirtschaftlichen Lösungen für die fehlenden Anforderungen selber am PC entwickeln und als Ergänzung oder Verfeinerung in den Prototyp einfügen.
Der EDV-Bereich setzt die zusätzlichen betriebswirtschaftlichen Lösungen wie beim Prototyp in das reale DV-System um.
In der Abbildung sind die Arbeitsschritte und Entscheidungspunkte nochmals verdeutlicht. Daraus wird klar: Der Fachbereich braucht über seine Lösung mit dem EDV-Bereich nicht mehr zu diskutieren, der jeweilige Bereich erfüllt diejenigen Aufgaben, für die er kompetent und verantwortlich ist. Der Fachbereich entwickelt die Anwendungen (logisches Design), der EDV-Bereich setzt das logische System in das physikalische System um.
Software-Prototypen sparen Entwicklungszeit
Daß eine solche Entwicklungsmethode nicht schon längst auf dem Markt ist, liegt wohl daran, daß kein Softwarehersteller sein Know-how als fertige fachliche Programmvorgabe so tiefgehend preisgibt, und jeder folglich die Software leicht nachmachen kann. Hat diese Methode am Markt aber erst einmal Erfolg, werden die Softwarehersteller ihre Standardprodukte auch alternativ als nachmachbaren Prototyp anbieten.
Die neue Entwicklungsmethode ist gegenüber einer vollständigen Eigenentwicklung oder Standardsoftware zu bewerten. Vergleichsbasis soll hier ein integriertes Einkaufssystem mit den Funktionen: Bedarfsanforderung, Anfrage, Angebot, Lieferantenauswahl, Bestellabwicklung, Wareneingang, Rechnungsprüfung, Entscheidungsunterstützung und Statistik sein.
Für eine Eigenentwicklung werden etwa fünf Mannjahre = 60 Mannmonate benötigt, die sich je zur Hälfte auf die fachliche Entwicklung/Organisation und die Programmierung aufteilen. Bei der neuen Methode werden für die Implementierung des Prototyps je nach dem eingesetzten Software-Entwicklungssystem durchschnittlich zwei Mannmonate gebraucht. Die Entwicklung und DV-Anpassung der durchschnittlich noch fehlenden 30 Prozent betriebsspezifischer Anforderungen beträgt (analog zur Eigenentwicklung, 30 Prozent von 60 Mannmonaten) 18 Mannmonate. Dieser Aufwand dürfte in der Praxis geringer sein, weil es leichter ist, ein vorgegebenes Grundmodell/Prototyp zu ergänzen und zu verfeinern als alles neu zu entwickeln. Gegenüber der Eigenentwicklung werden also 40 Mannmonate (60 - (2+18)) eingespart. Davon sind die Kosten für einen Seminarbesuch, für das Anwendungsprogramm auf PC und die Prototyp-Programmvorgabe von insgesamt 20 000 Mark noch abzusetzen. Bei einem Monatssatz von 10 000 Mark beträgt die gesamte Einsparung 380 000 Mark.
In dieser Vergleichsrechnung ist die Vorgabe eines abgesicherten Prototyps nicht bewertet. Bei einer Eigenentwicklung verfällt man aus Zeitdruck oder Unkenntnis leicht in den Fehler, von den bestehenden Abläufen auszugehen und nicht alle Möglichkeiten der Verbesserung auszuschöpfen. Doch dadurch sinkt der Nutzen der Anwendung erheblich.
Es kommen erhebliche Anpassungs-Kosten hinzu
Beim Vergleich zur Standardsoftware sind der Anschaffungspreis und die Anpassungskosten gegenüberzustellen. Der Preis einer integrierten Einkaufs-Standardsoftware mit dem angeführten Funktionsumfang beträgt zwar durchschnittlich 200 000 Mark, also so viel wie bei der neuen Methode anfallen. Dazu kommen aber noch erhebliche Anpassungskosten, die davon abhängen inwieweit sich der betriebliche Ablauf an den Standardablauf anpassen läßt und wie oft die Kosten durch neue Versionen nochmals anfallen. Im Schnitt müssen etwa zehn Prozent des Funktionsumfangs vom Softwarehersteller angepaßt oder ergänzt werden.
Nicht bewertet sind des weiteren die Abhängigkeit vom Softwarehersteller.
Nach der neuen Methode arbeitet der Fachbereich erst gründlich mit dem Prototyp und die Unternehmen haben ein transparentes, gut strukturiertes Programmpaket, das sie selber an zukünftige Entwicklungen leicht anpassen können. Gerade mittelständische Unternehmen müssen (und vollen) sich auf geänderte Situationen schnell mit ihrer Organisation einstellen können.
Die Prototyp-Programmvorgabe ist unabhängig vom Zielrechner, von der Zielsprache und dem Datenbanksystem, um durch eine implementationsunabhängige Vorgabe einen hohen Verbreitungsgrad zu erreichen, besonders aber auch um den Fachbereichsexperten nicht mit DV- Spezifikationen zu belasten.
Das fachliche Modell des Prototyps und die Ausführung der Programmvorgabe müssen die Akzeptanz beim Fach- und EDV-Bereich sicherstellen. Daher wurde der Prototyp aus verschiedenen fortschrittlichen Praxislösungen abgeleitet und zu einer optimalen Lösung weiterentwickelt mit der der Anwender gerne wie mit einem handlichen Werkzeug arbeitet, und mit der er auch hochgesteckte Ziele erfüllen kann. Eine solche Software entlastet ihn von Routinearbeiten und gibt ihm Zeit für kreative Aktivitäten, wodurch er ganz wesentlich zum Unternehmenserfolg beiträgt.
Dem Programmierer bleibt das physikalische Design
Die Programmierer sind gewohnt, nach eigenen Vorstellungen zu entwickeln; bei der neuen Methode sollen sie nur noch die systemabhängigen Spezifikationen (physikalisches Design) einbringen. Den Programmentwurf (logisches Design) dürfen sie nicht verändern, damit der implementierte Prototyp so wie das Anwendungsprogramm, mit dem der Fachbereich bereits auf dem PC gearbeitet hat, abläuft. Daher werden in der Programmvorgabe die Prinzipien des Programmentwurfs erläutert und vor dem Hintergrund einer benutzergerechten Gestaltung begründet.
Der Programmablauf ist in Form von Struktogrammen, denn eine Grafik sagt mehr als tausend Worte, nach der Top-Down-Methode bis auf Befehlsebene niedergelegt. Die Anweisungen und symbolischen Feldnamen sind darin in allgemein verständlichen Ausdrücken aufgeführt. Die symbolischen Namen sind so sprechend, daß ein Nachschlagen in Satzbeschreibungen nicht nötig ist. Zu der Programmvorgabe gehören außer dem Programmablauf (Funktionen) die Satz und Datenbankbeschreibungen und die Bildschirmmasken. Dieser Rahmen muß in der Regel an die betrieblichen Gegebenheiten angepaßt werden. Die Anpassung auf der Basis der vorgegebenen Beschreibungen bereitet allerdings keine Probleme. Die Druckprogramme sind nicht in der Prototyp-Vorgabe enthalten, weil sie zu betriebsspezifisch und leicht zu programmieren sind.
Der Aufwand zur Implementierung des Prototyps ist abhängig vom eingesetzten Programmiersystem (CASE). Am besten eignet sich die Methode, bei der die Programme am PC in Struktogrammform entwickelt und nach Fertigstellung automatisch auf den Host übernommen werden.
Der vorgegebene Prototyp kann hierbei sofort über eine mitgelieferte Diskette auf den PC geladen werden, wenn das gleiche Software-Entwicklungstool (Struktogramm-Editor) wie bei der Erstellung des Prototyp-Programmablaufs eingesetzt wird, so daß nur noch die programmiersprachenabhängige Modifikation vorgenommen werden muß. Im anderen Fall muß der Prototyp anhand der schriftlichen Programmvorgabe auf den Host nachcodiert werden.
Für die Entwicklung der fehlenden Anforderungen eignet sich am besten der Experte aus dem Fachbereich, weil er vorher das Modell in der Anwendung ausführlich kennengelernt hat. Ihm stellt sich der Prototyp- Programmablauf nicht abstrakt dar, sondern in allen Verästelungen gefüllt mit der fachlichen Aufgabenstellung. Der Zugang zur Programmlogik fällt ihm daher wesentlich leichter als einem fachfremden Programmierer.
Die Fachabteilung übernimmt das Austesten
Der analytisch denkende Fachmann hat die Struktogrammelemente und Programmentwicklung mit dem entsprechenden Softwaretool auf dem PC schnell erlernt. Schließlich dürfte es ihm auch nicht schwerfallen, die zielsprachenunabhängige Modifikation am PC vorzunehmen, so daß er auch für das Testen unabhängig vom EDV-Bereich ist. Aufgabe des EDV-Bereichs ist dann nur noch die Übernahme der am PC fertig entwickelten Lösung auf den Host.
Ein umfangreiches, integriertes System läßt sich mit allen seinen Funktionen nicht vollständig theoretisch entwickeln, sondern nur schrittweise. Erst wenn eine Funktion in der Anwendung erprobt ist wird die nächste Funktion entwickelt (Prototyping). Die mustergültige Programmstruktur des Prototyps wirkt als nachahmbares Beispiel zur Entwicklung der Ergänzungen. Gerade in der Testphase zeigen sich die Vorteile einer guten Strukturierung. Auftretende logische Fehler sind schnell behoben, wenn Entwicklung und Anwendung in einer Hand liegen. Auch die viel bejammerten Wartungskosten dürften auf diese Weise bedeutend niedriger liegen.
Entwickelt der Fachexperte selber, denkt er tiefgehender über Problemlösungen nach als wenn er nur Ansprechpartner des EDV-Bereichs ist. Dadurch treten Verbesserungsmöglichkeiten zu Tage, auf die sonst keiner gekommen wäre.
Die neue Methode unterstützt so die sich abzeichnende Entwicklung in der Software-Landschaft:
- Die DV-technischen Routinearbeiten übernehmen in steigendem Maß die Softwaretools. Künftig ist daher der geschulte Experte aus dem Fachbereich gefordert.
Das PC-Anwendungsprogramm für ein Einkaufssystem hat sich in mehreren RKW-Seminaren bewährt. Bevor das RKW die Prototyp-Programmvorgabe veröffentlicht und weitere Anwendungsgebiete aufbereitet, mochte das RKW bei geeigneten Pilotanwendern die Implementierung des Prototyps und die Weiterentwicklung zum betriebsindividuellen Einkaufssystem testen.
Gefragt sind mittelständische Unternehmen, in denen die Einkäufer gerne mit einem integrierten, benutzerfreundlichen System arbeiten und es mitentwickeln möchten und in denen der EDV-Bereich auch einmal neue Methoden der Softwareentwicklung in Zusammenarbeit dem Fachbereich erproben möchte.
Die Pilotanwender erhalten vom RKW geforderte Unterstützung durch Unternehmenspraktikerin der Einkaufsorganisation.