|
28.12.2009, 16:42 | #1 |
Участник
|
Цитата:
Сообщение от lagr221374
Где вы меня в гугл отсылали? Ну даже не в этом суть. По конкретным формулировкам Zabr-а вы не нашли по большей части такой функциональности в SAP. И к чему это приведет? К тому что возникнет необходимость создавать все это ручками. А это в SAP делается тяжело и трудоемко в сравнении с Ax.
1. В AX невозможно сделать каждый магазин складом и дать права на приемку товара пользователю из магазина? Надо писать? Мне казалось это организационный момент для любой системы, где можно делать несколько складов. 2. Надо писать такой функционал в DAX? imho придется, в SAP предусмотрен такой вариант с различными условиями для различных магазинов /сегментов закупок. 3. С юридической точки зрения спорно, но в случае необходимости в чем проблема поменять условия оплаты по действующим договорам? 4. Если Вам так сильно надо, могу уточнить, сходу ответа не знаю. Прикинете трудоемкость разработки решения для DAX? 5. Специально спросил про механизмы управления ценами/скидками для ритейла - получил лекцию на 20 минут про возможности SAP Price Optimization, SAP Markdown Optimization, SAP Promotion Managent. Пересказывать не возьмусь, но с заинтересованными в решении задачи лицами можно пообщаться. Расскажете со свой стороны про AX? =) Цитата:
Опыт c DAX только добавил понимания, что четкость формулировок помогает в общении с заказчиком. Но мы живем в свободной стране и если кто-то считает что работа консультанта это просто передать нечетко и непонятно сформулированную задачу в разработку, то видимо и такому мнению место есть. Цитата:
Сообщение от lagr221374
Ну во первых
Во вторых, как ни странно, но бизнес зависит от используемой ERP: часто автоматизация пронизывает все процессы предприятия и их изменение должно находить отражение в информационной системе предприятия. Если это по каким-то причинам такое отражение невозможно, то контроль над измененным процессом теряется и ставит под вопрос ценность самого изменения. Цитата:
Сообщение от lagr221374
SAP как отписал ранее менее гибок к "резким" изменениям: это логично так как он более проработан и это само по себе наверное хорошо для компаний с устоявшимися и незыблемыми процессами, но при "резком" изменении вызывает большее количество изменений (в силу проработанности деталей много и они должны быть все учтены), что в итоге приводит к повышенной трудоемкости подобного (и как понимаю идет в разрез с тезисом что все в идеале решается настройками) + на это накладывается сложность изменений, обусловленная достаточно хреновой системой разработки (ессно в сравнении с X++).
У Вас есть опыт разработки и DAX и в SAP? Вы писали ЧТЗ для DAX и SAP на примерно одинаковые модификации и можете оценить трудоемкость? Я вот от квалифицированных разработчиков не слышал жалоб на сложность/неудобство SAP как среды разработки, очень даже наоборот. Цитата:
Цитата:
Сообщение от lagr221374
Вот видите.
Типичное решение для SAP: для соединения кассы и SAP купить модуль SAP POS Data Management с кучей не пока нужных функций. Типичное решение для Ax: дать задание программисту и консультанту и получить желаемое за день - за два (это я грубо в реалии судя по приведенному в соответствующем разделе джобу пара часов). Вот потому и идет речь о большей гибкости Ax, что в конкретной ситуации для нее является +. Понятно что и трудоемкость не сравнимая. А место или нет кассы в интеграции с Ax вопрос спорный (почему нет, для каких то шаманств) и наверное по описанию темы был отдан на откуп заказчику - в него и тапки. Странно Вы читаете. Я Вам написал что можно и напрямую если сильно хочется. Только вот для кого это нужно? Для SAP есть выбор - купить узкоспециализированный функционал или писать, еще раз повторюсь для танкистов, кардинальной разницы в трудоемкости разработки нет. По многим задачам есть и решения партнеров, как и для DAX, где инвестиции в разработку уже сделаны. Только в силу традиции не спешить менять стандарт обычно их гораздо легче собрать между собой. Для DAX же решений от вендора ОЧЕНЬ мало. Вы сделаете интеграцию DAX с любой кассой за 2 часа? включая тестирование и отражение реализации в проектной документации? У вам МЕГА производительность труда. P.S. SAP POS DM стоит смешных денег, гораздо дешевле обойдется чем доп. лицензия для магазина на DAX, не говоря уже о полных размерах ущерба проектного решения "дотянуть ERP до магазина" для бизнеса. Последний раз редактировалось Aleck; 28.12.2009 в 16:58. |
|
28.12.2009, 17:15 | #2 |
Гость
|
Цитата:
Сообщение от Aleck
А Вы найдите по формулировкам Zabrа функционал в AX, хотя бы по п. 2
1. В AX невозможно сделать каждый магазин складом и дать права на приемку товара пользователю из магазина? Надо писать? Мне казалось это организационный момент для любой системы, где можно делать несколько складов. 2. Надо писать такой функционал в DAX? imho придется, в SAP предусмотрен такой вариант с различными условиями для различных магазинов /сегментов закупок. 3. С юридической точки зрения спорно, но в случае необходимости в чем проблема поменять условия оплаты по действующим договорам? 4. Если Вам так сильно надо, могу уточнить, сходу ответа не знаю. Прикинете трудоемкость разработки решения для DAX? 5. Специально спросил про механизмы управления ценами/скидками для ритейла - получил лекцию на 20 минут про возможности SAP Price Optimization, SAP Markdown Optimization, SAP Promotion Managent. Пересказывать не возьмусь, но с заинтересованными в решении задачи лицами можно пообщаться. Расскажете со свой стороны про AX? =) ... Цитата:
Сообщение от Aleck
..
Это меня еще со школы так развратили - четко и понятно мысли формулировать Опыт c DAX только добавил понимания, что четкость формулировок помогает в общении с заказчиком. Но мы живем в свободной стране и если кто-то считает что работа консультанта это просто передать нечетко и непонятно сформулированную задачу в разработку, то видимо и такому мнению место есть. ... Цитата:
Цитата:
Вы предложили купить модуль. Т.е. взаимодействие с кассой по ТЗ эквивалентно в SAP разработке модуля. Это порядка месяца работы. Это в разы больше оценки трудоемкости в Ax (оценю модифу в 2-4 часа - так как чай надо иногда пить ) Имеем 168 часов против 4. That's all. Цитата:
Я регулярно слышу иное от бывших разработчиков Ax и это правда. Сложно сравнивать систему 70-х и X++. Такое вот дело. Хм. в чем такая принципиальное разница между системами на поиск и уборку багов? Цитата:
Цитата:
Цитата:
Не болейте. |
|
28.12.2009, 17:42 | #3 |
Участник
|
Цитата:
Цитата:
Т.е. у Вас сведений нет? Как Вы там говорили? Слив засчитан? Цитата:
Сообщение от lagr221374
Я вам дал пример ТЗ про чеки.
Вы предложили купить модуль. Т.е. взаимодействие с кассой по ТЗ эквивалентно в SAP разработке модуля. Это порядка месяца работы. Это в разы больше оценки трудоемкости в Ax (оценю модифу в 2-4 часа - так как чай надо иногда пить ) Имеем 168 часов против 4. That's all. Для grocery тоже предложите интеграцию AX с кассой напрямую? =) В каком магазине можно это посмотреть как покупателю? Оценить скорость обслуживания на кассе)) Заодно и посчитать стоимость решения. Помнится на одном проекте подольше чем 4 часа интеграцию DAX c кассами делали, но так уж и быть спишем на неопытность. Чем торгуют? Какое к-во магазинов/касс? Повторить еще раз, что можно напрямую? С третьего раза дойдет или придется еще несколько раз повторить? ))) Опишете технологию интеграции (com?) в конкретном случае про 4 часа - спрошу у девелоперов оценку трудоемкости. Ждем-с. И Вы не хворайте. Последний раз редактировалось Aleck; 28.12.2009 в 18:36. |
|
28.12.2009, 23:18 | #4 |
Гость
|
Уфф вам Aleck повезло. Раскрытие тайн мира Ax произойдет раньше, чем завтра (благодарите провайдера и звезды)
Ладно будем считать уговорили (даже пиво с вас не возьму, а надо бы Ну если вы так хотите то имхо мое мнение (но кратко не растекаясь по древу): 1) Слишком дорого стала обходиться собственная логистика -> переход от распределения с собственного РЦ на самостоятельный развоз товара по магазинам поставщиками. - хз. Так как собственная логистика включает в себя не только склады, но открою вам тайну и собственно доставку и не совсем понятно будут ли учитываться данные расходы, будут ли введены понятия маршрутов, транспортных средств, регионов или зон доставки (которые могут не совпасть с региональными) и тому подобная хрень + куча отчетности. В общем логистика она большая. (2) Снижение покупательной активности населения и как следствие прогноз увеличения срока окупаемости новых магазинов -> разные условия отсрочки платежей поставщикам при поставках в новые и в старые магазины - хз так как понятие "разные условия отсрочки" может включать все что угодно. А все что угодно настройками решается только по вашим словам и только в SAPе. (3) проблемы с оборотными средствами у поставщиков и прогноз невозврата долгов за товар -> многие поставщики потребовали значительного сокращения отсрочки оплаты, в т.ч. задним числом (вследствие этого часть накладных оказалась "просрочена", хотя по старым условиям срок оплаты еще был далеко) - имхо мое мнение не так серъезно, но возможно это я по неведенью. (4) проблемы с оборотными средствами в ритейле -> специальный алгоритм распределения выделенной на оплату суммы между поставщиками по разным хитрым критериям (это в случае, когда можем заплатить меньше, чем фактически должны). - хз если какой то был уже, в случае Axapta не серъезно так как разработчики у нас все же люди в массе не глупые и на такой ход событий расчитывают. Если не было: ХЗ. (5) стало нужно быстро избавляться от больших остатков плохо продающихся товаров, чтобы освободить складские площади и быстро получить хоть что-то за эту фигню -> специальные алгоритмы распродажи (подробнее - коммерческая тайна). - хз. сильно зависит от обстоятельств и реализации. Разработчику иногда и так не формулируют. Не хрен баловать. Цитата:
Цитата:
Цитата:
Гы гы. Вот как заговорили. Вам может еще протокол описать? Не увиливайте и не отмазывайтесь теперь от своего ответа. Вопрос был прежде всего на идеологию: вам первое что пришло в голову - заказать модуль. Консультанту от Ax дать задание разработчику. Что и требовалось доказать. Гибкость и скорость на стороне Ax. Последний раз редактировалось lagr221374; 28.12.2009 в 23:21. |
|
|
За это сообщение автора поблагодарили: EVGL (-1). |
29.12.2009, 12:38 | #5 |
Участник
|
Цитата:
Сообщение от lagr221374
1) Слишком дорого стала обходиться собственная логистика -> переход от распределения с собственного РЦ на самостоятельный развоз товара по магазинам поставщиками.
- хз. Так как собственная логистика включает в себя не только склады, но открою вам тайну и собственно доставку и не совсем понятно будут ли учитываться данные расходы, будут ли введены понятия маршрутов, транспортных средств, регионов или зон доставки (которые могут не совпасть с региональными) и тому подобная хрень + куча отчетности. В общем логистика она большая. Я интерпретировал задачу так, я сильно ошибся? Zabr Вы что-то иное имели ввиду? Как то у меня "собственно доставку и не совсем понятно будут ли учитываться данные расходы, будут ли введены понятия маршрутов, транспортных средств, регионов или зон доставки (которые могут не совпасть с региональными) и тому подобная хрень + куча отчетности" с самостоятельной доcтавкой товара по магазинам поставщиками ну разве что freight costs отразить по поставке, если они будут выделены поставщиком, но это вроде как не проблема уже даже для AX с версии 4.0... Помню что в 3.0 косвенные дорабатывать приходилось... А этот поток сознания, что Вы выдали, мне кажется относится к старой схеме, от которой предполагается отказаться. Бизнес целесообразность, конечно, под вопросом, но такие условия задачи. Цитата:
Сообщение от lagr221374
(2) Снижение покупательной активности населения и как следствие прогноз увеличения срока окупаемости новых магазинов -> разные условия отсрочки платежей поставщикам при поставках в новые и в старые магазины
- хз так как понятие "разные условия отсрочки" может включать все что угодно. А все что угодно настройками решается только по вашим словам и только в SAPе. Что-то мне кажется, что и 10 не наскребете. Цитата:
Сообщение от lagr221374
(4) проблемы с оборотными средствами в ритейле -> специальный алгоритм распределения выделенной на оплату суммы между поставщиками по разным хитрым критериям (это в случае, когда можем заплатить меньше, чем фактически должны).
- хз если какой то был уже, в случае Axapta не серъезно так как разработчики у нас все же люди в массе не глупые и на такой ход событий расчитывают. Если не было: ХЗ. А как-то странно не знать относительно скромного функционала Аксапты в этой части, хотя бы в общих чертах, а сразу же бросаться разрабатывать. Цитата:
Сообщение от lagr221374
Разработчику иногда и так не формулируют. Не хрен баловать.
Из вариантов вами предложенных я заметил один: купи модуль, а там как фишка ляжет (помнитцо в Бананамама последнее что мелькало на форуме они к кассам хотели модуль купить...а через пару тройку лет ) Скорость оцениваю, как высокую так, как кассиру не надо по клавишам стучать - касса сама ему чек дает . Все остальное тайна есть - ответ был на форуме всех ноу-хау не расскрывает. Прэлестно! Правильно я понимаю, что сценарий работы такой = проводим сканером по бирке, автоматически формируется и разносится заказ в AX и печатается чек? Внимание вопрос (в третий раз): какой смысл в ERP вместо POS решения? Какие выгоды от такого проектного решения получает бизнес? Какова цена (лицензии, поддержка) такого решения? Это точно требование заказчика, или DAX вместо POS системы это Ваше проектное решения? Цитата:
Сообщение от lagr221374
Вам может еще протокол описать? Не увиливайте и не отмазывайтесь теперь от своего ответа. Вопрос был прежде всего на идеологию: вам первое что пришло в голову - заказать модуль. Консультанту от Ax дать задание разработчику. Что и требовалось доказать. Гибкость и скорость на стороне Ax.
Протоколов не надо, достаточно в общих чертах описать предполагаемый сценарий использования + в общих чертах подход к интеграции. Я правильно Вас понимаю, что Вы считаете, что для консультанта правильный подход это не разобраться в вопросе и в первую очередь предложить стандартное решение, а не думая и не разбираясь (как Вы явно проиллюстрировали в этом примере и в ответах на вопросы от Zabr) сразу бросать нечетко сформулированные задания разработчикам и городить свой новый функционал? Это Вы имели ввиду под профессионализмом консультанта? Незнание стандартного функционала, неумение вытащить у клиента детали по процессам и требованиям и неумение корректно сформулировать задание для разработчика? Последний раз редактировалось Aleck; 29.12.2009 в 13:00. Причина: typo |
|
|
За это сообщение автора поблагодарили: Vadik (1), ds1678 (1). |
29.12.2009, 12:53 | #6 |
Гость
|
- Да действительно неверно прочитал:
"на самостоятельный развоз товара по магазинам поставщиками" как "на самостоятельный развоз товара по магазинам" (так как это более сложная в моем понимании задача). + Ну вечер был . - все что угодно - это все что угодно. - вообще то я разработчик. Нигде не признавался в другом и в профиле написал для внимательных - про чек. Код приведите как напрямую. И оценку по времени. Тогда поговорим, а пока единственное ваше решение - купите модуль. Последний раз редактировалось lagr221374; 29.12.2009 в 13:16. |
|
|
За это сообщение автора поблагодарили: ds1678 (-1). |
29.12.2009, 14:09 | #7 |
Участник
|
Цитата:
Кто ходит в гости по утрам, тот поступает мудро (с) Медвед Сорри, Вы в теме писали, что внедренец, поэтому и подумал что консультант. Последний раз редактировалось Aleck; 29.12.2009 в 14:13. |
|
29.12.2009, 13:01 | #8 |
Гость
|
Цитата:
Цитата:
Цитата:
Разноситься заказ --> печатается чек. Все остальное ваши фантазии. Цитата:
Цитата:
И у вас нет на это ответа. А по наводящим вопросам: вы в реальности хоть раз интегрировались с ККМ? Тогда к чему глупые вопросы про com-порты? Цитата:
Сообщение от Aleck
...
Я Вам задаю уточняющие вопросы, чтобы ответить правильно на Ваш, а вот Вы увиливаете. Протоколов не надо, достаточно в общих чертах описать предполагаемый сценарий использования + в общих чертах подход к интеграции. Я правильно Вас понимаю, что Вы считаете, что для консультанта правильный подход это не разобраться в вопросе и в первую очередь предложить стандартное решение, а не думая и не разбираясь (как Вы явно проиллюстрировали в этом примере и в ответах на вопросы от Zabr) сразу бросать нечетко сформулированные задания разработчикам и городить свой новый функционал? Это Вы имели ввиду под профессионализмом консультанта? Незнание стандартного функционала, неумение вытащить у клиенте детали по процессам и требованиям и неумение корректно сформулировать задание для разработчика? Нужно просто дать оценку. Вы начинаете лезть в дебри философии: а надо ли? а можно? а если клиенту сплясать?. Надо. Нельзя. Плясали. Вопрос не в консультантах а в возможностях системы. SAP не может реализовать данное действо быстро и вы это убедительно доказали: купите новый модуль - Если еще вспомнить прошлое... То в Банане - маме на кассах после внедрения SAP отсутствовала большая часть товара бывшего в магазине. А они внедряли SAP. И наверное с модулем вами указанном. И это считалось удачным внедрением. Что же говорить о неуспешных? Т.е. есть высокая вероятность что модуль то уазанный вами еще пилить и пилить придется ЗЫ: потому разность в трудоемкости увеличу до 50 раз ) Последний раз редактировалось lagr221374; 29.12.2009 в 13:31. |
|
29.12.2009, 13:46 | #9 |
Участник
|
Aleck, ты стал заниматься втюхингом SAPa ?
__________________
|
|
29.12.2009, 13:58 | #10 |
Участник
|
Цитата:
Цитата:
Скомуниздили лицензию? =)) Цитата:
Поэтому и спрашиваю про подход к интеграции в общих чертах. Лично я не разработчик и с ККМ не интегрировался =) мне незачем чеки печатать) Проект один с интеграцией c ККМ был давно, я в детали интеграции не влезал, вопрос был копеечный. Цитата:
Цитата:
Может есть более дешевое решения с точки зрения TCO... Цитата:
Сообщение от lagr221374
Вопрос не в консультантах а в возможностях системы. SAP не может реализовать данное действо быстро и вы это убедительно доказали: купите новый модуль -
Сценарий использования как по ссылке описано (ТД Тракт)? http://www.retailer.ru/print/id/1555/ Если Вам так сильно болит могу узнать после праздников сколько потратили на разработку интеграции с ККМ в проекте по ссылке, мгновенного ответа правда не обещаю. Но полагаю, что вряд ли месяц, как Вы резво оценили доработочку в незнакомой Вам системе =) А по ссылочке статью прочтите, там как раз есть пару абзацев про Ваши иллюзии. |
|
29.12.2009, 14:07 | #11 |
Участник
|
Цитата:
Сообщение от lagr221374
Выгоды есть. Рассказ о них - тайна. Линцензии в отличие от SAP не требуется Выгода в 42 раза по трудоемкости минимум в сравнении с SAP. По деньгам вообще промолчу : десятки тысяч евро в сравнении с вашим решением сохраняются в кармане клиента. Это конечно для SAP-овца тяжело пережить, но в Ax вполне нормальное явление.
... Вопрос не в консультантах а в возможностях системы. SAP не может реализовать данное действо быстро и вы это убедительно доказали: купите новый модуль -
__________________
Денис Салтыков |
|
|
За это сообщение автора поблагодарили: Aleck (1), (-1). |
Теги |
axapta, axapta retail, sap, выбор, сравнение, холивар, dynamics |
|
|