Приступая к BPM: введение

Оригинал: Getting Started With BPM: Introduction
Авторы: Sandy Kemsley, Steve Russel

Суть управления бизнес-процессами (BPM) – оптимизация производительности сквозных процессов. BPM включает методологию процессного усовершенствования и поддерживающие ее инструменты. К методологии относятся, например, способы сбора информации о процессов («выявление» процессов) и методы процессной оптимизации, а инструменты включают в себя BPA (Business Process Analysis) для моделирования и анализа процессов и BPMS (Business Process Management Suite) для их автоматизации.

BPM – концепция не новая, но она продолжает быстро развиваться и приносить новую пользу. В прошлом ландшафт BPM серьезно изменили социальный BPM, аджайл и технологи кейс-менеджмента. Мы также наблюдаем изменения в том, как бизнес использует методы и инструменты BPM: больше совместной работы и больше контроля за порядком работы со стороны бизнеса.

В настоящей статье мы рассмотрим спектр вопросов от бизнеса и методологии до технологий:

1. Принцип золотой середины: правильный выбор первого процесса

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

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

Если только целью внедрения BPM в вашей компании не являются административные процессы, находящиеся в стороне от основного бизнеса, не выбирайте один из таких процессов в качестве первоначального. Не потому, что такие процессы нельзя улучшить – вероятно, можно – просто не рассчитывайте, что в компании будут в восторге от BPM, если вы продемонстрируете, как он может улучшить процесс оформления авансового отчета. Если для начала внедрения выбрать процесс, не обладающий ценностью, то мало кого будет волновать, преуспели ли вы. Хотя риск внедрения будет низким, но вы подвергнете риску всю будущую программу BPM, так как вы не воспользуетесь первым проектом для доказательства ее потенциальной ценности. Мало того — даже если вы получите одобрение второго проекта, может получиться так, что при переходе от административных процессов к основным мало что из методологии и инструментов удастся использовать. Чтобы продемонстрировать эффективность с точки зрения итоговых показателей организации, первый процесс должен быть одним из тех, что важны для бизнеса — основной процесс, в рамках которого работники ежедневно выполняют критичные задачи.

Выбор основного бизнес-процесса потребует тщательного управления рисками в ходе планирования проекта:

Ограничьте первую продуктивную итерацию минимальной функциональностью, которая вместе с тем представляет ценность, и минимально возможной кастомизацией. Скорее всего вы будете иметь дело с ручным процессом, поэтому эффект даст любое повышение удобства использования и автоматизация. Избегая усложнения проекта, вы сможете что-то запустить в промышленную эксплуатацию в короткий срок – от 90 до 120 дней, и это даст пользователям возможность оценить эффект и потенциал BPM. Обычно это означает, что BPMS будет раздавать задания при минимальной интеграции с другими системами.
Везде, где это возможно и практично, предоставьте пользователям максимум гибкости. Если BPMS умеет управлять динамическими процессами, дайте пользователям к ним доступ, чтобы можно было охватить недостаточно зрелые процессы и креативную работу, для которой структурированные процессы подходят не лучшим образом.
Начните с группы пользователей-лидеров, возможно в пределах одного подразделения, чтобы минимизировать передачу ответственности между BPMS и ручными процессами, затем выходите за его пределы. Планируйте управление сквозным бизнес-процессом в качестве конечной цели и стремитесь в первую очередь к ширине охвата (больше процесса), а не к глубине (больше функциональности на каждом шаге), так как требования к функциональности зачастую меняются с расширением рамок процесса.
Принимайте решение о расширении функциональности следующих итераций на основе отзывов пользователей после того, как они начали использовать систему в повседневной работе, а не на основе требований, написанных до того, как кто-нибудь приобрел практический опыт с BPMS.
Когда производительность пользователей достигнет приемлемого уровня, начните реализовывать технологически более сложную интеграцию с унаследованными приложениями, имея в виду возможность повторное использование этой функциональности.

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

2. Вовлекайте бизнес, чтобы обеспечить успех проекта

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

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

Если попытаться разобраться что не так в этом подходе, мы обнаружим несколько факторов:

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

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

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

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

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

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

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

И еще один, последний фактор:

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

3. Добейтесь востребованности со стороны пользователей

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

Преодоление сопротивления изменениям – ключ к востребованности со стороны пользователей

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

Два ключевых момента для перехода: во-первых, правильное проектирование и разработка приложения, и во-вторых, правильное управление изменениями.

Шесть советов по проектированию и разработке приложений, которые будут востребованы пользователями

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

Привлеките дизайнера пользовательских интерфейсов, который знает, как делать их производительными и простыми в использовании, а не просто симпатично выглядящими.
Заставьте дизайнера прошагать милю в ботинках пользователя (точнее, набрать милю на его клавиатуре). Пока дизайнер не будет полностью представлять себе весь спектр действий, выполняемых пользователем в его работе, он не сможет спроектировать годный с точки зрения пользователя интерфейс. Само собой разумеется, надо привлекать пользователей к проектированию интерфейсов, но не делайте этого без участия опытного дизайнера, знакомого с работой пользователя.
Удобство использования – вещь персональная: сосредоточьтесь на создании пользовательского интерфейса, экономящего время и переходы, требуемые для самых распространенных функций для каждой конкретной роли. Например, парадигма кейс-менеджмента с наиболее востребованной информацией о клиенте и ссылками на наиболее типичные запросы клиентов поможет сократить время ответа службы клиентской поддержки, так как оператор сможет отвечать на вопросы клиента и принимать заказы клиента на новые услуги с минимумом навигации. В случае операторов ввода данных, которым для эффективного выполнения их работы больше подойдет парадигма очереди задач, ориентированных на транзакции, эффективный пользовательский интерфейс будет совсем другим.
Создайте пользовательский интерфейс, который предоставит пользователям возможность его кастомизировать или конфигурировать. Даже если они участвуют в одних и тех же процессах и выполняют одни и те же задания, разные пользователи могут предпочесть организовывать свою работу в этих рамках по-разному, точно так же как они могут предпочитать по-разному организовывать свой физический рабочий стол. Например, дайте возможность по-другому расположить визуальные компоненты на экране, отсортировать списки задач, настроить напоминания и уведомления, поменять шрифты и цвета. В случае работников умственного труда, работающих с системой кейс-менеджемента, реконфигурация может быть весьма радикальной; для операторов, работающих с транзакциями, она скорее всего будет более скромной, но все же нацеленной на кастомизацию рабочей среды, делающую ее наиболее для них удобной.
Интегрируйтесь с другими технологиями и системами напрямую, чтобы сократить повторный ручной ввод информации. «Интеграция через вращающийся стул», при которой пользователь считывает информацию из одного приложения и вводит ее в другое, не только неэффективна и провоцирует ошибки — она также является сильным демотиватором для пользователей, говоря им, что время, которое они ежедневно тратят на эту работу, менее важно, чем время разработчика, которое ему надо однократно потратить на интеграцию.
Убедитесь, что BPM-платформа, которую вы выбираете, способна поддерживать такой подход к разработке. Есть много платформ, предлагающих очень гибкий пользовательский интерфейс, дающих возможность разработчику тщательно спроектировать наиболее удобный для пользователя интерфейс. Некоторые продукты ограничивают пользовательский интерфейс предопределенными формами или сильно урезанным фреймворком. Если используется предоставляемый вендором фреймворк, то важно убедиться, что он дает разработчикам возможность легко конфигурировать и расширять приложения.

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

Шесть советов по управлению изменениями, позволяющих добиться постоянной приверженности

От разработки хорошего BPM-приложения, облегчающего людям их работу, до приверженности с их стороны долгий путь. Чтобы закрепить успех, вы должны прибегнуть к управлению изменениями. Тут необходимо учитывать ряд вещей:

Убедитесь, что вы с самого начала вовлекли конечных пользователей и участников процесса. Раннее вовлечение уменьшает общий риск, и исследования показывают, что вовлечение пользователей в проводимые вами изменения на ранней стадии приводит к 25% сокращению затрат. С точки зрения управления изменениями, этот подход обеспечивает большую востребованность в начале и помогает избежать отката назад, к менее эффективным способам работы.
Необходимо также правильно обучать пользователей. Большая ошибка считать, что если пользователи способны навести и кликнуть мышку, то они не нуждаются в обучении: обучение по большей части направлено не на то, как использовать приложение, а на то, как использовать приложение для выполнения их конкретной работы. Обучение должно включать примеры из реальной жизни, сессии реальной работы и непрерывную опеку. Операционные регламенты должны быть переписаны, чтобы отразить использование нового приложения. Например, некоторые шаги в операционных регламентах можно сократить или исключить, потому что BPMS их автоматизирует, или же операционный регламент может быть полностью включен в пользовательский интерфейс BPM-приложения.
Если в течение некоторого времени новое приложение и существующие системы будут эксплуатироваться бок-о-бок, то процедура перехода должна быть задокументирована. Например, в течение некоторого времени BPM-приложение может использоваться только для работы с новыми клиентами, а существующие могут продолжать обрабатываться старыми системами и процедурами.
Метод сбора откликов пользователей на операционные регламенты и BPM-приложение. Рассмотрите возможность использования wiki для операционных регламентов, чтобы пользователи могли править эти регламенты самостоятельно, если они находят лучшие способы делать работу, и ясные процедуры подачи заявок на доработку самого приложения.
Примите во внимание культурный барьер, связанный с уменьшением использования электронной почты и распечаток. Одно из преимуществ BPM заключается в том, что он сохраняет аудиторский след — кто выполнял какие действия в процессе. Так что если менеджер, авторизовавшийся в системе, одобрил транзакцию в рамках BPM-приложения, то дополнительная бумага об одобрении транзакции, подписанная этим менеджером, может быть уже не нужна. Нет никаких требований закона или регулятора для множества бумажных форм и отчетов с подписями, ежедневно курсирующих по офисам – только «мы всегда так делали».
Измените систему стимулов и поощрений, направив их на правильное использование новых регламентов и систем. Это сильно зависит от специфики работы, но в качестве примера можно вознаграждать работников за сделанный ими вклад в wiki операционных регламентов.

Резюмируя, иметь замечательное новое приложение недостаточно: работники вдобавок должны захотеть им пользоваться. Вы можете стимулировать востребованность, выбирая BPM-решение, поддерживающее разные роли и предоставляющее среду, поощряющую пользователей в использовании приложения.

4. Природа работы: структурированная и неструктурированная

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

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

Тэйлор против Друкера

Чтобы задать контекст для противопоставления рутинного и умственного труда, рассмотрим различия между взглядами Фредерика Тэйлора и Питера Друкера. Тэйлора можно считать отцом структурированного BPM: он был инженером-механиком, увлеченным вопросами производительности в промышленности. Он верил в анализ потоков работ при помощи метода, который стали называть научной организацией труда: его сутью является определение наиболее эффективного пути исполнения определенного процесса на основе исследований времени и перемещений, затрачиваемых на производство. Если рассмотреть сегодняшний BPM, то в том, как мы анализируем и реализуем процессы, в особенности полностью автоматические, есть большая доля наследия Тэйлора. И действительно, для полностью автоматических (straight-through) процессов стандартизация процесса с целью оптимизации – отличная идея.

Однако не все процессы возможно анализировать таким способом: есть множество бизнес-ситуаций, когда мы просто не знаем точной последовательности шагов, которые должны быть сделаны для выполнения задания. Мы должны приступить к заданию, а затем использовать для определения последующих шагов информацию, поступающую в ходе процесса. Для описания того, как такие процессы и участвующие в них люди должны работать, Друкер изобрел термин «управление по целям» (management by objectives): вы устанавливаете цель и даете возможность человеку выбирать наилучший порядок действий, приводящий к ее достижению. Это и есть умственный труд.

Покорение непредсказуемого

Кейт Свенсон хорошо об этом сказал в недавней книге «Mastering the Unpredictable» («Покорение непредсказуемого»), посвященной адаптивному кейс-менеджменту:

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

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

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

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

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

BPMS и кейс-менеджмент

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

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

Чтобы эффективно помогать работникам умственного труда, системы кейс-менеджмента должны сочетать возможности BPMS, систем управления контента (ECM), систем управления бизнес-правилами и поддержки совместной работы, и хранить полную историю кейса для аудита и в помощь тем работникам, которые подключаются к кейсу на середине пути. Работники умственного труда зачастую являются продвинутыми пользователями, и они оценят возможность конфигурировать персональное рабочее место, так чтобы оно было максимально приспособлено для решения их задач; это привело к тому, что возможность самостоятельного конфигурирования пользователем также стала достаточно стандартной функциональностью во многих системах кейс-менеджмента.

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

5. Оценка успеха

После того как BPM-решение реализовано, вам надо продемонстрировать его выгоды, чтобы оправдать дальнейшее развертывание BPM в вашей организации. Измерение успеха требует определенной предварительной работы – такой, как замер исходных показателей процесса для сопоставления в будущем – а также расчета полученного «твердого» (hard) эффекта: сокращения расходов или увеличения доходов. Необходимо также обратить внимание на «мягкие» (soft) и «прорывные» (disruptive) эффекты – хотя их сложнее измерить и даже предвидеть, они могут дать намного больший выигрыш в долгосрочной перспективе.

ROI = сравнение до и после

Единственный способ преуспеть в оценке результатов вашей BPM-инициативы – это сравнение состояния «после» с отправной точкой «до». Насколько, по мнению сторонников реинжиниринга, вы обязаны игнорировать «as-is» при проектировании «to-be», настолько же вы не можете игнорировать стоимость вашего «as-is», если вы впоследствии рассчитываете обосновать экономическую эффективность инициативы. Это не значит, что вы должны смоделировать каждый существующий процесс и сосчитать каждую скрепку, но это значит, что у вас должно быть представление о стоимости действий, которые могут измениться в результате внедрения BPM.

Каждый проект BPM может давать несколько измеримых выигрышей, включая «hard» и «soft» — мы их рассмотрим в деталях ниже. Ключ к измерению успеха – составить список ожидаемых выигрышей, измерить и задокументировать текущее состояние как отправную точку и после внедрения измерить и задокументировать новое состояние, чтобы оценить сокращение издержек и повышение доходов. Это то, что относится к «возврату» в формуле возврата на инвестиции (ROI, Return On Ivestments).

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

После того, как вы составили представление о суммах возврата и инвестиций, вам надо выяснить, как в вашей организации рассчитывается возврат на инвестиции. Обычно ROI рассчитывается как окупаемость – период времени, за который эффект окупает затраты. В простейшем виде, если вы собираетесь вложить в проект $1200 и он будет экономить $750 в год, то окупаемость составит 1200/750 = 1,6 лет. Другими словами, через 1,6 лет вы окупите свои инвестиции и продолжите экономить $750/год без дополнительных вложений.

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

Что в вашем ROI

Многие проекты BPM стартуют с прицелам на определенный ROI: сокращение численности персонала или управление растущим бизнесом без увеличения численности за счет повышения эффективности. Всегда есть несколько факторов, которые стоит рассмотреть с точки зрения потенциального эффекта, и их можно поделить на «hard» и «soft».

«Hard» эффект обычно заключается в сокращении затрат в результате внедрения BPM (или в избежании дополнительных затрат в ситуации роста). «Soft» эффект обычно заключается в увеличении доходов или сокращении затрат благодаря прорывным изменениям в вашей бизнес-модели. Выражаясь слегка цинично, «hard» ROI – это то, с чем согласится ваш бухгалтер, а «soft» — это то, что должно случиться, если верить словам продавца. Реальность обычно где-то посредине.

Ниже следует список типовых «hard» и «soft» факторов – вам надо определить, какие из них применимы к вашей ситуации.

«Hard» эффект складывается из следующих факторов:

Сокращение численности персонала за счет повышения производительности и автоматизации, а также сокращения накладных расходов на офис, системы и поддержку
Сокращение числа ошибок за счет автоматической интеграции систем по данным и улучшенного контроля над процессом
Замена высокооплачиваемых работников низкооплачиваемыми в исполнении функций, в которых задачи могут быть упрощены за счет автоматизации
Сокращение времени от начала до конца сквозного процесса и достижение более высоких показателей SLA (Service Level Agreement, соглашение об уровне сервиса), влияющих на удовлетворенность заказчиков, а также исключение штрафов за нарушение SLA
Сокращение времени внесении изменений в процесс, особенно изменений, связанных с требованиями регулятора
Сокращение усилий на измерение показателей процесса и устранение таких не добавляющих ценности задач, как ручное ведение журналов, использовавшееся для измерения
Сокращение времени, за которое заказчик или третья сторона получает извещение о продвижении процесса, за счет их автоматизации

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

Сокращение затрат и времени на обработку бумаг
Сокращение затрат и времени на хранение и извлечение бумаг
Сокращение затрат и времени на печать и копирование бумаг

«Soft» эффект складывается из:

Аутсорсинг или оффшоринг определенных задач или целых процессов менее высокооплачиваемыми работниками в других городах, или разрешение сотрудником работать из дома для сокращения офисных издержек. Поскольку BPM позволяет разные задачи в процессе назначать разными исполнителям, некоторые ответственные задачи могут выполняться персоналом на дому, в то время как другие задачи, такие как ввод данных, направляются внешним исполнителям.
Повышение лояльности и удовлетворенности клиентов благодаря более быстрым и более эффективным процессам. В конкурентных отраслях лояльность клиентов является важным фактором, на который оказывают влияние взаимодействующие с клиентами процессы. Известен случай, когда компания, предоставляющая услуги обработки финансовых транзакций, была исключена из рассмотрения в качестве поставщика услуг потенциальным заказчиком из-за того, что не внедрила BPM и как следствие, не могла обеспечить требуемый уровень сервиса.
Сокращение затрат за счет самообслуживания клиентов, в частности в области мониторинга процессов. Если клиент имеет возможность непосредственно следить за прогрессом своего процесса, то он будет реже обращаться за помощью в колл-центр. Это имеет отношение к «hard» эффекту сокращения времени на извещение клиентов, но идет дальше простого извещения, позволяя заказчикам выполнять некоторые операции самим – например, такие, как изменение адреса. Это относится к категории «soft», так как нет гарантии, что заказчики воспользуются функциональностью самообслуживания.
Увеличение производительности, дающее возможность поднять доходы без увеличения численности персонала. Хотя это является оборотной стороной повышения эффективности и сокращения численности в разделе «hard», его все же часто относят к «soft», так как нет гарантии, что организация способна увеличить продажи при возросшей производительности.
Сокращение времени выхода на рынок для процессов разработки новой продукции. Опять-таки, это то же самое, что сокращение времени цикла, о котором шла речь выше, но тут мы полагаемся на то, что более оперативный вывод продукции на рынок даст выигрыш (возможно, не поддающийся измерению).

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

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

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

6. Переход к более широкому внедрению в организации

Реализация первого проекта BPM – это большое достижение, но нельзя на этом останавливаться: вы должны искать пути широкого внедрения BPM в организации и достижения большего эффекта. Одна сторона дела – это обобщение опыта, полученного на первом проекте, с целью его повторного использования, возможно через Центр передового опыта BPM; но кроме этого, надо, чтобы правильные люди стали проводниками правильной информации.

Найдите евангелиста

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

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

Используйте ROI для расширения области применения

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

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

Создайте Центр передового опыта

Переход от BPM-проекта к программе BPM в значительной степени есть использование того, что вы разработали в рамках первоначального проекта, обычно через создание Центра передового опыта (CoE, Center of Excellence). Без него практически невозможно обойтись, если речь идет о поддержке широкого распространения BPM, причем создание CoE не должно требовать больших и дорогостоящих усилий; самое важное – это собрать ценные находки из начальных проектов, которые могут быть повторно использованы, и людей, которые могут помочь новым проектам BPM. К таким находкам могут относиться программные компоненты, методологии, стандарты, лучшие практики или любые другие артефакты, созданные в рамках начального проекта. Чтобы сделать их доступными через Центр передового опыта, может понадобиться рефакторинг для стандартизации и обобщения на другие ситуации.

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

Превратите проект в программу

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

Об авторах

Сэнди Кэмсли (Sandy Kemsley) является независимым аналитиком и системным архитектором, специализирующимся на BPM, Enterprise 2.0, Enterprise Architecture и Business Intelligence. Помимо технических компетенций, она работала на той стороне проектов, которая обращенна к бизнесу — от бизнес-требований и анализа до технического проектирования и внедрения.

За свою более чем 20-летнюю карьеру она создавала и управляла успешными продуктовыми и сервисными компаниями, включая компанию с десктопным workflow и document management продуктом в 1988-90 и фирму из 40 человек, специализирующуюся на BPM и электронной коммерции в 1990-2000. В период 2000-2001 Сэнди работала в FileNet (ныне IBM) в качестве Director of eBusiness Evangelism в период запуска их BPM продукта eProcess, и в это время выступала в качестве приглашенного докладчика на темы BPM и его воздействия на бизнес на конференциях и у заказчиков в более чем 14 странах.

В 2001 Сэнди вернулась к частной консалтинговой практике в качестве BPM-архитектора, выполняя обязательства перед финансовыми и страховыми организациями по всей Северной Америке и работая с поставщиками BPM в качестве аналитика. Сэнди также разрабатывает и преподает учебные курсы по BPM и смежным темам.

Стив Рассел (Steve Russell) занимает позиции Старшего вице-президента по исследованиям и разработки и CTO в компании Global 360 Inc., расположенной в Далласе, Техас. У него более чем 25-летний опыт разработки программного обеспечения и платформ для корпоративных бизнес-процессов и управления документами. Стив обладает обширным опытом разработки и внедрения больших, критичных для бизнеса систем в компаниях, входящих в Fortune 2000.

Обсудить