Николай Гегамов
ИТ-директор OOO «International
Fragrance Distribution»
gegamov@ifd.ru

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

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

Предпосылки болезни. Пациент еще здоров
Время течет, бизнес меняется

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

Теперь — подробнее про «бомбу замедленного действия», которую я назвал возможностью модификации. Без нее действительно не всегда можно обойтись. Например, наиболее подвержена изменениям по независящим от бизнеса обстоятельствам бухгалтерия. Естественное желание при наличии дорогостоящего в сопровождении ERP-решения выделять бухгалтерию в отдельную мобильную систему, более дешевую в обслуживании. Скажем, на платформе стандартного программного продукта, производители которого достаточно чутко реагируют на все изменения в налоговом законодательстве. Кроме того, из-за ступенчатого развития возможна такая ситуация, когда многие бизнес-процессы всё ещё поддерживаются старыми системами. Причем какие-то из них даже и не планируются к интеграции в новую систему, особенно если они слабо формализованы или сильно локализованы. Тут возникает еще одна проблема — процедура синхронизации БД (база данных). А уж о системном бюджетировании на первых этапах внедрения вообще редко кто задумывается. Тут (точнее, потом) возникает еще одна проблема — консолидации данных различных систем. Еще позже, если все будет не так плохо, придут в голову идеи оптимизации, например, новомодные KPI (Key Performance Indicator — ключевые показатели эффективности), что также потребует сквозной модификации. Хорошо еще, если с самого начала не возникла идея CRM (Customer Relations Management — управление взаимоотношениями с клиентами) или других параллельных проектов. У многих эти блоки со временем отмирают, а это будет обидно. Конечно, я несколько утрирую, но в целом картина развития примерно такова.

 

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

 

 

 

 

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

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

 

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

 

 

 

Симптомы и диагноз. Пациент нервничает
Перспектива нового проекта
аналитической системы

 

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

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

Итак, рассмотрим второй случай. Проект разработки ИС полностью или частично завершен — во всяком случае завершен ряд основных его этапов, и компания уже полноценно эксплуатирует новые системы. Напомним, что мы имеем дело с ERP-решением. Значит, у нас уже есть изрядный блок стандартных отчетов. Поскольку система модифицируема, они могут быть до неузнаваемости переписаны или их уже может быть намного больше, чем предполагалось вначале. Для других систем-спутников разработаны также блоки отчетности. При этом возможны некие выгрузки данных из различных систем, в той или иной мере формализованные. И, наконец, могут быть некие средства консолидации этих выгрузок — от разработанных ИT-службой до приложений, написанных «на коленке», и просто таблиц Excel. В этом случае рано или поздно одновременно или порознь мы столкнемся с проблемами либо с задачами, которые к проблемам приведут.

  • Нужно разработать ПО под бизнес-процесс, которое затронет несколько разрозненных систем — т. е. они заведомо не реализуемы в текущей архитектуре программного комплекса. Это то же корпоративное бюджетирование, модели консолидации финансовых и нефинансовых данных, мотивации, мониторинг исполнения и т. д. Встанет проблема автоматизированной синхронизации данных или задача слияния систем в одну.
  • Одна или несколько систем стали настолько тяжеловесными, что возникли проблемы с отработкой стандартных отчетов. Это значит, что пользователь ждет отработки отчета часами. А вместе с ним его отчета ждет и весь офис, так как производительность системы резко упала.
  • Возможно, была предпринята попытка пакетного формирования отчетности — отчеты формировались каждую ночь и выкладывались в виде файлов. Тогда могла возникнуть следующая проблема: пользователям недостаточно отчетов с фиксированной структурой и параметрами — налицо потребность в динамических отчетах.
  • Возникла потребность в новых аналитических отчетах, оперирующих достаточно большим объемом данных, чтобы понять, что они не реализуемы по быстродействию в текущей ERP-системе.
  • Нет доверия к данным — проблема единого взгляда на управленческую информацию. Например, два разных департамента силами своих менеджеров получили один и тот же отчет с разными цифрами. Чей правильный? Кроме того, компании вряд ли будет удобно, если она попадёт в зависимость от тех или иных менеджеров, которые имеют свои, не санкционированные ИT-службой, программы обработки суррогатных данных.

Таким образом, перед руководителями проекта встает смутная и пугающая перспектива еще одного проекта — целой аналитической системы, причём скорее всего совсем на другой платформе. Она должна консолидировать данные всех необходимых систем и быть куда более быстродейстующей. На этом этапе участники проекта, как правило, вспоминают или узнают термины BI (Business Intelligence — системы бизнес-интеллекта), OLAP (On-line Analytical Processing — оперативная аналитическая обработка данных), DWH (Data WareHouse — хранилище данных(Далее — просто хранилище)). В результате они ближе знакомятся с разработчиками BI-платформ и инструментов, такими как Business Objects, SAS, Cognos, SAP, Microsoft, Oracle, Hyperion, MicroStrategy и т. д.

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

  Размышления
на тему ERP и BI: совмещать или
разносить?
 

Назначение систем настолько разное, что с ходу хочется прокричать: разносить! Однако при разнесении тут же получаем еще целую кучу проблем: организация внешнего хранилища, организация интерфейса обмена данными ERP и хранилища (одно благо — поток однонаправленный), проблема целостности данных, ввод дополнительного инструментария — OLAP и на его основе Q&R-системы (Query and Reporting tools — средства формирования запросов и построения отчетов)... Достаточно — кричать не будем. Лучше задумаемся: если не разносить, то как совмещать? Во-первых, ERP-решение должно быть действительно полноценной корпоративной системой — данные для BI-системы должны браться «изнутри». Во-вторых, лично я не знаю на настоящий момент более действенных систем обработки данных, чем OLAP. Таким образом, чтобы не отойти от принципа «два в одном», следует изначально выбирать ERP-систему с интегрированной OLAP-платформой. Надо отметить, что такие системы есть и это направление интенсивно развивается. Достаточно ли они мощны и подходят ли по функционалу конкретной компании — решать ей. Основная проблема совмещения ERP и OLAP в одной системе, по-моему, заключена в том, что структура данных транзакционных ERP-систем избыточна для OLAP и вряд ли позволяет эффективно строить OLAP-кубы. Менять структуру? Распределять данные? Научиться распознавать на программном уровне аналитическую и оперативную информацию и раскладывать ее, допустим, по разным серверам? Я здесь не говорю о примитивном фрагментарном распределении, таком как хранение данных по каждому периоду (допустим, году) на отдельном сервере. Все гораздо сложнее. Сегодня эта информация может быть оперативной, а через месяц она станет аналитической. То есть для каждой структуры информации должен быть определен ее жизненный цикл. Этот навык интеллектуального распределения БД ERP был бы существенным аргументом за совмещение. Достаточно. Я снова хочу кричать — надо разносить!
Итак, за несколько минут у меня вырвалось два крика души, прямо противоположных. Честно говоря, я не собирался здесь и сейчас давать ответ на этот вопрос, тем более что и не знаю его (во всяком случае, достаточно аргументированного). В любом случае приложений BI уже множество — от BPM (Enterprise Perfomance Management — управление эффективностью предприятия) и BSC (Balanced ScoreCard — система сбалансированных показателей) до тех же приложений по разведке данных (data mining). Их самих множество, причем с самой разной специализацией, производителей — также немало, а будет еще больше, и каждые следующие будут лучше, потому что само направление молодое и интенсивно развивающееся. А какое именно из них выбрать, зависит от потребностей и возможностей конкретной компании. Нужно анализировать...

 

 

Пациент идет на контакт
Первые этапы проектирования BI-системы

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

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

OLAP-отчетность решает уже упомянутые проблемы:

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

С другой стороны, OLAP-отчетность имеет и ограничения:

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

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

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

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

Пересмотр требований к качеству данных. Такой дорогостоящий и массивный инструмент бессмысленно внедрять, если он не будет охватывать достаточно большой объем деятельности компании, а пользователям не будет внушать полного доверия. Я считаю, что для успеха проекта очень важно, чтобы на этой стадии спайка бизнеса и ИT была очень сильной, причем бизнес должен выступать в роли ведущего.

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

Курс лечения
Разработка и внедрение BI-системы

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

Несмотря на, казалось бы, глубокое понимание содержания вышеописанного пункта «Определение требований к ключевым пользователям» всеми участниками проекта, вполне возможна ситуация пробуксовывания при внедрении системы. Даже при высококачественном, жестком и последовательном руководстве проектом не всегда удается пройти внедрение за одну итерацию. Например, возможен качественный скачок в видении системы со стороны аналитиков, что приведёт к пересмотру некоторых отчетов. Конечно, внедрение в таком случае замедлится, но это шаг вперед. А может, наоборот, возникнуть сопротивление проекту, скрытое или явное нежелание отказываться от «наколеночных систем». В любом случае это уже шаг назад — к повторному курсу обучения или даже к замене пользователей.

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

  • инкрементальное обновление хранилища;
  • предварительная подготовка данных в ERP-системе;
  • обновление только активных партиций кубов(Частей куба, относящихся к активному периоду.).

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

  Положительный
побочный
эффект
 

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

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

Как архивировать БД
По мере роста БД постепенно снижается производительность ERP-системы, она перестает помещаться в отведенном для нее дисковом пространстве. Я уже не говорю о том, какое время приходится тратить на такие регламентные процедуры администрирования БД, как, например, ее реиндексация. Наверняка этот комплекс проблем знаком всем ИT-специалистам не хуже, чем мне. Меньше всего мне нравится бороться с этим явлением путем наращивания аппаратных мощностей. В этом случае мы полностью становимся заложниками ситуации. Со временем суммы, затрачиваемые на новые серверы, начнут расти экспоненциально, а самое главное, мы подсознательно ощущаем, что рано или поздно все равно подойдем к пределу. Что же делать?

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

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

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

Схема «чистки» и «резки» ERP-системы

Заключение

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

Но когда сталкиваешься с проблемами быстродействия или полноты «родной» ERP-системы при генерации аналитических отчетов, то начинаешь нервно искать пути решения. Так вот, я для себя на данный момент не вижу ничего, кроме OLAP. Есть только его вариации и различные средства формирования запросов и построения отчетов на его платформе. Так что решение о новом BI-проекте фактически предопределено. Не тратьте время и нервы на поиск способов исцеления. Растущая компания, увы, рано или поздно заболеет, но лекарство известно. Главное — правильно выбрать дозировку, добиться сотрудничества с пациентом и грамотно провести курс лечения. Анализируйте это!