Utrzymanie i rozwój systemu
To jest pytanie, które blokuje najwięcej decyzji, i zadajesz je słusznie. Ten rozdział odpowiada, co dokładnie zostaje u Ciebie po projekcie, kto to rozwija i co się stanie, jeśli przestaniemy pracować razem.
Reklamacja — proces, którego nikt nie zaprojektował
— Klient reklamuje partię — mówi obsługa.
— Reklamacje? Tego nie ma w ERP. Jest w mailu i w arkuszu jakości.
Nigdy nie było. Proces żył obok systemów, bo był „za drobny” na moduł. Teraz jest opisany w modelu firmy: kto przyjmuje, kto ocenia, kto decyduje o wymianie, kiedy wychodzi korekta faktury. Z tego opisu powstaje moduł — nie ze zgłoszenia do dostawcy i miejsca w kolejce.
Klient dostaje wymianę i korektę w obiecanym terminie. I wraca z następnym zapytaniem. Tak domyka się obietnica z prologu — a reklamacja jest ostatnim miejscem, w którym mogła pęknąć, i pierwszym, które klient zapamięta.
Przejechaliśmy się już na dedykowanym oprogramowaniu
Znam to zdanie i słyszę je na co drugim spotkaniu. Firma zamówiła system szyty na miarę, dostała go z opóźnieniem, a potem został z nią kod, który rozumiał jeden zespół u dostawcy.
Dokumentacji nie było albo rozjechała się z rzeczywistością po pierwszym kwartale. Każda zmiana kosztowała tyle, co nowy moduł. Zmiana dostawcy nie wchodziła w grę, bo nikt inny nie chciał tego dotknąć.
Jeśli tak wyglądało Twoje ostatnie doświadczenie, masz pełne prawo pytać, czym to się różni. Reszta tego rozdziału jest odpowiedzią.
Cztery rzeczy, wszystkie po Twojej stronie
Po projekcie masz w ręku cztery rzeczy. Nic z tego nie stoi u mnie i nic z tego nie wymaga mojej zgody, żeby z tego korzystać.
Cyfrowy model firmy
Procesy, obiekty, reguły i uprawnienia, w formie czytelnej dla człowieka. Możesz go przeczytać bez pomocy programisty.
Repozytorium
Kod i pełna historia zmian, na Twoim koncie i pod Twoją kontrolą.
Infrastruktura
Miejsce, w którym system stoi: u Ciebie, w Twojej chmurze albo w wybranym centrum danych.
Dokumentacja decyzji
Architektura i uzasadnienia: co wybraliśmy, dlaczego i co odrzuciliśmy.
Aktywem jest specyfikacja, nie kod
W tamtym modelu trwałą rzeczą był kod, a wszystko poza nim było jego opisem. Tutaj jest odwrotnie. Zmiana idzie od modelu w dół, nie od kodu w górę.
- Trwałym artefaktem jest cyfrowy model firmy: procesy, obiekty, reguły i uprawnienia, spisane w formie, którą da się przeczytać.
- Kod powstaje z niego, jest udokumentowany i da się go wygenerować jeszcze raz.
- Zmiana wymagania to zmiana akapitu w modelu i ponowne wygenerowanie tego, co z niego wynika. Nie zgłoszenie, wycena i miejsce w kolejce u dostawcy.
- Proces obsługiwany rzadko i przez jeden dział przestaje być za drobny, żeby mieć własny moduł.
Twoim trwałym aktywem jest specyfikacja, nie kod.
Jak powstaje kolejny moduł
Nic z tego nie stoi u mnie i nic z tego nie wymaga mojej zgody, żeby z tego korzystać.
Praca zaczyna się od zapisu, nie od kodu. Opisujemy proces w modelu firmy: co się dzieje, w jakiej kolejności, kto co zatwierdza i co jest wyjątkiem. Dopiero z tego zapisu agenci budują moduł, a ja sprawdzam, czy to, co powstało, odpowiada zapisowi.
Konsekwencja jest praktyczna. Zmiana wymagania to zmiana akapitu w modelu i ponowne wygenerowanie tego, co z niego wynika. Nie jest to zgłoszenie, wycena i miejsce w kolejce u dostawcy.
Ta sama metoda pozwala robić rzeczy, których wcześniej nie opłacało się zamawiać. Proces obsługiwany przez jeden dział, rzadko i niewielkim nakładem, przestaje być za drobny, żeby mieć własny moduł.
Fabryka oprogramowania po Twojej stronie
Docelowo firma nie kupuje każdej zmiany na zewnątrz. Ma u siebie zestaw narzędzi i agentów, który z zapisu procesu potrafi zrobić działający moduł. W branży nazywa się to Dark Software Factory — fabryka oprogramowania, która pracuje bez człowieka nadzorującego każdy krok.
Nie jest to zespół programistów, którego trzeba zatrudnić. To narzędzia plus jedna rola: ktoś, kto rozumie proces i umie go opisać na tyle dokładnie, żeby powstał z tego moduł.
Tej roli można nauczyć kogoś, kogo już masz. To jest długi koniec tej drogi, a nie warunek pierwszego kroku.
W klasycznym modelu klient zostawał z kodem,
który rozumiał jeden zespół u dostawcy.
Tutaj zostaje zapis firmy, który czyta właściciel.Krzysztof Majchrzycki · AI Business Partner
Dlaczego Linux i otwarty stos pod modelami AI
Wybór stosu nie jest kwestią gustu, tylko rachunku na trzech pozycjach: ile kosztuje uruchamianie modeli, kto kontroluje to, co się z nimi dzieje, i czy ktoś inny może to po mnie przejąć.
Otwarty stos wypada dobrze na wszystkich trzech. Modele, biblioteki i narzędzia do pracy z nimi powstają na Linuksie i tam działają najtaniej. Nie ma opłaty za każdego użytkownika ani za każde wywołanie. A system stojący na otwartych komponentach może przejąć każdy zespół, nie tylko ten z odpowiednim certyfikatem partnerskim.
To nie znaczy, że jest jedynym wyborem. Jeśli Twoja firma stoi na komercyjnym stosie — Microsoft, IBM, Google, AWS — ta sama architektura daje się zbudować hybrydowo: ich usługi plus otwarte oprogramowanie, które sami wspierają. O tym jest następny rozdział.
Odpowiedź ma trzy części
To jest pytanie, które blokuje najwięcej decyzji, i zadajesz je słusznie.
- Ja projektuję i pilnuję, żeby powstało to, co zaprojektowane. Buduje partner wykonawczy, którego wybieramy wspólnie i który pracuje na Twoim repozytorium — umowę na budowę podpisujesz z nim bezpośrednio.
- To, co zostaje, można przeczytać. Nowy dostawca nie musi odgadywać intencji z kodu — dostaje zapis firmy i historię decyzji.
- Jeśli przestaniemy pracować razem, nie tracisz nic poza mną. Model, kod i infrastruktura stoją u Ciebie od pierwszego dnia, nie od momentu zakończenia współpracy.
Pytania, które padają w tym miejscu
Ile trwa zbudowanie takiego modelu?
Audyt i mapa danych to od trzech tygodni, Plan systemu firmy od sześciu. Dopiero po nich wiadomo, ile trwa wykonanie — i to jest powód, dla którego wcześniej nie podaję terminu.
Co jeśli przestaniemy współpracować?
Repozytorium, dane i infrastruktura są po Waszej stronie od pierwszego dnia. Model firmy jest zapisany tak, żeby przejął go inny dostawca bez odtwarzania wiedzy od zera.
Czy potrzebujemy własnych programistów?
Nie do utrzymania modelu. Model czyta i weryfikuje właściciel oraz osoby odpowiedzialne za procesy. Do wykonania potrzebny jest wykonawca — Wasz własny albo dowolny zewnętrzny.
Czy podejście „najpierw specyfikacja” wystarczy, żeby zbudować taki system?
Nie bez wspólnego modelu firmy. Specyfikacja bez cyfrowego modelu firmy produkuje pięćdziesiąt modułów zamiast pięćdziesięciu automatyzacji — każdy z własnym rozumieniem tego, czym jest klient, zlecenie i wyjątek. To odtworzenie tego samego problemu w nowszej technologii. Cyfrowy model firmy jest tym, co temu zapobiega.
Darmowy poradnik transformacji AI
dla Twojej Firmy
Jedno zamówienie w siedmiu rozdziałach: od pytania klienta
do dotrzymanej obietnicy.
Bez NDA i bez rozmowy sprzedażowej.
