Вопросы управления бизнес-процессами остро встают в компании, когда на определенном этапе ее развития сбои во взаимодействии подразделений, менеджеров, сотрудников начинают носить регулярный характер, оказывая при этом существенное влияние на эффективность деятельности самой организации. Сбои сопровождаются не только потерей информации, дублированием функций, лишними затратами и другими негативными последствиями, но и потерей качества продуктов предприятия, а значит, и потерей лояльности потребителей. Диагностировать причины этих проблем без детального изучения деятельности компании невозможно.
В основе управления бизнес-процессами лежат работы по их описанию, оптимизации и регламентации, и такого рода проекты затрагивают интересы широкого круга сотрудников, требования которых существенно различаются в зависимости от их роли в компании. Топ-мененджеры заинтересованы в повышении управляемости, гарантированности управленческих воздействий, прозрачности и т.д. (понимая под этим индикаторы, по которым можно определять, насколько успешна деятельность компании, и инструменты воздействия на персонал). Менеджеры среднего звена прежде всего хотят понимать границы своей деятельности и результаты, за которые они отвечают. Наконец, исполнителям нужны понятные, четкие правила работы. При реализации проекта необходимо учитывать интересы всех этих групп сотрудников. Приступая к подобного рода проектам, компании зачастую пытаются остановиться лишь на верхнем уровне анализа и оптимизации, экономя тем самым время проекта и удовлетворяя интерес высшего руководства. Но нужно понимать, что верхнеуровневый анализ хорош лишь для целей бизнес-диагностики, то есть выработки решений и рекомендаций относительно того, куда продвигаться и развивать проект далее (каковы наиболее проблемные области и что теоретически с ними можно сделать).
Вообще говоря, для того чтобы именно улучшить деятельность, а не закончить одними только лозунгами (или, как в последнее время их стало модно называть, принципами), в проекте мы вынуждены доходить до уровня исполнителей и их действий (упрощенно уровни детализации бизнес-процессов приведены на рис. 1).
Описание, моделирование и регламентация
Основа анализа деятельности — существующий бизнес-процесс. И для того чтобы увидеть ход его протекания, нам необходима модель (схема) данного процесса «как есть». Если не удастся получить эту схему, анализировать будет нечего. И чем точнее вы опишете существующий процесс на уровне исполнителей, тем лучше сможете проанализировать его «узкие места».
Единственное, что хотелось бы еще отметить: помните, качество моделирования и описания схем очень слабо зависят от выбранной вами нотации описания (как бы вам ни внушали обратное). Даже в самой простейшей нотации вы сможете сформировать качественную для анализа модель, главное — знать правила и требования к моделированию. Никакие сверхмодные нотации не гарантируют качество описания бизнес-процессов, а нередко, наоборот, они только препятствуют тому, чтобы модель была понята персоналом (исполнителями), и превращают простую и понятную работу в проекте в некое искусство «для избранных». Тогда как моделирование и анализ процессов — это вполне понятная технология, носителями которой должны быть не «третьи лица» (внешние консультанты или бизнес-инженеры), а обычные руководители компании всех уровней. Ведь это именно их задача — организовать деятельность вверенных им подразделений и персонала. Инструментом для этого и служит описание бизнес-процессов и их анализ. И чем проще такой инструмент — тем лучше.
Вместе с тем сам по себе анализ не может улучшить деятельность и повысить эффективность системы управления, поэтому следующим шагом должна стать продуманная и взвешенная модель бизнес-процесса «как должно быть». То есть модель, которая позволяет избежать проблемных мест в анализируемом бизнес-процессе, значительно не ухудшая при этом другие его характеристики или другие процессы. Ведь решения никогда не бывают однозначными по оптимальности, и улучшая процесс в одном месте, вы практически гарантированно будете ухудшать его в другом. Поэтому оптимизация — это всегда компромисс, который определяется условиями (внешними и внутренними) и ограничениями конкретной компании.
Следовательно, как бы нам того ни хотелось, оптимизируя процессы на детальном уровне, никогда нельзя брать процессы от других предприятий и пытаться применить их к себе «один в один». Это не означает, что при оптимизации деятельности нужно отмахиваться от лучших практик, существующих на рынке, — эти практики необходимо изучать, оценивать достоинства и недостатки, анализировать возможность их трансформации для собственных нужд. Но не более. Оптимизация — это поиск решения, которое даст наибольший эффект в данной конкретной компании, с ее особенностями, возможностями и существующими на момент анализа ограничениями. Зачастую поиск такого решения — это анализ накопленного опыта (не только своего, но и других компаний). Но именно анализ, а не копирование!
Таким образом, мы должны получить модели «как должно быть», и чем больше процессов мы охватим, тем более сможем улучшить свою деятельность. Отметим только, что сами по себе модели процессов эффективность управления компанией не повысят. Новыми моделями деятельности вы фактически изменяете правила работы персонала, и эти новые правила вы должны до персонала довести, но для этого нужны не схемы, а регламенты. И такие регламенты необходимо разработать. Именно регламенты и внедренные на их основе новые правила выполнения работы — таков значимый результат проекта по описанию и оптимизации бизнес-процессов. Причем важно понимать, что в подобного рода проектах принцип Парето (80/20) не работает, здесь действует совершенно другой принцип: «нельзя перепрыгнуть через пропасть на 99%».
Для каких предприятий актуально управление бизнес-процессами?
Во-первых, здесь важно, на каком этапе (стадии) развития находится компания. Для небольшой компании, с размытой группой потребителей, нежесткими процессами деятельности (стадия «личного энтузиазма» по Ларри Грейнеру), основным конкурентным преимуществом выступает гибкость и оперативность. Для таких предприятий (как правило, с одним-тремя десятками сотрудников в зависимости от отрасли) проекты управления бизнес-процессами противопоказаны, так как жесткие схемы процессов, регламенты и проч. «убивают» преимущество гибкости и оперативности.
Но по мере роста компании гибкость и оперативность могут превратиться в хаос, когда все что‑то делают, куда‑то бегут, а результат получают, как в басне «Лебедь, рак и щука». Управлять хаосом очень сложно, поэтому на следующем этапе своего развития компания переходит к регулярному менеджементу, когда начинает формироваться централизованная система управления (что очень важно для концентрации усилий и контроля ресурсов), явно формируются и приобретают смысл бизнес-процессы, поскольку на первый план выходят проблемы взаимодействия множества (а не десятка) сотрудников. Начиная с этой стадии развития имеет смысл говорить об управлении процессами.
Второй важный момент: описанию, регламентации подлежат только те процессы, которые сформировались и устойчиво повторяются. Для компании с большой вариативностью процессов необходимо не регламентировать, а скорее моделировать процессы, тестировать разные варианты и выбирать оптимальный — это другие подходы и проекты.
Наконец, третий аспект — характер деятельности предприятия. Управление с помощью описания и регламентации бизнес-процессов эффективно далеко не для каждого вида деятельности. Например, если основной бизнес компании по сути проектный (строительные предприятия, производители, специализирующиеся на позаказном производстве, и пр.), то управление такой деятельностью через бизнес-процессы неэффективно, что уже многократно доказано на практике. Деятельность по проекту определяется его планом, бюджетом, рамками, сроками и т. д., но не регламентами бизнес-процессов, и здесь нужны совершенно иные инструменты управления.
Управление процессами, именно как повторяемыми алгоритмами деятельности, оптимально для предприятий (или направлений деятельности) с повторяющимися, устойчивыми бизнес-процессами — производителей серийной продукции, ритейловых компаний и пр. Собственно процессное управление — это своего рода «автопилот», обеспечивающий ежедневную работу предприятия.
Чтобы проиллюстрировать эти различия, рассмотрим деятельность с точки зрения двух простейших факторов: «простота деятельности» и «повторяемость деятельности» (рис. 2). Мы получим четыре основных типа деятельности, а именно:
a)простая и новая (неповторяющаяся) деятельность (квадрант 1);
b)простая повторяющаяся деятельность (то есть деятельность, которая устойчиво повторяется субъектом по четко установленному алгоритму) — квадрант 2;
c)сложная и новая (неповторяющаяся) деятельность (квадрант 3);
d)сложная повторяющаяся деятельность (квадрант 4).
Применение такой простой типологии приводит к очевидным выводам, на которые почему‑то очень часто не обращают внимания. Деятельность предприятий неоднородна, и значит, в зависимости от её типа мы должны применять и различные технологии управления. В противном случае мы можем не получить желаемого и ожидаемого эффекта от управленческих воздействий и решений и рискуем управлять тем или иным видом деятельности правильным с точки зрения теории, но неэффективным с точки зрения практики способом.
Для того чтобы потом не вспоминать с горечью поговорку: «Хотели как лучше, а получилось как всегда», — необходимо четко сознавать, каким типом деятельности в данный момент мы управляем, что исследуем, оптимизируем, регламентируем и т. д. И для этого нам потребуются не очень красивые, но простые и однозначные определения. Итак, часть деятельности называется:
- задача — если это однократно выполняемая работа одного исполнителя за короткое время (т. е. каждое новое задание выполняется одним сотрудником, каждый раз по новым или меняющимся правилам);
- функция — если это регулярная работа одного исполнителя, выполняемая по известным ему правилам (т. е. каждое новое задание выполняется одним сотрудником, но всегда по установленным, повторяющимся, известным ему правилам);
- проект — если это однократно выполняемая работа многих исполнителей за длительное время (т. е. каждое новое задание выполняется многими сотрудниками, каждый раз по заново сформулированным правилам и алгоритмам);
- процесс — регулярно выполняемая работа многих исполнителей по четко зафиксированным правилам и алгоритмам.
Из всего этого следует, что, например, делать основной упор на систему управления бизнес-процессами для компании, в которой преобладает проектная деятельность или задачи, — не имеет смысла. Ведь в данном случае процессная система будет управлять тем, чего в компании почти нет, или тем, что слабо влияет на качество конечного продукта. И наоборот, бессмысленно внедрять системы управления проектами в «процессной» компании: это приведет к увеличению затрат и внесет в деятельность еще больше проблем и сложностей.
Подготовка и реализация проектов управления бизнес-процессами
Говоря об особенностях проектов по описанию и оптимизации бизнес-процессов, нельзя не затронуть вопрос выделения бизнес-процессов в компании. Вообще само выделение бизнес-процессов должно быть направлено на удовлетворение тех потребностей, о которых мы говорили выше. Процесс всегда должен приводить к измеряемому и значимому для всей компании результату. И с этой точки зрения процессы выделяются не по границам бизнес-подразделений, а по продукту/результату, т. е. бизнес-процесс — это полный цикл действий по доведению до клиента, внутреннего или внешнего, некоего продукта.
При этом, как мы отметили раньше, этапы реализации подобных проектов таковы.
1.Моделирование процессов «как есть».
2.Моделирование процессов «как должно быть».
3.Разработка регламентов процессов.
4.Внедрение изменений.
Желательно эти этапы не пропускать и не переставлять. Потому что писать регламенты без схем невозможно, а моделировать «как должно быть», не видя «как есть», — значит с большой вероятностью оптимизировать процессы, которые ты себе представляешь, но, как правило, не те, которые на самом деле существуют. Отдельно необходимо сказать и о роли консультантов в таких проектах. Самое неэффективное, чем они могут заниматься, — это описывать процессы клиента.
И неэффективно это не потому, что они не умеют их описывать. Проблема в том, что данная технология, как уже упоминалось, — это технология управления, предназначенная для руководителей компании. То есть руководители должны получить соответствующие компетенции, знания и навыки. Кроме того, стоит вспомнить, что основная задача таких проектов — внедрение новых правил. А практика и опыт показывают, что проще всего внедряются те решения, которые были выработаны либо самими руководителями (менеджерами процессов), либо при их очень активном участии. Поэтому основная задача консультантов в подобного рода проектах состоит не в том, чтобы за кого‑то описывать процессы (тем более что для этого требуется очень много времени — ведь важно не только проанкетировать персонал, как это привыкли делать в консалтинговых компаниях, а нужно пойти на производство и разобраться, как осуществляется деятельность), а в том, чтобы научить контролировать, сопровождать и моделировать. То есть дать руководителям компании необходимые знания (обучение) и навыки (помощь в практике) для реализации проекта, иными словами — передать компетенцию по технологиям описания, оптимизации и регламентации бизнес-процессов и пройти вместе с проектной командой весь этот путь хотя бы один раз, на примере нескольких базовых процессов предприятия. Дальше специалисты компании работают сами, «под присмотром» консультанта. В таком случае и проект получается дешевле, и компания прирастает новыми компетенциями.
Еще одна особенность проекта связана с организацией общего управления процессом. Если руководствоваться парадигмой, что процесс выделяется не по подразделению, а по продукту, то кто тогда может им управлять? Давать указания исполнителям, которые административно подчиняются руководителям разных подразделений? Все эти руководители находятся в прямом подчинении только у первых лиц компании, которые и выступают «владельцами» процесса. Но топ-менеджерам (владельцам процессов) оперативной деятельностью заниматься нецелесообразно, так как у них свои задачи и функции, поэтому по каждому процессу назначают менеджера, которому делегируются полномочия по управлению этим процессом. Как правило, это руководитель среднего звена, который несет ответственность за достижение конечного результата того или иного процесса. Например, для процесса отгрузки — руководитель отдела продаж, для процесса бюджетирования — руководитель планово‑экономического отдела и т. д. В таком случае, скажем, бухгалтер, участвующий в процессе отгрузки на его завершающем этапе, должен следовать указаниям менеджера процесса, которому напрямую не подчиняется. В результате формируется матричная структура управления с типичными проблемными вопросами.
И решить эти вопросы можно только таким образом, чтобы все схемы, модели процессов, процедуры, степень загрузки и квалификация исполнителей были согласованы со всеми административными руководителями, сотрудники которых в этом процессе участвуют.
Андрей Борисов
Старший консультант компании TopS BI (группа «Систематика»)
