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 organizacjiTo 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 żedobry 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…

Jolt Award: Visual Paradigm for UML

[singlepic id=228 w=320 h=240 float=right] Nie tylko ja jestem zdania, że używanie zaawansowanych systemów wspomagających prowadzenie analiz jest cechą analityków (firm), którzy przekroczyli pewien próg profesjonalizmu. Zapewne pojawią się tu zarzuty o zarozumiałość albo "wydziwianie", ale rozejrzyjmy się. Analityk to osoba wspierająca np. wdrażanie złożonych systemów ERP lub innych, nie mniej złożonych dedykowanych systemów (oprogramowania). Skoro ktoś poleca swoim klientom zaawansowane oprogramowanie wspomagające zarządzanie złożoną firmą czy organizacją, to jak prezentuje się na tym tle on sam, używający prostych i pracochłonnych narzędzi by to złożone oprogramowanie projektować? Można powiedzieć: "po narzędziach go…

Czytaj dalejJolt Award: Visual Paradigm for UML

Jak zdobyć nasze maile? Jak ich nie wysłać?

No cóż, nie jest rzadkością zrobienie literówki w adresie, nie jest także złe zaadresowanie listu w sytuacji gdy wszechobecne funkcje podpowiadania adresata wstawią w pole Do: kogoś innego z naszej listy kontaktów. Nie trzeba wielkiego pośpiechu czy nieuwagi by się to przytrafiło. Umieszczanie w stopce sentencji w rodzaju "jeżeli nie jesteś adresatem tego listu powiadom o tym nadawcę i zniszcz treść przesyłki" jest dość naiwne jeśli niechcący wyślemy super ofertę nie temu klientowi...To zjawisko to klasyczny przykład czynnika ludzkiego, z którym poważni ludzie nie dyskutują tylko szukają sposobu jak mu zaradzić. Na pewno nie jest skutecznym sposobem administracyjny zakaz mylenia się z dużą karą za pomyłkę: po protu nikt się nie przyzna, i mało który przypadkowy adresat doniesie sam na siebie.Jak zaradzić problemowi?W sumie nie aż tak trudno: nie używać poczty elektronicznej do wysyłania ważnych dokumentów. Czyli?Zamiast ryzykować wysłanie mailem ryzykownej treści, np. negocjowanej umowy, bezpieczniej jest umieścić plik w repozytorium i udostępnić uprawnionej osobie (stosowanie kompresji zip na hasło jest tylko półśrodkiem). Może to być system zarządzania przepływem pracy, nieskomplikowane repozytorium z funkcją monitorowania, inne. Możliwości jest wiele, ważne by nie "przedobrzyć" z procedurami.Jak nie trudno się domyśleć, i tu warto wykonać rzetelną analizę wymagań, procesów komunikacyjnych wewnątrz firmy z jej otoczeniem, analizę ryzyk. Jednak o wymaganiach w tym poście już nie napiszę :) zaś moi klienci wiedzą, że używam w ważnych przypadkach, systemu wymiany dokumentów zamiast poczty od ponad trzech lat.

Czytaj dalejJak zdobyć nasze maile? Jak ich nie wysłać?
Cykl tworzenia oprogramowania metodą zorientowaną na modele (Model Driven Development)
MDA Development Sequence (źr. Business Process Trend Newsletter, Maj 2004 nr. 5)

Hej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Tak więc jest metoda, praktyka pokazuje, że sprawdza się. Praktyka pokazuje także, że niestety nie jest to łatwe (modelowanie biznesu metodami obiektowymi, tu niestety nie da się powiedzieć, że "nie święci garnki lepią") dlatego powstały pewne zalecenia i wzorce projektowe. Należy je zrozumieć, nauczyć się stosować i stosować, co i tak nie zastąpi "projektowania" czyli twórczego pierwiastka w tym procesie. Dokładnie tak samo jak nie da się automatycznie tworzyć kodu programu, do tego potrzebni są (dobrzy) programiści.Z przekorą powiem też, że nie wiem jak zwinność metod programistycznych ([[Agile Manifesto]]) miała by ten proces uzdrowić i uczynić lepszym (nadal uważam, że brak dokumentacji, w tym modeli, raczej psuje projekty). Podsumowując można by powiedzieć, że etapy tworzenia oprogramowania to:Analiza biznesowa, której produktem są: model organizacji (CIM) oraz specyfikacja tego co ma powstać (PIM), to drugie to kompletne wymagania. Całość (sformalizowane modele) pozwala na przetestowanie czy tak określone wymagania spełniają potrzeby biznesu. Wytworzenie oprogramowania polegające na: implementacji modelu PIM, rozwiązaniu problemów technicznych (wymagania niefunkcjonalne) oraz dostarczeniu i wdrożeniu. Powyższe, tak udokumentowany projekt, pozwala także osiągnąć dodatkową korzyść: "wiedza organizacji" tkwi w modelu PIM i developer nie może jej przejąć bez zgody autora, Analityka Biznesowego i sponsora projektu (prawo autorskie).

Czytaj dalejHej, Biznesie, to ma być dla biznesu czyli dla Ciebie!

Znaczenie i zapotrzebowanie na specjalistów IT

Według Forrester zmieniający się porządek zapotrzebowania na specjalistów IT wynika głównie z trzech rzeczy: Coraz większa popularność różnych technologii i rozwiązań jak np. SaaS (Software -as-a-service) bądź Business Intelligence, które wpływają na zapotrzebowanie na konkretne umiejętności; Coraz bardziej rosnące znaczenie outsourcingu ze względu na łatwą dostępność czasową specjalistów o bardzo wysokich kwalifikacjach jak również opłacalność takiego modelu dla obu stron; Chęć redukcji kosztów wpływa coraz bardziej na decyzje podejmowane przez decydentów. Podczas badań jako skalę przyjęto skalę procentową odzwierciedlającą opinię decydentów w przebadanych firmach na temat znaczenia (ważności) ról w…

Czytaj dalejZnaczenie i zapotrzebowanie na specjalistów IT

Raport: Zarządzanie wymaganiami 2011

Ponad 80% projektów programistycznych ma przekroczone termin i budżet. Największą trudnością w tych projektach okazało się jasne zrozumienie tego, czego tak naprawdę klient potrzebuje, oraz udokumentowanie jego wymagań. Do przechowywania wymagań użyty był głównie word i excel oraz email. Przyznajemy jednak, że diagramy najlepiej wyjaśniające (uzupełniające) wątpliwości związane z wymaganiami to modele procesów i prototypy, jednak nie stosujemy ich. ( 2011 State of Requirements Management Report.)Jak widać brzmi znajomo z dwóch powodów: problemy znane każdemu i powody niestety także. Ciśnie mi się na usta "a nie mówiłem"...Czyli jednak wiemy że problemem projektów z zakresu inżynierii oprogramowania są zbyt proste metody i narzędzia zarządzania wymaganiami (pakiet biurowy), które w większości są stosowane. Wiemy, że modelowanie jest najskuteczniejsza metodą analizy i projektowania a mimo to nie stosuje się tych metod szukając stale "drogi na skróty".Dlaczego dostawcy oprogramowania nie stosują metod powszechnie jednak uznawanych za skuteczne?

Czytaj dalejRaport: Zarządzanie wymaganiami 2011

Koniec treści

Nie ma więcej stron do załadowania