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

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

Анатолий Белайчук Нач. отдела, зам. начальника, Москва

Какие конкретно задачи появляются на разных стадиях внедрения совокупностей управления бизнес-процессами (BPM) и как их рационально решать? Рекомендует Анатолий Белайчук.

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

Корпоративная практика12956 4

Как оседлать «цифровую волну»? Рекомендации для бизнеса

IT-менеджмент1955 7

В чем отличие между «дорогим калькулятором» и действенным IT-ответом

Автоматизация бизнес процессов в CRM Битрикс24


К прочтению:

самые интересные статьи, подобранные как раз для Вас:

spacer