Что значит «автоматизировать управление бизнес-процессами»

Научная организация труда, система управления качеством, реинжиниринг – процессная наука и практика развиваются под разными флагами уже свыше ста лет. Последняя волна интереса к бизнес-процессам поднялась в начале двухтысячных с появлением концепции 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 вовлекает людей бизнеса, которые во всевозрастающих масштабах дают предложения по тому, как компании следует работать в рамках того или иного процесса, чтобы лучше соответствовать ожиданиям клиентов и эффективнее использовать имеющиеся ресурсы и какие еще процессы можно заметно улучшить, реализовав их в системе.

Расскажите коллегам:
Комментарии
Сергей Мамин +841 Сергей Мамин Адм. директор, Белгород
Кузьма Михайлов пишет:
Термин Управлять уже давно структурировал Эд Деминг - управлять значит планировать, проверять, анализировать, корректировать. И ничего более. Подобная структура действий вполне подходит для использования в отношении БП. Особенно если говорить о модели БП, а не об отдельном ее эксземпляре

Ну, да. PDCA или КУ ( контур управления):

- цель (задача)

- план достижения

- действия по плану

- контроль (сравнение плана и факта)

- анализ причин отклонений, если они есть

- коррекция плана или цели.

И так итерационно, до достижения цели (задачи).

Теперь представим, что БП организован. Какая цель (задача) в отношении БП? Чтобы использовать КУ (PDCA). 

Сохранить? Реорганизовать? Улучшить? Документировать? Контролировать (мониторить)? Обеспечивать ?

Выбор из этого неполного набора целей в отношении БП, одной или более влечет за собой организацию КУ ( PDCA).

Вот почему я написал, что использование термина "управление БП" без прояснения в отношении каких именно целей (задач) контур управления будет организован, больше запутывает читателя, чем разъясняет ситуацию

 

 

Генеральный директор, Москва
Сергей Мамин пишет:
Вот почему я написал, что использование термина "управление БП" без прояснения в отношении каких именно целей (задач) контур управления будет организован, больше запутывает читателя, чем разъясняет ситуацию  

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

Помоему термин управлять содержит в себе понятие цель, как пьяный водитель понятие столб.

Сергей Мамин +841 Сергей Мамин Адм. директор, Белгород
Кузьма Михайлов пишет:
Помоему термин управлять содержит в себе понятие цель, как пьяный водитель понятие столб.

1) Не очень понял метафору. Не имея цели ( задачи) не возможно планировать. Ну и далее  по пунктам КУ. Управление начинается с постановки цели ( задачи)

2) "Вы когда говорите, к примеру - мол, я управляю автомобилем в пьяном виде. Всегда добавляете - в отношении своего дома, инспектора гаи, столба, встречной газельки? Ну что бы не запутать себя, хотя бы."

В данной фразе все довольно ясно. 

А вот управление - это лишь один из инструментов менеджера. Используется для достижения целей (задач), как правило, после выбора иного инструмента. Например, такого инструмента как организовывание ( реорганизовывание), например, БП. Инструмент организовывание имеет свою цель. Для ее достижения нужно управлять (строить и использовать КУ). 

То есть, тут более сложная история. Связка: организовывание БП - управление организовыванием. 

Или реорганизовывание БП - управление реорганизовыванием.

Или документирование БП - управление документированием БП.

Возможно фокус внимания перевели на обеспечение БП необходимыми ресурсами. Тогда обеспечение БП - управление обеспечением.

 

Генеральный директор, Бийск
Кузьма Михайлов пишет:
Вы когда говорите, к примеру - мол, я управляю автомобилем в пьяном виде. Всегда добавляете - в отношении своего дома, инспектора гаи, столба, встречной газельки? Ну что бы не запутать себя, хотя бы. Помоему термин управлять содержит в себе понятие цель, как пьяный водитель понятие столб.

Только вот, автомобиль, это не процесс, это конструкция. Скорее можно говорить об управлении движением автомобиля. Само движение, это процесс. Движение будет содержать в себе конечную цель, например, столб )

2
Оставлять комментарии могут только зарегистрированные пользователи
Статью прочитали
Обсуждение статей
Все комментарии
Дискуссии
Все дискуссии
HR-новости
Россияне стали меньше тревожиться из-за работы

Год назад уровень тревожности россиян по поводу различных возможных проблем на работе был выше.

Уровень счастья напрямую влияет на продуктивность большинства россиян

При этом почти каждый четвертый респондент считает, что их руководитель ничего не делает для счастья сотрудников.

70% россиян отмечают сильное влияние работы на уровень стресса

Наибольший стресс создают строгие дедлайны, внезапные и большие объемы задач, а также собственные ошибки при выполнении задач.