Make or Buy in der Softwareentwicklung
Make or Buy in der Softwareentwicklung
Laut der Computerwoche besteht nur in jedem vierten der befragten Unternehmen mehr als 20 Prozent der Softwarelandschaft aus Eigenentwicklungen. Auf die Frage: Warum sich Unternehmen überhaupt noch die Mühe machen lautete die Antwort, dass selbst-entwickelte Programme den Unternehmen helfen würden individuelle Prozesse Passgenau abzubilden. Dennoch sei die eigene Entwicklung immer weniger attraktiv geworden. Vor allem jedoch komplexe Eigenentwicklungen seien häufig teurer und risikoreicher als vergleichbare Standardsoftware.
Relativ einig hingehen sind sich die Befragten, und zwar immerhin jeder zweite Teilnehmer, wenn es darum geht Wettbewerbsdifferenzierende Prozesse abzubilden – diese seien fast immer Eigenentwicklungen die mit einem aufwändigen Customizing umgesetzt werden müssen, weil diese im Standard nicht enthalten sind. Da hat sich einiges getan, vor 9 Jahren (2008) sah das Ganze noch ganz anders aus, nämlich so:
“Die meisten (47 Prozent) der 1.200 befragten Firmen in Baden-Württemberg entwickeln Ihre Software lieber selbst, so das Ergebnis einer Studie des Zentrums für Europäische Wirtschaftsforschung demzufolge ist der Hauptgrund dafür (bei 78 Prozent der Befragten), dass passgenaue Lösungen Mangelware sind. Dicht gefolgt von dem Wunsch unabhängig von Anbietern bleiben zu wollen und dem Kostenfaktor der die interne Lösung als preislich attraktiver einstuft, als eine Fremdleistung. Nur sechs Prozent der Befragten gab an auf Externe zurück zu greifen.
Ist das Thema Make or Buy in der Softwareentwicklung damit endgültig durch? Unsere Realität sieht da noch ganz anders aus. Hier ein Einblick in eines unserer Best Practice Fälle.
Sind Sie bereit für den großen Make or Buy Showdown?
Die interne IT betritt die Bühne mit der Aussage: “Bis jetzt ging doch auch alles gut und nun brauchen wir eine kleine Verbesserung, die wir leicht auch selbst durchführen können. Außerdem kennen wir unsere Anforderungen/Prozesse so gut – und diese sind so einzigartig, dass ein Standard-Produkt diese gar nicht abbilden kann bzw. es keine vollständige Erfüllung geben wird. ” Meistens sorgt dieser Satz für Stille im Besprechungsraum. Er fällt nicht zum ersten Mal, viele Anwesenden wissen, das eine Argumentation schwierig wird, ein paar Wenige wagen eine Diskussion darüber, ein paar Andere nicken zustimmend und hoffen, dass es nicht allzu schief gehen wird ein paar Andere, häufig sind es Vertreter der Fachabteilungen, wünschen sich insgeheim ein “scheitern”, damit auch mal andere Lösungsansätze in Erwägung gezogen werden.
Die interne IT ist mächtig geworden in den letzten Jahren, Sie hat oft eine Stimme im Vorstand und viele Unternehmenslenker haben zu Recht verstanden, das es eine Zukunft ohne IT nicht geben wird. Welche Aufgaben diese wahrnimmt und wahrnehmen soll, ist allerdings häufig noch recht flexibel definiert, was häufig zu Reibereien zwischen IT und Fachbereichen führt. Am Ende des Tages geht es aber dennoch eigentlich immer um die Gretchenfrage Make or Buy in der Softwareentwicklung. Was macht mehr Sinn, was ist erfolgreicher. Die Antwort ist weder trivial noch einfach, da sehr viele Aspekte berücksichtigt werden müssen.
Ich versuche die Wichtigsten zu nennen – fordere Sie aber gleichzeitig dazu auf, aus Ihrer eigenen Situation heraus auch offen für andere ergänzende Argumente zu sein, falls Sie dieses Thema auf der Agenda haben sollten und dazu Ansatzpunkte sammeln.
Was sind gute Argumente für eine Buy Argumentation:
- die “kleine Verbesserung” ist im Vergleich sehr teuer/aufwendig
- die “kleinen Verbesserungen” sind nicht einmalig, sondern wiederkehrend und zwar in immer kürzer werdenden Zyklen. Ein Beispiel dafür: bisher wird mit “lokalen Excels” gearbeitet, nun wird nach einer Gruppen-Excel-Lösung gesucht (d.h. mehrere an einem Excel), damit muss es zentralisiert werden – vermeintlich eine Kleinigkeit, doch teuer und aufwendig.
- die nächsten Kleinigkeiten folgen sehr zeitnah, z.B. wenn Sie in den “zentralen Excels” bestimmte Bereiche für gewisse Nutzer schützen und/oder verbergen wollen
- usw.
Genau diese Anforderungen haben Standard-Lösung bereits gelöst und in ihre Produkte einfließen lassen.
Ihre Anforderungen & Prozesse sind nur für Sie “einzigartig”, weil Sie “in ihrer eigenen Suppe schwimmen”. Warum ich das so plakativ sage, ganz einfach, es würden sonst schlicht und einfach gar keine Standard-Lösungen auf dem Markt existieren. Ich versichere Ihnen viele mittelständische Familien- oder Inhaber geführte Unternehmen haben ähnliche Anforderungen. Eine PM-Lösung ist nicht Konzernen oder Börsenunternehmen vorbehalten – ganz im Gegenteil. Fast alle PM-Produkte sind aus Mittelstandsanforderungen entstanden.
Eine 100% ige Erfüllung wird es weder bei Eigenentwicklungen geben noch bei einem Standard-Produkt. Bei beiden ist es eine Kosten-Nutzen-Entscheidung.
Der Benefit einer Standard Software – so profitieren Sie davon
Standard-Software ist vielfach erprobt und bewährt. Es gibt tausende Anwender, ggf. weltweit Millionen, die diese Produkte täglich nutzen und damit “testen”. Die Qualität ist also um ein vielfaches höher und verlässlicher.
Hersteller folgen dem Markt und der Marktentwicklung eigenständig, d.h. Innovationen finden quasi “automatisch” den Weg ins Produkt, dazu muss nicht ein mittelständisches Unternehmen eine Entscheidung treffen und Geld dafür in die Hand nehmen. Innovationen sind ein wichtiges Gut in einer Software … siehe z.B. Betriebsystem-Updates, Office-Updates etc.. Ich glaube nicht, dass Sie einen IT-Leiter kenne der noch mit Office97 arbeiten wollen würde!
Eine Standardsoftware hilft dabei die eigene “Suppe” zumindest ein wenig zu verlassen – durch ein Standard-Produkt bekommt man eben über die Software auch Ideen, wie man bestimmte Probleme lösen kann – und wie diese bereits gelöst wurden (durch andere Kunden des Herstellers – Proof of Concept). Das stärkt am Ende den eigenen Prozess und damit das Unternehmen.
Durch die vielfache Erprobung und Verbesserung sind diese Produkte in der Regel einfach, verständlich und effizient, trotzdem sind die auch integrativ und offen.
Mit einem neuen Produkt erreicht man in der Regel einen Produktivitätssprung. Mit den vorhandenen Mitteln nähert man sich einer “Technologiegrenze” an. Um diese zu überspringen, muss man einen Technologiesprung wagen – wenn er gelingt, gibt es die Produktivitätssteigerung. Die Eigenentwicklung schafft das in der Regel nicht … sie verbessert ja nur die “alte Technologie”.
Was spricht für die Eigenentwicklung?
Wenn sich Ihr Unternehmen oder die IT-Abteilung in seiner strategischen Entwicklung dazu entschieden hat selbst ein PM-Software Anbieter werden zu wollen, dann sollten sie dieses erste Projekt dazu nutzen um Expertenwissen aufzubauen.
Oder aber ihre IT Abteilung benötigt ein weiteres/zusätzliches Aufgabengebiet, weil sie personell sehr gut aufgestellt sind, die Mitarbeiter freie Kapazitäten haben und deshalb “zusätzliche” Aufgaben benötigt werden.
Sollte dies die Zielsetzung sein, will ich Ihnen auch an dieser Stelle nicht vorenthalten, was auf Sie zukommen wird.
Was kommt bei einer Eigenlösung auf Sie zu?
Wir reden bei einer PM-Lösung nicht über ein kleines Tool, das mal ein Paar Termine und Aufwände verwaltet. Die Tool-Hersteller haben in der Regel 20-100 Entwicklungsmitarbeiter bei einer Unternehmensgröße von 60-300 Mitarbeitern, die sich ausschließlich mit diesem Produkt beschäftigen – das ist keine “Freizeit-Beschäftigung”. An eine Eigenlösung werden genauso intern Ansprüche gestellt wie an eine Standard-Software.
Das bedeutet, es muss dauerhaft Entwickler-Potential vorgehalten werden, das erreichte Wissen muss konserviert werden, für den Fall das ein Entwickler das Unternehmen verlässt.
Vergessen Sie dabei nicht das Thema Support – Jemand muss die Verantwortung übernehmen, dass das alles gut, korrekt und fehlerfrei funktioniert.
Wer trägt die Verantwortung für den Fall das die Eigenlösung die Innovationskraft des Unternehmens minimiert und sich dadurch ein Wettbewerbsnachteil ergibt?
Fazit: Make or Buy in der Softwareentwicklung
Bei unseren Kundenprojekten haben wir am Anfang immer den Eindruck das Projektmanagement ein ausschließlich internes Thema sei – woraus nicht selten die Idee und die Motivation entsteht es “oberflächlich” lösen zu können. Wir empfehlen deshalb immer den Inhalt der Projekte zu analysieren – diese sind nicht selten unternehmenskritisch und machen das Unternehmen zu dem was es ist und definieren die Marktstellung. Hinterfragen Sie also kritisch, wer die Entscheidung trägt wenn diese Marktrelevanz durch eine “falsche” Entscheidung aufs Spiel gesetzt werden sollte.
Letztendlich sind es erhebliche Unternehmensrisiken, die bewertet werden sollten und verantwortet werden müssen! Vergessen Sie dabei nicht die Gewährleistung und die Weiterentwicklung sowie den Betrieb der “Eigenleistung”.
Jedes Unternehmen verfügt über Kernkompetenzen oder spezielles Fertigungs-KnowHow – dieses Können hat das Unternehmen dort hin gebracht wo es Heute steht.
Unternehmen sind keine Inseln, nahezu alle haben Zulieferer oder Dienstleister für gewisse Anforderungen. Wie oft hat Ihr Management schon darüber nachgedacht das alles selbst zu machen und komplett auf “Zuarbeit” zu verzichten. Ich vermute mal nicht ganz so häufig. Und ich bin mal mutig und sage, das ist deshalb nicht passiert, weil diese in ihren jeweiligen Bereichen einen besseren Job machen, als sie es mit einem vernünftigen Aufwand selbst tun könnten! Da stellt sich doch zu Recht die Frage, warum es bei der Entwicklung einer Software doch noch so viele Graunuancen gibt.
Deshalb meine Bitte – seien Sie kritisch mit sich selbst, wenn Sie kein PM-Software-Experte sind, und ihr KnowHow nicht in Bereichen investieren/aufbauen wollen, die nicht zu den Kernkompetenzen ihres Unternehmen zählen – spricht das Unternehmen Geld damit verdienen kann! In diesem Falle lassen Sie das Andere machen, die alle vorherigen Fragen mit einem klaren Ja beantworten konnten.
Und zu guter Letzt empfehle ich Ihnen auch auf die Eigenentwicklung das Lasten- bzw. Pflichtenheft Schema anzuwenden, wie für die Standardsoftware Auswahlprodukte. Die Anforderungen sind im Lastenheft beschrieben und am Ende kann für die Eigenentwicklung ebenso ein Entwicklungspreis und eine Entwicklungsdauer beziffert werden – die man in Bezug zum Anschaffungspreis und der Implementierungsdauer ansetzen kann. Und selbstverständlich können auch für eine “Eigenlösung” Unterhaltskosten beziffert werden.
Und schlussendlich gibt es aus Sicht des Unternehmenscontrollings noch einen kleinen, wenn auch nicht ganz unerheblichen Hacken – der als Pro-Buy-Argument dient. Eine Software zu erwerben, also Lizenzen zu kaufen, steigert aus Buchhaltungssicht den Unternehmenswert, da Lizenzkäufe Investitionen sind, theoretisch könnte man diese ja am Markt wieder verkaufen – eine Eigenentwicklung kann man quasi bei Gebrauchsende nur noch wegwerfen. Die Investition ist quasi verloren.
zu guter Letzt
Ich habe diesen Beitrag mit Umfragen begonnen, es ist also nur konsequent ihn auch mit einer zu beenden – eine die in die Zukunft blickt … und Interessantes sieht. Da liegen wir doch gar nicht so falsch mit unserer Empfehlung.
In einer Studie von Capgemeni zum Thema IT- Trends, kommen 51,7 Prozent der Befragten zu dem Schluss, das in 10 Jahren die IT Abteilung zentral organisiert sein wird, und nahezu alle Leistungen von Extern eingekauft werden. Lediglich 29,3 Prozent glauben, dass die IT Abteilung in Zukunft zentral organisiert sein wird, und alle Leistungen selbst erbringen wird.
Genug für Heute!
Mehr Unterstützung gewünscht? ProjectPlant begleitet Sie gerne bei folgenden Fragestellungen:
IT- und Prozessberatung, Software Engineering, Service & Support oder mit best practice Schulungen.
Schreibe einen Kommentar