Due diligence techniczny przy fuzjach i przejęciach

Na czym polega due diligence techniczny

Due diligence techniczny to analiza technologii firmy przeprowadzana przez specjalistów technicznych przed przejęciem lub inwestycją. Pozwala sprawdzić, czy produkt, systemy, kod i zespół sprostają założeniom biznesplanu. Nabywcy wykorzystują ją, by wykryć ryzyka, ocenić potencjał wzrostu i zidentyfikować kosztowny dług technologiczny.

Analiza nie polega na przebudowie całego systemu i nie gwarantuje wykrycia każdej usterki. Daje zespołowi transakcyjnemu rzetelny obraz technologii, która może zostać przejęta. Wnioski mogą wpłynąć na cenę, warunki transakcji, plan integracji lub decyzję o rezygnacji z zakupu.

Zakres zależy od analizowanej firmy. Mała firma programistyczna może potrzebować ukierunkowanej analizy kodu i bezpieczeństwa. W przypadku większej spółki warto też sprawdzić koszty chmury, przetwarzanie danych, relacje z dostawcami i wiele systemów produktowych.

Co powinna obejmować analiza

Rzetelna analiza łączy zagadnienia z obszaru inżynierii, bezpieczeństwa i biznesu. Jej celem jest sprawdzenie, jak technologia działa obecnie i czy sprosta planom firmy. Analitycy powinni weryfikować kluczowe deklaracje na podstawie dowodów, zamiast polegać wyłącznie na prezentacjach i rozmowach.

Analiza kodu może ujawnić kruche elementy, niewystarczające testy i systemy trudne do modyfikacji. Ocena architektury pokazuje, jak współdziałają poszczególne elementy i gdzie może rozprzestrzenić się awaria. Analiza infrastruktury obejmuje dostępność, plany tworzenia kopii zapasowych, wydatki na chmurę i możliwość zwiększania liczby użytkowników.

Weryfikacja bezpieczeństwa i zgodności z przepisami jest ważna, bo nabywca może przejąć słabe zabezpieczenia lub ryzyko prawne. Sprawdź zasady dostępu, przepływy danych, znane luki, rejestry incydentów i wymagane standardy. NIST Cybersecurity Framework to uznane narzędzie do określania ram oceny ryzyka bezpieczeństwa.

Warto też sprawdzić własność intelektualną, plany produktowe i zespół techniczny. Potwierdź, że firma jest właścicielem kluczowego kodu i narzędzi lub ma prawo z nich korzystać. Ustal, czy krytyczna wiedza o systemach nie skupia się w rękach kilku osób oraz czy zespół jest w stanie rozwijać produkt i wspierać planowany wzrost.

• Kod: projekt, zakres testów, usterki i proces kompilacji
• Systemy: architektura, dostępność, kopie zapasowe i ograniczenia wzrostu
• Bezpieczeństwo: dostęp, ochrona danych, incydenty i nierozwiązane luki
• Zespół i prawa: kompetencje, kluczowe role i własność kodu

Jak przebiega proces due diligence technicznego

Typowe due diligence techniczne trwa od dwóch do czterech tygodni. Koszt często wynosi od 5 000 do 30 000 USD, w zależności od zakresu, wielkości firmy i złożoności systemów. Krótkie terminy lub duża liczba produktów mogą podnieść cenę.

Najpierw uzgodnij zakres prac związanych z due diligence technicznym. Określ kontekst transakcji, obszary analizy, wymagany dostęp, terminy i końcowe rezultaty. Wyznacz osobę kontaktową po każdej stronie, a następnie zbierz mapy systemów, dostęp do kodu, dokumentację bezpieczeństwa, plany produktowe i informacje o zespole.

Następnie porozmawiaj z kadrą kierowniczą i inżynierami, po czym zweryfikuj najważniejsze deklaracje. Przeanalizuj próbki kodu, konfigurację chmury, proces wdrażania zmian i rejestry incydentów. Gdy odpowiedzi są ogólnikowe lub nie zgadzają się z przekazanymi wcześniej informacjami, poproś o dowody.

Na zakończenie przygotuj raport z uszeregowanymi wnioskami. Oddziel pilne ryzyka od kwestii, które mogą poczekać, i wyjaśnij, jak każdy problem wpływa na koszty, rozwój lub wartość transakcji. Zostaw nabywcy czas na dodatkowe pytania, zanim zespół ustali ostateczne warunki.

1. Ustal zakres. Dopasuj obszary analizy do założeń transakcji i głównych produktów firmy.
2. Zbierz dowody. Poproś o kod, dokumentację systemów, zasady, plany i dostęp do kluczowych pracowników.
3. Weryfikuj i rozmawiaj. Sprawdzaj deklaracje, śledź ryzyka i zadawaj dodatkowe pytania.
4. Uszereguj wnioski. Przy każdym istotnym ryzyku opisz wpływ, przewidywany nakład pracy i kolejne kroki.

Praktyczna lista kontrolna analizy technicznej

Lista kontrolna pomaga sprawdzić te same kluczowe obszary i odnotować brakujące dowody. Dostosuj ją do transakcji — nie traktuj wszystkich pytań jednakowo. Firma oferująca prostą aplikację wymaga innej analizy niż przedsiębiorstwo przetwarzające wrażliwe dane lub korzystające ze złożonych systemów.

Do śledzenia dowodów, osób odpowiedzialnych, poziomu ryzyka i nierozstrzygniętych kwestii użyj wspólnego arkusza lub skoroszytu. Lista kontrolna analizy technicznej w PDF sprawdzi się przy szybkiej weryfikacji, ale arkusz łatwiej sortować i aktualizować. Zapisuj, kto dostarczył każdy materiał i kiedy.

Jakość dokumentacji to ważny wskaźnik. Brak map systemów może spowolnić przyszłe prace, a niejasna własność narazić kluczowy kod na ryzyko. Jeśli nabywca planuje połączyć produkty, dane lub systemy pracownicze, sprawdź możliwości integracji na wczesnym etapie.

Sygnały ostrzegawcze, które mogą wpłynąć na transakcję

Dług technologiczny nie zawsze jest powodem do rezygnacji z transakcji. Kluczowe pytanie brzmi, czy utrudnia rozwój, zwiększa ryzyko awarii lub kosztuje więcej, niż zakładano. Poproś zespół o wskazanie najkosztowniejszych problemów i przedstawienie planu ich rozwiązania.

Problemy ze zgodnością mogą znacznie utrudnić planowaną fuzję. Dwa produkty mogą korzystać z różnych modeli danych, narzędzi chmurowych lub systemów logowania. Jeśli nabywca oczekuje szybkiej integracji, przed ustaleniem sztywnego harmonogramu poproś inżynierów o przetestowanie tego scenariusza.

Inne sygnały ostrzegawcze to powtarzające się awarie, nieskuteczne kopie zapasowe, niezałatane luki i sytuacja, w której tylko jedna osoba zna kluczowy system. Korzystanie z produktu mogą też zagrozić brak praw do kodu lub niekorzystne warunki umów z dostawcami. Deklaracje bez potwierdzenia traktuj jako nierozstrzygnięte ryzyka, a nie dowód, że problem nie istnieje.

• Kluczowy kod ma niewiele testów lub niejasnego właściciela
• Plany odtwarzania istnieją tylko na papierze i nie zostały przetestowane
• Luki bezpieczeństwa pozostają nierozwiązane, bez wskazanej osoby odpowiedzialnej lub terminu
• Plany rozwoju zależą od systemów o znanych ograniczeniach wydajności
• Niejasne prawa do kluczowych produktów, warunki umów lub zasady przetwarzania danych

Jak przeprowadzić przydatną analizę

Zacznij od założeń transakcji. Jeśli wartość zależy od szybkiego wzrostu, skup się na skalowalności, niezawodności i możliwościach zespołu. Jeśli kluczowym atutem jest produkt, sprawdź jakość kodu, prawa i koszty jego utrzymania.

Zadawaj pytania w due diligence technicznym, które wymagają dowodów i pozwalają ocenić wpływ problemów. Na przykład: „Co zawiedzie jako pierwsze, jeśli liczba użytkowników się podwoi?” lub „Kiedy zespół ostatnio testował pełne odtworzenie systemu?”. Proś inżynierów o omówienie konkretnych przykładów, a nie tylko odpowiedzi „tak” lub „nie”.

Zachowaj rzeczowy i partnerski ton. Analiza przebiega najlepiej, gdy pracownicy wiedzą, dlaczego nabywca potrzebuje dostępu i jak wykorzysta wnioski. Ogranicz dostęp do danych do zakresu potrzebnego do analizy i stosuj bezpieczne zasady postępowania z kodem oraz danymi klientów.

Powiąż każdy problem z konsekwencjami biznesowymi. Oszacuj czas, koszty, potrzebną liczbę pracowników i ewentualne ryzyko dla klientów. Dzięki temu kadra kierownicza może porównać wyniki analizy technicznej z innymi zagrożeniami transakcji i zdecydować, które kwestie wymagają zmiany ceny, naprawy lub konkretnego planu działania.

Po analizie: przełóż wnioski na działania

Po zakończeniu analizy uszereguj wnioski według pilności i wpływu na transakcję. Poważne ryzyka związane z bezpieczeństwem lub prawami własności od razu przedstaw zespołowi transakcyjnemu. Mniejsze poprawki uwzględnij w planie po sfinalizowaniu transakcji, przypisując im osoby odpowiedzialne, terminy i budżety.

Integracji nie należy zaczynać od gruntownej przebudowy. Najpierw zadbaj o dostępność usług, kontrolę dostępu, kopie zapasowe i kluczową wiedzę pracowników. Następnie określ, które systemy zachować, połączyć lub wycofać, kierując się celami nabywcy.

Po sfinalizowaniu transakcji monitoruj postępy za pomocą krótkiej listy wskaźników. Mogą to być czas niedostępności, liczba nierozwiązanych luk wysokiego ryzyka, koszty chmury, tempo wdrożeń i utrzymanie kluczowych pracowników. Aktualizuj plan w miarę jak połączony zespół zdobywa wiedzę o systemach.

Wartość due diligence wynika z działań podjętych na podstawie jego ustaleń. Rzetelny zapis ryzyk i decyzji pomaga uniknąć powtarzania testów i utraty kontekstu. Ułatwia też kadrze kierowniczej finansowanie prac, które chronią wartość transakcji.