Литература:

• Статьи
• Обзоры
• Форумы
• Стандарты
• Книги
• Авторы

Оригинал статьи: Sandy Kemsley, Steve Russel, «Getting Started With BPM: Introduction»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1) Практикуйте совместное выявление процесса

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

2) Получайте отклик через средства визуализации

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

3) Разрабатывайте итеративно, через прототипы

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

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

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

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

4) Поделитесь правами и ответственностью за эксплуатацию

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы узнать больше о кейс-менеджменте и о разновидностях ad-hoc и неструктурированных процессов, для которых он может быть полезным, скачайте бесплатный отчет Форрестер: «Dynamic Case Management, An Old Idea Catches Fire».

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 и смежным темам.

Вы можете связаться с Сэнди по адресу sandy-at-column2.com.

Стив Рассел (Steve Russell)

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

Вы можете связаться со Стивом по адресу steve.russell-at-global360.com.

Комментарии