Slajd pierwszy: rewolucja. Drugi: autonomiczni agenci. Trzeci: konkurencja już to robi. Na czterdziestym widać wykres z jednego udanego przypadku i prośbę o roczny budżet. Zarząd chce wiedzieć, co się zmieni, ile kosztuje odbiór i co dzieje się przy błędzie. Prezentacja odpowiada kolejnym slajdem o przyszłości.
AI może przygotować strukturę i pomóc w redakcji, ale nie powinno wymyślać business case. Najpierw potrzebna jest decyzja, dowody z procesu i uczciwe warianty. Mniej slajdów, więcej rzeczy do sprawdzenia.
Zacznij od jednego pytania decyzyjnego
Zapisz, co ma zostać rozstrzygnięte: pilotaż, zakup, rozszerzenie, zatrzymanie albo wybór wariantu. Nie przygotowuj prezentacji „o AI” bez właściciela decyzji. Każda sekcja powinna dostarczać argumentu do konkretnego wyboru.
Określ zakres decyzji i termin. Pilotaż jednego procesu nie wymaga udowadniania transformacji całej firmy. Roczna umowa wymaga innych dowodów niż dwutygodniowy test. Nie mieszaj poziomów pewności i zobowiązań.
Przygotuj rekomendację przed projektowaniem slajdów. Jeżeli nie da się jej sformułować bez ogólników, brakuje danych, nie animacji. Model może pomóc ją skrócić po ustaleniu treści.
Pokaż proces przed rozwiązaniem
Przedstaw obecny koszt, czas, wolumen, błędy i właścicieli. Bez tego nie ma punktu odniesienia. „Ręcznie trwa to długo” nie wystarcza do oceny wartości. Wybierz kilka podobnych przypadków i opisz metodę pomiaru.
Zaznacz, co nie jest problemem. Może odpowiedź pisze się szybko, ale długo trwa szukanie źródła. Automatyzacja tekstu nie rozwiąże głównego kosztu. To pytanie powinno znaleźć się przed slajdem o modelu.
Jeżeli dane są szacowane, oznacz je i podaj zakres. Nie zmieniaj kilku przypadków w uniwersalny procent oszczędności. Mała próbka może pokazywać kierunek, ale nie gwarantowany wynik roczny.
Dowody z testu muszą mieć mianownik
Pokaż liczbę przypadków, typy, wersję modelu i daty. Oddziel typowe od trudnych. Jeden dobry przykład nie opisuje całego procesu. Dołącz błędy krytyczne i czas odbioru.
Przy każdej liczbie zapisz, jak ją zmierzono. „90% poprawności” bez definicji pola i oczekiwanego wyniku nie pomaga. Jeżeli człowiek sprawdzał wszystko, podaj koszt sprawdzenia. Inaczej automatyzacja wygląda na darmową.
Dodaj przypadki nieudane. To nie osłabia prezentacji; pokazuje, że zespół wie, gdzie proces nie działa. Zarząd powinien zobaczyć warunki decyzji, a nie tylko marketingową wersję pilotażu.
Koszt całkowity zamiast ceny licencji
Rozdziel abonament, wywołania, przygotowanie danych, integrację, szkolenie, odbiór, utrzymanie i wyjście. Pokaż stałe i zmienne. Przy każdym zapisz źródło lub założenie.
Porównaj ten sam wolumen i jakość. Tańszy model może wymagać więcej poprawek, więc koszt jednostkowy rośnie. Droższy może być lepszy przy trudnych dokumentach, ale niepotrzebny przy prostych. Warianty powinny uwzględniać routing pracy.
Pełną metodę opisuje przewodnik o całkowitym koszcie AI. Nie przedstawiaj oszczędności przed policzeniem nowej pracy.
Ryzyko opisz przez skutek i kontrolę
Nie wystarczy lista „halucynacje, RODO, bezpieczeństwo”. Zapisz konkretny skutek: błędna kwota w dokumencie, wysłanie danych do niewłaściwej osoby, publikacja starej wersji. Przy każdym pokaż zatrzymanie, właściciela i test.
Oddziel kontrole istniejące od planowanych. Jeżeli odbiór człowieka jest dopiero pomysłem, nie przedstawiaj go jako działającego zabezpieczenia. Zarząd powinien wiedzieć, co jest gotowe przed decyzją.
Przy wysokim ryzyku zaproponuj ograniczenie zakresu zamiast ogólnej akceptacji. Może model pracuje tylko na publicznych danych albo przygotowuje szkic bez zapisu. To jest konkretna decyzja architektury.
Warianty muszą obejmować brak AI
Pokaż proces bez zmiany, prostszą poprawkę, pilotaż AI i większe wdrożenie. Każdy wariant ma koszt, czas, ryzyko i spodziewany skutek. Nie przedstawiaj wyboru między dwoma dostawcami, jeżeli problem można rozwiązać formularzem.
Brak AI nie powinien być wariantem karykaturalnym: „zostajemy w erze kamienia”. Opisz rzeczywiste zalety obecnego procesu i ograniczenia. Czasem jest wystarczająco dobry przy małym wolumenie.
Rekomendacja powinna wskazywać warunek zmiany wariantu. Na przykład rozszerzenie po przejściu określonych przypadków i braku błędów krytycznych. To lepsze niż obietnica automatycznej skali.
Historia klienta bez fikcyjnych statystyk
Jeżeli pokazujesz przypadek, oznacz, czy jest fikcyjny, anonimizowany czy rzeczywisty. Nie twórz „klient zaoszczędził 40%” na podstawie jednego czasu generowania. To nie jest pomiar całego procesu.
Przy case study zachowaj wersję, zakres, okres i źródło. Pokaż, co dokładnie zmierzono. Jeżeli nie masz zgody na identyfikację klienta, ogranicz szczegóły. Nie dodawaj rozpoznawalnych informacji dla wiarygodności.
Model może pomóc zbudować narrację, ale nie może dopisywać faktów. Przy tworzeniu dowodów pomocne są zasady z artykułu o case study SEO i leadach.
Slajdy, które odpowiadają na pytania
Pierwszy slajd: decyzja i rekomendacja. Drugi: proces i koszt obecny. Trzeci: wynik testu z mianownikiem. Czwarty: koszt i warianty. Piąty: ryzyka i kontrole. Szósty: plan, właściciele, warunki stopu. Często wystarcza mniej, ale ta sekwencja zamyka podstawowe pytania.
Nie umieszczaj pełnych tabel drobnego druku. Przenieś je do aneksu z linkiem. Na slajdzie pokaż tylko dane potrzebne do wyboru. Aneks nie może jednak ukrywać najważniejszego ograniczenia.
Unikaj obrazów autonomicznych robotów jako dowodu. One nie mówią, czy proces działa. Lepiej pokazać jeden rzeczywisty wynik lub mapę decyzji.
Odbiór liczb przed redakcją tekstu
Najpierw sprawdź źródła, obliczenia, mianowniki i wersje. Dopiero potem poprawiaj narrację. Model może przypadkowo zmienić liczbę przy skracaniu, więc po redakcji porównaj ponownie z oryginałem.
Przypisz właściciela każdej sekcji. Finanse potwierdzają koszt, technika test, prawo ocenę zapisów, proces czas pracy. Nie wymagaj od jednej osoby zatwierdzenia wszystkiego na podstawie ogólnego „wygląda dobrze”.
Po każdej zmianie danych zaktualizuj zależne slajdy i aneks. Stara liczba w nagłówku potrafi przetrwać kilka wersji i stać się najgłośniejszym błędem prezentacji.
Przykład: decyzja o ograniczonym pilotażu
W fikcyjnym przykładzie zespół chce automatyzować odpowiedzi klientom. Załóżmy, że test pokazuje dobre wyniki na prostych pytaniach i złe na umowach. Zamiast prosić o pełne wdrożenie, rekomenduje pilotaż na publicznej bazie FAQ z odbiorem człowieka.
Koszt obejmuje przygotowanie źródeł i przegląd. Warunek rozszerzenia: brak publikacji bez źródła, stabilny czas odbioru i poprawa odpowiedzi. Proces umowy zostaje poza zakresem do osobnej oceny.
To jest mniej efektowne niż „autonomiczna obsługa”, ale decyzja jest konkretna i możliwa do wycofania. Zarząd widzi, co kupuje i czego nie kupuje.
Przygotowanie na pytania trudne
Zapisz odpowiedzi na: co przy błędzie, ile kosztuje odbiór, jak wygląda wyjście, kto odpowiada, co z danymi, kiedy zatrzymujemy. Nie używaj modelu do zgadywania odpowiedzi. Przygotuj dowody i oznacz nieznane.
Jeżeli nie znasz kosztu migracji, zapisz sposób oszacowania i termin. Nie dopisuj liczby, żeby uniknąć pauzy. Uczciwe „tego jeszcze nie zmierzyliśmy” jest lepsze niż fałszywa precyzja.
Przy konflikcie danych pokaż go. Nie wybieraj wygodniejszej wersji. Decyzja wymaga zrozumienia rozbieżności, a nie ukrycia jej w aneksie.
Plan po decyzji
Zapisz pierwszy krok, właściciela, termin, przypadki testowe i warunek stopu. Nie kończ prezentacji na „wdrożenie od przyszłego kwartału”. Brak planu zamienia entuzjazm w nowy projekt bez właściciela.
Dodaj moment przeglądu z tymi samymi kryteriami. Jeżeli wynik nie wystarcza, zatrzymanie jest normalną decyzją, nie porażką zespołu. Budżet powinien mieć jasne ograniczenie i sposób wycofania.
Próba prezentacji bez prowadzącego
Daj materiał jednej osobie z docelowej grupy i poproś o opisanie decyzji, kosztu, największego ryzyka i warunku stopu. Jeżeli odpowiedzi wymagają twojego tłumaczenia, slajdy nie niosą wystarczającej informacji. Popraw treść przed spotkaniem zamiast liczyć na ratunek przez komentarz.
Zaznacz miejsca, w których liczby nie mają źródła lub mianownika. Nie odpowiadaj na nie nowym tekstem nadawczym. Dodaj dokument i zakres. Prezentacja powinna wytrzymać czytanie bez autora.
Sprawdź także czas. Jeżeli najważniejsza decyzja pojawia się dopiero po długiej historii narzędzia, przenieś ją na początek. Odbiorca nie powinien zgadywać, po co jest spotkanie przez dwadzieścia minut.
Aneks, który rzeczywiście pomaga
Dołącz metodę testu, listę przypadków, koszty i źródła. Nie przenoś do aneksu wszystkiego, co nie zmieściło się na slajdach. Ma odpowiadać na pytania o dowody, a nie pełnić funkcję drugiej, dłuższej prezentacji.
Oznacz wersje i właścicieli danych. Przy aktualizacji slajdu sprawdź zależne fragmenty aneksu. Rozjazd między nimi jest szczególnie kosztowny, bo wygląda na dwie różne rekomendacje.
Przy udostępnianiu zewnętrznym przygotuj wersję bez danych wrażliwych. Nie usuwaj po prostu nazwiska klienta z pełnego raportu, jeżeli reszta pozwala go rozpoznać. Ogranicz zakres zgodnie z celem.
Decyzja o zatrzymaniu też potrzebuje narracji
Jeżeli rekomendacja brzmi „nie wdrażać”, pokaż koszt uniknięty, ograniczenia danych i lepszą alternatywę. Nie przedstawiaj jej jako porażki projektu. Dobry test może oszczędzić roczny koszt złego procesu.
Zapisz, co zachować: źródła, przypadki, rubrykę, warunki ponownej oceny. Nowy model lub większy wolumen mogą zmienić decyzję. Nie obiecuj powrotu bez tych warunków.
Po spotkaniu zapisz rzeczywistą decyzję, a nie tylko prezentowaną rekomendację. Zarząd może wybrać inny wariant albo ograniczyć zakres. Dodaj właściciela, termin i zmiany warunków. To pozwala ocenić proces bez udawania, że wszystko poszło według slajdów.
Przy kolejnej prezentacji otwórz poprzedni wynik i pokaż, co się zmieniło. Nie zaczynaj od nowej opowieści o narzędziu. Dane z realizacji są ważniejsze niż kolejna obietnica z demo.
Przy odbiorze sprawdź, czy rekomendacja odpowiada pytaniu właściciela decyzji. Może zespół przygotował doskonały business case pilotażu, a zarząd potrzebuje decyzji o zatrzymaniu obecnego procesu. Zmień pytanie przed kolejnymi slajdami.
Zachowaj źródło przy każdej istotnej liczbie i nie oddzielaj go drobnym drukiem od kontekstu. Odbiorca powinien móc sprawdzić metodę po spotkaniu. Prezentacja ma prowadzić do decyzji, a nie do konieczności ponownego analizowania źródeł od zera.
Przy wersji zewnętrznej ogranicz dane i szczegóły procesu zgodnie z odbiorcą. Nie wystarczy usunięcie logo klienta. Koszt, termin i unikalny przypadek mogą go identyfikować. Oceń cały kontekst przed udostępnieniem.
Zachowaj wersję prezentacji i decyzję końcową. To ogranicza późniejsze cytowanie rekomendacji, która nie została zaakceptowana, jako rzeczywistego planu firmy.
Aeneia Audit pomaga przygotować mapę kosztu i ryzyka. Przy dowodach i komunikacji pomocne jest podejście Aeneia Signal do case study.
Osoba podejmująca decyzję powinna widzieć także koszt odłożenia lub zatrzymania projektu. Zachowaj wersję prezentacji wraz z ostatecznym wyborem, żeby później odróżnić rekomendację od zatwierdzonego planu.
Sprawdź nas. To zdrowe.
Temat zmienia się szybko. Linki prowadzą do źródeł pierwotnych i stron, na których możesz zweryfikować kontekst.
