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

[AXcons]

Цитата:

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

Очень хорошо, тогда - пункт 2, так называемое предложение Solution Architecture Assessment, первый же пункт программы. Обращаю ваше внимание на то, что подается все меню целиком, а не только закуска или только десерт.

Предполагаю, что исходно вы общались с "Technology Solutions Professional", но это действительно не та профессия, которая нужна.

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

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

[mnt_dx]

Цитата:

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

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

Как вы себе видите эту концепцию? Мне думается, что 1-2 дня это слишком оптимистично. Даже просто на подумать надо больше.

[miklenew]

"с этим все прозрачно
эх разогнать бы всю эту кодлу
навести бы порядок
да все некогда, программировать нужно" (c)

[komar]

Цитата:

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

навести бы порядок
да все некогда, программировать нужно" (c)

Ну вот, перед вами Винни-Пух. Как видите, он спускается по лестнице вслед за своим другом Кристофером Робином, головой вниз, пересчитывая ступеньки собственным затылком: бум-бум-бум. Другого способа сходить с лестницы он пока не знает. Иногда ему, правда, кажется, что можно бы найти какой-то другой способ, если бы он только мог на минутку перестать бумкать и как следует сосредоточиться. Но, увы – сосредоточиться-то ему и некогда... (А.Милн)

[AXcons]

Цитата:

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

Как вы себе видите эту концепцию? Мне думается, что 1-2 дня это слишком оптимистично. Даже просто на подумать надо больше.

Черт, я это вижу так, ка как это написано в методологии. В любой методологии, причем... Как в анекдоте "Какого Цукерберга? - Да любого Цукерберга"..

1-2 дня нормально для моего проекта. Потому что у нас мало операций и довольно простой учет. Если вы газпром будете автоматизировать, то месяцок-другой потребуется, это да.

[gudzon]

Цитата:

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

1-2 дня нормально для моего проекта. Потому что у нас мало операций и довольно простой учет. Если вы газпром будете автоматизировать, то месяцок-другой потребуется, это да.

8-16 часов пишется и согласуется одна ФД. А вы целый анализ хотите. Хватит уже ворчать. Даже если какой то чудак с опытом (!!!) и возьмется вдруг за работы на 16 часов (!!!) вы ж будете месяц работы принимать с таким подходом.
ЗЫ напишите хоть конкретику. что хотите то.

[AXcons]

Цитата:

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

8-16 часов пишется и согласуется одна ФД. А вы целый анализ хотите. Хватит уже ворчать. Даже если какой то чудак с опытом (!!!) и возьмется вдруг за работы на 16 часов (!!!) вы ж будете месяц работы принимать с таким подходом.
ЗЫ напишите хоть конкретику. что хотите то.

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

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

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

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

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

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

[Raven Melancholic]

Что-то у нас второй день рассерженной прекрасной половины человечества.

Цитата:

Мы работаем с 1С

С Вами работает непосредственно ООО "1С", центр компетенция, партнер? В команде, которая с Вами работает есть Харитонов?

Цитата:

У меня файлик с этим анализом выглядит так:

Такой файлик делается за 1-2 дня? Сколько делал такое Ваш визави от 1С, сколько вендор WMS системы?

[AXcons]

Цитата:

Сообщение от Raven Melancholic

Такой файлик делается за 1-2 дня? Сколько делал такое Ваш визави от 1С, сколько вендор WMS системы?

Да, если у вас список операций уже готов (он делается на предыдущем этапе, и систему вы знаете, то да, что тут больше делать то?

[gudzon]

Цитата:

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

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

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

[mazzy]

Цитата:

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

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

Му-ха-ха-ха!

Похоже, вы видели только один документ, который называете fit-gap анализом. Смешно.

[AXcons]

Цитата:

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

Му-ха-ха-ха!

Похоже, вы видели только один документ, который называете fit-gap анализом. Смешно.

А выложите тот fit-gap, который вы делаете. Может, вместе и посмеемся?
Я могу поискать разные - и из оракловой методологии, и из sure step, и методологию европейских консалтеров, только вот дамгардовский фит гап уже потерялся, но если постараться и его можно найти.

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

[kingozzavr]

Цитата:

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

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

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

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

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

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

Я правильно понимаю, что у вас данный файлик уже заполнен в части пунктов:
1. Процесс
2. Требование
3. Тип требования

и вам необходимо, чтобы консультант прочитал и заполнил пункты:
1. Axapta полностью соответствует требованию? - да/нет
2. Обходной путь
3. Доработка (идея)
4. Решение

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

2AxCons

так как не знал что такое fit gap анализ то за развитие +

Для тех кто тоже не сталкивался:

http://marketolog.biz/gap--page-125.html

http://www.elitarium.ru/gapanaliz_preodolenie_razryvov/

[Atar]

Цитата:

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

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

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

[SOVA]

Цитата:

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

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

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

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

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

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

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

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

[mnt_dx]

Цитата:

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

Черт, я это вижу так, ка как это написано в методологии. В любой методологии, причем... Как в анекдоте "Какого Цукерберга? - Да любого Цукерберга"..

1-2 дня нормально для моего проекта. Потому что у нас мало операций и довольно простой учет. Если вы газпром будете автоматизировать, то месяцок-другой потребуется, это да.

Покажите требования к какой-либо операции, можно в ЛС, может что-то подскажу.

[Atar]

Цитата:

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

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

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

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

[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

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

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

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

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

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