Bir temiz oda projesi, işlevsel bir alan haline gelene kadar pek çok kişinin elinden geçer; iki tarafın her birinin, sınırın diğer tarafa ait olduğunu varsaydığı anda, o sınır artık kimse tarafından yönetilmez hale gelir. Asıl mesele, bir sorumluluk matrisinin kağıt üzerinde var olup olmadığı değil, bu matrisin işin, bilginin ve onayların el değiştirdiği gerçek noktalar etrafında oluşturulup oluşturulmadığıdır.

İsimleri atamadan önce proje sınırlarını belirleyin

Matrise herhangi bir isim veya şirket içi rol eklenmeden önce, proje ekibinin bir tarafın işinin nerede bittiği ve diğer tarafın işinin nerede başladığına dair net bir fikre sahip olması gerekir. Bu sınırlar, kurumsal rollerle aynı şey değildir. Tek bir şirket, bir arayüzün her iki tarafında da yer alabilir — bir düzen tasarlayıp daha sonra buna uygun kurulum yapabilir — ve matris yine de bu iki pozisyonu birbirinden ayırmalıdır; çünkü bunlar net bir şekilde belirlenmezse farklı riskler doğurur.

Bir temiz oda projesinde iki tür sınır tekrar tekrar karşımıza çıkar. Fiziksel arayüz, tedarik, şantiye çalışmaları, kurulum ve test süreçlerinin kesiştiği noktadır: bir ekipman parçasının satın alınan bir ürün olmaktan çıkıp sabitlenmiş, bağlanmış ve teste hazır hale geldiği yerdir. Bilgi arayüzü ise bir belgenin veya veri kümesinin el değiştirdiği ya da durumunun değiştiği noktadır: bir çizimin üretilme aşamasından komşu iş kollarıyla koordinasyona geçmesi ve ardından inşaat için onaylanmasına kadar uzanan süreçtir. Bunları aynı tür sınırlar olarak ele almak belirsizliğe yol açar; çünkü bir şeyi çizen taraf, onu diğer hizmetlerle koordine eden taraf olmayabilir ve onaylayan taraf da mutlaka o olmayabilir.

Bir sınırın nasıl haritalandırılması gerektiğini belirleyen koşul, o noktadaki işin veya bilginin devam edebilmesi için başka bir tarafın çıktısına bağlı olup olmadığıdır. Sınırın kendi kendine yeten bir yapıya sahip olduğu durumlarda — bir tarafın, başka birinden gelen ön aşama girdisine ihtiyaç duymadan tedarik, kurulum ve test işlemlerini gerçekleştirdiği durumlarda — basit bir “sorumlu kişi” ataması yeterli olabilir. Sınırın sıralamaya bağlı olduğu durumlarda ise — örneğin, bir ünitenin montaj boyutlarına uyması gereken bir duvar geçişi veya onaylanmadan önce mekanik ve elektriksel yerleşim planlarıyla koordine edilmesi gereken bir çizim gibi — matris, bu bağımlılığı şantiyede gayri resmi olarak çözüleceğini varsaymak yerine açıkça belirtmelidir.

Bu eşleştirme adımı, matrisin nihayetinde kaç satıra ihtiyaç duyacağını belirleyen unsurdur. Genel bir şirket rolleri listesinden oluşturulan bir matris, arayüzleri eksik sayma eğilimindedir; çünkü faaliyetleri, devir teslimlerin gerçekte nerede gerçekleştiğine göre değil, kimin gerçekleştirdiğine göre gruplandırır. Fiziksel ve bilgi arayüzlerinden oluşturulan bir matris ise, rol tabanlı bir listenin tek bir satırda birleştireceği sınırları ortaya çıkarır; ataması yapılmamış kapsamın genellikle buradan kaynaklandığı görülür.

Tasarım yetkisini tedarik ve uygulama görevlerinden ayırın

Sınırlar belirlendikten sonra, bir sonraki adım her bir sınırda yetkinin kime ait olduğunun tespit edilmesidir — ve yetki tek bir şey değildir. Bir tasarım çıktısı üretmek, bunu diğer disiplinlerle koordine etmek, kullanım için onaylamak, tasarımda gösterilenleri kurmak ve kurulan sonucu test etmek beş ayrı görevdir; bunları tek bir “sorumlu taraf” sütununa indirgeyen bir sorumluluk matrisi, anlaşmazlıkların nerede ortaya çıkabileceğini yeterince ortaya koymayacaktır.

Tasarım yetkisi, özellikle bir çözümün nasıl olması gerektiğini — düzeni, teknik özellikleri, arayüz boyutlarını — belirleme hakkına kimin sahip olduğu ile ilgilidir. Bu, fiziksel ekipmanı veya malzemeyi kimin sağlayacağıyla ilgili olan tedarik yetkisinden farklıdır ve bunları kimin kuracağı, bağlayacağı ve devreye alacağıyla ilgili olan uygulama yetkisinden de farklıdır. Bir taraf, tedarik veya uygulama yetkisine sahip olmadan tasarım yetkisine sahip olabilir; aynı şekilde, bir taraf, teknik özelliklerin belirlenmesinde herhangi bir söz hakkı olmaksızın ekipman tedarik edebilir. Matriste bu yetkiler birbirinden ayrılmadığında, sıkça görülen bir sorun şudur: işi uygulayan taraf, tasarım amacının zaten netleştirildiğini varsayarken, tasarım yetkisine sahip taraf ise net olmayan bir durum olduğunda uygulamanın sorular doğuracağını varsayar.

Bu görevlerin ne kadar sıkı bir şekilde birbirinden ayrılması gerektiğine ilişkin koşulu belirleyen unsur, tasarım çıktısı ile daha sonra ortaya çıkan fiziksel kısıtlamalar arasındaki karşılıklı bağımlılık derecesidir. Bir tasarımın saha koşullarından bağımsız olarak nihai hale getirilebildiği durumlarda, çatışma olasılığı çok düşük olduğundan bu ayrım pratikte o kadar da önemli değildir. Tasarımın, ancak kurulum sırasında teyit edilen koşullara (boşluklar, yapısal arayüzler, tesisat güzergâhları) yanıt vermesi gereken durumlarda ise, tasarım yetkisini uygulama görevinden ayrı tutmak zorunlu hale gelir; çünkü saha koşullarının bir tasarım değişikliğini mi gerektirdiğine yoksa mevcut amaç çerçevesinde sadece bir saha ayarlamasını mı gerektirdiğine karar verebilecek yetkiye sahip birine ihtiyaç vardır.

Onay yetkisi yine ayrı bir ele alınmayı hak ediyor. Bir çizimi veya tamamlanmış bir arayüzü onaylamak, onu üretmek, koordine etmek, kurmak veya test etmekle aynı eylem değildir; her ne kadar belirli bir projede tek bir taraf bazen bu rollerden birden fazlasını üstlense de. Onay yetkisi, onaylanacak işi üreten tarafta bulunuyorsa bile, matris, üretimin onay anlamına geldiği varsayımıyla onay sütununu boş bırakmak yerine, bunu yine de açıkça kaydetmelidir.

Her bir arayüzde girdileri, çıktıları, onayları ve kabul kanıtlarını kaydedin

Arayüzler eşleştirildiğinde ve yetki alanları görevlere göre ayrıldığında, her arayüzün kendisine ait tutarlı bir alan kümesi kaydedilmesi gerekir; zira sahibi belirlenmiş ancak tanımlanmış giriş veya çıkışları olmayan bir arayüz hâlâ eksik sayılır. Sahibi, kimin sorumlu olduğunu belirtir; geri kalan alanlar ise bu sorumluluğun gerçekte neleri kapsadığını gösterir.

Gerekli girdiler önemlidir; çünkü bir arayüzden sorumlu taraf, bunun hangi bilgilere veya malzemelere bağlı olduğunu bilmezse, arayüz doğru şekilde uygulanamaz. Örneğin, bir geçiş kutusunun konumu hem oda yerleşim planından hem de bitişik koridor veya destek alanının tasarımından gelen girdilere bağlıdır; bu bağımlılığı açık bir girdi olarak kaydetmek, kurulumunu yapan tarafın kendisine söylenmeden gerekli her şeye sahip olacağı varsayımını önler. Çıktılar ise aynı nedenden ötürü, ancak tersi bir şekilde önemlidir — matris, arayüzün ne üretmesi beklendiğini belirtmelidir; bu, teste hazır fiziksel bir kurulum, koordinasyona hazır bir çizim veya başka bir tarafın tasarım çalışması için hazır bir veri kümesi olabilir.

Onay, birçok matrisin belirsizleştiği noktadır; zira onay genellikle atanmak yerine varsayılır. Onayın kendi satırına ihtiyaç duyup duymayacağını belirleyen koşul, birden fazla tarafın onaylama sorumluluğunu makul bir şekilde üstlenip üstlenemeyeceğidir. Belirli bir çıktıyı onaylayabilecek konumda yalnızca bir tarafın bulunması durumunda, belirsizlik riski daha düşüktür. Onayın makul bir şekilde tasarımcıya, yükleniciye veya mal sahibinin temsilcisine ait olabileceği durumlarda, bu alanın atanmamış bırakılması, proje kapsamında anlaşmazlık ortaya çıktığında bunu çözmek için herhangi bir mekanizmanın bulunmadığı anlamına gelir.

Kabul kanıtı, sahiplikten ayrı bir alandır ve sahiplikten çıkarılmamalıdır. Bir arayüze sahip olmak, tek başına o arayüzün doğru bir şekilde tamamlandığının kanıtı değildir; matriste, çıktının kabulü için hangi kanıtların kullanılacağı belirtilmelidir — bu, bir test sonucu, bir onay kaydı ya da projenin tamamı yerine o belirli arayüzle bağlantılı başka bir tanımlanmış teslimat olabilir. Bu ayrım, aşağıda açıklanan yaşam döngüsü yapısını yansıtmaktadır: ISO 14644-4, bu standart tasarım, inşaat ve devreye almayı, her bir aşamanın kendine özgü doğrulama sürecine sahip bir dizi olarak ele alır; hangi sözleşme tarafının hangi adımı gerçekleştireceğini belirlemez; standart, yaşam döngüsü aşamalarını tanımlar ve bu aşamalar içindeki görev dağılımını ve kanıtları belirleyen, projenin kendi matrisidir.

Bir teklif incelemesi için bu bilgileri hazırlayan bir alıcı, bu alanların önceden tanımlanmış olmasından faydalanır; zira bir tedarikçinin ihtiyaç duyduğu yapılandırma ayrıntıları — hangi girdileri alacağı, hangi çıktıları sunması beklendiği ve kapsamının kabul edilmesi için hangi kanıtların kullanılacağı — matrisin, söz konusu konuyla ilgili her bir arayüzde gerektirdiği alanlarla aynıdır. tedarikçinin ekipmanı.

Teklif açıklamaları yoluyla çok taraflı ve atanmamış kapsam sorunlarını çözmek

Arayüzlerin eşleştirilmesi ve alanların kaydedilmesi, eksiklikleri ortaya çıkaracaktır ve bu eksikliklerin kendisi de önemli bilgiler sağlar. Sahibinin boş bırakılması, tek bir sorumlu tarafın bulunmadığı bir katkı sağlayanlar listesi, eksik bir girdi veya çıktı ya da eksik bir kabul kanıtı kaydı; bunların her biri farklı türde çözülmemiş kapsam sorunlarına işaret eder ve projenin tedarik veya inşaat aşamasına geçmeden önce her biri belirli bir açıklığa kavuşturma sorusuna dönüştürülmelidir.

Adı belirtilen bir sahibi olmayan bir arayüz en bariz eksikliktir ve bunun çözümü de buna paralel olarak basittir: Çalışmaya başlamadan önce o arayüzün sorumluluğunu kimin üstleneceğini belirlemek gerekir. Tek bir net sahibi olmadan birkaç tarafın listelendiği bir arayüz ise farklı bir sorundur — katkıda bulunanların hepsi doğru bir şekilde belirlenmiş olabilir, ancak matriste yine de diğerlerinden ayrılan tek bir sorumlu tarafın olması gerekir; çünkü katkı ve sorumluluk birbirinin yerine geçemez.

Bir girdi veya çıktı alanı boş bırakıldığında, gerekli olan açıklama mutlaka sahiplikle ilgili olmayabilir; daha çok tanımla ilgilidir: Bu arayüzün devam edebilmesi için ya da tamamlandığında ortaya çıkarması gereken şey tam olarak nedir? Bu alanın boş bırakılması, bilginin gereksiz olduğu anlamına gelmez; bu, matrisin henüz proje ekibini bunu belirtmeye zorlamadığı anlamına gelir.

Onay sürecinin eksik olduğu veya aynı çıktının üretilmesi, koordine edilmesi, kurulması ya da test edilmesinden sorumlu aynı birim tarafından üstlenildiği durumlarda, açıklığa kavuşturulması gereken husus, bu onay görevini açıkça ayırmaktır; bu, aynı şirketin farklı işlevler kapsamında her iki rolü de nihai olarak yerine getiriyor olsa bile geçerlidir. Kabul kanıtının boş bırakıldığı durumlarda ise, hangi kanıtın fiilen kullanılacağının belirtilmesi gerekir; zira tanımlanmış bir kabul kanıtı bulunmayan bir arayüzde, sahipliğin ne kadar net bir şekilde atanmış olursa olsun, projenin gerektirdiği standartlara uygun olarak tamamlandığının teyit edilmesinin bir yolu yoktur.

Bu boşlukların ne kadar acilen çözülmesi gerektiğinin belirleyicisi, teklif veya ihale aşamasının tasarımın kesinleşmesine göre ne kadar erken bir aşamada yer aldığıdır. Proje hâlâ teklif aşamasındayken açıklığa kavuşturulması gereken hususlar ortaya çıkarsa, henüz hiçbir taraf fiyatlandırma yapmamış veya kapsam taahhüdünde bulunmamışken, atanmamış bir arayüz soru-cevap süreciyle çözülebilir. Aynı eksiklik ancak sözleşmelerin imzalanmasından sonra ortaya çıkarsa, bu atanmamış arayüz genellikle geç bir değişiklik talebi olarak veya hangi tarafın kapsamının bunu içermesi gerektiği konusunda bir anlaşmazlık olarak gün yüzüne çıkar. Çözülmemiş her matris hücresini teklif açıklama kaydı, bunu yürütme aşamasında gayri resmi olarak çözülmeye bırakmak yerine, bu kararın ait olduğu ticari süreç içinde kalmasını sağlayan şey budur.

Sorumluluk matrisini sözleşme ve değişiklik sürecine dahil edin

Son hali verilmiş ancak sözleşmeye hiçbir zaman dahil edilmemiş bir sorumluluk matrisi, bir planlama notundan daha fazla bağlayıcılığa sahip değildir; zira iş başladıktan sonra hiçbir tarafı buna uymaya mecbur kılan bir hüküm bulunmamaktadır. Bu matris, sözleşmenin yanında gayri resmi olarak yer alan bir belge değil, sözleşmede atıfta bulunulan bir belge haline getirilmelidir.

Bir kez sabitlendiğinde, matrisin değişim süreciyle de tanımlanmış bir ilişkiye ihtiyacı vardır; zira projeler değişir — kapsam değişir, arayüzler yer değiştirir, başlangıçta bir çıktının sorumluluğu verilen taraf artık bunu teslim edecek durumda olmayabilir. İyi yönetilen bir matris ile kırılgan bir matrisi ayıran koşul, değişikliklerin olup olmadığı değil, değişiklikler meydana geldiğinde matrisin revize edilmesi için tanımlanmış bir prosedürün olup olmadığıdır. Böyle bir prosedürün olmadığı durumlarda, ilk proje değişikliği matrisi gayri resmi olarak geçersiz kılma eğilimindedir; çünkü hiçbir taraf, matrisi güncellemekle veya güncellemenin etkilenen diğer taraflarca kabul edildiğini teyit etmekle yükümlü değildir.

Sözleşmede sabitlenmiş bir matris, bir arayüz atamasına kimlerin değişiklik önerebileceğini, bu değişikliği kimin onaylaması gerektiğini ve güncellenmiş sürümün, buna bağlı olan tüm taraflara nasıl dağıtılacağını ve yeniden teyit edileceğini belirtmelidir. Bu, daha önce tartışılan arayüz düzeyindeki onaydan farklıdır; çünkü bu durum, değişmemiş bir matris içindeki belirli bir çıktının onaylanmasından ziyade, matrisin kendisinde yapılan değişikliklerle ilgilidir. Bir proje bunları aynı mekanizma olarak ele alırsa, matristeki bir değişiklik, matrisin tanımlaması amaçlanan yetkiye sahip taraf tarafından yapılabilir; bu da matrisin bir kontrol belgesi olarak işlevini zayıflatır.

Matriste daha önce kaydedilen ekipman ve arayüz ayrıntıları, proje ilerledikçe teslimat ve koordinasyonun nasıl yönetileceğine de yansır — bir temiz oda sistemi Birden fazla ekipman grubundan oluşturulan sistem, matrisin başlangıçta oluşturulması için temel alınan aynı arayüz netliğine bağlıdır; zira her bir grubun çevreleyen oda ve hizmetlerle olan fiziksel ve bilgi sınırları, matrisin oluşturulmasının asıl nedeniydi. Matrisin sabitlenmesi, proje ilerledikçe karar verme ihtiyacını ortadan kaldırmaz; bunun yerine, kimin bu kararı verme yetkisine sahip olduğunu ve herhangi bir arayüzdeki değişikliğin nihai olarak kabul edilmeden önce hangi kanıtların kontrol edileceğini belirler.

Sıkça Sorulan Sorular

Q: Bir temiz oda sorumluluk matrisi ne kadar ayrıntılı olmalıdır?
A: Bunu, genel bir şirket listesi yerine, sahiplik veya kabul durumunun belirsiz olabileceği her bir anlamlı fiziksel veya bilgi arayüzü etrafında şekillendirin. Her arayüzde bir sahip, varsa katkıda bulunanlar, gerekli girdi ve çıktılar, onay sorumluluğu ve kabul kanıtı belirtilmelidir.

Q: Temiz oda tedarikçisinin adının belirtilmesi, onu temiz odayla ilgili her türlü görevden sorumlu kılar mı?
A: Hayır. Tedarikçinin sorumluluk alanı, her bir arayüzde tasarım yetkisi, şantiye çalışmaları, kurulum, test ve onay süreçlerinden ayrılmalıdır. Modüler temiz oda veya temiz oda sistemi paketinin kesin sınırlarını belirleyin, ardından her bir ilgili görevi açıkça atayın.

Q: Aynı çizimi tek bir taraf hazırlayabilir, koordine edebilir ve onaylayabilir mi?
A: Proje, tek bir tarafa birden fazla görev atayabilir; ancak matris yine de üretim, koordinasyon ve onay süreçlerini ayrı ayrı kaydetmelidir. Bu, amaçlanan denetimleri görünür kılar ve tek bir geniş kapsamlı görev atamasının, sorumlusu belirlenmemiş bir görevi gizlemesini önler.

Q: Bir alıcı, aynı arayüzü farklı şekillerde tanımlayan teklifleri nasıl karşılaştırmalıdır?
A: Teklifleri aynı arayüz satırıyla karşılaştırın, ardından önerilen sahip, katkıda bulunanlar, girdiler, çıktılar, onay ve kabul kanıtlarını netleştirin. Matris sözleşmeye dahil edilmeden önce, teklif açıklığa kavuşturma günlüğündeki önemli farklılıkları giderin.

Q: Doldurulmuş bir sorumluluk matrisi, ISO 14644-4 standardına uygunluğu kanıtlar mı?
A: Hayır. Matris, proje sorumluluklarını ve kabul kanıtlarını belirler; ancak tek başına temiz oda gerekliliklerinin veya doğrulamanın yerine getirildiğini kanıtlamaz. ISO 14644-4, tasarım, inşaat, devreye alma ve doğrulama için yaşam döngüsü bağlamını sağlarken, projenin teslimat, onay ve kabul düzenlemelerini yine de kendisinin tanımlaması gerekir.