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

Четкая, продуманная и понятная схема — ценный результат, к которому нужно стремиться, создавая бизнес-процессы компании. Построение, выполненное по всем правилам, должно давать представление о следующих вещах:. Качественная схема всегда является информативной, простой для восприятия. Она дает представление, как процесс выполняется в реальных условиях. У вас есть вопросы? Тогда можете задать их нашим специалистам. С чего начать построение бизнес-процессов? Общий подход к работе по построению бизнес-процессов компании Построение схемы процессов бизнеса Моделирование бизнес-процессов Какими качествами должна обладать готовая схема бизнес-процессов?

Зачем нужно построение бизнес-процессов? Результат построения схемы Видео С чего начать построение бизнес-процессов? Схема создания бизнес-процессов компании. Автоматизация бизнес-процессов Оптимизация… Разработка схемы бизнес процесса организации Описание и оптимизация бизнес процессов компании Построение системы бизнес процессов Структура управления бизнесом Организационная… Построение и разработка моделей бизнес процессов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Идеальным вариантом является случай когда название работы формулируется при помощи слов. В крайнем случае нужно стремится использовать в названии не более 50 символов.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Для улучшения управляемости Процесса целесообразно разбить его на сеть бизнес-процессов. За выполнение каждого бизнес-процесса, также должен быть назначен ответственный из сотрудников подразделения. Пример такого разбиения приведен на Рис. Пример распределения и закрепления ответственности в матричной форме на Рис. В каждой строчке Матрицы может быть только одна буква О. То есть, за каждую работу может быть назначен только один ответственный. Букв У и И может быть несколько, или не быть вообще, но, как правило, Хозяин Процесса должен участвовать или получать информацию обо всех бизнес-процессах.

Ответственность, закрепленная в Матрице, должна быть внесена в Должностную инструкцию данного сотрудника. Из Матрицы на Рис. В реальном бизнесе Процессный подход в чистом виде встречается очень редко. Фактически он представляет из себя матричный способ управления, когда процесс пронизывает несколько функциональных подразделений и имеет Хозяина например, руководителя проекта , который не является начальником этих подразделений.

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

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

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

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

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

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

В настоящее время существует множество методологий описания процессов, классификации и группировок процессов внутри предприятия. На мой взгляд, одна из наиболее полных предложена Международной Бенчмаркинговой Палатой International Benchmarking Clearinghouse.

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

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

Иванова "Система качества ориентированная на процессы по материалам немецких изданий по проблемам качества " - Материалы конференции "TQM" Пермь. В ней приведены примеры построения "Обзорной карты процессов" и приведена методология разграничения процессов и определения "стыков".

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

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

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

Разбиение деятельности предприятия на отдельные процессы целесообразно вести с наложением процессов на структуру предприятия. Для небольшого предприятия с предельно малым количеством процессов, при проведении интервью руководителей подразделений и служб были сформулированы следующие процессы:. После минимизации и, явно напрашивающемся объединении процессов 1 и 2, 4 и 6, а также 9 и 10, получаем ту же карту, но с меньшим количеством процессов. Такое объединение процессов, заявленных первоначально как "совершенно разные и очень важные", становится возможным потому, что в терминологии ISO термин "продукция" относится не только к выпускаемой продукции или услугам, но и к перерабатываемым материалам.

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

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

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

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

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

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

Пример: В одной организации при описании сети бизнес-процессов в нотации . В ней приведены примеры построения "Обзорной карты процессов" и. 17 февр. г. - Читать работу online по теме: 3.Построение сети бизнес-процессов(теория). ВУЗ: УИЭУиП. Предмет: [НЕСОРТИРОВАННОЕ]. Размер. Поэтому для построения адекватной модели бизнес-процессов (а также для . Полученная сеть бизнес-процессов является моделью организации.

Найдено :

Случайные запросы