Показать сообщение отдельно
Старый 07.02.2009, 03:07   #32  
gl00mie is offline
gl00mie
Участник
MCBMSS
Most Valuable Professional
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
Лучший по профессии 2009
 
3,684 / 5788 (200) ++++++++++
Регистрация: 28.11.2005
Адрес: Москва
Записей в блоге: 3
Цитата:
Сообщение от coolibin Посмотреть сообщение
С точки же зрения потребителей системы из плюсов предложенного варианта увидел на вскидку три:
1. Незначительное снижение рисков проекта внедрения за счет уменьшения суммы необходимой на приобритение лицензий.
Фигасе, незначительное... Я лично был свидетелем того, как в производственной компании ген.директор, он же владелец, хотел - по наущению, ессно - внедрить Аксапту вместо доморощенной написанной на Delphi системы управления заказами (производство было ею вообще не окучено - жило отдельно на 1С), НО... грит, покажите мне, что Аксапта сможет выполнять хотя бы те же задачи, что существующая система, покажите, как наши бизнес-процессы будут в ней выглядеть. Ну вот уперся - и пофиг ему всякие case'ы и marketing hype. Внедренцы:
- Мы можем залить штатные демо-данные и показать стандартный функционал...
ГД:
- Не катит.
- Мы можем сделать специально обученные демо-данные на основе вашей системы и показать стандартный функционал...
- Не катит.
- Ну тогда купите лицензии, и мы быстренько слабаем нечто, похожее на вашу доморощенную систему - без производства, сводного, OLAP-анализа, etc.
- Это что, мне надо выложить [допустим] €50.000 только за "посмотреть"?!
- Ну и еще где-то €8.000 за работу. А без покупки лицензий - никаких модификаций функционала, такова лицензионная политика.
- Спасибо, до свидания.
Т.е. реально все упиралось в стоимость лицензий. Так что будь тогда такие варианты... Аксапта в этой конторе заработала бы намного раньше
Цитата:
Сообщение от coolibin Посмотреть сообщение
2. Возможность уменьшить влияние затрат по проекту на финансовые показатели просто за счет отсрочки оплаты. Но все-таки, основные затраты проекта внедрения - это не лицензии.
Фигасе... обычно лицензии составляют до трети стоимости проекта. Кому - незначительно, а кому (особенно в нынешнее время) - очень даже существенно.
Цитата:
Сообщение от coolibin Посмотреть сообщение
3. Возможность увидеть полный функционал системы даже в том случае, если, например, по планам было закупить только BE. Есть большая вероятность, что в процессе внедрения список лицензий будет пересмотрен в сторону увеличения набора, что так же выгодно и продавцу
Мне кажется, ключевой момент здесь - полный доступ к разработке. Это интересно и партнерам, поскольку не ставит для них непривычных ограничений (типа в исходный код не смотри, в EP не лезь), и клиентам, поскольку они могут увидеть все, на что способна система со всеми ее (оправданно) хвалёными возможностями по кастомизации.
Цитата:
Сообщение от coolibin Посмотреть сообщение
Что на мой взгляд было бы разумно изменить в предложении: Ограничение по количеству пользователей. Непонятно, почему так мало - 5?
Вспомним, из каких основных фаз состоит проект:
  1. предварительное обследование и анализ (лицензии нафиг не нужны);
  2. составление ТЗ на доработку/донастройку системы (аналогично);
  3. построение системы (вот тогда-то вы и захо-хочете лицензии);
  4. тестовая эксплуатация;
  5. промышленная эксплуатация и (с т.з. внедренца) первоначальная поддержка.
Реально количество одновременно работающих пользователей начинает волновать клиента лишь на заключительном этапе, потому что на предпоследнем этапе обычно в системе работают лишь ключевые пользователи, коих можно пересчитать по пальцам; опять же, вспомните штатные разграничения: one ring to rule them all, one ring to find them... тьфу, одна рабочая база, одна - тестовая, одна - разработческая. Т.е. разработчики из консалтинга могут совершенно спокойно впятером тусоваться в разработческой базе, пока ключевые пользователи впятером будут тусоваться в тестовой.
Цитата:
Сообщение от coolibin Посмотреть сообщение
Количество одновременно используемых лицензий на проекте распределяется по времени очень неравномерно. Заранее посчитать сколько понадобится для оптимальной работы непросто.
Achtung! А кто говорит про работу? Речь лишь про этап внедрения!
Цитата:
Сообщение от coolibin Посмотреть сообщение
Например, в какие-то моменты времени нужно посадить одновременно много людей на ручной ввод, в другой момент - провести обучение большого количества пользователей.
Вот если вы довольны результатами работы консалтинга и готовы "жить" с созданной системой - воля ваша: закупите нормальные лицензии, залейте их в тестовую базу и учите пользователей до посинения, хоть по 50 голов за раз... :-)
Цитата:
Сообщение от coolibin Посмотреть сообщение
Если же это станет постоянным предложением, то будет скорее расцениваться клиентом как попытка МС обернуть необходимость снижения цены лицензий всякими заумными схемами (аналогично, как это начинают сейчас делать строители). И даже может дать обратный эффект, то есть, насторожить клиентов. Вполне возможно, они почувствуют, что цена и на обычный пакет, вероятно, будет снижаться и примут решение переждать.
Помнится, аналогичный случай был в n-цатом году, когда некий посетитель форума очень возмущался тем, что при перерыве в покупке плана поддержки в случае его возобновлении MS, видите ли, просит компенсацию за "бесцельно прожитые [клиентом] годы" без плана поддержки. Как, мол, так, сокрушался форумчанин, ведь только что пришедший пользователь заплатит за поддержку меньше, нежели тот, кто "купил систему" раньше: где справедливость? Но ведь все эти годы "пришедший раньше" клиент пользовался системой и извлекал из ее работы выгоду - почему же он должен платить меньше того, кто начал извлекать выгоду из использования системы "вот только что"? Это я к тому, что использовать систему "здесь и сейчас" и использовать ее "как-нибудь потом, когда цены будут снижаться", - это, извините, "две большие разницы".
Цитата:
Сообщение от Ivanhoe Посмотреть сообщение
За свою практику не встречал проблем у клиента с покупкой лицензий. Как правило, лицензии покупались на стадии обследования / подготовки ТЗ. Опять же, после покупки лицензий клиент лишний раз подумает прежде чем решиться приостановить или свернуть проект.
Ну да, хорошо, если получится все провернуть таким образом... Но ведь и клиенты бывают "въедливые", которые не хотят платить здесь и сейчас за непонятно что...
Цитата:
Сообщение от mcc Посмотреть сообщение
AX уже практически самой дорогой на SMB-рынке ЕРП стала, если брать Advanced Management. А из-за одной несчастной intercompany приходится выбирать АМ.
"Хотите верьте, хотите - нет, а дело было так..." © х/ф "Полосатый рейс". В общем, есть примеры внедрений, где допилены очень витиеватые цепочки поставок между компаниями (в терминах Аксапты) "что и не снились нашим мудрецам", и при этом люди слыхом не слыхивали ни про какие Intercompany. С точки зрения AIF оно, может, интересно, а так - можно и перетоптаться без него, и еще неизвестно, что выйдет дешевле: реализация и поддержка своих "цепочек" или обучение пользователей жить в мире ограничений, навязанных Intercompany.
Цитата:
Сообщение от coolibin Посмотреть сообщение
Почему сразу разработчиков... Пользователи, например, еще задолго до промышленного старта могут начать, например, в системе причесывать справочники или параллельно с текущей работой тренироваться на демо-базе.
Вот чтобы тренироваться... Во-первых, просто так - пользователей не загоните, во-вторых, тех, что удастся заманить, хватит на демо-базу с лихвой. В-третьих, чтобы какой пользователь непонятно с чего начал справочники те же причесывать - да ни в жисть; а так, - без него решат, кто, когда, куда и сколько раз обязан будет ходить и что при этом делать. Если "прическа справочников" формализуема, то проще ее job'ом сделать, чем живых людей дергать на этот мартышин труд...
За это сообщение автора поблагодарили: mazzy (2), sukhanchik (5).