Если без проектов организация пусть и с трудом, но жить может, то без процессов ни она, ни ее проекты существовать не смогут.
Хочу призвать вас вдуматься в заголовок — управлять бизнес-процессами. Мне сразу приходит на ум диалог Воланда и Берлиоза. В применении к бизнес-процессам он мог бы звучать так: «Неужели вы думаете, что можете ими управлять... Кто подвесил, тот и перережет...» То есть, если этот многоликий таинственный бизнес подвесил, то он и управит. А кто он, этот бизнес? Собственник? Вряд ли он сможет и захочет. Руководитель компании? Тоже сомнительно. Менеджеры среднего звена? Разве кто-то из них так понимает свою задачу? Кто же тогда? Попробуйте отыскать в организации того, кто управляет бизнес-процессами. Поверьте, это очень нелегко.
Упростим задачу. Давайте поищем сами бизнес-процессы. Возможно, тогда отыщется тот таинственный незнакомец (или незнакомка), который ими управляет. Попросите сотрудника компании перечислить бизнес-процессы. Не может? А хотя бы те, с которыми работает? Рядовой сотрудник станет рассказывать про свои отдельные действия, в лучшем случае вспомнит о бизнес-функциях. Руководитель подразделения — по-разному склонять название своего подразделения. У вас не так? Тогда мы идем к вам (за опытом. А вы что подумали?).
Процессному подходу уже более 70 лет. Однако внедрение процессного подхода в России идет удивительное медленно. Роли менеджера процесса и владельца процесса встречаются крайне редко, и они намного экзотичнее руководителя или спонсора проекта. Возможно, это связано с регулярностью получения бонусов последними. Однако если без проектов организация пусть и с трудом, но жить может, то без процессов ни она, ни ее проекты существовать не смогут.
Определения
Займемся определениями (кто сказал, что этого не надо?). Процесс — это логическая последовательность связанных действий, которые преобразуют вход в результаты или выход. Бизнес-процесс — это процесс, результатом которого являются продукты или услуги для потребителей. Не все процессы компании являются бизнес-процессами. Так, большинство процессов ИТ не относится к бизнес-процессам. Кроме бизнес-процессов принято выделять процессы документооборота, а для промышленных компаний — технологические процессы (см.рис1). В государственных организациях по понятным причинам существуют деловые процессы.
Рис. 1. Бизнес-процесс и технологический процесс
Мода на описание и моделирование бизнес-процессов прокатилась и схлынула. Где-то остались пылящиеся в архивах тома схем, где-то — привычка рисовать бизнес-процессы и даже обсуждать их с коллегами. Однако практически не встречала, чтобы к проектированию бизнес-процессов научились подходить с той же серьезностью, что и к любой другой инженерной деятельности. Ощущение ответственности за созданный техническими инженерами объект — сооружение, машину, аппарат — несоизмеримо выше, чем бизнес-инженеров — за предприятие. Чаще всего бизнес-процессы складываются в практической деятельности подразделений и напоминают тропинки, протоптанные жильцами новостройки до ближайшей автобусной остановки. Хоть и грязно, да и неудобно, но ходим. Кто-то досочку подложил, кто-то в обход пошел. Когда уже научимся строить дороги? Когда начнем проектировать удобные и надежные бизнес-процессы?
Однако тут есть и объективные причины. Мир вокруг стремительно меняется. Мы видим это почти ежедневно на примере ИТ. Технологии растут как грибы, и не все из них поганки. Не замечать эти изменения опасно и даже преступно по отношению к компании и ее деятельности. Однако жесткие БП (особенно, если они недостаточно грамотно спроектированы) зачастую затрудняют использование новых возможностей и разворот компании к новому курсу.
Реинжиниринг БП (РБП) позволяет проанализировать текущий БП, учесть потребности рынка, компании и появившиеся технологии и перепроектировать БП по-новому. Проекты РБП многократно описаны и не менее многократно раскритикованы. Можно относиться к РБП по-разному. Однако по мере роста скорости изменений РБП не успевает за ними, и компания постоянно находится в состоянии догоняющей рынок. Поэтому на смену РБП пришла процессная технология управления бизнес-процессами (BPM или УБП), которая, как было сказано на одной из недавних конференций, уже не является чем-то новым, а просто общераспространенной методикой управления. Мне кажется, что до такого состояния российским предприятиям еще довольно далеко. Большей частью БП живут своей жизнью и управляют ими, хорошо если от случая к случаю.
ВРМ и ИТ
ВРМ имеет один важный для нас с вами аспект. Если РБП рассматривал ИТ как удобный, но не необходимый инструмент, то эта технология практически невозможна без грамотной автоматизации БП. Определения ВРМ включают этот важный момент. Например, мне больше всего нравится такое: «ВРМ — это одна из современных управленческих методик, включающая идеологию, направленную на повышение эффективности цепочки создания ценности для конечного потребителя товаров или услуг, и инструменты ИТ для гибкого управления бизнес-процессами».
Есть ли смысл в сочетании «гибкого управления бизнес-процессами и ИТ»? Ведь если процесс автоматизирован, то любые изменения БП потянут изменения в ИТ: в прикладных системах, а то и в других архитектурных слоях. Тут на помощь приходят платформы управления бизнес-процессами, которые в избытке предлагаются на современном рынке средств автоматизации. Такие платформы позволяют относительно быстро собрать бизнес-процесс и перестроить его в случае необходимости. Однако мне хотелось бы предостеречь читателя от излишнего оптимизма. Так же как невозможно получить золото из других материалов путем волшебных превращений, так и нельзя никакими пассами настроить автоматизированный БП на любую логику. Это можно сделать только в определенных пределах, правила для которых можно сформулировать следующим образом:
1. Система настраиваема в таком объеме, который был заложен в нее при проектировании.
2. Чем шире возможности настройки системы, тем она сложнее, менее надежна и устойчива, сложнее в обслуживании.
3. Для любой системы (в том числе ВРМ) работают правила жизненного цикла, то есть наступает момент, когда от существующей системы лучше отказаться, создать и внедрить новую, а старую аккуратно вывести из эксплуатации.
Лучше — имеется в виду дешевле, правильнее с точки зрения оперативных или стратегических задач, разумнее для эффективности архитектуры предприятия.
В любом случае управление изменениями (УИ) является важнейшим для ВРМ процессом, которому еще на ранних стадиях внедрения необходимо уделить серьезное внимание. УИ необходим:
• как барьер для опасных для работоспособности БП изменений, неважных и ненужных изменений, противоречивых изменений;
• как средство упорядочивания и управления изменениями, их приоритизации в порядке, наиболее подходящем конкретной компании и соответствующей ее бизнесу и месту на рынке;
• как средство согласования приоритетов изменений и поддержки баланса между интересами отдельных групп заинтересованных лиц;
• как средство влияния на жизненный цикл ВРМ-системы.
С управлением изменениями тесно связан другой важнейший для ВРМ процесс — управление архитектурой (см. рис.2). Любое изменение должно проходить архитектурную проверку, то есть поддерживаться всеми архитектурными слоями вплоть до инфраструктуры и средств связи. ВРМ находится на самом верхнем уровне архитектуры предприятия. Именно поэтому изменения требуют скрупулезного и обоснованного управления. В противном случае процесс просто развалится. Да и вся архитектура предприятия может оказаться под угрозой.
Рис. 2. Место ВРМ в архитектуре предприятия
Системы ВРМ относятся к системам зонтичной интеграции, объединяя прикладные системы, автоматизирующие подпроцессы и отдельные функции (зонтичная интеграция — объединение различных программных систем единой логикой и единым средствами доступа пользователей без организации прямого взаимодействия между системами). Именно поэтому проекты внедрения ВРМ настолько сложны. Именно поэтому процессам управления изменениями и управления архитектурой как с технической, так и с организационной точки зрения надо уделять большое внимание.
Автоматизация бизнес-процессов и технологических процессов
Возможно, именно преступное небрежение к этому представляет собой разгадку, почему бизнес-процессы столь некачественно автоматизированы. Если бы подобный уровень качества присутствовал в автоматизации технологических процессов, то боюсь, нас с вами уже бы не было, а Земля бы не существовала. Для поддержки требуемого качества ИТ есть технологии, стандарты, лучшие практики, опыт автоматизации технологических процессов (ТП). Почему бы это не использовать? Специалисты по автоматизации ТП (а я и себя отношу к их числу), почему же вы не займетесь этим вопросом? Я вот пишу эту статью хотя бы.
========================================
Некоторые рекомендации от автоматизации ТП до автоматизации БП.
1. Формируйте требования вместе с заказчиками и пользователями. Надеюсь, что все понятно: это разные роли и за ними часто — разные люди. При формировании требований к ВРМ обычно о ком-нибудь забывают, а иногда и об обоих.
2. Стройте архитектуру АС, а не один слой, который провисает и в итоге рушится. Учитывайте все слои при планировании, расчете бюджета, управлении и сопровождении.
3. Выявляйте критические участки и обеспечивайте для них дублирование (а то и тройное резервирование — если надо)
4. Не экономьте на тестировании и тестовых средах. Проверяйте все и в максимально приближенных к полевым условиям вместе с пользователями и заказчиками.
5. Уделяйте серьезное внимание обучению и документации.
6. Внимательно относитесь к параметрам времени и прочим удобствам работы пользователей.
7. Соблюдайте баланс между изменениями и качеством АС и всей ее архитектуры.
==========================================
Вы можете возразить, что кроме сходства между БП и ТП существуют серьезные различия. Не буду сопротивляться.
• БП намного сильнее интегрированы.
• В БП присутствует сильная обратная связь.
• БП обычно менее стабильны.
• ТП больше работают с оборудованием, роль человеческого фактора в БП намного выше.
Однако эти отличия не означают, что к автоматизации БП надо подходить менее осторожно и внимательно, чем к автоматизации ТП. Скорее — наоборот.
Прошлое и будущее ВРМ
Когда стоит или когда можно заняться внедрением ВРМ-систем? Распространено мнение, что автоматизировать можно только тогда, когда они устоялись, стабилизировались. Но в современном мире такой ситуации можно и не дождаться. Означает ли это, что управление бизнес-процессами обречено? Нет, выход видится в том, чтобы спроектировать БП таким образом, чтобы предоставить ему определенную свободу и автоматизировать, эту свободу не потеряв. Конечно, это требует высокого уровня инжиниринга и автоматизации.
Если убрать аббревиатуру и заглавные буквы, то ВРМ — это, в сущности, просто управление бизнес-процессами, которое так или иначе, пусть хаотично и частично не осознано, происходит всегда. Возможно, именно поэтому многие и не видят в ВРМ ничего нового. Другое распространенно заблуждение приравнивает ВРМ к документообороту. Для этого также есть определенные основания. Ведь большинство поставщиков систем документооборота предлагают и ВРМ -системы. Однако если документооборот — это обращение документов, то workflow — поток работ — автоматизация отдельный работ или бизнес-функций, а ВРМ — управление бизнес-процессами, workflow для бизнес-процессов на новом уровне.
Дальше развитие этой цепочки связывают с системами управления предприятием на основе информации IРM, когда деятельностью компании будут управлять не с помощью документов, а используя информацию, системами CaseManagement — управление организацией по событиям и игровыми принципами управления предприятием.
Другие перспективы развития BPM — использование в бизнес-процессах социальных систем и краудсорсинга, привлечение к выполнению бизнес-процесса широких социальных слоев.
Я очень надеюсь, что именно ВРМ позволит «причесать» бизнес-процессы отечественных компаний. Недаром, чтобы написать эти три буквы не требуется переключать регистр.
