Technical Due Diligence

Immer öfters umfasst eine Technical Due Diligence eine Prüfung und Bewertung mit klaren Aussagen zur Zukunftsfähigkeit und Skalierbarkeit von Software Assets und der Digital Readiness der Software Prozesse.

Sie wollen ein Unternehmen kaufen, dessen Wertschöpfung in hohem Maße abhängig von umfangreicher und individualisierter Software ist? Sie wollen ein Unternehmen kaufen, dessen Produkt Software ist? Sie wollen in beiden Fällen davon ausgehen, dass deren Anwendung und Weiterentwicklung nahtlos und im normalen Kostenrahmen möglich ist?

Sie suchen nach einer objektiven und verlässlichen Evaluierung der Qualität der Software und deren technologischen Zukunftsfähigkeit? Es interessiert Sie, ob die Entwickler State-of-the-Methoden und eine adäquate Dokumentation entwickelt haben? Sie wollen wissen, wer die relevanten Entwickler der Software sind, damit sie in der Verhandlung sicherstellen können, dass sie Teil des Deals sind? Wenn Sie das alles wissen wollen, dann sind wir und unsere DETANGLE® Software Analysis Suite der richtige Partner.

Eine Technical Software Due Diligence mit DETANGLE® zeigt in der M&A Transaktion frühzeitig die Chancen und Risiken für den Investor auf. Die DETANGLE® Suite ist sowohl für Zielunternehmen, die intensiv individualisierte Software für ihre Wertschöpfung einsetzen, als auch für Unternehmen bei denen Software das Produkt ist, als Due Diligence Software einsetzbar. Während es bei einem Softwareunternehmen selbstverständlich ist, das Produkt Software im Rahmen einer Due Diligence zu untersuchen, so ist es noch recht unüblich die im Geschäftsbetrieb eingesetzten Applikationen in einer Due Diligence als Asset zu bewerten.

Software Due Diligence geht über eine IT Due Diligence hinaus, ist aber kein Ersatz dafür. Beide sollten parallel als Teil einer Technical Due Diligence durchgeführt werden.


Kontaktieren Sie uns für weitere Information zu unserer Software Due Diligence. Kontaktieren Sie unseren Partner Gambit GmbH zu deren IT Due Diligence Angebot.


Was unterscheidet DETANGLE® von anderen Code Analyse Werkzeugen?

Mit der DETANGLE® Software Analysis Suite analysieren wir die Software direkt im Code. Dabei werden Entwicklungshistorie, Wartbarkeit und Erweiterbarkeit mit den den Bugs und den Features der Software korreliert. Dadurch wird es möglich, das eingepreiste Potential der Software mit der technischen und organisatorischen Realität der Software zu verknüpfen. Die Ergebnisse der Detangle® Analyse werden durch erfahrene Spezialisten interpretiert, und im Software Due Diligence Report nachvollziehbar dargestellt. Damit gewinnt ein Investor neue Einsichten für seine Kaufentscheidung und dessen Nachhaltigkeit.

Wir

  • zeigen, wie weit das Software Engineering bereits für digitale Geschäftsmodelle vorbereitet ist oder vorbereitet werden kann
  • messen, wie weit die Weiterentwicklung um neue Funktionalitäten ohne einen kostenintensiven Neuanfang oder signifikantem Mehraufwand gewährleistet ist
  • identifizieren die Key Player der Softwareentwicklung und stellen fest, welche Wissensträger Teil der M&A Transaktion sein sollten
  • beurteilen, ob der Software Engineering Prozess den Anforderungen einer agilen Entwicklungsmethodik und der Qualitätssicherung entspricht
  • beurteilen, ob die Dokumentation der Software ausreichend ist, oder identifizieren und priorisieren die Lücken in der Dokumentation.

Kontaktieren Sie uns, um die notwendige Entscheidungssicherheit für eine zukunftssichere Akquisition zu erlangen.


Key take-aways einer Software Due Diligence programs mit DETANGLE® :

  • Effiziente und minimal invasive Messung der entscheidenden Software Qualitätskriterien zur Wartbarkeit und Erweiterbarkeit der Software Assets basierend auf den Aufwänden und der Qualität der Features im Code statt einer reinen Codequalitätsanalyse
  • Daten-basierte Abschätzung der notwendigen Investitionen und Prognose der zu erwartenden Wartungsaufwände durch die versteckten technischen Schulden der Software Assets
  • Zuverlässige Identifikation der Know-how Träger im Softwareentwicklungsprozess und der angemessenen Verteilung des notwendigen Wissens im Team
  • Validierung der Digital Readiness der Softwareentwicklung und Software Prozesse
  • Interview-basierte Bewertung der Technical Trend Readiness der Software Assets durch erfahrene Software Experten
  • Abgleich der Ziele des Investors mit den technologischen Möglichkeiten der Software Produkte des Targets
  • Verifizierung, ob die anvisierte Entwicklung eines Unternehmens durch die Skalierbarkeit der individuellen und erfolgsrelevanten Applikationen überhaupt möglich ist.

Warum Software Due Diligence?

“In short, Software is eating the world” (Marc Andreessen)

Die Bedeutung von Software für den Unternehmenserfolg wird in einer zunehmend digitalisierten Geschäftswelt immer größer – Software ist das Rückgrat der Digitalisierung. Damit werden auch die Software Assets in M&A Transaktionen immer bewertungsrelevanter. für den Investor. Der Scope einer Due Diligence erweitert sich entsprechend, sowohl um die intensivierte Prüfung der selbst genutzten Business-IT Anwendungen, als auch um die ggfs. hergestellten Software-Produkten. Durch die hohe technologische Dynamik bei den Software Assets ist es wichtig festzustellen, ob die Architektur so konzipiert ist, dass sie den aktuellen technologischen Trends folgen kann und um Erweiterungen oder neue Features ergänzt werden kann.

Für den Investor in Software- oder in hochautomatisierte Unternehmen sollten folgende Aspekte bei der Prüfung des Zielunternehmens von besonderem Interesse sein:

  • die Wartbarkeit der Software für einen weitgehend störfreien weiteren Betrieb
  • die Erweiterbarkeit der Software um neue Features und Funktionalitäten
  • die Interoperabilität und Integrationsfähigkeit der Software-Assets in die eigene Software Produktpalette
  • die Future Readiness der Software bezüglich Skalierbarkeit, Performance und dem Einsatz aktueller Technologien (z.B. Cloud).

 

Eine Software muss so offen gestaltet sein, dass sie morgen um Antworten erweitert werden kann, deren Fragen heute noch nicht gestellt wurden.

Ein weiterer, oftmals vernachlässigter Aspekt in einer Software Due Diligence sind die Software Development Prozesse. Dabei ist es aus Due Diligence Sicht unwichtig, ob es sich um ein Softwareunternehmen oder ein Unternehmen mit hoch individueller Software in seinen Betriebsprozessen handelt. Relevante Fragen für den Software Development Prozess sind hierbei:

  • Werden Requirements, Features, Bugs strukturiert aufgenommen, geplant und deren Code-Änderungen erfasst?
  • Kann ein neuer Versionsstand technisch in kürzester Zeit erstellt, getestet und ausgerollt werden?
  • Kann jeder Versionsstand technisch bezüglich der geplanten und tatsächlich ausgerollten Features transparent nachverfolgt werden?
  • Wie weit ist der Benutzer in den Fehlererfassungssprozess integriert, um eine zeitnahe und umfassende Berichterstattung des Fehlers zu gewährleisten?
  • Wie weit sind Update und Upgrade-Mechanismen in der Software automatisiert?

Nur beide Untersuchungsfelder, Technologie und Development Prozess, zusammen ergeben einen adäquaten Eindruck, wie es um die Digital Readiness des Targets steht.

Zudem ändern digitale Geschäftsmodelle den Anspruch an die Softwareentwicklung grundlegend. Es geht nicht mehr nur um Optimieren oder Stabilisieren, es geht darum zu Innovieren. Neue Features und Funktionalitäten bedürfen deshalb einer Experimentierphase auf Technischer- und auf Benutzerebene bevor sie ein integraler Teil der Software werden. Durch die Dynamik der Veränderungsansprüche an Software und die dadurch erforderlichen immer kürzeren Releasezyklen, muss der Aufwand in diesen Phasen begrenzt werden. Die Benutzerakzeptanz sollten frühzeitig und kontinuierlich getestet werden und das wichtigste Freigabekriterium werden. Hat das Feature eine hohe Nutzungs- und Akzeptanzrate und Potential das Softwareprodukt leistungsfähiger, stabiler und/oder nutzerfreundlicher zu machen, muss Mehraufwand erbracht werden, um den Code und dessen Dokumentation in eine serienreife Qualität zu bringen. In der Praxis jedoch, wird die Interaktion von Innovation und Kundennutzen in der Softwareentwicklung zu wenig genutzt.

Fragen Sie uns nach unserem Angebot

Sie interessieren sich für eine Software Due Diligence mit DETANGLE®? Für ein Angebot für Sie und Ihr Software Produkt benötigen wir folgende Angaben:

  • Art und Anzahl eingesetzter Ticketing-Systeme
  • Art und Anzahl eingesetzter Repository-Systeme
  • Code-Umfang (Anzahl der Code-Zeilen)
  • Alter des Codes in Jahren
  • Anzahl der Entwickler

Kontaktieren Sie uns zur Klärung von Fragen oder zur Durchsprache weiterer Einzelheiten.


 

Einzigartiger Ansatz zur Software Due Diligence

Geschäftsrelevante technische Schulden transparent machen

Professor M. M. Lehman vom MIT hat sieben erfahrungsbasierte “Gesetze” des Software Engineering aufgestellt, die heute noch Bestand haben. Zwei davon lauten wie folgt:

«A system must be continually adapted or else it becomes
progressively less capable of satisfying its users.»

«The quality of a system will decline unless it is rigorously
maintained and adapted»

Lehman’s laws

Das heißt, dass eine Vernachlässigung der Softwarequalität zu immer höheren Entwicklungskosten in Form technischer Schulden führt. Unsere Software Due Diligence schafft Transparenz bezüglich dieser technischen Schulden und gibt Antworten zu folgenden Fragen:

  • Wie weit wirken sich technische Schulden bereits auf die aktuellen Wartungsaufwände der Software aus?
  • Welche technischen Schulden müssen abgebaut werden, um die Entwicklung neuer Funktionalität im normalen Kostenrahmen sicherzustellen?
  • Was sind die notwendigen Investitionen, um die geschäftsrelevanten technischen Schulden abzutragen?

Aktuelle Methoden der Code-Qualitätsanalyse weisen jedoch folgende Limitierungen auf:

  • Der Fokus der Qualitätsanalyse liegt allein auf Code, d.h. es wird allein eine entwickler-zentrische Perspektive abgedeckt
  • Es gibt zu viele undifferenzierte und oftmals irrelevante Findings. Bereiche des Codes, der über einen längeren Zeitraum nicht geändert wurde müssen beispielsweise nicht zwingend verbessert werden
  • Ein effektiver Einsatz des begrenzten Qualitätsbudgets zur Verbesserung ist nicht gewährleistet, um die Erweiterbarkeit um neue Features zu erhöhen.

Unsere DETANGLE® Analyse und Prognose liefert erfolgskritische Daten auf der geschäftsrelevanten Grundlage der Produktfeatures (deren Entwicklungsaufwand, Fehlerdichte und Qualität im Code) statt reiner Codeanalysen oder subjektiver Schätzungen der Entwickler, Manager und Kunden. Zum Beispiel werden Features mit geringer Nutzung aber hohem Entwicklungsaufwand schnell erkannt. Eine DETANGLE® Analyse betrachtet die Historie des Codes im Code-Repository und korreliert diese mit Bugs und Features, um zu geschäftsrelevanten Aussagen über die technischen Schulden zu kommen.

Die KPIs des Software Developments und des Software Managements beschränken sich aktuell oftmals immer noch auf das Budget und die Zeit zur Erstellung des Codes und eventuell noch auf die Qualität des Codes.

Oftmals findet dadurch noch eine strikte Trennung des Software Developments von den Zielen und Tätigkeiten des Business Developments statt. Stattdessen müssen Software- und Business Development zur Entwicklung neuer Features und Funktionalität und der Gewährleistung der Code-Qualität entlang eines Schichtenmodells der Produktfeatures integriert werden.

Digital Readiness des Software Developments beurteilen

“ … research shows that 80-90% of all R&D effort is allocated to commodity functionality. This means that out of every 10 people in R&D, 8 or 9 work on functionality that no customer cares about.” (Jan Bosch)

Professor Jan Bosch hat für das Software Development im digitalen Zeitalter der Plattformen und Ökosysteme folgendes Drei-Schichten-Produktmodell entwickelt:

Die Features eines Softwareproduktes sind drei Schichten zuzuordnen: der Experimentier-, der Differenzierungs- und der Commodity-Schicht.

  • Softwareprodukte sind “never-ending” Produkte. Es müssen fortlaufend neu, innovative Features mit Experimenten erprobt werden. Erstmal ist es ungewiss, welche Features beim Benutzer gut ankommen und ausgiebig genutzt werden.
  • Softwareprodukte haben immer kürzere Release-Zyklen. Jedes Release muss neue differenzierende Features bieten, die gegenüber der Konkurrenz einen Wettbewerbsvorteil darstellen.
  • Basis- bzw. Pflicht-Features werden von die Kunden als gegeben voraussetzt und werden von der Konkurrenz genauso angeboten.

Daraus zieht Professor Jan Bosch folgendes Schlüsse für das Software Development:

  • der Aufwand im Commodity Bereich soll sich maximal auf ca. 20% belaufen. Am besten man deckt diesen Bereich per Software Zulieferung durch Third Parties ab
  • der höchste Aufwand und eine sehr gute Qualität soll es für differenzierende Features geben
  • es sollen 10-20% des Aufwands für Experimente mit neuen Features oder Erweiterungen aufgebracht werden.

Unsere Software Due Diligence beurteilt die Digital Readiness des Software Developments anhand folgender Fragen:

  • Wie weit findet ein Controlling und Qualitätsmanagement basierend auf Features statt? Kann der Aufwand und die Qualität experimenteller versus differenzierender Features gemessen werden?
    • experimentelle Feature können durchaus “quick and dirty” umgesetzt werden
    • differenzierende Features dürfen einen hohen Aufwand erfordern und müssen wartbar und erweiterbar mit hoher Qualität im Code umgesetzt werden.
  • Wird die Nutzungsrate von Features gemessen, um ein effektives Change Management zu etablieren?
  • Wie gut ist die technische Infrastruktur, um eine zügige Auslieferung neuer Features und neuer Versionsstände zu bewerkstelligen?

Knowledge Risks identifizieren

Ein weiterer Schwerpunkt unserer Software Due Diligence liegt auf der Untersuchung der Risiken in der Wissensverteilung zur Erstellung der Software:

  • Wer sind die Key People bei der Erstellung des Codes?
  • Wie gut ist die Wissensverteilung im Entwicklungsteam bezogen auf den Code?
  • Wie gut ist die Codebasis dokumentiert, um eventuelle Abgänge von Entwicklern zu verkraften und die Einarbeitung neuer Entwickler zu erleichtern?

Future Readiness der Software Assets evaluieren

Zusätzlich führen wir Interviews, um auch Fragen zur Zukunftsfähigkeit der Software Assets zu klären:

  • Wie sieht die Skalierbarkeit und Performance der Software im Hinblick auf neue Kunden, Marktsegmente, Markttrends aus?
  • Ist ein Down/Up-sizing für neue Marktsegmente möglich?
  • Was ist der aktuelle Stand an verwendeter Software-Technologien? Wie weit ist ein Übergang oder eine Integration neuer Technologien möglich?