Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


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

Литература:

Вы приняли решение, что BPM подходит вашей организации. Но что дальше? О том, как организовать команду для оценки предложений, составить запрос предложения (Request for Proposal, RFP), проанализировать ответы на него, составить шорт-лист и выбрать подходящую BPM-систему.

Автор: Andrew Spanyi

Оригинал статьи: How to Choose the Right BPM Suite: From RFP to Final Selection.

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

Определите цели и желаемые результаты

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

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

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

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

Сформируйте команду для оценки

Важно создать команду, которая будет работать над составлением RFP, оценкой и окончательным выбором. Команда должна быть достаточно небольшой для эффективного принятия решения, но при этом представлять всех заинтересованных лиц, включая бизнес-спонсоров, менеджеров по продуктам, бизнес-аналитиков, системных инженеров, ИТ-архитекторов, служб ИТ, отвечающих за эксплуатацию и техническую поддержку. Работа начинается с утверждения целей и написания RFP и продолжается просмотром вендоров, демонстрацией продуктов, фазами окончательного выбора и внедрения. В «Enterprise Rent-A-Car» внедрение BPMS, завершившееся в начале этого года, превратило бюрократическую, с большим количеством бумаг процедуру запроса ИТ продукции и услуг в высокоавтоматизированный онлайновый процесс. В состав команды входили представители 65-тысячного персонала компании и полуторатысячного персонала ИТ, но Pat Steinmann, менеджер службы заявок департамента, говорит, что в ходе проекта критически важным был вклад ИТ архитектора. Она объясняет: «он обеспечил нам надлежащую техническую оценку, избавив от выбора продукта, который удовлетворял бы нашим функциональным требованиям, но плохо вел бы себя в нашей ИТ инфраструктуре». «Его вклад простирался от постановки ключевых технических вопросов в нашем RFP, позволивших быстро исключить неподходящие продукты, до финальной шага – выполнения проекта «proof-of-concept» с выбранным нами продуктом.»

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

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

После того как вы овладеете основами BPM, вы будет знать, где в основном лежат ваши потребности – в процессах, связанных с людьми или в интеграционных. Это знание сузит начальный список кандидатов, но назначение RFP – дать вам возможность составить шорт-лист вендоров, прошедших начальный отбор. В документе RFP должно содержаться достаточно информации для вендоров, чтобы они смогли эффективно охарактеризовать как они удовлетворят вашим функциональным и техническим требованиям в таких областях, как моделирование процессов, имитационное моделирование, управление документами, бизнес-аналитика (business activity monitoring), системная интеграция и так далее. Документ должен также раскрывать ваши ожидания в части скорости разработки, требуемой степени обучения и поддержки, политики апгрейдов, времени достижения самодостаточности в работе с BPMS и легкости внесения текущих изменений в бизнес-процессы.

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

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

Организуйте встречи с демонстрацией

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

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

Переговоры с каждым вендором должны позволить команде оценить ожидаемые выгоды, привязанные к усовершенствованиям – таким, как:

  • Сокращение времени обработки
  • Уменьшение стоимости предоставления данных
  • Упрощение доступа к документам
  • Уменьшение стоимости интеграции
  • Улучшение отслеживания и аудита дел сквозь подразделения
  • Мониторинг выполняющихся дел в реальном времени
  • Автоматические сигналы, эскалации и действия
  • Устранение «бумажных» процессов, избыточного протоколирования, ручного отслеживания и телефонных звонков
  • Автоматическая сигнализация об узких местах процесса
  • Автоматическая подача, маршрутизация, рассмотрение и архивирование электронных форм
  • Более полное соответствие регулирующим требованиям
  • Более полное соответствие ограничениям по бюджету и прибыльности
  • Упрощение предоставления услуг

В конце каждой встречи с демонстрацией оценочная команда должна иметь достаточно информации для оценки пригодности BPMS, ожидаемого темпа разработки, времени для освоения продукта, качества взаимодействия с персоналом вендора. В некоторых случаях вам может понадобиться запланировать повторная встреча, чтобы кандидат мог разработать специальный вариант использования (use case) или специфичный для конкретного процесса паттерн. В зависимости от сложности начального проекта, вы можете даже захотеть выполнить более обстоятельный проект «proof-of-concept».

Сделайте окончательный выбор

Окончательный выбор должен делаться на основании материальных и нематериальных факторов, включая:

  • Скорость внедрения
  • Вероятный возврат от инвестиций
  • Время на освоение
  • Впечатления от вендора (его культура и люди) в качестве потенциального партнера

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

Если ваша фирма преуспела в принятии технологических решений на основе макро-представлений о том, куда надо двигаться, то вы можете не тратить массу времени и сил на расчет ожидаемых цифр ROI. Однако, если ваше руководство до выделения финансирования пожелает увидеть ROI, то у вас может не быть большого выбора. Тщательный расчет ROI начинается с «базовых» оценок текущей эффективности в терминах стоимости, времени, качества и производительности. Только после этого вы можете замерять ожидаемые улучшения. Оценки сокращения издержек часто делаются в терминах эквивалента полной занятости (FTE, full time equivalent) на основе устранения ручных этапов работ. Сокращение времени выполнения процесса ужимает стоимость, сокращает время отклика и повышает удовлетворенность заказчиков. Аналогично, снижение числа ошибок уменьшает затраты и так же повышает удовлетворенность заказчиков. Повышение производительности – такой, как повышение числа транзакций при той же или меньшей численности – оказывает очевидное воздействие на себестоимость.

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

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

 

Сокращение издержек

Повышение удовлетворенности заказчиков

Время

Сокращение цикла обработки

Ускорение обработки
Уменьшение времени отклика
Более быстрая реакция на исключения

Качество

Сокращение числа ошибок ручного ввода
Сокращение объема ручного ввода

Больший контроль
Единообразная бизнес-практика
Улучшенная обработка исключений

Производительность

Меньше передач ответственности
Выше пропускная способность

Большее внимание шагам, создающим ценность для заказчиков
Меньше передач ответственности

Прочие

Сокращение стоимости поддержки
Сокращение административных трудозатрат
Улучшение ситуативной отчетности
Больший контроль
Снижение рисков

Более качественное принятие решений

Держите в уме «три V»

Вам кажется, что это большая работа? Так оно и есть. Как сделать, чтобы она лучше протекала? Это определяется тремя «V»: vision (дальновидность), value (ценность для потребителя), velocity (быстрота).

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

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

Andrew Spanyi – автор двух книг по процессному управлению: «Business Process Management is a Team Sport: Play it to Win!» и «More for Less: The Power of Process Management». Пишите ему по адресу: andrew@spanyi.com

Комментарии
#1 Анатолий Белайчук, 20.11.2008 13:27

В продолжение темы - заметка "BPM партизана" Исмаэля Галими "Don’t RFP, Just DIY", itredux.com/2008/10/14/dont-rfp-just-diy/ (под DIY понимается Do It Yourself - сделай сам).

Его утверждения, как обычно, во многом спорны, но как альтернативный взгляд заметка безусловно интересна. Я бы рассматривал большую часть его филиппик как полезное указание на то, как не надо проводить выбор софта. (Причем не только BPMS - большая часть сказанного справедлива и в более широком контексте.)

"Up until now, most enterprise customers have selected BPM products through a traditional Request For Proposal (RFP) process. They compiled huge laundry lists of features suggested by analyst firms and enriched by all possible stakeholders in the organization, submitted them to a dozen vendors for initial selection, invited three of four for a bake-off, then selected the winner based on its ability to deliver a Proof of Concept in a relatively short period of time (typically three to five business days)."

А вот это утверждение (которое я лично поддерживаю обеими руками) уже специфично для BPMS:

"BPM is not a magic wand that can let business people implement and change processes on their own. If it were, you would not have to pay expensive consultants to deploy these expensive BPM products, would you? BPM, or shall we say BPM 2.0, is a next-generation platform allowing business and IT to discover, design, implement, deploy, and optimize manageable business processes, together, better, faster, and cheaper than when using any other technology. But the only way for it to work is for business and IT to be involved, together, using the same tools, languages, and methodologies. And the only way BPM can bring agility to the business is when BPM is used by customers themselves. In other words, if you want it done right, Do It Yourself."

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

#2 Юлия Вагнер, 21.11.2008 13:02

"if you want it done right, Do It Yourself" - надо писать БОЛЬШИМИ БУКВАМИ!!!
Типичная картина: заказчик кивает головой:"да, да, мы знаем, что такое BPM, да, да, постоянные улучшения, да, да, надо чтобы сами...." - все всё знают. А дальше: "а сколько стоит разработать для нас вот этот процессик?... Сколько-сколько?... О! Дорого!" Ну и где "сами"? Это "сами чужими руками". А что, нельзя? Да можно конечно! Только имейте в виду, что поручая разработку (в смысле автоматизации) ваших бизнес-процессов сторонней организации вы по сути дела получаете традиционныю заказную разработку (с соответствующей ценой на оную). Но главное - ВЫ ТЕРЯЕТЕ ЭФФЕКТ BPM.
Так и хочется написать призыв: "Делайте сами. Привлекайте разработчиков со стороны только для работ, которые не можете выполнить самостоятельно. Этим вы не только сэкономите деньги, но и не выпустите из рук свои процессы."
Это практически крик души smile Наболело.

#3 Анатолий Белайчук, 21.11.2008 14:48

Оно конечно...

В последние годы наблюдается стабильная тенденция: компании и организации последовательно отказываются от собственных программных разработок. Все "наелись" самописными бухгалтериями, складами... Наслушались доморощенных гениев - "Зачем нам SAP, у нас своя система есть, лучше! Мы ее еще немного доработаем и будем продавать."

При всех недостатках коробочных/тиражируемых систем от 1С, SAP, MS они оказываются меньшим из зол, поэтому тенденция эта, в общем, правильная. Но как обычно, происходит перехлест: идет отказ не только от автоматизации стандартной функциональности (что правильно) но отказ вообще от каких бы то ни было собственных разработок.

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

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права