W rozwijającej się organizacji nieraz pojawiają się różne pomysły na to, jak dotychczasowe procesy biznesowe usprawnić, zoptymalizować czy też uprościć. Z pozoru zagadnienie wydaje się oczywiste – wystarczy znaleźć metodę, opracować plan wdrożenia, wdrożyć i cieszyć się efektem swoich prac. W praktyce jednak efekt końcowy wygląda różnie i, jak się okazuje, nie zawsze spełnia oczekiwania.
Dlatego też w tym krótkim artykule chciałbym przedstawić na podstawie własnego doświadczenia:
- na co warto zwrócić uwagę podczas wprowadzania zmian w procesach,
- jakie pułapki i problemy mogą się po drodze pojawiać,
- czego należy unikać.
Strategia relacji
Zanim zaczniemy zastanawiać się nad tym, od jakich procesów rozpoczniemy naszą przygodę, musimy pomyśleć o właściwej strategii zarządzania pomysłami. Dlaczego? Wynika to z faktu, że stanowi ona fundament późniejszych wdrożeń.
Często w różnych organizacjach już w tym punkcie popełnia się podstawowy błąd. Jaki? Stosuje się klasyczne podejście do wdrażania rozwiązań IT, innymi słowy: osoby z biznesu zgłaszają się do działu IT, a dział IT zajmuje się całością – gromadzi wiedzę o procesie, wdraża i monitoruje rozwiązanie. Podejście to, w którym wyłącznie IT odgrywa rolę eksperta, bardzo często prowadzi do przekroczenia budżetu projektu oraz licznych błędów w zakresie wymagań co do samego rozwiązania.
Dlatego też na wstępie konieczne jest zbudowanie odpowiednich relacji między IT a biznesem tak, by obie strony odgrywały role wiodące – IT jako specjalista techniczny, a strona biznesowa jako specjalista procesowy. Dzięki temu dostrzeżemy, że najlepszym źródłem wiedzy o procesie oraz o tym, co należy zrobić, żeby go usprawnić, jest ten, kto w tym procesie aktywnie uczestniczy. Lepszym doradcą będzie pracownik magazynu, który codziennie pracuje na procesie pakowania, niż programista, który nigdy takiej pracy nie wykonywał.
Dla kogo to wszystko?
Gdy uda nam się wypracować już relacje między działami i zdecydować, kto i za co odpowiada, warto w kontekście konkretnego projektu już na etapie analizy biznesowej skupić się na użytkowniku końcowym.
Oczywiście wszyscy bardzo dobrze znamy podejście user-centered[1], całą metodologię Agile i jesteśmy w stanie niemal natychmiast wywołać z pamięci hasła o tym, jak ważne i potrzebne jest to, by rozwiązanie, które tworzymy, było dla użytkownika najlepsze i spełniało wszystkie jego oczekiwania.
W praktyce projektowej jednak rzeczywistość jest nieco inna – mamy bowiem do czynienia także z innymi „siłami”, które mają wpływ na efekt końcowy. Kogo mam tutaj na myśli? Przede wszystkim managerów, którzy chcą, żeby projekt nie przekraczał budżetu i spełniał wszystkie wskazane oczekiwania, a także programistów, którym zależy najczęściej na tym, żeby rozwiązanie było stabilne i nie wymagało dodatkowej pracy po wdrożeniu. Sztuką więc jest już na wstępnym etapie tak zdefiniować wymagania i dobrać technologię, żeby spełnić oczekiwania wszystkich.
Jest to jednak zadanie prawie niewykonalne. Jak zatem rozwiązać ten problem? Poprzez kompromis.
Być elastycznym jak kompromis
Wyobraźmy sobie taką sytuację: mamy projekt pewnego rozwiązania do obsługi sklepu internetowego. Użytkownikowi końcowemu bardzo zależy na tym, żeby koszyk, w którym wyświetlają się produkty, posiadał tło w kolorze, powiedzmy, bladoróżowym. Problem jednak w tym, że kolor ten zupełnie nie odpowiada kolorystyce strony. Ponadto zmiana ta wiąże się z dość dużym nakładem pracy ze strony programisty i powoduje, że rozwiązanie może w przyszłości generować większą liczbę błędów.
Jak więc sprawić, by „wilk był syty i owca cała”? Nie ma na to jednoznacznej odpowiedzi. Warto jednak przy podejmowaniu decyzji zadać sobie kilka pytań:
- czy to wymaganie biznesowe jest na pewno konieczne do zrealizowania?
- czy wymaganie jest kluczowe dla działania całego rozwiązania?
- jakie będą konsekwencje odrzucenia lub wdrożenia wymagania?
- czy jest szansa na negocjacje i zmianę wymagania?
Gdy uda nam się na nie odpowiedzieć, będziemy mieli dość obszerną analizę całej sytuacji.
Pomyślmy teraz, jak moglibyśmy tę wiedzę wykorzystać. Jeśli okazałoby się, że wymaganie nie jest konieczne do zrealizowania, kluczowe będzie takie prowadzenie rozmowy z biznesem, by, o ile to możliwe, wymaganie usunąć. Wielką rolę odgrywają tutaj umiejętności miękkie programisty czy analityka, który potrafi wytłumaczyć, dlaczego należałoby to wymaganie odrzucić.
W przypadku, gdy wymaganie jest konieczne do zrealizowania, pierwsze skrzypce powinien grać programista, który znów, o ile to możliwe, musi znaleźć najbardziej optymalne rozwiązanie. Dobrym pomysłem na tym etapie jest przedstawienie biznesowi konsekwencji zrealizowania wymagania – z uwzględnieniem wszystkich problemów, jakie mogą pojawić się w przyszłości w związku z takim podejściem itp. Pozwala to czasem zdobyć pewną przestrzeń do renegocjacji wymagania.
Spojrzenie w przyszłość poszerza także horyzont poza (jak zwykliśmy myśleć w dzisiejszych czasach) zakres kilku miesięcy i pozwala w lepszym świetle dostrzec konsekwencje decyzji.
Szybki zysk to wolna strata
Nieraz w toku tworzenia rozwiązania, w związku z ograniczonym budżetem, podejmuje się decyzję o wyborze tańszej technologii, zmniejszeniu ilości funkcji w aplikacji czy też ograniczeniu zaangażowania firm doradczych. O ile takie podejście przynosi szybki zysk w początkowej fazie projektu, o tyle „mści się” w przyszłości i prowadzi ostatecznie do większych kosztów. Jest to niestety bardzo często popełniany błąd, szczególnie w czasie gorszej koniunktury.
Lęk przed zwiększonymi kosztami jest oczywiście czymś naturalnym, jednakże, jak każda emocja, nie jest on dobrym doradcą. Dlatego warto czasem przeznaczyć większe fundusze na rozwiązanie dobre, spełniające wszystkie wymagania i stabilne od strony technicznej, niż oszczędzać i narażać organizację na większe koszty w przyszłości.
Biznes też potrafi!
Jednym z częściej spotykanych błędów jest nieuwzględnianie zaangażowania biznesu w zakresie obsługi rozwiązania. Dla przykładu: tworzymy i wdrażamy proces automatyczny, który obsługuje wysyłkę wiadomości e-mail do określonych adresatów. Odbiorcy wiadomości zmieniają się stosunkowo często i za każdym razem konieczna jest zmiana adresów, którą musi wykonać programista. Ponadto do rozwiązania nie została utworzona instrukcja dla użytkownika końcowego.
Zastanówmy się teraz, jakie wynikają z tego konsekwencje:
- W przypadku braku programisty na stosunkowo prostą zmianę biznes będzie musiał czekać lub konieczne będzie zaangażowanie dodatkowej osoby do obsługi po stronie działu IT.
- Adresy zmieniają się często, a zatem dział IT będzie regularnie obciążany powtarzalnym i najpewniej prostym do rozwiązania zgłoszeniem.
- Nie ma instrukcji, więc użytkownik w przypadku niewłaściwego działania rozwiązania prawie zawsze będzie zgłaszał się do działu IT.
Jak widzimy, negatywnych efektów jest sporo i rodzą one niepotrzebne koszty. Dlatego bardzo ważne jest takie tworzenie rozwiązania, które umożliwi naprawę prostych błędów i obsługę rutynowych zmian użytkownikowi końcowemu.
Instrukcja
W przypadku braku osób o zacięciu technicznym w zespole po stronie biznesu, warto poświęcić nieco czasu na znalezienie takiego specjalisty, np. w innym, powiązanym dziale. Dzięki temu obniżymy koszty obsługi rozwiązania i przy okazji stworzymy dla pracowników przestrzeń do rozwoju. Oprócz tego warto przygotować instrukcję do procesu, nawet jeśli wydaje nam się ona zbędna i prawdopodobnie nie będzie wykorzystywana.
Dlaczego? Dzięki niej rozwiązanie „samodokumentuje się” i zastępowalność oraz przekazywanie wiedzy między pracownikami odbywa się sprawniej. Wystarczy, że programista spojrzy w instrukcję i już jest w stanie zbudować sobie przynajmniej szczątkowy obraz rozwiązania oraz lepiej zrozumieć zasady jego działania. Zyskują też osoby po stronie biznesu – mają prosty dokument, do którego mogą się odnieść zanim zgłoszą problem do działu IT.
Nie ma nic bardziej epickiego niż dokumentacja
Dokumentacja to temat chyba najmniej lubiany, szczególnie przez programistów. Jest ona jednak kluczowa do wypracowania odpowiedniego mechanizmu zastępowalności i przekazywania wiedzy o rozwiązaniach. Prawdopodobnie nie ma nic gorszego, niż skomplikowany proces, o którym wiedzę posiada tylko jeden członek zespołu. Wystarczy chwila nieobecności i koszty mogą być znaczące.
Jeśli chodzi o ilość dokumentów, to nie ma tutaj jednoznacznej recepty. Natomiast z pewnością dobrze jest stworzyć przynajmniej:
- opis procesu,
- diagram przedstawiający, jak proces wygląda obecnie,
- wspomnianą wcześniej instrukcję.
Można również wykorzystać podział diagramu procesu na dwie części – tzw. diagram As-Is i diagram To-Be[2], które wizualizują kolejno proces przed optymalizacją oraz po niej. Dzięki temu obraz zmian jest pełniejszy i pozwala na głębszą analizę, chociażby pod kątem lessons learned.
IT w demokracji
Na koniec chciałbym wspomnieć o kilku moich przemyśleniach dotyczących tzw. demokratyzacji w IT[3]. Sama koncepcja przenoszenia odpowiedzialności za tworzenie rozwiązań informatycznych na osoby z biznesu jest jak najbardziej właściwa i potrzebna, szczególnie w obliczu wciąż rosnącego zapotrzebowania na programistów. Dzięki technologiom typu low-code stało się to możliwe i można śmiało stwierdzić, że jest w tym ogromny potencjał. Niestety, jak w przypadku każdej nowości, podejście to rodzi pewne problemy, które, jeśli nie są rozwiązane, mogą spowodować wiele komplikacji.
Jednym z częstszych błędów jest brak odpowiedniej strategii tzw. citizen development. Osoby z biznesu otrzymują dostęp do narzędzi i tworzą rozwiązania, które doskonale odpowiadają ich potrzebom. Brak jakiejkolwiek kontroli ze strony osób bardziej doświadczonych w zakresie projektowania rozwiązań IT powoduje jednak, że optymalizacje te np.:
- nie spełniają podstawowych wymagań dotyczących bezpieczeństwa,
- są niewłaściwie zaprojektowane i niemożliwe jest ich monitorowanie,
- dotyczą procesów krytycznych, które powinny być pod stałą kontrolą.
Ze względu na ww. ryzyka warto na wstępie, jak zwykle, zastanowić się, jaką przyjmiemy strategię promowania tego typu rozwiązań w organizacji. Istnieje wiele modeli współpracy między działem IT a citizen developerami i trudno wskazać tutaj jeden, odpowiadający na wszystkie potrzeby. Zawsze jednak warto zwrócić uwagę na to, by rozwiązania tworzone przez osoby z biznesu były pod jakąś formą kontroli, np. poprzez polityki DLP[4], ograniczenia dostępu do określonych środowisk, weryfikację rozwiązania przed wdrożeniem itp.
Podsumowanie
Mam nadzieję, że w tym krótkim artykule udało mi się w sposób klarowny przedstawić kilka punktów, na które warto zwrócić uwagę przy optymalizacji i automatyzacji procesów.
Zagadnienie jest bardzo szerokie i otwiera liczne pola do dyskusji. Myślę więc, że warto dzielić się swoimi spostrzeżeniami i dyskutować na ten temat, by rozwiązania, które będziemy tworzyć w przyszłości, były bardziej efektywne, ciekawsze i aby spełniały nawet najbardziej wygórowane oczekiwania. Powodzenia!
***
Jeśli interesuje Cię tematyka zarządzania projektami i kompetencji miękkich, zajrzyj koniecznie również do innych artykułów naszych ekspertów 🙂
[1] https://www.interaction-design.org/literature/topics/user-centered-design (dostęp: 9.07.2024)
[2] https://www.visual-paradigm.com/tutorials/as-is-to-be-business-process.jsp#:~:text=The%20As%2DIs%20diagram%20offers,will%20appear%20in%20the%20future. (dostęp: 9.07.2024)
[3] Więcej na ten temat można dowiedzieć się tutaj: https://robonomika.pl/jak-demokratyzacja-it-pomaga-wdrazac-innowacje-cyfrowe-i-znalezc-lepsza-prace-moja-prezentacja-z#:~:text=Zgodnie%20z%20definicj%C4%85%20demokratyzacja%20IT,nast%C4%99pnie%20w%20ich%20codziennej%20pracy
[4] https://www.forcepoint.com/cyber-edu/dlp-policy (dostęp: 9.07.2024)
Zostaw komentarz