Знайте свои цели
Исследования в США и Европе показали, что неспособность сформулировать конкретные ожидания остается главной причиной провала стратегических инициатив в области CRM. Даже в условиях экономической стагнации и жесткой экономии в списке причин задержек при внедрении «прекращение финансирования» стоит за «отсутствием четкой стратегии».
Решение этой проблемы начинается в процессе первичного отбора возможных систем. В запросе на предложения необходимо сразу постараться сформулировать основные критерии оценки эффективности проекта — такие, как увеличение продуктивности работы (насколько?) и возврат инвестиций (в каком объеме?). Вы можете спросить поставщиков, как они помогут в соблюдении этих критериев, а также попросить рекомендации клиентов, которые использовали эти системы для достижения похожих целей. Это возымеет значительно больший эффект, чем выбор системы на основе списка функциональности.
Как это ни странно, сформулировать практичные и достижимые цели проекта в большинстве случаев бывает довольно сложно, особенно когда речь идет об автоматизации сначала. Записав две-три избитые фразы: «Увеличить объем продаж» или «Оптимизировать процесс прохождения сервисных заявок», менеджер часто впадает в глубокое раздумье — в какой мере информационная система сможет обеспечить такие результаты? Как определить — действительно ли увеличение продаж произошло благодаря внедрению системы или просто имело место сезонное колебание?
Если вы никогда раньше не участвовали в процессе сбора и формализации требований, вам будет трудно четко и однозначно сформулировать задачи автоматизации. Тем не менее, существует много источников, которые могут помочь в выполнении этого «домашнего задания». Приведем основные принципы по организации процесса формализации собственных требований.
Следует мысленно разделить процесс определения своих целей на три основных этапа:
< поиск фактов;
< сбор информации;
< интеграция информации.
Эти три этапа можно разделить на следующие основные шаги:
> Определить заинтересованных участников, которые могут служить источником требований. Таким источником может быть конечный пользователь, интерфейс другой системы или фактор внешней среды.
> Собрать «лист пожеланий» от каждого из заинтересованных участников. Вполне вероятно, что эти списки могут содержать противоречия, двусмысленность, излишние и ненужные требования.
> Документировать и переработать «листы пожеланий». После переработки они не должны быть слишком детализированы, должны быть сконцентрированы на решении проблемы и изложены в единой терминологии.
> Интегрировать все пожелания в единый список. Разрешить возникшие конфликты требований и несоответствия между различными точками зрения.
> Определить нефункциональные требования.
> Проверить требования с клиентом (получить авторизацию).
> Создать документ с описанием требований.

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

Компания будет лучше подготовлена к запуску проекта внедрения, если вы выполните следующие шаги на этапе определения своих задач и потребностей:
> Выпишите список бизнес-процессов, которые будут связаны с планируемым внедрением и могут повлиять на него. Идентифицируйте каждый бизнес-процесс и подготовьте описывающую его формальную документацию. Имеет смысл рассмотреть те бизнес-процессы, в которых внедряемая система будет непосредственно использована, и те, которые, возможно, придется изменить после внедрения системы.
> Определите участников проектной команды, которые будут авторизованы изменять ваши бизнес-процессы.
> Изучите возможное влияние измененных бизнес-процессов на пользователей системы (кроме обучения по использованию ПО):
< пользователи могут испытывать сложности в понимании произведенных изменений;
< пользователи примут новый процесс, однако им может понадобиться дополнительное время для адаптации;
< пользователи смогут безболезненно воспринять новый процесс.
> Оцените здраво — насколько процессы действительно соблюдаются. Постарайтесь быть как можно более честными. Если процессы не соблюдаются — объясните почему, или приложите другие документы по этой теме:
< процессы строго соблюдаются;
< процессы соблюдаются достаточно строго, однако время от времени < отдельные шаги могут быть пропущены;
< процессы не соблюдаются достаточно жестко;
< процессы игнорируются (что обычно означает — существует другой неформальный процесс).
Рассматривая собственные бизнес-процессы, вы можете сформулировать «внутреннее понимание проблем», т. е. попытаться ответить на вопрос «Что не так?», например:
Неправильно: «Проект должен гарантировать, что продавец сможет аккуратно подобрать конфигурацию и предоставить заказчику четкую спецификацию для заказа».
Правильно: «Продавцы не могут аккуратно подобрать конфигурацию, что приводит к неточным спецификациям при заказе».
По мере того, как вы формулируете свои задачи и вам становятся понятны корневые проблемы в области бизнес-процессов, можно приступать к поиску путей их решения. Вы можете начать этот процесс еще до запуска проекта, а затем проектная команда со стороны интегратора сможет дополнить и исправить этот список. Констатация возможного решения не должна описывать задачи программного приложения или какие-либо другие детали — она должна четко определять, как необходимо подходить к решению этой проблемы.
Например:
Неправильно: «Создать приложение для продавцов, в котором они смогут выбрать конфигурацию и сформировать правильный заказ».
Правильно: «Предоставить инструмент для конфигурации заказа в соответствии с существующими правилами».
Не рассчитывайте, что вы сможете с первого раза составить детальный и целостный документ, однако хорошо выполненное «домашнее задание» существенно повысит ваш авторитет в глазах приходящих консультантов и снизит вероятность того, что вас обманут.