11 sie 2022

CDE w praktyce na przykładzie platformy ePMflow. Pracujemy na plikach i ich właściwościach.

W poprzedniej części skonfigurowaliśmy projekt na bazie

11 sie 2022

W poprzedniej części skonfigurowaliśmy projekt na bazie dostarczonego szablonu. Kolejny krok to praca na plikach, które umieszczamy na platformie. W naszym pierwszym przykładzie będzie to dokumentacja projektowa. Pliki wrzucamy metodą drag&drop lub przez kliknięcie na przycisk “Prześlij”.

Widok pustego folderu

UWAGA

  1. Platforma posiada mechanizm nadpisywania (z zachowaniem historii wersji) plików o tej samej nazwie. W związku z tym możemy stosować dowolne nazewnictwo plików, ale chcąc zautomatyzować procesy zmian, nazwy nie mogą się zmieniać w trakcie trwania projektowania czy budowy.
  2. Rekomendujemy nie umieszczać w jednym folderze więcej niż 1000 plików ze względów optymalizacyjnych i dobrych praktyk.
  3. Maksymalna wielkość jednego pliku to 1.5 GB.

W momencie umieszczania plików użytkownikowi wyświetli się okno z następującymi opcjami:

  1. “Zastosuj ten sam zestaw właściwości dla wszystkich plików”. Przy wyłączonej opcji mamy możliwość zmiany nazwy i wrzucania każdego pliku z innym zestawem właściwości. Przy włączonej opcji, nie można zmienić nazw plików. 
  2. Pole “Opis” możemy używać w zależności od potrzeb w dowolny sposób. Np.
    – możemy w nim umieszczać starą nazwę dokumentu w przypadku zmiany nazewnictwa na etapie budowy na cele stosowania kodyfikacji,
    – możemy doprecyzować zawartość rysunku,
    – uzupełni się automatycznie z pliku Worda jeśli uzupełnione są właściwości dokumentu.
  3. Wybór właściwości z listy wartości dostępnych dla projektu.

Widok okna do umieszczania plików na platformie

UWAGA

  1. Dokumentację projektową powinniśmy wgrywać paczkami o tych samych właściwościach (najczęściej będzie to paczka z taką samą rewizją).
  2. Jeśli którekolwiek z pól dotyczących właściwości będzie puste, oznacza to, że Menedżer projektu go nie skonfigurował.
  3. Nie ma możliwości wrzucania plików razem ze strukturą katalogów.
  4. Rysunki w dokumentacji projektowej występujące najczęściej w dwóch formatach (natywnym i PDF) są ze sobą powiązane tylko nazwą. Dzięki użyciu sortowania po nazwie możemy je ułożyć obok siebie.

Przepływ pracy bez obiegów.

W wersji “START”, w której nie ma Systemu obiegu dokumentów, jedyną opcją zarządzania rewizjami jest ręczna praca na plikach. W jaki sposób przebiega? Mamy już wprowadzony komplet dokumentacji projektowej, całość ma przypisaną rewizję “00” i status “Zatwierdzone”. Zachodzi potrzeba wydania kolejnej rewizji np. z powodu błędu w dokumentacji branży konstrukcji. Naprawa tego błędu uzgadniania jest pomiędzy głównym projektantem i konstruktorem za pomocą standardowych narzędzi: e-mail, telefon, CDE zespołu projektowego. Kiedy wszystko zostało ustalone, projektant konstrukcji umieszcza rewizję rysunku w katalogu “Dokumentacja projektowa – uzgodnienia” nadając kolejną rewizję i status “Do zatwierdzenia”. 

Sposoby informowania o nowych treściach dodanych do projektu:

  • zbiorcze powiadomienie e-mail o 6:00 rano. Jest to e-mail dotyczący aktywności na platformie, w szczególności informujący o dodaniu nowego pliku, czy aktualizacji pliku.
  • powiadomienie e-mail konfigurowane (za pomocą reguły) dla określonego folderu, nie zawsze jest to optymalna metoda, ponieważ generuje olbrzymią ilość powiadomień (jeden plik – jeden e-mail)

Widok maila „Raport dzienny”

Wróćmy do zatwierdzenia plików. W momencie, w którym dokumenty zostały zatwierdzone np. protokołem na naradzie, Menedżer projektu:

  • zmienia im status na “Zatwierdzone”,
  • kopiuje plik ze zmianą wersji do katalogu “Dokumentacja projektowa” z zaznaczoną opcją “Nadpisz właściwości”
  • zmienia ponownie tym samym dokumentom status na “Archiwum”

Dokumenty w katalogu “Dokumentacja projektowa uzgodnienia” zostają do samego końca projektu czy budowy, ponieważ są historią wszystkich uzgodnień.

Dokumenty w katalogu “Dokumentacja projektowa” są historią wszystkich kontraktowo zatwierdzonych rewizji.

Jeśli dokument został odrzucony, to Menedżer projektu zmienia status na “Odrzucony” i oczekuje na kolejną wersję dokumentów.

Jak widać praca na rewizjach w wersji “START” jest możliwa i chcąc nie chcąc narażona na ludzkie błędy z uwagi na ręczne zmiany. Ale nie zawsze trzeba do muchy strzelać z armaty. Taką metodę pracy możemy wykorzystać do zaspokojenia wielu potrzeb. 

Przepływ pracy z obiegami.

W wersji PRO powyższą ręczną metodę możemy zautomatyzować. Cała struktura katalogów zostaje taka sama, będzie nam za to potrzebny dodatkowy katalog na raporty, który już został uwzględniony w szablonie projektu.

Długo myślałem, w jaki sposób pokazać  System obiegu dokumentów w przystępny sposób. Dlatego na początek skonfigurujemy prosty obieg nie do końca zgodny z naszą historią (ale zachowujący sens) ponieważ chciałbym Wam pokazać tworzenie obiegu od początku do końca razem z logowaniem się na przez inne osoby. W kolejnych artykułach rozwiniemy możliwości obiegów na platformie ePMflow.

Jak się zabrać do tych obiegów? Mnie zawsze pomaga BPMN – bardzo prosty język do graficznego  opisywania procesów. Obecnie  tworzymy je w darmowym rozwiązaniu ADONIS:CE.

Widok procesu „Karta uzgodnień dokumentacji” w ADONIS:CE

Mając już opanowany proces uzgadniania dokumentacji przystępujemy do jego konfiguracji w ePMflow.

Przed samym obiegiem dwie ważne rzeczy:

  1. Menedżer musi ustalić którzy użytkownicy dostaną prawo do uruchomienia obiegów. Tutaj wracamy do naszego szablonu projektu. Mamy w nim kolumnę związaną z tą opcją. Aby móc to zrobić na platformie należy być przypisanym do grupy “OBIEGI WNIOSKODAWCA”. Użytkowników dodajemy do tej grupy identycznie jak opisywałem w poprzednim artykule. Menedżer może w każdej chwili podejrzeć jakie są osoby w każdej grupie w swojej konsoli.

    Widok konsoli admina klienta – zakładka grupy.

  2. Należy włączyć widoczność danego rodzaju obiegu dla danego projektu. Robi się to poprzez dołączenie Listy o nazwie “Obiegi” i dodanie do niej określonego obiegu. Obecnie na serwerze demo mamy tylko jeden obieg standardowy i jego właśnie dodamy. Jeśli dany Klient ma obiegi personalizowane to tutaj właśnie pojawi się ich pełna lista.

    Widok dodawania Listy obiegów związanej z widocznością na projekcie.

Obieg tworzymy w tym samym miejscu, w którym ustalaliśmy właściwości dla plików (moduł – Wykaz danych). Wybieramy właściwą listę, nazywamy ją tak jak chcemy i klikamy “Zapisz”.

Widok listy do tworzenia obiegu standardowego.

Następnie wchodzimy w “Edytuj szczegóły” i konfigurujemy obieg w sposób odzwierciedlający przepływ pracy który robiliśmy ręcznie w wersji ePMflow bez obiegów.

Widok szczegółów listy obiegu.

Ostatni krok to utworzenie wszystkich zadań z planowanego procesu służącego tak naprawdę do zatwierdzania kolejnych rewizji dokumentów.

Widok okna tworzenia zadania w obiegu.

UWAGA:

  1. W obiegu typu KUD powinny być tylko załączniki które załączył wnioskodawca ponieważ zamierzamy używać kopiowania plików i automatycznego zmieniania statusu. Dlatego nie rekomendujemy włączania możliwości dodawania załączników.
  2. Obieg KUD nie służy do wymieniania się opiniami na roboczo. Służy tylko do finalnej formalnej akceptacji danego pakietu dokumentów.

Został nam ostatni krok czyli uruchomienie obiegu i przejście go przez osoby które dodaliśmy do obiegu. Najlepiej będzie jak obejrzycie to na poniższym nagraniu z webinara.

Dlaczego warto używać obiegów w uzgadnianiu dokumentacji?

  1. Standaryzujemy procesy w firmie lub/i na projekcie.
  2. Szybko ustalimy zatory w uzgodnieniach.
  3. Raporty z uzgodnień są cenną bazą wiedzy, szczególnie jeśli będzie potrzeba wrócić do nich po kilku latach.

W kolejnej części przyjrzymy się bardziej zaawansowanym opcjom w obiegach i możliwościom ich raportowania

Maciej Dejer
ePM

Leave a comment
More Posts
Comments
Comment