Подписаться
Рубрикатор
Полный список
Развитие организации
Управление процессами
Моделирование процессов
Регламентация процессов
Автоматизация процессов
Бережливое производство
Менеджмент качества
Управление проектами
Дайджесты по Business Studio

Облако терминов
12-процессная модель 4PL ACM Activity diagram AQPC ARIS ARIS 9 ARIS eEPC Balanced Scorecard Big Data & Analytic BMPN BPA BPEL BPM BPM accelerator BPM CBOK BPM-система BPM-системы BPMN BPMS BPR BPWin BS Portal BSC Business Intelligence Business Performance Management Business Performance Management (BPM) Business Process Management Business Process Management Systems Business Process Manager Business Rules Business Studio Business Studio 3.6 Business Studio 4 Business Studio 4.0 Business Studio Portal CA ERwin Data Modeler Case Management Casewise Casewise Corporate Modeler CFFC Corporate Modeler CPM CRM Decision Management DFD Directum ECM

Опрос

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

Библиотека

08.09.2014 12:43
  от автора
  Репин

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

Оценки за материал: 5.00 (5)

В статье В.В. Репина рассматриваются практические аспекты определения границ процессов при моделировании в среде Business Studio в нотации «Процедура» (простая блок-схема, Cross Functional Process Chart). Так же обсуждается вопрос привязки документов к стрелкам. Статья адресована сотрудникам компаний, осваивающим моделирование процессов с использованием Business Studio 4.0.
Статья № 1 из серии статей.
Введение

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

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

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

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

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


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

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

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

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

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

«An Event is something that happens during the course of a Process (событие – эточто-то, чтослучаетсявовремявыполненияпроцесса)».

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

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

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

События переключают функции и могут быть результатом выполнения функции. Упорядочивание комбинации событий и функций в последовательность позволяет
создать событийные диаграммы процессов EPC (Event - Driven Process Chain - цепочка процесса, управляемая событиями). С помощью этих диаграмм процедуры
бизнес-процесса представляются как логические последовательности событий».


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

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

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

С точки зрения практических задач моделирования бизнес-процессов можно определить, как минимум, три разных типа событий, на примере которых понятие события становится более очевидным (см. примеры на рис. 1):
1. событие, связанное с поступлением (отправкой) ресурса (информации, материального объекта);
2. событие, связанное с наступлением определенного времени:
a. по абсолютной временной шкале;
b. по относительной временной шкале;
3. событие, связанное с выполнение определенного условия.

Итак, ключевое назначение событий в модели:
• обозначение начала процесса;
• маршрутизация процесса в зависимости от различных ситуаций;
• обозначение завершения процесса.

Подчеркнем, понятие «событие» используется во всех современных нотациях, используемых для моделирования бизнес-процессов на операционном уровне (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. Использование миграции и междиаграмммных стрелок.

На рис. 3 показано, что документ «А» является выходом подпроцесса 1.2.3.1. и входом подпроцесса 2.3.2.2. Использована методика миграции стрелок. В свою очередь документ «Б» является выходом подпроцесса 1.2.3.2. и входом подпроцесса 2.3.3.3. При этом использован механизм создания междиаграммных ссылок.

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

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

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


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

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

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

В.В. Репин,
к.т.н., Исполнительный директор и партнер ООО «BPM Консалтинг Групп»,
доцент кафедры Бизнес-информатики и систем управления производством Национального Исследовательского Технологического Университета.


Сентябрь 2014 г.

Комментарии

Оценки: /
08.09.2014 16:08
  от автора
  Amberk
Владимир Владимирович, относится ли данный тезис к нотации IDEF0?

Привязывая документы к стрелкам предшествования можно, конечно, сократить количество графических элементов на схеме процесса (что и было изначально задумано разработчиками системы). Но методически это будет некорректно и, в конечном счете, запутает читателей схемы (сотрудников компании, работающих с системой и использующие регламенты процессов).
Оценки: 1/
08.09.2014 19:46
  от автора
  Репин
Спасибо за вопрос!

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

При переходе от нотации IDEF0 к нотации Work Flow ("Процедура") происходит, можно сказать, фазовый переход. Корректно перейти со структурной схемы на модель Work Flow сложно. Нужно договариваться о правилах. В Business Studio при декомпозиции схемы в IDEF0 на "Процедуру" стрелки с диаграммы IDEF0 мигрируют на диаграмму в нотации "Процедура" с типом связи "Связь предшествования". Приходится изменять тип связи на "Поток объектов". На мой взгляд, это наиболее корректный подход.
Оценки: /
09.09.2014 17:50
  от автора
  egorovev
Добрый день, Владимир Владимирович.

Спасибо за интересную статью.


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



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


Возник вопрос, касательно корректного избавления от туннельных стрелок.Например, в компании есть процесс "Рассылать e-mail", выходом данного процесса будет являться произведенная рассылка (при этом рассылка осуществляется как Партнерам, Клиентам, так и общей выборке). На диаграмме (IDEF0) выход процесса показан стрелкой с пустым наконечником, т.к. нет необходимости показывать стрелку на диаграммах верхнего уровня (чтобы не загромождать). Правильно ли будет указать для данной стрелки на данной диаграмме объект "Клиенты", "Партнеры", "Клиенты и Партнеры"?
Оценки: /
09.09.2014 18:08
  от автора
  Репин
Спасибо за вопрос, но...

В статье нотация IDEF0 не рассматривается - там свои особенности...

Но можно предложить следующий вариант. Стрелку на IDEF0-диаграмме именовать "Письма по e-mail" и прикрепить ее ко внешним ссылкам "Партнеры" и "Клиенты" ("Клиенты и партнеры").

Называть выход процесса термином "Произведенная рассылка", на мой взгляд, некорректно. Суть потока (продуктам процесса) - это письма по e-mail, а завершающее процесс событие - "Рассылка произведена".
Оценки: /
09.10.2014 09:23
  от автора
  egorovev
Владимир Владимирович, допускается ли не использование в нотации Процедура "Событий"? В представленной разработчиком модели, например в процедуре A2.5 Прием и открытие заказов, на диаграмме не использованы "события".

Файлы прикреплять не могу, вот ссылка на эту процедуру.


Оценки: /
09.10.2014 12:16
  от автора
  Репин
Да, использование событий в нотации "Процедура" допускается. Но разработчик рекомендует моделировать только начальное и завершающие событие (события). При использовании промежуточных событий отчеты разработчика работать не будут (см. текст данной статьи).

То, что в указанной Вами модели событий нет, это методическая ошибка разработчика, на мой взгляд.

Спасибо за вопрос!
Оценки: 1/
13.10.2014 07:01
  от автора
  Тихая осень
Добрый день, Владимир Владимирович!

Прочитала Вашу статью и книгу "Бизнес-процессы", и как то запуталась.

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

на мой взляд, это противоречивый подход
Оценки: /
17.10.2014 09:39
  от автора
  Репин
Привет, Светлана!

Вот абзац из книги целиком:

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

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

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

Выбирайте тот, который для Вас понятнее и не видится противоречивым...
Оценки: 1/
17.12.2014 11:00
  от автора
  SergioBY
Здравствуйте, Владимир!

Спасибо за хорошую статью!
Я во-первых, хотел бы обсудить пример (Рис. 2А). На этой модели я бы сделал по-другому следующее:
а) в функции "Уведомить клиента о невозможности" сделал бы вход "Запрос клиента" (тип «Поток объектов») - т.к. мы должны знать контакты клиента для направления ему уведомления
б) после функции "Уведомить клиента о невозможности" я бы делал конечное событие "Уведомление о отправлено" - т.к. логично, что разные исходы порождают разные конечные события.
Прокомментируйте пожалуйста - я где-то ошибаюсь в своих рассуждениях?

Во-вторых, я хотел бы обсудить с вами тему стрелок в БС.
1. Я не согласен с вами в том, что привязывая документы к стрелкам предшествования "это некорректно с содержательной точки зрения". В тех случаях, когда потоки управления и документов совпадают, стрелка предшествования это одновременно и стрелка потока управления и стрелка потока документов т.е. "два в одном". Поэтому я не вижу препятствий привязать документы к стрелкам предшествования в таких случаях.
2. Для соответствия модели и регламента я планирую задать в Соглашении правило однозначного соответствия: 1 стрелка = 1 документ; название стрелки = названию документа. Три документа - три стрелки. Мне это кажется наглядным и логичным. Как вы считаете, насколько это будет оправданным?
3. Я пока не придумал как моделировать, чтобы в регламенте выводились статусы документов. В справочнике документов логично создать 1 объект "Договор с подрядчиком" (создавать много - "Договор с подрядчиком (черновик), "Договор с подрядчиком (согласован)" и др. - однозначно неправильно). Тогда в регламенте согласования будет в качестве входов и выходов выводиться "Договор с подрядчиком" - без статусов...
Владимир, у вас есть идеи как используя нотацию Процедура обеспечить вывод статусов документов на моделях и в регламентах?
Оценки: /
24.12.2014 12:21
  от автора
  Репин
"...а) в функции "Уведомить клиента о невозможности" сделал бы вход "Запрос клиента" (тип «Поток объектов») - т.к. мы должны знать контакты клиента для направления ему уведомления...

- согласен

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


- да, так тоже можно сделать. В своей виде-презентации я об этом говорю:



"...В тех случаях, когда потоки управления и документов совпадают, стрелка предшествования это одновременно и стрелка потока управления и стрелка потока документов т.е. "два в одном"..."

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

"...правило однозначного соответствия: 1 стрелка = 1 документ; название стрелки = названию документа. Три документа - три стрелки. Мне это кажется наглядным и логичным. Как вы считаете, насколько это будет оправданным?..."

- в eEPC это так и есть. Все логично и наглядно. Но в "Процедуре" это вызовет "лес" стрелок. Я бы предложил все-таки привязывать документы к связям "поток объектов".

По третьему вопросу - согласен. Мы именно так и делаем, как правило.

Для вывода статусов можно использовать существующие возможности BS. На практике статусы используются нечасто. Думаю, стоит обсудить этот вопрос с СТУ.
Оценки: /
24.12.2014 14:35
  от автора
  Дмитрий Пинаев
1. Да, по замыслу разработчика можно объединять объекты со связями предшествования.
2. Поддерживаю Владимира, но только в той части, что не нужно создавать для каждого объекта свою стрелку. Стрелка - логическая сущность, которая может объединять несколько объектов.
3. Как вариант - в названии стрелки фиксировать статус, если статус будет относиться ко всем документам стрелки.
Оценки: /
25.12.2014 10:31
  от автора
  SergioBY
Господа и коллеги, спасибо за ответы!
Хотел бы продолжить дискуссию в части последних двух вопросов:
2. "Стрелка - логическая сущность, которая может объединять несколько объектов" Может, но не обязана В ЕРС каждый документ - отдельный объект на диаграмме - и ничего страшного в этом, никто не боится "леса документов". А стрелка занимает намного меньше места. Поэтому единственный аргумент против однозначности стрелки и объекта - это вызовет "лес" стрелок и будет некрасиво - мне не кажется достаточно веским. На мой взгляд свойство однозначности, которое мы получим, является более весомым. И в регламентах при таком способе моделирования все корректно. И это даст нам возможность указывать статус в стрелке без оговорки "если статус будет относиться ко всем документам стрелки" - т.к. у стрелки только 1 документ
3. Да, недавно мне из СТУ так и ответили - "в названии стрелки". Но в регламент наименование стрелки не попадает - там только названия объектов. В то же время, Владимир пишет, что в регламент выводить названия стрелок а не объектов - неправильно - "Некоторые, наоборот сознательно используются стрелки именно как входы/выходы и выводят в регламент названия стрелок, а не документов. Последний подход, на мой взгляд, является методически некорректным".
Получается безвыходная ситуация... Точнее выходом является - потом ручками добавлять в регламенте статусы документов
А для нас статусы очень важны - почти все документы (особенно Договора на закупку, Заявки, Проектная документация) проходят через большое количество статусов.
Оценки: /
12.01.2015 04:31
  от автора
  Тихая осень
Добрый день!

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

Например, в случае если при приемки товара выявляется бракованный товар - то заканчивается БП событием Товар, перемещен в зону брака, а если товар не бракованный, то БП заканчивается событием Товар, перемещен в зону хранения?
Оценки: /
12.01.2015 09:47
  от автора
  SergioBY
Да - смотрите ответ Владимира от 24.12.2014
Оценки: /
02.02.2015 11:54
  от автора
  TatianaSh
Добрый день!
Люди умные, подскажите, кто сможет! )
Работаю с BS недавно и во многом еще не могу понять логику моделирования БП.
Меня смущает тот факт, что при миграции стрелок на диаграмме не видно куда они уходят. Вы можете сказать, что если концы стрелок закрашены, то они выходят в процесс более верхнего уровня. Но если эти процессы существуют отдельно? Я имею ввиду, если регламенты этих процессов используют разные сотрудники и регламент процесса, например, четвертого уровня может существовать отдельно, то диаграмма становится неинформативной в отрыве от диаграммы верхнего уровня. Неискушенному сотруднику, который мало знаком с тонкостями закрашенных и пустых стрелок, сложно понять от куда ему приходит информация и куда он должен ее передать. Конечно, в описании мы можем все это отразить, но может есть какие-то приемы, которые позволят визуально показать связь процессов.
Междиаграммные ссылки тоже не всегда спасают, например, в типовых процессах (блоки со ссылкой на другой процесс).
Приведу пример. Есть процесс закупа мебели. Он может быть подпроцессом разных процессов, например, используется как этап в процессе приема нового сотрудника. В этом случае в процессе приема нового сотрудника будет блок со ссылкой на процесс закупа мебели. И именно блоком с входящей и исходящей стрелкой, а не междиагрммной ссылкой. При этом в процессе закупа мебели я могу лишь указать закрашенные стрелки, т.е. на диаграмме не будет видно связь с процессом приема нового сотрудника. Как все же правильнее сделать связь процессов приема нового сотрудника и закупа мебели?
Оценки: /
16.06.2015 02:13
  от автора
  Тихая осень
Добрый день! Подскажите опытные люди, для сертификации ISO имеет ли значение выбор нотации? Приглашенный консультант говорит о том, что описывая БП в нотации Процедура, для сертификации нам придется переделывать все схемы в формат EPC
Оценки: /
16.06.2015 16:57
  от автора
  prisyazhenko

Добрый день! Подскажите опытные люди, для сертификации ISO имеет ли значение выбор нотации? Приглашенный консультант говорит о том, что описывая БП в нотации Процедура, для сертификации нам придется переделывать все схемы в формат EPC

Не могу дать 100%-ой гарантии, но описанный консультантом вариант выглядит очень сомнительно. Думаю, Вам стоит попросить его подкрепить свои слова конкретными выдержками из требований по сертификации.
Оценки: /
21.08.2015 13:52
  от автора
  alena_zaharova@mail.ru
Владимир, приветствую. Давно не слышались . У нас опять "поднялась волна" обсуждения методологии моделирования на нижнем уровне. Посмотрела вашу презентацию, т.к. в ней вы затрагиваете 2 ключевых для нас вопроса:
- моделирование границ (использование междиаграммных ссылок)
- выбор нотации для моделирования
Спасибо за вашу работу.
Буду очень признательна, если ответите на несколько вопросов:
1. Если ли у вас пример, когда может потребоваться декомпозиция действия процедуры? Как вы знаете, мы ромбик используем как полноценное действие, соответственно, декомпозиция не возможна, вот я и подумала, м.б. мы что-то теряем?
2. На примере с прайс-листом, если вы в несколько действий разных процедур заберете его и сделаете междиаграммную ссылку с процессом Ценообразование, как решить вопрос с наличием большого количества стрелок в процессе Ценообразования? Только присоединением множества стрелок к одной? В нашей методологии пока так, в.т. числе мы закрепили, что не основные выходы (которые не являются частью цепочки процессов, а просто отсыл на другой процесс) мы не прикрепляем к процессу и выход не рисуем, а только в описании действия пишем это.
3. Давно мучающий нас вопрос, с которым мы в т.ч. обращались в BS. Если помните, мы используем междиаграмные ссылки на самом нижнем уровне в процедуре, правило - связь между действиями процедур. Вопрос - если мы хотим эту стрелку видеть и на диаграммах IDEF0, что нам может помочь? Только не предлагайте "тащить" все стрелки через верх...
Оценки: /
21.08.2015 14:00
  от автора
  alena_zaharova@mail.ru
М.б. уже не актуально, но прокомменчу Татьяне.
Цитата: Приведу пример. Есть процесс закупа мебели. Он может быть подпроцессом разных процессов, например, используется как этап в процессе приема нового сотрудника. В этом случае в процессе приема нового сотрудника будет блок со ссылкой на процесс закупа мебели. И именно блоком с входящей и исходящей стрелкой, а не междиагрммной ссылкой. При этом в процессе закупа мебели я могу лишь указать закрашенные стрелки, т.е. на диаграмме не будет видно связь с процессом приема нового сотрудника. Как все же правильнее сделать связь процессов приема нового сотрудника и закупа мебели?

Мы никогда не делаем этапом процесса этап/шаг/процедуру другого процесса. Мы используем такое понятие "Организует..." в вашем случае "Организует предоставление/закупку мебели" (м.б. ее закупать ее не надо т.к. она есть на складе). Чтобы не загромождать диаграмму процесса Закупки или Обеспечение сотрудников ТМЦ, мы стрелки туда не отдаем и междиаграмные ссылки не делаем, только в описании действия указываем, что он это делает в соответствии с процессом "Закупка ТМЦ" или "Обеспечение сотрудников ТМЦ".

Добавить комментарий

Комментировать материалы могут только зарегистрированные пользователи. Вы можете зарегистрироваться здесь.
©  2010-2014 В.В. Репин. Сайт основан 3 февраля 2001 г.

Все права защищены. Частичное или полное копирование информации данного ресурса возможно только с разрешения владельца.

Регистрация
О Портале
Правила
Контакты
Новости
Библиотека
Энциклопедия
Литература и сайты
Группы
Мои страницы
Тесты
Форум
Доска объявлений