Zidentyfikowanie niewłaściwych kroków, takich jak brak zbudowania zespołu wielobranżowego oraz brak określenia odpowiedzialności uczestników projektu na jego wczesnym etapie, może pomóc w zapewnieniu sukcesu nawet bardzo złożonych projektów systemów automatyzacji i sterowania.
Wszystkie udane projekty systemów automatyzacji i sterowania posiadają wspólne cechy, które stanowiły o ich sukcesie. Podobnie jest w przypadku projektów nieudanych. W tej kategorii projektów podjęto niewłaściwe kroki, które miały znaczący, negatywny wpływ na efekt końcowy prac. Prawidłowa realizacja projektu systemu automatyzacji i sterowania jest procesem, który wymaga nieustannego monitoringu i dostrajania przez liderów projektu. Proces ten obejmuje wiele kluczowych kroków, które zapewniają, że projekt zostanie zrealizowany właściwie i spełni wymagania użytkownika końcowego.
W praktyce udowodniono, że osiem wymienionych w dalszej części tekstu elementów powoduje zwykle istotne wyzwania dla projektu. Kluczową sprawą jest to, aby te niewłaściwie podejmowane kroki były rozpoznane na wczesnym etapie procesu projektowego, a uczestniczące w nim strony współpracowały nad tym, aby projekt szczęśliwie balansował aż do finalnego sukcesu.
1. Brak utworzenia zespołu wielobranżowego
Projekty integracji systemów nie zawsze są proste i banalne, co więcej mogą obejmować wielu uczestników w wielu fazach. Każdy uczestnik zwykle posiada fachową wiedzę ze swojej własnej, konkretnej dziedziny, a zrównoważony zespół powinien być reprezentowany przez kompetentne i doświadczone osoby we wszystkich aspektach objętych projektem. Posiadanie takich członków zespołu, którzy potrafią w przypadku powstania problemów szybko i właściwie je rozwiązywać jest sprawą kluczowej wagi dla udanego projektu.
Takimi uczestnikami projektu mogą być: użytkownik końcowy, firma inżynierska, generalny wykonawca, wykonawca prac elektrycznych, integrator systemów i/lub wykonawcy prac mechanicznych. Każda z tych branż musi być reprezentowana przez osoby posiadające odpowiedni poziom kompetencji, aby zapewnić, że zespół projektowy składa się z doświadczonych fachowców, którzy potrafią spełnić oczekiwania projektu. Weryfikacja kandydatów na członków zespołu projektowego, wybieranych spośród doświadczonych fachowców, jest kluczowym zadaniem przy budowaniu silnego i kompetentnego zespołu, który przygotuje projekt. Zaś odpowiedzialność w kwestii zadawania odpowiednich pytań kandydatom tak, aby zapewnić, że zespół będzie składał się z właściwych ludzi, którzy prawidłowo wykonają zadanie, spoczywa na liderze projektu.
2. Dokonywanie założeń przy definiowaniu ?sukcesu? projektu.
Zdefiniowanie tego, co oznacza ?sukces? projektu dla wszystkich uczestniczących w nim stron, nie może zostać zbagatelizowane. Definicja ta powstaje zwykle na bazie specyfikacji wymagań użytkownika (ang. user requirements specification, URS). Popularnym błędem jest tu zakładanie, że jakaś pozycja, efekt projektu (ang. deliverable) lub oczekiwanie klienta, które nie zostały wyraźnie wymienione z nazwy, jest nieodłączną częścią projektu. Powinny być zidentyfikowane specyficzne cele i oczekiwania wobec projektu, a każdy jego uczestnik powinien w pełni rozumieć, czego się oczekuje.
Innym, bardzo popularnym błędem, jest zakładanie, że jakaś platforma spełnia standardowe wymagania funkcjonalne, które mogą być realizowane przez specyficzną, istniejącą u klienta platformę. Może jednak okazać się, że funkcjonalność ta nie jest oferowana w standardzie tej innej platformy i będzie wymagała dopasowania jej do potrzeb klienta oraz odpowiedniego przetestowania tak, aby zapewnić, że spełni jego oczekiwania. Jeśli te oczekiwane funkcje nie zostaną w pełni zidentyfikowane przed uruchomieniem projektu, to może to doprowadzić do poniesienia dodatkowych kosztów.
Aby zdefiniować całą podstawową funkcjonalność, można opracować specyfikację oprogramowania, aby zidentyfikować typowe funkcje bibliotek lub standardy programowania, które powinny być zawarte w projekcie. W niektórych przypadkach, z powodu ograniczeń wynikających z harmonogramu, budżety przeznaczone na projekt są wyznaczane tak, jak dla wykorzystania platform standardowych, bez brania pod uwagę jakichkolwiek funkcji dopasowanych do potrzeb klienta. Wprowadza to dodatkowe ryzyko, tak więc znajomość tego, co posiadamy w istniejącymstarszym systemie sterowania jest sprawą zasadniczą w zidentyfikowaniu tego, jak sukces projektu będzie wyglądał z perspektywy przyszłej platformy systemowej.
3. Opracowanie planu z funkcjonalną specyfikacją projektu (FDS).
Migracja istniejących starszych platform systemów sterowania może stać się zawiłym i żmudnym procesem, zwłaszcza w perspektywie zminimalizowania kosztów produkcji. Te typy projektów wymagają rozległego planowania i prac inżynierskich przed wyłączeniem istniejącego systemu, identyfikacji każdej pojedynczej pętli sterowania i układu logicznego, aby zapewnić płynne i dokonane na czas przejście na nowy system. Nieznane informacje wprowadzają ryzyko dla projektu z automatyki, biorąc pod uwagę poziom integracji, który jest wymagany dla prawidłowej współpracy wszystkich elementów i łatwej wymiany danych. Uruchomienie projektu z automatyki dopiero po uprzednim opracowaniu specyfikacji funkcjonalnej projektu (ang. functional design specification, FDS) tak, aby zdefiniować produkty projektu oraz zadania inżynierskie, minimalizuje to ryzyko.
Dokument FDS zwykle definiuje wszelkie aspekty:
? architektury logicznej
? wymagań dotyczących sprzętu
? wymagań dotyczących oprogramowania
? wymagań licencyjnych
? strategii rozwijania oprogramowania
? migracji wejść/wyjść (I/O) lub strategii cutover (w metodyce ASAP: działania związane z transferem danych z istniejącego starszego systemu do systemu SAP)
? wdrożenie mapy drogowej
? opracowanie produktów projektu
? plany testów
? plan uruchomienia nowego systemu na miejscu
? plan odbioru technicznego na miejscu
Ten dokument spełnia wiele funkcji. Może być wykorzystywany jako ?żywy? dokument, który określa wszystkie komponenty, produkty projektu oraz strategie wdrożenia, co może się różnić w zależności od obszaru na obiekcie gdzie instalowany jest nowy system, ale może także służyć, jako narzędzie do oceny pracy integratorów wielu systemów. Powszechną praktyką wśród wykonawców jest to, że przy braku umieszczenia pewnych konkretnych pozycji w wykazie efektów projektu, dostarczają oni tylko niezbędne minimum, aby obniżyć koszty. Takie podejście przerzuca odpowiedzialność za projekt na użytkownika końcowego, który ma sam uzupełnić te brakujące pozycje.
Jest to ważny dokument, który zapewnia, że projekt będący w fazie realizacji przygotowany jest na każdą sytuację, wszystkie strony projektu akceptują specyficzne odpowiedzialności. Wykonanie założeń ogólnych na poziomie planowania efektów projektu zwykle daje w wyniku duże różnice w cenach ofertowych od różnych integratorów systemów. Generalnie oferenci z niższą ceną sporządzają kosztorysy zawierające mniej efektów projektu i mogą one nie być precyzyjnie określone w ich ofertach. Prowadzi to do zmian zamówień i stwarza ryzyko dla projektu. Posiadanie dokumentu FDS, który jasno określa wszystkie oczekiwania klienta, pomaga w otrzymaniu spójnych i dokładnych ofert cenowych od wielu integratorów systemów i pozwala na dokładną weryfikację przy wykorzystaniu takiego porównania, jak w popularnej grze planszowej ?Apples to Apples? (?jabłko do jabłka?).
Dokument FDS nie tylko podaje definicję specyficznego zakresu projektu z automatyki, ale także zawiera strategię jego wdrożenia i definicję uruchamiania i odbioru technicznego każdej fazy projektu oraz pełna listę produktów projektu. Dokument ten jest narzędziem, które przedstawia kompletną mapę drogową wdrożenia projektu, która może obejmować wiele faz w ciągu kilku lat.
Posiada on ogromną wartość, poprzez wyraźne określenie wszystkich wymaganych elementów projektu oraz usuwa ryzyko poprzez zdefiniowanie wszystkich nieznanych pozycji. Dokument ten zdecydowanie jest uważany za jeden z najważniejszych czynników osiągnięcia sukcesu przez projekt migracji istniejącego systemu lub całkowicie nowego systemu automatyki.
4. Nieprzestrzeganie procesu realizacji projektu i chodzenie na skróty
Opracowanie projektu kompleksowego systemu automatyki obejmuje kilka różnych aspektów i elementów, które muszą się połączyć i współpracować harmonijnie, aby osiągnąć sukces. Udane projekty są wynikami końcowymi przestrzegania sprawdzonych procedur i etapów realizacji procesów opracowywania projektów. Porażki mogą być przypisane złym nawykom, podobnie jak sukcesy dobrym nawykom i starannej realizacji procesu. Każdy etap i faza projektu są tak samo ważne, jak następne. Odpowiedzialność za zapewnienie realizacji procesu spoczywa na liderze projektu. Potrzebny jest też zespół, który sprawdził się w przeszłości i posiada w pełni udokumentowany oraz zrozumiały proces skutecznego wdrożenia projektu. Chodzenie na skróty, cięcie kosztów lub zwyczajne przechadzanie się bez celu, czy też bycie zachowawczym, może być szkodliwe dla projektu.
Wyniki cięć kosztów nie są widoczne od razu. Powstałe problemy zwykle są opóźnione w stosunku do ich przyczyn o kilka etapów projektu i prawie zawsze robią niemiłą niespodziankę w fazie odbioru technicznego. Liderzy projektu muszą przestrzegać procesu realizacji projektu i cenić dyscyplinę, aby ?pozostać na kursie?. Należy unikać poddawania się naciskom ze strony harmonogramów, poprzez nieobchodzenie kluczowych etapów, które utrzymują jakość i promują sukces poprzez utrzymywanie każdego w odpowiedzialności.
5. Brak określenia odpowiedzialności uczestników projektu
Jasne określenie zakresu odpowiedzialności osób uczestniczących w projekcie jest sprawą zasadniczą, aby zapewnić, że nie istnieją żadne luki i wszystkie aspekty projektu zostały poruszone. Nakładanie się odpowiedzialności powoduje niewydolność prac projektowych, zaś wyraźne określenie odpowiedzialności i ich zakresów jest ważne dla zapewnienia tego, iż każda osoba będzie zgadzała się na wykonanie odpowiedniego, przypisanego sobie zakresu prac. Jednym ze sposobów określenia odpowiedzialności jest opracowanie macierzy odpowiedzialności, które określa wszystkie obszary produktów projektu, wymienione w rzędach. Następnie wszyscy uczestnicy projektu są przypisywani pod względem odpowiedzialności do odpowiednich kolumn. Przy pomocy tej macierzy można jasno zidentyfikować wszystkie zakresy i poziomy odpowiedzialności, na przecięciach się rzędów i kolumn. Macierz odpowiedzialności powinna być opracowana i dostarczona wszystkim uczestnikom na wczesnym etapie projektu, aby zapewnić, że wszystkie ograniczenia zakresów odpowiedzialności będą znane i rozumiane. To ćwiczenie pomoże w uniknięciu nakładania się zakresów odpowiedzialności, promowaniu efektywności prac i wyjaśnianiu roli i produktów każdego uczestnika projektu. Ćwiczenie to może wydawać się trywialne, ale w niektórych sytuacjach może stać się bardzo obszerne, nawet w przypadku najprostszych projektów, gdy każde zadanie związane z planowanymi efektami projektu jest rozdzielane na wiele sekcji.
6. Niebranie pod uwagę planu awaryjnego
Posiadanie bufora, który pozwoli na przesuwanie harmonogramu i/lub budżetu projektu, sprzyja sukcesowi projektu. Nawet w najłatwiejszych i najbardziej płynnych w realizacji projektach, zawsze występuje nieoczekiwana zmiana, która jest nieprzewidziana na etapach opracowywania. O ile szczęście dopisze, zmiany te są małe, nie wymagają tworzenia nowej wersji projektu i są wykrywane oraz korygowane na wczesnym etapie realizacji projektu. Trzeba jednak mieć świadomość, że każda zmiana lub dodatek do wymagań zakresu projektu, może spowodować dużą jego dezorganizację i jeśli nie będzie bufora w harmonogramie, budżecie lub czasie przestoju przy przejściu na nowy system, może stać się onamocnym ciosem zadanym planowanemu całkowitemu sukcesowi projektu.
Zmiany w projekcie są nieuniknione i uzasadnianie posiadania potencjału na realizacje tych zmian powinno być wbudowane w proces planowania, podczas określania celów projektu. Każda osoba zaangażowana w projekt powinna mieć ustalone daty realizacji, budżety i zaplanowany czas przestoju oraz powinna starać się spełnić te wymagania. Te daty, wartości oraz długości czasów przestoju są określane jako ?cele aktywne?. Powinny być one komunikowane otwarcie i często. Jednak cele planu awaryjnego są uważane za cele finalne, które mogą być wykorzystane przez użytkownika końcowego lub nawet klienta wewnętrznego. Różnicą pomiędzy celem aktywnym a finalnym jest kwota awaryjna. Kwota ta jest zwykle zatajana na początku projektu i w miarę jego rozwijania może być wykorzystana, jeśli wydaje się to konieczne. Zamierzeniem nie jest wprowadzenie kogoś w błąd na temat dat finalnych, ale zmniejszenie ryzyka poprzez pozwolenie stronom kontraktu na podleganie celowi finalnemu. Pozwala to na pewną elastyczność i tak konfiguruje projekt, aby odniósł sukces.
7. Brak sporządzenia planu testów
Testowanie jest zasadniczą częścią udanego projektu. Kiepskie wykonanie testów prowadzi do przedłużenia uruchomienia projektu na miejscu oraz konieczności wprowadzania na miejscu takich zmian w oprogramowaniu, które powinny być wprowadzone w wyniku testów u wykonawcy. Wykonanie testów jest zaplanowanym wydarzeniem, które obejmuje wszystkie zaangażowane strony, aby zapewnić, że użytkownik końcowy otrzymuje system, który spełnia jego wymagania.
Stworzenie dokładnego planu testów na wysokim poziomie na początku projektu określi oczekiwania testowe i pozwoli wszystkim zainteresowanym stronom na zrozumienie poziomu swojego wkładu i zaangażowania. Ogólna strategia testowania powinna obejmować zarówno sprzęt, jak i oprogramowanie. Testy powinny być wykonywane jednocześnie lub niezależnie od siebie, ale oba rodzaje powinny być zrealizowane dokładnie.
Procedury testowe zwykle rozpoczynają się od testów akceptacyjnych sprzętu (ang. hardware acceptance testing, HAT), który zasila szafy We/Wy oraz testowania punktów We/Wy tak, aby zapewnić, że całe okablowanie wewnętrzne i funkcje sprzętowe działają tak, jak zostały zaprojektowane. Jest to wykonywane przez opuszczeniem warsztatu montującego panele. Wszyscy integratorzy systemów powinni posiadać wewnętrzne procedury jakości HAT, w których podane są wszystkie specyficzne punkty testowe, aby zapewnić, że klientowi dostarczane są panele o odpowiedniej jakości.
Testowanie oprogramowania jest wykonywane etapami, które częściowo nakładają się na siebie, aby zapewnić odpowiednią jakość weryfikacji. Najpierw powinien być wykonany przez integratora wewnętrzny test akceptacyjny, a następnie dopiero test z udziałem klienta. Po zakończeniu testu wewnętrznego należy wykonać fabryczny test akceptacyjny (ang. factory acceptance test, FAT). Realizacja tego testu powinna być przeprowadzona przez użytkownika końcowego, przy wsparciu ze strony integratora systemów. Test FAT generalnie obejmuje sprawdzenie całej konfiguracji, w stosunku do specyfikacji oprogramowania. Jeśli specyfikacja nie istnieje w jakiejś formie, to bardzo trudno jest zapewnić, że oprogramowanie spełni wymagania użytkownika końcowego.
Po zakończeniu dokładnych testów HAT i FAT, system sterowania jest gotowy do wysyłki na miejsce zainstalowania. Po zakończeniu instalacji tego systemu użytkownik końcowy wykonuje test odbioru końcowego (ang. site acceptance test, SAT), który zwykle odbywa się w asyście integratora systemów. Po przetestowaniu sprzętu w szafach sterowniczych, wraz z funkcjami oprogramowania, do sprawdzenia pozostały już tylko urządzenia obiektowe. Po podłączeniu wejść i wyjść urządzeń obiektowychwykonanie testów SAT powinno naśladować procedury FAT, ale przy wykorzystaniu urządzeń obiektowych.
Testy SAT nie powinny obejmować zmian w oprogramowaniu lub sprzętowych w systemie, jeśli specyfikacje zostały opracowane poprawnie, zaś testy zostały przeprowadzone prawidłowo. Ponadto procedury SAT zmieniają się w dużym stopniu, w zależności od funkcjonalnych możliwości przetwarzania danych i funkcji bezpieczeństwa w miejscu zainstalowania systemu. Testy powinny być dopasowane do obiektu, aby spełniać wymagania realizowanych w nim procesów, ale powinny także być dokładne, aby zapewnić, że na wszystkie aspekty systemu została zwrócona uwaga, aby dostarczyć bezpieczny i prawidłowo funkcjonujący system.
8. Brak dobrej komunikacji
Komunikacja pomiędzy specjalistami reprezentującymi różne branże może być wyzwaniem, szczególnie gdy harmonogramy są napięte i każdy uczestnik jest skoncentrowany na wykonywaniu swoich zadań i realizacji swoich celów. Jednak liderzy projektów muszą ustalić oczekiwania i pozwolić każdej zaangażowanej osobie na otwartą i częsta komunikację. Każda z zaangażowanych stron może znajdować się w odległym geograficznie miejscu i nie zawsze może być łatwo dostępna, aby podjąć dyskusję twarzą w twarz. Jednak jest zawsze zalecane, aby fizycznie uczestniczyć w otwarciu projektu, aby dążyć do promowania silnej relacji pomiędzy współpracownikami i pozwolić każdemu osobiście poznać innych uczestników projektu. Następnym z najlepszych rozwiązań jest wideorozmowa, która także może być efektywną metodą komunikacji.
Liderzy projektu są traktowani jak centrum dystrybucyjne dla komunikacji i są odpowiedzialni za zapewnienie, że wszystkie strony efektywnie wymieniają informacje. W celu zapewnienia, że wszystkie luki są wypełnione, lider projektu musi nauczyć się, w jaki sposób komunikuje się każdy członek jego zespołu i określić drogę komunikacji oraz stworzyć odpowiednie środowisko komunikacyjne, aby umożliwić im to. Ocena umiejętności członków zespołów projektowych pozwala liderom na zaadoptowanie ich stylu i/lub podejścia, aby pomóc w przezwyciężeniu potencjalnych braków komunikacji. Łatwiej jest to powiedzieć niż zrobić i wymaga to odpowiednich umiejętności ludzkich, aby zapewnić prawidłową ocenę. Ocena ta jest procesem trwającym przez cały projekt i staje się coraz bardziej kluczowa, w miarę jak zbliża się termin realizacji projektu.
Przydzielenie dedykowanego przedziału czasowego na komunikację pomiędzy grupami projektowymi jest sprawą zasadniczą. Może się to wydawać żmudnym zadaniem na początku projektu, ale takie spotkania ustalają oczekiwania i atmosferę realizacji projektu. Idealnie byłoby, gdyby ustalone spotkania odbywały się cyklicznie, zaś ten sam porządek czy wzór był przestrzegany, co powinno zawierać przedział czasowy dla każdego przedstawiciela, aby poruszał otwarcie wszelkie kwestie w grupie. W niektórych przypadkach lider projektu może być zmuszony do przygotowania szeregu pytań dla członków zespołu i pozwolić im na dostarczenie oczekiwanych informacji zwrotnych oraz wymaganych, aby pobudzić grupę do odpowiedniego współdziałania.
Liderzy projektu muszą także kontrolować współpracę członków zespołu, aby wydajnie wykorzystać przydzielony każdemu czas. Należy ograniczyć wyizolowane, szczegółowe dyskusje i polecić, aby odbywały się w odrębnej rozmowie, która powinna być ułatwiona przez liderów projektu. Po każdej dyskusji lider projektu powinien przekazać grupie zaktualizowane decyzje i działania, które zostały zidentyfikowane.
Klucze do sukcesu
Wdrożenie projektu automatyzacji systemu sterowania może być trudne do zarządzania, jeśli kluczowe aspekty nie są dokładnie zaplanowane. Stworzenie silnego zespołu wielobranżowego jest sprawą zasadniczą, aby w pełni podjąć odpowiedzialności związane z projektem. Zdefiniowanie celów i warunków sukcesu utrzymuje każdego członka zespołuprojektowego na właściwej drodze i odpowiednio zmotywowanego. Realizacja takiego projektu na podstawie znanych i sprawdzonych procedur, umożliwia wszystkim członkom zespołu planowanie i pełne zdefiniowanie szczegółowych zadań, wymaganych do spełnienia celów ogólnych projektu. Chodzenie na skróty lub pozwolenie na zaniedbania w procesie realizacji projektu, może wprowadzić nieprzewidziane problemy, które nie są łatwe do rozwiązania. Tak jak w przypadku liderów projektu, to naszą odpowiedzialnością jest, aby usunąć jak najwięcej ryzyka z projektu. Jest to realizowane poprzez określenie nieznanych elementów oraz przeprowadzenie testów FDS przed wdrożeniem projektu, aby zidentyfikować kluczowe obszary zagrożeń i określić rozwiązania zminimalizowania ryzyka.
Nakładanie się odpowiedzialności nie zawsze jest złe, ale granice zakresów odpowiedzialności dla uczestniczących w projekcie specjalistów ze wszystkich branż muszą być w pełni zbadane, aby zapewnić, że nie istnieją żadne luki. Ustalanie strategii na wypadek sytuacji kryzysowej jest sprawą zasadniczą, ponieważ w procesie realizacji zawsze powstaną problemy i doświadczeni liderzy projektu będą rozliczać się z tych problemów. Inną metodą pomagającą w ograniczeniu ryzyka jest przygotowanie dokładnego planu testów. Każdy projekt z automatyki powinien posiadać jasny i precyzyjny plan kontroli jakości, zaś jedynym sposobem na jej realizację jest pełne przetestowanie systemu, zarówno po jego opracowaniu i przed wysyłką do klienta, jak i podczas wdrażania.
Komunikacja jest zasadniczym spoiwem, które pomaga w utrzymaniu odpowiedniego tempa prac przy realizacji projektu. Musi ona być stale oceniana i zarządzana na wszystkich poziomach, aby zapewnić, że członkowie zespołu projektowego w pełni rozumieją to, co jest naprawdę potrzebne. Wszystkie z wymienionych wyżej aspektów są kluczowymi elementami dla projektów systemów automatyzacji i sterowania. Projekty te są zawsze wyzwaniem, ale także i nagrodą, zaś dokładne postępowanie według ustalonych procedur i wskazanych w artykule elementów pomoże w odniesieniu sukcesu zarówno w trakcie realizacji projektu jak i jego późniejszego wdrożenia.
Autor: Robbie Peoples jest menedżerem d/s integracji systemów w firmie Cross Company Integrated Systems Group.
