Shokava — система обліку та автоматизації для кафе

01Огляд проєкту

Shokava — це вебзастосунок для обліку та автоматизації роботи кафе, який ми спроєктували й зібрали під продуктовою назвою BillMaster. Це повноцінна SaaS-система для HoReCa: невеликий заклад заходить у свій кабінет під логіном і веде в одному місці все — приймання замовлень, рахунки та чеки, меню й позиції, склад і калькуляції собівартості, ролі персоналу та звітність. Замість зошитів, розрізнених таблиць і усних домовленостей кафе отримує єдиний інструмент, у якому кожна дія фіксується й відображається в цифрах.

Ідея виросла зі зрозумілого болю ринку. Маленьке кафе чи точка, як правило, не може дозволити собі важку касову систему рівня великої мережі — і водночас переростає облік «на колінах». Замовлення записують у блокнот, залишки складу живуть у голові закупника, собівартість страви ніхто до пуття не рахує, а наприкінці зміни ніхто не може впевнено сказати, скільки саме заробили й куди пішли продукти. Shokava закриває саме цей розрив: дає закладу дисципліну та прозорість великої системи, але у форматі легкого вебзастосунку, що відкривається у браузері.

Ми вели проєкт цілком — від моделі даних і серверної логіки до інтерфейсів кабінету, екрана приймання замовлень і звітів. Нижче розбираємо, яке завдання розв\'язує Shokava, як влаштовані його ключові модулі — замовлення, меню, склад і калькуляції, ролі та доступи — і які інженерні рішення дозволили перетворити побутовий хаос невеликого кафе на керований процес зі зрозумілими цифрами.

Важливо одразу позначити акцент продукту. Shokava — це не «електронне меню» й не просто гарний інтерфейс офіціанта. Головна цінність схована глибше: у контролі собівартості та залишків, у прозорості змін і у швидкості обслуговування. Саме ці три речі визначають, чи виживе маленький заклад, і саме навколо них ми вибудовували всю систему.

02Контекст і завдання

Коли ми розбирали завдання разом із власником, з\'ясувалося, що «облік» у типовому невеликому кафе — це набір слабко пов\'язаних між собою ручних практик. Кожна з них окремо здається стерпною, але разом вони створюють постійний витік грошей і часу. Ось болючі точки, які ми винесли на поверхню:

• Замовлення в блокноті. Офіціант записує позиції на папері або тримає в пам\'яті, передає на кухню усно. Помилки, забуті позиції, суперечки «я цього не замовляв» — усе це норма, а не виняток.
• Собівартість невідома. Ніхто не рахує, з яких інгредієнтів і в якій кількості складається страва. Ціну в меню ставлять «на око», а реальна маржа лишається загадкою доти, доки заклад не йде в мінус.
• Склад живе окремо від продажів. Залишки продуктів рахують вручну й рідко, списання не прив\'язані до проданих страв. У підсумку то «раптово» закінчується ключовий інгредієнт у час пік, то псуються забуті запаси.
• Зміна непрозора. Наприкінці дня складно сказати, скільки виручки пройшло, які позиції продавалися, що списано й чи сходиться каса. Контроль персоналу тримається на довірі, а не на даних.
• Немає розмежування прав. Або в усіх є доступ до всього, або все зав\'язано на одній людині. І те, і інше небезпечно: перше — для грошей і даних, друге — для безперервності роботи.

Завдання формулювалося так: зібрати ці розрізнені практики в єдину систему, де замовлення, склад, собівартість і звітність пов\'язані між собою й оновлюються автоматично. При цьому система має лишатися простою настільки, щоб її подолав заклад без власного IT-відділу, і достатньо суворою, щоб у кожного співробітника був рівно той доступ, який йому потрібен, — не більше.

Окремий пласт завдання — швидкість на лінії. У кафе немає зайвих секунд: якщо приймання замовлення чи пробивання чека гальмує, страждає обслуговування й росте черга. Тому інтерфейс офіціанта ми від самого початку розглядали не як «форму вводу даних», а як робочий інструмент, яким користуються поспіхом, однією рукою, між столами.

03Цілі проєкту

Із завдання виросли конкретні продуктові й інженерні цілі, які ми тримали в голові на кожному етапі:

• Єдине джерело правди. Замовлення, меню, склад, собівартість і звіти живуть в одній базі й пов\'язані між собою, а не рознесені по зошитах і файлах.
• Контроль собівартості. Кожна страва розкладена на інгредієнти з нормами витрати, тому система завжди знає реальну вартість порції та маржу за нею.
• Автоматичні списання. Продаж страви зменшує залишки інгредієнтів на складі автоматично — без окремої ручної операції.
• Ролі та доступи. Офіціант, кухар, менеджер і адміністратор бачать і можуть рівно те, що потрібно їхній ролі. Чутливі функції — під захистом.
• Швидкість обслуговування. Приймання замовлення й робота з рахунком мають бути швидкими та стійкими до поспіху, без зайвих кроків і очікувань.
• Прозорість змін. Будь-якої миті видно, що продано, що списано, скільки виручки й які залишки — без ручного зведення наприкінці дня.
• Доступність із браузера. Жодного встановлення важкого софту: вхід у кабінет за логіном, робота з будь-якого пристрою в закладі.

Ці цілі задавали не лише функціональність, а й характер інтерфейсів: технічний, спокійний, без декоративного шуму, з акцентом на те, щоб будь-яку часту операцію можна було зробити за мінімум кліків.

04Що ми зробили

Shokava збирає роботу кафе в кілька пов\'язаних модулів, які разом закривають увесь життєвий цикл — від приймання замовлення до звіту за зміну:

Ці модулі влаштовані не як окремі застосунки, а як частини одного цілого: меню живить замовлення, замовлення пов\'язані з калькуляціями, калькуляції рухають склад, склад і продажі потрапляють у звіти. Саме ця пов\'язаність і перетворює набір функцій на систему обліку.

05Архітектура рішення

Shokava — це серверний вебзастосунок з авторизацією: співробітник заходить у кабінет під своїм логіном і працює з даними свого закладу. Логічно система розкладена на кілька пов\'язаних шарів, і ця пов\'язаність — її головна інженерна цінність.

• Шар даних. Єдина модель, де описані заклад, співробітники та їхні ролі, меню й категорії, інгредієнти та норми витрати, замовлення та їхні позиції, рухи по складу. Усе пов\'язано посиланнями, тому система завжди знає, як одне впливає на інше.
• Шар операцій. Бізнес-логіка замовлення й рахунку, розрахунок собівартості з інгредієнтів, автоматичні списання під час продажу, агрегація даних у звіти. Тут живуть правила, за якими працює кафе.
• Шар доступу. Авторизація й розмежування прав: яка роль що бачить і що може робити. Чутливі операції — зміна цін, доступ до звітів, управління складом — закриті від тих, кому вони не потрібні.
• Шар інтерфейсів. Різні робочі екрани під різні ролі: швидке приймання замовлення для офіціанта, черга страв для кухні, аналітика й налаштування для менеджера та адміністратора.

Ключове архітектурне рішення — зв\'язок продажу зі складом через калькуляцію. Страва в меню прив\'язана до свого рецепта-калькуляції, калькуляція — до інгредієнтів та їхніх норм, інгредієнти — до складських залишків. Коли страва продається, ланцюжок спрацьовує сам: система знає собівартість порції й автоматично списує витрачені продукти. Без цього зв\'язку облік розпадався б на окремі незбіжні між собою шматочки — саме його ми й зробили стрижнем системи.

06Як проходить замовлення

З погляду лінії обслуговування шлях замовлення укладається в кілька кроків, і більша частина облікової роботи відбувається без участі персоналу:

• 1. Відкриття замовлення. Офіціант відкриває замовлення на столі й додає позиції з меню. Склад можна міняти по ходу обслуговування — додавати страви, прибирати, коригувати кількість.
• 2. Передача на кухню. Позиції йдуть у роботу: кухар бачить, що треба готувати, без усної передачі та загублених папірців.
• 3. Списання інгредієнтів. За кожною проданою позицією стоїть калькуляція, тому система автоматично зменшує залишки витрачених продуктів на складі.
• 4. Рахунок і чек. За готовністю замовлення закривається: формується рахунок і чек, фіксується виручка, замовлення переходить в історію.
• 5. Відображення у звітах. Закрите замовлення автоматично потрапляє у зведення зміни — за виручкою, проданими позиціями й рухом складу. Жодного ручного зведення наприкінці дня.

Важлива деталь — кожна дія прив\'язана до співробітника. Оскільки робота йде під логіном, система знає, хто відкрив замовлення, хто його вів і хто закрив. Це і дисциплінує персонал, і дає менеджерові опору під час розбору спірних ситуацій: за будь-яким замовленням видно, що в ньому відбувалося й хто за це відповідав.

07Ключові можливості

Розберемо те, що робить Shokava не «електронним меню», а саме системою обліку й автоматизації закладу.

Приймання та ведення замовлень

Серце системи — робота офіціанта. Замовлення відкривається на столі, позиції додаються з меню за кілька дотиків, склад вільно міняється по ходу обслуговування. Екран зроблено так, щоб ним було зручно користуватися поспіхом: часті дії — на виду, зайві кроки прибрані. Чим швидше проходить приймання замовлення, тим коротша черга й вищий обіг столів.

Рахунки й чеки

Замовлення закривається формуванням рахунку й чека — з фіксацією виручки та переведенням замовлення в історію. Це і зручність для гостя, і точка, у якій дані про продаж остаточно потрапляють в облік: з цієї миті позиція вважається проданою, інгредієнти — списаними, а виручка — врахованою.

Меню й позиції

Каталог страв і напоїв із категоріями, цінами й описами — фундамент, на якому тримається все інше. Меню легко підтримувати в актуальному стані: додати позицію, змінити ціну, приховати те, чого сьогодні немає. Кожна позиція пов\'язана зі своєю калькуляцією, тому зміна в меню одразу коректно відображається й у собівартості, і на складі.

Склад і калькуляції

Ключовий обліковий модуль. Для кожної страви задається калькуляція — з яких інгредієнтів і в якій кількості вона складається. Звідси система рахує реальну собівартість порції й автоматично списує продукти під час продажу. Залишки на складі оновлюються самі, за фактом продажів, а не за рідкими ручними інвентаризаціями.

Ролі та доступи

Офіціант, кухар, менеджер, адміністратор — у кожної ролі свій екран і свій набір прав. Офіціант приймає замовлення, кухар бачить чергу страв, менеджер працює з меню, складом і звітами, адміністратор керує закладом і співробітниками. Чутливі функції закриті від тих, кому вони не належать.

Кабінет управління та звіти

Менеджер і власник бачать картину закладу в цифрах: виручка, продажі за позиціями, залишки на складі. Звіти збираються автоматично з реальних операцій, тому їм можна довіряти — це не ручне зведення, яке легко підкрутити, а відображення того, що справді сталося за зміну чи період.

08Собівартість і калькуляції

Якщо в продукті є одна функція, заради якої варто впроваджувати облікову систему в маленькому кафе, — це контроль собівартості. Без нього заклад працює наосліп: ціни в меню стоять інтуїтивно, а реальну маржу ніхто не знає доти, доки гроші не починають закінчуватися. Shokava робить собівартість видимою й точною.

Механіка проста й сувора. Кожна страва розкладена на інгредієнти з нормами витрати: стільки-то грамів одного продукту, стільки-то мілілітрів іншого, стільки-то штук третього. Знаючи закупівельні ціни інгредієнтів, система рахує собівартість порції автоматично. А отже, завжди видно головний для громадського харчування показник — скільки коштує приготувати страву й скільки на ній заробляє заклад.

Це змінює управління кафе якісно. Власник бачить, які позиції реально прибуткові, а які тягнуть униз; може свідомо міняти ціну чи склад; помічає, коли зростання закупівельних цін з\'їло маржу, — не постфактум за збитками, а одразу за цифрами. Калькуляція перестає бути паперовою формальністю й стає робочим інструментом ціноутворення.

09Склад і автоматичні списання

Друга половина облікової цінності Shokava — склад, пов\'язаний із продажами. У більшості маленьких закладів склад і каса живуть у паралельних всесвітах: продали за одним, списали за іншим, порахували залишки раз на місяць і здивувалися розбіжності. Ми ці всесвіти з\'єднали.

Працює це через ту ж калькуляцію. Раз кожна страва розкладена на інгредієнти з нормами витрати, то продаж порції автоматично зменшує залишки цих інгредієнтів. Окрема ручна операція списання не потрібна — склад рухається сам, за фактом реальних продажів. Закупівлі ж заводяться як надходження, збільшуючи залишки. У результаті залишок за кожним продуктом будь-якої миті відображає реальну картину, а не останню ручну інвентаризацію тижневої давнини.

Прикладна цінність тут дуже конкретна. По-перше, контроль залишків: видно, що й коли закінчується, можна вчасно докупити й не зупинити кухню в час пік. По-друге, контроль втрат: розбіжність між тим, що мало списатися за продажами, і тим, що є на складі за фактом, — це прямий сигнал про псування, помилки чи зловживання. Система не звинувачує, але робить такі розбіжності видимими, а видиме — кероване.

10Ролі, доступи та безпека

Кафе — це колектив із різною відповідальністю, і давати всім однаковий доступ небезпечно. Тому в Shokava від самого початку закладено розмежування прав за ролями, і це не косметичне налаштування, а частина архітектури.

Ролі відображають реальну структуру закладу:

• Офіціант — приймає й веде замовлення, формує рахунки. Бачить те, що потрібно на лінії, і не має доступу до складу, ціноутворення та звітів.
• Кухар — бачить чергу страв і склад замовлень, працює з кухонною частиною процесу.
• Менеджер — керує меню, складом і калькуляціями, бачить звіти за виручкою й залишками, контролює зміну.
• Адміністратор — налаштовує заклад і співробітників, керує ролями й доступами, має повну картину.

За цим стоїть принцип найменших привілеїв: у кожного рівно ті права, що потрібні його роботі, — не більше. Це захищає і дані, і гроші: офіціант не зможе переписати ціни чи підчистити звіт, а доступ до чутливих функцій лишається в тих, хто за них відповідає. А оскільки робота йде під індивідуальним логіном, будь-яка дія в системі прив\'язана до конкретного співробітника — це і дисциплінує, і дає прозорість зміни, коли треба розібратися, що сталося.

11Кабінет управління та звіти

Щоб продукт був самостійним, мало екрана офіціанта — потрібен кабінет, де менеджер і власник бачать заклад цілком і керують ним. У кабінеті зібрано налаштування меню, складу й калькуляцій, управління співробітниками й ролями, а головне — звітність за реальними операціями.

Звіти відповідають на питання, які в кафе ставлять щодня: скільки виручки пройшло за зміну, які позиції продавалися найкраще, що списано зі складу, які залишки зараз. Оскільки все це збирається автоматично із замовлень і рухів складу, цифрам можна довіряти — вони відображають те, що справді сталося, а не ручне зведення, яке легко спотворити.

По суті, кабінет — це «пульт» над усім тим, що система робить у фоні. Він закриває повсякденні управлінські сценарії без зовнішньої допомоги: додати страву в меню й одразу завести її калькуляцію, оформити надходження товару, перевести співробітника на іншу роль, подивитися, як іде зміна, розібрати спірне замовлення. Прозорість змін тут не абстракція, а конкретний екран, на який менеджер дивиться протягом дня.

12Швидкість обслуговування

У громадському харчуванні час — це гроші в найпрямішому сенсі: чим швидше проходить обслуговування, тим більше гостей і вищий обіг столів. Тому швидкість на лінії була для нас не приємним бонусом, а окремою проєктною ціллю, під яку загострювався інтерфейс.

Ми виходили з того, що офіціант працює поспіхом, між столами, часто однією рукою. Отже, часті дії — відкрити замовлення, додати позицію, закрити рахунок — мають робитися за мінімум дотиків і бути стійкими до квапливості. Меню структуроване за категоріями, щоб потрібна позиція знаходилася швидко; склад замовлення міняється на льоту; закриття рахунку не вимагає зайвих підтверджень там, де вони не потрібні.

Важливо, що швидкість інтерфейсу не вступає в конфлікт зі суворістю обліку. Поки офіціант просто швидко приймає замовлення, система у фоні робить усю облікову роботу — зв\'язує позиції з калькуляціями, готує списання, накопичує дані для звітів. Персонал не відчуває тяжкості облікової системи, а заклад при цьому отримує всі її плоди. Цей баланс — швидко для лінії, суворо для обліку — ми й вважаємо одним із головних результатів проєкту.

13Технологічний стек та інфраструктура

Shokava — це вебзастосунок із серверною логікою, базою даних та авторизацією, розгорнутий як самостійний продукт на власній інфраструктурі, за Cloudflare і з валідним TLS-сертифікатом. Під нього ми зібрали акуратне ізольоване середовище — так безпечніше й простіше в супроводі.

• Бекенд — серверна логіка замовлень, рахунків, калькуляцій і складських рухів, агрегація даних у звіти, авторизація та перевірка прав на кожну дію.
• Дані — пов\'язана модель закладу: співробітники й ролі, меню й категорії, інгредієнти та норми витрати, замовлення та їхні позиції, рухи складу.
• Інтерфейси — робочі екрани під ролі: швидке приймання замовлення, кухонна черга, управління меню й складом, кабінет і звіти.
• Інфраструктура — ізольоване середовище за Cloudflare з DNS, TLS і захистом периметра; доступ у кабінет лише за логіном.

14Дизайн і UX

Облікова система продає не красу, а впевненість: персонал має довіряти інтерфейсу поспіхом, а власник — цифрам у звітах. Тому інтерфейси Shokava ми робили спокійними, технічними й функціональними, без декоративного шуму, який лише заважає в роботі.

Підхід до UX прямо випливав із ролей. Екран офіціанта оптимізований під швидкість: великі зрозумілі елементи, часті дії на виду, мінімум кроків до результату. Кабінет менеджера — навпаки, під вдумливу роботу з даними: тут важливі читабельність таблиць, зрозумілі зведення й зручність налаштування меню та калькуляцій. Один продукт, але різні режими роботи під різні завдання.

Окрема увага — тому, щоб складність обліку не вилазила назовні там, де вона не потрібна. Офіціантові не треба бачити калькуляції й собівартість — йому треба швидко прийняти замовлення; уся облікова механіка працює за лаштунками. А там, де дані важливі — у кабінеті та звітах, — ми, навпаки, робили їх максимально наочними. Гарний інтерфейс облікової системи — це той, який показує кожній ролі рівно стільки, скільки їй потрібно, і ні грамом більше.

15Як ми працювали

Проєкт вели послідовними етапами, на кожному з яких був відчутний результат:

• Дослідження. Розібрали, як реально влаштований облік у невеликому кафе: шлях замовлення, робота зі складом, болючі точки, ролі співробітників і сценарії кожної з них.
• Модель даних. Спроєктували пов\'язану схему — заклад, ролі, меню, інгредієнти й норми, замовлення й позиції, складські рухи, — на якій тримається вся логіка.
• Ядро обліку. Зібрали приймання замовлень, рахунки й чеки, калькуляції собівартості та автоматичні списання, авторизацію й розмежування прав.
• Звітність і кабінет. Зробили кабінет управління та зведення за виручкою, продажами й залишками, що збираються автоматично з реальних операцій.
• Обкатка й запуск. Прогнали систему на реальних сценаріях зміни, відшліфували швидкість на лінії й розгорнули продукт за Cloudflare з авторизацією і TLS.

На кожному кроці ми перевіряли рішення реальною роботою кафе: облікова система цінна рівно настільки, наскільки точно вона лягає на живий процес закладу, а не на абстрактну схему.

16Результат

Вийшла не «електронний блокнот для офіціанта», а самостійна система обліку й автоматизації кафе, у якій замовлення, склад, собівартість і звітність пов\'язані в єдине ціле й працюють на власника.

• Облік зібрано в одному місці — жодних зошитів і розрізнених таблиць, усе рахується й сходиться само.
• Собівартість кожної страви видно й точно — ціноутворення й маржа перестають бути гаданням.
• Склад рухається автоматично за продажами — залишки актуальні, втрати стають видимими.
• Розмежування прав захищає дані й гроші, а індивідуальні логіни роблять зміну прозорою.
• Швидкий інтерфейс офіціанта пришвидшує обслуговування, не жертвуючи суворістю обліку.

17Висновки

Shokava — приклад того, як правильна модель даних перетворює побутовий хаос невеликого закладу на керований процес. Найцінніше тут не в тому, що система «приймає замовлення», а в тому, як пов\'язані її частини: продаж рухає склад, склад і калькуляція дають собівартість, усе разом складається в чесний звіт. Саме ця пов\'язаність відрізняє справжню облікову систему від гарного меню з кнопкою «оплатити».

Для нас це був проєкт на стику продуктового мислення та інженерної дисципліни: треба було водночас зрозуміти реальну роботу кафе й зібрати сувору, але легку систему, якою користуються поспіхом і якій довіряють у цифрах. Якщо вам потрібна система обліку, SaaS для конкретної ніші чи складний вебзастосунок із ролями, даними й зрозумілою аналітикою — ми вміємо доводити таке до запуску.