Projekt pomieszczenia czystego przechodzi przez ręce wielu osób, zanim stanie się przestrzenią operacyjną, a w momencie, gdy obie strony uznają, że to druga strona jest odpowiedzialna za daną granicę, nikt już nie zarządza tą granicą. Nie chodzi o to, czy matryca odpowiedzialności istnieje na papierze, ale czy jest ona oparta na rzeczywistych punktach, w których następuje przekazywanie zadań, informacji i zatwierdzeń.

Przed nadaniem nazw należy wytyczyć granice projektu

Zanim do macierzy zostaną wprowadzone jakiekolwiek nazwiska lub stanowiska w firmie, zespół projektowy musi mieć jasny obraz tego, gdzie kończy się praca jednej strony, a zaczyna praca drugiej. Granice te nie pokrywają się z rolami organizacyjnymi. Ta sama firma może działać po obu stronach interfejsu — tworząc projekt, a następnie realizując go — a mimo to macierz musi rozdzielić te dwie pozycje, ponieważ w przypadku braku jasności wiążą się one z różnymi rodzajami ryzyka.

W projekcie pomieszczenia czystego powtarzają się dwa rodzaje granic. Granica fizyczna to miejsce, w którym spotykają się dostawa, prace na miejscu, montaż i testowanie: miejsce, w którym urządzenie przestaje być zakupionym elementem, a staje się czymś zamontowanym, podłączonym i gotowym do testów. Granica informacyjna to miejsce, w którym dokument lub zbiór danych przechodzi z rąk do rąk lub zmienia status: miejsce, w którym rysunek przechodzi od etapu sporządzenia do etapu uzgodnienia z sąsiednimi branżami, a następnie do etapu zatwierdzenia do realizacji. Traktowanie ich jako tego samego rodzaju granic powoduje niejasności, ponieważ strona, która coś rysuje, niekoniecznie jest tą samą stroną, która koordynuje to z innymi usługodawcami, ani też niekoniecznie tą samą stroną, która to zatwierdza.

Warunkiem decydującym o tym, w jaki sposób należy odwzorować granicę, jest to, czy praca lub informacja w danym punkcie zależy od wyników pracy innej strony, zanim będzie można kontynuować. W przypadku gdy granica jest samowystarczalna — jedna strona dostarcza, montuje i testuje bez konieczności uzyskania wkładu od kogoś innego na wcześniejszym etapie — wystarczające może być proste wskazanie właściciela. W przypadku gdy granica zależy od kolejności działań, np. przejście przez ścianę, które musi być dopasowane do wymiarów montażowych urządzenia, lub rysunek, który przed zatwierdzeniem musi zostać skoordynowany z układami mechanicznymi i elektrycznymi, matryca musi wyraźnie uwzględniać tę zależność, zamiast zakładać, że zostanie ona rozwiązana nieformalnie na miejscu budowy.

To właśnie ten etap mapowania decyduje o tym, ile wierszy będzie ostatecznie potrzebowała macierz. Macierz stworzona na podstawie ogólnej listy ról w firmie zazwyczaj nie uwzględnia wszystkich interfejsów, ponieważ grupuje działania według tego, kto je wykonuje, a nie według tego, gdzie faktycznie dochodzi do przekazywania zadań. Macierz stworzona na podstawie interfejsów fizycznych i informacyjnych ujawni granice, które w przypadku listy opartej na rolach zostałyby połączone w jedną pozycję – i właśnie tam zazwyczaj powstaje zakres zadań nieprzypisanych.

Należy oddzielić uprawnienia projektowe od obowiązków związanych z zaopatrzeniem i realizacją

Po wyznaczeniu granic kolejnym zadaniem jest ustalenie, kto sprawuje władzę w każdym z tych obszarów — a władza nie jest pojęciem jednolitym. Opracowanie projektu, koordynacja z innymi dziedzinami, zatwierdzenie go do użytku, wdrożenie tego, co przedstawia, oraz przetestowanie wdrożonego rozwiązania to pięć odrębnych obowiązków, a matryca odpowiedzialności, która łączy je w jedną kolumnę “podmiotu odpowiedzialnego”, nie uwzględnia w pełni obszarów, w których mogą pojawić się rozbieżności.

Uprawnienia projektowe dotyczą konkretnie tego, kto ma prawo określać, jak powinno wyglądać dane rozwiązanie — układ, specyfikację, wymiary interfejsu. Różni się to od uprawnień dostawczych, które dotyczą tego, kto dostarcza fizyczny sprzęt lub materiały, a także od uprawnień wykonawczych, które dotyczą tego, kto dokonuje instalacji, podłączenia i uruchomienia. Jedna strona może posiadać uprawnienia projektowe, nie posiadając jednocześnie uprawnień dostawczych ani wykonawczych, a inna strona może dostarczać sprzęt, nie mając żadnego wpływu na jego specyfikację. W przypadku gdy uprawnienia te nie są rozdzielone w matrycy, częstym źródłem niepowodzeń jest sytuacja, w której strona wykonująca prace zakłada, że intencje projektowe zostały już ustalone, podczas gdy strona posiadająca uprawnienia projektowe zakłada, że w trakcie realizacji pojawią się pytania, jeśli coś będzie niejasne.

Czynnikiem decydującym o tym, jak ściśle należy rozdzielić te zadania, jest stopień wzajemnej zależności między wynikami prac projektowych a ograniczeniami fizycznymi ujawnionymi w późniejszym etapie. W przypadku gdy projekt można sfinalizować niezależnie od warunków panujących na placu budowy, rozdzielenie tych obowiązków ma w praktyce mniejsze znaczenie, ponieważ prawdopodobieństwo wystąpienia konfliktu jest niewielkie. Natomiast gdy projekt musi uwzględniać warunki potwierdzone dopiero podczas montażu — prześwity, połączenia konstrukcyjne, przebieg instalacji — konieczne staje się wyraźne oddzielenie kompetencji projektowych od obowiązków wykonawczych, ponieważ ktoś musi mieć uprawnienia do decydowania, czy warunki panujące na placu budowy wymagają zmiany projektu, czy jedynie dostosowania na miejscu w ramach istniejącego zamierzenia.

Kwestia organu zatwierdzającego zasługuje na osobne omówienie. Zatwierdzenie rysunku lub gotowego interfejsu nie jest tym samym, co jego wykonanie, koordynacja, instalacja czy testowanie, nawet jeśli w ramach danego projektu jedna strona pełni czasem więcej niż jedną z tych ról. W przypadku gdy uprawnienia do zatwierdzania przysługują tej samej stronie, która wykonała zatwierdzane dzieło, w tabeli należy to wyraźnie odnotować, zamiast pozostawiać kolumnę „zatwierdzenie” pustą, wychodząc z założenia, że wykonanie oznacza automatycznie zatwierdzenie.

Należy rejestrować dane wejściowe, wyjściowe, zatwierdzenia oraz dowody odbioru na każdym punkcie styku

Po przypisaniu interfejsów i rozdzieleniu uprawnień według zakresu obowiązków każdy interfejs wymaga spójnego zestawu pól, które należy do niego przypisać, ponieważ interfejs z wyznaczonym właścicielem, ale bez zdefiniowanych danych wejściowych lub wyjściowych, nadal jest niekompletny. Pole „właściciel” określa, kto ponosi odpowiedzialność; pozostałe pola określają, czego ta odpowiedzialność faktycznie dotyczy.

Wymagane dane wejściowe mają znaczenie, ponieważ interfejs nie może zostać prawidłowo zrealizowany, jeśli strona za niego odpowiedzialna nie wie, od jakich informacji lub materiałów jest on zależny. Na przykład lokalizacja skrzynki przelotowej zależy zarówno od układu pomieszczenia, jak i od projektu sąsiedniego korytarza lub obszaru pomocniczego; odnotowanie tej zależności jako wyraźnego danych wejściowego zapobiega założeniu, że strona montująca skrzynkę będzie dysponować wszystkim niezbędnym bez konieczności informowania jej o tym. Wyniki mają znaczenie z tego samego powodu, ale w odwrotnym kierunku — matryca powinna określać, co ma dostarczyć interfejs, niezależnie od tego, czy jest to fizyczna instalacja gotowa do testów, rysunek gotowy do koordynacji, czy zbiór danych gotowy do wykorzystania w pracach projektowych innej strony.

Właśnie w kwestii zatwierdzania wiele matryc staje się niejasnych, ponieważ zatwierdzenie jest często domyślne, a nie przypisane konkretnej osobie. Warunkiem decydującym o tym, czy zatwierdzenie wymaga osobnego wiersza, jest to, czy więcej niż jedna strona mogłaby w sposób uzasadniony przypisać sobie odpowiedzialność za zatwierdzenie lub ją odrzucić. W sytuacji, gdy tylko jedna strona może kiedykolwiek znaleźć się w pozycji umożliwiającej zatwierdzenie danego wyniku, ryzyko niejasności jest mniejsze. W przypadku gdy zatwierdzenie mogłoby w uzasadniony sposób należeć do projektanta, wykonawcy lub przedstawiciela właściciela, pozostawienie tego pola nieprzypisanym oznacza, że projekt nie posiada mechanizmu pozwalającego na rozstrzyganie sporów, gdy takie się pojawią.

Dowód odbioru stanowi odrębną dziedzinę w stosunku do własności i nie należy go z niej wywnioskować. Samo posiadanie interfejsu nie stanowi dowodu, że został on prawidłowo zrealizowany; w matrycy należy odnotować, jakie dowody zostaną wykorzystane do odbioru wyniku — niezależnie od tego, czy będzie to wynik testu, protokół zatwierdzenia, czy też inny zdefiniowany produkt końcowy powiązany z tym konkretnym interfejsem, a nie z całym projektem. To rozróżnienie odzwierciedla strukturę cyklu życia opisaną w ISO 14644-4, która traktuje projektowanie, budowę i uruchomienie jako sekwencję z własnym procesem weryfikacji, nie określając przy tym, która strona umowy wykonuje dany etap; norma opisuje etapy cyklu życia, a to matryca projektu określa, komu przypisane są zadania i jakie dokumenty należy w ramach poszczególnych etapów zgromadzić.

Osoba odpowiedzialna za przygotowanie tych informacji na potrzeby analizy oferty zyskuje na tym, że pola te są już zdefiniowane, ponieważ szczegóły konfiguracji potrzebne dostawcy — jakie dane wejściowe otrzyma, jakie wyniki ma dostarczyć oraz jakie dowody zostaną wykorzystane do zatwierdzenia zakresu jego zadań — to te same pola, których wymaga matryca na każdym interfejsie mającym z tym związek sprzęt dostawcy.

Rozstrzyganie kwestii dotyczących wielu stron i zakresu nieprzypisanych poprzez wyjaśnienia dotyczące ofert

Analiza interfejsów i rejestracja pól ujawnią luki, a same te luki dostarczają cennych informacji. Puste pole „właściciel”, lista współpracowników bez wyznaczonej osoby odpowiedzialnej, brak danych wejściowych lub wyjściowych albo brak wpisu potwierdzającego odbioru – każda z tych sytuacji wskazuje na inny rodzaj nierozstrzygniętego zakresu i każda z nich powinna zostać przekształcona w konkretne pytanie wyjaśniające, zanim projekt przejdzie do kolejnego etapu – zamówienia publicznego lub realizacji.

Interfejs bez wyznaczonego właściciela stanowi najbardziej oczywistą lukę, a wyjaśnienie tej kwestii jest równie proste: przed rozpoczęciem prac należy ustalić, kto będzie odpowiedzialny za ten interfejs. Interfejs, w którym wymieniono kilka stron bez jednoznacznego wyznaczenia jednego właściciela, stanowi inny problem — wszyscy współtwórcy mogą być prawidłowo zidentyfikowani, ale w matrycy nadal potrzebna jest jedna strona ponosząca odpowiedzialność, odróżniona od pozostałych, ponieważ wkład i odpowiedzialność nie są pojęciami zamiennymi.

Jeśli pole wejściowe lub wyjściowe jest puste, niezbędne wyjaśnienie niekoniecznie dotyczy własności, ale definicji: czego konkretnie wymaga ten interfejs, aby kontynuować działanie, lub co ma wygenerować po zakończeniu. Pozostawienie tego pola pustego nie oznacza, że informacja ta jest zbędna; oznacza to jedynie, że matryca nie zmusiła jeszcze zespołu projektowego do jej określenia.

W przypadku braku zatwierdzenia lub gdy obowiązek ten został włączony do zakresu obowiązków tej samej strony odpowiedzialnej za wytworzenie, koordynację, instalację lub testowanie danego wyniku, wyjaśnienie polega na wyraźnym oddzieleniu tego obowiązku zatwierdzania, nawet jeśli ta sama firma ostatecznie pełni obie role w ramach różnych funkcji. Natomiast w przypadku, gdy dowód odbioru pozostaje pusty, wyjaśnienie polega na określeniu, jaki dowód zostanie faktycznie wykorzystany — ponieważ interfejs bez zdefiniowanego dowodu odbioru nie pozwala potwierdzić, że został zrealizowany zgodnie ze standardami wymaganymi w projekcie, niezależnie od tego, jak jasno przypisano za niego odpowiedzialność.

Czynnikiem decydującym o tym, jak pilne jest rozwiązanie tych luk, jest to, jak wcześnie etap składania ofert lub przetargu ma miejsce w stosunku do momentu zatwierdzenia projektu. Jeśli wyjaśnienia pojawiają się, gdy projekt jest jeszcze na etapie składania ofert, problem nieprzypisanej granicy odpowiedzialności można rozwiązać w ramach procedury pytań i odpowiedzi, zanim którakolwiek ze stron ustali cenę lub zobowiąże się do realizacji zakresu prac. Gdy ta sama luka zostanie wykryta dopiero po podpisaniu umów, ten sam nieprzypisany punkt styku pojawia się zazwyczaj jako późny wniosek o zmianę lub spór dotyczący tego, w jakim zakresie powinna była go uwzględnić dana strona. Przeniesienie każdej nierozwiązanej komórki macierzy do rejestr wyjaśnień dotyczących ofert, zamiast pozostawiać tę kwestię do nieformalnego rozstrzygnięcia w trakcie realizacji, pozwala utrzymać to rozstrzygnięcie w ramach procesu handlowego, do którego należy.

Należy uwzględnić matrycę odpowiedzialności w umowie oraz w procesie wprowadzania zmian

Matryca odpowiedzialności, która została sfinalizowana, ale nigdy nie została włączona do umowy, ma taką samą moc jak notatka planistyczna, ponieważ nic nie zobowiązuje żadnej ze stron do przestrzegania jej po rozpoczęciu prac. Matryca ta musi stać się dokumentem referencyjnym umowy, a nie dokumentem istniejącym nieformalnie obok umowy.

Po ustaleniu struktury macierzy konieczne jest również zdefiniowanie jej relacji z procesem zmian, ponieważ projekty ulegają zmianom — zmienia się zakres, przesuwają się interfejsy, a strona, której pierwotnie przypisano dany wynik, może nie być już w stanie go dostarczyć. Cechą odróżniającą dobrze zarządzaną matrycę od niestabilnej nie jest to, czy zmiany mają miejsce, ale to, czy matryca posiada określoną procedurę jej aktualizacji w przypadku ich wystąpienia. W przypadku braku takiej procedury pierwsza zmiana w projekcie zazwyczaj nieformalnie unieważnia matrycę, ponieważ żadna ze stron nie jest zobowiązana do jej aktualizacji ani do potwierdzenia, że aktualizacja została uzgodniona z pozostałymi zainteresowanymi stronami.

Matryca zawarta w umowie powinna określać, kto może zaproponować zmianę w przypisaniu interfejsu, kto musi tę zmianę zatwierdzić oraz w jaki sposób zaktualizowana wersja jest przekazywana i ponownie potwierdzana wszystkim stronom, które są od niej zależne. Różni się to od omówionego wcześniej zatwierdzania na poziomie interfejsu, ponieważ dotyczy zmian w samej macierzy, a nie zatwierdzania konkretnego wyniku w ramach niezmienionej macierzy. Jeśli w projekcie traktuje się te dwa mechanizmy jako to samo, zmiana w macierzy może zostać wprowadzona przez tę samą stronę, której uprawnienia macierz miała definiować, co osłabia jej funkcję jako dokumentu kontrolnego.

Szczegóły dotyczące sprzętu i interfejsów, odnotowane wcześniej w tabeli, mają również wpływ na sposób zarządzania realizacją i koordynacją w miarę postępów projektu — a system pomieszczeń czystych Złożoność systemu, w którym wykorzystano urządzenia z wielu rodzin, zależy od tej samej przejrzystości interfejsów, którą miała zapewnić matryca, ponieważ to właśnie fizyczne i informacyjne granice każdej z tych rodzin względem otaczającego pomieszczenia i mediów były głównym powodem stworzenia tej matrycy. „Zamrożenie” matrycy nie eliminuje konieczności podejmowania decyzji w miarę postępów projektu; określa ono jedynie, kto jest uprawniony do podejmowania takich decyzji oraz jakie dane zostaną zweryfikowane, zanim zmiana w dowolnym interfejsie zostanie uznana za ostateczną.

Często zadawane pytania

Q: Jak szczegółowa powinna być matryca odpowiedzialności w pomieszczeniu czystym?
A: Należy opierać się na każdym istotnym interfejsie fizycznym lub informacyjnym, w przypadku którego kwestia odpowiedzialności lub akceptacji może być niejasna, a nie na ogólnej liście firm. Każdy interfejs powinien określać jednego właściciela, ewentualnych współtwórców, wymagane dane wejściowe i wyjściowe, osobę odpowiedzialną za zatwierdzanie oraz dowód akceptacji.

Q: Czy wskazanie dostawcy pomieszczeń czystych oznacza, że ponosi on odpowiedzialność za wszystkie zadania związane z tymi pomieszczeniami?
A: Nie. Zakres obowiązków dostawcy należy oddzielić od kompetencji projektowych, prac na miejscu, montażu, testowania i zatwierdzania na każdym punkcie styku. Należy określić dokładne granice modułowego pomieszczenia czystego lub pakietu systemu pomieszczeń czystych, a następnie jednoznacznie przypisać wszystkie powiązane obowiązki.

Q: Czy jedna strona może sporządzić, skoordynować i zatwierdzić ten sam rysunek?
A: W ramach projektu jednej stronie można powierzyć kilka zadań, jednak w matrycy należy nadal oddzielnie rejestrować produkcję, koordynację i zatwierdzanie. Dzięki temu przewidziane mechanizmy kontroli stają się widoczne, a jedno szerokie zadanie nie przesłania obowiązków, za które nikt nie jest odpowiedzialny.

Q: W jaki sposób nabywca powinien porównać oferty, w których ten sam interfejs jest opisany w różny sposób?
A: Należy porównać oferty w odniesieniu do tego samego wiersza interfejsu, a następnie wyjaśnić kwestie dotyczące proponowanego właściciela, podmiotów wnoszących wkład, danych wejściowych, danych wyjściowych, zatwierdzenia oraz dowodów odbioru. Istotne rozbieżności należy wyjaśnić w rejestrze wyjaśnień dotyczących ofert, zanim macierz zostanie włączona do umowy.

Q: Czy sporządzona macierz odpowiedzialności stanowi dowód zgodności z normą ISO 14644-4?
A: Nie. Matryca określa zakres odpowiedzialności w ramach projektu oraz dowody odbioru; sama w sobie nie stanowi jednak dowodu na spełnienie wymagań dotyczących pomieszczeń czystych ani na przeprowadzenie weryfikacji. Norma ISO 14644-4 określa ramy cyklu życia w odniesieniu do projektowania, budowy, uruchomienia i weryfikacji, natomiast w ramach projektu należy nadal zdefiniować zasady dotyczące realizacji, zatwierdzania i odbioru.