Trochę wprost
Gdy jeździsz mercedesem, naprawiasz go w salonie mercedesa. Mechanik, który zna toyoty, zrobi to, co umie — nie to, co jest dla twojego auta najlepsze.
Dlaczego więc zakładasz, że każdy zespół techniczny wdroży daną technologię równie dobrze, jeśli to nie jest jego domenowy obszar?
Rynek jest duży, czerwony i coraz cięższy dla software house'ów. Widzimy to. Widzieliśmy to też od wewnątrz zespołów. Programiści rekomendowali technologie, które znali, w których mieli już napisane funkcjonalności, szablony, skróty. Nie te, które były dla ciebie korzystne — nie dlatego, że działali w złej wierze. Dlatego, że każdy optymalizuje w obrębie tego, co zna.
Dostawcy nie mają na celu powiedzieć ci, że to nie ich domena. Mają na celu podpisać umowę.
Technologia to 10%. Ale zły wybór technologii to vendor lock, koszt migracji za trzy lata i projekt który zaczyna się od długu którego nikt nie wpisał w budżet.
Technologia to 10%
Danie wdrożenia zespołowi IT to jak danie projektu domu inżynierowi od szalunków i krokwi. Dom stanie. Będzie spełniał wymagania budowlane. Ale czy będzie funkcjonalny? Czy będziesz chciał w nim mieszkać?
BCG przebadało ponad 850 firm i wyszło z jedną proporcją która obala większość briefingów transformacyjnych.
Skąd pochodzi sukces wdrożenia — formuła BCG
Większość organizacji inwestuje 90% energii w te pierwsze 10%. Kupują licencję. Wybierają stack. Negocjują z dostawcą. Podpisują umowę. I dopiero wtedy, gdy system jest już zamówiony, zaczynają zastanawiać się co z nim zrobić. Kto będzie go używał. Jak zmieni codzienną pracę działu który go dostanie. Co się stanie gdy pracownik się zablokuje o 14:00 w środę i nie będzie nikogo kto wytłumaczy jak to działa.
Technologia to 10%. Ale źle dobrana technologia to nie 10% problemu. To fundament na którym zbudujesz resztę błędów.
Developer wraca do swojej technologii jak pracownik do Excela
nie dlatego, że jest oporny. Dlatego, że zna to środowisko. Wie jak działa, gdzie są granice, co można obejść. To jest ten sam mechanizm który sprawia że pracownik omija nowy system i otwiera arkusz. Każdy optymalizuje w obrębie tego co zna. Dostawca robi to samo.
Czego nie znajdziesz w raporcie BCG.
I tu jest coś czego nie znajdziesz w raporcie BCG. Największe zwroty z inwestycji w nowe technologie mają sami developerzy we własnych projektach. Bo rozumieją problem od środka. Dobierają narzędzie do problemu, nie problem do narzędzia które akurat mają. Wiedzą kiedy wystarczy algorytm i kiedy potrzebny jest model.
Organizacja, która kupuje wdrożenie bez rozumienia problemu od środka, kupuje czyjąś optymalizację. Nie swoją. I płaci za nią przez kolejne trzy lata aktualizacji, migracji i promptów, które przestały działać po ostatniej aktualizacji modelu.
Dlatego powstały metodyki audytowe. I dlatego 80% firm ich nie używa.
Event Storming, Domain-Driven Design, Wardley Maps, Value Stream Mapping, Impact Mapping. Brzmi jak lista konferencyjnych buzzwordów. W praktyce to narzędzia które odpowiadają na jedno pytanie zanim ktokolwiek wybrał technologię: co tu właściwie się dzieje i gdzie jest prawdziwy problem.
Event Storming pozwala w jeden dzień zobaczyć cały przepływ zdarzeń w organizacji, łącznie z wyjątkami o których nikt nie mówi na warsztacie z karteczkami, bo każdy zakłada że inni je znają. DDD pozwala zdefiniować granice między obszarami tak precyzyjnie, że integracja między systemami przestaje być projektem a staje się konsekwencją projektu. Wardley Maps pokazują gdzie dana technologia jest towarem a gdzie jeszcze zawodem, co bezpośrednio przekłada się na decyzję buduj kontra kup.
Żadna z tych metod nie zastąpi wizyty w miejscu pracy. Ale każda z nich zadaje pytania których typowy przetarg nie zadaje nigdy. Nie "jakiego dostawcy wybrać" tylko "czy rozumiemy co chcemy zautomatyzować i czy jest to w ogóle warte automatyzacji".
Większość firm których dotykamy zaczyna od wyboru narzędzia. Metodyki audytowe zaczynają od mapy terenu. To różnica między nawigowaniem a jazdą na oślep z nadzieją że droga gdzieś doprowadzi.
Dlatego powstały grupy robocze
Zapraszamy partnerów z różnych obszarów technologicznych do wspólnej analizy twojego problemu. Nie przychodzimy z gotowym rozwiązaniem. Przychodzimy z pytaniami i z ludźmi którzy znają różne odpowiedzi.
Każdy dostawca zna swój stack. Każdy konsultant ma ulubione narzędzie. Grupa robocza ma jedno zadanie: znaleźć rozwiązanie które działa dla ciebie, nie dla nas.
Opisz problem i dołącz do grupy roboczej →
Czytaj dalej: kto nam wdroży AI — kolejność, checklista i koszty poza ofertą →
Konsultacja
Umów konsultację
Opisz krótko kontekst — wrócimy z terminem i propozycją następnego kroku. Możesz też napisać na connect@atypical.pl.