Концептуальные основы системы Алеф

Аксёнов Е.Г.

Добрый день. Сейчас будет три доклада, в которых мы рассмотрим продолжение вчерашнего разговора о концептуальных основах, прикладных аспектах того, что мы делаем, каким образом, как устроена система, какие решения существуют и т.д. Вчера, если вы помните, был зафиксирован один очень важный тезис, что существует оперативный уровень и существует некая модель, иногда её называют метамоделью хозяйственного состояния субъекта деятельности. Суть заключается в том, что если большинство систем, которые называют документоориентированными или как-то иначе, они непосредственно и сразу реагируют на возбуждение внешней среды или какие-то реакции на процессы, выполняют непосредственно в слое оперативном. И второй подход, который имеет право на существование и мы доказываем это своей практикой. Когда есть оперативный уровень, он воспринимает возбуждение среды, интерпретирует это в какую-то модель, на основании других параметров, метрик, регистров, как угодно можно называть это, выполняется анализ состояния, если точка решения условиям шага удовлетворяет состоянию определенных регистров, то процесс может идти дальше и т.д. Речь идёт о том, что существует защищённая область, которая как внутренний мир, она подвластна нашим с вами решениям, а внешний процесс во многом зависит от внешней среды, от того, что мы должны удовлетворять не только нашим решениям, но и требованиям рынка, заказчика, клиента, как угодно. Если посмотреть на второй более сложный подход, то он разворачивается в аспекте информационных технологий следующим образом. Есть какое-либо возбуждение. Это возбуждение может приниматься, либо документооборотной системой, либо другой. Александр Игоревич гораздо шире понимает термин Workflow, здесь я, в данном случае, имел в виду управление потоком документов. Возбуждение воспринимается на каком-то оперативном уровне, потом трансформируется в модель, и влияет на ход процесса, или влияет на структуру процесса опосредованно, через интеллект аналитиков, через обработку информации.

Существует целый ряд технологий, которые предназначены для решения частных вопросов данной концепции. Системы управления документами, Date Warehouse среды, которые хорошо работают с большими массивами многомерных данных, инструменты Extract Transform Load позволяют собирать информацию из разных систем и загружать её в модель. Инструменты Data Mining позволяют анализировать, искать зависимости, о которых мы раньше не знали.

Вчера мы остановились на том, что существует большое количество проблем, и статистика подтверждает это, потому что даже проекты по Date Warehouse в большинстве своём терпят крушение. И проблемы эти я выделил в единый список, хотя вчера они были разделены на методические, технологические и политические. Политические дальше рассмотрит Лев Тришанков, когда будет рассказывать о внедрениях. Здесь мы рассмотрим только методические и технологические проблемы. И первая из них – это построение тезауруса системы. Мы с вами только что слушали докладчиков из компании "Весть Метатехнология" и у вас должно было фиксироваться, мне хотелось бы, что бы это зафиксировалось, что, сделав это обследование, мы с вами вышли на тезаурус, мы вышли на понятия, на словарь. В переводе это означает сокровища это действительно сокровище, это то, что определяет, будет ли успех у проекта или не будет. Если мы не сумеем убедить людей, что им нужно договориться, то, безусловно, проект будет неудачным. Это моё мнение.

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

Выбор релевантной информационной технологии. Вы представляете, если посмотреть на любой элемент того, что было на прошлой в схеме, Data Mining, Date Warehouse, то это уже огромной сложности инструментарий, который в результате большого объема технических знаний, которыми нужно обладать, способны перевернуть проект. Серьезным вызовом является для внедряющих.

Минимизация вычислительных ресурсов для обеспечения оперативности. То, чего лишены оперативные системы - это процесс интерпретации. Они не линейны. Они, как правило, что-то с данными делают, как-то собирают их, преобразовывают и загружают. Этот процесс вполне серьёзная проблема и требует больших ресурсов. Как нам сделать так, чтобы мы могли использовать эту технологию, причём в наших условиях? Даже если мы не знаем точных цифр, примерно мы можем предположить, а точные цифры тоже известны, объемы финансирования подобного рода проектов на западе и мы понимаем, что не можем сейчас рассчитывать на такие бюджеты. Поэтому наша задача очень интересная. С одной стороны мы хотим использовать полностью концептуальную картину описанного выше, с другой стороны мы поставлены в такие жесткие рамки которые практически, если смотреть невооруженным взглядом, не оставляют нам пяточка для выигрыша. На самом деле мы хорошо вооружились нашим опытом и постарались всё-таки найти, ту самую маленькую лазейку, где можно построить такую систему, используя подобный подход.

Давайте посмотрим на эти уровни более подробно. Контроль прохождения этапов процесса. Оперативная разработка данных, преобразование, хранение и построение модели Data Mining . И первым пунктом там было наличие тезауруса, как проблема и как задача. Обратите внимание, что по мере нашего опускания вниз изменяются термины. Здесь термин данные, здесь информация, дальше знания, о которых говорил Александр Игоревич. Я не буду трогать управление знаниями, я сейчас хотел бы сконцентрироваться на другом. Но мы с вами видим, что из данных оперативного уровня мы получаем информацию в модели. Именно тогда когда эти данные будут связаны, будут осмыслены и объединены в единую концепцию, они станут для нас информацией. Что является ключевым термином в этом смысле? Для меня это знание о знании, это тот наш тезаурус, который мы должны создать. Это язык системы, его семантическое наполнение. Это клей, связывающий информационные системы и обеспечивающий взаимопонимание подразделений подсистемы. Система до тех пор не станет системой в полном смысле этого слова, пока она не будет пронизана единой семантикой, единимым семантическим полем. Смотрите сколько элементов у нас затронуты, связаны с метаданными. Это, конечно же, восприятие, рецепторика, это конечно же обмен, общение между документооборотными средами и оперативными средами обработки документов, это конечно же BPL инструментарий преобразований. Метаданные, по сути пронизывают всю систему. Давайте посмотрим, что является проблемой, почему так сложно построить единый тезаурус, единое семантическое поле. Прежде всего, высокая динамика контента. Недостаточно один раз зафиксировать картину мира. Надо постоянно с ней работать, уточняя, подстраивая, сопровождая. Система требует постоянного сопровождения, единая система управления. Проблема не в машинах, проблема в человеке и в среде.

Конечно, очень сложно выработать некую формальную логику, чтобы она позволила нам описать мир. Попытки такого рода осуществляются и вполне успешно. Если мы с вами заглянем в недра нашего компьютера, то увидим, что практически на каждом компьютере, где стоит SQL сервер, как бы нечаянно уже стоит Oracle Information, на основании которой в ближайшем будущем будут автоматизированы процессы Plug and Play, автоматизирована интеллектуальная подстройка приложений. Но она не выходит на уровень предметной области, это тот уровень, где нам с вами надо выполнять авторские вещи, чтобы решать наши проблемы.

Третья позиция – это островное мышление, это уже уровень корпоративной культуры. И до тех пор, пока люди будут жить за теми кирпичными перегородками, которые были представлены на слайдах компании "Весть Метатехналогия", где перегородки разделяют процессы, до тех пор, пока корпоративная культура будет признавать эти перегородки, нам с вами будет очень сложно.

Конфиденциальность. Где граница между секретом и незнанием? Сложно понять пока не узнаешь секрет. Поэтому часто на своей практике я за тяжелыми решетками конфиденциальности находил безграмотность. Дай бог, чтобы в вашем случае это было не так, но могут быть некие подозрения и опасения на этот счет. Модульный подход, технологические ограничения - эти вещи связаны с архитектурами информационных систем, с действительно той сложностью, которая сопровождает наличие тезауруса. Каким свойствам он должен удовлетворять? Прежде всего, он должен быть на столько полным, чтобы описать те явления, причём формально описать, те явления, которыми мы собираемся управлять. Расширяемость – конечно, мы будем целенаправленно с вами заниматься тем, что уточнять, улучшать эффективность управления, поэтому будем знать больше и больше. Нам надо создавать такой тезаурус, таким образом строить систему метаданных, чтобы нам было достаточно легко вносить изменения и уточнения, чтобы не было каскадных изменений. Если мы говорим об оперативных системах, документоориентированных, или как D2D их сейчас называют. Когда один документ работает непосредственно со структурами данных другого документа или третьего, количество этих связей падает, становится больше и больше по мере развития системы, и если нам с вами надо что-то изменить в одном документе, мы попадаем на каскадное изменение всей информационной системы. Это один из серьезнейших недостатков оперативного подхода, что он хорошо работает в устойчивых средах с малой энтропией.

Адекватность, согласованность, непротиворечивость. Методология, которая была изложена вам в первой половине, она как бы, по-моему, посвятила адекватности, согласованности, непротиворечивости достаточно большое время и я говорить об этом не буду. И что очень важно - оформленность среди стандартов. Сейчас произошел откат инвестиций из интернет-интранет технологий и как бы с одной стороны очень жаль, а с другой стороны я считаю, что основное дело на данном этапе сделано. Родилась XML-технология, родилось понимание необходимости стандартов, чтоб взаимодействовали в электронном бизнесе разные предприятия. И это очень важно, то, что появилась такая технология, и то, что принято это как стандарт, а не как частная инициатива. Стандарт языка – это основа построения корпоративной информационной инфраструктуры. Наше мнение такое, что тезаурус должен быть предъявлен и сформирован в той форме, в которой каждая из подсистем может обратиться к нему непосредственно, и, используя терминологию тезауруса получить необходимую информацию. Т.е. с модулем взаимодействует не непосредственно, а опосредованно, через метаданные, через термины которые для всей системы приняты как публично зафиксированные и понятные каждой из подсистем.

Стандарт языка - основа построения отраслевой и межотраслевой информационной инфраструктуры. Александр Игоревич говорил о B2B, B2C технологиях и определенная инициатива в этом направлении существует и у нас. Это связано с поставкой леса, корпоративные порталы у нефтяников, прокатчиков металла, которые занимаются прокатом металлов. Существует уже локальные корпоративные межотраслевые, отраслевые стандарты. Они, конечно, не вполне развиты, но это есть уже платформа для дальнейшего развития. Самое важное, что существует XML - то средство, которое, безусловно, лидирует сейчас в качестве фиксации, описания и технологической части использования стандартов. XML - это вещь вполне известная, но что я хотел сказать по этому поводу. Это расширяемая основа для построения стандартов тезауруса. Вполне легко расширяется и у нас есть достаточно большой опыт его действительно практического использования, и разочарований нет. Одновременно он является хранилищем описателей предметной области и основой для описания многомерных фактов. Дальше мы будем рассматривать это подробнее.

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

Какие требования у нас к модели? Мы говорили раньше: согласованность, непротиворечивость, адекватность, полнота и расширяемость. Если мы говорим о недостатках оперативных систем, что слишком много связей, они плохо работают при высоких энтропиях, значит, мы должны как-то сказать, что этот наш путь вылечит, позволит разрешить эту ситуацию. Давайте повнимательней посмотрим из чего состоит модель, что это такое. На наш взгляд, это уже наше мнение здесь мы уже начинаем говорить об Алефовском подходе, о подходе компании "Алеф консалтинг & софт". На наш взгляд модель есть многомерный вектор типа изображенного здесь. И не один, а целый комплекс согласованных между собой векторов. Легко заметить, что есть некая общность между кубом, который мы изображаем как иллюстрацию многомерного факта, таблицы фактов в любом хранилище данных, знаменитая звезда и многомерный вектор. Конечно же, есть определенная общность и поэтому мы говорим, что для хранения модели, хранения информации о состоянии наиболее релевантна, наиболее уместна технология DataWarehousing. Многомерные аналитические углы обеспечивают сбор информации о многомерных фактах хозяйственной деятельности, предоставление данных по запросам, причём оперативное предоставление информации по сложным аналитическим запросам. Обеспечение надежности, конфиденциальности хранения данных, необходимая степень денормализации. Есть два пути: как бы путь нормальной модели, который принят в оперативных системах и который решает проблему аномалии одновременно, и путь денормализованных систем – это две границы, абсолютно нормальные системы и абсолютно денормализованные. Не всегда есть буддийский средний путь тот, который мы выбираем и получаем эффект. Каким образом связаны эти параметры, углы, таблицы фактов? Мы, это наше мнение, наш путь, чтобы снизить энтропию модели, чтобы не ставить проектировщика перед неограниченным выбором мы сказали, что давайте примем закон сохранения энергии, закон сохранения как некое ограничение при создании модели. Т.е. у нас есть параметры, мы говорим, что в какой-то области эти параметры всегда приводят к нулевому изменению, т.е. если один параметр увеличился, то другой уменьшается на соответствующее изменение, единицу. И, конечно же, разные процессы должны жить в разных областях замкнутости, поэтому сама модель она является комплексом. Например, если мы имеем планирование или обработку товаро-движений, направлений, о которых Лев будет говорить позже – это один замкнутый комплекс, если мы имеем в виду учет бухгалтерский или управленческий - это другой, третий. Может быть много таких областей, объединение которых составляют ту самую полную модель хозяйственной деятельности. Как мы уже говорили очень хорошая технология, которую можно использовать для реализации такого подхода – это DataWarehousing. Т.е. два тезиса прошу фиксировать: первое – то, что XML – это практическая реализация тезауруса, DataWarehousing (многомерные кубы) – это практическая реализация технологии для хранения многомерных данных, наиболее релевантна на наш взгляд.

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

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

Как мы встраиваем стандарты? Мы с вами провели обследование не каким-то образом получили этот стандарт, причём не было сказано, а это на мой взгляд критично и важно, что системы моделирования, в том числе и ARIS, они умеют экспортировать результаты моделирования в стандарт XML, и получив на входе в систему Алеф такой стандарт, система автоматически его встраивает, формирует структурный справочник на основании этих стандартов, создает шаблоны, позволяет определить связи документов, полей с элементами стандарта. Т.е. она встраивает, создавая адекватные архитектуры внутри - это происходит автоматически. Для этого служит термин Алеф, в нашей системе это называется термин, обеспечивающий единый язык системы, ввод-вывод данных, потому что термины Алефа работают не только как внутренняя связующая нить или цепь, они также работают с внешним миром. Есть несколько примеров, где XML используется нашими клиентами, и это намного оказалось эффективнее, чем использовать даже репликацию, даже если объемы данных велики. Одним из примеров может быть Бургаз - это Газпромовская точка, которая отвечает за бурение за все исследования почв, грунтов и построена аналитическая система, сбор аналитических данных в бухгалтерском учете, в управленческом учёте, где передача между филиалами данных производится на стандарте XML. В данном случае использован корпоративный стандарт, который был создан на основании наших рекомендаций.

Формирование аналитики регистров. Когда мы говорим о многомерном факте, понятно, что в качестве его элементов этого вектора используется тоже элементы тезауруса. Поэтому когда мы формируем кубы, регистры модели, то мы используем те же самые элементы. Никаких других нельзя использовать. Если вам важно посмотреть многомерный вектор в разрезе ещё одного измерения вы должны будете ввести это в стандарт, создать соответствующую инфраструктуру. Только после того система даст возможность определить вам это как измерение, как размерность. Большинство из тех операций, о которых я сказал, делаются автоматически. Достаточно дополнить стандарт и все это прошивается вниз.

Работа с терминами выглядит таким образом. Здесь иерархия. После того как стандарты импортированных систем, автоматически генерируются термины системы, и они привязываются к полям документа, который один или несколько работает в качестве представителей данного термина (контрагент, счёт, адрес).

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

Ключевая вещь для работы с информацией пользователей в системе "Алеф" – это документы. В самом деле, система вполне является мощным, самостоятельным средством для создания оперативных приложений, где можно создавать не только оперативные приложения. Никто не заставляет вас использовать полный концептуальный подход, но мы его рекомендуем, потому что видим, насколько эффективно его использование. Документы позволяют создавать формы документов, регламентировать доступ, получать документ, который является посредником, он может доставлять запрос или информацию о состоянии модели, потому что просто пойти в многомерные таблицы и увидеть огромные массивы данных это вряд ли полезно, это не нужно никому. В документе с помощью программного интерфейса достаточно легко можно получить необходимую информацию. Есть целая система хранимых запросов, которые автоматически генерируют и используются для заполнения документов. Но это частности, об этом не хотелось бы сейчас говорить. Что очень важно, документ кроме презентационной роли, выполняет роль управления бизнес-логикой, потому что у документа есть свои алгоритмы, скрипты, по разным событиям, которые оживляют, позволяют вырабатывать реакцию автоматически.

Вот главный экран системы, куда попадает пользователь. У него есть папки, которые мы для него подготовили в соответствии с правами доступа. Эти папки могут быть статические, обновляемые, то есть если у вас изменился статус какого-то документа или какое-то поле вы можете его автоматически предоставить пользователю, указав для обновляемой папки соответствующий фильтр. Это список документов в данном случае запас по дате и меню, которое в контексте меню зависит от прав человека, от его прав на выполнение функций. Система позволяет создать список полей (а мы с вами договорились, что список полей наследуется из тезауруса) позволяет разработать структуру, форму документов, функциональный набор, справочники, связи, статические и динамические. Всё это пунктиром прохожу, потому что хочу, чтобы мы передали вам сегодня какой-то общий взгляд на систему и в частности на детали. Тут же можно нарисовать формы, сместить, отредактировать, как должна выглядеть; печатная, экранная формы, которые работают на входе и выходе. Это вещь верхнего уровня, определяющая поведение оперативного слоя.

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

Как нам с вами заполнить эти регистры? Ведь я уже сказал, что связь может быть не однозначна, не линейна. И достаточно сложно бывает, например, имея дело с аналитическими системами, наверное, вы сталкивались постоянно с процедурами адаптации, локирования. В целях аналитического учета, скажем одну сумму как-то распределить и эти рассеивания, распределения данных это всё нужно обслужить автоматически, чтобы не выполнять с помощью достаточно сложных алгоритмов. Эти задачи мы и поставили перед блоком "типовые операции", который отвечают за то, как информация из документов из оперативного слоя будет загружаться в аналитические регистры. Все эти сервисы там существуют и позволяют вам с помощью интерфейса определить, какие будут созданы изменения, на каких регистрах, какие способы адаптации будут выполнены и каким образом.

Тем о чем я вам сказал, мы занимаемся восемь лет, мы существуем с 93 года и за это время мы применили систему Алеф для автоматизации планирования, логистических схем, в частном случае – снабженческих, производственный учёт, бухгалтерский. Очень много разных задач мы решили с помощью этого подхода, который был изложен. Мы и наши партнёры. Должен оговориться, что наш бизнес партнёрский, и мы строим это именно по законам партнерского бизнеса, сами мы выполняем 30% проектов, а 70% наших проектов выполняют партнеры, которые существуют, в том числе и в Кирове. Компания "Торнадо Бизнес Технология" является одним из них и вполне на хорошем счету, потому что специалисты прошли достаточно давно уже сертификацию, успешно сдали экзамены и выполняют проекты. Мы работали сами в производстве, в торговле. В торговле выполнено много проектов, причём если в производстве сложность именно в нюансах технологии, которые мы должны как бы отразить на этих векторах, то в торговле, как и в снабжении об этом будет Лев говорить, достаточно сложная структура этих областей, моделей замкнутых. Потому что важно контролировать сразу несколько процессов. Причем, например, в фармацевтике они синхронизированы, и очень важно одновременно их поддерживать состояние. Мы будем подробнее об этом говорить. Большой опыт у нас есть в энергетике и в ценных бумагах, я вчера уже об этом говорил там, где важно очень быстро реагировать на изменения, на события документооборота. Это некоторые наши клиенты, проекты, которые либо завершены, либо существуют гарантии их успешного завершения. Достаточно эффективно решается задача в энергетике. Потому что это оказался сектор для нас очень интересным, по соотношению цена-качество. Уж так случилось, энергетика сейчас не лучшие времена переживает, но, тем не менее, для обеспечения успешности проектов важно вписываться в те бюджеты, которые существуют, и дать ту адекватную поддержку техническую тем проблемам, которые существуют в энергетике. Надо сказать очень сложным.

Здесь вы видите группу компаний "Видеоинтернешнл", это проект так же очень интересный тем, что построена была система управленческого учета для 49 предприятий. Основная задача, основная проблема клиента, а соответственно наша задача состояла в том, чтобы обеспечить ежедневную консолидацию учета. Это тяжелейшая была задача, потому что объемы данных были колоссальны, но, тем не менее, она была решена. Каждый вечер в стандарте GAAP на стол руководителю клали все данные. ЦБ РФ, Росуголь, Бургаз - это все предприятия, на которых совершенно разные были решены проблемы.

На сём я откланиваюсь, спасибо за внимание. Я предоставляю слово Льву Тришанкову, он расскажет уже о практическом приложении того, о чём мы говорили и тогда, наверное, вопросы можно будет задавать нам двоим. Спасибо.