Практикум

Проблема масштаба

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

Организационные факторы.

• Пользователи системы.
• Пользователи результатов работы системы.
• Как система повлияет на существующие бизнес-процессы?

Факторы среды:

• Существующие ограничения по оборудованию и ПО.
• Интерфейсы интеграции с другими системами.
• Роль данной системы в контексте инфраструктуры ИТ-предприятия в целом.

Проблема понимания

Проблема понимания может возникнуть из-за следующих причин:

• Различия в уровне квалификации людей, участвующих в проекте.
• Термины и определения, используемые для описания потребностей.
• Структура документации, используемая для описания потребностей.

Изменения

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

Бизнес-процессы

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

Проект внедрения CRM обязательно будет связан с существующими бизнес-процессами в вашей компании. Какие-то из процессов нужно будет создать или перестроить. Консультантам потребуется собрать необходимую информацию для понимания и лучшего планирования ваших бизнес-процессов.

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

1. Выпишите список бизнес-процессов, которые будут связаны с планируемым внедрением и могут повлиять на него. Идентифицируйте каждый бизнес-процесс и подготовьте описывающую его формальную документацию. Имеет смысл рассмотреть те бизнес-процессы, в которых внедряемая система будет непосредственно использована, и те, которые, возможно, придется изменить после внедрения системы.
2. Определите участников проектной команды, которые будут авторизованы изменять ваши бизнес-процессы.
3. Изучите возможное влияние измененных бизнес-процессов на пользователей системы (кроме обучения по использованию ПО).
4. Пользователи могут испытывать сложности в понимании произведенных изменений.
5. Пользователи примут новый процесс, однако им может понадобиться дополнительное время для адаптации.
6. Пользователи смогут безболезненно воспринять новый процесс.
7. Оцените здраво, насколько процессы действительно соблюдаются. Постарайтесь быть максимально честными. Если процессы не соблюдаются — объясните, почему, или приложите другие документы по этой теме:
   • Процессы строго соблюдаются.
   • Процессы соблюдаются достаточно строго, однако время от времени отдельные шаги могут быть пропущены.
   • Процессы не соблюдаются достаточно жестко.
   • Процессы игнорируются (что часто означает наличие другого неформального процесса).

Рассматривая собственные бизнес-процессы, вы можете сформулировать "внутреннее понимание проблем", т.е. попытаться ответить на вопрос: "Что не так?" Например:

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

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

9.7. Формирование команды и выбор участников

Выбор участников проекта

Успех любого проекта зависит от квалификации и опыта определенной команды людей (а также от степени их концентрации на задачах проекта). Все участники команды должны быть заинтересованы в успехе. Они должны иметь возможность полагаться как на свой собственный опыт, так и на возможности других участников команды, чтобы совместно сформировать среду эффективного взаимодействия. Вопросы психологической совместимости могут играть в процессе построения эффективной команды принципиальную роль. Со своей стороны, формируя команду участников того или иного проекта, подрядчик выбирает тех сотрудников, которые могут выступать экспертами в данной отрасли, обладают необходимыми знаниями по функциональности систем CRM, а также способны управлять постоянно изменяющимися запросами.

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

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

Рассмотрим кратко основные элементы командной структуры проекта.