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

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

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

Не Запад и не Восток

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

Но Россия — это и не Запад, и не Восток. Идея человека-винтика, человека-функции у нас воспринимается плохо. То же можно сказать и о концепции «по чистым трубам течет чистая вода», лежащей в основе TQM. Если что-то нужно сделать для получения сертификата ISO 9000 — сделаем, но сами не очень-то в это верим.

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

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

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

Основные проблемы связаны с кросс-функциональными процессами. (Когда в англоязычном тексте по менеджменту вы встречаете слово «function», знайте: это никакая не «функция», а подразделение. Можно перевести как «функциональное подразделение». Следовательно, «кросс-функциональный» означает «проходящий через несколько подразделений».) Например, процесс «от заказа до оплаты» затрагивает отдел продаж, производство, логистику, бухгалтерию… С точки зрения BPM важнее не то, как процесс выполняется внутри подразделения, а значения итоговых показателей на входе и выходе из него. Вы можете вообще не вникать в организацию процесса внутри, а просто задать для подразделения SLA, ориентированный на такие, например, показатели: «время выполнения подпроцесса с частотой 99% не должно превышать 2 часов» или «частота ошибок в оформлении документа не должна превышать 2%». Тем самым вы, с одной стороны, действуете в рамках процессного управления — сохраняете нацеленность на итоговые показатели кросс-функционального процесса, а с другой — не впадаете в крайность регламентировать всё и вся и задействуете правильные психологические стимулы. К великому сожалению, процессные инициативы у нас чаще выглядят строго наоборот: все внимание сосредоточено на содержании подпроцессов (так называемая субоптимизация), а о метриках процесса в целом думать как-то недосуг.

Три составляющие

Обычно BPM определяют как сочетание управленческой методологии и инструментария BPMS. Правда, это не для всех очевидно: есть технари, которые не видят разницы между BPM и BPMS, а с другой стороны, есть мнение, что BPM можно практиковать без BPMS. Замечу: да, можно и даже полезно — по аналогии с тем, как для изучения бухгалтерского учета полезно попрактиковаться в ведении двойной записи в собственноручно расчерченном журнале при помощи калькулятора. Но можно ли вести при помощи журнала и калькулятора бухгалтерский учет в современной компании? То же — и с процессами. Очень четко это сформулировал один из заказчиков: «Да, я могу управлять бизнес-процессом без BPMS. И я это делаю. Но это отнимает столько сил, что больше чем одним процессом в ручном режиме я физически управлять не могу». Это очень зрелый взгляд: BPMS рассматривается как «усилитель», а не как замена отсутствующей компетенции.

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

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

Анатолий Белайчук — президент компании «Бизнес-Консоль», bell@b-k.ru