Файл: Учебник Рекомендовано Федеральным государственным учреждением.pdf

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

целевых показателях бизнеса, как затраты, прибыль, оператив­
ность.
Проверка соответствия системы стандарту ERP включает не­
сколько этапов. При тестировании следует проверить наличие связи между модулем оперативного планирования производства и модулем управления персоналом. Например, в случае болезни какого-либо сотрудника должна быть обеспечена автоматическая либо полуавтоматическая корректировка сменных заданий.
Система должна увязывать все виды затрат ресурсов с бюджетом предприятия. Это должно проводиться в системе на стадии воз­
никновения обязательств, а не в момент фактического осущест­
вления платежей. Система должна содержать встроенный меха­
низм связи плана закупок с бюджетом. Тестирование состоит в получении информации о состоянии бюджетных статей на раз­
личных стадиях возникновения обязательств (обязательств на стадии договоров, заказов и выставленных счетов-фактур), а так­
же в проведении тестов на возможность формирования плана снабжения и заказов поставщикам при отсутствии достаточных средств на соответствующий период. Система должна предостав­
лять информацию о фактических затратах на производство от­
дельных видов продукции и затратах на содержание подразделений в разрезе статей, режимов работы, факторов отклонений и центров ответственности, т.е. структурной единицы предприятия, ответ­
ственной за определенные доходы либо расходы. В качестве теста системе может быть предложен такой запрос: «В какой мере по­
влияли на себестоимость продукции отклонения от планового уровня загрузки оборудования, относящегося к конкретному цен­
тру ответственности по конкретному подразделению?»
5.5.4. ВРМ (Business Performance
Management) — автоматизация процессов управленческого планирования и контроля
В настоящее время остро встает необходимость в специализи­
рованных приложениях для автоматизации управленческих задач бюджетирования, финансового планирования, анализа и контро­
ля. Международная компания IDC, специализирующаяся на не­
зависимом мониторинге рынка программного обеспечения, объединила такие приложения в новое семейство — ВРМ (Business
Performance Management — управление эффективностью бизнеса).
ВРМ-системы позволяют связывать воедино такие понятия, как миссия компании, стратегия развития, цели, долгосрочные планы, среднесрочные перспективы и конкретные бюджеты на ближай­
ший период. Топ-менеджеры могут предоставлять плановые бюд­
166

жеты начальникам отделов, которые, исходя из оценки ситуации
(могут ли они выполнить эти задачи, какие ресурсы им для этого нужны), их корректируют. Система позволяет им видеть и ис­
пользовать в своей работе отчетность смежных подразделений: на основе планов поставок сырья оценивать свои возможности по объемам производства и т. п. Далее откорректированные и допол­
ненные на нижнем уровне цифры агрегируются вновь до обще­
корпоративного уровня. Весь этот процесс «двунаправленного» бюджетирования итеративно повторяется до тех пор, пока не бу­
дет составлен наиболее «реальный» бюджет.
Благодаря единой среде сотрудничества каждый работник на­
чинает более четко осознавать свою роль в процессе управления организацией. Достоверность бюджета повышается за счет во­
влечения рядовых исполнителей в процесс его составления.
Аналитическая функциональность ВРМ-приложений обеспе­
чивает возможность составления отчетности «на лету». Система
ВРМ обладает возможностью своевременного обнаружения от­
клонения фактических показателей от их плановых величин и оповещ ения об этом менеджеров. В настоящее время ВРМ- приложения набирают все большую популярность. Предприятия различных сфер деятельности заинтересованы в использовании
BMP-приложений как мощного механизма консолидации отчет­
ности.
5.6. А налитическая обработка данны х д л я по дд е р ж к и принятия реш ений
Можно выделить три основные технологии поддержки при­
нятия управленческих решений на основе накопленной инфор­
мации:
— технологии, ориентированные на оперативную (транзакци­
онную) обработку данных и реализованные в большинстве тран­
закционных систем (OLTP). Сфера действия таких технологий — область детализированных данных. Классические реляционные
СУБД нормально справляются с подобными задачами, поэтому в подробном их рассмотрении нет необходимости;
— технологии OLAP (On-line Analytical Processing — интерак­
тивная аналитическая обработка данных), ориентированные на область агрегированных показателей;
— технологии интеллектуальной обработки данных, ориенти­
рованные на область закономерностей. Интеллектуальная обра­
ботка проводится методами интеллектуального анализа данных
(ИАД, в западной литературе — Data Mining). С помощью этих
167

технологий решаются задачи поиска функциональных и логиче­
ских закономерностей в накопленной информации.
Рассм отрим подробнее перечисленны е технологии.
5.6.1- OLAP (On-line Analitical Processing) — оперативный анализ данных
Механизм OLAP является на сегодня одним из популярных методов анализа данных. OLAP — это не отдельно взятый про­
граммный продукт, не язык программирования и даже не кон­
кретная технология. Если постараться охватить OLAP во всех его проявлениях, то это совокупность концепций, принципов и требований, лежащих в основе программных продуктов, которые облегчают аналитикам доступ к данным. Для начала выясним, зачем аналитикам надо специально облегчать доступ к дан­
ным.
Дело в том, что аналитики — это особые потребители корпо­
ративной информации. Их задача — найти закономерность в большом массиве данных. Поэтому аналитик не будет обращать внимания на отдельно взятый факт (например, продажа конкрет­
ному покупателю отдельного товара). Одиночные факты в базе данных могут заинтересовать, к примеру, бухгалтера или началь­
ника отдела продаж, в компетенции которого находится сделка.
Аналитику одной такой записи мало — ему могут понадобиться все сделки за месяцы или годы. При этом аналитик отбрасывает ненужные ему подробности вроде ИНН покупателя, его точного адреса и номера телефона.
Технологии OLAP основаны на понятии х р а н и л и щ е д а н - н ы х. Приведем определение, сформулированное «основателем» хранилищ данных Биллом Инмоном. OLAP — это предметно­
ориентированное, привязанное ко времени и неизменяемое со­
брание данных для поддержки процесса принятия управляющих решений.
Данные в хранилище поступают из оперативных систем (OLTP) и из внешних источников — статистических отчетов, Интернета, прайс-листов и т. п. (рис. 5.8). Оперативные данные «очищаются»' интегрируются и сохраняются в реляционном хранилище. При этом они уже доступны для анализа, их можно использовать с помощью различных средств построения отчетов. Затем данные
(полностью или частично) подготавливаются для OLAP-анализа.
Они могут быть загружены в специальную БД OLAP или оставле­
ны в реляционном хранилище. Важнейшим элементом инфор­
мационно-аналитической системы являются м е т а д а н н ы е , т.е. информация о структуре, размещении и трансформации данных.
168

Рис. 5.8. Структура корпоративной информационно-аналитической системы
Благодаря метаданным обеспечивается эффективное взаимодей­
ствие различных компонентов хранилища.
Возникает вопрос — зачем создавать хранилища данных, со­
держащие заведомо избыточную информацию, если необходимые данные уже имеются в файлах оперативных систем? Еще несколь­
ко лет назад в качестве главных причин называли различие фор­
матов хранящихся данных, их разрозненность, локализация в разных местах корпоративной сети. Действительно, раньше хра­
нение всех данных на центральном сервере базы данных было редким явлением для крупного предприятия. Сейчас в связи с интенсивным внедрением интегрированных корпоративных ин­
формационных систем положение меняется. Но остаются прин­
ципиальными три причины необходимости создания хранилищ данных. Во-первых, сложные аналитические запросы к оператив­
ным данным «забирают» ресурсы сервера и тормозят работу ин­
формационной системы, надолго блокируя таблицы данных.
Во-вторых, оперативные данные малопригодны для непосред­
ственного сложного анализа. В-третьих, системы OLTP предна­
значены для оперативной обработки данных, поэтому они не приспособлены для хранения информации за длительный период, в то время как для OLAP интересен многолетний и многоаспект­
ный анализ объекта.
Итак, OLAP предоставляет «сырье» для анализа в простой, по­
нятной структуре, используя удобные быстродействующие сред­
169

ства доступа, просмотра и анализа деловой информации. Тради­
ционные отчеты, даже построенные на основе единого хранилища, лишены гибкости. Их нельзя «покрутить», «развернуть» или «свер­
нуть», чтобы получить желаемое представление данных. OLAP является удобным инструментом для многомерного анализа дан­
ных, накопленных в хранилище.
В основе OLAP лежит наглядная модель данных, организуемая самим пользователем, в виде многомерных кубов (гиперкубов).
Осями многомерной системы координат служат атрибуты анали­
зируемого бизнес-процесса — и з м е р е н и я (Dimensions). На­
пример, для продаж это могут быть вид товара, регион, контрагент.
В качестве одного из измерений используется время. Данные, количественно характеризующие бизнес-процесс, называются м е р а м и (Measures). Это могут быть объемы продаж в количе­
ственном или денежном выражении, товарные остатки на складе, издержки и т. п. Пользователь получает естественную, интуитивно понятную модель данных. Анализируя информацию, он может
«разрезать» куб по разным направлениям. Это дает возможность получать сводные или детальные сведения о бизнес-процессе и осуществлять прочие манипуляции, которые придут в голову пользователю в процессе анализа.
В качестве мер в трехмерном кубе, изображенном на рис. 5.9, использованы суммы продаж, а в качестве измерений — время, товар и склад. Измерения представлены на определенных уровнях группировки: товары группируются по видам, а данные о времени совершения операций — по месяцам. Чуть позже мы рассмотрим уровни группировки (иерархии) подробнее.
На самом деле с точки зрения математики кубом такой массив будет далеко не всегда: у настоящего куба количество элементов во всех измерениях должно быть одинаковым, а у кубов OLAP такого ограничения нет. Тем не менее, несмотря на эти детали, термин «кубы OLAP» ввиду своей краткости и образности стал
Рис. 5.9. Пример OLAP-куба
170

общепринятым. Куб OLAP совсем не обязательно должен быть трехмерным. Он может быть и двух-, и многомерным — в зависи­
мости от решаемой задачи. Особо искушенным аналитикам может понадобиться порядка 20 измерений, и серьезные OLAP-продукгы именно на такое количество и рассчитаны. Более простые на­
стольные приложения поддерживают около 6 измерений.
Однако куб сам по себе для анализа не пригоден. Даже трех­
мерный куб сложно отобразить на экране компьютера так, чтобы были видны значения интересующих мер. Что уж говорить о кубах с количеством измерений больше трех? Для визуализации данных, хранящихся в кубе, применяют, как правило, привычные двумер­
ные табличные представления со сложными иерархическими за­
головками строк и столбцов. Поэтому перед употреблением из многомерного куба извлекают обычные двумерные таблицы. Эта операция образно называется «разрезанием» куба. Аналитик как бы берет и «разрезает» измерения куба по интересующим его меткам. Этим способом аналитик получает двумерный срез куба и с ним работает. Примерно так же лесорубы считают годовые кольца на спиле. Соответственно «неразрезанными», как правило, остаются только два измерения — по числу измерений таблицы.
Определяющие принципы OLAP были сформулированы в
1993 г. Э. Коддом — «изобретателем» реляционных БД. Позже его определение было переработано в так называемый тест FASMI, требующий, чтобы OLAP-приложение предоставляло возможно­
сти быстрого анализа разделяемой многомерной информации.
Расшифруем аббревиатуру FASMI:
— Fast (быстрый) — анализ должен производиться одинаково быстро по всем аспектам информации. Приемлемое время от­
клика — 5 с или менее;
— Analysis (анализ) — должна быть возможность осуществлять основные типы числового и статистического анализа, предопреде­
ленного разработчиком приложения или произвольно определяе­
мого пользователем;
— Shared (разделяемой) — множество пользователей должно иметь доступ к данным, при этом необходимо контролировать доступ к конфиденциальной информации;
— Multidimensional (многомерной) — это основная, наиболее существенная характеристика OLAP;
— Information (информация) — приложение должно иметь воз­
можность обращаться к любой нужной информации, независимо от ее объема и места хранения.
Работа с OLAP-системами может быть построена на основе двух описанных ниже схем.
1.
Для «легковесного» применения подойдут OLAP-средства, встроенные в настольные приложения. Такие средства, как пра­
171

вило, имеют множество ограничений: на количество измерений, на допустимые иерархии и т. д. К подобным средствам, например, относится модуль Pivot Table, позволяющий работать с кубами в
Microsoft Excel. Pivot Table входит в Microsoft Office с незапамятных времен и до недавнего времени был единственным OLAP-npo- дуктом в его составе. В этом случае данные извлекаются модулем- клиентом непосредственно из реляционной СУБД.
2.
В «тяжелых» случаях применяют двухступенчатую схему
«клиент-сервер». Сервер обеспечивает непосредственно извлече­
ние информации из СУБД и все прочее, необходимое для создания кубов. Специализированное же приложение-клиент предназна­
чено для удобного (а главное — эффективного) просмотра кубов и выявления тех самых аналитических закономерностей. В линей­
ке продуктов Microsoft серверная часть представлена продуктами
Microsoft Analysis Services, которые входят в MS SQL Server. Срав­
нительно недавно в состав MS Office включен OLAP-клиент под названием Microsoft Data Analyzer.
В России разработкой технологий OLAP занимаются несколько компаний. Наиболее известный программный продукт — аналити­
ческая платформа Контур фирмы InterSoft Lab. Все большую из­
вестность приобретает модуль Галактика Zoom системы «Галакти­
ка». Отметим, что эти программные продукты получили междуна­
родное признание и благодаря привлекательному сочетанию цена/ качество заняли свою нишу на западном рынке OLAP-продуктов.
Наличие в ERP-системе «встроенной OLAP-аналитики» станет в ближайшие годы важным конкурентным преимуществом инте­
грированных корпоративных информационных систем.