Doradztwo technologiczne

Due diligence technologiczne

Raport o stanie systemów, kodu, danych, licencji i zespołu IT firmy, którą kupujesz, z ryzykami i kosztem doprowadzenia do porządku przed podpisaniem umowy.

Porozmawiajmy o projekcie Zobacz zakres

Sytuacje

Z czym przychodzą do nas klienci

Kupujesz firmę, przejmujesz spółkę do grupy albo wchodzisz do niej jako inwestor, a sprzedający pokazuje przychody, klientów i działający system. Doradcy finansowi i prawni sprawdzą księgi i umowy, ale do kodu i serwerowni nie zajrzą. Due diligence technologiczne, czyli sprawdzenie stanu systemów, kodu, danych, umów licencyjnych i zespołu IT przed podpisaniem umowy, wypełnia tę lukę. Pokazuje, co należy do firmy, co trzyma się na pojedynczych osobach i co trzeba będzie naprawić po zakupie.

Kupujesz firmę, której wartość leży w oprogramowaniu

Przedmiotem zakupu jest firma programistyczna, sklep internetowy albo usługa, którą w całości obsługuje własne oprogramowanie. Nie wiadomo, kto napisał kod, czy prawa do niego ma sprzedający, czy jego podwykonawca, i czy system przetrwa odejście osób, które go zbudowały. Cena zależy od tych odpowiedzi, a dokumenty, które dostałeś, ich nie zawierają.

Inwestujesz w spółkę, która obiecuje wzrost

Zarząd spółki zapewnia, że system obsłuży wielokrotnie więcej klientów bez przebudowy, ale nikt tego nie sprawdził. Jeśli obietnica nie ma pokrycia, pierwsze pieniądze z inwestycji pójdą na przebudowę zamiast na sprzedaż.

Sprzedajesz własną firmę i chcesz wiedzieć, co znajdzie kupujący

Kupujący przyśle doradców, którzy zajrzą do kodu, licencji i umów z programistami. Każdy brak, który znajdą, obniży cenę albo wydłuży negocjacje. Wolisz znać te braki wcześniej: część naprawić, resztę opisać i wycenić samemu.

Zakres

Co sprawdzamy

  1. W każdym obszarze odpowiadamy na te same pytania: co jest, do kogo należy, co się stanie, gdy przestanie działać, i ile pracy wymaga doprowadzenie do porządku.

  2. Systemy. Spisujemy systemy, które prowadzą sprzedaż, obsługę klienta, rozliczenia i produkcję: gdzie są uruchomione i kto ma dostęp administracyjny, czyli prawo zmieniać ustawienia i użytkowników. Ustalamy, które firma kupiła, które zbudowała sama i które działają u dostawcy, którego umowa może wygasnąć ze zmianą właściciela.

  3. Kod. Kod źródłowy to zapis działania programu, który programista czyta i zmienia. Sprawdzamy, czy leży w repozytorium, czyli w miejscu przechowującym każdą wersję z historią zmian, i czy inna osoba zbuduje z niego działający system bez pomocy autorów. Oceniamy też dług technologiczny: skróty w budowie systemu, które ktoś będzie musiał spłacić pracą.

  4. Dane. Ustalamy, gdzie leżą dane o klientach, umowach i transakcjach, kto jest ich właścicielem według umów i czy da się je wyprowadzić z systemu. Sprawdzamy kopie zapasowe: czy powstają i czy ktokolwiek odtworzył z nich system, bo kopia nigdy nie odtworzona jest tylko założeniem. Przy danych osobowych sprawdzamy, czy firma wie, skąd je ma.

  5. Umowy licencyjne. Licencja to warunki, na jakich firma używa cudzego oprogramowania. Licencje komercyjne sprawdzamy pod kątem zmiany właściciela: część wymaga zgody producenta albo zmienia cenę, gdy firma przechodzi w inne ręce. Oprogramowanie otwarte, czyli kod dostępny za darmo na warunkach autora, sprawdzamy, bo część tych warunków może wymagać ujawnienia własnego kodu. Ocenę prawną wydaje kancelaria; dostarczamy jej listę umów i miejsc w kodzie do sprawdzenia.

  6. Zespół IT. Sprawdzamy, ile wiedzy o systemach istnieje wyłącznie w głowach osób, które je utrzymują. Ustalamy, kto jest pracownikiem, kto podwykonawcą i czy umowy przenoszą na firmę prawa do kodu, który te osoby napisały. Zależność od jednej osoby opisujemy w raporcie bez nazwisk.

  7. Powstaje raport dla zarządu: stan każdego obszaru, ryzyka według wagi i szacunek pracy potrzebnej do ich usunięcia. Przegląd własnych systemów bez transakcji w tle to osobny zakres, podobnie jak plan połączenia systemów obu firm po zakupie.

Wynik

Co dostajesz

  • Inwentarz systemów, danych i dostępów: co działa, gdzie i do kogo należy.
  • Raport o stanie kodu: repozytorium, możliwość zbudowania systemu bez autorów, dług technologiczny z przykładami.
  • Rejestr ryzyk z wagą: które blokują transakcję, które obniżają cenę, które da się naprawić po zakupie.
  • Szacunek pracy i kosztu doprowadzenia do porządku, obszar po obszarze, jako podstawa negocjacji ceny.
  • Lista umów dla kancelarii i lista pytań do sprzedającego bez odpowiedzi w dokumentach.

Przebieg

Jak przebiega praca

  1. Ustalamy zakres i dostęp.

    Z Tobą i doradcami transakcji ustalamy przedmiot zakupu i kolejność sprawdzeń; ze sprzedającym uzgadniamy dokumenty, dostępy i osoby do rozmów w ramach umowy o poufności. Wynik: plan przeglądu i lista tego, co sprzedający udostępnia.

  2. Czytamy dokumenty, kod i ustawienia systemów.

    Pracujemy na materiałach i serwerach sprzedającego, bez kopiowania danych. Wynik: opis stanu każdego obszaru i lista pytań, na które dokumenty nie odpowiadają.

  3. Rozmawiamy z zespołem IT sprzedającego.

    Osoby, które utrzymują systemy, pokazują nam, jak wprowadzają zmianę, obsługują awarię i odtwarzają system z kopii. Wynik: potwierdzone albo poprawione ustalenia i ocena zależności od pojedynczych osób.

  4. Przekazujemy raport.

    Omawiamy go z Tobą i doradcami transakcji: które ryzyka negocjować, które wymagają decyzji przed podpisaniem. Wynik: raport z rejestrem ryzyk i szacunkiem kosztu doprowadzenia do porządku.

Usługa nadrzędna

Doradztwo technologiczne

Analiza procesu i systemów zakończona rekomendacją z zakresem prac: uporządkować proces, połączyć systemy, które masz, albo zbudować nowy.

Zobacz usługę

Umów spotkanie

Umów rozmowę o problemie

Opisujesz proces albo system, który przestał wystarczać, i mówisz, co ma się zmienić. Rozmowa nic nie kosztuje.

Wybierz termin

Telefon: +48 455 406 404

Przed umową

Pytania, które zarząd powinien zadać wykonawcy przeglądu

  1. Kto będzie czytał kod i jakie systemy oceniał wcześniej?
  2. Czy raport rozróżni ryzyka, które blokują transakcję, od tych, które da się wycenić i naprawić po zakupie?
  3. Jak wykonawca ustali, czy prawa do kodu ma sprzedający, czy jego programiści albo podwykonawcy?
  4. Czy ktoś spróbuje odtworzyć system z kopii zapasowej, czy tylko sprawdzi, że kopie istnieją?
  5. Które licencje wymagają zgody producenta na zmianę właściciela i kto to sprawdzi: wykonawca czy kancelaria?
  6. Co w raporcie będzie oszacowane w pracy i pieniądzach, a co pozostanie opisem?
  7. Jak wykonawca chroni dane sprzedającego i co się z nimi stanie po zakończeniu przeglądu?

Co sprawdzić najpierw i jak głęboko, zależy od tego, co kupujesz i ile czasu zostało do umowy. Dlatego zaczynamy od analizy transakcji: jej przedmiotu, dostępu od sprzedającego i kolejności sprawdzeń.

Doradztwo technologiczne

Inne zakresy tej usługi

Zobacz usługę: Doradztwo technologiczne

Strategia technologiczna

Kierunek dla systemów firmy na kilka lat, spisany tak, że zarząd wie, które systemy zostają, które wymienia, w jakiej kolejności i za co płaci.

Zobacz zakres

Studium wykonalności

Odpowiedź przed dużym wydatkiem: czy planowany system albo automatyzację da się zbudować w zakładanym czasie i budżecie, na jakich danych i z jakimi ograniczeniami.

Zobacz zakres

Plan wdrożenia krok po kroku

Etapy wdrożenia ułożone tak, że każdy kończy się czymś, co działa w firmie, z osobami po Twojej stronie, decyzjami zarządu i warunkami przejścia do kolejnego.

Zobacz zakres

Jak zaczynamy

  1. Rozmowa o problemie

    Opisujesz proces albo system, który przestał wystarczać, i mówisz, co ma się zmienić. Rozmowa nic nie kosztuje.

  2. Analiza pod NDA

    Badamy proces i systemy i oddajemy rekomendację z zakresem prac. Zakres, termin i cenę analizy znasz przed jej startem.

  3. Oferta

    Dostajesz zakres, zespół, harmonogram i cenę wdrożenia. Decydujesz, czy ruszamy.

Koszt analizy zaliczamy na poczet wdrożenia, jeśli je zamówisz.

Porozmawiajmy o projekcie

Telefon: +48 455 406 404 E-mail: contact@aliaxit.com

© 2026 ALIAX IT sp. z o.o. · ul. Boczna 28, 64-115 Wilkowice · KRS 0001102190 · NIP 6972399808 Polityka prywatności ·