Restaurační informační systém

Restaurační informační systém
Zkratka projektu: Resisys
Email na vedoucího projektu: [email protected]
Stránky projektu: https://www.assembla.com/spaces/si-informacni-system-pro-restauraci
Řešitelé: Jakub Begera, Jakub Moravec, Pavel Matyáš, Pavel Valach
Termín cvičení: 3.semestr (zimní semestr 2014/2015), pondělí 12:45
Cvičící: Ing. Ondřej Macek
Datum odevzdání 1. iterace: 10.10.2014 (3.týden)
Tabulka verzí
Verze (název verze)
Datum
Důvod úprav
Autoři
0.9
24.9.2014
Tvorba první verze
Jakub Begera, Pavel Matyáš,
Pavel Valach, Jakub Moravec
0.9.1
29.9.2014
Úprava po konzultaci
Pavel Matyáš, Jakub Moravec
0.9.2
29.9.2014
Přidána úvodní stránka
Pavel Matyáš
0.9.3
30.9.2014
Úpravy na doporučení konzultanta projektu,
úprava popisu projektu, logo
Jakub Begera
0.9.4
1.10.2014
Rozpracování finanční stránky vize
Jakub Moravec
0.9.5
4.10.2014
Nové logo pro úvodní stránku, průběžná kontrola
gramatiky, Drobné vizuální úpravy dokumentu.
Pavel Matyáš
0.9.6
6.10.2014
Úprava po konzultaci
Jakub Begera, Pavel Matyáš,
Pavel Valach, Jakub Moravec
0.9.9
28.10.2014
Přidán popis jednotlivých rolí a přesněji
specifikována odezva. Přidán výkaz práce.
Pavel Matyáš, Pavel Valach,
Jakub Moravec
1
Obsah
Restaurační informační systém
Obsah
Úvod / Popis projektu
Klíčové vlastnosti produktu
Cíle projektu
Výkon
Kvalita a spolehlivost
Přijetí uživateli
Čím se lišíme od konkurence
Finance
Z pohledu zákazníka
Zainteresované osoby a instituce (stakeholders)
RACI matice
2
Úvod / Popis projektu
Cílem tohoto projektu je vytvoření komplexního informačního systému pro restaurace.
Tento systém si klade za cíl zefektivnit a optimalizovat procesy, se kterými se restaurace
každodenně potýká. Těmito procesy jsou zejména sledování životního cyklu objednávky (od
jejího přijetí číšníkem, přes zpracování kuchařem až po uhrazení zákazníkem), evidence a
plánování lidských zdrojů restaurace (rozdělování směn, výplaty apod.) a správa skladových
zásob (evidence, objednávky apod.).
Některé výše zmíněné procesy by mohly být zcela zautomatizovány, jako například
generování objednávky na základě poklesu hladiny skladových zásob, čímž by došlo k úspoře
na straně lidských zdrojů.
Klíčové vlastnosti produktu
Cíle projektu
Tento projekt si klade za cíl vytvořit univerzální informační systém pro restaurace
(viz popis projektu). Po vytvoření pilotní verze systému bude tento systém implementován v
restauraci Tuxův mls, která bude financovat vývoj výměnou za určité výhody (viz finance z
pohledu dodavatele). Do budoucna plánujeme nasazení i v dalších restauracích.
Z nasazení systému budou profitovat všichni jeho uživatelé, od číšníků, kterým
zpřehlední a zrychlí objednávky, přes kuchaře, jimž se zjednoduší informování o stavu
objednávky, až po management, kterému naše řešení přinese dokonalý přehled o stavu a
výkonu restaurace.
Výkon
V běžném provozu (tj. do 100 přihlášených uživatelů) bude odezva aplikace do jedné
sekundy. Při více než 100 uživatelích se odezva bude prodlužovat lineárně v závislosti na počtu
uživatelů.
Kvalita a spolehlivost
Aplikace bude dostupná neustále kromě pár výjimečných situací, kdy si naše společnost
vyhrazuje právo na přerušení chodu aplikace a to v následujících případech:
● aktualizace aplikace
○ nejčastěji jednou za dva měsíce
○ odstávka maximálně čtyři hodiny - roční uptime ≥99,7 % (při provozu 24 h
denně, 365 dní v roce)
● oprava nahlášených chyb:
○ odstávka maximálně dvě hodiny
○ chyby budou opraveny nejpozději druhý den po jejich nahlášení
Aktualizace budou prováděny, pokud možno, mimo otevírací dobu restaurace.
Přijetí uživateli
3
Systém má za cíl zvýšit efektivitu práce, zautomatizovat některé procesy, a tak
uživatelům pomoci zpříjemnit náplň jejich pracovní činnosti. Zároveň bude systém intuitivní
a uživatelsky přívětivý. Jeho nasazení do provozu s sebou nenese velké nároky na školení
personálu. Je tedy očekáváno pozitivní přijetí systému koncovými uživateli.
Čím se lišíme od konkurence
Vyvíjíme komplexní řešení, které pokryje všechny nároky restauračního zařízení, jako
např. správa objednávek, skladu apod - viz popis projektu. Vytváříme vysoce modulární systém,
který jsme schopni pro konkrétní restauraci upravit tak, aby vyhovoval jejím zaměstnancům a
stylu práce. Tím se lišíme od konkurence, která ve většinou vyvíjí univerzální systém, který ve
stejné podobě dodá všem zákazníkům. Vytvořením systému na míru chceme výrazně snížit
náklady na zaškolení personálu.
Funkce a role v systému
V systému budou definovány následující uživatelské role:
● manažer
○ V systému má veškerá možná oprávnění. Stará se o jeho celkový chod a o chod
restaurace samotné. Mj. tvoří jídelní lístek, stará se o správu zaměstnanců,
výplaty apod.
○ Všechny ostatní role jsou mu podřízeny.
● kuchař
○ Má na starosti přípravu jídla. V systému může upravovat stav objednávky.
● číšník
○ Vytváří, upravuje, maže a servíruje objednávku. Stará se o rezervace stolu.
Může zviditelnit/zneviditelnit položku v jídelním lístku (např. pokud dostane od
kuchaře zprávu, že již nejsou suroviny).
● skladník
○ Spravuje zásoby na skladě a stará se o objednávky zásob a zboží. Mj. upravuje
záznamy o dodavatelích.
Tito uživatelé budou mít v systému k dispozici následující funkčnosti:
● správa a obsluha zákazníků
○
○
○
objednávání pokrmů (číšník)
■ Díky zapisování objednávek do systému se číšníci mohou na sto procent
soustředit na komunikaci se zákazníkem místo toho, aby se snažili si
zapamatovat objednávky. Zapsání objednávek je zároveň podmínkou
dalších funkčností.
rezervace stolů (číšník)
■ Každý systém pro restaurace musí nezbytně obsahovat komponentu
pro rezervace, ani v tomto ohledu nezůstaneme pozadu a poskytneme
přehledný systém rezervací.
sledování a spravování objednávek (číšník, kuchař)
■ Systém bude sledovat životní cyklus objednávky. Ve chvíli, kdy číšník
zadá objednávku, se zobrazí upozornění kuchařovi. Ten tak může bez
4
○
zbytečných odkladů začít s přípravou pokrmů. Velice jednoduše potom
kuchař označí objednávku za připravenou a celý proces končí tím, že ji
číšník označí za zaplacenou. Tímto ušetří personál restaurace mnoho
času, který jinak zabírá předávání těchto informací a případné nejasnosti.
editace jídelního a nápojového lístku (manažer, číšník)
■ Jednoduchá a rychlá možnost editace nápojového lístku zajistí jeho
aktualitu a předejde rozhořčení zákazníků, kteří by si rádi objednali něco,
co je k mání v jídelním či nápojovém lístku, reálně ale už nikoliv.
● komplexní správa skladu
○
○
○
udržování minimálního množství položek na skladu (skladník)
■ V systému bude zadáno minimální množství daných surovin, které je
třeba na skladě udržovat. V momentě, kdy je daná hranice překročena,
systém automaticky vygeneruje objednávku potřebného zboží, která bude
předána k potvrzení skladníkovi. Ten bude na vznik tohoto požadavku
upozorněn.
generování objednávek (skladník)
■ Bude možno si nastavit pravidelné generování objednávek (např. jednou
měsíčně) + objednávky v kritickém množství zboží (viz výše). Bude
možno určit, kde se zboží objedná, kdy bude objednávka odeslána, co a
kolik toho bude objednáno. Objednávky se automaticky budou evidovat v
databázi systému.
správa dodavatelů (manažer, skladník)
■ Aby bylo možné automaticky generovat a odesílat objednávky, je
potřeba v systému vést, které zboží odebíráte od kterého dodavatele.
Čas, který bude na začátku stráven nastavováním dodavatelů se
několikanásobně vrátí. Systém poskytne velkou časovou úsporu jak
manažerovi restaurace, tak jejímu skladníkovi, kteří tyto úlohy normálně
řeší manuálně.
● správa zaměstnanců (manager)
○
○
○
plánování směn
■ Na základě profese, preferencí a časových možností jednotlivých
zaměstnanců budou generovány směny, které manager bude moci
manuálné upravit (a to i zpětně).
evidence odpracovaných hodin
■ Na základě naplánovaných směn se u každého zaměstnance bude
uchovávat statistika odpracovaných směn.
výplaty
■ Pomocí evidence odpracovaných hodin a hodinové sazby zaměstnance
se za dané odpracované období budou generovat data o výplatách.
Finance
Z pohledu dodavatele
Náklady spojené s vývojem systém u uhradí zadavatel, tedy Tuxův mls s.r.o. Tato
částka byla vypočítána na 80 000 Kč (200 Kč * 400 hodin práce na projektu). Samotný software
5
ale zůstává majetkem zhotovitele, tedy naší společnosti. Tuxův mls s.r.o. koupí získává
čtyřletou licenci na restaurační systém, jeho nasazení našimi pracovníky zdarma a roční
podporu zdarma.
Naším dalším cílem je oslovení dalších zákazníků. Navrhované obchodní podmínky jsou
následující:
● dvouletá licence na systém - 40 000 Kč (cena produktu stanovená obchodním
oddělením)
● nasazení systému a jeho dílčí upravení na míru zákazníka - 10 000Kč (200 Kč
* 50 hodin - 40 hod: drobné úpravy dle požadavků zákazníka, 10 hod: samotné
nasazení systému)
Každých šest měsíců po vytvoření systému bychom rádi oslovili alespoň 10 zákazníků.
Za tohoto předpokladu by byl příjem z prodeje v horizontu 4 let ~ 3 600 000,- Kč.
Z pohledu zákazníka
Položka
Částka
Vývoj a nasazení systému
80 000 Kč
Potřebný hardware pro zaměstnance
35 000 Kč
Údržba systému
2 000 Kč / měsíc
Práce potřebná na případné požadavky
zákazníka mimo zadání projektu
400 Kč / osoba na hodinu
* Podpora a údržba systému na první rok je garantována zdarma
** Ceny uvedené v tabulce jsou stanoveny na základě úvodní analýzy a nemusí být definitivní
Finanční návratnost zákazníka
Dle úvodní analýzy by měl informační systém přinést u zákazníka Tuxův mls s.r.o
následující úspory/zisky:
● snížení počtu číšníků ~ 21 000,- Kč / měsíc
● snížení úvazku skladníka ~ 10 000,- Kč / měsíc
● zjednodušení a zrychlení správy zaměstnanců ~ 10 000 Kč / měsíc
Pokud vezmeme v potaz čas nutný pro zavedení systému (ve kterém se tyto úspory zřejmě
budou projevovat v menší míře, nebo vůbec), finanční návratnost pro zákazníka je 4 měsíce.
Zainteresované osoby a instituce (stakeholders)
●
●
●
●
Firma zákazníka: Tuxův mls s.r.o., K Hladu 28, Praha 6
Zodpovědná osoba u zákazníka: Petr Vrchnítučňák
Konzultant zákazníka: Petr Vrchnítučňák
Konzultanti projektu: Ing. Ondřej Macek, prof. Ing. Jan Tux CSc.
6
RACI matice
Fáze projektu
Termín
Ing. Ondřej
Macek
prof. Ing. Jan
Tux CSc.
Jakub
Begera
Pavel
Matyáš
Pavel
Valach
Jakub
Moravec
Vize projektu
10. 10. 2014
C
C
R, A
R
R
R
Byznys analýza (BPM,
BDM)
24. 10. 2014
C
I
R
R, A
R
R
Katalog požadavků
24. 10. 2014
C
A
R
R
R, A
R
Model případů užití
24. 10. 2014
C
C
R
R
R
R, A
model analytických
tříd (nástin budoucí
implementace)
14. 11. 2014
C
I
R, A
R
R
R
robustní architektonický
základ - ukázka základů
aplikace na Youtube
14. 11. 2014
C
C
R
R, A
R
R
model architektury
(diagram komponent,
diagram balíčků a tříd)
28. 11. 2014
C
I
R
R
R, A
R
model komunikace
28. 11. 2014
C
I
R
R
R
R, A
model nasazení
28. 11. 2014
C
C
R, A
R
R
R
zpráva o implementaci
28. 11. 2014
C
I
R
R, A
R
R
plán testování případů
užití
28. 11. 2014
C
C
R
R
R, A
R
kompletní dokumentace
k projektu
12. 12. 2014
C
I
R
R
R
R, A
zpráva o implementaci +
uživatelský manuál
12. 12. 2014
C
I
R, A
R
R
R
zpráva o testování
12. 12. 2014
C
I
R
R, A
R
R
DVD k projektu
včetně virtualboxu s
rozchozenou aplikací
12. 12. 2014
C
I
R
R
R, A
R
zavedení systému
23. 12. 2014
C
A
R
R
R
R, A
* R (Responsible) - osoba pracující v této fázi projektu, A (Accountable) - osoba, která může
vynášet rozhodnutí, C (Consult) - klíčový účastník, který by měl mít účast na tvorbě rozhodnutí
či práci na projektu, I (Inform) - osoby, které by měly být informovány o rozhodnutích a akcích
7
Výkaz odpracovaných hodin za 1. iteraci
Jakub Begera – 9,75 hodin
Jakub Moravec – 12,50 hodin
Pavel Matyáš – 11.00 hodin
Pavel Valach – 5.00 hodin
Celkem odpracováno: 38.25 hodin
Rozdělení bodů za 1. iteraci
Příjmení a jméno
Begera Jakub
Moravec Jakub
Matyáš Pavel
Valach Pavel
Celkem (musí být 0)
Přerozděleno
3.týden
Důvod přerozdělení. Musí být vyplněno!
Nutnost přerozdělení.
Nutnost přerozdělení.
Nutnost přerozdělení.
Nutnost přerozdělení.
Přerozdělené body
2
2
-2
-2
0
4
Zpětné hodnocení 1. iterace
Co se osvědčilo/fungovalo?
Zejména týmová komunikace pomocí moderních kanálů jako Facebook - a hlavně osobní schůzky,
kde se vyřešilo a udělalo zdaleka nejvíc.
Jaké byly problémy?
Měli jsme problémy s používáním nástroje Enterprise Architect, zejména s tím, jak synchronizovat
naši práci. Zkrátka na to potřebujeme ještě trochu času. Také se teprve seznamujeme s Assemblou a
tiketovacím systémem, takže jsme často dělali tikety příliš obecné a nekonkrétní.
Co a jak zkusíme dělat lépe?
Zlepšíme se v tiketování a výkazech času, jelikož zde cítíme značné rezervy, a také se pokusíme
konečně vyřešit synchronizaci našich business modelů, abychom mohli nerušeně pokračovat v
práci.