Что такое вход процесса

Определение выходов и входов процесса. Выходы процесса. Входы и ресурсы процесса

Страницы работы

Фрагмент текста работы

Определение выходов, входов и ресурсов процесса

Входы и ресурсы процесса

Определение выходов и входов процесса

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

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

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

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

Что можно назвать выходами процесса?

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

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

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

Консалтинговые агентства проводят тренинги, семинары или маркетинговые исследования по заказу потребителей. Потребители устанавливают требования к содержанию, объёму и достоверности получаемой информации.

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

Для того, чтобы было легче определить, что является выходом процесса

Источник

Выделение бизнес-процессов организации: подход, основанный на результатах процессов

Александр Гончаров

Бизнес-аналитик компании «Бизнес-Архитектура»

Общепринятые подходы к выделению

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

В качестве референтных моделей могут быть выбраны: универсальная модель процессов OBM от Oracle, модель BKG и модель ИСО/МЭК/ТО 15504 ([3]), референтная модель APQC ([4]). Можно оттолкнуться от требований стандартов управления качеством ISO 9000:2000 ([5]). Существуют также отраслевые референтные модели (для банков [9], производственных [10], логистических компаний ).

Для этого применимы разные подходы (методы):

Предлагаем читателю самостоятельно ознакомиться с сутью этих методов [3], [4], [7],[8].

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

Принципы метода

В методе использованы следующие принципы:

Модель и классификация входов

При этом входы процесса удобно классифицировать на преобразующие, преобразуемые и управляющие.На рисунке 1 изображены входы и выходы процесса, расположенные согласно методологии SADT ([2]) и нотации IDEF0.

Рис. 1. Модель процесса, отражающая входы и выходы с их классификацией

Принцип классификации процессов по их основным выходам (результатам)

Рис. 2. Четыре группы любой организации

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

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

Рис. 3. Взаимосвязь основных и обеспечивающих процессов

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

Рис. 4. Взаимосвязь основных и управленческих процессов в контуре управления

Последовательное выделение процессов, начиная с их результатов

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

Учёт интересов всех заинтересованных сторон

Начало анализа: предназначение организации, ключевые заинтересованные стороны и результаты

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

Рис. 5. «Сферическая организация в вакууме»

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

Рис. 6. Определены ключевые потребители и результаты деятельности организации

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

Выделение основных

Построение цепочек ценности основных

Найденные результаты деятельности организации — не что иное, как выходы основных (как следует из вышеприведённого определения). Основные целесообразно представить в виде цепочки ценности (встречаются также термины цепочки добавленной стоимости, цепочки создания ценности), выделяя основные этапы создания результатов. Важно начинать с конца цепочки: от результата, предоставляемого потребителю. Результаты могут создаваться как одной, так и разными цепочками ценности, при этом цепочки на разных этапах могут объединяться и разъединяться.

Для описания цепочек ценностей можно пользоваться различными нотациями. Вполне подходит IDEF0. При этом нет необходимости перечислять и отображать на модели абсолютно все входы и выходы, как это часто делают: модель получается слишком громоздкой. На этом этапе важно зафиксировать ключевые этапы основных процессов, их выходы и участвующие подразделения. В методологии ARIS есть специальная нотация — VAD (value added chain — Диаграмма цепочек добавленного качества, [1]), автор обычно рисует цепочки ценности в аналогичном виде при помощи Visio.

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

Рис. 8. Цепочка ценности производственного предприятия

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

Рис. 9а. Цепочка ценности компании, строящей промышленные объекты (VAD)

Эта же цепочка ценности, созданная в программе Business Studio 4.0 с использованием нотации IDEF0, может выглядеть так:

Рис. 9б. Цепочка ценности компании, строящей промышленные объекты (IDEF0, Business Studio)

Такой путь описания основных полностью согласуется с построением потоков стоимости в концепции «бережливого производства» — Lean ([6]), но применимо для любых организаций. Цепочки ценностей торговых компаний или компаний, предоставляющих услуги, обычно намного проще.

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

Описание (предварительная спецификация) отдельных процессов

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

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

Выделение обеспечивающих

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

Какие нюансы здесь необходимо учитывать?

Выделение и описание управленческих процессов

На этом этапе также есть свои нюансы.

Управленческие процессы в этом подходе понимаются как совокупность процессов планирования и регулирования в контуре управления на разных уровнях управления (см. рис. 4).

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

Рис. 10. Уровни управления организацией

Моделирование процессов развития

Объединение процессов в единую сеть

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

Верификация модели

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

Кратко о преимуществах и недостатках метода

По мнению автора, метод обладает следующими преимуществами:

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

Источники информации

Источник

Вероятно, самый старый в рунете сайт о менеджменте качества

Действия являются самым ясным и выразительным раскрытием человека. (Г. Гегель)

Введение

Бизнес-процессы подразделения

Рисунок 1. Бизнес-процессы подразделения.

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

Рисунок 2. Взаимодействие бизнес-процессов подразделений.

В этом случае бизнес-процесс «Б» Подразделения 2 является поставщиком бизнес-процесса «А». Определяются границы процессов по входам и выходам, регламентируются требования (формы, сроки, ТУ и т.п.) по входам/выходам. Таким образом, деятельность внутри каждого подразделения четко структурируется, определяются зоны ответственности, распределяются ресурсы и, что очень важно, четко определяется порядок взаимодействия подразделений(3).

Сквозные бизнес-процессы

Рисунок 3. Сквозной (межфункциональный) процесс.

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

Выводы

Краткий сравнительный анализ подходов к выделению сквозных бизнес-процессов и бизнес-процессов подразделений показывает, что при внедрении процессного подхода к управлению в организации целесообразно:
Фаза 1.
a) построить сеть бизнес-процессов, выделяя процессы в рамках функциональных подразделений, назначить владельцев процессов;
b) описать бизнес-процессы подразделений и выполнить их регламентацию (- четко определяются границы процессов, необходимые для выполнения процессов ресурсы, налаживается взаимодействие между подразделениями по принципу «клиент-поставщик»);
c) разработать систему показателей оценки процессов, продуктов процессов и удовлетворенности клиентов;
d) запустить систему управления бизнес-процессами организации, основанную на выполнении цикла PDCA на всех уровням управления.
Фаза 2.
e) ЕСЛИ ЭТО ЦЕЛЕСООБРАЗНО, выделить сквозные процессы и назначить владельцев сквозных процессов;
f) описать и регламентировать сквозные процессы (используется уже существующие к этому моменту регламенты бизнес-процессов подразделений с четко описанными ресурсами), разработать механизмы выделения ресурсов владельцам сквозных процессов и механизмы управления сквозным процессом;
g) разработать систему контроля использования ресурсов сквозными процессами;
h) разработать систему показателей оценки сквозных процессов, продуктов процессов и удовлетворенности клиентов;
i) запустить цикл PDCA для сквозных процессов.

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

Источник

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, простая ). Но сотрудникам компаний, неискушенным в моделировании, необходимо отдавать отчет в каждом своем действии в системе: что и для чего делается. Моделировать просто так, наобум — напрасно тратить время и деньги компании. Качество полученных моделей предопределяет возможность использования их для анализа и принятия решений по реорганизации, выгрузки из системы регламентирующих документов по и проч.

Источник