Kto wdroży Dynamics 365 na budowie z pełną kontrolą kosztów i harmonogramu

Pełna kontrola kosztów i harmonogramu na budowie zależy od trzech rzeczy, o których większość ofert wdrożeniowych milczy: wyboru właściwego wariantu Dynamics 365 Project Operations, rozpoznawania przychodu według zaawansowania robót oraz śledzenia kosztu zaangażowanego, a nie tylko poniesionego. Dynamics 365 wdroży dobrze partner, który rozumie rachunkowość kontraktów budowlanych i realia generalnego wykonawstwa, a nie tylko konfigurację systemu.

Różnica ma bezpośrednie przełożenie na wynik: zespół znający wyłącznie technologię odwzoruje procesy firmy handlowej lub produkcyjnej, tymczasem kontrakt budowlany rządzi się własną logiką rozpoznania przychodu, potrąceń, zabezpieczeń i rozliczeń z podwykonawcami. Decyzje z pierwszych tygodni wdrożenia przesądzają, czy firma zobaczy rentowność projektu w trakcie realizacji, czy dopiero po zamknięciu, gdy na korektę marży jest już za późno.

Najważniejsze fakty w skrócie:

• Wariant Project Operations. Wariant „lite" prawie nigdy nie wystarcza na budowę; zwykle potrzebny jest wariant zintegrowany z ERP lub oparty na Finance & Operations.
• Koszt zaangażowany i EAC. Kontrola kosztów to prognoza kosztu na zakończenie oraz koszt związany umowami, a nie tylko koszt już poniesiony.
• Przychód w czasie i gotówka. Rozpoznanie według procentu zaawansowania i WIP; rentowny kontrakt potrafi pochłaniać gotówkę, więc wynik trzeba czytać obok przepływu i inkasa.
• Zmiany, kaucje, podwykonawcy. Roboty dodatkowe rejestrowane od razu, kaucje gwarancyjne i rozliczenia back-to-back z widocznym wpływem na płynność.
• Harmonogram. ERP planuje WBS i budżet, a ścieżkę krytyczną integruje się z Microsoft Project lub Primavera; liczy się spójność kosztu, terminu i postępu.
• Jak wybrać partnera. Rozmawia o rachunkowości kontraktów i pokazuje referencje z generalnego wykonawstwa, a nie tylko o modułach.

‍

Pierwsza pułapka: nie każdy Project Operations nadaje się na budowę

Dynamics 365 Project Operations występuje w kilku wariantach wdrożenia, które różnią się tym, co faktycznie obsługują, i to jest najczęstszy, kosztowny błąd na starcie. Wariant „lite" (non-stocked) obsługuje sprzedaż projektów, planowanie, czas i podstawowe materiały, ale nie zapewnia pełnej gospodarki magazynowej ani rozpoznawania przychodu, których wymaga budowa.

Różnice między wariantami opisuje dokumentacja Microsoft, a ich zrozumienie decyduje o tym, czy system udźwignie Twoje projekty.

‍

‍

Wniosek praktyczny brzmi jednoznacznie: firma budowlana prawie nigdy nie powinna kończyć na wariancie „lite". Jeśli partner proponuje najszybsze i najtańsze wdrożenie bez pytania o materiały, podwykonawców i sposób rozpoznawania przychodu, prawdopodobnie prowadzi Cię w ślepą uliczkę, z której wyjście oznacza migrację danych, ponowną konfigurację i drugą rundę kosztów. Z perspektywy zarządczej wybór wariantu jest decyzją o granicach systemu na kolejne lata, a nie kwestią techniczną, którą można w całości delegować do działu informatyki. Wariant zbyt lekki oszczędza w budżecie wdrożenia sumę, która wraca zwielokrotniona w postaci arkuszy prowadzonych obok systemu, ręcznych uzgodnień między kosztem a przychodem oraz braku jednego wiarygodnego źródła danych o rentowności kontraktu.

Wariant nadmiarowy, na przykład pełna gospodarka magazynowa u firmy, która nie prowadzi prefabrykacji, obciąża organizację złożonością, której nie wykorzysta, wydłuża wdrożenie i podnosi koszt utrzymania. Właściwa decyzja wynika z rzetelnej diagnozy modelu biznesowego: skali gospodarki materiałowej, udziału podwykonawstwa w wartości kontraktów, sposobu fakturowania klienta oraz wymagań sprawozdawczych wobec grupy kapitałowej. Dojrzały partner zaczyna od tej diagnozy, a rekomendację wariantu wywodzi z liczb opisujących portfel projektów, nie z domyślnej konfiguracji, którą wdraża najszybciej. Warto również pamiętać, że wybór wariantu nie jest decyzją nieodwracalną w sensie technologicznym, lecz jego zmiana po uruchomieniu systemu jest kosztowna organizacyjnie: wymaga ponownego przeszkolenia zespołów, migracji danych historycznych oraz okresu równoległej pracy dwóch konfiguracji, w którym rośnie ryzyko błędu.

Z tego względu decyzję o wariancie należy traktować jak decyzję inwestycyjną obarczoną kosztem utopionym, a nie jak ustawienie, które łatwo skorygować w kolejnej fazie projektu. To pierwszy praktyczny test kompetencji, który warto przeprowadzić już na etapie zapytania ofertowego.

‍

Kontrola kosztów, której nie widać w ofercie: koszt zaangażowany i EAC

Prawdziwa kontrola kosztów na budowie nie polega na tym, ile już wydano, lecz na tym, ile projekt będzie kosztować na końcu. Kluczowe są dwie wielkości rzadko wymieniane w ofertach: koszt zaangażowany (podpisane umowy z podwykonawcami i zamówienia, których faktury jeszcze nie przyszły) oraz szacowany koszt na zakończenie, czyli EAC.

Dyscyplinę tego typu opisuje metodyka zarządzania kosztami i project controls rozwijana przez AACE International: projekt trzeba mierzyć prognozą, a nie tylko historią.

‍

‍

Dobrze skonfigurowany Dynamics 365 pokazuje koszt zaangażowany w widoku projektu w chwili podpisania umowy z podwykonawcą, a nie dopiero po wpłynięciu faktury. Dla kierownika kontraktu i dyrektora finansowego to instrument wczesnego ostrzegania: w momencie podpisu wiadomo już, jaka część budżetu została nieodwołalnie związana, nawet jeśli żadna płatność nie wyszła. Projekt, który patrzy wyłącznie na koszt poniesiony, widzi jedynie przeszłość i systematycznie zaniża rzeczywiste zaangażowanie, przez co przekroczenie budżetu ujawnia się z opóźnieniem kilku miesięcy, gdy przestrzeń manewru już się zamknęła.

EAC jest z kolei liczbą, wokół której powinno obracać się zarządzanie każdym kontraktem: o marży decyduje nie koszt dotychczasowy, lecz wiarygodna prognoza kosztu na zakończenie, aktualizowana o rzeczywisty postęp, znane ryzyka i podpisane zobowiązania. Warto przy tym traktować każdy kontrakt jak osobny rachunek wyników, a nie worek na koszty rozliczany zbiorczo na koniec okresu: projekt ma własne przychody rozpoznawane w czasie, własne koszty, własną marżę i własną prognozę, a rolą systemu jest utrzymywanie tego rachunku na bieżąco. Taka konstrukcja zmienia charakter przeglądów projektowych, bo zamiast rozmowy o tym, co się wydarzyło, zespół dyskutuje o tym, jak zamknie się kontrakt i co należy zrobić dzisiaj, aby prognozowany wynik obronić.

Wskaźniki earned value, CPI i SPI, przekładają rozjazd między planem a wykonaniem na wczesny, mierzalny sygnał, a ich wartość polega na tym, że powstają automatycznie z danych transakcyjnych, nie z comiesięcznego uzgadniania arkuszy. Dla zarządu istotne jest to, że taki układ przenosi środek ciężkości rozmów projektowych z przeszłości na przyszłość: przedmiotem przeglądu przestaje być samo wykonanie budżetu do dnia dzisiejszego, a staje się nim wiarygodność prognozy zamknięcia oraz lista działań, które tę prognozę mają obronić.

‍

Przychód na budowie liczy się inaczej

Firma budowlana nie rozpoznaje przychodu w momencie wystawienia faktury, lecz według zaawansowania kontraktu (metoda procentu zaawansowania). To fundament rachunkowości kontraktów długoterminowych, którym zajmuje się m.in. Construction Financial Management Association. W praktyce oznacza to prowadzenie WIP (produkcji w toku) oraz kontrolę nadfakturowania i niedofakturowania: czy zafakturowano więcej, czy mniej, niż faktycznie zarobiono na etapie robót. System, który tego nie obsługuje, daje ładne faktury i błędny obraz rentowności, a partner, który nie mówi o zaawansowaniu i WIP przy pierwszej rozmowie, prawdopodobnie nie robił wcześniej wdrożenia w budownictwie.

Konsekwencje niewłaściwego rozpoznania przychodu wykraczają daleko poza estetykę sprawozdania. Kontrakt, w którym zafakturowano więcej, niż wynika z rzeczywistego zaawansowania, wykazuje przychód, który trzeba będzie dopiero „odpracować", co przy końcu projektu potrafi zamienić się w gwałtowną korektę marży i nieprzyjemną niespodziankę dla zarządu. Odwrotna sytuacja, niedofakturowanie, oznacza, że firma wykonała roboty, których jeszcze nie zamieniła na należność, a więc finansuje kontrakt z własnej gotówki, często nie zdając sobie z tego w pełni sprawy. Dla osoby odpowiedzialnej za wynik i płynność ta różnica ma podwójne znaczenie.

Po pierwsze, rzetelnie prowadzony WIP pokazuje prawdziwą rentowność każdego etapu, zanim projekt się domknie, i pozwala reagować na erozję marży w trakcie. Po drugie, zestawienie zarobionego z zafakturowanym jest bezpośrednim wskaźnikiem zapotrzebowania na kapitał obrotowy: portfel z systematycznym niedofakturowaniem sygnalizuje, że wzrost obrotów będzie wymagał rosnącego finansowania, nawet jeśli księgowo firma wykazuje zysk. Dobrze skonfigurowany Dynamics 365 wylicza WIP oraz pozycje nad- i niedofakturowania automatycznie, na podstawie zaawansowania i harmonogramu fakturowania, co pozwala domykać okresy sprawozdawcze szybciej i z większą pewnością.

‍

Zysk księgowy a gotówka dostępna na projekcie

Jedną z najgroźniejszych iluzji w zarządzaniu kontraktem jest utożsamianie zysku księgowego z gotówką, którą projekt faktycznie generuje. Rozpoznanie przychodu w czasie, według procentu zaawansowania, oznacza, że firma wykazuje wynik, zanim zainkasuje należność, a często zanim w ogóle wystawi fakturę za dany etap. W efekcie rentowny na papierze kontrakt może przez wiele miesięcy pochłaniać gotówkę: podwykonawcy i dostawcy oczekują płatności zgodnie z własnymi terminami, część należności pozostaje zamrożona w kaucjach gwarancyjnych, a inwestor rozlicza się według harmonogramu, który rzadko nadąża za tempem ponoszenia kosztów.

Dla dyrektora finansowego kluczowe jest więc równoległe czytanie dwóch obrazów tego samego projektu: rachunku wyników, który mówi o marży, oraz przepływu gotówki, który mówi o zdolności firmy do finansowania robót do momentu inkasa. System pokazujący wyłącznie zysk usypia czujność, ponieważ pozwala wierzyć, że dodatni wynik oznacza bezpieczeństwo finansowe, podczas gdy realnym ograniczeniem wzrostu bywa nie marża, lecz kapitał obrotowy. Dobrze zaprojektowane wdrożenie zestawia prognozę przychodu i kosztu z harmonogramem płatności i inkasa, dzięki czemu na poziomie pojedynczego kontraktu i całego portfela widać, kiedy projekt zacznie oddawać gotówkę, a kiedy będzie jej wymagał.

Ta wiedza przekłada się wprost na decyzje zarządu: negocjację zaliczek z inwestorem, ustawienie terminów płatności wobec podwykonawców oraz planowanie linii finansowania w skali portfela. Różnica między zyskiem a gotówką nie jest niuansem księgowym, lecz jednym z głównych źródeł ryzyka w budownictwie, a system, który jej nie uwidacznia, pozostawia zarząd bez narzędzia do zarządzania płynnością rosnącego portfela. Warto podkreślić, że najbardziej niebezpieczny bywa okres dynamicznego wzrostu: rosnący portfel rentownych kontraktów potrafi jednocześnie generować zysk i pogłębiać deficyt gotówki, ponieważ zapotrzebowanie na kapitał obrotowy rośnie szybciej niż inkaso.

‍

Zmiany, roszczenia i rezerwa na ryzyko

Największym cichym zabójcą marży na budowie są zmiany i roboty dodatkowe wykonywane, zanim zostaną wycenione i zatwierdzone. Jeśli zmiana trafia do systemu dopiero na etapie fakturowania, jej wpływ na budżet jest już nie do odzyskania. Wartość dobrego wdrożenia polega na tym, że rejestruje zmiany jako osobne pozycje kontraktu, wiąże je z budżetem i z akceptacją klienta oraz pokazuje ich wpływ na EAC. Mechanika utraty marży jest w praktyce prosta i powtarzalna: presja terminu skłania zespół do rozpoczęcia robót dodatkowych, zanim inwestor formalnie je zatwierdzi i wyceni, koszt jest ponoszony natychmiast, a odpowiadający mu przychód pozostaje niepewny, sporny lub odsuwany w czasie.

Każda zmiana niezarejestrowana w chwili powstania staje się roszczeniem trudnym do wyegzekwowania, a różnica między poniesionym kosztem a odzyskanym przychodem obciąża wynik. Dobrze skonfigurowany Dynamics 365 przełamuje ten schemat, wymuszając rejestrację zmiany jako odrębnej pozycji z własnym statusem, wartością, powiązaniem z budżetem pierwotnym oraz ścieżką akceptacji. Z tym samym mechanizmem wiąże się zarządzanie niepewnością kontraktu poprzez rezerwę na ryzyko, czyli contingency. Rezerwa nie jest ukrytym zapasem marży, który kierownik może dowolnie konsumować, lecz świadomie wydzieloną częścią budżetu przypisaną do zidentyfikowanych ryzyk: warunków gruntowych, cen i dostępności materiałów, wydajności podwykonawców czy niedokończonej dokumentacji.

System powinien rozróżniać budżet bazowy i rezerwę oraz pokazywać tempo jej uruchamiania względem postępu robót, ponieważ szybkie topnienie rezerwy na wczesnym etapie jest jednym z pierwszych sygnałów zbliżającego się przekroczenia. Dzięki temu EAC uwzględnia nie tylko koszty już znane, lecz także wycenioną ekspozycję na ryzyka jeszcze niezmaterializowane, a zarząd odróżnia kontrakt idący zgodnie z planem od takiego, który utrzymuje wynik wyłącznie dzięki konsumpcji rezerwy zawiązanej na starcie.

‍

Kaucje gwarancyjne i podwykonawcy

Budownictwo ma swoją specyfikę rozliczeń, której zwykły ERP nie obsługuje bez konfiguracji: kaucje gwarancyjne zatrzymywane z płatności (po stronie należności i zobowiązań), zwalniane po okresie gwarancyjnym, oraz rozliczenia z podwykonawcami w modelu zbliżonym do back-to-back. Partner z doświadczeniem w budownictwie skonfiguruje potrącenia kaucji, terminy ich zwolnienia i powiązanie płatności podwykonawcom z odbiorami, zamiast obiecywać, że „system to obsłuży". Znaczenie kaucji wykracza jednak poza samą mechanikę potrąceń i dotyka wprost kapitału obrotowego oraz przepływu gotówki, dlatego zasługuje na uwagę zarządu, a nie tylko działu księgowości.

Po stronie należności kaucja zatrzymana przez inwestora oznacza, że firma wykonała roboty, wykazała przychód i marżę, lecz części zapłaty nie zobaczy przez cały okres gwarancyjny, liczony niekiedy w latach. Po stronie zobowiązań firma zatrzymuje analogiczne kwoty swoim podwykonawcom, co częściowo równoważy efekt, lecz saldo netto kaucji w portfelu potrafi urosnąć do sumy istotnie obciążającej płynność, zwłaszcza w fazie dynamicznego wzrostu obrotów. Dla dyrektora finansowego kaucje są więc formą wymuszonego, długoterminowego finansowania inwestora ze środków wykonawcy, a system, który nie pokazuje ich salda, harmonogramu zwolnień i wpływu na gotówkę, pozostawia zarząd bez wiedzy o realnej wartości zamrożonego kapitału.

Dobrze skonfigurowany Dynamics 365 prowadzi kaucje jako wyodrębnione pozycje z przypisanymi terminami zwolnienia, dzięki czemu widać, kiedy i w jakiej wysokości środki wrócą do firmy oraz kiedy trzeba będzie zwolnić kaucje podwykonawcom. Powiązanie płatności podwykonawczych z odbiorami i z rozliczeniem wobec inwestora w modelu back-to-back chroni z kolei płynność w łańcuchu dostaw: firma nie płaci za etap, którego sama nie rozliczyła z zamawiającym, co ogranicza ryzyko finansowania podwykonawców z własnej gotówki.

‍

Ryzyko podwykonawcy i ryzyko koncentracji w portfelu

Generalny wykonawca powierza znaczną część wartości kontraktu podwykonawcom, przez co ryzyko realizacji przenosi się do łańcucha dostaw, a zły dobór lub upadłość podwykonawcy potrafi wywrócić rentowność i harmonogram całego projektu. Zarządzanie tym ryzykiem zaczyna się od widoczności: system powinien pokazywać, jaka część budżetu każdego kontraktu jest związana umowami podwykonawczymi, jaki jest status ich realizacji oraz jakie zobowiązania i kaucje wiążą firmę z każdym podwykonawcą. Bez tej wiedzy zarząd ocenia ryzyko intuicyjnie, tymczasem koszt zaangażowany zapisany w umowach podwykonawczych jest twardą miarą ekspozycji, która ujawnia się na długo przed pierwszą fakturą.

Osobnym, często niedocenianym zagadnieniem jest ryzyko koncentracji, i to w dwóch wymiarach jednocześnie. W wymiarze podwykonawczym firma, która na wielu kontraktach polega na tym samym podwykonawcy, kumuluje ekspozycję: jego problemy finansowe lub wydajnościowe uderzają nie w jeden, lecz w kilka projektów naraz, a system patrzący na kontrakty w izolacji tej kumulacji nie pokazuje. W wymiarze portfelowym ryzyko koncentracji dotyczy struktury portfela: udziału pojedynczego inwestora w przychodach, nagromadzenia projektów w jednym segmencie rynku lub jednoczesnego wejścia kilku dużych kontraktów w fazę maksymalnego zapotrzebowania na gotówkę.

Dla zarządu i rady nadzorczej są to informacje o charakterze strategicznym, ponieważ decydują o odporności firmy na pojedyncze zdarzenie. Dobrze skonfigurowany Dynamics 365, prowadzący spójne dane o kontraktach i podwykonawcach w jednym systemie, pozwala agregować tę ekspozycję na poziomie całego portfela: wskazać podwykonawców o największym łącznym udziale oraz inwestorów o największej koncentracji należności. Rolą partnera jest zaprojektowanie wymiarów analitycznych i raportów, które czynią ryzyko koncentracji widocznym, zanim się zmaterializuje, przenosząc zarządzanie nim z poziomu pojedynczego projektu na poziom decyzji o kształcie i dywersyfikacji portfela.

‍

Harmonogram: gdzie kończy się ERP

Uczciwa odpowiedź na pytanie o kontrolę harmonogramu brzmi: Dynamics 365 Project Operations planuje strukturę prac (WBS), budżet i zaangażowanie w czasie, ale do zaawansowanego harmonogramowania metodą ścieżki krytycznej firmy budowlane często integrują go z narzędziami takimi jak Microsoft Project czy Primavera. Partner, który twierdzi, że „jeden system zrobi wszystko, łącznie z pełnym harmonogramem budowy", zwykle upraszcza. Wartościowe wdrożenie łączy dane o postępie z harmonogramem tak, aby zaawansowanie robót, koszt i termin pokazywały spójny obraz, a nie żyły w trzech osobnych plikach. Z perspektywy osoby odpowiedzialnej za wynik istota integracji nie polega na tym, w którym narzędziu powstaje harmonogram, lecz na tym, że opóźnienie robót natychmiast przekłada się na prognozę kosztu i przychodu.

Czas na budowie jest bowiem kosztem: przedłużenie realizacji oznacza dłuższe utrzymanie zaplecza, sprzętu i nadzoru, ryzyko kar umownych oraz przesunięcie inkasa, a więc pogorszenie zarówno marży, jak i przepływu gotówki. Wiarygodność prognozy kosztu na zakończenie nie bierze się jednak z samego modelu, lecz z jakości danych, które go zasilają, a te powstają na placu budowy. Jeżeli postęp robót raportowany jest z opóźnieniem, szacowany „na oko" lub domykany dopiero na koniec miesiąca, nawet najlepiej skonfigurowany EAC opiera się na przeszłości i pozoruje precyzję, której nie ma. Rzetelna prognoza wymaga, aby rzeczywiste zaawansowanie, zużyte materiały, przepracowane roboczogodziny oraz stan realizacji umów podwykonawczych trafiały do systemu blisko momentu ich powstania.

Dlatego dojrzałe wdrożenie przywiązuje szczególną wagę do prostoty rejestracji postępu i do minimalizacji podwójnego wprowadzania danych, które jest głównym powodem opóźnień w raportowaniu. Im mniej wysiłku wymaga rzetelny wpis, tym świeższe dane trafiają do prognozy i tym bardziej EAC odzwierciedla rzeczywistość, a nie założenia sprzed miesięcy.

‍

Jak wybrać firmę do wdrożenia na budowie

Po powyższym kryteria wyboru partnera przestają być ogólne. Firmę wdrożeniową Dynamics 365 dla budownictwa oceniaj po tym, czy potrafi rozmawiać o rachunkowości kontraktów, a nie tylko o modułach:

‍

‍

Jeśli partner odpowiada na te pytania konkretami, zna budowę. Jeśli ucieka w ogólniki o „elastyczności systemu", ryzyko rośnie. Dla zarządu tabela powyżej jest w istocie narzędziem due diligence wobec wykonawcy wdrożenia, a każde pytanie weryfikuje inny obszar kompetencji, który później przełoży się na wynik. Warto obserwować nie tylko treść odpowiedzi, lecz także to, czy partner sam wprowadza wątki, których nie było w zapytaniu: rezerwę na ryzyko, saldo kaucji w portfelu, koncentrację podwykonawców, różnicę między zyskiem a gotówką na projekcie.

Firma, która realizowała wdrożenia w budownictwie, mówi o tych zagadnieniach z własnej inicjatywy, ponieważ zna miejsca, w których typowe wdrożenie ERP zawodzi w zetknięciu z realiami kontraktu. Równie istotne jak deklaracje jest to, jak partner planuje przełożyć rachunkowość kontraktów na konfigurację: strukturę wymiarów finansowych, reguły rozpoznania przychodu, obieg danych z placu budowy oraz raporty zarządcze dla kierownika kontraktu i dyrektora finansowego. Referencje pełnią tu rolę końcowego testu: wdrożenie u generalnego wykonawcy lub firmy inżynieryjnej dowodzi, że partner zmierzył się z pełną złożonością kontraktów budowlanych w rzeczywistej skali, a nie jedynie odtworzył standardową konfigurację. Wybór partnera jest w istocie decyzją o tym, kto pomoże firmie zbudować zdolność do sterowania rentownością projektów, dlatego zasługuje na taką samą staranność, jaką zarząd poświęca wyborowi kluczowego podwykonawcy.

Warto również ocenić, jak partner podchodzi do wdrożenia jako do projektu zmiany organizacyjnej, a nie wyłącznie instalacji oprogramowania: kto po stronie firmy zostanie właścicielem prognozy kosztu na zakończenie, w jaki sposób kierownicy budów zostaną przygotowani do rzetelnego raportowania postępu oraz jak nowe reguły rozpoznania przychodu i obsługi zmian wejdą w codzienną praktykę zespołów. Wdrożenie, które poprawnie skonfiguruje system, lecz nie zmieni sposobu pracy, pozostaje inwestycją niewykorzystaną.

‍

Który ERP dla budownictwa, inżynierii i biura projektowego

Dla firm inżynieryjno-budowlanych i biur projektowych trzon stanowi Dynamics 365 z Project Operations osadzonym na Finance & Operations: łączy finanse, koszty projektów, zakupy, podwykonawców i rozliczenia w jednym systemie. Biuro projektowe skorzysta przede wszystkim na ewidencji czasu, rozliczaniu projektów i fakturowaniu etapów, generalny wykonawca, na kontroli kosztów zaangażowanych, podwykonawcach i zmianach, a firma inżynieryjna, na powiązaniu projektu z budżetem i harmonogramem. Wspólny mianownik jest jeden: system ma pokazywać rentowność projektu w trakcie, a nie po jego zakończeniu.

Różnice w profilu tych organizacji przekładają się jednak na odmienne akcenty wdrożenia. Biuro projektowe jest firmą, w której głównym kosztem jest czas ludzi, dlatego jego rentowność rozstrzyga się na dyscyplinie ewidencji czasu, właściwym przypisaniu godzin do projektów oraz na fakturowaniu etapów zgodnie z postępem prac. Generalny wykonawca działa w modelu, w którym większość wartości przechodzi przez podwykonawców i materiały, więc środek ciężkości wdrożenia przesuwa się na koszt zaangażowany, obsługę zmian, kaucje i rozliczenia back-to-back, a rachunek wyników projektu jest w dużej mierze rachunkiem zarządzania łańcuchem dostaw.

Firma inżynieryjna łączy oba światy, ponieważ realizuje projekty o wysokim udziale pracy własnej i jednocześnie o znaczącej ekspozycji na harmonogram i ryzyko techniczne, co czyni powiązanie budżetu, zaawansowania i terminu szczególnie istotnym. Wartość jednej platformy polega na tym, że wszystkie te profile korzystają z tego samego, spójnego zestawu danych o kosztach, przychodzie i gotówce, a zarząd grupy prowadzącej działalność w kilku modelach jednocześnie otrzymuje porównywalny obraz rentowności niezależnie od charakteru projektu. Dobór właściwej konfiguracji dla każdego z tych profili, przy zachowaniu wspólnego rdzenia finansowego, odróżnia wdrożenie prowadzone przez partnera rozumiejącego budownictwo od standardowej instalacji systemu.

‍

Dlaczego ANEGIS

ANEGIS ma doświadczenie we wdrożeniach dla sektora budowlano-inżynieryjnego oraz w projektach realizowanych metodyką projektową, popartych statusem Microsoft Solutions Partner (Business Applications) i zespołem ponad 200 certyfikowanych ekspertów Microsoft. Przykładem jest wdrożenie dla NCC, jednej z wiodących skandynawskich firm budowlanych (ponad 18 500 pracowników, działalność w dziewięciu krajach), gdzie ANEGIS wdrożył Dynamics 365 Finance & Operations wraz z integracjami wymiany danych i automatyzacją procesów kontraktowych. To skala i typ złożoności, w których liczy się rozumienie kontraktów, a nie tylko konfiguracja systemu.

Dla zarządu istotne jest, że taki projekt wymaga jednoczesnego panowania nad wieloma wymiarami opisanymi powyżej: rozpoznaniem przychodu w czasie, kosztem zaangażowanym, obsługą zmian, kaucjami oraz rozliczeniami w rozbudowanym łańcuchu podwykonawców, i to w środowisku wielospółkowym oraz wielowalutowym. Wdrożenie o tej charakterystyce nie sprowadza się do uruchomienia modułów, lecz do zbudowania spójnego obiegu informacji, w którym plac budowy zasila prognozę, prognoza zasila rachunek wyników projektu, a rachunek wyników składa się na obraz rentowności całego portfela dostępny zarządowi. Doświadczenie zdobyte w realizacji o takiej skali przekłada się na znajomość problemów, które w mniejszych wdrożeniach nie ujawniają się z taką siłą: standaryzacji procesów kontraktowych między jednostkami oraz automatyzacji rozliczeń tam, gdzie ich ręczna obsługa nie skalowałaby się wraz z liczbą projektów.

Połączenie kompetencji technologicznej z rozumieniem rachunkowości kontraktów budowlanych pozwala przeprowadzić firmę przez wdrożenie w sposób, który po zakończeniu projektu nie wymaga poprawiania fundamentów. Dla zarządu wartość takiego wdrożenia mierzy się nie liczbą uruchomionych funkcji, lecz tym, o ile wcześniej firma dowiaduje się o zagrożeniu marży i o ile pewniej planuje zapotrzebowanie na kapitał obrotowy w kolejnych kwartałach.

Porozmawiajmy o wdrożeniu dla budownictwa

‍