Jak współpracować: budowanie prawdziwego sojuszu między konsultantami funkcjonalnymi i technicznymi

(Część 2 z 5 serii „Ludzki kod ERP”)

Bądźmy szczerzy. Jeśli poświęciłeś trochę czasu na wdrażanie oprogramowania dla przedsiębiorstw, prawdopodobnie zauważyłeś, że między konsultantami funkcjonalnymi a technicznymi często dochodzi do konfliktów.

Pomiędzy nimi rozciąga się przepaść nieporozumień, pasywno-agresywnych e-maili i opóźnionych terminów realizacji projektów.

Prosty incydent integracyjny

Widziałem, jak projekty stawały w miejscu na kilka tygodni tylko dlatego, że dwaj specjaliści mówili zupełnie różnymi językami.

Wyobraź sobie typowe spotkanie w sprawie uzgodnień. Konsultant funkcjonalny, świeżo po warsztatach z klientem, pochyla się i mówi: „ Klient musi zsynchronizować oprogramowanie produkcyjne z systemem ERP”. To bardzo proste. Musimy tylko zbudować prostą integrację z jego obecnym systemem MES, aby przesłać dane.

Problem polega na tym, że konsultant funkcjonalny sprzedaje rozwiązanie jako „łatwe”, głównie dlatego, że to nie on musi pisać kod. Podaje bardzo mało szczegółów i lekceważy kwestię wykonania technicznego, całkowicie nie doceniając poważnych konsekwencji technicznych.

Dla konsultanta integracja to tylko most koncepcyjny. Dla dewelopera ta sama „prosta integracja” oznacza koszmar struktur danych, błędów przekroczenia limitu czasu, tokenów bezpieczeństwa i brakujących walidacji danych.

Kiedy programista nieuchronnie wskazuje na te zawiłości, rodzi się niepotrzebny konflikt. Konsultant funkcjonalny uważa, że ​​programista niepotrzebnie komplikuje wymagania biznesowe. Deweloper uważa, że ​​konsultant funkcjonalny bagatelizuje jego ciężką pracę i składa klientowi niemożliwe do spełnienia obietnice.

Prawda jest taka, że ​​praca konsultanta funkcjonalnego wiąże się z trudnościami, których programista nie jest w stanie zrozumieć, i na odwrót. Programista nie musi stawiać czoła irracjonalnym żądaniom spanikowanego klienta, a konsultant funkcjonalny nie musi poruszać się w nieubłaganej logice architektury systemu. Żaden z zawodów nie jest mniej ważny ani prostszy od drugiego. Po prostu mierzą się z wyjątkowymi trudnościami, które druga strona rzadko dostrzega.

Prawdziwym wrogiem w tym pokoju jest ego i brak wzajemnego zrozumienia.

Witamy w drugiej części cyklu „Ludzki kod ERP”. Dziś zburzymy podziały między osobami projektującymi procesy biznesowe a tymi, które muszą je faktycznie tworzyć.

Rozmawiamy o tym, jak stworzyć niezawodną współpracę między zespołami funkcyjnymi i technicznymi.

Dwa światy, dwa języki

Aby rozwiązać ten konflikt, musimy najpierw zrozumieć jego przyczynę. Konsultanci funkcjonalni i techniczni funkcjonują w dwóch zupełnie różnych rzeczywistościach.

Konsultant funkcjonalny żyje w chaotycznym, nieprzewidywalnym świecie ludzkiego biznesu. Przechadza się po hali fabrycznej. Widzi fizyczny pot operatorów. Zmaga się z lękiem dyrektora finansowego i chaotycznym, nielogicznym sposobem, w jaki ludzie wykonują swoje codzienne zadania. Jego celem jest zapewnienie płynnego przepływu informacji w firmie.

Konsultant techniczny żyje w świecie absolutnej, binarnej logiki. Tabela bazy danych nie przejmuje się tym, że kierownik magazynu ma stresujący dzień. Architektura systemu wymaga sztywnych reguł, precyzyjnych definicji i zerowej niejednoznaczności. Ich celem jest zapewnienie stabilności, bezpieczeństwa i wydajności systemu.

Kiedy te dwa światy zderzają się bez translatora, następuje katastrofa. Powstaje integracja systemu, która jest technicznie bezbłędna, ale całkowicie bezużyteczna dla pracowników hali produkcyjnej, ponieważ nie uwzględnia fizycznych opóźnień spowodowanych przez wózek widłowy przemieszczający palety.

Mit konsultanta technicznego

Panuje błędne przekonanie, że aby załatać tę lukę, konsultant funkcjonalny musi nauczyć się pisać kod. To całkowite kłamstwo. Dobry konsultant ds. funkcjonalnego ERP nie musi umieć programować skryptów ani pisać złożonych zapytań SQL.

Muszą jednak bezwzględnie wiedzieć, jak system myśli.

Nie musisz wiedzieć, jak napisać ładunek API. Musisz jednak zrozumieć, że kiedy system wysyła komunikat, oczekuje konkretnej odpowiedzi, a Ty musisz zaprojektować proces biznesowy uwzględniający to, co się stanie, jeśli ta odpowiedź nigdy nie nadejdzie. Musisz zrozumieć różnicę między tabelą danych głównych a tabelą transakcyjną. Musisz znać podstawowe prawa architektury systemów.

Twoim prawdziwym zadaniem jako konsultanta funkcjonalnego jest bycie najlepszym tłumaczem ludzkim. Jesteś mostem, a nie programistą. Musisz przetworzyć chaotyczne, emocjonalne potrzeby firmy na przejrzyste, logiczne struktury, z którymi programista może faktycznie pracować.

Ochrona okopów

Najgorszym typem konsultanta funkcjonalnego jest ślepy wykonawca. To konsultant, który tak naprawdę nie przejmuje się rzeczywistymi potrzebami biznesowymi. Wykonuje polecenia jak mały żołnierz, wysłuchując nielogicznych lub całkowicie niewykonalnych próśb klienta o dostosowanie, zapisując je dokładnie tak, jak zostały powiedziane, i przekazując bezpośrednio zespołowi technicznemu, nie zastanawiając się, czy w ogóle mają sens.

Nowoczesna architektura CloudSuite zapobiega dosłownemu uszkodzeniu bazy danych, ale użytkownicy nadal będą prosić o modyfikacje, które całkowicie naruszają standardową logikę systemu. Kiedy programista nieuchronnie zauważy, że prośba jest technicznie absurdalna, tego typu konsultant po prostu wzrusza ramionami i mówi: „Nie obwiniaj mnie. Tego właśnie chce klient”

Takie zachowanie z czasem niszczy zaufanie i wystawia zespół techniczny na porażkę.

Prawdziwy konsultant działa jak tarcza. Twoim zadaniem jest ocenić, czy prośba jest całkowicie niewykonalna, zanim przekażesz ją działowi IT. Musisz zastosować zasadę „Pięciu Dlaczego”, o której mówiliśmy w Części 1, i odkryć rzeczywistą potrzebę biznesową.

Co więcej, jeśli deweloper ma trudności ze spełnieniem wymagania, nie wystarczy wskazać jedynie na specyfikację i zażądać rezultatów. Należy nawiązać z nim współpracę. Wspólnie badacie, czy ograniczenie techniczne jest obiektywne. Jeśli jest to obiektywna przeszkoda, musicie działać jako pomost i wrócić do klienta, aby wynegocjować rozwiązanie pośrednie.

Klienci uwielbiają używać klasycznego zwrotu: „W IT wszystko jest możliwe”. Musisz chronić swój zespół techniczny przed tym nastawieniem, ponieważ tak nie działa rzeczywistość. Nie przepisujemy podstawowych procesów od podstaw. Rozszerzamy standardowe funkcjonalności.

Kiedy programiści zdadzą sobie sprawę, że stoisz u bram, filtrując śmieci i chroniąc ich przed niemożliwymi do spełnienia obietnicami, zaczną cię szanować. Przestaną sprzeciwiać się twoim prośbom i zaczną współpracować nad twoimi rozwiązaniami.

Znoszenie upału

Konsultanci funkcjonalni często narzekają na bardzo specyficzną dynamikę. Gdy niestandardowy skrypt zawodzi lub system ulega awarii, konsultant techniczny siedzi bezpiecznie za monitorem. W tym samym czasie konsultant funkcjonalny musi siedzieć w sali konferencyjnej, patrzeć rozgniewanemu klientowi w oczy i tłumaczyć, dlaczego nowo wdrożona personalizacja nie działa zgodnie z oczekiwaniami. To niesprawiedliwe, że bierzesz na siebie winę za błąd techniczny, którego nie popełniłeś.

Jednak, czy ci się to podoba, czy nie, bycie łącznikiem między zespołem technicznym a klientem to właśnie twoje zadanie. Jesteś mostem. Narzekanie na stawienie czoła klientowi jest jak tarcza narzekająca na ciosy.

Sekretem udanego projektu jest wzajemna obrona. Silny sojusz oznacza, że ​​wzajemnie się zabezpieczacie. Konsultant funkcjonalny amortyzuje szok, przyjmuje na siebie ciężar odpowiedzialności i radzi sobie z frustracją klienta, aby zyskać cenny czas. Ta dynamika działa tylko wtedy, gdy deweloper go wspiera.

W prawdziwym partnerstwie, w chwili gdy konsultant wchodzi do wrogiej sali konferencyjnej, programista jest już o tym poinformowany i pracuje w tle nad rozwiązaniem problemu. Ty bronisz programisty przed paniką klienta, a programista broni Twojej wiarygodności, szybko naprawiając błąd.

Podręcznik Sojuszu

Jak przekształcić wrogi dział IT w swojego największego sojusznika? Oto trzy praktyczne zasady, które warto zastosować w kolejnym projekcie, aby zbudować prawdziwe partnerstwo.

1. Pisz specyfikacje binarne, a nie powieści

Programiści nienawidzą niejednoznaczności bardziej niż czegokolwiek innego na świecie. Nigdy nie pisz specyfikacji funkcjonalnej, która mówi: „System powinien automatycznie aktualizować status i powiadamiać użytkownika”. To powieść, a nie specyfikacja. Zamiast tego pisz w logice binarnej. Określ dokładnie, który wyzwalacz uruchamia zdarzenie. Zdefiniuj dokładnie, które pole tabeli ma zmienić status ze statusu A na status B.

Dokładnie określ, co powinno zawierać powiadomienie i kto jest jego odbiorcą. Usuń przymiotniki i zastąp je precyzyjnymi warunkami. Jeśli specyfikacja pozostawia pole do osobistej interpretacji, jest to zła specyfikacja. Nawet najdrobniejsze szczegóły muszą zostać zapisane w formalnej analizie i udostępnione. Krótka rozmowa telefoniczna w celu wstępnego omówienia tych szczegółów może mieć ogromne znaczenie dla ustanowienia wspólnego języka.

2. Zawsze wyjaśniaj „Dlaczego” w analizie

Pisząc specyfikację funkcjonalną, należy jasno wyjaśnić motywacje biznesowe stojące za żądaniem. Nie traktuj programisty jedynie jako wykonawcy kodu. Podobnie jak konsultanci funkcjonalni, programiści potrzebują pełnego kontekstu wymagania. Muszą rozumieć, nad czym pracują, ale co najważniejsze, dlaczegoto robią. Nie dawaj im po prostu instrukcji technicznych.

Wyjaśnij problem biznesowy. Załóżmy, że pracownicy magazynu wpisują obecnie tę liczbę ręcznie 500 razy dziennie, co powoduje opóźnienia w dostawach. Musimy zautomatyzować to pole, aby zaoszczędzić im dwie godziny na zmianie. Kiedy programista zrozumie kontekst i wpływ swojego kodu na człowieka, przekształci się z osoby przyjmującej zamówienia w aktywnego partnera, który może zaproponować znacznie lepsze rozwiązanie techniczne niż pierwotnie zakładałeś.

3. Uczyń ich częścią podróży

W większości projektów konsultant funkcjonalny to osoba, która dojeżdża do klienta i uczestniczy w ważnych spotkaniach. Taka dynamika często pozostawia programistę w izolacji w back office. Jeśli naprawdę chcesz pracować zespołowo, musisz robić to właściwie. Nie możesz po prostu pingować współpracowników technicznych tylko wtedy, gdy masz do przydzielenia konkretne zadanie programistyczne, nie przedstawiając im szerszego kontekstu.

Musisz sprawić, by poczuli się integralną częścią całego projektu. Korzystaj z okazji, aby regularnie z nimi rozmawiać i omawiać z nimi najnowsze zmiany u klienta, zmiany w projekcie i ogólną atmosferę. Zapewnienie im stałego kontekstu gwarantuje ich głębokie zaangażowanie. Kiedy programiści rozumieją szerszy obraz i czują się częścią procesu, przestają być jedynie wykonawcami, a stają się prawdziwymi partnerami w projekcie. Projekt, w którym konsultant funkcjonalny i programista współpracują ze sobą, niewątpliwie przyniesie doskonałe rezultaty zarówno w projekcie, jak i w ich codziennej pracy.

Sojusz w okopach

Tworzenie niestandardowego rozszerzenia lub integracja zewnętrznego oprogramowania z systemem ERP nigdy nie sprowadza się do napisania kilku linijek kodu. To ćwiczenie w komunikacji międzyludzkiej.

Najwspanialsza architektura techniczna świata runie, jeśli ludzie definiujący proces i ci, którzy tworzą logikę, przestaną się rozumieć. Odrzucając ego, ucząc się jasno wyrażać i chroniąc swój czas, możemy powstrzymać odwieczną wojnę i zacząć tworzyć oprogramowanie, które naprawdę robi różnicę.

Sukces wdrożenia w trybie Go-Live w dużej mierze zależy od nierozerwalnej współpracy między konsultantem funkcjonalnym a konsultantem technicznym. Żaden z nich nie odniesie sukcesu, działając w pojedynkę.

Następnie: Jak rozwijać najbardziej niedocenianą umiejętność w branży konsultingowej. Przeanalizujemy siłę ciekawości nad encyklopedyczną pamięcią.

Napisane przez Andreę Guaccio 

7 maja 2026 r