Kiedy Excel przestaje wystarczać do obsługi zleceń?

Arkusz działa, dopóki pracuje w nim jedna osoba

Excel jest dobrym narzędziem do obsługi zleceń. Powstaje w godzinę, każdy go zna, a nowa kolumna nie wymaga programisty. Większość firm, z którymi rozmawiamy, prowadziła w nim zlecenia przez lata i nie było w tym nic złego. Pytanie, kiedy Excel przestaje wystarczać do obsługi zleceń, ma więc odpowiedź inną niż „od początku był zły”. Przestaje wystarczać w konkretnym momencie, który da się rozpoznać i opisać.

Ten moment zwykle przychodzi wtedy, gdy w arkuszu zaczyna pracować więcej niż jedna osoba. Jedna osoba pamięta, co znaczy żółte tło, i wie, że kolumna K jest nieaktualna. Trzy osoby już tego nie wiedzą. Każda z nich zapisuje plik pod własną nazwą, a wersja na serwerze jest sprzed tygodnia. Arkusz nadal liczy poprawnie. Przestał tylko być wspólnym miejscem, w którym widać, co jest do zrobienia i kto to robi.

Ten poradnik ma pomóc w uczciwej decyzji. Pokazuje sygnały, przy których arkusz zaczyna kosztować więcej, niż daje, i sposoby na uporządkowanie go bez żadnej aplikacji. Pokazuje też, kiedy aplikacja do zleceń ma sens i jak przygotować do niej dane. Zakres takiej aplikacji opisujemy na stronie aplikacji do obsługi zleceń. Jeśli po lekturze uznasz, że wystarczy Ci uporządkowany arkusz, to też jest dobry wynik.

Sygnały, że Excel przestaje wystarczać do obsługi zleceń

Poniższe sytuacje słyszymy najczęściej. Żadna z nich pojedynczo nie oznacza, że trzeba budować aplikację. Trzy albo cztery naraz zwykle już tak.

• W kilku plikach istnieją różne statusy tego samego zlecenia i nikt nie wie, który jest aktualny.
• Pracownik nie wie, kto zatwierdził zmianę terminu albo zakresu, bo zmiana nie zostawiła śladu.
• Termin jest w kalendarzu jednej osoby, załączniki w skrzynce drugiej, a ustalenia z klientem w komunikatorze trzeciej.
• Plik jest „zablokowany do edycji przez innego użytkownika” kilka razy dziennie.
• Ktoś prowadzi własny, prywatny arkusz, bo wspólnemu nie ufa.
• Klient dzwoni z pytaniem o status, a odpowiedź wymaga telefonu do dwóch osób.
• Co poniedziałek ktoś przepisuje dane z arkusza do programu do faktur albo odwrotnie.
• Nowy pracownik uczy się arkusza przez tydzień, bo znaczenie kolorów i skrótów jest w głowie poprzednika.
• Wiersz zlecenia zniknął i nikt nie wie, czy został usunięty, przeniesiony, czy nadpisany.

Przez kilka dni zapisuj takie przypadki razem z tym, co z nich wynikło: opóźnienie, podwójna praca, zdenerwowany klient. Potem rozdziel je na dwie grupy. Pomyłki, które wzięły się z braku ustaleń, i pomyłki, które wzięły się z ograniczeń narzędzia. Pierwsza grupa nie zniknie po zmianie narzędzia. Nowa aplikacja też potrzebuje reguł, kto za co odpowiada.

Brak ustaleń wygląda tak: dwie osoby zmieniają termin, bo obie uważają, że mogą. Ograniczenie narzędzia wygląda tak: obie zmieniły termin, a arkusz nie pokazuje, która zrobiła to później i dlaczego. Pierwszy problem załatwia decyzja właściciela. Drugi załatwia historia zmian, której arkusz nie prowadzi na poziomie pojedynczego zlecenia.

Dwa sygnały, które wyglądają na problem narzędzia, a nim nie są

„Nikt nie aktualizuje arkusza” to najczęstsza skarga, z jaką firmy przychodzą po aplikację. Aplikacja tego nie naprawi. Jeśli pracownik nie wpisuje statusu w arkuszu, nie wpisze go też w aplikacji, dopóki nie wie, po co to robi i kto to sprawdza. Drugi taki sygnał to „arkusz ma za dużo kolumn”. Zwykle znaczy to, że przez lata dokładano pola na każdą sytuację i nikt nie usuwał tych, które przestały być potrzebne. Aplikacja z tymi samymi kolumnami będzie miała ten sam problem. W obu przypadkach najpierw jest decyzja, a dopiero potem narzędzie.

Co arkusz robi dobrze i czego aplikacja nie zastąpi

Zanim ktokolwiek zaproponuje Ci aplikację, zapisz, za co lubisz swój arkusz. Ta lista wróci na etapie ustalania zakresu. Aplikacja, która odbiera ludziom to, co w arkuszu działało, nie zostanie przyjęta.

Arkusz wygrywa w kilku rzeczach. Powstaje natychmiast i zmienia się natychmiast. Nowa kolumna to sekunda, a w aplikacji to zgłoszenie do wykonawcy. Liczy: marże, obłożenie, sumy na koniec miesiąca, bez projektowania raportu. Pozwala na analizę, której nikt nie przewidział: filtr, tabela przestawna, wykres na jedno spotkanie. Nie wymaga wdrożenia, szkolenia ani utrzymania. Działa bez internetu. Każdy w firmie go zna.

Dlatego w większości wdrożeń arkusz nie znika. Zostaje tam, gdzie jest najlepszy: w kalkulacjach, analizach ad hoc i raportach, które zmieniają się co miesiąc. Aplikacja przejmuje to, w czym arkusz jest słaby. Wspólną pracę wielu osób na tych samych danych, historię zmian, uprawnienia, statusy z regułami i załączniki przypięte do właściwego zlecenia. Dobra aplikacja do zleceń ma też eksport do arkusza, żeby analizy dalej robić tam, gdzie wygodnie.

Jest jeszcze jedna rzecz, której aplikacja nie zastąpi. Decyzji, kto w firmie odpowiada za zlecenie, kto może zmienić termin i kto zatwierdza zakończenie. Jeśli tych decyzji nie ma, aplikacja będzie je wymuszać polami, które ludzie zaczną omijać. Jeśli są, arkusz może je obsłużyć dłużej, niż się wydaje.

Co zostaje w arkuszu po wdrożeniu

Z rozmów o zakresie wraca kilka rzeczy, które prawie zawsze zostają w arkuszu. Kalkulator ofert z formułami, które właściciel dopracowywał latami i którym ufa. Rozliczenie miesięczne, które księgowa robi po swojemu. Analiza obłożenia na kwartał, robiona raz i oglądana na jednym spotkaniu. Archiwum zleceń sprzed lat, do którego nikt nie zagląda, ale które musi istnieć. Każda z tych rzeczy dostaje w aplikacji eksport, a nie zamiennik.

Kiedy najpierw uporządkować arkusz i jak to zrobić w tydzień

Nie każdy bałagan wymaga aplikacji. Jeśli proces jest prosty, osób jest niewiele, a problemem są niejednolite nazwy, zacznij od porządku w tym, co masz. To zajmuje kilka dni i nie kosztuje nic poza decyzjami. Poniższa lista jest w kolejności, w której ma sens.

1. Wyznacz jeden plik jako źródło prawdy. Pozostałe kopie zarchiwizuj albo usuń. Jeśli ktoś potrzebuje własnego widoku, niech filtruje źródło, a nie kopiuje je.
2. Przenieś plik do współdzielonego miejsca, w którym kilka osób może pracować naraz, zamiast wysyłać załączniki mailem.
3. Ustal listę statusów i zablokuj kolumnę statusu do wyboru z listy. „W trakcie”, „w realizacji” i „robi się” to trzy nazwy tego samego, a filtr ich nie połączy.
4. Dodaj kolumnę z osobą odpowiedzialną i wymagaj jej przy każdym wierszu. Zlecenie bez osoby jest problemem wszystkich, czyli niczyim.
5. Dodaj kolumny „ostatnia zmiana” i „kto zmienił”, wypełniane ręcznie. To słaba namiastka historii zmian, ale lepsza niż nic.
6. Nadaj każdemu zleceniu numer, który nie zmienia się nigdy, i używaj go w mailach, na dokumentach i w rozmowach.
7. Zablokuj kolumny, których nikt nie powinien ruszać: numer, data przyjęcia, klient.
8. Spisz na osobnym arkuszu, co znaczą kolory, skróty i kolumny. Nowy pracownik ma to przeczytać w pierwszy dzień.
9. Ustal, kto raz w tygodniu przegląda zlecenia bez ruchu i zamyka te, które powinny być zamknięte.

Po takim porządku sprawdź wynik na kilku rzeczywistych sprawach. Jeśli zespół potrafi znaleźć informacje i wykonać zadanie bez dodatkowej wiadomości, rozbudowa narzędzi może nie być potrzebna. Arkusz dopasowany do obecnej skali pracy jest lepszy niż aplikacja zaprojektowana na skalę, której jeszcze nie ma.

Tydzień obserwacji jednego procesu

Zanim zamówisz aplikację, poświęć jeden tydzień na obserwację. Wybierz jeden rodzaj zlecenia, najlepiej ten, który sprawia najwięcej kłopotu, i zaangażuj osoby, które go obsługują. Nie trzeba mierzyć całej firmy. Przez ten tydzień zapisujcie sytuacje, w których ktoś musi szukać informacji, przepisywać dane albo ustalać, która wersja pliku jest właściwa.

Przykłady z tabeli są ilustracją, nie pomiarem. Zapisujcie własny czas i częstotliwość, jeśli chcecie porównać proces przed zmianą i po niej. Po tygodniu rozdzielcie wpisy tak jak w sekcji o sygnałach: trudność wynikająca z narzędzia osobno, brak ustalonej odpowiedzialności osobno. Nowa aplikacja nie rozstrzygnie za firmę, kto podejmuje decyzję.

Jak prowadzić zapis, żeby nie zabrał więcej czasu niż praca

Jedna wspólna kartka albo osobny arkusz z kolumnami z tabeli powyżej. Wpis w jednym zdaniu, bez uzasadnień. Pięć minut na koniec dnia, w których każdy dopisuje, co go zatrzymało. Bez nazwisk winnych, bo celem jest mapa procesu, a nie ocena ludzi. Jeśli zespół poczuje, że zapis służy do rozliczania, wpisy znikną drugiego dnia. Po tygodniu właściciel albo kierownik czyta całość i grupuje wpisy według miejsca w procesie: przyjęcie, planowanie, wykonanie, rozliczenie.

Taki tydzień ma jeszcze jedną zaletę. Lista obserwacji jest gotowym opisem procesu, od którego zaczyna się rozmowa o zakresie, u nas i u każdego innego wykonawcy. Zamiast listy funkcji z internetu przynosisz listę miejsc, w których praca się zatrzymuje. To lepszy punkt wyjścia do wyceny.

Arkusz i aplikacja: uczciwe porównanie

Poniższa tabela porównuje oba narzędzia w sytuacjach, które pojawiają się przy obsłudze zleceń. Są wiersze, w których arkusz wygrywa, i nie ma powodu tego ukrywać.

Dwa ostatnie wiersze są uczciwe w obie strony. Arkusz nic nie kosztuje na starcie, ale uzależnia od autora. Aplikacja kosztuje, ale po przekazaniu kodu i dokumentacji nie zależy od jednej osoby w firmie ani od jednego wykonawcy.

Kiedy rozważyć aplikację do zleceń

Aplikacja ma sens, gdy problemy z sekcji o sygnałach wracają po uporządkowaniu arkusza. Zwykle dzieje się to w jednej z czterech sytuacji.

• Różne osoby wykonują kolejne kroki tego samego zlecenia. Biuro przyjmuje, kierownik planuje, ekipa wykonuje, biuro rozlicza. Każde przekazanie między nimi to miejsce, w którym arkusz gubi informację.
• Dostęp zależy od roli. Podwykonawca ma widzieć adres i zakres, ale nie stawkę. Praktykant ma dopisywać uwagi, ale nie zmieniać terminów.
• Dane muszą trafiać do innych systemów. Zlecenie zakończone ma stać się fakturą, a zamówienie materiału ma zejść ze stanu magazynu.
• Klienci mają sami sprawdzać status albo zatwierdzać materiały, zamiast dzwonić do biura.

Jeśli choć dwie z tych sytuacji są Twoje, zapisz, jak powinna wyglądać praca po zmianie. Przykładowe założenia dla pierwszej wersji:

• Każde zlecenie ma opiekuna, termin i jednoznaczny status z ustalonej listy.
• Zmiana etapu wymaga określonych informacji albo akceptacji wskazanej osoby.
• Dokumenty są przypisane do właściwego zlecenia, z wersjami.
• Zespół ma wspólny widok zadań i obciążenia na najbliższe dni.
• Zmiana terminu albo zakresu zostawia ślad i trafia do osoby, której dotyczy.

To przykłady do określenia zakresu, a nie obowiązkowa lista modułów. Jak dobrać funkcje do rzeczywistego obiegu, a nie do katalogu możliwości, opisujemy w poradniku o aplikacji do obsługi zleceń. Jeśli najwięcej kłopotu sprawia kontakt z klientem i oferty, a nie wykonanie, zacznij od CRM-u dla firmy usługowej. Jeśli klienci mają sami zaglądać do statusu, przeczytaj, co powinien zawierać panel klienta B2B. Pełny przegląd tego, co budujemy, jest na stronie aplikacji dla firm.

Gotowy program czy własna aplikacja

Między arkuszem a dedykowaną aplikacją jest jeszcze gotowy program do zleceń albo zadań. Jeśli obsługuje Wasz obieg bez kłopotliwych obejść, porównaj go z budową własnego narzędzia, licząc abonament, konfigurację i to, czego nie da się w nim zmienić. Dedykowana aplikacja ma sens przy obiegu, którego gotowy program nie zna, przy nietypowych uprawnieniach albo przy integracjach, których nie ma w jego cenniku. Sposób porównania opisujemy w poradniku gotowy CRM czy dedykowany. Zasady są te same dla programów do zleceń.

Jak arkusz pęka w różnych firmach

Arkusz zleceń w każdej branży wygląda podobnie: numer, klient, co, na kiedy, kto, status. Pęka w innym miejscu, zależnie od tego, co w zleceniu jest najtrudniejsze.

Serwis i instalacje

Arkusz pęka na terenie. Ekipa nie ma go przed sobą, więc dzwoni do biura, a biuro czyta z ekranu. Zdjęcia z montażu idą komunikatorem i nigdy nie trafiają do wiersza zlecenia. Zgłoszenie serwisowe po roku zaczyna się od szukania, co tam zamontowano. Pierwsza wersja aplikacji zwykle obejmuje kartę zlecenia dostępną z telefonu, zdjęcia przypięte do zlecenia i listę urządzeń przy kliencie.

Produkcja na zamówienie

Arkusz pęka na wersjach. Klient zmienia ilość albo materiał, powstaje druga oferta, a hala dostaje wydruk z pierwszej. Do tego kolejka produkcji w osobnym pliku u kierownika i wysyłki w trzecim. Pierwsza wersja aplikacji obejmuje zlecenie z wersjami specyfikacji, oznaczenie zaakceptowanej wersji i jeden widok kolejki dla hali. Planowanie maszyn często zostaje tam, gdzie było.

Handel i dystrybucja

Arkusz pęka na duplikatach danych. Klient i zamówienie są w programie handlowym, a usługa, dostawa z montażem albo reklamacja w arkuszu. Po roku adresy w obu miejscach są różne. Pierwsza wersja aplikacji obejmuje zlecenia usługowe połączone z klientem z programu handlowego, żeby dane wpisywać raz. Jak sprawdzamy, co da się połączyć, opisujemy na stronie integracji systemów.

Usługi dla firm

Biuro rachunkowe, kancelaria, agencja. Arkusz pęka na terminach cyklicznych i dokumentach od klienta. Co miesiąc te same zadania dla tych samych klientów, a brakujące dokumenty ścigane mailem. Pierwsza wersja obejmuje zadania cykliczne generowane automatycznie, listę dokumentów do dostarczenia i widok, kto czego jeszcze nie przysłał.

Firma budowlana

Arkusz pęka na zmianach zakresu. Ustalenia z budowy nie trafiają do żadnego pliku, a rozliczenie końcowe staje się sporem. Pierwsza wersja obejmuje dziennik zmian przy zleceniu: co, kiedy, kto zaakceptował po stronie inwestora, z załącznikiem. Harmonogram i kosztorys zwykle zostają w narzędziach, które firma już zna.

Firmy z oddziałami

Arkusz pęka na liczbie plików. Każdy oddział ma własny, a centrala raz w miesiącu skleja je w jeden, ręcznie. Pierwsza wersja obejmuje wspólną bazę zleceń z widokiem per oddział, uprawnieniami kierownika oddziału i raportem zbiorczym bez sklejania.

Przykład z biurka: trzy arkusze i tablica korkowa

Zakład produkujący konstrukcje stalowe na zamówienie zgłosił się z pytaniem o „program do zleceń”. Na pierwszej rozmowie okazało się, że zleceń pilnują trzy arkusze i jedna tablica korkowa w hali. Arkusz biura z zapytaniami i ofertami. Arkusz kierownika z kolejką produkcji. Arkusz logistyka z wysyłkami. Na tablicy wisiały wydruki zleceń w kolejności, którą znał tylko kierownik.

Krok pierwszy: spis plików i tego, kto w nich pracuje. Wyszło, że to samo zlecenie ma trzy numery, bo każdy arkusz numerował po swojemu. Klient podawał numer oferty, biuro szukało numeru zlecenia, hala znała numer z tablicy.

Krok drugi: tydzień obserwacji na jednym typie zlecenia. Najczęstszy wpis brzmiał: „klient zmienił termin, hala się nie dowiedziała”. Drugi: „na tablicy wisi wersja rysunku sprzed poprawki”. Trzeci: „logistyk nie wie, czy zlecenie jest gotowe do wysyłki, i chodzi na halę sprawdzić”.

Krok trzeci: rozdzielenie problemów. Zmiana terminu bez informacji dla hali była brakiem reguły, kto o tym informuje. Wersja rysunku na tablicy była ograniczeniem narzędzia, bo tablica nie ma wersji. Chodzenie logistyka na halę było jednym i drugim.

Krok czwarty: zakres pierwszej wersji. Jeden numer zlecenia od zapytania do wysyłki. Karta zlecenia z aktualną wersją rysunku i oznaczeniem, która jest obowiązująca. Statusy: przyjęte, w produkcji, gotowe, wysłane, z regułą, że „gotowe” ustawia hala, a „wysłane” logistyk. Powiadomienie dla hali przy zmianie terminu. Ekran dla hali na jednym komputerze zamiast tablicy. Arkusz biura z kalkulacjami ofert został, bo liczył dobrze i nikt nie chciał go zmieniać.

Co zostało na później: planowanie maszyn, magazyn materiałów, panel dla klienta. Każda z tych rzeczy była w pierwszej rozmowie na liście życzeń. Żadna nie była w tygodniu obserwacji. Jak decydować, co wchodzi do pierwszej wersji, a co czeka, opisujemy w poradniku o pierwszej wersji aplikacji dla firmy.

Przygotuj dane, zanim zmienisz narzędzie

Najdłuższy etap przejścia z arkusza na aplikację bywa porządek w danych, a nie sama budowa. Arkusz przez lata przyjmował wszystko: literówki w nazwach klientów, daty w trzech formatach, statusy w kolorach. Aplikacja tego nie przyjmie, więc porządek trzeba zrobić przed importem.

Co ustalić przed importem

• Które arkusze są aktualne, a które są archiwum albo kopią. Importujemy jedno źródło.
• Jaki identyfikator ma klient i jaki zlecenie. Jeśli nie ma stałego numeru, trzeba go nadać przed importem.
• Jak rozpoznać duplikaty: ta sama firma wpisana na trzy sposoby, to samo zlecenie w dwóch plikach.
• Które kolumny są potrzebne w codziennej pracy, a które są historią, która może trafić do archiwum.
• Co zrobić z wierszami niepełnymi: zlecenia bez terminu, bez klienta, bez statusu.
• Jakie statusy z arkusza odpowiadają statusom w aplikacji. Zwykle jest ich w arkuszu więcej, niż ktokolwiek pamięta.

Do planowania importu przygotuj przykładowe dane bez informacji poufnych. Kilkadziesiąt wierszy z usuniętymi nazwami wystarczy, żeby sprawdzić format i znaleźć pułapki. Próbna migracja na części danych pokazuje wynik, zanim przeniesie się całość. Po niej osoba odpowiedzialna sprawdza, czy użytkownicy widzą właściwe zlecenia i mogą wykonać uzgodnione czynności.

Co przechodzi do aplikacji, a co zostaje

Do aplikacji trafiają zlecenia otwarte i te zamknięte niedawno, do których zespół jeszcze wraca. Do tego lista klientów z identyfikatorami i lista statusów po uporządkowaniu. Dokumenty przypinamy do zleceń, jeśli da się je powiązać numerem. W arkuszu zostają kalkulatory, archiwum starsze niż okres, do którego ktokolwiek zagląda, i analizy. Granicę ustalamy przed importem. Przenoszenie wszystkiego „na wszelki wypadek” wydłuża porządkowanie i zaśmieca nową bazę od pierwszego dnia.

Moment przełączenia

Ustal dzień, od którego nowe zlecenia zakłada się tylko w aplikacji. Zlecenia otwarte w tym dniu przenieś importem albo ręcznie, z osobą, która sprawdzi każde. Prowadzenie arkusza i aplikacji równolegle „przez miesiąc, na wszelki wypadek” kończy się dwoma niepełnymi źródłami. Jeśli arkusz ma zostać do kalkulacji, zdecyduj, co w nim zostaje, a co już tylko w aplikacji. Szerzej o przygotowaniu zespołu i danych piszemy w poradniku o tym, jak przygotować firmę do wdrożenia CRM. Większość tamtych zasad dotyczy też aplikacji do zleceń.

Dane osobowe w arkuszach

Arkusz zleceń zawiera dane klientów, często osób prywatnych: imię, adres, telefon. Plik wysyłany mailem między pracownikami i trzymany na prywatnych laptopach jest trudny do upilnowania. Przy przejściu na aplikację ustalamy, gdzie dane są przechowywane, kto ma do nich dostęp i jak wygląda ich usunięcie. Obowiązki firmy jako administratora danych wynikają z RODO, a wyjaśnienia publikuje Urząd Ochrony Danych Osobowych. Sam fakt, że dane są w arkuszu, nie zwalnia z tych obowiązków.

Najczęstsze błędy przy przejściu z arkusza na aplikację

Poniższe błędy widzieliśmy u firm, które przychodziły po drugą aplikację, bo pierwsza nie została przyjęta. Każdy z nich da się przewidzieć przed budową.

• Arkusz przepisany jeden do jednego. Aplikacja z czterdziestoma kolumnami na jednym ekranie jest gorsza niż arkusz, bo nie ma w niej filtrów, do których ludzie przywykli.
• Wszystkie moduły naraz. Zlecenia, magazyn, planowanie, panel klienta i raporty w jednej wersji. Zespół dostaje system, którego nikt nie umie ogarnąć, a wdrożenie trwa dłużej, niż ktokolwiek zakładał.
• Narzędzie wybrane przed procesem. Firma kupuje albo zamawia aplikację, a potem dopasowuje do niej sposób pracy. Powinno być odwrotnie.
• Brak reguł odpowiedzialności. Aplikacja ma pole „opiekun”, ale nikt nie ustalił, kto je wypełnia, więc zostaje puste.
• Wyjątki pominięte w projekcie. Wstrzymanie, zmiana terminu, poprawka, anulowanie. Projekt obsługuje idealny przebieg, a życie składa się z wyjątków.
• Nikt z zespołu na testach. Właściciel odbiera aplikację sam, a ekipa pierwszy raz widzi ją w dniu startu.
• Równoległe prowadzenie arkusza. Po miesiącu oba źródła są niepełne i nikt nie wie, któremu wierzyć.
• Brak osoby odpowiedzialnej za dane po wdrożeniu. Duplikaty, martwe zlecenia i nieaktualne statusy po roku zamieniają aplikację w arkusz, który miała zastąpić.
• Prawa do kodu i dostępy nieustalone w umowie. Po zakończeniu współpracy firma nie może zmienić wykonawcy bez budowy od zera.

Każdy z tych błędów kosztuje więcej po wdrożeniu niż przed. Dlatego etap uzgadniania pierwszej wersji kończy się decyzją o funkcjach, rolach, danych i tym, co zostaje w obecnych narzędziach.

Jak wygląda współpraca z nami przy aplikacji do zleceń

Pierwsza wersja ma obsłużyć jedno zadanie od początku do końca. Jej zakres da się sprawdzić, zanim dołożymy kolejne działy. Współpraca ma cztery etapy, opisane na stronie oferty.

1. Rozpisujemy przebieg. Przechodzimy przez jedno zwykłe zlecenie i kilka trudniejszych sytuacji. Ustalamy, kto decyduje, jakie dane przekazuje i co dziś opóźnia pracę. Tydzień obserwacji z tego poradnika jest tu gotowym materiałem.
2. Uzgadniamy pierwszą wersję. Wybieramy funkcje, role i dane. Ustalamy kryteria odbioru oraz to, co pozostaje w obecnych narzędziach, w tym w arkuszu. Przygotowujemy zakres do indywidualnej wyceny.
3. Sprawdzamy z zespołem. Budujemy i testujemy kolejne elementy na uzgodnionych scenariuszach. Użytkownicy sprawdzają przekazywanie pracy, dokumenty, wyjątki oraz uprawnienia.
4. Uruchamiamy i obserwujemy. Planujemy przeniesienie danych, dostęp zespołu i opiekę. Po uruchomieniu zbieramy uwagi i wybieramy usprawnienia na podstawie rzeczywistego użycia.

Na wycenę wpływa liczba ról i wyjątków, dokumenty, migracja oraz połączenia z innymi systemami. Utrzymanie, usługi zewnętrzne i późniejszą rozbudowę ustalamy osobno. Zespół dostaje działające funkcje z uzgodnionego zakresu, dostępy i instrukcję obsługi. Zasady przekazania kodu, licencji, kopii zapasowych i wsparcia określamy w ofercie oraz umowie. Jak porównać oferty różnych wykonawców, opisujemy w poradniku o tym, ile kosztuje aplikacja dla firmy. Jeśli wolisz zacząć od formularza, wypełnij brief aplikacji.

Jak wygląda przejście jednego zlecenia

Zaczynamy od momentu, w którym zlecenie wchodzi do firmy: telefon, mail, formularz, wizyta. Potem idziemy krok po kroku przez każde przekazanie. Kto przyjmuje, gdzie zapisuje, kto się o tym dowiaduje, skąd bierze dane do planowania, co dostaje wykonawca, co wraca po wykonaniu, kto wystawia fakturę. Przy każdym kroku pytamy o wyjątki: co, jeśli klient zmieni termin, jeśli materiału nie ma, jeśli ekipa znajdzie na miejscu coś innego. Z tej rozmowy powstaje rysunek obiegu, który zatwierdzasz, zanim narysujemy pierwszy ekran. Osoby z biura i z wykonania powinny być na tej rozmowie razem, bo każda z nich zna inną połowę procesu.

Pytania do wykonawcy

Zadaj je nam i każdej innej firmie. Odpowiedzi pokażą, czy wykonawca myśli o Waszym obiegu, czy o swoim produkcie.

• Co z naszego arkusza zostanie, a co przejmie aplikacja, i kto o tym decyduje.
• Jak aplikacja obsłuży wstrzymanie, zmianę terminu, poprawkę i anulowanie zlecenia.
• Jak wygląda import danych z arkusza i jak sprawdzimy, czy się udał.
• Czy możemy sami dodawać pola albo statusy, czy każda zmiana jest zleceniem.
• Jak wygląda eksport danych do arkusza, gdy chcemy coś policzyć po swojemu.
• Z jakimi programami aplikacja będzie połączona i co się stanie, gdy połączenie nie działa.
• Kto jest właścicielem kodu i danych, gdzie są przechowywane i kto robi kopie.
• Co obejmuje utrzymanie, jaki jest sposób zgłaszania problemów i co jest rozwojem wycenianym osobno.

Co po uruchomieniu

Ocenę zacznij od problemu, z którym przyszliście. Jeśli chodziło o zmiany terminu, które nie docierały do hali, sprawdź po kilku tygodniach, czy docierają. Wybierz miernik związany z pierwotnym problemem: czas znalezienia zlecenia, liczbę ręcznych przepisań albo liczbę zleceń bez opiekuna. Porównaj podobne zadania przed wdrożeniem i po nim oraz zapytaj użytkowników o trudności. To daje podstawę do decyzji o kolejnej wersji.

Wyznacz osobę, która odpowiada za dane: czyści duplikaty, zamyka martwe zlecenia, zakłada i blokuje konta. Ustal, kto sprawdza, czy kopia zapasowa da się odtworzyć. Po pierwszych tygodniach zbierz listę rzeczy, które zespół nadal robi w arkuszu albo na kartce. Część z nich to kandydaci na kolejną wersję, część to sygnał, że coś w projekcie nie pasuje do pracy.

Funkcje AI, takie jak odczytanie zamówienia z przesłanego PDF-a albo podsumowanie wątku z klientem przy zleceniu, dokładamy wtedy, gdy pomagają w konkretnym zadaniu. Aplikacja działa bez nich. Gdzie AI pomaga, a gdzie wymaga kontroli człowieka, opisujemy w poradniku o AI w aplikacji firmowej.

Słownik pojęć i lista kontrolna przed decyzją

Kilka słów, które pojawią się w rozmowie o przejściu z arkusza na aplikację.

• Źródło prawdy. Jedno miejsce, w którym dane o zleceniu są obowiązujące. Wszystkie inne są kopią albo widokiem.
• Karta zlecenia. Ekran z wszystkimi informacjami o jednym zleceniu: klient, zakres, termin, osoba, status, dokumenty, historia.
• Status, etap. Punkt w obiegu zlecenia, wybierany z ustalonej listy, a nie wpisywany ręcznie.
• Warunek przejścia. Dane albo akceptacja wymagane, żeby zlecenie zmieniło status.
• Rola. Zestaw tego, co użytkownik widzi i może zmienić. Biuro, kierownik, ekipa i podwykonawca mają inne role.
• Historia zmian. Zapis, kto, kiedy i co zmienił przy zleceniu.
• Migracja, import. Przeniesienie danych z arkusza do aplikacji, z ustaleniem identyfikatorów i duplikatów.
• Próbna migracja. Import części danych, żeby sprawdzić wynik przed przeniesieniem całości.
• Integracja. Połączenie aplikacji z innym programem, w którym dane przepływają bez przepisywania.
• Panel klienta. Osobny widok dla klienta, w którym po zalogowaniu widzi wybrane informacje o swoim zleceniu.
• Pierwsza wersja, MVP. Zakres, który obsługuje jedno zadanie od początku do końca i da się sprawdzić przed rozbudową.
• Utrzymanie. Aktualizacje, kopie, monitoring i poprawki po wdrożeniu, ustalane osobno od budowy.

Lista kontrolna przed decyzją

1. Lista sygnałów z Waszej firmy, z podziałem na brak ustaleń i ograniczenia narzędzia.
2. Lista tego, za co lubicie arkusz i co ma w nim zostać.
3. Arkusz uporządkowany według listy z tego poradnika i sprawdzony na kilku sprawach.
4. Tydzień obserwacji jednego typu zlecenia, z zapisem czynności, źródeł i decyzji.
5. Role osób w obiegu i to, co każda z nich musi widzieć i móc zmienić.
6. Programy, z którymi aplikacja ma się łączyć, i co ma między nimi przepływać.
7. Spis arkuszy z oznaczeniem, który jest źródłem, i przykładowe dane bez informacji poufnych.
8. Osoba, która będzie odpowiadać za dane i decyzje po wdrożeniu.

TL;DR

• Arkusz przestaje wystarczać, gdy pracuje w nim kilka osób, a zlecenie przechodzi między nimi.
• Rozdziel problemy z braku ustaleń od ograniczeń narzędzia. Pierwszych aplikacja nie naprawi.
• Najpierw uporządkuj arkusz: jedno źródło, statusy z listy, osoba przy każdym zleceniu, stały numer.
• Zrób tydzień obserwacji jednego procesu. Ta lista jest lepszym briefem niż lista funkcji.
• Aplikacja ma sens przy rolach, warunkach przejścia, załącznikach, powiadomieniach i integracjach.
• Arkusz zwykle zostaje do kalkulacji i analiz. Aplikacja ma mieć eksport.
• Uporządkuj dane przed importem i ustal dzień przełączenia. Bez równoległego prowadzenia obu.

FAQ