Redukcja ryzyka poprzez planowanie

Jedną z podstawowych, często cytowanych korzyści z zatrudniania integratorów systemów do pomocy we wdrażaniu projektu jest redukcja ryzyka. Doświadczeni praktycy w jakiejkolwiek dziedzinie techniki odnoszą większe sukcesy niż entuzjastyczni amatorzy. Integratorzy systemów są wyspecjalizowanymi ekspertami w zakresie projektowania i realizacji przemysłowych systemów automatyki. Jednak nawet najbardziej utalentowany integrator bez wiedzy o procesie nie będzie w stanie poprawnie go skonfigurować i uruchomić.

– Poznanie i udokumentowanie wymagań użytkownika końcowego to największy pojedynczy czynnik decydujący o powodzeniu projektu – mówi Dean Streck, główny specjalista w VI Engineering. – Naszym ludziom, wykonującym codziennie pracę opartą na projekcie, mówimy, że muszą dokładnie, na piśmie, precyzować, co zamierzają robić, oraz określić, na jakiej podstawie będą z tej pracy rozliczeni.
Brent Stormwall, wiceprezes Pozytron, zgadza się z tym stwierdzeniem. – Kompletny projekt i plan komunikacji to klucz do tego, aby „sukces” i „zakończenie” były jednakowo rozumiane przez inwestora i integratora.
Jerry Armstrong, inżynier aplikacji z Walco, mówi: – Nie ma nic tak deprymującego dla inwestora, jak stwierdzenie „Nie wiedziałem, że wymagania dotyczyły również tego”, które słyszy po rozpoczęciu lub, co gorsza, po zakończeniu prac. Handlowiec lub inżynier aplikacji odpowiedzialny za organizację pracy musi przeznaczyć odpowiednią ilość czasu na rozmowę z inwestorem oraz wybór technologii, aby wiedzieć dokładnie, jakie są potrzeby klienta i jak je zaspokoić. To wcale nie oznacza, że należy omawiać każdy szczegół, taki jak kolor przycisków, najważniejsze punkty oraz wielkość przedsięwzięcia muszą być jednak zdefiniowane.
Armstrong dodaje – Mając dobrze zrobiony projekt, masz mniej niespodzianek w czasie implementacji systemu.
Don Ulrich, prezes Stone Technologies, przyznaje, że tworzenie planu i szacowanie ryzyka to klucz do sukcesu w każdym projekcie automatyki. – Mówimy naszym klientom już na samym początku, jak zamierzamy zrealizować każdy detal projektu. To staje się bazą do określenia wymagań i dla detali spisywanych w umowie. Następnie tworzymy kompletną ocenę ryzyka zawierającą ryzyko poślizgu czasowego, ryzyko technologiczne, ryzyko związane z niewystarczającymi zasobami, a nawet ryzyko tego, że klient nie dostarczy nam na czas wymaganych informacji.
Kiedy omawiamy projekt po raz kolejny, ponownie szacujemy ryzyko, ponieważ pojawiają się nowe zagrożenia, których nie uwzględniliśmy wcześniej. Jeśli tylko potrafimy je przewidzieć – rozwiązujemy je szybko. Najwięcej problemów sprawiają jednak te zagrożenia, które wydawały się niegroźne.

Joel Langill, główny konsultant i inżynier w ENGlobal Automation, zgadza się z tym. – Takim zagrożeniem może być ryzyko technologiczne dotyczące tego, jakich środków trzeba będzie użyć przy wdrażaniu nowego systemu lub uruchamianiu nowego oprogramowania. Mogą to być też zagrożenia związane z działalnością klienta – czy poradzi sobie z migracją ze starej do nowej technologii, z jednoczesnymi przenosinami do nowej dużej sterowni.
Ponadto dodaje: – Każde ryzyko indywidualne z punktu widzenia danego projektu powinno być udokumentowane i omówione. Kiedy tylko zostanie ono zrozumiane, należy skorygować procedury testowe tak, aby pokazywały skuteczność działań oraz łagodziły zagrożenie jeszcze zanim projekt zacznie być realizowany.
Jeśli chodzi o planowanie takich testów, Langill poleca zaczynać od końca. Najpierw tworzy plan testu finalnego, później procedury testowe linii produkcyjnych oraz samego sprzętu. Dopiero wtedy przygotowuje projekt, mając wciąż na uwadze te testy.
– Jednym z największych błędów popełnianych w projektach wymagających integracji wielu urządzeń automatyki jest brak opracowanych procedur testowych w czasie, kiedy sprzęt już jest gotowy – zaznacza Langhill. – To często skutkuje szybkim opracowywaniem testów, które albo nie sprawdzają wszystkiego, co powinny, albo ukrywają znane problemy.
Dan Purvis, główny inżynier systemów i przedstawiciel Houston Office of Optimation, opisuje, jak jego firma tworzy procedury testowe w postaci przedstawionego „diagramu V” na podstawie dokumentacji projektu. Nie jest zaskoczeniem, że początek to wymagania klienta końcowego. Trzem fazom testów odpowiadają trzy dokumenty pokazane na obrazku.
– W końcowym stanie projektu otrzymujesz oczywiście kompletną listę rzeczy, bo jego najgorsza część została zrobiona zaraz na początku – mówi Purvis. Ostateczne potwierdzenie zgodności z wymaganiami klienta, wymaganiami procesowymi i dokumentacją odzwierciedla specyfikację projektową. Gdzieś pomiędzy znajduje się bieżąca implementacja projektu – pisanie, integracja oraz test programu.
Purvis dodaje: – Instrukcje testowe dla programistów i operatorów tworzone są na podstawie dokumentów z fazy projektowej. Fabryczne testy dopuszczenia (FAT) powstają na podstawie specyfikacji wymagań funkcjonalnych (FRS) oraz dokumentów FAT. Jakakolwiek niezgodność tworzy listę poprawek, ale liczba mogących pojawić się niespodzianek jest mniejsza.
Pracujący dla Stone Technologies Ulrich określa „brak niespodzianek” jako pierwszą zasadę planowania i nadzoru projektu. – Jak by nie patrzeć – mówi – integratorzy nie są w stanie poradzić sobie z czymś, o czym nie wiedzą. Zasada numer dwa brzmi „Mogę zrobić to później – to nie jest plan”. Ulrich twierdzi, że klienci wolą słyszeć o problemach tak szybko, jak to możliwe, szczególnie jeśli złym wieściom towarzyszy od razu plan rozwiązania problemu.
Ray Bachelor, prezes Bachelor Controls, opisuje zarządzanie projektem: – Zarządzanie projektem to nie tylko raportowanie wydarzeń. Trzeba zarządzać nim w taki sposób, aby mieć pewność, że pozostaje on w zgodzie z pierwotnymi wymaganiami funkcjonalnymi. Powinien zatem mieć realistyczny plan, który pozwoli rozpocząć prace, a nie optymistyczny wykaz, który nieuchronnie prowadzi do opóźnień.
Artykuł pod redakcją mgr. inż. Łukasza Urbańskiego, doktoranta Instytutu Automatyki Przemysłowej Wydziału Elektrycznego Zachodniopomorskiego Uniwersytetu Technologicznego w Szczecinie