Technical Due Diligence Schweiz: Checkliste für den Verkauf eines Industrie-KMU

Ein strategischer Käufer interessiert sich für Ihr Industrie-KMU. Die Geschäftsleitung kann Produkte und Maschinenpark erklären – doch wer zeigt, welche Software den Betrieb trägt, wem die Rechte daran zustehen und welche technischen Risiken bereits bekannt sind? Wenn diese Antworten erst während der Prüfung zusammengesucht werden, kostet das Zeit und erschwert die Einordnung offener Punkte.

Für die technical due diligence schweiz brauchen Sie keine perfekte IT-Landschaft. Sie brauchen eine nachvollziehbare Darstellung des Ist-Zustands, belastbare Belege und eine verantwortliche Person für Rückfragen. Das folgende Szenario ist eine Annahme und beschreibt keinen Remoteplatz-Kunden: Ein Schweizer Industrie-KMU ordnet vor dem geplanten Verkauf an einen strategischen Käufer seine technischen Unterlagen. Dieser Beitrag zeigt, wie Sie den Prüfungsumfang festlegen, Dokumente und IP-Nachweise strukturieren und Risiken offen, aber kontrolliert aufbereiten.

Technical Due Diligence Schweiz: Was muss vor der Käuferprüfung klar sein?

Beginnen Sie nicht mit dem Hochladen aller vorhandenen Dateien. Klären Sie zuerst, welche Technik für Umsatz, Produktion, Lieferfähigkeit und den Betrieb nach einer Übernahme wesentlich ist. Bei einem Industrie-KMU können dazu ERP, Produktionsanbindungen, kundenspezifische Software, Produktdaten, Cloud-Dienste und die Systeme für Support oder Wartung gehören. Entscheidend ist nicht die Anzahl der Systeme, sondern ihre Bedeutung für das Geschäft.

• Prüfungsumfang: Listen Sie geschäftskritische Systeme und Schnittstellen mit Zweck, zuständiger Person und Abhängigkeiten auf. Trennen Sie Eigenentwicklungen von zugekauften Lösungen und Leistungen Dritter.
• Verantwortung: Benennen Sie eine technische Ansprechperson, die Aussagen mit Fachbereichen und Geschäftsleitung abstimmt. Die CFO-Funktion koordiniert den Datenraum; die technische Führung verantwortet die fachliche Einordnung.
• Grenzen der Aussage: Kennzeichnen Sie, was dokumentiert und geprüft ist, was auf Einschätzungen beruht und wo Belege fehlen. Ein fehlender Nachweis ist kein bestätigter Mangel, aber eine offene Frage.

Falls keine interne technische Führung den Überblick hat, kann ein Fractional CTO für Architektur-Reviews und technische Due Diligence die Bestandsaufnahme und die Kommunikation mit der Geschäftsleitung unterstützen. Die rechtliche Bewertung von Verträgen bleibt davon getrennt.

Welche Unterlagen gehören in eine technische Due-Diligence-Checkliste?

Ordnen Sie den Datenraum nach Fragen, die ein Käufer nachvollziehen können muss – nicht nach der bestehenden Ordnerstruktur Ihrer IT. Eine knappe Übersicht pro Prüfbereich hilft mehr als ein unkommentierter Export. Verweisen Sie jeweils auf den aktuellen Beleg, die verantwortliche Person und den Stand der Prüfung.

• Systeme und Architektur: Übersicht der Anwendungen, Betreiber:innen, Hosting-Umgebungen, Datenflüsse und wesentlichen Schnittstellen. Zeigen Sie insbesondere, wo ERP und Produktion voneinander abhängen; für diese Abgrenzung ist auch der Beitrag zur Führung bei der ERP-Modernisierung relevant.
• Betrieb und Sicherheit: Zuständigkeiten für Zugriffe, Änderungen, Backups, Wiederherstellung und Störungen. Halten Sie vorhandene Nachweise und zuletzt festgestellte Lücken getrennt fest, statt Kontrollen pauschal als vorhanden zu bezeichnen.
• Software und Dienstleister: Verzeichnis der Eigenentwicklungen, wesentlichen Drittkomponenten, externen Betreiber:innen und laufenden Verträge. Vermerken Sie, wer Systeme betreuen und Änderungen freigeben kann.
• Entwicklung und Übergabe: Beschreiben Sie, wo Dokumentation und technische Zugänge liegen, wie Änderungen entschieden werden und welches Wissen nur einzelne Personen besitzen. Eine vertiefte Architekturprüfung können Sie an den Fragen aus dem Beitrag zur Vorbereitung der IT-Architektur auf eine Tech Due Diligence spiegeln; eine Verkaufsprüfung hat jedoch einen anderen Transaktionskontext als eine Finanzierungsrunde.

Geben Sie sensible Zugänge, personenbezogene Daten oder vollständige technische Bestände nicht ungeprüft in einen Datenraum. Legen Sie mit Transaktions- und Rechtsberatung fest, welche Einsicht in welcher Prüfungsphase erforderlich und zulässig ist.

Wie weisen Sie Rechte an Software und Know-how nach?

Eine Systemliste beantwortet noch nicht, ob das Unternehmen Software und technische Ergebnisse im vorgesehenen Umfang nutzen, ändern oder übertragen kann. Erstellen Sie deshalb für geschäftskritische Eigenentwicklungen und Komponenten eine Zuordnung von Ergebnis, beteiligten Parteien, Vertrag und verfügbarem Nachweis. Prüfen Sie besonders Arbeiten früherer Mitarbeitender, externer Entwickler:innen und Technologiepartner.

• Eigenentwicklung: Halten Sie fest, welches Unternehmen als Rechteinhaberin geführt wird und welche Arbeits- oder Projektverträge sowie Abnahmeunterlagen diese Einordnung stützen.
• Drittsoftware: Erfassen Sie wesentliche Lizenzen, Nutzungsbedingungen und mögliche Einschränkungen bei einem Kontrollwechsel zur Prüfung durch Fachpersonen.
• Offene Belege: Markieren Sie fehlende Verträge oder unklare Rechteketten als Prüfpunkt. Ersetzen Sie Nachweise nicht durch die Aussage, dass Software «schon immer uns gehört».

Hinweis: Die Einordnung von IP-Rechten, Lizenzen, Datenschutz und vertraglichen Pflichten im Transaktionskontext erfordert eine fachliche Prüfung; dieser Beitrag ersetzt keine Rechts- oder Steuerberatung.

Wie machen Sie bekannte Risiken prüfbar statt unsichtbar?

Ein Käufer kann technische Schwächen eher beurteilen, wenn Auswirkung, Beleg und geplanter Umgang erkennbar sind. Führen Sie ein Risikoregister, das technische Feststellungen von Vermutungen trennt. Die Geschäftsleitung entscheidet, welche Risiken vor der Prüfung bearbeitet werden und welche mit Massnahmenplan offengelegt werden; die technische Führung liefert die Grundlage dafür.

• Risiko benennen: Beschreiben Sie den betroffenen Prozess, etwa eine nicht dokumentierte ERP-Schnittstelle oder eine von einer Einzelperson abhängige Produktionsanbindung.
• Auswirkung einordnen: Notieren Sie, was bei Ausfall oder Änderung betroffen wäre und welche Annahmen noch geprüft werden müssen. Vermeiden Sie unbelegte Angaben zu Schadenshöhen.
• Nachweis verlinken: Hinterlegen Sie vorhandene Test-, Betriebs- oder Vertragsunterlagen und halten Sie fest, wenn ein Nachweis fehlt.
• Massnahme verantworten: Weisen Sie eine zuständige Person zu und unterscheiden Sie zwischen kurzfristiger Absicherung, vertiefter Prüfung und längerfristiger Modernisierung.

Priorisieren Sie nach Geschäftsrelevanz und Klärbarkeit, nicht danach, welches Thema sich am einfachsten aus der Liste streichen lässt. Für Fragen, die erst nach einem Abschluss in eine Integrationsplanung übergehen, hilft die Abgrenzung eines Interim-CTO-Mandats für die IT-Integration. Sie ersetzt nicht die Prüfung vor dem Verkauf.

Wer führt die Vorbereitung – und wann lohnt externe Unterstützung?

Für das angenommene Industrie-KMU ist eine kleine, klar zuständige Arbeitsgruppe zweckmässiger als ein Datenraum ohne fachliche Freigabe. Die Geschäftsleitung legt Umfang und Prioritäten fest. Die CFO-Funktion koordiniert Transaktionsprozess und Unterlagen. IT-Verantwortliche und Fachbereiche liefern Belege; Rechts- und Transaktionsberater:innen prüfen die entsprechenden rechtlichen und vertraglichen Fragen. Eine technische Leitung prüft die Konsistenz der Aussagen und erklärt Abhängigkeiten gegenüber dem Käufer.

Externe technische Führung kann sinnvoll sein, wenn Software geschäftskritisch ist, aber niemand intern Architektur, Betrieb, Risiken und Nachweise übergreifend vertreten kann. Ein Fractional CTO übernimmt dann ein abgegrenztes Mandat für Bestandsaufnahme, Architektur-Review, Risikopriorisierung und technische Rückfragen – nicht die Rolle der Verkäuferberatung oder eine Garantie für ein Prüfergebnis. Vergleichen Sie den Bedarf an laufender Entscheidungsverantwortung mit einer punktuellen Analyse; der Beitrag Fractional CTO oder IT-Beratung erläutert diese Unterscheidung.

Die Aufwandsfaktoren sind vor allem Anzahl und Verflechtung der Systeme, Zustand der Dokumentation, Zahl der Drittparteien und Tiefe der Käuferfragen. Definieren Sie deshalb zuerst Umfang, Ergebnisse und Zuständigkeiten, bevor Sie ein Mandat besprechen. Einen Überblick über mögliche Zusammenarbeitsformen bietet die Seite zu Engagement-Modellen und Kosten; konkrete Konditionen werden im individuellen Angebot geklärt.

Häufige Fragen

Fazit

Strukturieren Sie die Vorbereitung entlang geschäftskritischer Systeme, belegbarer Rechte und offen ausgewiesener Risiken. So erhält die Geschäftsleitung eine Grundlage für Prioritäten, während Käuferfragen fachlich konsistent beantwortet werden können. Fehlt dafür interne technische Führung, prüfen Sie den Einsatz eines CTO as a Service und buchen Sie ein technisches Briefing zur Abgrenzung des Mandats.