Jedno zadanie, kilka zespołów i wspólny wynik
Organizacja społeczna prowadzi cykl zajęć. Jeden zespół ustala terminy, drugi przygotowuje materiały, trzeci zbiera dokumenty potrzebne do rozliczenia. Pod koniec projektu okazuje się, że potwierdzenie wykonania jest w jednej skrzynce, faktura w drugiej, a informacja o zmianie harmonogramu została przekazana podczas rozmowy. Nikt nie ukrywa dokumentów. Po prostu każda osoba widzi tylko fragment pracy.
System wspierający organizację może połączyć działania, osoby odpowiedzialne, wydatki i potrzebne potwierdzenia. Powinien też pokazać, kiedy sprawa wymaga decyzji i kto ma ją podjąć. Celem nie jest tworzenie dodatkowego raportu dla samego raportu. Chodzi o to, by osoba prowadząca zadanie potrafiła wyjaśnić, co zostało wykonane i jakie informacje wymagają jeszcze sprawdzenia.
Poniższy przykład jest hipotetyczny. Nie każda organizacja korzysta z dotacji, a warunki finansowania i rozliczenia zależą od konkretnej umowy, programu oraz właściwych przepisów. Zasady zapisane w aplikacji trzeba sprawdzić dla danego zadania. Sam system nie rozstrzyga, czy wydatek spełnia warunki finansowania.
Co organizacja chce wykonać
Zacznijcie od rezultatu zadania i jego podziału na działania. Dla cyklu zajęć mogą to być przygotowanie miejsca, ustalenie prowadzących, przekazanie materiałów oraz potwierdzenie przebiegu poszczególnych spotkań. Każdy element powinien mieć osobę odpowiedzialną i zrozumiały koniec. Sam napis „w realizacji” nie mówi, czy sala została potwierdzona albo czy prowadzący zna termin.
Przy zadaniu uczestniczącym w większym projekcie zapiszcie powiązanie z harmonogramem i źródłem ustaleń. Jeśli termin zmienia się po uzgodnieniu z partnerem, potrzebna jest informacja, kto podjął decyzję i kogo należy powiadomić. Nie każda zmiana wymaga tej samej procedury, ale każdy zainteresowany zespół powinien wiedzieć, która wersja planu jest aktualna.
Warto pokazać zależności między działaniami. Materiały mogą być potrzebne przed pierwszym spotkaniem, a ich przygotowanie zależeć od zaakceptowanej treści. Jeżeli jedno zadanie się opóźnia, osoba prowadząca projekt powinna widzieć wpływ na kolejne kroki. To pytanie o rzeczywisty przebieg pracy, podobne do tego, które opisujemy przy obsłudze zleceń w firmie usługowej.
Przy kilku lokalizacjach uzgodnijcie wspólne nazwy etapów, pozostawiając miejsce na różnice. Zespół w jednej miejscowości może współpracować z innym partnerem niż zespół w drugiej. O łączeniu wspólnych zasad z lokalnym sposobem pracy przeczytacie w artykule o systemie dla wielu oddziałów.
Przy współpracy kilku zespołów warto wskazać też miejsce, w którym zbierane są decyzje dotyczące całego projektu. Osoba prowadząca pojedyncze zajęcia nie powinna szukać zmienionego terminu w kilku wersjach planu. Zespół koordynujący może zachować uzasadnienie zmiany i przekazać zainteresowanym aktualny harmonogram. Zakres widocznych informacji powinien odpowiadać zadaniu danej osoby.
Odpowiedzialność i przekazanie sprawy
Każde działanie potrzebuje właściciela, ale nie każda osoba musi wykonywać je samodzielnie. Koordynator może odpowiadać za termin, a współpracownik przygotować materiał. Ustalcie, kto potwierdza wynik i komu przekazuje pytania. Jeśli potrzebna jest decyzja zarządu lub partnera, zaznaczcie to w planie przed rozpoczęciem pracy.
Zaplanujcie zastępstwo. Organizacje często pracują z niewielkimi zespołami oraz osobami zaangażowanymi w różnym wymiarze. Gdy jedna osoba jest nieobecna, następna powinna znaleźć aktualny stan i uzgodniony kanał kontaktu. Nie potrzebuje dostępu do całej historii prywatnej korespondencji. Potrzebuje informacji niezbędnej do kontynuowania zadania.
Przy współpracy z zewnętrznym wykonawcą opiszcie rezultat, termin i osobę odbierającą pracę. Jeśli zakres się zmieni, potrzebna jest czytelna propozycja oraz decyzja zgodna z warunkami współpracy. System może zachować historię, ale nie powinien przedstawiać niezatwierdzonej propozycji jako zaakceptowanego zadania.
Do każdej przeszkody dopiszcie następny krok. Brak odpowiedzi partnera, niedostępna sala i opóźniony materiał wymagają innych działań. Przydatne zasady przypisywania odpowiedzialności za wyjątki omawiamy w artykule o monitorowaniu automatyzacji.
Jeśli organizacja współpracuje z wolontariuszami, sposób przydzielenia zadań powinien wynikać z rzeczywistych uzgodnień i dostępności tych osób. Aplikacja może pokazać prośbę oraz potwierdzony zakres pomocy, ale nie powinna traktować braku odpowiedzi jako zgody. Ustalcie, kto prowadzi kontakt i jak zgłasza się zmianę planów przed rozpoczęciem działania.
Budżet i dokumenty w kontekście zadania
Uzgodnijcie, co oznaczają planowany koszt, zaakceptowany wydatek i rozliczona pozycja. Organizacja może potrzebować wszystkich tych informacji, ale nie powinny być sumowane bez wyjaśnienia. Przy pozycji zapiszcie zadanie, okres, źródło finansowania oraz osobę, która potwierdza przypisanie. Sposób ewidencji trzeba dopasować do zasad obowiązujących w danym projekcie. Jeżeli realizacja wymaga nowego zakupu, warto osobno zaplanować wniosek zakupowy i drogę jego akceptacji zgodnie z zasadami projektu.
Jeżeli jeden dokument dotyczy kilku działań lub źródeł finansowania, potrzebna jest uzgodniona metoda podziału i możliwość wyjaśnienia decyzji. Nie należy automatycznie dzielić kwoty według liczby zespołów tylko dlatego, że systemowi łatwo to policzyć. Osoba odpowiedzialna powinna widzieć podstawę podziału i wiedzieć, jak zgłosić korektę.
Przy dokumentach ustalcie miejsce przechowywania, zakres dostępu i sposób powiązania z pozycją budżetu. Czy do sprawy wystarczy numer dokumentu, czy potrzebna jest jego kopia? Kto może ją otworzyć i jak długo jest potrzebna? Odpowiedzi zależą od przyjętej procedury oraz rodzaju danych, dlatego warto uzgodnić je z osobami prowadzącymi rozliczenie i odpowiedzialnymi za informacje.
Jeśli projekt korzysta z finansowania zewnętrznego, porównajcie plan z aktualną umową i dokumentacją konkretnego programu. Przykładem jest regulamin programu NOWEFIO 2026, który opisuje warunki realizacji i rozliczenia dofinansowanych zadań. Nie oznacza to, że ten sam wzór i terminy stosują się do każdej organizacji. W razie zmiany warunków ktoś powinien ocenić wpływ na zapisane zadania oraz budżet.
Przy zmianie budżetu zachowajcie poprzednią wersję oraz wskazanie, kto i na jakiej podstawie zatwierdził korektę. Jeżeli wymagana jest zgoda podmiotu finansującego, status w aplikacji powinien odzwierciedlać rzeczywisty przebieg uzgodnień. Wysłanie prośby i otrzymanie decyzji są różnymi zdarzeniami. Do czasu potwierdzenia osoba prowadząca zadanie potrzebuje widzieć, że zmiana nadal oczekuje na rozstrzygnięcie.
W przypadku dokumentu dotyczącego kilku okresów sprawdźcie, jaką część pracy obejmuje oraz kto potwierdza jego przypisanie. Jeśli informacje są niepełne, lepiej pozostawić sprawę do wyjaśnienia niż wprowadzić domyślne wartości. Osoba rozliczająca powinna mieć możliwość odnalezienia źródła i zapisania powodu korekty bez ujawniania danych, których nie potrzebuje do wykonania zadania.
Potwierdzenie postępu bez zbędnych danych
Zespół potrzebuje wiedzieć, czy działanie się odbyło i co pozostało do wykonania. Forma potwierdzenia powinna wynikać z celu oraz warunków zadania. W jednym projekcie wystarczy zatwierdzony protokół, w innym potrzebny będzie dodatkowy dokument uzgodniony z finansującym. Nie zbierajcie zdjęć lub danych uczestników tylko dlatego, że formularz ma miejsce na załącznik.
Ustalcie, kto może zatwierdzić postęp oraz co dzieje się po zgłoszeniu błędu. Jeśli liczba spotkań w planie różni się od informacji prowadzącego, zadanie wymaga wyjaśnienia. System powinien zachować źródło i osobę odpowiedzialną za korektę, a nie automatycznie wybrać większą lub nowszą liczbę.
Przy kilku źródłach danych ustalcie znaczenie każdej wartości. Liczba zapisanych osób, liczba obecnych oraz liczba osób, które ukończyły działanie, odpowiadają na różne pytania. Przed przygotowaniem raportu uzgodnijcie definicję, okres i sposób liczenia. O takich decyzjach piszemy w tekście o definicjach wskaźników dashboardu.
Powiadomienie o braku dokumentu powinno trafiać do osoby, która może go dostarczyć lub wyjaśnić problem. Jeśli dokument pozostaje po stronie partnera, zespół organizacji potrzebuje widzieć stan prośby i kolejny termin kontaktu. Wysłanie przypomnienia nie jest jeszcze potwierdzeniem, że brak został usunięty.
Przy zbieraniu informacji od uczestników ograniczcie formularz do pytań potrzebnych dla uzgodnionego celu. Osobno ustalcie, kto ma dostęp do odpowiedzi i jakie dane są potrzebne w raporcie zbiorczym. Widok postępu może pokazywać liczbę potwierdzonych działań bez prezentowania szczegółów każdej osoby wszystkim członkom zespołu. Zakres danych i zasady dostępu powinny zostać ocenione dla konkretnego projektu.
Połączenie z istniejącymi narzędziami
Organizacja może korzystać z osobnego narzędzia księgowego, kalendarza oraz systemu zapisów. Przed integracją wskażcie dane przekazywane między nimi i osobę odpowiedzialną za każdą informację. Przykładowo kalendarz może pokazywać termin, ale decyzja o jego zmianie pozostaje w systemie prowadzenia zadania. Szczegóły zależą od rzeczywistych możliwości narzędzi i warunków dostępu.
W artykule o źródle danych w integracji wyjaśniamy, dlaczego trzeba uzgodnić obowiązujący zapis. Przy przekazywaniu zmian zaplanujcie również błąd połączenia. Osoba prowadząca projekt powinna wiedzieć, czy zmiana została przyjęta, czeka na ponowienie czy wymaga ręcznego wyjaśnienia.
Nie każda organizacja potrzebuje automatycznej wymiany od pierwszego dnia. W niektórych sytuacjach kontrolowany eksport lub ręczne potwierdzenie będzie łatwiejsze do sprawdzenia. Warto porównać ilość pracy, ryzyko pomyłki oraz możliwość utrzymania rozwiązania. O wyborze pierwszego zakresu piszemy w artykule o MVP aplikacji.
Jeżeli w przyszłości planujecie automatyzację, zachowajcie identyfikatory spraw i historię zatwierdzeń. Dzięki temu łatwiej sprawdzić, czy informacja przekazana do kolejnego narzędzia dotyczy właściwego zadania. O samej wymianie wiadomości przeczytacie także przy API i webhookach.
Gdy informacja trafia do kolejnego narzędzia ręcznie, zapiszcie osobę odpowiedzialną, datę przekazania oraz sposób sprawdzenia wyniku. Ręczny krok może być właściwy, jeśli zespół potrafi go regularnie wykonać i wyjaśnić rozbieżność. Problemem jest sytuacja, w której nikt nie wie, czy zadanie zostało przekazane, a oba narzędzia pokazują różne stany.
Próba na jednym fikcyjnym projekcie
Przygotujcie przykładowe zadanie z kilkoma działaniami, budżetem oraz osobami odpowiedzialnymi. Prześledźcie zmianę terminu, opóźniony dokument, korektę kosztu i zastępstwo koordynatora. Sprawdźcie, czy osoba prowadząca może odpowiedzieć, które działania zakończono i jakie informacje nadal wymagają potwierdzenia.
Do próby zaproście osoby wykonujące codzienną pracę oraz osobę prowadzącą rozliczenie. Poproście je o odnalezienie tego samego dokumentu i wyjaśnienie, do którego zadania należy. O obserwacji takich czynności piszemy przy testowaniu prototypu z pracownikami. Wynik pomoże poprawić nazwy pól i sposób przekazania sprawy.
Zapiszcie ograniczenia testu. Fikcyjne dane nie potwierdzają poprawności istniejącej ewidencji ani zgodności konkretnego rozliczenia z umową. Przygotujcie kryteria odbioru dla wersji systemu i wskażcie osoby odpowiedzialne za sprawdzenie rzeczywistego procesu przed wdrożeniem.
Jeżeli planujesz narzędzie dla organizacji społecznej, zobacz zakres oprogramowania na zamówienie i skontaktuj się z Archifutura. W briefie opisz działanie, uczestniczące zespoły, sposób potwierdzania postępu i pytanie, na które obecne dokumenty nie odpowiadają. Przykład bez danych uczestników wystarczy do rozpoczęcia rozmowy.
Po teście ustalcie, co poprawicie przed kolejną próbą i kto podejmie decyzję o wdrożeniu. Jeśli potrzebny dokument lub dostęp do systemu partnera nie był dostępny, zaznaczcie to w wynikach. Warto również zaplanować krótkie przekazanie instrukcji osobie zastępującej koordynatora, aby mogła samodzielnie odnaleźć otwarte sprawy.
Źródła i dokumentacja
Materiały sprawdzone przy opracowaniu tekstu. Przy wyborze usługi lub technologii potwierdzamy warunki dla konkretnego projektu.








