Что означает конечная граница процесса

14.04.202217.04.2022 admin 0 Comments

1.2.2. Границы процесса

Понятие границ процесса является важнейшим при внедрении процессного подхода. Подчеркну, что установление границ осуществляется субъективно – путем достижения договоренности между несколькими сторонами (поставщиками и потребителями). Для обсуждения границ процесса нужно сформулировать несколько определений.

Границы процесса – событие (совокупность событий), инициирующее и завершающее процесс.

Событие – наступление определенной ситуации (времени, перехода ответственности за ресурсы).

Инициирующее событие – событие, при наступлении которого начинается процесс.

Завершающее событие – событие, которым завершается процесс.

Пусть ресурс «А» является результатом преобразования в некотором процессе (рис. 1.2.2). С точки зрения владельца этого процесса ресурс «А» – выход. С точки зрения владельца процесса-потребителя ресурс «А» – вход. В момент передачи ресурса «А» от одного процесса к другому происходит переход ответственности за этот ресурс между владельцами процессов. Факт движения ресурса, сопровождающийся переходом ответственности, может быть идентифицирован при помощи события. С точки зрения владельца первого процесса это событие завершает процесс, с точки зрения владельца второго процесса – инициирует его. Одно и то же событие может быть сформулировано по-разному при описании границ двух рассматриваемых процессов. Первый владелец скажет, что ресурс «А» передан, а второй – что ресурс «А» получен. Чтобы при описании процессов было удобнее увязывать их в единую систему, лучше определять одно событие и давать ему примерно такую формулировку: «Ресурс “А” передан из процесса 1 в процесс 2»[11]. В любом случае формулировки событий должны быть обязательно согласованы между владельцами процессов при регламентации границ.

Рис. 1.2.2. Границы процессов

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

• «Товар помещен в зону хранения»;

• «Продукция упакована и передана покупателю»;

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

• «Поступил заказ клиента»;

• «Руководитель дал отмашку».

Последний пример приведен в шутку. С практической точки зрения такая формулировка события недопустима. Лучше сформулировать так: «Поступило распоряжение руководителя приступить к выполнению работы» (желательно в письменной форме или хотя бы по e-mail).

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

Рассмотрим более сложные случаи, когда событие, завершающее один процесс, не является событием, инициирующим другой процесс. Допустим, в одном из подразделений организации сотрудник подготовил отчет и поместил его на сервер. Завершающее процесс событие можно сформулировать так: «Отчет подготовлен и размещен на сервере». Через некоторое время (например, в конце месяца) сотрудник другого отдела скачивает или открывает на сервере и использует необходимую информацию. Событие, инициирующее его процесс, казалось бы, можно зафиксировать как «Получен отчет такой-то». В реальности отчет мог пролежать на сервере несколько дней до того момента, пока им воспользовались. Как быть? Ответ в формулировке события, инициирующего второй процесс. Это можно сделать так: «Наступил срок подготовки сводного отчета». Далее сотрудник проверяет наличие отчета на сервере. Результат – следующее событие: «Отчет такой-то присутствует на сервере». Очевидно, что определение такого типа событий зависит от степени детализации при описании процесса.

Еще пример: рассмотрим отправку какого-либо документа по корпоративной электронной сети. Факт отправки документа сотрудником можно описать событием «Документ отправлен по e-mail». Однако сотрудник, которому отправлен данный документ, может его получить не сразу или вообще не получить (сбой сети, случайное удаление и т. п.). Значит, инициировать процесс второго сотрудника будет событие «Получен документ по e-mail». Очевидно, что это два разных события. В данном случае можно:

• использовать две разные формулировки событий, как было показано выше;

• рассматривать передачу документа по электронной сети в качестве самостоятельного, но автоматически выполняемого процесса, имеющего своего владельца и т. п.[12]

Мы рассмотрели первую значительную группу событий, которые идентифицируются при проведении анализа движения ресурсов (как материальных, так и информационных). Вторая группа – это события, связанные с достижением некоторого времени по абсолютной или относительной хронологической шкале. Например, событие «Наступило 8 Марта» указывает на календарную дату, то есть привязано к календарной дате (абсолютная шкала[13]). Событие «Прошло два рабочих дня после поступления заказа» указывает на наступление некоторого времени по относительной шкале, измеряемой в днях (начало шкалы приходится на момент поступления заказа). В зависимости от процесса масштаб временно?й шкалы различен: месяцы, дни, часы и даже минуты.

Итак, для четкого определения границ процесса необходимо:

• определить, какие ресурсы движутся внутрь и вовне процесса (входы и выходы);

• определить инициирующие и завершающие события;

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

Данный текст является ознакомительным фрагментом.

Продолжение на ЛитРес

Как правильно определить границы процесса

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

Почему так важно правильно определить границы процесса

Не стоит недооценивать значимость определения границ бизнес процессов.

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

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

В методологии управления бизнес процессами существует раздел под названием Process discovery – открытие или определение процессов, который включает в себя идентификацию процессов и определение границ.

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

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

Завершение одного процесса всегда является началом другого.

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

Вход – это то, что процесс берет в работу, перерабатывает и из чего производится продукт процесса.

Исходя из концепции «входов-выходов», именно по поступающим в процесс входам (по совместительству продуктам других процессов) и продуктам на выходе рассматриваемого процесса определяют границы процесса. Проще говоря, границы процесса определяются поступлением входов и завершением производства продуктов.

Так вот. Это неверно!

Определить границы процесса – это решить несколько задач. Одна из них – установить, в каком случае процесс начинает свое выполнение и когда можно сказать, что процесс завершен. Можно ли сказать, что процесс всегда начинается при поступлении в него входа? Нет. Вход необходим для «производства» продукта, но поступление входа вовсе не означает, что процесс сразу же начнет работу. Процесс может начаться задолго до или после поступления входа. И на это может оказывать влияние куча факторов.

Входы, выходы и события границ процесса

Вы находитесь на рабочем месте и захотели есть. Но в компании не принято уходить на обед «когда вздумается» и есть отведенное для этого время. Именно наступление времени обеденного перерыва начнет выполнение процесса «Обед». В данном случае чувство голода или потребность в его удовлетворении является входом процесса. Но лишь время обеденного перерыва будет являться тем спусковым крючком, тем событием, которое начнет выполнение процесса.

Событие начала

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

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

То же самое касается завершения процесса. Любой процесс должен завершаться событием окончания, которое удобно рассматривать как условие, при наступлении которого мы считаем, что процесс завершен.
Опять же, процесс может не заканчиваться производством своего продукта. В нашем примере с обедом продуктом процесса является удовлетворенный голод. Но означает ли это, что процесс “Обед” будет завершен тогда, когда вы наелись? Конечно же, нет. Более того, есть несколько событий, которыми может закончится обед. Это может быть истечение установленного времени, возвращение на рабочее место или нечто иное.

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

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

Событие окончания одного процесса логически связано с событием начала другого

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

Не все события, которые начинают процесс, формальны

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

С событиями разобрались. Теперь вернемся ко входам и продуктам процессов.

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

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

Переход права собственности на продукт процесса.

И тут начинается самое интересное.

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

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

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

Входов и продуктов процесса может быть множество.
Существуют основные и второстепенные продукты. И о второстепенных не стоит забывать.
Для определения начальной границы должна быть четко определена связка «поставщик – переход права собственности – вход – событие начала»
Для определения конечной границы должна быть связка «продукт – переход права собственности – клиент процесса – событие окончания»

Участники бизнес процесса

Участники бизнес процесса в общем и владелец процесса в частности – это неотъемлемые части полноценного определения границ процесса. Это позволяет связать процесс с организационной и функциональными структурами организации.

К слову, при определении бизнес процессов мы избегаем понятия «организационная единица», будь то отдел, департамент или конкретная должность. В управлении бизнес процессами базовой единицей участника процесса является роль.

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

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

Границы процесса также зависят от того, какие ресурсы использует процесс и каким образом они в него попадают. Определение ресурсов, способа их поступления и перехода права собственности аналогично передаче продукта одного процесса на вход другому процессу. Фактически то, что является ресурсом для одного процесса, является продуктом другого. Надеюсь, эта мысль понятна из вышеописанного.

Управление или осуществление управленческого цикла процесса

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

Да, мы говорим сейчас о цикле Деминга – PDCA.

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

Процесс производства можно разбить на:

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

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

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

Как правильно определить границы процесса

Резюме

Для того, чтобы правильно определить границы бизнес процесса, необходимо:
1. Определить, к какому типу относится процесс на верхнем уровне – основной, вспомогательный или процесс управления.
2. Конкретизировать продукты процесса и процессы, которые дальше используют эти продукты.
3. Формализовать механизм перехода права собственности продукта процесса.
4. Понять, какие части процесса относятся к непосредственному выполнению операций по производству продукта процесса, а какие к управлению.
5. Определить входы и источники входов процесса.
6. Обозначить события начала и окончания процесса.
7. Определить владельцев процесса и его участников.
8. Понять, какие ресурсы использует процесс и откуда их получает.
9. Дать название процессу, определяющее его суть.

Теперь вы знаете, что нужно делать, чтобы правильно определить границы процесса.

Источник

Business Studio, нотация «Процедура»: границы процессов, события, стрелки

Владимир Репин

Генеральный директор ООО «Владимир Репин Менеджмент»

Руководитель отдела Анализа и методологического обеспечения ПО № 8 ГБУ «Аналитический центр» Департамента экономической политики и развития города Москвы

Консультант по управлению

Кандидат технических наук

Введение

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

Границы процессов

На рис. 1 показано, что для определения границ любого процесса необходимо определить:

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

Рис. 1. Определение границ процесса: входы/выходы и события

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

Давайте попытаемся понять, что же такое «событие». В «Википедии» приводится следующее определение:

«Событие — то, что имеет место, происходит, наступает в произвольной точке ; значительное происшествие…»

Определение, конечно, не очень четкое. Оно скорее философское. Посмотрим, что говорят профессиональные стандарты.
В стандарте ISO 19510 «Information technology — Object Management Group Business Process Model and Notation» в разделе 8.4.5 Events приводится следующее определение события:

К сожалению, это тоже не самое понятное и четкое определение.

Обратимся к стандартам ARIS. Определение, приводимое в «Методах ARIS» сформулировано следующим образом:

Указанное определение является более четким и практически ориентированным.

Так же приведем определение события, сформулированное разработчиком среды моделирования Business Studio:

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

С точки зрения практических задач моделирования можно определить, как минимум, три разных типа событий, на примере которых понятие события становится более очевидным (см. примеры на рис. 1):

Итак, ключевое назначение событий в модели:

Подчеркнем, понятие «событие» используется во всех современных нотациях, используемых для моделирования на операционном уровне (WorkFlow): eEPC, BPMN 2.0, CFFC. Далее в статьях серии мы рассмотрим, каким образом применяются события, и определяются границы процессов в указанных нотациях.

Нотация «Процедура» Business Studio

Входы/выходы процесса

Посмотрим, каким образом визуально можно показать границы процесса в нотации «Процедура» (CFFC — Cross Functional Flow Chart)среды моделирования Business Studio.

Рис. 2А. Схема процесса в нотации «Процедура» (CFFC, простая )

На рис. 2А показано событие «Поступил запрос от клиента». Оно является инициирующим для рассматриваемого процесса. Справа от операции процесса «Выполнить анализ запроса» показаны стрелки с двумя наконечниками — информационные входы. Заметим, что эти входы не «висят в воздухе». Один из них привязан к внешней ссылке «Клиент». Другой вход поступает из процесса «Управление ценообразованием». Так же «Счет на оплату товара» и «Информация об отказе» являются выходами процесса. Они поступают к клиенту. «Счет на оплату» поступает так же в процесс «Контроль оплаты счетов».

Обратим внимание читателя, что на схеме процесса использовано два типа стрелок:

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

Заметим, что стрелки типа «Связь предшествования» можно не именовать. Но автор статьи придерживается стиля, при котором такие стрелки именуются в терминах событий, например: «Запрос не соответствует номенклатуре», «Счет на оплату подготовлен». Это делается исключительно с целью повышения визуальной наглядности схемы для пользователей.

Пример, представленный на рис. 2А., показывает, откуда в процессе берутся информационные входы, и как ведут себя выходы. Очень важно при моделировании процессов всегда помнить о том, что ни входы, ни выходы процесса не должны «повисать в воздухе».

Отметим, что если бы стрелка «Счет на оплату товара» с двумя тёмными наконечниками не была присоединена к кружку «Контроль оплаты счетов» (это условное обозначение т.н. междиаграммной ссылки в Business Studio), то это означало бы ее миграцию на верхний уровень.

Наоборот, если наконечники стрелки светлые (см. на рис. 2А стрелку «Пример»), то в соответствии с принятыми в Business Studio условными обозначениями это означает, что стрелка туннельная, и не будет показана на диаграмме верхнего уровня.

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

Использование событий

На рис. 2А представлено два события:

Тем специалистам, которые работали с нотацией eEPC, возможно, захотелось бы использовать промежуточные события по ходу процесса, как показано на рис. 2Б. К сожалению, промежуточные события в нотации «Процедура» Business Studio не поддерживаются. Показать их на схеме процессам можно, но использование варианта, представленного на рис. 2Б, приведет к плачевным последствиям — операции процесса не будут соединены связями предшествования, вследствие чего некоторые функциональные возможности системы не будут работать. Например, нельзя будет получить часть регламента, содержащую перечень следующих операций. Невозможно будет осуществить имитационное моделирование процесса и прочее.

В нотации «Процедура» Business Studio можно восполнить недостаток, связанный с невозможностью использования промежуточных событий процесса, именуя стрелки типа «Связь предшествования» в терминах событий, как было сказано выше.

Кроме того, в для каждой операции (действия) процесса можно заполнять два текстовых поля: «Начало» и «Результат». Эти текстовые поля легко вывести в соответствующий раздел регламента процесса для пояснения, с какого события начинается, и каким событием завершается операция процесса или процесс в целом. Заполнение текстовых полей «Начало» и «Результат» для каждой операции процесса в нотации «Процедура» является хорошим упражнением, которое способствует более глубокому пониманию и формированию качественной модели процесса.

Рис. 2Б. Промежуточные события в нотации «Процедура» (CFFC, простая )

Миграция и туннельные стрелки

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

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

На рис. 3. показаны описанные выше ситуации.

Рис. 3. Использование миграции и междиаграмммных стрелок

В Business Studio миграцию и междиаграммные ссылки можно использовать в нотациях «Процедура» и IDEF0. Заметим, что в нотациях eEPC и BPMN в Business Studio нет ни миграции, ни междиаграммныхсссылок. Взаимодействие между процессами в этих нотация можно показать ( в eEPC и свернутый пул в BPMN).

Привязка документов к стрелкам

В нотации «Процедура» есть еще одна любопытная особенность, связанная с архитектурой самой среды BusinessStudio. Заключается она в том, что к стрелкам на диаграмме в нотации «Процедура» (и еще в нотации IDEF0) можно привязывать объекты из справочника «Объекты деятельности» как показано на рис. 4.

Рис. 4. Привязка документов к стрелкам

Для чего это делается? Проще всего понять это, взглянув на рис. 5. Объект из справочника объектов деятельности (бумажный или электронный документ) привязывается к стрелке, показанной на диаграмме процесса. К этому объекту может быть привязан реальный файл MSWord. Практический смысл такой привязки:

Заметим, что форма документа в виде файла может быть либо закачана в базу Business Studio, либо на нее может быть сделана ссылка на внешний источник (файл, находящийся на жестком диске).

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

Рис. 5. Смысл привязки документов к стрелкам в Business Studio

Стоит подчеркнуть, что стрелка с двумя наконечниками, собственно, моделирует вход/выход на первом уровне абстракции (Словарь стрелок хранится в специальном справочнике Business Studio). На втором, более детальном, уровне используются ресурсы из справочника «Объекты деятельности», привязанные к стрелкам. И этот факт является еще одним «подводным камнем» при использовании нотации «Процедура». Некоторые неопытные пользователи Business Studio ленятся привязывать объекты к стрелкам. В результате, в регламенте процесса появляются пустые места. Некоторые, наоборот сознательно используются стрелки именно как входы/выходы и выводят в регламент названия стрелок, а не документов. Последний подход, на мой взгляд, является методически некорректным.

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

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

Плохой стиль моделирования процессов в Business Studio

В заключение на рис. 6 представлен «плохой», методически некорректный стиль использования нотации «Процедура» в Business Studio.

Рис. 6. «Плохой» стиль моделирования в нотации «Процедура»Business Studio

Предлагаем читателю самому найти ошибки (методически некорректные моменты) в данной схеме. В следующей статье серии мы приведем соответствующие ответы.

Резюме

Среда моделирования Business Studio предоставляет пользователям гибкие возможности для описания и регламентации в нотации «Процедура» (CFFC, простая ). Но сотрудникам компаний, неискушенным в моделировании, необходимо отдавать отчет в каждом своем действии в системе: что и для чего делается. Моделировать просто так, наобум — напрасно тратить время и деньги компании. Качество полученных моделей предопределяет возможность использования их для анализа и принятия решений по реорганизации, выгрузки из системы регламентирующих документов по и проч.

Источник

Для чего все в жизни происходит?

Что означает конечная граница процесса

1.2.2. Границы процесса

Читайте также

Личные границы

Мои границы и меры за их пресечение

Здравствуйте, я письмо из-за границы!

3.1. ПЛАНИРОВАНИЕ ПРОЦЕССА

Установите свое присутствие и очертите его границы

Риторические парадоксы – камень преткновения аргументации или границы языковых способностей?

Как правильно определить границы процесса