Недавно на CNews было опубликовано сообщение под названием «»
Это одна из редких новостей по теме BI, т.е. бизнес-аналитики. Поэтому мы ре??или посвятить ей отдельную публикацию и по мере возможности рассмотреть детали проекта.
Такая декомпозиция новостных текстов помогает более отчетливо понять свое собственное движение на рынке. Напомним, что мы также позиционируем свои программные продукты как инструменты класса BI (Business Intelligence). На русский язык это как раз и переводится как «бизнес-аналитика»
Общие сведения о проекте
Во-первых, отметим, что это одна из последних новостей после вхождения компании Business Objects в состав SAP.
Сам проект был посвящен «созданию информационно-аналитической системы». Как уже говорилось вы??е, проекты такого рода достаточно редкое явление. Сейчас чаще пи??ут о внедрении ERP или CRM.
Профиль организации тоже достаточно нестандартный. «Мостотрест» занимается строительством «объектов транспортной инфраструктуры». Т.е. он относится к числу строительных организаций, для которых не так уж и много написано программного обеспечения. Помнится, еще год-два назад на страницах специализированных ??Т-изданий обсуждался этот вопрос и делались прогнозы, что в ближай??ем будущем такое ПО будет появляться.
??сполнителем проекта выступила компания «Терн». Она уже давно работает в этой области и специализируется как раз на BI-ре??ениях. Единственное, что в ее портфеле главным образом ре??ения от SAP. Хотя сам по себе портфель достаточно разнообразный, там есть и десктопные ре??ения, и онлайн-варианты.
Главная задача проекта
Главная задача проекта, как следует из текста — повы??ение «эффективности руководства проектами, выполняемыми об??ирной филиальной сетью». ?? если «повы??ение эффективности руководства» есть слова довольно общие, повторяемые практически в каждом проекте, то вот филиальная сеть это уже теплее. Скорее всего проблема именно в ней: много филиалов, разнородная информация, поступает нерегулярно и в итоге нет общей картины.
Отсюда новая информационная система должна «ускорить процесс обработки информации», ускорить процесс обмена данными между подразделениями, обеспечить представление необходимых сведений в аппарат генерального директора, т.е. для топ-менеджмента. В принципе все задачи достаточно понятные и стандартные. Сделать так, чтобы информация поступала быстро, чтобы она приходила в головной офис и циркулировала между подразделениями.
??дем даль??е. Разработанное и внедренное ре??ение должно сократить время на сбор информации, ее проверку, консолидацию и анализ данных, плюс углубленный анализ этих данных в оперативных режимах, причем на разных уровнях управления компанией. В последнем случае, скорее всего, имеется в виду, например, уровень отдельных филиалов и уровень компании в целом.
Здесь уже по??ло перечисление конкретных операций, входящих в состав понятия «анализ». Это сбор, проверка, консолидация данных. Кроме того, выделен анализ в оперативном режиме. Отсюда, логично, что есть еще анализ и не в оперативном режиме, а на стратегическом уровне. Правда, до последнего времени у специалистов нет четкого понимания, что это такое и чем он отличается от оперативного.
Компоненты анализа
Еще подробности. В рамках проекта построена подсистема план-факторного анализа, которая потом была интегрирована в общую систему поддержки принятия ре??ений. Первый момент нередко выдается за вер??ину аналитической мысли, мол вот план, а вот факт. На самом деле этот план-факторный анализ при??ел из бухгалтерии, где анализ как таковой жестко ограничен узкими рамками счетоводческой идеологии. Реально же в хоро??ем анализе план-факт есть только один из вариантов работы с данными.
Еще более абстрактно упоминание системы поддержки ре??ений. Давно уже от??умели споры о том, что это такое. Погасли иллюзии, что программы настолько поумнеют, что сами будут находить ре??ения. Неизбежно вызрела парадигма, что автоматизированные системы только подготавливают информацию для принятия ре??ения. Но при таком подходе можно сказать, что любая система так или иначе содержит информацию, которую можно использовать для принятия ре??ения. Отсюда, сегодня можно констатировать достаточно стойкое недоверие к самому термину поддержки принятия ре??ения. Как правило за ним скрывается что-то простое и менее пафосное.
?? следующий абзац подтверждает, что громкие слова о поддержке принятия ре??ения в реальности оказываются ре??ением простых и типовых задач, причем само собой разумеющихся. Речь идет о том, что новая система позволяет консолидировать боль??ие объемы информации по разным направлениям деятельности компании, что помогает принимать ре??ения по эффективному управлению филиалами и другими подразделениями. ?? кроме консолидации речь идет еще об оперативности представления данных, причем речь идет о взаиморасчетах между филиалами, что также пафосно называется «перекрестным анализом»
В сухом остатке имеем — быстрее стали получать данные из филиалов, смогли свести их в общие таблицы и отчеты, и это, естественно, помогает принимать ре??ения на уровне управления компанией в целом. Т.е. вырисовывается главная задача проекта — заставить филиалы предоставлять информацию, разработать специальные формы, которые они будут присылать, сделать общую базу, куда все эти формы будут вноситься. Ну а даль??е уже строить отчеты с фильтрацией по всей компании, или по разным филиалам.
Плюсы и минусы хранилища данных
Наконец еще информация, уже более техническая о самом проекте. Так, проект выполнялся в 2 этапа. На первом «было создано хранилище данных и разработаны процедуры загрузки, консолидации и очистки.»
Это достаточно информативная часть текста, которую следует рассмотреть более подробно. ??так, главное содержание первого этапа — это создание хранилища данных. Нам уже доводилось в некоторых публикациях говорить, что боль??ие аналитические системы зачастую гре??ат тем, что в них основное внимание уделяется созданию хранилища данных, а на сам анализ этих данных уже не хватает ни времени, ни сил.
С одной стороны, хранилище данных действительно необходимая вещь. Достаточно сказать, что многие учетные системы оперируют только актуальными данными. Например, в той же 1С данные за про??лые годы просто переносятся в архив. Т.е. для повседневной работы вполне достаточно данных за текущий год. В этом случае, конечно, нужно создавать хранилище данных за предыдущие периоды, поскольку аналитика не ограничивается только текущей информацией.
С другой стороны, процедура создания хранилищ данных сегодня начинает уже выглядеть определенным анахронизмом. Т.е., кроме собственно оперативных данных нужно еще создавать и данные архивные. Плюс к ним продумывать процедуры перенесения в архив. Это достаточно трудоемкая работа, отнимающая много времени и ресурсов.
Какова альтернатива данному пути? — Для ответа на этот вопрос вспомним, что архивы данных в учетных системах обычно создаются потому, что разрастается размер базы, с которой уже становится тяжело работать. Но, и это главный момент, такое положение дел было характерно для автоматизации в предыдущие годы, когда аппаратные ресурсы были еще достаточно скромные. Сегодня же, когда можно использовать очень мощные компьютеры и сервера, размер базы данных уже не является ограничивающим фактором. Современные компьютеры вполне могут справляться с теми объемами данных, которые накапливаются на предприятиях.
Отсюда, отпадает необходимость создавать отдельное хранилище данных и для анализа могут использоваться данные, которые хранятся в одной, общей базе данных. А нагрузка на вычислительные ресурсы регулируется фильтрацией данных. Оперативный учет использует текущие данные и по своим алгоритмам, анализ может использовать и текущие, и архивные данные, и тоже по своим алгоритмам. Но все эти данные могут храниться в одной базе.
Операции по подготовке данных
Чуть позже мы еще вернемся к организации хранилища данных, реализованного в проекте Мостотреста. Сейчас обратим внимание на процедуры внесения информации в это хранилище. В тексте названы «загрузка», «консолидация» и «очистка». «Загрузка» означает, что была разработана общая структура таблиц базы в хранилище, затем, на их основе, были созданы формы ввода исходной информации. Причем, скорее всего, формы ввода информации использовались в филиалах. Затем был организован процесс их пересылки в головной офис, где также была налажена автоматическая загрузка их в общую базу.
?? вот здесь тоже не простой технический вопрос — эта исходная информация загружалась параллельно в две программы или в какую-то одну? Т.е. загружалась ли эта информация только в хранилище данных, либо параллельно еще и в другую программу, которая использовалась для оперативного учета? Ведь хранилище данных — это, по сути дела, архив информации. Он, по идее, не используется для оперативного учета. Если же это была только одна база, то значит архив использовался и для оперативной работы, что еще раз подтверждает правильность высказанных нами вы??е аргументов по поводу хранилища данных.
Следующая операция — «консолидация». Это означает, что в общей базе данных информации от каждого филиала программа присваивала некие префиксы, благодаря которым впоследствии при анализе можно было строить отчеты в разрезе подразделений.
Наконец, последняя из названных операций — «очистка» данных. Это одна из специфических операций или стадий работы с данными, когда они очищаются от возможных о??ибок. При внедрении автоматизированных аналитических систем практически всегда имеет место стадия, когда после установки программного обеспечения и получения первых отчетов выявляются о??ибки. Как правило они замечаются именно в отчетах, т.е. в анализе. Показательно при этом, что ранее, при работе с данными в оперативном режиме они, как правило, не обнаруживаются.
Такие о??ибки могут быть связаны либо с неправильным вводом данных, либо с неправильной или нестандартной их интерпретацией. Если с о??ибками первого рода более менее понятно, то для иллюстрации о??ибок интерпретации приведем следующий пример. В проекте для компании, торгующей автозапчастями, «о??ибка» в отчете была связана с тем, что бухгалтерия (а данные для анализа брались из бухгалтерской программы) перенесла одну из сделок на другой отчетный период.
??нформационно-аналитические панели руководителя
Наконец, еще одно ре??ение, которое было реализовано на первом этапе проекта — «руководству «Мостотреста» был предоставлен универсальный инструмент анализа – информационная панель руководителя».
Такие панели сейчас довольно модная тенденция. Есть они в CRM-приложениях Oracle, различные тачборды (touch board) есть в онлайновых аналитических конструкторах, есть информационная панель руководителя и у «Галактики»
Самый интересный вопрос, связанный с подобными информационными или интерактивными панелями состоит в том, какие именно показатели на них выводятся. ??деальный вариант — здесь должны отображаться основные индикаторы работы предприятия. Причем не только текущие, но и предупреждающие на ближай??ее будущее.
Здесь мы вплотную подходим к идеологии организации анализа. Какие именно показатели нужны, в каким отчетах они должны отображаться, каким должен быть общий список этих отчетов — вот перечень основных вопросов, возникающих при создании подобных панелей. ?? все они, как мы покажем в одной из следующих публикаций, тесным образом связаны с общей концепцией управления предприятием.
А пока вернемся к проекту Мостотреста. Как сказано в сообщении, на втором этапе » был осуществлён переход с Excel на платформу SAP BusinessObjects и разработаны два вида вне??ней и внутренней отчётности по компании в целом и по структурным подразделениям (филиалам), которые отражают финансово-экономические показатели «Мостотреста».
Здесь можно выделить три момента. В первом случае приходится только удивляться, как такая боль??ая организация до проекта работала на Excel?! КРоме всего прочего, это говорит и о том, что выбор аналитических инструментов сегодня не так уж и велик.
Следующий момент, в принципе повторяет сказанное вы??е — основное содержание проекта составила разработка отчетности в разрезе подразделений и для предприятия в целом.
Наконец, в последнем блоке приведенного фрагмента затрагивается как раз проблема показателей для информационной панели руководителя. В данном случае разработчики по??ли по проторенному пути и выбрали в качестве таковых финансово-экономические. Т.е., скорее всего, они просто взяли те показатели, на которые им указал заказчик. А заказчик, в свою очередь, действовал по известной схеме — немного бухгалтерии, немного финансов, торговля, склад, задолженности и т.д.
Заключение
Таким образом, заканчивая на?? развернутый анализ данного новостного сообщения, можно сказать, что по сути дела проект был посвящен достаточно типовой задаче — свести воедино информацию из филиалов, чтобы получать отчеты как в целом по всему предприятию, так и в разрезе структурных подразделений.
Что характерно, для ре??ения подобных задач достаточно в принципе средств той же 1С. ?? если в данном проекте эта платформа не использовалась, то причиной может быть товарная специализация 1С. Как известно, услуги и работы, в том числе строительные, у этой платформы реализованы не на таком уровне, как товарный учет.
Если же посмотреть на информацию о проекте с технической стороны, то можно конкретизировать те моменты, которые обычно включаютс в понятие бизнес-аналитики. Это два боль??их блока — хранилище данных и собственно анализ.
Т.е. вначале данные должны быть подготовлены для анализа, для этого отрабатываются процедуры сбора информации, регламенты их передачи в общую базу, их проверки (очистки), процедуры обеспечения их консолидации.
Анализ в свою очередь включает в себя такие аспекты как различение оперативного и стратегического видов анализа, анализ по принципу план-факт, информационно-аналитическая панель для руководителя и связанная с ней проблема выбора показателей-индикаторов
Сергей Дмитриев
