Форум Сообщества Аналитиков
Дисциплины => Системный Анализ и Требования => Тема начата: Galogen от 19 Июля 2011, 22:56:12
-
Задача опытного аналитика, довольствуясь неполной информацией и учтя возможные пути развития, предложить наиболее оптимальные варианты. Однако что считать критерием оптимальности? Соответствие требованиям заказчика, возможностью развития системы в будущем, минимальные затраты на реализацию?
В качестве такой гимнастики ума хочу предложить два возможных решения одной несложной задачи.
Имеется столовая (внутренняя).Количество сотрудников достаточное, чтобы подумать об оптимизации процесса заказа обедов и учета этих заказов. В текущий момент времени учет взятых обедов сотрудником ведется просто: работник столовой сидит на выдаче, слушает заказа, подсчитывает его сумму, записывает результат в журнал, дает на подпись сотруднику. Такая ситуация не нравится директору: человек отвлекается на ведение учета, учет ведется вручную, оперативности нет, получить данные по сотруднику сложно, нет детализирования, трудно вести статистику.
Предложили:
вариация 1
будет сенсорный экран (терминал).
сотрудник авторизуется средствами быстрой идентификации (прокси, смарт-карты. штрих-коды и т.п.)
сотрудник делает заказ, нажимая пункты интерактивного меню и по завершению заказа печатает чек
сотрудник встает в очередь, отдает чек работнику столовой, получает обед
работник столовой выдает обед, регистрирует чек в системе, проводя им под сканером штрих-кода (подтверждает исполнение заказа)
если какое-то блюдо закончилось, сотрудник возвращается к терминалу, авторизуется вновь и исправляет текущий заказ, печатает новый чек
вариация 2
будет сенсорный экран (терминал).
сотрудник авторизуется средствами быстрой идентификации (прокси, смарт-карты. штрих-коды и т.п.)
сотрудник делает заказ, нажимая пункты интерактивного меню, и по завершению подтверждает заказ
сотрудник встает в очередь (предполагается, что заказ он делает в тот момент, когда предыдущий уже получает свой заказ), получает свой обед
работник столовой после выдачи обеда нажатием на экране, подтверждает исполнение заказа этого сотрудника, на экране отображается следующий в очереди заказ
если какое-то блюдо закончилось, работник столовой извещает сотрудника об этом и по его распоряжению корректирует заказ или вообще отменяет
Что вы можете сказать по этим вариантам, который из них вы предпочли бы и почему, может вы предложите свой вариант?
-
В обоих вариантах есть несколько моментов которые с одной стороны упрощают и автоматизируют процесс, а с другой стороны создают новые проблемы и способствуют возникновению коллизий (выбрал блюдо по списку, а блюда - нет, передумал, ошибся при выборе думал что выбрал А а хотел Б и т.п.).
Вариант 3.
"Учет проданных блюд выполнять по факту, с фиксированием перечня позиций и суммы заказа за сотрудником по пропуску или специальной карточки".
Для учета проданных блюд и товаров используется терминал с сенсорным экраном (в составе комплекса ККМ)
Работник столовой (кассир) пробивает выбранные блюда и товары. Для ускорения процесса указания блюд текущего меню может быть представлен картинками разбит по категориям, либо на посуде с блюдом зафиксирован штрих-код, либо к терминалу подключена дополнительная клавиатура с картинками (как в весах в магазинах, замена картинок и названий блюд на клавиатуре производится после согласования меню до начала работы). Для товаров фиксирование может производится по штрих-коду.
После формирования заказа по фактически взятым блюдам (товарам) фиксирует пропуск сотрудника считыванием штрих-кода или магнитной полосы (предпочтительнее поскольку сложнее подделать), выдает чек. У "посетителей со стороны" принимает деньги, выдает чек.
-
Спасибо, DinamoYA
Ваш вариант интересен, но он не решает главного требования заказчика - исключить сидение работника столовой за задачей учета. В Вашем варианте, Вы по сути заменили ручной учет стоимости на электронный. Но все равно остается кассир. Ваш вариант, конечно, гибкий ибо он учитывает возможность явной оплаты обеда. Но для нашего случая это не будет характерно.
Корпоративность, закрытость столовой обязательное условие. В результате этого цены в столовой коммунистические, а качество обедов - домашнее. Предполагается, что сторонних посетителей не будет (просто мы ушли от этого варианта уже). Однако будут возможно гости, но гости и есть гости, они питаются за счет компании и об этом руководство сообщает явно. Чтобы зарегистрировать гостевые обеды - будет достаточно создать гостевой аккаунт.
Может подробнее рассмотрим все негативные аспекты каждого варианта?
1. вариант с чеком
самое проблемное, это когда сотрудник сделал заказа, подошел к выдаче. А блюдо закончилось, что делать? Я предполагал возвращаться к терминалу и перезаказывать. Этот вариант вполне нормален, если народу раз два, и куда как не нормален, если в подобную "ловушку" попалось сразу человек 10.
минимизировать риск такого явления можно было бы контролируя доступное, заказанное и реально выданное количество блюд, своевременным изменением меню. Правда, здесь есть риск что будто бы блюдо кончилось, а реально оно все-таки есть.
2. вариант с интерфейсом у работника столовой имеет на мой взгляд 1 недостаток: он в лозунге: "1 в очереди обслуживается, второй делает заказ, третий знакомится с меню", т.е. все-таки получается, что обслуживание несколько будет торомозится по сравнению 1 вариантом, зато полностью снимаются проблемы с некорректно сделанным заказом, заказом закончившегося блюда, нет печатать чек - он в целом похож на Ваш 3 вариант.
Но заказчки как-то высказался против такого, работник на выдаче выдает питание и ни его задача тыкать пальцем в монитор, принять чек - максимум на что мы можем рассчитывать
-
У меня, в одной из контор, была подобная система обедов
Процесс был организован следующим образом
1. сотрудник регистрирповался в системе заказа обеда пропуском
2. из электронного меню выбирал блюда (меню формировалось за 2 часа до обеда администратором системы)
3. сформировав заказ, сотрудник его подверждал
4. чек печатался сразу на месте работника столовой
5. сотрудник подходил к работнику столовой и оплачивал обед по распечатанному чеку (обеды не были беплатными :( )
6. далее сотрудник шел на выдачу обеда, где повар по чеку формировал заказ
Если блюдо заканчивалось работник столовой оперативно убирал его из меню
Рад буду ответить на вопросы
-
1. на прилавке с блюдами, у каждой картинки с блюдом есть считыватель магнитной карты
2. обедающий проходит вдоль прилавка, прикладывая карту к считываетелям,
3. выбранное блюдо подсвечивыается со стороны раздатчика, он его накладывает и выдает потребителю
4. на выходе печатается чек и его обедающий забирает
5. деньги списываются со счета обедающего в момент выбора блюда
6. деньги пополняются в терминале столовой
7. если закончивается блюдо, раздатчик блокирует считыватель
итого:
1. задействовано оптимальное кол-во раздатчиков в столовой
2. нет кассира
3. счет можно пополнять как приспичит
минусы:
если нет денег на карте, а в карманах только мелочь, тяжело пополнять счет
-
ДенисКа, хороший вариант.
Данная схема усложняется если большой выбор блюд (супы, гарниры, горячие блюда), очень много считывателей придется ставить.
Сложно организовать гибкость с ситуацией пол блюда.
Не продуман вопрос отказа от выбранного блюда, если деньги списываются (начисляются) в момент заказа. Нужно либо чтобы раздатчик подтвердил факт выдачи (например прикладыванием своей карты или кнопкой) или механизм "отказа".
"минусы:
если нет денег на карте, а в карманах только мелочь, тяжело пополнять счет".
По идее в той постановке что у автора нет проблем взять деньги с сотрудника потом.
Вопрос пополнения счета можно из данного варианта исключить.
-
1. сотрудник регистрирповался в системе заказа обеда пропуском
будет аналогично
2. из электронного меню выбирал блюда (меню формировалось за 2 часа до обеда администратором системы)
как-то так же
3. сформировав заказ, сотрудник его подверждал
пока очень похоже
4. чек печатался сразу на месте работника столовой
5. сотрудник подходил к работнику столовой и оплачивал обед по распечатанному чеку (обеды не были беплатными :( )
уже не похоже. поскольку выделенный работник на "кассе" и чеках - типа считается неоптимальным и ненужным. При этом обеды у нас не бесплатные, а оплачиваются через удержание из зааботной платы в конце месяца
6. далее сотрудник шел на выдачу обеда, где повар по чеку формировал заказ
Этот шаг по сути в моем варианте 1 предполагается, единственно. что повар-работник столовой должен подтвердить выполнение, регистрацией чека черес скансистему. Чек надрывается и отдается сотруднику как доказательство, например.
-
Интересный вариант, но нерентабельный. Считываетель - это устройство, их нужно столько сколько блюд. Устройство стоит денег и не малых. Неясно как отменять ошибочно заказанное блюдо или блюдо которое закончилось. а оператинво его не заблокировали (ну несли вам котлету и уронили ее . а она последняя)
-
Кстати, уважаемый, Galogen, пора бы уточнить первоначальную постановку указав там те ограничения что выявились в процессе обсуждения вариантов:
"Отказ от кассира"
"Ограничение по бюджету"
"Отсутствие необходимости оплаты"
и т.п.
А можно пофантазировать?
Каждому блюду на текущий день после фиксирования меню присваивается числовой код.
Все тарелки и емкости унифицированы по типам (одинаковые глубокие, одинаковые неглубокие)
На раздаче одно блюдо помещается только в одну емкость (тарелку).
Сверху тарелка накрывается крышкой с кодом блюда.
Обедающий при входе на раздачу сканирует свою карту (типа приступил к выбору).
Обедающий как в обычной столовой набирает блюда, расставляет их на поднос.
На выходе с раздачи устанавливает поднос в специально обозначенное место, сканирует карту.
Система фотографирует изображение подноса, сохраняет его в систему. По данному изображению выполняется распознавание кодов блюд. После этого открывается барьер для выхода обедающего (чтобы не получилось что ушел не сфотографировавшись)
Минусы:
- нужна специальная посуда с крышками или удобный способ прикрепления кода к тарелке чтобы обеспечить корректное считывание
- если много тарелок сложно поместить на один поднос
- есть возможность махинаций сокрытия блюд путем установки тарелок друг на друга (лечится созданием снимка с другой камеры расположенной в другой плоскости).
-
Задача опытного аналитика, довольствуясь неполной информацией и учтя возможные пути развития, предложить наиболее оптимальные варианты. Однако что считать критерием оптимальности? Соответствие требованиям заказчика, возможностью развития системы в будущем, минимальные затраты на реализацию?
наиболее оптимальных вариантов не бывает! бывают оптимальные (по заданным критериям) и неоптимальные (по ним же) :о)))
В качестве такой гимнастики ума хочу предложить два возможных решения одной несложной задачи.
все уже придумано до нас - горе-директора спасет бизнес-ланч. причем возможны варианты его комплектования. для столовой самое то. это, кстати, вполне проверенный вариант для смарт- и прочих карт и штрих-кодов: ставится сканер и сотрудник чекается после взятия ланча. контролер от столовой проверяет, чтобы не брали по несколько комплектов либо чекали карточку соответствующее число раз.
все остальное легко делается в компе, хоть в том же экселе.
при необходимости можно сделать интранет страничку с предварительными заказами. надо только решить вопрос, что делать с заказанными и невостребованными ланчами (у нас в свое время было автоматическое списание из з/п), и сколько ланчей нужно еще, чтобы удовлетворить оставшийся спрос (вдруг какие-нибудь клиенты приедут, которых надо покормить). впрочем, второй вопрос решается довольно просто, цена ланча несколько завышается, чтобы покрывать дополнительные издержки.
вариация 1
будет сенсорный экран (терминал).
сотрудник авторизуется средствами быстрой идентификации (прокси, смарт-карты. штрих-коды и т.п.)
сотрудник делает заказ, нажимая пункты интерактивного меню и по завершению заказа печатает чек
сотрудник встает в очередь, отдает чек работнику столовой, получает обед
работник столовой выдает обед, регистрирует чек в системе, проводя им под сканером штрих-кода (подтверждает исполнение заказа)
если какое-то блюдо закончилось, сотрудник возвращается к терминалу, авторизуется вновь и исправляет текущий заказ, печатает новый чек
а в иваново есть макдональдс? там все это уже реализовано - достаточно внимательно посмотреть.
вариация 2
будет сенсорный экран (терминал).
сотрудник авторизуется средствами быстрой идентификации (прокси, смарт-карты. штрих-коды и т.п.)
сотрудник делает заказ, нажимая пункты интерактивного меню, и по завершению подтверждает заказ
сотрудник встает в очередь (предполагается, что заказ он делает в тот момент, когда предыдущий уже получает свой заказ), получает свой обед
работник столовой после выдачи обеда нажатием на экране, подтверждает исполнение заказа этого сотрудника, на экране отображается следующий в очереди заказ
если какое-то блюдо закончилось, работник столовой извещает сотрудника об этом и по его распоряжению корректирует заказ или вообще отменяет
формально правильнее чек "пробивать" (печатать) по факту, чем мучиться с исправлением текущего заказа, повторными авторизациями, извещениями, распоряжениями и прочей хренью. для этого достаточно иметь в меню блюда равной стоимости в одной категории.
-
поскольку выделенный работник на "кассе" и чеках - типа считается неоптимальным и ненужным. При этом обеды у нас не бесплатные, а оплачиваются через удержание из зааботной платы в конце месяцаЭтот шаг по сути в моем варианте 1 предполагается, единственно. что повар-работник столовой должен подтвердить выполнение, регистрацией чека черес скансистему. Чек надрывается и отдается сотруднику как доказательство, например.
В том варианте, который был реализован у нас - не было сохранения стоимости обеда, оплата происходила сразу же.
Поэтому работник на кассе, да не нужный элемент.
Вообще для предложенной схемы подойдет любая система с электронным меню.
Понадобится два терминала один для сотудника, второй у повора на раздаче с правами администратора (блокировка, разблокировка блюд, закрытие заказа и т.д.)
Сотруднику после подтверждения заказа выдается чек с номером заказа. Подходя к раздаче он говорит работнику столовой номер, который напечатан на чеке. У работника столовой на терминале отображается заказ - он его формирует и помечает как исполененый. При этом сотруник на раздаче может внести изменения в заказ (возможно стоит подверждать внесенные изменения пропуском сотрудника).
При этом система может отслеживать количество заказанных порций блюд (если их заранее внести в систему) и блокировать блюдо в меню при исчерпании
-
Для ускорения процесса указания блюд текущего меню может быть представлен картинками разбит по категориям, либо на посуде с блюдом зафиксирован штрих-код, либо к терминалу подключена дополнительная клавиатура с картинками (как в весах в магазинах, замена картинок и названий блюд на клавиатуре производится после согласования меню до начала работы).
зачем такие сложности? "Когда у общества нет цветовой дифференциации штанов, то нет цели!" (с)
в меге, например, есть типа иппонский суши-бар (название не помню): там блюда одной стоимости ездят по транспортеру в тарелочках одного цвета. пациент клиент сам берет то, что ему нравится из представленного ассортимента. когда официант/кассир фиксирует оплату, он считает общую стоимость в этих же единицах: три синих по писят, два желтых по семьдесят, один фиолетовый по сто и т.п.
-
зачем такие сложности? "Когда у общества нет цветовой дифференциации штанов, то нет цели!" (с)
в меге, например, есть типа иппонский суши-бар (название не помню): там блюда одной стоимости ездят по транспортеру в тарелочках одного цвета. пациент клиент сам берет то, что ему нравится из представленного ассортимента. когда официант/кассир фиксирует оплату, он считает общую стоимость в этих же единицах: три синих по писят, два желтых по семьдесят, один фиолетовый по сто и т.п.
Ну это я попытался поставить себя на место начальника столовой, для которого идентификация с точностью до блюда позволит:
- автоматически формировать по раскладке списание продуктов входящих в это блюдо
- позволяет контролировать какое конкретно блюдо продано, для статистики и расчета потребности в продуктах
- разбираться какие блюда могли оказать негативное влияние на организм обедающего (да и такие случаи известны, ходили расспрашивали обедающих что они вчера ели).
-
Ну это я попытался поставить себя на место начальника столовой, для которого идентификация с точностью до блюда позволит:
- автоматически формировать по раскладке списание продуктов входящих в это блюдо
- позволяет контролировать какое конкретно блюдо продано, для статистики и расчета потребности в продуктах
- разбираться какие блюда могли оказать негативное влияние на организм обедающего (да и такие случаи известны, ходили расспрашивали обедающих что они вчера ели).
Вы забываете, что в первую очередь начальник чукотки столовой должен обеспечить сбыт (должно быть накормлено Х человек), а уже для его обеспечения определять потребность в продуктах, знать технологии приготовления, иметь соответствующей оборудование (для готовки и торговое) и т.п. Степень автоматичности обратно пропорциональна степени геморройности для конкретного начальника получения второстепенной информации (в т.ч. по результатам продаж).
-
наиболее оптимальных вариантов не бывает! бывают оптимальные (по заданным критериям) и неоптимальные (по ним же) :о)))
уел, Водолеюшка. Ох, уел...
все уже придумано до нас - горе-директора спасет бизнес-ланч. причем возможны варианты его комплектования. для столовой самое то. это, кстати, вполне проверенный вариант для смарт- и прочих карт и штрих-кодов: ставится сканер и сотрудник чекается после взятия ланча. контролер от столовой проверяет, чтобы не брали по несколько комплектов либо чекали карточку соответствующее число раз.
все остальное легко делается в компе, хоть в том же экселе.
при необходимости можно сделать интранет страничку с предварительными заказами. надо только решить вопрос, что делать с заказанными и невостребованными ланчами (у нас в свое время было автоматическое списание из з/п), и сколько ланчей нужно еще, чтобы удовлетворить оставшийся спрос (вдруг какие-нибудь клиенты приедут, которых надо покормить). впрочем, второй вопрос решается довольно просто, цена ланча несколько завышается, чтобы покрывать дополнительные издержки.
Читай первый пост
а в иваново есть макдональдс? там все это уже реализовано - достаточно внимательно посмотреть.
Их реализация построена на другом принципе
формально правильнее чек "пробивать" (печатать) по факту, чем мучиться с исправлением текущего заказа, повторными авторизациями, извещениями, распоряжениями и прочей хренью.
неплохо, но если пробивать по факту. т.е. на стороне работника столовой после реализации заказа - зачем вообще тогда чек нужен?
для этого достаточно иметь в меню блюда равной стоимости в одной категории.
а если их нет, тогда что? и опятьже читаем первый пост
-
Имеется столовая (внутренняя).Количество сотрудников достаточное, чтобы подумать об оптимизации процесса заказа обедов и учета этих заказов. В текущий момент времени учет взятых обедов сотрудником ведется просто: работник столовой сидит на выдаче, слушает заказа, подсчитывает его сумму, записывает результат в журнал, дает на подпись сотруднику. Такая ситуация не нравится директору: человек отвлекается на ведение учета, учет ведется вручную, оперативности нет, получить данные по сотруднику сложно, нет детализирования, трудно вести статистику.
Кстати, уважаемый, Galogen, пора бы уточнить первоначальную постановку указав там те ограничения что выявились в процессе обсуждения вариантов:
"Отказ от кассира"
"Ограничение по бюджету"
"Отсутствие необходимости оплаты"
и т.п.
1. кассир не нужен
2. естественно есть ограничение по бюджету. вариант со считывтелем на каждом образце блюда - это по-моему через чур
3. оплата через удержания из заработной платы
А можно пофантазировать?
Нужно :)
Каждому блюду на текущий день после фиксирования меню присваивается числовой код.
Все тарелки и емкости унифицированы по типам (одинаковые глубокие, одинаковые неглубокие)
На раздаче одно блюдо помещается только в одну емкость (тарелку).
Сверху тарелка накрывается крышкой с кодом блюда.
Обедающий при входе на раздачу сканирует свою карту (типа приступил к выбору).
Обедающий как в обычной столовой набирает блюда, расставляет их на поднос.
На выходе с раздачи устанавливает поднос в специально обозначенное место, сканирует карту.
Система фотографирует изображение подноса, сохраняет его в систему. По данному изображению выполняется распознавание кодов блюд. После этого открывается барьер для выхода обедающего (чтобы не получилось что ушел не сфотографировавшись)
Минусы:
- нужна специальная посуда с крышками или удобный способ прикрепления кода к тарелке чтобы обеспечить корректное считывание
- если много тарелок сложно поместить на один поднос
- есть возможность махинаций сокрытия блюд путем установки тарелок друг на друга (лечится созданием снимка с другой камеры расположенной в другой плоскости).
очень оригинально, но сложно на мой взгляд и требует высокой квалификации не просто программиста, а математика, чтобы все это замоделировать
-
В том варианте, который был реализован у нас - не было сохранения стоимости обеда, оплата происходила сразу же.
Поэтому работник на кассе, да не нужный элемент.
Вообще для предложенной схемы подойдет любая система с электронным меню.
Понадобится два терминала один для сотудника, второй у повора на раздаче с правами администратора (блокировка, разблокировка блюд, закрытие заказа и т.д.)
Сотруднику после подтверждения заказа выдается чек с номером заказа. Подходя к раздаче он говорит работнику столовой номер, который напечатан на чеке. У работника столовой на терминале отображается заказ - он его формирует и помечает как исполененый. При этом сотруник на раздаче может внести изменения в заказ (возможно стоит подверждать внесенные изменения пропуском сотрудника).
При этом система может отслеживать количество заказанных порций блюд (если их заранее внести в систему) и блокировать блюдо в меню при исчерпании
По-моему это очень похоже на мой второй вариант.
Даю определеную вводную: заказчик полаает(и выдвигает такое требование). чтобы у работника на выдаче никаких компьютеров не было- "Еще чего ставить терминал для работника. Он же пищу выдает и этими руками будет в монитор тыкать?" Будет ли это определяющим требованием?
-
Может все-таки определим критерии оптимальности?
Типа таких:
- разумная минимизация затрат на обслуживание (считаем, что затраты на приготовление блюд постоянны)
- минимизация затрат на контроль (при этом не исключение затрат и, собственно, контроля)
- минимизация затрат на учет (наверное еще достоверность учета)
- минимизация времени (затрат?) на формирование отчетности (разумеется, возможность формирования отчетности в различных разрезах)
Тут IMHO недостаточно рассматривать по отдельности процедуру заказа/выбора блюда, расчета и т.п. Тут нужно строить технологию обслуживания в целом, начиная с того, что реализуется (под видом обеда :о))) сотрудникам. Я бы посоветовал выписать в столбик (например) выполняемые операции и исключить те, которые "не приносят ценности", чтобы получить только то, без чего процесс обслуживания в принципе работать не может.
если говорить на уровне автоматов и предельной фантазии (вспоминая не то носова, не то шекли):
- сотрудник подходит к стойке,
- сует куда-нить свою карточку (скажем так - в считыватель)
- открывается дверца
- и оттуда выезжает на подносике полностью укомплектованный бизнес ланч (вариант: сотрудник самостоятельно берет subj из открывшейся ниши)
всё!
-
Может все-таки определим критерии оптимальности?
- минимизация затрат на контроль (при этом не исключение затрат и, собственно, контроля)
- минимизация затрат на учет (наверное еще достоверность учета)
- минимизация времени (затрат?) на формирование отчетности (разумеется, возможность формирования отчетности в различных разрезах)
- возможность получать информацию в разрезах блюд, сумм, дней, сотрудников и т.п.
Тут IMHO недостаточно рассматривать по отдельности процедуру заказа/выбора блюда, расчета и т.п. Тут нужно строить технологию обслуживания в целом, начиная с того, что реализуется (под видом обеда :о))) сотрудникам. Я бы посоветовал выписать в столбик (например) выполняемые операции и исключить те, которые "не приносят ценности", чтобы получить только то, без чего процесс обслуживания в принципе работать не может.
Ну не надо усложнять. У тебя есть некий набор блюд, который приготовил повар - как творческая натура он делает творческое меню.
если говорить на уровне автоматов и предельной фантазии (вспоминая не то носова, не то шекли):
....
- и оттуда выезжает на подносике полностью укомплектованный бизнес ланч (вариант: сотрудник самостоятельно берет subj из открывшейся ниши)
всё!
Дался тебе этот бизнес-ланч :)
-
Дался тебе этот бизнес-ланч :)
а что? простой и понятный (теперь) термин :о)))
предлагаю все-таки двигаться в сторону традиционного управленческого цикла, а не продавать сотрудникам то, что повар-творец натворит :о)))
т.е. планируем и организуем деятельность - реализуем/контролируем - учитываем - строим отчеты и анализируем достигнутые результаты
-
Все! Концепция продана. К моему сожалению. Найден какой-то 1с программист, который типа сделает все качественно, быстро и дешево. И .. без наших аналитических рефлексий.
-
Все! Концепция продана. К моему сожалению. Найден какой-то 1с программист, который типа сделает все качественно, быстро и дешево. И .. без наших аналитических рефлексий.
ну вот и я думаю...зачем аналитики нужны?
-
Все! Концепция продана... Найден какой-то 1с программист...
Вы ж уже накалывались на этом и, насколько я понимаю, неоднократно. Впрочем, скупой хозяин-барин платит дважды.
-
Для "хотелок", не связанных с основными бизнес-процессами использование такого подхода (нанять специалиста по конкретной системе) вполне оправдано.
Главное чтобы специалист не начал изобретать велосипед, и писать уникальную систему с 0.
Есть готовое решение 1С:Ресторан+Бар+Кафе на 7.7.
Вот мой еще один вариант минимизирующий оборудование и затраты на ПО.
1. Система (С) находится в режиме ожидания выбора пользователя:
Заказ
Отмена.
2. Обедающий (О) выбирает вариант Заказ.
2.1. С запрашивает сканирование карты, ожидает сканирования.
2.2. О сканирует карту
2.3. С переходит в режим формирования заказа, высвечивает текущее меню.
2.4. О выбирает блюда, завершает оформление заказа. Если отказывается от заказа возврат на шаг 1.
2.5. С печатает чек с составом заказа и шк заказа.
2.6. О передает чек работнику столовой (РС)
2.7. РС выдает блюда. Если выданы все блюда то сканирует ш/к, переход на ш. 2.8.
Исключение если блюда нет просит О отказаться от заказа и оформить новый. Обслуживание завершено. Возврат на ш. 1.
2.8. С по шк чека находит заказ, проставляет статус выдан. Обслуживание завершено. Возврат на ш. 1.
3. О выбирает вариант Отмена заказа
3.1. С ожидает сканирования шк на чеке
3.2. О сканирует шк чека
3.3. С отменяет действие заказа (если он не еще не отменен или не выдан). Обслуживание завершено. Возврат на ш. 1.
Оборудование: Касса на базе ПК, с сенсорным экраном, с доп оборудованием ридер магнитных карт, принтер чеков, сканер ШК (порядка 30 т.р.).
Поскольку реальных денег не пробивается то фискальный регистратор не нужен, кассовый ящик тоже, то можно взять обычнй моноблок и подключить к нему ридер и сканер ШК.
ПО: готовое решение 1С:Ресторан+Бар+Кафе на 7.7.
Доработка ПО под бизнес-процесс, без серьезного изменения основной функциональности конфигурации, 2-3 рабочих дня (порядка 20-30 т.р.).
В зависимости от перспектив "касса" подключается к локальной сети, для удаленного администрирования и управления. Для большей надежности базу можно разместить на сервере. Функциональность конфигурации используется только в той части какой нужно (либо тупо: "ведение меню, заказ, подтверждение, статистика" либо дополнительно: учет блюд, раскладка, учет продуктов, выгрузка в БД бухгалтерии и т.п).
-
Вы ж уже накалывались на этом и, насколько я понимаю, неоднократно. Впрочем, скупой хозяин-барин платит дважды.
Ты в данном случае ошибаешься. это два независмых события и точки принятия решения.
-
Интересное решение. Простое и, кажется, отработанное. Единственно - как это выглядит 1С:Ресторан+Бар+Кафе на 7.7 и удобно ли этим пользоваться?
-
Интересное решение. Простое и, кажется, отработанное. Единственно - как это выглядит 1С:Ресторан+Бар+Кафе на 7.7 и удобно ли этим пользоваться?
Базовые формы экранные рассчитаны на работу кассира.
Формы в данной конфигурации не заточены под ввод с экрана и там стандартный интерфейс.
В том варианте что я видел не очень удачный был экран - маленький и тыкать нужно было в экран каким либо предметом типа карандаша (или той же карточкой). Однако это не мешало достаточно быстро кассиру выбирать позиции.
Администратор может работает с системой удаленно используя обычную клавиатуру и мышь.
Но собственно это и есть предмет доработки системы (на это я оптимистично отвел 2-3 рабочих дня программиста 1С).
Несколько дополнений.
При включении терминала обеспечивается запуск двух сессий системы.
1. Сессия для работы с заказами. В этой сессии работа выполняется только с тремя формами.
"выбора варианта"
"ввода заказа"
"отказа от заказа"
При выборе варианта модально открывается соответствующая форма.
На форме "ввода заказа" в виде картинок размещается содержимое текущего меню, над дизайном можно подумать.
Вариант размещения меню на форме может зависеть от нескольких факторов, но это уже детали.
Далее эта форма использует стандартный документ системы Заказ его программно создает, заполняет, дает команду печатать чек.
После закрытия формы "ввода заказа"система снова возвращается в форму "выбора вариантов".
Закрыть работу сессии может только пользователь знающий специальный пароль.
2. Сессия для работника столовой. В этой сессии работа с системой визуально не выполняется, программно открывается специальная форма, в которой обрабатывается только событие считывания шк.
Необходимо покупать многопользовательскую версию, как минимум на трех одновременно работающих пользователей: 2 сессии рабочие + сессия для администрирования (ввод номенклатуры, меню, цен и т.п.). Это чтобы в случае необходимости вносить изменения в справочники, меню, цены и т.п. не завершая рабочие сессии.
http://rarus.ru/1c-restoran/1c-rarus-restoran-bar-kafe2-5-st-s/
Единственный минус, новые версии системы не поддерживаются, и платформа 7.7 устаревшая. Хотя для таких задач очень даже подходит, требования к ресурсам низкие, надежность работы.
-
Стоимость работ на мой взгляд великовата: 20-30 тыс. за оптимистичные 2-3 дня или пессимистичную неделю.
Я, правда, не знаю каким образом формируются расценки. Хотя понятно, что заказчик стремится заплатить меньше, исполнитель наоборот получить больше.
Интерфейсные возможности 1С ограничены, Вы полагает, что легко сделать простой и вместе с тем приятный в использовании интерфейс?
-
Стоимость работ на мой взгляд великовата: 20-30 тыс. за оптимистичные 2-3 дня или пессимистичную неделю.
Я, правда, не знаю каким образом формируются расценки. Хотя понятно, что заказчик стремится заплатить меньше, исполнитель наоборот получить больше.
Я очень усредненно посчитал, по ставке 1250 руб в час. так 3(дня)*8(часов)* 1250 руб. = 30'000 руб.
У фрилансеров можно подешевле найти, у франчайзи дороже.
Интерфейсные возможности 1С ограничены, Вы полагает, что легко сделать простой и вместе с тем приятный в использовании интерфейс?
Даже на 7.7 можно сделать красиво, удобно и быстро.
Вариант 1.
Все блюда на одной закладке.
Подходит при известном и не очень большом количестве блюд в категории (4-5)
При количестве категорий 4-5.
Форма делится ряды. Один ряд соответствует одной категории.
В ряду для каждого блюда размещается три элемента кнопка выбора блюда, картинка блюда, название блюда.
К сожалению не помню есть ли возможность в 7.7 изображение программно для кнопки менять (в 8-ке реально). Если можно то тогда прямо на кнопке выводится изображение блюда и лишний элемент не нужен.
При этом дополнительно можно для каждого блюда галочками отмечать что оно уже выбрано.
Можно сделать одну кнопку для выбора блюда в категории и одно поле для картинки, и кнопки листать картинки вперед - назад. При нажатии вперед выводится картинка следующего блюда, назад предыдущего.
Вариант 2.
На каждую категорию блюд своя закладка.
Закуски, Первое, Гарнир, Горячее, Напитки и т.п.
На каждой закладке перечень картинок с блюдами текущего меню, как в варианте 1.
Этот вариант если блюд в категории много и нужно много кнопок и картинок разместить.
Заголовок и подвал одинаковые для обоих вариантов.
Количество кнопок и картинок изначально избыточное размещается, при открытии формы лишние кнопки "прячутся".
В заголовке формы имя сотрудника и номер карты (пропуска, табельный)
В подвале формы в виде таблицы перечень отмеченных блюд и кнопки принять заказ и отказ от заказа.
При нажатии принять заказ программно формируется заказ, в котором в виде строк перечисляются номенклатуры соответствующие выбранным позициям (в принципе в таблице выбранных уже эти позиции определены).
-
Ваша идея, очень близкая к моей первоначальной.
Однако потом в ходе дискуссий мы с товарищем придумали нечто такое, см. вложение.
Т.е. поскольку меню будет не очень большим, то нет нужды делать дополнительную таблицу. Даже если меню будет куда разнообразнее, тоже можно придумать что-то похожее, но уйти от концепции таблицы или какого-то списка.
Идея я надеюсь понятная. Это конечно только одно состояние скрина. Но в целом, каждый элемент экрана представляется как автомат реагирующий на конечное множество входных сообщений=событий
-
Ваша идея, очень близкая к моей первоначальной.
Так это собственно и есть ваш вариант 1, просто описан подробно сценарий взаимодействия с системой.
И приведен пример реализации на готовом решении.
-
Так это собственно и есть ваш вариант 1, просто описан подробно сценарий взаимодействия с системой.
И приведен пример реализации на готовом решении.
Ну, конечно. Просто я имел в виду идею интерфейса, а не подробности сценария взаимодействия.
-
Варианты решения - это всегда хорошо.
Хотелось бы предложить вариант, но я не увидела обозначенных целей решения задачи. Тем более нет сортировки целей по важности.
Понятно, что цели не всегда можно сравнить и т.п.
Однако, на начальной стадии проекта куда важнее определиться с целями и границами.
Варианты решения - это всегда самое интересное. Но почему бы не посмотреть как другие компании решали похожую задачу?
-
Варианты решения - это всегда хорошо.
Хотелось бы предложить вариант, но я не увидела обозначенных целей решения задачи. Тем более нет сортировки целей по важности.
Понятно, что цели не всегда можно сравнить и т.п.
Однако, на начальной стадии проекта куда важнее определиться с целями и границами.
Варианты решения - это всегда самое интересное. Но почему бы не посмотреть как другие компании решали похожую задачу?
Julia, скажите сколько будет 2347,5 Х 245,67 с точностью до третьего знака
-
Хотелось бы предложить вариант, но я не увидела обозначенных целей решения задачи. Тем более нет сортировки целей по важности
Одна из основных задач компетентного аналитика как раз и заключается из "проблем" и "хотелок" заказчика, выделить и зафиксировать цели.
Если обратить внимание на дискуссию по этой интересной в качестве разминки задачке, то можно увидеть что помимо обсуждения вариантов проводилась, в том числе работа по выявлению целей.
Да, в явном виде цели так и не были до конца оформлены, но думаю что для данной достаточно тривиальной задачи они очевидны:
- повышение удовлетворенности потребителей за счет:
- сокращения времени обслуживания
- улучшения качества обслуживания
- повышение рентабельности деятельности столовой компании за счет:
- уменьшения ФОТ
- повышения качества планирования на основе статистических данных
- повышения качества учета.
-
Одна из основных задач компетентного аналитика как раз и заключается из "проблем" и "хотелок" заказчика, выделить и зафиксировать цели.
Если обратить внимание на дискуссию по этой интересной в качестве разминки задачке, то можно увидеть что помимо обсуждения вариантов проводилась, в том числе работа по выявлению целей.
Да, в явном виде цели так и не были до конца оформлены, но думаю что для данной достаточно тривиальной задачи они очевидны:
- повышение удовлетворенности потребителей за счет:
- сокращения времени обслуживания
- улучшения качества обслуживания
- повышение рентабельности деятельности столовой компании за счет:
- уменьшения ФОТ
- повышения качества планирования на основе статистических данных
- повышения качества учета.
+1
Только первые две цели можно смело в топку:)
Результат внедрение 1С решения (сначала сильно отличающегося от моих предложений, теперь все больше и больше их принимающих) - заказа обеда стал гораздо больше. Основное местостояние теперь монитор заказа. Народ все-таки пока еще видимо боится технологических штучек. Однако в целом это напрягает только при относительно большом количестве народа.
Сотрудника принимающего и учитывающего заказ сократили. Остально без изменения. Есть обратная связь: оценка обеда и обслуживания. Но в цеом качество не изменилось, оно было и так не плохое, хотя субъективно оно ухудшилось - порции явно уменьшились, а цены слегка увеличились. Правда, причина может быть вполне объективной, происходила итерационная адаптация цены и размера блюд.
-
Основное местостояние теперь монитор заказа. Народ все-таки пока еще видимо боится технологических штучек.
Однако в целом это напрягает только при относительно большом количестве народа.
Значит интерфейс не настолько интуитивен и прост как мог бы быть.
Сотрудника принимающего и учитывающего заказ сократили. Остально без изменения. Есть обратная связь: оценка обеда и обслуживания. Но в целом качество не изменилось, оно было и так не плохое, хотя субъективно оно ухудшилось - порции явно уменьшились, а цены слегка увеличились. Правда, причина может быть вполне объективной, происходила итерационная адаптация цены и размера блюд.
Заказчик ставил целью издержки сократить, обеспечить как минимум "нулевую рентабельность".
Что говорит об отсутствии в его видении понимания, что при определенном уровне обслуживания и наличия дополнительного сервиса и организации продаж прочих товаров, можно увеличить выручку и повысить рентабельность. А за счет более высокой "маржи" на прочие товары обеспечить умеренные цены на еду. С другой стороны куда они "клиенты" денутся с подводной лодки, рядом наверно либо дороже либо далеко.
В мою бытность работы на предприятии связанном в продажей мясных продуктов, где была круглосуточная столовая и буфет в режиме рабочего дня, основная прибыль зарабатывалась именно на продукции и прочих товарах (там был наличный расчет и гости тоже пользовались услугами столовой).
-
DinamoYA, в данном случае Вы делаете неверные выводы вследствие неверных исходных положений.
Напомню:
1. все работники столовой - сотрудники нашей компании
2. обедают только сотрудники нашей компании (у нас порядка 250 человек, реально обедает половина ну или больше)
3. обеды не оплачиваются явно, просто начисляется на счет и вычитается из ЗП
4. обеды в целом вне конкуренции - стоимость минимум в два раза меньше, а качество очень неплохое, почти домашнее.
5. имхо, работодатель-заказчик, своих целей вполне добился - убрал баластную единицу из столовой, получил сведения в структурированном и доступном для дальнейшего использования виде.
Насчет интерфейса - это да поиграть юзабилити можно, но я пришел к выводу, что зазор тут невелик, подавляющее время тратится на чтение и выбор...
-
Понял Вас, уважаемый Эдуард, я просто стараюсь смотреть на это глазами "бизнеса, который в любой ситуации ищет возможности извлечения прибыли".
Предлагаю пофанатазировать как можно сделать текущий процесс еще более оптимальным и более удобным для "пользователей".
1. На внутреннем web-портале (если таковой имеется) делаем форму заказа. Если портала нет, то простенькую форму в excel где галочки нужно проставить или количество блюд.
2. Пользователь заблаговременно до похода в столовую формирует свой заказ и он транслируется в систему.
С вариантом excel файла отправляет файл на специальный e-mail (или на FTP или на файловый ресурс) с которого система 1С сама забирает и транслирует заказ в систему.
3. При посещении столовой регистрируется на терминале картой (пропуском), подтверждает печать заказа, система печатает чек.
ЛО: "В бытность моей работы в одной компании заказ делали на неделю вперед (правда на бумажечке), в конце текущей недели. Мне лично, такой вариант очень нравился поскольку мог супругу попросить не готовить вечером по будням те блюда которые я заказывал в этот день на обед. А для обслуживающей компании тоже сокращение издержек поскольку на неделю известен пул заказов и можно более оптимально планировать закупки."