| | |Menu główne

Management.

Zarządzanie Projektowaniem vs. Zarządzanie Dokumentacją

Często pojęcie zarządzenia w zespołach projektowych utożsamia się z Zarządzaniem Dokumentacją, a przecież dokumenty projektowe są wynikiem wielu procesów, które również powinny być wspierane poprzez chociażby standaryzację. Popularne słowo „workflow” wcale nie odnosi się do obiegu dokumentu jako takiego, a do „przepływu pracy”. Słysząc „workflow” wiele osób widzi przed oczami prostokąciki połączone strzałeczkami najczęściej odnoszące się do pojedynczego pliku. Problem w tym, że zazwyczaj tylko jeden z tych prostokącików ma opis „praca w toku” a przecież „workflow” to głównie praca w toku. Jeżeli etapy życia dokumentu opisane są „praca w toku” -> „sprawdzanie” -> „produkcja” to nie oznacza workflow tylko listę statusów jakie plik może osiągać. Określenie praktycznego wokflow uzyskamy dopiero po uszczegółowieniu co się dzieje gdy plik jest w stanie „praca w toku” – jak wygląda współpraca, wymiana danych i informacji pomiędzy osobami opracowującymi dokumentację? Jakie warunki muszą być spełnione aby ta współpraca była możliwa i efektywna?

Komputerowe Wspomaganie Systemu

Cofnijmy się na chwilkę o kilkadziesiąt lat wstecz. Pomimo braku komputerów projektowano urządzenia, tworzono do nich dokumentację, która była zatwierdzana i przekazywana na produkcję. Pojawienie się komputerów usprawniło jedynie wiele czynności związanych z tymi procesami. Wydaje się być niezrozumiałe dlaczego definicje dotyczące projektowania i wytwarzania (CAD, CAM, CAE) rozpoczynają się od zwrotu Computer Aided (komputerowo wspomagane) a skróty dotyczące zarządzania dokumentacją nie.

Jeżeli popatrzymy na funkcje Systemu Zarządzania Dokumentacją w ujęciu praktycznym okaże się, że wcale nie wymaga on dodatkowego oprogramowania. Każda firma posiada swój własny tradycyjny, ręczny System Zarządzania Dokumentacją. Zbiór zasad i procedur powoduje przygotowanie dokumentacji i późniejsze pojawienie się jej na warsztacie w odpowiednim czasie. Wprowadzenie tzw. PDM jest tylko komputerowym wspomaganiem tego systemu. Od początków pojawienia się PDM każdy przyjął za oczywiste, że jest to system komputerowy, a przecież tak samo jak projektowanie odbywało się bez komputerów tak samo zarządzanie dokumentacją jakoś się udawało. To uproszczenie powoduje wiele nieporozumień i utrudnia właściwy wybór oprogramowania wspomagającego zarządzanie dokumentacją.

Należy więc zadać pytanie: czy w ramach rozwoju, podążania za wymaganiami rynku, potrzebujemy wdrożenia Systemu, czy oprogramowania wspomagającego System, który już mam?

Zakres wdrożenia

Jak szeroko należy zdefiniować otoczenie, żeby dyskusja na powyższe temty była produktywna? Czy musimy zdefiniować pełen zakres procesów od pomysłu do utylizacji, tak jak jest to w przypadku popularnego ostatnio PLM ? Jeżeli zawęzimy zakres poszukiwań naszego rozwiązania do procesów, które mają miejsce od momentu kiedy projektant dostanie zlecenie wykonania projektu do emisji dokumentacji to możemy mówić o wdrożeniu oprogramowania Wspomagającego System Inżynierski.
Prześledźmy jakieś najprostsze modelowe zadanie stawiane przed Systemem Inżynierskim:
Projektant otrzymuje dane wejściowe i ma zadanie przygotować dokumentację wykonawczą. Efekty swojej pracy ma umieścić w zadanym miejscu, aby inni zainteresowani mieli do nich dostęp. Ktoś oczywiście sprawdza tą dokumentację i zatwierdza. Końcowym etapem jest podłączenie dokumentu do innych danych tego produktu.
Zadania te będą realizowane przez cztery logicznie wydzielone funkcje Systemu Inżynierskiego:
1. Projektowanie i Dokumentowanie.
2. Współdzielenie Danych.
3. Zarządzanie Dokumentami.
4. Zarządzanie Danymi Produktu.
Taki logiczny, odpowiadający rzeczywistości podział funkcji pozwala na selektywne dobieranie narzędzi wspomagających poszczególne funkcje Systemu a co za tym idzie możliwość planowania etapowego rozwoju, nadając priorytet biznesowo uzasadnionym zmianom.

Zarządzanie Dokumentami vs. Zarządzanie Danymi Produktu

Skąd pomysł na rozdzielenie zarządzania dokumentem i zarządzanie danymi produktu?
Powodów jest wiele, ale najprostszym wyjaśnieniem jest to, że dane o produkcie mogą być zawarte w kilku plikach a nie w jednym. Zarządzanie jednym plikiem, najczęściej dokumentacją wykonawczą, nie determinuje poprawności innych danych, a nawet ich obecności. Dlatego w bazie tworzy się obiekt, który jest swoistą reprezentacją produktu, co daje możliwość sprawdzenia chociażby kompletacji dokumentów. Inaczej mówiąc jeżeli ktoś zatwierdził „produkt” to nie oznacza tylko, że dokumentacja wykonawcza jest poprawna, ale również, że wszystkie pozostałe dokumenty są załączone.

Pliki, obiekty, zadania

Oprócz podziału grup funkcji Systemu Inżynierskiego należy zwrócić uwagę na strukturę przechowywanych danych. Opracowując informacje na temat wybranego zagadnienia należy zastanowić się, czego ta informacja dotyczy – pojedynczego pliku, obiektu (produktu), czy konkretnego zadania określonego w czasie.

Implementacja środowiska czy Implementacja procesów?

Przed rozpoczęciem wdrożenia należy wyraźnie odpowiedzieć sobie na pytanie: czy oczekuję implementacji komputerowego środowiska, które będzie wspierało procesy, które już działają w sposób tradycyjny (ręczny), czy może oczekuję analizy tych procesów i ich zmiany?
Pamiętajmy, że implementacja każdego systemu komputerowego cementuje nawyki, nie sprawdzając czy są dobre czy złe.

Marcin Gryz

 

Dane kontaktowe:

697 334 600

marcin.gryz@procad.pl

170_moldflow
170_simulation
170_rapid
170_roll_forming
managment
Back to Top