Aplikacja dla zakładu gastronomicznego: jak zaplanować przygotowanie dań na kilka lokalizacji

Plan kuchni zaczyna się w lokalach

Centralna kuchnia przygotowuje dania dla kilku punktów. Jeden lokal potrzebuje więcej porcji na popołudnie, drugi zmienia zamówienie po zamknięciu porannego planu, a osoba pakująca widzi wydrukowaną listę sprzed ostatniej korekty. Różnica między planem a rzeczywistą ilością wychodzi na jaw dopiero przy odbiorze.

Aplikacja może połączyć zapotrzebowanie lokali, plan przygotowania, rzeczywiste ilości i potwierdzenie przekazania. Nie przewidzi samodzielnie wszystkich zmian ani nie zastąpi zasad bezpieczeństwa żywności. Pomaga za to wskazać aktualną wersję planu oraz osobę, która podejmuje decyzję, gdy potrzeby lokalu i możliwości kuchni się rozchodzą.

Przykład jest fikcyjny i dotyczy organizacji pracy. Wymagania dotyczące żywności, dokumentacji, transportu i informacji o produktach trzeba sprawdzić dla konkretnej działalności oraz właściwej jurysdykcji. Zakres danych w systemie powinny uzgodnić osoby odpowiedzialne za bezpieczeństwo i prowadzenie zakładu.

Zapotrzebowanie musi mieć wersję i termin

Każdy lokal powinien móc wskazać, czego potrzebuje, na jaki termin i w jakiej jednostce. Jedna pozycja może oznaczać porcję, opakowanie lub składnik wykorzystywany na miejscu. Uzgodnijcie nazwy oraz jednostki przed automatycznym sumowaniem. Liczba bez informacji o jednostce może być poprawna matematycznie, ale bezużyteczna przy pakowaniu. Inny przebieg ma zbieranie wyborów poszczególnych odbiorców przed wspólnym wydaniem. Omawiamy go w artykule o zamówieniach zbiorowych w gastronomii.

Ustalcie, kiedy lokal przekazuje plan, kiedy kuchnia go przegląda oraz kto może go zmienić po rozpoczęciu przygotowań. Wczesna propozycja i zatwierdzone zapotrzebowanie powinny mieć różne stany. Jeżeli lokal prosi o korektę po uzgodnionym czasie, system powinien pokazać ją osobie podejmującej decyzję, a nie po cichu nadpisać listę przekazaną kuchni.

Jeśli odpowiedź z kuchni różni się od prośby, lokal potrzebuje widzieć zarówno pierwotne zapotrzebowanie, jak i uzgodniony wynik. Brak możliwości przygotowania części porcji może wymagać decyzji o zamienniku, zmianie ilości albo innym terminie. Warunki takiej decyzji ustalają uczestnicy procesu. Aplikacja powinna zachować ich odpowiedź i wskazać, która wersja obowiązuje.

Przy kilku punktach uzgodnijcie wspólne nazwy oraz osoby odpowiedzialne za lokalne zamówienia. O relacji między wspólnymi zasadami a różnicami lokalnymi piszemy w artykule o systemie dla wielu oddziałów. Nie każdy lokal musi mieć identyczny harmonogram dostaw.

Warto także ustalić sposób zgłoszenia zamknięcia lokalu lub zmiany godzin pracy. Jeśli punkt nie będzie przyjmować dostawy, kuchnia potrzebuje tej informacji przed przygotowaniem planu. Osoba odpowiedzialna powinna wskazać, którego terminu dotyczy zmiana oraz czy pozostałe zamówienia nadal obowiązują. Taki zapis pomaga uniknąć poprawiania całego harmonogramu na podstawie jednej wiadomości.

Plan przygotowania to propozycja pracy

Kuchnia może zestawić potwierdzone potrzeby z dostępnymi składnikami, personelem i czasem. Wynik powinien wskazywać, co zaplanowano oraz które pozycje wymagają decyzji. Jeśli brakuje informacji o dostawie składnika, system nie powinien udawać pewności. Osoba planująca potrzebuje widzieć brak i sposób jego wyjaśnienia.

Przy każdej partii lub serii pracy ustalcie identyfikator używany w zakładzie, planowany produkt, ilość oraz osoby odpowiedzialne za kolejne etapy. Szczegółowość zależy od procesu. Jedna lista dla całego dnia może być zbyt ogólna, jeśli różne lokale otrzymują inne zestawy albo przygotowanie przebiega w kilku turach.

Zaplanowana ilość nie jest jeszcze ilością faktycznie przygotowaną. Po zakończeniu pracy zespół powinien móc zapisać rzeczywisty wynik i różnicę, na przykład mniejszą liczbę opakowań niż planowano. Nie zakładajcie przyczyny tej różnicy bez potwierdzenia. Potrzebny jest właściciel decyzji o zmianie podziału między lokalami.

Podobne rozróżnienie planu i rzeczywistej pracy opisujemy w artykule o zleceniach i przestojach produkcyjnych. W gastronomii dodatkowe znaczenie mają właściwe dla produktu warunki oraz informacje potrzebne do bezpiecznego przekazania żywności.

Przy planowaniu pracy zapytajcie również, kto może potwierdzić zakończenie danego etapu. Jedna osoba może przygotować składniki, a inna odpowiadać za pakowanie i przekazanie do lokali. Aktualny plan powinien pokazywać powiązanie tych zadań oraz brak, który uniemożliwia dalszą pracę. Nie każda czynność wymaga osobnego powiadomienia, ale ważne przeszkody potrzebują właściciela.

Składniki i pochodzenie informacji

Przed integracją z magazynem ustalcie, skąd pochodzi informacja o składnikach oraz kiedy jest aktualizowana. System kuchni może pokazać planowane zużycie, ale rzeczywisty stan wymaga potwierdzonego źródła. Jeśli dostawa nie została przyjęta lub zapis jeszcze nie dotarł, osoba planująca powinna widzieć ograniczenie zamiast automatycznie traktować składnik jako dostępny.

Komisja Europejska opisuje identyfikowalność żywności jako możliwość śledzenia jej na etapach produkcji, przetwarzania i dystrybucji. Zakres obowiązków i szczegółowych zapisów należy ocenić dla konkretnej działalności. Projekt aplikacji może pomóc połączyć informacje o źródle, przygotowaniu i przekazaniu, ale sam zapis w systemie nie potwierdza spełnienia wszystkich wymagań.

Uzgodnijcie, jakie identyfikatory oraz dokumenty są rzeczywiście używane w zakładzie i kto sprawdza ich poprawność. Jeśli informacja o składniku pochodzi od dostawcy, a inna z wewnętrznego katalogu, potrzebny jest sposób rozstrzygnięcia rozbieżności. O odpowiedzialności za dane w kilku narzędziach piszemy w artykule o źródle danych w integracji.

Nie kopiujcie automatycznie informacji o składnikach z podobnego produktu. Zmiana receptury lub dostawy może mieć znaczenie dla informacji przekazywanej dalej. Aktualne dane i sposób ich zatwierdzania powinny być częścią procesu prowadzonego przez osoby odpowiedzialne, a nie domysłem aplikacji opartym na nazwie dania.

Przekazanie do właściwego lokalu

Przy pakowaniu wskażcie lokal, produkt, ilość oraz uzgodniony czas przekazania. Jeśli jedna pozycja jest przygotowywana w kilku turach, system powinien pokazać, która część jest gotowa, a która nadal czeka. Nie oznaczajcie całego zamówienia jako zakończonego tylko dlatego, że wydrukowano pierwszą etykietę.

Osoba wydająca potrzebuje potwierdzić, co rzeczywiście przekazano i komu. Lokal powinien móc porównać otrzymaną ilość z uzgodnionym planem oraz zgłosić różnicę. Brak potwierdzenia po stronie odbiorcy nie oznacza automatycznie braku dostawy. Może oznaczać, że informacja nie została jeszcze zapisana albo przekazana między narzędziami.

Przy rozbieżności zapiszcie osobę odpowiedzialną za wyjaśnienie i następny krok. Jeżeli lokal zgłasza brak opakowania, a kuchnia widzi potwierdzenie wydania, obie informacje są potrzebne do rozmowy. System nie powinien sam zmieniać stanu na korzyść jednej strony bez ustalonej reguły. O przekazywaniu spraw wymagających decyzji piszemy w artykule o monitorowaniu procesów.

Transport może być organizowany wewnętrznie lub przez partnera. Ustalcie, jakie informacje musi otrzymać osoba przewożąca, jak potwierdza przekazanie oraz kto reaguje na opóźnienie. Warunki przewozu żywności trzeba określić dla produktu i właściwych wymagań. Nie podajemy uniwersalnego czasu ani temperatury dla wszystkich dań.

Jeżeli po odbiorze lokal stwierdzi pomyłkę w oznaczeniu, ustalcie sposób wstrzymania dalszego użycia i przekazania sprawy osobie odpowiedzialnej. Konkretne postępowanie musi wynikać z procedur zakładu oraz rodzaju produktu. System może zachować informację o zgłoszeniu i decyzji, ale nie powinien sam rozstrzygać bezpieczeństwa żywności na podstawie niepełnego opisu.

Zmiana planu w trakcie dnia

Lokal może zgłosić zmianę zapotrzebowania, gdy przygotowania już trwają. System powinien pokazać, do której wersji planu odnosi się prośba i kto może ją przyjąć. Jeżeli część pracy została wykonana, nie wystarczy zastąpić starej liczby nową. Potrzebna jest decyzja, co zrobić z przygotowaną ilością i jak poinformować pozostałe osoby.

Zdarza się również, że kuchnia musi zaproponować inną ilość. Lokal powinien wiedzieć, co pozostaje bez zmian, a co wymaga potwierdzenia. Wysłanie wiadomości nie oznacza jeszcze, że pracownik lokalu ją przeczytał i zaakceptował. Warto oddzielić propozycję, odpowiedź oraz ostateczne przekazanie.

Jeśli plan zmienił się poza aplikacją, uzgodnijcie sposób zapisania wyniku. Po rozmowie telefonicznej osoba odpowiedzialna powinna móc uzupełnić kontekst przy właściwym zadaniu. Historia ma pomagać następnym pracownikom zrozumieć aktualny stan, a nie zmuszać ich do przeszukiwania kilku prywatnych rozmów.

Przy pracy między systemami przydatne jest również rozróżnienie wysłanej zmiany i potwierdzenia jej przyjęcia. Takie etapy opisujemy w artykule o API i webhookach. Jeśli połączenie nie działa, potrzebny jest plan kontaktu oraz późniejszego uzgodnienia stanu.

Informacje dla lokalu i decyzje po odbiorze

Lokal potrzebuje wiedzieć, co otrzymał, jakie informacje o produkcie są właściwe dla tej dostawy i do kogo zgłosić problem. Zakres informacji powinien zostać ustalony dla konkretnej działalności oraz aktualnych wymagań. System może ułatwić odnalezienie dokumentu, ale nie zastępuje sprawdzenia jego treści przez osoby odpowiedzialne.

Jeżeli po przekazaniu pojawi się informacja wymagająca sprawdzenia określonej partii, uzgodnione powiązania mogą pomóc ustalić, które lokale otrzymały produkt. Potrzebna jest jednak ocena kompletności zapisów oraz decyzja właściwych osób. Nie należy obiecywać pełnego odnalezienia wszystkich produktów, jeśli proces wcześniej nie rejestrował potrzebnych danych.

Raport dla koordynatora może pokazywać ilość planowaną, przygotowaną i potwierdzoną przy odbiorze. Przed porównaniem ustalcie definicje, jednostki oraz sposób uwzględnienia korekt. O takich decyzjach piszemy w artykule o definicjach wskaźników. Jedna liczba „zrealizowane” nie wyjaśni, na którym etapie powstała różnica.

Jeśli lokal zgłasza problem z jakością, powiążcie sprawę z produktem i dostępnymi informacjami, a następnie przekażcie ją osobie odpowiedzialnej. Nie przypisujcie automatycznie przyczyny na podstawie samego statusu. O przekazywaniu zgłoszeń piszemy także w artykule o obsłudze zleceń w firmie usługowej.

Próba z kuchnią i lokalami

Przygotujcie fikcyjny plan dla dwóch lokali oraz kilka pozycji w różnych jednostkach. Prześledźcie zgłoszenie potrzeb, potwierdzenie przez kuchnię, zmianę ilości, pakowanie i odbiór. Następnie sprawdźcie brak składnika, opóźnione potwierdzenie oraz różnicę między wydaną i otrzymaną liczbą opakowań.

Poproście pracownika kuchni i lokalu o wskazanie aktualnej wersji planu oraz osoby, która ma wyjaśnić rozbieżność. Jeśli odpowiedzi są różne, przeanalizujcie nazwy statusów i sposób przekazania informacji. O przygotowaniu takich prób piszemy w artykule o testowaniu prototypu z pracownikami.

Zapiszcie ograniczenia testu. Fikcyjne dane nie potwierdzają poprawności aktualnej dokumentacji bezpieczeństwa ani gotowości prawdziwej dostawy. Te kwestie wymagają osobnej oceny odpowiedzialnych osób. O uzgadnianiu scenariuszy technicznych przeczytacie przy odbiorze aplikacji.

Jeżeli planujesz narzędzie dla kuchni i lokali, poznaj zakres oprogramowania na zamówienie i skontaktuj się z Archifutura. W briefie opisz sposób zbierania zapotrzebowania, etapy przygotowania i przekazania oraz moment, w którym najczęściej pojawiają się rozbieżności. Na początek wystarczy fikcyjny przykład.

Po próbie sprawdźcie również, czy uczestnicy potrafią odróżnić zmianę zaakceptowaną od propozycji oczekującej na odpowiedź. Koordynator powinien wiedzieć, które dane zostały potwierdzone przez lokal, a które nadal wymagają kontaktu. Zapiszcie uwagi razem z osobą odpowiedzialną za poprawkę oraz scenariuszem ponownego sprawdzenia. Jeśli próba ujawni brak danych źródłowych, wskażcie też osobę, która je potwierdzi przed wdrożeniem.