Услуги построения бизнес процессов. Кейс

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

О бизнес-процессах говорят много и часто преимущественно в связи с автоматизацией бизнеса. Использую этот термин и я, в том числе, в своих статьях, посвященных CRM-системам, ERP, работе с BPMN-нотациями, IDEF0 и других инструментов, которые могут понадобиться в работе бизнес-консультанта и внедрении систем автоматизации. При этом в Рунете понятное и развернутое определение термина «бизнес-процесс» я не нашел.

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

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

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

Бизнес-процесс – это логическая последовательность действий человека (или нескольких человек) в коллективе. Цель описания бизнес-процесса – анализ и регламентация тех или иных действий в коллективе.

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

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

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

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

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

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

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

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

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

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

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

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

1. Берем заготовку A;
2. Соединяем ее с заготовкой B;
3. Обрабатываем под параметры C;
4. Получаем деталь.

В бизнес-процессе вполне нормальной считается следующая ситуация:

1. Получаем вводные данные A:
   • Если данные соответствуют условию B, переходим на последовательность действий C;
   • Если данные соответствуют условию D, выполняем действия E.
2. Полученный результат передается на выход.

История появления термина

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

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

На самом деле описание бизнес-процессов и нотации BPMN появились в 70-е годы XX века, когда повсеместно начали использоваться информационные системы. И сам термин, и нотации понадобились изначально именно для разработки информационный систем.

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

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

Первые методологически проработанные нотации бизнес-процессов (а я буду говорить именно о методологически проработанных нотациях, например, IDEF3***) появились у военных в США. Причина очевидна – уже тогда военные в США пользовались автоматизацией с использованием удаленных соединений, т.е. той самой системой, которая позже стала Интернетом. И при таком уровне применения информационных систем потребность в нотациях бизнес-процессов была особенно актуальной.

***По теме методологически проработанных нотаций хочу также сказать пару слов. Почему я привел в качестве примера IDEF3: я еще не видел более проработанной методологически системы описания бизнес-процессов. Даже BPMN 2.0 все еще развивается и дорабатывается. А если вы почитаете англоязычное описание IDEF3 (перевода на русский я пока не видел), то также сумеете оценить по достоинству глубину его проработки.

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

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

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

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

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

Зачем моделировать (описывать) бизнес-процессы

Моделирование бизнес-процессов помогает решить сразу две задачи:

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

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

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

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

Как описывать бизнес-процессы

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

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

1. Собираем участников процесса (сотрудников);
2. Собираем входящую информацию, необходимую и достаточную для запуска процесса;
3. Собираем используемые системы. Это может быть учетная система,CRM, электронная почта, таблицы Excel и т.д. Все, что реально используется в работе, необходимо зафиксировать.
4. Определяем ожидаемый результат – что будет в конце процесса.
5. Собираем последовательность действий, которые выполняет человек.
6. Вычленяем условия. В зависимости от разных входящих данных и промежуточных результатов действия могут быть разными.
7. Описываем всю собранную информацию в графическом виде в удобной нотации (IDEF3, BPMN 2.0 и т.д.).

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

• Законченность. Бизнес-процесс должен четко отвечать на вопрос, стоящий перед ним. Если мы говорим о процессе продажи определенного товара или услуги, то бизнес-процесс должен полностью описывать действия, необходимые для получения указанного результата, и завершающегося именно таким результатом (с определенными допущениями, о которых я говорил выше).
• Лаконичность. Бизнес-процесс должен сочетать в себе достаточность, т.е. описывать все необходимые этапы и действия, при этом быть максимально лаконичным для простоты восприятия. Лично я вывел для себя «правило 15 минут» - если за этот период времени я могу объяснить руководству компании представленный бизнес-процесс, значит, его можно показывать заказчику. Получается быстрее – прекрасно, требует больше времени и слов – надо подумать, что можно сократить и упростить.
  Я когда-то лично видел графическое описание бизнес-процесса, выполненное на листе 2 метров длиной (и соответствующей шириной). Его даже просто рассмотреть и понять, куда ведет какая стрелка крайне сложно. А как его пояснять заказчику, я лично не представляю.
  Помните, что человек воспринимает зрительно определенный объем информации, ограниченный, в том числе, определенным размером листа или экрана (это связано с особенностями зрения), а также числом элементов (возможности мозга также ограничены). Простой и лаконичный бизнес-процесс заказчик поймет, просто «охватив» схему взглядом. Сложный и перенасыщенный деталями придется изучать не один час просто для того, чтобы понять, что там отображено. Скорей всего, руководитель компании, который не является экспертом в работе отдельных подразделений, а также ограничен по количеству свободного времени, просто не будет изучать столь сложную конструкцию и не поймет сути даже самых выгодных предложений.
• Использование общепризнанных нотаций. Не стоит изобретать собственные обозначения и правила. Используйте нотации, которыми пользуются во всем мире. Я видел в книгах некоторых отечественных авторов попытки создания собственной системы обозначений. И, честно говоря, так и не понял, зачем они усложняют жизнь и себе, и своим читателям. Здесь как с языком – вы можете придумать свой особый язык, но понимать его никто, кроме вас, не будет. А если он окажется похож на существующие, то может еще и путаница появиться. Либо вас сочтут безграмотным, так как вы не по правилам известных языков используете пунктуацию, склоняете слова и т.д. Так и с нотациями – есть уже устоявшиеся, известные людям и, что также немаловажно, интуитивно понятные нотации. Они потому и стали популярны, что в процессе их создания и доработок постоянно тестировались на простоту, однозначность и удобство. Если вы будете использовать готовые нотации, вас будут понимать, воспринимать, как эксперта, да и сами правила нотаций уберегут вас от логических ошибок. Я лично рекомендую IDEF3 и BPMN 2.0.
• Все участники бизнес-процесса должны быть учтены и прямо указаны. И делать это необходимо без использования сносок с нумерациями, комментариях в объектах Swimm line (специальные сноски) и т.д. Этим нередко «грешат» любители создавать собственные конструкции вместо использования готовых нотаций. Где-то у них названия не помещаются, где-то им кажется, что длинное название в теле бизнес-процесса будет неудобным. В результате либо приходится искать в сносках, о ком именно идет речь, либо создатели таких бизнес-процессов просто забывают указать кого-то из участников.
• Понятное потребителю описание. Самое главное – ваш потребитель, тот, кто будет читать эту нотацию, должен быстро и, в идеале, даже без ваших пояснений понимать описание бизнес-процесс.

Распространенные мифы и заблуждения

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

Я не рекомендую так поступать. Во-первых, при использовании готовых инструментов вам не потребуется изобретать свои обозначения и стандарты. Все давно придумано до вас. При этом стандартные нотации действительно понятны интуитивно, читаются однозначно, известны многим людям. Во-вторых, в готовых системах (IDEF3, BPMN 2.0 и пр.) имеется проработанная методология и строгие ограничения. Их можно воспринимать как язык программирования и среду для работы с этим языком. Здесь вы просто не сумеете совершить многих ошибок, от этого вас уберегут стандарты синтаксиса и сама среда (ограничения в редакторе, автоматические проверки).

Не путайте описания бизнес-процессы компании и бизнес-процессы IT систем.

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

Распространенная ошибка: Бизнес-процесс обязательно приносит ценность (прибыль).

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

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

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

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

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

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

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

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

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

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

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

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

- собираемся с ответственным за процесс и основными участниками/ экспертами (до 3 человек);
- определяем границы процесса, участников, входы/ выходы, этапы процесса – блоки, на которые разбиваем процесс и результаты этих этапов;
- договариваемся и в итоге рисуем такую схему процесса:

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

В описании мы используем обозначения:

В результате схема процесса (этапа) выглядит так:

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

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

Мы описываем процесс так:

1. Организуем рабочее совещание участников процесса и экспертов;

2. Готовим «клейкую стену» , карточки формата A5, маркеры;

3. Определяем модератора, который ведет дискуссию, пишет и клеит карточки на стену;

4. Размечаем горизонтальные строки малярным скотчем;

5. Определяем участников процесса, записываем на карточках и клеим слева на стене в соответствующих строках;

6. Определяем (подтверждаем) вход/ выход процесса (желтые карточки);

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

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

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

10. Фотографируем и отдаем на оцифровку.

В итоге получаем схему в MS Visio, как на предыдущем рисунке.

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

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

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

Личная информация:

Консультировал в области регулярного менеджмента более 70-ти компаний: от 10 до 9.000 человек (включая: холдинги, сети магазинов, фабрики, сервисные компании, строителей, государственных служащих, веб-агентства, интернет-магазины). Ученик Александра Фридмана.

Один из соавторов книги "Социальные технологии Таллиннской школы менеджеров. Опыт успешного использования в бизнесе, менеджменте и частной жизни": http://www.ozon.ru/context/detail/id/140084653/

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

Конфуций

кому: собственникам, топ-менеджерам, руководителям

Управление процессами через регламенты приводит к управлению «рукой через ногу»

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

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

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

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

Процесс (синоним “бизнес-процесс”) - это последовательность действий для решения какой-либо типовой задачи (нетиповые задачи относятся к проектам).

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

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

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

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

Почему регламентов недостаточно

• Далеко не все процессы линейные. Многие имеют множество условий “если…, то…”. Сложно быстро разобраться в “полотенце” текста регламента и понять, как этапы процесса связаны между собой . Например, регламент по подбору сотрудников изобилует подобными развилками почти на каждом этапе. В зависимости от должности соискателя собеседование может проходить удалённо или очно, с привлечением его непосредственного руководителя или без.
• Если процесс проходит через несколько звеньев, возникает проблема “кто ответственен за конечный результат”. В случае сбоев и косяков, сотрудники валят вину друг на друга и на обстоятельства, возникает круговая порука.
• Сотрудники не могут договориться между собой о том, кто выполняет какую работу.
• Из-за низкой наглядности (всё тот же гигантский объём текста регламента) крайне непросто заниматься оптимизацией и развитием процесса .
• Значительны затраты времени сотрудников на чтение, изучение, и понимание общей картины и всех взаимосвязей. Регламент редко описывает процесс целиком. Зачастую процессу, проходящему через несколько отделов, соответствуют разные регламенты.

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

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

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

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

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

Всем этим критериям, по моему мнению, отвечает нотация BPMN (версия 2.0) . Для отрисовки схем рекомендую использовать бесплатную программу Bizagi Modeler .

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

Итого, схемы процессов решают следующие задачи:

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

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

Ключевая фишка процессного управления - ответственный за весь процесс

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

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

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

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

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

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

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

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

Алгоритм описания и развития бизнес-процесса с помощью схем и регламентов

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

Этап 1. Нарисовать и согласовать схему процесса

1. Начертите схему процесса совместно с ответственным за развитие процесса и экспертами из числа ответственных за исполнение конкретных копий процесса. Выделите наиболее критичные точки процесса. У каждого процесса и у каждого этапа на схеме есть “вход” и есть “выход”. При написании регламента учтите, что будет подаваться на вход, а что будет результатом работы.
2. Согласуйте схему со всеми участниками процесса или начальниками подразделений участников.

Пример №1. Схема процесса “Подбор сотрудников” в нотации BPMN

Пример №2. Часть схемы “Подбор сотрудников” в нотации BPMN

Этап 2. Написать регламент выполнения этапов процесса

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

Пример описания в регламенте одного из этапов схемы процесса

Этап 3. Запустить управление процессом

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

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

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

Этап 4. Развивайте и оптимизируйте процесс с целью роста эффективности и качества

Как я уже упоминал, за развитие процесса должен отвечать его “владелец” (обращаю внимание, что это не из разряда “хочу/не хочу”, а почётная обязанность сотрудника).

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

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

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

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

Заключение, или Почему «всё и сразу» - это путь на кладбище проектов

Про процессы можно рассказывать много, хватит на целую книгу. Но… кладбища мёртвых проектов заполнены попытками внедрить “всё и сразу” и на самом дорогом и/или многофункциональном программном обеспечении. В лучшем случае сотрудники не использовали внедрённые технологии, или системы получались настолько громоздкими, что работать с ними было невозможно. В худшем - сложности при внедрении так и не позволили завершить работу до конца.

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

Читавшие эту статью, также читали

Время «Ч»: Когда внедрение регулярного менеджмента в вашей компании неизбежно, а оттягивание старта лишь принесёт дополнительные убытки

Сайт производителя товаров и оборудования: 10 типовых ошибок, которые препятствуют поиску новых дилеров и оптовиков

2.3. Корневая модель бизнес-процессов и ее использование

Рис. 2.3.1. Направления использования корневой модели бизнес-процессов

С чего надо начинать описание бизнес-процессов? Практика сформировала три подхода, или два варианта ответа на этот вопрос (рис. 2.3.2).

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

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

Вариант 3. Описывать итерационно снизу (детально) – вверх (агрегированно), а потом наоборот.

Реализация подхода «описываем сверху – от корневой модели БП» позволяет попутно решить следующие задачи и удовлетворить связанные с ними требования:

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

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

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

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

Системно перейти к более детальным описаниям.

Рис. 2.3.2. Как описать бизнес-процессы?

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

Полезный для расширения восприятия комментарий. Финансовые потоки и их модели используются при «финансовой оцифровке» процессов, при построении операционных бюджетов компании. Система операционных бюджетов компании представляет собой оцифрованные основные процессы деятельности, а свод операционных бюджетов в финансовые (бюджет доходов и расходов (БДР), бюджет по балансовому листу (ББЛ), бюджет движения денежных средств (БДДС) позволяет строить стандартные финансовые отчеты (рис. 2.3.3). Поэтому бюджетирование часто начинается с построения корневой модели БП.

Рис. 2.3.3. Схема «финансовой оцифровки» бизнес-процессов

2.4. Иллюстрации направлений использования корневой модели бизнес-процессов

Рис. 2.4.1. Направления использования модели процессов верхнего уровня

Корневая модель БП может играть роль «запускающего описания» для составления классификатора процессов.

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

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

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

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

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

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

Таким образом, в зависимости от конечной цели специалисты применяют различные приемы работы с бизнес-процессами (рис. 2.4.2).

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

2.5. Примеры корневых моделей бизнес-процессов

Рис. 2.5.1. Пример модели основных бизнес-процессов производственной компании

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

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

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

Рис. 2.5.2. Пример типовой модели основных и поддерживающих бизнес-процессов производственно-торговой компании

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

Рынок, исследование рынка (маркетинг).

Проектирование продукции, товаров, услуг.

Планирование и организация производства.

Планирование и организация снабжения заданных объемов производства.

Производство продуктов (услуг).

Сбыт продукции.

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

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

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

Модель производственно-торговой компании (см. рис. 2.5.2). К основным процессам в другой часто упоминаемой модели относятся следующие БП:

Маркетинг;

Разработка продуктов и услуг;

Производство продукции;

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

Осуществление продаж и управление обслуживанием клиентов.

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

К поддерживающим процессам в этой модели отнесены:

Совершенствование деятельности (по-другому это можно назвать бизнес-инжинирингом);

Управление защитой окружающей среды;

Управление внешними связями;

Управление финансами;

Управление корпоративными службами;

Управление персоналом;

Управление инфраструктурой компании;

Управление юридическими услугами;

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

Снабжение;

Разработка и сопровождение систем (технологий).

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

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

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

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

Модель дистрибьюторской компании. Модель (см. рис. 2.5.3) включает семь основных БП и шесть поддерживающих (в предыдущей модели было пять и одиннадцать). К основным БП относятся:

Разработка стратегии;

Бизнес-планирование, т. е. уточнение стратегии и детальное планирование деятельности компании;

Организация вывода продукции (услуг) на рынок;

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

Послепродажный сервис клиента;

Бизнес-мониторинг обеспечивающей деятельности.

К поддерживающим БП в модели относятся:

Управление человеческими ресурсами;

Управление финансовыми ресурсами;

ИТ-поддержка;

Обеспечение безопасности;

Управление улучшениями и изменениями (то, что в предыдущей модели называлось «совершенствование деятельности компании», или «бизнес-инжиниринг»);

Прочие сопровождающие и офисные БП.

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

Модельосновных бизнес-процессов строительных и инжиниринговых компаний (рис. 2.5.4 и 2.5.5). Если говорить об универсальных приемах построения бизнес-моделей, то некоторые приемы можно продемонстрировать на примере строительных и инжиниринговых компаний.

Корневая модель БП включает два блока (соответственно рис. 2.5.4 и 2.5.5). Один блок – это основные процессы. Они определяются исходя из анализа и описания основных этапов создания объектов в разных отраслях. Это этапы создания объектов в инжиниринге и строительстве (слой процессов на нис. 2.5.4):

Концептуальный инжиниринг (инвестиционное структурирование и инвестирование);

Создание объекта;

Эксплуатация объекта;

Изменение, развитие или утилизация объекта.

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

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

А вот рассмотрение предыдущих моделей (рис. 2.5.2–2.5.3) в части поддерживающих БП можно использовать для подготовки шаблона или опорного решения поддерживающих процессов и для строительных или инжиниринговых компаний. Вариант такого блока поддерживающих процессов приведен на рис. 2.5.4.

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

1. Сфера управления компанией в целом.

2. Сфера развития.

3. Сфера основной деятельности.

4. Сфера поддерживающей деятельности.

Пример построения и использования модели процессов верхнего уровня энергетической компании приведен в следующих темах настоящего Навигатора (см. элемент 10.3.6).

Рис. 2.5.5. Сферы деятельности энергетической компании (пример)

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

В общих чертах подход к построению корневой модели БП может быть задан следующим образом (рис. 2.5.7):

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

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

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

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

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

Рис. 2.5.7. Как подготовиться к описанию бизнес-процессов компании

2.6. Пример. Схема моделирования бизнес-процесса «снизу»

Рис. 2.6.1. Пример последовательности моделирования бизнес-процесса

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

В рассматриваемом примере алгоритм моделирования предполагает следующие действия.

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

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

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

Описание структуры потоков в БП. Если речь идет о создании информационной системы – это поток информации и документооборот. Если же речь идет, например, о применении ERP-системы (планирование распределения ресурсов), то это может быть поток материальных ресурсов. Все определяется точкой зрения разработчика и целями описания БП.

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

Наряду с построением диаграмм потоков предполагается и построение алгоритма БП , т. е. логика исполнения функций и логические условия, которые определяют эту логику исполнения функций. Все это фиксируется в виде алгоритма исполнения процесса.

Рис. 2.6.2. Пошаговое моделирование бизнес-процесса (шаги 1 и 2)

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

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

Схемы пошагового моделирования бизнес-процесса.

Какие работы необходимо выполнять? – Шаг 1 (рис. 2.6.2). На этом шаге необходимо задать состав действий, составить их классификатор, согласовать наименования действий и сгруппировать их на основе иерархического классификатора.

Каков порядок (последовательность) выполнения? Этот следующий естественный шаг (шаг 2) сфокусирован на определении порядка и последовательности выполнения действия. Если действия заданы, то надо зафиксировать последовательность их исполнения. Результатом этого этапа является построение блок-схемы выполнения действий (см. рис. 2.6.2).

Что является результатом каждого действия? Какие ресурсы для этого необходимы? Если работы заданы, если задана последовательность исполнения действий, то надлежит конкретизировать, уточнить входы и выходы каждого действия (рис. 2.6.3, шаг 3).

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

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

Рис. 2.6.3. Пошаговое моделирование бизнес-процесса (шаги 3 и 4)

Кто какие работы выполняет? Кто за что отвечает? Можно считать, что модель БП отражает агрегированное, систематизированное знание о порядке исполнения действий основными его исполнителями. Поэтому на данном шаге внимание фокусируется на определении исполнителей отдельных действий (см. рис. 2.6.4, шаг 5). Здесь определяется, кто исполняет действия, кто за что отвечает.

На стыках между действием 1 и действием 2 возникает промежуточный результат.

Согласование результата, точек зрения на указанный результат подразделениями 1 и 2 – это и есть главный смысл предыдущего этапа согласования внутренних продуктов и услуг БП и горизонтальной ответственности за их исполнение.

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

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

Самое раннее упоминание методики встречается в рукописях экономиста Адама Смита, вышедших в печать в 1776 году. Специалист описал случай распределения сложной процедуры создания штифтов на контактном заводе. В итоге благодаря разделению сложных задач между сотрудниками, производительность увеличилась на 24 000%. Смит отстаивал пользу разумного упрощения сложных процедур. Уровень распределения определялся в этом случае экспериментально через проектирование БП. Идея Смита получила широкое признание.

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

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

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

Простая схема реализации БП

Запрос клиента > Оператор Call-центра (фиксация заявки)> Менеджер (обработка запроса > Логист (движение, доставка, перевозка материалов) > Бухгалтер (расчет расходов, формирование счета) > Производство > ОТК (проверка качества) > Реализация

Классификация бизнес-процессов зависит от коммерческих целей разделения. Различают несколько категорий БП:

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

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

1. Анализ деятельности объекта.
2. Тестирование действующих БП.
3. Распределение активных процессов по группам.
4. Корректировка рабочих цепочек.
5. Распределение задач между персоналом.
6. Внедрение систем контроля и управления БП.

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

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

Разрыв в процессе - потерянные деньги

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

Управление БП с помощью компьютерных технологий

Достижения последних десятилетий в сфере IT скорректировали привычные процессы. Если в середине XIX века программное обеспечение имело ограниченные ресурсы для администрирования деятельности предприятий, то сегодня это мощные системы, дающие серьезные перспективы для максимально эффективной автоматизации БП: SAP, Oracle, PeopleSoft и прочие. Теперь бизнес-процесс это специальные протоколы и веб-язык, модели коммерческой мотивации для конструирования, коррекции и управлению бизнесом или графические изображения для визуального отображения блок-схем, диаграмм и многое другое.

Анализ и автоматизация активных рабочих моделей

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

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

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

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

Алгоритм методики складывается из трех задач:

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

Оптимизация бизнес-процессов включает в себя 5 этапов:

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

Цель оптимизации по Джеймсу Харрингтону по-своему радикальна. Она заключается в кардинальной перестройке организации, а не серии постепенных реструктуризаций. Такая модель была описана в книге Майкла Хаммера и Джеймса Чампи «Реинжиниринг корпорации: манифест бизнес-революции», выпущенной в 1993 году. Многие предприятия решаются применить систему, другие отказываются от радикальной методики в угоду более лояльным, к действующей модели, процедурам. Однако и те и другие считают оптимизацию БП ценным инструментом для увеличения эффективности.