Бизнес процесс в виде схемы. Построение бизнес процессов компании и этапы разработки бизнес процесса

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

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

Член ABPMP Russia

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

Бизнес-тренер

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

В статье рассмотрены вопросы выбора нотации для описания процессов с целью последующей регламентации. Сравниваются между собой часто используемые нотации Work Flow, такие как: «Простая блок-схема » в MS Visio, «Процедура» Business Studio, нотация ARIS eEPC и другие. При сравнении нотаций основное внимание уделяется вопросам создания простых и понятных сотрудникам организации схем процессов.

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

Введение

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

Сравнение нотаций

Для сравнения были выбраны следующие нотации описания процессов:

1. «Простая блок-схема » (с отображением движения документов, с использованием блока «Решение»);
2. «Простая блока-схема » (без отображения движения документов, без использования блоков «Решение»);
3. «Процедура» системы Business Studio (один из возможных вариантов представления);
4. ARIS eEPC.

В качестве тестового примера был выбран простой и интуитивно понятный процесс. Результаты описания этого процесса представлены на Рис. 1-4.

Рис. 1. Схема процесса в нотации «Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На схеме, представленной на Рис. 1, последовательность выполнения операций процесса во времени показана при помощи жирных стрелок, а движение документов — при помощи тонких пунктирных стрелок. Блоки «Решение» использованы классическим образом. Они отображают информацию (вопросы), от которых «зависит» последующий ход процесса. Такой подход к использованию «ромбиков» является весьма распространенным. Но фактически, вся логика принятия решений и формирования тех или иных выходов (документов) должна заключаться внутри операций процесса. Если задуматься, то ценность (смысл) рисования этих «ромбиков» не является очевидным. Что это за объекты: операции процесса, события? Вроде бы, ни то, и ни другое. Это скорее операторы принятия решения по какому-либо условию. Но ведь мы разрабатываем схему процесса для людей, а не пишем компьютерную программу на специальном языке. В компьютерной программе «ромбик» был бы полноценной операцией сравнения условий и т. п. Но на схеме процесса нужно показывать реальные объекты — процессы, выполняемые людьми, документы, информационные системы и т. п. Задумайтесь, корректно ли показывать «ромбики» отдельно от операции процесса на схеме? Вместо этого можно:

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

Сформулируем «плюсы» и «минусы» рассмотренного выше (Рис. 1) способа использования «ромбиков».

«Простая блок-схема » в MS Visio (с движением документов, с использованием блока «Решение»)

На Рис. 2 показан пример того же самого процесса, только описанного без использования блоков «Решение» и документов. Легко проверить, что на этой схеме на 24 графических элемента меньше, чем на схеме Рис. 1. Схема Рис. 2 выглядит гораздо проще. От графических элементов не рябит в глазах, а с точки зрения информативности эта схема вполне понятна и доступна конечному пользователю. Если для каждой операции процесса описать требования к ее выполнению текстом, то комбинируя табличную и графическую формы представления, можно вполне адекватно описать порядок исполнения процесса для сотрудников компании.

Рис. 2. Схема процесса в нотации «Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

«Простая блок-схема » в MS Visio (без движения документов, без использования блока «Решение»)

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

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

Второй особенностью схемы процесса, представленной на Рис. 3, является применение стрелок. Для отображения последовательности операций можно использовать стрелку с одним наконечником — стрелку «предшествования». Для отображения движения документов можно использовать стрелку с двумя наконечниками. Однако в Business Studio можно обойтись использованием только одного типа стрелок — стрелками «предшествования». При этом к именованным стрелкам можно привязывать необходимое количество документов, которые определены в справочнике объектов деятельности.

Такой подход дает возможность:

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

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

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

Рис. 3. «Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

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

«Процедура» системы Business Studio (вариант с нетрадиционным использованием блоков «Решение»)

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

На Рис. 4 представлена схема рассматриваемого процесса, разработанная в нотации ARIS eEPC. Заметим, что на схему не поместились некоторые операции процесса. Эта неполная схема простейшего процесса, выполненная в нотации ARIS eEPC, содержит четыре оператора логики и восемь событий! Сотрудник, читающий схему, должен уметь правильно интерпретировать все эти логические операторы. Без специального обучения и наличия некоторых навыков чтения подобных схем, рядовой сотрудник вряд ли сможет понять логику рассматриваемого процесса без подробного текстового описания или помощи квалифицированного бизнес-аналитика.

Заметим, что схема процесса в нотации ARIS eEPC занимает существенно больше места, чем схемы, представленные на Рис. 1-3. Трудоемкость формирования такой схемы также существенно выше.

Рис. 4. Схема процесса в нотации ARIS eEPC (построена в Business Studio)

Схема процесса в нотации ARIS eEPC (построена в Business Studio)

В целом, если Вы не собираетесь покупать SAP R/3, то выбор и использование нотации ARIS eEPC не является, с точки зрения автора статьи, оптимальным решением. Стоит обратить внимание на более наглядные и интуитивно понятные исполнителям нотации описания процессов. Впрочем, кому-то нотация ARIS eEPC может показаться более наглядной и понятной. До определенной степени, это вопрос вкуса.

Описание процесса для целей последующей автоматизации

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

Своим мнением об использовании BPMN 2.0. делится А. А. Белайчук — Генеральный директор компании «Бизнес-консоль»:

«На Рис. 5 изображен тот же процесс в нотации BPMN. Как мы видим, этот рисунок похож на Рис. 1: в нотации BPMN задачи изображаются прямоугольниками, развилки — ромбами, данные — пиктограммой, похожей на документ. Потоки управления — сплошные линии, потоки данных — пунктирные.

Надо учитывать, что на этой диаграмме задействована только малая часть нотации BPMN: только один вид развилок из 5 имеющихся в палитре, один вид задач из 8. Помимо более широкой палитры, эту нотацию отличает возможность моделировать не только изолированный поток работ, но также несколько процессов, взаимодействующих друг с другом через сообщения или данные. Кроме того, эта нотация более строгая: в ней определены не только значки, но и правила, по которым они могут сочетаться друг с другом. Необходимость таких правил диктуется тем, что нотация BPMN ориентирована не только на то, что ее будут читать люди, но и на непосредственное исполнение специальным программным обеспечением — „движком“ BPM-системы.

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

Рис. 5. Схема процесса в нотации BPMN 2.0

Практика жизни

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

Рис. 6. Примеры схемы процесса одной из компаний

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

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

Выводы

Итак, очевидно, что при описании процессов нужно стремиться к простоте и понятности для сотрудников.

Использование сложных, формализованных нотаций при описании процессов приводит к:

• Трудностям при использовании (интерпретации) схем рядовыми сотрудниками;
• Невозможности (сложности) организации работ по описанию процессов силами сотрудников подразделений, не прошедших специальное обучение;
• Значительному увеличению трудозатрат бизнес-аналитиков на формирование схем;
• Дополнительным сложностям при документировании схем (большой объем и т. п.).

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

http://finexpert.ru/ — среда общения профессионалов http://bpm3.ru/ — процессы, проекты, эффективность

Мы рассмотрели основные понятия бизнес-процессов. В данной части мы рассмотрим моделирование бизнес-процессов и приведем пример моделирования.

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

Моделирование – процесс исследования деятельности организации с целью построения формализованного (графического, табличного, текстового) описания бизнес-процессов организации.

• интервьюирование;
• работа с законодательством, документами организации;
• методы мозгового штурма и т.д.

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

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

1. Определить результат и владельца бизнес-процесса.
2. Определить набор и порядок действий, составляющих бизнес-процесс.
3. Определить исполнителей бизнес-процесса: на данном шаге необходимо произвести разделение зон ответственности, выделить какие сотрудники каких подразделений несут ответственность за выполнение действий процесса, привязать исполнителей к действиям.
4. Определить события бизнес-процесса. Определить типы событий: начальное, конечное, промежуточное. Привязать промежуточные события к действиям.
5. Определить ресурсы: документы, информацию, и др. потребляемые действиями бизнес-процессов. Привязать ресурсы к действиям.

Схема, иллюстрирующая алгоритм моделирования показана на рисунке ниже:

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

• дополнить существующую модель ответвлениями;
• предусмотреть отдельно действия «альтернативного» процесса.

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

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

Для фиксации бизнес-процессов в графическом виде используется система условных обозначений элементов (нотация). Наиболее известные нотации: SADT/IDEF0, IDEF3, DFD, BPMN, ARIS, UML. Рассмотрение и сравнительный анализ нотации не входит в предмет обсуждения данной статьи; интересующимся в интернете можно найти массу статей на темы сравнения нотаций, например «IDEF vs ARIS».

Пример описания бизнес-процесса

Приведем пример описания бизнес-процесса. В качестве примера возьмем процесс предоставления неоплаченного отпуска. Рассмотрим порядок и документооборот, возникающий при указанном выше процессе. Метод сбора информации: законодательство РФ как предварительный материал перед интервью с экспертами предметной области и Владельцем процесса. Нотация описания: ARIS eEPC.

1. Сбор исходного материала.

1.1 Предоставление отпуска регламентируется Трудовым Кодексом (при сборе материала необходимо опираться на последнюю редакцию, на момент написания статьи – с изменениями от 30 декабря 2015 г. № 434-ФЗ), статьей 128 Отпуск без сохранения заработной платы

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

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

• участникам Великой Отечественной войны — до 35 календарных дней в году;
• работающим пенсионерам по старости (по возрасту) — до 14 календарных дней в году;
• родителям и женам (мужьям) военнослужащих, сотрудников органов внутренних дел, федеральной противопожарной службы, органов по контролю за оборотом наркотических средств и психотропных веществ, таможенных органов, сотрудников учреждений и органов уголовно-исполнительной системы, погибших или умерших вследствие ранения, контузии или увечья, полученных при исполнении обязанностей военной службы (службы), либо вследствие заболевания, связанного с прохождением военной службы (службы), — до 14 календарных дней в году;
• работающим инвалидам — до 60 календарных дней в году;
• работникам в случаях рождения ребенка, регистрации брака, смерти близких родственников — до пяти календарных дней;

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

1.2. Документооборот при оформлении отпуска регламентируется постановлением Госкомстата РФ от 05.01.2004 N 1 «Об утверждении унифицированных форм первичной учетной документации по учету труда и его оплаты», раздел «Приказ (распоряжение) о предоставлении отпуска работнику».

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

Составляются работником кадровой службы или уполномоченным им на это лицом, подписываются руководителем организации или уполномоченным им на это лицом, объявляются работнику под расписку. На основании приказа (распоряжения) о предоставлении отпуска делаются отметки в личной карточке (форма N Т-2 или N Т-2ГС(МС)), лицевом счете (форма N Т-54 или N Т-54а) и производится расчет заработной платы, причитающейся за отпуск, по форме N T-60 »Записка-расчет о предоставлении отпуска работнику».

Приводим данные, необходимые для моделирования бизнес-процесса (действуем согласно описанной ранее схеме):

1. Результат бизнес-процесса - оформленные согласно законодательству РФ и стандартам организации документы .

2. Владелец бизнес-процесса : руководитель кадровой службы. Как определить владельца? Владелец – это сотрудник, обладающий ресурсами для осуществления бизнес-процесса (в данном случае ресурсы – сотрудники кадровой службы) и несущий ответственность за результат бизнес-процесса.

3. Набор и порядок действий :

написание заявления -> составление приказа -> -> –> .

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

4. Исполнители бизнес-процесса. . Для более наглядного предоставления информации приведем последовательность шагов и исполнителей в таблице:

5. События . Дополним вышеуказанную таблицу информацией о событиях:

6. Ресурсы, документы и информация . В данном примере мы не учитываем такие ресурсы, как время исполнителей, материалы и оборудование, т.к. нам важны документы, оформленные согласно законодательству РФ и стандартам организации (см. результата процесса). Нам надо проанализировать, какие документы принимают участие в процессе. Дополним существующую таблицу информацией:

7. Проведем анализ «что если».

• Что если заявление будет содержать ошибки (начиная от грамматических, заканчивая неправильным указанием реквизитов)? Инициатор заявления не обязан иметь достаточную квалификацию для безошибочного заполнения заявления (а обязан уметь грамотно выполнять свои непосредственные обязанности). Для устранения случая неправильного заполнения заявления добавим действие проверки заявления в основной процесс, т.к. нам важно предотвратить наличие ошибочного документа в процессе.
• Что если приказ на отпуск будет неправильно составлен? Т.к. в обязанности специалиста кадровой службы входит составление кадровых документов, то мы предполагаем, что в большом количестве случаев приказ составляется правильно. Это не отменяет проверку квалификации специалиста кадровой службы (процессы приема на работу и аттестации) и проведение периодической проверки документов (процесс аудита кадровых документов).
• Что если руководитель не подпишет приказ и инициатор:
  • имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос запишем в открытые вопросы по данному процессу и зададим его Владельцу процесса при согласовании процесса. Всю ответственность за исполнение процесса несет Владелец процесса, именно он определяет правила выполнения работы во вверенном ему подразделении;
  • не имеет право на отпуск, согласно 128 статье Трудового кодекса. Данный вопрос также запишем в открытые вопросы.

• Что если инициатор откажется подписывать приказ (например, у него изменились обстоятельства, согласно которым он брал отпуск)? Мы прекращаем процесс.
• Что если внесение отметок в кадровые документы Т-2 и Т-54а будет некорректным? Данный вопрос аналогичен вопросу, рассматриваемому в п. 3.2.

Дополним существующую таблицу полученной информацией. Фактически мы получили предварительное описание процесса в табличном виде:

Открытые вопросы

• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор имеет право на отпуск, согласно 128 статье Трудового кодекса
• Что если руководитель инициатора отказался подписать приказ на отпуск и инициатор не имеет право на отпуск, согласно 128 статье Трудового кодекса

Краткое обозначение элементов нотации ARIS eEPC приведено в таблице ниже (описаны не все элементы нотации, а используемые. Графическое обозначение элементов взято из пакета MS Visio):

Схема, отображающая взаимодействие элементов показана ниже:

Графическое отображение процесса предоставлено выглядит следующим образом:

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

Вместо заключения

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

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

- Смотри, бизнес-процессы снижают вариабельность результатов за счет стандартизации операций. Вариабельность означает снижение разброса допустимых вариантов результатов процесса. Я описал простой пример, бизнес-процессы применимы не только к кадровому делу, но и к деятельности организации. Представь себе, что организация, специализирующая на поставке запчастей, будет производить детали с разным уровнем качества (мы помним, что качество – это соблюдение характеристик изделия). Далее автозапчасти будут ставиться на автомобили, и мы получим… продукцию АвтоВАЗа. Продукция АвтоВАЗа находит своего покупателя, но мы в последнее время предпочитаем автомобили качественной сборки.

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

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

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

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

Спасибо читателям, что дошли до этого места. Можно было бы многое сказать дополнительно: рассказать про инструменты, используемые при описании бизнес-процессов, подробнее коснуться нотаций… Но это всё продолжение введения в бизнес-процессы.

Евгений Пономарёв

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

Функции (операции, действия);

События (в некоторых методиках используется термин «состояния»);

Ресурсы, среди которых, отдельно выделяют две группы: о исполнители — роли, сотрудники, должности, подразделения о информационные ресурсы — документы, файлы, архивы и другие носители информации;

Продукты и услуги

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

Функция (формальное определение) — это предметно-ориентированное задание или действие, выполняемое над объектом, в результате которого достигается одна или несколько целей, стоящих перед компанией

Возможны три варианта структурирования функций на предприятии

По объекту — объектно-ориентированный;

По процессу — процессно-ориентированный;

По операциям — операционно-ориентированный

Объектно-ориентированный подход заключается в том, что выделяются все функции, которые воздействуют на один и тот же объект, например, «заказ» (см. Рис. 4). При процессно-ориентированном подходе выделяются все функции, задействованные в процессе, например, «обработка заказа» (см. Рис. 5). При операционно-ориентированной структуре функций внимание сосредотачивается на виде операций, например, «корректировка».

1.2.2. События

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

В комплексных информационных системах чаще используется понятие «состояние)). Состояние и событие всегда связаны с каким либо объектом. В случае события «Товар есть на складе» некий объект (товар) находится в состоянии наличия. В дальнейшем описание состояний объектов помогает составлять требования к информационной системе.

1.2.3. Ресурсы

Ресурсы — потребляемые в процессе предметы труда и используемые в процессе средства труда.

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

1.2.4. Исполнители

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

Организационные звенья — структурные подразделения — отделы, и т. д.;

Должности — различные должности из штатного расписания компании, например: Менеджер по продажам, Логистик, Товаровед, Начальник цеха №1;

Сотрудники — персоналии, работники компании (ФИО), например, Иванов Иван Иванович;

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

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

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

Администратор

Пользователь

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

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

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

Исполняет (executive) — непосредственно участвует в выполнении действия, причем, если есть несколько исполнителей, то подразумевается, что они взаимозаменяемы и каждый может выполнить действие самостоятельно.

Утверждает результат — обычно руководящие должности.

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

Отвечает за ИТ обеспечение — например, системный администратор.

Консультирует такой тип связи присутствует при участии внешних консультантов.

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

1.2.5. Информационные ресурсы

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

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

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

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

1.2.6. Продукты и услуги

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

1.2.7. Потоки

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

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

Информационный поток — показывает перемещение таких объектов как бумажные документы, файлы, записи баз данных и т.д.

Организационный поток — последовательность исполнителей процесса в порядке выполняемых работ.

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

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

1.2.8. Уровни описания процессов (декомпозиция)

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

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

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

Каждая из методик моделирования имеет право на существование, а также свои достоинства и недостатки.

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

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

Что же представляет собой многоуровневое моделирование бизнес-процессов? Функция (одно действие) процесса может представлять собой отдельный процесс и раскрываться уровнем ниже в виде отдельного процесса состоящего из нескольких операций.

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

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

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

Бизнес-процесс — последовательность действий (подпроцессов), направленная на получение заданного результата, ценного для организации.

Бизнес процесс

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

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

Ключевыми понятиями процессного подхода являются:

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

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

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

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

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

Бизнес-процесс

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

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

Общее представление бизнес-процесса.

Понятие бизнес-процесса

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

В соответствии со стандартом ENISO 9001:2000 процесс - это набор взаимосвязанных средств и действий, преобразующих вход в результат. Процессы вызывают изменения соответствующего объекта.

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

Такими параметрами являются:

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

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

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

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

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

К ним относятся:

• стратегическое развитие компании;
• долго- и среднесрочное планирование в компании;
• развитие персонала;
• инвестиционное планирование;
• мотивация персонала и др.

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

• обработка данных;
• техническое обслуживание;
• логистика;
• административные процессы и др.

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

Схема 2. Взаимосвязь бизнес-процессов предприятия

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

Схема 3: Уровни бизнес-процессов.

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

Схожие термины:

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

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

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

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

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

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

Основные элементы

Главными элементами данной нотации являются два понятия: «Функция» и «Событие». Отображаются они следующим образом:

Рисунок 1. Основные элемента нотации eEPC

Отличие друг от друга функций и событий:

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

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

Пример. Пользователь интернет-магазина оставил на сайте заявку, а работник магазина получил ее.

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

«Поступила заявка от клиента» - событие;
«Проверить остатки товара» - функция;
«Получена выписка об остатках товара» - событие;
«Позвонить клиенту» - функция;
«Информация от клиента получена» - событие;
«Создать запись в журнале заявок» - функция;
«Запись в журнале заявок создана» - событие.

На схеме это выглядит так:

Рисунок 2. Фрагмент процесса обработки заявки от клиентов в интернет-магазине

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

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

Кроме двух основных элементов в нотации eEPC используются и другие. Рассмотрим их подробнее.

Дополнительные элементы

В нотацию можно добавить следующие элементы:

Рисунок 3. Дополнительные элементы нотации eEPC

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

Рисунок 4. Варианты элементов, которые можно использовать для расширения нотации eEPC

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

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

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

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

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

В идеале важные распоряжения должны поступать в письменной форме, а исполнитель должен подтверждать их получение.

Введение в бизнес-процессы. Часть 2

Но по различным причинам это не всегда возможно. Вот что можно сделать в такой ситуации:

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

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

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

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

Продолжение следует.

Александр Сагалович, www.probusiness.by

Центр Оптимизации Бизнеса реальный отзыв

Владимир Карусель

Центр Оптимизации Бизнеса реальный отзыв:
Хочу уберечь людей от еще одних МОШЕННИКОВ в интернете!
Приветствую Вас дорогие друзья, на этом единственно честном сайте со свободой слова!
За невозможностью написать РЕАЛЬНЫЙ отзыв об этой организации, вынужден делать это здесь. Очень надеюсь что это поможет и его не удалят! Вы не найдете в интернете негативный отзыв или даже средний. Их просто не публикуют. Пробовал сделать это на нескольких популярных сайтах, таких как "Добавь" по адресу www.stop-list.ru ; на "Социальная сеть трудовой взаимопомощи" по адресу antijob.net ; "Курьер финансы" по адресу www.courier.com.ru, заверяющих население в своей честности и неподкупности — ни один комментарий не был размещен о Центре Оптимизации Бизнеса, более того, я говорил с их администрацией — никто не собирается удалять ЛОЖЬ со своих страниц и продолжают покрывать преступников, размещая статьи на заказ о "Центре оптимизации бизнеса".

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

Глава 4 Описание бизнес-процессов организации

На просьбу поговорить с бухгалтером "посылают" писать письма. Все мои номера телефонов занесли в черный список, дозвониться не могу. Проконсультировался с юристом — на их сайте вся информация — это маркетинговый ход и их за "текст" привлечь не возможно. Не связывайтесь с Центром оптимизации бизнеса!!! Слишком много мошенничества в Интернете! А самое главное нет никакой возможности с ними бороться! Нашел людей, которых они тоже кинули, они не верят в справедливость и нашу правовую систему и отказываются бороться. Будьте ОСТОРОЖНЫ! Покупайте любые услуги после заключения договора и личной встречи! Не будьте наивными! "Разбудите меня через 100 лет и я Вам скажу что в этой стране по-прежнему пьют и воруют" — известный русский писатель.

Copyright: Владимир Карусель, 2015
Свидетельство о публикации №115112704421

Список читателей / Версия для печати / Разместить анонс / Заявить о нарушении

Рецензии

Написать рецензию

100% мошенники. У меня возникла необходимость воспользоваться услугами этих жуликов (тогда я этого не знал). Прочитал много хороших отзывов о "Центре оптимизации бизнеса" их сайт lph.ru. Только сейчас обратил внимание, что большинство сайтов с хорошими отзывами содержит …..lph.ru. В общем, купился на этот развод и перевел крупную сумму и ВСЕ……деньги ушли в никуда. Банк выдал мне справку о поступлении денежных средств на их счет, но бухгалтерия "Центра Оптимизации Бизнеса" отрицает поступление, менеджеры говорят — пишите. На мои письма отвечают - у нас счет заблокирован Ваших денег не видим. Ждем…. Жду уже больше месяца. Развод!!! Избегайте маркетинговых уловок жуликов — lph.ru. !!!

Дмитрий Соколов 42 07.12.2015 15:10 • Заявить о нарушении

Добавить замечания

Написать рецензию Написать личное сообщение Другие произведения автора Владимир Карусель

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

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

Основные обязанности:

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

Требования:

• опыт работы в аналогичной позиции от двух лет;
• отличные знания технических средств визуализации (MS Visio – обязательно);
• навыки управления эффективностью процессов;
• опыт ведения кросс-функциональных проектов;
• знание ERP-систем и процессов управления;
• опыт проведения внутреннего аудита (будет преимуществом).

Вы нам подходите, если вы:

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

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

С чего начать построение бизнес-процессов?

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

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

Общий подход к работе по построению бизнес-процессов компании

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

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

Построение схемы и этапы

Построение можно выполнять по следующему алгоритму:

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

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

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

Преимущества:

• Визуализация с помощью диаграмм;
• Не требует навыков программирования;
• Возможность контроля отслеживать выполнения задач;
• Интеграция с платформой 1С Битрикс
• Назначения ролей;
• Присутствует полна документация по работе с ELMA BPM

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

Преимущества:

• Позволяет сформировать наглядную организационную структуру компании;
• Ведение штатного расписания;
• Возможность моделирования бизнес-процессов;
• Визуализация и контроль системы KPI.

Преимущества:

• Построение любых моделей
• Проверка моделей на жизнеспособность
• Авто-генерация документов
• Точная настройка моделей бизнес-процессов
• Модели можно перевести в код
• Выгрузка модели в графическом виде
• Версия для Mac OS X

Какими качествами должна обладать готовая схема бизнес-процессов?

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

• с какими другими процессами и чем он связан;
• какие операции, кем и в каком порядке выполняются;
• какие документы используются и в каких операциях;

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

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

Зачем нужно построение бизнес-процессов?

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

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

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

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

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

Как построить схему бизнес-процессов?

Этапы составления бизнес-процессов:

1. Установка границ. Обозначение событий, которые является началом и окончанием процесса.
2. Схематичное изображение блоков процесса. Расположение блоков подпроцессов, операций в порядке выполнения.
3. Усложнение схемы. Добавление в нее различных вариантов развития событий и промежуточных операций.
4. Распределение ролей. Для построения бизнес-процесса не требуется вводить в схему конкретные должности или определенных сотрудников — используется понятие роли. Один исполнитель не обязательно выполняет только одну роль.
5. Размещение документов (докладов, сообщений, писем), учет промежуточных продуктов.
6. Уточнение используемых программ, систем и баз данных.
7. Расположение материалов и инструментов, применяемых в бизнес-процессах предприятия.
8. Определение показателей эффективности.
9. Связывание схемы с прочими процессами.
10. Проверка структуры полученной модели.

Результат построения схемы бизнес-процессов

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

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

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

Видео про построение бизнес-процессов

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

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

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

Рисунок 1.2 «Горизонтальное и вертикальное описание бизнес-процессов»

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

Способы описания бизнес-процессов.

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

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

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

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

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

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

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

Рисунок 1.3 «Способы описания бизнес-процессов»

Описание окружения бизнес-процесса.

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

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

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

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

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

Рисунок 1.4 «Схема окружения бизнес-процесса»

Классификация входов и выходов бизнес - процесса.

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

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

Таблица 1.1 - «Характеристики первичных и вторичных входов и выходов бизнес-процесс»

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

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

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

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

Описание бизнес-процессов верхнего уровня.

Классический подход к описанию бизнес-процессов.

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

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

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

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

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

Построение диаграмм потоков данных - DFD

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

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

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

Рисунок 1.5 «Диаграмм потоков данных - DFD»

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

Рисунок 1.6 «Пример несовпадения временной последовательности

работ и направления движения документа»

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

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

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

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

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

Название работы = Действие + Объект на которым действие осуществляется

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

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

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

Название потока = Объект, представляющий поток + Статус объекта

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

Построение сети бизнес-процессов.

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

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

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

Рисунок 1.8 «Разработка сети бизнес-процессов»

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

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

Рисунок 1.9 «Пример сети бизнес-процессов»

Описание бизнес-процессов нижнего уровня.

Декомпозиция бизнес-процесса.

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

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

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

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

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

Построение диаграммы потоков работ - WFD

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

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

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

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

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

Рисунок 1.11 «Диаграмма потоков работ - WFD»

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

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