Nie każde wdrożenie automatyzacji kończy się sukcesem za pierwszym razem. Część firm zgłasza się do nas po projekcie, który utknął: narzędzie zostało kupione, konfiguracja zaczęta, a efektu nie ma. Takie sprawy wyglądają inaczej niż wdrożenie od zera i wymagają innego początku.
Najczęstsza przyczyna nie leży po stronie technologii. Narzędzia są dziś na tyle dojrzałe, że rzadko okazują się wąskim gardłem. Problem pojawia się wcześniej — na etapie ustalania, co właściwie ma zostać zautomatyzowane i po czym poznamy, że działa.
Projekt zaczyna się od narzędzia zamiast od procesu. Firma kupuje rozwiązanie, bo dobrze wypadło na prezentacji, a dopiero potem szuka zastosowania. Dopasowanie procesu do narzędzia zawsze idzie gorzej niż dobór narzędzia do procesu.
Druga przyczyna to brak dostępu do danych. Automatyzacja ma korzystać z informacji, które w firmie istnieją, ale rozproszone są między arkuszami, skrzynkami pocztowymi i programem magazynowym, a części nikt nigdy nie zapisywał — bo „wszyscy wiedzą".
Trzecia to zbyt szeroki zakres pierwszego etapu. Zamiast zautomatyzować jedną czynność i sprawdzić efekt, projekt obejmuje od razu cały dział. Kiedy coś nie działa, nie wiadomo który element zawiódł, a wdrożenie grzęźnie w poprawkach.
Wdrożenie prowadzone „przy okazji" przez osobę, która ma też swoje normalne obowiązki, przesuwa się w nieskończoność. Nie z braku chęci — po prostu bieżąca praca zawsze wygrywa z projektem bez terminu.
Dlatego przy przejmowaniu takiego wdrożenia ustalamy dwie rzeczy: kto po stronie firmy podejmuje decyzje i ile czasu realnie może na to poświęcić. Jeśli odpowiedź brzmi „nikt" i „nie wiadomo", zakres trzeba zawęzić tak, żeby projekt dało się dowieźć mimo to.
Od ustalenia, co miało zostać osiągnięte. Brzmi banalnie, ale bardzo często okazuje się, że cel nigdy nie został zapisany w mierzalnej formie. „Usprawnić obsługę zapytań" to intencja, nie cel. „Skrócić czas pierwszej odpowiedzi z ośmiu godzin do jednej" to cel, który da się sprawdzić.
Potem sprawdzamy, co już powstało. Bywa, że część pracy jest wartościowa i wystarczy ją dokończyć. Bywa też, że przyjęte założenia były błędne i taniej jest zacząć od nowa niż naprawiać. Mówimy o tym wprost, zamiast ratować pracę, która i tak nie doprowadzi do celu.
Pierwszy etap powinien być na tyle mały, żeby dało się go uruchomić w kilka dni, i na tyle konkretny, żeby efekt był widoczny bez analiz. Jedna czynność, jeden zespół, jeden mierzalny wynik.
Ma to dwie zalety. Po pierwsze, szybko pokazuje, czy założenia były trafne — a jeśli nie, korekta kosztuje kilka dni, nie kilka miesięcy. Po drugie, buduje zaufanie zespołu, który przy poprzednim projekcie zdążył się zniechęcić.
Dopiero po sprawdzeniu pierwszego kroku rozszerzamy zakres. Kolejne etapy idą szybciej, bo dane są już uporządkowane, a integracje działają.
Najlepiej sprawdzają się czynności powtarzalne, opisane regułami i wykonywane często. Przepisywanie danych między systemami, przygotowywanie tych samych zestawień, wstępne segregowanie wiadomości, wypełnianie dokumentów według szablonu.
Gorzej wypadają zadania wymagające oceny sytuacji, znajomości kontekstu albo odpowiedzialności za decyzję. Tam automatyzacja może przygotować materiał i propozycję, ale decyzję zostawia człowiekowi — i tak zwykle powinna być zaprojektowana.
Osobna kategoria to zadania wykonywane rzadko. Automatyzacja czynności powtarzanej raz na kwartał rzadko zwraca koszt wdrożenia, nawet jeśli technicznie jest wykonalna. Mówimy o tym, zamiast rozszerzać zakres projektu.
Automatyzacja działa na tym, co dostanie. Jeśli dane są niekompletne, zapisywane w różny sposób przez różne osoby albo istnieją tylko w formie skanów, pierwszy etap projektu polega na ich uporządkowaniu, a nie na wdrażaniu narzędzia.
To etap, który bywa pomijany, a odpowiada za większość nieudanych wdrożeń. Uporządkowane dane mają wartość niezależnie od tego, czy automatyzacja powstanie — ułatwiają też zwykłą pracę i raportowanie.
Przy narzędziach AI pojawia się pytanie, co dzieje się z przekazywanymi informacjami. Odpowiedź zależy od konkretnego rozwiązania i wybranego wariantu usługi — różnice bywają duże i warto je ustalić przed wdrożeniem, a nie po.
Przy danych wrażliwych stosujemy rozwiązania ograniczające zakres przekazywanych informacji: przetwarzanie lokalne tam, gdzie to możliwe, usuwanie danych osobowych przed wysłaniem, oddzielenie środowiska testowego od produkcyjnego. Ustalamy też, kto w firmie ma dostęp do wyników.
Punktem odniesienia jest czas poświęcany dziś na czynność, którą chcemy zautomatyzować. Jeśli dwie osoby tracą po godzinie dziennie na przepisywanie danych, wiadomo, ile warta jest zmiana i ile sensownie można na nią wydać.
Rachunek obejmuje nie tylko wdrożenie, ale też utrzymanie: opłaty za narzędzia, czas na poprawki po zmianach w firmie, okresową kontrolę wyników. Automatyzacja nie jest jednorazowym wydatkiem i lepiej wiedzieć to na początku.
Gdy proces zmienia się co miesiąc — automatyzacja będzie wymagała przeróbek szybciej, niż zdąży się zwrócić. Gdy czynność wykonuje jedna osoba raz w tygodniu przez kwadrans. Gdy prawdziwym problemem jest organizacja pracy, a nie jej pracochłonność — wtedy automatyzacja utrwali tylko istniejący bałagan.
W takich sytuacjach mówimy o tym wprost i proponujemy tańsze rozwiązanie: uporządkowanie procesu, szablon dokumentu, zmianę kolejności czynności. Bywa, że to wystarcza.
Pracujemy krótkimi cyklami z ustalonym punktem kontrolnym. Po każdym etapie pokazujemy, co działa, i uzgadniamy, czy idziemy dalej w tym kierunku. Firma nie musi czekać kilku miesięcy, żeby zobaczyć pierwszy efekt.
Dokumentujemy przy tym konfigurację — co zostało ustawione, gdzie i dlaczego. Dzięki temu wdrożenie nie staje się kolejnym rozwiązaniem zrozumiałym wyłącznie dla jego autora. To ta sama zasada, przez którą wiele projektów utyka po odejściu jednej osoby.
Po zakończeniu etapu przekazujemy zespołowi krótkie omówienie: co się zmieniło, czego już nie trzeba robić ręcznie i co zrobić, gdy coś zadziała inaczej niż zwykle. Bez tego nawet dobrze zbudowana automatyzacja bywa omijana.
Automatyzacja żyje razem z firmą. Zmienia się formularz u dostawcy, dochodzi nowy rodzaj dokumentu, program dostaje aktualizację — i coś, co działało bezbłędnie, zaczyna pomijać część przypadków.
Dlatego po wdrożeniu warto ustalić prosty tryb kontroli: kto sprawdza wyniki, jak często i po czym pozna, że coś przestało działać. Przy dobrze zaprojektowanym rozwiązaniu wystarcza rzut oka raz w tygodniu.
Tak. Zaczynamy od przeglądu tego, co powstało, i oceny, co da się wykorzystać. Nie oceniamy pracy poprzedniego wykonawcy — nie znamy warunków, w jakich pracował.
Przy dobrze zawężonym zakresie zwykle od kilku dni do dwóch tygodni. Jeśli wychodzi znacznie więcej, to sygnał, że zakres jest za szeroki i trzeba go podzielić.
Zwykle nie. Automatyzację buduje się wokół tego, co firma już ma. Wymiana systemu to osobna decyzja, którą warto podejmować z własnych powodów, nie pod naciskiem wdrożenia.
W małych i średnich firmach zwykle nie. Efektem jest raczej to, że ludzie przestają tracić czas na przepisywanie danych i wracają do pracy, na którą wcześniej go brakowało. Jeśli jednak celem projektu jest ograniczenie kosztów pracy, warto powiedzieć to wprost na początku — zmienia to zakres i sposób wdrożenia.
To częsty i uzasadniony opór, zwłaszcza po nieudanym poprzednim projekcie. Dlatego pierwszy etap dobieramy tak, żeby zdejmował z ludzi czynność, której nie lubią, a nie dokładał im nowych obowiązków.
Kontakt: 22 390 56 49 — telefon czynny całą dobę, siedem dni w tygodniu. Obsługujemy Grodzisk Mazowiecki i okolice.
Arrived compass prepare an on as. Reasonable particular on my it in sympathize. Size now easy eat hand how. Unwilling he departure elsewhere dejection at. Heart large seems may purse means few blind.
Address