Wdrożenie na opak

Nie czekać z momentem rozpoczęcia wdrożenia na specjalnie dogodną chwilę, np. przerwę urlopową, bo nie ma nic lepszego niż wdrażanie, gdy stary system informatyczny jest obciążony nawałem bieżących prac, a użytkownicy mają mało czasu na picie kawy. Wtedy też bardziej myślą o pracy i zapewne tym chętniej podejmą się dodatkowych zadań związanych z wdrożeniem.

Zmieniać reguły przetwarzania, i to z tak dużą częstotliwością, że zanim się je wdroży, przestają już być aktualne. Prawdziwej pikanterii sprawie nadaje sytuacja, gdy oprócz wdrażanego eksploatujemy także stary system bądź jego fragmenty. Wtedy naprawdę wielu programistów znajdzie zatrudnienie.

Na szkoleniach użytkowników poruszać tematy związane z podstawami komputera: mysz, foldery, formatowanie tekstu. Tematykę związaną z wdrażanym oprogramowaniem traktować raczej luźno, bo po co dawać użytkownikom powody do czepiania się szczegółów. Poza tym, podstawy komputera mają ludzie na ogół opanowane, więc tym bardziej będą się cieszyć, że szkolenie nie było trudne i odnieśli sukces. Uwaga! Przy wdrażaniu technologii przestarzałych wypada jednak przeszkolić użytkowników w posługiwaniu się interfejsem znakowym, ze szczególnym naciskiem na zgrabne przeskakiwanie przy użyciu klawiatury pomiędzy kilkudziesięcioma polami na planszy.

Jak porazić zaskakującymi efektami

Wyrażać szczery podziw dla faktu, że osiągnięto integrację między modułami oprogramowania na poziomie danych osobowych, chociaż dane te są wspólne i umieszczone w jednej tabeli.

Określać jako gotowy system, który nie generuje oczekiwanych raportów. Wiadomo przecież, że istnieją generatory raportów, które od ręki uporają się same ze wszystkimi wymaganiami użytkowników.

Rozpowiadać o sukcesie integracyjnym na poziomie danych w systemie z centralną bazą.

Zastanawiać się, jak sparametryzować system, gdy już został oddany do użytku.

Szukać w nowym oprogramowaniu opcji dostępnych w starym systemie, po czym dowiedzieć się, że opcje te są dopiero w planie w przyszłych wersjach nowego oprogramowania. To się nazywa pech!

Zastanawiać się, jak w systemie identyfikowany jest obiekt i podawać do wyboru szereg dziwnie brzmiących identyfikatorów, z których po pewnym czasie żaden okazuje się nie być ani unikatowy, ani niezmienny.

Dziwić się, że w nowym oprogramowaniu nadal mamy to samo, czyli sprawy nie dzieją się same i w dalszym ciągu trzeba wprowadzać i utrzymywać dane oraz przestrzegać dziwnych procedur postępowania. W sumie nie wiadomo, po co było to całe zamieszanie z wymianą oprogramowania.

Czego nie powinno się robić

Wdrażać produkt technologicznie przestarzały tylko dlatego, że jest on dużo tańszy od współcześnie oferowanych. Cóż, oprogramowanie to nie wino, więc nie zyskuje wraz z upływem czasu. Trudno, aby było po latach droższe i lepsze od oprogramowania wykonanego w nowszej technologii. Ale jeśli ktoś lubi starocie…

Wymieniać istniejący system na nowy tylko dlatego, że użytkownicy jednego z modułów nie radzą sobie z nim za sprawą swojej niewiedzy i niechęci do nauki. Po wymianie systemu okazuje się najczęściej, że nadal korzystaniu z niego towarzyszą te same utrapienia.

Wymieniać system na nowy, bo stary nie działa zgodnie z przepisami a nowy działa - zgodnie z zapewnieniami producenta. Po wdrożeniu okazuje się, że nowy działa tylko zgodnie z zapewnieniami producenta.

Zmieniać chwilowo system na tańszy w eksploatacji, bo obecny jest zbyt drogi - z założeniem, że gdy sytuacja finansowa poprawi się, wtedy powróci się do systemu droższego. Biorąc pod uwagę same koszty procesu wdrażania oraz powstałe w tym procesie zamieszanie, lepiej po prostu niczego nie ruszać.

Zmieniać system wraz ze zmianą zarządu firmy. Wiadomo, że w czasach demokracji każdy może mieć swój pogląd na sprawę, ale czy jest to rzeczywiście dobry powód do ponoszenia wysokich kosztów?


TOP 200