.png?&quality=65&format=webp)
Внедряем СЭД без потерь: программа автоматизации документооборота в организации
О преимуществах СЭД, кейсах использования и о функциональности топовых систем для автоматизации документооборота читайте в этой статье.
Мир процессной автоматизации велик и неоднороден — на рынке представлено множество решений, не только BPMS, но их тоже иногда называют BPMS, хотя они представляют собой процессные движки. В этом материале не будет выводов о том, что один класс систем очевидно неудачный, а другой гораздо лучше. Моя цель — разнести оба понятия для аудитории и дать читателям объективное представление о каждом виде автоматизации бизнес-процессов.
Что такое Low-code BPMS?
Речь идет о развитии концепции BPMS — то есть построении бизнес-процессов и создании бизнес-приложений при помощи конструкторов и всевозможных визуальных настроек, которые понятны широкому кругу пользователей: от программистов до аналитиков и даже топ-менеджмента. Острие технологий, большинство внутренних решений автоматизации реализуется при помощи Low-code BPMS. Это позволяет вовлечь максимальное количество пользователей в процесс разработки и всем говорить на одном языке. Кроме того, такие конструкторы способны значительно ускорить разработку решений.
Что такое процессный движок?
BPM-системы, которые представляют собой некую транзакционную машину — они позволяют обернуть код в workflow-процессы, которые будут исполняться в BPM-системе. Есть очень распространенный в России продукт немецкого происхождения, он имеет некоторые конструкторы, позволяющие создать визуальные модели и настроить процессы, но дальше упаковка решения осуществляется кодом. Идет разработка в классическом представлении: если говорить об экранных формах — HTML, CSS, JavaScript, то есть пишутся Java-классы даже для простых Low-code-BPMS-задач. Например, если в процессе необходимо отправить клиенту email-сообщение, вы разворачиваете почтовый сервер, пишете код, который будет упаковывать сообщение, и т. п. Для разработчиков это тривиальная задача, ничего сложного в ней нет, но citizen-девелоперам осилить ее уже намного сложнее, все-таки это инструмент для программистов.
Конечно, процессный движок существенно ускоряет классическую разработку: программист пишет только внутреннюю функциональность блоков, а упаковку и бизнес-процесс, который будет транзакционно выполняться внутри системы, осуществляет платформа, которая может масштабироваться, брать на себя вопросы нагрузок и т. п. В итоге повышается и стабильность исполнения — разработчикам не нужно думать, как будут выполняться процессы на уровне ядра, поскольку платформа сама решает такие задачи. Однако процессный движок предполагает большой объем разработки, а значит, наличие соответствующих специалистов высокой квалификации, которые будут ею заниматься.
Может показаться, что выбор очевиден и я пытаюсь склонить читателя к Low-code BPMS. На самом деле это не так, потому что ситуации различаются. Если речь о небольшой организации с амбициозными планами относительно цифровой трансформации, автоматизации, создания гибких процессов — тут Low-code без вариантов. Но если в команде большой штат программистов, требуется высокий уровень кастомизации и нужно создать сложные нестандартные решения — все преимущества Low-code будут умножены на ноль, потому что придется слишком многое менять и так или иначе обходить ограничения платформы.
Когда разумно отказаться от Low-code в пользу процессных движков?
Во-первых, когда нужен проект с высоким уровнем кастомизации. Если мы создаем нетиповое решение с очень сложными экранными формами и хитрой логикой, то предполагается большое количество разработки, потому что конструкторами такие вещи не закрываются.
Во-вторых, если есть сыгранная команда разработчиков, работающих на языке этого процессного движка. Они могут переехать из своей привычной среды разработки в среду разработки процессного движка, и для них радикально изменится немногое — просто получат инструмент, дающий преимущество в скорости разработки и стабильности решений, которые они делают. Понятно, что в таком сценарии Low-code BPMS не принесет пользы.
Когда лучше выбрать Low-code BPMS-платформу?
Во всех остальных случаях Low-code позволяет вовлечь в работу широкий круг специалистов — аналитиков, всевозможных citizen-девелоперов, руководителей отделов, программистов, архитекторов и пр. Динамика процесса тогда гораздо выше, поскольку бизнес не только ставит задачу, но и вовлекается в ее решение, а разработка перестает представлять собой черный ящик.
Данный подход удобен в том числе для компаний с сильной командой разработки. Менее интересные и более монотонные задачи в ходе разработки на Low-code-платформе могут быть переданы на внутренних аналитиков — в результате разработчики будут больше заниматься чем-то интересным и втянутся в процесс. Скорость разработки при этом значительно возрастает.
Резюме
Конечно, со стороны кажется, что обе системы решают близкий круг задач — так или иначе это автоматизация бизнес-процессов (зачастую вендоры сами друг друга называют BPM-системами). Но важно отличать Low-code BPMS, который базируется на низком пороге входа и большом количестве всевозможных конструкторов и настроек, от процессных движков, которые представляют собой некую обертку для среды разработки и транзакционный механизм, позволяющий запускать процессы. Различие критическое, и необходимо сразу на старте проекта знать свои вводные:
Какая стоит задача?
Делаем мы типовую автоматизацию, то есть создаем интерфейсы автоматизации внутренних или внешних процессов, или же создаем уникальный кастомный продукт, который предполагает большое количество нестандартных решений?
Какая у нас есть внутренняя команда?
Многое зависит от того, какими человеческими ресурсами обладает компания, поскольку требования к исполнителям в случае процессных движков действительно высоки.
Как видим, оба подхода имеют право на жизнь, хотя решают разные задачи и подразумевают разную динамику разработки. Разработка на Low-code BPMS, несмотря на все преимущества, подходит не для всех случаев, и, конечно, далеко не всем компаниям удастся запустить рабочие проекты на процессных движках. Однако в нашей практике есть заказчики, которые совмещают использование обеих платформ — сложные решения создают на процессных движках, а рядом развернут продукт для всего остального, где можно создавать решения быстрее и с меньшими усилиями.
