Opisane tu podejście często nazywane jest "kaskadowym" (waterfall - wodospad). Jest ono dość często wskazywane jako powód porażek projektów, ale moim zdaniem jest to pewna demagogia, gdyż tak na prawdę przyczyną większości problemów jest nie tyle "wodospadowe" podejście, ono jak widać z powyżej opisanego procesu, ma głęboki sens, co wzięcie sobie na barki projektu (zawarcie umowy z dostawca na trzy lata to przyjęcie w dniu jej zawarcia harmonogramu łamiącego opisana powyżej zasadę) na lata zaniedbując zupełnie fakt, że otoczenie rynkowe obecnie zmienia się nawet co kwartał.Mamy więc kuriozalne zestawienie: podjęcie projektu od razu od ostatniego etapu (wybór dostawy, produktu i realizacja) i zaplanowanie go od razu na np. trzy lata. To projekt w rodzaju "nie wiem co tu jest grane ale kupujemy [ten system] i wdrażamy go". To nie ma prawa się udać...A nasze "lessons learned"? No właśnie, znane mi projekty zakończone kłopotami, to właśnie projekty na skróty. Projektu prowadzone w myśl powyższych zasad (krótkie i dobrze zaplanowane etapy) są znacznie bardziej odporne na kłopoty.
Swego czasu pisałem o tym, że np. klasa przechowująca informacje o pracowniku raczej powinna nazywać się DaneOPracowniku a nie Pracownik. Dlaczego? Bo projekt systemu zawierający informacje o pracownikach i klientach, a także treść wielu dokumentów, powinien pozwalać zrozumieć co jest "w systemie" a co w "rzeczywistości" (pracownik jest żywym organizmem, oprogramowanie co najwyżej zarządza danymi opisującymi tego pracownika). Ku mojemu zaskoczeniu ale także radości, niemalże ten sam problem poruszył Ron Ross (bloger i autor książki BUILDING BUSINESS SOLUTIONS: Business Analysis with Business Rules): To make a long story short, business models talk directly about real-world things (as business people do);…
Pojawiła się polemika do mojego artykułu Duży monolityczny ERP czy integracja (fragment, gorąco polecam cały wpis): Witam Kolegę Blogera i na powitanie mam małą polemikę. Otóż nie mogę się zgodzić na tak szeroko postawione pytanie "Duży ERP, czy integracja" gdyż na nie odpowiedziała już Historia. Od ERP nie ma odwrotu! (RE: Duży ERP czy integracja - ERP -view.pl - System ERP, CRM, ERP, Business Intelligence, MRP).?*? Jako, że zostałem wywołany do tablicy :), odpisuję. Zakładam, że powyższą lekturę już Państwo mają za sobą, jeżeli jednak nie, cytuje treści, które omawiam. Na początek proponuję uzgodnić jedną rzecz: definicję…
Tym razem krótko. Praktycznie za każdym razem moje rozmowy z potencjalnymi klientami dotykają problemu: jeden zintegrowany system ERP czy kilka dziedzinowych rozwiązań. Ja zawsze powtarzam to samo: im większy monolityczny system tym większym ograniczeniem i kosztem staje się dla firmy, tym większe uzależnienie od jednego dostwcy. Na rynku ścierają się stale dwie grupy opinii: "duży ERP jest lepszy bo od jednego dostawcy i od razu zintegrowany", kontra teza "duży ERP monolityczny wymaga wielu prac dostosowawczych i bardzo trudno zmienić w nim jedno nie ingerując w resztę". [...] "lepszym rozwiązaniem będzie wdrożenie systemów dziedzinowych i ich zintegrowanie"...
