«Соглашения по моделированию» (или просто «Соглашения») — это документ, в котором фиксируются правила и достигнутые договоренности относительно того, как будут строиться модели процессов и их окружения. «Соглашения» описывают цели и задачи моделирования, используемые при моделировании методы и графические нотации, а также организацию хранения моделей. В документе определяется уровень детализации при описании бизнес-процессов и их окружения (организационной структуры, документов, продуктов/услуг, информационных систем и т.д.), а также дается информация, связанная с генерацией отчетов по моделям и форматами публикации моделей в интернет-портале.
Если предполагается работа со специализированным инструментом, эти правила и договоренности будут являться основой для настроек соответствующей программной среды.
В приложении 1 приведены типовые разделы «Соглашений по моделированию», разработанных для проекта по описанию бизнес-процессов «как есть» в среде ARIS, а в приложении 2 представлен раздел «Цели и ограничения документа» «Соглашений по моделированию» для описания процессов банка.
Стоит отметить, что этот документ не является статичным, а может изменяться и дополняться на протяжении всего проекта с соответствующими процедурами согласования..
Настройка специализированного инструментария
Важной частью моделирования в любой программной инструментальной среде является правильное ее конфигурирование и настройка. В случае работы с обычным графическим редактором необходимо создать графические объекты, с помощью которых будут отображать сущности и их взаимосвязи в процессах. Если используется специализированный инструментарий, то необходимо использовать ту методологию, графические объекты и типы связей между ними, которые положены в основу инструмента. На этапе подготовки к моделированию рекомендуется произвести соответствующие настройки программной среды:
- 1) определить структуру папок для хранения моделей;
- 2) сконфигурировать набор методов моделирования под конкретные потребности, т.е. провести настройку так называемых методологических фильтров. Это значительно упрощает моделирование;
- 3) определить графические шаблоны для создания моделей и их публикации на веб-портале.
Задача второго шага подготовительного этапа — конфигурирование инструмента, что предполагает отбор из всего множества методов, которые предоставляет инструмент, ровно тех, которые необходимы для реализации проекта и достижения его целей.
Также важно определиться с графическими опциями для печати моделей и публикации их в Интернете. Все это делается для получения наглядных, читаемых моделей, которые с легкостью воспринимаются всеми заинтересованными лицами — менеджерами, технологами, специалистами из функциональных подразделений и т.д.
Такое качество моделей может быть достигнуто, если установить и выполнить правила оформления моделей:
- • расположение модели на листе формата А4 (иногда АЗ), что ограничивает число объектов модели;
- • эргономичный вид объектов, включая цвет, форму, элементы оформления;
- • соответствующее (взаимное) расположение объектов в модели — соблюдение законов симметрии, выравнивание расстояний между идентично расположенными объектами;
- • отображение важных характеристик объектов в поле моделирования.
На рис. 9 (см. цв. вклейку) представлена наглядная, читаемая модель, описывающая упрощенный процесс оценки платежеспособности клиента. Что является отличительными признаками таких эргономически правильных моделей? Информация структурирована по месту расположения: документы слева, исполнители справа.
Они присутствуют на моделях около тех функций, где они необходимы для быстрого понимания модели. Вся модель «разделена» на элементарные ячейки информации: функция и ее ресурсное окружение. В модели в виде вертикали выделено основное, наиболее вероятное развитие событий. Так целесообразно делать всегда, когда в модели встречаются логические операторы. Связи между объектами имеют минимальное число изломов — как правило, не более одного.
Оформление моделей очень важно, оно может помочь каждому понять суть процесса, а может поставить в тупик. По этой причине по ходу разработки модели нужно уделять внимание размеру модели, ориентации и положению текста.
Планирование согласования и утверждения моделей
Подробной, детальной информацией о процессах компании обладают только ее сотрудники. При моделировании они выступают в роли экспертов, которые сначала предоставляют информацию о моделируемых процессах, а затем согласуют и иногда утверждают модели. Иногда — потому что чаще на практике за утверждение моделей отвечают Владельцы процессов.
До начала работ по моделированию необходимо определить и назначить экспертов и Владельцев процессов и сформировать график встреч с ними. Также необходимо спланировать с соответствующими экспертами от профильных подразделений компании разработку моделей связанных с процессами аспектов деятельности, например, организационной структуры, информационных систем. Кроме того, до начала проекта определяются процедуры согласования и утверждения моделей процессов.
Источник: studme.org
«Соглашение по моделированию бизнес-процессов»
Предлагаем вашему вниманию корпоративный стандарт «Соглашение по моделированию бизнес-процессов», версия 1.
Для кого?
«Соглашение» необходимо для компании, которая:
• внедряет программный продукт Business Studio 5;
• активно использует метод описания и анализа бизнес-процессов в нотациях IDEF0/BPMN с целью их оптимизации, регламентации и подготовки требований к автоматизации.
Для чего?
«Соглашение» включает в себя набор требований к моделированию бизнес-процессов в нотациях IDEF0 и BPMN, которые необходимы для:
• стандартизации деятельности по моделированию бизнес-процессов компании;
• получения схем процессов высокого качества, с использованием которых можно проводить анализ и принимать эффективные решения по изменению процессов;
• обучения и аттестации бизнес-аналитиков и сотрудников подразделений на знание методов моделирования бизнес-процессов и функционала Business Studio 5.
Как было создано «Соглашение»?
Разработчик «Соглашения» — Владимир Репин, к.т.н., доцент, член ABPMP Russian Chapter, Генеральный директор ООО «Владимир Репин Менеджмент», консультант по управлению.
«Соглашение» создано на основе:
• практики и опыта выполнения и методического сопровождения множества проектов внедрения Business Studio 5, разработки архитектур бизнес-процессов в нотации IDEF0, моделирования и анализа процессов в нотации BPNN;
• практики и опыта обучения и аттестации сотрудников компаний навыкам моделирования бизнес-процессов;
• анализа стандартов моделирования бизнес-процессов средних и крупных компаний РФ;
• методической литературы по моделированию бизнес-процессов.
Кто уже использует?
В настоящее время «Соглашение (полностью или после адаптации) используют следующие компании:
• ЧТПЗ;
• Торговый дом «Ярмарка»;
• АСТ;
• «Русский Свет»;
• «Стиль-Трейд»;
• FESCO;
• и другие.
Структура «Соглашения»
- ОБЩИЕ ПОЛОЖЕНИЯ 3
1.1. ВВОД В ДЕЙСТВИЕ 3
1.2. НАЗНАЧЕНИЕ И ОБЛАСТЬ ДЕЙСТВИЯ 3
1.3. ТЕРМИНЫ, ОПРЕДЕЛЕНИЯ, ОБОЗНАЧЕНИЯ И СОКРАЩЕНИЯ 4
1.4. ПЕРЕЧЕНЬ ССЫЛОЧНЫХ ДОКУМЕНТОВ 5 - ВЕДЕНИЕ СПРАВОЧНИКОВ 7
2.1. СПРАВОЧНИК «ОРГЕДИНИЦЫ» 7
2.2. СПРАВОЧНИК «ДЕЯТЕЛЬНОСТЬ» 11
2.3. СПРАВОЧНИК «ФУНКЦИОНАЛЬНЫЕ ОБЪЕКТЫ» 13
2.4. СПРАВОЧНИК «МЕТОДЫ УПРАВЛЕНИЯ» 16 - МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ В НОТАЦИИ IDEF0 18
3.1. ПРИМЕНЕНИЕ МОДЕЛЕЙ В НОТАЦИИ IDEF0 18
3.2. ЭЛЕМЕНТЫ НОТАЦИИ IDEF0 21
3.3. ТРЕБОВАНИЯ К ФОРМИРОВАНИЮ СХЕМ ПРОЦЕССОВ В НОТАЦИИ IDEF0 22
3.4. ПОРЯДОК ФОРМИРОВАНИЯ СХЕМЫ ПРОЦЕССА В НОТАЦИИ IDEF0 35 - МОДЕЛИРОВАНИЕ БИЗНЕС-ПРОЦЕССОВ В НОТАЦИИ BPMN 37
4.1. ОБЩИЕ ТРЕБОВАНИЯ 37
4.2. МОДЕЛИРОВАНИЕ СОБЫТИЙ 38
4.3. МОДЕЛИРОВАНИЕ ЗАДАЧ, СВЯЗЕЙ И ВЗАИМОДЕЙСТВУЮЩИХ ПРОЦЕССОВ/ВНЕШНИХ СУБЪЕКТОВ 40
4.4. МОДЕЛИРОВАНИЕ ШЛЮЗОВ 42
4.5. МОДЕЛИРОВАНИЕ ДВИЖЕНИЯ ДОКУМЕНТОВ ВНУТРИ ПРОЦЕССА И СТАТУСОВ 45
4.6. МОДЕЛИРОВАНИЕ ИНФОРМАЦИОННЫХ СИСТЕМ И БАЗ ДАННЫХ 47
4.7. МОДЕЛИРОВАНИЕ ДВИЖЕНИЯ ДОКУМЕНТОВ МЕЖДУ ПРОЦЕССАМИ 48
4.8. МОДЕЛИРОВАНИЕ МЕЖПРОЦЕССНОГО ВЗАИМОДЕЙСТВИЯ ПУТЕМ ОТПРАВКИ/ПОЛУЧЕНИЯ СООБЩЕНИЙ 49
4.9. МОДЕЛИРОВАНИЕ ПОДПРОЦЕССОВ И ТИПОВЫХ ПРОЦЕССОВ 51
4.10. ИНТЕГРАЦИЯ МОДЕЛЕЙ В НОТАЦИИ IDEF0 И НОТАЦИИ BPMN 52
4.11. СТАРТ ПРОЦЕССА НЕСКОЛЬКИМИ СОБЫТИЯМИ 56
4.12. ИСПОЛЬЗОВАНИЕ ТЕРМИНАТОРА 57
4.13. ПОРЯДОК ФОРМИРОВАНИЯ СХЕМЫ ПРОЦЕССА В НОТАЦИИ BPMN 58 - ПРИЛОЖЕНИЯ 59
5.1. ПРИЛОЖЕНИЕ № 1. ТРЕБОВАНИЯ К ФОРМУЛИРОВКАМ НАЗВАНИЙ ПРОЦЕССОВ (ЗАДАЧ) 59
5.2. ПРИЛОЖЕНИЕ № 2. ПРИМЕРЫ ПРАВИЛЬНОЙ И НЕПРАВИЛЬНОЙ ФОРМУЛИРОВКИ НАЗВАНИЯ ПРОЦЕССА 60
5.3. ПРИЛОЖЕНИЕ № 3. РЕКОМЕНДУЕМЫЕ СТАТУСЫ ДОКУМЕНТОВ. 62
5.4. ПРИЛОЖЕНИЕ № 4. ЧЕК-ЛИСТ КОНТРОЛЯ КАЧЕСТВА СХЕМЫ ПРОЦЕССА В НОТАЦИИ BPMN 63
5.5. ПРИЛОЖЕНИЕ № 5. ПРИМЕР МОДЕЛИ БИЗНЕС-ПРОЦЕССА В НОТАЦИИ BPMN 64
Скрины из «Соглашения»
Пример схемы бизнес-процесса, разработанной с учетом требований «Соглашения»
Комплект поставки и финансовые условия
• «Соглашение» передается в формате MS Word, 64 стр., формат А4, 36 цветных рисунков.
• рисунки, использованные в «Соглашении», в виде отдельных файлов не передаются;
• консультации по внедрению «Соглашения» предоставляются отдельно на основе согласованных сторонами тарифов;
• поставка осуществляется только юридическим лицам;
• стоимость «Соглашения» — 80 тыс. рублей, НДС не выделяется.
• 100% предоплата по договору;
• Заказчику передаются неисключительные авторские права на «Соглашение».
• Заказчик имеет право:
o использовать «Соглашение» для своих внутренних целей;
o вносить в него необходимые изменения и дополнения;
o использовать «Соглашение» в рамках учебного процесса компании;
• Заказчик не имеет право:
o выкладывать «Соглашение» в открытый доступ (сеть Интернет);
o передавать бесплатно и/или продавать «Соглашение» третьим юридическим или физическим лицам;
o продавать «Соглашение» после внесения в него каких-либо изменений;
o публично демонстрировать «Соглашение» на платных или бесплатных тренингах, конференциях и прочих открытых мероприятиях.
• За нарушение авторских прав договором предусмотрен штраф;
Disclaimer
Исполнитель не несет ответственности за качество архитектуры бизнес-процессов и моделей бизнес-процессов в нотациях IDEF0/BPMN, разработанных сотрудниками Заказчика с использованием «Соглашения».
Источник: repin.guru
Соглашение о моделировании процессов
Главной целью моделирования является создание единой базы знаний и единого стандарта отображения информации о:
o структуре персонала организации;
o иерархии бизнес-процессов/функций;
o последовательности выполнения бизнес-процессов/функций;
o распределении бизнес-процессов/функций между подразделениями и исполнителями;
o входящих/исходящих информационных потоков бизнес-процессов/функций.
6.11.2.Объекты моделирования и их свойства
При моделировании бизнес-процессов и выполнении вышеуказанных задач используются следующие типы объектов:
o Структурные единицы (подразделения, должности, сотрудники);
o Технологические процессы и функции;
o Документы и другие данные, составляющие информационное окружение при выполнении функций.
В последующих разделах приводится графическое изображение и состав описания (свойств) объектов, которые используются при моделировании.
6.1.1.1. Структурные единицы
В таблице приведены графические изображения, и свойства объектов, используемых при моделировании структурных диаграмм моделей в ARIS Toolset.
Тип объекта в ARIS Toolset
Графическое изображение объекта
Cвойства объектов в АRIS Toolset
Управление медицинского страхования
Организация, продажа и сопровождение ДМС
Ф. И.О. сотрудника
Андеррайтер управления медицинского страхования
Оценка рисков, определение личных коэффициентов, подписание договора ДМС в рамках имеющейся доверенности
Управляющая компания холдинга
Управление и контроль деятельности основных подразделений организации
6.1.1.2. Технологические процессы и функции
Процесс и функции процесса отличаются только уровнем описания – детальным (нижний уровень – функция) или общим (верхний уровень – процесс).
Тип объекта в ARIS Toolset
Графическое изображение объекта
Cвойства объектов в АRIS Toolset
Оформление и согласование договора ДМС с клиентом
Оформляется типовой договор ДМС
Контроль таможенных платежей
Проверка ГТД по срокам подачи, состоянию задолженности.
По результатам проверки проставляется отметка «Проверено».
6.1.1.3. Информационные объекты, используемые в моделях процессов
6.1.1.3.1. Набор данных
Тип объекта в ARIS Toolset
Графическое изображение объекта
Cвойства объектов в АRIS Toolset
Документы, инструкции и другие формы данных
Анкетные данные страхователя
Создается с целью фиксации собранных данных о клиенте
Примечание: знак «assignment» , расположенный под правым нижним углом объекта указывает на декомпозицию объекта. Так, например, комплекты данных или документов изображаются в моделях тем же объектом, что и набор данных, но их можно отличить по наличию знака «assignment» – под правым нижним углом объекта:
6.1.1.3.2. Информация, хранящаяся в базе данных
Тип объекта в ARIS Toolset
Графическое изображение объекта
Cвойства объектов в АRIS Toolset
База данных полисов ДМС
6.1.1.4. Информационные системы
Тип объекта в ARIS Toolset
Графическое изображение объекта
Cвойства объектов в АRIS Toolset
Application system
Текстовой процессор MS Word
Используется для создания документов
6.11.3.Типы моделей
В данном разделе представлены основные типы моделей, используемые для решения задач моделирования.
При описании типов моделей указывается:
o задачи, которые можно решать при анализе конкретных моделей;
o перечень используемых объектов;
o используемые виды отношений между объектами.
6.1.1.5. Модели организационной структуры предприятия
Для моделирования представления организации используется организационная диаграмма. Ниже перечислены объекты, используемые при построении модели и виды отношений между объектами модели. Пример – в Приложении 1 к соглашению о моделировании.
Тип модели в ARIS Toolset
Cвойства модели в АRIS Toolset
Группа учёта операций ДМС Операционного управления
Оформление договоров, полисов, карточек, ведение учета поступлений страховых премий, ввод и контроль статданных
Типы используемых объектов:
Структурные подразделения предприятия
Виды отношений между объектами:
Департамент состоит из отдела.
Ф. И.О. занимает должность
Is Organization Manager for
Начальник отдела является руководителем отдела
Is Organization Manager for
Начальник отдела является руководителем специалиста отдела
Is technical superior
Начальник отдела является техническим руководителем специалиста отдела.
Is disciplinary superior
Начальник отдела является дисциплинарным руководителем Специалиста отдела.
6.1.1.6. Модель дерева функций.
Для представления иерархически структурированных бизнес-процессов организации используется модель дерева функций. Ниже перечислены объекты, используемые при построении модели и виды отношений между объектами модели. Пример – в Приложении 2 к соглашению о моделировании.
Тип модели в ARIS Toolset
Cвойства модели в АRIS Toolset
Принятие документов от страхователя при страховом случае
Организация начала процесса урегулирования убытков при страховом случае
Типы используемых объектов:
Виды отношений между объектами:
Is process-oriented superior – подчинение по процессу
Функция 2 и Функция 1 являются составными частями Функции внутри одного бизнес-процесса.
Is object-oriented superior – подчинение по объекту
В состав Функции входят операции – Функция 2 и Функция 1, которые выполняются над одним и тем же объектом.
Is execution-oriented superior – подчинение по способу выполнения
В состав Функции входят операции – Функция 2 и Функция 1, которые выполняют одни и те же операции над различными объектами в различных бизнес-процессах.
6.1.1.7. Модели наборов данных и документов
Для представления структуры данных /документов информационного окружения бизнес-процессов организации используется модель набора данных и документов. Ниже перечислены объекты, используемые при построении модели и виды отношений между объектами модели. Пример – в Приложении 3 к соглашению о моделировании.
Тип модели в ARIS Toolset
Cвойства модели в АRIS Toolset
Technical Term Model
Комплект документов №10
Комплект документов №10 используется в процессе «Рассмотрение заявки», состоит из следующих документов: анкета, заявление, …..
Типы используемых объектов:
Документы, инструкции и другие формы данных
Виды отношений между объектами:
Документ (Анкета) входит в комплект документов (Комплект документов №10)
6.1.1.8. Модель событийной цепочки процесса
Для представления последовательности выполнения бизнес-процессов/функций организации используется модель событийных цепочек процесса. Ниже перечислены объекты, используемые при построении модели и виды отношений между объектами модели. Пример – в Приложении 4 к соглашению о моделировании.
Тип модели в ARIS Toolset
Cвойства модели в АRIS Toolset
Принятие документов от страхователя при страховом случае
Организация начала процесса урегулирования убытков при страховом случае
Типы используемых объектов:
Интерфейсные процессы (п. 6.1.1.2)
Документы, пакеты документов, инструкции и другие формы данных (п.6.1.1.7)
Подразделения, должностные лица, бизнес-роли (п. 6.1.1.1)
Все необходимые объекты организационной структуры
Набор данных (п. 6.1.1.3.2)
Информационная система (п. 6.1.1.4)
Виды отношений между объектами:
Данные на входе функции
Данные на выходе функции
Is evaluated by
После завершения события управление переходит на логический оператор.
Выполнение функции приводит к передаче управления к логическому оператору.
Логический оператор активизирует функцию.
Прикладная система осуществляет поддержку выполнения функции
Набор данных является входом для функции
Выход функции направляется в набор данных
Прикладная система использует набор данных
Допущение: событие после функции может быть не обозначено, кроме следующих случаев:
§ событие является внешним (запускающим или завершающим бизнес-процесс);
§ событие является существенным;
§ после функции следует логическая развилка.
6.11.4.Приложение 1 к соглашению о моделировании. Пример модели организационной структуры «Департамента корпоративного управления и новой экономики».
Рис.1.Пример модели организационной структуры «Департамента корпоративного управления и новой экономики».
6.11.5.Приложение 2 к соглашению о моделировании. Пример модели дерева функций «Таможенный контроль при вывозе через ППП».
Рис.2 Пример модели дерева функций «Таможенный контроль при вывозе через ППП».
6.11.6. Приложение 3 к соглашению о моделировании. Пример модели наборов данных и документов «Документы для подтверждения права на возмещение НДС».
Рис.3. Пример модели наборов данных и документов «Документы для подтверждения права на возмещение НДС».
6.11.7.Приложение 4 к соглашению о моделировании. Пример модели процесса «Проверка количества фактически вывезенного товара».
Рис.4. Пример модели процесса «Проверка количества фактически вывезенного товара».
6.11.8. Глоссарий терминов к соглашению о моделировании
Процесс – последовательность действий персонала организации, выполняемых для достижения определенных целей с использованием ресурсов.
Ресурс – документ (продукт/услуга), материал, время, персонал, оборудование, – всё, что необходимо для выполнения процесса.
Вход процесса – ресурс, поступающий от других процессов.
Выход процесса – ресурс, формирующийся в результате выполнения процесса.
Функция – действие, осуществляемое в рамках процесса.
o результат выполнения процесса, или функции;
o факт, с которым связывается начало/окончание/ процесса, или функции.
o состояние, которое является существенным для целей управления бизнесом и которое оказывает влияние, или контролирует дальнейшее развитие одного, или более процессов.
Границы процесса – допустимая область использования ресурсов в ходе процесса.
Процесс-поставщик – процесс, поставляющий ресурсы для другого процесса.
Процесс-клиент – процесс, получающий ресурсы как результат выполнения другого процесса.
Роль – типовая характеристика, категория (или набор таковых) организационной единицы.
Владелец процесса – организационная единица (как правило, должностное лицо, или группа лиц), имеющая в своем распоряжении ресурсное обеспечение процесса, управляющая его ходом и несущая ответственность за его выполнение.
Декомпозиция – разделение процесса, функции, или иного объекта модели на части.
Заказчик – организация, или лицо для которого, в соответствии с договором, проводится инжиниринг и/или реинжиниринг процессов организации с участием владельцев процессов и/или третьих лиц.
Модель – формализованное описание процесса, организации и т. д., отображающее взаимосвязи между всеми его частями.
Регламент процесса – совокупность правил и ограничений протекания процесса.
Клиент – субъект (организация, или лицо), получающий выход процесса.
Поставщик – субъект (организация, или лицо), подающий на вход процесса ресурсы.
[1] Постановление Госкомстата РФ от 15 июля 2002 г. N 154 “Об утверждении Положения о порядке представления статистической информации, необходимой для проведения государственных статистических наблюдений”
[2] Вид носителя информации и способ передачи сведений на электронных носителях определяются соглашением взаимодействующих сторон.
[3] Отчетность для целей настоящего исследования есть закрепленный нормативными (правовыми) актами способ группировки и предоставления информации о хозяйствующих субъектах в федеральные органы исполнительной власти.
[4] Федеральный закон от 10 января 2002 г. N 1-ФЗ “Об электронной цифровой подписи”
[5] Порядок доступа к конфиденциальной информации налоговых органов (утв. приказом МНС РФ от 03 марта 2003 г. N БГ-3-28/96)
[6] Федеральный закон от 10 января 2002 г. N 1-ФЗ “Об электронной цифровой подписи”
[7] Формулировка из комментария к Конституции РФ (под ред. Окунькова). Комментарий не является нормативно-правовым актом и не имеет обязательной юридической силы.
[8] http://www1.worldbank. org/publicsector/egov/definition. htm
[9] Регламент регистрации и подключения юридических и физических лиц к СЭДО Пенсионного фонда Российской Федерации. Утверждено Постановлением Правления ПФР от 26.01.2001 N 15.
[10] Интерфейсные процессы (процесс-поставщик, процесс-клиент) служат для обеспечения перехода на другой уровень диаграммы.
Источник: pandia.ru