Следует определить, к какому из существующих организационных подразделений должен принадлежать каждый из исполнителей, участвующих в новых бизнес-процессах. Возможно потребуется изменить структуру функциональных подразделений — добавить или убрать некоторые подсистемы, объединить или разделить. Самый ответственный этап — создание команд процессов.
Причем команда может состоять и из одного человека. Команды могут быть как временными (для решения единовременной задачи), так и постоянными.
Необходимо определить, сколько и каких команд нужно создать. Как правило, для каждого прецедента создается одна команда. Если прецедент может иметь несколько одновременно выполняющихся экземпляров, каждому экземпляру может соответствовать своя команда. Каждому прецеденту нужно сопоставить владельца процесса. Затем следует описать структуру новых организационных отношений. Типовая структура новой компании, а также типовые обязанности сотрудников такой структуры были описаны в п. 2.3. Поскольку изменение бизнеса меняет не только структуру организационных отношений, но и сам характер работы исполнителей и менеджеров, требуется разработать программу обучения сотрудников компании. Возможно даже потребуется обучение новым приемам работы клиентов и партнеров компании. Изменения должны коснуться и системы управления и оценок, а также системы мотивации (см. п. 2.4). Разработка информационной системы.
Поскольку создание информационной системы поддержки нового бизнеса — очень важная и одновременно чрезвычайно сложная и трудоемкая часть прямого инжиниринга, ему посвящен отдельный параграф (п. 4.6). Проверка нового бизнеса. Проверка нового бизнеса осуществляется на протяжении всего этапа прямого инжиниринга несколько раз и включает в себя: * проверку П-модели и О-модели нового бизнеса; * проверку прототипа информационной системы поддержки; * выполнение пробной инсталляции модели всего бизнеса, но в масштабах изолированной части компании.
После каждого тестирования следует анализировать результаты и модифицировать модели. Тестирование лучше проводить на прототипах. Существует несколько видов прототипирования [6]: 1. Информационное — создание прототипов на бумаге (в виде диаграмм и текстовых описаний). 2. Компьютерное — моделирование новых процессов с помощью компьютера 3. Организационное — моделирование новых процессов с участием сотрудников компании и клиентов в виде деловой игры.
Информационное моделирование рекомендуется выполнять на ранних этапах создания модели нового бизнеса. Эта старомодная «проверка на столе» позволяет избежать грубых ошибок в основной концепции проекта. Используя компьютерные инструментальные средства моделирования (см. гл. 5), можно более детально проанализировать различные шаги новых процессов. Присваивая этим шагам различные значения, можно измерить параметры рассматриваемого бизнеса и получить оценку его работы. При создании информационной системы поддержки нового бизнеса используются и информационные, и компьютерные прототипы.
Организационное прототипирование, как правило, используется на заключительном этапе при проведении пробной инсталляции с участием реальных пользователей.
Инсталляция процессов на примере отдельной части бизнеса позволяет оценить эффективность новых процессов и новой информационной системы, выявить различные проблемы и ограничения.
В процессе тестирования моделируются различные ситуации, исследуется полнота и надежность созданной модели бизнеса. По результатам тестирования в модель могут быть внесены некоторые коррективы и уточнения. И в заключение — несколько слов о внедрении новых процессов.
Это очень ответственный этап, потому что в то время, как внедряются новые процессы, необходимо продолжать работу существующих процессов. Клиенты и партнеры не должны испытывать неудобств от совмещения старых и новых процессов. Существуют различные способы аккуратного внедрения. Как правило, после завершения пилотного проекта выбирают подразделение, специалисты которого имеют наилучшие шансы на достижение успеха при внедрении новых процессов [3].
4.6. Построение информационной системы поддержки Информационные технологии являются основой реинжиниринга бизнес-процессов. Информационная система (ИС) решающим образом влияет на функционирование процессов и при правильном использовании приводит к многократному повышению их результативности [3].
Учитывая важнейшую роль ИС поддержки нового бизнеса, необходимо как можно раньше определить основные функции информационной системы. Модели бизнес-процессов и модели информационной системы тесно взаимосвязаны: с одной стороны, модели нового бизнеса позволяют сформулировать требования к программному обеспечению, с другой стороны, модель ИС определяет направления модификации исходных бизнес-процессов. Поэтому необходимо предусмотреть несколько итераций между формированием модели бизнеса и созданием ИС.
Подобные итерации должны проводиться на протяжении всей разработки: на этапе визуализации определяются контуры обеих моделей, которые затем детализируются. Чем дальше продвигается разработка, тем более детальными становятся обе модели. Использование одних и тех же подходов для построения как бизнес-системы, так и соответствующей информационной системы значительно упрощает взаимосвязи между этими моделями. В данном параграфе будет рассмотрено, как методика построения Прецедент-моделей и Объект-моделей, описанная в п. 3.2, может быть использована при создании ИС нового бизнеса. Поскольку информационная система является достаточно сложной системой, для ее создания необходима мощная технология разработки.
Рассмотрим этапы разработки программного обеспечения [3] (см. рис. 4.8): 1. Сбор требований. На этом этапе собираются все предложения, идеи, пожелания и требования к информационной системе. Первоначальный список требований рекомендуется сформировать еще на этапе визуализации новой компании, когда определяется роль новых ИТ в модифицированном бизнесе. В дальнейшем список требований к ИС прорабатывается и для наиболее важных компонентов информационной системы составляется окончательная спецификация требований. 2. Анализ требований. Цель этого этапа состоит в проверке полноты и непротиворечивости спецификаций требований и построении Прецедент-модели информационной системы. П-модель отражает функциональные требования к системе. При ее построении должны быть определены субъекты системы (пользователи), основные прецеденты, их взаимосвязи (интерфейсы). Должно быть составлено высокоуровневое описание прецедентов. 3. Идеальное проектирование (логическое проектирование).
Этот этап предназначен для построения логической структуры информационной системы. Результатом является объектная модель, в которой отражены основные объекты системы — функциональные (процедуры), информационные (данные), интерфейсные (экранные формы) — а также их связи и связи с конечными пользователями системы. 4. Реальное проектирование (физическое проектирование).
На этом этапе разрабатывается модель, служащая базисом для реализации информационной системы. При этом формируется физическая структура баз данных, составляются подробные спецификации функциональных блоков, создаются макеты экранных форм и т.д. Важно обеспечить ясность и гибкость модели, что позволит в дальнейшем легко ее модифицировать.
5. Реализация.
Цель данного этапа — создание программного кода и баз данных информационной системы. 6.
Тестирование. Здесь проверяется соответствие информационной системы предъявляемым к ней требованиям. Программный продукт не может считаться готовым до тех пор, пока «настоящий» пользователь не признает его работу удовлетворительной. Тестирование — длительный и дорогостоящий этап (на него приходится 25 — 50% стоимости разработки). Раньше тестирование относили на конец процесса разработки и сводили только к проверке программного кода. Сейчас большинство специалистов считают, что о тестировании следует позаботиться с самого начала разработки. При этом специально выбранные пользователи проверяют не только макеты и готовые версии продукта, но и документацию.
Результатом этого этапа должны быть корректные результаты прогона системы на тестовых задачах. Процесс разработки информационной системы может рассматриваться как своего рода бизнес-процесс. Следовательно, этот процесс может быть представлен в виде П-О-модели прецедента «Разработка информационной системы». Субъектами такого прецедента являются конечные пользователи и заказчики ИС.
И хотя те и другие одновременно являются участниками разработки системы, все же их удобнее представить субъектами, т.к. они играют пассивную, опосредованную роль в разработке. Описание потока событий прецедента «Разработка ИС» представляет собой подробное описание хода работ на каждом из этапов разработки — от сбора требований до тестирования системы. Построение объектной модели прецедента «Разработка ИС» включает в себя: * определение участников разработки (интерфейсных и управляющих объектов), * определение для каждого этапа исходных данных и результатов (объектов-сущностей); * определение взаимодействий между объектами. На рис. 4.9 приведена схема взаимосвязи основных объектов, участвующих в прецеденте «Разработка ИС». Приведем описание потока событий прецедента разработки информационной системы в терминах участвующих объектов: 1.
Сбор требований. Интерфейсный объект Интервьюер опрашивает потенциальных Пользователей ИС и Заказчиков с целью выявления их пожеланий и требований к системе. Собранная информация обрабатывается и формируется Список требований. Элементы списка упорядочены по приоритетам и содержат приблизительные оценки сроков разработки.
2.
Анализ требований. Аналитик требований, используя информацию, содержащуюся в Списке требований, формирует П-модель информационной системы. При этом он использует О-модель нового бизнеса, для поддержки которого и создается ИС.
В П-модели ИС находят отражение функции и динамика поведения информационной системы. Затем Аналитик составляет описания интерфейсов конечного пользователя. На основании П-модели и описаний интерфейсов создается макет (прототип) системы, который Тестирующим оперативно проверяется и обсуждается с будущими пользователями. 3. Идеальное проектирование. Проектировщик на основании Списка требований, О-модели нового бизнеса и П-модели ИС формирует О-модель информационной системы. Для каждого прецедента ИС Проектировщик выделяет объекты, необходимые для реализации потока событий прецедента, и описывает выполнение прецедентов в терминах объектов. Затем создается уточненный макет системы, который Тестирующий обсуждает с пользователями. После проверки модели Проектировщик создает унифицированное и структурированное описание модели. 4. Реальное проектирование. После того, как О-модель ИС создана, Разработчик принимает ее в качестве отправной точки для создания модели реализации (эта модель не показана на рис. 4.9).
Разработчик начинает с адаптации модели к условиям реального окружения с учетом выбранных средств реализации (языка программирования, СУБД и т.д.) и возможностей стыковки ИС с существующим программным обеспечением. Затем формируется физическая структура баз данных, составляются подробные спецификации функциональных блоков, создаются макеты экранных форм. 5. Реализация. Разработчик на основании модели реализации формирует программный код, создаются базы данных, создается сопроводительная документация и т.д. 6. Тестирование готового продукта. Тестирующий, тесно взаимодействуя с Пользователем и Заказчиком, проверяет соответствие готовой системы и документации спецификации требований. Тестирующий обрабатывает все замечания, пожелания и комментарии о продукте. Эта информация передается участникам разработки для исправления ошибок и внесения корректив. Рассмотрим подробнее процесс формирования П-модели и О-модели информационной системы. П-модель информационной системы формируется Аналитиком требований на основании Спецификации требований и О-модели нового бизнеса. Построение П-модели начинается с выделения прецедентов и субъектов системы. В [3] описан алгоритм выделения прецедентов и субъектов информационной системы из модели бизнеса. Рассмотрим основные идеи этого алгоритма. Для каждого субъекта, а также управляющего или интерфейсного объекта модели бизнеса выполняются следующие действия: 1.
Определяется, использует ли данный объект в своей деятельности информационную систему. Если да, то в модели ИС ему сопоставляется субъект — пользователь информационной системы. 2. Проверяются все обязательства объекта. Если некоторое обязательство осуществляется с помощью информационной системы, то либо в модели ИС идентифицируется новый прецедент ИС и в его описание вносится соответствующее обязательство, либо обязательство вносится в уже выделенный ранее прецедент информационной системы. Поясним изложенное выше на конкретном примере — выделении субъектов и прецедентов информационной системы на основании О-модели бизнес-процесса «Продажа заказного продукта» (см. п. 3.2). На рис. 3.4 приведена схема взаимодействия объектов данного прецедента, на рис. 3.6 — диаграмма взаимодействия объектов. В прецеденте «Продажа заказного продукта» участвуют: субъект Клиент, интерфейсный объект Продавец, управляющие объекты Проектировщик и Отправитель продукта. Для каждого из этих объектов определяется, используют ли они в своей деятельности информационную систему.
Например, Продавец при приеме заказа от Клиента заносит Заказ в информационную систему. В этом случае объекту Продавец модели бизнеса сопоставляется субъект Продавец в модели ИС.
Продавец в прецеденте «Продажа заказного продукта» имеет следующие обязательства: * «Получить заказ клиента»; * «Передать заказ проектировщику»; * «Передать отправителю адрес клиента»; * «Принять оплату клиента». Первые 3 обязательства могут быть выполнены с помощью одного прецедента ИС «Обработка заказа» (см.
рис.
4.10).
В описание этого прецедента вносятся функции ввода, хранения и использования информации о заказе и адресе клиента. Для обязательства «Принять оплату клиента» выделяется новый прецедент ИС «Оплата заказа», и в его описание вносится соответствующая функция (см. рис. 4.10). Если субъект Клиент бизнес-модели тоже может использовать информационную систему (например, вносить заказ в ИС через Интернет), то ему в модели ИС сопоставляется субъект Клиент. Обязательство Клиента «Заказ продукта» может выполняться с помощью уже выделенного прецедента «Обработка заказа» (соответствующая функция добавляется в его описание). Обязательство «Оплата продукта» не может выполняться без участия Продавца. Аналогичным образом объекту Проектировщик модели бизнеса сопоставляется субъект Проектировщик модели ИС. С помощью информационной системы он может выполнять обязательство «получить информацию о заказанном продукте».
При этом он может использовать ранее выделенный прецедент ИС «Обработка заказа». Объекту Отправитель модели бизнеса сопоставляется субъект Отправитель модели ИС.
Его обязательство «получить адрес клиента» может быть выполнено с помощью прецедента ИС «Обработка заказа», а обязательство «получить информацию об оплате» — с помощью прецедента «Оплата заказа». После выделения субъектов и прецедентов модели ИС необходимо составить полные описания выделенных прецедентов в виде потока событий и описания интерфейсов пользователей ИС. Создание таких описаний — сложная и трудоемкая работа. При этом используются описания прецедентов модели бизнеса и список требований к информационной системе. Рекомендуется разработать несколько различных сценариев использования ИС, т.е. описать несколько экземпляров прецедентов ИС и создать несколько соответствующих макетов интерфейсов пользователя. Разработанные сценарии нужно обсудить с будущими пользователями. Построение О-модели информационной системы осуществляется Проектировщиком на основании П-модели ИС, списка требований и О-модели нового бизнеса. Построение О-модели ИС начинается с выделения объектов, участвующих в выполнении прецедентов ИС. Объекты информационной системы бывают трех типов: Интерфейсные объекты — поддерживают взаимодействие ИС с субъектами (пользователями). Они обеспечивают функции ввода и вывода информации (данных и управляющих сигналов), преобразование информации из внутрисистемных форм представления во внешние и наоборот. К интерфейсным объектам относятся экранные формы, интерфейсы с принтерами, с датчиками, протоколы связи. Управляющие объекты — активные модули системы (процедуры), выполняющие некоторые операции, например, запись, удаление, поиск сортировка данных в базах данных, вычисления, преобразования данных. Объекты-сущности — информационные объекты, которые хранятся, передаются, используются для преобразований и т.д.
По содержанию они представляют собой либо данные, либо управляющие сигналы, по форме — базы данных, файлы, сообщения. Рассмотрим пример формирования О-модели прецедента ИС «Обработка заказа». Фрагмент данной модели приведен на рис. 4.11. Основные функции данного прецедента: 1. Ввод заказа (информации о заказываемом продукте и адресе клиента) либо Продавцом, либо непосредственно Клиентом. 2. Выдача информации о заказанном продукте Проектировщику продукта 3. Выдача информации об адресе клиента и о продукте Отправителю. В качестве объекта-сущности здесь выступает информационный объект «заказ», содержащий информацию о заказанном продукте и об адресе клиента (см. рис. 4.11). Этот объект соответствует объекту «заказ» в модели бизнеса (в прецеденте «Продажа заказного продукта»). В качестве интерфейсных объектов выступают: блок «Ввод заказа», с помощью которого вводится информация о заказе Продавцом, либо Клиентом; блок «Выдача заказа», с помощью которого выдается информация о заказе (см. рис. 4.11). Управляющими объектами являются: блок «Запись заказа», который вносит введенный заказ в базу данных; блок «Поиск заказа», который извлекает данные из БД и передает их блоку выдачи заказа. Контрольные вопросы 1. Какова роль мотивации к проведению реинжиниринга для различных групп сотрудников компании? 2. Что должна содержать директива на проведение реинжиниринга? 3. Перечислите основных участников проекта по реинжинирингу, их роли и обязанности. 4. Каковы особенности каскадной, спиральной и макетной схемы разработки?
Какая схема наиболее пригодна для реинжиниринга и почему? 5. Какие виды обсуждений Вы знаете? В чем состоят их отличительные особенности? 6. Что включает в себя анализ положения дел, проводимый на этапе визуализации? 7. Каким образом осуществляется работа по спецификации целей? 8. Каково основное содержание этапа обратного инжиниринга?
9. Каково основное содержание этапа прямого инжиниринга? 10. Каковы основные характеристики «хорошего» прецедента модели нового бизнеса? 11. Что включает в себя разработка новой оргструктуры? 12. Какие виды прототипирования Вы знаете? 13. Охарактеризуйте основные этапы разработки информационной системы.
Для каждого этапа укажите участников, исходные данные и результаты. 14.
Как осуществляется построение П-модели и О-модели информационной системы? 5. ИНСТРУМЕНТАЛЬНЫЕ СРЕДСТВА ДЛЯ ПРОВЕДЕНИЯ РЕИНЖИНИРИНГА 5.1. Классификация и анализ существующих инструментальных средств.
Использование инструментальных средств во многом определяет успех конкретного проекта по реинжинирингу. В конечном счете, любой проект по реинжинирингу может быть реализован и без использования поддерживающих инструментариев. Однако применение средств поддержки в процессе разработки может существенно сократить сроки разработки, уменьшить трудозатраты, повысить качество разработки, уменьшить количество ошибок. Инструментальные компьютерные средства предоставляют следующие возможности, повышающие эффективность реинжиниринга: * Систематизация информации о проекте и его компонентах, что облегчает внесение дополнений и изменений, позволяет отслеживать процесс принятия решений, упрощает верификацию проекта и сопутствующей ему документации; * Визуальное моделирование, заменяющее разработчику бумагу и карандаш на компьютер и позволяющее формировать графический проект в интерактивном режиме с использованием визуальных средств (диаграмм, блок-схем, графов), дополненный различного рода описаниями (спецификациями, словарями); * Анализ построенных моделей, включая возможность просчитать стоимостные и временные характеристики различных процессов, проверить гипотезы «что, если …», проверить возможные последствия различных ситуаций и т.д.; * Поддержка коллективной работы — возможность параллельной разработки отдельных компонент проекта различными группами разработчиков с возможностью интеграции результатов в один общий проект; * Использование типовых решений — использование ранее накопленного опыта при принятии решений, а также использование готовых типовых компонент; * Автоматическое создание компонент системы — например, автоматическая кодогенерация (создание компьютерных программ, баз данных на основе введенных моделей и диаграмм), формирование различного рода отчетов, документации по заданному шаблону и т.д. Большинство современных консалтинговых фирм при проведении реинжиниринга используют CASE-средства. Первоначально термин CASE расшифровывался как Computer Aided Software Engineering — компьютерная поддержка проектирования программного обеспечения, т.к.
CASE-средства представляли собой инструментальные системы для автоматизации разработки компьютерных программ.
Поскольку составной частью разработки программных систем является создание моделей автоматизируемой предметной области, то все больше CASE-средств стало ориентироваться на моделирование и проектирование сложных систем широкого назначения. Постепенно понятие CASE приобрело новый смысл, и все чаще стало расшифровываться как — Computer Aided System Engineering — компьютерная поддержка проектирования систем [10].
Современный рынок CASE-средств насчитывает сотни систем, различающихся по следующим параметрам: Функциональные возможности. Большинство средств ориентировано на достаточно узкий диапазон функций: либо это средства для построения функциональных моделей, либо — для проектирования баз данных, либо — для управления проектом и т.д. Однако в последнее время идет активное развитие интегрированных многофункциональных средств. Такие средства поддерживают широкий спектр функций, начиная от построения и анализа моделей бизнеса и заканчивая автоматическим или автоматизированным программированием. При реализации больших проектов по реинжинирингу рекомендуется использовать именно эти средства. Однако, как правило, эти средства достаточно дороги, сложны для использования, требуют длительного обучения работе с ними. Методология.
В современных CASE-пакетах используются практически все известные методологии проектирования. По некоторым оценкам примерно четверть известных CASE-средств поддерживает лишь одну методологию, столько же поддерживает 2-3 методологии. Имеются пакеты, поддерживающие 7 и более методологий.
Существуют средства, не поддерживающие ни одной методологии проектирования (средства управления проектом, средства планирования) и средства, независимые от методологий, т.е. обладающие исключительными возможностями по адаптации к любым методам. Для проектов по реинжинирингу рекомендуется использовать CASE-средства, поддерживающие объектно-ориентированны методы проектирования, т.к. объектно-ориентированный подход в настоящее время признан базовой методологией BPR [3]. В любом случае выбор методики проектирования и выбор инструментального поддерживающего средства должны производиться одновременно на подготовительном этапе реинжиниринга. Ориентация на пользователя. Большинство CASE-средств ориентировано на программистов и не предполагают непосредственное участие менеджеров в разработке моделей. Однако опыт ренинжиниринга показывает, что опосредованное участие менеджеров (специалистов в области реконструируемого бизнеса) в компьютерном моделировании зачастую приводит к неадекватности моделей и к непоправим ошибкам в проведении BPR. Ориентация на пользователей, не являющихся специалистами в области ИТ, предъявляет высокие требования к интерфейсу CASE-средства в части простоты использования. Интерфейс должен быть «прозрачным», легко осваиваемым для того, чтобы менеджеры могли самостоятельно, без помощи программистов воплощать свои идеи в виде работающих моделей бизнеса. Технические характеристики. Немаловажное значение для распространения CASE-средств имеют вычислительные платформы, на которых они реализуются. Сегодня это, как правило: тип ЭВМ — IBM-совместимые, операционные системы — Unix и Windows NT/95. Немаловажную роль играют возможности многопользовательского доступа к инструментарию. Цена. Самые дешевые средства, реализующие узкий диапазон функций, имеют стоимость порядка 300 — 1000 дол. Цена интегрированных многофункциональных средств колеблется в интервале 10000 — 50000 дол. Все используемые в BPR инструментальные средства можно разделить на следующие группы [3, 13] (см. рис. 5.1): 1. Средства управления проектом. Назначение: Используются на подготовительном этапе BPR для планирования хода выполнения работ, а также для сопровождения проекта (контроля и корректировки планов выполнения работ). Кроме того, средства этой категории могут быть использованы на этапах обратного и прямого инжиниринга для создания модели бизнес-процесса в виде последовательности работ. Основные функции: * формирование календарных графиков работ, построение диаграммы Ганта и сетевых графиков. При этом можно задавать различные связи между работами: выполнение работы может допускаться по завершении другой работы, при наступлении определенного момента времени и доступности ресурса и т.д.; * управление ресурсами, включающее возможность задавать распределение ресурсов между работами во времени, строить диаграммы ресурсов, проводить анализ их загруженности, автоматически перераспределять ресурсы; * управление затратами, позволяющие рассчитывать финансовые показатели проекта, например, составление бюджета проекта, учитывающего затраты труда, расход материалов и накладные расходы. Примеры: CA-SuperProject (Computer Associates International), Microsoft Project (Microsoft), Time Line (Symantec).
2.. Средства создания диаграмм. Назначение: Это средства, используемые на этапах визуализации, обратного и прямого инжиниринга для формирования статических моделей существующего и нового бизнеса. Кроме того, средства этой категории используются при разработке информационной системы (ИС) нового бизнеса. Основные функции: * формирование функциональной модели бизнеса или информационной системы. Наиболее распространенный метод реализации данной функции — метод SADT (технология IDEF0), позволяющий описать бизнес-процесс или процесс в ИС в виде иерархии функций, связанных между собой входящими/исходящими потоками (материальными, финансовыми, информационными), управляющими воздействиями, исполнителями; * формирование информационной модели бизнес-процессов, в том числе выделение объектов бизнеса, описание их поведения и связей друг с другом. Наиболее распространенный метод реализации данной функции — метод IDEF1X, с помощью которого создается описание информационного пространства выполнения бизнес-процессов, содержащего информационные объекты (сущности), их свойства (атрибуты), отношения с другими объектами (связи); * анализ эффективности организации бизнеса, включающий выделение показателей эффективности бизнес-процессов, функционально-стоимостной анализ, выделение центров затрат, анализ загрузки и распределения ресурсов. Наиболее распространенный метод реализации данной функции — метод ABC (Activity Based Costing — функционально-стоимостной анализ) — метод определения стоимости и других характеристик изделий и услуг на основе функций и ресурсов, задействованных в бизнес-процессах. Большинство CASE-средств поддерживает лишь одну из выше перечисленных функций. Примеры: Design/IDEF (Meta Software), BPWin (Logic Works), EasyABC (ABC Technologies), Staffware (Staffware plc) 3. Средства имитационного моделирования/анимации. Назначение: Средства этой категории используются на этапах визуализации, обратного и прямого инжиниринга для анализа динамики бизнес-процессов как существующего, так и нового бизнеса. Основные функции: * построение потоковых диаграмм, в которых представлены основные рабочие процедуры бизнеса и описано их поведение, а также информационные и материальные потоки между ними.
При описании потоков учитываются различные метрики (например, частота появления заявок, время выполнения каждой рабочей процедуры, время передачи выходных данных и т.д.); * «проигрывание» моделей в сжатом времени или пошаговом режиме, изменение характеристик потоков и распределения ресурсов по принципу «что — если». При этом используются анимационные эффекты для демонстрации работы модели. Наиболее распространенный метод имитационного моделирования — CPN (Color Petri Nets — раскрашенные сети Петри) — методология создания динамической модели бизнес-процесса, позволяющая проанализировать зависящие от времени характеристики выполнения процесса и распределение ресурсов для входящих потоков различной структуры. Примеры: ServiceModel (ProModel), ReThink (Gensym), ModSym (CASI). 4. Средства создания информационных систем Назначение: Это средства, используемые на этапе прямого инжиниринга для разработки информационных систем в составе новых бизнес-процессов. Основные функции: * формирование функциональной структуры (архитектуры) информационной системы.
Наиболее распространенный метод реализации данной функции — DFD (Data Flow Diagrams — диаграммы потоков данных) — методология структурно-функционального анализа, описывающая внешние по отношению к системе источники и адресаты данных, логические функции, потоки данных и хранилища данных; * структурирование (моделирование) данных, в том числе: создание концептуальной модели структуры базы данных, автоматическая генерация физической модели БД и др. Наибольшее распространение получили: метод построения ER (Entity-Relationship)-диаграмм Чена и методология Уорнера-Орра DSSD (Data Structured Systems Development); * быстрая разработка приложений (визуальное программирование). Средства, обеспечивающие данную функцию называются RAD-средствами (Rapid Application Development). Они представляют собой визуальные дизайнеры приложений с автоматической кодогенерацией и позволяют создавать приложения в интерактивном режиме с помощью набора визуальных средств. Примеры: S-Designor (PowerSoft), CASE*Designer (Oracle), Power Builder, Rational Rose (Rational Software) 5.
Интегрированные многофункциональные средства. Назначение: Это средства, автоматизирующие все основные этапы BPR, начиная от планирования работ по проекту, формирования статических и динамических моделей существующего и нового бизнеса и заканчивая формированием информационной системы поддержки нового бизнеса.
Основные функции: * спецификация бизнес-процессов, построение и анализ функциональной, структурной моделей бизнеса (поддержка методологии IDEF, потоки работ в сочетании с объектной ориентацией и т.д.); * возможности имитационного моделирования; * включение средств разработки приложений или стыковка с RAD-средствами.
Кроме того, средства данной категории, как правило, поддерживают многопользовательский доступ к инструментарию. Некоторые средства используют методы инженерии знаний (экспертных систем), позволяющие представлять в моделях плохо формализуемые, эвристические знания экспертов о бизнес-процессах. Примеры: G2 (Gensym), SPARKS (Coopers & Lybrand). На рисунке 5.2 представлено, какие группы инструментальных средств поддержки используются на том или ином этапе технологии BPR. Как уже упоминалось, реинжиниринг осуществляют специалисты двух типов — профессионалы в области бизнеса (менеджеры) и профессионалы в области информационных систем (программисты). Средства категории 4 предназначены для разработчиков информационных систем, средства категорий 1, 2 и 3 — для менеджеров (непрограммирующих пользователей), средства категории 5 предназначены как для менеджеров, так и для программистов. Однако, если непосредственное использование менеджерами средств управления проектами и средств создания диаграмм (ИС групп 1 и 2) не вызывает трудностей, благодаря их простоте и ясности, то при использовании менеджерами средств имитационного моделирования и интегрированных средств (ИС групп 3 и 5) возникают определенные проблемы. Дело в том, что построение реальных имитационных моделей зачастую требует от пользователей специальной подготовки Поэтому фирмы-поставщики средств имитационного моделирования и интегрированных средств, как правило, предоставляют методологическую поддержку своих продуктов и консалтинговые услуги. ИС категории 3 и 5 являются наиболее дорогими средствами. Стоимость этих средств колеблется в интервале от 10000 до 50000 дол.
Однако, несмотря на сложность и дороговизну, использование данных средств для крупных проектов по реинжинирингу вполне оправданно, т.к.
они обеспечивают «прозрачность» представления моделей бизнеса и наиболее полный анализ бизнес-процессов.
5.2. Характеристика некоторых инструментальных средств поддержки BPR 5.2.1.
CASE-пакет Design/IDEF Пакет Design/IDEF — графическая среда для проектирования и моделирования сложных систем широкого назначения, поддерживающая методологию описания и моделирования системных функций (IDEF0/SADT), структур и потоков данных в системе (IDEF1, IDEF1X, ER) и поведения системы (IDEF/CPN). Пакет Design/IDEF разработан фирмой Meta Software (США) и принят в качестве стандарта для проектов, финансируемых американскими и европейскими спонсорами.
Пакет был использован для создания проектов сложнейших систем, связанных с автоматизацией и компьютеризацией производства, управлением и контролем в телекоммуникационных сетях и аэрокосмических комплексах и др. Рассмотрим основные возможности пакета [10]. Организация графической среды. Пакет предоставляет быструю и высококачественную графику, позволяющую создавать стандартные и пользовательские графические объекты, осуществлять выравнивание и манипулирование объектами, выбирать атрибуты графических объектов и текста. В пакете реализованы возможности для построения и редактирования диаграмм: построение связывающих линий типа «резинка», маршрутизация и сглаживание дуг и т.д. Обеспечение непротиворечивости модели. В пакете имеются возможности, обеспечивающие точность, целостность и непротиворечивость IDEF-модели на протяжении всего цикла ее создания.
Так, при модификации текста, принадлежащего функциональному блоку или дуге в какой-то одной части модели, осуществляется динамическая корректировка текста на всех страницах модели. Поддержка «Словаря данных». Встроенный «Словарь данных» позволяет хранить информацию о функциях и потоках данных в IDEF-модели, вводить неограниченно число параметров для каждого объекта. Предоставляется разнообразный набор функций сопровождения, восстановления и сохранения целостности файлов данных. Генерация отчетов. Пакет Design/IDEF предоставляет пять видов отчетов для поддержки и анализа моделей: отчет о функциях; отчет о дугах; отчет о ссылках; отчет о контроле полноты модели; IDEF-отчет. Все отчеты могут быть выведены на экран компьютера, отредактированы с помощью текстового редактора и распечатаны. Из отчетов информация может быть экспортирована для использования в других программах, таких, как электронные таблицы, текстовые редакторы и др. Организация коллективной работы. Пакет поддерживает работу многочисленной группы разработчиков, создающих одновременно большую и сложную IDEF-модель.
Каждый разработчик проектирует свою подмодель. Подмодели легко интегрируются в одну большую модель.
Моделирование данных (IDEF1-, IDEF1X- и ER-методологии). Пакет позволяет создавать информационные модели, которые представляют собой как собственно данные, так и связи между ними. Информация, содержащаяся в IDEF-моделях, экспортируется в любую базу данных, а сами модели могут быть экспортированы в Design/CPN — пакет динамического моделирования сложных систем. Как CASE-продукт по разработке программного обеспечения пакет Design/IDEF поддерживает первые этапы создания программного продукта, которыми являются: * формулировка требований и целей проекта; * разработка спецификаций (формализованное описание требований); * создание проекта (определение подсистем и их взаимодействий); * документирование проекта (создание базы данных проекта, текстовое описание составных частей проекта); * анализ проекта (проверка проекта на полноту и непротиворечивость). Результатом работы пакета Design/IDEF является проект программной системы, состоящий из двух частей: 1) проекта функциональной структуры системы, содержащего иерархически связанные страницы с IDEF0-диаграммами и описывающего все модули (вплоть до элементарных функций) системы, их взаимосвязи, входные и выходные параметры; 2) проекта информационной структуры системы — логической модели ее базы данных, описывающей все структуры и взаимосвязи данных. С помощью средств пакета Design/IDEF оба проекта проверяются на полноту и непротиворечивость, дополняются базой данных проекта и документацией. Пакет Design/IDEF работает в различных операционных средах: Windows, Macintosh, Unix и др. можно переносить диаграммы из одной операционной среды в другую.
5.2.2. Инструментальный комплекс моделирования G2 G2 — инструментальный комплекс для создания динамических интеллектуальных систем в управлении и моделировании.
Комплекс разработан фирмой Gensym (США), которой сегодня принадлежит 50% мирового рынка интеллектуальных систем, используемых в системах управления. Все 25 самых крупных индустриальных мировых корпораций используют G2 [3]. Классы задач, для которых предназначена система G2: системы моделирования; составление расписаний и планирование; диагностика; мониторинг в реальном масштабе времени; системы проектирования и др. Основное достоинство G2 — возможность применения ее, как интегрирующей компоненты, позволяющей за счет открытости архитектуры легко объединять разрозненные средства автоматизации в единую комплексную систему управления, охватывающую все аспекты производственной деятельности — от формирования портфеля заказов до отгрузки готовой продукции.
Система G2 базируется на объектно-ориентированной технологии, которая в настоящее время является главной тенденцией в области новых информационных технологий. Все компоненты G2 можно разделить на три основные группы (см. рис. 5.3): база знаний (знания и данные), управляющие подсистемы, интерфейс [3]. База знаний. Все знания в системе G2 хранятся в двух типах файлов: базы знаний, где хранятся знания о приложениях, и библиотеки знаний, где хранятся общие знания, используемые более, чем в одном приложении. Глобально сущности в базе знаний (БЗ) можно разделить на структуры данных и исполняемые утверждения (см. рис. 5.3). Структуры данных. Основой представления знаний в G2 является понятие класса.
Все, что хранится в БЗ и чем оперирует система, является экземпляром того или иного класса. Опишем наиболее важные классы: * объекты — представляют собой объекты реального мира в приложении.
С каждым объектом ассоциируется таблица атрибутов, элементами которой является пары «атрибут-значение»; * связи — предназначены для отображения путей между объектами.
Можно создать классы связей для указания различных типов потоков между объектами. Например, объекты могут быть соединены водопроводными трубами и/или проводами; * рабочие пространства — отображаются, как ограниченные рабочие области, в которые можно помещать объекты и объединять их в схемы. Каждый экземпляр объекта может обладать своим рабочим пространством, представляющим его внутреннюю структуру. Все классы G2 обладают по крайней мере одним общим свойством — их экземпляры имеют графическую форму представления.
С помощью графических образов можно строить схемы систем для любого уровня сложности.
Исполняемые утверждения. Основные виды утверждений — правила, процедуры, формулы, функции. Правила имеют условия и заключения и представляются в виде: if then . В набор действий входят: присвоение значения атрибуту или переменной; создание или удаление экземпляра объекта; изменение положения пиктограммы объекта; запуск процедуры и т.д. Управляющие подсистемы. Основными управляющими модулями G2 являются машина вывода, планировщик и подсистема моделирования. Машина вывода выполняет рассуждения на основании знаний, содержащихся в БЗ, и данных, поступающих от подсистемы моделирования или от внешних источников. Машина вывода проверяет и исполняет правила. Планировщик координирует одновременное выполнение множества задач. Он определяет порядок обработки задач, взаимодействует с источниками данных и пользователями, запускает процессы и осуществляет коммуникацию с другими процессами в сети. Подсистема моделирования используется для имитационного моделирования реальных объектов и устройств, например, для имитации показаний датчиков. В подсистеме моделирования предусмотрены средства для вычисления алгебраических и дифференциальных уравнений, возможность задания формул и т.д. Интерфейс. Поскольку G2 является средством для разработки конкретных приложений реального времени, он располагает мощной средой разработчика, автоматизирующей создание приложений, а также средствами, обеспечивающими интерфейс с внешним окружением Среда разработчика включает в себя: * естественно-языковой текстовый редактор, управляемый процедурой грамматического разбора; * средства создания графического интерфейса с пользователем, позволяющие создавать и редактировать пиктограммы объектов, создавать различные типы графиков, формировать интерфейс конечного пользователя с приложением (создавать меню, управляющие элементы и т.д.); * средства инспекции и отладки, позволяющие осуществлять поиск элементов в БЗ, трассировку, обнаружение ошибок и др. Интерфейс с внешним окружением обеспечивает групповую работу с приложением на принципах архитектуры распределенной обработки «клиент-сервер». Кроме того, специальные средства позволяют легко интегрировать G2-приложение в существующие системы управления. На базе инструментального комплекса G2 разработано множество проблемно-ориентированных расширений для быстрой реализации сложных динамических систем. Одно из таких расширений — комплекс Rethink — было разработано специально для проведения реинжиниринга. Основные возможности системы Rethink [3]: 1. Формирование моделей бизнес-процессов в виде диаграмм, состоящих из блоков и соединений. Блоки представляют собой задачи в бизнес-процессах, а соединения — потоки сущностей (информации, предметов). Свойства и поведение блоков могут описываться как точными, так и случайными величинами. Поддерживается создание иерархических моделей, позволяющих описывать процессы с различной степенью детализации. 2. Определение различных параметров процессов, таких, как время, стоимость и др. Специальные инструменты позволяют получать отображать в числовой и графической форме параметры моделируемых процессов в заданных точках модели. 3. «Проигрывание» моделей, проверка гипотез «Что, если». Для этих целей в системе реализован механизм сценариев, которые позволяют исследовать зависимость поведения модели от поведения внешнего мира и каких-либо параметров модели. При этом все изменения параметров сразу отражаются на графическом изображении модели, что обеспечивает наглядность и понятность процессов. По результатам «прогона» модели автоматически формируется отчет. Как и комплекс G2, система Rethink функционирует на большинстве типов компьютеров в различных операционных средах, а также поддерживает коллективную работу на основе архитектуры «клиент-сервер». Контрольные вопросы 1. Какие основные возможности предоставляют инструментальные средства поддержки реинжиниринга? 2. По каким параметрам отличаются существующие на современном рынке инструментальные CASE-средства? 3. Каковы основные группы инструментариев, используемых в BPR? Для каждой группы средств опишите назначение и основные функции. 4. Приведите краткую характеристику пакета Design/IDEF. 5. Приведите краткую характеристику инструментального комплекса G2 и системы Rethink. 6. МЕТОДИЧЕСКИЕ УКАЗАНИЯ ПО ИЗУЧЕНИЮ ДИСЦИПЛИНЫ «СИСТЕМНЫЕ ТЕХНОЛОГИИ ПРОЕКТИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ» 6.1. Цели и задачи дисциплины, ее связь с другими дисциплинами Цель дисциплины — дать знания и умения в перепроектировании (реинжиниринге) бизнес-систем на основе новых информационных технологий с использованием современных методов моделирования и инструментальных средств поддержки. Основными задачами изучения дисциплины являются: а) изучение теоретических основ технологии проектирования бизнес-процессов; б) приобретение практических умений и навыков в моделировании бизнес-процессов, а также в разработке информационных систем поддержки бизнес-процессов. Связь дисциплины с другими учебными дисциплинами. Изучение данной дисциплины базируется на дисциплинах «Теория организации» и «Системный анализ и исследование операций». 6.2. Рабочая программа 6.2.1. Программа изучения дисциплины