Projekt statku to setki rysunków, tysiące rewizji i dziesiątki osób, które muszą wiedzieć, która wersja dokumentu jest aktualna. Gdy oferta powstaje w jednym arkuszu, lista rysunków w drugim, godziny w trzecim, a uwagi weryfikatora giną w skrzynce mailowej, zarządzanie biurem projektowym zamienia się w ciągłe odtwarzanie, kto, co i kiedy zmienił.
W tym artykule pokazujemy na konkretnym scenariuszu, jak biuro projektowe branży morskiej prowadzi projekt statku wielozadaniowego w systemie Flowgres: od zapytania ze stoczni, przez strukturę WBS i obieg rewizji, aż po protokół przekazania i rozliczenie godzin. Pełny opis tego przypadku użycia znajdziesz na stronie Flowgres dla biura projektowego.
Najważniejsze wnioski
- Jeden spójny proces – od szansy sprzedaży w CRM do zamknięcia projektu – eliminuje wielokrotne wprowadzanie tych samych danych.
- Struktura WBS z podziałem na działy (np. 100–500) porządkuje dokumentację, budżet godzinowy i odpowiedzialność.
- Każda rewizja dokumentu ma właściciela, status i historię, dzięki czemu wiadomo, która wersja jest aktualna i co blokuje proces.
- Kierownik projektu widzi postęp na bieżąco: burndown, raport tygodniowy rewizji i alerty o przekroczeniach terminów lub budżetu.
- Klient i stocznia odbierają dokumentację przez portal, a pełna historia zmian ułatwia odbiory i audyty.
- Zespół wdrożeniowy Flowgres prowadzi firmę przez całe wdrożenie – od przygotowania zespołu po pełną konfigurację systemu.
Spis treści
- Dlaczego biuro projektowe w branży morskiej potrzebuje jednego systemu?
- Jeden przepływ: od zapytania ofertowego do odbioru dokumentacji
- Scenariusz krok po kroku: projekt statku wielozadaniowego
- Kto pracuje w systemie i za co odpowiada?
- Jak Flowgres pilnuje obiegu dokumentacji?
- Co zyskuje biuro projektowe?
- Kompletne wdrożenie z zespołem Flowgres
- Najczęściej zadawane pytania
Dlaczego biuro projektowe w branży morskiej potrzebuje jednego systemu?
Biuro projektujące statki pracuje jednocześnie w kilku wymiarach. Jest kontrakt ze stocznią lub armatorem, z terminami i kamieniami milowymi. Jest podział pracy na dyscypliny – kadłub, maszynownię, wyposażenie, elektrykę, konstrukcję. Jest wreszcie dokumentacja techniczna, w której każdy rysunek przechodzi przez kolejne rewizje, weryfikację i oficjalne wydanie.
Skalę dobrze pokazuje przykład jednego z biur branży morskiej korzystających z Flowgres: ponad 500 zrealizowanych projektów, ponad 74 tys. dokumentów technicznych, ponad 80 tys. obsłużonych rewizji, ponad 85 tys. komentarzy i ponad 400 aktywnych użytkowników. Przy takiej liczbie elementów arkusze i poczta przestają wystarczać.
Typowe sygnały, że obecne narzędzia nie nadążają
- Dane klienta i kontraktu są przepisywane ręcznie z oferty do projektu, a potem do list dokumentów.
- Nie wiadomo od razu, kto aktualnie pracuje nad danym rysunkiem i na jakim jest on etapie.
- Uwagi weryfikatora trafiają mailem, przez co trudno je powiązać z konkretną rewizją.
- Postęp projektu i wykorzystanie budżetu godzinowego trzeba składać ręcznie przed każdym spotkaniem.
- Przy odbiorze lub audycie odtworzenie historii zmian zajmuje dni zamiast minut.
Jeden przepływ: od zapytania ofertowego do odbioru dokumentacji
We Flowgres cała praca biura projektowego toczy się w jednym procesie, w którym każdy etap korzysta z danych utworzonych wcześniej. Proces dzieli się na pięć obszarów:
- CRM i sprzedaż – zapytanie od stoczni lub armatora, rejestracja szansy sprzedaży, kalkulacja oferty, wewnętrzna akceptacja, negocjacje i podpisanie kontraktu.
- Uruchomienie projektu – założenie projektu, struktura WBS z podziałem na działy i dyscypliny, przypisanie kierownika projektu i kierowników działów, budżet godzinowy, harmonogram i alokacja zasobów.
- Dokumentacja techniczna – lista rysunków według typów, przypisanie inżynierów, terminy kontraktowe i wewnętrzne, kolejne rewizje (A, B, C…) oraz pliki CAD i PDF.
- Weryfikacja i QA – przekazanie rewizji do sprawdzenia, uwagi w wątkach komentarzy, poprawki, zatwierdzenie i wydanie dokumentu.
- Odbiór i raporty – protokół przekazania (transmittal), potwierdzenie odbioru przez klienta, raporty postępu, fakturowanie według kamieni milowych i archiwizacja.
Co to oznacza w praktyce? Oferta jest automatycznie powiązana z projektem, projekt korzysta z zebranych wcześniej danych klienta, dokumentacja opiera się na strukturze WBS, a rewizje są trwale powiązane z dokumentami. Raporty powstają na bieżąco z rzeczywistych danych, a nie z ręcznie aktualizowanych zestawień.
Scenariusz krok po kroku: projekt statku wielozadaniowego
Poniższy przykład pokazuje, jak w systemie przebiega projekt statku typu Multipurpose Subsea Support Vessel – od pierwszego zapytania stoczni po zamknięcie projektu.
Krok 1. Pozyskanie kontraktu (CRM, dyrektor handlowy)
Stocznia składa zapytanie, a dyrektor handlowy rejestruje szansę sprzedaży w module CRM. Pipeline prowadzi ją przez etapy Opportunity → Quoted → Approved → Contract Won. System przechowuje historię wersji ofertowych z dokumentami, kalkulację, protokoły spotkań i negocjacji, a także obsługuje waluty i kursy wymiany. Gdy kontrakt zostaje wygrany, automatycznie powstaje zamówienie z numerem kontraktu, datami i wartością.
Krok 2. Uruchomienie projektu (kierownik projektu)
Kierownik projektu zakłada projekt i uzupełnia dane statku, takie jak numer IMO, numer budowy i parametry jednostki. Następnie buduje WBS z podziałem na działy, np. 100 (część podstawowa), 200 (maszynownia), 300 (wyposażenie), 400 (elektryka) i 500 (konstrukcja). Ustala budżet godzinowy z podziałem na okresy, daty kontraktowe oraz tygodniową alokację inżynierów. Status projektu zmienia się z Planned na At work.
Krok 3. Lista dokumentacji (kierownicy działów)
Kierownicy działów tworzą rejestr dokumentów według typów: rysunki ogólnego rozkładu (ARR), rysunki elektryczne (ELEC), specyfikacje (SPEC), obliczenia stateczności i wytrzymałości (STAB, FEM, CALC), instrukcje (MAN), schematy ISO czy dokumenty NC dla obróbki CNC. Flowgres obsługuje ponad 20 typów dokumentów. Każdy z nich otrzymuje numer według wzorca automatycznej numeracji, powiązanie z WBS i działem, odpowiedzialnego inżyniera oraz termin kontraktowy i wewnętrzny. Dokumenty można grupować i definiować między nimi zależności.
Krok 4. Praca nad rewizjami (inżynier, weryfikator)
Inżynier zmienia status rewizji na At work i rejestruje czas pracy bezpośrednio przy niej. Po zakończeniu przekazuje dokument do weryfikacji (Checking). Kierownik działu dodaje komentarze z uwagami i, jeśli trzeba, odsyła rewizję do poprawki. Po korekcie dokument wraca do sprawdzenia, a po zatwierdzeniu otrzymuje status Issued i staje się dostępny dla klienta. Osobno definiowane są role odpowiedzialnego, wystawiającego i zatwierdzającego, a system zestawia estymowany czas pracy z rzeczywistym.
Krok 5. Monitoring i raporty (kierownik projektu)
Kierownik projektu śledzi postęp na wykresie burndown, który porównuje godziny zaplanowane ze zrealizowanymi. Raport tygodniowy pokazuje liczbę rewizji wydanych, w trakcie i opóźnionych. System sygnalizuje przekroczenie budżetu lub terminów (SLA), a widgety statystyk pokazują produktywność w podziale na działy i inżynierów. Więcej o tym obszarze przeczytasz na stronie Raporty i analizy.
Krok 6. Odbiór i fakturowanie (PM, klient, stocznia)
Po osiągnięciu kamienia milowego – np. wydaniu dokumentacji klasyfikacyjnej – system generuje protokół przekazania (transmittal). Klient potwierdza odbiór przez portal. Zrealizowane godziny są porównywane z budżetem na potrzeby rozliczenia, a fakturowanie odbywa się według kamieni milowych. Po zakończeniu projektu dokumentacja trafia do archiwum, a projekt otrzymuje status Finished.
Kto pracuje w systemie i za co odpowiada?
Każda rola widzi w systemie to, czego potrzebuje na swoim etapie projektu. W opisywanym scenariuszu wyróżniamy sześć ról:
- Dyrektor handlowy – rejestruje szanse sprzedaży, przygotowuje oferty, prowadzi negocjacje i podpisuje kontrakt (etap: CRM i sprzedaż).
- Kierownik projektu – konfiguruje projekt, ustala budżet godzinowy i harmonogram, alokuje zasoby i śledzi postęp (uruchomienie, dokumentacja, odbiór i raporty).
- Kierownik działu – przydziela zadania inżynierom w swojej dyscyplinie, kontroluje postęp i weryfikuje dokumentację (dokumentacja, weryfikacja).
- Inżynier / projektant – tworzy rysunki i dokumenty, prowadzi kolejne rewizje, rejestruje czas i komentuje (dokumentacja techniczna).
- QA / weryfikator – sprawdza rewizje, zatwierdza je i wydaje gotowe dokumenty (weryfikacja, odbiór).
- Klient / stocznia – ma dostęp wyłącznie do wybranych projektów; zgłasza zapytania, odbiera dokumentację i komentuje rewizje przez portal (sprzedaż, odbiór).
Komunikacja odbywa się w kontekście pracy: wątki komentarzy są przypisane do konkretnych dokumentów i rewizji, a powiadomienia informują o zmianach statusów i nowych uwagach. Uzupełnieniem jest wewnętrzny komunikator i tablica informacyjna dla działów i firm – więcej na stronie Komunikacja zespołu.
Jak Flowgres pilnuje obiegu dokumentacji?
Każdy dokument i każdy projekt ma jasno zdefiniowany cykl życia. Dzięki statusom w każdej chwili wiadomo, na jakim etapie jest praca, kto odpowiada za kolejny krok i czy projekt idzie zgodnie z planem.
Statusy rewizji dokumentu
- New – rewizja utworzona, prace jeszcze nie ruszyły.
- To Do – zadanie przydzielone, czeka w kolejce; wiadomo, kto je wykona.
- At work – projektant aktywnie pracuje nad rysunkiem lub dokumentem.
- Checking – dokument w weryfikacji pod kątem poprawności i zgodności z wymaganiami.
- Pending – prace wstrzymane w oczekiwaniu na decyzję, dane wejściowe lub odpowiedź klienta albo innego działu.
- Issued – rewizja zatwierdzona i oficjalnie wydana, gotowa do przekazania.
- Finished – rewizja zamknięta, z pełną historią zmian w archiwum.
Dodatkowo rewizję można wstrzymać (Hold) lub anulować (Canceled) na dowolnym etapie, np. przy zmianie zakresu.
Statusy projektu
Projekt przechodzi przez etapy New → Planned → At work → Finished. Na etapie wyceny może mieć status Tender (projekt przetargowy), a w razie potrzeby zostać czasowo wstrzymany (Hold), np. w oczekiwaniu na decyzję klienta.
Taki model daje cztery rzeczy, których trudno oczekiwać od arkusza: wiadomo, kto w danym momencie pracuje nad dokumentem; od razu widać wąskie gardła; system przechowuje pełną historię zmian i decyzji; a raport postępu powstaje automatycznie.
Co zyskuje biuro projektowe?
Jedno źródło informacji
Dane klienta, projektu, dokumentacji, rewizji i raportów pozostają powiązane przez cały cykl życia projektu. Zespół zawsze pracuje na aktualnych informacjach.
Pełna kontrola nad dokumentacją
Każdy dokument ma właściciela, status, historię zmian i powiązanie z projektem. Łatwo ustalić, kto odpowiada za dany etap i która wersja jest obowiązująca.
Mniej pracy administracyjnej
Informacje wprowadzone raz – w ofercie, w danych klienta czy w WBS – są wykorzystywane na kolejnych etapach bez ręcznego przepisywania.
Większa przewidywalność projektu
Kierownik projektu ma bieżący wgląd w postęp, wykorzystanie budżetu godzinowego, status dokumentacji i ewentualne opóźnienia, zanim przełożą się one na termin kontraktowy.
Lepsza współpraca zespołów
Handlowcy, kierownicy, projektanci, weryfikatorzy i klient korzystają z tych samych danych, każdy w zakresie odpowiednim dla swojej roli.
Gotowość do odbiorów i audytów
Historia rewizji, uwag i decyzji jest dostępna przez cały czas realizacji i po jej zakończeniu, co ułatwia odbiory i odtworzenie przebiegu prac.
Kompletne wdrożenie z zespołem Flowgres
Sam system to dopiero początek. Zespół wdrożeniowy Flowgres zapewnia kompletne wdrożenie i sprawnie przeprowadza firmę przez cały proces implementacji – od analizy procesów biura, przez przygotowanie zespołu na zmianę sposobu pracy, aż po wszystkie niezbędne konfiguracje: strukturę WBS i działów, typy dokumentów i wzorce numeracji, statusy rewizji, role i uprawnienia, budżety godzinowe oraz dostęp dla klientów i stoczni.
Dużą wagę przykładamy do mentalnego przygotowania zespołu. Nowe narzędzie działa naprawdę dobrze dopiero wtedy, gdy projektanci, weryfikatorzy i kierownicy rozumieją, dlaczego zmienia się sposób pracy i co dzięki temu zyskują. Dlatego wdrożenie to nie tylko konfiguracja, ale też wspólne ustalenie zasad i wsparcie użytkowników na starcie.
Chcemy być Twoim partnerem na ścieżce rozwoju i skalowania biznesu – nie tylko dostawcą oprogramowania. Gdy biuro rośnie, dochodzą nowe działy, typy projektów czy klienci, system rozwija się razem z nim.
Zobacz ten scenariusz na przykładzie własnego biura
Opisany przypadek dotyczy biura projektującego statki, ale ten sam model – CRM, WBS, rejestr dokumentów, rewizje z workflow QA, rozliczanie godzin i raporty – sprawdza się wszędzie tam, gdzie efektem pracy jest wielodyscyplinarna dokumentacja techniczna. Szczegóły, interaktywny scenariusz i opis ról znajdziesz na stronie Zarządzanie biurem projektowym – Flowgres.
Chcesz sprawdzić, jak taki proces wyglądałby w Twojej firmie? Umów bezpłatną prezentację Flowgres – pokażemy system na przykładzie Twoich projektów i dokumentacji.
Najczęściej zadawane pytania
Czy Flowgres zastępuje oprogramowanie CAD?
Nie. Flowgres nie służy do rysowania, tylko do zarządzania tym, co dzieje się wokół rysunków: rejestrem dokumentów, rewizjami, statusami, odpowiedzialnością, czasem pracy i przekazaniem klientowi. Pliki CAD i PDF są załączane do konkretnych rewizji.
Jak Flowgres pomaga kontrolować budżet godzinowy projektu?
Budżet godzinowy jest ustalany przy uruchomieniu projektu, z podziałem na działy i okresy. Inżynierowie rejestrują czas bezpośrednio przy rewizjach, a system zestawia estymację z rzeczywistym czasem, pokazuje postęp na wykresie burndown i sygnalizuje przekroczenia.
Czy klient lub stocznia mogą mieć dostęp do systemu?
Tak. Użytkownicy po stronie klienta mają dostęp wyłącznie do wybranych projektów. Mogą zgłaszać zapytania, odbierać wydaną dokumentację i komentować rewizje przez portal, bez wglądu w pozostałe dane biura.
Jakie typy dokumentów obsługuje system?
Rejestr obejmuje ponad 20 typów dokumentów, m.in. ARR, ELEC, STAB, SPEC, ISO, NC, FEM, CALC i MAN. Każdy typ może mieć własny wzorzec automatycznej numeracji.
Czy ten model pasuje tylko do branży morskiej?
Scenariusz powstał na bazie biura projektującego statki, ale struktura WBS, rejestr dokumentów i workflow rewizji odpowiadają potrzebom każdego biura inżynieryjnego pracującego nad wielodyscyplinarną dokumentacją techniczną. Zakres konfiguracji ustalany jest podczas analizy przedwdrożeniowej.
Przeczytaj także
