analiza wymagań – Page 11 – JZ IT Consulting Ltd

Łańcuch wartości M.E.Porter (Competitive Advantage, 1985)

Wymagania na system ERP – co ma do tego M.E.Porter i rok 1985?

Post author:Jaroslaw Zelinski
Post published:18 July 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Podejście takie jest stosowane. Badania pokazują, że liderzy rynku, bez względu na branżę, to firmy dobrze zarządzane a nie te, które najwięcej wydały na IT. Podejście to wymaga dużej odwagi i samodzielności, ignorowania tak zwanych modeli referencyjnych (bo te są dobrymi praktykami a nie czymś co należy skopiować), owocuje jednak sukcesami. Niestety często zdarza się, że wdrożenie systemu ERP niszczy przewagę firmy, gdyż nowa technologia zamiast ją umocnić niszczy kompromisami i kopiowaniem modeli innych firm (nie raz konkurentów) wszystko to co odróżniało ją od innych. Za zakończenie polecam gorąco drugą ksiązkę Portera: [[Porter o konkurencji, Michael E. Porter, PWE, Warszawa 2001]]. W tej znajdziemy zbiór dziewięciu artykułów na temat budowania konkurencji i jej utrzymaniu. W szczególności warto poznać artykuł "[[W jaki sposób informacja wpływa na przewagę konkurencyjną]]". Pięć zasad, które mogą pomóc w budowaniu przewagi na bazie informacji, odsyłam do książki , warto. To przyczynek to napisania kilku słów o systemach wspomagania decyzji ale to inny temat, nie ERP...

A jeżeli klient nie ma kompetencji do wykonania analizy

Post author:Jaroslaw Zelinski
Post published:5 July 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Opisywane tu nie raz metody bazujące na modelowaniu przyszłego systemu (jego logiki biznesowej) i testowaniu czy model pozwala na spełnienie celu biznesowego dają oszczędności nawet 50%, a bywa, że znacznie większe, jeśli okaże się, że uniknięto zakupu jakiegoś zbędnego oprogramowania lub modułu. Koszt dobrze opracowanej analizy z dużym zapasem pokrywają oszczędności wynikające z braku wielu prototypów. Podsumowując: analityka zawsze warto zatrudnić, poprzedzając to kontrolą tego co wytworzy. Dobry analityk zawsze wyceni projekt jako umowę o dzieło o konkretnym terminie i koszcie. Projekty w rodzaju czas i materiał to projekty w rodzaju " na początku nikt nic nie wie". Warto je robić tylko w przypadkach, gdy tej wiedzy faktycznie nie ma, spodziewamy się systemu o wartości setek tysięcy złotych lub kosztowniejszych i zainwestowanie nawet kilkudziesięciu tysięcy w analizę, która pozwoli oszacować ryzyko wydania tych kilkuset, może mieć sens. W takich przypadkach i tak ustalamy próg kosztów, przy których uznamy, że dalsze prace już niczego nowego nie wniosą. A na koniec, analiza trwająca kilka czy kilkanaście dni roboczych, zakończona kilkudziesięcioma stronami tekstu i tabelą na setki pozycji wymagań w niczym nam nie pomoże.

Budżet na projekt IT

Post author:Jaroslaw Zelinski
Post published:4 July 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Tak więc moim zdaniem budżet zamawiającego to wiedza zamawiającego, której nie musi ujawniać. Skoro już jej nie ujawnia to powinien mieć kompetencje (własne lub wynajęte) pozwalające po pierwsze opisać projekt, po drugie zdefiniować (opisać) "to coś informatycznego" co pomorze mu ten projekt zrealizować. Wyjawienie przez klienta planów i budżetu takiemu dostawcy to postawienie się pod ścianę w negocjacjach z nim. Dlatego nie ma sensu sytuacja gdy dostawca pyta klienta o jego budżet czy oferowanie mu czegokolwiek. I nie ma tu znaczenia uczciwość tego dostawcy bo z perspektywy klienta sprzedawca na prowizji stanowi duże ryzyko dla rzetelności takiej oferty. I na koniec: napisanie tylko: "system ma wystawiać faktury VAT" jako opis tego co chcemy kupić nie ma żadnego sensu bo to stanowczo za mało by cokolwiek wycenić i ocenić.... ale też napisanie, że "kontrahenta można dodać do faktury z rozwijanej listy uruchamianej prawym klawiszem myszy", jest jeszcze większym błędem, bo po pierwsze nie raz narzuca wspomnianą kastomizacje (a to podnosi koszt), a po drugie bywają lepsze sposoby rozwiązania tego problemu. Dla gotowego systemu nie ma sensu pisanie aż takich szczegółów, a dla dedykowanego robi się to zupełnie inaczej.

Metoda naukowa w analizie biznesowej

Post author:Jaroslaw Zelinski
Post published:4 July 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Po kolei: obserwacje to analiza tego co i jak się w firmie dzieje (analiza dokumentów i wywiady) budowanie hipotezy to tworzenie modelu procesowego tej firmy i modelu jej dziedziny eksperymenty to testowanie modeli poprzez sprawdzanie czy model procesu da jako produkt taki sam dokument jak te w praktyce przyjęcie lub odrzucenie hipotezy oraz jej powtarzanie to iteracyjne testowanie i ulepszanie modelu (jeśli był wadliwy)

Analiza a programowanie czyli gramy w chińczyka na szachownicy

Post author:Jaroslaw Zelinski
Post published:3 June 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

proszę programistów: róbcie to co rozumiecie i nie wmawiajcie nikomu, że wiecie lepiej jak zarządzać firmą Waszych klientów. Róbcie to co każdy dobry stolarz: poproście klienta o rysunek tego co ma powstać i zróbcie. Nie zapominajcie, że dobry stolarz to nie to samo do dobry projektant, jak klient nie potrafi rysować (a najczęściej nie, bo nie to jest jego kompetencją), dobry stolarz zawsze odeśle do projektanta po rysunek. Między innymi dlatego, by później nie być posądzonym o stronniczość czyli rysowanie tylko tego co jest łatwe w wykonaniu. Rzecz w tym, że nie ma być łatwe dla stolarza a dobre dla klienta.