Konteksty

Zarys metodyki wdrożenia ochrony danych

Czy to z uwagi na wymogi prawne, czy też z potrzeby zachowania tajemnicy, Instytucje i podmioty gospodarcze w pewnym momencie stają przed wyzwaniem jakim jest budowa bezpiecznego środowiska do przetwarzania danych.

Niniejszy artykuł ma za zadanie przedstawić ogólny zarys takiej metodyki ze szczególnym uwzględnieniem problematyki ochrony danych osobowych.

 

Na wstępie należy podkreślić, że:

  1. 100% bezpieczeństwo danych jest świętym Graalem specjalistów. Wszyscy go szukają, ale poszukiwania wciąż trwają;
  2. nakłady na zabezpieczanie danych muszą być skorelowane z ich wartością oraz sytuacją w jakiej podmiot je przetwarzający się znajduje;
  3. ochrona danych jest procesem ciągłym. Nie jest to jednorazowa akcja, ale działalność systematyczna wymagająca stałego nakładu pracy.

Poczyniwszy te zastrzeżenia nie opuszczamy jednak rąk i staramy się osiągnąć to co możliwe w ramach posiadanych możliwości, aby ochronić to co uważamy za ważne. Szczególnie, że zgodnie z zasadą Vilfreda Pareto 80% efektu osiągniemy dzięki 20% nakładom.

Wydaje się, że obserwując proces zabezpieczania danych można zobaczyć w nim 8 działań - dla potrzeb narracyjnych moglibyśmy je nazwać krokami. Prześledźmy je od początku zakładając że problematyką ochrony danych zajmujemy się po raz pierwszy w podmiocie, który właśnie rozpoczął swoją działalność.

 

Krok 1 - Co chronimy?

No przecież dane! A może chodzi nawet o dane osobowe, których rozumienie precyzują określone akty prawne.

Jeśli jednak zastanowimy się trochę dłużej, to może wcale nie chodzi nam o dane, może raczej o informacje, które można z tych danych pozyskać? Z pewnością zauważy ktoś, że to zbędne rozróżnienie i szkoda czasu na teoretyzowanie. Ale czy przypadkiem język nas nie ogranicza? Ostatnimi laty "dane" zostały silnie skojarzone ze światem zer i jedynek - jeśli ktoś stracił dane to znaczy nie ma kopii i "padł" mu komputer. Takie rozumienie danych może zawęzić naszą wrażliwość nie tylko dlatego, że zapomnimy o dokumentach papierowych, ale możemy usnąć poza zakres naszej uwagi również inne obszary, gdzie znajduje się informacja, która powinna podlegać ochronie. Tym samym mogłoby się okazać, że a) my straciliśmy coś, b) ktoś inny stracił lub zyskał w sposób nieuprawniony.

Więc może tak naprawdę nie chronimy informacji tylko chronimy wartości? I dopiero w tym kontekście - uwzględniając wartości możemy przystąpić do sporządzania listy tego co będziemy chronić. Warto podkreślić, że nie możemy ograniczyć się wyłącznie do naszych wartości - musimy pomyśleć również o innych. Zmusza nas do tego ludzka solidarność (nie rób drugiemu co tobie nie miłe) lub obowiązujące prawo (dura lex sed lex) - tak jak ma to miejsce w przypadku ochrony danych osobowych.

 

Opracowanie listy zasobów chronionych ma 3 podstawowe zadania.

  1. Wykazać relacje pomiędzy zasobami a celami biznesowymi, obowiązkami statutowymi czy wynikającymi z legislatury
  2. Wykazać listę zasobów niezbędnych do działania, wymagających utrzymania i ochrony - punkt wyjścia dla kolejnego kroku
  3. Wskazać osoby odpowiedzialne za utrzymanie i bezpieczeństwo zasobu.

W praktyce sporządzenie listy zasobów chronionych jest zadaniem trudnym i powinno uwzględniać różnorakie punkty widzenia. Inną listę sporządzi prezes, inna informatyk, jeszcze inną księgowy. Faktycznie pełna lista wartości chronionych powinna obejmować wszystkie aktywa jednostki (nie te z bilansu - te z normy . My trzymajmy się jednak zagadnień związanych z ochroną danych.

 

Warto jest strukturalizować zasoby chronione poprzez powiązanie ich z celem ich istnienia. Można posłużyć się różnymi kryteriami podziału. Inne kryteria przyjmiemy planując ochronę informacji finansowych w spółce akcyjnej, a inne ochronę danych osobowych. Dobrym punktem wyjścia są zapisy jakie powinniśmy znaleźć w podstawowych dokumentach jednostki, w statutach, misji czy strategii rozwoju, mogą to być długoterminowe cele MBO, elementy polityki informacyjnej, obowiązujące podmiot przepisy czy też nawet umowy, mogą to być też podstawowe procesy jednostki. Nie jest natomiast dobrym rozwiązaniem posługiwanie się strukturą organizacyjną.

W przypadku ochrony danych osobowych wydaje się, że powinniśmy wyjść od celów, dla których przetwarzamy dane; zdekomponować je na zbiory a te na podstawowe zasoby niezbędne do ich utrzymania. Mogłoby to wyglądać np tak:

l.p. cel przetwarzania danych osobowych zbiór danych zasób chroniony osoba odpowiedzialna
1 obsługa sprzedaży

dokumenty sprzedaży

teczki z fakturami sprzedawców

kierownik działu sprzedaży

2    

dokumenty księgowe

główny księgowy

3    

archiwum księgowe

główny księgowy
4   korespondencja papierowa z klientem akta kierownika działu sprzedaży kierownik działu sprzedaży
5   system informatyczny Magazyn i Sprzedaż serwerownia kierownik IT

6

    stacje robocze działu sprzedaży kierownik IT
7    

sejf na backup

kierownik IT
8   system informatyczny e-Sklep usługa utrzymania sklepu  
9     komputery klienckie VPN kierownik IT
10     łącze do Internetu kierownik IT
11     sejf na backup kierownik IT
12   system informatyczny FK serwerownia (5) kierownik IT
13     stacje robocze księgowości kierownik IT
14     sejf na backup (7) kierownik IT
15 obsługa zaopatrzenia dokumenty zakupu teczki z fakturami zaopatrzeniowców kierownik działu sprzedaży 
16     dokumenty księgowe (2) główny księgowy
17     archiwum księgowe (3) główny księgowy
18   korespondencja papierowa z dostawcami akta kierownika działu zaopatrzenia kierownik działu zaopatrzenia
19   system informatyczny FK Serwerownia (5) kierownik IT 
20     stacje robocze księgowości (13) kierownik IT 
21     sejf na backup (7) kierownik IT 

Z uwagi na aspekt dydaktyczny dołączyliśmy do przykładu jeszcze jeden cel przetwarzania - obsługę zaopatrzenia. Ma to na celu zobrazowanie relacji jakie zachodzą pomiędzy poszczególnymi poziomami klasyfikacyjnymi. Zwróćmy uwagę, że ten sam system informatyczny FK służy obsłudze obu celów, podobnie jak w tej samej serwerowni zlokalizowane są różne zbiory. Cele mogą być realizowane w wielu zbiorach a zbiory mogą realizować wiele celów. Podobnie jest z relacją między zbiorem a zasobem. Są to tzw. relacje wiele do wielu - nie są one wygodne w obsłudze papierowej - do ich obsługi dobrze jest skorzystać ze wsparcia narzędzia informatycznego.

Sporządzona lista nie może być zbyt ogólna, nie może być też zbyt szczegółowa, jest to jednak zależne od potrzeb. Np. w przypadku stacji roboczych można byłyby wydzielić komputery stacjonarne oraz notebooki. Podobnie serwerownia z pozycji 5 mogłaby być podzielona na drobniejsze składowe.

 

Krok 2 - Szacowanie ryzyka

Dysponując listą zasobów chronionych opracowaną w kroku 1 czas oszacować ryzyka z nimi powiązane. W tym celu najpierw staramy się wymyślić ryzyka związane z każdym zasobem. Można to zrobić opierając się na wiedzy ekspertów dziedzinowych, ale czasami warto skorzystać z techniki burzy mózgów. Warunkiem udanej burzy mózgów będzie brak wśród uczestników ekspertów dziedzinowych, którzy samą obecnością zablokowali by inwencję pozostałych. Czasami efekty burzy mózgów zaskakują świeżością spojrzenia, której brakuje osobom z dużym doświadczeniem w danej dziedzinie.

 

Zobaczmy jak mogłoby to wyglądać na przykładzie serwerowni?

l.p. Zasób Ryzyko Opis Osoby kompetentne
  Serwerownia Utrata i przerwy w zasilaniu elektrycznym

Może spowodować zatrzymanie działania sprzętu IT

szef obsługi technicznej

1   Awaria systemu klimatyzacji Może doprowadzić do niekontrolowanych wyłączeń sprzętu IT a nawet do awarii szef obsługi technicznej
2   Awaria sprzętu IT Zatrzymane zostaną usługi świadczone przez dany sprzęt kierownik działu IT
3   Działania ekip remontowo–budowlanych Może dojść do zadymienia, zapylenia, drgań lub uszkodzeń mechanizcnych szef obsługi technicznej
4   Utrata łączności z Internetem Brak dostępu do usług świadczonych przez podmiot w internecie, brak dostępu do serwerów czasu, DNS kierownik działu IT
5   Zalanie wodą Uszkodzenie sprzętu IT

szef obsługi technicznej,

kierownik działu IT

 

Nie jest to oczywiście lista kompletna, ale nie to jest celem tego artykułu.

Mając listę ryzyk możemy przystąpić do ich szacowania. W tym celu konieczne jest określenie prawdopodobieństwa wystąpienia określonego ryzyka oraz skutki jakie jego wystąpienie będzie miało dla organizacji. Oceny ryzyka dokonują generalnie osoby kompetentne.

 

W tym celu trzeba przyjąć jakieś skale liczbową i przypisać każdemu ryzyku odpowiednie liczby.

Wystarczająca w większości przypadków oraz minimalna dla skali prawdopodobieństwa wydaje się skala trójwartościowa:

1 mało prawdopodobne zdarzenie
2 sporadycznie się zdarza
3 bardzo prawdopodobne, że się zdarzy

Dla oceny skutków możemy również przyjąć skalę 3 wartościową

1 mało dotkliwe
2 średnio dotkliwe
3 bardzo dotkliwe

Oczywiście nic nie stoi na przeszkodzie, aby zastosować np 4 lub 5 wartości - ważne aby osoby korzystające z przyjętej skali nie miały kłopotu z jej stosowaniem. Należy więc opisać co to znaczy "dotkliwość" - być może innym językiem w zależności od specjalności osoby dokonującej oceny (inaczej dla księgowego a inaczej dla informatyka) i z całą pewnością w kontekście konkretnego ADO. Przykładowo strata miliona złotych może być zarówno ostatnim epizodem dla przedsiębiorstwa jak i pozostać nieomalże niezauważona w związku z dużą rentownością działalności.

Szacowanie, które nie stratyfikuje wyników (wszystko jest średnie lub wszystko jest duże) wymaga przemyślenia - być może należy zmienić skalę - np bez wartości środkowych by zmusić osobę odpowiedzialną do bardziej zdecydowanych wyborów. W pewnych działalnościach jednak może być uzasadnione.

 

Z przyjętego prawdopodobieństwa i przyjętych skutków wywodzimy wartość ryzyka. Możemy zrobić to nieomalże automatycznie korzystając np z takiej tabelki:

  prawdopodobieństwo
dotkliwość 1 - małe 2 średnie 3 duże
1 - mała 1 ryzyko bardzo małe 2 ryzyko małe 3 ryzyko średnie
2 - średnia  2 ryzyko małe 3 ryzyko średnie 4 ryzyko duże
3 - duża 3 ryzyko średnie 4 ryzyko duże 5 ryzyko bardzo duże

 

Zawsze można zmienić wartość ryzyka - powinno to jednak być uzasadnione. Podkreślmy, że są to bardzo pracochłonne i czasochłonne prace i być może przy pierwszym podejściu należy ograniczyć się do analizy zagadnień kluczowych dla naszej działalności. Na szczegóły przyjdzie czas podczas kolejnej iteracji - "nie od razu Kraków zbudowano".

 

Teraz przyszedł czas na akceptację ryzyka. Akceptacji dokonuje ktoś o z samych szczytów instytucji - najlepiej prezes, zarząd lub osoby specjalnie do tego delegowane.

Akceptacja powinna też zostać wyrażona w jakiejś skali, ale oczywiście z odpowiednim komentarzem, np.

1 zdarzenie dopuszczalne, akceptowane są skutki jego materializacji
2 staramy się nie dopuścić do wystąpienia, w ramach zwykłej działalności jednostki
3 staramy się nie dopuścić do wystąpienia, podejmowane są działania mające łagodzić skutki ewentualnej materializacji zagrożenia podlegające raportowaniu
4 zdarzenie niedopuszczalne, powoływane są dedykowane projekty z wydzielonym budżetem mające na celu uniknięcie zdarzenia

Produkt końcowy - tabelka zbierająca zidentyfikowane ryzyka, musi być zaakceptowana przez zarząd / władze i od tego momentu staje się punktem wyjścia do dalszych działań - opracowania polityki bezpieczeństwa.

 

 Krok 3 - Opracowanie polityki bezpieczeństwa

W istocie krok najtrudniejszy. O ile dwa poprzednie kroki są krokami analitycznymi, w tym musimy dokonać syntezy wiedzy o organizacji, wymogów prawnych, zagadnień technicznych oraz doświadczenia w opracowywaniu polityk bezpieczeństwa. Punktem wyjścia jest oczywiście informacje nabyte w w poprzednich krokach. Wiedząc co i znając priorytety możemy zastanowić się JAK będziemy chronić nasze wartości w sposób odpowiedni do naszych możliwości. Uzasadnione będzie skorzystanie z wiedzy ekspertów dziedzinowych w szczególności - mówimy przecież o danych - informatyków i to różnych specjalności..

 

Na początek warto zastanowić się czym powinna być polityka. Polityka to plan wszystkich działań dotyczących ochrony danych wraz ze wskazaniem osób odpowiedzialnych za konkretne obszary tej mapy. Polityka powinna odpowiadać na pytania ogólne, które w kontekście przetwarzania danych mogą się pojawić i powinna wskazywać osoby kompetentne do udzielenia odpowiedzi szczegółowych. 

Może oczywiście istnieć polityka nie spisana. Jednak zgódźmy się, że sprawdzić może się tylko w zespołach, w których każda sprawa trafia do szefa i w zasadzie można ją ograniczyć do dwóch punktów: 1) szef decyduje oraz 2) szef decyduje w każdym wypadku. Przyjmijmy więc, że polityka jest dokumentem spisanym.

Może też istnieć polityka spisana i faktycznie realizowana. Tym przypadkiem nie będziemy się tu jednak zajmować zakładając, że ochroną danych chcemy zająć się na poważnie.

Polityka powinna być dokumentem modułowym zawierającym część stałą oraz załączniki. Uchroni to nas przed nowelizacją całego dokumentu w przypadku zmian o charakterze ilościowym (np zmiany w obszarze przetwarzania danych).

Nic natomiast nie uchroni nas przed zmianami w polityce mającymi charakter jakościowy i błędem byłoby zakładanie, że polityka do dokument niezmienny - przecież "za chwilę" krok trzeci będziemy powtarzać.

 

 

Główne  składowe dokumentu oraz efekty kolejnych etapów jego przygotowania to:

  1. określenie danych podlegających ochronie - korzystamy z zasadniczych wyników z kroku 1 ;
  2. analiza zagrożeń w pigułce - podsumowanie kluczowych wyników z kroku 2;
  3. wskazanie osób odpowiedzialnych za przetwarzane danych oraz wdrożenie polityki ich ochrony;
  4. wskazanie mechanizmu nadawania uprawnień do przetwarzania danych;
  5. określenie ogólnych zasad organizacyjnych dotyczących ochrony danych;
  6. określenie organizacyjnych i technicznych środków służących bezpieczeństwu danych;
  7. wskazanie postępowania w przypadku incydentu;
  8. opis dokumentacji przetwarzania danych;
  9. opracowanie słownika wykorzystanej terminologii;
  10. przygotowanie preambuły.

Nie ukrywajmy zasadnicza polityka kryje się w punktach 5-6 i właśnie o nich w tym artykule możemy najmniej powiedzieć  - nie da się opisać przygotowania polityki bez odniesień do konkretnej sytuacji. Skupmy się więc na uwagach ogólnych.

 

ad 1 i 2

W samym dokumencie zamieszczamy opis przyjętej metodyki oraz zasady aktualizacji. Warto opisać też procedurę zgłaszania nowych potrzeb informacyjnych. Właściwy opis zasobów chronionych oraz analizę zagrożeń przenosimy w całości lub części do załączników.

 

ad 3

W tej części polityki staramy się włączyć ochronę danych w strukturę zarządzania instytucją.

Wskazujemy konkretne stanowiska odpowiedzialne za bezpieczeństwo danych, w szczególności powołujemy wydzielone stanowiska i określamy zakres ich kompetencji (przykładem może być ABI / IOD).

 

ad 4

W tej części określamy kto decyduje o dostępie do danych, oraz sposób i warunki na jakich ktoś uzyskuje dostęp do informacji, ze szczególnym uwzględnieniem dostępu do systemów informatycznych. Często pisemna forma upoważnienia wydaje się rozsądna. Aby nie mnożyć dokumentów rozbudowa i poważne potraktowanie upoważnień do przetwarzania danych osobowych wydaje się dobrą koncepcją.

 

ad 5

W tej części polityki określamy ogólne zasady organizacyjne dotyczące ochrony danych. Wydaje się, ze obowiązkowe klauzule dotyczą:

 

ad 6

Najobszerniejsza część polityki, zawierająca najwięcej odniesień do konkretnej sytuacji. Warto wydzielić kilka obszarów, w ramach których systematyzujemy zagadnienia. Podstawowe to:

W samej polityce zamieszczamy tylko kluczowe wytyczne, starając się szczegóły przenieść do załączników. Każdy załącznik musi mieć jasno określone procedury aktualizacji oraz wskazanie stanowiska odpowiedzialnego za jego aktualizację.

 

ad 7

Jedna z bardziej bolesnych spraw dla osób zajmujących się bezpieczeństwem informacji jest sytuacja kiedy zdarzenia wpływające na bezpieczeństwo danych (np zgubienie nośnika danych) są skrzętnie "zamiatane pod dywan".

Wszyscy mamy tendencję do takiego postępowania ponieważ często wiąże się to z przekroczeniem jakiejś regulacji i może mieć to dla nas negatywne konsekwencje. Dlatego podstawą funkcjonowania systemu wczesnego ostrzegania  a jednocześnie mechanizmu pozwalającego na doskonalenie naszej polityki odnośnie bezpieczeństwa danych jest poczucie bezpieczeństwa pracowników. W polityce bezpieczeństwa nie można pominąć opisu obsługi incydentów.

W praktyce warto jest wdrożyć elektroniczny system służący do rejestracji zdarzeń. W instytucjach stosujący elektroniczny obieg dokumentów po prostu dodać kolejną sprawę, której bieg może nadać każdy upoważniony do przetwarzania danych osobowych a w szczególnych przypadkach również osoba, której dane przetwarzamy. W wersji minimum być może wystarczy odrębny adres e-mail.

 

ad 8. 

W tej części polityki dokonujemy opisu i wskazania dokumentów i rejestrów dotyczących ochrony informacji, określamy osoby odpowiedzialne za utrzymanie tej dokumentacji. Warto tu posłużyć się elektronicznym repozytorium przechowującym wersje składowanych dokumentów. Przy okazji warto przygotować listę dokumentów, które powinny mieć odniesienie do opracowywanej polityki - np regulamin pracy i zadbać o ich nowelizację.

 

ad 9.

Słowniczek terminów - pamiętajmy że z polityka mogą zapoznawać się osoby o różnych specjalnościach.

 

ad 10

Polityka musi przekazywać odbiorcy intencję władz w sprawie ochrony danych. Powinno być zawarte w preambule.polityki.

 

Krok 4 - Budowa rozwiązań technicznych

W tym kroku nie tylko budujemy czy modernizujemy infrastrukturę IT, ale też wstawiamy odpowiednie drzwi i zamki. Wszystkie działania w tym punkcie powinny być oczywiście ekonomicznie uzasadnione, dopasowane do wartości, które chronimy, zgodne z przyjętą polityką bezpieczeństwa.

Rozwiązania techniczne można widzieć w trzech obszarach:

  1. utrzymania danych
  2. zabezpieczeń fizycznych
  3. dostępu do danych

ad 1

Obszar utrzymania danych obejmuje techniczne środki niezbędne do przechowywania danych. Są to wszelkiego rodzaju nośniki informacji zarówno klasyczne - papier - jak i elektroniczne (dyski, taśmy) jak i urządzenia je obsługujące. Na przykład teczki, segregatory, szafy, sejfy itp. - w przypadku dokumentów oraz macierze dyskowe, biblioteki taśmowe, serwery i oprogramowanie w przypadku świata IT. Nie bez znaczenia może być rodzaj papieru i nie bez znaczenia jakość nośnika magnetycznego jeśli zamierzamy przechować coś przez dłuższy czas. W przypadku przetwarzania danych w systemach informatycznych obszar utrzymania to praktycznie 1/3 serwerowni. 

Jeśli polityka zakłada ciągłość pracy systemów IT warto jest budować infrastrukturę gdzie poszczególne elementy są zdublowane. Jeśli jest taka możliwość najlepiej budować lustrzane serwerownie w dwóch geograficznie różnych lokalizacjach. Jeśli serwerownia jest tylko jedna, to przynajmniej kopie zapasowe muszą być przechowywane w innej lokalizacji.

 

ad 2

Wiedząc jakie środki techniczne są niezbędne do utrzymania danych konieczne jest zbudowanie dla nich bezpiecznego środowiska. Niezbędne są odpowiednie pomieszczenia i infrastruktura zabezpieczająca warunki przetwarzania. Jednak nie tylko ściany i drzwi, odpowiednia temperatura, wilgotność i gwarantowane zasilanie, ale również środki kontroli dostępu do nośników oraz infrastruktury.

 

ad 3

Dostęp do tradycyjnych dokumentów organizują nam właściwe procedury organizacyjne. Dostęp do danych elektronicznych z reguły otrzymujemy po przez sieć i oprogramowanie zawiadujące uprawnieniami, choć możliwe jest też powielenie informacji i otrzymanie jej na nośniku elektronicznym.

 

Krok 5 - Opracowanie rozwiązań organizacyjnych

Bez włączenia zasad ochrony danych do zwykłych procesów instytucji i włączenie w proces ochrony wszystkich jej pracowników nie można liczyć na bezpieczeństwo danych. Szczególnie istotne jest wskazanie ryzyk oraz sposobów ich unikania w momentach kiedy może dojść do materializacji ryzyka w określonych krokach procesu.

Jeśli organizacja pracy nie przebiega procesowo i nie ma woli do zmiany tego stanu, pozostaje nam czerpać z doświadczeń doświadczonych uczestników procesu - najczęściej nie mają oni problemu ze wskazaniem sytuacji jakie powinny być w zmienione w związku z unikaniem konkretnych zagrożeń.

 

Rozwiązania organizacyjne można podzielić na:

  1. związane ze stosowaniem rozwiązań technicznych;
  2. proceduralne.

W ramach tych pierwszych często mamy związane ręce wymogami technicznymi. Np logowanie do systemu za pomocą karty procesorowej związane jest z koniecznością jej przygotowania i wydania, co pociąga za sobą określone procedury organizacyjne. Gdzie mamy do czynienia z techniką możliwe jest wykorzystanie technik poka yoke, co w sposób drastyczny może wyeliminować drobne błędy - wiąże się jednak z dodatkowymi kosztami. Przykładem może być zamek w którym nie da się wyjąć klucza jeśli zamek nie jest prawidłowo zamknięty.

 

W rozwiązaniach proceduralnych modyfikujemy  sposób postępowania, np. zmieniamy obieg spraw czy dokumentów.

 

Trzeba tu podkreślić, że wzrost bezpieczeństwa z reguły wiąże się ze wzrostem uciążliwości - coś co dotąd robiliśmy prościej, teraz robimy w sposób bardziej złożony, często bardziej pracochłonny. Stąd czasami mniej złożone i mniej bezpieczne procedury mogą w ogólnym rozrachunku być bardzie bezpieczne niż procedury z założenia bezpieczniejsze. Przykładem może być pomysł losowego generowania haseł. Kto nie zapisze hasła, które wygląda jak kawałem kodu maszynowego? 

 

Krok 6 - Przeszkolenie personelu

Powinno dotyczyć zarówno znajomości zasad przetwarzania danych, obsługi rozwiązań technicznych,  jak i zmian w procesach biznesowych. Pomocne mogą okazać się narzędzia dydaktyki zdalnej, szczególnie w dużych lub rozproszonych geograficznie podmiotach.

Krok 7 - Wdrożenie rozwiązania

Najlepiej w formie projektów - w końcu zarządzamy zmianą, którą powinniśmy zaplanować i nadzorować jej realizację. Poszczególne zadania projektowe powinny być powierzone konkretnym osobom a ich wykonanie potwierdzone.

 

Krok 8 - Audyt skuteczności rozwiązania

Bez sprawdzenia jak opracowane i wdrożone rozwiązanie funkcjonuje w praktyce nie dowiemy się czy nasze działanie odniosło pożądany skutek.