In dieser Serie geht es um die Probleme, die mit der Anpassung von Standardsoftware verbunden sind.
Terminologie
Vorab zur Terminologie, wie ich sie verwende. Da die IT-Branche keinen einheitlichen Sprachgebrauch hat, ist es müßig darüber diskutieren, was richtig oder falsch ist. Jedenfalls sollte dargelegt werden, welche Begriffe man mit welchen Inhalten verwendet.
1.) Standardsoftware: Es wird immer wieder geschrieben, dass Standardsoftware Software für breite Anwenderkreise sei; Individualsoftware sei solche, die man für ganz spezielle Kundenwünsche erstelle. Ich grenze die beiden Begriffe funktional danach ab, welche Funktionen sie in meinen Verträgen haben sollen. Die Unterscheidung von Standard- und Individualsoftware spielt eine Rolle bei der Beschreibung des Projekts (was ist der Standard und wie muss er angepasst werden, damit er den individuellen Bedürfnissen des Kunden entspricht?) und bei der Beschreibung der urheberrechtlichen Aspekte (welche Rechte erhält der Kunde an der Standardsoftware und welche an der Individualsoftware). Und wenn man diesen Ausgangspunkt akzeptiert, ist es ganz einfach: Standardsoftware ist die Software, die außerhalb und unabhängig von dem Projekt mit dem Kunden hergestellt wurde oder hergestellt wird, während Individualsoftware die Software ist, die im Auftrag des Kunden erstellt wird. Jede andere Definition hat mich bislang nicht weitergebracht.
2.) Customizing oder Parametrisierung
Insbesondere die Terminologie von SAP unterscheidet sich von vielen anderen der Branche: Customizing und Parametrisierung sind im Ausgangspunkt technische Maßnahmen zur Anpassung der Standardsoftware an die Bedürfnisse des Kunden. Ich spreche von Customizing, wenn Sourcecode verändert oder neu geschrieben wird und von Parametrisierung, wenn technische Möglichkeiten innerhalb der Software zur Anpassung verwendet werden können. Wichtig ist diese Unterscheidung, weil im Rahmen des Customizings an Software immer Nutzungsrechte entstehen, während dies bei der Parametrisierung nicht sein muss. Im Übrigen ist es ziemlich egal, ob man von Parametrisierung oder Customizing spricht.
Anpassung von Standardsoftware an die Geschäftsprozesse des Unternehmens
Standardsoftware soll immer das können, was der Kunde individuell verlangt. Dieser Satz ist nicht ironisch gemeint, sondern beschreibt ein Missverständnis, dem viele Kunden erliegen. Die Einführung von Standardsoftware verursacht Kosten. Um die Kosten bei der Einführung zu senken, wird gefordert, dass die Software so wenig als möglich individualisiert werden soll.
Und hier beginnt oft mein Unverständnis. Wenn die Standardsoftware zum eigenen Unternehmen wie ein Anzug passen soll, den man nur noch marginal durch den Schneider ändern lassen muss, müsste man von Seiten des Auftraggebers genau wissen, wie die Funktionen und Eigenschaften aussehen sollen, die die einzuführende Standardsoftware aufweist. Und der Auftraggeber müsste sich darüber im Klaren sein, wie die Geschäftsprozesse in dem eigenen Unternehmen aussehen, was bedingt, dass der Auftraggeber selbst weiß, wie in seinem Unternehmen gearbeitet wird.
Ich habe Geschäftsführer auf Kundenseiten erlebt, die ernsthaft sagten, sie wollten so viel wie möglich mit der Standardsoftware abdecken, die jetzt eingeführt werde. Das müsse werkvertraglich abgesichert sein. Als ich dann sagte, ob man denn wisse, wie man selbst im Unternehmen arbeite, war die Antwort: Nein, das wisse man nicht, aber man werde sich an die Software anpassen. Bis dahin war die Situation für mich rätselhaft, aber nun wurde sie obskur: Denn auf die Frage, ob man sich schon einmal mit der Leistungsbeschreibung der Standardsoftware beschäftigt habe, kam die Antwort, eine solche Leistungsbeschreibung gebe es nicht, man würde das später in Workshops feststellen.
An dieser Stelle kann ich jedes IT-Unternehmen verstehen, das nur im Dienstvertragsrecht arbeiten will. Das Werkvertragsrecht, das ja das Erreichen eines bestimmten Erfolgs zum Gegenstand hat, kann doch bitte nur dann zur Anwendung kommen, wenn man den Erfolg zumindest bestimmbar eingrenzen kann. Die Absurdität dieser Haltung des Auftraggebers – und die ist häufig im Markt anzutreffen – wird durch folgende Analogie klar: Man will ein Auto ohne Sonderausstattung kaufen, das seinen eigenen Bedürfnissen entspricht. Weder die eigenen Bedürfnisse hat man definiert noch die Leistungsbeschreibung der Standardausstattung studiert.
Projektfehler vermeiden – Was kann die Standardsoftware?
In den Workshops zwischen dem Auftragnehmer und dem Auftraggeber wird häufig blumig und viel darüber gesprochen, was die Prozesse der angepassten Software sein sollten. Das ist der falsche Weg. Der Weg beginnt mit dem Studium einer Leistungsbeschreibung der Standardsoftware.
Teil 2: Die Wichtigkeit der Leistungsbeschreibung der Standardsoftware