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

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

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

Кейс. Как описать бизнес-процессы самому?

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

Шаг 1.

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

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

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

Рис. 1. Системный оператор.

1. НАСТОЯЩЕЕ.

1.1 Исследуемая система: бизнес-процессы.

Система бизнес процессов, особое внимание сквозным бизнес-процессам (затрагивающим работу 2 и более отделов или групп). Гибкость процессов.

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

1.2. Надсистема.

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

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

1.3. Подсистемы.

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

2. ПРОШЛОЕ 30-е гг. 20 века.

2.1. Система.

Человек на рабочем месте, инструкции руководителей (именно «инструкции»).

Одной из самых известных методологий описания организаций как организационно-технических систем, стала методология структурного анализа и проектирования систем SADT (Structured Analysis and Design Technique) . Она была разработана американцем Дугласом Россом (D. Ross) в 1973 г. Особенно широкое применение получило одно из подмножеств SADT — методология функционального моделирования IDEF0 (Integration Definition For Function Modeling). Инициатором ее разработки и дальнейшей стандартизации было Министерство обороны США. Методология IDEF0 успешно применялась в военных, коммерческих организациях для решения широкого спектра задач (от разработки программного обеспечения для оборонных систем до разработки систем материально-технического снабжения и управления финансами). Наличие возможностей и опыт применения IDEF0 в различных предметных сферах, наряду с растущей компьютерной поддержкой, сделало ее еще более доступной в использовании. Это, в свою очередь, также привело к широкому использованию IDEF0 как методологии для описания бизнес-процессов организаций. Во многом популярность методологии функционального моделирования IDEF0 обусловлена простотой нотации, основными элементами которой являются функциональный блок и стрелка.

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

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

3.2. Надсистема.

3.3. Подсистемы.

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

4. БУДУЩЕЕ.

4.1. Система.

Гибкие карты бизнес-процесса, интегрированные в CRM-системы и системы более высокого уровня (ERP-системы).

4.2. Надсистема.

Саморазвивающийся бизнес (компания), дальнейшее развитие LEAN , CRM-система, ERP-системы с интеграцией , .

4.3. Подсистемы.

Мгновенный доступ к самообновляющейся информации. Гибкая система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, автоматическая отчетность по показателям, гибкое управление эффективностью процессов. Автоматизация, роботизация, система развития компетенций, knowledge management .

Шаг 2.

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

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

1. Что потеряли из прошлого (а это интересно и эффективно)?
2. Что изменится в перспективе? Что можно оставить без изменений, а в каких аспектах нужно заложить фундамент уже сейчас?
3. На что седует обратить внимание при разаработке алгоритма описания бизнес-процессов?

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

1. Подсистемы: Быстрый доступ к информации. Система бизнес процессов (модель), управление ответственностью, управление персоналом, регламентация процессов, отчетность персонала, автоматизация процессов, управление эффективностью процессов. Мы видим, что бизнес-процессы должны иметь возможность быстро извлекаться из информационной среды, иметь высокую гибкость, иметь реперные точки, которые покажут, что изменится в надсистеме при изменении бизнес-процесса на уровне конкретной должности.
2. Стратегический менеджмент, система сбалансированных показателей. Бережливое производство, система менеджмента качества. Рынок, конкуренция… Относительная стабильность, постепенная, плавная смена обстановки (существенное отличие от НС «Настоящее» ).Действующее законодательство. При проектировании бизнес-процессов должна быть разработана система показателей: KPI (ключевые показатели эффективности) и управленческие индикаторы, по которым мы отслеживаем эффективность достижения KPI. Будущее показывает нам, что бизнес-процессы должны быть включены с систему управления знаниями, то есть должна быть разработана система показателей, завязанная на модель компетенций. Предусмотреть здесь отсутствие разрыва! Автоматическому сбору статистики по показателям следует уделить особое внимание, развивать культуру работы с цифрами, постепенно подготавливая систему управления к применению методов машинного обучения в будущем.

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

1. Учесть, что чувство времени у людей хоть и развилось со времен А.К. Гастева, но все же далеко от идеала, поэтому бизнес-процессы должны быть автоматизированы в CRM-системе с функцией автоматического уведомления, но в любом случае, перед тем как готовить ТЗ для CRM, куда в конечном итоге попадет описание БП, создается бумажный документ. Важно учесть, что пытаться все подряд регламентировать глупо, а в небольших компаниях такое внимание к администрированию чревато потерей бизнеса. Поэтому перед регламентацией процессов следует определить положение компании на S-кривой (удобнее всего по И. Адизесу) и исходя из этого назначить «масштаб» регламентации, то есть определить степень детализации процесса. Также важно определить степень свободы принятия решения сотрудника в изменении бизнес-процессов с целью повышения их эффективности. Как было указано выше, предусмотреть возможность оперативного изменения процесса, но с простановкой маркеров, какие из смежных процессов будут невольно затронуты. Следует предусмотреть разграничение прав доступа по изменению процессов.

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

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

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

1. При описании БП следует учесть взаимодействие между подразделениями. Именно на стыке отделов происходит наибольший дефект коммуникаций, искажение информации и различного рода сбои. Рекомендации - см. выше. Дополнительно: при определении профиля личности место не рассматривать изолировано, а посмотреть в связке с подразделениями и владельцами процессов, с которыми бизнес-процессы переплетены наиболее тесно. Задачу решать на уровне мест, в свойства материала не уходить (см. рекомендации по схематизации)!

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

Шаг 3.

Когда мы брались за эту задачу, то уже тогда понимали, что одни и те же рекомендации не могут применяться для компаний на разных этапах своего развития. Поэтому на данном шаге мы решили посмотреть, как меняется найденная нами концепция решения в зависимости от ее положения компании на S-кривой . Наилучшим образом этапы развития компании описывает S-образная кривая в концепции И. Адизеса (рис. 2):

Рис. 2. Стадии развития компании по И. Адизесу.

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

• Цели деятельности;
• Системное описание бизнес-процессов (функциональной бизнес-модели бизнеса);
• Организационная структура предприятия;
• Должностные инструкции сотрудников;
• Системы управленческой отчетности;
• Регламенты деятельности (стандартизации);
• Процедуры управления стандартами;
• Механизмы контроля исполнения стандартов на предприятии.

Теперь мы можем описать требования к БП на каждом этапе развития компании в соответствии с выбранными критериями.

1. ухаживание:

Цели: во главе стоит идея и интуиция. Бизнеса как такового еще нет, но есть огромное желание реализоваться.

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

Организационная структура: отсутствует.

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

Отчетность: отсутствует. Руководитель не нуждается в отчетности, так как сам “полностью в теме”, а также отсутствует наработанная статистика. Работа в компании не организована должным образом, чтобы учитывать результаты для формирования отчетности.

Регламенты: отсутствуют.

Управление стандартами: отсутствуют.

Отсутствуют.

2. младенчество:

Цели: начинает зарождаться целеполагание, но оно строится не по методике SMART (SMART - это аббревиатура методики целеполагания и постановки задач. Расшифровка S.M.A.R.T.: Specific (цель должна быть конкретна), Measurable (измерима), Achievable (достижима), Relevant (быть релевантной, т.е. соответствовать деятельности и потребностям предприятия, уместной), Timed (определена во времени).

У руководителя не хватает навыка постановки целей и не достаточно рыночной информации, чтобы конкретизировать их. Цели звучат как лозунги: “быть №1 (или просто лучшими) в отрасли (нише)”, “занять максимальную часть рынка”, “стать лидером на рынке”, “добиться максимальной прибыли” и т.д. и т.п.

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

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

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

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

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

Управление стандартами: отсутствует.

Контроль исполнения стандартов: отсутствует.

3. Давай-давай:

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

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

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

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

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

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

Регламенты: руководители начинают ощущать потребность в создании регламентов деятельности и приступают создавать мини-инструкции, например, как правильно принять заявку клиента, упаковать продукт или построить разговор с клиентом (скрипты переговоров). Инструкции создаются интуитивно, носят характер затыкания “дырок” в работе (локальная стандартизация). Методика регламентации отсутствует.

Управление стандартами: регламенты не проходят в компании процедуры согласования и утверждения, спускаются “сверху” персоналу. Часто воспринимаются сотрудниками как дополнительная нагрузка и вызывают негодования по поводу того, что зачем это все нужно и так “все работают на все 100% и, не покладая рук”. Руководитель проводит стихийные обучения по мере выявления “косяков”. Считает, что сотрудники и так все должны сами знать и понимать самостоятельно.

Контроль исполнения стандартов: отсутствует.

4. юность:

Цели: цели на предприятии определяются в терминах SMART.

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

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

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

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

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

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

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

Контроль исполнения стандартов: с увеличение количества регламентов возникает потребность в регулярном контроле их исполнения (аудите).

5. Расцвет:

Цели: цели на предприятии определяются в терминах SMART с применением системы сбалансированных показателей (финансы, маркетинг, процессы, развитие персонала).

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

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

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

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

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

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

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

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

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

Контроль исполнения стандартов: контроль исполнения начинает проводится в форме аудита в масштабе всей компании. Процесс контроля регламентирован.

6. Стабильность:

Цели: цели на предприятии определены в терминах SMART с применением системы сбалансированных показателей, создана система показателей эффективности деятельности компании. Цели и показатели каскадированы до каждой должности.

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

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

Должностные инструкции: корректируются и улучшаются с целью повышения качества работы персонала.

Отчетность: регулярно корректируется и дополняется создающими ценность показателями и аналитикой.

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

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

Контроль исполнения стандартов: ведется регулярное проведение аудитов.

7. Аристократия:

Цели: цели перестают пересматриваться и актуализироваться.

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

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

Должностные инструкции: перестают корректироваться с целью повышения качества работы персонала.

Отчетность: не корректируется и не дополняется создающими ценность показателями и аналитикой.

Регламенты: снижение активности компании в области стандартизации. Владение методикой теряется как навык. Бизнес-процессы и система автоматизации устаревает.

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

Контроль исполнения стандартов: качество проведения аудитов не контролируется.

8. охота на ведьм:

Цели: цели устарели, не актуальны.

Бизнес-процессы: потеря актуальности.

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

Должностные инструкции: перестают быть актуальными.

Отчетность: перестает быть актуальной.

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

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

Контроль исполнения стандартов: аудиты отменены.

9. Бюрократия:

Цели: цели устарели, не актуальны.

Бизнес-процессы: полная потеря актуальности и структуры бизнес-процессов.

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

Должностные инструкции: устарели, либо создаются без ориентации на бизнес-модель.

Отчетность: потеря актуальности, бесконтрольное сокращение объема отчетной информации. Уход работы “в тень”.

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

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

Контроль исполнения стандартов: отсутствует.

Шаг 4.

Это инструментальный шаг (берите и делайте).

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

При этом учтите следующее:

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

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

1. Определить положение компании на S-кривой;
2. Исходя из п.1, сформулировать цели описания БП, поставить акценты;
3. Сформулировать название процесса;
4. Провести работу над видением и целью БП;
5. Определить границы процесса (начало и конец);
6. Определить входы (ресурс) и выходы (результат) процесса в целом;
7. Назначить владельца процесса;
8. Определить состав и последовательность выполнения работ (создать цикл );
9. Определить действия , границы, входы и выходы каждого этапа;
10. Определить сроки каждого этапа;
11. Определить ответственных за каждый этап;
12. Оформить процесс документально (подготовить Стандарт).

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

Таблица 1. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (что должно входить в состав описания БП на различных этапах развития компании):

Сокращения:

Бизнес-процессы (БП)

Организационная структура (Орг.)

Должностные инструкции (ДИ)

Отчетность (Отч.)

Регламенты (Р)

Управление стандартами (Упр. ст.)

Контроль исполнения стандартов (КИС)

Таблица 2. Рекомендации по описанию бизнес-процесса в зависимости от положения компании на S-образной кривой (кто должен прописывать БП):

Сокращения:

“-” отсутствует;

К — команда;

Ко — консультант (эксперт).

Литература:

1. Как преодолеть кризисы менеджмента. Диагностика и решение управленческих проблем / Ицхак Калдерон Адизес — М.: Манн, Иванов и Фербер, 2014.
2. Найти идею: Ведение в ТРИЗ - теорию решения изобретательских задач / Генрих Альтшуллер - 3-е изд. - М.: Альпина Паблишерз, 2010.

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

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

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

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

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

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

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

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

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

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. Проверка структуры полученной модели.

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

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

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

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

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

Инструкция

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

Описать бизнес-процесс можно несколькими способами. Наиболее популярный из них - графический, с помощью , выполненных в различных нотациях (нотация - набор символов для обозначения чего-либо).
Самые распространенные виды нотаций для описания бизнес-процессов - это IDEF0, BPMN, EPC (ARIS) и др.
В качестве примера остановимся на диаграмме, выполненной в нотации BPMN (Business Process Modelling Notation) с помощью CASE-средства PowerDesigner (Рис.1). Главными элементами на диаграмме являются:
1. «Процесс» (функция) - скругленный по углам прямоугольник;
2. «Переход» - стрелка, соединяющая процессы;
3. «Решение» - ромб, содержащий вопрос, на который можно ответить только «Да» или «Нет»;
4. Условия - текстовые выражения, при которых осуществляется переход от функции к другой. Условия всегда заключаются в квадратные скобки. Иногда полезно разбить вашу на «Дорожки» - вертикальные или горизонтальные секции, обозначающие подразделения предприятия или сотрудников, ответственных за выполнение определенной функции. В таком случае этой функции должен находиться в пределах своей секции. Кроме перечисленных элементов, может содержать также перечень данных, которые являются входными или выходными для процесса, а также ссылки на правила или регламент, согласно которым выполняется та или иная функция. Пример описания бизнес-процесса «Контроль производства изделия» показан на рис.1. Нетрудно заметить, что эта диаграмма очень похожа на блок-схему алгоритма решения задачи.

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

Полезный совет

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

Источники:

• М.Рыбаков. Оптимизация бизнес-процессов.
• как составить бизнес процесс

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

Инструкция

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

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

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

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

2. Организационная концепция

Организационная концепция включает пять элементов:

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

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

1. Клиенты процесса.
2. Цели процесса.
3. Результаты процесса.
4. Ресурсы процесса.
5. Поставщики процесса.
6. Исполнители процесса.
7. Владелец процесса.
8. Показатели процесса.
9. Содержание (краткое описание) процесса.
10. Состав процесса (перечень процессов нижележащего уровня).

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

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

3. Организационная структура

Главное назначение организационной структуры – обслуживание бизнес-процессов.

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

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

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

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

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

4. Идентификайция процессов

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

1. Название процесса

2. Краткое описание процесса

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

3. Клиент процесса

Клиенты процесса – это лица или организации, получающие выгоду от выполнения процесса, пользующиеся его результатами.

4. Цели процесса

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

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

Таким образом, необходимо определить цели всех заинтересованных сторон в процессе.

5. Результат процесса

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

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

6. Показатели процесса

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

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

Такая последовательность шагов позволяет прийти к правильным показателям процесса.

7. Ресурсы процесса

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

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

8. Поставщики процесса

9. Исполнители процесса

10. Владелец процесса

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

5. Описание должностных обязанностей сотрудников

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

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

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

6. Определение состава компетенций специалистов

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

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

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

Нам будут нужны первая и вторая колонка этой таблицы. Вместо остальных колонок добавим три новые: «Знания», «Навыки», «Личные качества». Таким образом, у нас есть список процессов, в которых участвует сотрудник, краткое описание этих процессов и три колонки, которые нужно заполнить, последовательно рассматривая каждый процесс.

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

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

7. Определение профиля должности

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

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

Документ «Профиль должности» имеет следующую структуру:

• Общие знания,
• Предметные знания,
• Навыки,
• Личные качества,
• Ценности,
• Функциональные обязанности,
• Области ответственности.

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

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

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

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

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

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

Неохваченными в рамках статьи остались следующие задачи:

• Определение показателей деятельности (KPI).
• Установление правил вознаграждения за результат.

Этим вопросам посвящен вебинар «Как разработать систему KPI. Применение показателей деятельности для мотивации сотрудников».

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

Партнерский материал.