![]() |
#11 |
Участник
|
Цитата:
Сообщение от AXcons
![]() Никто, похоже, не видел в глаза что такое fit-gap анализ. Грустно.
А, между тем, эта табличка была и в Дамгардовской методологии, насколько я помню. И в sure step, вроде был вид этой таблицы, в какой-то последней версии методологии. Fir-gap это не дизайн. Это анализ покрытия требований функциональностью. Это пре-дизайн. У меня файлик с этим анализом выглядит так: Процесс Требование Тип требования Axapta полностью соответствует требованию? - да/нет Обходной путь Доработка (идея) Решение Трудозатраты при использовании обходного пути Трудозатраты без обходного пути Трудозатраты итоговые Приоритет Понятно, трудозатраты и решение - это уже процесс согласования. Затем, по итогам согласования этой таблички, пишется подробный дизайн - как именно будет все настроено в системе по каждой операции, и какие именно доработки, ТЗ к ним, концепция загрузки данных и т.д. и т.п... Но у нас задача была несколько облегчена тем, что компания достаточно изнутри стандартизирована и многие аспекты бизнес-логики можно было прочесть, прежде, чем идти искать реальное подтверждение на производстве и обслуживающих его подразделений, прежде, чем начинать сбор и уточнение требований. Это было важно-иметь четкое представление о том, что предстоит автоматизировать и как "безболезненно" избавляться в процессе от "зоопарка существовавших на тот момент ИС и разрозненных БД". Но это совершенно не похоже на те коммерческие предложения, которые готовятся в консалтинге для клиентов на предпродажной стадии "тиражирования коробочных бизнес-решений" с дополнительной оценкой необходимых доработок. Изучать все программные продукты, в т.ч. AXAPTA (на тот момент), к примеру, возможности доработки функционала своими силами, сам функционал. Никакого предварительного обучения программным продуктам и "коробочным решениям" не было. Ни единой книги по DAX у нас не было, ни курсов и сертификатов, ни опыта внедрения коробочных решений. Конечно трудозатраты и экономические аспекты оценки и обоснования выбора той или иной из сравниваемых ERP-систем помогали выполнять экономисты. Однако, нам это не помешало выполнить успешный проект своими силами. Потому как программистам разобраться проще, чем консультантам или архитекторам, которые не владеют навыками изучения функционала "изнутри" и было большое желание накопить опыт именно внутри команды, т.к. иначе "сидеть на игле тех. поддержки". В целом, хотелось бы сказать, что без знания бизнес-процессов конкретной компании (технологии производства, учета и проч.), а не просто типового представителя всей отрасли промышленности/сферы деятельности, сложно представить на сколько будет оптимальным внедрение "коробочного решения на базе ERP". Сидя в офисе на доработке коробочных решений и их продажах, по-моему, вообще сложно представить, что эти специалисты смогут помочь Вам оценить степень покрытия готовым функционалом всех бизнес-требований без тестовой базы данных и пилотного проекта. Для этого необходимо выезжать на объекты автоматизации, собирать информацию о том, какие решения использовались и на сколько успешно (хотя бы 2-3 типовых клиента). |
|