Natürlich ist es wahr, dass eine von Grund auf neu entwickelte individuelle Softwarelösung im Vergleich zu einer reinen Standardlösung teurer ist, sofern die genau gleiche Leistung resultieren soll. Aber auch bei Standardlösungen kann ein Softwareprojekt zu hohen Kosten führen, wenn Wünsche nach Optimierungen, Anpassungen, Schnittstellen etc. umgesetzt werden. Anpassungen an einer Standardlösung sind im Vergleich zu einer individuellen Lösung oft teurer. Daher kommt es bei der Einführung von Standardsoftware immer wieder vor, dass Kosten aus dem Ruder laufen und eine als günstiger empfundene Lösung schlussendlich teuer zu stehen kommt.

Warum Individualsoftware?

Sehr viele Standardlösungen haben einen individuell für den jeweiligen Kunden programmierten Zusatz. Dieser Zusatz kann grossen Ärger bereiten, wenn die Basis-Software gar nicht dazu gedacht ist, mit solchen Zusätzen zusammen zu funktionieren. Dabei spielt nicht nur die Technik der Software eine Rolle, sondern in hohem Mass die Strategie und das Verhalten des Herstellers. International aufgestellte Softwareunternehmen haben oft eine recht komplexe Firmenstruktur mit einer entsprechenden vollständigen Arbeitsteilung.

Die Tools der Entwickler

Die Entwicklungsumgebung stellt dem Programmierer die wichtigen Komponenten für seine Arbeit zur Verfügung wie ein Editor, welcher die Eingabe des Codes vereinfacht oder einen Compiler um den Code in eine für die Maschine ausführbare Form umzuwandeln. Im Allgemeinen definiert die Entwicklungs-umgebung auch die Programmiersprache, in einzelnen Fällen auch die Datenbank. Darüber hinaus nimmt die Entwicklungsumgebung viele Arbeiten ab, wie z.B. die Versionsverwaltung. Wichtig beim Program-mieren ist die Dokumentation. Welche Ideen stehen hinter dem Code? Auch hier werden starke Funktionen angeboten. Oft wird sogar eine bestimmte Entwicklungsmethodik wie Scrum unterstützt oder sogar vorausgesetzt. Das kann dazu führen, dass der lokale Implementierer und Programmierer von der grundsätzlichen Entwicklungsstrategie des Herstellers kaum etwas erfährt und überrascht wird von einem neuen Release, welches sich technisch eventuell massiv von der bisherigen Softwareversion unter-scheidet. Damit steht er genauso wie sein Kunde vor der Tatsache, dass die zusätzlich programmierten Teile im neuen Release nicht mehr funktionieren und eventuell nur mit grossem Aufwand wieder angepasst oder sogar ganz neu programmiert werden müssen. Die vermeintlich einmalige Investition steht damit noch einmal an.

Auch Tools können individuell sein

Neben der eigentlichen Entwicklungsarbeit bietet eine moderne Entwicklungsumgebung aber auch umfangreiche Bibliotheken an funktionalen Softwarebausteinen. Hier werden bereits für den Anwender erkennbare Unterschiede in Grundfunktionen  definiert. Ein einfaches Beispiel dazu zur Illustration: Möchte man auf einem PC ein File öffnen, so sehen die Bedienungs-elemente je nach Software recht unterschiedlich aus. Vielleicht mit gelben Ordnersymbolen, mit «+»-Zeichen oder kleinen Dreiecken. Natürlich will man bei der Softwareentwicklung nicht jedes Mal neu definieren, wie die Benutzer-oberfläche  auszusehen hat, um ein File zu öffnen. Das sollte in der Entwicklungsumgebung definiert und hinterlegt werden können. Gartenmann Software AG hat den Anspruch, dass auch dieses auf den ersten Blick nebensächliche Detail auf den unter-schiedlichen Geräten PC, Pad, Smartphone gleich behandelt wird, und der Benutzer überall das gleiche Erscheinungsbild antrifft. Das bedeutet wiederum, dass über der eigentlichen Entwicklungsumgebung eine weitere Schicht zu liegen kommt, welche die individuelle Strategie der Entwicklungsfirma transportiert.

Einheitlichkeit durch Framework

Kunden wollen heute eine Software einfach starten und ortsunabhängig, plattformneutral nutzen. Die Software resp. das User Interface soll stets gleich aussehen, egal mit welcher Basis-Technologie (Hardware, Betriebssystem) man die Software nutzt. Damit dies umgesetzt werden kann, werden dafür geschaffene Frameworks wie z.B. SERVOY eingesetzt. Unsere neuen Lösungen basieren technologisch auf SERVOY, erhalten dazu aber eine eigene «Zwischenschicht», um dem Anspruch der grafisch identischen Darstellung und Nutzung der Software gerecht zu werden.

Das von uns entwickelte ergänzende Framework basiert auf einer Java/Javascript Technologie und erlaubt es, effzient Module und Softwarebereiche mit grafisch identischem Erscheinungsbild auf allen Plattformen und Gerätetypen anzubieten. Basierend auf unserem sogenannten «Core», einem zentralen Lösungskern mit allen immer wieder benötigten Softwaremodulen und –funktionalitäten, können wir mit vernünftigem Aufwand kundenspezifische Anwendungen erstellen, ohne das Rad immer wieder neu erfinden zu müssen. Die Releasefähigkeit wird dabei bewahrt, da kundenspezifische Entwicklungen ausserhalb des «Core» stattfinden.

Der Kern ist schon vorhanden

Je nach Kundenbedürfnissen können wir mit den vorhandenen Kernmodulen 30% bis 70% des gewünschten Projektes  abdecken. Mit diesem Anteil kann gleich verfahren werden wie mit einer Standardsoftware. Die Kosten sind bekannt und bieten für das Projekt schon mal eine entsprechende Budget-Sicherheit. Das Augenmerk für die Projektsicherheit liegt daher auf dem individuell zu entwickelnden Softwareteil. Wie soll vorgegangen werden, damit die Software zu vereinbarten Kosten die Aufgabe beim Kunden erfüllt? Grundsätzlich ist dazu in jedem Fall eine enge Zusammenarbeit vom Anbieter und vom Anwender notwendig, sonst kann sich der Erfolg nicht einstellen. Gerade dieser Aspekt wird aber oft zu wenig beachtet.

Kann der Projekterfolg erzwungen werden?

Die Angst vor dem Misserfolg und ein latentes Misstrauen definiert zu häufig beim Auftraggeber das Vorgehen und verhindert den gesuchten Erfolg. Typischerweise versucht der Auftraggeber mit einem möglichst engen Pflichten- (Lasten-) Heft die Software zu definieren und die Definition gleich noch mit Verträgen zu fixieren. Funktionen, Preise und Strafen sind damit schon mal definiert, eine gute Lösung aber leider nicht. Oft wird dabei nicht einmal das zu Grunde liegende Problem, also die eigentliche zu lösende Aufgabe der Software verständlich oder sogar messbar beschrieben. Der Auftraggeber sieht sich bereits selbst in der Rolle des Entwicklers. Dieses Vorgehen hat mindestens zwei fundamentale Nachteile:

  • Es verhindert jegliche Kreativität in der Softwareentwicklung. Die abgegebene genaue Definition schiebt den Entwickler in die Rolle des Ausführenden, sein eigenes Denken ist nur beschränkt erwünscht. Durch die intensive geistige Durchdringung während der Entwicklung könnten aber elegante Ideen entstehen, welche das Budget entlasten könnten statt zu belasten.
  • Auf Veränderungen im Umfeld kann nicht eingegangen werden. Gute Business Software ist kein statisches Gebilde! Sie entwickelt sich technologisch und funktional und soll sich den Kundenbedürfnissen anpassen. Gerade bei lang dauernden Projekten ändern sich zudem im organisatorischen Umfeld oft entscheidende Faktoren, welche einbezogen werden müssten. Beispielsweise bringen sich verändernde Firmenstrukturen andere Anforderungen an die Software mit sich, oder der Aufgabenschwerpunkt wird durch einen Personalwechsel verschoben.

Der Auftraggeber muss dem Entwickler gewissermassen eine lange Leine geben, um wirklich gute Lösungen zu erhalten. Um sich trotzdem nicht dem Vorwurf auszusetzen, dass dieses Vorgehen einer Fahrt ins Blaue gleichkommt, spielt es eine grosse Rolle, worauf das nötige Vertrauen basiert. Gibt es eine Reihe verlässlicher Referenzen? Sind die angewendeten Methoden verlässlich und zielführend?

Die Zusammenarbeit definiert den Erfolg

Gerade bei den Projektmethoden öffnen sich fast ideologische Gräben. Die langjährige Praxis bei Gartenmann zeigt, dass es auch ohne Konflikte geht. Angewendet werden Scrum und agile Methoden, um in kleinen Schritten zum Ziel zu kommen. Vor allem aber braucht es Tools und ein konstantes Verhalten, um über die lange Entwicklungszeit eng mit dem Kunden zusammen zu spannen. In diesem Bereich hat sich in den letzten zehn Jahren viel verändert. Gartenmann setzt heute über die Cloud Blogs und Wikis ein, um das Projekt in allen Facetten zu beschreiben. Damit wird nicht nur Transparenz geschaffen, sondern auch der Auftraggeber in die Pflicht genommen. Dieses Beispiel zeigt anschaulich: Wer von den Vorteilen einer individuell entwickelten Software profitieren will, muss sich selbst dafür engagieren. Eigene Ressourcen sind unabdingbar, um die Prozesse und Anforderungen zu formulieren und laufend zu testen, zu hinterfragen und nicht zuletzt im Dialog dem Entwickler zur Verfügung zu stehen. Individualsoftware, um entscheidende Vorteile über die Konkurrenz zu erlangen, kann man nicht einkaufen wie eine Kiste Bier. Da helfen auch juristisch stichfeste Verträge nicht viel. Mit einem steigenden Anteil von Individualsoftware nehmen auch die weichen Faktoren zu, welche berücksichtigt werden müssen. In diesem Aspekt kann die neutrale Sicht eines unabhängigen Beraters allenfalls nutzbringend zugezogen werden.