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

О таком движении западные аналитики в течение последнего года явно заявляют, как и об отраслевой специализации BI. Теперь, по их мнению, BI уже не просто системы, сообщающие людям о том, что есть, теперь они должны быть способны принимать решения без включения в цепь «слабого звена» — людей. Это потребует от компаний прогнозирующего моделирования, а значит, четко описанных процессов и бизнес-правил, как и средств их автоматизированного выполнения. Американское издание журнала Intelligent Enterprise указывает, что хотя такая точка зрения и кажется слишком амбициозной, но после прошлогодних мегапоглощений BI-вендоров Hyperion, Business Objects и Cognos соответственно компаниями Oracle, SAP и IBM все чаще можно услышать термин «контекстный BI», что можно понимать как внедрение BI-функций на рабочие места и в повседневные приложения.

Редакция американского Intelligent Enterprise провела исследование, в которое был включен вопрос касательно того, используют ли или собираются использовать компании такие BI-функции. В исследовании приняли участие 385 респондентов, и 32 % из них указали, что используют их, и среди них было 62 % тех, кто оценивает использование BI в своей компании как «очень успешное». При этом 46% от общего числа ответивших указали, что собираются использовать встроенные BI-функции, и в их составе — 29% «успешных практиков» BI.

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

Каждую неделю один шаг вперед

Сергей Буш
Заместитель генерального директора компании «Verysell-Проекты»
Итерационное (пошаговое) ведение проекта, когда через каждые одну-две недели на «натурном прототипе» зримо для бизнеса отображается ход работы, — лучший подход не только для BI-проектов, но и для большинства «классических» проектов внедрения транзакционных систем. Такой подход принято называть адаптивным.

Адаптивный подход в случае с BI-проектами может значительно облегчить жизнь. Поскольку не только функциональное наполнение и представление данных BI-системы всегда будет в высокой степени индивидуальным, но и системы, из которых будут браться необходимые данные (ERP, CRM, СЭД), будут в значительной мере специализированными для данной организации. И реальной альтернативы адаптивной методологии в данном случае не видно.

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

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

Движемся в сторону отраслевых решений

Алексей Зайцев
Руководитель отдела информационно-аналитических систем компании TopS BI (ГК «Систематика»)
При подготовке к проекту внедрения аналитической системы следует определить, насколько эта система нужна бизнес-пользователям, и постараться сформулировать её задачи, предварительные требования к ней, а также возможные источники данных. Это позволит в первом приближении понять функциональные рамки будущего проекта, потребности заказчика и ключевых пользователей и примерные сроки работ. На этапе формулирования предварительных требований к системе может выясниться, что некоторые из них подвержены изменениям в ближайшем будущем либо придётся переработать существующие в компании бизнес-процессы.

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

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

Итерационное ведение проекта

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

«Правильное» хранилище — прежде всего

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

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

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

Начиная с малого

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

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

Демонстрация будущего на основе «пилотов»

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

Качество данных

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

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

Михаил Чиженко
Business Solutions Architect, SAP
Одна из существенных задач в самом начале проекта — оценить «готовность» компании к внедрению BI. К сожалению, не всегда сами компании готовы к выполнению подобных проектов, а интеграторы не уделяют должного внимания этой задаче. Важно не опережать события и дать компании созреть до внедрения подобных систем. На определенной стадии этого осознания наступает тот самый момент, когда менеджмент и аналитики могут вполне предметно сформулировать то, чего они хотят от системы, а именно состав наиболее важных с точки зрения анализа бизнеса ключевых показателей.

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

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

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