По мотивам общения с Майкрософтом

[kingozzavr]

Цитата:

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

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

Я не говорю, что все дураки. Нет. Но технологии внедрения на рынке грамотной нет. Мое мнение. Если думаете по другому - просто докажите это, покажите кто умеет хорошо внедрять. Я очень обрадуюсь, если найдутся такие люди/компании. Честно.

Ну смотрите, насколько я понял, у вас судя по всему уже готов документ, который обычно называется "Функциональные требования", таким образом, база для проведения fit-gap анализа уже есть. Проблема видимо в том, что собственных ресурсов для его проведения нет. Требуется привлечь экспертов, которые помогут определить, какие из требований могут быть реализованы за счет функционала Axapta, а какие останутся за рамками \ потребуют доработок?

Из партнеров, я бы вам рекомендовал российский офис Коламбуса или Корус. Там точно есть хорошие специалисты.

[Atar]

Fit Gap - лишь одна из последних активностей фазы Анализ, если мы не говорим про Диагностику. Впрочем, и там суть та же.
В любом случае, он служит для того, чтобы:
1. задокументировать соответствие Решения требованиям,
2. определить способы устранения несоответствий.

Не все клиенты согласны платить за такой документ отдельно, как и за многие другие предусмотренные методологией работы. Поэтому, часто в целях экономии эти 2 пункта выполняются частично в рамках того же Анализа процессов и частично - уже Дизайна. И документируются либо в описании процессов, либо в Дизайне решения (FDD в терминологии MS SS), в зависимости от принятого способа устранения несоответствия.

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

Так вот, если по существу вопроса - Fit Gap анализ возможен только после анализа требований. Вы хотите за 2 дня провести ряд сессий рабочих встреч и задокументировать требования (ну или в Вашем случае - проанализировать готовый документ с требованиями), чтобы за тот же срок ещё и задизайнить/задокументировать обходы и устранения несоответствий?
Если речь об одном небольшом процессе, не связанном с другими (я б это назвал даже скорее небольшим набором функций процесса) - наверное такое возможно.
Но невозможно в случае Решения в целом.

P.S. что то в последнее время на axforum активизировались дамы. Ранее в подобных "активностях" участвовали сплошь мужики. Тенденция?

[Atar]

Цитата:

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

А мне надо, чтобы, наоборот, помогли сделать концепцию функциональности по ключевым операциям.
В принципе, это работы на полдня-день, имея прописанные операции и требования.

1. А Вы уверены, что исполнителя устроит качество и детализация прописанных операций и требований?
2. Опытный специалист знает, как много он ещё не знает. Остальные думают, что за день можно оценить степень несоответствия и необходимость изменений, да ещё и задокументировать их.
Это действительно, к продавцам партнёров.
Вас правильно направили.

Я вижу, что Вы опытный специалист, поэтому недоумеваю, откуда такие противоречия в требованиях.

[Atar]

Цитата:

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

В принципе, если у вас действительно ..., то сделать fit-gap анализ возможно за несколько дней, ... Но опять же, если ... то это сделать скорее всего получится.

Очень много "если", и при этом в конце всего лишь "скорее всего". Очевидно, что это из-за того, что не все "если" перечислены.
И даже тут речь ни о полдня, но и о дне, ни о двух днях.
Видимо, тоже неадекватная оценка?

[miklenew]

Цитата:

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

Сколько видел - это проекты типа "пришли - поставили стандарт - допиливаем годами по кругу, пока сами не запутаемся"

Сколько? И какой процент таких?
Допиливание допиливанию рознь.
Одно дело допиливание на стадии внедрения, другое на стадии эксплуатации.
Второе это уже жизнь организации с этим продуктом.
Новые отчёты, новая функциональность, полезные бантики для старых вещей и всё это нужно.

[miklenew]

Судя по сводкам с фронта, щас нет недостатка кадров на рынке труда.
Самое время взять 2-3 программистов и внедрять всё своими силами.
Тут он что то прокашлял. Было слышно что то заканчивающееся на "с".
Самим делать прототипы и смотреть, что подходит, что нет.
Тут то вам насоветуют, что для внедрения нужно банда как минимум 5 человек.
Не верьте.
Прошлая работа (производство машиностроение): 2 (программиста-консультанта) + 1 РП (он же консультант).
И прототипы и документацию и обучение всё на троих.

[gudzon]

Цитата:

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

Самое время взять 2-3 программистов и внедрять всё своими силами.
Тут он что то прокашлял. Было слышно что то заканчивающееся на "с".

Дайнемикс Акс

[AXcons]

Цитата:

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

1. А Вы уверены, что исполнителя устроит качество и детализация прописанных операций и требований?
2. Опытный специалист знает, как много он ещё не знает. Остальные думают, что за день можно оценить степень несоответствия и необходимость изменений, да ещё и задокументировать их.
Это действительно, к продавцам партнёров.
Вас правильно направили.

Я вижу, что Вы опытный специалист, поэтому недоумеваю, откуда такие противоречия в требованиях.

У меня как раз противоречий нет. Но, т.к. никто из присутствующих, судя по всему, такой документ не делал, то и возникает непонимание. Просто нет опыта работы с такой технологией.

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

Этап Анализа:
1. Проводим анкетирование, интервьюирование, собираем документы, процедуры, учетные политики, отчетные формы - что есть, короче.

2. Составляем документы:
- Лист операций/требований. - экселевская таблица: БП/Операция/Требования к операции, тип требования, .. какие-то аналитики еще..приоритеты...

- Альбом печатных и отчетных форм.

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

3. Согласовываем список операций и требования - что все правильно, ничего не забыли.

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

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

Про 1-2 это была оценка работы именно на моем проекте, потому что 1) у нас Аксапта уже много лет есть, перечень требований известен, обдуман и понятен, вопрос только (!) в функциональности 2012 версии - что-то, может быть, там добавилось, что может облегчить наше существование... На это много времени не надо. К тому же, есть подозрение, что по на большинство вопросов ответ будет "нет".

Почему именно хотелось, чтобы кто-то из Майкрософта помог сделать этот анализ - потому что мнения о функциональности 12й разняться. Например, мне в МС говорили, что появилась новая складская аналитика "Канал дистрибуции", а нам как раз это очень надо. Спросила у нашего нового подрядчика по Аксапте - они очень удивились, пошли в Аксапту посмотреть - нет такого. Не нашли такой аналитики в системе. Меня такие вещи настораживают. Коллеги из другого партнера тоже смотрят на наши требования - говорят "ничего нет". А у МС в презентациях все есть... Как так? Кому верить? Если есть - пусть покажут как работает..

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

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

7. По итогам этапа подписываются: перечень требований, перечень доработок с разбивкой по этапам, альбом отчетных/печатных форм.

Также по итогам согласования перечня доработок уточняется бюджет на следующие этапы.

Этап Дизайн:

1. Берем табличку с операциями/требованиями, добавляем несколько колонок, и пишем в них дизайн системы и кратко идеи доработок.

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

3. Согласовываем дизайн.
Тестовый дизайн также можно написать при необходимости, но без фанатизма. Не копи-паст руководства пользователя.
Один партнер нам заявил как-то - да, у нас Дизайн системы является руководством пользователя, мы не пишем отдельного руководства. Редчайший бред.

Корректируем бюджет на этап Разработки при необходимости.

Этап Разработки

Пишем ТЗ, делаем разработку, тестирование...
ну дальше не буду расписывать..

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

Естественно, не претендую на то, что этот подход самый или единственно верный. Но он технологичный. Подсмотрен, кстати, у европейских консалтеров. Вообще им за науку большое спасибо.

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

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

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

Anyway, всем спасибо за участие в дискуссии.

[mazzy]

Цитата:

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

Например, мне в МС говорили, что появилась новая складская аналитика "Канал дистрибуции", а нам как раз это очень надо. Спросила у нашего нового подрядчика по Аксапте - они очень удивились, пошли в Аксапту посмотреть - нет такого. Не нашли такой аналитики в системе.

Канал дистрибьюции - это не складская аналитика.
это понятие появилось в 12 в модуле retail

можно трактовать это понятие как отдельный магазин, как группу магазинов (например, территориально близких. например, интернет магазины отдельно, реальные магазины отдельно)

канал дистрибьюции в русской версии находится в группе настроек "распределение". ))))

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

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

вы бы просто спросили... Бгггг.

[mazzy]

по сути:
вам говорят, что примерно по такой технологии работают все.
вам говорят, что примерно такие документы делают все.
вы не верите. это ваше право.

Цитата:

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

У меня как раз противоречий нет.

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

а многие здесь отлично понимают, что "сдать" займет гораздо больше времени и сил, чем "сделать".

Цитата:

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

Но, т.к. никто из присутствующих, судя по всему, такой документ не делал, то и возникает непонимание. Просто нет опыта работы с такой технологией.

Восторг! Чистый восторг!

Но это всего лишь значит, что "сдать" вам (заказчику, которого вы представляете) будет в разы дольше (трудозатратнее). И всего-то.
вы ж не первый заказчик, который считает себя исключительным.
можно сказать, что вы типичный представитель типичного заказчика.

Цитата:

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

Вообще такой документ составить несложно, если вы...

составить - говно вопрос. только его ж потом утвердить у вас надо будет, акт подписать...

Цитата:

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

у нас... перечень требований известен, обдуман и понятен, вопрос только

меня искренее восхищает эта детская непоследовательность.
в двух предложениях смешать "вы", "мы" и безличные глаголы...
Бгггг!!!!

Восторг! Чистый восторг!

Цитата:

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

К тому же, есть подозрение, что по на большинство вопросов ответ будет "нет".

Бггггг!!!

Цитата:

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

Почему именно хотелось, чтобы кто-то из Майкрософта помог сделать этот анализ

господи, да в чем проблемы то!
заплатите им по их ставкам. я не помню случая, чтобы майкросот отказался от оплаченных работ.

Цитата:

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

А у МС в презентациях все есть... Как так? Кому верить? Если есть - пусть покажут как работает..

Му-ха-ха-ха!
Корпорация зла, не иначе!

Цитата:

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

5. С заказчиком просматриваем этот документ, и принимаем решение по доработкам - сколько стоит

"принимаем" - в данном случае, кто подразумевается под участником этого действа?
если исполнитель, то каков прогноз на длительность этого шага? и как будет оплачиваться исполнителю этот шаг?

))))))

Цитата:

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

7. По итогам этапа подписываются: перечень требований, перечень доработок с разбивкой по этапам, альбом отчетных/печатных форм.

а здесь кто участники?
цитата из вашего сообщения:

Цитата:

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

Вообще такой документ составить несложно, если вы...

Цитата:

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

Также по итогам согласования перечня доработок уточняется бюджет на следующие этапы.

О! У вас и согласование предусмотрено...
Угу! Точно! 1-2 дня. Несложно.
Му-ха-ха-ха!


AXcons, боюсь что вы даже не осознаете как доставляет ваш текст.

[SOVA]

Цитата:

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

Никто, похоже, не видел в глаза что такое fit-gap анализ. Грустно.

А, между тем, эта табличка была и в Дамгардовской методологии, насколько я помню.
И в sure step, вроде был вид этой таблицы, в какой-то последней версии методологии.

Fir-gap это не дизайн. Это анализ покрытия требований функциональностью. Это пре-дизайн.

У меня файлик с этим анализом выглядит так:
Процесс
Требование
Тип требования
Axapta полностью соответствует требованию? - да/нет
Обходной путь
Доработка (идея)
Решение
Трудозатраты при использовании обходного пути
Трудозатраты без обходного пути
Трудозатраты итоговые
Приоритет

Понятно, трудозатраты и решение - это уже процесс согласования.

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

Почему же не видели? Видели и делали, но в основном, чтобы обосновать выбор конкретной ERP-системы, к примеру, DAX и примерно оценить трудозатраты и стоимость проекта. Речь шла о комплексной автоматизации производственного холдинга-внутренний проект.
Но у нас задача была несколько облегчена тем, что компания достаточно изнутри стандартизирована и многие аспекты бизнес-логики можно было прочесть, прежде, чем идти искать реальное подтверждение на производстве и обслуживающих его подразделений, прежде, чем начинать сбор и уточнение требований.
Это было важно-иметь четкое представление о том, что предстоит автоматизировать и как "безболезненно" избавляться в процессе от "зоопарка существовавших на тот момент ИС и разрозненных БД".
Но это совершенно не похоже на те коммерческие предложения, которые готовятся в консалтинге для клиентов на предпродажной стадии "тиражирования коробочных бизнес-решений" с дополнительной оценкой необходимых доработок.
Изучать все программные продукты, в т.ч. AXAPTA (на тот момент), к примеру, возможности доработки функционала своими силами, сам функционал.
Никакого предварительного обучения программным продуктам и "коробочным решениям" не было.
Ни единой книги по DAX у нас не было, ни курсов и сертификатов, ни опыта внедрения коробочных решений. Конечно трудозатраты и экономические аспекты оценки и обоснования выбора той или иной из сравниваемых ERP-систем помогали выполнять экономисты. Однако, нам это не помешало выполнить успешный проект своими силами. Потому как программистам разобраться проще, чем консультантам или архитекторам, которые не владеют навыками изучения функционала "изнутри" и было большое желание накопить опыт именно внутри команды, т.к. иначе "сидеть на игле тех. поддержки".
В целом, хотелось бы сказать, что без знания бизнес-процессов конкретной компании (технологии производства, учета и проч.), а не просто типового представителя всей отрасли промышленности/сферы деятельности, сложно представить на сколько будет оптимальным внедрение "коробочного решения на базе ERP".
Сидя в офисе на доработке коробочных решений и их продажах, по-моему, вообще сложно представить, что эти специалисты смогут помочь Вам оценить степень покрытия готовым функционалом всех бизнес-требований без тестовой базы данных и пилотного проекта.
Для этого необходимо выезжать на объекты автоматизации, собирать информацию о том, какие решения использовались и на сколько успешно (хотя бы 2-3 типовых клиента).

[gudzon]

Цитата:

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

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

То что вы описали это не "ваш подход". Это базовая методология создания ЛЮБОГО продукта (и не только айти). Так работает ЛЮБОЙ консалтинг (и не только айти). Устал повторять.
В сухом остатке. Понятно, что вы устроились на заказчика. Требования описали. В системе лень ковыряться и изучать. Ищите тех, кто возьмет на себя этот нелегкий труд. Требования то описать не сложно. Попробуйте их на систему наложить правильно. Да еще и доработки нужные описать. Такие люди есть. Но задешево и быстро никто делать не будет. Точно не один два дня. Люди с опытом это понимают и вам пишут. У вас 10 групп процессов. Они очень укрупненные. Чего стоит "все что связано с продажей" и "все что связано с закупками". Ну это ладно. Пусть в каждой группе по 10 процессов. В каждом процессе по 5 операций. Итого 500 операций. Их надо сопоставить с функционалом в системе. На стандарт ляжет от силы процентов 80%. 20% надо описать вам доработки. И это я молчу про печатные формы, интеграцию, согласование документа (здесь вы точно крови попьете). Также правильно сказали - надо еще продумать связь между модулями.
ЗЫ Утомила уже тема. Неделю поразвлекали, спасибо. Удачи вам. Продумайте нормальный бюджет или тайм материал - и люди к вам потянутся. А с таким подходом как у вас - так и не сделаете ничего. Или в 1С. Они с радостью мелкими шажками будут допиливать ваши пожелания лет 5.
ЗЫ Ваша проблема, имхо, не в методологии. И уж тем более не в шаблоне документа fit gap анализ. А в том чтобы найти специалистов, которые хорошо (именно работали с этим, а не просто тренинги прочитали и видели один раз) знают указанные вами области. Корус вам предлагал помощь. У них точно есть специалисты по разным областям. Или Коламбус. Но будьте готовы деньги платить.

Цитата:

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

... Корус вам предлагал помощь. У них точно есть специалисты по разным областям. Или Коламбус...

Are you sure?
I-neti тогда уж впишите, чо уж мелочиться.

Цитата:

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

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

Ну в общем то имхо вы двигаетесь в правильном направлении и мыслите здраво. Найдите опытного консультанта по конкретной тематике (путем встречи с узкими специалистами и опросом) и вперед тем более разработчики у вас есть.

[gudzon]

Цитата:

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

Are you sure?
I-neti тогда уж впишите, чо уж мелочиться.

i-neti не занимается консалтингом.

Цитата:

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

i-neti не занимается консалтингом.

"крупнейшая компания России, специализирующаяся на разработке и сопровождении (техподдержке) Microsoft Dynamics AX и 1С."
"всего в штате компании 11 консультантов и 25 разработчиков Dynamics AX. "
В общем тоже самое что в Корусе что в Колумбусе.
Тем более в списке клиентов есть и Колумбус и Корус и Навикон (т.е. привлекают ресурсы из данной конторы так как нет своих специалистов видимо)

[Удвой Покуров]

Цитата:

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

У всех остальных вендоров выполнима почему-то. Мы работаем с 1С, с вендором розничной системы, со складской системой, и т.д. - и у всех это выполнимо.

Цитата:

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

Вы хоть один документ fit-gap анализа видело от наших российских консультантов? Никто не может отчет об обследовании написать нормально, о чем вы вообще говорите...

Какие-то взаимоисключающие параграфы.

Цитата:

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

Никто, похоже, не видел в глаза что такое fit-gap анализ. Грустно... Fir-gap это не дизайн. Это анализ покрытия требований функциональностью. Это пре-дизайн. У меня файлик с этим анализом выглядит ... 14. Учет ОС.
15. Кросс-док хранение на складе.

Похоже, это Вы не видели нормального GFA. То, о чем Вы говорите - это обычно быстро в рамках пресейла делается, типа есть/нет. Как в том анекдоте "Приборы? -800! -Что 800? -А что приборы?". Ну, укажут что учет ОС есть. Он и в упомянотом Вами Oracle EBS есть. Как, кстати, и крос-докинг. Так что смело ставим "+". А только потом оказывается, что Учет ОС - только буржуйсткий, и для крос-докинга необходима дозакупка модуля WMS.

Цитата:

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

Для 9-ки я такое могу сделать за 1-2 дня.

На таком уровне - это делается опытным архитектором за 1-2 часа, причем по разным системам. Много ли ума надо - галочек наствить. А вот отвечать за их правильность, это другое дело. Это и стоит те 2-3 недели, про которые вам говорят. Но перед нами типичный пример тупого клиента, который никак не думает о том, что сначала надо подписать НДА, заключить договор, в котором, кстати, будет и ответсенность прописана, потом провести интервью с ключевыми сотрудниками (найдя их сначала и поймав), понять их задачи - что с чем сравнвать, какие ТОЧНО задачи надо решать в новой системе (что они уже поговонокодили, что можно заменить стандартом в новой версии, что надо будет переносить и разрабатывать заново), потом писать протоколы общения с пользователями и четкое формирование требований к функциональному объему проекта, и только потом - писать сравнение - Gap/Fit, причетм не просто по функциям, а в разрезе выявленных задач (и скрытых, которые надо реализовать для их реализации), и, кстати, для тех кто не видел нормальных GFA и считает что их можно сделать за 1 день - вписать не только плюсик / минусик (и, в тяжелых случаях "+/-"), а кол-во в часах доработок, в рамках которых планируется реализовать данную разницу в текущей и требуемой функциональности! И именно по этому документу идет первая оценка трудоемкости проекта, в части реализации требуемой функциональности для сдачи проекта. (Ну, правда, есть еще один Gap/Fit, в котором указана критичной той или иной функциональности, по ней можно разбивать проект на части - что необходимо для запуска, что можно реализовать после старта проекта - это для умников, которые за 1 день GFA делают и других этомц учат).

Цитата:

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

Нет, это называется русский г-но консалтинг

Это называется русский г-но клиент. Которому будешь 2 недели сдавать любой документ, "это не так, это не то, да я сам это сделаю за 2 часа!". Как будто сдача документов - это бесплатное время консультанта. "А не хотите - полно других партнеров". И прошибают их по цене, онижетакойисключительныйклиент. Люди работают ниже рентабельности, потом разоряются.

Лечится полугодовой практикой на любом консалтинге, когда данные персонажи видят сами себя с другой стороны. И их "да я за 2 дня сделаю! -Отлично! Вы не такой, как остальные, все хотят с нас 2 недели!!" Вдруг превращаются в те самые 2-3 недели, а то и месяц. То пользователей нет, то формат не тот.. и, вообще, не будем платить за ваш "

Цитата:

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

русский г-но консалтинг

[Bobkov]

Цитата:

Сообщение от Удвой Покуров

Которому будешь 2 недели сдавать любой документ, "это не так, это не то, да я сам это сделаю за 2 часа!".

Самый перл - это "Вам же сразу сказали, что все нужно сделать хорошо, а вы все сделали плохо!"

[gudzon]

Цитата:

Сообщение от Удвой Покуров

Лечится полугодовой практикой на любом консалтинге, когда данные персонажи видят сами себя с другой стороны.

Со всем согласен) А с этим вдвойне!

[Vals]

Мужики, хватит гнать на клиентов

P.S. Люблю всех наших клиентов!

[KiselevSA]

(вставлю свои пять копеек)
Основной свой опыт с AX получил на клиенте и, глядя с той колокольни, на эту дискуссию, могу сказать: две, нет, три основные проблемы взаимоотношений клиент/консалтинг на проекте - это отсутствие бизнес-аналитика со стороны клиента, умеющего работать толмачом между специалистами двух сторон (перевод с птичьего на другой птичий); отсутствие прикладника со стороны консалтинга; идиотская приверженность некоторых представителей клиента к «рюшечкам» и нежелание тратить оставшиеся нервы специалистами консалтинга на борьбу с рюшечками.
Запустите основные процессы, научите пользователей работать, покажите преимущества и расскажите, как малой кровью обойти недостатки. О рюшечках и прочей рихтовке задумайтесь потом. Очень часто альбом процессов и альбом документов при разработке выливается в следующее закидывание помидорами: «- Вы не сказали, что это нужно (или что нужно учесть это и это). - А вы не спросили об этом.» Да чтобы спросить, надо знать, о чем спрашивать.
Специалисты клиента забывают или не хотят (иногда и специально) раскрывать все «секреты»: «Вот не скажу, может и останемся в знакомой среде». Высшее руководство, заинтересованное в переходе на новую систему, спрашивать, за редким исключением, бесполезно, ибо они нарисуют сферического коня в вакууме, свою розовую мечту, далекую от истины. Итоговый документ превращается в декларацию о намерениях с легким абрисом «болевых точек». И это не устраивает обе стороны: «Плохой консалтинг, забыли … (список на n листах)»; «Проблемный клиент, список дополнительных работ на n листах без расширения бюджета». Хорошо, если у консалтинговой компании есть уже опыт в выбранной сфере автоматизации. Уже наступали на грабли и знают, что надо не забыть спросить. Мелкие отличия сильно не скажутся. А если нет? Вот тут и начинается игра в русскую рулетку, а всего-то надо одного толмача, который не будет относиться к рискам проекта.