тиражируемые ERP?

iscrafm
Дата: 25.01.2012 21:09:49
Известный всем Попов на главной странице сайта вывесил ролик ( здесь, 15 минут ), в котором тиражируемое ERP ПО называется изобретением Авы. Как считаете, это толстый троллинг или он действительно не знает о существовании такого ПО? Или тиражируемого ПО в ERP-сегменте действительно нет?
ViPRos
Дата: 25.01.2012 23:09:26
iscrafm,

ну че тебя тянет на этот примитив?
iscrafm
Дата: 25.01.2012 23:10:57
ViPRos
iscrafm,

ну че тебя тянет на этот примитив?

ну мне интересно, все производители тиражных ERP поперхнулись или нет?
ViPRos
Дата: 25.01.2012 23:47:04
iscrafm,

не думаю что производители ЕРП интересуются высказываниями лавочника
битый
Дата: 26.01.2012 08:51:52
iscrafm
Известный всем Попов на главной странице сайта вывесил ролик ( здесь, 15 минут ), в котором тиражируемое ERP ПО называется изобретением Авы. Как считаете, это толстый троллинг или он действительно не знает о существовании такого ПО? Или тиражируемого ПО в ERP-сегменте действительно нет?

Забей...
iscrafm
Дата: 26.01.2012 11:11:42
битый,

да меня они не интересуют. По какой-то причине зашел на страницу и узнаю такое. Просто даже интересно стало куда делись все тиражные системы.
artemana
Дата: 26.01.2012 21:24:16
iscrafm
битый,

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

Наша пока на месте.

Ролик построен на подмене понятий. Клиника "AVA": - "после нашей ампутации у Вас никогда не будут мерзнуть ноги!!!"

Правда, в основе ролика, лежит действительная статистика. Довольно часто в результате адаптации продукта под заказчика, образуется такой большой кусок окаменелого ПО, которое перевести на новую версию от производителя и (или) разобраться в нем без придворного программиста очень дорого, почти невозможно.

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

Адаптация должна быть в разумных пределах и включать только те моменты, которые действительно актуальны для конкретного клиента или отрасли. При этом базовые возможности системы должны быть развиты прилично, то есть ERP-система не должна поставляться полуголой. И главное, архитектура системы должна давать возможность поставщику относительно дешево обновить клиенту функционал базовой версии, не подвергая его персональные модули полному перепрограммированию. Конечно, те клиенты кто полностью отказывается от персонализации своего ERP-проекта выигрывают в затратах на внедрение и сопровождение. Но есть и другие критерии, т.е., как и везде - все дело в пропорции.
iscrafm
Дата: 26.01.2012 21:41:10
artemana,

я о том и говорю. Меня впечатлило то, что он говорит: это мы придумали тиражные ERP. Как один из создателей такой Российской ERP еще в 90-е аж поперхнулся.
Garya
Дата: 27.01.2012 16:38:22
По описываемой "революционной" схеме работала и работает сопровождение целого ряда ERP-систем, в частности, SyteLine, ИТ-Предприятие и ряда других. Заявление о том, что AVA первая в мире изобретательница велосипеда - фарс, вошедший уже в традиции AVA.

Коллеги из AVA, похоже, не понимают, что у маркетингового привирания имеются границы, переходить через которые самим себе дороже. Люди, которые врут на каждом шагу, в том числе без острой на то необходимости и не считаясь с масштабами привирания, создают себе и соответствующую репутацию - вместо рекламы (как они себе это представляют) делают антирекламу. Во всяком случае, я, как специалист, представляющий интересы не вендора и не франча, а потенциального заказчика, изначально исключил бы из перечня рассылки тендерных предложений компанию, которая ведет себя как цыганка на вокзале. Однако, это их личное дело.
___
Абстрагируясь от конкретных вендоров и персоналий, мне кажется, имеет смысл рассмотреть отличия различных моделей сопровождения. Следует заметить, что их гораздо больше, чем две, и, если их даже как-то упростить и сгруппировать, то получается примерно так:
1) [вендор ПО] - [заказчик]
2) [вендор ПО] - [кастомизатор] - [заказчик]
3) [вендор платформы] - [вендор решения] - [заказчик]
4) [вендор платформы] - [вендор решения] - [кастомизатор] - [заказчик]
...
И даже по перечисленным моделям могут быть вариации. К примеру, часть кастомизации может выполняться вендором решения, часть сторонней организацией-кастомизатором, часть собственными специалистами заказчика, и тогда кастомизация разбивается на слои, выстраивается матрица ответственности во взаимосвязи с уровнями функицонала.

Вне всякого сомнения, модель 1) делает конечного потребителя более близким к вендору ПО. С одной стороны, это плюс. С другой стороны, вендору ПО приходится проваливаться своими мозгами во множество мелких проблем всех своих клиентов, и чем количество клиентов больше, тем труднее это становится делать.

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

Таким образом, делится частное и общее на сферы ответственности и на уровни сопровождения таким образом, чтобы на каждом уровне риски были сведены и трудоемкость сопровождения были сведены к минимуму.

Если говорить о динамике от модели 1) к модели 4), то в общем случае можно сказать, что 1) оптимально использовать мелкими разработчиками ПО с небольшим количеством клиентов. При этом разработчик ПО может выглядеть в глазах клиента более выигрышно за счет более высокой оперативности сопровождения, низкой стоимости продукта и большей ориентированности продукта на частные запросы. По мере увеличения порядкового номера модели увеличивается и количество пользователей продукта. Модель 1) неприменима при большом количестве конечных потребителей, хотя может иметь преимущества при малом. При увеличении числа клиентов, как правило, увеличивается и порядковый номер применяемой модели сопровождения. Какая именно модель сопровождения лучше, определяется масштабами этого сопровождения.

____

Судя по тому, что коллеги из AVA применяют модель 1), количество клиентов у них относительно небольшое, потому что для большого количества клиентов она неприменима. К примеру, сопровождение ERP-системы SyteLine новый ее владелец (INFOR) перевел в модель с партнерами-кастомизаторами, потому что количество клиентов выросло до критической величины.
client500
Дата: 28.02.2012 19:20:50
увидел много пространных объяснений и частных мнений не в обиду авторам, а где факты, кто ни будь тестил это ПО?
а то получается из разряда, "я Пастернака не читал, но творчество его осуждаю"