witam, Dnia :25 Michał Gładysz napisał(a): Witam,

Transkrypt

1 Od: "" Do: DW: Data: :12 Temat: RE: Model dziedziny systemu a zmiany organizacyjne Nie mam zastrzeżeń do dokumentu. Moja strona to Nie mam nic przeciwko podaniu mojego imienia i nazwiska. Jest mi niezmiernie miło, że uwzględni Pan moje spostrzeżenie w swojej publikacji. Jestem zobowiązany i pozdrawiam From: IT-Consulting Jarosław Żeliński [mailto:j.zelinski@it-consulting.pl] Sent: Tuesday, June 25, :37 AM To: "" Subject: Re: Model dziedziny systemu a zmiany organizacyjne witam, Na bazie naszej korespondencji powstał załączony wpis do blogu (jeszcze nie opublikowany). Przesyłam Panu do zapoznania się z prośba o ewentualne uwagi i zastrzeżenia, jeżeli nie ma Pan nic przeciwko podam Pana imię i nazwisko (jeżeli ma Pan swoja stronę, to podlinkuję). Dnia :25 napisał(a): Jeszcze raz dziękuję za wszystkie odpowiedzi. From: IT-Consulting Jarosław Żeliński [mailto:j.zelinski@it-consulting.pl] Sent: Thursday, June 06, :07 PM To: "" 1/8

2 Subject: Re: Model dziedziny systemu a zmiany organizacyjne Nie namieszał Pan, jest dokładnie tak jak Pan pisze, interesuje nas dokument biznesowy, zwarty byt jako informacja, można ją klasyfikować (umowa jawna, umowa poufna). Tu małe zaskoczenie będzie być może: powiązane są ze sobą nie dokumenty jako takie (może poza załacznikami), a dokument z czynnością/procesem. Tu przydaje sie diagram faktów: [umowa] - <jest zawierana z> - [kontrahent] legenda: [pojęcie], <fakt>. fakty to zdarzenia dzięki którym łączymy (zaliczamy do zbioru) ze sobą pojęcia (tu dokument z podmiotem kontrahenta). jz P.S. pokusze sie chyba na taki przykład :) Dnia :47 napisał(a): Być może to kwestia nazewnictwa mnie chodzi nie tyle o model danych implikujący modelowanie ERD (bazy danych), ale raczej model informacji, gdzie 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 pozwolic 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 PS. Być może za bardzo namieszałem From: IT-Consulting Jarosław Żeliński [mailto:j.zelinski@it-consulting.pl] Sent: Thursday, June 06, :40 PM 2/8

3 To: "" Subject: Re: Model dziedziny systemu a zmiany organizacyjne Dokładnie tak :), dodam jednak jedną ważną rzecz: nie robi się już modelu danych w brzmieniu "model danych" bo każdy człowiek IT potratuje jako sygnał do modelowania bazy danych co przy obecnej technologii jest błędem. Należy "poprzestać" na specyfikacji dokumentów z opisem każdego: do czego służy (przez czym chroni jego posiadanie) i gdzie jest przetwarzany/przechowywany, a tę informację da "wprost" model procesów biznesowych w BPMN (np. w postaci raportu z analizy i modeli procesów. jz Dnia :51 napisał(a): Bardzo dziękuję za odpowiedź. 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 (powinien pomóc w tym model danych przetwarzanych przez organizację) to definiuje norma - 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ć. From: IT-Consulting Jarosław Żeliński [mailto:j.zelinski@it-consulting.pl] Sent: Tuesday, June 04, :56 AM To: "" 3/8

4 Subject: Re: Model dziedziny systemu a zmiany organizacyjne Dnia :04 napisał(a): Od lat śledzę Pana blog i osiągniecia 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? 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 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? 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?) i góry dziękuję za odpowiedź Witam Niewprost odpowiedzi sam Pan już udzielił :) Miewam i takie projektu (ale szczegóły tych norm robią juz inni). Kontynuując Pana "Przenosząc to na grunt własnym problemów zawodowych..." słusznie: 1. Robimy analize problemu i jej wynik opisujemy jako BMM 2. Modelujemy organizację (procesy BPMN) i /8

5 uzupełniamy ten modele o skojarzone z rolami opisy obowiązków itp. (ja mapuje tu dokumentację HR lub daję rekomendacje do jej uzupełnienia). Wymagania na procedury to wskazanie wszystkich tych ryzykownych miejsc, które bez procedur rodzą ryzyko pogorszenia jakości lub ciągłości działania organizacji, treśc procedury wynika z tego co chcemy "utrwalić" lub uczynić powtarzalnym (w mojej nomenklaturze procedura to scenariusz czynności.procesu). To co Pan napisał: lista ról, umiejętności każdej "roli" to dokumenty HR, lista procedur dla dalej roli, wynika wprost z modelu procesów. Odpowiednikiem dziedziny będzie specyfikacja reguł biznesowych, czyli wewnętrznych ogólnych zasad. Diagramłów klas jako modelu dziedziny nie robię na tym poziomie, ale słownik kluczowych pojęć i model (diagram) faktów od pewnego czasu tak (diagram raczej dla siebie dlla kontroli), bo to - słownik - pozwala na upilnowanie jednoznaczności i spójności całej dokumentacji ISO i poprzedzającej dokumentacji analizy wymagań na te procedury. Mile mnie Pan zaskoczył, bo bardzo rzadko spotykam się z poprzedzaniem wdrażania norm ISO analizami "czego od oczekujemy i po co ". Dodam, że projektu programistyczne to nie 100% moich projektów :), są także te czysto zarządcze i organizacyjne. Chyba nawet pokuszę się o taki przykład na blogu :) -- Jarosław Żeliński, 5/8

6 Tel. kom.: , Adres korespondencyjny: Jarosław Żeliński IT-Consulting Atrium Centrum ul. Jana Pawła II Warszawa 6/8

7 -- Jarosław Żeliński, Tel. kom.: , Adres korespondencyjny: Jarosław Żeliński IT-Consulting Atrium Centrum ul. Jana Pawła II Warszawa 7/8

8 -- Jarosław Żeliński, Tel. kom.: , Adres korespondencyjny: Jarosław Żeliński IT-Consulting Atrium Centrum ul. Jana Pawła II Warszawa -- Jarosław Żeliński, Tel. kom.: , Adres korespondencyjny: Jarosław Żeliński IT-Consulting Atrium Centrum ul. Jana Pawła II Warszawa 8/8