- Я обещаю научить за 10 лет ишака всему Корану
- Ходжа, что ты говоришь?
Ведь, шах тебя обезглавит, если ты не
исполнишь свое обещание!
- Да, за 10 лет кто-нибудь помрет - либо шах,
либо ишак, либо я…

Вольное толкование старой притчи для внедренцев ERP

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

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

В чем же тогда проблема? Почему большая часть таких «серьезных проектов» кончается откровенной неудачей? Почему такие известные системы, как SAP, Oracle Financial, People Soft, не работают эффективно, по крайней мере, в нашей стране? Буквально месяц назад один очень серьезный начальник одной из самых известных в нашей стране компаний признался на переговорах - что в России нет нормально внедренных и эффективно функционирующих проектов SAP R3.

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

Почему же с упорством, достойным лучшего применения, все вокруг повторяют свои заветные «три буквы»? По какой причине этот начальник снова и снова инициирует внедрение SAP R3? Почему консультантам этих неработающих систем готовы платить зарплату, превышающую доход директора? Попробуем, если и не разобраться в этих вопросах, то, хотя бы взглянуть на проблему «с другой стороны».

Что же мы автоматизируем?

Группа специалистов реализует информационный проект
любой сложности по цене, ниже рыночной

Реальное рекламное объявление,
которое, наверное, кто-то принял всерьез.

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

Прошло десятилетие. Люди, принимающие решения, убедились, что «программа партии и программа телепередач» не подходит для их «самого мощного компьютера». Могучие сервера были загружены на полную мощность… Но, чем загружены? Весь персонал, от девочки-оператора до начальника отдела «заболел игрушками», сотни и тысячи часов рабочего времени были посвящены набору и распечатке анекдотов, Камасутры и рассказов Дейла Карнеги. Пришло время новых ожиданий, новых иллюзий. Наступила короткая эпоха АСУ и АРМ-ов.

Те, кому сейчас за 30, хорошо помнят это время. Наивные детские иллюзии, что еще немного, еще чуть-чуть и «снизойдет на нас АСУ». Новое обострение этой «болезни» пришло с широким распространением «персоналок». Помните lexicon, wd, первые, еще довольно корявые электронные таблицы, уже основательно подзабытые Multiplan, Lotus-123? А знаменитый FrameWork, который кое-где вполне серьезно рассматривался в качестве единого решения всех информационных задач (желающие «поддержать отечественного производителя» могут вспомнить «Мастер»)? История повторяется - и на новом этапе развития такие же «специалисты после двухнедельных курсов переподготовки» готовы с апломбом «решать все ваши проблемы» с помощью Excel или Access-а. А наиболее «продвинутые» к концу восьмидесятых знали слова FoxPro и Paradox (те, кто слышал про PAL, считались уже «совсем крутыми профессионалами»). Загляните на любой форум программистов. Устойчивое «дежавю» - так же, как 20 лет назад, апологеты 1С, Axapt’ы, Oracle, Delphi пытаются убедить собеседников (а, может быть, себя?), что они готовы решить любую задачу - проблема только в том, что заказчик сам не знает, что хочет.

До абсурда такая позиция была доведена в IT-отделе одной крупной фарм-компании, основной функцией которого было обслуживание, поддержка и развития биллинга. Реакция на вопросы финансистов была примерно следующая:

1. Наша задача - объяснить вам структуру данных системы, в каких таблицах хранится информация, какие поля несут смысловую нагрузку
2. Если вы хотите что-то посчитать, например, «отгрузку» или «дебиторку», вы должны мне написать ТЗ, указав из каких таблиц проводить выборку по каким формальным критериям
3. По вашему ТЗ мы пишем запрос и предоставляем вам результаты этого запроса. Кто отвечает за полученную картину? Конечно, вы сами - ведь, вы же определили и таблицы и поля и критерии выборки.

Оцените эффективность работы такого «транслятора»! Поневоле вспоминается бессмертная фраза - «Я лично пришивал пуговицы! К пуговицам претензии есть?»…

Прошло еще несколько лет. Такие «крутые пришиватели пуговиц» доблестно провалили свои проекты, и некоторые стали задумываться - в чем причина постоянных неудач? Новое время несло новые «розовые иллюзии». Вспомните, как вдруг стали безумно популярны IDEF, ERP, CRM - в зависимости от того, с чем столкнулся такой «специалист» или, что чаще, за продажу какого решения он получал свою «трудовую копеечку».

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

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

Как вы думаете, чем закончился проект? Правильно - прошел год, бюджет был благополучно освоен, результатов нет, и не предвиделось, а на повестке дня возник новый актуальный вопрос - «поиск крайнего». Вы удивлены? Автор, почему-то - нет.

Предлагаю на некоторое время стать «такими занудами», и попробовать хоть немного разобраться в ситуации.

Кратко назовем наиболее популярные «трехбуквенные сочетания»

В работах Оливера Уайта ( Oliver Wight ) и Американского общества по управлению запасами и управлению производством [APICS92] были сформулированы алгоритмы планирования, сегодня известные как MRP ( Material Requirements Planning ) - планирование потребностей в материалах - в конце 60-х годов, и MRP II ( Manufacturing Resource Planning ) - планирование ресурсов производства - в конце 70-х - начале 80-х гг. Не вдаваясь в тонкости методологии, подчеркнем суть подхода - «оптимальное планирование ресурсов, достаточных для производства продукции» .

Концепция ERP ( Enterprise Resource Planning - управление ресурсами предприятия ) предложена в начале 90-х годов аналитической фирмой GartnerGroup. Суть ERP - идентификация и планирование всех ресурсов предприятия, которые необходимы для осуществления продаж, производства, закупок и учета в процессе выполнения клиентских заказов .

Не претендуя на полноту, упомянем еще несколько «трехбуквенных аббревиатур»

CRM ( Customer Relationship Management ) - управление взаимоотношениями с клиентами

OPT ( Optimised Production Technology ) - оптимизированная технология производства

JIT ( Just - in - time ) - метод планирования и управления

Желающие могут легко продолжить этот список (например, CAD/CAM/CAE, PDM …).

Попробуем определить общую цель, объединяющую подобные методики.

В качестве «отправной точки» предлагается следующая формулировка « организация управленческого учета, обеспечивающего адекватную картину бизнеса и основу для принятия управленческих решений ».

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

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

Автор предлагает подумать не о маркетинге, а о сути - как правильно понять самое главное - определиться с предметной областью и постановкой задачи .

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

Иногда выбор очевиден. Если в серийном производстве основная проблема - бесконечно растущие запасы, надо думать о MRP. Торговой компании, определившей приоритет в расширении клиентской базы, следует присмотреться к CRM - решениям. Промышленные предприятия, обеспокоенные бесконтрольно увеличивающимися издержками, могут решиться на ERP - проект.

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

Если отбросить шелуху «рекламных иллюзий», «солидных рекомендаций» и «best practice», в сухом остатке окажется главная цель и задача внедрения информационных систем: « Обеспечить достоверную картину бизнеса, дающую основу для принятия управленческих решений ».

А все остальные доводы «вторичны». Большой проект не стоит затевать из-за «понтов» или по причине «все так делают». Во всяком случае, серьезный профессионал не должен попадаться на такую примитивную наживку…

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

Вывод : Основная задача проекта - построение адекватного финансового управленческого учета .

Кто такой «генерал Ледгер» и как он себя ведет в «реальной жизни».

Коль до гвоздя добраться трудно молотком,
его мы лазером по шляпку заколотим..

Гимн Аэромех-а

- А теперь, Ваше Величество,
извольте доказать следующую теорем…
- Месье, Вы - дворянин. И я - дворянин.
Дайте мне честное слово дворянина,
что этот треугольник равнобедренный…

Довольно распространенный метод принятия решений

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

Если задать этот вопрос продавцу «большого» решения, ответ будет примерно следующий

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

Кратко прокомментируем «покрытие функциональности основных бизнес - процессов предприятия». Какие процессы отнести к основным? Что выходит за «рамки покрытия»? Должна ли система обеспечивать прозрачность этих бизнес - процессов?

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

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

Автор с большим интересом познакомится с руководителем, который допустит бесследное исчезновение товара на складе или появление запасов «из ниоткуда». А как ответят на этот вопрос ERP - системы?

Предлагаю провести следующий эксперимент

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

Теперь проверьте в Excel или Access (автор пользуется MS SQL Server) соответствие остатков приходам и расходам. Делайте ставки, дамы и господа!

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

Такой эксперимент автор проводил года три назад с довольно популярной ERP-системой JDE (информацию можно найти, например, здесь http://vremya.org/jde.htm ).

Вопросами «откуда появилось 100 винчестеров на складе» или «куда делось 25 мышек» я довел команду консультантов до истерики. Профессионалы, 5 лет внедряющие JDE в различных компаниях, в течение 3 месяцев искали ответ на такие простые вопросы.

Поднимаю ставки до 20 к 1 - готовы спорить со мной внедренцы SAP R3 или Oracle Financial? Может, среди консультантов Axapta или Exact найдутся спорщики, готовые рискнуть сотней долларов?

Теперь посмотрим ситуацию с «интегрированным решением».

«Интеграция» заключается в сборе информации со всех модулей (продажи, закупки, склад, производство) в главную книгу - GeneralLedger(GL).

Попробуйте задать вопрос - соответствует ли информация GL первичным документам модуля - источника? Уверены, что да? А как насчет ручного ввода проводок в главную книгу? Коррекции сумм? Исправления первичных документов по закупке?

Уверяю вас, что соответствующий эксперимент на реальных данных приведет к очень интересным результатам.

Теперь спросим консультантов - а можно ли в вашей ERP-системе адекватно отразить «все наши бизнес-процессы»? Вы уверены?

Расскажите, пожалуйста, схему автоматического определения соответствия возвратов от покупателя и отгрузок (если не было такой отгрузки, то откуда возврат?). А если возврат соответствует трем отгрузкам? Что, это соответствие устанавливается «вручную»?

Как происходит расчет НДС? Что - в Excel или в бухгалтерской программе?

Как реализован бартер (частичный зачет поставок, услуг и прочее, прочее, прочее)?
Что - опять «вручную» или в GL без проведения документов по модулям закупка и продажа?

Можно ли рассчитать налог на прибыль и отложенные налоговые активы и обязательства?…

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

А сколько таких вопросов «остались за кадром». Десятки? Сотни? Тысячи?

Неужели все эти процессы несущественны?

А представьте задачу управления холдингом, предприятия которого разбросаны по всей стране. Если уж в центре самые простые и актуальные проблемы не имеют удовлетворительного решения в рамках системы, что же делать с филиалом в Томске или Благовещенске? Переносить всю «головную боль» в регионы, умножая бардак местной спецификой, недостаточной квалификацией и слабой управляемостью?

Вывод : Системы класса ERP могут эффективно решать только «специализированные задачи». Внедрение полноценного учета требует других технологических инструментов .

И как же они, все-таки работают?

Больше всего астронома мучил вопрос -
Как же ученые узнают названия звезд?

Все не так плохо, как есть на самом деле
Иначе - разве было бы так хорошо,
как нам кажется?

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

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

Вариант 1 - у нас все в системе, но баланс «в Excel».

По имеющейся у автора статистике более двух третей реально работающих систем класса ERP не используются как инструмент формирования баланса.

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

Последний шаг - получить адекватный баланс (General Ledger) натыкается на непреодолимые препятствия. Попытка свести (хотя бы проконтролировать!) итоги отчетного периода приводит к многочисленным «дырам в учете».

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

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

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

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

Диапазон применяемых решений довольно широк.

Приведем наиболее популярные

1. Отчетные формы создаются в таблицах Excel.
   Заполняются в большинстве случаев «вручную». Наиболее «продвинутые» импортируют сводные данные из учетных систем (ERP, бухгалтерия), но «ручная доводка» необходима.
   По неофициальной статистике такие решения составляют 60-70%.
   И эта картина неявно признается аудиторами и консультантами.
   Ведущие компании (в т.ч. из «большой четверки») постоянно проводят семинары на тему «Использования для подготовки финансовой отчетности таблиц Excel».
2. Отчетные формы «автоматизируются на коленках».
   Намаявшись с десятками, а то и сотнями, Excel-ей, данные которых постоянно не сходятся, финансовые службы кое-как сами «механизируют процесс». Поскольку среди таких специалистов редко встречаются IT-профессионалы, диапазон решений весьма специфичен - чаще всего это слабо связанные между собой приложения Access (иногда - надстройка над Excel).
   Консультанты и аудиторы» редко воспринимают такие решения серьезно, хотя, по сравнению с рекомендуемым (см предыдущий вариант), в этом случае надежность и достоверность «генерала ледгера» повышается и (если разработкой руководил специалист, профессионально разбирающийся в финансовом учете) иногда весьма существенно.
   Подобного рода решения встречаются примерно в 20% случаев.
3. Консолидация в учетной системе
   Понимая необходимость технологического контроля основных учетных принципов (прежде всего - непрерывность, целостность и двойная запись), примерно в 5-10% финансовые службы пытаются организовать консолидацию и получение финансового баланса в единой системе. Обычно попытки начинаются с модуля GL «родной ERP». Результаты такого подхода чаще всего, более, чем скромные.
   Тогда (особенно, если CFO привык к «своей учетной системе») делаются шаги к внедрению «какой-нибудь бухгалтерии», обычно российской - 1С, Парус и т.п.
   Организуется импорт первичных данных (иногда - сводных, изредка - по операциям), потом результаты «корректируются под честное слово CFO».
   В чем же проблема такого подхода? Прежде всего, в «закрытости решения».
   Процедуры импорта, написанные программистом, считаются «черным ящиком». Никто, кроме разработчика (а очень скоро и он сам) не может толком понять взаимосвязь многочисленных процессов «внутри импорта». Намучившись год-два с никому непонятными «соплями и доработками», участники проекта предпочитают не «возиться с автоматизацией», а сводить баланс «руками» в той же 1С. Проблемы опять повторяются...

Вариант 2 - у нас все в системе, «как в Excel».

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

Потерпев неудачу в «полноценном внедрении ERP» (или просто не начав проект), финансовая служба находит следующий выход

1. Оперативная отчетность формируется «внешними средствами» - чаще всего итоговые формы заполняются вручную (иногда делаются попытки механизации - см. выше).
2. Данные отчетных форм вручную вносятся в GL(как вариант - отчетные формы импортируются в систему).

Думаю, такое внедрение ERP «для галочки» вряд ли можно рассматривать в качестве серьезного проекта. К получению адекватного баланса эта технология не имеет никакого отношения.

Так что же посоветовать?

Попробуем не «изобретать велосипед», а разобраться в проблемах и « рекомендациях ведущих стоматологов ».

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

«Дорожная карта» проекта будет иметь примерно следующий вид:

1. Сбор исходной информации обо всех хозяйственных операциях.
2. Первичная классификация (с обязательной обратной связью!), выделение основных бизнес - процессов. Обязательный разбор всех первичных данных (!).
3. Трансформация данных в соответствие с учетной политикой и учетной схемой.
   Формализация бизнес - процессов в терминах плана счетов и аналитик финансового учета. Расчет сальдо балансовых статей - активов и пассивов.
   Технологический контроль базовых учетных принципов.
4. Дополнительные расчетные модули - переоценка ОС, расчет резервов, accruals и пр. в соответствие с учетной политикой и учетной схемой финансового учета. Формирование General Ledger (обязательная связь с источником данных - первичных и расчетных!).
5. Формирование финансовой отчетности - оперативной и итогового пакета.

Как вы думаете, какой инструментарий наиболее адекватен поставленным задачам?

Excel или Access? Модуль GL ERP или пакет консолидации с невозможностью разобраться во «внутренностях бизнес - процессов»?

Или, все-таки, наиболее эффективен инструментарий, предназначенный именно для работы с данными?

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

Все дороги ведут к хранилищу?

Карфаген должен быть разрушен!

Постоянно повторяющаяся «повестка дня».

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

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

А при «грамотно» реализованной «дорожной карте» «подхватить процесс» может практически любой профессионал - информационщик. Модульная композиция позволит эффективно развивать любую часть такого проекта и оперативно модифицировать и даже менять первичные системы. Сомневающимся предложу сравнить количество и стоимость специалистов настройки модулей SAP R3 и/или владеющих инструментарием РСУБД.

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

Естественно, такое Хранилище не вполне соответствует определению DataWarehouse , введенном в 1992 г Биллом Инмоном (предметно-ориентированный, интегрированный, неизменчивый, поддерживающий хронологию набор данных, организованный для целей поддержки управления).