Zmienny chaos

Wielokrotnie w moich wpisach pojawiał się temat powiązania zmian z różnymi elementami, takimi jak komunikacja, status, zarządzanie ryzykiem, zakres zmiany, luki w procesie itp. Starałem się przytoczyć przykłady, możliwe przyczyny, jak i zastanowić się nad rozwiązaniami. Przykłady łatwo można było sobie wyobrazić. Jednak nigdy nie skupiłem się na częstotliwości zmian w kontekście ich zakresu. Postaram się to dziś nadrobić, wspomagając sieiagramem znalezionym w prezentacji na Uniwersytecie w Eindhoven.

Autor (Wil van der Aalst) diagramu wskazuje w przyjazny sposób jaka jest zależność między częstotliwością wprowadzania zmian oraz wpływem wdrażanych zmian. Na diagramie pojawiają się dwa skróty: BPR oznaczający Business Process Reengineering (więcej o tzw. reinżynierii procesów biznesowych w wpisach z 2008 i 2010r.)  oraz CPI oznaczający Continuous Process Improvement (o czym więcej w jednym z kolejnych wpisów).

Z powyższego diagramu wynika, że jak próbuje się wykonywać zmiany często i mające duży wpływ to wtedy następuje chaos. Jest to bardzo dobre określenie sytuacji, która może nastąpić w przedsiębiorstwie. Możemy mówić o następujących obszarach problemów.

• Ludzie – co mają robić ludzie? Jak postępować? Jakie procedury/regulacje obowiązują w danym momencie? Kto działa wg nowych zasad? Gdzie powinienem zgłaszać problemy? Z kim współpracuję?
• Komunikacja – kiedy i jaką zmianę należy zakomunikować? Kto jest odpowiedzialny? Co, od kiedy i do kiedy obowiązuje? Czy informacja jest jeszcze aktualna?
• Kontrola – jak skontrolować sposób postępowania? Jak sprawdzić czy procesy działają poprawnie? Co jest punktem odniesienia dla obecnego procesu? Czy dana obserwacja jest wynikiem błędnego procesu czy okresu przejściowego?
• Dane – Gdzie są dane? Gdzie powinniśmy przechowywać dokumenty? Kto jest za to odpowiedzialny? Która baza jest źródłem danych a która jest wtórna? Jak wygląda proces przenoszenia, migracji danych?
• Klienci – Którzy są odbiorcami produktów firmy? Jakie informacje uzyskują? Jakie są produkty, za jaką cenę i w jakim czasie mogą pozyskać? Czy otrzymują informację zgodną z komunikacją wewnętrzną? Czy wiedzą czego mogą oczekiwać? Czy sobie radzą w nowym systemie, z nowymi wymogami?

Nad taką sytuacją jest trudno zapanować, dlatego przed wdrożeniem zmian warto przeanalizować wpływ planowanej zmiany oraz termin jej wdrożenia. Mówiąc termin mam na myśli przede wszystkim to, czy zmiana nie jest realizowana zbyt wcześnie po ostatnich zmianach, czy ludziom udało się dostosować do nowych zasad. Nie będę się powtarzać, że ważna jest dwukierunkowa komunikacja (o czym pisałem w swoim artykule). Można wymieniać kolejne obszary, bardziej lub mniej szczegółowe. Jednakże mogą jedynie pokazać jeszcze większy obraz chaosu. Powyższa lista myślę, że jest wystarczająca.

Reklama

Przechadzka po szachownicy

Zadanie:
Odwiedź wszystkie pola szachownicy ruchem skoczka szachowego, odwiedzając każde pole tylko raz, zaczynając z a) rogu, b) jednego z pól środkowych, c) jednego z pól na brzegu, ale nie rogu.

Rozwiązanie:
Osoba (czyli Klient) sterująca skończkiem, zaczynającym z odpowiedniego miejsca zachownicy (czyli Odwiedzający), wykonuje ruchy skoczkiem po polach szachownicy (czyli Struktura Obiektów). W zależności od pola na których się znajdzie (czyli Elemencie Strukury) może wykonać zaakceptowane kroki – wycofać ruch (brak możliwości ruchu dalej, a są pola jeszcze bez odwiedzin), przejść do kolejnego wolnego pola, zakończyć przejście (wszystkie pola zostały odwiedzone). Próbowałem kiedyś to zadanie rozwiązać, zaczynając z różnych miejscach. Później spotkałem się z algorytmem dla programistów, który pozwala na określenie automatyczne takiej ścieżki.

Wzorzec Odwiedzający

Zaznaczone poprzez pogrubienie fragmenty odnoszą się do wzorca projektowego Odwiedzający (ang. Visitor). Przejście po Strukturze odbywa się tak, że najpierw następuje wysłane żądanie do Elementu Struktury z prośbą o akceptację Odwiedzającego. Następuje weryfikacja stanu. W momencie akceptacji, następuje polecenie odwiedzenia Elementu i wykonanie odpowiedniej operacji/polecenia.

Wzorzec jest przydatny, gdy chcemy przejść odpowiednią strukturę i wykonać dla każdego z elementów odpowiednią operację. W powyższym przykładzie obok zmiany stanu następuje wykonanie operacji wyboru kolejnego elementu, przejścia dalej lub wycofania, ponieważ stan wskazuje, że nie dane odwiedziny nie pozwolą na dalsze przejście. W takich sytuacjach zmiana operacji do wykonania powinna się odbywać bez wpływu na wszystkie elementy struktury. Załóżmy, że rozszerzamy strukturę o jeden poziom – np. szachownicę o jeden wiersz na dole, wtedy każdy z elementów struktury, na który ma ta zmiana wpływ, zostanie zmodyfikowany, a pozostałe nie ulegną zmianie.

Proces rozwoju grupy w praktyce

Kiedyś zostałem wybrany do kilkunastoosobowej grupy, przed którą zostało postawione zadanie. Zadanie było zasygnalizowane w kilku zdaniach, bardziej przez ideę, przyszło, że tak powiem z góry struktury organizacyjnej. Otrzymałem zaproszenie na pierwsze spotkanie, na którym miał zostać ustalony plan działania. Jak się okazało, przedstawiony plan wywołał dość długą dyskusję o tym jakie są cele zadania, co należy wykonać, co ma być informacją zwrotną, w jaki sposób ma to zostać zakomunikowane. Po pierwszym spotkaniu, w dyskusjach pojawiało się stwierdzenie, że nie takiej pracy się spodziewali. Myśleliśmy, że spotkania będą bardziej kreatywne, jakaś burza mózgów, pomysły, z kŧórymi będzie można się identyfikować.

W czasie kolejnego spotkania, dyskusja zaczęła się trochę z innego punktu, zaczęto szukać punktów zaczepienia, wątków przeszkadzających, znajdować zarówno proste, jak i skomplikowane rozwiązania. Nadano pewną strukturę spotkaniu, pewne osoby odnalazły role dla siebie, zbierania pomysłów, organizowania ich, próby zebrania ocen. Na koniec udało się przygotować zestaw propozycji, z którymi jako grupa się zgadzaliśmy i jak później się okazało, spotkały się one z bardzo pozytywnym odbiorem inicjatorów wątku.

Czy brzmi to znajomo?

Jakiś czas temu po tym zadaniu, wpadła mi w ręce książka o „Komunikacji w grupie” (autorstwa Peter Hartley). W książce tej przytoczony został proces rozwoju grupy składający się z etapów (autorstwa Tuckmana): Formowanie, Burza, Normowanie oraz Wykonanie. W powyższym opisie można znaleźć fragmenty, które charakteryzują te etapy:

• Formowanie – „… dyskusję o tym jakie są cele zadania, co należy wykonać, co ma b yć informacją zwrotną, w jaki sposób ma to zostać zakomunikowane…”.
• Burza – „… stwierdzenie, że nie takiej pracy się spodziewali… Myśleliśmy, że spotkania będą bardziej kreatywne, jakaś burza mózgów, pomysły, z kŧórymi będzie można się identyfikować…”.
• Normowanie – „…. zaczęto szukać punktów zaczepienia, wątków przeszkadzających, znajdować zarówno proste, jak i skomplikowane rozwiązania….”.
• Wykonanie – „…. Nadano pewną strukturę spotkaniu, pewne osoby odnalazły role dla siebie, zbierania pomysłów, organizowania ich, próby zebrania ocen. Na koniec udało się przygotować zestaw propozycji…”.

Znajomy błąd pełnomocnika

Siedzisz przed monitorem, uruchamiasz przeglądarkę i wpisujesz adres strony internetowej, klikasz enter i zamiast oczekiwanej zawartości strony pojawia się błąd:

„Proxy Error
The proxy server received an invalid response from an upstream server.
The proxy server could not handle the request GET /.
Reason: Error reading from remote server”

Brzmi znajomo? Myślę, że tak. Patrząc na stopień wykorzystania Internetu, połączeń i komunikacji elektronicznej taki błąd może się zdarzyć zawsze. Może to być podczas przeglądania Intranetu na domowym komputerze czy podczas szukania informacji w sieci wewnętrznej, mającej połączenie z Internetem.

Przyczyny błędu mogą być różne i na różnym etapie mogą nastapić – na serwerze sieci na przykład lokalnego dostawcy internetu, na serwerze firmy, który próbuje się dostać do danych wewnątrz, na serwerze obsługującym połączenia między siecią wewnętrzną a Internetem.

Cechą wspólną tych sytuacji jest to, że do pewnego serwera wysyłane jest żądanie, które on próbuje obsłużyć. A następnie ma miejsce komunikacja w drugą stronę. Poniższy przykładowy diagram przedstawia taką sytuację.

Diagram obrazuje także ideę wzorca projektowego Pełnomocnik (ang. proxy), który opiera się na założeniu, że między klientem a rzeczywistym obiektem znajduje się pełnomocnik. Pełnomocnik ten decyduje o udostępnieniu rzeczywistego obiektu (kontroluje dostęp do niego). Może mieć też charakter zabezpieczający, co jak najbardziej można sobie wyobrazić również w powyższych przykładach.

Nazwa „proxy”, pojawiająca się w powyższym komunikacie błędu, nie jest przypadkowa. Serwer zwracający ten błąd wskazuje o braku możliwości realizacji żądania albo o niedostępności rzeczywistego obiektu. Jest pełnomocnikiem zasobów dostępnych na danym serwerze lub w połączonej sieci.