Дипломная (вкр): Формирование функциональных требований к CRM системе в сфере retail

В предыдущем разделе достаточно подробно были описаны перечни задач в рамках разработки требований, которые, очевидно, являются основополагающими для процесса управления требованиями. Второй фактор, от которого зависит этот процесс - тип организации-заказчика. В теории выделяют 3 основных типа[2]:

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

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

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

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

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

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

Сегодня для эффективного управления требованиями проектной команде необходимо иметь хороший инструментарий. На данный момент на рынке существует множество решений. Отметим наиболее распространенные из них: IBM Rational Requisite Pro, Telelogic DOORS, Borland Caliber RM, Redmine. Ниже приведена сравнительная таблица инструментов управления требованиями (см. Рисунок 17)

Рисунок 17 Сравнительная таблица инструментов управления требованиями

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

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

.        Наличие связей (трассируемость) между требованиями

.        Актуальность проектной документации

.        Хороший инструментарий

Сравнительный анализ методов разработки функциональных требований

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

Сравнительный анализ представляет собой матрицу (см. Таблица 9), в которой указаны методики сбора требований, методики анализа требований и аспекты, по которым можно их сравнить. Оценка проведена исключительно в разрезе теоретической знаний применимо к каскадной модели управления проектами. Вся таблица будет заполнена значениями «+», «-», «+/-». Далее представлены критерии разбалловки.

Ключевые показатели, по которым будет производиться оценка, следующие:

Для методик сбора требований: оценивается относительная затрата временных ресурсов на применение выбранной модели. Значение будет заполнено на основании критического анализа литературы, при временных затратах больше недели, ставится минус, иначе - плюс.

Для методик анализа требований: оценивается относительная затрата временных ресурсов на проведение данного метода анализа. Значение заполняется на основании теоритических данных. При относительно небольших временных затратах на применение методики ставится «+», иначе «-».

2.      Скорость получения результатов

Для методик сбора требований: оценивается скорость получения обратной связи от заинтересованного лица. При наличии личного контакта со стейкхолдером или наличии быстрого способа получения результатов, ставится «+», иначе «-».

Для методик анализа требований: оценивается скорость понимания методик анализа со стороны заказчика и предоставление замечаний/ комментариев/ обратной связи по ним. В случае относительной скорости описанного процесса ставится плюс, иначе - минус.

3.      Бюджетность

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

Для методик анализа требований: для оценки применяется теоритическое обоснование относительной затратности того или иного метода анализа. При высоких затратах временных ресурсов и теоретическим подтверждением больших денежных затрат ставится «-», при относительно низких затратах временных ресурсов и теоретическим подтверждением низкого уровня денежных затрат, ставится «+».

4.      Фокус на функциональных требованиях

Для методик сбора требований: оценивается применимость выбранного метода для прояснения функциональных требований. Если метод применим, ставится плюс, если же нет - минус.

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

5.      Достоверность и качественность получаемой информации

Для методик сбора требований: оценивается качество предоставляемой информации. Если предоставляемая информация является недостаточной для прояснения функциональных требований, или недостоверной ввиду отсутствия мотивация заинтересованных сторон - ставится «-», иначе «+».

Для методик анализа требований: Если предоставляемая информация является недостаточной для прояснения функциональных требований, или недостоверной ввиду отсутствия мотивация заинтересованных сторон - ставится «-», иначе «+».

6.      Личный контакт с заинтересованным лицом

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

Для методик анализа требований: не применимо (не может являться отрицательной или положительной характеристикой исследуемого метода)

7.      Применимость на опасных производствах

Для методик сбора требований: если выбранная методика сбора не несет опасности для здоровья и жизнедеятельности при применении её на опасных производствах, то ставится «+», иначе «-».

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

8.      Выявление пропущенных функций

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

Ячейка заполняется значением «+/-» в случае, если на критерий влияет внешняя среда, в зависимости от который, результат может смениться как на плюс, так и на минус.

9.      Отсутствие ограничений

Для методик сбора и анализа требований: если метод сбора или анализа требований подразумевает под собой использование специализированного ПО, привлечения специалистов другого профиля, то ставится «-», иначе «+».

Таблица 9 Сравнительный анализ методик сбора и анализа функциональных требований

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

2. Практическое исследование

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

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

·        Входит в ТОП-10 крупнейших консалтинговых фирм в России

·        Компанией реализовано более 300 проектов по внедрению ИТ -систем различного уровня

·        Компания «Техносерв Консалтинг» сертифицирована по системе менеджмента качества на соответствие международному стандарту ISO 9001:2008

·        Компания завоевала титул «Интегратор года» в национальном конкурсе программ лояльности Loyalty awards в 2014 г.

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

2.1 Исходные данные проекта

Название проекта: Реализация единого Операционного CRM для 3 торговых сетей

Исполнитель работ: ООО «Техносерв Консалтинг»

На момент начала проекта у компании XXX существовала система лояльности, к которой были подключены две торговые сети из трех, которая перестала отвечать бизнес-требованиям заказчика, и была недостаточно гибкой, для того, чтобы подключить к системе лояльности одну из самых быстроразвивающихся сетей группы компаний.

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

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

Реализация проекта производится для 3х торговых сетей, которыми управляет организация-заказчик.

Согласно уставу проекта в зону ответственности бизнес-аналитика входит:

·        Выполнение работ по разработке и документированию бизнес и функциональных требований к проектным решениям;

·        Разработка документации к системе;

·        Участие в обучении пользователей работе с системой.

2.2 Сбор и систематизация информации о процессе разработки функциональных требований

Определение заинтересованных сторон

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

Список стейкхолдеров был определен на этапе предпроектного исследования и внесён в документ «Устав проекта». Список заинтересованных лиц проекта и их зоны ответственности см. Приложение А.

Методика сбора и анализа требований

Формирование функциональных требований - итеративный процесс. Требования фиксируются один за другим, детализируются и помещаются в общую структуру. Как уже упоминалось выше, требования могут формироваться из различных источников. В случае исследуемого проекта в рамках тендера заказчиком были предоставлены верхнеуровневые требования, из которых были выявлены бизнес-требования, схемы основных бизнес-процессов и сценарии AS IS (см. Приложение Б), касающихся сферы лояльности. Уже на основании этих источников формируются и анализируются функциональные требования к внедряемой системе лояльности. Функциональный охват исследуемого проекта приведен на схеме ниже (см. Рисунок 18):

Рисунок 18 Функциональный охват исследуемого проекта

В случае «Техносерв консалтинг» методиками сбора функциональных требований были определены:

·        Проведение совместных семинаров (workshop) на протяжении всего этапа анализа

·        Опыт работы с аналогичными системами

·        Документации предшествующей системы

·        Изучение видеозаписей работы персонала в аналогичной системе

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