31.12.2009, 21:51 | #11 |
Moderator
|
Цитата:
Сообщение от Vadik
Ага. И при наличии n-цати ведущихся проектов имеем n-цать версий одного и того же "решения", так как m-цать консультантов нагибают хотелками "от Петровича" X программистов, которых хаотично перебрасывают длинными и короткими рокировками между Y проектами. Консультантам (молодым и горячим) об архитектуре решения думать некогда (не царское это дело, да и умение думать на уровне тиражируемого решения как скилл часто востребовано меньше чем например энергичность), 30-50% рабочего времени программистов занято починкой разваливающегося решения после импорта очередной "фичи" с очередного проекта для очередной предпродажной демонстрации (крайне желательно наличие выделенных под эти задачи гуру). Ресурсов на приведение рефакторинга всего этого зоопарка нет.. Ничего не напоминает ?
При всем этом прошу отметить что новый клиент получает "решение" в добровольно-принудительном порядке (в виде более-менее работоспособной версии приложения с другого проекта) еще на развертывании и шансов "спрыгнуть" у него если честно никаких. "Поумнеть" он конечно может, но отказ от "решения" в пользу стандартного функционала будет равносилен новому внедрению. Так что не стоит наверное излишне демонизировать клиента, у нас (внедренцев) тоже своих скелетов в шкафу хватает P.S. Вот-вот. Только это будет не "поумнение", а "да @@ @@@@ @@@@!!!" со стороны клиента, сопровождающееся переходом на другую (какую угодно, как правило - более дорогую, в надежде что хоть там этого бардака не будет - какая наивность) систему. А других (более дорогих) - сами знаете, раз-два и обчелся. Вот только с них "спрыгивать" уже некуда Просто даже при самых лучших навереньях внедренца, который честно пытается внедрить стандартную систему с минимумом доработок (а не бредит по поводу разработки "верти кального" решения, как их один мой знакомый называет), далеко не всегда удается убедить клиента использовать стандартную (ну или умеренно модифицированную) функциональность. Причем зачастую, это связано не с врожденной придурковатостью клиента, а с тем что риск одномоментного перехода, ну допустим, к новой схеме расчета себестоимости и прибыли (и соответственно - бонусов), слишком велик и клиент предпочитает платить за доработку, а не рисковать остановкой бизнеса. В идеале - в такой ситуации хорошо бы как-то донести до клиента что: а) лучше бы так не делать, поскольку много дополнительных затрат, и часть выигрыша от внедрения системы теряется. б) Хорошо бы в будущем, после первичного запуска системы, все-таки распрямить сомнительный бизнес-процесс и отказаться от кривой функциональности. При разумном подходе, доработка функциональности может использоваться для того чтобы заменить революцию на предприятии в эволюцию. И в этом сила тех решений, которые идут от кастомизаций, а не от конфигурирования стандарта с раз и навсегда предопределенными бизнес-процессами. Но в реальности мало кто из партнеров так делает, ибо: 1. Вертикальное решение - хороший способ маркетинговой отстройки от конкурентов (особено при дележке лидов в MS) 2. Стандартную функциональность консультанты обычно довольно плохо знают и понимают. 3. Собственные ошибки сотрудники (и со стороны клиента и со стороны партнера) принимают за источники конкурентного преимущества (так называемый синдром родителей Дауна, про который я когда-то писал). 4. За доработки можно срубить бабла |
|
|
За это сообщение автора поблагодарили: Lemming (5), Theodoro (1). |
Теги |
axapta, axapta retail, sap, выбор, сравнение, холивар, dynamics |
|
|