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

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

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

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

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

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

Сразу отмечу, что термин «бизнес-процесс» лишь частично несет в себе ту логику, каковая вкладывалась в него, скажем, в 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, называем «бизнес-процессом» любые исследуемые или проектируемые процессы?! Это сродни тому, что любую программу на компьютере называть объектно-ориентированной, лишь потому, что она программа!

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

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

Теория управления предприятием: мыслить процессами

Столкнулся в обсуждении с термином «вспомогательный процесс»…. Полез в Интернет – ссылки пестрят. И даже в Википедии отдельная статья: Вспомогательные процессы — это процессы, которые обеспечивают бесперебойное протекание основных процессов (изготовление и ремонт инструментов и оснастки; ремонт оборудования; обеспечение всеми видами энергий (электроэнергией, теплом, паром, водой, сжатым воздухом и т. д.))

Ребята, да, вы что, в самом деле?! Не бывает «вспомогательных» процессов! И если вы этого не понимаете, то вы не понимаете сути термина «процесс»!

Но, обо всем по порядку. Итак:

Процесс

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

Т.е. надо так понимать, что «основной» процесс – это тот, от которого вы много денег получаете, а «вспомогательный» – так, чуть-чуть….

Но, шутки в сторону.

Подозреваю, что терминология «основной – вспомогательный» была банально перенесена из теории функционального управления, которая, на самом деле (и вполне закономерно!) оперирует терминами «основное производство» и «вспомогательные службы», и укрепившись, обросла корнями, запутав и смысл и логику новомодного процессного управления.

Что интересно, в Википедие отсутствует термин «функциональное управление», но вот, что нам говорит экономический словарь на сайте Академик:

ФУНКЦИОНАЛЬНОЕ УПРАВЛЕНИЕ - управление по функциям, в процессе которого каждый функциональный руководитель ведает исполнением определенного круга функций, работ (производственные, технологические, проектные, финансовые, информационные, обеспечивающие).

Корявое, ни о чем не говорящее определение... На мой взгляд, лучше так: «функциональное управление – это управление производственными процессами с помощью выделенного из них обеспечивающего функционала, реализованное конвейерным способом».
Поясню. Любое предприятие создается с целью производства некоего продукта – товара/услуги, получение которого обеспечивается набором производственных функций. Это – понятно. Но помимо функций производственных, каждое производство должно еще и обеспечить собственное существование. Для чего в нем появляются кадровый, бухгалтерский, снабженческий и прочие функционалы. Так вот, функциональное управление – это когда мы из производственного процесса с корнем выдрали весь обеспечивающий функционал, унифицировали его и разместили поверх производства, проводя управление производственной деятельностью с помощью вновь организованного общего функционала.

Деятельность любого предприятия с функциональным управлением мы можем изобразить в виде схемы, которая легко превращается в таблицу:

Схема 1

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

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

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

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

Управление процессами

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

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

Схема 2

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

Если результаты процессной реализации сравнить с предыдущим вариантом, то можно отметить:

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

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

В качестве пояснения к первому пункту рассмотрим пример функции отдела кадров, реализованную тем или иным способом:

1. Функция встроена в производственный процесс. В основном это говорит о том, что проблем с подбором нужного персонала нет, и все кадровые изменения/перемещения решаются «на лету» руководителем процесса.

2. Через информационное поле реализовывать именно эту функцию смысла не видно. Лишь ведение общей информации в виде статистических данных.

3. Функция сохранена в торгово-управляющей надстройке. При возникновении кадровых проблем руководитель процесса обращается в соответствующее подразделение компании с просьбой по оказанию кадровой помощи. В итоге проблема сообща решается. Оплата деятельности кадрового подразделения производится из общего фонда компании.

4. Функция выделена в отдельный процесс. Грубо говоря, на основе нашего подразделения создается кадровое агентство, которое не только зарабатывает себе на жизнь производством кадровых услуг, но и приносит прибыль всей компании за счет своей деятельности. Обычно, в таких случаях большая часть деятельности подобного кадрового агентства приходится на подразделения компании.

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

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

Достоинства процессного управления можно выразить следующим набором:

1. Легок в управлении;
2. Хорошо масштабируется путем добавления новых «кубиков»;
3. Легко реагирует на индивидуальный подход к клиенту/заказчику.

Взгляд с позиции финансов

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

Все итоги функционала, размещенного построчно в схеме 1, выражают расходную часть деятельности предприятия. Тогда как итоги работы процессов – часть уже доходную. И таким образом можно утверждать, что функциональный подход – это управление расходами предприятия. Процессная же реализация сразу дает вам четкую картинку по изменению доходной части.

И вновь пояснение. В первом варианте, когда вы пытаетесь что-то изменить в производственных процессах, вы меняете параметры одной из управляющих функций. Т.е. фактически вы изменяете расходную часть и ждете, как это откликнется на выходе продукции в производственном процессе. А так как таких изменений много, они происходят постоянно и во всех функциях, то вычислить влияние конкретного действия достаточно сложно. И в итоге – вы увеличили расходную часть, а «выхлопа» – не последовало.

В случае процессной реализации – не рентабельных процессов просто быть не может – он просто не запустится. А добавляя/убирая кубики процессов, вы изменяете объем дохода.

И возвращаясь к вопросу, который меня «возмутил», и о котором я упомянул в самом начале работы:

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

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