Mega projekty, czyli jak zjeść słonia
Ku mojemu zaskoczeniu dość często dostaję pytania o możliwość zaangażowania się w roli analityka np. na rok na warunkach: 100% czasu na miejscu u klienta a wynikiem ma być specyfikacja wymagań na oprogramowanie, którego realizacja jest planowana na np. kolejne 5 lat. Nie ma to moim zdaniem żadnego sensu i nie angażuje się w takie projekty. Ale po kolei.Autor: Jarosław Żeliński - IT-Consulting.pl
Już w roku chyba 2003 robiłem analizę ryzyka dużych i długich projektów, celem była ocena prawdopodobieństwa i kosztów wprowadzania zmian do zakresu projektu. Jak nie trudno się domyśleć, jest to – zmiany zakresu – najbardziej niechciana rzecz w każdym projekcie. Materiał ten był prezentowany na jednej z konferencji dotyczących wdrażania systemów ERP.
Co spowodowało moje zainteresowanie tym problemem? To co każdy w tej branży widział chyba najmniej raz w życiu: różnica pomiędzy pierwotną specyfikacją a ostatecznym produktem. W dużych projektach często te dwa stany nie mają z sobą zbyt wiele wspólnego! Więc pojawia się pytanie: po co robić wielką analizę i dokumentację skoro większość tej dokumentacji, rozdział po rozdziale, ląduje w koszu za sprawą „zarządzania zmianą”?
Popatrzmy na to:
Analiza i specyfikowanie wymagań to tak na prawdę prognoza mówiąca, że to co teraz projektujemy będzie w przyszłości, w dniu oddania do użytku, potrzebne w takiej formie w jakiej właśnie to projektujemy. Jak wiemy, prognozy są tym większym błędem obarczone i bardziej w przyszłość wybiegają. Powyższy diagram to typowy megaprojekt. Linia przerywana obrazuje pewną hipotetyczną granicę, powyżej której ryzyko błędnej prognozy przekracza np. 50% (czyli klasyczny rzut monetą).
Innymi słowy, rozpoczynając megaprojekt mamy niemalże pewność, że jego zakres ulegnie zmianie czyli cała praca powyżej tej linii przerywanej pójdzie do kosza (na koszt sponsora projektu ).
W naturalny sposób nasuwa się wniosek: nie należy robić nic ponad tę przerywaną linię. Wtedy otrzymamy taki diagram:
Robimy tylko to co z ryzykiem bliskim zera zostanie zaimplementowane bez zmian. Jak? Pierwszy etap to analiza problemu i projektowanie architektury całości – model komponentów. Jest to jakaś logika systemu na dość wysokim poziomie abstrakcji ale dająca się przetestować. Stanowi ona podstawę dalszej pracy nad każdym komponentem osobno (kolejne etapy). Uszczegóławianie wymagań odkładamy „na ostatni moment”. W ten sposób „kwartał po kwartale” doprecyzowujemy wymagania na kolejny etap i realizujemy go. Co zyskujemy? Nie wyrzucamy do kosza nadmiernie szczegółowej i rozległej dokumentacji wymagań, nie ponosimy koszów projektowania czegoś co może „wylecieć” z zakresu za pół roku z powodów np. zmian na rynku, możemy w dowolnym momencie zmienić kolejne planowane komponenty, usunąć jedne i opracować nowe bez ryzyka zbędnych kosztów.
Pierwszy etap ma pewną cechę: tworzy (taki ma cel) jeden wspólny model wszystkich projektów dla danej organizacji o wdzięcznej nazwie Architektura Korporacyjna. Kolejne konkretne komponenty architektury IT to kolejne projekty, cechujące się zrozumianym umiejscowieniem w całości organizacji i wiarygodnym, spójnym z całością zakresem.
Dlatego z reguły nie mają sensu:
- wdrożenia departamentowe oderwane od reszty (np. Dział Handlowy sobie funduje sam system CRM),
- projekty trwające dłużej niż trzy kwartały (ostatni kwartał to kolejne planowanie budżetu na kolejny rok czyli planowanie zmian),
- mega projekty ERPII czyli „all in one” dla firmy w ramach jednego projektu.
Więc jak zjeść słonia by się nie udławić? Powoli i po kawałku… I nie zapominajmy, że wyzwaniem może być nie tyle nowe oprogramowanie co zmiana nawyków ludzi… a nie ma nic gorszego niż planowanie nowego oprogramowania dla starych nawyków bo po co to robić?
Pamiętajmy, że zarządzanie zakresem projektu jest tym kosztowniejsze im więcej szczegółów ten zakres posiada. Projekt o 30 wymaganiach vs. projekt o 300 wymaganiach to nie projekt o 10-krotnie większym koszcie, ta różnica będzie znacznie większa (pomijam to jak w ogóle zdefiniujemy wymaganie).
Tak więc przeciętny projekt to dla analityka praca na nie więcej niż kwartał (mniej więcej). Jak ja opisać wymagania na systemy ERP? Nie są to setki szczegółowych wymagań, bo to nie ma sensu. To opis architektury korporacyjnej wraz z zestawem celów biznesowych dla każdego potencjalnie kupowanego modułu (podsystemu) oraz wymagania jako testy pokazujące realizację tych celów. Tych testów (wymagań) będzie raczej 30 niż 300, zaś ewentualne dedykowane funkcjonalności są projektowane „na ostatni moment” jeżeli okaże się, że żaden rynkowy produkt ich nie oferuje a nam na prawdę są one potrzebne.
Najnowsze wiadomości
W ramach realizowanej strategii transformacji PSI Software SE zaprezentowała nową identyfikację wizualną. Odświeżony wizerunek w spójny sposób oddaje technologiczne zaawansowanie firmy, jej głęboką wiedzę branżową oraz silne ukierunkowanie na potrzeby klientów. Zmiany te wzmacniają pozycję PSI jako innowacyjnego lidera technologicznego w obszarze skalowalnych rozwiązań informatycznych opartych na sztucznej inteligencji i chmurze, rozwijanych z myślą o energetyce i przemyśle.
Najnowsze artykuły
Współczesna logistyka wymaga nie tylko szybkości działania, lecz także maksymalnej precyzji – to właśnie te czynniki coraz częściej decydują o przewadze konkurencyjnej firm. Nawet drobne pomyłki w ewidencji stanów magazynowych, błędy przy przyjmowaniu dostaw czy nieprawidłowe rozmieszczenie towarów, mogą skutkować poważnymi stratami finansowymi i opóźnieniami w realizacji zamówień. W jaki sposób nowoczesne rozwiązania do zarządzania pomagają unikać takich sytuacji? Czym właściwie różni się tradycyjny system magazynowy od zaawansowanych rozwiązań klasy WMS (ang. Warehouse Management System)? I w jaki sposób inteligentne zarządzanie procesami magazynowymi realnie usprawnia codzienną pracę setek firm?
Zysk przedsiębiorstwa produkcyjnego zależy nie tylko od wydajności maszyn, ale przede wszystkim od precyzyjnego planowania, realnych danych i umiejętnego zarządzania procesami. Dlatego firmy, które chcą skutecznie działać zarówno w modelu Make to Stock (MTS), jak i Make to Order (MTO), coraz częściej sięgają po rozwiązania klasy ERP, takie jak BPSC ERP.
Migracja z SAP ECC na S4 HANA: Ryzyka, korzyści i alternatywne rozwiązania
Jak maksymalizować zyski z MTO i MTS dzięki BPSC ERP?
Warsztaty analityczne i sesja discovery. Jak wygląda pierwszy etap współpracy z partnerem wdrożeniowym ERP
ERP a modele produkcji: jak zestroić strategię z wymaganiami rynku
Standaryzacja we wdrożeniach ERP: Fundament efektywności i globalnej skali działania
