<<
>>

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

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

материалы, внутренние регламенты и процедуры или другие документы по вашей компании и индустрии в целом.

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

Все требования можно условно разделить на функциональные и не­функциональные.

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

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

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

| Недвусмысленные.

| Полные.

| Необходимые.

| Измеряемые.

| Целостные.

| Изменяемые.

| Отслеживаемые.

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

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

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

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

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

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

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

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

| Поиск фактов.

| Сбор информации.

| Интеграция информации.

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

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

2. Собрать «листы пожеланий» от каждого из заинтересован­ных участников. Вполне вероятно, что эти списки могут содер­жать противоречия, двусмысленность, излишние и ненужные требования.

3. Документировать и переработать «листы пожеланий». После пере­работки они не должны быть слишком детализированы, но скон­центрированы на решении проблемы и изложены в единой терми­нологии.

4. Интегрировать все пожелания в единый список. Разрешить воз­никшие конфликты требований и несоответствия между различ­ными точками зрения.

5. Определить нефункциональные требования.

6. Согласовать требования с клиентом (получить авторизацию).

7. Создать документ с описанием требований.

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

| Проблема масштаба — требования содержат или слишком много,

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

| Изменения — постоянно меняющиеся требования.

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

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

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

| Пользователи системы.

| Пользователи результатов работы системы.

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

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

| Существующие ограничения по оборудованию и ПО. | Интерфейсы интеграции с другими системами.

| Роль данной системы в контексте инфраструктуры ИТ-предприятия

в целом.

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

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

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

| Термины и определения, используемые для описания потребностей.

| Структура документации, используемая для описания потребностей.

Изменения

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

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

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

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

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

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

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

2. Определите участников проектной команды, которые будут авто­ризованы изменять ваши бизнес-процессы.

3. Изучите возможное влияние измененных бизнес-процессов на пользователей системы (кроме обучения по использованию ПО).

4. Пользователи могут испытывать сложности в понимании произве­денных изменений.

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

6. Пользователи смогут безболезненно воспринять новый процесс.

7. Оцените здраво, насколько процессы действительно соблюдают­ся. Постарайтесь быть максимально честными. Если процессы не соблюдаются — объясните, почему, или приложите другие доку­менты по этой теме:

| Процессы строго соблюдаются.

| Процессы соблюдаются достаточно строго, однако время от

времени отдельные шаги могут быть пропущены.

| Процессы не соблюдаются достаточно жестко.

| Процессы игнорируются (что часто означает наличие другого

неформального процесса).

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

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

Неправильно

Правильно

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

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

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

Неправильно

Правильно

Предоставить инструмент для конфигурации заказа в соот­ветствии с существующими правилами

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

<< | >>
Источник: Черкашин Павел Александрович. Готовы ли Вы к войне за клиента? Стратегия управления взаимоотношениями с клиентами. 2004

Еще по теме 9.6. «Домашнее задание»: подготовка к запуску проекта Знание бизнеса:

  1. 16. КОМПЬЮТЕРНЫЕ ПРОГРАММНЫЕ ПРОДУКТЫ, ИСПОЛЬЗУЕМЫЕ ПРИ ПОДГОТОВКЕ И АНАЛИЗЕ БИЗНЕС-ПЛАНОВ ИНВЕСТИЦИОННЫХ ПРОЕКТОВ
  2. Запуск своего бизнеса
  3. Запуск бренда и запуск товара — не одно и то же
  4. Разработка бизнес‑плана запуска и развития франчайзинговой системы
  5. 9.4. Подготовка проекта
  6. Подготовка и структура проекта нововведений
  7. УПРАВЛЕНИЕ ДОМАШНИМ БИЗНЕСОМ
  8. 2.3. Предварительная подготовка проекта
  9. 3.5. Реализация решения о внедрении бизнес-планированияОпыт подготовки общекорпоративного бизнес-плана на год (1996-1999 гг.)
  10. Управление проектом технической подготовки производства
  11. 12. РАЗДЕЛЫ БИЗНЕС‑ПЛАНА «ОКРУЖЕНИЕ И НОРМАТИВНАЯ ИНФОРМАЦИЯ», «РИСКИ ПРОЕКТА И СТРАХОВАНИЕ», «КАЛЕНДАРНЫЙ ПЛАН РЕАЛИЗАЦИИ ПРОЕКТА»