Um beim Einkauf von Individualsoftware bessere Verträge für eine bessere Software abzuschließen, sind ein Umdenken und neue Werkzeuge im Einkauf nötig.
Das Vaadin Entwicklungsteam hat in den letzten beiden Jahren große messbare Anstrengungen unternommen, die interne Architektur-Qualität des Vaadin Flow Webframeworks zu verbessern. Der Fokus auf Qualitätsverbesserungen statt alleiniger Feature-Neuentwicklung hat sich bezahlt gemacht. Der steigende Wartungsaufwand zur Beseitigung neuer Bugs konnte im Jahr 2021 reduziert und 2022 konstant gehalten werden.
Es gibt immer mehr Produkte oder auch Geschäftsmodelle, deren Erfolg von eigens dafür entwickelter Software abhängt. Nur wenige Unternehmen können diese Software vollständig selbst entwickeln und müssen deshalb mit externen Software-Entwicklungsdienstleistern zusammenarbeiten. Die Beschaffung solcher durch einen Partner individuell entwickelter Software ist für den verantwortlichen Einkäufer komplex und erfordert entsprechende Erfahrungen.
Die Herausforderungen in der Beschaffung werden nicht nur von der Komplexität der Software selbst, sondern auch vom vorgesehenen Anwendungsfall bestimmt. Besonderes Augenmerk verdient dabei sowohl die gesamte Entwicklungsdauer des Produktes, in dem die Software eingesetzt werden soll, als auch dessen Nutzungsdauer. Wird die Software beispielsweise zur Steuerung in Fahrzeugen, Flugzeugen oder Anlagen eingesetzt, ist man für Jahrzehnte an den Software-Entwicklungspartner gebunden. Die potentiellen Dienstleister, die auf der Einkaufsshortlist stehen, kann man deshalb nicht nur nach Preis oder TCO auswählen. Weitere Kriterien müssen herangezogen werden, um Auskunft darüber zu geben, ob diese Dienstleister auch noch nach Jahren die richtigen Partner sein könnten.
Deshalb empfehlen wir bei der Qualifikation der Entwicklungsdienstleistern und während der anschließenden Entwicklung u.a. folgende Maßnahmen:
Bei diesen Maßnahmen sollen u.a. folgende Technologie-fokussierte Fragen* gestellt werden:
| An die Fachbereiche (Einkauf, R&D, QM) | An den Entwicklungsdienstleister |
|
Ist das nötige Wissen vorhanden, um den Softwaredienstleister zu auditieren und um dessen Arbeitsfortschritt zu kontrollieren? Nach welchen Kriterien werden gelieferte Versionen der Software geprüft? |
Gewähren die Abrechnungsmodelle eine Aufwandstransparanz während der Entwicklung und im Lifecycle? Ist die Technologie der gelieferten Software so beschaffen, dass sie über die Produktlebensdauer zu normalen Kosten weiterentwickelt werden kann? |
| Stehen State of the Art Tools (bzw. Partner) zur Verfügung, um die Softwarequalität bereits im Entwicklungsprozess und bei der Abnahme nachzuweisen? |
Liegen Erfahrungen vor, um langjährige Softwareentwicklungen erfolgreich mit der dazugehörigen Produktentwicklung (des Auftraggebers) zu synchronisieren? Liegen Erfahrungen vor, um Individual-Software über sehr lange Zeiträume weiterzuentwickeln und zu warten? |
|
Was sind die technologischen KPIs beim Fortschrittsmonitoring und bei der Abnahme der jeweiligen Iteration? Wurden diese KPIs als Qualitäts- und Abnahmekriterien im Vertrag aufgenommen? |
Liegt die Bereitschaft vor, sich bereits in der Entwicklungsphase monitoren zu lassen? Beispiele: Trend der technischen Schulden, Vollständigkeit der Dokumentation + Nachvollziehbarkeit des Codes, Status der Cloud Readiness). |
| Wie ist sichergestellt, dass über die lange Entwicklungszeit bei Änderungen der Anforderungen nur berechtigte Nachforderungen seitens des Dienstleisters erhoben werden? |
Wie ist der Zugang zur Technologie und den erzeugten Entwicklungsmaterialien (z.B. Issue Tracker, Code-Histories, Dokumentation) im Falle eines Ausfalls von Entwicklern oder der Entwicklungssysteme gewährleistet? |
Tabelle 1: Fragen-Checkliste
* Diese Fragen sind speziell für die technische Prüfung der Lieferanten und dessen Lieferungen gedacht. Selbstverständlich sollten auch die weiteren üblichen Kriterien einer Lieferantenqualifizierung (Bonität, Referenzen, Kosten, Bedingungen) geprüft werden.
Das nachfolgende Bild zeigt, dass die Mindestvoraussetzung für einen erfolgreiche Beschaffung die gute Zusammenarbeit der internen Stakeholder (Einkauf, R&D und QM) ist, die vom Einkauf synchronisiert werden sollte. Um die Qualität der Software Iterationen während der Entwicklung wirklich kompetent beurteilen zu können, müssen auf der Abnehmerseite frühestmöglich auch Software-Analysetools wie DETANGLE von Cape of Good Code eingesetzt werden.
Abb. 1: Individualsoftware ist ein fluides Produkt mit volatilen Anforderungen. Der Einkauf benötigt bei Software-Dienstleistern neue ganzheitliche Konzepte für den gesamten Lieferanten-Lifecycle
Als abschließenden Hinweis auf neue Kriterien beim Einkauf von Individualsoftware empfehlen wir, regelmäßig mögliche Abhängigkeiten von einzelnen Entwicklern zu prüfen. Ein Ausfall oder Abgang von Entwicklern mit Schlüsselkompetenz ist nicht einfach zu kompensieren und könnte das komplette Entwicklungsprojekt gefährden, zumindest aber erheblich verzögern.
Der Dienstleister wird das aber meist erst offenbaren, wenn es schon zu spät ist. Diese Abhängigkeiten können durch regelmäßige Scans der Code-Historie mit unserer Software Analyse Suite DETANGLE aufgedeckt werden und ermöglichen ein proaktives Risikomanagement.
Jeder Beteiligte in der Lieferkette für die Entwicklung einer Individualsoftware sollte sich darüber im Klaren sein, dass eine fehlerbehaftete Software katastrophale Auswirkungen auf Ihr Unternehmen, Ihre Kunden und auch auf die Nutzer von deren Produkten haben kann. Nur ein höchstes Maß an Sorgfalt während des gesamten Software-Lebenszyklus kann dieses Risiko minimieren. Die professionelle Auswahl des richtigen Entwicklungspartners mit Einsatz von State-of-the-Art Methoden und Kriterien ist Teil dieser Verantwortung.
1. Blog-Bild
Volatile Produktvorgaben beim Einkauf erfordern, dass die Code-Architektur zukunftsfähig bleibt. Neue Abnahmekriterien und Qualitätsmetriken sind...
Anhand eines modifizierten PDCA Zyklus gehen wir darauf ein, was der Einkauf im Rahmen der kontinuierlichen Lieferantenanalyse tun kann und tun...
Git Squash Merge hilft nicht wirklich, saubere Commit-Historien zu erstellen. Es ist nur eine Krücke, um eine sinnvolle Commit-Aufteilung zu umgehen.