Warum Top CIOs auf die Zusammenarbeit mit externen Softwareentwicklungs-Partnern setzen und worauf sie dabei achten.

7 Gründe, einen externen Softwareentwicklungs-Partner ins Boot zu holen:

1. Schnellere Time-to-Market, sofern der potentielle Entwicklungspartner nach Best Practice ausgerichtet ist und bereits sämtliche Tools, Methoden, etc. etabliert sind. In solchen Fällen ist ein Onboarding eines Projektes innerhalb weniger Tage möglich. Der Aufbau eines internen Teams inkl. der notwendigen Infrastruktur und organisatorischer Rahmenbedingungen würde realistisch betrachtet mindestens 9 bis 12 Monate in Anspruch nehmen.
2. Kostenersparnis, da die Kosten für den Personalaufbau und den Aufbau einer modernen state-of-the-art Test- und Entwicklungsumgebung wegfallen.
3. Laufender Know-how Transferdurch die Zusammenarbeit mit einem externen Expertenteam in Richtung eigenes Unternehmen.
4. Höhere Effektivität, wenn das externe Team bereits eingespielt ist und sich die einzelnen Entwickler nicht erst in einem Team “finden” müssen. Dieser Prozess dauert erfahrungsgemäß drei bis sechs Monate.
5. Technische und UX Excellence, weil diese nicht als verhandelbare Größen gelten und durch die Umsetzung einer Vielzahl von Projekten seitens eines externen Entwicklungspartners bereits nachhaltig etabliert sein sollten.
6. Experten im Bereich agiler Softwareentwicklung, da dies deren Kerngeschäft ist und daher davon ausgegangen werden kann (sollte allerdings im Einzelfall geprüft werden), dass sie die einschlägigen Methoden und Frameworks wie Scrum, Pair Programming, Extreme Programming, Test Driven Development, Domain Driven Design etc. umfassend beherrschen und nicht erst erlernt werden müssen.
7. Laufende Lieferung und 100%ige Transparenzdurch eine entsprechende auf CI/CD ausgerichtete Test- und Entwicklungsumgebung.

3 Optionen bei der Wahl eines Softwareentwicklungs-Partners:

1. Freelancer
   Der Einsatz von Freelancern ist ein probates Mittel, wenn es darum geht, kurzfristige Engpässe zu überbrücken. Auch für überschaubare, nicht zeitkritische Aufgaben eignet sich diese Option. Handelt es sich aber um größere, komplexere Softwareentwicklungsprojekte, die den Einsatz eines gesamten Teams erfordern, sollte man von dieser Alternative absehen.
2. Offshore & Nearshore
   Bei Offshore & Nearshore werden die Entwicklungstätigkeiten auf einem anderen Kontinent (z.B.: Indien) im Falle von Offshore und an das angrenzende Osteuropa im Falle von Nearshore aus der DACH Perspektive ausgelagert. Häufig wird dieses Modell dadurch ergänzt, dass ein Projektleiter eingesetzt wird, der die Koordination und Kommunikation zwischen dem Kunden und dem Entwicklungsteam übernimmt. Dieser soll etwaige Defizite hinsichtlich Sprache, Kultur, Zeitdifferenz etc. ausgleichen. An die Grenzen stößt dieses Vorgehen insbesondere dann, wenn die Entwicklung nach agilen Methoden oder Scrum durchgeführt werden soll. Beispielsweise ist laut Scrum keine Projektleitung oder “Übersetzungsfunktion” zwischen dem Product Owner des Kunden und dem Scrum Umsetzungsteam vorgesehen.
3. Onshore
   Einsatz eines langfristigen, in DACH angesiedelten Digitalisierungspartners im Bereich agiler Softwareentwicklung bzw. Individualsoftware, der das Unternehmen von der Idee zum fertigen Produkt inhaltlich wie technologisch begleitet und unterstützt.

1. Ist der Dienstleister in der Lage, Ende zu Ende (von der Idee bis zum Betrieb) zu unterstützen?
2. Was ist das Selbstverständnis des Dienstleisters? Proaktiver Digitalisierungspartner oder klassischer Auftragnehmer?
3. Ist das Unternehmen in der Lage, Best Practices in puncto agiler Softwareentwicklung einzubringen?
4. Entwickelt der Dienstleister tatsächlich nach agilen Methoden z. B.: Scrum inkl. der definierten Artefakte und Events?
5. Sind alle Entwickler Scrum zertifiziert?
6. Sind die Teammitglieder T-shaped?
7. Ist das Team cross-funktional?
8. Arbeitet das Team ausschließlich bzw. zu 100 % für diesen Kunden?
9. Welche Technologien bzw. Frameworks werden unterstützt?
10. Wird in Sprints von vier Wochen oder kürzer voll funktionsfähige Software geliefert (Stichwort: CI/CD)?
11. Steht eine vollautomatisierte Test- und Entwicklungsumgebung nach aktuellem Stand der Technik zur Verfügung?
12. Wie erfolgt das Wissensmanagement des Dienstleisters?
13. Bietet der Dienstleister 24×7 Transparenz hinsichtlich Entwicklungsfortschritt, Velocity etc. (Stichwort: Live Coding)?
14. Welche Garantien bzw. Möglichkeiten zum Vertragsausstieg bietet der Dienstleister?
15. Hat der Softwareentwicklungspartner seine Organisation nach dem agilen Manifest ausgerichtet?
16. Wie hoch ist die Wiederbeauftragungs- und Empfehlungsrate der Kunden des Dienstleisters?
17. Soll ein langfristiger Entwicklungspartner im Sinne von “software development as a service” oder ein Anbieter für die Umsetzung eines konkreten Projekts evaluiert werden?

Externe Software Entwickler können zumeist effizient einen neuen Code entwickeln und eigene Zielvorstellungen anreichern. Sie ersetzen nicht die eigene Kompetenz zu den aktuellen und künftigen Prozessen und sie brauchen eine kompetente Anlaufstelle im Unternehmen, um gut gesteuert zu werden.” Ali Aram, EY

Damit wir in unserer Gesellschaft, in unseren Schulen, in unseren Organisationen Nachhaltige Innovation findet nicht über Produktentwicklungen statt, Innovation ist wirklich nachhaltig, wenn die Firma in der Lage ist, kontinuierlich am eigenen Geschäftsmodell (und der eigenen Organisation) zu arbeiten. Teil dieses Geschäftsmodells sind auch die Partner mit denen man arbeitet. Wenn diese Softwarepartner bisher “nur” als Lieferant betrachtet worden sind, aus denen man die letzten paar Euro herausquetschen konnte und gleichzeitig aber Software zu einem immer wichtigeren Teil des zukünftigen Geschäftsmodells wird, wird das langfristig ein Problem werden.“ Eric-Jan Kaak, Spar ICS

Bei VERBUND arbeiten wir im Rahmen vieler Projekte mit Fremdfirmen zusammen – zwei Drittel unserer Softwarespezialisten sind extern. Die große Chance auf der einen Seite ist, schneller zu lernen und vom Wissen des Marktes zu profitieren. Externe Entwicklerinnen und Entwickler bringen neue Herangehensweisen sowie reiche Projekterfahrung mit und kurbeln so die Prozesse an. Auf der anderen Seite gibt es auch Knackpunkte: Auch IT-Profis benötigen in der Regel viel Zeit, bis sie das notwendige Verständnis für die Prozesse eines Unternehmens aufgebaut haben. Zudem besteht das Risiko, dass das Know-how wieder verschwindet, sobald die Zusammenarbeit endet.” Thomas Zapf, Verbund

Individualentwickler kommen bei jenen Prozessen zum Einsatz, die dem Unternehmen einen essenziellen Mehrwert bringen, einen USP für die Firma darstellen. Solche Entwicklungen sind oft komplex und erfordern Wissen über betriebsinterne Prozesse. Eine der großen Herausforderungen ist es dabei, dieses Wissen an Entwickler zu transferieren. Das dauert oft lange und ist von dem Risiko begleitet, dass der Entwickler, dem man das Know-how vermittelt hat, dann nicht mehr zur Verfügung steht (das kann intern aber natürlich auch passieren).

Man muss auch darauf achten, dass sich nach langer Zusammenarbeit kein „Schlendrian“ einschleicht, die Qualität sinkt, Entwicklungen nicht mehr so gut getestet werden, „weil man sich eh gut kennt” Gunther Glawar, EVVA

In der Regel verfügen externe Entwickler – weil zwingend notwendig – über State-of-Art Know-how, während die eigenen Entwickler oftmals NUR die eigene Landschaft teilweise kennen und sich oftmals über Jahre nicht weiterentwickelt haben. Insofern ist externes Know-How sehr befruchtend. Man muss aber darauf achten sich von externem Know-How nicht komplett abhängig zu machen und dieses wieder ins Unternehmen transportieren.” Nino Messaoud, Barry Wehmiller

Eigentlich sollten externe Entwickler eine gute Chance für jene sein, die keine Entwicklung mehr haben, denn sie können so Know-how wieder aufbauen ohne dabei abwarten zu müssen, bis das interne Team wieder steht.

Leider haben diese externen Entwickler oft fehlendes Industrie- bzw. Firmen Know-how, so zumindest im Fall von Burckhardt Compression, oft fehlt es ihnen selber noch an datennaher Programmierung, weil sie eben aus der Anwendungsentwicklung kommen und den eigenen Brain-Wash (Transition) noch nicht abgeschlossen haben oder aber diese Entwickler selbst an den Daten und den Analysemöglichkeiten interessiert sind und diese als eigene Services anbieten wollen. Amazon, Microsoft, SAP, PTC um nur einige zu nennen, wollen keine Programme abliefern, sondern selbst Zugang zu Daten bekommen.“

Helmut Draxler, Burckhardt Compression Group

Das Funktionieren der Zusammenarbeit mit externen Entwicklern hängt sehr häufig von den Einzelpersonen ab. Am besten funktioniert die Zusammenarbeit, wenn an beiden Seiten Verantwortliche das Geschäft des jeweils anderen auch verstehen und nachvollziehen können.” Susanne Tischmann, ÖAMTC

Externe Softwareentwickler und Partner dienen als Inkubatoren für neue Trends und Möglichkeiten, um unsere Portfolios weiterzuentwickeln. Im Gegensatz zur klassischen Produktentwicklung, bei der der Kunde unser Produkt erhält und das Produkt bis auf wenige Anpassung bis zum Lebensende praktisch unverändert im Einsatz hat, ist bei digitalen Produkten die permanente effiziente und stabile Weiterentwicklung gefragt. Nur so ist es möglich, mit der unglaublichen Innovationskraft und -geschwindigkeit, die im digitalen Umfeld herrscht, Schritt zu halten.” Klaus Glatz, Andritz

Mehr zum Thema finden Sie im neuen Software Transformation Factsheet 2021.

Für Sie KOSTENLOS zum Downloaden: