Częsty problem, z jakim się spotykam, to zjawisko “utraty panowania nad złożonością” (analizy, dokumentacji, itp.). Winnymi są zresztą sami zamawiający, niepotrafiący myśleć abstrakcyjnie. Nie chodzi o to, że powinni umieć, chodzi o to, że nie uznają tego, nie potrafią. Paradoksalnie, programiści w większości także nie potrafią myśleć abstrakcyjnie.

Beneficjenci  oprogramowania starają się opisać swoje oczekiwania przez pryzmat swojej szczegółowej  wiedzy o pracy jaką wykonują, pomijając w swych opisach niestety jej “oczywiste” dla nich elementy (z reguły najważniejsze). Programiści zaś patrzą na swoją pracę dokładnie tak samo: chcą usłyszeć “co mają zaprogramować”. Pierwsi godzinami opowiadają o znanych im przypadkach i metodach wytworzenia jednego dokumentu, drudzy już w pierwszej minucie spotkania z klientami pytają o “typ pola” tej formatki.

W efekcie zamawiający wyartykułuje setki wymagań a developer zada pytania o kolejne brakujące setki szczegółów tych setek wymagań. Zupełnie niepotrzebnie w pierwszych fazach projektu.

Wśród wielu takich szczegółów są różnego rodzaju ograniczenia nazywane regułami biznesowymi. Poniżej przykładowe “śmieciowe” zapisy w wymaganiach:

1.       Assigning values to variables.

2.       Asserting mandatory GUI fields.

3.       Specifying which data can be viewed by which users.

4.       Expressing which documents are to be routed to which queues.

5.       Orchestrating tasks assignments in an execution environment.

(źr. A Quick 5-Item List of What Are Not Business Rules! ? Ron Ross on Business Rules).

Po pierwsze są to albo elementy związane z implementacja (czyli ostatni etap pracy) albo elementy scenariuszy pracy z GUI. Ani jedno ani drugie to nie reguły biznesowe, bo te – jak sama nazwa wskazuje – ograniczają (regulują) działania biznesowe (ludzi) a nie oprogramowania. Oprogramowanie to tylko narzędzie pracy, ma określone cechy i funkcjonalności i nie może kolidować z biznesem (jego regułami), to tylko narzędzie w rękach ludzi.

Reguły biznesowe

Reguła biznesowa nie powinna zawierać w sobie kryteriów podejmowania decyzji. Reguła biznesowa nie jest elementem algorytmizacji, wskazuje kiedy i co, a nie jak, ma być wykonane. Należy zawsze pamiętać, że model organizacji, system którego elementami są także ludzie, nie może od tych ludzi abstrahować. Dlatego diagramy zawierające wręcz algorytmiczną szczegółowość być może mają sens, tam gdzie szukamy 100%-towej automatyzacji, albo nie mają żadnego sensu.

Na stronie  Business Rules Group można przeczytać Manifest Reguł Biznesowych (także w polskiej wersji ;)). Dlaczego akurat to polecam? Bo konsorcjum to wprowadziło do OMG standard Semantics Of Business Vocabulary And Business Rules (SBVR), który jest zharmonizowany z innymi notacjami, w szczególności z BMM, BPMN i UML. Dzięki temu pojęcie reguły biznesowej ma tę sama definicję na wysokim poziomie abstrakcji analizy biznesowej i na poziomie np. “business rules engine” na poziomie implementacji.

 

Korzyści ze stosowania standardu SBVR to przede wszystkim panowanie nad szczegółami od samego początku projektu. Od samego początku analizy i projektowania logiki systemu należy skupić się na tym “co i po co” a nie “jak”. Zajmowanie się pytaniami “jak” (najgorsze pytanie analizy: jak Państwo to robią) na samym początku, prowadzi do zgromadzenia ogromnej ilości nadmiarowych szczegółów, które zamulają prace wszystkich członków zespołu projektowego. Szczegóły, te których znajomość faktycznie wnosi wartość, należy analizować na końcu, wtedy – mając szkielet całego projektu – wiemy które mają jakiekolwiek znaczenie. Po drugie większość szczegółów obecnie wykonywanej pracy i tak ulegnie zmianie w związku z wdrażaniem nowego narzędzia.

Tak więc: od ogółu do szczegółu, systematycznie i z pełnym zrozumieniem na każdym etapie, a nie “spiszemy wszystko co wiemy a potem zobaczymy”.

Temat tego czy i na ile nietechniczne kadry zarządcze, czyli tak zwany biznes, rozumieją nowe technologie przewija się regularnie przez zarówno prasę jak i blogi. Po pierwsze jest w tym wiele prawdy a po drugie niby dlaczego miało by być inaczej? Jeżeli jakaś treść jest napisana tak zwanym technicznym językiem, to odbiorca, kim jest, sam się ujawni, podobnie jak w przypadku gdy np. w samolocie niemieckich linii lotniczych stewardesa  zawoła do kogoś po polsku podniosą się wyłącznie Polacy.

Z architekturą korporacyjną jest podobnie co potwierdza niżej mój kolega dr. hab. Andrzej Sobczak:

Po pierwsze TOGAF jest napisany w bardzo nieprzystępny sposób ? nawet dla osób dobrze znających angielski (występuje bardzo dużo pojęć, które nie są intuicyjne). Co więcej ?czuć?, że TOGAF został napisany przez informatyków dla informatyków (należy pamiętać, że TOGAF wywodzi się z TAFIM ? tj. Technical Architecture Framework for Information Management, a do wersji 7.0 włącznie w TOGAF?ie mówiono wyłącznie o architekturze IT, dopiero od wersji 8.0 wprowadzono koncepcję architektury korporacyjnej). Po drugie jest niezwykle obszerny (specyfikacja standardu liczy około 700 stron) i nie zawsze jest podzielona w logiczny sposób. Po trzecie wreszcie specyfikacja TOGAF jest miejscami niespójna (co do koncepcji i terminologii) i w niektórych obszarach mocno przestarzała (wynika to z historii rozwoju TOGAF?a jako standardu ? pierwsza jego wersja pojawiła się już w 1996 roku ? bez mała 20 lat temu).

To są minusy tego standardu. Jednak z roku na rok zyskuje on coraz większą popularność. Jeszcze 10 lat temu miał on 7% ?rynku ram archtektonicznych? na świecie?, obecnie jego udział zwiększył się do blisko 60%. Nie można go więc ignorować. Niezbędne jest odpowiednie ?sprzedanie? tego podejścia biznesowej części organizacji. (Jak rozmawiać z biznesem nt. TOGAF?a? | Architektura Korporacyjna).

Powyżej zwrócono uwagę na trzy problemy standardu TOGAF, który jak zauważa autor, ma obecnie 60% udział w rynku (standardów tych jest więcej, przeczytaj mój artykuł i książkę How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework).

Niezrozumiałość to chyba faktycznie efekt tego, że autorami są informatycy. Jest to akurat uzasadnione bo rodowód TOGAF to “konkurencja” dla ITIL.

Obszerność. Hm, tu akurat nie uważam by był to zarzut, specyfikacja notacji BPMN ma podobną objętość, a UML przekroczył 1000 stron. Ramy architektoniczne to także przestrzeń pojęciowa, potężny zestaw terminów mających definicje i cel istnienia czyli opisanie czegoś w spójny sposób. Tu płynnie przechodzimy do trzeciej wady: niespójność. To niestety w moich oczach praktycznie dyskwalifikuje każdy system jeżeli jest niespójny.

Niespójność oznacza powstanie potencjalnej niejednoznaczności w każdym dokumencie (modelu), w którym zostanie użyta niespójna przestrzeń pojęciowa (przypomnę, że poprawna przestrzeń pojęciowa to zestaw pojęć, które cechują: kompletność, niesprzeczność, wzajemna wykluczalność).  A TOGAF i jego słownik terminów to nic innego jak pewna przestrzeń pojęć.

Czy koniecznie musi to być TOGAF?

Ile razy szukam w sieci i książkach definicji pojęcia “architektura korporacyjna” tyle razy przekonuję się, że jej nie ma bo w zasadzie każda znaleziona jest “nieco inna”. Można jednak, studiując literaturę na ten temat, dojść do przekonania, że chodzi po protu o tak zwane całościowe (jak ktoś woli to  holistyczne) systemowe podejście do patrzenia na organizację (analiza systemowa).

Popatrzmy na definicje angielskie (w tym języku powstały pierwsze specyfikacje AE, źr. Oxford Dictionaries):

enteprise –  a business or company: entrepreneurial economic activity

architecture – the art or practice of designing and constructing buildings, the complex or carefully designed structure of something

Tak więc wypada przyjąć, że architektura korporacyjna to

“(całościowa) struktura organizacji prowadzącej działalność o charakterze  komercyjnym“.

[[Jaap Schekkerman]] w swojej książce [[How to Survive in the Jungle of Enterprise Architecture Frameworks: Creating or Choosing an Enterprise Architecture Framework. Creating or choosing an Enteprice Architecture Framework]] tak definiuje AK:

Enterprise Architecture in a complete expression of the enterprise (architektura korporacyjna to kompletny opis organizacji)

Pozostaje odpowiedzieć na pytanie, co zawiera ten kompletny opis? Schekkerman, jak i wielu innych, mówi “wszystko”:

Mamy więc strategię i technologie oraz odpowiadające jej zdolności operacyjne (zarządcze) i technologiczne. Taki opis jest “kompatybilny” z opisem procesu biznesowego w konwencji IGOE (Input, Guide, Output, Enablers, model w projektach z obszaru [[Business Process Manamegent]]) który,  poza swoim wejściem i wyjściem, jest definiowany przez reguły (guide) oraz zasoby umożliwiające jego funkcjonowanie – enablers).

Tak więc mamy odpowiedź na pytanie “Co to znaczy wszystko”. Znaczy to: koncepcja biznesowa (strategia) i sposób zarządzania oraz wymagane technologie czyli strategia ich wykorzystania i zdolność użycia (ich absorpcji). Szczególnie to ostanie ma głęboki sens, gdyż sam fakt zakupu jakiejkolwiek technologii nie jest równoznaczny z jej operacyjnym wdrożeniem (o czym przekonał się niejeden beneficjent systemu np. ERP, CRM czy BI).

Teraz przewrotnie użyję fragmentu podtytułu ww. książki:

Creating an Enterprise Architecture Framework

Tworzenie ramy architektury korporacyjnej. Jak? W sumie, o czym wspominałem w niejednym poprzednim artykule, mamy darmowy komplet narzędzi, czyli systemy pojęciowe dla każdego z powyższych czterech obszarów: strategię możemy opisać z użyciem notacji BMM, reguł biznesowych oraz procesów end-2-end i notacji BPMN. Technologię i sposób jej wykorzystania z pomocą notacji UML. Odpowiednie mapowania (powyżej: poziome i pionowe) robimy albo w macierzy, albo z pomocą Siatki Zachmana. Wybór zależy od przyjętej metody i narzędzia CASE jakim zamierzamy ten projekt dokumentować (bez narzędzia odradzam).

Organizacja OMG dobrze zadbała o spójność tych notacji (Semantic Core), czego niestety nie można powiedzieć o TOGAF i The Open Group (notacja ArchiMate niestety, nie tylko moim zdaniem, pozostawia nieco do życzenia, pomijam już jej licencjonowanie).

Teraz polecam zapoznanie się artykułem Produkty w procesie analizy wymagań. Proszę zwrócić uwagę, że powyższe cztery obszary wiedzy o organizacji: strategia biznesowa, sposób zarządzania – model biznesowy, strategia i zdolność wykorzystania nowych technologii, są objęte opisaną analizą przed-wdrożeniową i analizą wymagań. Wzajemne mapowanie obiektów z tych czterech obszarów to nic innego jak tak zwane śladowanie i walidacja: każdy element musi czemuś służyć i z czegoś wynikać. Moim zdaniem:

Specyfikacja wymagań powinna być produktem (wynikać z) Architektury Korporacyjnej, a nie powstawać każdorazowo od zera z prowadzonych setek wywiadów i warsztatów. 

Tak więc projekt

Architektura Korporacyjna, moim zdaniem, nie ma sensu “sam dla siebie”. Tego typu dokumentacja służy najpierw do zrozumienia działania złożonej organizacji a potem do podejmowania decyzji o każdej reorganizacji czy inwestycji w zasoby.

Wystarczy,  że każda analiza wymagań będzie prowadzona w ten sam, powtarzalny sposób i jako efekt, będzie dawała kompatybilne z poprzedni modele (i dokumenty). Narastająco tworzona dokumentacja prostą drogą poprowadzi nas do dokumentu o nazwie Nasza Architektura Korporacyjna. Zwróci się (koszty stworzenia metodyki) najprawdopodobniej już przy drugim projekcie.

(linia czerwona obrazuje kolejne projekty analityczne i ich narastający koszt, linia niebieska to kolejne projekty analityczne zastąpione stworzeniem i utrzymaniem dokumentacji Architektury Korporacyjnej podczas pierwszego projektu, źr. Jarosław Żeliński, opracowanie własne)

Od czego należy zacząć? Od zbudowania własnej (lub  własnego wariantu) metodyki jej tworzenia oraz zatrudnieniu Architekta. Czy to powinien być własny pracownik? Moim zdaniem nie, gdyż po pierwsze nie będziemy w stanie obciążyć go pracą na 100%. Po drugie powinien to być ktoś z zewnątrz, by nie był uwikłany w wewnątrzorganizacyjne zależności – Architekt korporacyjny nigdy nie powinien być interesariuszem w projekcie związanym z reorganizacją a jako pracownik zawsze nim będzie (podobnie jak lekarz domowy to raczej nikt z domowników).  Kolega w innym swoim artykule pisze:

Architektura korporacyjna nie powinna być utożsamiana z formalnym opisem organizacji (jak to definiuje TOGAF) i nie powinna być tak ?sprzedawana? wewnątrz organizacji.

Jeżeli nie tak ? to w jaki inny sposób? W tym miejscu należy koniecznie odwołać się do ?ojca? koncepcji architektury korporacyjnej ? czyli J. Zachmana. Uważa on, że architektura korporacyjna pomaga rozwiązywać problemy organizacji w iteracyjny i przyrostowy sposób. Przedstawiciele  firmy iCMG idą wręcz dalej ? nazywają oni architekturę korporacyjną dyscypliną naukową zajmującą się tworzeniem, działaniem i rozwojem organizacji. (Czy już pora wymyślić od nowa architekturę korporacyjną? | Architektura Korporacyjna).

i wypada mi się z nim zgodzić 🙂 poza jednym: uważam, że powinien być to opis formalny bo tylko wtedy będzie jednoznaczny i “naukowy”. Tylko wtedy będzie możliwe jego “badanie” np. przeprowadzenie analizy skutków decyzji o reorganizacji zanim ją rozpoczniemy.

Teraz zapewne ktoś powie, że piszę tak tylko dlatego, że świadczę takie usługi. Otóż jest dokładnie odwrotnie: świadczę takie usługi bo głęboko wierzę, że tak właśnie należy postępować, bo – jeżeli organizacja istnieje to ona, architektura, też jest, należy ją tylko przeanalizować, zbudować jej model i korzystać z niego przy podejmowaniu każdej ryzykownej decyzji. Dobry model powinien wolno się zmieniać, tak jak wolno się zmienia organizacja. Jeżeli model jest zbyt szczegółowy i wymaga dużych nakładów na jego aktualizacje jest złym modelem.

Nagromadzenie danych to jeszcze nie jest nauka (Galileusz)

Duże bazy danych na określony temat – najczęściej mowa o zachowaniach klientów ? to ostatnio temat pierwszych, najdalej drugich, stron gazet. BigData to temat przewodni konferencji i artykułów na pierwszych stronach periodyków branży IT. W 2011 roku artykuł na podobny temat kończyłem pytając:

Budowanie modeli na bazie małych partii danych jest po pierwsze wiarygodniejsze (paradoksalnie) niż proste wnioskowanie statystyczne, po drugie daje szanse odkrycia czegoś nowego. W czym problem? To drugie jest nie możliwe z pomocą deterministycznej maszyny jaką jest komputer. To wymaga człowieka, ten jednak nie daje się produkować masowo? ;), korporacja na nim nie zarobi.

Hm? czy przypadkiem promowanie systemów hurtowni danych, BI, pracy z terabajtami danych itp.. to nie tworzenie sobie rynku przez dostawców tych technologii? (Ujarzmić dane – ale po co ich aż tyle?). Ale po kolei. Jednak problem nadal jest. Redakcja COMPUTERWORLD tak zachęca do udziału w swojej konferencji z BigData w tytule (fragment):

Big Data nie jest tylko kolejnym hasłem marketingowym dostawców IT. To antycypacja zjawiska przekroczenia masy krytycznej wielkości, różnorodności, liczby i dynamiki źródeł gromadzonych w przedsiębiorstwie danych. Gdy mamy ich naprawdę dużo, gdy pochodzą one z wielu różnych miejsc, gdy są stale aktualizowane i ciągle ich przybywa, wtedy możliwości analityczne i potencjał wykorzystania wiedzy zgromadzonej w tych danych rośnie wykładniczo. Ale wymaga to całkiem nowych platform technologicznych i zestawów kompetencji.

Wniosek jaki wysnuto: potrzebna nowa, ?lepsza? technologia. Czy aby na pewno? Jeżeli jednak BigData ma nie być kolejnym hasłem marketingowym to znaczy, że nie jest najlepszym rozwiązaniem kupienie kolejnego jeszcze większego i jeszcze szybszego ?sprzętu?. Moim zdaniem w dalszej części zaproszenia zwrócono uwagę na kierunek dający większe szanse powodzenia:

Liczba danych gromadzonych w biznesie przyrasta rocznie o 50 procent. Więcej jednak wcale nie znaczy lepiej – by hasło Big Data przełożyło się na Big Business potrzeba nowych umiejętności, odpowiednich narzędzi i odpowiedniej strategii zarządzania informacją. (źr. Zaproszenie na konferencję BigData COMPUTERWORLD luty 2013)

Pada hasło strategia, na którym postaram się skupić w dalszej części. Wcześniej jednak zdefiniujmy pojęcie BigData by wiadomo było o czym tu będę traktował:

W 2001 roku META Group (obecnie Gartner) opublikowała raport, który opisuje big data w modelu 3V. Wskazuje on na dużą ilość danych (Volume), dużą zmienność danych (Velocity) oraz dużą różnorodność danych (Variety). W 2012 roku Gartner uzupełnił podaną wcześniej definicję wskazując, iż ?big data to zbiory informacji o dużej objętości, dużej zmienności i/lub dużej różnorodności, które wymagają nowych form przetwarzania w celu wspomagania podejmowania decyzji, odkrywania nowych zjawisk oraz optymalizacji procesów?. (źr. BigData WIKI)

Tak wiec mamy definicję: big data to zbiory informacji o dużej objętości, dużej zmienności i/lub dużej różnorodności. Resztę pominąłem zdania pominąłem, gdyż to czego BigData wymaga nie jest przedmiotem definicji pojęcia.

Na czym polega problem biznesowy? Generalnie ludzie (o heurystykach już pisałem)  stosują metody indukcyjne jako narzędzie wyciągania wniosków. Indukcja to w naukach empirycznych metoda polegająca na wprowadzeniu uogólnień na podstawie eksperymentów i obserwacji faktów, formułowaniu i weryfikacji hipotez. Zaczątki indukcji w sensie nowożytnym stworzył F. Bacon, który uznał, że indukcja i eksperyment to dwie skuteczne metody ustalania prawdy. Słowo klucz tu to ?fakty?. Z indukcją mają do czynienia wszyscy, którzy korzystają z analizy trendów (np. analiza techniczna w przypadku analizy kursów walut czy akcji).

Problem z indukcją, jako metodą, polega na tym, że w zasadzie sprowadza się do próby oceny tego, z jakim prawdopodobieństwem powtórzy się historia badanego zjawiska. Metoda ta nie prowadzi do nowych odkryć, prowadzi do modeli opisujących prawdopodobieństwo powtórzenia się faktów, o których mamy wiedzę, że wystąpiły.

Firmy, w miarę rozwoju technologii i rozbudowy swoich procesów biznesowych, gromadzą coraz większe ilości danych o znanych im faktach ze swojej historii. Rejestrowane są coraz dokładniej i ?gęściej? w czasie, wszelkie zdarzenia na firmowych stronach WWW, wszelka wiedza o zdarzeniach w prowadzonej działalności. Firmy popycha do tego wiara w to, że im więcej danych tym lepsze wnioski. Praktyka jednak pokazuje, że rosnąca dokładność ?próbkowania? np. zachowań klientów nie prowadzi do proporcjonalnego wzrostu zamówień. Owszem, poznając te zachowania można lepiej zaadresować ofertę, to prawda ale nie jest to zależność liniowa.

Do 2015 roku ponad 85 proc. firm sklasyfikowanych w rankingu Fortune 500 nie będzie potrafiło efektywnie wykorzystać posiadanych zbiorów danych, bowiem wystąpi efekt tzw. big data. Co więc z tymi danymi robić? Ignorować je troszkę. Jeżeli prawdą jest, że dziś, w ciągu zaledwie dwóch dni produkujemy tyle danych, ile ludzkość wytworzyła od zarania dziejów do roku 2003, to porównując to z postępem dokonanym w ciągu ostatniej dekady z postępem ostatnich dwóch tysięcy lat, wniosek nasuwa się jeden: raczej nie ilość danych decyduje o wiedzy i postępie. Więc co?

W opozycji do indukcji jako metody poznania (epistemologia) stoi dedukcja. Dedukcja to rozumowanie polegające na wyprowadzaniu z przesłanek (zdań) uznanych za prawdziwe na podstawie faktów, następstwa będącego logicznym i prawdziwym wnioskiem. Innymi słowy, dedukcja polega postawieniu hipotezy na podstawie pewnej ograniczonej liczby danych (faktów), udowodnieniu jej słuszności (poprzez brak faktów przeczących tej tezie – nieudana falsyfikacja) i wyciąganiu wniosków o przyszłości. Jak dowodzi się takiej hipotezy? Testuje się  sprawdzając, czy poprawnie opisuje znany z historii fakty. Innymi słowy: jeżeli nie odkryto faktów obalających tezę (pokazujących, że jest nieprawdziwa) uznaje się ją za poprawną.

Typowym przykładem indukcji jest prognozowanie pogody na bazie znanych z historii faktów: prognoza była uznaniem, że powtórzy się określona sytuacja zaobserwowana w przeszłości (np. nisko latające jaskółki zapowiadają deszcze). Obecne prognozy to dedukcja: na bazie określonej partii danych opracowano tezę: model fizyczny atmosfery i zjawisk w niej zachodzących. Model ten, po podaniu danych o stanie obecnym atmosfery, pozwala na wnioskowanie (wyliczenie) jego stanu na dzień lub tydzień następny (tu krótko i średnioterminowa prognoza). Co ciekawe, ta metoda (dedukcja) pozwala na przewidywanie faktów, które nie zaszły w przeszłości (z prawdopodobieństwem wynikającym z jakości użytego modelu i kosztu obliczeń).

Dedukcję jako metodę poznania (metoda dowodzenia poprzez stawianie hipotez i ich falsyfikację) opisał Karl Popper. Nosi ona obecnie nazwę ?metody naukowej?.

Jak to się ma do naszego BigData? Moim zdaniem BigData to ślepa uliczka. Rosnące nakłady na sprzęt i oprogramowanie zmniejszają jedynie błąd statystyczny obliczeń nie wnosząc nic do ich jakości w rozumieniu ?jakości prognozowania?. Co do ?odkrywania? czegokolwiek nie ma mowy, udowodniono, że metodami indukcyjnymi nie da się niczego nowego odkryć, można co najwyżej udokumentować trend. Owszem, pozostaje kwestia analizy korelacyjnej, czyli wykrywania związków pomiędzy faktami (np. czy pora dnia wpływa na decyzje zakupowe). Tego typu analizy nie są niczym nowym, są znane wśród specjalistów z zakresu Business Inteligence od dawna.

Tak więc kluczową strategią wydaje się tu być tak zwany program retencyjny, czyli strategia wyboru danych do przechowywania (i usuwanie pozostałych), bo nie da się “zapamiętać? wszystkiego. Jednym z ?modnych? elementów strategii sprzedażowych są tak zwane programy partnerskie. Maciej Tesławski (ekspert z zakresu marketingu) na swoim blogu pisze:

Programy retencyjne mogą być B2B, B2C i multipartnerskie, lojalnościowe mogą być tylko B2C bo w biznesie decyzje zakupowe podejmuje się w znacznym stopniu racjonalnie a nie emocjonalnie. Jeśli chodzi o ocenę działających programów retencyjnych, to podstawowy błąd jaki widzę to niewykorzystywanie bazy informacji o uczestnikach programu przez firmy. To jest potężny zbiór informacji o zachowaniach poszczególnych konsumentów, w połączeniu z danymi demograficznymi pozwala na ?poznanie? profilu najbardziej wartościowych konsumentów. Nie zauważyłem aby ktokolwiek to wykorzystywał. Dzieje się tak zapewne dlatego, że bazy danych rosną w postępie geometrycznym i przerastają możliwości ich bieżącego wykorzystywania.

Skoro tak, to wiemy co ? pozostaje jak. Jak zauważono na początku, przyrastająca ilość danych, a raczej korzystanie z nich, wymaga całkiem nowych platform technologicznych i zestawów kompetencji. Platformy technologiczne są, postęp techniczny nam je zapewnia. Wydaje się, że  kluczem jest ?nowy zestaw kompetencji?.

Moim zdaniem dużymi krokami nadchodzi  czas, gdy z analizy statystycznej należy się przerzucić na analizę systemową ? dedukcję, oraz odpowiednie strategie retencji danych. W niedawnej przeszłości stwierdzono, że rosnąca ilość danych i dalsze uszczegółowianie danych o zmianach temperatury, ciśnienia, wielkości opadów nie poprawiają jakości prognoz pogody. Zmieniono podejście i jak widać udało się, prognozy pogody nigdy nie były tak dokładne jak w ostatniej dekadzie a nie jest to efekt BigData.

Od technologii teraz nie oczekiwał bym ogromnych pojemności a mocy obliczeniowej, tu widzę drogę do sukcesu: analiza ograniczonej ilości faktów, budowanie modeli zachowań np. konsumentów, prognozowanie tych zachować. Myślę też, że pewnego progu jakości prognoz nie przekroczymy. Filozofia dowodzi, że nie da się stworzyć w świecie realnym demiurga (w filozofii Platona określano tak budowniczego świata nadającego kształty wiecznej, bezkształtnej materii według wzorców, jakie stanowią doskonałe idee; w filozofii nowożytnej demon potrafiący obliczyć przyszły stan świata na podstawie wiedzy o wszystkich atomach i prawach nimi rządzących). Praktyka pokazuje, że nie istnieje i długo nie powstanie taka moc obliczeniowa by choć troszkę się do demiurga zbliżyć.

A czym jest ta analiza systemowa i modelowanie? Wyobraźmy sobie kogoś, kto chce przewidywać zachowania kul podczas gry w snookera. Problem ten może zostać opisany faktami opisującymi grę powierzchownie: ?Gracz uderza białą kulę, która przemieszcza się z pewną prędkością, ta po określonym czasie uderza czerwoną kulę pod określonym kątem, uderzona czerwona kula przemieszcza się na pewną odległość w pewnym kierunku.? Można sfilmować setki tysięcy takich uderzeń, zarejestrować z dowolna dokładnością parametry każdego uderzenia i jego skutki. Jednak tą metodą i tak nie stworzymy nawet dość dobrej symulacji. Aby stworzyć na prawdę dobrą symulację, należy zrozumieć prawa rządzące ruchem kul, ich zależność od siły i kierunku uderzenia, kierunku itp. Zrozumienie tych praw pozwoli znacznie łatwiej przewidzieć skutek każdego uderzenia.? (na podstawie Analysis Patterns. Reusable Object Models, Martin Fowler, Addison-Wesley, 1997).

P.S.

W ramach uzupełnienia dyskusji o indukcji zamieszczam cytat z Karla Poppera, jedna z wielu obecnych opinii o indukcji jako metodzie:

Polecam teą artykuły wcześnijesze:

• Ujarzmić firmowe dane…
• Ekonomia myślenia…

Wczoraj podczas drugiego dnia dnia konferencji EOIF jeden z referatów (Zarządzanie wymaganiami biznesowymi dla systemów IT wspierających elektroniczny obieg informacji, Sylwia Raczko, Carrywater Group S.A.). Nie podejmę próby powtórzenia go, nie taki mam cel. Będzie tu kilka słów ode mnie. Ale po kolei.

Etap pierwszy to analiza otoczenia projektu

Najczęściej pomijany etap w projektach. Moim zdaniem z dwóch powodów. Mało który sponsor projektu ma świadomość jakie ryzyka niesie brak wiedzy o otoczeniu projektu, bo jako sponsor już uwierzył w jego sukces (choroba znana jako emocjonalne podejście do własnych pomysłów). Drugi powód to fakt, że wielu interesariuszy projektu ma interes w tym, by te ryzyka nie zostały ujawnione. ten etap to pierwszy element, którego realizacja napotyka opory, a moim zdaniem powinien być wykonany nie raz przez zawarciem głównej umowy, gdyż może się okazać, że  projekt jest z góry skazany na porażkę.

Z perspektywy każdego systemu (system to nie tylko oprogramowanie, to także system zarządzani jakością czy nowy system rabatowy) należy opracować model uwzględniający tych, którzy będę z niego bezpośrednio korzystali (aktorzy) oraz tych, którzy odczują skutki jego wdrożenia a mają wpływ na jego powstawanie. Taka analiza wpływu pozwoli ocenić ryzyka generowane przez każdego interesariusza i właściwie na nie zareagować. Jednym z produktów takiej analizy jest plan komunikacji. Mamy więc na tym etapie produkty:

1. model otoczenia systemu (projektu),
2. analiza ryzyka,
3. plan komunikacji.

Więcej o tym etapie w artykule Udziałowcy projektu czyli który diagram UML (czytaj).

Etap drugi analiza i specyfikowanie wymagań

Ten etap jest największą częścią projektu analitycznego. Jak zebrać wymagania to tema rzeka. Ogólnie metody analizy i specyfikowania wymagań można podzielić na dwie grupy:

1. metody formalne,
2. metody nieformane.

Pierwsze opierają się na zastosowaniu sformalizowanych systemów pojęciowych i weryfikowalnym procesie analitycznym czyli po protu na stosowaniu określonych notacji (z reguły BMM i BPMN) oraz  analizy systemowej.

Drugie bazują na spotkaniach, warsztatach, moderowanych sesjach. Ich główną cechą  jest uznanie, że tak zebrane dane są wiarygodne: uznanie a priori, że zamawiający się nie myli i ma rację. Jakkolwiek to brzmi, nie jest to takie oczywiste. Wykazanie niesprzeczności tak zebranych wymagań jest wykonalne ale już ich spójność i kompletność jest nie do wykazania bo nie istnieje test kompletności “opowiadania”, skoro nie można wykazać (przetestować) kompletności to tym bardziej nie da się wykazać spójności.

Metody formalne bazują na analizie “od ogółu do szczegółu” organizacji i opracowaniu jej kompletnego modelu (na wymaganym dla danej analizy poziomie szczegółowości). Model taki staje się narzędziem testowania wymagań, np. mając modele wszystkich procesów biznesowych możemy sprawdzić, czy nie pominęliśmy jakichś istotnych działań, które wymagały by ujęcia w wymaganiach.

Bardzo ważna rzeczą jest jest podzielenie wymagań na biznesowe i funkcjonalne bo to nie to samo (czytaj Produkty w procesie analizy wymagań). Pani Raczko przywołała definicję Rona Ross’a, jednak chyba zbyt uprościła oryginał sprowadzając słowo “system” do “oprogramowanie”. Znany mi oryginał brzmi:

We define a business requirement as ?something called for or demanded by a business model that a system model must support?

We define a system model as follows a model that provides a design for an automatable system that is computationally competent.

(źr. What?s the Difference Between Business Requirements and Functional Requirements?)

Rzecz w tym, że słowo “computational” oznacza “wyliczalność” w rozumieniu da się wyliczać automatycznie (raczej w sensie algorytmicznym). To nie koniecznie musi być komputer, mogą to być określone do wdrożenia procedury (przypomnę, że przedmiotem projektowania może być system zarządzania jakością lub system rabatowy sprzedaży). Warto zwrócić uwagę, że Ross nie użył słowa “requirement” (wymagania) w odniesieniu do systemu a “model”. Ross także słusznie zauważa, że wikipedia zrównuje pojęcie wymagać z wymaganiami funkcjonalnymi co jest i moim zdaniem błędem. Prawdopodobnie to uproszczenie w prezentacji zostało dokonane z uwagi na tematykę konferencji, uważam jednak, że jest groźne. Mam wszystkie książki Ross’a i wydaje mi się, że nie zrównuje on pojęcia system z oprogramowaniem.

Wymagania biznesowe w stosunku do wymagań “systemowych” cechuje inna bardzo ważna różnica: treść wymagań biznesowych MUSI być w 100% zrozumiała dla zamawiającego, napisana jego językiem. Model systemu, jako wymagania na system, może być (i z reguły jest) już “wiedzą tajemną” zrozumiałą tylko dla dostawcy systemu.

Zarządzanie zmianą wymagań

To kolejne niechciane dziecko w projektach. Jeżeli zgodzimy się, że zmiana wymagań jest “normą” to brak wiedzy (zapisów) o tych zmianach potrafi zabić projekt. Problem, który ja widzę w wielu projektach to: im łatwiej zgłosić i egzekwować zmianę w wymaganiach tym więcej tych zmian jest. Nie chodzi o to by tych zmian zakazywać, chodzi o to by były one za każdym razem przemyślane, a chodzi głownie o wpływ zmian na termin i budżet projektu.

Ja także widzę tu dużą różnicę. Z moich obserwacji wynika, że projekty, w których zastosowano zwinne metody zarządzania nimi, bardzo często tracą kontrolę nad zakresem projektu. Po pierwsze dlatego, że wprowadzanie zmian bez ich dokumentowania i świadomego przeprojektowywania systemu, prowadzi do niekontrolowanego przyrostu pracy. Po drugie projekty zwinne cechuje to, że nie  mają opisanego zakresu projektu a jedynie wizje produktu jaki ma powstać, w efekcie jedynym elementem projektu jakim zarządza kierownik projektu jest praktycznie tylko budżet gdyż zakres jako taki nie istnieje a harmonogram to tylko na bieżąco definiowane etapy.

Uogólniając nieco: w metodach klasycznych istnieje sztywna granica pomiędzy fazą analizy i specyfikowania wymagań a fazą ich implementacji. W metodach zwinnych mamy pętlę zgłaszania zmian (i nowych wymagań), która z reguły nie jest dokumentowana.

Czy to powoduje, że w metodach klasycznych odcinamy sobie możliwość zastosowania nowych pomysłów? Absolutnie nie, nowe pomysły są materiałem na nowy projekt. Zgłaszane zmiany są analizowane i albo są akceptowane  bo mają mały lub żaden wpływ na budżet i harmonogram, albo są odkładane na etap “eksploatacji i rozwoju” w cyklu życia produktu (nowy cel projektu i nowy projekt). Pani Raczko stwierdziła, że jej doświadczenie wskazuje, że projekty prowadzone metodą klasyczną są z reguły szybciej kończone, ale dotyczy to raczej większych projektów. Moje doświadczenia są analogiczne. Granicą którą kiedyś obliczałem, po przekroczeniu której warto zrezygnować z metod zwinnych, jest budżet przekraczający 100 tys. zł. Jak widać nie są to aż tak wielkie projekty. Jednak dla każdej firmy utrata 100 tys. zł (nieudany projekt) stanowi bardzo odczuwalny wydatek.

Jak wygląda taka zmiana?

 

Kluczowe korzyści to kompletna dokumentacja projektu, jest ona nie tylko pomocna po jego zakończeniu, ale także w trakcie jego trwania, gdyż stanowi narzędzie kontroli budżetu. Bardzo złym miernikiem postępu projektu jest deklarowanie zużywanych zasobów (roboczogodziny lub dni), w zwinnych metodach to w zasadzie jest to jedyny miernik. Jeżeli zaś dysponujemy dokumentacją każdej zmiany, jest ona znacznie bardziej wiarygodnym miernikiem postępu projektu, gdyż zarządzamy projektem zadaniowo a nie zasobowo. W metodach zwinnych nie da się wykonać analizy wpływu zmiany na cały projekt, bo nie istnieje dokumentacja całego systemu (jego model), on dopiero powstaje w trakcie trwania projektu. Tak więc w zasadzie nie istnieje pojęcie analizy ryzyka zgłaszanej zmiany w metodach zwinnych. W metodzie klasycznej, mamy udokumentowany, każdy etap projektu co, poza ewentualnymi sporami o zakres, pozwala panować nad spójnością i niesprzecznościa zgłaszanych zmian wymagań, gdyż specyfikacja – jako całość – przez cały czas trwania projektu (a nie tylko na początku) ma być kompletna, spójna i niesprzeczna.

Na koniec narzędzia

W tej kwestii jedno jest pewne: jeżeli już uznamy, że wymaganiami zarządzamy, to robienie tego narzędziami biurowymi (edytor tekstu, arkusz kalkulacyjny, proste oprogramowanie do diagramów typu Visio) strasznie podniesie pracochłonność projektu (czytaj o sabotażu dokumentacyjnym). Klienci, którzy uważają, że wolno użyć tylko narzędzi, których sami na co dzień używają, sami sobie robią krzywdę, bo zgłaszanie zmian nie polega na modyfikacji cudzych dokumentów projektowych, a na tworzeniu własnych (czytaj o zgłaszaniu zmian).

Biorąc pod uwagę fakt, że wymagań w średnim nawet projekcie jest co najmniej kilkadziesiąt, utrzymanie ich spójności i analiza wpływu każdej zmiany na cały projekt staje się benedyktyńską pracą, najczęściej szybko zarzucaną właśnie z powodu pracochłonności (a nie braku jej sensu). Dlatego w zasadzie brak narzędzia CASE do zarządzania wymaganiami (są z reguły częścią narzędzi do analizy i modelowania) w zasadzie w moich oczach dyskwalifikuje usługodawcę.

Z powyższego płynie także kolejny wniosek: autor specyfikacji wymagań, powinien kontynuować projekt jako osoba zarządzająca wymaganiami, i bardzo dobrze jest jeżeli pracuje po stronie Zamawiającego, gdyż stanowi naturalny mechanizm kontroli pracy dostawcy np. oprogramowania. Zamawiający nie ma innej możliwości realnego, merytorycznego nadzoru nad dostawcą, to Zamawiający powinien zarządzać wymaganiami bo to w końcu jego wymagania!

W artykule Inżynieria wymagań między innymi opublikowałem taksonomię wymagań, jej rozwinięta postać:

Temat wymagań regularnie wypływa na forach dyskusyjnych i na konferencjach. Ostatnio w podobnej formie pojawił się na pewnym forum serwisu LinkedIn i na dzisiejszej konferencji. Na forum padło pytanie: co wybrać jako dokumentacje wymagań: SRS czy Use Case (odpowiednio [[Software Requirements Specification]] czyli [[specyfikacja wymagań na oprogramowanie]] i Przypadki Użycia oprogramowania). Na dzisiejszej konferencji zaś prawnik, podczas swojego referatu, zwrócił uwagę na fakt, że od strony umów, projekty – od analizy przedwdrożeniowej do dostarczenia zamówionego oprogramowania – należy dzielić projekt na fazy będące, zależnie od celu, umową efektu (umowa o dzieło) i umową starannego działania (umowa zlecenia).

Problem w tym, że SRS – często rozumiane jako dokument o strukturze opisanej w [[rekomendacji IEEE830]], zawiera w pewnej formie przypadki użycia (ale nie ich scenariusze) rozumiane jako opis funkcjonalności. Do tego rekomendacja ta nie jest standardem zawartości dokumentu a rekomendacją.

 

Pojęcie przypadku użycia ma co najmniej dwie zupełnie różne definicje: jedną rodem z książki Alistair’a Cockbourna “Jak pisać efektywne przypadki użycia”, druga w specyfikacji notacji UML. Osobiście preferuję te drugą i tylko o nie będzie tu mowa (Cockbourn zresztą jawnie wyraża niechęć do UML w swojej książce).

Dla uporządkowania dalszej treści przyjmuję, że pojęcie przypadek użycia oprogramowania i funkcjonalność oprogramowania są tożsame (a konkretnie przypadek użycia opisuje sposób realizacji funkcjonalności): obie określają to jaki efekt chce osiągnąć (do czego użyć), w konkretnym przypadku, użytkownik oprogramowania (konkretna funkcja jaką pełni oprogramowanie, to jego możliwy przypadek użycia).

Popatrzmy na etapy projektu, które wyróżniono na bazie tego, jakiej wiedzy potrzebujemy na każdym z tych etapów, by zaplanować kolejny.

 

 

Jako pierwsze powstają wymagania biznesowe opracowane na bazie oceny sytuacji biznesowej. Są one albo własnym produktem Zamawiającego albo produktem zatrudnionego do tego celu eksperta. Na bazie wymagań biznesowych (celów biznesowych) wykonuje się analizę wykonywalności tych celów, powstaje pomysł rozwiązania problemu (osiągnięcia celu) w postaci wymagań wobec rekomendowanego rozwiązania.  Jeżeli istnieje (znaleziono) na rynku rozwiązanie (produkt lub standardową usługę) zostaje ono zakupione i wdrożone. Jeżeli nie (dotyczy nie tylko całości ale i części wymagań) należy rozwiązanie najpierw zaprojektować a potem dopiero zlecić wykonanie i wdrożenie (a wcześniej na bazie projektu wycenić).

Każdy z tych produktów to przedmiot osobnej umowy (lub jej etapu).  Zależnie od “stopnia niewiedzy” po stronie Zamawiającego, może to być umowa o dzieło lub zlecenia. Jednak zaleca się (prawnicy zalecają) by, zawsze tam gdzie angażowany jest ekspert (usługodawca) zewnętrzny, stosować umowy o dzieło (umowa efektu), gdyż pozwala to panować i nad czasem i nad budżetem projektu oraz w przypadku sporu sądowego, możliwe było określenie przedmiotu sporu (opis tego co miało zostać wytworzone – dzieło).

Do zawarcia umowy o dzieło konieczny jest opis tego co ma powstać (opis dzieła). Patrząc od końca: zawierając umowę z dostawcą oprogramowania mamy wymagania wobec produktu gotowego (w momencie zakupu spełnia je lub nie) lub wykonany projekt tego co ma powstać. Aby powstał projekt musimy mieć określone wymagania wobec rozwiązania i wymagania (cele) biznesowe. Najtrudniej jest wycenić etap analizy sytuacji biznesowej bo tu w zasadzie nie wiemy jaka ta sytuacja jest. Wymagania biznesowe, by powstały, wymagają pozyskania wiedzy o tym jak funkcjonuje organizacja Zamawiającego i jakie zmiany planuje. To etap analizy biznesowej (model motywacji biznesowej i modele procesów biznesowych). W tym wypadku będzie to raczej umowa starannego działania z ekspertem, który tę analizę (i modele)  wykona.

Pewnym rozwiązaniem problemu ryzyka umowy “czas i materiał” (nie wiemy kiedy i jakim kosztem powstanie oczekiwany produkt),  jest określenie tego jaki konkretnie produkt ma powstać (opis tego, jak stwierdzimy, że prace wykonano poprawnie) i określenia czasu jaki sobie na to dajemy. Wymaga to pewnej inwestycji, poświęcenia czasu na to, ale  opłaci się bo mocno obniżamy ryzyko projektu.

Konkluzja prawnika, by zawierać umowy o dzieło jeżeli tylko jest to możliwe, jest moim zdaniem słuszna. Tam gdzie nie mamy wystarczającej wiedzy by zawierać takie umowy, warto zainwestować czas by określić jednak przedmiot umowy, gdyż umowa zlecenia z ekspertem (dostawcą oprogramowania) powoduje, że Zamawiający kompletnie nie panuje nad umową: nie wie jakiego produktu oczekiwać, satysfakcja z wykonanej pracy może nadejść w trudnym do przewidzenia czasie.

Druga uwaga: jeżeli cały proces, od pierwszej analizy do dostarczenia produktu, realizuje jedna firma, mamy do czynienia z sytuacją, w której dostawca sam kontroluje stawiane mu wymagania bo sam sobie definiuje to co ma następnie wytworzyć. Taki brak kontroli rodzi poważne ryzyko nierzetelności.