Литература:

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

Автор: Glenn Smith, ведущий консультант Appian
Дата: 28.01.09
Оригинал статьи: How Good Does a Process Definition Need to Be?
http://www.ebizq.net/topics/human_centric_bpm/features/10910.html

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

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

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

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

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

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

Означает ли это, что мы должны бросить попытки и ограничить BPM-приложения рутинными задачами с небольшими или нулевыми вариациями? Конечно нет. Решение в том, чтобы перестать пытаться реализовать идеальный процесс и остановится на достаточно хорошем. Секрет успеха – в безболезненном переходе из мира заданных процессов в область неструктурированной человеческой деятельности и обратно. Системы должны допускать отклонения от заданного бизнес-процесса и правил, продолжая фиксировать решения и результаты в соответствии со стандартным процессом. Должна быть обеспечена возможность изменять определение процесса в ходе его исполнения, только для данного исполняемого экземпляра. Это должно делаться внутри процессного приложения, чтобы сохранить возможности построения отчетов и аудита.

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

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

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

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

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

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

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

Комментарии