Oprogramowanie często wydaje się być szybkim rozwiązaniem każdego problemu. Ale samo w sobie może stać się problemem. Brak przewidywania w trakcie instalacji może być przyczyną złego działania i awarii. Wybór złych narzędzi do pracy spowoduje, że nowy proces będzie przebiegał gorzej niż ten, który miał być usprawniony.
Istnieje zawsze różnica pomiędzy tym, jak system powinie
n działać a jak działa. Niezależnie od tego, czy wykonujesz rzeczy z plastiku, pluszowe zabawki, czy maszyny drukarskie, pryncypia kształtowania i wzmacniania informatycznej strony biznesu są te same.
Na kłopoty: szkolenie
Jaki jest jeden z pierwszych Rola inżyniera w wyborze i wdrażaniu oprogramowania problemów, z którym stykają się użytkownicy nowego oprogramowania? Nie mają pojęcia, jak wykonać jakąkolwiek operację, na co najprostszą radą jest wręczyć im instrukcję. Remedium na interpretację grubych podręczników użytkownika może być mały i krótki przewodnik po specyfi cznych najbardziej potrzebnych funkcjach, umożliwiający natychmiastowy start. Oprogramowanie jest bezużyteczne, jeśli staje się przeszkodą dla użytkowników w ich codziennej pracy.
Szkolenie jest lepsze. Szybkie przejście przez najważniejsze funkcje z kimś, kto już zna oprogramowanie, może mieć decydujące znaczenie dla decyzji o zakupie. Wciąż zdarzają się pomysły, aby posadzić wszystkich w jednym miejscu na całodniowej sesji, na której będą prezentowane wszystkie wejścia i wyjścia oraz funkcje programu. Informatycy może to kochają, ale osoby o mniejszych zdolnościach technicznych mogą się tylko bardziej rozczarować.
Jeśli to możliwe, należy pracować z trenerami nad opracowaniem specyfi cznych szkoleń. Należy stworzyć listę wszystkich osób, które potrzebują szkoleń, sklasyfi kować rodzaj wykonywanych przez nich prac i sposobów użytkowania systemu. Następnie należy zorganizować szkolenia, które będą odpowiadały ich potrzebom. Oprogramowanie jest często nabywane na podstawie wyobrażeń kierownictwa o potrzebach użytkowników lub marzeń informatyków. O ile jednak użytkownik jest w stanie natychmiast wskazać problemy, z jakimi się styka w codziennym użytkowaniu, to może nie być w stanie zidentyfikować potencjalnych problemów z oprogramowaniem na podstawie prezentacji sprzedawcy. To moment, w którym inżynier z dużym doświadczeniem w zakresie systemów staje się niezbędny.
Weźmy jako przykład system zarządzania dokumentami. Firma X potrzebuje oprogramowanie, które może śledzić położenie każdego elektronicznego dokumentu i rysunku. Zakupione oprogramowanie, było najtańszą dostępną opcją, którą sprzedawca nazwał „wersją szkieletową tego, czego potrzebujemy”. Okazało się, że rozwiązanie ma bardzo słabą architekturę. Nie było bazy danych, ani protokołów sortujących. Należało też samodzielnie oprogramować interfejsy pokazane w trakcie prezentacji. Jeśli ktoś z doświadczeniem technicznym brałby udział w negocjacjach, a nie tylko pracownicy działu zakupów, mógłby zapytać: „Co dokładnie rozumie Pan przez wersję szkieletową?” Cała idea systemu zarządzania dokumentami została pogrzebana, ponieważ firma X otrzymała coś w najlepszym razie bezużytecznego, a trzy tygodnie prób zbudowania czegokolwiek wokół zakupionego szkieletu zaprowadziło donikąd.
Inżynierowie pokonują problemy
Inżynierowie są łącznikiem pomiędzy fabryką/warsztatem i kadrą zarządzającą. Rozumieją, czego potrzebują użytkownicy końcowi. Często są jedynymi rozumiejącymi prawdziwe problemy fabryki w czasie prezentowania oprogramowania. Co więcej, są jedynymi, którzy widzą braki aktualnie używanego oprogramowania. O wiele prościej jest żądać wybranych funkcji i cech oprogramowania przed zakupem niż po.
Jako wyszkoleni zawodowcy, aby przewidywać potencjalne problemy przed wdrożeniem, inżynierowie o wiele częściej zadają pytania o sprawy, których inni nie dostrzegają. Co więcej, ponieważ znają stosowane oprogramowanie i sprzęt, o wiele łatwiej przewidują zgrzyty przy próbie dołożenia jednego lub kilku trybików do informatycznej maszynerii.
Jak nowy tryb będzie pasował do istniejącej korporacyjnej maszynerii? Czy zamierzasz dostosować istniejące procesy do nowego oprogramowania? Czy zamierzasz dostosować oprogramowanie do istniejących procesów? Jak zawsze są wady i zalety każdego rozwiązania. Jeśli konieczne jest dostosowanie procesów do oprogramowania, zmiany będą dotyczyły całego ciągu działań.
Dostosowanie procedur do oprogramowania jest idealną okazją do usunięcia zbędnych operacji i działań. Dopasowanie oprogramowania do procesów także jest powodem do wymuszenia zmian w przepływie procesów. Dopasowanie procesów do oprogramowania często okazuje się „chwytem prawą ręką za lewe ucho” i skutkuje tym, że nowe oprogramowanie stwarza tylko problemy w działaniach, które wcześniej były realizowane sprawnie.
Jeśli brak jest planów dotychczasowych działań, to jest to dobry moment, aby je wykonać. Kierownictwo jest bardziej skłonne udostępnić zasoby, aby dowiedzieć się, jak wyglądają procedury w firmie i określić, jak można je lepiej realizować, jeśli powodzenie wdrożenia oprogramowania wartego kilka milionów złotych będzie od tego zależeć. Jeśli nowe oprogramowanie wymusi poprawę przebiegu procesów, wdrożenie go będzie miało dodatkowy pozytywny efekt, który inaczej nie mógłby być osiągnięty, który może być osiągnięty tylko wtedy, gdy się dobrze wykona wszystkie etapy prac.
|
A jak to jest w Polsce?
Dział IT to poważna część przedsiębiorstwa, z dużym budżetem i niepodważalną pozycją w firmie. Istotna i kluczowa rola informatyki w zarządzaniu jest doskonale rozumiana w większości przedsiębiorstw. Dlaczego więc, gdy zarząd stwierdza, że stosowany system informatyczny jest niewydolny, zaczyna się droga przez mękę, a wybór nowego systemu wspierającego zarządzanie staje się wojną? W dodatku często zakończoną pyrrusowym zwycięstwem. Problemy poruszane w artykule są niestety powtarzającą się dolegliwością, nieodzownie związaną z zakupami oprogramowania. Dotyczy to nie tylko zastosowań ściśle inżynierskich lub produkcyjnych, ale także wszelkich systemów wspomagających zarządzanie. Autorka jako częstą przyczynę podaje odseparowanie procesu zakupowego od osób bezpośrednio zainteresowanych oraz merytorycznie odpowiedzialnych. Jednak przyczyn dokonywania złych wyborów jest wiele. Trudno o jednoznaczną i uniwersalną odpowiedź, gdyż każde przedsiębiorstwo jest inne i występują w nim inne ograniczenia, zależności, działają inne mechanizmy.
Inną przyczyną, z którą dość powszechnie stykam się w praktyce, jest nawyk zarządzania fi rmą jak ciągłym procesem, co jest stanem normalnym w czasach status quo. Gdy jednak musimy dokonać zmian, potrzebne jest spojrzenie projektowe.
Typowe powody do wymiany oprogramowania są zwykle te same: słabnąca wydajność wobec rozwoju firmy, ograniczenia funkcjonalne, brak integracji pomiędzy aplikacjami, słabe możliwości raportowe i analityczne. Czasem zdarza się, że dotychczasowe oprogramowanie było tworzone przez własną grupę programistów, która znalazła lepsze zajęcie i pozostawiła firmę bez szczegółowej dokumentacji do jednostkowego produktu.
Działanie projektowe od procesowego różni się kilkoma cechami. Przede wszystkim projekt jest działaniem odbywającym się w ograniczonym czasie, którego efektem ma być stworzenie produktu. Działanie procesowe zwykle skierowane jest na bieżące sprawy związane z prowadzeniem firmy. Dział księgowości jest typowym przykładem działania procesowego.
Mimo że wiedza o zarządzaniu projektami szerzy się bardzo szybko, kadra kierownicza wciąż ma trudności w jej implementowaniu w przedsiębiorstwach. W większości firm nie ma zatrudnionego ani jednego kierownika projektu, gdyż zwyczajnie nie ma takiej potrzeby.
W przypadku projektu informatycznego, podobnie jak na budowie, potrzebny jest kierownik. Kierownik projektu informatycznego powinien uczestniczyć od momentu fazy tworzenia wymagań poprzez wybór dostawcy, implementację i uruchomienie, na fazie stabilizacji kończąc. Wtedy ma możliwość wpływania na całokształt systemu. Kierownikiem projektu ze strony klienta często staje się szef działu IT. Rozwiązanie takie ma wiele zalet: zwykle jest to osoba doskonale znająca firmę. Ma też i wady. Szef IT będzie traktował projekt jako dodatkowy obowiązek. Często jest też silnie związany z istniejącymi rozwiązaniami, musi więc być otwarty na nowości. Wynajęcie doświadczonego kierownika projektu nie jest trudne. Istnieją firmy, które wynajmują takich ludzi, są też wolni strzelcy.
Często dużym dylematem dla zarządzających jest przejście ze starego na nowy system. W dobrze przygotowanym i zaplanowanym projekcie informatycznym przewidziane są takie działania, precyzyjnie zaplanowane i realizowane. Wspólnie ze wszystkimi zainteresowanymi proces taki jest krótki i pozwala na łagodną tranzycję bez wprowadzania zbędnych zaburzeń w codziennej działalności firmy. Oczywiście warunkiem jest przygotowanie nowego systemu w postaci akceptowalnej przez użytkowników końcowych, w więc po testach akceptacyjnych i spełnieniu wszystkich wymagań.
W różnych przedsiębiorstwach mogą występować różne krytyczne czynniki sukcesu projektu informatycznego. Z pewnością, niezależnie od tego, czy dotyczy to piekarni, banku czy fabryki, podejście projektowe minimalizuje ryzyko niepowodzenia i przyczynia się do lepszego działania nowego oprogramowania. I nie ważne, czy dostawcy przekonują o łatwości wdrażania swoich produktów, o czym klient może się przekonać dopiero na własnej skórze. Nieważne, czy wdrażamy program wart kilkaset tysięcy, kilka czy kilkanaście milionów. Musimy zgodnie ze starą żołnierską zasadą stracić wiele potu na przygotowaniach, aby późnej realizować wdrożenie bez ofi ar i strat. Musimy postarać się, by nasz projekt był pełnym zwycięstwem wszystkich uczestniczących w nim stron.
|
Szycie na miarę
Oto przykład projektu, w którym „szyto oprogramowanie na miarę”, zgodnie z wymaganiami fabryki. Fabryka chciała mieć system zarządzania danymi produkcyjnymi, który pozwoliłby na śledzenie potrzeb materiałowych, dróg produkcyjnych, danych o defektach bez żadnych zniekształceń aż do pojedynczych elementów. Inżynierowie, kierownictwo oraz dział zakupów usiedli razem, aby naszkicować listę wymagań wobec oprogramowania. W rezultacie zakupiono oprogramowanie, które spełniało postawione wymagania. Potem dopasowano je do wymagań aktualnego schematu procesów.
Inżynierowie dostrzegli potrzebę stworzenia map procesów dla ponad tuzina produktów. Potem dział IT udostępnił oprogramowanie wraz z trasami, zapotrzebowaniem materiałowym oraz mapą defektów, specyfi czną dla każdego produktu, Wtedy efekt okazał się wart zachodu. Wraz z wdrożeniem nowego oprogramowania stało się możliwe otrzymywanie cyklicznych raportów, tworzonych po kliknięciu myszką. Przejrzyste i jasne raporty wykazywały, ile czasu trzeba było przeznaczyć na naprawy. Wcześniej uzyskanie tych informacji wymagało godzin. Co więcej, możliwe stało się śledzenie właściwych i dokładnych kosztów napraw pojedynczych elementów i podzespołów.
Dopasowanie oprogramowania do indywidualnych potrzeb napotyka na szereg problemów. Praca z dostawcą programu opóźnia implementację i zwiększa koszty oprogramowania. Szkolenie pracowników powoduje, że będą musieli na jakiś czas zrezygnować z innych kluczowych projektów. Oznacza to jednocześnie, że mogą zmieniać oprogramowanie, rozumiejąc specyfi czne potrzeby zastosowania, także w przyszłości. Taka możliwość oznacza intensywną
pracę z programem. Może wiązać się z nauką na błędach. Zawsze wymagane jest debugowanie. Zaleca się, aby przeprowadzać tzw. beta-testy oprogramowania zanim będzie ono użytkowane.
Krytyczne testowanie beta
Innym ważnym zadaniem, które często jest pomijane, jest przeprowadzanie beta-testów oprogramowania. Zwykle inżynierowie rozumieją cechy dobrego interfejsu człowiek- -maszyna. Programiści są bardziej skoncentrowani na przetwarzaniu odbywającym się na serwerach niż na tym, czy schemat kolorów nowego oprogramowania będzie ułatwiał czytanie z ekranu o trzeciej po południu na środku hali fabrycznej. Użytkownicy końcowi powinni uczestniczyć w każdym teście beta, jeśli to tylko możliwe. Jednakże inżynierowie powinni być pierwszymi beta-testerami, którzy testują oprogramowanie. Z łatwością dostrzegają różnice pomiędzy ekranami rzeczywistymi a tymi pokazanymi w dokumentacji użytkownika, które nie zostały dostrzeżone przez IT, ale będą ważne dla użytkowników. System powinien być w miarę możliwości całkowicie zdebugowany przez zwykłych użytkowników przed rozpoczęciem testów beta, aby nie sprzyjać klęsce zanim oprogramowanie opuści pokoje programistów.
Inżynierowie muszą brać udział w procesie zakupu oprogramowania,
wdrażania i dokumentacji, dokładnie tak, jak w procesie produkcji. Mogą mieć podobny wpływ na wydajność i efektywność związaną ze zmianą oprogramowania.
Tamara Wilhite jest dyplomowanym inżynierem, obecnie pracuje w przemyśle obronnym jako specjalista ds. oprogramowania do zarządzania danymi produktu.
Artykuł pod redakcją Andrzeja Sobczaka
Autor:
Tamara Wilhite, specjalista ds. oprogramowania do zarządzania danymi produk
