Software & Systems

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

·     Разработка образа будущей компании – спецификация основных целей компании исходя из ее стратегии, потребностей клиентов, общего уровня бизнеса в отрасли и текущего состояния компании.

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

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

·     Внедрение перепроектированных процессов. Рассматривая эти этапы, можно выделить задачи, для которых необходимо использовать моделирование, и определить ряд требований к моделям.

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

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

В статье рассматриваются вопросы, связанные с использованием интеллектуального имитационного моделирования в реинжиниринге, в частности РДО (ресурсы, действия, операции)-имитатора.

Модели в реинжиниринге бизнес-процессов

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

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

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

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

Решение указанных задач и других, связанных с реинжинирингом, обусловливает разработку и использование различных моделей. Многоаспектность проблемы и ее сложность объясняют невозможность разработки и использования одной общей для всех задач модели. Анализ и управление сложными процессами практически всегда приводит к созданию целого комплекса моделей, каждая из которых описывает какой-либо один (или несколько) из аспектов процесса.

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

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

Таким образом, имеется проблема разработки мощного инструмента быстрого создания различного рода моделей, инструмента, понятного не только программистам, но и менеджерам, осуществляющим реинжиниринг. Кроме того, необходимым является создание методологии использования такого инструмента на всех этапах реинжиниринга. Крайне желательной является возможность последовательного преобразования модели от одного этапа к следующему. Такая возможность обеспечивает преемственность знаний и данных между этапами реинжиниринга, уменьшает вероятность ошибок, облегчает разработку всего спектра необходимых моделей. К сожалению, в настоящее время нет программных средств, отвечающих всем этим и другим требованиям, выдвигаемым к аппарату разработки моделей [1-3].

Наиболее продвинутым в этом плане является аппарат имитационного моделирования (ИМ), традиционно используемый для решения задач анализа и управления сложными системами и процессами [6]. Он обеспечивает представление моделируемого процесса в динамике и с любой степенью детализации. При реинжиниринге имитационные модели позволяют описать основные рабочие процедуры компании и их развитие во времени, а также информационные и материальные потоки между ними. Имитационная модель уже сама по себе после создания и тестирования представляет собой знания о моделируемом процессе и, более того, служит источником получения новых знаний.

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

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

Метод интеллектуального ИМ - РДО

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

Любая система на концептуальном уровне представляет собой набор некоторых ресурсов. Состав ресурсов различен для систем разных видов и может меняться для одной и той же системы при ее функционировании. Последнее обстоятельство связано с выходом из строя и восстановлением отдельных ресурсов при их эксплуатации и с модернизациями и модификациями системы.

Ресурсы могут быть двух видов – постоянные и временные. Постоянные ресурсы всегда присутствуют в системе, временные ресурсы поступают и покидают ее в процессе функционирования. Все ресурсы образуют множество:

,

где – i-й ресурс системы; N – число ресурсов в данный момент времени.

Состояние i-го ресурса можно описать вектором значений его параметров:

,

где  – значение j-го параметра i-го ресурса; Mi– число параметров i-го ресурса.

Тогда состояние системы представим в виде вектора состояний всех ее ресурсов:

.

Ресурсы взаимодействуют друг с другом в соответствии с определенными закономерностями, выполняя определенные действия. Каждое действие связано с некоторыми событиями, происходящими в системе. Таким образом, событие представляет собой элементарное действие в том смысле, что оно не имеет протяженности во времени. Совершение какого-либо события приводит к изменению состояния системы.

События можно разделить на регулярные, вызываемые штатным функционированием ресурсов, и нерегулярные (случайные). Изменения в системе при совершении регулярного события могут быть формализованы и должны отражать логику взаимодействия ресурсов между собой. Нерегулярные события происходят либо при нештатной работе ресурсов (поломки, отказы), либо по внешним по отношению к системе причинам.

Регулярное событие можно формально представить как некоторое изменение состояния и описать следующим образом:

где – момент времени свершения события e; и  – состояние системы до и после собы- тия e.

Используя понятие событие, целенаправленное действие можно описать через события начала и окончания действия:

.      (1)

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

Событие  не инициируется системой управления, поэтому оно описывается лишь временем возникновения и состоянием ресурсов после завершения события

.

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

Соотношение (1) описывает действие, не прерываемое нерегулярными событиями, то есть завершающееся в штатном режиме. Для того чтобы действие могло начаться, его ресурсы должны отвечать условию .

Процесс в системе можно представить как временную последовательность действий и нерегулярных событий

,

где A – множество действий; – множество нерегулярных событий; a – отношение предшествования во времени.

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

где  – алгоритмы преобразования параметров, описывающих состояние ресурсов при событиях и ;  – состояние ресурсов после завершения события .

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

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

где  – описание множества формальных ресурсов операции .

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

Таким образом, операция описывает, что может произойти в системе при определенных условиях, а действие – что произошло, происходит или произойдет и в какое время. Действие как процедурное знание может быть описано правилом продукции. Обычно в работах по искусственному интеллекту продукционные системы рассматривают без учета стохастических событий, в этом случае время исключают из рассмотрения и описывают только логическую взаимосвязь действий. Предполагается, что параметры изменяются один раз за действие: ЕСЛИ (условие) ТО (действие).

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

ЕСЛИ (условие) ТО1 (событие 1) ЖДАТЬ () ТО2 (событие 2).

Здесь событие 2 наступает через интервал времени, определяемый закономерностями действия и состоянием его ресурсов. Если в течение данного временного интервала происходит нерегулярное событие, то событие 2 не наступает.

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

Процесс в системе в общем случае описывается графом И/ИЛИ, вершины которого соответствуют определенным состояниям системы, а дуги - правилам продукций.

Рассмотренный подход реализует следующие основные положения (рис.1):

- информационное представление элемента системы – это ресурс, представленный фреймом в базе данных;

- процесс, протекающий в системе, описывают как последовательность целенаправленных действий и нерегулярных событий;

- описание действия – операция, описывающая законы изменения состояния системы при начале и при окончании действия;

- операция формально представляется модифицированным продукционным правилом для динамического мира.

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

Множество значений всех параметров всех ресурсов образует базу данных системы (набор декларативных знаний), а множество операций – базу знаний. Использование приведенного метода формализации позволяет с единых позиций создавать модели, используемые на различных этапах реинжиниринга. Метод является альтернативой существующим языкам моделирования и в отличие от них характеризуется выделением знаний из программного обеспечения в информационное. Это позволяет получить ряд полезных свойств моделей (таких как открытость), облегчает создание, адаптацию и наладку модели при модификации моделируемой системы или изменениях в характере ее функционирования [7-10], что важно в процессе проведения реинжиниринга.

Язык РДО

Этот язык реализует РДО-метод представления знаний о дискретных системах и процессах и основывается на введенных выше модифицированных продукциях. В нем используются символические имена, арифметические и логические выражения, функции. Язык также позволяет описывать показатели функционирования, которые требуются исследователю, и анимационные кадры [7]. На языке РДО формируются базы данных и знаний о моделируемой системе. Для описания динамической компоненты применяются модифицированные продукционные правила. Структура продукционного имитатора представлена на рисунке 2.

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

Итак, продукционная система (БД, БЗ и система вывода), система имитации нерегулярных событий и аппарат ведения событий совместно осуществляют построение модели процесса. На основании анализа результатов имитации на этой модели вычисляются различные показатели функционирования системы. Система трассировки выводит подробную информацию о событиях в специальный файл, который затем обрабатывается для детального анализа процесса и представления информации в удобном виде. Система анимации позволяет отображать на экране во время моделирования поведение системы.

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

С использованием описанного аппарата были проведены исследования функционирования и созданы системы управления рядом объектов, среди которых почтовое отделение, линия разлива пищевых жидкостей фирмы Перье (Франция), участок разделки бревен фирмы Хондельберг (Германия), цех механообработки завода экспериментального машиностроения г. Протвино (Россия).

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

Модели реинжиниринга и их представление в ИМ и в РДО

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

Исходной информацией для моделирования работы отделения служат:

· структура функций, выполняемых почтовым отделением, представленная в виде IDEF0-диаграмм работы почтового отделения;

· входной поток клиентов, требующих обслуживания, характеристики которого получены обработкой фотографий рабочего дня отделения;

· множество типов заявок, поступающих от клиентов и потенциально возможных типов.

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

ИМ позволяет анализировать работу почтового отделения связи при штатном функционировании (обратный инжиниринг) и при изменении входного потока клиентов (требований на обслуживание), при изменении условий работы самого отделения и т.д. При этом исследователь может преследовать различные цели, в частности направленные на повышение эффективности работы отделения.

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

Создание ИМ начинается с создания модели существующей компании, точнее, с бизнес-процесса существующей компании. Все элементы компании, участвующие в бизнес-процессе (как людские, так и технические), представлены в ИМ в терминах РДО-метода как ресурсы. Ресурсы относятся к подмножествам ресурсов одного или нескольких типов. Все ресурсы некоторого типа описываются определенным множеством параметров. Так, типы ресурсов Отделения, Окна и Клиенты описываются на РДО следующим образом:

$Resource_type Отделения : permanent

$Parameters

 Состояние : (Начало_Дня,Рабочий_День,Конец_Дня)

$End

$Resource_type Окна : permanent

$Parameters

 Номер             : integer[1..5]

 Работоспособность  : (Открыто,Закрыто)

 Занятость          : (Свободен,Занят)

 Обслужено         : integer[0..30000] = 0

 В_Очереди        : integer[0..30000] = 0

Интервал1_Начало  : real

 Интервал1_Конец   : real

 Интервал2_Начало  : real

 Интервал2_Конец   : real    {Если клиент указывает один интервал, то}

 Интервал3_Начало  : real    {остальные интервалы не используются и Началу и Концу интервала := 0.0}

 Интервал3_Конец   : real

$End

$Resource_type Клиенты : temporary

$Parameters

 Заявка       : (Отправить_Ценную_Бандероль,

            Отправить_Заказную_Бандероль,

            Отправить_Простую_Бандероль,

                           . . . . . . . . . . . . . . . . . .

                           . . . . . . . . . . . . . . . . . .

Открытие_Текущих_Счетов)

            {. Любая новая заявка}

 Состояние      : (Возник,Пришел,В_Очереди,Обслуживается, Обслужился, Ушел)

 Номер_В_Очереди   : integer[1..30000]

 Номер_Окна     : such_as Окна.Номер

 Приход_В_Очередь  : real

 Время_В_Очереди   : real

$End

Конкретные ресурсы относятся к одному из типов и отличаются друг от друга значениями параметров, например:

$Resources

 Отделение   : Отделения Начало_Дня

 Окно1       : Окна 1 Закрыто Свободен * * 9.0 18.0  0.0 0.0       0.0 0.0

 Окно2       : Окна 2 Закрыто Свободен * * 9.0 10.0  0.0 0.0   0.0 0.0

 Окно3       : Окна 3 Закрыто Свободен * * 9.0 18.0  0.0 0.0   0.0 0.0

 Окно4       : Окна 4 Закрыто Свободен * * 9.0 18.0  0.0 0.0    0.0 0.0

 Окно5       : Окна 5 Закрыто Свободен * * 9.0 10.0   0.0 0.0    0.0 0.0

{Одно из окон должно начинать работу в 9:00 ОБЯЗАТЕЛЬНО}

 Из_Клиент1  : Изображаемые_Клиенты 1 Отправить_Ценную_ Бандероль

.........................

$End

Ресурсы взаимодействуют друг с другом в процессе. При этом необходимо принимать решения по тому, как осуществлять эти взаимодействия. Ситуации, в которых принимаются некоторые решения, называются точками решения. В ИМ мы рассматриваем наиболее часто точки решения следующих двух видов:

· когда некоторое действие закончилось, мы должны решить, какое следующее действие будет выполняться;

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

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

Например, операции прихода клиента и открытие окна в РДО модели будут описаны следующим образом:

$Pattern Приход_Клиента_На_Почту : operation trace

$Relevant_resources

 Рел_Отделение : Отделения       NoChange NoChange

 Рел_Нагрузка  : Виды_Нагрузки   Keep  Keep

 Рел_Клиент    : Клиенты         Create NoChange

$Time = Время_Прихода_Клиента(Рел_Нагрузка.Вид,

                Рел_Нагрузка.Минимум_Среднее_Число,

                Рел_Нагрузка.Максимум_Дисперсия)

$Body

 Рел_Отделение

 Choice from Рел_Отделение.Состояние = Рабочий_День

  first

 Рел_Нагрузка

  Choice from   Рел_Нагрузка.Грузить = Да

  first

  Convert_begin

   Грузить set  Нет

  Convert_end

   Грузить set Да

 Рел_Клиент

 Convert_begin

  Заявка             set Заявка_Клиента

  Состояние          set Возник

  Номер_В_Очереди   set 1

  Номер_Окна        set 1

  Приход_В_Очередь  set Time_now

  Время_В_Очереди   set 0.0

$End

$Pattern Открыть_Окно : rule

$Relevant_resources

 Рел_Время : Время    NoChange

 Рел_Окно  : Окна      Keep

$Body

 Рел_Время

  Choice NoCheck

  first

 Рел_Окно

  Choice from Рел_Окно.Работоспособность = Закрыто and

            [Рел_Окно.Интервал1_Начало = Рел_Время.Часы or

            Рел_Окно.Интервал2_Начало = Рел_Время.Часы or

            Рел_Окно.Интервал3_Начало = Рел_Время.Часы]

 first

  Convert_rule

   Работоспособность set Открыто

$End

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

$Pattern Обслуживание : keyboard

$Parameters

 Номер : such_as Окна.Номер

$Relevant_resources

  Рел_Смотритель : Смотрители  Keep     NoChange

$Time = 0.0

$Body

 Рел_Смотритель

  Choice from Рел_Смотритель.Номер = Номер

  first

  Convert_begin

   Разрешить set Показать_Спрятать (Рел_Смотритель. Разрешить, Номер)

$End

ИМ служит для выполнения анализа существующего бизнес-процесса (как есть) и в то же самое время является базой для создания ИМ будущего бизнес-процесса (как будет). При ее созда- нии в РДО в существующую ИМ могут добавляться новые ресурсы, но главное, что в ней изменяются правила, описывающие закономерности взаимодействия ресурсов, для достижения стоящих перед отделением целей.

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

Метод РДО, используя относительно компактные и независимые описания отдельных закономерностей бизнес-процесса, позволяет легко модифицировать состав ресурсов и множество продукционных правил. При этом никак не затрагиваются механизмы логического вывода, сбора показателей и визуализации процесса имитации.

Аппарат ИМ позволяет анализировать две модели компании (внешнюю и внутреннюю) в динамике, учитывая параллельность подпроцессов, ограниченность ресурсов, их появление и удаление из модели и т.д.

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

Опыт использования интеллектуального ИМ в рассматриваемой области показывает его эффективность и гибкость по отношению к другим традиционно используемым инструментальным средствам.

Список литературы

1. Ойхман Е.Г., Попов Э.В. Реинжиниринг бизнеса: реинжиниринг организаций и информационные технологии. -М.: Финансы и статистика, 1997. - 336с.

2. Попов Э.В. Реинжиниринг бизнес-процессов и искусственный интеллект // Новости искусственного интеллекта. - 1996. - №4. -С.5-40.

3. Кисель Е.Б., Кондрашова Е.Н., Шинкарев М.Б. Опыт использования средств искусственного интеллекта в моделировании бизнес-процессов // Новости искусственного интеллекта. -1996. -№4. - С.85-121.

4. Hammer M. Reengineering Work: Don’t Automate. Obliterate, Harvard Business Review. July/August 1990.

5. Hammer M., Champy J. Reengineering the corporetion: A manifesto for Business Revolution. N-Y: Harper Collins, 1993.

6. Pritsker A. Alan B., Introduction to Simulation and SLAM II. Systems Publishing Corporation West Lafayette, Indiana, 1984.

7. Емельянов В.В., Ясиновский С.И. Введение в интеллектуальное имитационное моделирование. Язык РДО. -М.: АНВИК, 1998. - 428с.

8. Emelyanov V.V., Ovsyannicov M.V., Yasinovsky S.I. An AI-based Method and Tool for Discrete Manufacturing Systems Simulation and Real-time Control, Proc. of IEPM’95, Marrakech, April 4-7, 1995. Vol 1.- p.322-332.

9. Emelyanov V.V., Yasinovsky S.I. Representing knowledge for simulation complicated discrete systems and processes// Proc. of Fifth Int. Confr. Computer Integrated Manufacturing and Automation Technology. CIMAT’96. Grenoble, May 29-31, 1996.- P. 134-140.

10. Emelyanov V.V. Representing knowledge for simulation complicated discrete systems and processes// Proc. of CESA’96 IMACS Multiconference. Computational Engineering in Systems Applications. Symposium on Robotics and Cybernetics. Lille - France, July 9-12, 1996.-P.289-293.

11. Emelyanov V.V., Iassinovski S.I. An AI-based object-oriented tool for discrete manufacturing systems simulation. Journal of Intelligent Manufacturing. Vol.8, №1, February 1997. p.49-59.