UCS (Store-House R-Keeper) VS Iiko
Здрастуйте, шановні колеги! Я займаюся консалтингом, у 2014 р. у мене стартував проект з оптимізації БП (бізнес-процесів) Ресторану та Служби доставки. Характеристики: • Місто-мільйонник, із середньою діловою активністю. • Ресторан у 3 лідерів. 150 місць, 3 зали. Служба доставки – №1 у місті. 2,5-3 тис. замовлень на місяць. • Основні завдання – прозора виробнича с/ст, min втрати, зростання маржинального прибутку.
Перше питання було про засоби автоматизації БП. Компанія працювала наПО UCS,в якому виявилися помилки, що заважають проекту:
1.У UCS розділені блоки front-office (R-Keeper) і back-office (Store House).Тобто. с/ст формується над момент реалізації готової продукції (ДП), а після вивантаження док-ов реалізації з R-Keeper в SH, формування та проведення расх. накладних. У результаті – збій оперативності даних 1-2-3… дня, що у громадського харчування біда, т.к. цикл "товар-гроші-товар" дуже короткий і всі ТМЦ дико обертаються (якщо це не 18-річний віскі). 2.У програмі Store House заборонені негативні залишки.Типу «Ви не можете зробити страву, якщо у вас немає для неї продуктів». На мою думку, «факт» та «облік» у громадському харчуванні завжди нерівні – відхилення +- «вшити» у процес. Котлета по-київськи не автомобіль – чогось більше, чогось менше поклали. Це при тому, що нами в ході роботи було проміряно всі коефіцієнти. втрат переділів сировини, п/фабр. і страв і «вшити» у тих. картки. Тобто. ми min відхилення, але вони все одно були потрібні. SH пропонує замість заперечень. залишків користуватися пекельним алгоритмом «компенсацій»: 1) вивантажте документ про реалізацію з програми R-Keeper 2) сформуйте на його підставі витрат. накладну 3) під час проведення цієїнакладної ви побачите всі рядки з відсутніми продуктами/товарами, але накладна не буде проведена. 4) проаналізуйте – чи можливі ці недостачі? (подається як «+» – можна бігти розбиратися, чому бракує 2 гр. солі, чи 5 гр. кави… ) 5) після аналізу сформуйте прих. накладну, яка оприбутковує за нульовою ціною всі продукти/товари, що відсутні. 6) проведіть расх. накладну – ура! Ви сформували с/ст. ДП за попередній день (2-3 дні).
Що відбувається на практиці? Звичайно - розумітися ніколи - все «шарашат» компенсації автоматично, спотворюючи дані про натуральний обіг сировини, т.к. ніяких продуктів під ці компенсації на кухні по-факту немає, а причин, що викликали недостачі маса – пересорт, недоклали/переклали, прийшла якісно інша сировина, винесли/з'їли, помилка в тих. карті і т.д. Що бачить мозок у звітах з обігу ТМЦ? Або покладе. у, або «0» - приводу турбуватися немає – все перекрито неіснуючими компенсаціями. Амінь.
3.У програмі SH при формуванні с/ст ГП використовується метод FIFO.Метод FIFO хороший при партійному обліку, де за фактом з полиці беруть дійсно найстарішу по приходу од. ТМЦ. У жодному ресторані це реалізувати неможливо. У громадському харчуванні метод FIFO викликає спотворення произв. с/ст ДП, що веде до помилок ціноутворення. Наприклад, на ринку «хитнуло» ціни на лосось – за місяць він подорожчав-подешевшав на 50%. Ви з переляку купили велику партію дорогої риби. У перспективі – все добре, але SH буде «шарашити» у с/с ваших суші суми на 50% вище за ринок, поки партія дорогої риби не закінчиться в обліку. Ви можете підняти ціни, дивлячись на вашу с/с – вистрибніть вище за ринок і втратите клієнтів. А може бути і в інший бік – все дорожчає, ви закуповуєте за новими цінами, а у с/с у вас старіі ви спізнюєтеся з підвищенням своїх цін, втрачаючи прибуток.
Тільки метод «ковзної середньої» може бути використаний при списанні продуктів/товарів у с/с ДП – наполягаю на цьому! 1С його успішно використовує довгі роки. Навіщо було винаходити «велосипед із квадратними колесами»? - не зрозуміло…
Ми проаналізували ринок ПЗ та вибрали Iiko. У травні 2015 р. ми перевели весь комплекс цього ПЗ. Що в результаті? На даний момент (Жовтень 2015 р.) кращого програмного забезпечення для громадського харчування, ніж Iiko на ринку немає.Я ВІДМОВЛЯЮСЯ ПРОДУВАТИ Iikoу свої нові проекти та рекомендувати його клієнтам. суперечливі твердження, правда? Давайте розберемося.Плюси:1. Всі описані помилки UCS відсутні - Iiko єдина програма, одночасно з реалізацією автоматично формується произв. с/вартість, є запереч. залишки та метод «ковзної середньої». 2. Дуже сильний back-office - виробничий блок з тих. картами та модифікаторами, добротний блок з/плати, грамотні звіти (стандартні та OLAP). Програма не годиться для управлінського обліку до чистого прибутку (немає блок обліку ОС, слабкий блок розрахунків (каса, банк, підзвіт)), і навіть при цьому – молодці! Маржинальний прибуток – як у долоні.Мінус:1. Гірше з front-office.Зовнішньо – все «в шоколаді» - списано у UCS, і доопрацьовано "красу". Але! Програма "важка" - UCS працює під DOS, а Iiko - під Windows. ПЗ Iiko не дешеве, тому про нове "залізо", якого вимагатиме ПЗ, до переходу не говорять. У результаті - при встановленні нового релізу у нас злетіла Доставка в обід п'ятниці! Не працювали пів-п'ятниці та суботу. Вирішення проблеми було запропоновано Керуючим Рестораном, а доблесні програмісти Iiko пропонували просто «не працювати, поки «Москва» не виправить помилку». Втрата виручки ніщо, порівняно зрепутаційними втратами! Ми розгойдували Доставку 1,5 року, вийшли на приріст числа замовлень в 40-50%, і повинні втрачати своє реноме через те, що ці «заморожені пінгвіни» не можуть виправити помилки, що повторюються? Нам сказали – «оновлюйте «залізо» - кожен новий реліз буде важчим за попередній». Чому ми до переходу не знали про це? Чи кілька сотень тисяч несподіваного подорожчання проекту – це нормально?2. Карти програм лояльності. Це просто біда! Нам обіцяли модну програму Iiko Net із СМС оповіщеннями, мобільними додатками, звітами тощо. Ми переходимо і починається пекло! • Будь-який «клік» для змін карти, закладу нової викликає очікування 35 секунд, при тому, що стандартна операція може робитися в 3-4 і більше «кліків». Керуючий перестає керувати рестораном, ця свята жінка сидить годинником за комп'ютером, гіпнотизуючи клієнтську базу, з нескінченним «кухлем» очікування. • Звітів немає! У нас складна програма лояльності = знижки+бонуси+депозити. Депозити обслуговуються вручну. Ми не можемо побачити – з приводу людини потрапили гроші на карту – поклав він їх сам, або це «подарунковий депозит». • У чеках не видно ні суми списання з картки, ні Ф. І. власника. І т.п. Це було жахливо! Під час розгляду з'ясувалося, що систему Iiko net продано Ощадбанку. Ощад її «пиляє» під себе, блок для інших клієнтів втрачено, і чекати нічого. Нам з 15 разів дуже невиразно розповіли, що Iiko «допилюватиме» свою стару систему Iiko Card (списано у UCS на 100%), створювати щось схоже на Iiko Net, але в які терміни – невідомо.
Ми пішли назад на Iiko Card, працювати без жодних «плюшок». Частина даних була втрачена під час переходу, і домагалася вручну (8 осіб * 6 годин безперервної роботи). Наш шановний власник говорить«Хлопці, мені незручно, що у нас все по-старому – гості повинні тягати з собою карти, щоб отримати знижку/бонус». Він знайшов нам фірму, яка «намальовує» СМС-сервіси, АЛЕ! Компанія IIKO відмовилася співпрацювати із ними. Це гроші, вони не готові їх віддати людям, і самі заробити не можуть як собака на сіні.
3. Розвиток ПЗ.1) Чому «баги» нових релізів, навіть дикі - «цей звіт у попередньому релізі працював, а в новому – чомусь ні….» виправляються лише у новому релізі, терміни виходу якого – «приблизно 2 рази на рік»? Чому ми повинні чекати на виправлення «косяків» півроку. 2) Я бачу в нових релізах «веселенький» новий дизайн у back-office і не бачу звіту по замовленням Доставки, який необхідний службі щодня! Де релевантність роботи Iiko та важливості запитів клієнтів? 3) Як Iiko докручуватиме ПЗ до обліку чистого прибутку, якщо зрушень у цьому напрямі немає? Iiko не розуміє важливості повного обліку для будь-якого власника? А може просто – спочиває на лаврах.