Привет, меня зовут Евгений, и я никогда не был программистом — написание кода вызывало у меня чуть ли не смертельную скуку. Конечно, за двадцатилетнюю карьеру приходилось писать скрипты на PowerShell, Python и т. д., но о серьёзной разработке речи не было. Тем не менее моя профессиональная деятельность не ограничивалась системным администрированием. В какой-то момент я познакомился с Microsoft SharePoint — технологией, которая и определила вектор моего развития как IT-специалиста.
SharePoint — это огромный конструктор со множеством деталей, из которых можно собрать практически что угодно — от корпоративного новостного портала до mission critical системы. В нём собраны все необходимые службы и приложения для работы с контентом. Кроме того, SharePoint позволяет создавать несложные сайты с уникальным дизайном и лендинги. А вот что касается автоматизации бизнес-процессов, то тут администраторы быстро понимают, что есть два пути: либо разрабатывать фичи самостоятельно (или обращаться к программистам), либо использовать внешние (по отношению к SharePoint) решения. Я пошёл по второму пути — и в итоге, пришел к no-code/low-code (NC/LC) — решениям, позволяющим создавать приложения практически без использования сложного кода. Это подкупает: можно быстро разрабатывать сложные решения, не прибегая к программированию. Но всё оказалось не так просто, и сегодня я расскажу, почему NС/LC-решения не взлетели в Ozon.
Сразу оговорюсь, целью данной статьи не является умаление достоинств NC/LC-решений, в них, безусловно, есть свои (и не маленькие) плюсы. Я скорее хочу показать, в каких ситуациях вам стоит отказаться от NC/LC-решений и нанять разработчиков, чтобы обойти те грабли, по которым ходил я. А те, кто дочитают до конца, узнают, как нам в Ozon удаётся скрещивать NC/LC с решениями, которые разработаны с нуля. И ещё: в статье я рассказываю преимущественно о Microsoft Power Platform, так как именно на этой платформе мы делаем NC/LC-решения.
Краткий обзор NC/LC-решений и немного истории
SharePoint Workflow + InfoPath
Первым NC/LC-решением, с которым я познакомился, было SharePoint Workflow, намертво привязанный к SharePoint. Выше я писал, что NC/LC — это внешние решения; так вот, SharePoint Workflow был единственным, можно сказать, встроенным вариантом, который можно было использовать с SharePoint.
SharePoint Workflow имел один существенный минус — он не умел работать с формами списков. Да, на нём можно было сделать рассылку уведомлений, настроить доступы к различным элементам SharePoint, создать процессы согласования, но если было необходимо кастомизировать форму (подставить в поле списка данные из внешних источников, скрыть/показать поле, по условиям, и т. д.), то либо приходилось идти к разработчикам, либо… в некоторых случаях спасал InfoPath. Но, во-первых, он входил в редакцию Microsoft Office Enterprise, а значит, стоил дополнительных денег, а во-вторых, был довольно сложен сам по себе. Кроме того, если у вас была русская версия Microsoft Office (а у многих она была именно такой), то и InfoPath тоже был русский, а это был отдельный кошмар разработчиков. Именно тогда я понял, что 1С — это не моё ;)
Nintex Workflow + Nintex Forms
Следующее NC/LC-решение, с которым мне довелось познакомиться, было связкой из двух продуктов компании Nintex — Nintex Workflow и Nintex Forms. Когда я начал работать с ними, понял, что за NC/LC будущее. Продукты Nintex были хороши буквально во всём. Они были настолько гибкими и мощными, что за семь лет работы с ними (за этот период вышли две мажорные версии и появилась облачная редакция) я не испробовал их возможности на все 100%. Рабочие процессы огромной сложности с кучей согласований (как последовательных, так и параллельных) можно было конструировать в максимально короткие сроки. Что касается форм, то тут тоже был простор для деятельности. А если вам всё-таки не хватало чего-то, вы всегда могли либо расширить функционал с помощью JavaScript, либо написать свои «кубики». Формы же легко кастомизировались с помощью CSS.
Существенный минус решений от Nintex — их стоимость.
В ту пору облачных версий ещё не существовало, все работали on-premise, а продукты Nintex лицензировались по фронтенд-серверам SharePoint. Точных цен я, конечно, уже не помню, но в 2013—2017 годах лицензия для фермы SharePoint из двух фронтенд-серверов стоила больше 1 млн рублей в год (плюс обязательная техническая поддержка в размере 20—25% от общей стоимости). И это была стандартная редакция. Enterprise, который имел огромные возможности по интеграции с внешними системами, стоил ещё дороже.
А также неприятные особенности в политике лицензирования.
Вы были обязаны продлевать лицензию на следующий день после окончания предыдущей. Казалось бы, так работают все, но в отличие от лицензий Microsoft 365 вы не могли допустить простоя. Например, ваша лицензия заканчивалась 31 марта. Значит, следующая должна была начаться с 1 апреля. Иначе… нет, продакшен бы не остановился и никто бы не умер, но вот лицензии на dev-серверах работать бы перестали, и разработка стала бы недоступна. Кроме того, перестали бы прилетать обновления. А ещё, после оплаты следующая лицензия всё равно начиналась бы 1 апреля — и неважно, когда вы совершили оплату: 10 апреля или после майских праздников. В итоге вы платили огромные деньги, а продукт использовали меньше, что обидно. К сожалению, в крупных государственных компаниях (а именно в такой я пять лет работал с Nintex) часто не удаётся пройти все согласования вовремя — и один раз я имел очень неприятный разговор с СБ на предмет того, почему новая лицензия начиналась не с завтрашнего дня, а задним числом.
Несмотря на то, что продукты Nintex очень популярны в больших компаниях с огромным количеством процессов, эти компании всё равно вынуждены нанимать разработчиков, так как эта платформа тоже имеет свои ограничения. Например, однажды при обновлении с одной минорной версии на другую у нас сломались некоторые процессы, внутри которых был JS-код. Починить это получилось, только переписав весь код практически полностью, потому что Nintex изменила логику его обработки.
Microsoft Power Platform
В облачной экосистеме Microsoft есть целый спектр решений для создания NC/LC-решений. Это платформа Power Platform, которая состоит из четырёх основных компонент:
Power Apps — решение для создания приложений (причём это могут быть не только формы). Маркетологи Microsoft утверждают, что Power Apps позволяет создавать приложения практически любой сложности — от однокнопочного решения, рассылающего письма, до полноценных порталов с личным кабинетом пользователя, кучей интеграций с внешними системами и т. д.
Power Automate — конструктор потоков, с помощью которых можно автоматизировать бизнес-процессы.
Power BI — очень мощная система для аналитики.
Power Virtual Agents. Хотите создать бота? Вам сюда. Кстати, боты для Teams будут бесплатны.
Как сказано выше, Power Platform — облачное решение. Для работы с ним необходима подписка Microsoft 365, причём лицензия нужна каждому пользователю, который работает с платформой.
Очевидно, что перечисленные решения — далеко не полный список в мире NC/LC-решений. Есть и другие: K2, которое теперь является частью Nintex, DocTrix от компании i-Sys Labs, Mendix и другие. У каждого из них есть свои как плюсы, так и минусы. Например, DocTrix легко может сравниться по возможностям с Nintex, а стоит гораздо дешевле. К тому же это российская разработка, а значит, техническая поддержка оказывается на русском языке. Однако полноценное сравнение всех этих решений выходит за рамки данной статьи.
Минусы Power Platform, которые перекрыли все плюсы
Лицензии. С одной стороны, Power Platform входит в минимальную лицензию E1, с другой — очень быстро упираешься в ограничения стандартного функционала. Одни из самых востребованных «кубиков» — внешний HTTP request и шаблонизатор Word — требуют лицензию Power Automate Plan 2, что выливается в дополнительные затраты. Напомню, что лицензия нужна каждому пользователю, который работает с приложением, причём даже если пользователь использует данный функционал нечасто, платить за лицензию приходится постоянно.
Нет возможности совместной разработки приложений. На момент написания статьи Microsoft анонсировала эту фичу, но когда она станет общедоступной и как это будет выглядеть, пока непонятно. В результате, если вы работаете в команде, то за доступом к приложению нужно буквально вставать в очередь.
Скорость. Решения на Power Apps работают довольно медленно. Первая загрузка формы может достигать 30 секунд и более, что в современном мире просто неприемлемо. Когда пользователю надо быстро согласовать несколько заявок, ждать загрузки каждой из них по полминуты — ну такое…
Сложность построения тестовой среды. Power Platform позволяет копировать приложения и потоки, но делать это нужно очень аккуратно, ибо везде свои GUID’ы: одно неверное движение — и вот уже тестовые данные летят в продакшен.
Сложность настройки бэкапов. Если в Power Apps есть хоть какая-то версионность, то Power Automate не поддерживает даже её. Более того, нет никакой корзины — случайно удалённый поток придётся переделывать с нуля. Потоки и приложения, конечно, можно экспортировать и хранить в Git, но делать это нужно вручную — очень легко ошибиться.
Я могу достаточно долго перечислять минусы Power Apps разной степени критичности. С некоторыми из них вполне можно жить, но в какой-то момент, когда приложение разрастается до чего-то действительно серьёзного, понимаешь, что проще всё это написать, например, на Vue, React или Angular.
Что касается Power Automate, то тут самый большой минус — огромная ручная работа, которая неизбежно приводит к неприятным ошибками.
Почему не все NC/LC-решения прижились в Ozon
В Ozon я руковожу группой автоматизации процессов, и мы используем Power Platform для автоматизации внутренних процессов: различных видов заявок (на обучение, командировки, подбор персонала и т. д.), заказа и выдачи сим-карт и многих других. Эта платформа (в связке с SharePoint Online) была выбрана в связи с тем, что на ней довольно быстро можно создавать необходимые нам приложения и автоматизировать процессы. А скорость разработки для нас критический фактор.
В результате мы начали переносить (читай: создавать с нуля) процессы в Power Automate, и приложения — в Power Apps. Однако почти сразу выяснилось, что сделать это не так просто, как нам казалось.
Наша основная задача состояла в том, чтобы максимально быстро перенести функционал из другой информационной системы. А из-за особенностей Power Platform делать это приходилось для каждого процесса практически с нуля. Например, роли пользователей, которые в исходной ИС были стандартными, в Power Apps приходилось каждый раз создавать заново, а потом прописывать логику их работы в Power Automate.
Боль с комментариями. В SharePoint Online некоторое время назад появилась возможность комментировать элементы списка и, что самое главное, в комментариях можно упоминать других пользователей, которым сразу предоставляется доступ к элементу и отправляется письмо-уведомление. Да, не брендированное, но с этим мы готовы были смириться. И в принципе данная фича нас и, главное, заказчиков полностью устраивала — кроме одного критичного момента: у каждого пользователя, который имеет доступ к элементу списка, есть возможность удалить все комментарии — как свои, так и чужие. И этот факт не позволяет нам пользоваться стандартными комментариями, а заставляет к каждому сервису прикручивать свои, а потом в Power Automate создавать логику отправки уведомлений и предоставления доступа.
Ещё один проблемный кейс — работа с уведомлениями. При автоматизации бизнес-процесса согласования заявок в приложении Power Apps у нас есть довольно много кнопок, каждая из которых запускает тот или иной поток Power Automate. Потоки эти, кроме всего прочего, рассылают уведомления пользователям. Так вот, шаблон каждого уведомления необходимо создавать отдельно. Кроме того, по необъяснимой причине в некоторых потоках эти шаблоны ломаются — и пользователь получает нечитаемую кашу. Закономерности найти не получается, и единственное решение — создавать отдельную переменную для каждого шаблона и уже её использовать внутри «кубика», отправляющего уведомления. В результате 80% времени уходит на возню с письмами.
Конечно, мы копировали приложения и процессы, чтобы не создавать их с нуля для каждого бизнес-процесса и переиспользовать одинаковый функционал, однако разница в самих бизнес-процессах часто не позволяла сделать это быстро и безболезненно. В Power Apps практически отсутствует возможность создавать паттерны и копировать наборы полей, чтобы использовать их в разных приложениях. В Power Automate есть возможность скопировать один «кубик» или даже целый набор (объединив их в Scope), однако это не всегда хорошо работает, например, если вы используете циклы, условия и другие логические конструкции. В результате, чтобы хоть как-то ускорить процесс переноса сервисов, нам пришлось обратиться к сторонней компании, которая помогала создавать приложения Power Apps, а мы в это время делали логику на Power Automate, чтобы потом совместными усилиями скрестить одно с другим.
После четырёх месяцев разработки решений на Power Platform мы пришли к выводу, что дальше так дело не пойдет. Бэклог проектов растёт, а мы большую часть времени едим кактус из минусов Power Platform. Последней каплей стало то, что нам необходимо было делать приложения в едином корпоративном стиле, что в Power Apps практически невозможно. Костылями прикручивать CSS по видеороликам с YouTube никто не хотел.
В результате приняли решение постепенно отказаться хотя бы от Power Apps, так как потоки Power Automate даже со всеми минусами нас устраивали, по крайней мере пока. Для фронтенда выбрали Vue.js, а бэкенд оставили на связке SharePoint и Power Automate. Мы думали о разработке кастомного решения, но при наших масштабах это как стрелять из пушки по воробьям. Аналитики же продолжают делать отчёты в Power BI.
Неоспоримым плюсом такого решения является то, что приложения на Vue.js можно делать как внутри SharePoint, так и вовне. Весь вопрос — в авторизации, который довольно легко решается с помощью Nuxt.js и MSAL. Ещё одно преимущество такого решения — масштабируемость. В будущем нам придётся дорабатывать функционал существующих сервисов, а организация нормальной тестовой среды в Power Platform — занятие слишком трудоёмкое.
Выводы
Наш опыт показывает, что нет единственно верного инструмента для создания приложений. NC/LC-решения хороши для разработки небольших приложений, которые выполняют одну-две функции. Создавать же Enterprise-решения до сих пор проще и быстрее с помощью классических методов разработки. Связано это, как мне кажется, с тем, что Microsoft в своих продуктах сделала очень сильный упор на интеграцию с внешними системами, не задумываясь об удобстве для разработчиков. Что толку от 500+ коннекторов в Power Apps, если использовать большую их часть можно, во-первых, только с Premium-лицензией, покупать которую нужно для всех пользователей, а во-вторых, через боль и страдания? Гораздо проще использовать public API внешних систем в своём собственном решении.
Прежде чем пойти по пути NC/LC-решений, необходимо очень тщательно взвесить все плюсы и минусы выбранной вами платформы.
Определите для себя критерии для сравнения. Например:
стоимость и сроки внедрения,
условия лицензирования,
функционал,
наличие специалистов в штате или необходимость привлечения сторонних специалистов,
сложность поддержки,
возможности кастомизации и масштабирования.
Если ваша компания не готова создавать отдел разработчиков, но автоматизировать процессы ей необходимо, можно посмотреть в сторону решений Nintex. Да, они дорогие, но с ними любой power user сможет быстро и достаточно качественно создавать сложные формы и потоки. В случае же если у вас небольшая компания и вы уже пользуетесь продуктами экосистемы Microsoft 365, Power Platform, возможно, будет лучшим решением. Но, когда вы работаете в IT-компании, в которой 10 000+ сотрудников, а процессы сложны настолько, что на их анализ уходят месяцы, лучше сто раз подумать, прежде чем выбрать какое-либо NC/LC-решение. Полагаться на них на 100% — значит обречь себя на все те страдания, которые описаны в статье.
