analiza biznesowa – Page 18 – JZ IT Consulting Ltd

Reguły biznesowe jako motor sterujący organizacji: fakty + definicje pojęć

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

Mapa (model) procesów oraz struktura organizacyjna, by były jednoznaczne, muszą być także zestawem zdefiniowanych pojęć. Musimy wiedzieć co znaczy słowo: przełożony, podwładny, komórka organizacyjna czy jej kierownik. Jeszcze większym wyzwaniem zdefiniowanie systemu pojęć dla mapy procesów (proces, czynność, zdarzenie, dokument...). Budowanie systemów pojęciowych spełniających powyższe warunki jest bardzo trudne dlatego dla modeli procesów biznesowych najlepiej wykorzystać gotowy model pojęciowy: jest nim notacja. Najlepiej obecnie opracowanym takim modelem pojęciowym jest gotowa notacja [[BPMN]]. Tworzenie własnych jest kosztowne (czas i wiedza osoby opracowującej) i bardzo ryzykowne (może się nie udać). Dlatego używanie dzisiaj własnych lub innych (np. dostosowywane profilami diagramy UML) jest w moich oczach nieracjonalnym podejściem. Model pojęć specyficzny dla danej organizacji niestety musi powstać "od zera", podobnie jak powiązana z nim specyfiakcja reguł biznesowych. Jest to trudne bo tworzenie przestrzeni nazw wymaga utrzymania niezależności poszczególnych definicji i spójności i zupełności całego ich systemu. Niedochowanie tych wymagań prowadzi do niepełności a nawet sprzeczności reguł biznesowych, które w końcu są budowane (odkrywane i dokumentowane) z pomocą tych pojęć. Zanim wiec zaangażujesz kogoś do modelowania własnej firmy, upewnij się, komu zlecasz tę pracę... W bardzo dużym więc skrócie: procesy biznesowe to faktyczny, widoczny sposób pracy firm (ludzi w nich zatrudnionych), procesy to efekt funkcjonowania ludzi w środowisku ograniczeń, należy poznać tych ludzi, ograniczenia to: procedury, prawo, zarządzenia wewnętrzne oraz specyficzne dla firmy wewnętrzne normy zwane regułami biznesowymi, opracowanie biznesowego modelu firmy wymaga zrozumienia i opisania tego co powyżej opisałem, nie istnieje droga na skróty. ...

Analityk biznesowy czyli wyplenić dwuznaczność z dokumentów analitycznych!

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

"Im większa niejednoznaczność dokumentu wymagań tym większe ryzyko, że projekt będzie miał kłopoty". Powyższe nie stanowi żadnego odkrycia co nie zmienia faktu, że jakość większości dokumentów wymagań (owe 70%) jest słaba, na co wskazują sami ankietowani. Rola Kierownika Projektu to między innymi zarządzanie ryzykiem. Statystyki są nieubłagane, więc brak dobrego analityka i dobrej analizy wymagań spycha projekt w kierunku kłopotów. No to mamy kolejne badanie: Znaczenie i zapotrzebowanie na specjalistów wg. Forrestera: 70% badanych decydentów uważa, że Analityk Biznesowy to kluczowa postać w projekcie. Jednak nie dlatego, że jest ważniejszy od np. kierownika projektu, bo nie jest ważniejszy. Dlatego, że od jakości jego produktu (analiza i specyfikacja wymagań) zależy właśnie ryzyko całego projektu. Co jest wadą większości analiz biznesowych? To, że są one tak na prawdę uporządkowanym zapisem wywiadów z klientem a nie faktyczną analizą organizacji, jej potrzeb (bo raczej nie koniecznie jej pracowników!) i celów biznesowych. Jakie są treści tekstowego lub tabelarycznego zapisu wywiadów? NIEJEDNOZNACZNE! Jakie są niesformalizowane, swobodnie tworzone diagramy procesów? NIEJEDNOZNACZNE! Jakie są słowne opisy struktury oprogramowania jakie ma powstać? NIEJEDNOZNACZNE! Co zrobić? Używać już na etapie analizy biznesowej i projektowania sformalizowanych narzędzi takich jak standardowe notacje i metodyki, wtedy opisy będą JEDNOZNACZNE. Czy to trudne? Tak, w końcu te 70% porażek to nie przypadek...

Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

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

W czym problem z kiepskiej jakości analizami i modelami? W tym, że ich autorzy podejmują próby dodawania nowych symboli do notacji, psując spójność i jednoznaczność diagramów, stosują symbole notacji niezgodnie z nadanymi im znaczeniami albo łamią zasadę wyłączonego środka mówiącą w uproszczeniu, że jeżeli coś jest czymś to znaczy, że nie jest już niczym innym (np. jeżeli coś jest zdarzeniem to na pewno nie jest ani czynnością, ani danymi, ani regułą decyzyjną). Innymi słowy: jeżeli jakieś ziarno węgla jest kostką to na pewno nie jest ani groszkiem, ani orzechem ani miałem. A co jeżeli jednak wynik analizy jest opisem w języku naturalnym lub zestawem diagramów łamiących zasady notacji? Wtedy tak naprawdę analitykami są programiści, bo oni i tak muszą to zamienić na kod w języku programowania, którego używają. Czy to dobry pomysł? Pozostawię odpowiedź czytelnikowi...

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).

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.