Aplikacja do obsługi zleceń - jak wybrać potrzebne funkcje?

Opisz jedno zlecenie od przyjęcia do zamknięcia

Aplikacja do obsługi zleceń ma tyle sensu, ile ma go opis procesu, na którym powstaje. Dlatego zanim zaczniesz wybierać funkcje, weź jedno typowe zlecenie i zapisz jego przebieg. Kto je przyjmuje, jakie dane sprawdza, komu przekazuje wykonanie, co potwierdza zakończenie. Taki opis zajmuje godzinę i oszczędza tygodnie przy ustalaniu zakresu.

Uwzględnij to, co odbiega od planu: powrót do poprzedniego etapu, zmianę zakresu w trakcie, brak informacji od klienta, chorobę wykonawcy. Idealny przebieg obsłuży każda aplikacja. O przydatności decyduje obsługa wyjątków, bo to one dziś lądują w mailach i komunikatorach.

Opis pozwala odróżnić czynności od statusów. „Oczekuje” niewiele mówi, jeśli nie wiadomo na co i kto ma zareagować. „Oczekuje na akceptację klienta, odpowiada handlowiec” mówi wszystko. Dobre nazwy statusów pozwalają zrozumieć sytuację bez otwierania dodatkowych wiadomości.

Zapisz też, gdzie dziś ta praca się zatrzymuje. Zlecenie przyjęte, ale nikt nie wie, czy magazyn ma materiał. Wykonawca skończył, ale faktura nie wychodzi, bo brakuje protokołu. Klient dzwoni z pytaniem o status, a odpowiedź wymaga trzech telefonów. Każde takie miejsce to kandydat na funkcję. Jeśli pracujecie w arkuszach, poradnik o tym, kiedy Excel przestaje wystarczać, pomoże ocenić, czy problem leży w narzędziu, czy w procesie.

Co ma zawierać opis jednego zlecenia

• Skąd zlecenie przychodzi i jakie dane ma na wejściu. Zaznacz, które pola są zwykle puste.
• Kto podejmuje każdą decyzję po drodze: wycena, przydział, akceptacja, odbiór.
• Jakie dokumenty powstają na każdym etapie i kto je dziś przechowuje.
• Co klient dostaje od firmy w trakcie: potwierdzenie, wycenę, termin, protokół.
• Trzy wyjątki z ostatniego miesiąca i to, jak zostały obsłużone.
• Gdzie zlecenie najczęściej czeka i na kogo.
• Co oznacza „zamknięte” i kto ma prawo to stwierdzić.

Forma nie ma znaczenia. Notatka w mailu, arkusz z kolumnami, nagranie rozmowy z osobą, która przyjmuje zlecenia. Z tego materiału układamy przebieg na pierwszym etapie współpracy.

Zlecenie, zadanie, dokument, akceptacja: cztery rzeczy, które się mylą

W arkuszu wszystko jest wierszem. W aplikacji te cztery rzeczy muszą być osobne, bo każda ma innego właściciela, inny cykl życia i inne uprawnienia.

Zlecenie

Odbiorca, uzgodniony zakres, termin, status i osoba odpowiedzialna za całość. Zlecenie ma jedną kartę i jedną historię. Jeśli klient zmieni zakres, zmiana jest wpisem w historii zlecenia, nie nowym wierszem.

Zadanie

Czynność do wykonania przez konkretną osobę, z warunkiem zakończenia. Jedno zlecenie może mieć kilka zadań u różnych osób: pomiar, zamówienie materiału, montaż, odbiór. Zadanie ma własny status, ale zlecenie nie jest zamknięte, dopóki otwarte jest choć jedno zadanie. Nie każda firma potrzebuje zadań w pierwszej wersji. Jeśli zlecenie wykonuje jedna osoba od początku do końca, wystarczy jeden etap realizacji.

Dokument

Plik z wersją, kontekstem i zasadami dostępu. Dokument jest przypięty do zlecenia albo do zadania, nigdy luzem. Ma wersje, bo oferta z poniedziałku i oferta po poprawkach z czwartku to dwa różne dokumenty, a wykonawca musi wiedzieć, który obowiązuje. Zdjęcia z realizacji też są dokumentami, z datą i autorem.

Akceptacja

Informacja, co i przez kogo zostało potwierdzone. Akceptacja wyceny przez klienta, akceptacja projektu przez koordynatora, odbiór prac przez inwestora. Akceptacja jest zdarzeniem z datą i osobą, nie polem do zaznaczenia. Cofnięcie akceptacji też jest zdarzeniem.

Nie wszystkie elementy muszą trafić do pierwszej wersji. Decyzję podejmij na podstawie opisanych zleceń, nie na podstawie tego, co ma konkurencja. Jak ograniczyć pierwszą wersję do tego, co potrzebne, opisujemy w poradniku o zakresie MVP aplikacji.

Statusy i przekazanie pracy: żeby „w realizacji” coś znaczyło

Statusy to najczęściej źle projektowany element. Lista powstaje w pięć minut, a potem przez lata zespół nie wie, czy „w realizacji” oznacza, że ktoś pracuje, czy że ktoś powinien zacząć. Dobry status ma trzy cechy. Wiadomo, kto za niego odpowiada. Wiadomo, co musi się wydarzyć, żeby go opuścić. Wiadomo, co go blokuje.

Dla każdego statusu zapisz warunek wejścia, osobę odpowiedzialną i zdarzenie, które go kończy. Dla zlecenia montażowego może to wyglądać tak.

Zwróć uwagę na status „Wstrzymane”. Bez niego zlecenie, które czeka na materiał, wisi w „W realizacji” i psuje każdy raport obciążenia. Status „Zamknięte” jako jedyny nie ma właściciela.

Przejścia, których nie ma w idealnym przebiegu

Poprawki po odbiorze: zlecenie wraca z „Do odbioru” do „W realizacji” z notatką, co poprawić. To osobne przejście z własnym zapisem w historii. Anulowanie: możliwe z każdego statusu poza „Zamknięte”, wymaga powodu i uprawnienia. Zmiana terminu: nie zmienia statusu, ale jest zdarzeniem z autorem, bo potem ktoś pyta, dlaczego termin się przesunął. Zmiana wykonawcy w trakcie: zdarzenie, które przenosi otwarte zadania i powiadamia obie osoby.

Nie zakładaj, że każdy użytkownik może zmieniać każdy status. Wykonawca zgłasza zakończenie, ale nie zamyka zlecenia. Handlowiec nie przenosi do „W realizacji”, jeśli nie ma akceptacji klienta. Takie reguły zapisujemy w aplikacji, a nie w instrukcji, której nikt nie czyta.

Każda rola potrzebuje innego widoku tych samych danych

Osoba wykonująca pracę chce zobaczyć swoje zadania na dziś, z adresem, dokumentami i telefonem do klienta. Koordynator potrzebuje obrazu obciążenia: kto ma ile otwartych zadań, co jest wstrzymane i dlaczego, co przekroczyło termin. Obsługa klienta szuka aktualnej informacji, którą może przekazać odbiorcy bez dzwonienia do wykonawcy. Właściciel chce wiedzieć, ile zleceń jest w każdym statusie i gdzie się zatrzymują.

Te widoki korzystają ze wspólnych danych, ale pokazują je inaczej. Wykonawca nie musi widzieć marży. Obsługa klienta nie musi widzieć wewnętrznych notatek koordynatora o problemach z podwykonawcą. Uprawnienia projektujemy razem z widokami, bo jedno wynika z drugiego.

Praca poza biurem

Jeśli wykonawcy pracują w terenie, widok na telefonie jest tym, którego używają najczęściej. Ma mieć trzy rzeczy na pierwszym ekranie: dzisiejsze zadania, przycisk do zgłoszenia zakończenia i dodawanie zdjęcia. Wszystko inne może być głębiej. Przeglądarka na telefonie wystarcza do większości zastosowań i tak projektujemy potrzebne widoki w zakresie projektu. Aplikacja instalowana ze sklepu, praca bez internetu i urządzenia specjalistyczne to osobne wymagania. Wpływają na zakres i wycenę, dlatego pytamy o nie na pierwszym etapie.

Praca bez zasięgu zasługuje na osobne zdanie. W piwnicy, w hali albo na budowie poza miastem telefon traci sieć. Jeśli wykonawca ma tam dodać protokół, aplikacja musi zapisać go lokalnie i wysłać później. To osobny mechanizm, droższy, niż się wydaje. Lepiej wiedzieć wcześniej, czy jest potrzebny, czy wystarczy, że wykonawca uzupełni dane w samochodzie.

Powiadomienia: komu i kiedy

Powiadomienie ma trafiać do osoby, która ma coś zrobić, w momencie, gdy może to zrobić. Wykonawca dostaje informację o nowym zadaniu i o zmianie zakresu w zadaniu, które ma otwarte. Koordynator dostaje informację o wstrzymaniu, o przekroczonym terminie i o zgłoszonym zakończeniu, bo po każdym z tych zdarzeń podejmuje decyzję. Handlowiec dostaje informację o akceptacji albo odrzuceniu wyceny przez klienta.

Nikt nie dostaje powiadomienia o każdej zmianie statusu w każdym zleceniu. Taki strumień po tygodniu jest ignorowany razem z tym jednym komunikatem, który był ważny. Zamiast tego koordynator ma poranne zestawienie: co jest wstrzymane, co po terminie, co czeka na jego decyzję. Kanał dobieramy do roli. Osoba w biurze czyta aplikację, osoba w terenie potrzebuje powiadomienia na telefonie, a klient maila.

Raporty, które ktoś czyta

Pierwsza wersja ma dwa albo trzy raporty, nie dwadzieścia. Zlecenia po terminie z osobą odpowiedzialną. Zlecenia wstrzymane z przyczyną i czasem oczekiwania. Obciążenie wykonawców na najbliższy tydzień. Każdy z nich odpowiada na pytanie, które właściciel albo koordynator zadaje dziś, dzwoniąc po firmie. Raport, który nie zmienia żadnej decyzji, nie wchodzi do zakresu, choćby był łatwy do zrobienia.

Które funkcje aplikacji do obsługi zleceń trafiają do pierwszej wersji

Lista funkcji w ofertach wykonawców bywa długa, a każda pozycja brzmi potrzebnie. Poniższa tabela porządkuje je według tego, co najczęściej jest w pierwszej wersji, a co dochodzi po kilku miesiącach użycia. Ostateczny podział zależy od Waszego opisu zlecenia.

Ostatni wiersz wymaga komentarza. Funkcje AI w aplikacji do zleceń mają sens dopiero wtedy, gdy statusy i odpowiedzialność działają bez nich. Model, który klasyfikuje zgłoszenia do źle zaprojektowanych kategorii, utrwala bałagan. Gdzie taka funkcja pomaga i co wymaga kontroli człowieka, opisujemy w poradniku o AI w aplikacji firmowej.

Oceń każdą funkcję jednym pytaniem: które zdarzenie z opisu zlecenia obsługuje. Jeśli nie da się wskazać zdarzenia, funkcja czeka na drugą wersję. Co wpływa na wycenę takiego zakresu, opisujemy w poradniku o kosztach aplikacji dla firmy.

Skąd przychodzi zlecenie i dokąd trafia informacja o zakończeniu

Zlecenie rzadko rodzi się w aplikacji do zleceń. Przychodzi z formularza na stronie, z CRM-u po wygranej ofercie, ze sklepu, z maila od stałego klienta. Po zakończeniu informacja idzie dalej: do księgowości po fakturę, do CRM-u jako historia klienta, do klienta jako potwierdzenie. Każde z tych połączeń to osobna decyzja, a brak decyzji oznacza przepisywanie.

Jedno źródło dla każdej informacji

Ustal, który system jest źródłem dla każdej danej. Dane klienta pochodzą z CRM-u, a aplikacja do zleceń je czyta, nie edytuje. Status realizacji pochodzi z aplikacji do zleceń, a CRM go wyświetla. Cena pochodzi z oferty albo z cennika, nigdy z ręcznego wpisu w zleceniu. Bez tej zasady ta sama sprawa ma po miesiącu trzy wersje w trzech miejscach i nikt nie wie, która obowiązuje.

CRM i obsługa zleceń to dwa różne narzędzia, które mogą dzielić dane. CRM porządkuje relacje i sprzedaż, obsługa zleceń skupia się na realizacji uzgodnionych prac. Najważniejsze jest miejsce przekazania: w którym momencie sprawa przestaje być ofertą i staje się zleceniem, i kto za ten moment odpowiada. W projekcie dla Nomatec CRM porządkuje obsługę zapytań i kontakt handlowy. Obsługa zleceń zaczyna się tam, gdzie kończy się sprzedaż, i w ofercie traktujemy ją jako osobny zakres. Jak zaprojektować przekazanie sprawy z zapytania do realizacji, opisujemy w poradniku o CRM-ie dla firmy usługowej.

Co sprawdzamy przed obietnicą integracji

Połączenie z innym systemem oceniamy na podstawie jego dokumentacji, nie na podstawie zapewnień sprzedawcy, że „ma API”. Sprawdzamy, czy system udostępnia interfejs, eksport albo inny dopuszczony sposób wymiany danych, jakie są limity i czy dostęp kosztuje osobno. Ustalamy też, co się dzieje, gdy drugi system nie odpowiada: rejestr błędów, ponowienia, informacja dla osoby odpowiedzialnej. Zakres takich prac opisujemy na stronie integracji systemów, a przepływ zapytania z formularza w poradniku o integracji strony z CRM-em.

Czy klient ma widzieć status

Dostęp klientów do zlecenia to osobny zakres. Panel klienta pokazuje wybrane informacje: status, termin, dokumenty do akceptacji, bez udostępniania całego narzędzia pracowników. Zakres widoczności, dokumenty i sposób logowania projektujemy oddzielnie od widoku zespołu. Panel ma sens, gdy klienci regularnie pytają o status albo akceptują etapy prac. Jeśli klient dzwoni dwa razy w roku, mail o zmianie statusu załatwia sprawę. Co powinien zawierać panel, żeby klienci z niego korzystali, opisujemy w poradniku o panelu klienta B2B, a zakres usługi na stronie paneli klienta i portali B2B.

Co jest inne w zależności od tego, czym się zajmujesz

Szkielet jest wspólny: zlecenie, zadania, dokumenty, akceptacje, statusy. Różnice leżą w tym, co jest zleceniem, kto je wykonuje i co kończy pracę.

Serwis i instalacje

Zlecenie to wizyta u klienta albo seria wizyt. Przychodzi telefonem, mailem albo z formularza, często z niepełnymi danymi. Potrzebne elementy: adres i dojazd, urządzenie z historią poprzednich wizyt, części użyte przy naprawie, protokół z podpisem albo zdjęciem, czas pracy. Statusy odzwierciedlają ruch w terenie: zaplanowane, w drodze, na miejscu, zakończone, wymaga drugiej wizyty. Wykonawca pracuje z telefonu, więc jego widok jest najważniejszy w całym projekcie.

Produkcja B2B

Zlecenie to zamówienie na partię albo detal, często z rysunkiem i specyfikacją. Zadania idą przez działy: technologia, zakupy materiału, produkcja, kontrola jakości, wysyłka. Dokumenty mają wersje, bo klient zmienia rysunek w trakcie. Akceptacja rysunku przez klienta jest zdarzeniem, bez którego produkcja nie powinna ruszyć. Raport obciążenia dotyczy maszyn i ludzi naraz. Tu najczęściej pojawia się integracja z systemem magazynowym albo księgowym, bo dane o materiale są już gdzieś zapisane.

Handel i dystrybucja

Zlecenie to zamówienie do skompletowania i dostarczenia. Zadania: rezerwacja towaru, kompletacja, pakowanie, transport, dokumenty dostawy. Wyjątki: brak towaru, częściowa dostawa, zwrot. Aplikacja często zaczyna się od integracji ze sklepem albo systemem sprzedaży, bo zamówienia już tam są. Wartość daje widoczność: kto kompletuje, co czeka na towar, co wyszło. Panel klienta ze statusem dostawy jest tu częstszy niż w innych branżach.

Usługi dla firm: agencje, biura, kancelarie

Zlecenie to projekt albo sprawa z etapami i akceptacjami klienta. Dokumenty są głównym produktem, więc wersje i akceptacje są w pierwszej wersji, nie później. Zadania idą między specjalistami, a koordynator pilnuje terminów. Czas pracy bywa podstawą rozliczenia, więc jego rejestracja wchodzi do zakresu wcześnie. Panel klienta z dokumentami do akceptacji pojawia się tu najczęściej, bo zastępuje maile z załącznikami w pięciu wersjach.

Firmy budowlane i remontowe

Zlecenie to budowa albo remont trwający tygodnie, z wieloma zadaniami i podwykonawcami. Dokumenty: umowa, kosztorys, protokoły odbioru etapów, zdjęcia z postępu, dziennik. Zmiany zakresu w trakcie są regułą, więc historia zmian z akceptacją inwestora jest w pierwszej wersji. Wykonawcy w terenie mają słaby zasięg, więc pytanie o pracę bez internetu pada tu najwcześniej. Widok dla kierownika budowy różni się od widoku dla biura, które pilnuje faktur podwykonawców.

Firmy z kilkoma oddziałami

Zlecenie wygląda tak samo w każdym oddziale, ale ludzie są różni. Jednolite statusy i pola pozwalają centrali porównywać oddziały i przenosić zlecenia między nimi. Uprawnienia są per oddział: koordynator w Poznaniu nie widzi zleceń z Zielonej Góry, chyba że je przejmuje. Raport dla centrali jest widokiem ponad oddziałami. Przeniesienie wykonawcy do innego oddziału na tydzień to scenariusz, który sprawdzamy przy odbiorze.

Przykład z biurka: klient zmienia zakres w trakcie realizacji

Najwięcej o potrzebnych funkcjach mówi sytuacja, która odbiega od planu. Opisujemy jeden scenariusz, który w różnych wersjach wraca w każdej rozmowie o zleceniach. Firma montująca instalacje przyjęła zlecenie od klienta biznesowego. Handlowiec uzgodnił zakres, klient zaakceptował wycenę, koordynator przydzielił ekipę. W drugim dniu montażu klient napisał do handlowca, że chce dołożyć jeszcze jedno pomieszczenie.

Przed aplikacją działo się to tak: handlowiec odpowiadał „jasne”, dzwonił do koordynatora, koordynator pisał ekipie na komunikatorze. Ekipa pracowała według wydrukowanej wyceny z pierwszego dnia. Materiału na dodatkowe pomieszczenie nie było. Faktura wychodziła według starej wyceny, a klient dzwonił z pytaniem, dlaczego brakuje pozycji. Nikt nie wiedział, kto i kiedy zgodził się na zmianę.

Krok pierwszy: zapisanie zmiany jako zdarzenia. Handlowiec wpisuje w karcie zlecenia propozycję zmiany zakresu z opisem i oznacza, kto musi podjąć decyzję. Zlecenie dostaje znacznik „zmiana w toku”, widoczny dla każdego, kto je otwiera.

Krok drugi: ocena wpływu. Koordynator sprawdza, czy ekipa ma czas i czy magazyn ma materiał. Wpisuje nowy termin i nowy koszt. Jeśli zmiana wymaga akceptacji klienta, handlowiec wysyła zaktualizowaną wycenę, a zlecenie przechodzi do „Czeka na klienta” z zachowaniem informacji, że montaż trwa.

Krok trzeci: zatwierdzenie i nowa wersja ustaleń. Po akceptacji aplikacja oznacza nową wycenę jako obowiązującą, a starą jako archiwalną. Historia zapisuje, kto zatwierdził i kiedy. Wykonawca dostaje powiadomienie i widzi w swoim zadaniu, co się zmieniło: dodatkowe pomieszczenie, dodatkowy materiał do odbioru z magazynu, nowy termin zakończenia.

Krok czwarty: odrzucenie. Jeśli klient nie akceptuje nowej wyceny, zmiana dostaje status „odrzucona”, zlecenie wraca do pierwotnego zakresu, a handlowiec informuje klienta. Ten krok jest równie ważny jak zatwierdzenie i równie często pomijany w projektach.

Krok piąty: zamknięcie i faktura. Do odbioru trafia zakres po zmianie. Faktura powstaje na podstawie obowiązującej wersji wyceny, a nie tej, którą ktoś wydrukował pierwszego dnia.

W jednej firmie wystarczy zatwierdzenie przez koordynatora, w innej potrzebna jest akceptacja klienta, w jeszcze innej zmiana powyżej ustalonej kwoty idzie do właściciela. To reguły, które zapisujemy w aplikacji na podstawie Waszego opisu. Ten scenariusz jest jednym z tych, które przechodzimy z zespołem przy odbiorze, na kontach z różnymi rolami.

Drugi scenariusz: brak protokołu przy odbiorze

Ta sama firma, inne zlecenie. Ekipa kończy montaż w piątek po południu i zgłasza zakończenie z telefonu. Protokołu nie ma, bo klient wyszedł wcześniej i nie podpisał. W poniedziałek biuro chce wystawić fakturę. Przed aplikacją faktura wychodziła bez protokołu, a spór z klientem o zakres zaczynał się tydzień później.

W aplikacji zgłoszenie zakończenia bez protokołu przenosi zlecenie do „Do odbioru” ze znacznikiem „brak protokołu”. Koordynator widzi to w porannym zestawieniu i decyduje. Wysyła protokół klientowi do podpisu zdalnie albo planuje krótką wizytę. Może też przyjąć zdjęcia z realizacji jako podstawę odbioru, jeśli umowa na to pozwala. Przejście do „Zamknięte” jest zablokowane do czasu, aż protokół albo zatwierdzona alternatywa znajdą się w dokumentach zlecenia. Faktura nie może wyjść wcześniej, bo integracja z księgowością czyta tylko zlecenia zamknięte. Jedna reguła w aplikacji zastąpiła tu kilka rozmów i jeden spór.

Jak odebrać aplikację: scenariusze zamiast liczby ekranów

Odbiór na podstawie prezentacji ekranów kończy się tym, że pierwszy wyjątek w realnej pracy zatrzymuje zespół. Odbieraj na scenariuszach. Każdy scenariusz ma opis sytuacji, oczekiwany wynik i rolę, na której koncie go przechodzisz. Kryteria odbioru ustalamy przy uzgadnianiu pierwszej wersji, więc nie ma sporu o to, co znaczy „działa”.

1. Zwykłe zlecenie od przyjęcia do zamknięcia, na koncie każdej roli po kolei. Każda osoba widzi tylko to, co powinna.
2. Zmiana osoby odpowiedzialnej w trakcie. Otwarte zadania przechodzą, obie osoby dostają powiadomienie, historia to zapisuje.
3. Brak dokumentu wymaganego do przejścia statusu. Aplikacja blokuje przejście i mówi, czego brakuje.
4. Cofnięcie akceptacji. Zlecenie wraca do właściwego statusu, nowa wersja dokumentu nie znika, historia pokazuje, kto cofnął.
5. Zmiana zakresu w trakcie realizacji według scenariusza z poprzedniej sekcji, z wariantem odrzucenia.
6. Wstrzymanie i wznowienie. Zlecenie wraca do statusu sprzed wstrzymania, a nie do początku.
7. Anulowanie zlecenia z zadaniami w toku. Wykonawcy dostają informację, dokumenty zostają, raport obciążenia się aktualizuje.
8. Praca z telefonu: dodanie zdjęcia i zgłoszenie zakończenia na słabym zasięgu.
9. Przeniesienie danych z arkusza na próbce zleceń z duplikatami i brakami. Sprawdzasz, co się stało z każdym wierszem.
10. Błąd integracji: drugi system nie odpowiada. Zlecenie da się zapisać, a ktoś dostaje informację o błędzie.
11. Użytkownik bez uprawnienia próbuje zmienić status. Aplikacja odmawia i niczego nie zapisuje.
12. Raport dla właściciela zgadza się z tym, co widać na liście zleceń.

Scenariusze przechodzi zespół, nie my. Osoba, która będzie codziennie przyjmować zlecenia, zauważy brak pola szybciej niż ktokolwiek z zewnątrz. Każda uwaga z odbioru dostaje numer i decyzję: poprawiamy przed startem, poprawiamy po starcie albo nie poprawiamy, bo nie było w zakresie.

Etapy współpracy i co wpływa na wycenę

Zakres aplikacji do obsługi zleceń budujemy w czterech etapach. Pierwsza wersja ma obsłużyć jedno zadanie od początku do końca, a jej zakres można sprawdzić przed rozbudową o kolejne działy.

Rozpisujemy przebieg

Przechodzimy przez jedno zwykłe zlecenie i kilka trudniejszych sytuacji. Ustalamy, kto decyduje, jakie dane przekazuje i co dziś opóźnia pracę. Od Ciebie potrzebujemy opisu z pierwszej sekcji tego poradnika i anonimowego przykładu arkusza albo obiegu zlecenia. Nie potrzebujesz specyfikacji.

Uzgadniamy pierwszą wersję

Wybieramy funkcje, role i dane. Ustalamy kryteria odbioru oraz to, co zostaje w obecnych narzędziach. Przygotowujemy zakres do indywidualnej wyceny. Na wycenę wpływa liczba ról i wyjątków, dokumenty, migracja oraz połączenia z innymi systemami. Osobno ustalamy utrzymanie, usługi zewnętrzne i późniejszą rozbudowę. Koszt potwierdzamy po rozpoznaniu zakresu.

Sprawdzamy z zespołem

Budujemy i testujemy kolejne elementy na uzgodnionych scenariuszach. Użytkownicy sprawdzają przekazywanie pracy, dokumenty, wyjątki oraz uprawnienia. Lista z poprzedniej sekcji jest podstawą tych testów.

Uruchamiamy i obserwujemy

Planujemy przeniesienie danych, dostęp zespołu i opiekę. Przed importem ustalamy identyfikatory, duplikaty i brakujące informacje. Próba migracji na części danych pozwala sprawdzić wynik przed przeniesieniem całości. Po uruchomieniu zbieramy uwagi i wybieramy usprawnienia na podstawie rzeczywistego użycia. Zespół otrzymuje 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.

Gotowy program czy własna aplikacja

Jeżeli gotowe narzędzie obsługuje Wasz proces bez kłopotliwych obejść, porównaj je z budową własnej aplikacji. Porównanie ma dotyczyć scenariuszy z sekcji o odbiorze, nie listy funkcji z ulotki. Dedykowana aplikacja ma sens przy specyficznym obiegu, uprawnieniach albo integracjach, których gotowy program nie odtworzy. Jak przeprowadzić takie porównanie, opisujemy w poradniku o gotowym i dedykowanym systemie. Zasady są te same dla CRM-u i dla zleceń.

Pytania do wykonawcy i najczęstsze błędy

O co zapytać przed podpisaniem oferty

• Na podstawie czego powstała lista funkcji: naszego opisu zlecenia czy szablonu.
• Jak aplikacja obsługuje wstrzymanie, poprawki po odbiorze, anulowanie i zmianę zakresu w trakcie.
• Kto może zmieniać który status i gdzie są zapisane te reguły.
• Jak wyglądają wersje dokumentów i skąd wykonawca wie, która obowiązuje.
• Jak wygląda widok na telefonie i co się dzieje bez zasięgu.
• Jakie integracje są w zakresie, na podstawie jakiej dokumentacji zostały ocenione i co się dzieje przy błędzie.
• Jak przeniesiecie dane z arkusza, jak potraktujecie duplikaty i jak sprawdzimy wynik.
• Jakie są kryteria odbioru i czy możemy przejść scenariusze na kontach różnych ról.
• Co dostajemy przy przekazaniu: kod, dokumentację, dostępy, kopie zapasowe.
• Jak wygląda opieka po starcie, zgłaszanie problemów i dodawanie kolejnych funkcji.

Błędy, które kosztują najwięcej

• Przeniesienie arkusza jeden do jednego. Kolumny stają się polami, a problem z odpowiedzialnością i statusami zostaje. Sam import tabel niczego nie porządkuje.
• Projektowanie wyłącznie idealnego przebiegu. Pierwsze wstrzymane zlecenie ląduje w mailu, a po miesiącu połowa spraw jest obsługiwana obok aplikacji.
• Statusy bez właściciela. „W realizacji” bez osoby odpowiedzialnej oznacza, że nikt nie realizuje.
• Wszystkie funkcje w pierwszej wersji. Zespół dostaje narzędzie, w którym połowa ekranów nie dotyczy jego pracy, i przestaje go używać.
• Dokumenty luzem, poza zleceniem. Po pół roku nikt nie wie, która wycena obowiązuje, tak samo jak w mailach.
• Brak widoku dla wykonawcy w terenie. Aplikacja projektowana z perspektywy biura kończy jako narzędzie, do którego biuro przepisuje dane z telefonów.
• Integracja obiecana przed sprawdzeniem dokumentacji. Okazuje się, że system udostępnia eksport raz dziennie, a proces potrzebował danych na bieżąco.
• Odbiór na prezentacji. Zespół widzi ekrany i się zgadza, a pierwszy tydzień pracy pokazuje brak pola, bez którego nie da się przyjąć zlecenia.
• Brak osoby po stronie firmy, która decyduje o zmianach po starcie. Uwagi zespołu nie mają adresata i aplikacja zastyga w wersji z dnia uruchomienia.

Słownik pojęć z oferty i z rozmów o zakresie

• Zlecenie. Jednostka pracy uzgodniona z klientem, z zakresem, terminem i osobą odpowiedzialną za całość. Ma jedną kartę i jedną historię.
• Zadanie. Czynność w ramach zlecenia, przypisana do jednej osoby, z warunkiem zakończenia. Zlecenie może mieć wiele zadań.
• Status. Etap, na którym jest zlecenie, z osobą odpowiedzialną za następny krok i zdarzeniem, które go kończy.
• Przejście. Zmiana statusu z regułą, kto może jej dokonać i co musi być spełnione. Zapisuje się w historii.
• Wyjątek. Sytuacja poza idealnym przebiegiem: wstrzymanie, poprawki, anulowanie, zmiana zakresu. Obsługa wyjątków decyduje o przydatności aplikacji.
• Historia zlecenia. Zapis wszystkich zdarzeń: kto, kiedy, co zmienił. Podstawa odpowiedzi na pytanie, dlaczego termin się przesunął.
• Wersja dokumentu. Kolejne wydanie tego samego dokumentu, z datą i autorem. Jedna wersja jest oznaczona jako obowiązująca.
• Akceptacja. Zdarzenie potwierdzenia przez konkretną osobę: wyceny, projektu, odbioru. Ma datę i autora, może być cofnięta.
• Rola. Zestaw uprawnień i widoków przypisany do funkcji w firmie: wykonawca, koordynator, obsługa klienta, właściciel. Jedna osoba może mieć kilka ról.
• Widok. Sposób pokazania wspólnych danych dla jednej roli: moje zadania, obciążenie zespołu, sprawy wymagające reakcji.
• Źródło danych. System, w którym dana informacja jest edytowana. Inne systemy ją czytają. Dla danych klienta to zwykle CRM, dla statusu realizacji aplikacja do zleceń.
• Integracja. Połączenie aplikacji z innym systemem, ocenione na podstawie jego dokumentacji, z ustalonym kierunkiem danych i obsługą błędów.
• Migracja. Przeniesienie danych z arkuszy albo poprzedniego narzędzia, z ustalonymi identyfikatorami, duplikatami i sposobem sprawdzenia wyniku.
• Kryteria odbioru. Lista scenariuszy z oczekiwanym wynikiem, uzgodniona przed budową, według której zespół sprawdza aplikację.

Co po wdrożeniu: dane, dostępy, rozwój

Aplikacja do zleceń zaczyna żyć w dniu, w którym zespół przestaje używać arkusza. Kilka rzeczy trzeba zaplanować przed tym dniem, bo potem nie ma na nie czasu.

Pierwsze tygodnie

Przez pierwsze tygodnie zbieramy uwagi z codziennego użycia i wybieramy usprawnienia na podstawie rzeczywistej pracy, nie pomysłów z odbioru. Najczęstsze uwagi dotyczą brakującego pola, zbyt długiej listy statusów i powiadomień, których jest za dużo. Wyznacz jedną osobę, która zbiera uwagi od zespołu i przekazuje nam jedną listę. Uwagi w pięciu mailach od czterech osób zawierają sprzeczności.

Dostępy i konta

Ustal, kto zakłada konta nowym pracownikom i kto wyłącza konta odchodzącym. Konto byłego pracownika z dostępem do zleceń i danych klientów to częstsze zagrożenie niż włamanie. Dostępy administracyjne trzymaj u dwóch osób, nie u jednej i nie u wszystkich.

Dane i okres przechowywania

Dokumenty i historia zleceń rosną. Zasady dostępu i okres przechowywania określamy przed wdrożeniem, ale po roku sprawdź, czy są stosowane. Jeśli w zleceniach są dane osobowe klientów, okres przechowywania wynika z Waszych obowiązków jako administratora danych. Tekst rozporządzenia jest na EUR-Lex, a decyzję o okresach podejmij z osobą, która zajmuje się u Was RODO. Kopie zapasowe i miejsce utrzymania ustalamy w ofercie. Kto sprawdza, czy kopię da się odtworzyć, ustalacie Wy.

Rozwój na podstawie użycia

Kolejne funkcje dodajemy wtedy, gdy zespół zgłasza konkretny brak, nie wtedy, gdy pojawia się pomysł. Panel klienta ma sens, gdy obsługa klienta liczy pytania o status. Integracja z księgowością ma sens, gdy ktoś liczy przepisane faktury. Raport ma sens, gdy ktoś go czyta i podejmuje na jego podstawie decyzję. Zasady opieki, czas reakcji i sposób zgłaszania problemów są w ofercie, więc wiadomo, do kogo pisać.

TL;DR

• Zacznij od opisu jednego zlecenia z wyjątkami. Z niego wynikają statusy, role i funkcje.
• Rozdziel zlecenie, zadanie, dokument i akceptację. Każde ma innego właściciela i inną historię.
• Każdy status ma osobę odpowiedzialną i zdarzenie, które go kończy. Wstrzymanie i poprawki to osobne przejścia.
• Widoki projektuj per rola. Widok wykonawcy na telefonie jest najważniejszy, jeśli praca jest w terenie.
• Do pierwszej wersji trafiają funkcje, które obsługują zdarzenia z opisu. Reszta czeka na użycie.
• Ustal źródło dla każdej informacji i sprawdź integracje w dokumentacji przed obietnicą.
• Odbieraj na scenariuszach z kontami różnych ról, nie na prezentacji ekranów.
• Po starcie jedna osoba zbiera uwagi, a kolejne funkcje dochodzą na podstawie użycia.

FAQ