Практикум

Подход, который приносит результаты

Поставщики, которые действительно заинтересованы в вас как клиенте, представят развернутый ответ в кратчайшие сроки. Подобный подход позволяет сузить круг потенциальных решений с десятков до единиц. Практический опыт показывает, что составление квалифицированного списка вопросов и правильная обработка результатов позволяет просеять 30–40 поставщиков и выбрать из них 3–4 в течение недели.

Когда количество поставщиков, составляющих "короткий список", не превышает 3–4, с ними можно организовать более тесное и конструктивное взаимодействие. В частности, можно подписать Соглашение о конфиденциальности, разослать технические спецификации и бизнес-требования, а также расширенный список квалификационных вопросов, который иногда может включать до 100 пунктов.

Примерный список критериев выбора решения CRM

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

• Соответствие запрашиваемой функциональности (50%)

  Составить полный список необходимых функций с указанием приоритетов (или этапов) и сложности реализации — shopping list.

  Попросить поставщиков указать, какие из функций входят в базовую функциональность, какие требуют доработки.

  Сделать сквозной анализ каждой функции.
• Цена решения (30%)

  Разброс цен может быть огромным — от $5000 до $500 000 за один и тот же набор функциональности.

  С поставщиками можно и нужно торговаться.
• Общая стоимость владения (10%)

  Исходная цена решения — только 20–30% от общей стоимости владения.

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

  Какие гарантии дает поставщик?
• Масштабируемость (5%)

  Что будет с предлагаемым решением через 2–3 года, когда ваш бизнес вырастет? Какие сценарии предлагает поставщик?
• Опыт применения в России (5%)

  Кто уже использует решение в России, и насколько эффективно? Можно ли организовать визит к существующему клиенту?

9.6. "Домашнее задание": подготовка к запуску проекта

Знание бизнеса

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

Формализация и анализ требований

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

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

Детальные спецификации — это то, что можно характеризовать следующими параметрами:

• Недвусмысленные.
• Полные.
• Необходимые.
• Измеряемые.
• Целостные.
• Изменяемые.
• Отслеживаемые.

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

Главная цель процесса определения требований — снабжение проектной команды объективной и целостной информацией для составления плана-графика проекта и функциональных требований к системе.

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

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

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

Так как каждый проект всегда уникален, не существует готовой "книги рецептов" для определения требований. Каждый проект требует собственной стратегии для этого процесса в соответствии со спецификой вашей компании.

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

Следует мысленно разделить процесс определения своих целей на три основных этапа:

• Поиск фактов.
• Сбор информации.
• Интеграция информации.

Эти три этапа можно разделить на следующие основные шаги.

1. Определить заинтересованных участников, которые могут служить источником требований. Таким источником может быть конечный пользователь, интерфейс другой системы или внешний партнер.
2. Собрать "листы пожеланий" от каждого из заинтересованных участников. Вполне вероятно, что эти списки могут содержать противоречия, двусмысленность, излишние и ненужные требования.
3. Документировать и переработать "листы пожеланий". После переработки они не должны быть слишком детализированы, но сконцентрированы на решении проблемы и изложены в единой терминологии.
4. Интегрировать все пожелания в единый список. Разрешить возникшие конфликты требований и несоответствия между различными точками зрения.
5. Определить нефункциональные требования.
6. Согласовать требования с клиентом (получить авторизацию).
7. Создать документ с описанием требований.

Избегайте следующих "классических" проблем при анализе потребностей:

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