Документы бизнес процесса

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

Документы бизнес процесса. О чем речь?

Все вопросы, которые мы получаем о документации в области управления бизнес процессами, можно обобщить и выделить 4 типа:

1. Что из себя представляет документ?
2. Каков состав документа?
3. Как его правильно составить?
4. Кто должен быть автором документа?

Мы решили рассказать и затронуть те документы бизнес процесса, которые, как показывает практика, являются самыми важными. А также, самыми востребованными.

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

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

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

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

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

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

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

Еще пример. В нашей компании прописаны и строго соблюдаются 9 принципов:

• Всегда держать свое слово
• Всегда соблюдать сроки
• Качество должно быть гарантированным
• Все, что видит клиент, должно быть идеальным
• Каждый раз все с начала
• Интересы клиента важнее
• Минимум усилий со стороны клиента
• Личная ответственность
• Сотрудники компании – клиенты друг для друга

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

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

Если в компании действует направление Управление качеством, то политику в области управления бизнес процессами можно объединить с политикой по управлению качеством.

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

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

Положение об управлении бизнес процессами

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

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

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

• Правила определения границ бизнес процессов
• Правила определения взаимосвязей процессов
• Правила декомпозиции процессов
• Описание структуры и уровней декомпозиции процессов
• Правила моделирования и описания бизнес процессов
• Правила определения и измерения KPI процессов
• Правила внедрения и изменения процессов
• Правила мониторинга, оценки эффективности и улучшения процессов
• Порядок осуществления документооборота по бизнес процессам
• Правила определения владельцев бизнес процессов
• Ответственность и полномочия владельцев бизнес процессов
• Описание жизненного цикла процессов и правила определения текущей стадии процессов
• Правила определения зрелости бизнес процессов
• Правила организации управления бизнес процессами в компании
• Описание структуры управления бизнес процессами в компании
• Ответственность и полномочия структуры управления бизнес процессами

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

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

Соглашение о моделировании

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

Соглашение о моделировании содержит описание:

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

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

Соглашение о моделировании должно разрабатываться экспертами, внутренними или внешними, на основании особенностей и требований компании к процессу моделирования. Крайне важным аспектом является понимание уровня специалистов, которые будут осуществлять моделирование бизнес процессов. Чем ниже уровень, тем более подробным и простым должен быть документ. Как и все документы бизнес процесса.

Положение об офисе управления бизнес процессами

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

В зоне ответственности офиса управления бизнес процессами лежит:

• Управление методологией управления бизнес процессами
• Проведение исследований, в том числе интервью, и мониторинг данных
• Описание и моделирование бизнес процессов
• Анализ эффективности бизнес процессов
• Разработка и управление проектами по изменению бизнес процессов
• И так далее

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

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

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

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

Регламент бизнес процесса

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

Подробнее можно прочитать в статьях:

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

Описание процесса

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

Описание процесса, как правило, описывает только то, как процесс выполняется, но оставляет за скобками управление процессом.

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

Стандарт процесса

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

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

Подробнее, о стандартизации и стандарте процесса, можно прочитать здесь.

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

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

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

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

Прочитать подробнее и скачать образец карточки процесса можно по ссылке.

Стандартная операционная процедура (СОП)

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

Пример процедуры:

1. Поздороваться с клиентом
2. Попросить паспорт
3. Сверить данные паспорта с карточкой клиента
4. Если данные совпадают, перейти к процессу обслуживания
5. Если данные не совпадают, отказать в обслуживании

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

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

В нотации BPMN, даже предусмотрен отдельный вид операции, под названием Script, что и есть операция выполнения процедуры.

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

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

Бизнес правило

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

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

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

Бизнес правило в виде схемы

Гораздо проще выразить правило в виде матрицы и прикрепить ее к операции.

Матрица бизнес правила

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

Рабочая инструкция

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

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

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

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

А какие еще документы бизнес процессов вас интересуют? 

Бизнес процессы и стандарты управления

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

Стандарты автоматизации бизнес-процессов

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

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

Цели автоматизации выделенных бизнес процессов на предприятии:

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

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

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

Business Process Management System (BPMS)

BPMS, Business Process Management System — современная система, предназначенная для удобного управления бизнес-процессами. Идея в том, чтобы взять описание бизнес-процесса, отследить его выполнение с применением специализированной программы. Описания создаются сотрудниками компании или приглашенными специалистами по реинжинирингу.

Автоматизация бизнес-процессов малого предприятия или большой компании выполняется при помощи разработки или приобретения прикладного ПО. Однако при внедрении такой системы следует учитывать определенные нюансы. BPM-программа автоматизирует лишь часть шагов процесса. Также необходимость внести изменения в ПО для Business Process Management System означает перепрограммирование, связанное со значительными затратами времени.

BPM-система не обновляется в таком темпе, который требуют быстро изменяющиеся условия бизнеса или потребности конкретной организации. Любопытно, что изначально подобные системы были выпущены именно с целью решения данной проблемы.

Для BPMS (Business Process Management System) любое описание бизнес-процесса создается на языке, который исполняется программой BPM.

Виды систем автоматизации

Тип системы	Описание
Неизменяемая	Последовательность действий определяется конкретными факторами (конфигурация оборудования, условия процесса). Не изменяется в ходе работы.
Программируемая	Последовательность действий можно изменять, исходя из конфигурации процесса, заданной программы. Существует набор инструкций, который интерпретируется системой, по выбору последовательности действий.
Гибкая (самонастраиваемая)	Программа может выбирать требуемые действия во время работы системы. Конфигурация процесса выполняется на основе полученных данных о ходе текущего процесса.

Методологии описания бизнес-процессов организации — Студопедия

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

Кажущаяся на первый взгляд сложность описания бизнес-процессов является раздутой. Классическая технология описания бизнес-процессов, которая была разработана на заре рождения процессных технологий управления, достаточно проста и состоит всего лишь из двух стандартов описания бизнес-процессов — DFD и WFD. Большинство других современных стандартов, не смотря на другие названия, представляют небольшие разновидности и дополнения двух классических подходов DFD и WFD.

Согласно классическому подходу стандарт DFD, который расшифровывается, как Data Flow Diagram, представляет из себя диаграмму потоков данных, которая используется для описания бизнес-процессов верхнего уровня. В свою очередь стандарт WFD расшифровывается как Work Flow Diagram и представляет собой диаграмму потоков работ, которая используется для описания бизнес-процессов нижнего уровня. У диаграммы потоков работ имеются и другое название — диаграмма алгоритмов. Давайте рассмотрим два этих стандарта, составляющих классическую методологию описания бизнес-процессов.

Стандарт описания бизнес-процессов DFD — Data Flow Diagram переводится как диаграмма потоков данных и используется для описания процессов верхнего уровня.

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

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

Рисунок 3.1 – Диаграмма потоков данных – DFD

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

Рисунок 3.2 – Пример несовпадения временной последовательности работ и направления движения документа

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

Рисунок 3.3 – Пример бизнес-процесс верхнего уровня

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

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

Правило 1. Названия работы нужно формулировать согласно следующее формуле.

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

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

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

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

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

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

Рисунок 3.4 – Разработка сети бизнес-процессов.

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

На практике сеть процессов часто называют сетью или схемой взаимодействия бизнес-процессов. Отличие сети процессов от классической схемы DFD состоит в том, что на сети нужно показать внешние субъекты, с которым взаимодействуют бизнес-процессы компании — клиенты, поставщики, банки и др.

При построении DFD-схемы бизнес-процесса необходимо использовать правило «7», согласно которому нужно выбрать такой уровень абстрагирования и детализации, при котором схема бизнес-процесса будет состоять в среднем из семи работ. Использование большей детализации и соответственно количества работ приведет к сильному усложнению схемы и снижению возможности проведения качественного анализа бизнес-процесса. Это в свою очередь связано с тем, что человек может эффективно оперировать не более чем семью различными объектами. Использование небольшой детализации и меньшего количества работ на схеме бизнес-процесса приведет к тому, что работы будут достаточно укрупненными для того и это также уменьшит возможность проведения их качественного анализа и оптимизации.

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

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

В случае необходимости работы на схеме процесс а второго уровня могут быть декомпозированы на схемы бизнес-процессов третьего уровня и т.д. Декомпозиция бизнес-процесса должна продолжаться до тех пор, пока не будут достигнуты цели его описания. В данном случае удобно использовать понятия вложенный процесс или подпроцесс. На рисунке 3.9 процессная схема работы 3 является вложенным процессом или подпроцессом процесса верхнего уровня. Аналогичным образом процессные схемы работ 3.1 и 3.4 являются вложенными процессами или подпроцессами процесса второго уровня.

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

Рисунок 3.5 – Декомпозиция бизнес-процесса

При описании бизнес-процессов нижнего уровня используются немного другие процессные схемы, под названием WFD — Work Flow Diagram, что переводится как диаграмма потоков работ. На этой схеме появляются дополнительные объекты, с помощью которых описывается процесс: логические операторы, события начала и окончания процесса, а также элементы, показывающие временные задержки (Рисунок 3.6).

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

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

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

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

Отличительной особенностью WFD — диаграммы является то, что стрелки между операциями бизнес-процесса обозначают не потоки объектов (информационные и материальные), а потоки или временную последовательность выполнения работ.

Итак с помощью двух классических схем DFD и WFD можно описать подробно все бизнес-процессы компании.

Рисунок 3.6 – Диаграмма потоков работ- WFD

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

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

На самом деле, несмотря на свое различие, в основном связанное с названием диаграмм и видов используемых объектов современные методологии описания бизнес-процессов практически идентичны и представляют из себя незначительные видоизменения двух классических схем — DFD и WFD — Work Flow Diagram, которые были рассмотрены.

Давайте рассмотрим другие современные языки описания бизнес-процессов:

· IDEF0;

· DFD в нотациях Гейна-Сарсона и Йордана-Де Марко;

· IDEF3;

· Oracle;

· BAAN;

· ARIS.

Методология IDEF0

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

Методология IDEF0 незначительно отличается от классической схемы описания бизнес-процессов DFD, которая была рассмотрена ранее. Основным отличием является наличие в языке дополнительной аналитики. Данный стандарт описания бизнес-процессов предлагает показывать не просто входы и выходы, как это делается в DFD — формате, он предлагает ввести три типа входов. Первый тип входов назвали так же входом, а два других входа назвали управлением и механизмами.

В стандарте IDEF0 с помощью входа показывают объекты — информационные и материальные потоки, которые преобразуются в бизнес-процессе. С помощью управления показывают объекты — материальные и информационные потоки, которые не преобразуются в процессе, но нужны для его выполнения. С помощью механизмов стал^ показывать механизмы, при помощи которых бизнес-процесс реализуется: технические средства, люди, информационные системы и т.д. Выход бизнес-процесса, описанного в стандарте IDEF0 полностью соответствует по смыслу выходу процесса, описанному при помощи DFD-схемы.

Четыре типа объектов, применяемых для описания входов и выходов в стандарте IDEF0, в английском варианте образуют сокращение ICOM и на схеме IDEF0 размещаются в строго отведенных местах относительно работ, которые называются функциональными блоками (Таблица 3.1).

Таблица 3.1 – Название и размещение входов и выходов в стандарте IDEF0 относительно функционального блока

Название объектов	Размещение
Русский вариант	Английский вариант
Вход	Input	Подходит к работе слева
Управление	Control	Подходит к работе сверху
Выход	Output	Исходит от работы справа
Механизм	Mechanism	Подходит к работе снизу

Давайте рассмотрим пример бизнес-процесса «Выточить деталь», который выполняет токарь. Входом процесса является заготовка из которой вытачивается деталь — она физически преобразуется в процессе. Для того, что бы токарь начал точить деталь ему нужно дать задание или план. Также ему понадобится чертеж с размерами детали. Так вот, чертеж, задание или план нужны для реализации бизнес-процесса и процесс без них не начнется, но по ходу выполнения процесса они не преобразуются. Согласно стандарту IDEF0 их относят к управлению. Для того, что бы выточить деталь нужен токарь, нужен станок — их относят к механизмам. Выходами или результатами бизнес-процесса является деталь (Рисунок 3.7).

Рисунок 3.7 – Стандарт описания бизнес-процесса IDEF0

Стандарт IDEF0 получил большое распространение в США и активно используется в России. Ввиду того, что в стандарте IDEF0 появилась дополнительная аналитика пс сравнению с классическим стандартом DFD, схемы бизнес-процессов получаемые при описании в стандарте IDEF0 выглядят более сложными с точки зрения менеджеров компании, в виду ограниченного наличия у них свободного времени. Данная сложность часто приводит к тому, что менеджеры, особенно высшего уровня, которые должны принимать активное участие в проекте по описанию и оптимизации деятельности компании, «отказываются» от работы с IDEF0. В данном случае IDEF0 — является излишне информационно насыщенным и сложным стандартом.

Второй недостаток стандарта IDEF0 связан с тем, что он дает больше поводов и возможностей сторонникам сопротивлений изменениям притормозить проект по описанию и оптимизации бизнес-процессов и дискредитировать его идею. Это также связано с усложненной аналитикой стандарта IDEFO, которая часто дает повод задуматься и задавать следующие вопросы: «А правильно ли, что этот объект отнесен ко входу? Может его отнести к управлению?»

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

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

Методология DFD в нотациях Гейна-Сарсона и Йордана-Де Маоко

Следующий стандарт описания бизнес-процессов, который получил распространение, был разработан на основе развития классической методологии DFD. Данный стандарт представлен двумя немного различающихся вариантами, которые называют нотациями. Первая из них называется нотацией Гейна Сарсона, вторая нотацией Йордона-Де Марко.

Гейн Сарсон, предложил классическую DFD-схему немного усложнить. Он предложил ввести дополнительный объект, с помощью которого показываются места бизнес-процесса, в которых хранится информация, либо материальные ресурсы. Примерами таким мест являются архив, в котором хранятся документы, база данных, в которой хранится информация, либо склад, на котором хранятся материальные ресурсы. Данный объект получил название — хранилище данных. На DFD-схемах в нотациях Гейна-Сарсона и Йордона-Де Марко также используются объекты, с помощью которых показывают внешних субъектов, с которыми бизнес-процесс взаимодействует. Данные объекты называют внешними сущностями. На рисунке 3.8 приведен пример DFD-схемы бизнес-процесса «Оформлении и выдача трудовой книжки сотруднику при увольнении», разработанной в нотации Гейна-Сарсона.

Рисунок 3.8 – DFD-схема бизнес-процесса «Оформление и выдача трудовой книжки сотруднику при увольнении» в нотации Гейна-Сарсонса

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

Вторая нотация Йордона-Де Марко методологии DFD была названа в честь разработавшего ее специалиста Йордона-Де Марко. В первом приближении эта нотация аналогична нотации Гейна Саросна, за исключение форм объектов: для описаний операций бизнес-процесса вместо закругленных прямоугольников стали использоваться круги, немного видоизменились и другие объекты- хранилище данных и внешние сущности (Рисунок 3.9).

Рисунок 3.9 – DFD- схема бизнес-процесса «Оформление и выдача трудовой книжки сотруднику при увольнении» в нотации Йордона-Де Марко

В таблице 3.2 приведены названия, обозначения и смыл элементов, используемых при построении DFD-схемы бизнес-процесса в нотациях Гейна-Сарсано и Йордона-ДеМарко.

Таблица 3.2 – Элементы методологии DFD в нотациях Гейна-Сарсано и Йордана-Де Марко

Знакомство с нотацией IDEF0 и пример использования / Блог компании Trinion / Хабр

Одна картинка стоит тысячи слов

Народная мудрость

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

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

Несколько слов о преимуществах графики

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

И для начала сделаем небольшой экскурс в историю. Вернемся в далекий 1877 год, в период Русско-Турецкой войны. Именно тогда полиграфист Сытин впервые применил графику при описании военных действий. Сейчас для нас все это привычно, при описании любого сражения у каждого перед глазами возникают карты со стрелками, которые наглядно показывают ход сражения. А в те времена военные действия описывались словами. Для каждого боя — много-много слов. И понять в итоге, что же происходит, было очень сложно.

А потому идея Сытина была поистине революционной — он начал печатать литографические копии карт с обозначением укреплений и расположений воинских частей. Назывались эти карты “Для читателей газет. Пособие”. Идея оказалась настолько актуальной, что первый же тираж “Пособий” разошелся мгновенно. И потом такие приложения были очень востребованы. Причина очевидна. Графика помогала понять то, что при помощи одних слов разобрать было практически невозможно.

Аналогичный пример беспомощности словесных описаний я могу привести также из своей практики. Один из моих заказчиков очень просил взяться за внедрение ERP-системы для его компании. На вопрос, есть ли у них какое-то техническое задание, я получил ответ: “Да, есть. Но в нем 400 страниц”. При этом клиент очень жаловался, что мои коллеги, к которым он обращался ранее, либо отказывались от проекта вообще, либо называли явно завышенные цены. После того, как я увидел, что в техническом задании действительно 400 страниц, и состоит оно исключительно из текстового описания, я понял причины поведения разработчиков. Прочитать такой объем текста, вникнуть в него, разобраться во всех нюансах только для того, чтобы понять задачу и назвать цену — это и правда очень сложно.

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

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

Почему это важно для моей работы

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

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

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

→ Пример одного из моих отчетов в текстовом виде

На самом деле, важно не предоставить объем, а максимально быстро и полно донести суть. Большие объемы текста требуют времени, которого у бизнесменов чаще всего очень мало. А графика позволяет сократить объем моего предложения и наглядно, в понятной форме показать решение. В результате мои предложения значительно сократились, в них появилась графика, а решения о начале сотрудничества стали приниматься быстрее.

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

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

Что такое нотация описания бизнес-процессов

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

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

В общем, нотации можно назвать языком программирования при бизнес-анализе.

Что такое IDEF0?

IDEF0 — методология функционального моделирования (англ. function modeling) и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является ее акцент на соподчиненность объектов. В IDEF0 рассматриваются логические отношения между работами, а не их временна́я последовательность (поток работ).

Википедия

Стандарт IDEF0 был разработан в 1981 году в США департаментом Военно-воздушных сил для автоматизации промышленных предприятий. В процессе разработки программного обеспечения разработчики столкнулись с необходимостью разработки новых методов анализа бизнес-процессов. В результате появилась методология функционального моделирования IDEF0, в которой для анализа применяются специальные нотации IDEF0.

Функциональная модель компании

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

Стрелки могут быть:

• Входящие – вводные, которые ставят определенную задачу.
• Исходящие – выводящие результат деятельности.
• Управляющие (сверху вниз) – механизмы управления (положения, инструкции и пр).
• Механизмы (снизу вверх) – что используется для того, чтобы произвести необходимую работу.

Входящие и исходящие стрелки точнее было бы называть вводящими и выводящими, так как по-английски они называются Input и Output соответственно. Но особенности перевода и привычные названия выглядят уже так, как сложилось. И все же для правильного понимания терминов важно помнить их значение в данном случае. Это подтверждается еще и тем, что данная нотация создана прежде всего для разработки ПО, и термины переводить правильнее в этой точки зрения.

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

IDEF0 – это очень простой и одновременно наглядный язык описания бизнес-процессов. С помощью этого стандарта возможна передача информации между разработчиками, консультантами и пользователями. Стандарт очень тщательно разрабатывался, он удобен для проектирования, универсален. Для работы с ним существует множество инструментов, например, VISIO, BPWIN, ERWIN, Bussines studio и т.д.

Кроме того, использование для создания бизнес-моделей IDEF0 — это не только удобно, это еще и правильно. Этот инструмент был разработан для бизнес-аналитики, он прошел длительную и тщательную отладку и шлифовку. А потому при помощи IDEF0 создать функциональную модель без ошибок намного проще, чем без применения этого стандарта.

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

Пример создания функциональной модели IDEF0

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

Основной блок – «Написать статью».

Пример описания функциональной модели верхнего уровня

Входящие стрелки – «Опыт», «Информация из сторонних источников». Это те вводные, которые необходимы для начала работы.

Управляющие для написания статьи – это «План публикации», «Требования издателя», «Правила русского языка».

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

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

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

В нашем случае работа делится на 4 основных этапа:

1. Подготовить аудио.
2. Подготовить текст
3. Подготовить текст к публикации.
4. Разместить статью в издании.

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

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

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

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

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

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

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

Как создавать нотации IDEF0

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

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

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

При этом важно понимать, что в результате потребуется 2 нотации. Первая будет отображать бизнес-процессы в виде «как есть». Ее вы создаете на основе интервью и согласовываете каждую детализацию с сотрудниками компании и руководителем. Очень важно, чтобы ваше видение существующих процессов совпало с реальностью, именно для этого и требуется подтверждение на всех уровнях.

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

Требования стандарта IDEF0

Базовые требования стандарта IDEF0, в принципе, я описал выше и показал на примере.

1. В левом верхнем углу всегда – главный элемент.
2. Все элементы должны иметь входящие и исходящие стрелки, так как для выполнения необходимо что-то получить на входе (заказ, поставленную задачу), а после обработки на выходе необходимо передать готовый продукт. Входящие стрелки всегда слева, исходящие – справа.
3. Сверху – управляющие элементы, снизу – механизмы, необходимые для выполнения процесса.
4. Если на одном листе (экране) располагается несколько блоков, каждый последующий располагается справа и ниже предыдущего.
5. Необходимо стремиться создавать схемы таким образом, чтобы пересечение стрелок было сведено к необходимому минимуму.

Стандарт IDEF0 включает в себя также общепринятые обозначения, правила, требования к блокам диаграмм, имеет собственную семантику. Подробно ознакомиться с ними можно в документе «Методология функционального моделирования IDEF0».

Типичные ошибки

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

Использование различных цветов

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

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

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

Слишком большое количество блоков

При составлении модели часто стараются отобразить на одном листе все нюансы работы компании со всеми подробностями. В результате получается очень большое количество блоков с большим количеством управляющих стрелок. Читабельность при этом теряется.

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

Нарушение структуры при внесении корректировок

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

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

Правила названия управляющих элементов и блоков

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

Чаще всего ошибки допускают при названии блоков. Например, вместо «Создать статью» пишут «Создание статьи». Блоки в данном подходе – это действия, а потому они должны быть всегда глаголами.

Выгоды использования IDEF0

• Самая первая выгода очевидна – это наглядность. Вы сами начинаете понимать, как работает та или иная система, и можете также наглядно пояснить, где в этой системе «тонкие места» и как ваши решения помогут избавиться от них.
• Взаимопонимание и отсутствие разночтений. При обсуждении работы компании с использованием функциональной модели у вас имеются наглядные и понятные интуитивно блоки задач с управляющими элементами. Кроме того, функциональное моделирование предполагает создание в случае необходимости глоссария, в котором раскрываются условные обозначения и термины. В результате вы с клиентом, руководителем, другими сотрудниками при обсуждении проблемы говорите на одном языке.
• Простота и высокая скорость создания модели. Конечно, научиться моделированию не так просто, как кажется. Ведь схема — это, по сути, сверхплотная подача информации, что очень хорошо для понимания, но для реализации такой подачи требуется особый подход. Мозг аналитика выступает в данном случае как очень мощный пресс с одной стороны, и фильтр – с другой. Но с опытом этот процесс становится очень быстрым. В результате вы получаете инструмент, который поможет и самому разобраться, что же происходит в той или иной системе, и при помощи созданного в сжатые сроки наглядного пособия проиллюстрировать важные моменты коллегам или заказчикам.
• Дисциплина и отсутствие ошибок. Стандарт IDEF0 предполагает строгие рамки и правила. Такой подход дисциплинирует, а привычка действовать в рамках стандарта помогает избежать ошибок по невнимательности. Любые нарушения стандарта становятся сразу заметны.

В чем трудность применения IDEF0

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

При этом я считаю, что бизнес-аналитик — это не совсем профессия, бизнес-аналитикой занимается каждый руководитель бизнеса или разработчик каких-то систем, который анализирует бизнес и стремится выстроить наиболее эффективную систему. Именно для этих людей и для этих целей предназначен инструмент IDEF0.

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

Еще статьи по данной теме:

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

Разбираемся с понятием BPM. Что такое управление бизнес процессами

В современных условиях бизнес активно применяет процессный подход к организации работы. Но до сих пор существует проблема понимания – что такое управление бизнес-процессами и как правильно использовать BPM.

Определение по версии EABPM (Европейская ассоциация BPM) этого термина звучит следующим образом:

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

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

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

Также напомню, что эту тему я поднимаю уже не первый раз. Я много говорил о бизнес-процессах в таких статьях, как «Что такое бизнес-процесс и описание бизнес процесса» или «Краткое описание BPMN с примером».

Но вопросы остаются, их часто задают мне и читатели статей, и мои клиенты. Кроме того, очень много путаницы в понимание сути вносят маркетинговые статьи и термины, связанные с этой сферой деятельности. Как разработчики программных систем, так и бизнес-консультанты, постоянно использующие в работе эти инструменты, успели внести в сферу управления бизнес-процессов очень много исключительно маркетинговых понятий. С одной стороны, этот процесс неизбежен в любой коммерческой сфере. С другой — BPM и без того не самая простая для неспециалиста методология. А маркетинг вносит дополнительную путаницу.

А потому я решил дать свое развернутое определение тому, что такое управление бизнес-процессами. И надеюсь, что сумею помочь разобраться в основных вопросах, связанных с применением BPM.

Как появилось BPM

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

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

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

1. Описание рабочего места
2. Должностная инструкция сотрудника
3. Требования техники безопасности и т.д.

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

А что делать, если появляется необходимость быстро изменить работу целой организации? А если еще при этом внедряется автоматизация? Ответом на эти запросы и стало появление BPM.

О том, что такое бизнес-процесс, я уже писал («Что такое бизнес-процесс и описание бизнес процесса»), а потому повторять основные положения и определение самого бизнес-процесса не буду. А на понятии управление бизнес процессами давайте остановимся подробнее.

Об управлении бизнес-процессами простыми словами

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

Определение от меня:

Управление бизнес-процессами (BPM) – это управление действиями (автоматизированными и неавтоматизирвоанными) в коллективе посредством бизнес-процессов.

Чтобы управлять любыми бизнес процессами необходимо:

1. Описать сами бизнес-процессы.
2. Внедрить в работу коллектива описанный бизнес процесс
3. Назначить людей, ответственных за бизнес-процессы, так называемых, стек-холдеров или владельцев бизнес-процессов.

Важно понимать, что бизнес-процесс может выполняться как человеком, так и быть частично автоматизированным. Аналогично и стек-холдером может быть и человек, и программа (автоматическое выполнение операций и автоматизированный контроль).

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

Необходимо исходить из понимания: процессный подход — это управление целым через управление частями.

И чтобы исключить путаницу в терминологии, поясню:

• BPM – это методология. т.е. набор основных принципов и подходов к построению нотаций и самой организации работы при помощи бизнес-процессов.
• BPMN – нотация(язык), в которой строятся нотации, в том числе, исполняемые
• BPMS – IT система исполнения, построенная по определенным правилам, заданных в методологии

Если проводить аналогию с наукой, то BPM — это прежде всего подход, своего рода мировозрение. BPMN — это методы и алгоритмы решения конкретных задач. Например, доказательства для теорем или набор методов для создания проекта обеспечения электричеством объекта (производства, многоквартирного дома). А, в свою очередь, BPMS- это уже готовые прикладные решения, которые можно “включить” и они уже будут работать. Для математики это — готовые решения задач, имеющих практическое значение. Для физики — непосредственное реализации той самой электропроводки и подключение объектов. Для сферы айти — готовый программный код.

Исполняемые и неисполняемые бизнес процессы

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

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

Для исполняемой нотации требуется определенная IT-среда — BPMS. При этом даже неисполняемые я рекомендую выполнять в BPMN, так как здесь сама среда помогает выявлять возможные ошибки, противоречия, что повышает грамотность и точность описания бизнес-процесса.

Отличия процессного и функционального подходов

Еще один важный факт, который поможет понять, что же такое на самом деле «управление бизнес-процессом». Мы уже выяснили, что управление – это создание определенной последовательности действий сотрудников. Т.е. в результате каждая автоматизированная система работает определенным образом. А человек – обязан по инструкции также выполнять заданные по инструкции действия.

При этом также необходимо знать:

Для стратегического планирования и оценки работы компании “в целом” лучше использовать функциональное моделирование и нотации (например IDF0). Об этом я подробно писал в статье “Знакомство с нотацией IDEF0 и пример использования”. Здесь вы сможете исходить из желаемого результата и выстраивать последовательность функций “черных ящиков”, необходимых для его достижения.

Для управления последовательностью действий и оптимизации того. что происходит внутри каждого этапа работы, а также улучшению взаимодействия между разными “черными ящиками”, необходим процессный подход BPM. Здесь вы изучаете уже сами действия, отслеживаете скорость и трудоемкость достижения результатов, оптимизируете и стандартизируете их.

Если вы вносите какие-то изменения в бизнес-процесс, то вы всегда отталкиваетесь не от целого, а от части. Т.е. вы меняете алгоритм работы программы и/или корректируете должностную инструкцию сотруднику, выполняющую определенные функции. В результате меняется один из элементов бизнес-процесса, и, как следствие, бизнес-процесс в целом.

Необходимо понимать:

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

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

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

При процессном подходе мы получаем ответ на вопрос «как это лучше выполнить», т.е. концентрируемся на тактическом, оперативном управлении. А потому здесь при изменении отдельных элементов между «входом и «выходом» меняется весь процесс.

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

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

Описание работы с BPM

Для лучшего понимания того, что такое BPM (управление бизнес-процессами), я приведу пример последовательности действий бизнес-аналитика в рамках этой методологии:

Опрос людей (сотрудников компании). Понимание того, каким образом производится работа в каждом конкретном случае.

Документирование бизнес-процесса на основе полученных данных. На этом этапе аналитик получает описание бизнес-процесса «как есть».

Изучение полученного бизнес-процесса с точки зрения слабых мест и возможности оптимизации:

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

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

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

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

Жизненный цикл процесса в BPM

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

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

Главное правило бизнес-аналитика: при оптимизации процесса нужно уметь вовремя остановиться. И здесь необходимо четко анализировать — трудоемкость (стоимость) изменений и повышение эффективности (выгоды) в результате.

Плюсы и минусы BPM

К числу преимуществ использования BPM относятся:

• Возможность максимально детализировать действия людей и систем, необходимые для получения результата.
• Графические нотации – наглядны, что позволяет понять особенности процессов в компании и увидеть их слабые места.
• Нотации прекрасно подходят в качестве инструкции исполнителю, который получит четкую и однозначную последовательность действий. При этом она будет оформлена графически – наиболее удобным для восприятия человеком образом.
• При использовании процессного подхода результат выполнения процесса будет стандартизирован и соответствовать ожидаемому. Это позволит снизить влияние человеческого фактора на уровень сервиса или выполнения любых других видов работы.
• Методология BPM – прекрасно проработана и стандартизирована благодаря BPMN. При этом инструменты (нотации BPMN) интуитивно понятны даже для людей, не изучавших управление бизнес-процессами вообще. С другой стороны, наличие стандартов и правил позволяет избегать ошибок при разработке и создавать в системе BPMS исполняемые нотации (готовые элементы автоматизации бизнеса).

Минусы BPM, как это часто бывает, находятся там же, где и преимущества:

• Высокая степень детализации процессов мешает восприятию работы бизнеса для стратегического планирования.
• На людях, которые разрабатывают процессную модель, лежит очень большая ответственность. Любая ошибка может привести к печальным результатам. Например, при разработке функциональной модели есть данные на входе, результат на выходе, инструменты, которые предоставляет компания исполнителю, и сам исполнитель. Пока исполнитель на выходе выдает ожидаемый результат, в рамках функции он может действовать по собственному усмотрению, выбирая оптимальный метод достижения цели. При процессном подходе исполнитель лишается «свободы маневра». У него появляется четко заданная последовательность действий с учетом всех возможных условий. И он не имеет права действовать иначе, даже если результат окажется отличным от ожидаемого.
• Бизнес-процесс статичен и практически не подлежит корректировкам «изнутри». Исполнитель получает четкую последовательность действий и уже не может проявить инициативу. В результате, любую ошибку исполнители будут повторять из раза в раз, пока она не будет исправлена в самом бизнес-процессе.

Каким компаниям подходит BPM

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

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

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

Подробнее о том, как именно управлять бизнесом при помощи бизнес-процессов я рассказывал уже в прошлых статьях, и буду говорить еще не один раз. Здесь я постарался максимально просто пояснить различия между терминами BPM, BPMS, BPMN и описать само понятие «управление бизнес-процессами». Без этих базовых знаний разобраться в процессном подходе невозможно.

Вопросы и ответы

В чем отличие функционального моделирования от процессного?

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

Какие понятия входят в BPMN?

В первую очередь, это непосредственно система BPMN, а также описание нотаций BPMS. О них я писал в этой статье, и подробно — в предыдущих статьях (см. рекомендуемые ссылки в конце публикации). Кроме того, не так давно появились новые понятия — DMN и CMMN. На них я сейчас подробно останавливаться не буду. Постараюсь описать новые понятия и их особенности в будущих публикациях.

Зачем нужно в построении нотаций столько сложностей и разные подходы?

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

С чего начать работу с BPM?

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

Можно ли использовать BPM для неавтоматизированных систем?

Можно. Это подход предназначен, в первую очередь, не для автоматизации (в IT сфере есть свои инструменты), а для организации работы компании или любого коллектива. Здесь могут учитываться участки работы с применением автоматизированных систем. А могут рассматриваться исключительно процессы в коллективе, причем, любом — от строительных бригад или производства до творческих коллективов в театре или филармонии. Главное, четко описать — как происходит интересующий вас процесс, а также, как вы его хотите изменить.

Для лучшего понимания тематики рекомендую статьи:

Также в настоящее время я готовлю к публикации книгу и онлайн курс, в которой подробно опишу собственное видение процессного подхода к бизнесу, а также мой собственный практический опыт работы в сфере функционального и процессного моделирования. Все желающие могут подписаться на уведомление о выходе новой книги по и другие новости trinion.org/podpiska-na-novosti-sayta>ссылке.

Разработка бизнес-процессов (описание, моделирование, реинжиниринг) от Систус Консалт

 

 

Разработка и реинжиниринг бизнес-процессов

 

 

 

 

ВНИМАНИЕ!

Приглашаем пройти обучение с одновременным консультированием по разработке и внедрению СМК по стандарту ISO 9001:2015 (ГОСТ Р ИСО 9001-2015) , кому предстоит самостоятельно разрабатывать СМК. Подробнее читать…

 

 

Разработка, моделирование, описание, реинжиниринг бизнес-процессов. Какова  актуальность?

В работе каждого генерального директора постоянно возникает вопрос: Что надо изменить в компании, чтобы повысить исполнительность сотрудников и производительность их труда, снизить непроизводственные потери, увеличить количество заказчиков и объем заказов, одним словом — как повысить эффективность и прибыльность организации?

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

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

К тому же оптимизация бизнес-процессов, как показывает практика, является самым дешевым и самым эффективным способом улучшения работы компании.

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

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

 

 

 

 

 

Моделирование бизнес-процессов, разработка бизнес-процессов – ключевой элемент СМК

Процессное управление и система бизнес-процессов является ключевым элементом систем менеджмента качества (СМК) по ISO 9001 (ИСО 9001), при чем разработка и внедрение СМК является главным направлением нашей деятельности. Таким образом, создав систему управления бизнес-процессами, Вы во многом подготовите компанию к разработке и внедрению СМК.

 

ВНИМАНИЕ! В случае разработки (моделирования) системы бизнес-процессов снижается стоимость услуги «Разработка системы менеджмента качества (СМК) по ISO 9001» .

 

 

Разработанная нами система управления бизнес-процессами легко встраивается в любую автоматизированную информационную систему управления производственной деятельностью компании (автоматизация бизнес-процессов).

Необходимо отметить, что система бизнес-процессов является основой любой системы менеджмента компании (системы менеджмента качества (СМК), системы экологического менеджмента, системы охраны труда и безопасности здоровья, менеджмента рисков, системы финансового менеджмента и др.). Таким образом, разработав систему управления бизнес-процессами, Вы значительно сократите затраты и трудоемкость работ по созданию любой системы менеджмента.

 

Разработка бизнес-процессов (моделирование, описание, реинжиниринг бизнес-процессов) включает комплекс работ

Перечень работ

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

 

Описание бизнес-процессов (оптимизация бизнес-процессов) включает следующий состав работ

1. Обследование существующей системы управления компанией. Разработка системы бизнес-процессов начинается со сбора и анализа информации о действующих бизнес-процессах; о недостатках, имеющихся при осуществлении работы подразделений и отдельных должностных лиц; об элементах системы управления, требующих оптимизации (реинжиниринга) бизнес-процессов; о корпоративной культуре в компании; изучается внешняя и внутренняя нормативная документация компании, др.
2. Разработка модели (сети) бизнес-процессов. На этом этапе фактически начинается разработка (моделирование) системы управления бизнес-процессами. Определяются бизнес-процессы, их взаимосвязь между собою. Назначаются владельцы бизнес-процессов. Строится графическая сеть или модель бизнес-процессов.
3. Разработка показателей и методов мониторинга бизнес-процессов. Определяются ключевые параметры (реперные точки) бизнес-процессов, выполняя которые владельцы бизнес-процессов обеспечивают нормальный ход бизнес-процесса. Выбираются наиболее действенные методы мониторинга бизнес-процессов.
4. Разработка системы показателей эффективности бизнес-процессов. Разработка показателей для оценки функционирования каждого бизнес-процесса. Создание механизма определения планируемых показателей бизнес-процессов и оценки их результатов.
5. Процедура «Разработка стандартов, регламентов или карт бизнес-процессов» включает в себя работы по созданию документов, в которых приведено описание бизнес-процессов по функциям, блок-схем бизнес-процессов СМК, процедур и ресурсов бизнес-процессов. Другими словами, осуществляется моделирование бизнес-процессов. На данном этапе работ проводится реинжиниринг (оптимизация) бизнес-процессов с учетом их взаимодействия. В процессы СМК встраивается система управления рисками, что обеспечивает повышение эффективности и результативности СМК.
6. Разработка схемы последовательности и взаимодействия  бизнес-процессов. Документируется взаимодействие бизнес-процессов по входным и выходным данным с целью визуализации системы бизнес-процессов. Определяется и документируется очередность выполнения бизнес-процессов с учетом их взаимосвязи.
7. Доработка схемы организационной структуры компании, положений о подразделениях, должностных и профессиональных инструкций. На этом этапе проекта вносятся изменения в организационно-распорядительные документы компании по результатам услуги «Описание бизнес-процессов, реинжиниринг бизнес-процессов». Обязанности, функции, права и ответственность, изложенные в положениях о подразделениях, должностных и профессиональных инструкциях корректируются с учетом разработанных бизнес-процессов или бизнес-процессов, прошедших процедуру – реинжиниринг (оптимизация) бизнес-процессов.

 

Стоимость (цена) и продолжительность работ

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

 

ВНИМАНИЕ! Услуга «Описание (моделирование) бизнес-процессов, реинжиниринг бизнес-процессов» оказывается с учетом всех требований ISO 9001 (ИСО 9001), предъявляемых к системам менеджмента качества (СМК). Разработанная система управаления бизнес-процессами создает основу системы менеджмента качества компании и её наличие почти в 2 раза сокращает затраты на разработку СМК.

 

 

Более подробную информацию об услугах, включая стоимость и продолжительность работ, можно получить по телефону: +7 (915) 281-03-08 или по электронной почте: [email protected]

Моделирование бизнеса. Основные подходы / Блог компании Trinion / Хабр

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

Я уже писал о моделировании при помощи IDEF0 (Знакомство с нотацией IDEF0 и пример использования), об организации работы склада и работе с клиентами от лида до сделки (Внедрение CRM. От регистрации лида до закрытия сделки. Кейс и пояснения), о системе Bizagi (Bizagi. Описание. Пример). И везде я использовал при пояснении примеров и практических решений нотации бизнес-процессов.

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

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

Основные подходы

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

• Функциональный;
• Процессный;
• Ментальный (с применением ментальных карт).

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

Функциональное моделирование

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

Например, компания разрабатывает какую-то CRM-систему для своего бизнеса. В случае применения функционального подхода к моделированию уже сама выбранная среда для работы подсказывает, с чего начинать. Точка входа – «входящий интерес клиента или лид», точка выхода – желаемый результат: «покупка и получение лояльного клиента», «получение постоянного клиента», «получение максимум информации о потенциальном клиенте» и т.д.

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

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

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

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

Процессное моделирование (моделирование бизнес процессов)

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

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

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

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

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

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

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

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

Ментальный подход (ментальные карты)

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

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

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

Плюсы применения таких ментальных карт очевидны:

• Не нужно знать какие-то специальные языки;
• Нет строгих рамок и ограничений при создании схемы;
• Ментальная карта в большинстве случаев интуитивно понятна;
• Создавать такие схемы просто.

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

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

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

Методология и языки бизнес-моделирования

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

Методология — это система принципов и стандартов описания бизнес моделей и их последующего анализа. В то время как язык бизнес-моделирования – это не более чем инструмент для разработки моделей бизнеса.

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

Отличие языков разработки бизнес-моделей в от языков проектирования систем

Существует целое семейство языков проектирования систем, которые внешне схожи с языками бизнес-моделирования, например, это Ares Studios, целое семейство языков UML и другие, которые используются для проектирования IT-систем.

Основное различие этих языков от языков разработки бизнес-процессов лежит в их предназначении. Если языки проектирования IT-систем рассматривают бизнес-процессы с точки зрения возможности их автоматизации, воплощении в IT-системах, то языки бизнес-моделирования рассматривают последовательность действий именно с точки зрения бизнеса, включая работу как IT-систем, так и сотрудников, движения товаров и т.д.

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

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

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

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

На самом деле, стандарты и правила – это огромный плюс:

1. Языки моделирования помогают максимально качественно передать информацию. Стандартизация повышает простоту восприятия.
2. Скорость разработки моделей значительно увеличивается. Языки содержат все необходимые инструменты и графические блоки в готовом виде. Вам не придется «рисовать» или придумывать свою терминологию. Инструментарий уже готов, и работа в его рамках значительно ускоряется. Конечно, язык нужно выучить. Но один раз изучить – это намного быстрее, чем каждый раз придумывать и пояснять собственный набор обозначений.
3. Снижается число возможных ошибок. Сами элементы системы уже будут «подсказывать» перечень возможных и необходимых действий. А в случае создания исполняемых моделей или неисполняемых, но в строгих рамках правил, всегда можно проверить работу бизнес-модели в исполняемой среде и провести отладку, как при программировании.

Применение моделей бизнеса на практике

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

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

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

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

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

Стандарты и моделирование бизнес-процессов

Управление бизнес-процессами (BPM)

Управление бизнес-процессами (BPM) Что такое BPM? Управление бизнес-процессами — это в первую очередь философия бизнеса О людях Как они работают вместе (их бизнес-процессы) Цели производительности

Дополнительная информация

Введение в BPMN

Стивен А.Уайт, IBM Corporation Аннотация Этот документ предназначен для обеспечения общего обзора и введения в нотацию моделирования бизнес-процессов (BPMN). Контекст и общее использование BPMN

Дополнительная информация

Обозначения моделирования процессов

Нотации моделирования процессов Управляемые событиями цепочки процессов (EPC) Нотация моделирования бизнес-процессов (BPMN) Повестка дня управления рабочими процессами Мотивация для BPM EPC BPMN Пример 1 Почему моделирование бизнес-процессов

Дополнительная информация

XPDL 2.0 и BPMN 1.0 Учебное пособие

Учебное пособие по XPDL 2.0 и BPMN 1.0 Март Апрель 2006 г. Кейт Свенсон Председатель, Технический комитет WfMC Вице-президент по исследованиям и разработкам, Fujitsu Software Corporation Джастин Брант, заместитель председателя, Европа, WfMC Steering

Дополнительная информация

BPMN и управление бизнес-процессами

BPMN и управление бизнес-процессами Введение в новый стандарт моделирования бизнес-процессов Мартин Оуэн и Джог Радж Попкин Software www.popkin.com (c) 2003 г., Popkin Software www.bptrends.com Executive

Дополнительная информация

Модель бизнес-процесса

Модель бизнес-процесса от Sparx Systems Все материалы Sparx Systems 2007 Sparx Systems 2007 Страница: 1 Содержание ВВЕДЕНИЕ … 3 ОБОЗНАЧЕНИЕ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ (BPMN) … 4 ЭЛЕМЕНТЫ ПОТОКА … 4

Дополнительная информация

Моделирование процессов с использованием BPMN 2.0

Моделирование процессов с использованием BPMN 2.0 В этой главе дается краткий обзор концепций нотации моделирования бизнес-процессов (BPMN) с особым упором на дополнения BPMN 2.0. Кроме того, он описывает

Дополнительная информация

Модернизация рабочего процесса с поддержкой SOA

Аннотация Виталий Хусидман Модернизация рабочего процесса — это случай модернизации, управляемой архитектурой (ADM), и следует за жизненным циклом ADM Horseshoe.В этом документе объясняется, как модернизация рабочего процесса вписывается в ADM

. Дополнительная информация

Курс по бизнес-процессам (BPMN)

Курс по бизнес-процессам (BPMN) 2-дневный курс, проводимый как открытый курс или курс на месте. Мы также предлагаем индивидуальные основы и расширенные модули, которые могут быть разработаны / адаптированы в соответствии с требованиями. Цели курса День

Дополнительная информация

Стандарты OMG BPM

OMG BPM Standards Дерек Майерс Генеральный директор, BPM Focus +44 (20) 8742 8500 Офис в Великобритании +44 (7703) 178 500 UK Cell +1 (714) 600 9010 US Cell miers @ bpmfocus.org Определение BPM Управление бизнес-процессами — это в первую очередь

Дополнительная информация

Моделирование бизнес-процессов

Электронная среда моделирования бизнес-процессов Семинар Balbir Barn 12 февраля 2007 г. Повестка дня Почему мы создаем модели бизнес-процессов Исторический контекст Подходы к моделированию бизнес-процессов Бизнес-процесс

Дополнительная информация

Многопарадигмальное управление процессами

Многопарадигмальное управление процессами Майкл Цур Мюлен 1, Майкл Роземанн 2 1 Технологический институт Стивенса Уэсли Дж.Школа управления технологиями Хоу Касл-Пойнт на Гудзоне Хобокен, штат Нью-Джерси 07030,

Дополнительная информация

MDE FOR BPM A Систематический обзор

MDE FOR BPM A Systematic Review Хосе Мануэль Перес Научно-исследовательский институт UCLM-Soluziona, Ronda de Toledo s / n, 13005, Сьюдад-Реаль, Испания [email protected] Франсиско Руис, Марио Пиаттини

Дополнительная информация

Руководство по моделированию

Руководство по моделированию [Вставьте здесь название компании] Июль 2014 г. Автор: Джон Доу Джон[email protected] Стр. 1 из 22 Содержание 1. Введение … 3 2. Управление бизнес-процессами (BPM) … 4 2.1.

Дополнительная информация

Описательные конструкции BPMN 2.0

Ссылка: Мустафа Джаррар: Конспекты лекций по описательным конструкциям BPMN 2.0 Бирзейтский университет, Палестина, 2015 г. Описательные конструкции BPMN 2.0 Мустафа Джаррар Бирзейтский университет, Палестина [email protected]

Дополнительная информация

IBM WebSphere Business Integration

BPTrends 1 Обзор продукта 1133 Westchester Ave.Уайт-Плейнс, Нью-Йорк 10604 Узнайте номера телефонов и факсов в вашем районе. продает набор продуктов BPM в рамках WebSphere Business Integration

Дополнительная информация

Бизнес-правила и стандарты

Справедливый информационный документ Исаака Стэн Хендрикс, председатель, OMG Business Rules Special Interest Group, декабрь 2003 г. 1 800 999 2955 из США 1 415 472 2211 откуда угодно [email protected] электронная почта www.fairisaac.com

Дополнительная информация .

Определение стандартов управления бизнес-процессами (BPM)

название компании Страна Австралия Канада Индия объединенное Королевство Соединенные Штаты —— Афганистан Албания Алжир американское Самоа Андорра Ангола Ангилья Антарктида Антигуа и Барбуда Аргентина Армения Аруба Австрия Азербайджан Багамы Бахрейн Бангладеш Барбадос Беларусь Бельгия Белиз Бенин Бермуды Бутан Боливия Бонэйр, Синт-Эстатиус и Саба Босния и Герцеговина Ботсвана Остров Буве Бразилия Британская территория Индийского океана Бруней-Даруссалам Болгария Буркина-Фасо Бурунди Камбоджа Камерун Кабо-Верде Каймановы острова Центрально-Африканская Республика Чад Чили Китай Остров Рождества Кокосовые (Килинг) острова Колумбия Коморские острова Конго Конго, Демократическая Республика Острова Кука Коста-Рика Хорватия Куба Кюрасао Кипр Республика Чехия Берег Слоновой Кости Дания Джибути Доминика Доминиканская Респблика Эквадор Египет Сальвадор Экваториальная Гвинея Эритрея Эстония Эфиопия Фолклендские (Мальвинские) острова Фарерские острова Фиджи Финляндия Франция Французская Гвиана Французская Полинезия Южные Французские Территории Габон Гамбия Грузия Германия Гана Гибралтар Греция Гренландия Гренада Гваделупа Гуам Гватемала Гернси Гвинея Гвинея-Бисау Гайана Гаити Heard / McDonald Isls.Гондурас Гонконг Венгрия Исландия Индонезия Иран, Исламская Республика Ирак Ирландия Остров Мэн Израиль Италия Ямайка Япония Джерси Иордания Казахстан Кения Кирибати Корея, Народно-Демократическая Республика Корея, Республика Кувейт Кыргызстан Лаосская Народно-Демократическая Республика Латвия Ливан Лесото Либерия Ливия Лихтенштейн Литва Люксембург Макао Македония, бывшая югославская Республика Мадагаскар Малави Малайзия Мальдивы Мали Мальта Маршалловы острова Мартиника Мавритания Маврикий Майотта Мексика Микронезия, Федеративные Штаты Молдова, Республика Монако Монголия Черногория Монсеррат Марокко Мозамбик Мьянма Намибия Науру Непал Нидерланды

.

NRS Business Process Standards and Guidelines using BPMN

Моделирование процессов с использованием BPMN 2.0

Моделирование процессов с использованием BPMN 2.0 В этой главе дается краткий обзор концепций нотации моделирования бизнес-процессов (BPMN) с особым упором на дополнения BPMN 2.0. Кроме того, он описывает

Дополнительная информация

Введение в BPMN

Стивен А. Уайт, IBM Corporation Аннотация Этот документ предназначен для обеспечения общего обзора и введения в нотацию моделирования бизнес-процессов (BPMN).Контекст и общее использование BPMN

Дополнительная информация

Руководство по моделированию

Руководство по моделированию [Вставьте здесь название компании] Июль 2014 г. Автор: Джон Доу [email protected] Стр. 1 из 22 Содержание 1. Введение … 3 2. Управление бизнес-процессами (BPM) … 4 2.1.

Дополнительная информация

Модель бизнес-процесса

Модель бизнес-процесса от Sparx Systems Все материалы Sparx Systems 2007 Sparx Systems 2007 Страница: 1 Содержание ВВЕДЕНИЕ…3 ОБОЗНАЧЕНИЕ МОДЕЛИРОВАНИЯ БИЗНЕС-ПРОЦЕССОВ (BPMN) … 4 ЭЛЕМЕНТЫ ПОТОКА … 4

Дополнительная информация

Описательные конструкции BPMN 2.0

Ссылка: Мустафа Джаррар: Конспекты лекций по описательным конструкциям BPMN 2.0 Бирзейтский университет, Палестина, 2015 г. Описательные конструкции BPMN 2.0 Мустафа Джаррар Бирзейтский университет, Палестина [email protected]

Дополнительная информация

Обозначения моделирования процессов

Нотации моделирования процессов Управляемые событиями цепочки процессов (EPC) Нотация моделирования бизнес-процессов (BPMN) Повестка дня управления рабочими процессами Мотивация для BPM EPC BPMN Пример 1 Почему моделирование бизнес-процессов

Дополнительная информация

Понятные человеку диаграммы BPMN

Понятные для человека диаграммы BPMN Рефакторинг примера голосования по электронной почте OMG Томас Аллвейер, версия 1.1 1 Модель процесса голосования по электронной почте Группа управления объектами (OMG) опубликовала полезный ненормативный документ

Дополнительная информация

ЛЕКЦИЯ 11: МОДЕЛИРОВАНИЕ ПРОЦЕССА

ЛЕКЦИЯ 11: МОДЕЛИРОВАНИЕ ПРОЦЕССОВ Схема логического моделирования процессов Элементы диаграммы потоков данных Функциональная декомпозиция Потоки данных Правила и рекомендации Структурированный анализ с примерами использования Цели обучения

Дополнительная информация

Моделирование шаблонов рабочего процесса

Моделирование шаблонов рабочего процесса Шаблоны рабочего процесса Bizagi Suite 1 Содержание Моделирование шаблонов рабочего процесса… 4 Реализация шаблонов … 4 Основные шаблоны потока управления … 4 WCP 1- Последовательность … 4 WCP 2-

Дополнительная информация

Теперь доступно на Amazon

Том Дебевуаз Джеймс Тейлор MicroGuide по моделированию процессов и решений в BPMN / DMN Создание более эффективных процессов путем интеграции моделирования процессов с моделированием решений Этот образец книги содержит:

Дополнительная информация

Промежуточное ПО Oracle Fusion

Руководство по моделированию и внедрению промежуточного программного обеспечения Oracle Fusion для Oracle Business Process Management 11g Release 1 (11.1.1) E15176-02 июль 2010 г. Описывает, как разрабатывать и внедрять бизнес-процессы с использованием

. Дополнительная информация

РАЗДЕЛ 2 ПРОГРАММИРОВАНИЕ И РАЗВИТИЕ

Page 1 РАЗДЕЛ 2 МЕТОДОЛОГИЯ РАЗРАБОТКИ ПРОГРАММИРОВАНИЯ И РАЗРАБОТКИ ПОДХОД ВОДОПАДА Модель разработки программного обеспечения Waterfall — это нисходящий последовательный подход к проектированию, разработке и тестированию

Дополнительная информация

Модернизация рабочего процесса с поддержкой SOA

Аннотация Виталий Хусидман Модернизация рабочего процесса — это случай модернизации, управляемой архитектурой (ADM), и следует за жизненным циклом ADM Horseshoe.В этом документе объясняется, как модернизация рабочего процесса вписывается в ADM

. Дополнительная информация

Символы процесса / работы

Блок-схемы и их значения Блок-схемы, определенные Николасом Хеббом Ниже приведен базовый обзор с описанием и значением наиболее распространенных символов блок-схем, также обычно называемых блок-схемой

. Дополнительная информация

Курс по бизнес-процессам (BPMN)

Курс по бизнес-процессам (BPMN) 2-дневный курс, проводимый как открытый курс или курс на месте. Мы также предлагаем индивидуальные основы и расширенные модули, которые могут быть разработаны / адаптированы в соответствии с требованиями. Цели курса День

Дополнительная информация

ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ

ТРЕБОВАНИЯ К ПРОГРАММНОМУ ОБЕСПЕЧЕНИЮ http: // www.tutorialspoint.com/software_engineering/software_requirements.htm Авторские права tutorialspoint.com Требования к программному обеспечению представляют собой описание функций и функций

Дополнительная информация

ГРУППА ВНУТРЕННИХ УСЛУГ PMO

Программа владения и осведомленности 1 Программа 3 Программа 4 Программа 5 Программа 6 Программа 7 Программа 2 Развитие возможностей Инфраструктура Программа n ОСНОВНЫЕ ФУНКЦИИ ГРУППЫ ВНУТРЕННИХ УСЛУГ Действовать как интерфейс

Дополнительная информация

Позиционирование центра управления данными

Центр управления данными Позиционирование Возможности и позиционирование Collibra Совет по управлению данными: Управление Операционная модель Управление данными Организация Роли и обязанности Процессы и рабочий процесс Актив

Дополнительная информация

Диаграммы вариантов использования.Руководство

Учебное пособие по диаграммам вариантов использования Что такое вариант использования? Концепция анализа требований Случай использования системы / продукта Описывает действия системы с точки зрения пользователя Рассказывает историю Последовательность

Дополнительная информация

Разработка требований к программному обеспечению

Разработка требований к программному обеспечению Три основные задачи в RE: 1 Выявить, что действительно хотят клиенты.Определите заинтересованные стороны, их цели и точки зрения. 2 Документ запишите (). Понятно

Дополнительная информация

BPMN и управление бизнес-процессами

BPMN и управление бизнес-процессами Введение в новый стандарт моделирования бизнес-процессов Мартин Оуэн и Джог Радж Попкин Software www.popkin.com (c) 2003 г., Popkin Software www.bptrends.com Executive

Дополнительная информация

6-1.Моделирование процессов

6-1 Ключевые определения моделирования процесса Модель процесса Формальный способ представления того, как работает бизнес-система. Иллюстрирует выполняемые действия и то, как данные перемещаются между ними. Диаграмма потоков данных

Дополнительная информация

Целостность 10. Руководство по учебной программе

Integrity 10 Curriculum Guide Live Classroom Curriculum Guide Integrity 10 Администрирование рабочих процессов и документов Обучение Целостность 10 Обучение администрированию SCM Целостность 10 Базовое обучение пользователей SCM

Дополнительная информация .

Расчет заработной платы. Авторитетные источники: Стандарты бизнес-процессов: Стандарты бизнес-правил:

Транскрипция

1 Авторитетные источники: Министерство обороны R, Vol. 7A, Глава 2 Министерство обороны R, Vol. 7A, Глава 29 Министерство обороны R, Vol. 7A, Глава 33 Министерство обороны R, Vol.7A, Глава 34 Министерство обороны R, Vol. 7A, Все главы Министерства обороны R, Vol. 5, Глава 8 Министерство обороны R, Vol. 5, Глава 24 Министерство обороны R, Том. 5, Глава 11 Министерство обороны R, Том. 12, Глава 16 Министерство обороны R, Vol. 7A, Глава 38 Министерство обороны R, Vol. 7A, Глава 48 Министерство обороны R, Vol. 7A, Глава 59 JFMIP SR-99-5 Требования к кадровым ресурсам и системам расчета заработной платы, Глава 14 JFMIP SR-99-5 Требования к кадровым ресурсам и системам расчета заработной платы, Глава 15 JFMIP SR-99-5 Требования к кадровым ресурсам и системам расчета заработной платы, Глава 6 JFMIP SR-99-5 Требования к кадровым ресурсам и системам расчета заработной платы, Глава 7 Совместные федеральные правила командировок, Том.1, Глава 10 OFFM-NO-0106 Требования к основной финансовой системе, Глава 11 Министерство обороны R, Vol. 5, Глава 6 Стандарты бизнес-процессов: Стандарт бизнес-процессов не был предписан законом или политикой Министерства обороны США. Стандарты бизнес-правил: Payroll_Processing_Business_Rule_03_001 Система расчета заработной платы военнослужащих должна поддерживать полный спектр действий по начислению заработной платы, включая запуск, изменение или прекращение выплаты заработной платы, удержания из заработной платы, информацию о членах или выборы с текущими и будущими датами на основе: 1.Ввод транзакции от специалиста по кадрам или начислению заработной платы 2. Ввод транзакции из внешних системных интерфейсов 3. Ввод транзакции на основе самообслуживания сотрудников Страница 1 из 12

2 4. События жизненного цикла, такие как присоединение, повышение, понижение в должности, разделения, назначения и изменения зависимости, 5. Изменения массовой ставки 6. Дата вступления в силу будущего или годовщины системы JFMIP SR-99-5 Требования к кадровым ресурсам и системам расчета заработной платы, Глава 14 JFMIP SR-99-5 Требования к кадровым ресурсам и системам расчета заработной платы, Глава 6 JFMIP SR-99-5 Требования к кадровым ресурсам и системам расчета заработной платы, Глава 7 Payroll_Processing_Business_Rule_03_002 Для поддержки расчета заработной платы военная система расчета заработной платы должна рассчитывать оплату на основе сегментов вычислений и заработной платы Даты начала и окончания периода: 1.Вычислительный сегмент — Вычислительные сегменты обозначают изменение ежемесячной ставки или права на получение прав и создаются, когда даты начала и окончания для расчетных факторов права (т. Е. Оценка, местоположение, тип оплаты тура и т. Д.) Не совпадают с датами периода оплаты. даты начала и окончания. 2. Дата начала платежного периода — дата начала платежного периода. Период оплаты — это повторяющийся период времени, в течение которого учитывается и оплачивается время военнослужащего. Даты начала и окончания периода оплаты используются вместе с датами начала и окончания периода заработка (например,грамм. Basic Pay и Basic Allowance for Housing) для определения сегментов расчета для расчета заработной платы. 3. Дата окончания платежного периода — дата окончания платежного периода. Период оплаты — это повторяющийся период времени, в течение которого учитывается и оплачивается время военнослужащего. Даты начала и окончания периода оплаты используются вместе с датами начала и окончания заработка (например, Basic Pay и Basic Allowance for Housing) для определения сегментов расчета для расчета заработной платы. Payroll_Processing_Business_Rule_03_003 Для поддержки обработки платежных ведомостей система расчета заработной платы военнослужащих должна рассчитывать валовую оплату как сумму каждой ставки заработной платы, умноженной на количество единиц, связанных с ней, плюс все соответствующие надбавки и / или другие валовые компоненты оплаты.Payroll_Processing_Business_Rule_03_004 Для поддержки обработки заработной платы военная система расчета заработной платы должна выполнять ретроактивные расчеты на основе корректировок предыдущего периода, изменений в праве сотрудника (для заработка или удержаний) или массовых изменений таблицы. Payroll_Processing_Business_Rule_03_005 Для поддержки обработки заработной платы военная система расчета заработной платы должна рассчитывать текущие и / или ретроактивные корректировки для надбавок, премий и дифференциалов, как это определено законом или постановлением. Они могут быть установлены в долларах или рассчитаны как процент от заработной платы с применением верхних пределов или других ограничений, когда это применимо.Страница 2 из 12

3 Payroll_Processing_Business_Rule_03_006 Система выплаты заработной платы военнослужащим и система подачи должны обеспечивать автоматизированные функции для создания сторнирования всего графика платежей или одного платежа в графике платежей на основе одного действия в сети. Создание записей сторнирования промежуточных выплат, запись восстановленной кредиторской задолженности и обновление соответствующих записей о платежах.Payroll_Processing_Business_Rule_03_007 Система расчета заработной платы военнослужащих должна автоматически вычислять, пересчитывать или изменять все права и отчисления на основе событий жизненного цикла, системных изменений или административных изменений, которые обновляют факторы расчета, права на участие, учета или выплаты, общие для еще одного права на заработную плату или вычетов. Примеры включают: 1. Изменения ставок заработной платы (например, BP, BAH, COLA, OHA) 2. Изменения местоположения (например, член, иждивенцы, враждебные области оплаты, области, освобожденные от налогов, CONUS и OCONUS) 3.Изменения иждивенчества (например, количество иждивенцев или тип иждивенца) 4. Статус служебных обязанностей (например, несанкционированное отсутствие, дезертирство, гражданское заключение, военное заключение, дополнительный отпуск, отпуск и т. Д.) 5. Тип тура и типы дат вступления в силу (например, неактивная командировка) , короткий тур и длительный тур) 6. Изменения налоговых ставок (например, новые налоговые ставки от федерального или государственного IRS) 7. Изменения ставок удержания (например, SGLI, Family SGLI, USSH) 8. Изменения FRB (например, FRB добавляет или изменяет маршрут транзитные номера и тип счета, используемый для Net Pay или отчислений) 9.Изменения жизненного цикла (например, вступление, разлучение, смерть, продвижение по службе и т. Д.) 10. Выплаты по BAS II во время отпуска. PCS, TDY и госпитализация 11. Взыскание долга (например, остаток долга уменьшен до нуля) 12. Сбор за срочные выплаты, например оставшийся баланс выделенных средств снижен до нуля) 13. Колебания иностранной валюты по жилищным пособиям за рубежом 14. Колебания в иностранной валюте пособия по прожиточному минимуму за рубежом 15. Пособие на разлучение с семьей Места на основе OHA Колебания иностранной валюты Министерство обороны R, Vol.7A, Все главы JFMIP SR-99-5 Требования к кадровым ресурсам и начислению заработной платы, Глава 6 Совместные федеральные правила поездок, Vol. 1, Глава 10 Payroll_Processing_Business_Rule_03_008 Система оплаты труда военнослужащих должна устанавливать и поддерживать будущие даты и суммы для автоматической выплаты первоначальных, ежемесячных платежей в рассрочку для бонусов, поощрительных выплат и специальных выплат. Министерство обороны R, Vol. 7A, Все главы Payroll_Processing_Business_Rule_03_011 Система оплаты труда военнослужащих должна поддерживать начальные или частичные выплаты бонусов, поощрительных выплат и специальных выплат, когда военнослужащие не выполняют условия контракта или службы, для которых была разрешена премия, специальная оплата или поощрительная выплата, в том числе: 1 .Прекращение будущих платежей в рассрочку 2. Возврат предыдущих платежей в рассрочку Страница 3 из 12

4 3. Выплата будущих взносов Министерство обороны R, Vol. 7A, Глава 2 Payroll_Processing_Business_Rule_03_013 Военная система расчета заработной платы рассчитывает дневную ставку (единицу оплаты) путем деления месячной ставки на 30 с получением результата, скорректированного с точностью до цента, считая полцента и более в целом.Payroll_Processing_Business_Rule_03_015 Если военная служба начинается или заканчивается в промежуточный день месяца, система расчета заработной платы военных должна рассчитывать заработную плату и пособия за фактическое количество дней, отработанных в течение этого календарного месяца, но только до 30-го числа этого месяца. Payroll_Processing_Business_Rule_03_017 Для резервных членов, призванных на действительную военную службу, система расчета заработной платы военнослужащих должна рассчитывать заработную плату и надбавки за необходимое время в пути от: 1. От дома до первого места службы 2. От последнего места службы до дома (за исключением случаев, когда они освобождены от действительной службы для выхода на пенсию, уволены, уволены с действительной службы или при увольнении).Payroll_Processing_Business_Rule_03_018 Для поддержки процесса выплаты система расчета заработной платы должна поддерживать функциональность для записи отмены выплат (возвратов платежей) для отдельных платежей, которые не были согласованы. Payroll_Processing_Business_Rule_03_019 Если участник умирает, система расчета заработной платы военнослужащих должна обеспечивать возможность выплаты всех будущих премиальных, специальных выплат и поощрительных выплат в рассрочку в окончательной выплате члена при увольнении. Министерство обороны R, Vol. 7A, Глава 2 Payroll_Processing_Business_Rule_03_020 Военная система расчета заработной платы должна устанавливать и поддерживать будущие даты и суммы для автоматической выплаты основных и стандартных денежных пособий на замену одежды.Страница 4 из 12

5 Министерство обороны R, Vol. 7A, Глава 29 Payroll_Processing_Business_Rule_03_022 Система расчета заработной платы военнослужащих должна рассчитывать ежемесячную заработную плату (30 дней) путем деления годовой заработной платы на 12 равных частей. Один взнос представляет собой оплату за каждый календарный месяц. Payroll_Processing_Business_Rule_03_023 Если действительная военная служба начинается 31-го числа любого месяца, и участник находится на действительной военной службе в течение 30 или более дней, военная система оплаты труда не выплачивает компенсацию за этот день.Payroll_Processing_Business_Rule_03_024 Если какое-либо лицо поступает на действительную службу в течение февраля и служит до конца месяца, военная система расчета заработной платы должна рассчитывать компенсацию заработной платы и пособий в течение 1 месяца (30 дней) за вычетом пропорциональной суммы для количества дней, истекших до поступления на службу . Payroll_Processing_Business_Rule_03_025 Если военная служба заканчивается до последнего дня февраля, система расчета заработной платы военных должна рассчитывать заработную плату и пособия только за фактическое количество отработанных дней.Payroll_Processing_Business_Rule_03_026 Для сотрудников силовых структур, имеющих право на получение компенсации за непрерывные периоды менее 1 месяца, система расчета заработной платы военнослужащих должна рассчитывать заработную плату и надбавки за каждый день периода по ставке 1/30 от ежемесячной суммы такой оплаты и пособия. Payroll_Processing_Business_Rule_03_028 Если участники обязаны нести действительную военную службу в течение 30 или более дней, но освобождаются до прохождения такой активной службы не менее 30 дней, система расчета заработной платы военнослужащих должна рассчитывать заработную плату и надбавки на повседневной основе.Страница 5 из 12

6 Payroll_Processing_Business_Rule_03_029 За отсутствие в статусе неплатежей 28 февраля невисокосного года военная система расчета заработной платы удерживает заработную плату за 3 дня. Если член отсутствует только 28 февраля високосного года, военная система расчета заработной платы вычитает заработную плату за 1 день — 28-е. В случае отсутствия 29 февраля високосного года из системы расчета заработной платы военных вычитается заработная плата за 2 дня.Payroll_Processing_Business_Rule_03_030 Военная система должна учитывать, что никакая заработная плата не теряется из-за несанкционированного отсутствия на 31-й день месяца, за исключением случаев, когда это первый день отсутствия или когда служащему платят за день в соответствии с DoDFMR, том 7A, глава 01, пункт B .1 Payroll_Processing_Business_Rule_03_031 Система расчета заработной платы военнослужащих должна вычитать 1/30 заработной платы за 1 месяц за каждый день отсутствия в статусе неоплаты. Payroll_Processing_Business_Rule_03_032 Для поддержки расчета заработной платы военная система расчета заработной платы должна фиксировать тип и даты поездки участника следующим образом: 1.Тип оплаты тура — тип оплаты тура в сочетании со статусом долга участника, используемый для определения количества дней, в течение которых военный член имеет право на оплату и надбавки за период тура, а также причитается ли члену заработная плата и / или надбавка в течение периода тура. Например, буровой тур, короткий тур и длительный тур. 2. Дата начала типа оплаты тура — дата начала определенного типа оплаты тура. 3. Дата окончания типа оплаты тура — Дата окончания определенного типа оплаты тура. Министерство обороны R, Vol. 7A, Глава 59 CHRIS: Член неактивной дежурной службы Дата начала и время Член неактивной дежурной службы Дата окончания дежурства Компонент резерва активной дежурной даты Члена резерва Компонент Активная дата окончания дежурства Зарезервированный компонент Активный тип дежурства Заработная плата_Процессинг_Business_Rule_03_032_01 Для длительных поездок с активной дежурностью (туры 30 дней или больше AKA Extended Active Duty Tours), система расчета заработной платы военнослужащих должна рассчитывать заработную плату и надбавки за весь период, как если бы в каждом месяце было 30 дней, а дневная ставка определяется как 1/30 от месячной ставки выплаты.Например: 31-й день месяца любого месяца Страница 6 из 12

7 не оплачивается. Payroll_Processing_Business_Rule_03_032_02 Для краткосрочных командировок на действительную военную службу (туры менее 30 дней) система расчета заработной платы военнослужащих должна рассчитывать заработную плату и надбавки на основе фактических дней в течение периода оплаты, а дневная ставка определяется как 1/30 от месячной ставки выплаты.Например: 31-й день месяца любого месяца выплачивается, если член находится на активной службе в 31-й день месяца Payroll_Processing_Business_Rule_03_032_03 Для неактивных учебных поездок (командировок) военная система расчета заработной платы должна рассчитывать заработную плату и надбавки на основе количество тренировочных периодов, зарегистрированных за день. Ежедневная ставка определяется как 1/30 от месячной ставки, и члену выплачивается дневная ставка за каждый период учений (неактивное дежурное обучение не менее 2 часов).Например: если участник обслуживает два периода обучения за один календарный день, то члену выплачивается оплата за 2 дня. См. Исключения для: 1. Пособия по присяге 2. Пособия по электронной проверке 3. Пособия по пошлинам на похороны 4. Базового пособия на проживание в натуральном виде Payroll_Processing_Business_Rule_03_032_04 Когда участник находится в краткосрочной поездке (действующая служба менее 30 дней) и продолжает активную работу пошлины в течение 30 дней или более по новым заказам или поправкам к первоначальным заказам, система расчета заработной платы военных должна рассчитывать заработную плату и надбавки на основе длительной поездки, как если бы в каждом месяце было 30 дней, а дневная ставка определяется как 1/30 от ежемесячная ставка пособия.Например: 31-й день месяца любого месяца не выплачивается Payroll_Processing_Business_Rule_03_032_05 Для Muster Duty Tours члену выплачивается надбавка за Muster Duty, но не разрешена оплата и надбавки Payroll_Processing_Business_Rule_03_032_06 Для Funeral Honors Duty Tours и не разрешены выплаты и пособия. Страница 7 из 12

8 Payroll_Processing_Business_Rule_03_032_07 Для дежурного тура электронного скрининга участнику выплачивается надбавка за электронный скрининг и не разрешается оплата и надбавки.Payroll_Processing_Business_Rule_03_032_08 Для коротких туров активной службы без оплаты и надбавок (туры менее 30 дней) члену не причитается заработная плата и надбавки Payroll_Processing_Business_Rule_03_032_09 Для коротких туров активной работы без оплаты (менее 30 дней) члену не причитается оплата, но разрешенная базовая надбавка к прожиточному минимуму (BAS) Коммутация наличными Заработная плата_Processing_Business_Rule_03_032_10 Для неактивных учебных поездок без оплаты (учебные туры) члену не причитается заработная плата или надбавки. Заработная плата_Processing_Business_Rule_03_036. более 360 дней в году, если это указано на основании фактического права, если общая сумма основана на сочетании оплаты активной службы, продленной службы и компенсации за обучение на неактивной службе Payroll_Processing_Business_Rule_03_037 Чтобы предотвратить потерю средств, система расчета заработной платы военнослужащих не должна допускать пользователи должны задним числом изменить или остановить расчет заработной платы удержания и возврат платежей, если эти отчисления были выплачены участнику или другому получателю (чек, электронный перевод средств, IPAC или оплата наличными).Вместо этого об ошибочной оплате необходимо сообщить в Отдел выплат для расследования или обработки. Отдел выплат выдает ваучер на возврат платежа, а затем переводит кредит на платежный счет участников. Примеры включают в себя: 1. Платежи по распределению 2. Платежи по долгам 3. Налоговые платежи 4. Платежи SGLI 5. Чистая оплата Страница 8 из 12

9 6. Частичные или авансовые платежи 7.Платежи по векселям Montgomery GI (стандартные и дополнительные) 8. Платежи TSP 9. Возвращенные облигации Министерство обороны R, Vol. 5, Глава 11 Министерство обороны R, Том. 5, Глава 24 Министерство обороны R, Том. 5, Глава 6 Министерство обороны R, Vol. 5, Глава 8 Министерство обороны R, Vol. 7A, Глава 42 Министерство обороны R, Vol. 7A, Глава 43 Payroll_Processing_Business_Rule_03_038 Система расчета заработной платы военнослужащих должна рассчитывать и сообщать начисление заработной платы военнослужащим пенсионерам за каждый период оплаты 1.Расчеты основаны на процентах начисления заработной платы пенсионеров, ежегодно публикуемых Управлением министра обороны (OSD), умноженных на общую сумму базовой заработной платы, рассчитанную за период выплаты. 2. Отдельные итоги рассчитываются для сотрудников действующей службы, резерва и национальной гвардии на основе полной или неполной занятости 3. Начисления пенсионных выплат сообщаются в интерфейсе учета заработной платы 4. Начисление пенсионных выплат не увеличивает валовую сумму члена Плата и не выплачивается члену Министерства обороны R, Vol.12, Глава 16 Министерство обороны R, Vol. 12, Глава 16 CHRIS: Компонент резерва члена Активный тип службы Член унифицированной службы Тип компонента Payroll_Processing_Business_Rule_03_039 Для поддержки обработки платежной ведомости система расчета заработной платы должна гарантировать, что вычеты из заработной платы, такие как выплаты, налоги, долги и украшения, не превышают валовую заработную плату военнослужащего (исключение: Задолженность SGLI) Payroll_Processing_Business_Rule_03_040 Система расчета заработной платы военнослужащих не будет производить выплаты, выплаты и пособия, если только член не имеет разрешения на базовую выплату на тот же период времени.См. Исключения для: 1. Пособие по присяге 2. Пособие по электронной проверке 3. Пособие по пошлинам на похороны 4. Базовое пособие на проживание в натуральной или денежной форме 5. Базовое пособие на проживание с иждивенцами для членов, не имеющих статуса оплачиваемой работы 6. Жилье за ​​рубежом Пособие с иждивенцами для членов в статусе неплатежей Страница 9 из 12

10 7. Базовое пособие на жилье с иждивенцами до оставшихся иждивенцев 8.Пособие на проживание за границей с иждивенцами, находящимися на иждивении 9. Выплата по инвалидности Объединенные федеральные правила поездок, Vol. 1, Глава 10 Payroll_Processing_Business_Rule_03_041 Система расчета заработной платы военнослужащих не должна выплачивать членам компонента резерва и охраны за неактивную военную подготовку, проводимую в день, в который он или она также имеет право на базовую оплату за действительную службу или действительную службу за обучение, или за день, в который вы имеете право на получение надбавки за прохождение службы (MDA). Payroll_Processing_Business_Rule_03_043 Система расчета заработной платы военнослужащих должна взаимодействовать с основными финансовыми системами для поддержки корректировок заработной платы и регулярных расчетов, которые пересекаются с финансовыми и / или календарными годами, и предоставлять необходимую информацию в основные финансовые и другие информационные системы.Payroll_Processing_Business_Rule_03_045 Для поддержки расчета заработной платы военная система расчета заработной платы должна фиксировать и сохранять статус обязанностей члена, чтобы определить, разрешены ли оплата и надбавки для его командировки следующим образом: 1. Статус обязанности — Статус обязанности члена фиксирует состояние Член военной службы Министерства обороны США, имеющий отношение к его или ее готовности к службе; (т. е. заключение, разлучение, умерший, несанкционированное отсутствие, дезертирство, дополнительный отпуск и т. д.). Статус обязанности члена используется с типом оплаты тура, чтобы определить, имеет ли член право на оплату и надбавки за такой статус долга, а также количество дней к оплате 2.Дата начала статуса обязанности — дата начала, на которую заказывается или разрешается определенный статус обязанности. Используется для определения начальной и конечной дат оплаты и надбавок участника. 3. Дата окончания статуса обязанности — дата окончания, для которой назначается или санкционируется определенный статус обязанности. Используется для определения даты начала и окончания выплаты члену заработной платы и надбавок Payroll_Processing_Business_Rule_03_045_09 Если статус члена имеет статус службы, необходимой для государственной службы, и в течение периода удержания, за исключением времени войны, члены имеют право на регулярную заработную плату и надбавки, а также 25-процентное увеличение основной заработной платы, на которую они имели право за день до начала периода удержания. Страница 10 из 12

11 Payroll_Processing_Business_Rule_03_045_11 Если статус члена — условно-досрочное освобождение (освобожден из дисциплинарных казарм), то член считается находящимся в разрешенном отпускном статусе и имеет право на оплату и пособия в той мере, в какой у члена есть неиспользованный накопленный отпуск на счет члена , за вычетом оставшихся в силе штрафов и неустойки.После использования накопленного отпуска член считается находящимся в сверхнормативном отпуске или отпуске без сохранения заработной платы и не имеет права на оплату и пособия в течение этого периода Министерство обороны R, Vol. 7A, Глава 48 Payroll_Processing_Business_Rule_03_045_14 Если статус участника — Присутствует при исполнении служебных обязанностей, участник имеет право на оплату и надбавки в зависимости от применимого типа оплаты тура Министерство обороны R, Vol. 7A, Глава 38 Министерство обороны R, Vol. 7A, Глава 59 Payroll_Processing_Business_Rule_03_046 Система расчета заработной платы военнослужащих должна рассчитывать и сообщать о начислении в Фонд медицинского обслуживания пенсионеров, имеющих право на Medicare, за каждый период оплаты 1.Расчеты основаны на ожидаемой средней численности персонала в течение финансового года, умноженной на нормальные расценки на душу населения, ежегодно публикуемые Советом актуариев Фонда здравоохранения пенсионеров, имеющих право на получение медицинской помощи DoD. 2. Отдельные итоги рассчитываются для военнослужащих действительной службы, резерва и национальной гвардии на основе полной или неполной занятости. 3. Начисление средств в Фонд медицинского обслуживания пенсионеров, имеющих право на участие в программе Medicare, отображается в интерфейсе расчета заработной платы. 4. Начисление в Фонд медицинского обслуживания пенсионеров, имеющих право на участие в программе Medicare, не увеличивает валовую заработную плату участника и не выплачивается участнику.Министерство обороны R, Vol. 12, Глава 16 Министерство обороны R, Vol. 12, Глава 16 CHRIS: Ставка права на заработную плату военнослужащим Министерства обороны США Дата начала Ставка права на выплату военнослужащих Министерства обороны США Дата прекращения выплаты военнослужащим Министерства обороны США Тип ставки права на выплату военнослужащих Министерства обороны США Тип компонента резерва Активный тип службы Член Унифицированной службы Тип компонента Payroll_Processing_Business_Rule_03_047 Система оплаты труда военнослужащих должна быть настраиваемой, чтобы соответствовать определенным агентством деловая практика. Настраиваемые функции агентства должны управляться таблицами / параметрами; например: 1.Таблицы ставок заработной платы военнослужащих 2. Таблицы налоговых кодов штатов 3. Таблица курсов иностранных валют 4. Таблицы идентификационных кодов получателей 5. Базовая надбавка на жилье Таблицы кодов территорий военного жилья 6. Таблицы бухгалтерского учета Страница 11 из 12

12 7. Таблицы значений доменов Приложение A: Общие стандарты информации о людских ресурсах Ставка права на оплату военнослужащих DoD Дата начала Ставка права на оплату военнослужащих DoD Начальная дата — это календарная дата, с которой начинается тип ставки DoD для военных выплат.Дата прекращения выплаты военнослужащих Министерства обороны США. Дата прекращения выплаты военнослужащих Министерства обороны США. Дата прекращения выплаты военнослужащих Министерства обороны США — это календарная дата, на которую заканчивается типовая ставка выплаты военнослужащих Министерства обороны США. Тип допустимой ставки военной заработной платы Министерства обороны США Тип допустимой ставки военной заработной платы Министерства обороны США — это классификация военной ставки Министерства обороны США. Дата-время начала службы неактивного дежурного участника Дата-время начала неактивной дежурной службы — календарная дата и время дня, когда начинается период неактивной дежурной службы (id) члена военной службы Министерства обороны. Дата-время остановки службы — это календарная дата и время дня, когда заканчивается период неактивной службы (ID) члена военной службы Министерства обороны США.Дата начала активной военной службы компонента резерва Членского резерва Дата начала активной службы компонента резерва — это календарная дата, когда начинается период активной службы члена военной службы Министерства обороны США. Дата прекращения активной службы компонента резерва. Дата окончания активной службы компонента резерва. Дата окончания активной службы компонента резерва — это календарная дата, когда заканчивается период действительной военной службы члена военной службы Министерства обороны США. Компонент резерва члена Активный тип обязанности Компонент резерва члена Активный тип обязанности — это классификация периода действительной военной службы, в течение которого выполняет военную службу министерства обороны компонента резерва.Тип компонента унифицированной службы Участник Тип компонента военной формы — это особая категория подразделения военной службы, в которую входит член военной службы Министерства обороны США. Страница 12 из 12

.

No related posts.