1696

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 22:38:18 »

Все! Концепция продана. К моему сожалению. Найден какой-то 1с программист, который типа сделает все качественно, быстро и дешево. И .. без наших аналитических рефлексий.

1697

Идеи и мозговой штурм / Re: Применение Ваших знаний (как системных аналитиков) в собственной жизни. Цели.

« : 20 Июля 2011, 22:23:54 »

ida и Водолей, простите за простоту.
Не устраивайте срач! Дайте человеку высказаться и получить нормальные ответы

1698

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 17:30:37 »

Может все-таки определим критерии оптимальности?

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

Тут IMHO недостаточно рассматривать по отдельности процедуру заказа/выбора блюда, расчета и т.п. Тут нужно строить технологию обслуживания в целом, начиная с того, что реализуется (под видом обеда :о))) сотрудникам. Я бы посоветовал выписать в столбик (например) выполняемые операции и исключить те, которые "не приносят ценности", чтобы получить только то, без чего процесс обслуживания в принципе работать не может.

Ну не надо усложнять. У тебя есть некий набор блюд, который приготовил повар - как творческая натура он делает творческое меню.

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

Дался тебе этот бизнес-ланч

1699

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 16:04:11 »

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

По-моему это очень похоже на мой второй вариант.
Даю определеную вводную: заказчик полаает(и выдвигает такое требование). чтобы у работника на выдаче никаких компьютеров не было- "Еще чего ставить терминал для работника. Он же пищу выдает и этими руками будет в монитор тыкать?" Будет ли это определяющим требованием?

1700

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 16:00:41 »

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

Кстати, уважаемый, Galogen, пора бы уточнить первоначальную постановку указав там те ограничения что выявились в процессе обсуждения вариантов:
"Отказ от кассира"
"Ограничение по бюджету"
"Отсутствие необходимости оплаты"
и т.п.

1. кассир не нужен
2. естественно есть ограничение по бюджету. вариант со считывтелем на каждом образце блюда - это по-моему через чур
3. оплата через удержания из заработной платы

А можно пофантазировать?

Нужно

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

очень оригинально, но сложно на мой взгляд и требует высокой квалификации не просто программиста, а математика, чтобы все это замоделировать

1701

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 15:54:35 »

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

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

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

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

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

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

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

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

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

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

1702

Идеи и мозговой штурм / Re: Применение Ваших знаний (как системных аналитиков) в собственной жизни. Цели.

« : 20 Июля 2011, 13:14:09 »

Bas,  как Вы считаете,   я могу   дать ответ в теме Denis Beskov  на его  вопрос? Ответ  м.б.  длинным.

Если Вам хочется, you are welcome

1703

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:12:18 »

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

1704

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 13:09:00 »

1. сотрудник регистрирповался в системе заказа обеда пропуском

будет аналогично

2. из электронного меню выбирал блюда (меню формировалось за 2 часа до обеда администратором системы)

как-то так же

3. сформировав заказ, сотрудник его подверждал

пока очень похоже

4. чек печатался сразу на месте работника столовой
5. сотрудник подходил к работнику столовой и оплачивал обед по распечатанному чеку (обеды не были беплатными )

уже не похоже. поскольку выделенный работник на "кассе" и чеках - типа считается неоптимальным и ненужным. При этом обеды у нас не бесплатные, а оплачиваются через удержание из зааботной платы в конце месяца

6. далее сотрудник шел на выдачу обеда, где повар по чеку формировал заказ

Этот шаг по сути в моем варианте 1 предполагается, единственно. что повар-работник столовой должен подтвердить выполнение, регистрацией чека черес скансистему. Чек надрывается и отдается сотруднику как доказательство, например.

1705

Системный Анализ и Требования / Re: Какое решение оптимальнее?

« : 20 Июля 2011, 09:58:25 »

Спасибо, DinamoYA

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

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

Может подробнее рассмотрим все негативные аспекты каждого варианта?
1. вариант с чеком
 самое проблемное, это когда сотрудник сделал заказа, подошел к выдаче. А блюдо закончилось, что делать? Я предполагал возвращаться к терминалу и перезаказывать. Этот вариант вполне нормален, если народу раз два, и куда как не нормален, если в подобную "ловушку" попалось сразу человек 10.
 минимизировать риск такого явления можно было бы контролируя доступное, заказанное и реально выданное количество блюд,  своевременным изменением меню. Правда, здесь есть риск что будто бы блюдо кончилось, а реально оно все-таки есть.

2. вариант с интерфейсом у работника столовой имеет на мой взгляд 1 недостаток: он в лозунге: "1 в очереди обслуживается, второй делает заказ, третий знакомится с меню", т.е. все-таки получается, что обслуживание несколько будет торомозится по сравнению  1 вариантом, зато полностью снимаются проблемы с некорректно сделанным заказом, заказом закончившегося блюда, нет печатать чек - он в целом похож на Ваш 3 вариант.

Но заказчки как-то высказался против такого, работник на выдаче выдает питание и ни его задача тыкать пальцем в монитор, принять чек - максимум на что мы можем рассчитывать

1706

Системный Анализ и Требования / Какое решение оптимальнее?

« : 19 Июля 2011, 22:56:12 »

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

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

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

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

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

Что вы можете сказать по этим вариантам, который из них вы предпочли бы и почему, может вы предложите свой вариант?

1707

Идеи и мозговой штурм / Re: Что влияет на качество документов Аналитика?

« : 19 Июля 2011, 22:13:49 »

Если вы не ищите ошибки в документации, то зачем вы вообще документацию пишете? Она просто не нужна.

То есть обычно документацию пишут для того, чтобы искать ошибки? Ну что бы было кому за что официально платить зарплату? Так получается?

1708

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 18 Июля 2011, 16:11:06 »

Это давний гемор, я его встречал на всех версиях в той или иной степени

pha, пиши жалобу я опубликую на сайте.

1709

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 18 Июля 2011, 15:01:15 »

Ждем

1710

Sparx / Re: Enterprise Architect: Проблема с генерацией отчетов

« : 18 Июля 2011, 09:04:05 »

Опишите ситуацию на английском, я зашлю в поддержку, глядишь ответят