także analiza przedwdrożeniowa
Tak więc: jak dostawca dużego ERP mówi, że duży ERP jest najlepszy to należy to traktować tak samo jak ofertę dostawcy dużego zestawu garnków ze stali nierdzewnej, z których i tak na co dzień używamy jednego a naleśniki i tak robimy z pomocą kupionej wcześniej dobrej teflonowej patelni bo do naleśników lepsza a zamiana jej na nową z nierdzewki tylko dlatego, że "z kompletu" przeczy zdrowemu rozsądkowi i używa się jej mimo, że pokrywka z zestawu lekko wystaje ... ale przykrywa bo taki jest jej główny cel (w zasadzie tylko nie powinna być mniejsza ani zbyt duża).
Na stronie serwisu http://www.samorzad.pap.pl pojawił się ciekawy artykuł: Serwis jak labirynt. Nie licząc zamieszczonej listy powodów trudności w korzystaniu z serwisów WWW Urzędów (przebadano cztery z Małopolski) pojawiły się przykłady typowych kłopotów: ?Dodatkowym problemem jest sam opis tego elementu [elementy menu na stronie, przyp. red.] (?Katalog usług. Poradnik interesanta.?). Nie jest to język, którym posługują się użytkownicy. Szukając tej części serwisu szukali raczej linku ?załatw sprawę w urzędzie?, ewentualnie “e-urząd??. Jak podejść więc do tworzenia biznesowej firmowej strony WWW? Nie wierzyć w to, że strona WWW to portal Web 2.0, strona WWW dla firmy czy urzędu to po prostu kolejna aplikacja biznesowa, która musi (przepraszam, żyjemy w wolnym kraju: powinna) przynieść korzyści.
(more…)
Specyfikacja wymagań powinna dokładnie opisywać procesy, to jakie dane i gdzie są potrzebne, z jakimi innymi systemami należy się zintegrować i wiele innych, istotnych z punktu widzenia zamawiającego i jego infrastruktury oraz potencjalnych kosztów. Teraz dopiero dostawca może dokonać rzetelnej wyceny a specyfikacja wymagań będzie odzwierciedlała potrzeby zamawiającego a nie możliwości dostawcy J.
Po co to napisałem? Absolutnie nie była moim celem krytyka produktu, celem jest zwrócić Państwa uwagę na to by zawsze zapytać o to czy moduły oferowanego oprogramowania są samowystarczalne, czy mogą pracować z oprogramowaniem innych dostawców i jakie to oprogramowanie musi spełniać wymagania. Wybór monolitycznego pakietu to decyzja o tym, że wszystkie poszczególne moduły spełniają nasze wymagania. Nie dajcie się Państwo namawiać na kompromisy w rodzaju: ?ten moduł co prawda nie robi tego co Państwo chcecie ale jest konieczny by działał moduł XXX?.
To prosta droga do zniszczenia pieczołowicie wypracowanych metod pracy w firmie. Reorganizacja przed wdrożeniem nie polega na przejęciu cudzych metod (procesów referencyjnych itp.) tylko na optymalizacji własnych!
Każdy model procesów nie spełniający powyższych zasad można nazwać właśnie naiwnym modelem czyli takim, w którym dowolne symbole, bez zdefiniowanych zasad zostały połączone ze sobą tak jak usłyszano np. w rozmowie z pracownikiem analizowanej organizacji. Modele takie są bardzo często narzędziem do planowania zmian organizacyjnych, specyfikowania wymagań na systemy IT, specyfikowania centrów kosztów w metodach ABC zarządzania kosztami, w wielu innych sytuacjach. Użycie w którejkolwiek z tych potrzeb złego, naiwnego modelu skazuje cały projekt na niepowodzenie.
Tak więc model procesów bez zdefiniowanej i rygorystycznie przestrzeganej semantyki (słownika symboli), syntaktyki (zasad dopuszczalnych relacji pomiędzy tymi symbolami), pragmatyki (co modelujemy i jak) należy odrzucić!
