Практикум

9.8. Планирование проекта и отчетность

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

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

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

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

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

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

За счет использования плана-графика проекта достигается следующее:

• Управление взаимодействием между участниками проектной команды, согласование с высшим руководством.
• Определение потенциальных проблем заранее, чтобы найти наиболее дешевые и эффективные способы их решения.
• Помощь специалистам подрядчика и заказчика в планировании времени участия своих сотрудников на проекте, чтобы заранее предусмотреть отпуска, праздники и другие конфликты расписаний.
• Четкий расчет необходимых ресурсов заказчика и подрядчика для решения поставленных задач, контроль ответственности — кто отвечает за какие задачи, и какие ресурсы при этом задействованы.
• Формализация процедуры сдачи-приемки результатов работы.

9.9. Основные этапы внедрения

Проект внедрения системы CRM состоит из следующих основных этапов (некоторые могут осуществляться параллельно):

1. Планирование внедрения:
   • Встреча по запуску проекта (Kick-Off Meeting).
   • Сбор требований бизнес-пользователей.
   • Создание структуры разделения работ.
   • Разработка обобщенного плана-графика проекта.
   • Утверждение детального описания объемов работ.
2. Определение потребностей и дизайн-системы:
   • Разработка и документирование архитектуры системы высокого уровня.
   • Разработка и документирование модели данных.
   • Разработка и документирование представлений (экранов) приложений — контрагенты, контакты, потенциальные сделки, и т.д..
   • Определение пользователей и их прав доступа.
   • Разработка и документирование формата интеграции с существующими информационными системами.
   • Анализ и совершенствование модели данных.
   • Разработка и документирование схем конвертации данных (логическая привязка таблиц и полей данных в интегрируемых системах).
   • Утверждение окончательной документации по архитектуре системы.
3. Конвертация данных:
   • Разработка детальной схемы конвертации данных.
   • Разработка скриптов импорта.
   • Разработка скриптов очищения/переформатирования данных (в случае необходимости).
   • Осуществление конвертации данных.
   • Проверка правильности конвертации данных.
   • Запуск механизма резервного копирования данных.
   • Утверждение результатов конвертации.
4. Установка и развертывание системы:
   • Конфигурация серверов, сети, установка системного ПО.
   • Установка СУБД.
   • Установка сервера синхронизации данных (в случае необходимости).
   • Установка альфа-версии доработок и вновь разработанных компонентов.
   • Установка конвертированных данных.
   • Тестирование альфа-версии доработок и компонентов.
   • Конфигурирование системы для бета-тестирования пользователями.
   • Запуск в работу первой группы пользователей.
   • Утверждение окончательных версий приложений.

Встреча по запуску проекта (Kick-Off Meeting)

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

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

Во время встречи по запуску проекта решаются следующие вопросы:

• Обсуждение конкретных целей, которых данный проект должен добиться.
• Разработка планов и графиков реализации.
• Распределение обязанностей и выделение ресурсов.

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

План-график проекта

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

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

Определение функциональных требований

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

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

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

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

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

Доработки системы CRM

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

Каждая доработка документируется и утверждается прежде, чем начинается ее реализация. Каждое изменение исходной системы сопровождается оценкой по объемам ресурсов, а также временным диапазоном, необходимым для реализации и тестирования данной функции. Форма документирования доработки включает следующие параметры:

• Краткое описание требуемого изменения.
• Пример экранной формы, шаблона отчета или другой материал, который лучше описывает необходимое изменение.
• Ранг приоритета данного изменения.
• Оценка необходимых ресурсов для реализации (в человеко-днях).
• Оценка стоимости (если применимо).
• Оценка возможного влияния на план-график проекта в целом.

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

Мы уверены, что лучший способ создания хорошей системы — постоянный контакт с конечными пользователями этой системы в процессе внесения в нее доработок и изменений. Когда задача по доработке утверждена и запущена в работу, специалист вносит соответствующие исправления в систему и сразу же представляет их пользователям для получения от них обратной связи. Часто требуемые изменения могут быть внесены за считанные минуты и сразу же на месте представлены для рассмотрения, если встроенный инструментарий архитектурного проектирования (такой, как SalesLogix Architect или Siebel Tools) позволяет это сделать. Таким образом, пользователям предоставляется возможность участвовать в процессе построения системы еще до обучения ее использованию.

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

Конвертация данных

Одним из видов сервиса, предоставляемого компаниями-интеграторами, является конвертация существующих данных в новую систему. Многолетняя история работы с клиентами может представлять собой довольно большой массив данных, который вы захотите частично или полностью конвертировать в систему CRM. Чем больше информации должно мигрировать из старых форматов в новую систему, тем дольше может длиться процесс внедрения. В рамках проекта компания-интегратор обычно осуществляет конвертацию всей информации о существующих и потенциальных клиентах, которая имеется в структурированном электронном виде. Эта информация обычно включает как минимум имена клиентов, их адреса, типы, номера телефонов и факсов, ключевые контакты. Если информация недоступна в электронном виде, можно ввести вручную данные о 20% лучших клиентов, которые создают наибольший объем бизнеса для вашей компании. Для этой цели можно использовать временного сотрудника. Информация о других клиентах может быть введена позже, по мере необходимости.

Если информация о клиентах существует в электронном формате, она обычно может быть конвертирована в формат любой CRM-системы. Наиболее удобным форматом файлов для конвертации является "текст, разделенный запятой" (*.csv). Большинство программ для управления контактной информацией — такие, как Microsoft Access, Excel предоставляют данную опцию для экспорта.

Также возможно подключить данные напрямую через таблицы удаленной базы данных, такой как Access, Oracle или Microsoft SQL. В дальнейшем эти связи между таблицами можно использовать для импорта данных.

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

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

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