BPM или ERP: что внедрять?
Звонок от потенциального заказчика: "Наша компания находится на распутье. Мы (дирекция по методологии и бизнес-процессам) считаем, что надо внедрять BPM (Business Process Management, Управление бизнес-процессами), но есть другая точка зрения - что надо внедрить ERP-систему. Пожалуйста помогите доказать нашу правоту перед лицами, принимающими решение."
Это старая тема, можно сказать - вечная. И поговорить тут есть о чем.
Назад в будущее
Допустим, мы решили внедрить ERP. Давайте мысленно представим, что все уже позади, и мы ее успешно внедрили.
Сделаем два допущения. Первое: требования к системе были составлены идеально. То есть все бизнес-процессы описаны, все справочники и источники данных проанализированы, все потребности бизнеса четко сформулированы. Более того, еще одно допущение: внедрение проведено тоже идеально. Все настроено в точности так, как мы заказывали.
(Фантастика? Конечно. Но пусть.)
Теперь контрольный вопрос: сколько времени прошло с начала внедрения? Оценки тут расходятся, но большинство согласится, что год-два - это реалистичная оценка.
Смотрите что мы получили: систему, идеально настроенную на наши бизнес-процессы, но в том виде, как мы их понимали полтора года назад. Теперь оглянемся назад: наша компания сейчас и полтора года назад - это одна и та же компания? Бизнес-окружение сейчас и полтора года назад - одно и то же? Strengths/Weaknesses/Opportunities/Threats, вот это всё - не изменились?
Вопрос конечно же риторический.
Так зачем нам ввязываться в проект, который на выходе даст заведомое "не то" даже при идеальных условиях? Сегодня компании готовы тратить деньги в основном лишь на то, что даст эффект в течение максимум полугода.
Транзакции и бизнес-процессы
Компания Гартнер в 2012 году предложила трехскоростную архитектуру приложений.
В своем исследовании Гарнер констатировал растущий разрыв между потребностями бизнеса в быстром развертывании современных, легких в использовании приложений и тяготением ИТ к универсальным прикладным пакетам с широкой функциональностью. Это противоречие объективно обусловлено тем, что разные процессы в бизнесе протекают с разной скоростью.
Аналогично тому, как у здания есть фундамент и стены, которые строятся на десятилетия или даже века, внутренняя отделка, которую меняют, делая ремонт раз в несколько лет, и внутренняя обстановка, которую можно изменить в любой момент, просто переставив мебель, в архитектуре предприятий тоже можно выделить три уровня:
- Нижний уровень - system of records, т.е. системы, реализующие управленческий учет. Поскольку речь идет о более-менее стандартной функциональности, темп изменений минимален. Здесь рулят ERP и другие корпоративные системы (CRM, WMS, PLM...).
- Средний уровень - system of differentiation, т.е. системы, поддерживающие основные бизнес-процессы, обеспечивающие конкурентное преимущество компании. Темп изменений довольно высок, так как основные бизнес-процессы – это предмет постоянных усовершенствований. Это идеальная область применения BPM/BPMS.
- Верхний уровень - system of innovation, т.е. системы, поддерживающие инновационные, изыскательские работы. Если в случае system of differentation речь идет о поддержке наших собственных, уникальных рецептов ведения бизнеса, то здесь - о поиске новых рецептов. Темп изменений таков, что затруднительно говорить хоть о какой-то стабильности, о каких-то шаблонах процессов и т.п. Это поле деятельности систем класса ACM (Адаптивный кейс-менеджмент).
Как видим, трем областям применения соответствуют три разных класса информационных систем. Следовательно, выбор платформы автоматизации определяется нашими приоритетами:
- Хотите самый лучший учет? Внедряйте ERP.
- Хотите самые лучшие бизнес-процессы? Внедряйте BPM.
- Хотите максимум инноваций? Внедряйте ACM.
А можно всё и сразу?
Но ведь ERP-системы поддерживают и транзакции, и бизнес-процессы. И внедрение ERP начинается с обследования и анализа бизнес-процессов компании.
Совершенно верно. И в этом есть проблема.
Системы ERP способны автоматизировать бизнес-процессы, точно так же, как системы BPMS способны автоматизировать учетные функции. Но делают они это одинаково плохо, т.к. заточены под другое. (Вряд ли вендоры в этом не признаются, т.к. их задача - продавать.)
В системах ERP и BPMS бизнес-процессами принято называть несколько разные вещи. С точки зрения ERP, нет транзакции - нет процесса. С точки же зрения BPM, транзакция, т.е. регистрация уже свершившегося факта,- это самая простая и неинтересная часть бизнес-процесса. Например, с точки зрения ERP процесс продажи начинается с регистрации спецификации клиентского заказа. А с точки зрения BPM это уже финал процесса, и самое интересное происходит до этого - контакты, расчет цены, согласование условий, подготовка и подписание договора...
На практике происходит следующее: если организация при внедрении ERP ставит ограниченные цели - привести в порядок справочники, наладить учет (имеется в виду учет управленческий, а не только бухгалтерский), автоматизировать более-менее стандартные процессы низкого уровня, выполняющиеся в пределах одного подразделения - все получается относительно легко, с разумными бюджетом и сроками. Но если внедренцы ERP берутся за автоматизацию специфических для компании процессов, то сроки, стоимость, риски проекта могут значительно вырасти: многомесячные обследования, скандалы из-за изменения требований, сопротивление при внедрении...
Но требования к основным бизнес-процессам не могут не меняться в ходе внедрения, т.к. характерные сроки внедрения больше характерного интервала времени между изменениями бизнес-среды, конкуренции, поведения клиентов и т.д.
ERP-системы часто сравнивают с цементным раствором: его можно залить в любую форму (настройка при внедрении), но потом что-то изменить довольно затратно, а быстро - практически невозможно. Проблема, с которой сталкиваются многие организации, внедрившие ERP,- очередь доработок, растягивающаяся на многие месяцы.
Проблема реализации основных бизнес-процессов в среде ERP заключается в том, что методологической основой современных систем ERP является классический реинжиниринг, понимаемый как однократное усилие:
- проанализировать процессы "как есть" (as-is)
- спроектировать процессы "как будет" (to-be)
- разработать план перехода
Это идеи 90-х годов. С тех пор теория и практика управления бизнес-процесс ушли далеко вперед, и в полной мере новые подходы реализованы в системах класса BPMS.
Двухскоростной ИТ
В конечном итоге, каждой компании нужны и учет, и бизнес-процессы, так что вопрос или/или не стоит. Просто подходить к ним следует по-разному.
Любой компании учет нужен в первую очередь - без него бизнес вести попросту невозможно. Но при этом незачем гоняться за самой лучшей учетной системой - она должна быть всего лишь "достаточно хорошей". По этой же причине не следует спешить менять корпоративную информационную систему - благодаря учетной системе разбогатеть еще никому не удавалось.
С бизнес-процессами ситуация обратная: с одной стороны, это в каком-то смысле предмет роскоши - в компании не слишком большого масштаба бизнес-процессы могут исполняться спонтанно, на уровне самоорганизации. Да, это будет отражаться на клиентах, но если конкуренция и стандарты обслуживания в данной рыночной нише не слишком высоки, то как-то обойдется. С другой стороны, процессы можно улучшать бесконечно - такого понятия, как "оптимальный процесс", не существует; улучшение бизнес-процесса - это бег за горизонтом. И на высококонкурентных рынках именно это и наблюдается.
Учетные системы (system of records) и процессные (system of differentiation) живут на разных скоростях:
- Учет желательно сделать один раз, как следует и надолго - это проект внедрения корпоративной системы (в частности, ERP).
- Процессами можно и нужно заниматься бесконечно, короткими итерациями, обеспечивающими быструю отдачу - это проект BPM/BPMS. Точнее - не проект, а программа, понимаемая как серия проектов разработки-внедрения-усовершенствования процессов.
Из-за разных ритмов объединять учетную и процессную функциональность в одном проекте внедрения ERP не следует. Об этом же говорит и концепция "двухскоростного ИТ" от Гартнер (bimodal IT): организация должна раздельно подходить к проектами, в которых приоритетом является стабильность (это про учет), и теми, в которых приоритетом является скорость реакции (это про бизнес-процессы).
Органичное сочетание ERP и BPM
Ограничения систем ERP, о которых речь шла выше, были осознаны в начале 2000-х, в результате чего появилась концепция управления бизнес-процессами с помощью систем класса BPMS. В ней предлагается использовать для бизнес-функций и для сквозных "от и до" бизнес-процессов системы разных классов:
- Уровень бизнес-функции - сюда входит не только учет, но и, например, расчет производственного плана - это фундамент, относительно стабильная (медленно меняющаяся) часть общей системы. Она автоматизируется с помощью традиционных корпоративных систем - ERP, CRM, SCM, WMS, PLM, APS,...
- Бизнес-процессы - в первую очередь речь идет о процессах кросс-функциональных и сквозных ("от и до") - автоматизируются с помощью систем класса BPMS.
- Бизнес-процессы обращаются к бизнес-функциям, реализованными в корпоративных системах, через протоколы и программные средства интеграции (обычно на основе SOA).
- Так это же концепция Best of Breed (использование систем, лучших в своем классе, в противоположность Single Vendor - использование системы от одного поставщика),- скажет кто-то.
Не в этом суть. Принято считать, что специализированные системы класса BPMS (т.н. Pure-Play) более функциональны и более дружественны по отношению к пользователям, но вы можете использовать BPMS от поставщика вашей системы ERP или CRM. Главное понимать разницу между бизнес-функциями и бизнес-процессами и дифференцировано подходить к автоматизации тех и других.
Рекомендации: что делать
1. Отказаться от идеи реинжиниринга бизнес-процессов через внедрение ERP, ограничив функциональность корпоративных систем автоматизацией бизнес-функций и процедур уровня подразделения.
2. Оценить реальную необходимость замены существующей корпоративной системы, приняв во внимание сроки внедрения альтернативной системы, ожидаемый эффект, стоимость.
3. Если принято решение внедрять ERP, то постараться свести к минимуму процессную составляющую и за счет этого минимизировать сроки, стоимость, риски.
4. Инициировать пилотный проект BPM, выбрав для него бизнес-процесс не самый сложный, но обладающий реальной ценностью и существенным потенциалом улучшения.
[an error occurred while processing this directive]