Проблемы создания систем Business Intelligence

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

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

Мотивы и цели организации хранилищ данных и внедрения BI-приложений

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

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

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

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

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

И второй момент — это не только сама потребность в анализе, но и появление специалистов, способных формулировать свои потребности в аналитических инструментах. «Мы всегда различаем просто пользователей аналитических инструментов и тех, кто с их помощью будет производить информацию, — говорит один из участников круглого стола. — Тех, кто будет читать отчеты, много: это пользователи, и им создадут пред­установленные отчеты. А вот тех, кто будет сидеть и крутить кубы данных, очень мало. Чаще всего первые — это финансисты, те, кто готовит информацию высшему руковод­ству. Потому что им приходится перелопачивать горы данных и им нужен какой‑нибудь инструмент, чтобы можно было не 60 тысяч позиций загрузить, а миллион, потому что Excel не тянет. Они начинают говорить “давай, ставь чего‑нибудь такое, чтобы я больше ничего в Excel не делал”. Но количество людей, которым нужна такая система именно как инструмент для работы, очень небольшое».

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

Инициация BI-проектов

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

Мнение бесспорное. Однако как быть, если руководство не созрело? Ни в коем случае не идти на проект? Или при каких‑то условиях такие проекты могут инициироваться с подачи ИТ-директора? «Пытаться объяснить бизнесу, какие принципиальные выгоды могут принести системы информационной аналитики, большого смысла не имеет, — говорит один из ИТ-директоров. — Если бизнес не готов воспринимать подобные вещи, то убеждать его в этом не надо. Адекватного понимания скорее всего не будет, и даже если выделять деньги, скажем, на пилотный проект, при слабой востребованности бизнеса в аналитике вряд ли получится что‑либо практически значимое». Здесь потенциальная привлекательность данного типа решений может сыграть злую шутку, когда бизнес легко поддастся на пропаганду вне какой‑либо связи с реальным интересом со своей стороны. И ничем хорошим это не кончится.

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

Аналитики, естественно, его поддерживают. Однако это не простой путь, потому что глупости, к сожалению, случаются. Скажем, есть службы, которые занимаются традиционным анализом данных, они обрабатывают данные, проверяют (как правило, в Excel) и подают руководству. И вдруг рядом ложится отчет аналитической службы, в котором диаметрально противоположный результат. Кто прав? Такие вопросы можно устранить постоянным анализом качества информации. Причем он должен происходить как можно ближе к первичным источникам информации».

То есть мы опять приходим к тому же — вслед за таким «партизанским» проникновением BI-инструментов в компанию проявить инициативу должны первые руководители. Потому что все остальное будет «бесполезной пальбой в воздух», как выразился один из участников круглого стола. «Понаблюдав эти годы, как система “шарахается” в разные стороны, руководитель понимает, какую пользу из всего этого можно извлечь, и начинает формулировать цели, — продолжает один из участников круглого стола. — Вот мы сейчас на таком этапе и находимся. Сейчас совещания по этому вопросу проходят в очень конструктивном русле. Раньше это был сплошной крик и каждая служба доказывала, что ничего не может, ничего не получится. А теперь люди начали друг друга слушать, понимать и искать какие‑то пути решения».

Необходимые и достаточные условия для старта BI-проектов

В ходе круглого стола было сформулировано несколько необходимых и достаточных условий для старта BI-проектов.

1. Развитая система учета: все операции, которые проходят в компании, должны быть отражены в системе. «BI-проекты стоит инициировать только тогда, когда есть очень хорошая основа в виде реально внедренной и работающей ERP‑системы, — считает Владимир Королев, генеральный директор компании “Малахит”, осуществляющей проекты построения КИС в Группе ЧТПЗ. — Мы изначально исходили из принципа однократного ввода документа в систему, стараясь искоренить бумажный документооборот, и теперь информация в бумажной форме осталась только в бухгалтерии (из‑за требований законодательства). Все остальные документы существуют в электронном виде, накапливаются годами, и с содержащейся в них информацией можно делать то, что невозможно было бы сделать с бумажными архивами, — аналитику в каких угодно разрезах и представлениях. К примеру, на нашем предприятии еще 15 лет назад был введен в документы такой реквизит, как “код подразделения”. И когда мы приступили к внедрению системы бюджетирования, данный реквизит оказался исключительно востребованным».

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

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

Заметим, что организация процесса «очистки» данных для наполнения хранилища всеми экспертами отмечается как важнейший процесс. И согласно одному из мнений, в BI-проектах 80% времени уходит на извлечение и выверку данных. Однако часть участников круглого стола придерживалась более радикальной точки зрения — 80% времени на создание хранилища потратить на очистку данных неправильно. Гарантии того, что мы вычистим данные, нет. И следовательно, вообще не стоит затевать проект, если нет чистых данных. Причем это условие необходимое. Сначала надо разобраться с достоверностью данных в учетных системах, а потом уже обдумывать BI-проект.

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

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

Единое понимание целей

Аналогичный порядкок должен наблюдаться и с целями проекта. «Все попытки создать качественную BI‑систему без четко сформулированных целей обречены на провал, — замечает Наталья Сарапулова. — Если каждый выходит на проект со своей целью в голове, то ситуация будет напоминать известную басню Крылова про лебедя, рака и щуку». Если каждый выходит со своей целью, так решение и проектируется. Причем ситуация осложняется тем, что эта проблема очень трудно определяется и очень трудно понимается как причина неуспеха, — ведь никто таким анализом особо не занимается. «Большинство неудач в области внедрения и использования BI‑систем связано с ошибками в проектировании этих систем, — считает Любовь Перепелицына, советник заместителя генерального директора по ИТ ОАО «Сибур — Минеральные удобрения». Если в самом начале нельзя сформулировать требования к тем аналитическим данным, которые должны быть на выходе, то проект лучше вообще не начинать».

«BI‑системы — это все‑таки инструменты, обладающие, как правило, большими возможностями по генерации отчетов разнообразных форм и представлений, — говорит Алексей Комаров, начальник центра управления проектом BAAN “Северсталь-метиз”. — Поэтому в силу доступности у пользователей появляется искушение сгенерировать как можно больше отчетов. Использование BI‑систем должно в первую очередь основываться на четком понимании того, для каких целей нужны те или иные данные, а это уже вопрос самостоятельного проекта по систематизации, унификации и упрощению управленческой, финансовой, бухгалтерской и другой отчетности».

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

Итерационное создание системы

Еще один важный аспект — тактика построения BI‑системы. Практика показывает, что отнюдь не всегда удается внедрить BI-решение за одну итерацию. «Решение задач в области аналитической обработки отличается от внедрения, скажем, новых модулей ERP‑системы, это более рискованные работы, определенный процент которых даже при грамотном подходе может завершиться неудачей, — говорит один из ИТ-директоров. — Ведь в отличие от работы с более привычными нам транзакционными системами здесь мы больше автоматизируем не должностные обязанности сотрудников, а их индивидуальные склонности к каким‑то видам работ. И это мы тоже должны адекватно учесть».

Очень часто на очередном этапе проекта плывут задачи, возникает качественный скачок в видении системы со стороны аналитиков или топ-менеджеров. «По окончании одного из его этапов руководитель проекта от ИТ вместе с исполнителем сочли работу, связанную с формированием отчетности, полностью выполненной, однако вскоре выяснилось, что её результат совершенно не устраивает бизнес, — делится опытом другой ИТ-директор. — Стало ясно, что бизнес хочет и может иметь дело с аналитическими приложениями самостоятельно, хотя это и требует дополнительной работы как непосредственно в области формирования процессов обработки информации, так и в сфере интерфейсных возможностей системы».

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

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

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

Сроки, пилоты, консультанты

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

Первое — понятие «пилотный проект» при создании BI-решения существенно меняет свой смысл и становится скорее первой фазой итерационного процесса внедрения. «Отношение к пилотным проектам у меня сложное. На моей практике все “пилоты” превращались в полноценные проекты, — подтверждает один из участников круглого стола. — В пилоте необходимо охватить законченную функциональную область, и он лишь называется пилотным, а по сути — обычный полнофункциональный проект. И работать в таких “пилотах” приходилось как в обычном проекте. Тем более, что помощи от консультантов в пилотном проекте не добьешься: денег за “пилот” много не дадут».

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

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

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

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

Это, конечно, радикальный взгляд, однако в нем есть весьма рациональное зерно. Ведь в силу значительной неопределенности в будущих задачах, нечеткой формулировки потребностей («даже если на старте проекта высказываются четкие требования, очень скоро выясняется, что они тоже весьма расплывчаты»), незнания необходимых моделей и алгоритмов взаимодействие с поставщиками ИТ-услуг в значительной степени должно строиться по иным принципам, чем, скажем, при внедрении ERP‑систем. «Классические тендеры здесь вряд ли подходят, тут уместнее менее формализованные способы общения с поставщиками, — считает ИТ-директор компании “Л’этуаль” Николай Зайцев (читайте его интервью в № 9-10/ 2008). — Для выбора решения абсолютно необходимо попробовать некоторые задачи на наших данных. При этом мне, конечно, могут говорить, что очень похожая задача как раз решалась при помощи той же системы в аналогичной компании, что можно познакомиться с их опытом, что там все прошло чрезвычайно успешно и т. д. Однако я все равно остаюсь твердым сторонником того, что лучшим способом является проведение своего рода “натурных испытаний”. Нам необходимо доказательство работо­способности предлагаемой системы на наших задачах и наших данных. И только по мере того, как результаты пилотного проекта приобретают видимые для бизнеса очертания, делаются презентации результатов для бизнеса».

Замкнуть цикл

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

Интересен опыт Группы ЧТПЗ, где после внедрения модуля CRM в 2006 году для дирекции продаж компанией «Малахит» было разработано решение, предоставляющее бизнес-аналитику всем участникам процесса сбыта готовой продукции. Здесь BI-решение решало одну, пусть частную, но практическую задачу: автоматическое начисление зарплаты и мотивация менеджеров по продажам Группы ЧТПЗ. И решение такой практической задачи во многом помогло решить вышеперечисленные проблемы проектов.

«В отличие от других отчетов, формируемых в BI‑системах, информация по сбыту готовой продукции была очень востребована, так как на ее основе начислялись зарплата и премии менеджерам по продажам, — говорит Рустем Искаков, заместитель исполнительного директора “Малахит”. — Менеджер понимал, что чем больше будет цифр в определенной колонке, тем больше денег он получит в кассе в конце месяца. Эта информация напрямую связана с мотивацией персонала, поэтому мы подошли к проекту со всей возможной тщательностью. Любая ошибка в данных могла стоить человеку заработной платы, поэтому в процесс формирования этой аналитики были вовлечены сами менеджеры и их руководители. В итоге мы добились прозрачности, которая позволяет менеджеру по продажам видеть, как формируются его премии, дали ему инструмент и объяснили принцип — что он должен сделать для того, чтобы получить больше денег. Мы дали руководителям аналитику, на основе которой они могут принимать управленческие решения, к примеру, уволить нерадивых сотрудников и поощрить тех, кто хорошо работает. Наконец, самый верхний слой аналитики предназначен директору торгового дома, который может на ее основе строить прогноз продаж и выносить на совет директоров стратегические вопросы».

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

Модифицируя ERP‑систему

Когда мы говорим о замыкании цикла использования аналитики, надо вспомнить еще об одной проблеме BI‑систем — полноте аналитики той учетной системы, на которую ставится такое решение. Потому что когда ставится цель, ради которой разворачивается весь BI-проект, может быть принято решение по расширению аналитических признаков операций в первичной учетной системе. То есть возникнет обратная задача — реконструкция на ERP‑системы исходя из задач BI. Хороший пример — проект на «Северсталь-метизе».

«Ситуация с внедрением BI‑системы в нашей компании довольно уникальная, — рассказывает Алексей Комаров. — “Северсталь-метиз” развивался стремительно, и нам сразу же были нужны управленческие данные. Стандартные формы отчетов ERP‑системы не всегда позволяют в полной мере удовлетворить запросы пользователей в части управленческих и оперативных отчетов, и получилось так, что ERP‑система развивалась параллельно с BI. Более того, BI‑система стала жизненно важной для успешного внедрения ERP‑системы, так как прежде всего позволила аналитикам проще и быстрее преобразовывать первичные цифры в структурированный анализ. Эти две системы в процессе своего развития дополняли друг друга, и в результате получился тандем, который по‑своему уникален и практически полностью удовлетворяет потребности пользователей. Такое сочетание позволяет наиболее эффективно реализовывать возможности обеих систем, получая в конечном счете именно тот результат, которого ожидает топ-менеджмент.

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

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

Наиболее важные моменты при инициировании проектов в области BI

a) обеспечение поддержки проекта руководством компании;
b) обследование текущих и потенциальных задач, уточнение требований, классификация отчетов, как минимум по критерию аналитические/оперативные;
c) анализ изменений бизнес-процессов и оргструктуры, которые потребуются для реализации проекта, выявление конкретных функциональных заказчиков будущих отчетов и аналитики (кому нужны аналитические данные — топ-менеджерам, линейным руководителям; нужна ли такая особая категория специалистов, как аналитики; необходимы ли аналитики в подразделениях или они должны быть собраны в специальном отделе и т.д.) и определение требований к ключевым пользователям;
d) предварительная оценка бюджета проекта и его сроков;
e) обследование источников данных, определение, какая информация где хранится, пересмотр требований к качеству данных.

Требования становятся более жесткими

Олег Оленин
Технический консультант, компания InterSystems

Сегодня требования к средствам бизнес-анализа и к проектам по их внедрению становятся более жесткими. Результат от внедрения BI‑средств важно получить даже не сразу по окончании проекта, а после каждого этапа внедрения. Возможность анализа актуальных, «живых» данных должна обеспечивать эффективное решение тактических задач и быстроту реакции на изменения на рынке. Поэтому использование средств real time BI, embedded BI сегодня становится наиболее актуальным. Самым трудоемким в BI-проектах было и остается создание механизмов выгрузки и согласования данных из разных КИС. «Приближая» средства BI к корпоративному приложению, т. е. встраивая их в приложения, мы значительно сокращаем и упрощаем решение: повышается оперативность доступа к данным, скорость внесения изменений. Проект реализуется по принципу эволюционного наращивания аналитических возможностей BI: т.е. получить видимый результат можно на каждом этапе. При использовании embedded BI дополнительным преимуществом становится и то, что сотрудники заказчика продолжают использовать уже знакомый интерфейс приложений и требуется только небольшое обучение новым возможностям.