Eine Due Diligence ganz allgemein wird in der Regel anlassbezogen durchgeführt, Inhalt und Schwerpunkt der Analyse werden durch den jeweiligen Zweck konkretisiert. Das wichtigste Anwendungsgebiet einer Due Diligence ist die Vorbereitung von Unternehmensakquisitionen. Für den Verkauf von Unternehmen oder Unternehmensanteilen oder z. B. für die Durchführung einer Venture Capital Finanzierung ist eine Bewertung des Unternehmens die elementare Voraussetzung. Eine Software Due Diligence wird erforderlich, wenn in einem Unternehmen Softwareentwicklung einen signifikanten Anteil der Wertschöpfung darstellt. Da die Beurteilung des Vermögenswerts „Software“ nicht ohne einschlägige Expertise vorgenommen werden kann, werden im Rahmen einer Due Diligence seitens der Wirtschaftsfachleute weitere Spezialisten für die spezifischen Fachgebiete hinzugezogen. Auftraggeber für eine Software Due Diligence sind im anlassbezogenen Fall meistens Investoren oder Banken. Eine Due Diligence kann auch ohne konkreten Anlass auf freiwilliger Basis durchgeführt werden. Ein Unternehmen simuliert für sich intern einen bevorstehenden Akquise-Prozess und stellt sich testhalber den Anforderungen des M&A-Marktes. Die Due Diligence dient dabei dem Unternehmen zur eigenen Positionsbestimmung und hilft Stellen mit Verbesserungs- und Wertsteigerungspotenzial zu identifizieren, indem die Verantwortlichen sich temporär die Sicht eines externen Kaufinteressenten zu eigen machen. Regelmäßig durchgeführt können die im Rahmen der Analyse generierten Daten über den Ist-Zustand des Unternehmens als Eingangssignal für das Aufbauen eines Regelkreises verwendet werden. Eine Due Diligence als Führungsinstrument bzw. „Check-up“ einzusetzen ist eine sehr hilfreiche Anwendungsart. Im Falle der freiwilligen Begutachtung sind die Auftraggeber in der Regel die Inhaber der Unternehmen selbst oder die für die Entwicklung von Software verantwortlichen Führungskräfte.

Bei der Bewertung eines Unternehmens hat sich im Großen und Ganzen das sogenannte Ertragswertverfahren bewährt. Innerhalb der Berechnungsformel wird über den sogenannten „Betafaktor“ das unternehmensspezifische Risiko im Verhältnis zum Marktdurchschnitt abgebildet. Eine Vielzahl von Werttreibern verringert das Risiko für einen Investor, entsprechend kann der Wert des Unternehmens höher angesetzt werden. Können bei Analyse des Unternehmens jedoch zahlreiche Mängel und Schwachstellen identifiziert werden, wird in Relation zum Sanierungsbedarf der Wert des Unternehmens nach unten korrigiert. In einer Software Due Diligence werden die fünf Teilbereiche Mitarbeiter, Tools, Prozesse, Code und Anwendung einer sorgfältigen Analyse unterzogen. Der Bewerter versucht den Teilbereichen nach der Analyse jeweils einen spezifischen Risikofaktor zuzuordnen. Aus den einzelnen Risikofaktoren ist anschließend unter Berücksichtigung einer Gewichtung ein übergeordneter Risikofaktor zu berechnen, der als Betafaktor in die formale Berechnung mit einfließt. Das Gesamt-Risiko für die Berechnung des Ertragswertes bestimmt sich also durch die Summe der gewichteten Einzel-Risiken. Ein „durchschnittliches Risiko“ (= Betafaktor 1,0) wird einem durchschnittlich gut aufgestellten Softwareunternehmen zugeordnet, das solide agiert und dessen Software und Softwareentwicklung im Großen und Ganzen dem Stand der Technik in der Branche entsprechen. Die ganze Thematik der Bewertung von Software und Softwareunternehmen erläutere ich ausführlich in meinem Buch in Kapitel 2, „Wert der Software“.

Für die Durchführung einer Software Due Diligence verwende ich folgenden Ablaufplan:

Die benötigte Analysezeit hängt sowohl von der Komplexität der Anwendung mitsamt der dahinterliegenden Fachdomäne ab, als auch von der Größe des Entwicklerteams und dem Umfang des im Unternehmen vorhandenen Codes. In einem großen Team, das sich für Millionen Zeilen von Quellcode verantwortlich zeigt, erfordert der Prozessschritt der Detailanalyse deutlich mehr Zeit als z. B. in einem kleinen Startup, das erst vor 18 Monaten die Geschäftstätigkeit aufgenommen hat, entsprechend nur über eine begrenzte Personalstärke verfügt und noch nicht allzu viel selbst entwickelten Code auf den Festplatten gespeichert hat.