О разных подходах к описанию бизнес-процессов.
Заметка прежде всего для неспециалистов — для общего понимания основ.
У меня уже когда-то была аналогичная заметка для продавцов, теперь сделаю то же самое, максимально понятным языком.
Наиболее стратегический подход соответствует одному из множества определений бизнес-процесса — если коротко, преобразование входов в выходы.
Наглядно получается на примере производства: у нас есть сырье, заготовки и т.п., всё это поступает на "вход" процесса, а на выходе имеем готовую продукцию или что там делает производство. Получается некий ящик, в который с одной стороны входит, с другой выходит.
Изначально такой подход как раз в производстве и применялся. Первичная цель — координация работы разных подразделений и синхронизация логистики. "Большое" предприятие было, по сути, равно "большому" основному процессу, в который что-то входило и что-то выходило. Внутри ящика рисовали ящики поменьше, они описывали процессы внутри "большого" процесса, и часто соответствовали различным функциям или подразделениям внутри "большого" предприятия. Такая детализация называется декомпозицией — раскладыванием общего на составные части. У процессов поменьше тоже свои входы и выходы, которые синхронизированы с общими.
Дополнительно к ящику обычно пририсовывали еще два вида стрелок: это т.н. механизмы (оборудование, человеческие и другие ресурсы, но не сырье, и т.п.) и контроли. Второе символизировало всевозможные регламенты, приказы и другие действия и воздействия руководства на процесс. Получалось примерно так:
Способ описания процесса, "язык" написания диаграмм, называется нотацией. В данном случае это нечто, похожее на нотацию IDEF0 (я сильно упростил, чтобы было нагляднее) — основную из целого семейства нотаций, очень активно использовавшихся и до сих пор используемых во многих предприятиях.
Не будем углубляться в детали, перейдем к следующему варианту описания процессов — на основании потока данных. Это больше импонирует разработчикам различного программного обеспечения, т.к. их как раз и интересует больше всего, какие данные куда должны поступать.
Графически для этого используется обычно DFD (data flow diagram). И, как правило, используется при разработке различных информационных систем.
Следующий очень простой принцип всегда применялся людьми бизнеса: это просто изображение хода работ, в виде интуитивно понятных блок-схем, где могут быть элементарные правила, но может быть и просто наглядное изображение некой последовательности действий, событий, состояний и т.п. Плюс такого способа — гибкость, минус — отсутствие четких правил.
Скажем, в нотации IDEF0 процесс всегда должен обозначаться глаголом и каким-то дополнением. Например, "изготовить деталь". Т.е. нельзя написать в виде состояния, "изготовление детали". Нужен глагол, чтобы избежать двусмысленностей. Тогда как при составлении блок-схем правила достаточно условны, там можно даже статусы в виде элементов поставить, это на усмотрение автора. Кстати, так часто и делают. Чтобы понимать, из какого состояния в какое переходит, например, какой-то объект.
Часто встречающийся вариант — т.н. flow chart или work flow (это не совсем одно и то же, но сейчас различие не так важно), как бы диаграмма потока (действий). И это может быть не только алгоритм в виде блок-схемы, с элементарными хотя бы правилами, но и просто визуальное изображение с картинками для наглядности в качестве элементов и стрелочками, показывающими переход от одного элемента в другой.
Разработчики ПО, помимо иногда используемой DFD, часто используют семейство UML, универсального языка моделирования. Там несколько нотаций, которые описывают структуру данных, типичные варианты действий пользователя, системные элементы и как система будет работать. Т.е. процесс можно описать и в рамках UML тоже, в каком-то аспекте.
Это своеобразный стандарт для разработчиков, но он не очень удобен для неспециалистов.
Упомяну еще об одном варианте — BPEL — это язык диаграмм, который можно автоматически превращать в код, если упрощенно. Довольно мощная штука, еще менее понятная для неспециалистов. И он не единственный, но не будем углубляться.
Более значимый принцип был использован в нотации EPC — там цепочка элементов описывалась на основе и в привязке к событиям (event-driven process chain). Нотация активно используется в широко известных системах SAP, она очень удобная, мощная, понятная как для разработчиков, так и для бизнес-пользователей.
Но есть нюанс: она привязана, по сути, к определенной методике (ARIS, тоже активно и успешно используется в SAP). Кстати, создателя ARIS профессора Шеера иногда упрекали, что он хочет заставить весь мир смотреть через его очки... 😉
Тот же "событийный" принцип, но без привязки к методикам (и вендорам, в итоге), был применен в разработке наиболее современной на данный момент нотации BPMN. В этой нотации на "старте" процесса всегда есть начальное событие (или оно понятным образом подразумевается), действия-активности всегда выражаются глаголом плюс дополнением, как это традиционно сложилось, в конце всегда есть (или подразумевается) финальное событие — или, чаще, несколько, которые завершают определенные разветвления процесса.
Нотация проста, интуитивно понятна, на описательном уровне ее можно использовать как аналог традиционных блок-схем, там всего 4 основных видов элементов и достаточно понятные правила (практически везде в данном блоге я буду приводить примеры процессов в этой нотации).
При этом она также понятна и разработчикам, а если подойти к написанию диаграмм с должной аккуратностью, то возможно исполнение модели, как это делается в случае BPEL или EPC.
Но с одним важным нюансом: это общепринятый стандарт, поддерживаемый мировыми гигантами. Т.е. если BPEL — задумка неплохая, но не сильно удобная для бизнес-пользователей и очень слабо поддерживаемая, если EPC — гибкая, удобная и современная нотация, используемая к тому же в рамках очень мощной методологии ARIS, но поддерживаемая по сути только Software AG и SAP (при этом SAP — лидер на рынке ERP, но это только настраивает против остальных участников рынка), то BPMN — не только простая (на описательном уровне) и понятная нотация, но она еще и продукт очень непростого согласия нескольких мировых гигантов (включая упомянутые выше Software AG и SAP, но далеко не только).
Она (BPMN) не зависит от конкретных методик, что с одной стороны как бы добавляет работы аналитикам, с другой — делает ее гибкой и универсальной. В задумке, правильно задокументированные диаграммы должны иметь возможность быть перенесены из системы одного производителя в другую без потери смысла и функциональности.
Вернемся к нашему вопросу — итак, теперь мы имеем процесс, как некий понятный алгоритм действий, который начинается стартовым событием-триггером и завершается одним или несколькими вариантами финальных событий. Т.е. некая четкая инструкция для пользователей или автоматизированных систем, что, когда и в каком случае нужно делать.
Более того, сам процесс это не совсем аналог "потока работ", work flow, т.к. различные "пулы", содержащие такие аналоги, как бы "общаются" между собой, передавая информацию и отображая, таким образом, достаточно большую общую картину процесса.
Пример:
В итоге, обычно имеем некий стратегический принцип понимания процесса как превращения входов в выходы, что удобно при рассмотрении общих вопросов стратегии, архитектуры предприятия и т.п., а также более детальный "событийный" вариант изображения процесса, который может с любой заданной точностью показать алгоритм действий, с указанием времени, исполнителей и любой информации, которую аналитик посчитает нужным упомянуть (в виде аттрибутов можно указать всё, что угодно).
Второй вариант становится де факто стандартом, он сейчас активно используется в т.н. системах управления бизнес-процессами, которых уже множество и которые очень разные, от встроенных в другие системы до максимально независимых, включая с открытым кодом.
Для людей бизнеса просто важно понимать, что есть разные подходы, и наиболее два популярных из них не похожи друг на друга (кстати, в рамках семейства IDEF их пытались "поженить", но широкой популярности из-за сложности эти нотации не получили) и используют разные принципы. Поэтому, например, когда звучит фраза "я наладил там бизнес-процессы", надо понимать, речь о стратегических вещах, наведен порядок в плане что куда входит и выходит, или речь о более процедурных, если можно так выразиться, моментах, когда оптимизация коснулась не только каких-то общих вещей, но и деталей исполнения работ, возможно, вплоть до мельчайших.
Стратегические моменты, как правило, интересны собственникам бизнеса, топ-менеджерам, инвесторам и т.п. Тогда как, предполжим, разработчикам они крайне редко нужны. Их больше интересует как раз последовательность действий, а не что подается на входе и потом превращается в результат.
Популярность "событийного" подхода обусловлена также широкими техническими возможностями, которых не было раньше. Это, в первую очередь, автоматизация разного уровня, от "естественного" функционала в один шаг (нажал кнопку — сформировался документ, например) до достаточно сложных цепочек и далее, до автоматического принятия решений (это направление сейчас переживает бурный рост) и до искусственного интеллекта.
Что такой подход может дать руководителю? Если общей фразой — возможность более эффективно управлять процессами.
Более понятным языком, наверное, лучше сделать на примере.
Итак, есть, скажем, простой процесс. Стартовое событие: пользователь клиент-банка оформляет заявку на продажу находящейся у него на счете валюты. Казалось бы, дальше всё просто. Заявка рассматривается (я не знаю, делаю предположения), далее идут какие-то действия сотрудников банка, валюта продается, деньги поступают на счет, вуаля, всё просто. Если что-то в заявке не так, сотрудник связывается с клиентом, решает проблему, далее опять по накатанному.
Однако, в жизни несколько иначе (пересказываю реальный кейс).
Пользователь оформляет заявку, но у него возникает вопрос по одному пункту (он оформляет в первый раз и не знает). Он звонит закрепленному за ним сотруднику, сотрудник тоже не знает ответа, предлагает позвонить в колл-центр. В колл-центре разъясняют, заявка оформлена.
Пользователь должен при этом предоставить дополнительные документы в банк. Он предоставляет и ждет. Но ничего не происходит, поэтому он опять звонит эккаунт-менеджеру, та не берет трубку (видимо, занята). Клиент волнуется — а вдруг что-то не так? Может надо что-то еще предоставить, что-то еще сделать и т.п.
Очень простая процедура повлекла за собой ряд дополнительных действий и со стороны клиента, и со стороны сотрудников. Разве это оптимально? Вероятно, оптимальнее было бы, скажем, просто поставить подсказку возле того поля, которое изначально вызвало сомнения (сумма договора; что делать, если в договоре не указана сумма, если он о сотрудничестве "вообще"? Ноль оставить нельзя, разгадка — просто указать сумму продаваемой валюты, никаких вопросов от банка при этом не будет, но кто ж знал).
Далее, было бы оптимально, уведомлять клиента, если он того хочет, о ходе процедуры. Чтобы не было сомнений и волнений, которые потом превращаются в звонки в банк, отнимая время у сотрудников.
Казалось бы, очень просто. Но повторю: это реальный кейс, это не выдумка.
Вроде мелочь, но сколько таких мелочей? По сути, руководитель мог бы повлиять на процесс (изменив его), если бы:
- он понимал, как процесс исполняется;
- имел возможность его проанализирвать;
- понимал т.н. "карту путешествия" клиента, т.е. как поступает обычно клиент и с чем он по ходу сталкивается.
Т.е., возвращаясь к нашей теме, подход к описанию процессов на более детальном, "событийном" уровне — одна из составляющих, дающих возможность реально управлять процессом. И я не имею в виду наорать на ответственного за процедуру сотрудника, я имею в виду изменить некую деталь в системе.
Естественно, помимо понимания и управления собственными процессами, неплохо бы и знать, как себя ведет и какие сложности испытывает клиент, — но об этом в другой раз.
Сейчас же надеюсь, практический смысл разных подходов к описанию процессов стал теперь более понятен. :)
Заметка прежде всего для неспециалистов — для общего понимания основ.
У меня уже когда-то была аналогичная заметка для продавцов, теперь сделаю то же самое, максимально понятным языком.
Наиболее стратегический подход соответствует одному из множества определений бизнес-процесса — если коротко, преобразование входов в выходы.
Наглядно получается на примере производства: у нас есть сырье, заготовки и т.п., всё это поступает на "вход" процесса, а на выходе имеем готовую продукцию или что там делает производство. Получается некий ящик, в который с одной стороны входит, с другой выходит.
Изначально такой подход как раз в производстве и применялся. Первичная цель — координация работы разных подразделений и синхронизация логистики. "Большое" предприятие было, по сути, равно "большому" основному процессу, в который что-то входило и что-то выходило. Внутри ящика рисовали ящики поменьше, они описывали процессы внутри "большого" процесса, и часто соответствовали различным функциям или подразделениям внутри "большого" предприятия. Такая детализация называется декомпозицией — раскладыванием общего на составные части. У процессов поменьше тоже свои входы и выходы, которые синхронизированы с общими.
Дополнительно к ящику обычно пририсовывали еще два вида стрелок: это т.н. механизмы (оборудование, человеческие и другие ресурсы, но не сырье, и т.п.) и контроли. Второе символизировало всевозможные регламенты, приказы и другие действия и воздействия руководства на процесс. Получалось примерно так:
Способ описания процесса, "язык" написания диаграмм, называется нотацией. В данном случае это нечто, похожее на нотацию IDEF0 (я сильно упростил, чтобы было нагляднее) — основную из целого семейства нотаций, очень активно использовавшихся и до сих пор используемых во многих предприятиях.
Не будем углубляться в детали, перейдем к следующему варианту описания процессов — на основании потока данных. Это больше импонирует разработчикам различного программного обеспечения, т.к. их как раз и интересует больше всего, какие данные куда должны поступать.
Графически для этого используется обычно DFD (data flow diagram). И, как правило, используется при разработке различных информационных систем.
Следующий очень простой принцип всегда применялся людьми бизнеса: это просто изображение хода работ, в виде интуитивно понятных блок-схем, где могут быть элементарные правила, но может быть и просто наглядное изображение некой последовательности действий, событий, состояний и т.п. Плюс такого способа — гибкость, минус — отсутствие четких правил.
Скажем, в нотации IDEF0 процесс всегда должен обозначаться глаголом и каким-то дополнением. Например, "изготовить деталь". Т.е. нельзя написать в виде состояния, "изготовление детали". Нужен глагол, чтобы избежать двусмысленностей. Тогда как при составлении блок-схем правила достаточно условны, там можно даже статусы в виде элементов поставить, это на усмотрение автора. Кстати, так часто и делают. Чтобы понимать, из какого состояния в какое переходит, например, какой-то объект.
Часто встречающийся вариант — т.н. flow chart или work flow (это не совсем одно и то же, но сейчас различие не так важно), как бы диаграмма потока (действий). И это может быть не только алгоритм в виде блок-схемы, с элементарными хотя бы правилами, но и просто визуальное изображение с картинками для наглядности в качестве элементов и стрелочками, показывающими переход от одного элемента в другой.
Разработчики ПО, помимо иногда используемой DFD, часто используют семейство UML, универсального языка моделирования. Там несколько нотаций, которые описывают структуру данных, типичные варианты действий пользователя, системные элементы и как система будет работать. Т.е. процесс можно описать и в рамках UML тоже, в каком-то аспекте.
Это своеобразный стандарт для разработчиков, но он не очень удобен для неспециалистов.
Упомяну еще об одном варианте — BPEL — это язык диаграмм, который можно автоматически превращать в код, если упрощенно. Довольно мощная штука, еще менее понятная для неспециалистов. И он не единственный, но не будем углубляться.
Более значимый принцип был использован в нотации EPC — там цепочка элементов описывалась на основе и в привязке к событиям (event-driven process chain). Нотация активно используется в широко известных системах SAP, она очень удобная, мощная, понятная как для разработчиков, так и для бизнес-пользователей.
Но есть нюанс: она привязана, по сути, к определенной методике (ARIS, тоже активно и успешно используется в SAP). Кстати, создателя ARIS профессора Шеера иногда упрекали, что он хочет заставить весь мир смотреть через его очки... 😉
Тот же "событийный" принцип, но без привязки к методикам (и вендорам, в итоге), был применен в разработке наиболее современной на данный момент нотации BPMN. В этой нотации на "старте" процесса всегда есть начальное событие (или оно понятным образом подразумевается), действия-активности всегда выражаются глаголом плюс дополнением, как это традиционно сложилось, в конце всегда есть (или подразумевается) финальное событие — или, чаще, несколько, которые завершают определенные разветвления процесса.
Нотация проста, интуитивно понятна, на описательном уровне ее можно использовать как аналог традиционных блок-схем, там всего 4 основных видов элементов и достаточно понятные правила (практически везде в данном блоге я буду приводить примеры процессов в этой нотации).
При этом она также понятна и разработчикам, а если подойти к написанию диаграмм с должной аккуратностью, то возможно исполнение модели, как это делается в случае BPEL или EPC.
Но с одним важным нюансом: это общепринятый стандарт, поддерживаемый мировыми гигантами. Т.е. если BPEL — задумка неплохая, но не сильно удобная для бизнес-пользователей и очень слабо поддерживаемая, если EPC — гибкая, удобная и современная нотация, используемая к тому же в рамках очень мощной методологии ARIS, но поддерживаемая по сути только Software AG и SAP (при этом SAP — лидер на рынке ERP, но это только настраивает против остальных участников рынка), то BPMN — не только простая (на описательном уровне) и понятная нотация, но она еще и продукт очень непростого согласия нескольких мировых гигантов (включая упомянутые выше Software AG и SAP, но далеко не только).
Она (BPMN) не зависит от конкретных методик, что с одной стороны как бы добавляет работы аналитикам, с другой — делает ее гибкой и универсальной. В задумке, правильно задокументированные диаграммы должны иметь возможность быть перенесены из системы одного производителя в другую без потери смысла и функциональности.
Вернемся к нашему вопросу — итак, теперь мы имеем процесс, как некий понятный алгоритм действий, который начинается стартовым событием-триггером и завершается одним или несколькими вариантами финальных событий. Т.е. некая четкая инструкция для пользователей или автоматизированных систем, что, когда и в каком случае нужно делать.
Более того, сам процесс это не совсем аналог "потока работ", work flow, т.к. различные "пулы", содержащие такие аналоги, как бы "общаются" между собой, передавая информацию и отображая, таким образом, достаточно большую общую картину процесса.
Пример:
В итоге, обычно имеем некий стратегический принцип понимания процесса как превращения входов в выходы, что удобно при рассмотрении общих вопросов стратегии, архитектуры предприятия и т.п., а также более детальный "событийный" вариант изображения процесса, который может с любой заданной точностью показать алгоритм действий, с указанием времени, исполнителей и любой информации, которую аналитик посчитает нужным упомянуть (в виде аттрибутов можно указать всё, что угодно).
Второй вариант становится де факто стандартом, он сейчас активно используется в т.н. системах управления бизнес-процессами, которых уже множество и которые очень разные, от встроенных в другие системы до максимально независимых, включая с открытым кодом.
Для людей бизнеса просто важно понимать, что есть разные подходы, и наиболее два популярных из них не похожи друг на друга (кстати, в рамках семейства IDEF их пытались "поженить", но широкой популярности из-за сложности эти нотации не получили) и используют разные принципы. Поэтому, например, когда звучит фраза "я наладил там бизнес-процессы", надо понимать, речь о стратегических вещах, наведен порядок в плане что куда входит и выходит, или речь о более процедурных, если можно так выразиться, моментах, когда оптимизация коснулась не только каких-то общих вещей, но и деталей исполнения работ, возможно, вплоть до мельчайших.
Стратегические моменты, как правило, интересны собственникам бизнеса, топ-менеджерам, инвесторам и т.п. Тогда как, предполжим, разработчикам они крайне редко нужны. Их больше интересует как раз последовательность действий, а не что подается на входе и потом превращается в результат.
Популярность "событийного" подхода обусловлена также широкими техническими возможностями, которых не было раньше. Это, в первую очередь, автоматизация разного уровня, от "естественного" функционала в один шаг (нажал кнопку — сформировался документ, например) до достаточно сложных цепочек и далее, до автоматического принятия решений (это направление сейчас переживает бурный рост) и до искусственного интеллекта.
Что такой подход может дать руководителю? Если общей фразой — возможность более эффективно управлять процессами.
Более понятным языком, наверное, лучше сделать на примере.
Итак, есть, скажем, простой процесс. Стартовое событие: пользователь клиент-банка оформляет заявку на продажу находящейся у него на счете валюты. Казалось бы, дальше всё просто. Заявка рассматривается (я не знаю, делаю предположения), далее идут какие-то действия сотрудников банка, валюта продается, деньги поступают на счет, вуаля, всё просто. Если что-то в заявке не так, сотрудник связывается с клиентом, решает проблему, далее опять по накатанному.
Однако, в жизни несколько иначе (пересказываю реальный кейс).
Пользователь оформляет заявку, но у него возникает вопрос по одному пункту (он оформляет в первый раз и не знает). Он звонит закрепленному за ним сотруднику, сотрудник тоже не знает ответа, предлагает позвонить в колл-центр. В колл-центре разъясняют, заявка оформлена.
Пользователь должен при этом предоставить дополнительные документы в банк. Он предоставляет и ждет. Но ничего не происходит, поэтому он опять звонит эккаунт-менеджеру, та не берет трубку (видимо, занята). Клиент волнуется — а вдруг что-то не так? Может надо что-то еще предоставить, что-то еще сделать и т.п.
Очень простая процедура повлекла за собой ряд дополнительных действий и со стороны клиента, и со стороны сотрудников. Разве это оптимально? Вероятно, оптимальнее было бы, скажем, просто поставить подсказку возле того поля, которое изначально вызвало сомнения (сумма договора; что делать, если в договоре не указана сумма, если он о сотрудничестве "вообще"? Ноль оставить нельзя, разгадка — просто указать сумму продаваемой валюты, никаких вопросов от банка при этом не будет, но кто ж знал).
Далее, было бы оптимально, уведомлять клиента, если он того хочет, о ходе процедуры. Чтобы не было сомнений и волнений, которые потом превращаются в звонки в банк, отнимая время у сотрудников.
Казалось бы, очень просто. Но повторю: это реальный кейс, это не выдумка.
Вроде мелочь, но сколько таких мелочей? По сути, руководитель мог бы повлиять на процесс (изменив его), если бы:
- он понимал, как процесс исполняется;
- имел возможность его проанализирвать;
- понимал т.н. "карту путешествия" клиента, т.е. как поступает обычно клиент и с чем он по ходу сталкивается.
Т.е., возвращаясь к нашей теме, подход к описанию процессов на более детальном, "событийном" уровне — одна из составляющих, дающих возможность реально управлять процессом. И я не имею в виду наорать на ответственного за процедуру сотрудника, я имею в виду изменить некую деталь в системе.
Естественно, помимо понимания и управления собственными процессами, неплохо бы и знать, как себя ведет и какие сложности испытывает клиент, — но об этом в другой раз.
Сейчас же надеюсь, практический смысл разных подходов к описанию процессов стал теперь более понятен. :)
No comments:
Post a Comment