Практически, 90% руководителей совершенно не задумываются о бизнес-процессах. И это вполне естественно. Как естественно не задумываться о процессах, происходящих внутри нас самих — в организме. Процессы происходят постоянно. Вне зависимости от нашего осознания.
В бизнесе так же безостановочно происходят самые разные процессы: процессы маркетинга и продаж, производственные процессы, процессы закупки и логистики, а также другие. Чем крупнее бизнес, тем большее количество процессов происходит в единицу времени.
В предыдущей статье мы оценили выгоды, которые получает компания и ее сотрудники от формализации и внедрения бизнес-процессов. Почему же руководитель может позволить себе не думать о процессах? По причине банального недостатка знаний. Как часто ваши руководители проходят обучение? И как часто это обучение касается освоения бизнес-процессов?
Боюсь, ваши ответы будут не в пользу высокой квалификации руководителей.
Чтобы устранить данный пробел я пишу цикл статей о бизнес-процессах и записал сразу два видео-курса: 1) экспресс-курс «Процессный подход к управлению» и 2) методический курс из 4 частей «Как создать систему на основе бизнес-процессов». Вы можете бесплатно подписаться на методический курс с условием выполнения всех практических кейсов курса.
Карта бизнес-процесса as-is
Управление бизнес-процессами: принципы и компромиссы
Вопросы управления бизнес-процессами остро встают в компании, когда на определенном этапе ее развития сбои во взаимодействии подразделений, менеджеров, сотрудников начинают носить регулярный характер, при этом оказывая существенное влияние на эффективность деятельности самой организации. Сбои сопровождаются не только потерей информации, дублированием функций, лишними затратами и другими негативными последствиями, но и потерей качества продуктов компании, а значит и потерей лояльности потребителей. Диагностировать причины этих проблем без детального изучения деятельности компании невозможно.
В основе управления бизнес-процессами лежат работы по их описанию, оптимизации и регламентации, и такого рода проекты затрагивают интересы широкого круга сотрудников, требования которых существенно различаются, в зависимости от их роли в компании. Топ-мененджеры заинтересованы в повышении управляемости, гарантированности управленческих воздействий, прозрачности и т.д. (понимая под этим индикаторы, по которым можно определять, насколько успешна деятельность компании, и инструменты воздействия на персонал). Менеджеры среднего звена хотят, прежде всего, понимать границы своей деятельности и результаты, за которые они отвечают. Наконец, исполнители хотят иметь понятные, четкие правила своей работы. При реализации проекта необходимо учитывать интересы всех этих групп сотрудников.
Зачастую, приступая к подобного рода проектам, компании пытаются остановиться лишь на верхнем уровне анализа и оптимизации, экономя тем самым время проекта и удовлетворяя интерес высшего руководства. Но нужно понимать, что верхнеуровневый анализ хорош лишь для целей бизнес-диагностики, то есть выработки решений и рекомендаций относительно того, куда продвигаться и развивать проект далее (какие области наиболее проблемные и что теоретически с ними можно сделать). Вообще говоря, для того чтобы мы именно улучшили деятельность, а не закончили одними только лозунгами (или, как последнее время их стало модно называть,– принципами), мы вынуждены в проекте доходить до уровня исполнителей и их действий (упрощенно уровни детализации бизнес-процессов приведены на рис.1).
Моделирование бизнес процессов: гайд от начала до конца
Рис 1. Уровни детализации бизнес-процессов:
- Операция – минимальная для анализа часть деятельности отдельного сотрудника, выполняемая им «автоматически», без проведения осознанного контроля.
- Действие – несколько последовательно выполняемых операций, после реализации которых исполнитель осуществляет осознанный контроль (выделяя операции и действия, необходимо ориентироваться не на уровень начинающего работника, а на уровень профессионала).
- Процедура – несколько последовательно выполняемых действий, осуществляемых конкретным исполнителем. У процедуры должен быть результат: документ, продукт или недокументированная информация (устное сообщение, электронное письмо, факс…), в зависимости от процесса.
- Бизнес-процесс базового уровня – последовательность взаимосвязанных процедур, выполняемых различными исполнителями и приводящая к получению законченного и значимого результата для организации. Например, заключенный договор, акт сдачи-приемки, товар на складе и т.п.
- Направление деятельности – укрупненная часть деятельности организации, состоящая из одной или нескольких групп бизнес-процессов базового уровня.
Описание, моделирование и регламентация
Основа анализа деятельности – существующий бизнес-процесс. И для того чтобы увидеть ход его протекания, нам необходима модель (схема) данного процесса «как есть». Если не удастся получить эту схему, анализировать будет нечего. И чем точнее вы опишете существующий процесс на уровне исполнителей, тем качественнее сможете проанализировать его «узкие места».
Единственное, что хотелось бы еще отметить: помните, качество моделирования и описания схем очень слабо зависят от выбранной вами нотации описания (как бы вам ни внушали обратное). Даже в самой простейшей нотации вы сможете сформировать качественную для анализа модель, главное – знать правила и требования к моделированию.
Никакие сверхмодные нотации не гарантируют качество описания бизнес-процессов, а нередко, наоборот, только ухудшают понимание моделей персоналом (исполнителями) и превращают простую и понятную работу в проекте в некое искусство «для избранных». Тогда как моделирование и анализ процессов – это вполне понятная технология, носителями которой должны быть не «третьи лица» (внешние консультанты или бизнес-инженеры), а обычные руководители компании всех уровней. Ведь это именно их задача – организовывать деятельность вверенных им подразделений и персонала. Инструментом для этого и служит описание бизнес-процессов и их анализ. И чем проще такой инструмент – тем лучше.
Вместе с тем, сам по себе анализ не может улучшить деятельность и повысить эффективность системы управления, поэтому следующим шагом должна стать продуманная и взвешенная модель бизнес-процесса «как должно быть». То есть модель, которая позволяет избежать проблемных мест в анализируемом бизнес-процессе, при этом значительно не ухудшая другие его характеристики или другие процессы.
Ведь решения по оптимальности никогда не бывают однозначными, и, улучшая процесс в одном месте, вы практически гарантировано будете его ухудшать в другом. Поэтому оптимизация – это всегда компромисс, который определяется условиями (внешними и внутренними) и ограничениями конкретной организации.
Следовательно, как бы нам того ни хотелось, оптимизируя процессы на детальном уровне, никогда нельзя брать процессы с других предприятий и пытаться их применить к себе «один в один». Это не означает, что при оптимизации деятельности нужно «отмахиваться» от лучших практик, существующих на рынке, – эти практики необходимо изучать, оценивать достоинства и недостатки, анализировать возможность их трансформации для собственных нужд.
Но не более. Оптимизация – это поиск решения, которое даст наибольший эффект в данной конкретной компании, с ее особенностями, возможностями и существующими на момент анализа ограничениями. Зачастую поиск такого решения – это анализ накопленного опыта (не только своего, но и других компаний). Но именно АНАЛИЗ, а НЕ КОПИРОВАНИЕ!
Таким образом, мы должны получить модели «как должно быть», и чем большее количество процессов мы охватываем, тем более качественно сможем улучшить свою деятельность. Отметим только, что сами по себе модели процессов эффективность управления компанией не повысят.
Новыми моделями деятельности вы фактически изменяете правила работы персонала, и эти новые правила вы должны до персонала довести, но для этого нужны не схемы, а регламенты. И такие регламенты необходимо разработать. Именно регламенты и внедренные на их основе новые правила выполнения работы персоналом – значимый результат проекта по описанию и оптимизации бизнес-процессов. Причем важно понимать, что в подобного рода проектах принцип Парето (80/20) не работает, здесь действует совершенно другой принцип: «невозможно перепрыгнуть пропасть на 99%».
Для каких предприятий актуально управление бизнес-процессами?
Первое, что необходимо отметить – важно, на каком этапе (стадии) развития находится компания. Для небольшой компании, с размытой группой потребителей, нежесткими процессами деятельности (стадия «личного энтузиазма» по Ларри Э. Грейнеру) основным конкурентным преимуществом выступает гибкость и оперативность. Для таких компаний (как правило, с одним — тремя десятками сотрудников, в зависимости от отрасли) проекты управления бизнес-процессами противопоказаны, так как жесткие схемы процессов, регламенты и пр. «убивают» преимущество гибкости и оперативности.
Но по мере роста компании, гибкость и оперативность могут превратиться в хаос, когда все что-то делают, куда-то бегут, но получают результат из серии «лебедь, рак и щука». Управлять хаосом очень сложно, поэтому на следующем этапе своего развития компания переходит к регулярному менеджементу, когда начинает формироваться централизованная система управления (что очень важно для концентрации усилий и контроля ресурсов), явно формируются и приобретают смысл бизнес-процессы, т.к. на первый план выходят проблемы взаимодействия множества (а не десятка) сотрудников. Начиная с этой стадии развития, имеет смысл говорить об управлении процессами.
Второй важный момент: описанию, регламентации подлежат только те процессы, которые сформировались и устойчиво повторяются. Для компании с большой вариативностью процессов необходимо не регламентировать, а, скорее, моделировать процессы, тестировать разные варианты и выбирать оптимальный – это другие подходы и проекты.
Наконец, третий аспект – характер деятельности предприятия. Управление с помощью описания и регламентации бизнес-процессов эффективно далеко не для каждого вида деятельности.
Например, если основной бизнес компании по сути проектный (строительные предприятия, производители, специализирующиеся на позаказном производстве, и пр.) – управление такой деятельностью через бизнес-процессы неэффективно, что уже многократно доказано на практике. Деятельность по проекту определяется его ПЛАНОМ, бюджетом, рамками, сроками и т.д., но не регламентами бизнес-процессов, и здесь нужны совершенно иные инструменты управления. Управление процессами, именно как повторяемыми алгоритмами деятельности, оптимально для предприятий (или направлений деятельности) с повторяющимися, устойчивыми бизнес-процессами, – для производителей серийной продукции, ритейловых компаний и пр. Собственно процессное управление – это своего рода «автопилот», обеспечивающий ежедневную работу компании.
Чтобы проиллюстрировать эти различия, рассмотрим деятельность с точки зрения двух простейших факторов: «простота деятельности» и «повторяемость деятельности» (рис. 2). Мы получим четыре основных типа деятельности, а именно:
a) простая и новая (неповторяющаяся) деятельность (квадрант 1);
b) простая и повторяющаяся деятельность (то есть деятельность, которая устойчиво повторяется субъектом по четко установленному алгоритму) – квадрант 2;
c) сложная и новая (неповторяющаяся) деятельность (квадрант 3);
d) сложная повторяющаяся деятельность (квадрант 4).
Рис 2. Анализ типов деятельности предприятий.
Применение такой простой типологии приводит к очевидным выводам, на которые почему-то очень часто не обращают внимание. Деятельность неоднородна. Значит, в зависимости от типа деятельности мы должны применять и различные технологии управления. В противном случае мы можем не получить желаемого и ожидаемого эффекта от управленческих воздействий и решений и рискуем управлять тем или иным видом деятельности правильным с точки зрения теории, но неэффективным с точки зрения практики способом.
Для того чтобы потом с горечью не вспоминать поговорку: «Хотели как лучше – получилось как всегда», — необходимо четко осознавать, каким типом деятельности в данный момент мы управляем…, исследуем, оптимизируем, регламентируем и т.д. И для этого нам потребуются не очень красивые, но зато простые и однозначные определения. Итак, часть деятельности называется:
Задача– если это однократно выполняемая работа одного исполнителя за короткое время (т.е. каждое новое задание выполняется одним сотрудником, каждый раз по новым или меняющимся правилам);
Функция – если это регулярная работа одного исполнителя, выполняемая по известным ему правилам (т.е.. каждое новое задание выполняется одним сотрудником, но всегда по установленным, повторяющимся, известным ему правилам);
Проект– если это однократно выполняемая работа многих исполнителей за длительное время (т.е. каждое новое задание выполняется многими сотрудниками, каждый раз по заново сформулированным правилам и алгоритмам);
Процесс– это регулярно выполняемая работа многих исполнителей по четко зафиксированным правилам и алгоритмам.
Из всего этого следует, что, например, делать основной упор на систему управления бизнес-процессами для компании, в которой преобладает проектная деятельность или задачи – не имеет смысла. Так как в данном случае процессная система будет управлять тем, чего в компании почти нет, или тем, что слабо влияет на качество конечного продукта(ов). И наоборот, бессмысленно внедрять системы управления проектами в «процессной» компании: это приведет к увеличению затрат и внесет в деятельность еще больше проблем и сложностей.
Особенности подготовки и реализации проектов управления бизнес-процессами
Говоря об особенностях реализации проектов по описанию и оптимизации бизнес-процессов, нельзя не затронуть вопрос выделения бизнес-процессов в компании. Вообще, само выделение бизнес-процессов должно быть направлено на удовлетворение тех потребностей, о которых мы говорили выше. Процесс всегда должен приводить к измеряемому и значимому для всей компании результату. И с этой точки зрения процессы выделяются не по границам бизнес-подразделений, а по продуктурезультату, т.е. бизнес-процесс – это полный цикл действий по доведению до клиента, внутреннего или внешнего, некоего продукта. При этом, как мы отметили раньше, этапы реализации подобных проектов следующие:
Моделирование процессов «как есть».
Моделирование процессов «как должно быть».
Разработка регламентов процессов.
Внедрение изменений.
Желательно эти этапы не пропускать и переставлять. Потому что писать регламенты без схем невозможно, а моделировать «как должно быть», не видя «как есть», – значит, с большой вероятностью, оптимизировать процессы, которые ты себе представляешь, но, как правило, не те, которые на самом деле существуют.
Отдельно необходимо сказать и о роли консультантов в таких проектах. Самое неэффективное, чем они могут заниматься – это описывать процессы клиента. И неэффективно это не потому, что они не умеют их описывать. Проблема в том, что данная технология, как уже упоминалось, – это технология управления, предназначенная для руководителей компании.
То есть руководители должны получить соответствующие компетенции, знания и навыки. Кроме того, стоит вспомнить, что основанная задача таких проектов – внедрение новых правил. А практика и опыт показывают, что проще всего внедряются те решения, которые были выработаны либо самими руководителями (менеджерами процессов), либо при их очень активном участии.
Поэтому основанная задача консультантов в подобного рода проектах состоит не в том, чтобы описывать за кого-то процессы (тем более что для этого требуется очень много времени: важно не только проанкетировать персонал, как это привыкли делать в консалтинговых компаниях, а пойти на производство и разобраться в том, как осуществляется деятельность), а в том, чтобы научить, помогать, контролировать, сопровождать, модерировать. То есть дать руководителям компании необходимые знания (обучение) и навыки (помощь в практике) для реализации проекта, иными словами – передать компетенцию по технологиям описания, оптимизации и регламентации бизнес-процессов и пройти вместе с командой проекта весь путь описания бизнес-процессов хотя бы раз, на примере нескольких базовых процессов предприятия. Дальше специалисты компании работают сами, под «присмотром» консультанта. В таком случае и проект получается дешевле, и компания прирастает новыми компетенциями.
Еще одна особенность проекта связана с организацией общего управления процессом. Если руководствоваться парадигмой, что процесс выделяется не по подразделению, а по продукту, то кто тогда может им управлять? Давать указания исполнителям, которые административно подчиняются руководителям разных подразделений?
Все эти руководители – в прямом подчинении только у первых лиц компании, которые и выступают «владельцами» процесса. Но топ-менеджерам (владельцам процессов) оперативной деятельностью заниматься нецелесообразно, так как у них свои задачи и функции, поэтому по каждому процессу назначают менеджера, которому делегируются полномочия по управлению этим процессом.
Как правило, это руководитель среднего звена, который несет ответственность за достижение конечного результата процесса. Например, для процесса отгрузки – руководитель отдела продаж, для процесса бюджетирования – руководитель планово-экономического отдела и т.д. В таком случае, скажем, бухгалтер, участвующий в процессе отгрузки на его завершающем этапе, должен следовать указаниям менеджера процесса, которому напрямую не подчиняется. В результате формируется матричная структура управления, с типичными проблемными вопросами. И решить эти вопросы можно только тем, что все схемы, модели процессов, процедуры, степень загрузки и квалификация исполнителей будут согласованы со всеми административными руководителями, сотрудники которых в этом процессе участвуют.
Intelligent Enterprise № 18, 2008
- Задать вопрос эксперту
- Написать сообщение
Источник: www.topsbi.ru
Описание и оптимизация бизнес-процессов компании
Михаил Гордеев, директор по технологиям ЗАО «Евроменеджмент» Андрей Борисов, эксперт направления «Регламентация деятельности и описание бизнес-процессов» «Невской консалтинговой компании» Наталья Коршак, руководитель направления «Регламентация деятельности и описание бизнес-процессов» «Невской консалтинговой компании» Источник: http://www.e-xecutive.ru
При внесении изменений в деятельность компании руководитель вынужден балансировать между двумя крайностями. С одной стороны, есть опасность сломать непродуманным решением налаженные и описанные бизнес-процессы компании. С другой стороны, есть желание повысить эффективность максимальным образом, то есть разрушить все «до основанья, а затем…» построить что-то кардинально новое. Именно на второй парадигме основывался активно пропагандируемый ещё несколько лет назад реинжиниринг бизнес-процессов.
В учебниках по описанию бизнес-процессов приводились замечательные примеры многократного улучшения эффективности деятельности крупных международных компаний. Например, как IBM в разы ускорило процесс рассмотрения заявки на предоставление персональных компьютеров в кредит.
Члены правления корпорации IBM заинтересовались, почему средний срок рассмотрения заявки на предоставление кредита для приобретения персонального компьютера составляет чуть ли не полтора месяца. За это время большинство потребителей успевают приобрести такую «мелочь» (одну-две тысячи долларов) где-либо еще. Чтобы проверить описанный бизнес-процесс компании, члены правления решили провести эксперимент: тут же на заседании заполнили по заявке и попросили отнестись к этим документам со всем вниманием. Разумеется, на следующий день они получили уведомление о предоставлении кредита. «Значит, умеем, когда надо», — решили члены правления и распорядились провести в компании описание и анализ бизнес-процессов.
В результате они узнали, что каждую заявку проверяет несколько отделов, каждый из которых рассматривает определенный ее аспект (кредитную историю, задолженности, имущество и т. п.). Причем, согласно утверждённому описанию, бизнес-процесс рассмотрения каждым отделом компании осуществляется последовательно.
Новые заявки поступают в очередной отдел, эксперт проводит анализ и делает определенные выводы: «Все ясно, можно предоставить компьютер в кредит. Все ясно, нужно отказать. Так, интересный случай, надо разобраться…» И пока он рассматривает одну заявку, со всеми остальными, в том числе и с теми, решение по которым уже было принято, никто не работает, они просто лежат у него в кабинете. И в каждом отделе описанный выше бизнес-процесс повторяется!
Решение, принятое членами совета директоров компании, было простым по сути и реинжиниринговым по реализации. Каждый отдел сформулировал ряд четких критериев, по которым можно было четко понять, что необходимо сделать с каждой заявкой: предоставлять компьютер в кредит, отказать или же провести более детальный анализ. Затем специалисты компании описали новый бизнес-процесс и разработали многотерминальную экспертную систему, за терминалы посадили операционисток (естественно, обучив их по специально разработанной программе). В результате бизнес-процесс стал таким: заявка поступает к операционистке, которая вводит данные в экспертную систему, определяющую — предоставить компьютер в кредит; отказать на следующих основаниях (текст отказа прилагается); направить заявку на дальнейшее рассмотрение в следующие отделы (перечень отделов).
В итоге выполнения описанного бизнес-процесса в течение нескольких дней клиентам компании сообщали, будет или нет удовлетворена их просьба, или о том, что им придется подождать еще несколько дней. Сокращение сроков рассмотрения заявок привело к росту продаж, экономии затрат на экспертов, которые начали выполнять более квалифицированную работу.
В примере налицо кардинальное изменение описания бизнес-процесса и повышение эффективности в разы. Самое интересное, что почти все руководители много раз действовали аналогичным образом тогда, когда можно было четко сформулировать критерии принятия итогового решения (таких , например, как критерии предоставления скидок: если доставка осуществляется за пять дней, предоставляется трехпроцентная скидка, если же доставка занимает десять дней, предоставляется пятипроцентная скидка). Как только эти критерии сформулированы, принятие решения делегируется вниз, что приводит к экономии, улучшению описанных бизнес-процессов, повышению качества… Причем реализация изменений бизнес-процессов обычно проходит проще, чем в компании IBM, поскольку при этом не требуется экспертная система и сокращение специалистов, — но и не приводит к подобному повышению эффективности.
Подобная работа является одним из результатов оптимизации бизнес-процессов — кропотливой работы по постоянному улучшению деятельности компании.
Отличием оптимизации от реинжиниринга в данном случае является скорость получения результата, объем работ и суть изменений. Если не вдаваться в подробности, при оптимизации одно правило быстро доводится до исполнителя и корректируется «на ходу». Когда осуществляется реинжиниринг, долго и тщательно разрабатывается определенная система описаний бизнес-процессов, которая затем проверяется, а после реализуется, и часто при ее реализации разрабатываются и внедряются различные формы автоматизации.
В табл. 1 представлены различия между реинжинирингом и оптимизацией (усовершенствованием) бизнес-процессов, выделенные Томом Давенпортом , гуру в области описания бизнес-процессов.
Таблица 1. Различия между реинжинирингом и оптимизацией бизнес-процессов
Источник: piter-consult.ru