В данной статье рассмотрено применение подхода управления соответствиями бизнес-процессов, с учетом возможных изменений на уровне пользователя. В ходе работы описаны методологические и практические особенности проектирования информационных систем. This article discusses the application of the compliance management of business processes, subject to possible changes on the level of the user. During the work are described methodological and practical features of the design of information systems.

1. 1
УДК 65.011.56
Симкин А.В.1,2
1 ГОУ ВПО «Московский физико-технический институт»
2 Московский государственный университет имени Н.Э. Баумана
Создание и применение модели гибкой автоматизации
бизнес-процессов с использованием семантических сетей
Аннотация
В данной статье рассмотрено проектирование современного подхода,
называемого «управлением соответствиями», обеспечивающего гибкое описание
бизнес-процессов на уровне пользователя. Рассмотрены методологические и
практические способы проектирования информационных систем. Описана
существующая апробация и полученные результаты работы в данном направлении.
Ключевые слова: автоматизация, бизнес-процесс, интернет-магазин,
информационная система, онтологическая структура, семантическая сеть, система
управление предприятием, управление соответствиями.
Введение
Время от времени в организациях возникает проблема, связанная с
автоматизацией бизнес-процессов. В силу быстрой изменчивости бизнес-среды
компаниям необходимо оперативно адаптировать свои бизнес-процессы. Например,
для компании «живущей» в динамично развивающейся сфере интернет ритейла без
постоянного сопровождения и изменения системы управленческого учета работа
персонала организации может быть малоэффективной. Формализованная адаптация
процессов обычно не вызывает труда1, тогда как модификация информационной
системы уровня предприятия требует больших затрат.
Что же делать в этом случае? Самый правильный способ - это создание
стратегической модели информационной системы, которая может динамически
изменяться одновременно с предприятием. В данном случае, компонентный метод
самый распространенный и правильный, с точки зрения архитектуры предприятия.
Данный архитектурный подход подробно рассмотрен в литературе [1].
1
Данное замечание сделано относительно затрат на ее реализацию. Однако, например, формализация
процесса с точки зрения программиста и пользователя может сильно отличаться.

2. 2
Однако на текущий момент не существует универсальных методов
семантического описания бизнес-процессов на уровне информационных систем
предприятия. Для описания бизнес-процессов и построения формализованных
моделей верхнего уровня можно воспользоваться такими средствами как BPWIN
или ARIS. К сожалению, их непосредственная интеграция с информационными
системами уровня предприятия не всегда возможна и целесообразна.
Человечеству еще предстоит пройти этап создания универсальной модели
формализации и описания бизнес-процессов, которая позволит избавиться от
программиста при разработке информационных систем. Если архитектор
предприятия сможет сам проектировать и разрабатывать всю информационную
систему, рассогласование формализованной модели и ее реализации будет
устранено.
Попытка решения данной задачи требует перехода в область искусственного
интеллекта. А методология этого процесса, т.е. вопрос о том, как предоставить
знания о модели, принадлежит когнитивной психологии и философии формализмов.
Таким образом, видно, что исследование данной задачи лежит на стыке различных
областей науки, что добавляет ещё большую сложность для ее решения.
В настоящее время методики семантического представления и, впоследствии,
эффективного использования больших массивов знаний активно разрабатываются
и внедряются за счет новой формы организации и обработки знаний в сети Internet -
Semantic Web [2] . Эта концепция предполагает дополнение развертываемых в Web
материалов семантическими описаниями специального вида2, допускающих
автоматическую обработку. Однако переход к технологиям Web 2.0, и в будущем, к
Web 3.0, в практики Web-технологий встречается очень редко, не говоря уже об
информационных системах уровня предприятия.
Существует много методов представления знаний с точки зрения
графических формализмов, таких как: представление знаний с графической
нотацией, продукционное представление знаний и деревья «И/ИЛИ», семантические
сети, фреймовые иерархии, представление знаний в Semantic Web. Данные методы
подробно рассмотрены в литературе [4].
2
Расширяемый Язык Разметки (eXtensible Markup Language, XML) и Система Описания Ресурсов (Resource
Description Framework, RDF) - см. литературу [3].

3. 3
Построение модели
Поставим задачу создания и реализации простой и распространенной модели
бизнес-процесса Интернет-торговли. Получение формализованного описания
исходных данных необходимо для последующей автоматизации данного процесса.
Для решения подобной задачи была разработана (рис. 1) цикличная модель
представления знаний. Рассмотрим подробнее данную модель.
Первичное описание бизнес-процесса обычно имеет лексическое
представление. На первом этапе необходимо выбрать имеющиеся данные.
Второй этап один из самых сложных с точки зрения «компьютерного разума».
Задача выражения смысла - это первый этап «вплетения» семантической сети в уже
имеющуюся структуру знаний [3]. С точки зрения функциональной возможностей
машинной обработки, решение этого этапа задачи означает более эффективную
обработку и «понимание» данных ЭВМ.
На этапе выбора способа представления знаний имеет смысл подобрать
наиболее оптимальный вариант с точки зрения уровня детализации. В данном
случае имеется в виду, что представление одних и тех же знаний может иметь
различный вид3. Например, программист и пользователь системы могут совершенно
по-разному воспринимать входящую информацию по какому-либо объекту системы.
Следующий этап «Представление знаний» заключается в выборе метода
описания и его формализации, в каком либо виде. Как уже говорилось ранее,
существует множество методов представления знаний с точки зрения графических
формализмов [4].
На последнем этапе необходимо реализовать полученное представление
программными средствами. Это очень самая сложная практическая задача. Кроме
того не существует каких либо методик реализации данной задачи.
Предложенная модель цикличная (см. рис. 1). Это необходимо для того чтобы
была возможна ее детализация, выбирая каждый полученный уровень
представления и применяя к нему данную модель.
3
См. далее на примере.

4. 4
Рисунок 1. Модель представления динамических бизнес-процессов
Применение модели
Теперь применим данную модель к поставленной задаче. Управленческий
учет организации, занимающейся доставкой товаров4, невозможно вести без
реквизита «Статус заказа» документа «Заказ Покупателя/Поставщику». Это свойство
позволяет отслеживать текущее состояние документа.
Грамотное и четко формализованное отражение знаний о текущем состоянии
объекта (в данном случае это Заказ) и является семантическим его представлением.
Описав логику сопоставления статуса Заказа определенному набору критериев, мы,
не подозревая, уже формализуем на верхнем уровне состояния, в которых может
находиться Заказ. Какой бы короткий не был бизнес-процесс без данного свойства
быстро и оперативно отследить текущую ситуацию по необходимому документу
невозможно. Ведь открытие и просмотр огромных аналитических отчетов,
достаточно трудоемкая задача, требующая способности пользователя к быстрому
анализу больших объемов информации. Мы уже прошли первые этапы модели. На
следующих этапах выберем способ и метод представления знаний.
В простом аналитическом случае можно представить семантику Заказа как
знания с графической аннотацией. Однако часто, применяется простое лексическое
4
В данном случае это Интернет-торговля.
Выбор данных
Выражение
смысла
Выбор способа
представления
знаний
Представление
знаний
Реализация
полученного
представления

5. 5
описание содержащейся в заказе информации. Например: «Статус “Необработан”
ставится в момент поступления заказа в систему и не меняется до тех пор, пока не
сделан хотя бы один заказ поставщику, или не зарезервирован хотя бы один товар на
складе»5.
Рисунок 2. Этапы бизнес-процесса интернет заказа.
Подобный вид представления знаний хорошо понятен любому человеку,
однако он сложен в описании, и требует хорошей концентрации как
формализующего, так и интерпретирующего.
Теперь покажем, как различие способов представления знаний сказывается
на понимании бизнес-процесса пользователями системы.
Классический бизнес-процесс6, для компаний, занимающихся Интернет-
торговлей, выглядит следующим образом (см. рисунок 2). Для нашей задачи
рассмотрим детализированный бизнес-процесс «Исполнение Заказа». На рисунке 3
представлен бизнес-процесс в его классическом функциональном7 понимании.
Как видно, в подобном представлении очень хорошо видно, кто и какие
функции выполняет, однако трудно сказать о том, в каком состоянии находится тот
или иной «Заказ Покупателя».
Таким образом, в данной задаче целесообразно описать бизнес-процесс
документа «Заказ Покупателя» с точки зрения его движения по статусам, как
наиболее оптимальный. На данном уровне декомпозиции это удобнее всего
реализовать методикой расширенных семантических сетей деревьями «И/ИЛИ» [4].
Таким образом, мы определим, какие семантические статусы достигаются в тот или
иной момент его состояния.
5
Пример формализации статуса Заказа лексикой; взят из реальной организации.
6
Данный бизнес-процесс получен обобщенно по результатам исследования около 5 компаний.
7
Здесь, под функциональностью имеется в виду то, что бизнес-процесс отражает функции и роли
исполнителей этих функций.

6. 6
На рисунке 4 изображено подобное описание. Конечно, в данном случае
говорить о полном представлении семантической сети не приходится. Во-первых,
мы имеем узкоспециализированную задачу, ориентированную на определенный
бизнес-процесс. Во-вторых, даже в рамках данного бизнес-процесса нам удалось
применить выработанную модель, с помощью которой можно решать подобные
задачи. Причем в данном случае использованы далеко не все свойства и
возможности расширенных семантических сетей. Например, у каждого документа
можно выделить еще определенные свойства и наследования8.
8
См. литературу [4].
Формирование
поставки/
реализации
Доставка
Курьер
Логист/Менеджер
Получение
денег
Возврат
товара
Приём денег
Товар
принят?
Нет Да
Управление
курьерами и
доставками
Логист
Склад
Кассир
Статус заказа:
«Формируется/В работе»
Исполнение заказа
Резервирование
товаров
Заказ
Поставщику
Поступление ТиУ
Отчет по
доставке
V
Заказ
Покупателя
Склад
Статус заказа:
«Не обработан»
Статус заказа:
«Сформирован»
Статус заказа:
«Доставлен»
Статус заказа:
«Не доставлен»
Рисунок 3. Бизнес-процесс «Исполнение заказа»

7. 7
V
V
Резервирование
товаров 1..K
Заказ
Поставщику
K..N
V
Заказ
Поставщику
1..N
Резервирование
товаров
Заказ
Поставщику
Не обработан
Формируется
Сформирован
В работе
Доставлен
Не доставлен
V
Поступление ТиУ
1..K
Заказ Поставщику
K..N
Дата Поступления =
Дата Отгрузки
V
Поступление
ТиУ 1..N
V
Поступление
ТиУ 1..N
Отчет по
доставке
V
Смена
статуса
Смена
статуса
Смена
статуса
Смена
статуса
Заказ Покупателя
Рисунок 4. Бизнес-процесс, отраженный в виде семантических сетей расширенных деревьями «И/ИЛИ»
Этап реализации, возможно, самый сложный и трудоемкий в данной модели.
К сожалению не всегда возможно технически реализовать подобную задачу. Даже
если с методологической точки зрения знания были хорошо описаны и
формализованы. Тем более гибкую автоматизацию бизнес-процесса реализуемого
при внедрении системы управления уровня предприятия не всегда целесообразно
выполнять.
При решении данной задачи был проведен первый этап реализации гибкого
бизнес-процесса. На платформе 1С: Предприятие 89 в прикладном решении
Управление торговлей 10.3 была разработана подсистема управления статусами
Заказа. Реквизит документа «Заказ Покупателя» обладает возможностью
мониторинга и его гибкой настройки как со стороны пользователя самостоятельно,
так и со стороны правил логистики. Для этого в конфигуратор были заложены
«точки» или состояния бизнес-процесса, на которые опирается дальнейшее
поведение подсистемы управления статусами. У программиста или пользователя
9
Подробное описание архитектуры данной платформы приведено в литературе [5].

8. 8
всегда имеется возможность добавить новый статус и определить его описание
(программным кодом и набором правил) или изменить существующий не
затрагивая конфигурацию системы (см. рисунок 5). Это позволяет более гибко и
быстро настраивать бизнес-процесс под каждого заказчика.
Заключение
Следующий этап перехода к более гибкому и понятному семантическому
представлению бизнес-процесса с точки зрения пользователя – это реализация в
системе определенного набора универсальных правил, позволяющих ему
трансформировать заложенный бизнес-процесс. Так же возможна реализация
графического интерфейса, который позволил бы пользователю работать в режиме
WYSIWYG.
Таким образом, была сформулирована и применена модель для описания и
последующей автоматизации динамически трансформирующихся бизнес-процессов
с использованием семантических сетей.
Рисунок 5. Справочник «Статусы заказов»

9. 9
Литература
1. Зиндер Е. З. «3D-предприятие» - модель трансформирующейся системы //
Директор ИС. – 2000. – № 4. –
http://www.citforum.ru/seminars/cbd2000/cbd_day2_01.shtml
2. Semantic Web. – http://www.w3.org/2001/sw
3. Tim Berners-Lee, James Hendler, Ora Lassila. The Semantic Web // Scientific American
Magazine. – 2001, May. – http://www.scientificamerican.com/article.cfm?id=the-
semantic-web. – Перевод: http://ezolin.pisem.net/logic/semantic_web_rus.html
4. С.Е. Дубовик, Д.В. Сошников. Использование семантических сетей, расширенных
деревьями И/ИЛИ для представления структурно-динамических знаний в
интеллектуальных системах // Электронный журнал Труды МАИ. – 2003. – № 13.
– http://www.mai.ru/science/trudy/
5. Габец А.П. и др. Профессиональная разработка в системе 1С: Предприятие 8. – М.:
«1С-Паблишинг»; СПб.: Питер, 2006. – 808 с.
6. Бедрединов Р., Бедрединов Т. Система открытого информационного обмена как
инструмент управления качеством бизнес-процессов компании // Управление
финансовыми рисками. – 2008. – № 2. – http://bedredinov.ru/