Построение распределенных логистических систем.
Первый проект по построению логистической системы для одного из крупнейших поставщиков телекоммуникационного оборудования компания “Алеф” выполнила в 1995 году.
Решение было выполнено в рамках технологии “клиент-сервер”. Тогда в качестве сервера мы использовали MS SQL 4.21, а клиентская часть была разработана на Power Builder, тоже версии 4.
Система строилась от насущных потребностей бизнеса и являлась, по сути, исключительно средством автоматизации бизнес процессов Заказчика:
- складских операций;
- операций товарного терминала;
- поддержки гарантийных ремонтов;
- Прием заявок, формирование заказов поставщику;
- Управление сделками.
Система представляла собой вполне гибкий конструктор. В нее достаточно легко можно встроить новую схему взаимодействия с клиентом, определить новые режимы выставления счетов, ожидания платежей, формирования спецификаций.
Для ее адаптации к новым условиям крайне редко приходится прибегать к исходным текстам, так как уровень настраиваемости системы был достаточно высок.
Для обслуживания такой системы в крупной компании необходима 1-2 штатная единица.
Кроме того, она крайне нетребовательна к вычислительным ресурсам.
Система эксплуатируется в компании по сей день и вполне устраивает заказчика.
Но мы решили никогда больше не создавать таких систем.
Почему:
- Архитектура системы строится от процесса. – Есть процесс и надо автоматизировать его выполнение. С ростом сложности и с ростом обслуживаемых процессов процессно-ориентированные системы все дальше уходят от четкого представления о хозяйственной деятельности как единого целого и все более похожи на набор сервисов для выполнения различных оперативных процедур.
- Процессно-ориентированные системы крайне сложно совместимы с другими подсистемами предприятия (финансовые, бюджетные). Технологическая несовместимость уже не является такой большой проблемой как было раньше. На первый план выходит семантическая несовместимость: процессы разные, критические параметры разные и смежные вопросы проработаны поверхностно, по сравнению с автоматизируемыми процессами.
- 
Крайне сложно управлять достоверностью получаемых результатов. Речь идет не об ошибках в количестве товаров на складе, а о достоверности сфокусированной картины деятельности, о совместимости отчетов различных подсистем. Процессно-ориентированные системы не дают представление о хозяйственной деятельности в целом (хобот слона, хвост слона, нога слона). Поэтому крайне сложно формировать картину хозяйственной деятельности, а тем более управлять ее достоверностью.
- Сложность поддержки преемственности данных во времени. Процесс меняется во времени. Следовательно картина прошлого, настоящего и будущего несопоставима. Как же в этом случае поизводить исторический анализ, анализ трендов. Остается единственный путь для анализа – создание хранилищ данных. Это попытка строить модель хозяйственной деятельности, но в off-line. Мир сейчас трудно пропробывает эти варианты. Там свои бюджеты и свои проблемы: сбор данных, сопоставление, приведение к единому виду. Но по-прежнему крайне сложно управлять достоверностью, оценить возможную погрешность и т. д.
Но жизнь-то требует иного. Картина деятельности стремительно усложняется.
- Увеличение адаптивности систем. Необходима адаптивность системы к изменчивым контекстам деятельности, изменениям в бизнес-процессах
- Обеспечение поддержки реальной распределенности:
o территориальной распределенности;
o системной распределенности;
o административной распределенности.
Ведь процессы все чаще затрагивают более одной информационной подсистемы, принадлежащей, или формирующей критические данные о хозяйственной деятельности, более чем для одного бизнес образования.
Что же нужно, чтобы в стремительно усложняющейся картине хозяйственной деятельности, не потерять контроль над происходящим, научиться адаптироваться без кардинального пересмотра основной семантической структуры предметного уровня, научиться “разговаривать” с другими системами?
Для этого нужны:
- общий язык. Стремительно наступает время протоколов взаимодействия систем предметного уровня;
- отказ от исключительно ориентации на процесс при построении архитектур логистических и прочих специальных информационных подсистем. Необходима фокусировка на устойчивой модели хозяйственной деятельности, в определенной степени абстрагированной от реальных бизнес процессов.
На наш взгляд именно семантика и модель должны быть поставлены во главу угла при проектировании систем.
Ведь если нет общего языка, а язык жестов недоступен, то договориться практически невозможно.
Конечно, в процессно-ориентированных системах также используются некие зародыши модели - регистры общего пользования. Но, как правило, их появление объясняется технологическими мотивами. Отсутствует методически обоснованный подход их формирования и установления взаимосвязи.
В процессно-ориентированных системах, говоря языком психологов, мы имеем только старт-рефлекторный уровень – отдернутая от чайника рука.
Подход, который используется в компании “Алеф” направлен на создание нового уровня отражения хозяйственной деятельности – явное выделение уровня модели в отдельный архитектурный слой.
Мы реализуем этот подход при решении логистических задач, задач финансового учета и планирования.
В рамках этого подхода параметры, характеризующие хозяйственное состояние предприятия, представлены в виде сгруппированных и согласованных между собой многомерных векторов, в качестве размерностей которых используются качественные харакетристики параметра, представляющие понятия предметной области.
Например, состояние склада может быть охарактеризовано следующим многомерным параметром:
Состояние Склада = Состояние Склада (Дата, Склад, Товар, Партия, Заказ, Требование, Количество, Сумма)
Это означает, что состояние склада будет описываться следующей таблицей:
Дата | Склад | Товар | Партия | Заказ | Требование | Количество | Сумма |
1/01/2002 | 1 | 2 | 134 | 432 | 3432 | 35656 | |
2/01/2002 | 2 | 2 | 453 | 4534 | 53455 | ||
1/02/2002 | 1 | 2 | 456 |
Процессно-ориентированные структуры данных (в терминах Алефа - документ) сами по себе уже не являются единственным носителем информации. Оперативно корректируемые параметры модели в этом случае содержат необходимую информацию о состоянии каждого склада, размещенных у поставщика заказов, принятых заявок и т. пр.
Параметры позволяют строить опосредованные связи между документами и процессами – связи типа "документ-параметр-документ".
Практически все приложения, поддерживающие оперативную деятельность, имеют отдельные регистры для хранения информации о состоянии склада, принятых заявках, размещенных заказах в различных разрезах. В нашем подходе принципиально то, что эти регистры рождаются при проектировании согласованной модели хозяйственной деятельности, а не какого-либо частного бизнес-процесса или группы бизнес-процессов.
Создавая с помощью параметров модель хозяйственной деятельности мы получаем еще более мощного посредника – модель. И в этом случае мы уже получаем информационную структуру, намного более защищенную от превратностей текущей внешней среды, более консервативную, позволяющую строить более устойчивые связи типа “документ-модель-документ”.
При автоматизации сложных хозяйственных процессов, количество трансформаций количественных и качественных характеристик весьма значительно.
Каким же образом связать параметры модели, чтобы обеспечивалась непротиворечивость их состояния?
Для обеспечения надежности информации мы воспользовались опытом итальянского математика фра Лука ди Борго сан Сеполькро (Лука Пачиолли), жившем в XIV веке.
Лука Пачиолли для описания хозяйственных процессов предложил использовать параметры, выбранные и сгруппированные таким образом, чтобы сумма их изменений в рамках группы всегда была равна 0. Такие группы называют балансами.
Использование такого простого правила, а по сути – закона сохранения, позволит нам застраховаться от случайных ошибок, связанных с технической реализацией процесса регистрации изменений параметров.
На рисунке процесс 2 "публикует" данные с помощью параметра, из которого процесс 1 их считывает и автоматически вырабатывает решения о ходе дальнейшего развития процесса.
Являясь посредником между документами и процессами, отчетами и подсистемами, модель содержит "разделяемые" данные, которые один участник взаимодействия "публикует", а другой участник использует в рамках единой информационной инфраструктуры.
Однако не важная особенность подхода состоит в том, что они одинаковым образом интерпретируют информацию, содержащуюся в разделяемых данных за счет единого семантического поля информационной системы.
Проектирование от модели.
Как спроектировать подобную модель, чтобы она была адекватна хозяйственной деятельности, достоверна и полна?
Мы не будем здесь касаться нюансов построения модели, а лишь в общих чертах опишем процесс ее формирования.
Процесс построения модели представляет собой итеративную процедуру, включающую четыре шага:
- Выявление свойств предметной области. В процессе обследования выявляются свойства предметной области, неотраженные ранее в тезаурусе.
- Формирование тезауруса системы. Тезаурус – это терминологический словарь, описывающий предметную область. Здесь не имеется в виду IV GL, basic или C#. Речь идет о семантической модели предметной области;
- Выявление замкнутых подсистем параметров.
- Выявление параметров в рамках балансов модели;
Рассмотрим данный подход на примере обработки заявки покупателя. Пусть упрощенная бизнес процедура включает семь этапов:
1. Регистрация заявки покупателя
2. Формирование заказа поставщику
3. Получение товара
4. Оприходование полученного товара на склад
5. Резервирование необходимого количества товара под заявку
6. Резервирование товара под заявку на конкретном складе
7.
 |
Отгрузка товара со склада покупателю
На первом шаге происходит знакомство с предметной областью.
Процесс начинается регистрацией заявки и оканчивается отгрузкой товара покупателю - ее исполнением, что означает поставку товара покупателю в необходимом количестве по условленной цене.
Каждый процесс характеризуется некоторым набором количественных и качественных характеристик. К числу количественных характеристик можно отнести стоимость и количество товара на различных этапах бизнес процедуры. В то же время, она характеризуется некоторыми качественными характеристиками, такими как поставщик, покупатель, товар, склад и другие.
На втором шаге полученная информация представляется в виде тезауруса.
Тезаурус системы состоит из понятий, описывающих предметную область, их взаимоотношения и атрибуты.
- Контрегент – физич или юридич лицо, которое участвует в операциях с компанией
- Заказчик – это контрагент, размещающий заказ.
- Резервирование – это состояние товара, когда он исключается из свободного остатка. Резервирование может быть выполнено только под конкретный заказ.
На третьем шаге определим количество и характер балансов.
Ведь в процессе деятельности эти характеристики претерпевают изменения: стоимость товара изменяется под воздействием скидок, наценок, изменения себестоимости товара. Операции влекут за собой бонусы и агентские.
Количество каждого товара также постоянно изменяется, переходя из одного состояния в другое: какое-то количество товара заказано клиентом и попало в заказ поставщику, другая часть зарезервирована из остатка на складе, третья - остается необеспеченной. Особый эффект наносят явления пересортицы, замен и аналогов.
 |
Кроме того, один и тот же параметр может присутствовать в различных балансах (см рисунок).
Очевидно, что обе количественные характеристики потребуют жесткого контроля замкнутости: стоимость товара и количество каждого товара.
Кроме того, стоимостные представления также могут быть различные. Например, если в компании ведется управленческий, бухгалтерский и налоговый учет в соответствии со следующей таблицей.
Элемент учетной политики | Управленческий учет | Бухгалтерский учет | Налоговый учет |
Валюта учета | Доллар США | Российский рубль | Российский рубль |
Метод списания | LIFO | Средняя цена | LIFO |
Субъект учета | Бизнес образование | Юридическое лицо | Юридическое лицо |
Значит кроме товарного баланса, необходимо иметь еще и финансовые балансы для управленческого, бухгалтерского и налогового учета.
Предположим, что в нашем примере необходимо иметь два баланса: товарный и стоимостной.
На заключительном шаге определяются ключевые параметры и их структура в рамках каждого из замкнутых пространств.
 |
На рисунке приведена схема регистров-параметров модели, сгруппированных в два баланса – товарный и суммовой.
Проблемы технической реализации:
Техническая реализация подобного подхода также не является тривиальной. Более пяти лет нам понадобилось, чтобы осознать ресурсоемкость и сложность данного подхода.
В результате нам удалось добиться хороших результатов.
Но основные проблемы, с которыми мы столкнулись были следующие:
- 
Управление тезаурусом
- Развитие модели без прерывания деловой активности.
o Изменение состава параметров
o Изменение аналитической структуры параметров
o Изменения алгоритма преобразования состояния процесса в состояние модели.
- Управление достоверностью модели
o Управление технологией преобразования документов в изменения регистров
o Гарантия замкнутости регистров области
- Обеспечение быстродействие.
Изложенный подход нуждается в семантической прозрачности. В системе Алеф эту задачу выполняют "Термины".
При регистрации нового термина автоматически создается семантическая инфраструктура решения, которая обеспечивает как межмодульный обмен данными в рамках единой информационной системы, так и связь между системами.
Дело в том, что термины не только являются “протоколом” общения между процессами. Они могут быть также представлены в виде XML схем, определяющих технологию обмена данными с другими системами.
Кроме того, обмен XML сообщениями является основным способом обеспечения распределенной работы в Системе Алеф.
Специальные сервисы обеспечивают “горячий” подхват изменений в системе.
Для управления достоверностью на уровне реализации используются документируемые и прозрачные процедуры преобразования, транзакции на уровне СУБД.
Отражение оперативных процессов в модели требует больших вычислительных ресурсов. Поэтому очень сложной задачей является реализация физической структуры регистров и формирование запросов к ним.
Вот лишь несколько технологических решений, позволивших обеспечить хорошее быстродействие системы:
· Разнесение балансов на различные структуры таблиц СУБД,
· выделение структур для оперативного кэша параметров,
· формирование агрегатов аналитических комбинаций и прочее.
В результате пользователь системы, ничего не зная о происходящих за пределами графического интерфейса процессах, оперативно формирует хозяйственную модель предприятия, которая так важна и для управления процессом, и для управления компанией.
