Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


 
Что такое бизнес-процесс?

Литература:

Автор: Пол Хармон

Оригинал статьи: What is a Business Process?

BPTrends публикует информацию о бизнес-процессах с 2003 года. За это время мы опубликовали более 1000 статей, в которых встречалось слово «процесс». Кто-то может подумать, что к настоящему времени со значением слова «процесс» уже все согласны. Я был шокирован, однако, в ходе недавней дискуссии на Linkedin, увидев количество определений, предлагаемых практиками. Ясно, что согласия в значении базового термина «процесс» нет.

Могу сказать, что я бы хотел «прояснить» или «определить» этот термин, но очевидно, что и другие вправе давать определения так же, как и я, и очевидно, что они выберут иное определение, нежели я. Я могу только сказать как я использую этот термин, и напомнить всем, кто читает то, что я пишу для BPTrends, что я и в дальнейшем буду использовать его в том же контексте.

Во-первых, использую ли я слово «процесс» или «бизнес-процесс», я всегда имею в виду бизнес-процесс. Энциклопедический словарь Мерриам Вебстер, к примеру, предлагает следующее, как первое определение процесса: (1) естественный феномен, характеризующийся постепенными изменениями, приводящими к тому или иному результату  (например, процесс роста). Это, разумеется, не тот процесс, который я имею в виду. Когда я использую термин «процесс», я имею в виду то, как организована и исполняется работа в организации. Так, для ясности, когда я использую термин «процесс», я имею в виду бизнес-процесс.

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

 

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

Я начинал работать с процессами еще в 60-х, когда большинство компаний еще не были озабочены программным обеспечением. В то время я работал с Гэрри Раммлером в Praxis, и когда компании нанимали нас улучшить процессы, они неизменно ссылались на то, что делают сотрудники. Таким образом, они просили нас улучшить процесс продаж или производственный процесс или процесс найма сотрудников. Люди, которые нас нанимали, изначально подразумевали, что мы будем рассматривать последовательность действий сотрудников, и предложим изменения в существующей последовательности или характере действий. И мы изначально объясняли, что мы не сможем гарантировать хороший результат, если мы не сможем изучить и изменить каждый аспект рассматриваемого процесса.

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

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

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

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

Это ограниченное определение может быть связано с Джоном Захманом и его популярным фреймворком. В 1987 году Захман, исследователь в IBM, предложил то, что сейчас в народе называют фреймворком Захмана – способ концептуализации того, что включается в любую архитектуру информационных систем [1]. Захман заимствовал термин архитектура из строительства, где различные типы рисунков и чертежей архитектуры здания обычно необходимы для строительства здания. Он провел параллель и для софтверной разработки. Он подчеркнул, что организация не имеет простейшей архитектуры, но вместо этого обладает целым рядом диаграмм и документов, представляющих различные аспекты или точки зрения. В последующие годы, когда он писал свои оригинальные статьи, Захман работал над тем, чтобы уточнить и доработать свой фреймворк. На Рисунке 1 представлена последняя версия фреймворка Захмана.

 

 Рисунок 1. Фреймфорк Захмана

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

Позвольте мне объяснить, почему я не согласен с взглядом Захмана. Представьте, что вы назначаете кого-то ключевым процессным или отвечающим за цепочку создания ценности менеджером. Затем вы показываете отдельные диаграммы действий, которые имеют место в цепочке создания ценности. «Вы будете отвечать за эту диаграмму», - объясняете вы. «Если диаграмму нужно изменить, вы будете управлять изменениями».  Какой нормальный менеджер возьмется за эту работу? Процессная работа – это не перемещение квадратиков на диаграмме – это изменение производительности организации. Процессная работа – это создание измеримых результатов, таких как удвоение количества штуковин, производимых процессом, и/или уменьшение жалоб потребителей на 50%, и/или сокращение расходов на 20%.

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

С годами я стал понимать, что люди в ИТ часто используют слово «процесс» для обозначения чего-то, что делает софтверная система. По этому определению, процесс начинается тогда, когда кто-то что-то вводит в запрограммированный процесс, который затем применяет некоторый алгоритм к введенным данным и производит выход.  Давайте называть это софтверным процессом.

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

Мне нравится Amazon.com. Я постоянно покупаю там книги.  Буквально на днях я получил не ту книгу. Я вошел в онлайн и получил информацию, необходимую для возврата книги, и мне необходимо было связаться с кем-то, что я и сделал. Этот товарищ написал мне по email, извинился и организовал возврат. Возврат прошел гладко, и я почувствовал себя счастливым, что являюсь заказчиком Амазона. Если все было сделано не так хорошо, я бы поискал другой источник покупки книг онлайн. Amazon.com – хороший пример высокой степени автоматизации бизнес-процессов. Но все равно в их работе все еще остается места, где задействованы люди, и роль, которую они исполняют – критическая, поскольку эти люди и есть лицо компании Amazon.com.

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

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

Я часто использую диаграмму, изображенную на Рисунке 2, чтобы объяснить действительную роль, которую процессы могут оказать на то, что думают об организации. Если вы думаете, что организация – это набор функциональных единиц или отделов, то у вас иной взгляд. На организационной диаграмме нет заказчиков. Так же как и нет пути создания ценности. Это только изолированные единицы, которые выполняют действия, которые могут или не могут быть ценными. Только процессный взгляд покажет вам, как собрать все вместе для получения результата.

 Рисунок 2. Процессный взгляд объединения всей организации вокруг создания ценности для заказчика.

Рассматривать процессы, как основную управленческую перспективу для современной организации – это основная идея, которую мы, процессники, должны продвигать. Организации существуют для того, чтобы исполнять процессы, создающие ценность для заказчиков и собственников. Чтобы управлять организацией, вы должны управлять ее процессами. Процессы либо производят что-то ценное, либо нет. Все в организации существует для того чтобы поддерживать процессы, и либо они делают это, либо должны быть изменены или устранены. Это видение, которое продвигают Деминг, Шинго, Раммлер, Дэвенпорт, Хаммер, Барлтон и многие другие, и это по-прежнему самый мощный и полезный подход к управлению организацией.

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

 

Комментарии
#1 Анатолий Белайчук, 10.10.2011 18:42

Довели человека smile

Из статьи видно, что Хармон в целом является последователем Раммлера. Но больше последнего разбирается в ИТ-аспектах.

>> люди в ИТ часто используют слово «процесс» для обозначения чего-то, что делает софтверная система. По этому определению, процесс начинается тогда, когда кто-то что-то вводит в запрограммированный процесс, который затем применяет некоторый алгоритм к введенным данным и производит выход. Давайте называть это софтверным процессом

#2 Валерий Лопатин, 22.10.2011 03:02

1)"Это, разумеется, не тот процесс, который я имею в виду."

Я бы не стал так категорически утверждать. "Постепенные изменения, приводящие к тому или иному результату" - разве они не имеют отношения к процессу совершенствования БП?

2)"Бизнес-процесс – это то, чем управляют менеджеры бизнес-процесов."

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

Но чем реально управляют менеджеры?

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

3)"Процессная работа – это создание измеримых результатов, таких как удвоение количества штуковин, производимых процессом, и/или уменьшение жалоб потребителей на 50%, и/или сокращение расходов на 20%."

То есть, процессная работа для Хармона - это совершенствование шаблона БП. А любое совершенствование - это решение проблемы и здесь без системного подхода не обойтись. Поэтому Хармон и говорит: "Я думаю о процессной методологии как о системном подходе к выявлению, как организация работает и способам диагностики, какие изменения приведут к значительному улучшению ее деятельности."

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

Правда мы тут последнее время все вспомнили про динамические (адаптивные, ad hoc и т.п.) бизнес процессы, у которых шаблон заранее не определен. Здесь уже "удвоением штуковин, производимых процессом" не отделаешся.

#3 Юлия Вагнер, 24.10.2011 12:04

Валерий,
вот это
"БП это шаблон и экземпляры. И соответственно разные объекты управления. И два перпендикулярных управления: управление функционированием бизнес-процесса (по ходу развертывания экземпляра БП) и управление совершенствование БП (улучшение шаблона БП).
И когда мы говорим о менеджерах, подразумеваем первый вид управления."
именно НЕ то, что Хармон имеет в виду.
Для того, чтобы его понять, надо на минуточку забыть о машинном представлении процесса. Хармон не мыслит категориями шаблонов и экземпляров.
Т.е. "процессная работа для Хармона - это совершенствование шаблона БП" - это большое НЕТ.
Помните песню: "А я говорю, роса, говорю. Она говорит - мокро". У Вас с Хармоном получился бы похожий диалог smile

#4 Валерий Лопатин, 25.10.2011 09:35

Юлия,в отличие от вас, я не айтишник и категориями машинного представления процессов не оперирую.

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

Можно эти термины не использовать, от этого ничего не изменится. И думаю Хармон это прекрасно понимает.

Жаль что для вас это "роса" и "мокро". Невольно возникает вопрос, как же вы представляете себе "процессную работу" Хармона?

#5 Юлия Вагнер, 25.10.2011 10:50

Валерий,
думаю, что Хармон ставит во главу угла именно управленческие аспекты BPM, а не повышение производительности за счет чистых эффектов автоматизации. Такой эффект нужно и должно использовать, но не вместо, а как приятное дополнение.
Что такое шаблоны или описания бизнес-процессов, если они не связаны с общей концепцией управления (скажем, с ToC, Six Sigma или другими), со стратегией? Мне кажется, что именно это Хармон и пытается объяснить.

#6 Валерий Лопатин, 25.10.2011 13:07

Юлия,
"Хармон ставит во главу угла именно управленческие аспекты BPM" - к сожалению, не знаю, какой смысл вы вкладываете в эту фразу.

Если это касается текущего функционирования бизнес-процессов, то (как я говорил выше), во главу угла эти аспекты лучше не ставить.

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

"Что такое шаблоны или описания бизнес-процессов, если они не связаны с общей концепцией управления (скажем, с ToC, Six Sigma или другими), со стратегией".
То что шаблоны бизнес-процессов есть следствие стратегии - это достаточно тривиальная мысль. По вашему, Хармон это "пытается объяснить"?

Кстати, "ToC, Six Sigma" - это скорее некие наборы методов и инструментов, а не концепции управления.

#7 Виктор Кобыща, 07.11.2011 12:36

Разделяю шоковое состояние Хармона. И согласен с теми, кто с конца XX века говорит о "понятийной катастрофе", об использовании терминов без понятий.

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

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

С моей точки зрения, Хармон различает использование термина "процесс", отнесенного к бизнесу как целому, как системе деятельности, и "процесс", как цепочка действий, отнесенных к частным операционным системам внутри бизнеса. Это различение он и закрепляет термином (знаком) "бизнес-процесс", относя его к первому значению понятия.

Следующее различение - Хармон отделил бизнес-процессы и процессы обработки информации (знаковых форм) в информационных системах, тем самым проблематизировав термин "автоматизация управления" как фигуру речи.

Лет десять назад Владимир Дмитриевич Алёшин публиковал статью по автоматизации, там он также явно разделил производство продуктов и производство информации:
"автоматизированная система управления предприятием производит информацию, необходимую для коммуникаций в процессе производства продуктов".

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

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права