November 2011 – Page 3 – JZ IT Consulting Ltd

HARD FACTS ON BUSINESS ANALYSIS

Post author:Jaroslaw Zelinski
Post published:15 November 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

? 70% of all project failures are as a result of poor requirements. ? There is a 60% time and cost premium to be paid on projects with poor quality requirements. ? As the projects get more interdepartmental and complex, the failure rate rises. ? It costs 80 times as much to fix defects after delivery, than at the specification stage. ? 74 per cent of all companies have immature requirements practices. ? Large scale systems project fail with alarming regularity. A typical project over-ran its budget by 189% and over-ran its schedule by 222%. ? Average project has about 30% rework. This means that for every Kshs 1,000,000, Kshs 300,000 is spent redoing something that was thought to be complete. ? The average company with low requirements maturity wastes 34% of the organization?s IT development budget. ? 68% of companies simply did not use the necessary competency in requirements discovery at the start of their project to assure project success. Source: IAG Business Analysis Benchmark, 2008 (za HARD FACTS ON BUSINESS ANALYSIS | LinkedIn).

Przypadki użycia systemu czyli co?

Post author:Jaroslaw Zelinski
Post published:14 November 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Po kilku latach kolejnych doświadczeń upewniam się, że proste jest piękne: przypadek użycia to pojedyncza, elementarna kompletna usługa świadczona przez System dla jego użytkownika. Usługa ta jednak może mieć warianty. Jaki z tego ma pożytek sponsor projektu? Koszt, projekt ma kilkanaście lub kilkadziesiąt a nie setki przypadków użycia i jest łatwiejszy w implementacji. A gdzie przypadki systemowe? Nie ma takich. Pojęcie Aktora ma jasną definicję (osoba lub inny system mający interakcję z Systemem), pojęcie przypadku użycia także (specyfikacja działań Systemu w odpowiedzi na działania aktora lub innego podmiotu "zainteresowanego" Systemem) (źr.: OMG Unified Modeling LanguageTM (OMG UML), Superstructure Version 2.3). Wymyślanie nowych definicji nie tylko psuje standard bo nie pasuje do spójnej przestrzeni nazw. Wymyślanie swoich znaczeń po protu psuje zrozumiałość, niszczy role komunikacyjną modeli (języka ich tworzenia). Niestety Pan Cockbourn jest w moich oczach takim "dorabiaczem" i psującym sens prostego i jak widać trudnego zarazem, narzędzia jakim jest model przypadków użycia systemu.

Udziałowcy projektu czyli który diagram UML …

Post author:Jaroslaw Zelinski
Post published:12 November 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Stosowanie reguł (semantyki i syntaktyki) UML pozwala utrzymać spójność modeli zależnych (podległe temu diagramowi uszczegółowienia Projektu Systemu, realizacja Aktorów, przypadki użycia itp.) oraz zachować spójność logiczną i pojęciową całej dokumentacji. To zaś jest warunkiem weryfikacji poprawności całego projektu. UML to notacja, której kluczowym pojęciem jest klasyfikator (oparta jest na definiowanych pojęciach i relacjach między nimi) dlatego warto przestrzegać (zawsze warto) zasad notacji i np. nie utożsamiać Aktora System CRM (jest to jakaś abstrakcja systemu integrowanego) z konkretnym Jakimś Systemem CRM. Aktor ma konkretne znaczenie na diagramie UML (zdefiniowane wyżej) i konkretny system także. Zachowanie tego podziału (abstrakcja i jej realizacja) pozwala zdefiniować oddzielnie wymagania i oddzielnie konkretne rozwiązania je spełniające co jest istotą rozdziału wymagań od spełniających je rozwiązań. Diagramy przypadków użycia są bardzo ważnymi diagramami, gdyż stanowią "korzeń" modelu realizacji systemu zaś łamanie zasad notacji prowadzi praktycznie zawsze do utraty możliwości ich, modeli, weryfikacji.

Na rynku pojawił się popyt na tzw. ‘małe ERP’

Post author:Jaroslaw Zelinski
Post published:9 November 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Tak, zawsze warto podjąć próbę zakupu systemu ERP minimalnym kosztem. Najprostsza metoda to testowa eksploatacja (zakup na bazie samej prezentacji systemu gorąco odradzam!). Jednak na tę ścieżkę mogą sobie pozwolić firmy, których sposób działania jest "standardowy" (co by to nie miało tu znaczyć ;)). Jeżeli tylko "czujemy", że wyróżniamy się czymkolwiek na rynku i to stanowi o naszej pozycji na nim, odradzam "gotowce" bo te zrównają firmę z "resztą świata". Czy to znaczy, że ma to być system dedykowany? Nie! To znaczy, że warto wykonać jednak model procesów, upewnić się, że jesteśmy MbO i SMART (i naprawić ewentualne braki), znaleźć nasze źródło przewagi. Dla tego jednego obszaru (źródła przewagi) wykonać dokładną analizę i zaprojektować dedykowane rozwiązanie, a "resztę" obsłużyć dobrze dobranym, gotowym, małym ERP. Takie badanie przed wdrożeniem to audyt firmy, audyt tego czy firma jest MbO i SMART (propnuje nie informatyzować bałaganu i niewiedzy), analiza przedwdrożeniowa czy analiza potrzeb to dopiero kolejne etapy projektu: specyfikowanie wymagań. Aha, chyba widać już, że należy robić to przed wyborem i zakupem systemu ERP, nigdy po, bo wtedy jest za późno.

Czy systemy CRM przynoszą oczekiwane korzyści?

Post author:Jaroslaw Zelinski
Post published:8 November 2011
Post category:Analizy biznesowa i projektowanie oprogramowania

Wdrożenie systemu CRM poprzedzać powinna szczegółowa analiza procesów biznesowych oraz realnych potrzeb organizacji To w zasadzie podsumowanie powyższych uwag. CRM to praktycznie dwa kluczowe aspekty: procesy biznesowe związane z obsługą zdarzeń dotyczących klientów, repozytorium dokumentów powiązanych z tymi zdarzeniami. Te dwa powyższe punkty skłaniają mnie do postawienia tezy, mówiącej że dobry system CRM to system wspomagający procesy biznesowe związane z obsługą klientów oraz zarządzający informacjami związanymi z obsługą klientów. Powinien też integrować te dane w całej organizacji. Dlatego warto rozważyć, analizę obecnej sytuacji w firmie i wdrożenie, zamiast oprogramowania mającego w nazwie CRM, systemu typu workflow wraz z repozytorium dokumentów. Przy ograniczonym budżecie doskonale, w roli CRM, sprawdzają się same repozytoria dokumentów, które później zawsze można uzupełnić systemem wspierającym procesy biznesowe.