О выборе процессно-ориентированного программного обеспечения

Уровни зрелости управления бизнес-процессами и классы ПО

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

Подробнее о классах процессно-ориентированного ПО читайте в статье "Путеводитель по ландшафту процессно-ориентированного программного обеспечения"

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

В концепции уровней зрелости главное не количество уровней и не их название – это континуум состояний, который для удобства поделен на этапы. Поэтому неудивительно, что общепринятой модели оценки зрелости управления бизнес-процессами не существует: в BPM CBOK – одна, у Gartner Inc. – другая, CMMI представляет собой третью и т.д. Модель может насчитывать пять, шесть или больше уровней.

Если наложить концепцию уровней зрелости на типичную картину того, как по мере развития у компании меняются потребности в части процессно-ориентированного ПО, то увидим следующую закономерность: 

1. Процессов нет, и они не нужны

Для компании на стадии стартапа управление бизнес-процессами неактуально по двум причинам:

• В силу небольшой численности (обычно в команде от пяти до десяти человек) и высокой мотивированности отсутствуют кросс-функциональные проблемы.
• На этом этапе представление о целевой аудитории и ценностном предложении размыто. Компания находится в поиске своего «рецепта ведения бизнеса».
  

Иными словами, на этом этапе все зыбко, и от формализма будет больше вреда, чем пользы. Соответственно, процессное ПО не востребовано.

2. Текстовые регламенты

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

• сохранить преемственность;
• исключить потерю знаний;
• обеспечить быструю адаптацию новичков.

Для этого разрабатывают должностные инструкции и процессные регламенты: «напиши, что делаешь – делай, что написал». Основной инструмент – Microsoft Word.

3. Графические модели процессов

Организации, увлекшиеся написанием объемных регламентов, через некоторое время обнаруживают, что их не читают: «толковому сотруднику регламент не нужен, а бестолковому – бесполезен».

Следующая идея – «одна картинка стоит тысячи слов». Ее можно реализовать двумя способами:

• Простейшие блок-схемы. Этот вариант достаточно наглядный, однако без формальной методологии. В результате одну и ту же схему процесса каждый сотрудник читает по-своему. 
• Стандартизированные графические нотации, например BPMN. Такой подход дает лучшие результаты, поскольку «значки» на диаграмме всеми трактуются одинаково. 

На этом этапе становится востребованным ПО для моделирования бизнес-процессов. Также могут быть полезны средства имитационного моделирования, если компания не только документирует существующее положение дел, но и стремится оптимизировать процессы.

4. Реестр процессов

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

Затевая тотальное документирование, надо иметь в виду, что оно чревато так называемым аналитическим параличом: процессы меняются быстрее, чем компания успевает их описывать

В результате проект затягивается буквально до бесконечности. Если же описания не актуализировать, то через некоторое время компания обнаруживает, что они устарели. Иными словами, не соответствуют тому, как работа выполняется в реальности. 

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

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

Альтернативный, более прагматичный, вариант – реестр процессов в простой табличной форме SIPOC , для которой достаточно Microsoft Excel.

5. Процессы в ERP

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

1. В любой компании ключевые процессы – это то, чем она отличается от конкурентов. Сама идея получить такие процессы «из коробки» от поставщика ERP-системы абсурдна. Стандартизации поддаются в основном вспомогательные процессы. Реализация основных процессов требует обследования, анализа, моделирования и дорогостоящей доработки системы. 
2. Фактически процессы выполняются в системе не так, как было задумано. Это наглядно демонстрирует ПО для автоматического выявления процессов.
3. Детали реализации процесса в ERP зашиты в программный код. Они непрозрачны для бизнеса, и как следствие, он не способен полноценно управлять процессами. 
4. Современные ERP-системы в основном рассчитаны на однократную кастомизацию на этапе внедрения. Регулярное внесение изменений в процессы в таком ПО сопряжено с большими трудозатратами. Как результат – очередь пожеланий по доработке от бизнеса длиной в полгода. И хотя преобразования в системе происходят медленно, а стоят дорого, с этим приходится мириться. 

Частично устранить перечисленные недостатки позволяют разного рода «подпорки». Например, в виде электронной почты и файлов Excel. Но при таком взаимодействии процессы выполняются вне системы, а значит, возможности их координации и оптимизации ограничены. В какой-то мере контроль обеспечивают системы документооборота и ECM-системы. Однако, так как в них отсутствуют стандартные процессные нотации и полноценная работа с данными, их следует рассматривать лишь как компромиссное решение.

6. Цифровые процессы

Внедрив ERP и убедившись, что это не панацея («ERP есть, а счастья нет»), компании начинают проявлять интерес к более передовым технологиям. В большей степени соответствует современной методологии управления бизнес-процессами ПО класса BPMS/iBPMS/Low-code. Быстрее других на этот уровень выходят компании, сделавшие ставку на цифровую трансформацию. Они понимают, что цифровая модель ведения бизнеса немыслима без цифровых бизнес-процессов.

Переход к цифровым бизнес-процессам, разумеется, не означает отказа от ERP, CRM и других корпоративных систем – они играют роль учетного фундамента. Бизнес-процесс, реализованный в BPMS, использует функциональность этих систем как готовые «строительные блоки». Поэтому внедрение систем этого класса не обходится без интеграции с унаследованными системами. Если количество корпоративных систем велико, стоит присмотреться к ПО класса EAI . Облегченный вариант интеграции и способ добиться локального, но быстрого успеха в оптимизации процессов – технологии RPA . 

Алгоритм выбора ПО

Итак, предварительное условие – отталкиваясь от уровня зрелости, определиться с классом ПО. Не стоит сравнивать в одном тендере 1С, систему класса Enterprise Architecture, поставщика коробочной ECM и BPMS-систем. 
Следующие шаги:

1. Определить важные для вашей компании функциональные и нефункциональные требования, которым должен удовлетворять программный продукт.
2. Сформировать широкий список кандидатов и разослать им запросы информации с перечнем требований.
3. Оценить ответы и сформировать на их основе узкий список.
4. Провести встречу с каждым кандидатом из узкого перечня для презентации компании и демонстрации продукта.
5. Выбрать оптимальный для вашей компании вариант.

Приведенная выше последовательность шагов является стандартной – так проводится большинство тендеров по выбору программных продуктов. Но в выборе процессного ПО есть определенные нюансы:

• В списке требований следует отделить критические от второстепенных. Выбирать программный продукт, исходя из числа проставленных «галочек», – не лучшая идея. Сто второстепенных галочек не компенсируют отсутствие ключевой функциональности, так же как сто лаборантов не заменяют одного профессора.
• Рейтинги ПО, которые публикуют уважаемые аналитические агентства Gartner и Forrester, – информация к размышлению, а не прямое руководство к действию. В российской практике есть примеры того, как компания выбрала BPMS, ориентируясь только на лидерский квадрант Gartner, – получилось не слишком удачно.
• Если это новый для вас класс ПО, то стоит предусмотреть запуск пилотного проекта (Proof of Concept). Желательно, чтобы поставщик продемонстрировал возможности программного продукта и собственное умение с ним работать не на стандартном примере, а на конкретном – вашем. Контрольный пример не должен быть слишком объемным, т.к. затягивать выбор не в интересах ни ваших, ни поставщика. С другой стороны, в нем должны быть отражены ваши ключевые требования.
• Рассмотрите возможность заказать пилотный проект одновременно двум-трем поставщикам. Они могут потребовать оплаты своих работ в рамках пилотного проекта – для вас это будут дополнительные затраты. Но подумайте, что хуже – потратиться на «пилот» или сделать неудачный выбор на основе неполной или не вполне достоверной информации и потом годами работать с ПО, которое не соответствует вашим требованиям?

Предварительная классификация

Как показывает опыт, наибольшие сложности у заказчиков возникают при выборе ПО класса BPMS/iBPMS/Low-code. В отличие от специализированных инструментов, это интегрированное ПО с обширной функциональностью, а количество программных продуктов этого класса исчисляется десятками. Чтобы упростить себе выбор, предварительно ответьте на три ключевых вопроса:

1. Насколько для вашей организации важно импортозамещение?

Если это критичное требование, то выбор ограничится пятью–десятью именами из перечня отечественных поставщиков.

2. Какой ИТ-платформе отдается предпочтение в вашей организации – java или Microsoft.NET?

Большинство программных продуктов данного класса используют java, в то время как подавляющая часть заказчиков предпочитают технологии Microsoft. Если вы из числа последних, выбор упрощается.

3. Вы отдаете предпочтение ПО с открытым исходным кодом?

Если ответ положительный, то выбор значительно сужается. ПО с открытым кодом не обязательно является бесплатным, но обычно обходится дешевле. Оборотная сторона медали – разработка прикладного решения обычно требует большего объема программирования и обходится дороже.

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

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