Здравствуйте, DreamWeaver, Вы писали:

DW> Ну тут нужно определиться о чем мы говорим. Если мы говорим о дорогом элитном ресторане в старом стиле, который не использует навороченные системы и девушек с КПК только потому чтобы не портить общую атмосферу (а не потому что денег жалко или нет), то, думаю они найдут человека с большим опытом, который посчитает почти мгновенно (6.5 + (40% от 4.25) + 1.7) — 10% от всей суммы (лично я это смогу быстро посчитать только на калькуляторе, в уме если считать потребуется некоторое время). Но я ориентирую свой продукт на небольшие кафешки и ресторанчики, которые не внедряют такие системы, потому что дорого. Официантки в таких кафешках обычно получают мизер и там работаю в основном студентки на подработке и обычно в таких заведения большая текучка, поэтому говорить о том, что официантка может быстро посчитать что я выше приводил — не приходится.

Черт побери еще раз. Что это за студентки такие там, что не в состоянии 5-10 чисел сложить, а делают это с ошибками! А на базар ты иногда ходишь ? Там КПК еще 100 лет не будет, а подсчитывают без особых проблем, и не только подсчитывают, но еще и обсчитывают. Вполне виртуозно. Хотя студенток там нет.

И далее — ну пусть иногда и делают ошибку, но как часто, и стоит ли на это обращать внимание ? Сколько денег может недополучить заведение из-за этих ошибок, и когда эта сумма достигент величины, чтобы оплатить все КПК и прочее компьютерное оборудование вместе с лицензиями ? А если найдется одна официантка, которая часто ошибается, то либо направить ее на ускоренные курсы арифметики начальных классов, либо просто выгнать. При большой текучке одной дурой больше, одной меньше...


>А когда она одна на 15-20 столов и все от нее чего-то хотят одновременно, ошибиться по-моему не мудрено.

Да что за проблема такая ? Ну записала она в свой блокнот "шницель 2, пиво 4, оливье 2". И что, теперь сложно подсчитать ? Не верю!!!

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Не верю!!!
Вы фамилию верно указали в профиле?

Усложним задачу.
За столом 4 гостя, каждый платит за себя.
Заведение — загородный клуб. Столик стоит у реки, кухня метрах в двухстах.

Здравствуйте, gandjustas, Вы писали:

G>Что значит "постоянная" ? Она вероятнее всего будет происходить один раз при изменении меню (то есть оооочень редко).

Откуда клиент узнает об изменении меню? Ему придется регулярно дергать сервер. А сам по себе такой http запрос/ответ немногим меньше
запроса/ответа со списком блюд в меню. Тем более запрос списка блюд он привязан к логике и мы вполне можем ему лично задать нужное кеширование
на любом участке.

Z>>Я еще раз спрошу, выполнение каких требований обеспечивает (или облегчает) введение систему следующих механизмов: "локальная бд", "сервис синхронизации"?
G>Уменьшение нагрузки на сеть\сервер
как я показал уменьшение никакое, скорее увеличение, в твоем решении клиенты регулярно впустую опрашивают сервис обновления.

G>Увеличение скорости работы интерфейса на КПК
Ага, вместо того, чтобы взять из кеша мы сделаем запрос. Откуда ускорение?

G>Если постараться, то можно сделать прием заказов при отсуствии связи с сервером (но толку от такого мало)
Вот... первый реальный плюс, но как ты сам заметил, толку от него действительно мало.

G>А вообще не надо бояться локльных бд и синхронизации, это довольно простые в использовании вещи. Даже проще, чем делать cache-friendly веб-приложение.
Приложение все равно писать придется, AJAX, SL или WPF, это уже не суть важно. А вот сопровождение одного сервера сильно отличается от сопровождение одного сервера
и нескольких десятков рабочих мест.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Здравствуйте, DreamWeaver, Вы писали:

DW>> Ну тут нужно определиться о чем мы говорим. Если мы говорим о дорогом элитном ресторане в старом стиле, который не использует навороченные системы и девушек с КПК только потому чтобы не портить общую атмосферу (а не потому что денег жалко или нет), то, думаю они найдут человека с большим опытом, который посчитает почти мгновенно (6.5 + (40% от 4.25) + 1.7) — 10% от всей суммы (лично я это смогу быстро посчитать только на калькуляторе, в уме если считать потребуется некоторое время). Но я ориентирую свой продукт на небольшие кафешки и ресторанчики, которые не внедряют такие системы, потому что дорого. Официантки в таких кафешках обычно получают мизер и там работаю в основном студентки на подработке и обычно в таких заведения большая текучка, поэтому говорить о том, что официантка может быстро посчитать что я выше приводил — не приходится.

PD>Черт побери еще раз. Что это за студентки такие там, что не в состоянии 5-10 чисел сложить, а делают это с ошибками! А на базар ты иногда ходишь ? Там КПК еще 100 лет не будет, а подсчитывают без особых проблем, и не только подсчитывают, но еще и обсчитывают. Вполне виртуозно. Хотя студенток там нет.

На базар ходил, там обычно с калькуляторами все.

PD>И далее — ну пусть иногда и делают ошибку, но как часто, и стоит ли на это обращать внимание ? Сколько денег может недополучить заведение из-за этих ошибок, и когда эта сумма достигнет величины, чтобы оплатить все КПК и прочее компьютерное оборудование вместе с лицензиями ? А если найдется одна официантка, которая часто ошибается, то либо направить ее на ускоренные курсы арифметики начальных классов, либо просто выгнать. При большой текучке одной дурой больше, одной меньше...
Достаточно много я считаю заведение может недополучить. Сами ошибки в калькуляции может и не играют особой роли, так как обсчитать можно как себе в пользу, так и нет. Но из-за затрат на расчеты уходит много времени и многие клиенты просто не дожидаясь официантки через минут 10 просто уходят, а если их обсчитывают не в их пользу может просто потом не приходят и не рекомендуют своим знакомым приходить, так как обслуживают долго. Предположительно думаю при затратах 1000 евро на кпк и комп, окупаемость где-то 2-3 месяца для небольшой кафешки с 15 столами.

>>А когда она одна на 15-20 столов и все от нее чего-то хотят одновременно, ошибиться по-моему не мудрено.

PD>Да что за проблема такая ? Ну записала она в свой блокнот "шницель 2, пиво 4, оливье 2". И что, теперь сложно подсчитать ? Не верю!!!

Считать приходится что-то типа (6.5 + (40% от 4.25) + 1.7) — 10% от полученной суммы. Попробуй посчитать в уме и засечь время сколько на это уйдет.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Не верю!!!
HL>Вы фамилию верно указали в профиле?

Я так полагал, что всем известно. что не я — автор этого изречения.

HL>Усложним задачу.
HL>За столом 4 гостя, каждый платит за себя.
HL>Заведение — загородный клуб. Столик стоит у реки, кухня метрах в двухстах.

И что ? Калькулятора не хватит, чтобы каждому посчитать его шницель и пиво ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>И что ? Калькулятора не хватит, чтобы каждому посчитать его шницель и пиво ?
Я Вас умоляю.

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

Во-вторых, пока он протопает 200 метров к кухне, а потом обратно, пройдет много времени. За это время уже что-то могут приготовить.

А ведь еще нужно узнать, когда забирать заказ. А стол не один...
Не, калькулятора не хватит.

Здравствуйте, DreamWeaver, Вы писали:

DW> На базар ходил, там обычно с калькуляторами все.

Естественно. Я же не предлагаю, чтобы они столбиком на бумаге складывали. И у официантки калькулятор должен быть.


PD>>И далее — ну пусть иногда и делают ошибку, но как часто, и стоит ли на это обращать внимание ? Сколько денег может недополучить заведение из-за этих ошибок, и когда эта сумма достигнет величины, чтобы оплатить все КПК и прочее компьютерное оборудование вместе с лицензиями ? А если найдется одна официантка, которая часто ошибается, то либо направить ее на ускоренные курсы арифметики начальных классов, либо просто выгнать. При большой текучке одной дурой больше, одной меньше...
DW> Достаточно много я считаю заведение может недополучить. Сами ошибки в калькуляции может и не играют особой роли, так как обсчитать можно как себе в пользу, так и нет. Но из-за затрат на расчеты уходит много времени и многие клиенты просто не дожидаясь официантки через минут 10 просто уходят, а если их обсчитывают не в их пользу может просто потом не приходят и не рекомендуют своим знакомым приходить, так как обслуживают долго.

Ох, что-то мне это весьма сомнительно. Я бы на месте владельца этого кафе сначала провел бы анализ. Его нетрудно сделать — просто нанять человека, который посидел бы в кафе пару дней и понаблюдал. Сколько вообще уходит не поевши ? Сколько в среднем времени ждут ? Почему ждут, может, потому, что шницель надо изжарить, и никакой КПК тут не поможет. Если уходят не поевши, можно к нему подойти и вежливо спросить — почему ? И т.д. Словом, разобраться, что именно имеет место. И только если выяснится, что bottleneck именно в том. что официант передает заказ на кухню слишком медленно, и ущерб от этого достаточно существенен, чтобы окупить покупку харда и софта — вот тогда и делать что-то. И не раньше!

>Предположительно думаю при затратах 1000 евро на кпк и комп, окупаемость где-то 2-3 месяца для небольшой кафешки с 15 столами.

Не годится тут "думаю". Тут точные цифры нужны и обоснование.

DW> Считать приходится что-то типа (6.5 + (40% от 4.25) + 1.7) — 10% от полученной суммы. Попробуй посчитать в уме и засечь время сколько на это уйдет.

Я где-то предлагал считать в уме ??? Берем калькулятор

4.25 * 40 /100
+6.5
+1.7
*0.9

Итого — 10-15 сек.

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>И что ? Калькулятора не хватит, чтобы каждому посчитать его шницель и пиво ?
HL>Я Вас умоляю.

Я вас таки тоже. Между прочим. еще лет 20 назад вполне счетами обходились.

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

HL>Во-вторых, пока он протопает 200 метров к кухне, а потом обратно, пройдет много времени. За это время уже что-то могут приготовить.

Ну-ну. 200 метров. У Вас часом не на стадионе кормежка происходит ?

HL>А ведь еще нужно узнать, когда забирать заказ. А стол не один...
HL>Не, калькулятора не хватит.

Я таки никак не могу понять, как это до сих пор весь ресторанный бизнес не лопнул из-за отсутствия этих средств.

Здравствуйте, DreamWeaver, Вы писали:

Где гарантия, что и с КПК ошибки делаться не будут ? Ткнет она в шницель вместо эскалопа и привет!
Что будем делать, если связь прервется ? Сервер упадет ? Будет она подходить к каждому клиенту и спрашивать, что он заказал ?
Кто всю эту прелесть обслуживать будет ? Сисадмина наймем ?

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Где гарантия, что и с КПК ошибки делаться не будут ? Ткнет она в шницель вместо эскалопа и привет!
Количество ошибок измениться не должно, к чему аргумент?

PD>Что будем делать, если связь прервется ? Сервер упадет ? Будет она подходить к каждому клиенту и спрашивать, что он заказал ?
А что ресторан сейчас делает, когда касса не работает? Я встречал ситуации когда тупо посылает клиентов. Лучше уж тупо подходить и спрашивать,
момент должен быть редкий.

PD>Кто всю эту прелесть обслуживать будет ? Сисадмина наймем ?
Тот кто установил систему тот пусть и поддерживает, это дешевле сисадмина.

Здравствуйте, Pavel Dvorkin, Вы писали:

PD>Ну-ну. 200 метров. У Вас часом не на стадионе кормежка происходит ?
Хм... я так понимаю, что Ваша позиция — если Вы чего-то не видели/не пробовали/не делали, значит этой штуки нет и быть не может. Так?

Я привожу пример вполне реального объекта.
Загородный клуб. Большая территория, по которой разбросаны группы столов. Около группы столов может быть что-то баро-подобное, но кухня в любом случае одна. Из-за рельефа местности, деревьев, там даже Wi-Fi не во всех точках работает, в качестве резервного канала используется GPRS-соединение.

PD>Я таки никак не могу понять, как это до сих пор весь ресторанный бизнес не лопнул из-за отсутствия этих средств.

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

Но утверждать, что средство автоматизации глупость, ненужная "фенечка"... зачем? Форматов заведений — множество. Посещаемость, площадь тоже варьируются. Кому-то достаточно бумажки, кто-то нуждается в КПК у официантов, а кто-то никогда в жизни не напечатает штрихкоды в меню, потому что его заведение стилизовано под рюшечки и цветочки.

К чему категоричность?

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, gandjustas, Вы писали:

G>>Что значит "постоянная" ? Она вероятнее всего будет происходить один раз при изменении меню (то есть оооочень редко).

Z>Откуда клиент узнает об изменении меню? Ему придется регулярно дергать сервер. А сам по себе такой http запрос/ответ немногим меньше
Z>запроса/ответа со списком блюд в меню. Тем более запрос списка блюд он привязан к логике и мы вполне можем ему лично задать нужное кеширование
Z>на любом участке.
Об изменении меню узнает официант и сможет синхронизировать данные на КПК. В принципе можно для верности раз в день синхронизировать.
Кстати если изменений не будет, то трафик будет минимальным.

Z>>>Я еще раз спрошу, выполнение каких требований обеспечивает (или облегчает) введение систему следующих механизмов: "локальная бд", "сервис синхронизации"?
G>>Уменьшение нагрузки на сеть\сервер
Z>как я показал уменьшение никакое, скорее увеличение, в твоем решении клиенты регулярно впустую опрашивают сервис обновления.
Официант за день больше тысячи запросов к меню делает, поэтому умеьшение будет значительное.

G>>Увеличение скорости работы интерфейса на КПК
Z>Ага, вместо того, чтобы взять из кеша мы сделаем запрос. Откуда ускорение?
Из какого кеша? Уверен что работа с SqlServer CE медленнее будет?

G>>Если постараться, то можно сделать прием заказов при отсуствии связи с сервером (но толку от такого мало)
Z>Вот... первый реальный плюс, но как ты сам заметил, толку от него действительно мало.
Да и два других плюса очень даже реальные. Сажающаяся батарея — очень плохо для КПК, если им надо пользоваться постоянно.

G>>А вообще не надо бояться локльных бд и синхронизации, это довольно простые в использовании вещи. Даже проще, чем делать cache-friendly веб-приложение.
Z>Приложение все равно писать придется, AJAX, SL или WPF, это уже не суть важно.
В случае кпк очень важно.

Z>А вот сопровождение одного сервера сильно отличается от сопровождение одного сервера и нескольких десятков рабочих мест.
Есть ClickOnce, для CF тоже что-то подобное можно в инете найти.

Здравствуйте, gandjustas, Вы писали:

Z>>Откуда клиент узнает об изменении меню? Ему придется регулярно дергать сервер. А сам по себе такой http запрос/ответ немногим меньше
Z>>запроса/ответа со списком блюд в меню. Тем более запрос списка блюд он привязан к логике и мы вполне можем ему лично задать нужное кеширование
Z>>на любом участке.
G>Об изменении меню узнает официант и сможет синхронизировать данные на КПК. В принципе можно для верности раз в день синхронизировать.
G>Кстати если изменений не будет, то трафик будет минимальным.

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

Z>>>>Я еще раз спрошу, выполнение каких требований обеспечивает (или облегчает) введение систему следующих механизмов: "локальная бд", "сервис синхронизации"?
G>>>Уменьшение нагрузки на сеть\сервер
Z>>как я показал уменьшение никакое, скорее увеличение, в твоем решении клиенты регулярно впустую опрашивают сервис обновления.
G>Официант за день больше тысячи запросов к меню делает, поэтому умеьшение будет значительное.

Ну и что мешает это меню просто держать в памяти? Батарея сядет от 10 кб данных?

G>>>Увеличение скорости работы интерфейса на КПК
Z>>Ага, вместо того, чтобы взять из кеша мы сделаем запрос. Откуда ускорение?
G>Из какого кеша? Уверен что работа с SqlServer CE медленнее будет?

Уверен, быстрее чем hash[key] еще ни один сервер не научился работать.

G>Да и два других плюса очень даже реальные. Сажающаяся батарея — очень плохо для КПК, если им надо пользоваться постоянно.

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

G>>>А вообще не надо бояться локльных бд и синхронизации, это довольно простые в использовании вещи. Даже проще, чем делать cache-friendly веб-приложение.
Z>>Приложение все равно писать придется, AJAX, SL или WPF, это уже не суть важно.
G>В случае кпк очень важно.

Не буду спорить, поинт в том, что все эти технологии не требуют EF и локальной СУБД. В крайнем случае сделаем пилотный интерфейс на каждой технологии и сравним. Я считаю, что выигрыш от использования WPF вместо SL минимален, но если он будет заметным — не вопрос. Только это все равно не оправдывает лишний стек технологий.

Z>>А вот сопровождение одного сервера сильно отличается от сопровождение одного сервера и нескольких десятков рабочих мест.
G>Есть ClickOnce, для CF тоже что-то подобное можно в инете найти.

Если выигрыш от WPF перевесит — можно и задуматься над этим, но только после того как этот выигрыш будет показан.

Здравствуйте, Ziaw, Вы писали:

Z>Я вроде показывал, что запрос на все строки меню будет отличаться от запроса на необходимость синхронизации на пару килобайт. Кладем этот запрос в
Z>кеш и получаем ту же производительность.
В какой кеш? HTTP-кешем в ajax приложении мы не управляем. Кеш в памяти для КПК — не самая лучшая идея, память у него ограничена.
Если кеш сохранять куда-то, то лучше сразу использовать SqlServer CE.


Z>>>>>Я еще раз спрошу, выполнение каких требований обеспечивает (или облегчает) введение систему следующих механизмов: "локальная бд", "сервис синхронизации"?
G>>>>Уменьшение нагрузки на сеть\сервер
Z>>>как я показал уменьшение никакое, скорее увеличение, в твоем решении клиенты регулярно впустую опрашивают сервис обновления.
G>>Официант за день больше тысячи запросов к меню делает, поэтому умеьшение будет значительное.

Z>Ну и что мешает это меню просто держать в памяти? Батарея сядет от 10 кб данных?
А синхронизировать как? Свой протокол для этого делать? И зачем держать в ОП, если можно на держать тоже самое на флешке?

G>>>>Увеличение скорости работы интерфейса на КПК
Z>>>Ага, вместо того, чтобы взять из кеша мы сделаем запрос. Откуда ускорение?
G>>Из какого кеша? Уверен что работа с SqlServer CE медленнее будет?
Z>Уверен, быстрее чем hash[key] еще ни один сервер не научился работать.
А тебе нужна такая запредельная скорость? SqlServerCE выдает тыщу записей в секунду на КПК (то что я видел). Этого вполне хватит.

G>>Да и два других плюса очень даже реальные. Сажающаяся батарея — очень плохо для КПК, если им надо пользоваться постоянно.
Z>Что конкретно ее садит сильнее чем запуск сиквел сервера на мизерной базе?
Постоянная передача по сети.

Здравствуйте, gandjustas, Вы писали:

G>Здравствуйте, Ziaw, Вы писали:

Z>>Я вроде показывал, что запрос на все строки меню будет отличаться от запроса на необходимость синхронизации на пару килобайт. Кладем этот запрос в
Z>>кеш и получаем ту же производительность.
G>В какой кеш? HTTP-кешем в ajax приложении мы не управляем.

Это еще почему? Курим протокол HTTP до просветления.

G> Кеш в памяти для КПК — не самая лучшая идея, память у него ограничена.
G>Если кеш сохранять куда-то, то лучше сразу использовать SqlServer CE.

Включаем голову и понимаем, что код сервера отожрет памяти на порядки больше, чем нам требуется на кеш.

Z>>Ну и что мешает это меню просто держать в памяти? Батарея сядет от 10 кб данных?
G>А синхронизировать как? Свой протокол для этого делать? И зачем держать в ОП, если можно на держать тоже самое на флешке?

Что держать на флешке? 10 килобайтный списко блюд в меню? Самому не смешно?

G>>>>>Увеличение скорости работы интерфейса на КПК
Z>>>>Ага, вместо того, чтобы взять из кеша мы сделаем запрос. Откуда ускорение?
G>>>Из какого кеша? Уверен что работа с SqlServer CE медленнее будет?
Z>>Уверен, быстрее чем hash[key] еще ни один сервер не научился работать.
G>А тебе нужна такая запредельная скорость? SqlServerCE выдает тыщу записей в секунду на КПК (то что я видел). Этого вполне хватит.

Капец кокой-то... Ты диалог выше сам прочитай, я уже не могу

G>>>Да и два других плюса очень даже реальные. Сажающаяся батарея — очень плохо для КПК, если им надо пользоваться постоянно.
Z>>Что конкретно ее садит сильнее чем запуск сиквел сервера на мизерной базе?
G>Постоянная передача по сети.

Постоянная передача чего? От постоянной передачи заказов ты никуда не денешся, а список блюд не требует постоянной передачи.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, gandjustas, Вы писали:

G>>Здравствуйте, Ziaw, Вы писали:

Z>>>Я вроде показывал, что запрос на все строки меню будет отличаться от запроса на необходимость синхронизации на пару килобайт. Кладем этот запрос в
Z>>>кеш и получаем ту же производительность.
G>>В какой кеш? HTTP-кешем в ajax приложении мы не управляем.

Z>Это еще почему? Курим протокол HTTP до просветления.

Кто сказал что браузер на КПК бкдет держать кеш столько сколько нужно?

G>> Кеш в памяти для КПК — не самая лучшая идея, память у него ограничена.
G>>Если кеш сохранять куда-то, то лучше сразу использовать SqlServer CE.

Z>Включаем голову и понимаем, что код сервера отожрет памяти на порядки больше, чем нам требуется на кеш.
С чего бы? Нам не нужно его постоянно в памяти держать.

Z>>>Ну и что мешает это меню просто держать в памяти? Батарея сядет от 10 кб данных?
G>>А синхронизировать как? Свой протокол для этого делать? И зачем держать в ОП, если можно на держать тоже самое на флешке?
Z>Что держать на флешке? 10 килобайтный списко блюд в меню? Самому не смешно?
Нет.

А ты много для КПК писал?

Здравствуйте, HowardLovekraft, Вы писали:

HL>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Ну-ну. 200 метров. У Вас часом не на стадионе кормежка происходит ?
HL>Хм... я так понимаю, что Ваша позиция — если Вы чего-то не видели/не пробовали/не делали, значит этой штуки нет и быть не может. Так?

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

HL>Я привожу пример вполне реального объекта.
HL>Загородный клуб. Большая территория, по которой разбросаны группы столов. Около группы столов может быть что-то баро-подобное, но кухня в любом случае одна. Из-за рельефа местности, деревьев, там даже Wi-Fi не во всех точках работает, в качестве резервного канала используется GPRS-соединение.

Да, очень типичная ситуация.

PD>>Я таки никак не могу понять, как это до сих пор весь ресторанный бизнес не лопнул из-за отсутствия этих средств.

HL>Павел, Вы утрируете. Никто не говорит, что весь ресторанный бизнес должен лопнуть из-за отсутствия у официанта КПК. Перемещаться в пространстве тоже вполне можно и на лошади.

Можно. Если это загородный клуб, который Вы описали, то не исключено, что это будет самым радикальным ускорением. Wi-Fi — бог его знает, а вот блюдо привезут быстрее. Принял официант заказ, пришпорил лошадь, поскакал в кухню, прискакал с шницелем. Да и посмотреть приятно


HL>Но утверждать, что средство автоматизации глупость

Гм. Я такое говорил ? Ссылку, пожалуйста.

>, ненужная "фенечка"... зачем? Форматов заведений — множество. Посещаемость, площадь тоже варьируются. Кому-то достаточно бумажки, кто-то нуждается в КПК у официантов, а кто-то никогда в жизни не напечатает штрихкоды в меню, потому что его заведение стилизовано под рюшечки и цветочки.

А вот с этим согласен

HL>К чему категоричность?

А нет ее. Я же ясно где-то тут писал — сначала оцените кк следует ситуацию, какие расходы, какие возможные доходы, а потом и принимайте решение.

Здравствуйте, Ziaw, Вы писали:

Z>Здравствуйте, Pavel Dvorkin, Вы писали:

PD>>Где гарантия, что и с КПК ошибки делаться не будут ? Ткнет она в шницель вместо эскалопа и привет!
Z>Количество ошибок измениться не должно, к чему аргумент?

К тому, что если оно не изменится, то и дохода никакого не будет. А аргументировали необходимость всей этой автоматизации именно возможным доходом от уменьшения числа ошибок.

PD>>Что будем делать, если связь прервется ? Сервер упадет ? Будет она подходить к каждому клиенту и спрашивать, что он заказал ?
Z>А что ресторан сейчас делает, когда касса не работает? Я встречал ситуации когда тупо посылает клиентов. Лучше уж тупо подходить и спрашивать,

Когда касса не работает, можно новых клиентов не принимать. Это понятно, они уйдут. Со старыми что будем делать ? Я уже суп съел и шницель жду, а мне говорят — извините, мы тут не помним, что Вы заказали...

Z>момент должен быть редкий.

Если мне таким образом шницель не подадут, этот момент в данном кафе больше никогда не повторится. Со мной

Z>Тот кто установил систему тот пусть и поддерживает, это дешевле сисадмина.

А кто установил ? За установку и поддержку платить ему надо ? Сколько ? Из каких средств ?

Здравствуйте, DreamWeaver, Вы писали:

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

Во-первых, с этого и надо было начинать, а во-вторых, у вас взаимоисключающие требования.
А главное, всё что вам это принесёт — ещё одна "пшик"-строчка к резюме. А смысл тратить время?...