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

Непереводимая игра слов

Не стоит, наверное, зацикливаться на таком неудобном для перевода на русский язык и таком красивом в своем английском родном варианте названии этой технологии — Business Intelligence. В сети есть целые трактаты, посвященные поиску правильного аналога в нашем языке. К сожалению, практически каждый из них заканчивается словами: «По мнению автора, лучший аналог…», и далее по тексту употребляется то сочетание русских слов, выбору которого могло быть посвящено несколько абзацев, если не страниц убористого текста.

Но по собственному опыту могу судить, что в разговоре с представителями бизнеса еще несколько лет назад использование что оригинала, что любого из его подстрочных переводов заводило беседу на некоторое время в тупик. Потому что у любого человека, не окунувшегося с головой в ИТ, бизнес-анализ связывался с чем‑то не менее абстрактным, но очевидно не имеющим отношения к технологиям BI. Каждый раз требовался некий экскурс в тему, в результате которого всегда в глазах собеседника читалось легкое разочарование. Как, это не про анализ того, насколько интеллигентно работает мой бизнес? Как только ты его, это разочарование, видел, разговор можно было продолжать. Но требовались колоссальные усилия, чтобы опять зажечь повторную искру интереса собственно к тому, чему посвящена эта статья.

Я уж не говорю про составляющие этой технологии, которые на русском так и не нашли своего адекватного устоявшегося перевода. Для людей непосвященных все технологии, название которых невозможно ни понять без пространственных объяснений, ни перевести простым русским языком, — всякие там olap, data mining, кластеризация, dash-board — изначально вызывают отторжение. И, надо признать, в этом случае терминология с технологией бизнес-анализа сыграла злую шутку. Во всяком случае, на начальном этапе ее рас­пространения. Да и сейчас еще не все так радужно.

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

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

С чего все начиналось

У разных компаний могут быть разные причины начинать или не начинать применять BI. Мы подошли к этой идее уже достаточно давно, примерно лет семь тому назад. И основной причиной, основным побудительным мотивом была планировавшаяся ИТ-службой (вернее, только созревавшая в головах) смена одной учетной системы на другую как по причине морального ее старения, так и с учетом планов развития самой компании (опять же еще только витавшими в головах руководства).

То есть использование BI не было потребностью бизнеса, который даже не знал о том, что нечто такое существует. Пользователи терпеливо часами ждали готовности своих отчетов, кто как мог приспосабливаясь к таким условиям. Кто‑то запускал по несколько сессий учетной системы, кто‑то оставлял отчетность готовиться на ночь, кто‑то что‑то вел самостоятельно у себя в табличках Excel. Но в прин­ципе все более или менее были довольны своей жизнью. Поскольку не знали о другой. И именно в этом была причина первых трудностей, с которыми нам вскорости пришлось столкнуться.

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

Взяты были за образец лучшие практики, «настругано» с два десятка разных показателей и еще столько же измерений. Проделана масса работы для того, чтобы из модели учетной системы данные именно в таких измерениях уметь представить. Потому что оказалось, например, что канал сбыта «Розничный покупатель» — это не все покупки, оплаченные на кассовой линейке, а оттуда нужно разными хитроумными способами изъять часть выручки, которую следует отнести к другому каналу сбыта (в результатах работы которого, как вы правильно догадываетесь, было заинтереосвано другое подразделение компании).

Цель, в общем‑то, была благая. Оперативную отчетность оставить умирать вместе со старой учетной системой, поскольку неизбежность появления ее аналогов в новой очевидна. А вот ту часть, которая «не очень», которую условно можно назвать аналитической, переключить в будущем на новый источник данных. И таким образом высвободить свой ИТ-шный ресурс, сконцентрировав его использование на самом внедрении новой системы учета.

И благой цели мы достигли. Но…

Первые трудности

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

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

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

Очевидных недостатков для пользователей было не так много. Первый лежал на поверхно­сти — в кубах не было данных за текущий день. Удивительно, но с этим пользователь долго не мог смириться, с завидной регулярностью отправляя в службу поддержки вопросы типа: «А я не вижу таких‑то данных, я только что лично внес их в систему». Второй — это необходимость работать сразу с двумя системами, оперативной и аналитической.

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

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

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

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

Здесь я должен сделать вынужденное отступление, чтобы сказать пару слов о клиенте доступа к данными. Как вы понимаете, когда такая система строится самостоятельно, то решение лежит на поверхности. Это Microsoft Excel. Удобно, привычно, вопросы интеграции с хранилищем на базе Microsoft SQL Server уже решены за вас уважаемой компанией. Плюс Visual Basic как универсальное средство для собственного творчества. Но главный плюс, конечно же, в привычке и в каком‑то уровне умения пользователей с Excel работать. Так получились вместо свободных кубов заранее нарезанные и зафиксированные их срезы. Что касается второй проблемы, с доверием к данным, она не разрешена полностью и по истечении семи лет эксплуатации и развития системы. Причин здесь много, есть и объективные, и, опять же, не очень. Постараюсь их назвать в порядке, так сказать, степени озабоченности пользователей.

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

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

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

Ну и не буду обелять ИТ‑службу, бывают (хотя заявляю совершенно уверенно на основе уже многолетнего опыта эксплуатации — это последняя причина в списке по частоте возникновения) и ошибки в алгоритмах обработки данных. Особенно трудно поддерживать актуальность соответствия моделей между транзакционной системой и хранилищем, когда что‑то постоянно меняется в самом объекте автоматизации.

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

От аналитики в сторону оперативного учета

Учитывая нескончаемый поток запросов на тему «а почему?», пришлось задуматься о том, чтобы можно было, не прибегая к учетной системе, находясь в кубах, получить ответ на него, и желательно самостоятельно. Это некое подобие того самого drill-down, который должен быть неотъемлемой частью любой приличной BI‑системы. Однако здесь это не просто проваливание до исходных документов, а необходимость сопоставить одни документы с другими, поднять все ссылки между порожденными документами и представить все это пользователю в таком виде, чтобы он нашел свою потерянную рентабельность. Применительно к нашей компании это означало реализовать в аналитической системе всю логику партионного учета.

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

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

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

Дальше — больше. Если есть детальный анализ, то почему на этих данных не строить детальный прогноз и планирование? Скажем, не рассчитывать потребность в товаре, не формировать заявки поставщикам? При этом у вас всегда под рукой мощный инструмент, объясняющий, почему именно столько планируется продать /требуется заказать. А этот класс задач уж точно относится к оперативной работе. Не сможешь сформировать заказ поставщику — и все, не работает подразделение логистики, встала торговля.

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

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

Информационная безопасность

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

Пришлось решать вопросы разделения прав доступа к определенным наборам отчетов — коллекциям, на уровне которых и определяется их доступность группам пользователей, описанным в Active Directory. Понятно, что создавать самостоятельную систему описания и разграничения прав было бы очень трудозатратно, поэтому и привязались к уже имевшемуся в компании универсальному инструменту. Необходимо было только реализовать интерфейс с AD. Внешне для пользователя это выглядит как дополнительная надстройка в его Excel, в которой появляется список доступных ему отчетов. При выборе отчета его шаблон загружается непосредственно из хранилища, пользователю остается лишь задать его параметры и нажать кнопку «Обновить».

Следующим шагом в ужесточении правил доступа к отчетности стал полный перенос этого инструментария на серверы с терминальным доступом. Таким образом, работать с отчетностью стало можно, только находясь в корпоративной сети компании. При этом функция обычного копирования через Clipboard тоже была отключена. Это было жесткое, но необходимое ограничение. Однако, учитывая оперативный характер получаемой отчетности (и в первую очередь для сотрудников логистики), пришлось идти на определенные послабления. Нужно было иметь возможность доставать с терминального сервера получаемые в отчетах данные и отправлять их во внешний мир (пример — рекомендации для составления заявки поставщику). В результате поиска приемлемого варианта родилось решение, которое позволяет пользователю отправлять любой отчет себе на почту. Это, конечно, не уберегает коммерческие данные компании от их несанкционированного распространения, но как минимум оставляет в системе следы того, что данные были переданы в незащищенную зону, и сделано это было таким‑то сотрудником. А дальше дело уже сотрудников информационной безопасности следить за этим трафиком и задавать вопросы в случае неочевидного поведения пользователей. Еще одним шагом к ужесточению работы с коммерческими данными стал тотальный мониторинг печати на всех принтерах, на которые можно было вывести отчетность непосредственно с терминальных серверов (их в компании несколько, они обслуживают разные группы пользователей, балансируя таким образом нагрузку на систему в целом).

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

Элементы «сладкой» свободы

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

  • Во-первых, это стандартные механизмы задания параметров для анализа — выбор региона, подразделения, поставщика, временного интервала.
  • Во-вторых, это стандартизация цветовых и структурных подходов к формированию отчетности. Практически везде используются одни и те же правила и форматы представления одинаковых данных.
  • В-третьих, это механизм фильтрации данных, где при задании тех или иных значений фильтра автоматически пересчитываются довольно сложные агрегаты (еще раз прошу вспомнить, что мы оперируем уже не стандартным olap-отчетом).
  • В-четвертых, это различные сложные сортировки. Скажем, можно получить сквозной рейтинг продаж как по отдельным товарам, так и по группам товаров, входящих в ту или иную коллекцию. В результате пользователь имеет плоский список, в котором перемежается, например, выручка, получаемая от отдельных товарных позиций и от групп товаров, объединенных признаком вхождения в одну коллекцию.
  • В-пятых, это drill-down, реализованный как переход на отдельные листы Excel, на которых предоставляется та или иная детальная информация об интересующем объекте или цифре, включая демонстрацию графической информации. В некоторых отчетах есть даже такие изыски, когда эта детализация строится не на основе данных, загруженных в хранилище, а с обращением непо­средственно в учетную систему.
  • В-шестых, погружению в хранилище теперь подвергаются данные не только из учетной торговой системы, а из прочих учетных систем, которые эксплуатируются в компании. Таким образом, в одном отчете можно получить полные исчерпывающие данные о движении товара, о сальдо взаимоотношений с поставщиком, о текущих запасах товара в разных стадиях жизненного цикла его партий.

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

Основные проблемы создания BI‑системы

Какие проблемы остались нерешенными на сегодняшний день? Какие из них существенны? А что можно считать «прихотью» пользователя (да простят меня представители бизнеса за употребление таких слов)?

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

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

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

Третья — это вопрос взаимодействия пользователей с системой. Изначально предполагается, да и само название технологии к этому располагает (и тут мы возвращаемся к самому началу статьи), что пользователи — профессионально грамотны и понимают, что и зачем с этим делать, интеллектуалы, если не интеллигенты от бизнеса. К сожалению, на практике это далеко не так. Самому обучению, как основам, так и непосредственным методикам конкретной работы и анализу, нужно учить. Делать это профессионально и качественно, и, что немаловажно, на постоянном уровне. Всегда что‑то меняется — или сами пользователи, или модели представления данных (как в нашем случае, когда под прикрытием BI происходила смена учетной системы), или приоритеты в системе управления самой компанией. Далеко не все из пользователей погружены в эти процессы. Уровень знания о них у некоторых ограничивается «сплетнями в курилке», поэтому вопрос создания тренерской прослойки между любой ИТ‑системой и ее пользователями всегда должен иметь один из самых важных приоритетов.