Показать сообщение отдельно
Старый 26.06.2019, 11:40   #8  
Ivanhoe is offline
Ivanhoe
Участник
Аватар для Ivanhoe
Лучший по профессии 2017
Лучший по профессии 2015
Лучший по профессии 2014
Лучший по профессии AXAWARD 2013
Лучший по профессии 2011
 
4,143 / 2155 (80) +++++++++
Регистрация: 29.09.2005
Адрес: Санкт-Петербург
А у вас CRM это насколько важная система для бизнеса? Доверять облаку MS не все готовы, а доверять еще более мелкому провайдеру - ну такое Что будет если они закроются? Должны быть какие-то очень веские причины идти в облачное решение такого провайдера.

Цитата:
Я "происхожу" из мира Dynamics AX, где большинство внедрений очень долгие, проблематичные, все дедлайны и бюджеты в несколько раз в итоге выше обещанных изначально сейлзами. Очень редко какой проект обходится совершенно без модификаций кода. А апгрейды на новую версию обычно отдельный проект-кошмарчик. По моему опыту это происходит из-за очень поверхностного изначального анализа бизнес-требований и желании сейлзов проекта подцепить клиента (а дальше ему уже деваться некуда), поэтому клиенту даются нереалистичные сроки и оценка . Дополнительно тут же появляются скрытые расходы на инфраструктуру (доп сервера, память (для разворачивания различных environments нужны доп сервера + сервера для Batch - processoв, потом еще и обнаруживаются доп проблемы с производительностью и снова нужно подкупать стероиды)
1. В аксапте бывают проекты разные. В том числе не очень долгие и не очень проблематичные. Тут больше не от системы зависит, а от того, что "продано" и что "куплено", а также от самих заказчиков и подрядчиков.
2. Модификации не есть абсолютное зло. Важен баланс - что вы получаете за стоимость лицензий, а что вы оплачиваете за кастом. И за какое качество кастома вы готовы платить, и какое качество может обеспечить подрядчик.
3. Обновление платформы / версии не может быть самоцелью. Вы делаете Автоматизированную систему, которая должна решать бизнес-задачи. Заложить в нее все возможные будущие бизнес-задачи не реально. Надеется на то, что в будущем обновлении платформы появится именно то, что вам нужно - ну такое.
4. Нереалистичные сроки дают странные продавцы - мнение производства не учитывается? В договоре никаких обязательств и штрафных санкций? Тогда это уже вопросы к покупателю - а что же он купил у таких продавцов?
5. Требуйте в договоре описание всех расходов, даже если какие-то еще трудно определить. Услуги на внедрение, оценку услуг по поддержке, оценку лицензий / облака / железа на старте проекта, на запуске системы, потенциально на 5 лет вперед. Явно впишите что любые дополнительные затраты за счет поставщика, пусть задумаются сразу, не стоит ли включить покупку Visual Studio (чисто пример) в закупку по договору.
6. В договоре хорошо бы хоть как-то зафиксировать состав работ/услуг по проекту. В т.ч. поймете какое тестирование предполагается. В т.ч. можно явно прописать состав сред для проекта: dev, test, build, prod или что там нужно по их методике.

В связи с облаком хорошо бы еще такие вопросы прояснить: у вас выделенная инфраструктура будет или shared с другими клиентами (мало ли). Как гарантируется производительность (если гарантируется), работоспособность, сроки восстановления в случае поломок и т.п.. Кому принадлежат права на систему и все наработки в рамках проекта. Какие работы по поддержке / администрированию облачного решения включены в стоимость.
__________________
Ivanhoe as is..

Последний раз редактировалось Ivanhoe; 26.06.2019 в 11:42.
За это сообщение автора поблагодарили: Артем Enot Грунин (1), cuba (1).