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

Что называют бизнес-процессом?

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

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

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

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

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

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

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

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

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

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

Вход-процесс-результат бизнес-процесса

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

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

Зачем эти сложности или что дает процессный подход?

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

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

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

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

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

Этап 1. Определение и ограничение бизнес-процесса

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

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

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

Этап 2. Задание точек начала и окончания, основных блоков

Любая схема бизнес-процесса имеет начало и конец. Например, за начало берётся поступившая от клиента заявка, за конечную точку – момент передачи ему готового продукта (доставки).

Далее вычленяются основные этапы обработки бизнес-процесса. Например:

• Регистрация входящей заявки.
• Презентация клиенту подходящего продукта.
• Оформление конкретной заявки.
• Производство продукта (или поиск его на складе) и отправка клиенту.

Этап 3. Детализация схемы бизнес-процесса

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

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

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

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

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

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

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

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

Этап 5. Проверка схемы бизнес-процесса

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

Готовая схема бизнес-процесса может быть с лёгкостью автоматизирована с помощью систем BPM.

Е. Гайдукова

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

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

Александр БУЙВАЛЕНКО

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

Управление бизнес-процессами компании предполагает выполнение (прохождение) основных этапов работ:

• описание бизнес-процессов («как есть»);
• анализ бизнес-процессов («как есть»);
• оптимизация бизнес-процессов («как должно быть»);
• регламентация бизнес-процессов;
• внедрение бизнес-процессов;
• управление бизнес-процессами и их постоянное совершенствование.

На каждом этапе есть свои нюансы и дополнительные шаги.

– это последний этап перехода компании на процессно-ориентированный подход. Он же, самый сложный.

Не каждой компании удается этот путь пройти. Не так все просто, как преподносят на презентациях и конференциях. Рассказывая о легкости и быстроте работы с бизнес-процессами, преуспевают продавцы программного обеспечения (BPM, EPP, CRM, ECM). Особенно, когда речь заходит об автоматизации бизнес-процессов с помощью BPMS-систем. Большинству неудачных попыток работы с бизнес-процессами свойственны типичные ошибки. Они также будут рассмотрены. Не редко звучат фразы: «Нам казалось, все гораздо проще. Я не думал(а), что это будет так долго. Теперь мы понимаем, почему у нас не получилось». Самое простое и надежное решение при самостоятельной работе с бизнес-процессами – сначала разобраться в вопросе, потом приступать к практической реализации. Это сэкономит нервы и время у сотрудников и деньги для компании.

УПРАВЛЕНИЕ БИЗНЕС-ПРОЦЕССАМИ КОМПАНИИ БАЗОВЫЕ ПОНЯТИЯ

Бизнес-процессы компании – это что? У многих понимание этого термина существенно размыто, что приводит к путанице даже в рамках одной компании. Если обратить внимание на сам термин «бизнес-процессы это…», то обнаружится достаточно забавная картина – сколько авторов книг по бизнес-процессам, примерно столько и терминов. С точки зрения маркетинга все понятно – каждый хочет выделиться или внести что-то свое, наиболее важное. Но это сильно усложняет сам термин и вносит сумятицу в головах интересующихся. Итак, что такое бизнес-процессы компании? В данном случае, реально все просто. Любой бизнес-процесс – это определенный участок работы, для которого характерно наличие четырех признаков.

Бизнес-процесс это:

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

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

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

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

• основные процессы;
• вспомогательные процессы;
• процессы управления;
• процессы развития.

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

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

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

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

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

УПРАВЛЕНИЕ БИЗНЕС-ПРОЦЕССАМИ КОМПАНИИ ОПИСАНИЕ БИЗНЕС-ПРОЦЕССОВ

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

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

Итак, как описать бизнес-процесс? Прежде чем начать описание бизнес-процесса, следует:

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

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

Очень часто в компаниях для моделирования бизнес-процессов используют достаточно простую нотацию – межфункциональная блок-схема бизнес-процесса (Cross Functional Flowchart). За простотой кроется множество недостатков.

Пример бизнес-процесса предприятия – БП 1.11.1

Пример бизнес-процесса предприятия – БП 1.7.1

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

Другой крайностью, по сравнению с блок-схемами, можно считать нотацию BPMN. Возможности большие. Многое предусмотрено, с точки зрения отображения нюансов бизнес-процессов компании. Но где речь идет о больших возможностях и гибкости, всегда присутствует простое следствие – сложность освоения. Декларация основателей данной нотации о том, что она учитывает интересы и бизнес-пользователей, и бизнес-аналитиков, и представителей IT-подразделений – мягко говоря, преувеличена. Бизнес-аналитики и представители IT-подразделений освоить ее смогут. А модели бизнес-процессов предназначены только для них? Говорить, что BPMN на сегодняшний день – это основной стандарт описания бизнес-процессов, как минимум, не корректно. Для BPMS-систем, бесспорно. А вот для BPM-систем, уже не факт. И почему после BPMN появились еще нотации? Не так все просто и универсально, как заявляется. Выбор нотации должен осуществляться с учетом целого ряда факторов.

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

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

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

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

УПРАВЛЕНИЕ БИЗНЕС-ПРОЦЕССАМИ КОМПАНИИ РЕГЛАМЕНТАЦИЯ БИЗНЕС-ПРОЦЕССОВ

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

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

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

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

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

Еще более комично выглядят обещания представителей BPM-систем о возможности формирования таких документов, как «Положение о подразделении» и «Должностная инструкция». Документы, которые приходилось видеть, не выдерживают никакой критики. Даже если представить бессмысленное – компания описала все 100% бизнес-процессов. Сформированные на базе BPM-системы документы нельзя назвать ни должностной инструкцией, ни положением о подразделении. Это банальная выборка из функций бизнес-процессов, в которых участвует должность или подразделение. Если на титульном листе написано «Должностная инструкция», «Положение о подразделении» и даже «Регламент бизнес-процесса» – это абсолютно не означает, что содержимое документа соответствует необходимым требованиям. Но если руководитель не понимает, чем должностная инструкция отличается от регламента бизнес-процесса или результат нужен «для галочки», сама идея получения подобных документов «нажатием одной кнопки» будет для него привлекательна.

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

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

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

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

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

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

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

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

Технологический процесс и бизнес-процесс

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

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

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

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

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

Я не единожды читал информацию о том, что нотации бизнес-процессов IDEF0 появилось чуть ли ни в середине XIX века. Более реалистичные авторы пишут о периоде Второй Мировой войны. Но и они ошибаются.
Например, когда я написал статью об 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% действий не несут никакой ценности.
На самом деле, бизнес-процессы бывают разными. Результатом каких-то будет и правда получение прибыли, например, прямые продажи. В других случаях о приобретении ценности и вообще об оценке действий с этой точки зрения говорить сложно. Например, как можно оценить, какую ценность приносит бизнес-процесс отгрузки товара или формирования и отправки налоговой отчетности?
Я считаю, что бизнес-процесс совсем не обязательно приносит какую-то ценность, если понимать ее как непосредственную прибыль компании. Внедрение процессно-ориентированного подхода и реализация бизнес-процессов направлены больше на другое — на сохранность ценности, т.е. получению большей результативности при тех же затратах.
Возможно ли создать идеальный бизнес-процесс — когда следует остановиться?
Нет. Бизнес—процесс должен быть простым, понятным, удобным, читабельным. Но идеальным он не будет никогда.
Когда я начинал работать, мне и самому все время казалось, что я что-то недорабатываю, где-то можно было бы сделать лучше. А нередко и клиенты меня просили детализировать и описать подробнее тот или иной процесс. И я это также считал своим недочетом.
На самом деле, исходя из всего выше описанного, моделирование бизнес-процесса — это некоторое допущение, процесс творческий. С другой стороны, я в свое время не знал даже что ответить на просьбы описать еще «это” и «вон то”. Но со временем я понял, что бизнес-моделирование — это не просто творчество, но некий диалектический процесс. И уже само создание бизнес-процесса всегда будет нести в себе собственное отрицание. Здесь действительно стоит подходить к вопросу с философской точки зрения. И создавая бизнес-процесс, нужно помнить, что мы не можем охватить все и сразу, а потому он всегда будет несовершенен. Но при этом мы уже закладываем в него то, что будем совершенствовать в будущем. Стоит к этому подходить просто как к факту.
Ваш бизнес-процесс должен решать поставленную задачу, отвечать на тот вопрос, который рассматривается в рамках проекта. Все остальное — вопрос будущего возможного сотрудничества. Именно так и стоит пояснять заказчикам, почему вы не детализируете какие-то процессы или не рисуете еще какой-то бизнес-процесс, связанный с обсуждаемым.
Для лучшего понимания тематики рекомендую статьи:

• Разбираемся с понятием BPM. Что такое управление бизнес процессами
• Моделирование бизнеса. Основные подходы
• Знакомство с нотацией IDEF0 и пример использования
• Краткое описание BPMN с примером
• Что такое BPMS
• Использование GAP-анализа для выявления и согласования задач по проекту

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

Шесть этапов совершенствования бизнес-процессов

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

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

2. Анализ. Тщательно изучите бизнес-процесс, который собираетесь усовершенствовать.

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

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

5. Внедрение. Внесите необходимые изменения.

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

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

Что можно было бы сделать?

Помните Пола и его переживания по поводу того, что в компании Pedal Power плохо поставлено обновление информации для электронной рассылки?

Вот что предложил бы ему наш эксперт.

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

Данный текст является ознакомительным фрагментом.
Читать книгу целиком
Поделитесь на страничке