The Other Way©

Data: 2014-01-27
Autor: Sebastian Konkol
The Other Way ©

W ramach zeszłorocznych remanentów zapowiadałem jeszcze jeden punkt widzenia w temacie Open Source. Tym razem udało mi się rzeczywiście „wkrótce”. Rzecz o hybrydzie, która z jednej strony jest Open Source, a z drugiej – oprogramowaniem licencjonowanym, czyli Commercial Open Source. Nie w tym jednak rzecz, że jest tańsze – rzecz w tym, że otwiera nowe możliwości realizacji projektów informatycznych.

Wdrożenie każdego systemu informatycznego wprowadza zmianę w sposobie działania firmy. Czasami zmiana jest taka, jaka została założona – wszak systemy informatyczne wdraża się właśnie po to, aby wprowadzić zmianę (lepiej, szybciej, taniej, dokładniej, mniej ryzykownie, z mniejszym nakładem wysiłku, …). Czasami, kiedy system wdrażany jest dla wdrożenia, zmiana jest nieprzewidywalna – ale także jest. Najczęściej rzeczywista zmiana – będąca agregacją chęci, wysiłków, zaniechań i decyzyjności – objawia się mieszanką tego, co zamierzone, z tym, co „tak wyszło”. Zmiana jednak zawsze występuje.

Zasięg zmiany – innymi słowy, konsekwencje wdrożenia systemu – nie są do końca przewidywalne. To fascynujące, że kultura organizacyjna firmy nigdy nie jest przedmiotem analizy przedwdrożeniowej. Analizuje się wymagania, procesy, dane i co tam jeszcze, ale nie grunt, na jaki trafi nowy system. Oznacza to, że nie wiadomo, jak firma przyjmie nowy system i jak postanowi z niego korzystać. Może bowiem z niego wyciągać znacznie więcej, niż ktokolwiek w firmie byłby skłonny pozwolić, lub wkładać do niego znacznie mniej, niż ktokolwiek w firmie byłby zdolny narzucić. Na tym polega siła społeczna i nikt nie będzie winny takiej sytuacji, kiedy już się ujawni.

System wkracza na obszary, które dotąd jakoś funkcjonowały. Po wdrożeniu – by design – będą funkcjonować inaczej, a to jest „najazd” na ludzkie przyzwyczajenia i tworzy warunki dla powstania lęków przed dostosowaniem się do nowej formuły pracy. I nic się nie da z tym zrobić – taka jest cecha gatunkowa Homo sapiens. Im większy system, tym poważniejsza zmiana. W przypadku części klas systemów (np. CRM, ERP, zarządzanie sprzedażą, SCM) zmiana nie tyle odbywa się na tle kultury organizacyjnej firmy, co bezpośrednio ją dotyka, próbując dokonać zmiany w jej postaci. Piszę „próbując”, bo kultura organizacyjna to agregat intencji, działań i zaniechań wszystkich uczestników życia firmowego. Można jej wręcz nadać cechy inteligencji – ona się zmieni tak, jak uzna za stosowne, nigdy zaś by design.

W takich sytuacjach wdrożenie systemu jest eksperymentem – zmiana, jaka ostatecznie będzie efektem wdrożenia nie jest określona (nawet, gdyby było to przedmiotem analiz, choć zwykle nie jest). Nie wiadomo bowiem, jaki będzie efekt końcowy, jak zmieni się firma po wdrożeniu, jak zmianę przyjmie cała organizacja. Krótko mówiąc, czy filozofia działania organizacji ulegnie przekształceniu na tyle, aby dopasować się do logiki działania systemu.

Eksperyment to nie jest coś złego, choć w wielu firmach tak właśnie jest postrzegany. Co więcej, teoria i praktyka wdrożeń systemów informatycznych dopracowała się już metod działania w takich projektach. Odpowiedzią na „eksperyment” jest „adaptacyjność” – krótkie cykle wdrożeń, małe przyrosty funkcjonalne, szybki feedback, niskie koszty pojedynczego cyklu. Wdrażamy coś małego, co wpływa na zmianę przyzwyczajeń i obowiązujących praktyk, ukierunkowując te zmiany. I patrzymy, jakie są efekty – co zadziałało, co trzeba dopracować. A wdrożony kawałek wywiera ciągły wpływ na kierunek przemian organizacji.

Tytułowe “The OtherWay©” jest podejściem adaptacyjnym do wdrażania systemów informatycznych. Jego kluczowym elementem jest wykorzystanie dostępnego oprogramowania Open Source. Podstawowe pryncypia tej metody są następujące:

  • Zmiana ma być wspomagana przez etapy wdrożenia systemu. Zrozumienie zasięgu wpływu na kulturę organizacyjną jest wyznacznikiem dekompozycji wdrożenia na przyrosty funkcjonalne, które ukierunkowują przeprowadzenie zmiany. Zaczynamy z czymś najprostszym, co wdrażane jest w istotnym, ale nie krytycznym obszarze działania firmy. Kolejne przyrosty określane są tak, aby korygować niepożądane zmiany w kulturze organizacyjnej.
  • Plan wdrożenia to nie religia. Sekwencja, zakres, czas realizacji kolejnych przyrostów podporządkowane są ocenie osiąganych efektów, a nie pierwotnemu planowi, stworzonemu – siłą rzeczy – w warunkach niezrozumienia zdolności organizacji do dostosowania się do nowej logiki działania.
  • Zasięg wdrożenia ma przyrastać. Nie wolno poddać się kuszącej perspektywie Big Bang. Firma nie zmieni się w oczekiwanym kierunku z powodu wdrożenia systemu. Im większa zmiana, tym większy opór i tym większe prawdopodobieństwo odrzucenia systemu przez organizację.
  • Każdy przyrost to eksperyment. Eksperyment może się nie udać, a poniesione koszty zostaną utopione. Lepiej wycofać się z przyrostu, który nie pomaga zmienić organizacji, niż tkwić w pacie i ponosić koszty odrzucenia systemu.
  • Wymagania to sugestie, nie kontrakt. Wszystkie wymagania na system, jakie składają wymagający, mówią podprogowo „wdrażajcie co chcecie, byle u nas pozostało tak samo”. Kultura organizacji (niemalże wszystkich) nastawiona jest na trwanie, a nie na zmianę. Każda zmiana jest minimalizowana. Dużo wysiłku wymaga ustalenie jak dojść do zmiany, bez jej narzucania.

Oczywiście, że takie podejście jest trudne, jeśli porównać je do typowego wdrożenia „wodospadowego” (Waterfall). Różnica jest jednak dość fundamentalna – „wodospad” nie przejmuje się sukcesem wdrożenia, tylko realizuje Plan, często sformułowany przed rokiem lub nawet kilkoma laty, bez posiadania nawet promila wiedzy o tym, jak system zostanie przez firmę przyjęty. Powyższe podejście wbudowuje dbałość o sukces wdrożenia w samą metodę działania. To sukces jest trudny, nie metoda. Dołączając ten aspekt do równania, „wodospad” powinien być odrzucony w przedbiegach.

Podejście to przetestowałem w dwóch przypadkach wdrożeń systemów CRM, w obu posługując się systemem Open Source jako katalizatorem zmiany. W dużym uproszczeniu, filozofia wygląda następująco:

  • Weźmy system wymaganej klasy (np. CRM) dostępny na którejś z licencji Open Source, które posiada także wersje komercyjne (tzw. Commercial Open Source) i wdróżmy go – dokładnie takim, jakim jest, bez żadnych zmian – w małym istotnym ale nie krytycznym obszarze (np. kontakt z jednym z segmentów klientów).
  • Pozwólmy na działania w tym systemie, żeby użytkownicy się z nim obyli. Ustalmy, jakie zmiany (już odnosząc się do nowego systemu) należy wprowadzić, żeby coś poprawić. Nadajmy tym wymaganiom kierunek pożądanej zmiany w organizacji.
  • Uzyskajmy w ten sposób zadowolonych użytkowników, którzy pomogą nam szerzyć dobrą nowinę o systemie w firmie. Zaindukujmy takie myślenie u innych grup i wybierzmy kolejny obszar do wdrożenia.
  • Zakres zmian analizujmy pod kątem wykonalności. Korzystajmy z dostępnych dodatków (plugin, komponent), aby realizować wymagania – nadal w trybie tak, jak jest dostępne.
  • Zasięg wdrożenia oceniajmy pod kątem ryzyka, czy jeszcze możemy działać na Open Source, czy powinniśmy już mieć poważniejsze wsparcie – przejść na Commercial open Source.
  • Obserwujmy zachodzącą zmianę i korygujmy jej kierunek w kolejnych przyrostach.

Wynikiem jest zwykle system bez istotnych zmian realizowanych „pod straszliwie specyficzne potrzeby organizacji”. Efektem jest przeprowadzona ewolucyjnie zmiana, z minimalnym oporem organizacji. Oczywiście, takie podejście wymaga dowagi i siły sprawczej w organizacji, bo każda firma miliardy kluczowych wymagań must-have, bez których nowy system będzie po prosty beznadziejny – wymagań, bez realizacji których firma działa już kilkanaście lat, ale teraz to już „się zapadnie pod sobą wyniki spadną na twarz”. Zajęcie odpowiedniej niszy w działaniach organizacji pozwala na przeprowadzenie dowodu skuteczności, chroniącego przed szafowaniem takimi „wymaganiami”.

Słowo o kosztach. Rzeczywiste koszty wdrożenia systemu informatycznego składają się głównie z kosztów wprowadzenia zmiany organizacyjnej, głównie ukrytych i „złośliwych”. I choć nikt tego nie ujmuje w controllingu firm, tak naprawdę kosztuje zmiana kultury organizacyjnej, a nie ICT. Minimalizacja kosztów ICT opiera się właśnie na Open Source, systemach licencjonowanych posiadających wersję tzw. Community Edition. Przejście na wersję licencjonowaną to minimalizacja ryzyka, głównie technologicznego. Z Open Source zawsze można się łatwo wycofać – w sensie technologii ICT nie jest to związane z istotnymi kosztami.

Po co to wszystko? Żeby przeprowadzić firmę przez zmianę filozofii działania w jakimś obszarze (np. CRM) przy wykorzystaniu ICT, które nie kosztuje wagonu pieniędzy. Jeśli firma uzna, że już wie, jak wykorzystać system w tym obszarze (np. system klasy CRM), to może podjąć decyzję o przejściu z Open Source na oprogramowanie licencjonowane (choć ja mam wątpliwości). Będzie to jednak rzeczywiście wdrożenie systemu, a nie zmiany kultury organizacyjnej.

Pozostaw komentarz