Наверх

Мой личный взгляд на бизнес-процессы

Время чтения: 7 минут
1
Мой личный взгляд на бизнес-процессы

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

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

По-видимому надо принять как данность, что единого определения бизнес-процесса нет и не будет. И не имеет смысла навязывать единственно верное определение. Я этого делать и не буду, а всего лишь попытаюсь объяснить, что лично я понимаю под термином “бизнес-процесс”.

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

Например: “От заказа до оплаты” - это бизнес-процесс? По-видимому, да.

А как насчет таких вещей, как:

  • “управление персоналом”
  • “добыча нефти”
  • “отчет о командировке”
  • “выписка счета”
  • “замена картриджа в принтере”

Может это все бизнес-процессы, а может и нет… Смотря с какой точки зрения посмотреть.

Меня в первую очередь интересует взгляд с точки зрения процессного управления.

Что такое процессное управление?

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

Проблема, с которой сталкивается любая иерархическая организация:

  • Сначала появляется специализация: одни сотрудники подготовлены для работы в одной функциональной области, другие - в другой.
  • Потом эти сотрудники рассаживаются по отделам и по комнатам в соответствии со своей функцией.
  • Заканчивается дело тем, что каждый сотрудник начинает воспринимать как “свое” ту функцию, которая ему поручена, а конечный результат - то, ради чего организация существует, т.е. удовлетворение каких-либо потребностей внешнего мира - вроде как никому не поручен. (По Райкину: “К пуговицам претензии есть? - Нет, к пуговицам претензий нет! Я хочу узнать кто у вас за костюмчик отвечает? - Мы!”)

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

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

По большому счету, таких решений изобретено всего два: проектное и процессное управление.

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

Бизнес-процесс в рамках процессного управления

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

Ключевые аспекты понятия бизнес-процесс в этой трактовке:

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

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

Бизнес-процесс в рамках функционального управления

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

Я в это не верю. По моему убеждению, бизнес-процесс - это не заменена функциональной некомпетентности, с которой может и должно справляться функциональное управление. Сотрудник не справляется? Научите или замените. Не помогает? Замените непосредственного руководителя.

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

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

Классификация бизнес-процессов

Уместно задать вопрос: а куда в определении выше делся заказчик?

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

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

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

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

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

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

  • Сквозной процесс начинается с обращения заказчика и заканчивается окончанием работы по его запросу, классический пример - “От заказа до оплата”.
  • В противоположность этому примеру, бизнес-процесс “Доставка товара клиенту” является основным, но не является сквозным.

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

Бизнес-процесс с точки зрения BPM

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

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

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

В результате в современной трактовке процессное управление имеет два измерения:

  • управление организацией посредством бизнес-процессов
  • и управление самими бизнес-процессами в классическом цикле PDCA

Современные процессная методология и инструментарий BPMS смотрят на бизнес-процесс как на нечто постоянно меняющееся. Поэтому, в частности, в проектах BPM неприменима разработка по методу “водопада” - только Agile.

Чтобы прочитать эту статью до конца,
или зарегистрируйтесь

Комментарии 1

Хороший текст.

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

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

Интересно, как пощупать в основном процессе ценность для заказчика (только для внешнего), и почему в нем "не создается стоимость (не наращиваются издержки)"?

Чтобы прокомментировать, или зарегистрируйтесь