Бизнес-аналитика и система поддержки принятия решений в информационных технологиях

Каждый ИТ-проект включает в себя множество уровней, элементов, наборов действий, которые должны создавать процесс – от обнаружения до внедрения. Любой процесс или проект может провалиться из-за неотлаженных элементов.

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

Продать готовую ИТ-услугу сложнее, нежели продать канцелярскую ручку. Поэтому зачастую заказчики просят создать некий продукт специально под их нужды. В роли заказчика может выступать как обычный клиент (производство компьютерных игр для пользователей), так и бизнес в целом (разработка программного обеспечения для компании-заказчика) [1].

Бизнес-аналитика и система поддержки принятия решений в информационных технологиях

Селивонин Александр Евгеньевич аспирант Института информационных систем и инженерно-компьютерных технологий, Российский новый университет, Москва. Сфера научных интересов: системный анализ, бизнес-анализ, управление и обработка информации. Автор одной опубликованной научной работы. ORCID: 0000-0003-3251-3743.

Сбор бизнес-требований в ИТ-компаниях

Прежде всего, выстраивается сложная цепочка взаимодействия между заказчиком и компанией-исполнителем (стейкхолдером) [2]. Детально данный процесс можно представить в следующем виде.

• 1.    На первом этапе происходит общение между заказчиком и менеджером по продажам, который в данном случае собирает высокоуровневые требования к будущей системе. Эти требования передаются далее команде, и на их основе будет подготовлен ответ на запрос заказчика.

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

• 3.    Следующий этап – передача бизнес-требований бизнес-аналитику для грамотного описания технической документации, на основе которой разработчики сконструируют будущий продукт. Этот этап является основополагающим для создания решения, которым заказчик будет удовлетворен.

Иногда данный сценарий может быть сокращен только до сбора бизнес-требований бизнес-аналитиком от заказчика.

Функционал бизнес-аналитика

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

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

Бизнес-аналитик должен обладать следующими навыками:

• •    анализ бизнес-процессов , умение оценивать и описывать текущие бизнес-процессы в компании и выявлять проблемы и слабые места системы;

• •    моделирование бизнес-процессов . Бизнес-аналитик предлагает способы оптимизации и автоматизации бизнес-процессов для повышения эффективности [3] работы компании, и эта его функция получает всё большее применение в российских наукоемких компаниях;

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

• –    техническое задание (далее – ТЗ) – это документ, который содержит четкие конкретные требования и является основным документом для разработчиков;

• –    Userstory – это текст для пользователя, описание последовательности его действий, некий прогноз на действия пользователя в системе;

• –    Usecase – схож с Userstory, однако имеет вид диаграммы последовательности действий пользователя в системе или продукте, помогает создать общее видение продукта;

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

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

Роль бизнес-аналитика в проекте

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

Управление проектом и бизнес-анализ – это стратегические процессы, которые включают в себя различные точки зрения на проект. Управление проектом направлено на создание услуги, продукта или результата проекта для достижения конкретных целей. Операционный анализ фокусируется на понимании потребностей заинтересованных сторон и определении решений для удовлетворения этих потребностей [4].

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

Бизнес-аналитик также может проводить обучение, чтобы помочь пользователям лучше понять и наиболее эффективно использовать продукт.

Бизнес-аналитика и система поддержки принятия решений в информационных технологиях

Этап написания технического задания, этап разработки – всё это требует сложных программных решений. Atlassian, 1C, SQLOracle, CRM – это своего рода компоненты экспертных систем, помогающие эксперту правильно структурировать, анализировать данные и принимать на их основе решения.

Связь экспертных систем с ИТ

В крупных ИТ-компаниях аналитика не заканчивается на уровне анализа и написания технического задания. На регулярной основе требуется анализировать рынок, изучать потребительское поведение, строить бизнес-модели и бизнес-процессы, делать прогноз [5] на будущий продукт, отталкиваясь от того, что сейчас в тренде, что интересует потребителя.

Одним из ключевых в ИТ-компаниях является отдел BI (Business Intelligence), или, другими словами, отдел бизнес-аналитики. BI-аналитик занимается сбором, анализом и представлением большого объема данных по бизнесу для руководства компании.

Если компания только начинает развиваться, возможно, данного отдела еще нет, и тогда заказчик обращается к сторонним фирмам, занимающимся предоставлением инструментов или услуг по анализу рынка, – так называемым консалтинговым компаниям.

Бизнес-аналитик пользуется набором программ и систем для исследования и прогнозирования рынка, принимает обоснованные бизнес-решения, опираясь на собранные бизнес-данные (статистику, опыт, примеры, прогнозирование). Например: компания собирается запустить новый продукт, и перед аналитиком ставится задача – просчитать все риски. Бизнес-аналитик анализирует имеющиеся данные и выдает результат, что этот продукт может быть интересен аудитории, разработка будет стоить энное количество денег, есть такие-то конкуренты и др. Данный результат представляется в виде инфографики, презентаций, отчетов или бизнес-планов. Такая работа является исследованием и поиском пути для бизнеса.

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

Также в BI-отделе имеются разработчики. BI-разработчик создает инструменты, с которыми работает аналитик. Так как BI-разработчик постоянно работает с данными, а данные хранятся, как правило, в реляционных базах, то необходимо знать язык SQL для управления данными, иметь понимание корпоративного хранилища данных, моделей данных, ETL, OLAP и др. Разрабатываемые инструменты являются экспертными системами, или системами поддержки принятия решений (далее – СППР), которые помогают выполнить сбор данных, а также их анализ. На основе таких данных СППР составляет план, который может быть использован на дальнейших стадиях разработки предполагаемого продукта.

Архитектура СППР

Построение СППР основывается на четырех ключевых элементах:

• 1.    пользовательский интерфейс. Является основным компонентом СППР. Через него пользователи получают доступ к аналитике веб-портала;

• 2.    сервер и конструктор рабочей панели. Это основной компонент BI-платформы для создания интерактивных отчетов на основе собранных данных из различных источников: учетных систем, различных систем управления базами данных (далее – СУБД), систем обработки Big Data, а также данных, собранных вручную через Excel;

• 3.    аналитическая СУБД. Представляет собой набор данных, организованных для легкого доступа и анализа. Большие базы данных масштаба предприятия часто называют хранилищами данных, или витринами данных;

• 4.    модуль сбора данных. Заменяет таблицы Excel на легконастраиваемые веб-формы, которые бесшовно интегрированы с аналитической системой, позволяют рассматривать различные срезы данных, выявлять тренды и зависимости по выбранным критериям [6].

Классификация СППР

В своей книге «Системы поддержки принятия решений» [6] Дэниэл Пауэр классифицирует СППР по следующим признакам:

• •    управляемые моделями (Model-Driven DSS). Их отличительной особенностью является использование ограниченных по размерам наборов данных и параметров. Их объем не должен превышать объем, необходимый для создания репрезентативной модели, требуемой для анализа финансовой или экономической ситуации. Является верхнеуровне-вой системой (здесь и далее см. Рисунок). Примерами таких систем являются OLAP, GIS;

• •    управляемые документами (Document-Driven DSS). Такие системы обеспечивают поиск, выделение и классификацию в неструктурированных тестовых документах. Являются системами среднего уровня. Такими системами обычно являются системы интеллектуального анализа текста (Textmining), HTML, TXT, PDF;

• •    управляемые знаниями (Knowledge-Driven DSS). Они могут давать пользователю полезные рекомендации или определенные указания, делать предположения, основываясь на правилах бизнеса и базе знаний. Также являются системами среднего уровня. Пример – экспертные системы [7];

• •    управляемые данными (Data-Driven DSS). Обеспечивают доступ и прием больших баз структурированных данных. Являются системами нижнего уровня, к ним относятся EIS, хранилища;

• •    управляемые сообщениями (Communication-Driven DSS). Поддерживаются разнообразными технологиями групповой работы. Также являются системами нижнего уровня. К ним относятся видео-конференц-связь, электронная почта.

Каждый из этих типов в равной мере применяется в работе бизнес-аналитика.

Схематично классификацию СППР можно представить следующим образом (Рисунок 1):

Бизнес-аналитика и система поддержки принятия решений в информационных технологиях

Рисунок 1. Классификация СППР

Источник: схема выполнена автором.

Существующие проблемы СППР

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

Системы не идеальны, они не могут существовать сами по себе [8]. В любой момент может произойти разрушение баз данных, появиться малозначительный или серьезный баг, приводящий к блокировке пользования системой, что потребует скорейшего его устранения. Для таких случаев необходима команда поддержки существующей системы, оперативно решающая возникшие проблемы. Всё это также сказывается на работе аналитика с системой принятия решения и на бизнесе в целом, так как отнимает бюджет, который уходит на поддержку СППР.

Что касается дополнительных проблем использования СППР, то к ним можно отнести следующие:

• •    высокая стоимость;

• •    необходимость в наличии подготовленного специалиста;

• •    высокая неопределенность или неточность конечных результатов планирования;

• •    отсутствие свободного описания проблемы и четкой структуры и другие.