Zaskakujący minimalizm

Czytając ISO 19650 części 1 i 2, bez załączników narodowych, natraficie na słowo atrybut trzykrotnie. Ciekawe, prawda? Dowiecie się z tych trzech miejsc, że: 

  • zaleca się uzgodnienie nazw atrybutów i metadanych dla informacji w CDE (19650-1 pkt. 11.3), 
  • CDE powinno posiadać zdolność zarządzania atrybutami dla każdego kontenera informacji (19650-1, pkt. 12.1), 
  • każdy kontener informacji powinien mieć atrybut, który określa: status (zdatność), rewizję i bliżej nieokreśloną klasyfikację (19650-2, pkt. 5.1.7). 

Jak widać, wymogi stawiane przez ISO 19650 są klarowne, spójne z innymi zapisami i wydają się łatwe do wdrożenia. Chyba nie budzi wątpliwości konieczność posiadania atrybutów dla kluczowych informacji wymaganych przez normę, nazwania ich i możliwość zarządzania nimi w CDE. Warunki te spełnia niemal każdy system CDE lub EDMS. 

Uważam, że wdrożenie powyższych zapisów w praktyce może nie być łatwe. Spełnienie tych prostych wymagań z punktu widzenia stricte formalnego nie jest wyzwaniem. Jednak wdrożenie w oparciu o nie, działającego mechanizmu atrybutowania potrafi sprawić wiele problemów. 

Nieoczywisty problem

Gdy przygotowujemy strategię atrybutowania, odwołanie się w Wymaganiach Informacyjnych dla projektów (EIR) do ISO 19650, jest niewystarczające. Brak w nim dokładnych informacji jak planować zarządzanie atrybutami nawet na poziomie dokumentów. W efekcie konieczne jest każdorazowe uszczegółowienie EIRa na wielu płaszczyznach. Na polskim, wciąż mało dojrzałym rynku, skutkuje to znikomym poziomem powtarzalności schematów i standardów, pomiędzy projektami. Nawet u tego samego zamawiającego. 

Zapisy ISO 19650 dotyczące atrybutów nie są złe. Jednak ze względu na swoją lakoniczność i ogólność, mogą być problematyczne. W teorii szczegóły powinny się znaleźć w załączniku krajowym. Niestety, jeżeli przetłumaczenie normy na język polski zajęło kilka lat, to chyba nie bardzo możemy liczyć na szybkie pojawienie się takiego załącznika. Istniejący od kilku lat załącznik brytyjski, standaryzuje kody statusów (zdatności) i podaje obszernie opisane kodowanie nazw dokumentów. Nie rozwiązuje to jednak problemu małej szczegółowości wymagań dla większości kontenerów informacji. 

Czego mnie brakuje?

  • Skończonej listy atrybutów, które powinny mieć typowe kontenery informacji.
  • Listy atrybutów dodatkowych, które ze względu na ich przydatność czy popularność warto mieć na uwadze.
  • Kilku zaleceń i dobrych praktyk jak tworzyć strategię atrybutowania.

Nic nie wskazuje na to, żeby szczegółowe wytyczne pojawiły się w normie w najbliższej przyszłości. Podzielę się własnymi doświadczeniami. 

To, ile tych atrybutów?

Pracując i doradzając przy projektach spotkałem się z wieloma systemami atrybutowania zarówno dokumentów, jak i komponentów w modelach. Każdy z nich można umieścić na wykresie, gdzie oś X oznacza ilość, szczegółowość i złożoność atrybutów (od niskiej do wysokiej), a oś Y – faktyczne stosowanie przyjętego systemu w codziennej pracy (od nigdy do zawsze). Moje doświadczenie pokazuje dosyć oczywistą korelację: wraz ze wzrostem skomplikowania przyjętego systemu spada skuteczność jego wdrożenia i stosowania. 

Każdy, a szczególnie menedżerowie, chcą wiedzieć o dokumentach i komponentach jak najwięcej. Dlatego odczuwają potrzebę stosowania dużej liczby atrybutów. Jednak to nie oni wprowadzają te informacje do systemów. Problemem jest użycie rozbudowanych schematów i konieczność wypełniania treścią długiej liczby atrybutów. Złapanie balansu i skuteczne atrybutowanie na niezbędnym, ale wystarczającym poziomie jest sztuką. 

Rozwiązaniem nie jest oczywiście dążąca do zera, drastyczna redukcja liczby atrybutów. Jednak przy dodawaniu kolejnego atrybutu konieczne jest każdorazowe uzasadnienie jego istnienia. Zarówno, gdy dodajemy go do dokumentów, komponentów BIM i CAD, czy innych, mniej oczywistych kontenerów informacji, jak pozycje w kosztorysie. Ktoś będzie musiał te atrybuty uzupełniać, sprawdzać i utrzymywać. To generuje koszt, który przynajmniej w teorii powinien się zwrócić. Przykładowo: ktoś inny poświęci mniej czasu na swoje zadania, wykorzystując tę informację. 

Nie istnieje dokładna liczba atrybutów, która jest uznawana za idealną. Jednak z moich obserwacji wynika, że w większości przypadków wybrany kontener da się opisać przy pomocy kilku do 12-15 atrybutów. Od razu doprecyzuję. Zwłaszcza w przypadku komponentów BIM podana liczba odnosi się do wybranej kategorii informacji. Typowe kategorie to: podstawowe informacje o komponencie nadawane przez projektanta, informacje z budowy, informacje gwarancyjne, informacje o usterkach, itp. Ostatecznie w przypadku komponentów BIM, pojedynczy kontener może mieć znacząco więcej atrybutów niż 15. 

Kilka dobrych praktyk

Nie gwarantuję, że spisane poniżej dobre praktyki są uniwersalne i sprawdzą się w każdej sytuacji, ale mnie dotychczas służyły dobrze. 

  1. Każdy atrybut powinien istnieć w jakimś celu.  
  1. Informacja zawarta w atrybutach powinna być rozumiana intuicyjnie, bez zaglądania do instrukcji. 
  1. Nie dodawaj atrybutów na zapas z założeniem, że „może się przydadzą”! 
  1. Liczba atrybutów powinna być minimalna, ale wystarczająca do zaspokojenia procesów, w których będziemy używać danego kontenera informacji (np. kontrola dokumentów, komunikacja z klientem, zestawienia materiałowe z modeli BIM, rozliczenie kosztorysu). 
  1. W miarę możliwości atrybut powinien występować w największej ilości kontenerów, tak żeby jak najmniej posiadało wartość generyczną typu „XXX” lub „000”. Np. każdy dokument ma określony typ, ale nie każdy jest przypisany do lokalizacji w projekcie. Natomiast lokalizację znajdziemy w większości projektów, bo jest przydatna dla dokumentów używanych codziennie przez zespół. 
  1. Wartości atrybutów powinny być zrozumiałe bez konieczności zerkania do instrukcji. Akronimy stosuj, gdy są niezbędne lub powszechnie używane. 
  1. Pojedynczy atrybut to pojedyncza informacja. Nie łącz w atrybucie „Materiał” jego typu, klasy i rodzaju. To zawsze kończy się dodatkową pracą przy odczycie i wykorzystaniu informacji na dalszych etapach prac. 
  1. Pojedyncza informacja to pojedynczy atrybut. Jeżeli masz atrybut określający materiał, to nie powtarzaj tej informacji w innych atrybutach. 
  1. Rozróżniam trzy kategorie atrybutów: 
  • nadawane automatycznie
  • dodawane ręcznie, gdzie wiele kontenerów ma tą samą wartość, 
  • dodawane ręcznie, gdzie każdy kontener ma unikalną wartość. 
  1. Im więcej atrybutów nadawanych automatycznie tym lepiej. Ale pamiętaj, że one nie są bezkosztowe. Ktoś musi zdefiniować i utrzymywać skrypty, procesy, biblioteki, które będą nimi zarządzać. 
  1. Atrybuty o unikalnej wartości dodawanej ręcznie są najtrudniejsze do zweryfikowania pod kątem tego, czy zawierają prawdziwą informację. W wielu przypadkach (np. data wbudowania, data odbioru, numer seryjny) sprawdzamy je wyrywkowo lub wręcz zakładamy, że są poprawne. Dlatego powinny być stosowane, gdy jesteśmy przekonani, że dana informacja jest nam potrzebna. 
  1. Automatyzowanie wszystkiego nie zawsze jest właściwą drogą. Czasem stworzenie i utrzymanie mechanizmów, które automatyzują uzupełnianie wybranego atrybutu, zabiera więcej czasu niż uzupełnianie go ręcznie. 
  1. Last but not least: Wdrażając po raz pierwszy proces, będzie lepiej, gdy okaże się, że macie za mało atrybutów, niż za dużo. Jeżeli zespół zgadza się, że na pewno potrzebuje 8 atrybutów i być może jeszcze 5 innych, to na początek użyjcie 8. 

Przykłady z CDE

Wiemy już, że ISO 19650 wymaga atrybutów takich jak: kody stanu, statusu i rewizji. Dobrze działająca platforma, taka jak iCDE ma dedykowane atrybuty oraz zautomatyzowane mechanizmy, które pozwalają na łatwe zarządzanie dokumentami w miarę postępujących prac. 

Rewizja jest aktualizowana przy każdorazowym dodaniu nowej wersji dokumentu i przy przeniesieniu pliku pomiędzy stanami (np. zmieniając WIP do SHA). Natomiast zmiana stanu i statusu następuje w efekcie uruchomienia procesów przekazywania dokumentów. iCDE w głównym widoku plików wyświetla wszystkie niezbędne informacje, które pozwalają na szybkie zrozumienie kto i do czego może użyć dokumentów. 

Automatycznie nadawane kody stanu, statusu i rewizji

Powyższy przykład obrazuje wyłącznie atrybuty wymagane przez normę. Są one niewystarczające do tego, żeby efektywnie zarządzać całością dokumentacji. iCDE automatycznie rejestruje znacznie więcej danych. Od tego kto jest właścicielem dokumentu, jakim procesom podlegała rewizja, po informacje, które dokumentują każdy proces (kto, kiedy, do kogo oraz w jakim celu). Większość to metadane systemu. Nie wymagają konfiguracji ani utrzymania ze strony użytkownika. Są one wartością dodaną, która wynika, ze stosowania platformy CDE. 

Metadane pozwalające na efektywne zarządzanie dokumentacją

W iCDE każdy dokument ma łatwo dostępny podgląd. Można w nim znaleźć listę wszystkich rewizji. Dla każdej z nich znajdziemy obszerny raport, który pozwala na szybkie odczytanie informacji o bieżących i historycznych procesach, załącznikach do dokumentu, czy nadanych przez użytkowników atrybutach. Co ważne, system nie narzuca limitów. Pozwala na swobodne dodawanie i edytowanie nowych atrybutów i ich wartości przez firmowych administratorów. Interfejs jest tak łatwy, że rolę administratora mogą pełnić osoby bez specjalnego doświadczenia czy umiejętności technicznych. W efekcie nie generuje to dodatkowych kosztów. 

Podgląd historii pojedynczego dokumentu

_________________________________________________________________________________________________

Chcesz dowiedzieć się jak iCDE może usprawnić pracę w Twojej firmie? Umów się na darmową konsultację z ekspertem.

Czekamy na Twoją wiadomość na contact@icde.com