Дэвид Хеффлер, вице-президент по управлению продуктами компании Infor, рассказывает на портале ITPro Today о том, как раскрыть возможности успешного расширения ERP-решения в современном SaaS-ландшафте.

Расширение решений для планирования ресурсов предприятия (ERP) в среде с минимальным кодированием/без кодирования (low-code/no-code) претерпело значительные изменения за последнее десятилетие. До появления многопользовательского облака компании могли создавать все, что им заблагорассудится, в любой форме, поскольку они отвечали только за свою собственную систему. Если что-то выполнялось слишком медленно или слишком долго, компании могли добавить больше памяти. Кроме того, если в системе хранилось слишком много исторических данных, можно было купить дополнительную емкость. Однако с развитием SaaS-решений, когда ваша ERP-система является одной из многих в общем пространстве (представьте себе жильца кондоминиума), возможность «делать то, что хочется» больше не представляется возможной.

Как никогда ранее, среды low-code/no-code должны гарантировать, что процесс создания расширения будет работать эффективно, максимально используя ресурсы, выделенные вам как арендатору, и не влияя на других арендаторов в вашей среде SaaS. Эти инструменты также должны быть рассчитаны на всех — от гражданских разработчиков до профессионалов.

Как же определить, что используемый вами фреймворк создан с учетом этих целей? Начнем с определения того, что делает расширение успешным. Во-первых, оно должно решать конкретную бизнес-задачу. Это может быть как простое объединение данных из различных учетных систем, так и сложные модули, требующие таблиц, форм, бизнес-логики и влияющие на обработку информации в ERP. Во-вторых, каким бы ни было решение, его уникальность не должна жертвовать возможностью модернизации ERP. В-третьих, оно должно быть рассчитано на различных авторов. Это означает, что расширения могут исходить из различных источников: от поставщика ПО, партнеров и даже клиентов. Все эти источники должны работать в гармонии с ERP.

Достижение целей расширения: на что обратить внимание

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

Примерами являются:

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

Фреймворк также не должен наказывать вас, если первоначально ваше расширение было создано по модели no-code, но требует дальнейшего развития. Он должен позволять брать готовое решение и развивать его, используя возможности low-code и даже full-code, а не начинать все сначала.

Возможность обновления расширений

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

Ориентируйтесь на цель расширения

Вам необходимо, чтобы расширение улучшало ведение бизнеса, а наличие фреймворка, который по умолчанию учитывает некоторые базовые потребности (такие как навигация по записям и FCRUD [Function Create Read Update and Delete]), позволяет быстрее реализовать окупаемость инвестиций в расширение за счет сокращения времени разработки.

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

Масштабируемость

Многие расширения начинаются с малого — как по функциональности, так и по количеству пользователей, обращающихся к ним. Однако неизбежно, что расширение будет развиваться. Либо будет расширяться функциональность, либо будет увеличиваться количество пользователей. Фреймворк, на котором построено расширение, должен быть способен адаптироваться к этим изменениям и росту без вмешательства разработчика. Если фреймворк имеет все необходимые элементы, он сможет расширяться и сжиматься в соответствии с потребностями вашего расширения. Если для решения необходимо получить миллионы строк по уникальному запросу, то хороший фреймворк будет обладать функциями, позволяющими выполнять пакетный поиск записей для снижения нагрузки на облачную ферму, а также способностью увеличивать/уменьшать масштаб, чтобы не затрагивать других арендаторов в процессе выполнения запроса.

Эволюция vs. революция

Технологии развиваются быстрыми темпами, и фреймворки low-code/no-code должны гарантировать, что при появлении новых возможностей (например, ChatGPT) не придется переделывать предыдущие расширения, чтобы использовать эти возможности. В противном случае это будет стоить вам времени и денег из-за ненужных переделок. В условиях современного быстро меняющегося конкурентного рынка это может серьезно повлиять на вашу прибыльность.