Продолжаем про системную подготовку к внедрению (начало здесь и здесь). Теперь поговорим про подготовку внутренней команды.

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

А между тем, одним из важнейших драйверов успеха является вовлечённость будущих пользователей ИС в процесс внедрения.

Представьте 2 разных ситуации: - вы собрали всех на первую встречу по проекту, объявили о старте проекта, распределили кто и чем будет заниматься; - вы заранее сформировали команду, провели совместно подготовительные работы, сработали взаимодействие друг с другом, полностью и подробно обсудили как будет происходить взаимодействие, что на каких этапах проекта будет требоваться от каждого, обсудили вопросы каждого участника.

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

А именно на первом этапе согласуются какие настройки в системе должны быть выполнены, детально описываются функциональные разрывы, формируются детальные требования к интеграции информационных систем, детально прорабатываются требования к инфраструктуре и безопасности. Если вы вышли к внедрению неподготовленными в плане процессов - плюс ко всему сбор данных по процессам, описание AS IS, анализ AS IS, формирование TO BE.

А если ещё и команда не подготовлена к внедрению, то вы приличную часть первого этапа занимаетесь не тем, что описано выше, а собираете команду и проводите рабочее слаживание. Ну и где же тут эффективная работа? А ведь все за нее так ратуют. Тогда может быть вместо чисто теоретических формул, расчета спорных показателей, спорах о том "палка - это явление безначальное или бесконечное" и прочего занимательного времяпровождения лучше сделать что-то практически полезное? Например, обследовать процессы (хотя бы AS IS), подготовить команду, проанализировать какие варианты ИС есть и как они покрываю ваши процессы, подготовить методику внедрения и т.д.

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