Бизнес-процесс: «Этот смутный объект желания»

Цикл «Теория управления предприятием»

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

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

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

Но оно отвечает лишь на вопрос «что?», не указывая нам «как?» и «когда?» получается бизнес-процесс. Вот об этом мы сегодня и поговорим.

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

Важный принцип

Термин «бизнес-процесс» является прямым и непосредственным атрибутом теории «Business Process Reengineering». Т.е. говоря «бизнес-процесс», мы подразумеваем «реинжиниринг», а упоминая реинжиниринг, понимаем, что речь идет о бизнес-процессах. Иначе говоря, бизнес-процесс является непременным участником реорганизационных перестроек, или объектом, который прошел эти самые «революционные преобразования» по Майклу Хаммеру. Но при этом необходимо иметь в виду, что не все преобразования являются «реинжинирингом». А только те, которые приводят к реализации процессного управления или к получению выделенных процессов (что, по сути, одно и то же).

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

Вспомним, с какой целью вводил свою теорию Майкл Хаммер. А он «всего лишь» пытался вывести единый стандарт реорганизационных преобразований предприятия, который позволил бы обеспечить стабильно высокое качество продукции, а также повысить управляемость предприятия, каковая страдала в ходе организационного роста, вызванного ростом объемов и/или ассортимента производимой продукции.

Параметр управляемости предприятия

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

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

Итак, имеем некое предприятие с n участниками. Данное предприятие за единицу времени выпускает продукцию, итоговый результат которого в денежном выражении равен P. Таким образом, мы можем получить соотношение P/n – количество продукции в денежном выражении на каждого участника за единицу времени, каковое и будет указывать нам начальную точку для изучения фактора «управляемость предприятия».

Предположим, что наше предприятие начало расти. В этом случае количество участников изменится с n на n1, а объем продукции вырастет с P до P1. Это вновь позволяет нам получить новое соотношение P1/n1.

И теперь, если наше P1/n1 >= P/n, то параметр «управляемость предприятия» просто фантастически высок, а наше предприятие имеет очень хороший потенциал роста.

Если P1/n1 примерно сравнимо с P/n, то это также неплохой показатель, указывающий на стабильность и качество управленческих связей.

Ну, и наконец, если P1/n1 существенно меньше P/n, то предприятию просто необходим реинжиниринг.

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

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

Программные аналогии

Наибольшую наглядность параметр «управляемость» приобретает в примерах относящихся к сфере разработки программного обеспечения. Здесь все просто и понятно – с ростом кода разрабатываемой программы, программист теряет контроль над взаимодействием внутренних функций программы, пропуская явные ляпы, и все с большим трудом находя некорректности.

С целью повышения управляемости в написании новых компьютерных программ создаются принципиально новые подходы программирования: от программ в машинных кодах к языкам программирования низкого уровня, к языкам высокого уровня, к структурному программированию и, наконец, к программированию объектному.

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

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

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

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

Структурное программирование сравнимо с панельным строительством – со всеми вытекающими. Ну, а программирование в объектах можно сравнить со строительством целыми, готовыми к «употреблению» комнатами. Комнату на этаж поставили – и можно заселяться.

К чему все это? А к тому, что проектирование оргструктуры предприятия – это точно такое же программирование, как и компьютерное со своим своеобразным языком и командами. И методология BPR – это полный аналог объектно-ориентированного программирования (ООП). Причем BPR более близок к «строительству комнатами», чем собственно ООП.

Иначе говоря, функциональное управление предприятием предполагает «программирование» оргструктуры на языке существенно более низкого уровня, чем процессное управление, каковое программируется на уровне объектно-ориентированного языка.

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

Так почему же мы, находясь в рамках BPR, называем «бизнес-процессом» любые исследуемые или проектируемые процессы?! Это сродни тому, что любую программу на компьютере называть объектно-ориентированной, лишь потому, что она программа!

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

Такова суровая правда жизни….