Zaskoczył mnie ostatnio jeden z moich czytelników: zapytał mnie:

Od lat śledzę Pana blog i osiągnięcia w zakresie analizy systemowej i biznesowej. Mimo, że nie zajmuję się zawodowo modelowaniem wymagań na oprogramowanie starałem się zrozumie Pana podejście:

1)      W pierwszym etapie wykonujemy analizę biznesową problemu klienta korzystając z BMM

2)      Jeśli dochodzimy na tej podstawie do wniosku, że właściwym podejściem jest wytworzenie oprogramowania przeprowadzamy analizę systemową korzystając z UML i tworzymy model dziedziny systemu, który jest podstawą do projektowania i wytwarzania dedykowanego oprogramowania

Czy dobrze zrozumiałem?

Odpisałem, że tak, jednak warto robić pomiędzy punktami 1) i 2) model firmy opisujący jak ona działa, gdyż takie projekty są bardzo dobrymi momentami na ewentualne reorganizacje. I tu padają tezy związane z modelowaniem organizacji:

Przenosząc to na grunt własnym problemów zawodowych próbuję analogicznie stworzyć model postępowania w problemach organizacyjnych rozwiązywanych za pomocą stworzenia odpowiednich procedur postępowania (n.p. przy wdrażaniu systemów zarządzania zgodnych z ISO 27001, ISO 20000 i ISO 22301):

1)      Podobnie jak powyżej wykonujemy analizę biznesową problemu klienta korzystając z BMM

2)      Po stwierdzeniu, że problem można rozwiązać zbiorem procedur przeprowadzamy analizę organizacyjną (?) korzystając z BMPN i tworzymy??

No właśnie ? czy spotkał się Pan z odpowiednikiem modelu dziedziny systemy w ?inżynierii wymagań na organizację?? Czyli ze zbiorem wymagań na procedury, które powinny zostać wdrożone, aby rozwiązać określony problem biznesowy?

Niestety w Polsce nie spotkałem, spotykam się jednak w literaturze z tezami, że wdrożenie jakichkolwiek norm, nie tylko jakości, powinno być także poprzedzone analizą. Innymi słowy normy jakości powinny być wdrażane jako odpowiedź (rozwiązanie) na określone wymagania, a nie dla samego faktu ich wdrażania. Owszem, bywa, że wymaganiem jest np. wymóg przetargowy (oferty mogą składać tylko firmy mające określony certyfikat), jednak moda na jakość, mimo że nie przeminęła całkowicie, powoli przechodzi w racjonalne powody wdrażania norm jakości.

Sam zresztą wdrażam pewne procedury w każdym moim projekcie, np. “zakazuję” wymiany dokumentów emailem, są współdzielone w repozytorium pozwalającym na ich wersjonowanie i komentowanie (skrzynki mailowe to jeden z najgorszych sposobów zarządzania dokumentacją projektową, nie tylko z powodu braku poufności). Uwagi do dokumentów “nakazuję” zgłaszać pisemnie osobna notatkę, a nie w macierzystym dokumencie metodą nanoszenia i rejestracji zmian. W tym przypadku po prostu nikt nie panuje  nad treścią dokumentu, rozmywa się jego autorstwo (a jako osoba realizująca umowę o dzieło nie mogę do tego dopuszczać), no nie można mieć pewności, że ktoś określonych uwag nie “zaakcpetował”, czego już nie widać, a wyszukiwanie zmian w nawet średniej wielkości dokumencie, potrafi być żmudne.  (przeczytaj o wadach pracy z narzędziami biurowymi w projektach).

Procedury to efekt wymagań jakie ja stawiam przed procesem analizy i projektowania, miedzy innymi:

1. musi być zachowane jednoosobowe autorstwo dokumentów (każdy dokument ma wyłącznie jednego autora): wprowadzanie do niego zmian przez inne osoby jest niedopuszczalne,  
2. musi być dostęp do historii prac nad dokumentem: uwagi do treści, w tym propozycje zmiany, do dokumentów są zgłaszane wyłącznie w trybie “zgłaszania zmian” (każdy taki dokument ma także jednego autora: osobą zgłaszającą
3. tylko uzasadnione zmiany podlegają rozpatrywaniu: każda uwaga do recenzowanej treści musi zawierać uzasadnienie (jakie ryzyko niesie obecna treść, jak ją zmienić).
4. dokumenty nie mogą ginąć, nie mogą byś usuwane, kolejne wersje muszą być oznaczane numerem wersji, każdy członek zespołu projektowego musi mieć identyczne informacje: musi być wdrożone współdzielone repozytorium plików projektowych, dokumenty są znakowane czasem i godziną dostarczenia.
5. musi być możliwa praca zdalna bez konieczności instalowania na komputerze jakiegokolwiek dodatkowego oprogramowania: repozytorium plików powinno pracować poprzez przeglądarkę WWW.

Tak więc mamy określone wymagania i ich realizację (opis wymagania i procedura po dwukropku). Normalnym trybem  w większych projektach, prowadzona jest analiza firmy i budowany jest jej model procesowy. Na nim “wyszukujemy” miejsca stwarzające ryzyka, opisujemy je. Jeżeli uznamy, że chcemy te ryzyka eliminować lub zmniejszać, mamy tym samym wymagania biznesowe. Kolejny krok to opracowanie rozwiązania, w moim przypadku powyżej, były to trzy procedury oraz wymaganie na elektroniczne repozytorium. Można więc sobie wyobrazić, że w kategoriach całej firmy powstaną wymagania, które można zrealizować wdrażając konkretną normę ISO.

Zastanawiam się również co taki model powinien zawierać? (analogicznie do modelu dziedziny systemu):

– listę ról (odpowiednik obiektów/klas?)

– listę umiejętności danej roli (odpowiednik cech obiektu/klasy?)

– listę procedur jakie używa dana rola (odpowiednik metod obiektu/klasy?)

Powyższe to raczej materiał na model procesowy. Prawdą jest, że role to pewne obiekty w systemie jakim jest organizacja, jednak już ich umiejętności i procedury to wiedza o tym jak wykonać daną prace, procedura (jej utworzenie) to minimalizacja ryzyka, że praca ta zostanie wykonana źle. I tu przytoczę mój model procesu w organizacji:

Tak więc każdy elementarny proces zawiera elementy, o których wspomina mój czytelnik. Owszem model obiektowy jest tu możliwy do wykonania ale będzie to statyczna struktura (która także bywa potrzebna jako model) jednak model organizacji w postaci procesów, to fundament tej dokumentacji. Proszę zwrócić uwagę, że  to co jest wokół procesu (procedury, reguły biznesowe, struktura organizacyjna, zakresy kompetencji, inne) to w większości elementy dokumentacji systemów zarządzania jakością. Mając model procesu, po jego ewentualnej optymalizacji, mamy bardzo dobry materiał do opracowania wymagań na System Zarządzania Jakością: wiemy jakie dokładnie dokumenty mają powstać a jakie należy zmodyfikować, wiemy po co powstają.

Zaletą takiego postępowania jest możliwość uzasadnienia biznesowego (śladowanie) każdego wymagania. Innymi słowy, jesteśmy w stanie wykazać, że każda proponowana nowa lub zmieniona procedura, wspiera określony cel biznesowy oraz wynika z “naprawy” określonego procesu.

Po przeczytaniu powyższego, w kolejnym liście  mój czytelnik pisze porządkując:

Chciałbym się jeszcze podzielić jedną obserwacją a propos ISO ? być może uzna Pan ją za błędną ?

Otóż akurat norma ISO 27001, z którą mam aktualnie do czynienia definiuje coś takiego co nazywa przeprowadzeniem analizy ryzyka, a efektem ma być plan postępowania z ryzykiem. Na początku nie mogłem sobie tego wyobrazić, ale po Pańskiej odpowiedzi sprawa wydaje się jasna:

– na podstawie analizy organizacji definiujemy klasyfikację informacji  ? to definiuje norma ([…] punktem wyjścia są dokumenty i artefakty (fizyczna reprezentacja/lokalizacja dokumentów), które zawierają informacje. Przykładowo umowa z kontrahentem i oferta (dokumenty) zawiera wycenę usługi (informacja), która powinna być chroniona na określonym poziomie. Związanie dokumentów i ich reprezentacji za pomocą ?informacji? pozwala ustalić poziom ochrony określonych dokumentów i ich fizycznych reprezentacji i lokalizacji. Z kolei poziom ochrony informacji jest czystym wymaganiem biznesowym ? to biznes określa jakie ?informacje? należy ?jak? chronić. Model ?informacji? powinien pozwolić na podstawie klasyfikacji ustalonej z biznesem określić poziom ochrony dokumentów i ich fizycznych realizacji/lokalizacji. Stąd już prosta droga do określenia ryzyka związanego z przetwarzaniem dokumentów i sposobów zabezpieczenia. Prosty przykład ? umowa (dokument) pozbawiona informacji o warunkach handlowych (tajemnica przedsiębiorstwa) może mieć niższy poziom ochrony (wynikający wyłącznie z praw autorskich) niż umowa z tymi informacjami?)

– potem określamy jak są przetwarzane informacje, które chcemy chronić tworząc model organizacji za pomocą BPMN

– analizując ten model możemy ustalić miejsca w modelu przetwarzania, gdzie występuje ryzyko utraty bezpieczeństwa i gdzie należy wdrożyć procedury kontrolne

– wtedy mamy listę procedur do wdrożenia dla konsultanta ISO.

Podsumowując norma narzuca wykonanie analizy organizacyjnej i określenie wymagań na procedury. Niestety załączniki do normy podają przykłady takich procedur, więc uproszczone podejście konsultantów ISO sprowadzałoby się do wdrożenia procedur ?gotowców? według załącznika do normy, z pominięciem zrozumienia co, jak i dlaczego należy chronić.

Oczywiście punktem wyjścia jest dokumentacja klienta, a więc wspomniane dokumenty HR, opisy stanowisk, obowiązków, architektura danych/systemów. Zrozumiałem, że na tej podstawie tworzymy diagram faktów (na podstawie, którego można wygenerować słownik) i dalej analizujemy jak działa organizacja i co należy zabezpieczać.

No i mamy, najprawdopodobniej, gotowy sposób postępowania. Co ciekawe dopiero po przeczytaniu tego listu zdałem sobie sprawę, że w wielu projektach wykonywałem powyższe prace, w różnym zakresie (ja już nie tworzyłem typowych dla ISO procedur) z zupełnie innego powodu: poprawa jakości działania firmy, zanim zostanie wdrożone oprogramowanie. Po co? Żeby nie informatyzować bałaganu. Jak widać, do podnoszenia jakości prowadzi wiele dróg.

(cytaty pochodzą z listu Pana Michała Gładysza)