Выбор ERP

[fed]

Цитата:

Сообщение от ds1678

А клиент в состоянии взвесить все реальные "за" и "против"? Его неосведомленность в нюансах, которые вспоследствии могут оказаться критическими, не смущает ни вас, ни клиента?

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



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

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

[Vadik]

Цитата:

Сообщение от fed

Просто есть категория клиентов, которые могут учиться только на собственных ошибках. И проще для них запрограммировать как они хотят

Ага. И при наличии n-цати ведущихся проектов имеем n-цать версий одного и того же "решения", так как m-цать консультантов нагибают хотелками "от Петровича" X программистов, которых хаотично перебрасывают длинными и короткими рокировками между Y проектами. Консультантам (молодым и горячим) об архитектуре решения думать некогда (не царское это дело, да и умение думать на уровне тиражируемого решения как скилл часто востребовано меньше чем например энергичность), 30-50% рабочего времени программистов занято починкой разваливающегося решения после импорта очередной "фичи" с очередного проекта для очередной предпродажной демонстрации (крайне желательно наличие выделенных под эти задачи гуру). Ресурсов на приведение рефакторинга всего этого зоопарка нет.. Ничего не напоминает ?
При всем этом прошу отметить что новый клиент получает "решение" в добровольно-принудительном порядке (в виде более-менее работоспособной версии приложения с другого проекта) еще на развертывании и шансов "спрыгнуть" у него если честно никаких. "Поумнеть" он конечно может, но отказ от "решения" в пользу стандартного функционала будет равносилен новому внедрению.
Так что не стоит наверное излишне демонизировать клиента, у нас (внедренцев) тоже своих скелетов в шкафу хватает
P.S.

Цитата:

Когда эти клиенты будут переходить на новую версию (или новую систему), есть шансы что они местами поумнеют (на почве смены власти в части подразделений) и некоторые свои старые хотелки дезавуируют.

Вот-вот. Только это будет не "поумнение", а "да @@ @@@@ @@@@!!!" со стороны клиента, сопровождающееся переходом на другую (какую угодно, как правило - более дорогую, в надежде что хоть там этого бардака не будет - какая наивность) систему. А других (более дорогих) - сами знаете, раз-два и обчелся. Вот только с них "спрыгивать" уже некуда

[fed]

Цитата:

Сообщение от Vadik

Ага. И при наличии n-цати ведущихся проектов имеем n-цать версий одного и того же "решения", так как m-цать консультантов нагибают хотелками "от Петровича" X программистов, которых хаотично перебрасывают длинными и короткими рокировками между Y проектами. Консультантам (молодым и горячим) об архитектуре решения думать некогда (не царское это дело, да и умение думать на уровне тиражируемого решения как скилл часто востребовано меньше чем например энергичность), 30-50% рабочего времени программистов занято починкой разваливающегося решения после импорта очередной "фичи" с очередного проекта для очередной предпродажной демонстрации (крайне желательно наличие выделенных под эти задачи гуру). Ресурсов на приведение рефакторинга всего этого зоопарка нет.. Ничего не напоминает ?
При всем этом прошу отметить что новый клиент получает "решение" в добровольно-принудительном порядке (в виде более-менее работоспособной версии приложения с другого проекта) еще на развертывании и шансов "спрыгнуть" у него если честно никаких. "Поумнеть" он конечно может, но отказ от "решения" в пользу стандартного функционала будет равносилен новому внедрению.
Так что не стоит наверное излишне демонизировать клиента, у нас (внедренцев) тоже своих скелетов в шкафу хватает
P.S.
Вот-вот. Только это будет не "поумнение", а "да @@ @@@@ @@@@!!!" со стороны клиента, сопровождающееся переходом на другую (какую угодно, как правило - более дорогую, в надежде что хоть там этого бардака не будет - какая наивность) систему. А других (более дорогих) - сами знаете, раз-два и обчелся. Вот только с них "спрыгивать" уже некуда

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

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

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

Но в реальности мало кто из партнеров так делает, ибо:
1. Вертикальное решение - хороший способ маркетинговой отстройки от конкурентов (особено при дележке лидов в MS)
2. Стандартную функциональность консультанты обычно довольно плохо знают и понимают.
3. Собственные ошибки сотрудники (и со стороны клиента и со стороны партнера) принимают за источники конкурентного преимущества (так называемый синдром родителей Дауна, про который я когда-то писал).
4. За доработки можно срубить бабла