Документирование бизнес-требований подразумевает формирование документа, который должен быть согласован с заказчиками и, возможно, оценен специалистами в области реализации.
Из чего этот документ будет состоять?
Большую часть его элементов мы с вами уже рассматривали.
- Формулировка задачи. В отдельных случаях постановка задачи доступна нам сразу, однако в рамках бизнес-анализа мы, как правило, ее уточняем.
Итак, вопросы которые требуют небольшого пояснения:
Ресурсы:
Что имеется в наличии, чтобы помочь реализовать проект?
Существуют программные, аппаратные средства, материалы, шаблоны.
Очень часто команда, которая будет заниматься реализацией, не имеет представления о том, какие еще проекты были реализованы в этой области или, к примеру, реализуются параллельно.
И, соответственно, со стороны заказчика должны быть представители, которые обладают информацией о предметной области и могут сформулировать, какие еще существуют ресурсы, которые можно использовать для того, чтобы достичь целей проекта. Как правило, это — результаты каких-то смежных проектов или техническая документация.
Ограничения:
Каковы ограничивающие факторы для проекта?
Почти всегда есть 3 ограничения: время, бюджет, навыки пользователей. Как правило, ограничений больше, но эти 3 являются хорошей отправной точкой.
Ограничения — это те нюансы, аспекты, которыми бизнес ограничивает пространство решений для того, чтобы была возможность воспользоваться бизнес-результатами проекта.
И, как правило, туда входит время, бюджет …
Обязательно необходимо принять во внимание навыки пользователей, которые будут пользоваться нашей системой.
И другие ограничения. Например, в одном из проектов была ситуация, когда заказчик, создавая большое и сложное решение, ограничил перечень возможных использованных СУБД в связи с наличием определенных контрактов. Как бы проектировщикам не хотелось использовать другие решения, с учетом наличия этих ограничений, приходилось принимать их во внимание.
Список предположений:
Что мы предположили, когда готовили этот документ?
Предположения также должны быть проверены, так как любое предположение — это риск.
Раздел предположений, наверное, один из самых важных с точки зрения влияния, которое он имеет на дальнейшую работу в проекте. Список предположений — это наши гипотезы, в которых мы не были уверены, и исходя из которых мы сформировали документ.
Далеко не все вопросы могут быть разрешены с помощью целенаправленного исследования, или их разрешение стоит достаточно дорого.
В этой ситуации приходится делать некоторые предположения. Мы можем предположить, что какое-то оборудование будет доставлено к какому-то сроку. Или мы можем предположить, что какой-то проект, реализующий часть большой системы, с которой мы взаимодействуем, также будет реализован. Или, к примеру, мы можем предположить, что к моменту, когда будет сформировано какое-то подразделение, у него появятся какие-то конкретные требования.
Вся неопределенность, которую мы раскрываем не с помощью достоверной информации, а сделав некоторое предположение — это риски проекта. Если не реализуется какое-то предположение, то, скорее всего, и целостность наших требований, возможность достижения бизнес-результатов, окажется под угрозой. Поэтому это очень важный раздел, который часто забывают — перечень предположений, на которых мы основываемся для того, чтобы выдвигать и формулировать требования.
Итак, бизнес-требования — документ, который фиксирует решения уровня бизнес-среды, бизнес-системы с точки зрения того, какие задачи мы собираемся решить для того, чтобы достичь бизнес-целей. В этом документе не принято формулировать большое количество функциональных или детальных архитектурных решений, только те требования, которые определены бизнес-средой или контекстом системы, в которой она будет использована.
Источник: requirements.ru
Бизнес vs Функциональные требования
В техническом задании регистрируются как бизнес-требования к системе, так и функциональные требования:
— Бизнес-требования представляют собой описание того, ЧТО должна делать система на языке бизнес-пользователя. Бизнес-требования, в частности должны быть понятны руководителю, не имеющему технической подготовки и опыта.
— Функциональные требования представляют собой описание того, КАК те или иные действия осуществляются в системе. На этапе разработки технического задания функциональные требования обычно фиксируются только для наиболее сложных блоков проекта. Углубление в сложные зоны позволяет снизить риски при последующей оценке проекта. Обычно функциональные требования включают блок-схемы, диаграммы состояний, потоковые диаграммы, и дополняются макетами наиболее сложных экранов.
Пример бизнес-требования:
«Для рекламной кампании важно максимально точно отслеживать лимит показов, чтобы избежать финансовых потерь, связанных с показом баннеров сверх оплаченного лимита. Помимо этого, возникает задача ограничить показ одного баннера одному пользователю, например — не больше N раз в день».
Пример функционального требования:
«Для решения этой задачи [какой – см. выше] предполагается использовать внешний сервис, к которому баннерные сервера будут обращаться при каждом показе баннера. Поскольку данный сервис является точкой отказа, баннерные сервера должны корректно обрабатывать ситуацию когда внешний сервис недоступен или отвечает с задержками».
Обычно мы включаем
Техническое задание содержит описание ролей и основных пользовательских сценариев в разрабатываемой системе.
В случае с системой баннерной рекламы, мы выделим такой сценарий как создание рекламного места пользователем в роли Администратор.
Название сценария: Создание рекламного места
Роль: Администратор
Пример функционального требования:
«После добавления новой площадки в системе, администратор должен создать связанные с ней рекламные места. При создании рекламного места должны указываться площадка, тип места, поддерживаемый формат баннеров, размер, частота показов (для статических мест). После создания рекламного места оно становится доступным для менеджеров, размещающих рекламу.
Каждое созданное рекламное место получает универсальный идентификатор, который используется системой управления сайтом в запросе на показ баннеров. Для этого требуется внести соответствующие изменения в код страницы сайта».
Техническое задание содержит требования к интеграции разрабатываемой системы с другими внешними и внутренними системами, используемыми заказчиком.
В контексте технического задания на баннерную систему, это – интеграция с системами управления сайтом компании, биллинга, аутентификации и хранения данных пользователей.
«Система баннерной рекламы связана с тремя внешними модулями, функционирующими в окружении компании: системой управления сайтом компании, системой биллинга и системой аутентификации и хранения данных пользователей». Каждый показ баннера сопровождается запросом от системы управления сайтом к баннерной системе. Эти системы, кроме того, используют общие идентификаторы площадок и рекламных мест, а также согласованные имена параметров таргетирования».
В техническое задание мы обычно включаем глоссарий, разъясняющий значения специальных терминов, используемых в документе. Очень важно точно определить значение терминов, которые в дальнейшем используются в документе.
«Размещение (единица размещения, строка медиаплана) – это сущность, объединяющая баннер, который необходимо показывать, рекламное место, на котором будет показан баннер, а также правила показа. Правила показа определяют период размещения, параметры таргетирования, лимиты размещения, веса и т.п. Фактически, все рекламные кампании состоят из размещений».
Частота контакта – количество уникальных пользователей, посмотревших рекламный баннер определенное число раз. Например, частота контакта 5 – количество уникальных пользователей, каждый из которых посмотрел данный рекламный баннер не менее 5 раз. Частота контакта 1 = Охват.
Основные принципы
При написании ТЗ мы стараемся максимально использовать графические материалы для наглядного и сжатого представления информации. Одна диаграмма зачастую в состоянии заменить несколько страниц текста. В данном контексте, мы видим своей целью т.н. рисование ТЗ, т.е. представление всех более-менее сложных фрагментов системы в графическом виде и использование текста в качестве комментариев к графическим материалам.
У руководителей предприятий обычно нет времени на изучение многостраничных технических требований. Просмотр изображений даёт наглядное представление об основных характеристиках разрабатываемой системы. Как следствие, улучшается коммуникация между бизнес-пользователем и нами и растет качество самих требований.
Cледующая схема, иллюстрирующая структуру рекламных кампаний и взаимосвязь между основными понятиями в рамках рекламных кампаний, сэкономила нам несколько страниц текста.
По необходимости, мы используем в ТЗ прототипы избранных экранов системы (functional wireframes), которые, не являясь окончательными, демонстрируют базовый блок функциональности пользовательского интерфейса.
Вот такой прототип экрана редактирования рекламной кампании был включен в ТЗ на систему баннерной рекламы.
Источник: poisk-ru.ru
Технология выбора информационных систем
Технология выбора информационных систем
Вопрос выбора информационной системы очень важен — в статье представлена технология выбора информационных систем на базе опыта выполненных проектов.
Причины неудач проектов по внедрению корпоративных информационных систем
В настоящее время, выживание на рынке, создание конкурентных преимуществ, развитие бизнеса требуют от руководства предприятия принятия огромного числа решений, для чего сопоставляется и оценивается большой объем информации, полнота и достоверность которой зачастую оставляет желать лучшего. Не имея точной информации, большинство решений принимается на основании интуиции руководителей, и исправить ситуацию может внедрение современной корпоративной информационной системы (КИС), которая будет содержать необходимую информацию для принятия решений.
После принятия решения об автоматизации, необходимо ответить на следующие вопросы:
- Каким же образом выбрать систему в зависимости от целей и задач бизнеса и текущего состояния автоматизации?
- Как расставить приоритеты для задач, требующих автоматизации, и определить последовательность их решения?
- Будет ли эффект от внедрения превышать затраты на приобретение КИС?
Известно, что число неудачных внедрений корпоративных информационных систем достигает достаточно большого процента от общего числа внедрений. Очень часто основной причиной неудачи проекта внедрения является неправильный выбор, как самой системы, так и ее поставщика. На сегодняшний день основными заказчиками ИТ-решений являются крупные предприятия, но интерес средних компаний к внедрению информационных систем неуклонно растет, и если выбор КИС для первых во многом определяется масштабами бизнеса и ограничен лишь несколькими альтернативами, то для вторых выбор не столь однозначен.
В настоящее время на российском рынке представлено множество различных корпоративных информационных систем для промышленных предприятий, банков, страховых компаний и т.д. Все системы различаются по цене и функциональным возможностям. Кроме этого, некоторые, наиболее популярные системы, имеют нескольких поставщиков, внедренческие команды которых могут существенно различаться по профессионализму. Все это может привести к ошибкам при выборе корпоративной информационной системы и ее поставщика и отсутствию необходимого эффекта от автоматизации.
Если говорить об ошибках, возникающих при внедрении корпоративных информационных систем, то на первом месте находится отсутствие понимания целей проекта. Очень часто предприятие приступает к выбору и внедрению КИС, не имея четкого представления о желаемом результате автоматизации. В результате выбирается система, не способная поддержать стратегию развития предприятия, результатом чего является существенное превышение бюджета, сроков, отсутствие значимых результатов и потеря интереса со стороны руководства к информационным технологиям. При этом эффективность подобной КИС может быть отрицательной. Поэтому, при выборе информационной системы необходим подробный анализ стратегии предприятия, именно он должен являться отправной точкой при выборе.
На сегодняшний день многие предприятия страдают именно от того, что решения по вопросам, связанным с информационными технологиями, готовятся на уровне ИТ — подразделения, которое не учитывает требования бизнеса, как основного потребителя. Иногда руководство выбирает корпоративную информационную систему исходя из своего понимания бизнеса, что повышает риск того, что систему не удастся внедрить по техническим причинам (например, из-за недостаточной масштабируемости или совместимости с существующими ИТ — решениями).
Внедрение корпоративной информационной системы — это проект, который должен осуществляться в тесном сотрудничестве поставщика и собственных специалистов предприятия, внедряющих данную систему. От эффективности работы данной команды зависит успех проекта, причём инициативу во внедрении постепенно должны брать на себя собственные специалисты. Команда поставщика никогда не сделает проект только своими силами, либо эффект от внедрения будет на порядок меньше ожидаемого. С другой стороны, собственная команда специалистов мало эффективна без консультационной и технической поддержки поставщика.
Таким образом, еще одна ошибка связана с выбором поставщика, который будет осуществлять внедрение КИС. На настоящий момент времени немногие предприятия, внедряющие у себя информационные системы, имеют в своем штате высококвалифицированных специалистов по внедрению, поэтому обучение специалистов идет в ходе проекта. Но довольно часто команда внедрения поставщика также учиться в ходе проекта, а ведь внедрение даже самого совершенного ИТ-решения неопытным поставщиком может привести к большим финансовым потерям и отсутствию ожидаемого эффекта. Исходя из этого, необходимо тщательнейшим образом подходить к выбору поставщика, который должен иметь команду внедрения с опытом успешных проектов и эффективными методиками внедрения.
Технология выбора информационных систем — способ снизить риски
Зачастую даже внедрение корпоративной информационной системы, признанное успешным, дает эффект значительно ниже ожидаемого, причины в следующем:
- Цели внедрения КИС и пути их достижения четко не определены или меняются в ходе реализации
- Отсутствует стратегия развития информационных технологий или она не соответствует стратегии развития самого предприятия
- Топ-менеджеры предприятия не участвуют в проекте внедрения
- Управление проектами реорганизации предприятия и внедрения КИС не согласованы
- Отсутствие у компании квалифицированных специалистов для сопровождения информационной системы
- Не полное использование всех возможностей КИС
Естественно, что любое внедрение корпоративной информационной системы руководитель предприятия рассматривает как инвестиционный проект. Главный вопрос, который его интересует, — сколько это стоит и что это даст? Поэтому наряду с эффектом от внедрения очень важен вопрос и его стоимости. Необходимо определить, соответствует ли цена, уплачиваемая за автоматизацию, тому эффекту, который будет достигнут. Есть и еще один немаловажный момент — всегда существует объективный риск того, что проект внедрения не будет доведен до конца.
Таким образом, чтобы повысить вероятность успешного внедрения КИС, следует основательно подходить к процессу выбора информационной системы и её поставщика. Необходима технология выбора информационных систем. Это процесс требует глубокого понимания целей внедрения, требований к корпоративной информационной системе и к поставщику; высокой технической компетенции; знаний стандартов и классов систем (MRP II, ERP, CRM, EDMS и т.д.), а также рынка КИС (системы, поставщики). Сложность такого процесса приводит к тому, что все чаще предприятия обращаются в консалтинговые компании для осуществления профессионального выбора корпоративной информационной системы и поставщика, и минимизации следующих рисков проекта внедрения:
- Смена целей внедрения во время выполнения проекта;
- Ошибки в планировании проекта внедрения;
- Отсутствие грамотного технического задания;
- Отсутствие методологии внедрения;
- Неслаженной работы участников проекта (проектных групп);
- Информационных разрывов между модулями;
- Недостаточного документирования проекта внедрения;
- Несовпадение внедренного функционала заявленным требованиям;
- Нехватка ресурсов (персонал и финансы);
- Возможное неприятие новой системы большинством персоналом предприятия.
Развитие информационных технологий определяет стратегия предприятия
Обязательное требование к корпоративной информационной системе – поддержка стратегии развития предприятия, иначе выбранная КИС, будет препятствием для эффективного развития. Анализ стратегии дает систему целей предприятия, из которых выделяются цели внедрения информационной системы. Как правило, эти цели, могут формализовываться в виде концепции корпоративной информационной системы. Желательно, чтобы на этапе выбора концепция была уже разработана, поскольку в ней содержится большое число требований к КИС, имеющих наибольшее значение.
В случае отсутствия концепции, цели внедрения КИС должны определяться экспертным путем, с помощью проведения семинара с руководителями предприятия на этапе выбора системы. Важно понимать, что корпоративная информационная система – это не автоматизация отдельных локальных задач и подразделений, а создание единой информационной инфраструктуры предприятия, которая включает абсолютно все: создание коммуникационных каналов, единой методологии учета, единого программного обеспечения и единой базы знаний, позволяющей получать актуальную и объективную информацию.
Обычно уровень осознания требований к КИС индивидуален для каждого руководителя, но при обобщении, можно выделить четыре степени предварительной проработки целей автоматизации:
- Нужно все, вчера и желательно бесплатно;
- Требуется неизвестно что и неизвестно когда;
- Необходимо автоматизировать существующий бизнес-процесс (или несколько), существенно не изменяя их;
- Необходимо провести глобальные усовершенствования в рамках реорганизации бизнеса.
Исходя из стратегических установок необходимо формировать первичные требования к информационной системе, которые в дальнейшем дополняются по результатам анализа бизнес-процессов и инфраструктуры ИТ. Формализация и осознание целей внедрения КИС, взаимосвязанных с целями бизнеса является первым шагом на пути успешного внедрения.
Пример целей внедрения корпоративной информационной системы:
- Достичь финансовой прозрачности предприятия для Акционеров
- Увеличить стоимость и инвестиционную привлекательность бизнеса
- Поддерживать быстрый рост бизнеса
- Обеспечить оперативную информационную поддержку принятия управленческих решений
- Улучшить систему бизнес-планирования и бюджетирования
- Уменьшить средний уровень складских запасов, путем эффективного управления складами и логистикой
- Создать механизмы контроля над ключевыми бизнес-процессами и документами
- Достичь прозрачности жизненного цикла товара в информационной системе
- Поддерживать распределенную структуру бизнеса
Бизнес-процессы определяют функционал корпоративной информационной системы
После определения требований к информационной системе со стороны стратегии развития предприятия, которые будут носить достаточно высокоуровневый характер, необходимо провести определение требований со стороны бизнес-процессов, учитывающих как настоящую, так и перспективную деятельность предприятия. Для определения требований к КИС со стороны бизнес-процессов необходимо формализовать бизнес-процессы (чаще всего описываются бизнес-процессы верхнего уровня) для общего понимания специфики предприятия и выбора процессов для первоочередной автоматизации. Кроме того, для требований также необходимо определить их веса (т.е. степень значимости).
Зачастую предприятия при выборе системы и подготовке к внедрению сталкиваются с тем, что не могут определиться с очередностью автоматизации различных процессов. Бухгалтер заявляет, что без автоматизации его направления, жизнь предприятия остановится, государство «задушит» штрафами. Руководитель отдела кадров считает, что, поскольку кадры решают все, именно его подразделение необходимо автоматизировать в первую очередь. В этот спор вмешиваются службы маркетинга, сбыта, снабжения и т.д. Исходя из этого очень часто, основные требования к автоматизации собираются из процессов «Управление персоналом» и «Бухгалтерский учет», а это значит, что КИС будет выбрана под задачи данных процессов, хотя они являются вспомогательными процессами предприятия и не добавляют качества.
Если в первую очередь автоматизируются «второстепенные» работы, которые в большинстве своем не способствуют окупаемости КИС, но при этом требуют отвлечения финансовых и человеческих ресурсов, то нередко, оценивая эффект от подобной «информатизации», руководитель заявляет о полной бессмысленности проделанных работ. К тому же, такой подход делает дальнейшую автоматизацию основных процессов предприятия (Производство, Снабжение, Сбыт и т.д.) с помощью выбранной КИС невозможной, что очень часто приводит к замене системы на дальнейших этапах развития предприятия.
Все это говорит о том, что необходимо выявить «критичные бизнес-процессы» — это те бизнес-процессы в которых сосредоточены (или, в соответствии с тенденциями развития внешней и внутренней среды, будут сосредоточены в будущем) основные конкурентные преимущества предприятия. Если конкурентное преимущество предприятия — привлечение и удержание клиентов, то наиболее критичными становятся подсистемы сбыта, маркетинга и рекламы. Если же конкурентное преимущество — контроль эффективности использования финансовых ресурсов, то на первый план выходят процессы финансового управления.
В ходе анализа критичных бизнес-процессов может быть выявлено, что информатизация их достаточна для осуществления нормальной деятельности (информационная система, поддерживающая данные процессы, удовлетворяет текущим и перспективным требованиям), а основной задачей является, например, управление рекламными мероприятиями или маркетинговыми исследованиями. В этом случае может оказаться более эффективным использовать специализированные программные продукты, решающие подобные частные задачи, и интеграция их в существующую корпоративную информационную систему. В данном случае необходимо сформировать рекомендации по выбору информационных систем, содержащие оценку соответствия функционала системы процессам.
Технология выбора информационных систем — этапы
При выборе корпоративной информационной системы предприятия, как правило, ориентируются только на внешние признаки в общении с разработчиками – презентация, количество инсталляций, «громкость» имени и, конечно, стоимость. При этом остаются в тени вопросы функциональности и технической реализации, и, как следствие, ограничения в дальнейшей работе: отсутствие кроссплатформенности, способы и методы синхронизации данных, масштабируемость, возможность удаленной работы пользователей и многое другое. Производя выбор без понимания технических и функциональных параметров системы, можно совершить ошибку, которую в дальнейшем исправить без потерь будет невозможно.
Сам процесс выбора КИС является достаточно сложным и специфическим, а поэтому требует специальных знаний и значительного опыта работы в области бизнес-технологий. Кроме того, обращение Заказчика непосредственно к одному конкретному поставщику повлечет за собой проект по внедрению только той системы, которой обладает данный поставщик, независимо от того, насколько она подходит Заказчику по функциональности, рискам, стоимости и срокам внедрения.Использование независимой консалтинговой компании может являться наиболее правильным подходом для значительного снижения рисков проекта по выбору КИС.
Проект по выбору корпоративной информационной системы обычно включает следующие этапы работ:
1. Экспресс-диагностика предприятия – в рамках данных работ определяются цели внедрения КИС, и происходит их увязка со стратегическими целями предприятия. Затем формируется описание бизнес-процессов предприятия верхнего уровня, причем глубина описания должна быть достаточной для общего понимания специфики предприятия и обозначения процессов для первоочередной автоматизации;
2. Разработка требований к системе и к поставщику – в рамках данных работ определяются границы проекта внедрения КИС, уточняются описания наиболее критичных бизнес-процессов; проводится аудит ИТ-инфраструктуры и существующих на предприятии программных решений. Основываясь на полученных данных, формируются требования к системе и поставщику. Количество данных требований может варьироваться в широких пределах, и для крупных предприятий может составлять более 500. При работе с таким количеством требований необходимо их классифицировать по группам. Есть различные подходы к классификации, но необходимо обязательно отразить следующие группы требований:
- функциональные требования;
- технические требования;
- стоимостные требования;
- требования к поставщику.
Разделение требований на группы позволяет применять различные методики оценки к разным группам.
3. Определение участников тендера – в рамках данного этапа происходит сбор и актуализация информации по корпоративным информационным системам и поставщикам. В настоящее время достаточно тяжело получить объективную информацию о информационных системах, представленных на рынке. Количество КИС растет из года в год, заказчики путаются в понятиях и классификациях систем, пытаясь разобраться в ситуации. Но, тем не менее, ситуация не является безвыходной, и получить требуемую информацию все таки возможно.
Необходимо лишь грамотно подойти к вопросу сбора информации, поскольку 80-90% информации о состоянии рынка может быть получено путем анализа открытых источников информации на основе которых, в консалтинговых компаниях формируется база знаний по рынку ИТ — решений. Составляется перечень КИС принимаемых для рассмотрения в рамках проекта и затем по специально разработанным формам производится рассылка запроса информации поставщикам (RFI – request for information). Все ответы поставщиков анализируются на соответствие требованиям, выделенным на предыдущем этапе, и в результате формируется перечень участников тендера.
4. Организация тендера – в рамках данного этапа происходит организация и проведение тендера путем составления и рассылки поставщикам запроса коммерческого предложения (RFP – request for proposal), содержащего перечень требований к ИТ-решению, сбор и оценка коммерческих предложений с использованием специальной методики. Рекомендуется также «попробовать» как эти системы будут работать на реальных данных предприятия, для этого готовится контрольный пример (демонстрация по сценарию) или осуществляется «пилотное» внедрение на одном процессе (возможно, вспомогательном) предприятия.
Как правило, длительность проектов данного типа составляет от двух до шести недель, в зависимости от размера предприятия. Опыт проектов показывает, что данные сроки позволяют сформировать достаточные требования для выбора корпоративной информационной системы и осуществить ее обоснованный выбор. Большинство предприятий подходят к этапу выбора КИС, с разработанной стратегией развития и описанными бизнес-процессами, что облегчает работы по выбору информационной системы. Описанный подход к выбору КИС, как показывает наша практика, позволяет значительно снизить риски при выборе системы и существенно облегчить работы по внедрению.
Исходя из вышесказанного, можно отметить, что серьезный подход к выработке требований, выбору КИС и поставщику еще не дает 100% гарантии эффективного внедрения корпоративной информационной системы, но в тоже время существенно минимизирует основные риски проекта.
Б. Дружинин А.К. Коптелов
Источник: koptelov.info
