Лекции по КиС
.pdf«Oracle», поддерживает базы данных Ingres, RDB и INFORMIX. «Metaphase» помимо Oracle планирует поддержку Sybase
и INFORMIX. Система «Optegra» работает только с Oracle. Matrix –
это единственный коммерческий продукт PDM, поддерживающий объектно-ориентированную СУБД: Objectivity. Однако архитектурные принципы систем компаний «Metaphase» и «Computervision» также позволят им использовать СУБД в будущем.
Поддержка распределенных хранилищ данных является одним из основных требований к реализации систем PDM в масштабах предприятия. Возможности работы с неограниченным числом распределенных баз данных и поддержку множества конфигураций серверов баз данных предоставляют сегодня системы фирм «Computervision», «Metaphase», «Sherpa» и «IBM». «Eigner» и «НР» не предлагают таких возможностей, однако «Hewlett-Packard» анонсировала их реализацию.
Контрольные вопросы
1.Что такое PDM/PDL?
2.Каковы особенности пользовательской среды?
3.Какие достоинства и недостатки PDM/PDL-систем можно выде-
лить?
81
9.СИСТЕМА КЛАССА WfMS/BPMS
ИWORKFLOW-ДИАГРАММЫ
9.1. Основные понятия WfMS/BPMS
Технология потока работ (workflow) впервые дала о себе знать в конце 1980-х – начале 1990-х гг. Весьма скоро появилась соответствующая организация – Коалиция по управлению потоком работ
(Workflow Management Coalition, WfMC), которая уже в 1994 г. вы-
пустила свой первый официальный документ – словарь-глоссарий Terminology & Glossary. Третья редакция этого документа (февраль 1999 г.) определяет термин «поток работ» (workflow) следующим образом: «Автоматизация бизнес-процесса, полная или частичная, в процессе которой документы, информация или задания передаются от одного участника к другому для выполнения им действия в соответствии с набором процедурных правил».
Поток работ обычно включает в себя некоторое количество логических шагов, каждый из которых известен как действие (activity). Действие может подразумевать ручное взаимодействие с пользователем или участником потока работ (workflow participant) либо может выполняться с использованием машинных ресурсов. Доставка работы пользователям увеличивает эффективность. Автоматизация фактической работы обеспечивает огромный рост эффективности, а также предоставляет менеджерам возможности создания виртуальной организации и эффективного участия в электронной коммерции.
В том же упомянутом словаре-глоссарии система управления потоком работ (workflow management system) определяется так: «Система, которая определяет, создаёт и управляет выполнением потоков работ посредством использования программного обеспечения, работающего на одном или нескольких движках потока работ, которые способны интерпретировать определения процессов, взаимодействовать с участниками потока работ и, при необходимости, использовать инструменты и приложения информационных технологий».
Было бы большим упрощением считать, что система управления потоком работ (СУПР) управляет потоком работ. Тем не менее, суть СУПР состоит в том, что она может интерпретировать определение потока работ, обычно, но не всегда, созданное по отдельности,
82
управлять триггерами, сигнализаторами, а также взаимодействовать с внешними системами. Важно заметить, что это определение покрывает спектр СУПР, исключая при этом просто системы реляционных баз данных и системы электронной помощи с программируемыми механизмами доставки. Схема автоматизации бизнес-процесов представлены на рис. 7.
Бизнес-процесс
(т.е. то, что должно случиться)
определяется |
в |
|
управляется
Определение процесса
(представление того, что должно случиться)
Подпроцессы |
из |
|
состоит |
используется |
для |
управления |
|
|
создания |
Система управления потоком работ
(контролирует автоматизированные аспекты бизнес-процесса)
через
Экземпляры процесса
Действия
которые могут быть |
|
или |
|
Действия вручную |
Автоматизированные |
(которые не управляются как |
действия |
часть системы рабочего потока) |
|
(представление того, что фактически происходит)
включают одно или больше
во время выполнения Экземпляры
представляются |
действий |
|
|
|
которые включают |
|
и/или |
Элементы работы |
Задействованные |
(задания, выданные |
приложения |
участнику рабочего потока) |
(компьютерные |
|
|
|
инструменты/приложения, |
|
используемые для |
|
поддержания действия) |
Рис. 7. Схема автоматизации бизнес-процессов
Бизнес-процесс (business process) – набор из одной или нескольких связанных процедур или действий, которые сообща реализуют деловую или политическую цель, обычно в контексте организационной структуры, определяющей функциональные роли и отношения.
Определение процесса (process definition) – представление бизнеспроцесса в форме, которая поддерживает автоматизированное управление. Определение процесса состоит из совокупности действий
83
и взаимоотношений между ними, критериев начала и окончания процесса, а также информации об отдельных действиях (рис. 8).
Системные данные и данные окружения
|
|
Определение процесса |
|
|
||
|
|
|
потока работ |
может ссылаться на |
|
|
|
|
|
|
|
|
Определение |
|
|
состоит из |
|
|
|
(под)процесса |
может |
|
Соответствующие |
может |
Действие процесса |
реализуется |
Атомарное |
включать |
данные потока работ |
использовать |
потока работ |
как |
действие |
|
|
||||||
|
использовать |
|
исполняется |
может задействовать |
|
Цикл |
|
|
|
|
|
||
|
|
|
|
|
|
|
|
|
|
|
|
к |
|
|
|
|
|
|
от |
|
|
может |
Спецификация участника |
Описание приложения |
Переходная информация |
||
|
потока работ |
потока работ |
|
(включая управление циклами) |
||
|
|
|
может |
|
|
|
|
|
|
использовать |
|
|
|
|
|
|
может ссылаться |
|
|
|
|
|
Организационная |
|
|
|
|
|
|
|
модель |
|
|
|
|
Рис. 8. Схема обработки потока работ |
|
|
|||
Действие (activity) – описание части работы, которая составляет один логический шаг в рамках процесса. Действие может быть ручным, не поддерживающим компьютерную автоматизацию, либо автоматизированным действием потока работ. Действие потока работ требует человеческих и/или машинных ресурсов для поддержания выполнения процесса; когда требуется человеческий ресурс, действие назначается участнику потока работ.
Автоматизированное действие (automated activity) – действие, которое поддаётся компьютерной автоматизации с использованием СУПР для управления действием во время выполнения бизнеспроцесса, частью которого оно является.
Ручное действие (manual activity) – действие в рамках бизнеспроцесса, которое не поддаётся автоматизации и поэтому находится за пределами СУПР. Такие действия могут включаться в определение процесса, например, для поддержания моделирования процесса, но они не являются частью результирующего потока работ.
Экземпляр (instance, применительно к процессу или к действию) – представление отдельного исполнения процесса или действия в рамках процесса, включая связанные с ним данные. Каждый экземпляр
84
представляет собой отдельный поток выполнения (при наличии в процессе параллельных действий его экземпляр может включать несколько одновременно выполняющихся потоков) процесса или действия, управляемый независимо и имеющий своё собственное внутреннее состояние и видимую снаружи сущность, которая может использоваться как указатель, например, для записи или извлечения проверочных данных, относящихся к отдельному исполнению.
Экземпляр процесса (process instance) – представление отдельного исполнения процесса.
Экземпляр действия (activity instance) – представление действия в рамках (отдельного) исполнения процесса, то есть в рамках экземпляра процесса.
Участник потока работ (workflow participant) – ресурс, который выполняет работу, представленную экземпляром действия потока работ. Эта работа обычно представляется в виде одного или нескольких элементов работы, назначенных участнику потока работ посредством списка работ.
Элемент работы (work item) – представление работы, которая будет выполняться (участником потока работ) в контексте действия экземпляра процесса.
Список работ (worklist) – список элементов работы, связанных с данным участником потока работ (или, в некоторых случаях, с группой участников, которые могут разделять между собой общий список работ). Список работ составляет часть интерфейса между ядром потока работ и обработчиком списка работ.
Обработчик списка работ (worklist handler) – программный компонент, который управляет взаимодействием между пользователем (или группой пользователей) и списком работ, поддерживаемым ядром потока работ. Этот компонент позволяет передавать элементы работы от СУПР к пользователям, а также уведомления о завершении или другие сообщения о состоянии работ между пользователем и системой (рис. 9).
WAPI (Workflow APIs and Interchange Formats) – набор программ-
ных интерфейсов приложений и форматов обмена потока работ, публикуемый WfMC, и объединяющий в себе спецификации для взаимодействия между различными компонентами систем и приложения управления потоком работ (рис. 10).
85
Инструменты определения процессов
Интерфейс 1
Программый интерфейс и форматы обмена
Другие службы исполнения Служба исполнения 
Инструменты |
Интерфейс 5 |
|
Интерфейс 4 |
Ядро |
|
администрирования |
Ядро |
||||
|
|
потока |
|||
и наблюдения |
|
потока |
|
||
|
|
работ |
|||
|
|
работ |
|
||
|
|
|
потока работ |
||
|
|
потока работ |
|
||
|
|
|
|
||
|
|
Интерфейс 2 |
Интерфейс 3 |
|
|
|
|
Клиентские приложения |
Запускаемые |
|
|
|
|
потока работ |
приложения |
|
Рис. 9. Структура системы управления потоком работ
|
|
|
|
Инструмент/задача |
|
|
|
|
|
|
|
определения процесса |
Интерфейс |
||
|
|
|
|
|
|
||
|
|
|
|
создаёт/ |
|
определения процесса |
|
|
|
|
|
|
|
|
|
|
|
|
|
изменяет |
|
|
|
|
Организационная модель |
может |
Определение процесса |
|
Спецификации |
||
|
ссылаться на |
|
|||||
|
|
может |
|
обрабатывается |
наследует |
проверок и контроля |
|
|
|
ссылаться на |
|
|
свойства |
|
|
|
|
|
|
|
|
|
|
Внешний |
создаёт, |
Диспетчер |
создаёт и |
Экземпляр |
использует |
История экземпляра |
|
программный объект |
уничтожает, |
потока работ |
уничтожает |
процесса |
журнал контроля |
процесса |
|
изменяет |
|||||||
|
генерирует |
может |
|
||
Интерфейс |
|
||||
использовать |
|
||||
|
|
||||
управления/взаимодействия |
|
|
|
может |
обеспечивает |
|
|
||||
процессов и действий |
|
Данные, относящиеся вызывать |
|||
|
контекст |
||||
|
|
к потоку работ |
вызова |
||
|
|
||||
|
|
|
|||
|
|
|
Служба |
|
Элемент работы |
|
исполнения |
|
|
потока работ |
|
|
|
|
|
Интерфейс |
|
|
|
обработчика списка работ |
может |
Агент |
инструмента |
|
устанавливать |
|
|
|
обрабатывается |
|
|
Обработчик
списка работ может
Приложение
вызывать
представляется |
|
для предпринятия |
Интерфейс |
действия |
|
|
вызова приложений |
Участник
Рис. 10. Взаимодействие службы исполнения потока работ с интерфейсами
86
Этапы жизненного цикла процесса приведены на рис. 11.
Время построения |
Инструменты анализа |
|
|
Проектирование и |
бизнес-процессов, |
|
|
моделирования и |
|
||
определение |
|
||
определения |
|
||
процесса |
|
||
|
|
||
|
Определение |
|
|
Время выполнения |
процесса |
|
|
|
Изменения процесса |
|
|
Создание экземпляра |
Служба исполнения |
Управляющие данные потока работ |
|
процесса и управление |
потока работ |
||
|
|||
процессом |
|
Данные, относящиеся к потоку работ |
|
Время выполнения |
|
||
Приложения и |
|
||
|
Данные приложений |
||
Взаимодействие |
инструменты ИТ |
||
|
с пользователями и инструментами приложений
Рис. 11. Этапы жизненного цикла процесса
9.2.Официальная классификация систем управления потоком работ
Автономная СУПР (autonomous workflow) является функциональной без дополнительного ПО, за исключением систем управления базами данных и промежуточного ПО обмена сообщениями. Для развёртывания автономного решения технологии потока работ прикладные системы, которые являются внешними по отношению к СУПР, вызываются во время выполнения, а относящиеся к потоку работ данные передаются между участниками потока работ.
Встроенная СУПР (embedded workflow) является функциональной, только если она используется окружающей (встраивающей) системой, например, системой планирования ресурсами предприятия (Enterprise Resource Planning, ERP). Функциональность потока работ встроенных систем демонстрируется окружающей её программной системой. Стандартными примерами являются, как уже было отмечено, ERP-системы, а также платёжные системы и системы межбанковских расчётов. Компоненты потока работ используются для управления последовательностью функций приложения, управления очередями и обработки исключительных ситуаций.
Встроенные системы делятся на две категории: основанные на технологии потока работ (workflow-based) и системы с поддержкой
87
этой технологии (workflow-enabled). Решения, основанные на технологии потока работ, не являются функциональными без встроенной функциональности потока работ, тогда как системы просто с поддержкой этой технологии оставляют на усмотрение производителя вопрос о том, будет ли использоваться встроенный компонент потока работ в данном контексте. На рис. 12 представлена классификация систем упралвения потоком работ по примению.
Ориентация на клиента
постоянное
использование основной группой
Предприятие
Сотрудничество 
внешний процесс
|
Производство |
случайное |
|
использование по |
|
всей организации |
внутренний процесс |
неструктурированный |
структурированный |
процесс |
процесс |
Рис. 12. Классификация систем управления потоком работ по применению
Контрольные вопросы
1.Перечислите основные понятия WfMS/BPMS.
2.Проведите классификацию систем управления потоками работ по применению.
88
10. СИСТЕМЫ КЛАССА SCM
10.1. Основные понятия. Принцип работы SCM
Ни одна организация в настоящее время не в состоянии самостоятельно контролировать весь процесс (цепочку) пропизводсва, от добычи исходного сырья до продажи готового изделия конечному потребителю. Этот сложный цикл разбит на этапы (звенья), и множество организаций участвуют в нём как торговые партнеры (поставщики и покупатели), прежде чем железная руда, сырая нефть, песок или другие материалы превратятся, например, в новенький компьютер, счастливым обладателем которого станет какой-нибудь покупатель.
Последние несколько лет рынок программных продуктов для управления цепочками поставок активно развивается. Всё больше компаний приобретают программное обеспечение (ПО) для SCM, дополняя ими свои системы для планирования ресурсов и отказываясь от приобретения очередных версий ERP-систем, что привело к появлению новых игроков на этом рынке и падению доходов таких грандов, как Baan и SAP. Так, в 1999 г., на ежегодной конференции,
которую проводило Американское общество по управлению производством и запасами (American Production and Inventory Control Society, APICS), соотношение производителей, предлагающих SCM- и ERP-системы, составило 93 к 68. По оценкам компании «AMR Research», в период до 2004 г. рынок SCM-систем будет ежегодно увеличиваться на 40 %, в то время как рынок ERP-систем на столько же сокращаться.
Чтобы дать объяснение этому явлению, необходимо обратиться сначала собственно к самим управленческим методикам, которые лежат в основе автоматизированной системы управления производством (АСУП), так как именно они определяют пути развития ПО.
Можно сказать, что управление цепочками поставок представляет собой новую концепцию управления бизнесом и является итогом всех тех перемен, которые произошли в различных управленческих и технических дисциплинах за последние несколько десятилетий. А первыми внесли изменения в управление и организацию
89
производства японские промышленники (в частности, «Toyota»), использовавшие новую стратегию гибкого производства.
В Японии впервые была применена многоуровневая система поставок: производитель работал с ограниченным количеством поставщиков первого уровня, обеспечивавших его основными комплектующими, которые, в свою очередь, сотрудничали с ограниченным количеством поставщиков второго уровня, которые пред-
оставляли |
компоненты для производства этих комплектующих, – |
в такой |
системе использовался «тянущий» принцип вместо |
«толкающего», а именно: заказ на производство конечного изделия «тянул» комплектующие по всей цепочке поставщиков.
Кроме того, в маркетинговой стратегии организаций произошли изменения, поставившие в центр маркетинговой политики покупателя. Новая концепция предполагала, что компании сосредоточены не на своих потребностях, а на нуждах покупателей, производят то, что им (покупателям) необходимо, и получают прибыль именно за счёт максимального удовлетворения этих нужд. Но подобная ориентация требовала, во-первых, поставок разных модификаций товаров для различных регионов, во-вторых, частых обновлений линеек выпускаемых продуктов. Жизненный цикл товаров сократился на порядок – с нескольких лет до нескольких месяцев. В связи с этим всё большее развитие получают заказные формы организации производства, такие, как комплектация (Complete-To-Order, CTO), сборка (Assemble-To-Order, ATO), производство (Make-To-Order, MTO) и разработка на заказ (Engineer-To-Order, ETO). Теперь уже потребности конечного потребителя начали «тянуть» все компоненты по цепочке от исходных материалов до готового изделия. Необходимость работать с конечными покупателями по новой схеме привела к трансформации традиционных каналов распределения в вертикальные маркетинговые системы. Основное различие между системами заключалось в том, что в традиционном канале все участники работали порознь, стараясь обеспечить себе максимальную прибыль (иногда даже в ущерб партнерам), а участники вертикальной маркетинговой системы действовали как единый организм, повышая свою доходность именно за счёт координации и объединения усилий.
Развитие технологий тоже не стояло на месте. Появились рабоиы и полностью автоматизированные производственные линии, что способствовало совершенствованию гибких производств. Например, завод компании «Ford» в Ленгсдейле (по данным 1994 г.) ежедневно
90