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

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

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

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

iscrafm,

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

Сисой,

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

iscrafmДядя Будда
Не возникает сомнений, что необходимо иметь приоритет в развитии системы: либо оперативно удовлетворять все желания клиента и при этом со временем все чаще натыкаться на различные "подводные камни"

это уже следствие архитектуры системы. Ни на что не натыкаются. Если конечно речь не идет о спагетти.
Я не оспариваю тот факт, что это следствие архитектуры, я как раз и выражаю свое мнение в пользу такой архитектуры. На мой взгляд, при большом количестве клиентов и, соответственно, большом количестве надстроек вероятность несогласованности этих надстроек с плановыми изменениями в ядре растет пропорционально количеству дописок. И в перспективе приводит к тому, что клиенту проще оставить все как есть, чем поставить официальные обновления.
iscrafmДядя Будда
договариваться с клиентом, что данный функционал будет реализован в такие-то сроки (а при удовлетворенности клиента продуктом, обычно не возникает проблем с такими договоренностями). Клиент с одной стороны "дисциплинируется" и более тщательно и заранее продумывает свою маркетинговую политику, с другой стороны он получает грамотно реализованный функционал, в котором есть уверенность, что он будет работоспобен, когда понадобится.
я о том и говорю, что система не развивается с бизнесом, а сама по себе.
Скорее, система развивается со своими клиентами (вместе со всеми, с их "бизнесами"). Развитие системы самой по себе никому не нужно: ни клиентам, ни, тем более, разработчикам.

Сисой
Такая система обречена на автоматизацию ларьков. Кому нужна малоизвестная ИС с ограниченным функционалом, если тот же самый функционал есть у конкурентов плюс еще тьма всякой всячины?
По-моему, в обзоре, который породил эту ветку как раз "красной нитью" проходит мысль, что ситуация на рынке ERP в данный момент такова, что представители ERP-систем зачастую не могут провести клиенту полноценную демонстрацию того функционала, который необходим клиенту, даже если этот функционал и реализован в системе. Где же тогда гарантия, что если продавцы не могут провести достойную презентацию, то внедренцы потом смогут грамотно выполнить свою работу. Клиенту ведь мало знать, что то-то и то-то можно делать в рамках системы, он хочет этим пользоваться. Если же "малоизвестная ИС с ограниченным функционалом" может удовлетворить потребности клиента, то почему бы не выбрать ее. Вопрос возникает о надежности разработчиков. Шансы у малоизвестной компании исчезнуть с рынка выше, чем у популярных. И такая ситуация естественна для любой сферы бизнеса - это факт, с которым можно только смириться.
Сисой Т.е. крупные игроки такую ИС никогда не купят, а мелкие бизнесы до крупных могут и не вырасти. В нынешней экономической ситуации расти сложно, скупят в момент.
Подобный подход реализуем только в относительно свободной нише, где нет конкурентов. Или, как в 90-е, нет вообще ничего. Когда же рынок захвачен и поделен, заинтересовывать клиента сложнее.
Если опасаться конкурентной борьбы с более могущественными (как минимум, в плане известности брэнда) представителями рынка, то тогда теряется смысл вообще выходить на рынок. На каждом этапе развития у любой компании, будь то разработчик ПО или ларек на автобусной остановке, есть свой круг потенциальных покупателей и со временем при правильном планировании бизнеса этот круг расширяется.
Что касается перекупки продукта более именитым конкурентом, это говорит о том, что продукт в состоянии соревноваться с ним и "уводит" потенциальных клиентов, следовательно, продукт развивается в правильном направлении. Ну а будет он перекуплен или нет - это вопрос скорее философский для этой ветки форума.

LSVТоже ипотечник1. Так все-таки настройка всех возможностей , или программирование в SQL ?
2. Если именно настройка (без программирования), то приведите пример такой системы, пожалуйста.1. Не "или", а "и". Делаем доработки в SQL, затем делаем настройки на них.
2. Так только в строго коробочных системах. Тупиковое направление для систем широкого применения, ИМХО.
Возможность выполнения поверхностных донастроек (в т.ч. и написание SQL-запросов) на стороне клиентов, конечно, должна присутствовать в системе. Но это касается в первую очередь таких донастроек, которые не вносят изменения в операционные данные. К примеру, если один из клиентов готов пожертвовать производительностью системы ради просмотра в одном списке большого количества "тяжелых" данных, не совершая каких-либо дополнительных телодвижений, то такую настройку нужно естественно реализовывать только у этого клиента.
Тем не менее злоупотреблять такими настройками не стоит. Более правильной способ - понять, какую проблему клиент хочет решить в целом , возможно, есть другие, более удобные решения.