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

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

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

Czego największe firmy technologiczne nie mówią swoim klientom?

Zasady panujące na rynku produktów i usług IT wydają się przejrzyste: klient wydaje pieniądze na jakiś produkt, oczekując w zamian określonych korzyści. Jak wynika z udostępnionych przez Gartner Inc. analiz, firmy realizują przy okazji swoją strategię, o której wolałyby klientom nie mówić. Jakie są ich cele? [...] Omawiając strategie firm, Gaughan podkreślił również znaczenie działających przy nich ośrodków badawczych. Ich nadrzędnym celem jest tworzenie innowacji w takich sposób, aby ? zachowując pozory rozwoju ? utrzymywać istniejący stan rzeczy tak długo, jak to tylko możliwe.(źr. Czego największe firmy technologiczne nie mówią swoim klientom?. oraz oryginał: What Microsoft, Oracle, IBM, And SAP Don't Tell Customers)

Czytaj dalejCzego największe firmy technologiczne nie mówią swoim klientom?

Co zrobić przed wyborem dostawcy usług IT?

Jednak powyższy fragment, waga procesu opisu wymagań, stanowi tylko 8% całości tekstu, którego autorem jest firma dostarczająca dedykowane rozwiązania. Dlaczego? Może rzecz w tym, skoro analiza potrzeb (patrz powyżej) powinna być wykonana przed wyborem rozwiązania i jego dostawcy to wniosek nasuwa się sam: nie robi tego ten dostawca i słusznie. Tak więc z dużym prawdopodobieństwem można przyjąć, że "określanie potrzeb" nie jest mocną stroną firm, które dostarczają konkretne rozwiązania :). Skoro więc "Punktem wyjścia w procesie doboru dostawcy usług IT jest precyzyjne określenie własnej potrzeby w tym zakresie ", to gorąco zachęcam Państwa do precyzyjnego określania swoich potrzeb przed wyborem partnera, który je zrealizuje.

Czytaj dalejCo zrobić przed wyborem dostawcy usług IT?

Rzeczpospolita wprowadzi opłaty online – a nie mówiłem

Tak więc rynek jest nieubłagany, skoro reklamy nie zarabiają na utrzymanie merytorycznych serwisów, trzeba będzie płacić za ich treść. Cóż? prawa rynku są nieubłagane, coraz więcej gazet i autorów blokuje bezpłatny dostęp do swoich archiwów zaś bieżące informacje są coraz częściej, nie tylko publikowane, są po prostu sprzedawane poszczególnym publikatorom (Prawo autorskie czyli model biznesowy sprzedaży wartości niematerialnych i usług). To, Rzeczpospolita, kolejny tytuł, który zaczyna pobierać opłaty za treść.

Czytaj dalejRzeczpospolita wprowadzi opłaty online – a nie mówiłem

Logika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

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

Czytaj dalejLogika wnioskowania dedukcyjnego czyli czym jest poprawna analiza i modelowanie

HARD FACTS ON BUSINESS ANALYSIS

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

Czytaj dalejHARD FACTS ON BUSINESS ANALYSIS

Przypadki użycia systemu czyli co?

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.

Czytaj dalejPrzypadki użycia systemu czyli co?

Udziałowcy projektu czyli który diagram UML …

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.

Czytaj dalejUdziałowcy projektu czyli który diagram UML …

Na rynku pojawił się popyt na tzw. «małe ERP»

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.

Czytaj dalejNa rynku pojawił się popyt na tzw. «małe ERP»

Czy systemy CRM przynoszą oczekiwane korzyści?

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.

Czytaj dalejCzy systemy CRM przynoszą oczekiwane korzyści?

Historia pewnego mojego klienta

Zalecenie dla zamawiających: zawsze patrze na ręce wykonawcy... prośba do programistów: Jak piszecie kod, którego celem jest szyfrowanie transmisji, renderowanie obrazków itp. to róbcie to jak najlepiej potraficie ale jak implementujecie model dziedziny to dajcie mu spokój, to nie Wasz problem, po protu skopiujcie go, a jak Wasz analityk nie potrafi Wam dać takiego modelu obiektowego to zmieńcie analityka...Po drugie wykonawca, który składając ofertę zaakceptował projekt (wymagania) a potem neguje treść tego projektu ... kim jest?

Czytaj dalejHistoria pewnego mojego klienta

Ryzykujemy upadek firmy z powodu jednego obrażonego pracownika…

To częste zjawisko: zemsta. Nie ma tu znaczenia czy "słuszna" czy nie bo nie ma słusznej zemsty, jest tylko łamanie prawa. Czy jest na to lekarstwo? Hm... nie ma na zemstę, czy jest lekarstwo na kradzieże? Tak: nie mieć czego ukraść lub nie być od tego uzależnionym. Zapewne dla wielu z Państwa brzmi to kuriozalnie ale im bardziej jakiś biznes (model biznesowy) oparty jest na tajemnicy tym bardziej jest on ryzykowany zaś im więcej mamy tajemnic tym bardziej tracimy wolność. Jaki z tego wniosek? Należy albo nie mieć tajemnic albo mieć świadomość konsekwencji ich posiadania i być przygotowanym. W przeciwnym wypadku ryzykujemy potencjalny upadek firmy z powodu jednego obrażonego pracownika... Ale... projektując system można wielu rzeczom zapobiec systemowo i proceduralnie... np. kluczem ochrony przed takim ryzykiem jest coś, co pewnie wzbudzi u wielu nie małe emocje: żaden pracownik firmy nie powinien być twórcą oprogramowania w niej wykorzystywanego...

Czytaj dalejRyzykujemy upadek firmy z powodu jednego obrażonego pracownika…

Koniec treści

Nie ma więcej stron do załadowania