Audyt AI i pilotaż - zacznij od procesu, nie od technologii

Zamiast wybierać narzędzie i szukać dla niego zastosowania, sprawdzamy najpierw, gdzie w Twojej firmie realnie znika czas. Dostajesz dokument z rekomendacją i zakresem pilotażu, a nie ofertę na wdrożenie, którego nikt jeszcze nie policzył.

Dla kogo

Kiedy warto zacząć od audytu

1

Brak kierunku

Wiecie, że AI może pomóc, ale nie wiecie gdzie. Temat jest na agendzie zarządu, budżet wstępnie zarezerwowany, ale nikt nie potrafi wskazać procesu, od którego zacząć.

2

Kilka pomysłów

Macie kilka pomysłów i nie wiecie, który jest najlepszy. Audyt porównuje je na tych samych kryteriach: pracochłonność, ryzyko, wpływ na codzienną pracę.

3

Potrzeba dowodu

Zarząd rzadko akceptuje inwestycję opartą na przekonaniu, że „AI teraz pomaga wszystkim". Audyt daje dokument, który da się położyć na stole.

4

Weryfikacja

Dostaliście już wycenę i chcecie ją sprawdzić przed decyzją.

Kiedy audyt nie jest potrzebny?

Jeśli wiecie dokładnie, czego chcecie, macie opisany proces i uporządkowaną wiedzę, można pominąć ten etap i przejść od razu do pilotażu. Powiemy to wprost, jeśli tak będzie. Audyt nie jest obowiązkową bramką przed każdą rozmową.

Jak kwalifikujemy proces do audytu

Trzy pytania, po których wiadomo, czy jest o czym rozmawiać

Pytanie 1

  • Gdzie znika czas? Gdzie zespół traci dziś najwięcej czasu na przepisywanie danych, szukanie informacji, przygotowywanie odpowiedzi albo pilnowanie spraw?

Pytanie 2

  • Gdzie są dane? Jakie dane są potrzebne, żeby to usprawnić i gdzie one dziś leżą?

Pytanie 3

  • Chmura czy u Was? Czy te dane mogą być przetwarzane w chmurze, czy muszą pozostać w środowisku firmy? To pytanie decyduje o kształcie całego projektu, dlatego zadajemy je od razu.
Zakres
Co analizujemy
  • Proces
    Którędy dziś płynie sprawa od początku do zamknięcia, ile trwa każdy krok, gdzie stoi i czeka na kogoś, gdzie powstaje praca wykonywana ręcznie.
  • Dane
    Jakie informacje są potrzebne, w jakiej formie istnieją, gdzie leżą i czy są aktualne. Ten punkt najczęściej ujawnia, że część wiedzy używanej codziennie nie istnieje nigdzie na piśmie.
  • Systemy
    Z czego faktycznie korzystacie, jakie dane są dostępne i co da się z nimi zrobić bez ingerencji w rozwiązania krytyczne dla działania firmy.
  • Ludzie i decyzje
    Kto w procesie decyduje, które decyzje muszą pozostać przy człowieku i gdzie potrzebna jest akceptacja przed kolejnym krokiem. Wyznaczenie tej granicy jest częścią audytu.

Co otrzymujecie

Dokument w trzech częściach, gotowy do przedstawienia zarządowi

Bez tłumaczenia technicznego, tak, żeby dało się go czytać na spotkaniu decyzyjnym.

Część 1

  • Stan obecny Mapa procesu z zaznaczonymi punktami, w których powstaje ręczna praca i opóźnienia. Krótki opis wykorzystywanych systemów i dostępnych danych.

Część 2

  • Ustalenia i priorytety Lista obszarów o największym potencjale, uszeregowana według efektu i pracochłonności, a nie według tego, co technicznie najciekawsze. Każdy z oszacowaniem i wskazaniem, czego wymaga po Waszej stronie.

Część 3

  • Rekomendacja i pilotaż Jedno wskazane rozwiązanie z uzasadnieniem oraz gotowy zakres ograniczonego pilotażu: co obejmuje, ile trwa, jakie mierniki i jaki punkt odniesienia.

Format rekomendacji

Przedstawiamy warianty i wskazujemy jeden

Rekomendacja nie jest jednym zdaniem „proponujemy wdrożyć X”. Decyzja zostaje po Waszej stronie, ale nie jest podejmowana w ciemno. Do każdego wariantu podajemy pracochłonność, ryzyko i wpływ na codzienną pracę zespołu. Przykładowy zakres rekomendacji:

Wariant A

  • Uporządkowanie tego, co jest Czasem wystarczy poprawić przepływ informacji albo opisać brakujące procedury, bez wdrażania czegokolwiek nowego.

Wariant B

  • Automatyzacja fragmentu Zawężony zakres, szybki efekt, ograniczone ryzyko. Najczęstsza rekomendacja przy pierwszym projekcie.

Wariant C

  • Szersze wdrożenie z integracjami Większy efekt, dłuższy projekt, więcej zależności między systemami i zespołami.
Model pilotażu
Pilotaż to ograniczony fragment, nie mniejsza wersja całego wdrożenia
  • Zawężony zakres
    Jedna kategoria spraw, jeden zespół albo jeden typ dokumentu. Tyle, żeby zobaczyć efekt, i nie więcej.
  • Mierniki i punkt odniesienia ustalone z góry
    Kryteria sukcesu zapisujemy przed rozpoczęciem prac, a punkt odniesienia mierzymy przed startem. To najczęściej pomijany element i najczęstsza przyczyna sporów o to, czy wdrożenie „się udało".
  • Wyraźna granica odpowiedzialności
    Co robi system, a co pozostaje przy człowieku. Ustalone na piśmie, zanim cokolwiek zostanie uruchomione.
  • Decyzja o kontynuacji na danych
    Po pilotażu wracamy z wynikami i rekomendacją: rozszerzać, zmienić podejście albo zatrzymać się tam, gdzie jesteśmy.
Kryteria sukcesu i mierniki

Mierniki dobieramy do procesu, nie odwrotnie

Na etapie audytu wybieramy z nich dwa lub trzy i ustalamy dla nich punkt odniesienia. Poniżej te, które sprawdzają się najczęściej.

Czas obsługi sprawy

Od wpłynięcia do zamknięcia.

Sprawy obsługiwane ręcznie

Ile z nich nadal wymaga przepisywania danych.

Czas dotarcia do informacji

Ile zajmuje znalezienie odpowiedzi potrzebnej do pracy.

Liczba błędów

Pomyłki powstające przy ręcznym przenoszeniu danych.

Sprawy domknięte samodzielnie

Udział spraw zamkniętych bez angażowania kolejnej osoby.

Koszt jednostkowy

Koszt obsługi jednej sprawy, jeśli da się go sensownie policzyć.

Czego nie podajemy: wyników z cudzych wdrożeń jako obietnicy dla Waszego procesu. Liczba wyrwana z innego kontekstu nie mówi nic o Waszej sytuacji. Mierzymy u Was i na Waszych danych.

Audyt procesu czy audyt aplikacji

Dwie różne usługi – warto wiedzieć, której potrzebujecie

Jeśli problemem jest istniejąca aplikacja, a nie proces, zaczynamy od tej drugiej ścieżki.

Zobacz: Refaktoryzacja aplikacji z AI →
  • Audyt procesu

    Punktem wyjścia jest sposób pracy: sprawa, dokument, zapytanie, przepływ między ludźmi i systemami.

    Odpowiada na pytanie: gdzie warto usprawnić pracę.

  • Audyt aplikacji i kodu

    Dotyczy konkretnego oprogramowania: jego stanu technicznego, bezpieczeństwa, architektury i możliwości dalszego rozwoju.

    Odpowiada na pytanie: czy tę aplikację warto rozwijać dalej i co jej grozi.

Dalsze ścieżki wdrożenia

Po audycie projekt idzie jedną z opracowanych dróg

Rozstrzygamy to w rekomendacji, nie po podpisaniu umowy. W każdym przypadku pozostaje jeden zespół prowadzący i jeden punkt kontaktu. Nie odsyłamy Was między spółkami.

Projekty produktowe: GOTOMA Software House

  • Wdrożenie oprogramowania, asystentów i automatyzacji w istniejącym środowisku. Tą ścieżką idzie większość projektów: asystent na stronie, praca z dokumentami, automatyzacja fragmentu procesu, integracja z Waszymi systemami.

Projekty infrastrukturalne z GOTOMA GENERAL

  • Kryteria techniczne: dane i model nie mogą opuszczać Waszej infrastruktury albo potrzebne jest dedykowane środowisko.
  • Kryteria biznesowe: sprzęt lub infrastruktura fizyczna, koordynacja kilku wykonawców, dotacja lub tryb przetargowy, kilka lokalizacji, zmiany w samym ERP lub MES.

Projekty przekrojowe: Grupa GOTOMA

  • Jeśli potrzeba obejmuje kilka obszarów jednocześnie na przykład sprzedaż, dokumenty i infrastrukturę, prowadzimy je w ramach Grupy Technologicznej, z jedną konsultacją zamiast trzech osobnych rozmów.

Umów analizę przypadku

Krótka rozmowa, po której będziecie wiedzieć, czy wdrożenie AI ma w Waszym przypadku sens.

Porozmawiajmy