Nie potrzebujesz specyfikacji ani listy technologii, żeby rozpocząć rozmowę o projekcie. Potrzebny jest opis sytuacji. Najbardziej użyteczny materiał to często jeden rzeczywisty przykład przeprowadzony od początku do końca — bez danych poufnych.
Poniższy schemat jest propozycją przygotowania takiego opisu, a nie obietnicą wyceny bez dalszych pytań.
1. Napisz, jaki efekt chcesz osiągnąć
„Potrzebujemy AI” mówi o narzędziu. „Chcemy przestać przepisywać dane z dokumentów do aplikacji” mówi o potrzebie. Drugi opis pozwala rozważyć kilka rozwiązań, w tym takie, które nie wymagają modelu AI.
Oddziel cel od pomysłu na wykonanie. Jeśli masz już preferowaną technologię, dopisz, z czego wynika wybór: umowy z dostawcą, kompetencji zespołu czy wymagań integracji.
2. Pokaż obecny proces
Opisz, kto wykonuje zadanie, skąd bierze dane i co robi z wynikiem. Nie pomijaj arkusza pomocniczego ani wiadomości wysyłanej do kolegi — często właśnie tam znajduje się istotna reguła, której nie ma w żadnym systemie.
Przykład syntetyczny: pracownik odbiera załącznik, sprawdza numer zamówienia w aplikacji, kopiuje trzy pola i wysyła potwierdzenie. Jeśli numer nie istnieje, dopytuje nadawcę. To znacznie więcej informacji niż „obsługujemy dokumenty ręcznie”.
3. Określ dane i dostępne systemy
Wymień aplikacje, typy plików i źródła informacji. Jeśli wiesz o istnieniu API lub eksportu, zaznacz to. Nie musisz samodzielnie badać dokumentacji technicznej.
Na początek wystarczy zanonimizowany przykład albo opis pól. Nie przesyłaj haseł, tokenów dostępowych ani pełnego eksportu bazy. Zasady dostępu do rzeczywistych danych ustala się przed analizą wymagającą takiego dostępu.
4. Opisz wyjątki i koszt błędu
Co dzieje się, gdy brakuje danych? Czy jedna wiadomość może przyjść dwa razy? Czy można bezpiecznie ponowić operację? Czy błędny wynik da się poprawić, czy uruchamia nieodwracalną czynność?
Te pytania pomagają zdecydować, gdzie potrzebna będzie kontrola człowieka. Automatyzacja zwykłej ścieżki bez obsługi wyjątków może tylko przenieść ręczną pracę w inne miejsce.
5. Podaj ograniczenia
Termin, orientacyjny budżet, wymagania dostawcy i dostępność osób znających proces wpływają na zakres pierwszego etapu. Informacja „nie możemy zmienić systemu księgowego” jest równie ważna jak lista oczekiwanych funkcji.
Jeśli ograniczenia nie są jeszcze znane, zapisz to wprost. Niewiadome można zbadać w analizie wykonalności zamiast ukrywać je w pozornie dokładnej wycenie.
6. Ustal, jak rozpoznasz sukces
Zamiast „ma być szybciej” zaproponuj obserwowalny rezultat: poprawne zamówienie trafia do systemu bez przepisywania, a niepełne dokumenty pojawiają się na liście do sprawdzenia. Pomiar czasu lub liczby błędów wymaga punktu odniesienia z obecnego procesu.
Krótki szablon do pierwszej wiadomości
- Chcemy osiągnąć…
- Dziś robimy to tak…
- Korzystamy z…
- Najczęściej problem pojawia się, gdy…
- Musimy uwzględnić…
- Pierwsza wersja będzie użyteczna, jeśli…
Nie musisz od razu wypełnić każdego punktu. Opisz to, co już wiesz, a brakujące pytania ustalimy podczas rozmowy. Przy większej niepewności dobrym pierwszym krokiem może być płatna analiza wykonalności.