Научная организация труда, система управления качеством, реинжиниринг – процессная наука и практика развиваются под разными флагами уже свыше ста лет. Последняя волна интереса к бизнес-процессам поднялась в начале двухтысячных с появлением концепции BPM (Business Process Management – управление бизнес-процессами), вобравшей все лучшее из прежних наработок в этой области и одновременно давшей ответ на проблемы, которые к этому моменту назрели.
Внедрение BPM существенно отличается от внедрения ERP и других корпоративных систем. Как показывает опыт, работоспособную схему процесса невозможно разработать ни с первой, ни со второй попытки – если речь идет об основных, кросс-функциональных процессах, рассчитывайте на пять-десять итераций. Поэтому традиционный подход, при котором бизнес пишет требования к автоматизации и «перебрасывает их через стену» в IT, здесь не работает. Вместо него применяются гибкие (Agile) методологии: короткие итерации, быстрое прототипирование, непосредственное участие бизнеса в проектировании процессов (принцип «что нарисовали, то и исполняем»).
Организации, нацеленной на внедрение BPM, предстоит многому научиться: переосмыслить – что такое бизнес-процесс, изменить культуру взаимоотношений между бизнесом и IT, превратив их в партнерские, измерять показатели бизнес-процессов в реальном времени и принимать решения на основе этих показателей и т.д. Все это ради того, чтобы в итоге повысить удовлетворенность заказчиков (а значит, заработать больше денег), оптимизировать операции (сократить затраты, повысить отдачу имеющихся ресурсов) и стать более подвижными, научиться быстро реагировать на возможности, открывающиеся в бизнесе.
Что для этого надо делать? Очертим первые шаги, благо, здесь накоплено достаточно опыта и сформировались стандартные практики, которые рекомендует большинство поставщиков.
1. Повышение собственной компетенции
Делать что-то в области BPM, обладая нулевой собственной компетенцией, – дело рискованное, так как недобросовестный поставщик легко сможет вами манипулировать в своих интересах.
Применительно к BPM организации можно поделить на три категории, в зависимости от масштаба:
1) Малые. Эти компании не могут себе позволить держать в штате выделенного специалиста по бизнес-процессам. Тем не менее, и здесь есть примеры успешных проектов BPM – мотором в них становится кто-то из руководства, например, технический директор.
2) Средние. Могут себе позволить одного выделенного специалиста или небольшую группу специалистов (процессный офис). Зачастую они совмещают роли специалистов по бизнес-процессам и менеджеров проектов (совмещенный процессный и проектный офис).
3) Крупные. Эти организации имеют выделенное специализированное подразделение, например, департамент бизнес-технологий. Помимо специалистов по бизнес-процессам, они могут похвастаться бизнес-архитекторами.
Оцените свои возможности (финансовые и людские), разработайте перспективный план развития процессной компетенции, включающий прием на работу новых и/или переподготовку существующих специалистов. Разработайте программу обучения.
2. Выбор консультанта и поставщика BPMS
Некоторые крупные организации делают ставку исключительно на собственную компетенцию в области BPM. Если ваша организация не из их числа или если вас не устраивает медленный путь проб и ошибок, то нужен внешний консультант.
Если BPM для вас новая область, начините с исследования рынка: проведите поиск в интернете, походите на конференции по BPM, чтобы познакомиться с потенциальным партнером лично. Вам нужна компания, специализирующаяся на BPM-консалтинге (включая разработку, внедрение, обучение), и поставщик программного обеспечения класса BPMS. Предпочтительно получить и то, и другое из одних рук: это может быть компания-разработчик или сертифицированный партнер.
Если у вас есть на примете поставщик или поставщики, которым вы доверяете по предыдущему опыту или на авторитет которых полагаетесь, то процедура выбора может быть упрощенной. Пригласите кандидатов сделать презентацию, совмещенную с демонстрацией системы, запросите коммерческое предложение.
Формальная процедура (объявление условий тендера, рассылка приглашений потенциальным участникам, запрос и изучение предложений, многоступенчатый отбор и т.д.) – более длительная и дорогостоящая, но для некоторых компаний единственно возможная в силу внутренней политики.
Несколько рекомендаций по процедуре выбора:
- Не доверяйте выбор IT-подразделению. Его голос обязательно должен быть услышан, но в первую очередь надо учитывать мнение бизнес-технологов, специалистов по управлению бизнес-процессами, бизнес-пользователей.
- Цена, конечно, важный критерий, но выбирать поставщика только по цене – большая ошибка. Компетенция может стоить дорого, но некомпетентность обходится намного дороже.
- Не делайте выбор исходя из числа плюсов в опросной форме. Помните: минус по одному важному критерию перевесит десять плюсов по малозначащим. Определитесь, что для вас критично, а что всего лишь желательно. Прежде чем формировать окончательный список вопросов и критерии оценки, выслушайте потенциальных поставщиков – что они считают самым ценным в своем предложении.
- Выберите одного-двух кандидатов.
3. Демонстрационный пилот (Proof of Concept)
Цель пилотного проекта – в максимально короткий срок получить полную информацию для принятия решения о приобретении системы и запуска ее в промышленную эксплуатацию, то есть избежать покупки «кота в мешке». Ключевое слово здесь – срок, а не функциональность. Обычный срок пилотного проекта BPM – два-три месяца. Не поддавайтесь соблазну расширить рамки пилота, тем самым удлиняя его: помните, что чем дольше длится пилот, тем позже вы начнете получать отдачу от инвестиций в BPM.
По результатам пилота, во-первых, вы должны увидеть, что представляет собой система с точки зрения всех заинтересованных лиц – аналитиков, разработчиков, исполнителей, руководителей. Не менее важно то, что вы сможете оценить квалификацию и стиль работы поставщика.
Пилотный проект должен иметь официальный статус: у него должны быть спонсор, менеджер, устав, план-график. Проектная команда должна быть утверждена приказом руководства. Не пытайтесь выполнить проект «подпольно» – ничего хорошего из этого обычно не выходит.
Выберите пилотный бизнес-процесс. Он должен быть не слишком сложным, чтобы пилотный проект не растягивался во времени и в то же время не тривиальный, чтобы результат представлял ценность для бизнеса, а не выглядел бесполезной игрушкой. При выборе процесса отталкивайтесь от реально существующих в компании бизнес-проблем. Найдите несколько процессов-кандидатов, обсудите их с поставщиком, выберите для реализации один процесс.
Определите требования к процессу. Сосредоточьтесь на бизнес-требованиях: что не устраивает в текущем положении дел, чего ожидают от процесса владелец и потребители, по каким критериям вы оцениваете его качество. Подсказка: автоматизация не может заявляться как цель проекта, это только средство.
Не пытайтесь составить исчерпывающее ТЗ, ведь цель пилотного проекта – получить оценку предлагаемого решения в возможно короткие сроки. Разработка детального ТЗ, во-первых, займет время, сравнимое со сроком всего проекта, а во-вторых, как показывает опыт, в ходе пилота представление о процессе меняется настолько серьезно, что ТЗ устаревает уже к середине проекта.
Специфика процессной работы такова, что чем больше вы работаете с процессом, тем лучше понимаете, как он должен быть устроен. Поэтому ТЗ проекта BPM будет меняться в ходе работы. Это может показаться непривычным, но в данном случае это единственно возможный путь.
На стадии пилотного проекта лицензии и компьютерное оборудование приобретать как правило не требуется, но будьте готовы к тому, что поставщик предложит заплатить за консалтинг и разработку. Некоторые поставщики делают пилотный проект бесплатно, но в итоге такой вариант может оказаться дороже – поставщик эти затраты включит в цену софта, причем с лихвой.
Смету, которую представит поставщик, следует рассматривать как ориентировочную. Так как предполагается, что в ходе проекта может меняться ТЗ, то это повлечет за собой и корректировку сметы. Каждый раз, когда в ходе проекта появляются новые требования, надо либо отказаться от каких-то других требований, чтобы объем проекта остался приблизительно тем же, либо увеличивать смету. Большинство поставщиков выставляют счета и акты не по исходной ориентировочной смете, а по фактическим трудозатратам, исходя из стоимости человеко-часа или человеко-дня. (Это относится не только к пилотному проекту, но и к дальнейшей работе.)
Результатом пилотного проекта будет установленная и настроенная система BPMS и реализованный в ней бизнес-процесс, готовый к опытной эксплуатации.
4. Опытная эксплуатация
Определите круг участников опытной эксплуатации. Как правило, он включает ключевых сотрудников – исполнителей процесса, руководителей, бизнес-технологов.
Заранее подготовьте несколько сценариев прохождения процесса – какие данные на каком шаге процесса вводятся, какие решения принимаются. Можете воспользоваться историческими данными фактического исполнения рассматриваемого процесса. В течение одной-двух недель пройдите процесс несколько раз от начала и до конца.
Соберите мнения команды о целесообразности использования системы в промышленном режиме и о желаемых доработках. (Часть доработок поставщик может выполнить прямо в ходе опытной эксплуатации.)
5. Принятие решения
Если к пилотному проекту было допущено больше одного поставщика, выберите победителя. На основе результатов опытной эксплуатации примите решение о продолжении проекта, то есть о приобретении ПО и о запуске системы в промышленную эксплуатацию.
6. Запуск в промышленную эксплуатацию
Если на предыдущем шаге принято положительное решение, разработайте план-график следующего этапа проекта BPM, включающего в себя:
- определение числа пользователей на начальном этапе эксплуатации системы и приобретение лицензий;
- развертывание промышленной среды на оборудовании заказчика;
- доработку системы по результатам опытной эксплуатации;
- обучение пользователей;
- выпуск приказа и иные организационные мероприятия, сопутствующие запуску системы.
7. Расширение сферы применения системы
Тактика внедрения BPM строится на цепочке относительно коротких (порядка одного месяца) проектов, в каждом из которых какие-то процессы дорабатываются (оптимизируются), какие-то новые разрабатываются, запускаются в опытную и промышленную эксплуатацию.
Важно, чтобы каждая такая работа имела ощутимый бизнес-эффект: тогда успех очередного этапа повышает доверие к системе, и для нее находятся все новые и новые применения. Успешный проект BPM вовлекает людей бизнеса, которые во всевозрастающих масштабах дают предложения по тому, как компании следует работать в рамках того или иного процесса, чтобы лучше соответствовать ожиданиям клиентов и эффективнее использовать имеющиеся ресурсы и какие еще процессы можно заметно улучшить, реализовав их в системе.
Интересно все таки, а что же значит "управление бизнес-процессами" которое зачем то нужно автоматизировать??
Легко сказать. Где же их брать? Это же высокие технологии, которых пока ещё нет у нас...
Статья выглядит скорее как мини-лекция, описывающая проект выбора и внедрения инструмента BPM и рассчитана на тех, кто об этом что-то уже знает. В этом ее несомненная польза.. Хотела бы немного прокомментировать, выйдя за границы стать, погуляя, так сказать, по окрестностям управления. Я в теме управления давно, поэтому с точки зрения практика-консультанта-преподавателя добавила бы свое мнение:
1. Сам по себе BPM (или BPMS) не живет в вакууме. Реализовывать управление ТОЛЬКО бизнес-процессами, причем по очереди, не осознав заранее их динамики и взаимосвязей – утопия. Тут еще надо бы задуматься об архитектуре, не которую эти процессы накладываются. Архитектура – скелет, процессы – системы кровообращения, дыхания и т.п. А то получится, что легкие разместите где-нибудь на пятке.
2. В наше время нужно еще учитывать и ИТ – технологии и возможности, которые очень сильно влияют на ситуацию в бизнесе и управлении им. Ну выберете вы СЕЙЧАС некое приложение BPM, внедрите, даже запустите. А каковы перспективы поставщика этого решения, как решение связано с развитием других частей вашей инфраструктуры, включая их ИТ – составляющую? Устаревшая порочная практика автоматизации ТОЛЬКО бизнес – процессов зачастую приводит к огромным скрытым затратам на адаптацию и развитие технологической составляющей жизни организации.
3. Не всегда получается выделить именно БИЗНЕС-ПРОЦЕССЫ. По факту они есть в компаниях, где среда более-менее стабильна. Или часть деятельности компании стабильна, а часть – нет. Там же, где деятельность быстро меняется в зависимости от текущей ситуации, где на первом месте фактор скорости, а не качества, нужны другие подходы.
4. И потом я бы не путала хороших (и плохих) внешних консультантов с практиками. Теоретически это два разных типа специалистов. С чем соглашусь, так это с тем, что мало тех, кто сочетает умение помочь третьей компании (консалтинговые навыки) с использованием собственного опыта. Мне нравятся результаты, которые получаются от симбиоза команды, состоящей из сотрудников компании, одного-двух внешних консультантов и одного-двух внешних специалистов – практиков (советников). В идеале можно обойтись одним очень грамотным специалистом (см. выше). Есть возможности, о которых мало кто знает. Например, можно пригласить кого-то из экспертных сообществ, а не из компании - консультанта. Во многих случаях это можно сделать бесплатно. Важно, что бы такая команда охватила бы НЕ ТОЛЬКО аспекты автоматизации BPM, но и всю остальную жизнь предприятия и сделала бы это ДО начала работы с BPM. Ну и довольно часто серьезные вендоры обеспечивают обучение и консалтинг за те же деньги, а также имеют возможность пригласить специалистов в смежных областях.
Законный вопрос, сам в некотором недоумении. Авторское название было другим, но редакция поставила свой вариант для привлечения внимания.
Уже больше 10 лет в Москве ежегодно проводится по несколько конференций по теме BPM. На каждой есть и аналитика, есть и рассказы про проекты. Уже три года существует профессиональная ассоциация, объединяющая свыше ста действительных членов и в несколько раз больше сочувствующих. Так что "нет у нас" это все же слишком пессимистично.
Справедливо, но тут есть ловушка: сначала необходимо научиться управлять отдельными процессами и только потом замахиваться на управление системой процессов, т.е. на архитектуру. На определенном достаточно высоком уровне зрелости заниматься архитектурой необходимо, но ставить ее во главу угла - это как поступать сразу в вуз, минуя среднюю школу.
Здесь не очень понятно - что значит "только"? Сквозной бизнес-процесс строится из функциональных блоков, за которые отвечают функциональные подразделения и соответствующие функциональные информационные системы. Проектов BPM без интеграции с унаследованными системами практически не бывает.
По сути согласен, но сформулировал бы несколько по-другому: не другие подходы, а расширение подхода. Современный тренд - слияние управление классическими (исполняемыми по шаблонам) процессами c динамической, исследовательской, творческой работой (adaptive/dynamic case management) в единое целое.
Спасибо за содержательные комментарии!
А я сегодня противень с шампурами купил "Сделано в Германии".
Вопрос "сколько" я не увидел в рекомендациях. Какова должна быть повторяемость процессов, чтобы вообще браться за их автоматизацию.
Совсем примитивно - сколько транзакций в течение года, сколько лет это будет работать? И transaction cost при текущем положении дел. Запланированную стоимость (и сроки) автоматизации на всякий случай будьте готовы умножить на коэффициент от 2х до 3х.
А "наша" транзакция - это управляющее воздействие на бизнес-процессы. Т.е. мы ставим эту функцию изменений на поток... это вряд ли, как вы думаете? Мониторинг, аудит БП - это ок, но в статье написано "управление"... А может управление БП надо автоматизировать ради того, чтобы держать управленцев (рационализаторов) в рамках правил ))) ?
Термин "управлять БП" больше запутывает, чем что- то поясняет.
БП нужно организовывать, реорганизовывать, контролировать, обеспечивать, поддерживать, улучшать, сохранять, документировать.
Когда это получается в ручном режиме, часть функций можно пробовать автоматизировать. Те, что должны стабильно функционировать.
А я в Германии покупаю шампуры только в русских магазинах (из России).
И поверьте - это не ностальгия! :-)
Термин Управлять уже давно структурировал Эд Деминг - управлять значит планировать, проверять, анализировать, корректировать. И ничего более.
Подобная структура действий вполне подходит для использования в отношении БП. Особенно если говорить о модели БП, а не об отдельном ее эксземпляре.