Задача опытного аналитика, довольствуясь неполной информацией и учтя возможные пути развития, предложить наиболее оптимальные варианты. Однако что считать критерием оптимальности? Соответствие требованиям заказчика, возможностью развития системы в будущем, минимальные затраты на реализацию?

В качестве такой гимнастики ума хочу предложить два возможных решения одной несложной задачи.

Имеется столовая (внутренняя).Количество сотрудников достаточное, чтобы подумать об оптимизации процесса заказа обедов и учета этих заказов. В текущий момент времени учет взятых обедов сотрудником ведется просто: работник столовой сидит на выдаче, слушает заказа, подсчитывает его сумму, записывает результат в журнал, дает на подпись сотруднику. Такая ситуация не нравится директору: человек отвлекается на ведение учета, учет ведется вручную, оперативности нет, получить данные по сотруднику сложно, нет детализирования, трудно вести статистику.

Предложили:
вариация 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 предполагается, единственно. что повар-работник столовой должен подтвердить выполнение, регистрацией чека черес скансистему. Чек надрывается и отдается сотруднику как доказательство, например.

В том варианте, который был реализован у нас - не было сохранения стоимости обеда, оплата происходила сразу же.
Поэтому работник на кассе, да не нужный элемент.
Вообще для предложенной схемы подойдет любая система с электронным меню.
Понадобится два терминала один для сотудника, второй у повора на раздаче  с правами администратора (блокировка, разблокировка блюд, закрытие заказа и т.д.)
Сотруднику после подтверждения заказа выдается чек с номером заказа. Подходя к раздаче он говорит работнику столовой номер, который напечатан на чеке. У работника столовой на терминале отображается заказ - он его формирует и помечает как исполененый. При этом сотруник  на раздаче может внести изменения в заказ (возможно стоит подверждать внесенные изменения пропуском сотрудника).
При этом система может отслеживать количество заказанных порций блюд (если их заранее внести в систему) и блокировать блюдо в меню при исчерпании

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

зачем такие сложности? "Когда у общества нет цветовой дифференциации штанов, то нет цели!" (с)
в меге, например, есть типа иппонский суши-бар (название не помню): там блюда одной стоимости ездят по транспортеру в тарелочках одного цвета. пациент клиент сам берет то, что ему нравится из представленного ассортимента. когда официант/кассир фиксирует оплату, он считает общую стоимость в этих же единицах: три синих по писят, два желтых по семьдесят, один фиолетовый по сто и т.п.

зачем такие сложности? "Когда у общества нет цветовой дифференциации штанов, то нет цели!" (с)
в меге, например, есть типа иппонский суши-бар (название не помню): там блюда одной стоимости ездят по транспортеру в тарелочках одного цвета. пациент клиент сам берет то, что ему нравится из представленного ассортимента. когда официант/кассир фиксирует оплату, он считает общую стоимость в этих же единицах: три синих по писят, два желтых по семьдесят, один фиолетовый по сто и т.п.

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

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

Вы забываете, что в первую очередь начальник чукотки столовой должен обеспечить сбыт (должно быть накормлено Х человек), а уже для его обеспечения определять потребность в продуктах, знать технологии приготовления, иметь соответствующей оборудование (для готовки и торговое) и т.п. Степень автоматичности обратно пропорциональна степени геморройности для конкретного начальника получения второстепенной информации (в т.ч. по результатам продаж).

наиболее оптимальных вариантов не бывает! бывают оптимальные (по заданным критериям) и неоптимальные (по ним же) :о)))

уел, Водолеюшка. Ох, уел...

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

Читай первый пост

а в иваново есть макдональдс? там все это уже реализовано - достаточно внимательно посмотреть.

Их реализация построена на другом принципе

формально правильнее чек "пробивать" (печатать) по факту, чем мучиться с исправлением текущего заказа, повторными авторизациями, извещениями, распоряжениями и прочей хренью.

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

для этого достаточно иметь в меню блюда равной стоимости в одной категории.

а если их нет, тогда что? и опятьже читаем первый пост