Michał Zalewski
Tym razem postanowiłem poruszyć umysły nieszablonowymi określeniami, niecodziennymi porównaniami czy też kontrowersyjnymi tezami. Zacznę od dość zaskakującej, przynajmniej na pierwszy rzut oka, ale dobrze przemyślanej i moim zdaniem trafnej definicji osoby inżyniera uruchomieniowego oraz tego, czym powinien się zajmować w procesie inwestycyjnym.
Trudności, pułapki i szanse
Pomysł na sformułowanie takiej definicji pojawił się z potrzeby wypełnienia luki, nie spotkałem bowiem takowej informacji w polskiej inżynierskiej rzeczywistości. Kim zatem jest i czym zajmuje się inżynier uruchomieniowy? Moim zdaniem inżynier uruchomieniowy to osoba, której zadaniem jest określenie, zaplanowanie, pomoc w przeprowadzeniu i udokumentowaniu zintegrowanego, wielobranżowego procesu uruchomienia obiektu i instalacji będących na jego wyposażeniu.
To skomplikowane, więc rozłóżmy definicję na czynniki pierwsze. Najpierw przedmiot, czyli proces uruchomienia. Tutaj zapewne wszystko jasne, trzeba wszystko uruchomić. Wielobranżowy to też oczywiste. Najczęściej uruchomienie dotyczy systemów wielu branż jednocześnie i wszystko trzeba robić w tym samym czasie. Skąd więc pomysł na określenie zintegrowany? Czy nie lepiej określić jednocześnie? Otóż nie, przywołam również moją definicję integracji z numeru 5/2020 „a&s Polska”: Integracja niezależnych systemów to takie ich połączenie, dzięki któremu osiągamy dodatkowe funkcjonalności niedostępne dla systemów niezintegrowanych.
W określeniu zintegrowany proces uruchomieniowy mamy ten sam powód użycia tego sformułowania. Każda branża (pakiet wentylacyjny, elektryczny, automatyki HVAC) dobrze wie, co i jak ma uruchomić. Ale z osobna, bez ścisłego współdziałania z innymi, albo nie jest w stanie tego zrobić, a już na pewno nie w odpowiednio krótkim czasie. Stąd świadome użycie słowa zintegrowany, bo w tym współdziałaniu jest ogromna wartość dodana, niedostępna przy jego braku.
Przejdziemy do zadań inżyniera uruchomieniowego z przytoczonej definicji.
Określenie procesu uruchomieniowego
Trzeba sporządzić pełną listę urządzeń, systemów, elementów budynku, które muszą być uruchomione dla osiągnięcia zakładanej funkcjonalności obiektu. Lista ta musi uwzględniać również podsystemy i zbiorcze elementy poszczególnych systemów (poszczególne szafy automatyki w systemie BMS, centrale, podcentrale i pętle w systemie SSP, maszynownie, zaworownie, sekcje i podsekcje instalacji tryskaczowej itp.). Przecież to wszystko jest w projekcie, więc po co? Przede wszystkim po to, by je zidentyfikować i określić w jednym dokumencie, który nazywam planem uruchomień. Przygotowanie takiego planu poprzedza analiza projektów wykonawczych poszczególnych branż, opisów projektu budowlanego, architektonicznego, warunków ochrony ppoż., scenariuszy pożarowych, listy we/wy systemu SSP, opisów algorytmów pracy poszczególnych instalacji itp.
Z doświadczenia wiem, że zawsze w projekcie taka analiza wskaże tematy uruchomieniowe, których nikt wcześniej nie zauważył, np. centralka pogodowa w systemie sterowania oddymianiem grawitacyjnym dla bardzo skomplikowanego geometrycznie dachu, wspomniana w projekcie w opisie architektury jednym zdaniem: podział na odpowiednie grupy poszczególnych sekcji okien oddymiających będzie zależał od kierunki wiatru. I nic więcej nie znajdziemy w całym projekcie.
Zaplanowanie procesu uruchomieniowego
Gotowy plan uruchomień najpierw przekształcamy w harmonogram poprzez ustalenie kolejności i następstwa pracy uruchomieniowej na poszczególnych systemach, elementach oraz czas trwania poszczególnych zadań. Drugim zadaniem jest omówienie ze wszystkimi uczestnikami zintegrowanego procesu uruchomieniowego poszczególnych zadań im przynależnych oraz określenie i uzgodnienie zasad kolejności pracy. Nie da się uruchamiać tych systemów po kolei, gdyż nie ma na to odpowiednio dużo czasu, trzeba to umiejętnie robić równolegle. Zaczynamy od uruchomienia pętli modułowych SSP, automatyki wentylacji oraz układu sterowania klapami oddymiającymi i bytowymi, koniecznie równolegle. Następnie przerywamy uruchomienia SSP, przeprowadzamy testy punktowe współdziałania interfejsów we/wy, dość krótkie, jeżeli wcześniej automatyka wentylacji była prawidłowo uruchomiona jako samodzielna, a wszystkie klapy zostały przetestowane elektromechanicznie. Następnie punktowo z SSP sprawdzamy po kolei każde z urządzeń.
To przykład dla zilustrowania procesu, natomiast wszystkie te i podobne aspekty trzeba szczegółowo omówić z inżynierami odpowiedzialnymi za poszczególne systemy i uzgodnić zintegrowanie działania. Słowo „uzgodnić” jest tutaj kluczowe. Do swojego planu trzeba przekonać możliwie największą liczbę osób, inaczej będą próby działania wg własnych pomysłów lub potrzeb, bez zwracania uwagi na główny cel lub priorytety.
I tutaj pierwsza pułapka: podobnie jak w integracji systemów, tak i w integracji uruchomień ważna jest spójność komunikacji. Przy próbie „poukładania” zespołu inżynierów zawsze dochodzi do spięć i konfliktów wynikających najczęściej wyłącznie z powodu braku prawidłowej komunikacji. To zadanie dla inżyniera uruchomieniowego, by połączyć czasem sprzeczne plany i interesy we wspólny zintegrowany cel.
Pomoc w przeprowadzeniu uruchomień
Celowo używam słowa „pomoc”. Zdarzyło mi się kilka razy, że moja propozycja współpracy jako inżyniera uruchomieniowego była źle zrozumiana. Wykonawca SSP stracił pracownika odpowiedzialnego za uruchomienie systemu (opracowanie matrycy sterowań i programowanie). Poproszono mnie o pomoc, oczekując, że zaprogramuję SSP. A to nie ta funkcja i nie te kompetencje. Owszem, inżynier uruchomieniowy musi znać zasady programowania systemów, by np. wspomóc programistę w doborze odpowiedniego planu adresacji, ale nie może koncentrować się tylko na programowaniu.
Podobnie dla wentylacji: inżynier uruchomieniowy nie mierzy wydajności wentylacji, tylko tak zaplanuje wcześniejsze działania, by umożliwić jej przeprowadzenie. W tym samym czasie nie można prowadzić uruchomień SSP (klapy odcinające wentylacji będą zamykały się przy każdym teście), nie można testować Systemu Zasilania Rezerwowego (SZR), Przeciwpożarowego Wyłącznika Prądu (PWP), agregatu, nie mówiąc o pracach pylących. Rolą inżyniera uruchomieniowego powinno być trochę arbitralne podzielenie czasu na uruchomienia poszczególnych pakietów, by nie powodowały kolizji lub konieczności powtarzania części prac.
Ktoś słusznie zauważy: przecież to już zostało zaplanowane. Racja, ale każdy projekt jest unikatowy, napotyka się nieoczekiwane problemy i niezbędna jest korekta planów, trzeba znajdować nowe rozwiązania dla nieoczekiwanych przeszkód lub problemów.
Udokumentowanie uruchomień
Nie jest to jedynie podpisanie protokołów końcowych, że wszystko działa. Ważne jest udokumentowanie problemów i usterek stwierdzanych podczas poszczególnych etapów uruchomień, a także opis podjętych działań naprawczych. Jest to ważne, ponieważ może mieć wpływ na prawidłową eksploatację budynku. Coraz więcej inwestorów nabiera świadomości, że taka wiedza jest cenna i w tych procesach wymaga aktywnego uczestnictwa nadzoru inwestorskiego. Ostatnio obserwuję również podobne działania generalnych wykonawców, gdyż oczekiwania wydłużania czasu gwarancji w budynkach i zapewnienia prowadzenia czynności serwisowych (nie mylić z serwisem eksploatacyjnym) przez okres gwarancji wymuszają przygotowania do sprawnego procesu usuwania usterek.
Brak informacji z uruchomień może powodować konieczność ponownego przeprowadzania badań, testów itp., bo ich wyniki mogą być pomocne w szukaniu przyczyn awarii. Co ważne, ten fakt może rzutować na bezpieczeństwo budynku lub osób w nim przebywających. Przykłady: inaczej potraktujemy awarię zaciętej klapy oddymiającej, jeżeli to jest jej pierwsze zacięcie, wezwiemy serwis do naprawy czy kontroli, inaczej zaś, gdy w dokumentach uruchomieniowych będzie wskazane, że dana klapa już na początku wykazywała problemy. Inaczej podejdziemy do szukania przyczyny zakłóceń magistrali komunikacyjnej, jeżeli będziemy mieli pewność, że na początku działała poprawnie, a inaczej, jeśli w trakcie testów zostały już odnotowane problemy, np. powtarzające się przy określonych testach strefy dymowej. Dlatego warto dokumentować pisemnie wyniki testów i sprawdzeń, ta wiedza może być pomocna. I argument najważniejszy: warto posiadać kopie takich dokumentów w przypadku sporów, poważnych awarii oraz (odpukać) tragicznych zdarzeń na terenie obiektu.
Dokumentowanie uruchomień może być odbierane jako niepotrzebna „papierologia”, ale jeżeli potrafimy wspomóc proces poprzez sporządzenie wzorów list kontrolnych i czynności, mając gotowe do wypełnienia formularze testów, zyskamy większe zrozumienie i aprobatę. Na tym właśnie polega oferowana przez inżyniera uruchomieniowego pomoc w uruchomieniach – nie można dać się wciągać w bezpośrednie uruchomienia, to nie twoja rola, zaplanuj szczegółowe plany testów i przygotuj gotowe formularze. Co ważne, „spersonalizowane”, czyli przystosowane do konkretnego obiektu, konkretnych systemów i rozwiązań. Nie będzie akceptacji twoich pomysłów, jeżeli check lista uruchomieniowa będzie zawierała pozycje, w które należy wpisywać wynik „Nie dotyczy”.
Inżynier uruchomieniowy nie powinien głęboko angażować się w bezpośrednie uruchomienia poszczególnych elementów. Jeżeli jednak posiadasz wiedzę szczegółową, to dziel się nią z innymi. Pokazuj, jak można coś zaprogramować szybciej, lub pomagaj w wyszukiwaniu sposobów kontynuowania testów po napotkaniu problemów. Jeżeli nie dojechała połowa sygnalizatorów akustycznych, nie przerywaj testów współdziałania, można zainstalować po jednym na każdym końcu linii, w najgorszym wypadku w trakcie testów sprawdź multimetrem stan wyjść. Nie przerywaj testów, gdy linki bramy pożarowej zerwały się przy pierwszym uruchomieniu – trzymacz bramy można przetestować, przykładając do niego śrubokręt (koniecznie ferromagnetyczny). Ważne, by było to odnotowane w protokołach. Algorytmy zostaną przetestowane, a potem, po naprawie lub uzupełnieniu braków, wystarczy jeden test, by wiedzieć, że wszystko działa.
Przy planowaniu uruchomień trzeba pamiętać, że harmonogram to nie cyrograf, można i należy nad nim pracować i korygować, by dopasować go w fazie uruchomień. A jeżeli uda się dotrzymać daty końcowej, nikt nie będzie miał pretensji o małe korekty w trakcie.
Wróćmy do określenia procesu uruchomieniowego. Zdarzało mi się pominąć w tej fazie jakiś fakt lub oczywiste wątpliwości. Przykłady: nieprecyzyjne sformułowania scenariusza pożarowego, brak algorytmu pracy (np. automatyki chłodu lub wentylacji) i deklaracja, że programista wgra gotowy program, okazało się natomiast, że kaskada pracy układu wież nie uwzględniała rotacji, tylko załączanie zawsze wg zapotrzebowania tej samej kolejności. Żywotność układu dramatycznie spadła, bo pierwsza wieża wyeksploatowała się już po roku. Projektant myślał, że to sprawa oczywista, i nie napisał, a programista zaprogramował to, co otrzymał w wytycznych. Każde zbagatelizowanie identyfikacji lub nieprecyzyjność zapisów obracało się przeciwko jakości lub, co gorsza, było powodem problemów odbiorowych. Jeżeli więc coś zauważysz i masz wątpliwości, walcz uparcie o wyjaśnienie. Na papierze to tylko trochę więcej pracy projektanta, podczas uruchomień zaś to czas stracony na przeprogramowywanie i ponowne testy.
Nie każdy dostrzega walory i korzyści z zaproszenia inżyniera uruchomieniowego do pomocy. Moje doświadczenia są jednak takie, że coraz częściej udaje się zachęcić do współpracy przy projekcie. W przypadku dużych i skomplikowanych obiektów łatwiej przekonać do tego pomysłu, na łatwych jest mniej potrzeb. Jednak zawsze jest wiele problemów i trzeba być gotowym na duży wysiłek, pot i łzy, ale warto, bo satysfakcja jest ogromna.
Odważnych i z odpowiednim doświadczeniem zapraszam do zajęcia się tematem i promowania poprzez swoje oferty innowacyjnej pozycji w trakcie projektów. Mniej doświadczonych zapraszam do kontaktu, zadawania pytań, dzielenia się wątpliwościami. Wszystkich gorąco zachęcam do dyskusji.
 |
|
