Es ist noch nicht allzu viele Jahre her, da gab es bezüglich des Einsatzes von Softwarelösungen nur ein Zaubermittel: Standardsoftware. Als Argumente wurden vor allem geringere Kosten ins Feld geführt, aber auch eine höhere Qualität der Produkte, ein breiter Support oder die laufende Weiterentwicklung wurden als Vorteile von Software ab der Stange genannt.
Heute aber ist Individualsoftware wieder deutlich höher im Kurs. Dies nicht zuletzt darum, weil Informatik heute längst nicht mehr nur als Kostenfaktor gesehen wird, sondern als Chance, sich mittels Technologie zu differenzieren, und Differenzierung ist mit Standardprodukten nur schwer zu erreichen. So erklärt Renato a Marca de Donatz, COO Business Software bei Löwenfels Partner: «Individualsoftware macht dort Sinn, wo sich ein Unternehmen von der Konkurrenz abheben will. Wenn es nicht zentral ist, dass ich mich im Verkaufsprozess differenziere, dann wähle ich eine Cloud-Lösung. Das geht schnell und ohne viel Aufwand. Allerdings muss ich mich mit dem vorgegebenen Prozess arrangieren. Will sich aber mein Unternehmen genau im Verkaufsprozess von allen Mitbewerbern unterscheiden, dann macht es Sinn, eine individuell auf meine Bedürfnisse angepasste Lösung einzusetzen.»
Keine Entweder-/Oder-Frage
Allerdings ist die Frage nach Standard- oder Individualsoftware keine Entweder-/Oder-Frage. Standardsoftware macht sicherlich überall dort Sinn, wo Standardprozesse abgebildet werden. Zeiterfassung, Buchhaltung, CRM oder ERP sind hier Beispiele. Dazu Laurin Stoll, CEO von Yoo: «In vielen Bereichen existiert gut entwickelte Standardsoftware. Individualsoftware und Software ab der Stange schliessen sich jedoch gegenseitig nicht aus. Die Frage ist nicht ‹build vs. buy› sondern wo ‹buy› und wo ‹build›.» Häufig führe die Kombination zu sinnvollen Ergebnissen, wobei auch bei Individualsoftware einzelne Komponenten dazugekauft werden können, so Stoll. «Individualsoftware ist überall dort erfolgsversprechend, wo sonst viele gelebte und eingefleischte Prozesse in einem Betrieb geändert werden müssen.»
In eine ähnliche Richtung gehen die Aussagen von Thomas Wüst, CEO und Inhaber von Ti&m: «Je individueller die Prozesse, desto sinnvoller auch eine individuelle Entwicklung.» Nach dieser einfachen Formel seien die etablierten und standardisierten Unternehmensprozesse wie Finance und Controlling oder HR nach wie vor prädestiniert für Standardsoftware-Pakete. «Aber Vorsicht: im Zuge der Digitalisierung bleibt in einigen Unternehmen kein Stein auf dem anderen. Neue Geschäftsmodelle spriessen wie Pilze aus dem Boden und generieren neue Bedürfnisse. Als Reaktion entwickeln sich die Softwarearchitekturen immer mehr von monolithischen Blöcken hin zu Service-Netzen, die je nach Bedarf zusammengestellt und bei Bedarf um neue Services erweitert werden.» Diese Entwicklung mache auch vor den Kernfunktionen eines Unternehmens nicht halt, so Wüst, was zur Folge hat, dass die Standardkomponenten wesentlich feingranularer seien und auch nicht mehr unbedingt aus einer Hand kommen müssen.
Mittels Testprojekt zum richtigen Partner
Ist der Entscheid gefallen, sich eine massgeschneiderte, individuelle Software entwickeln zu lassen, geht es an die Suche des passenden Entwicklungspartners. Diese Suche kann durchaus aufwändig sein, allerdings ist die Wahl des passenden Partners für das Gelingen eines Software-Projekts absolut entscheidend. Oder wie es Yoo-CEO Laurin Stoll sagt: «Softwareentwicklung ist ein People Business: Am Schluss wird das entwickelte Resultat nur so gut, wie die Zusammenarbeit zwischen Auftraggeber und Auftragnehmer.» Philippe Streit, CEO von Advis, fügt ausserdem hinzu: «Der Aufbau der Kundenbeziehung vor dem eigentlichen Projekt ist entscheidend.» Gespräche nicht nur mit den Verkäufern, sondern auch mit den Entwicklern, Projektleitern – das sei der Weg zum Erfolg, weiss Streit.
Reto Bättig, CEO von M&F Engineering, gibt folgenden Rat: «Am besten findet ein Unternehmen den passenden Partner, indem es mit den möglichen Partnerfirmen über das Vorhaben spricht und idealerweise sogar passende Referenzkunden des Unternehmens kontaktiert. Danach kann man mit einem kleinen Testprojekt prüfen, ob sich die Erwartungen erfüllen. So entwickelt sich ein gutes Gefühl, ob die Partnerfirma zum Unternehmen passt.» Ins gleiche Horn bläst Laurin Stoll: «Die beste Evaluation eines Software-Partners gelingt unserer Erfahrung nach mittels eines kleinen, überschaubaren Pilot-/Vorprojektes.»
Ebenfalls als wichtige Kriterien bei der Wahl eines Software-Entwicklungspartners genannt wird die ausgewiesene Erfahrung in ähnlich gelagerten Projekten respektive erfolgreiche Referenzprojekte inklusive entsprechender Kundenreferenzen, aber auch qualifiziertes Management und Personal, finanzielle Stabilität und in dem Zusammenhang die Firmenhistorie sowie Skalierungsmöglichkeiten innerhalb der Firma respektive im Netzwerk. Entsprechend wird eine aktive Marktrecherche empfohlen, zum Beispiel in IT-Fachmedien, sowie das Einholen von Auskünften bei IT-Consulting-Firmen, CIOs anderer Firmen und im eigenen Netzwerk.
Von den Entwicklerunternehmen immer wieder genannt wird auch der Punkt Kommunikation beziehungsweise die Notwendigkeit, dass Kunde und Anbieter dieselbe Sprache sprechen. Ebenfalls Beachtung zu schenken ist weiter den vom Entwickler verwendeten Technologien, wie Andrin Spring, CEO von Exanic, erklärt: «Wichtig ist sicherlich, dass moderne und aktuelle Technologien verwendet werden.» Hier könne es zu einem Tradeoff zwischen Erfahrung/Bewährtem und Neu/Innovation kommen. Diese Balance sei nicht immer einfach zu finden. «Die verfügbaren Kapazitäten und gegenseitigen Erwartungen sollten zudem klar abgesprochen werden, um spätere Missverständnisse zu vermeiden.» Für eine zielführende Partnerschaft sei es zudem sinnvoll, dass man bezüglich Unternehmenskultur ein ähnliches Mindset hat – Stichwort Agilität beispielsweise –, weil dies den Alltag beziehungsweise die Zusammenarbeit massgeblich prägt. Und: «Im Rahmen einer Auswahl ist es auf jeden Fall sinnvoll, immer mehrere Optionen zu prüfen. Der potenzielle Softwarepartner sollte über ein Profil mit klar erkennbarem Fokus verfügen. Software ist nicht gleich Software. Die Zeiten, wo eine Firma alles kann, sind heute definitiv vorbei.» Thomas Wüst von Ti&m ergänzt: «Ein Softwarepartner, der die Bedürfnisse des Kunden aufnehmen kann und mit ihm gemeinsam innovative und erfolgreiche Lösungen gestalten kann, sitzt nah beim Kunden vor Ort und deckt das komplette benötigte Wissen – fachlich, methodisch und technisch – in vertikal integrierten Teams ab. Nur ein solches Setting ermöglicht eine echte Partnerschaft auf Augenhöhe, bei der der Auftraggeber vom unternehmerischen Geist und der Innovationsfähigkeit des Dienstleisters profitieren kann.»
Anforderungen: Ein Agiler, kollaborativer Prozess
Ist der Software-Entwicklungspartner gefunden, steht als nächster grosser Meilenstein die Definition eines Anforderungskatalogs an. «Der Anforderungskatalog muss sowohl funktionale, nicht funktionale Anforderungen sowie Randbedingungen enthalten. Diese sind entsprechend kategorisiert und in Muss, Soll und Kann eingeteilt», erklärt dazu Patrick Arpagaus, CEO von Werosoft. Weiter ergänzt er, dass die Anforderungen verständlich formuliert und im Falle von nicht-funktionalen Anforderungen auch messbar sein sollen. Und: «Im Idealfall sind die Anforderungen bereits mit Akzeptanzkriterien ergänzt.» Daniel Gubler, Account Manager bei Clavis, fügt an: «Wichtig für den Anforderungskatalog ist der Einbezug der absoluten Spezialisten aus dem Business und der IT, kombiniert mit Personen, die den Blick fürs Ganze haben.» Bei Clavis starte man häufig mit einer initialen Version, worauf dann die Anforderungen agil gesammelt, bewertet und in überschaubaren Arbeitspaketen umgesetzt werden. In eine ähnliche Richtung gehen die Aussagen von Nicolas Durville, CEO von Zühlke Schweiz. Er sagt, dass im Requirements Engineering früher häufig lange und umfangreiche Anforderungskataloge geschrieben und diese anschliessend an die Softwareabteilung zur Umsetzung weitergegeben wurden. Dies mit dem Ergebnis, dass Anforderungen implementiert wurden, die nicht gebraucht wurden oder keinen echten Mehrwert mit sich brachten. «Heute ist der Prozess von agilen Prinzipien und einem engen Austausch mit den Fachabteilungen geprägt. Die Produkte werden über mehrere Sprints weiterentwickelt. Die Entwicklung ist daher schneller, die Ergebnisse werden früher sichtbar und die entwickelte Lösung bringt den Fachabteilungen und Kunden den erwünschten Mehrwert», so Durville, der zudem anfügt: «Die echten Erfolgsfaktoren sind die enge Zusammenarbeit des Business und der IT sowie die schrittweise Entwicklung von neuen Lösungen.»
Laut Tim Weinmann, VP Marketing bei Mimacom, wird ein Anforderungskatalog im Idealfall zusammen erarbeitet. «Insofern sollte auch das Requirements Engineering in einem kollaborativen Modus stattfinden. Somit können die Anforderungen frühzeitig einer Kosten-/Nutzen-Analyse unterzogen werden, das gemeinsame Verständnis der zu entwickelnden Lösung steigt und die technologischen Anforderungen können daraus abgeleitet werden.» Dies bestätigt auch Advis-CEO Philippe Streit: «Wir haben sehr gute Erfahrungen gemacht, wenn unsere Mitarbeitenden direkt mit dem Benutzer vor Ort interagieren und mittels Interviews und Besuchen vor Ort die Arbeitsabläufe und die Firma kennenlernen. In einem zweiten Schritt werden dann User-Stories erstellt und gemeinsam immer detaillierter beschrieben. Am Ende des Prozesses hat man eine sehr gute Übersicht über das ganze Projekt, die nötigen Arbeiten und auch eine grobe Aufwandschätzung.»
Eine Herausforderung dieser agilen Vorgehendweise liegt allerdings darin, das Budget im Griff zu haben, wie etwa Andrin Spring, CEO von Exanic, erklärt, «weil das agile Vorgehen nicht den Anspruch hat, sämtliche Einzelheiten von Beginn weg zu definieren.» Gleichzeitig bestehe aber oftmals der Anspruch nach einer genauen Aufwandschätzung, woraus sich ein Zielkonflikt ergebe. «Es macht deshalb Sinn, ein Budget zu definieren und dieses in überschaubare Teile wie zum Beispiel Phasen und Meilensteine aufzuteilen. Neben einer laufenden Budgetkontrolle ist vor allem die konsequente Beachtung der Prioritäten im Backlog beziehungsweise deren Anpassung bei Bedarf sowie das Tracking von Änderungen und neuen Anforderungen entscheidend für den Projekterfolg.» Wichtig sei nicht zuletzt auch, dass man sich bewusst wird, dass ein Projekt heute selten «fertig» ist. «Nach dem Release erfolgt die Weiterentwicklung aufgrund von Anpassungen und neuen Anforderungen, welche sich über einen längeren Zeitraum verteilt. Es ist deshalb sinnvoll, bei der Budgetierung diese Weiterentwicklung zu berücksichtigen. Die Folge sind Jahresbudgets anstatt einmalige Projektbudgets.»
Den Unterhalt nicht vergessen
Aber auch abgesehen von Budget gibt es einige Punkte hinsichtlich Betrieb beziehungsweise Unterhalt und Support zu beachten, wenn eine entwickelte Software eingeführt wurde. Reto Bättig, CEO von M&F Engineering, schickt hierzu voraus, dass die wichtigste Frage hierbei sei, ob die Software «lebt», sprich kontinuierlich weiterentwickelt wird, oder ob sie «fertig» ist, etwa für ein Laborgerät oder eine Maschine entwickelt wurde, die danach 20 Jahre lang ihren Dienst tun soll. «Je nachdem gibt es ganz unterschiedliche Anforderungen an Unterhalt und Support. Wichtig ist, dass man schon am Anfang des Projekts darüber spricht, was danach an Unterhalt und Support benötigt wird und wie man das am besten organisatorisch aufstellen und gewährleisten kann.»
Immer wieder genannt wird im Zusammenhang mit Support der DevOps-Ansatz, wo die Entwickler auch für die Wartung und gewisse Teile des Betriebs verantwortlich sind, wie Nicolas Durville von Zühlke erklärt. Auch Thomas Wüst, CEO von Ti&m, sagt, dass Entwicklung und Betrieb immer mehr zum DevOps verschmelzen: «Insofern ist es sehr sinnvoll, mit einem Partner zusammenzuarbeiten, der den gesamten Lebenszyklus eines Produktes abdecken kann, von der ersten Idee über die kompetente Entwicklung bis zum stabilen Betrieb gemäss anerkannten Sicherheits- und Management-Standards. Gerade in Cloud-basierten Umgebungen, mit Micro-Service-basierten Applikationen und komplexen Containerorchestrierungen ist es essenziell, dass Entwicklung und Operations ohne Kommunikationsverluste zusammenspielen. Insofern ist auch hier das Konzept der vertikal integrierten Teams das erfolgversprechendste Modell.»
Ebenfalls mehr als einmal genannt werden Service Level Agreements (SLAs), die auch vom Gros der Entwicklerfirmen angeboten werden. Daniel Gubler von Clavis etwa erklärt, dass bei jedem Projekt auch ein SLA abgeschlossen werde, welches dem Kunden die nötige Sicherheit in der Betriebsphase gibt. «Bestandteil des SLA ist die Verfügbarkeit unserer Spezialisten, ein Monitoring der Lösung, proaktive Wartungsarbeiten und auch ein vorausschauendes Releasemanagement, um die nötigen Unterhaltsarbeiten zu planen und durchzuführen.»
Nicht zuletzt wird auch empfohlen, ein fixes Budget für den Unterhalt der entwickelten Software einzuplanen. Christian Güdemann, CTO und Leiter Development bei Webgate Consulting, erklärt, dass gemäss eigener Erfahrung rund 20 bis 25 Prozent des Budgets für die erste Phase des After-Go-Life-Supports reserviert sein sollten. «Damit lassen sich ‹Quick Wins› realisieren, welche innerhalb des Projekts nicht aufgefallen sind – kleine Anpassungen, welche beim Kunden zu einer Verbesserung im Arbeitsprozess führen.» Nach dieser Phase des After Go Lifes empfehle es sich, jeweils mindestens 15 Prozent des Projektbudgets pro Jahr für den Unterhalt und Support zur Verfügung zu stellen, damit auf Änderungen im Prozess und eventuelle Fehler reagiert werden kann. Bestätigt werden diese Angaben von Laurin Stoll von Yoo. Er erklärt: «Ein System ist nur so gut, wie man es auch unterhält und pflegt. Es lohnt sich, kontinuierlich in den Unterhalt einer Plattform zu investieren, nur so kann diese längerfristig überleben.» Häufig würde in Betrieben initial stark für ein Realisierungsbudget gekämpft – in den Folgejahren werde das System jedoch vernachlässigt. «Eine Individualsoftware wird in den Betrieben häufig nicht wie ein Softwareprodukt gewartet, sondern wie ein One-Off-Projekt. Das führt langfristig zu Mehrkosten und neuen Projekten, in welchen alte, ungewartete Software dann generalüberholt oder komplett neu entwickelt werden.» Yoo empfehle deshalb, jährlich zwischen 10 und 20 Prozent des Initialbudgets für die kontinuierliche Weiterentwicklung zu reservieren.
Fehler vermeiden
Abschliessend wollten wir von den Softwareschmieden noch wissen, welche Fehler gemäss ihrer Erfahrung am häufigsten zum Scheitern eines Softwareprojektes führen. Hier werden in erster Linie drei Punkte genannt: Fehler bei der Definition der Anforderungen, zu grosse oder zu lange Projekte und last but not least Defizite in der Kommunikation.
Zum ersten Punkt erklärt etwa Daniel Gubler von Clavis: «Bei der Definition der Anforderungen besteht die Gefahr, dass zu viele vor allem irrelevante Anforderungen aufgenommen werden oder diese ungenau formuliert sind. Die Folge ist häufig eine Lösung, die den Funktionsumfang sprengt und den Benutzer überfordert oder dass die Lösung die Erwartungen nicht trifft.»
Zum zweiten Punkt rät Renato a Marca de Donatz von Löwenfels Partner, keine Monstervorhaben zu definieren. «Es ist wichtig, dass der Kunde und der Software-Partner die Komplexität des Gesamtprojektes und der Teilprojekte gemeinsam beurteilen und laufend überwachen. Unterstützend wirkt, ein Grossvorhaben in mehrere Etappen zu gliedern und eine agile Methode anzuwenden.» Nicolas Durville von Zühlke ergänzt hierzu: «Dauern Projekte zu lange und die involvierten Stakeholder haben den Anspruch, dass der erste Release fast schon perfekt sein muss, steht der Erfolg des Projekts auf der Kippe. Es ist zielführender, früh eine erste Version des Produktes zu lancieren, Feedback bei den Kunden und Nutzern einzuholen und das Produkt schrittweise weiterzuentwickeln.»
Und zum dritten Punkt – dem Faktor Kommunikation – nochmals Thomas Wüst von Ti&m: «Software-Entwicklung ist People Business. Insofern sind auch die Gründe eines Scheiterns selten in der Technik selbst zu finden. Meistens sind mangelnde Klarheit und Kommunikation der Ziele, mangelnder Einbezug der Endbenutzer und schlechte Fokussierung Ursache eines Scheiterns.» Agile Modelle würden diese Aspekte mit der Vermittlung von Wertehaltungen, hochfrequenten Iterationen und ständiger Priorisierung der Anforderungen adressieren. «Aber das allein ist auch noch keine Garantie für den Erfolg. Es braucht in jedem Projekt den oder die Leader, die die Ziele des Projektes verinnerlicht haben und mit Fachkompetenz und Engagement dem Rest des Teams vermitteln können.»
90 Prozent der Schweizer Unternehmen setzen auf die DevOps-Prinzipien
Wie es mit der Adaption von DevOps, also der Koordination und Kooperation von Software-Entwicklung und dem Betrieb der IT-Infrastruktur, in der Schweiz steht, wollte das Unternehmen VSHN im Rahmen einer breit angelegten Befragung herausfinden. Für die bereits zum zweiten Mal durchgeführte Studie wurden wiederum rund 250 Schweizer Unternehmen aller Grössen befragt.
Die Studie kommt zum Schluss, dass das DevOps-Konzept als wichtige Praxis fest in der Schweiz etabliert ist. So erklärten 44 Prozent der Studienteilnehmer, DevOps werde «voll und ganz» im Unternehmen verwendet und bei knapp 47 Prozent ist dies zumindest teilweise der Fall. Entsprechend gaben rund 54 Prozent an, Software-Entwicklung und IT-Betrieb würden im Betrieb zusammen strukturiert. Zum Vergleich: Im vergangenen Jahr lag der Wert mit 55,7 Prozent noch geringfügig höher. Deutlich stärker ist auch das Lager der DevOps-Kritiker geworden. So wird das DevOps-Konzept von vielen markant kritischer beurteilt als noch vor einem Jahr. Während bei der aktuellen Befragung knapp 79 Prozent DevOps als «eher positiv» betrachten, lag der Wert letztes Jahr noch fast bei 90 Prozent. Umgekehrt sehen heute über 14 Prozent der Umfrageteilnehmer DevOps als «eher kritisch», während dies letztes Jahr gerade einmal bei 2,8 Prozent der Befragten der Fall war.
Nichtdestortrotz ist die Erwartungshaltung hoch: Die Unternehmen versprechen sich von den DevOps-Prinzipien verkürzte Releasezyklen, höhere Flexibilität, eine verbesserte Zusammenarbeit sowie weniger Aufwand bei der Wartung. DevOps wird bei vielen Unternehmen mittlerweile auch als interne Kernkompetenz angesehen, doch wurde auch erkannt, dass DevOps nicht als Patentrezept betrachtet werden kann. Als Haupthindernisse für die Einführung von DevOps werden der Mangel an Fachwissen, Zeitmangel, die Komplexität der Organisation und mangelnde Unterstützung durch das Management identifiziert.
Was die bevorzugten Projektmanagement-Methoden anbelangt, steht Scrum mit rund 40 Prozent der Nennungen an der Spitze, gefolgt von Kanban (33%) und Wasserfall (15%). Bei den bevorzugten Programmiersprachen wird das Feld von Javascript mit gut 15 Prozent der Nennungen angeführt, gefolgt von SQL (13,9%) und Java (12%), wobei Java im Vorjahresvergleich einen Platz zurückgerutscht ist. Als beliebteste DevOps-Tools werden indessen Docker, Git und Kubernetes bezeichnet. Weiter erklärten 40 Prozent der Studienteilnehmer, die IT-Budgets würden im laufenden Jahr ansteigen, 2018 war dies noch bei gut 50 Prozent der Fall.
Marktübersicht Software-Entwickler aus der Schweiz
«Swiss IT Magazine» präsentiert in dieser
Marktübersicht eine Auswahl von 30 Schweizer Software-Entwicklungsunternehmen.
