Ускорение внутренней разработки приложений с помощью платформ Low‑Code и No‑Code

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

Созданию таких платформ способствовал дефицит специализированных приложений, которых нет в App Store или Google Play, нехватка квалифицированных программистов, перегрузка IT-отделов и аутсорсинговых агентств, высокие затраты и длительные сроки разработки, а также неоднородное качество получаемых решений.

В результате аналитическое агентство Gartner Inc. предсказало, что к 2024 году разработка приложений на платформах low-code будет составлять более 65% всей активности в этой сфере.

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

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

«Что удивительно, так это их высокая эффективность на таких платформах», — отмечает Майк Ширальди, ведущий архитектор решений в Mendix (Бостон). — «Они не застревают в изощренном синтаксисе языков и при этом уникальным образом понимают бизнес-проблему, пробел в процессе и способ его устранения».

В 2018 году Mendix была приобретена Siemens.

Сотрудники-разработчики

В компании Flowserve (Ирвинг, Техас), производящей решения для управления потоками жидкостей для нефтегазовой отрасли, сотрудники использовали low-code платформу Appian (Тайсонс, Вирджиния) для создания приложений самых разных целей, в том числе портала сервисного центра для процесса ремонта насосов. С помощью приложения сотрудник создает заказ на ремонт, а затем фиксирует и управляет всеми связанными данными: осмотром, расчетом стоимости, координацией труда и запчастей, согласованием и утверждением, а также отгрузкой и выставлением счета.

Для нужд Flowserve готовое коробочное ПО просто не существует, утверждает Малкольм Росс, заместитель технического директора и вице-президент по продуктовой стратегии Appian.

«Существует ПО для управления запасами и HR-ресурсами, но ничего, что объединяло бы труд и запчасти вместе», — говорит Росс.

Low-code платформы позволяют бизнес-пользователям, как сотрудники Flowserve, разрабатывать индивидуальные решения для автоматизации и организации процессов.

«Любой пользователь low-code, создающий пользовательское приложение, обладает глубоким знанием о решаемой проблеме и процессе», — говорит Теджас Гадхиа, главный евангелист платформы разработки в Zoho Corp. (Плезантон, Калифорния). — «Это главное преимущество low-code: разработка остается внутри компании, вместо того чтобы пользователям приходилось формулировать требования для IT-команды или внешних разработчиков».

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

Гибкая разработка приложений

«Это оказывается самым важным, если вы хотите действительно гибкую и инновационную разработку: передайте приложение пользователям, получите обратную связь и выпустите итерацию», — говорит Правін Сешадри, CEO AppSheet (Сиэтл). — «Именно количество качественных итераций превращает приложение в полезный и успешный инструмент. Скорость итераций — залог успеха».

Хотя разработка и использование приложения уже ценны тем, что повышают производительность, на определенном этапе производители понимают дополнительную ценность платформы в создании множества приложений. Это осознание часто приходит от команды аналитики, которая видит: приложения не только повышают продуктивность, но и собирают данные, используемые ERP, MES или PLM системами завода.

«Это как золото», — говорит Сешадри. — «Оно дает представление о вещах, о которых мы раньше не имели никакой информации».

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

«Это стимулирует стратегическое мышление: как сделать нашу компанию фундаментально более конкурентоспособной?» — добавляет он.

Кейс повышения эффективности

Элайджа Магрейн, директор по операциям в Tutti Gourmet (производитель здоровых снеков в Хадсоне, Квебек, Канада), начал использовать AppSheet около 16 месяцев назад для управления запасами.

Раньше инвентаризация проводилась путем физического подсчета с последующим ручным вводом в таблицы. Ошибки были частыми, некоторые позиции упускались. С платформой Магрейн создал приложение для инвентаризации с формулами и расчетами, как в электронных таблицах, а позже добавил штрих-коды и QR-коды, автоматизировав подсчет.

«Внедрение системы штрих-кодирования через AppSheet и автоматические уведомления о пополнении запасов повысили нашу эффективность и гарантировали, что мы всегда способны выполнять заказы и производить на полной мощности», — говорит Магрейн.

Всего Магрейн создал около 40 приложений для повседневных операций: учета рабочего времени, списков одобренных поставщиков, чек-листов осмотров, управления складскими запасами, отслеживания распределения продукции и многого другого.

«Честно говоря, сейчас у меня полнофункциональная ERP на базе AppSheet», — отмечает он.

Благодаря облачной природе платформы, руководитель Магрейна может получать доступ к приложениям инвентаризации, управления проектами и НИОКР в дороге. Новый менеджер по продажам может отслеживать, когда магазин получал поставку, и при необходимости сделать звонок.

«Low-code относится к коду как префабрикированный дом — к дому, построенному с нуля».

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

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

Критическая важность обновляемости

Главное различие между DIY-платформами — возможность для технически подкованного создателя добавить собственный код.

No-code решения предлагают 100% разработку «точкой-и-кликом» и ориентированы на бизнес-пользователей без навыков программирования. Чаще всего это инструменты для замены или усиления таблиц. AppSheet — no-code платформа.

Low-code инструменты также в основном используют настройку «точкой-и-кликом», но предоставляют расширенные возможности через скриптовые языки для сложной бизнес-логики. Они адресованы пользователям с большей технической подготовкой, но не уровня профессиональных разработчиков. Appian, Mendix и Zoho Creator — low-code платформы.

«Low-code к коду — как префабрикированный дом к дому, построенному с нуля. No-code — это по сути готовый "двойной широкий" дом», — говорит Джон Сколамьеро, менеджер по архитектуре и управлению в Mendix.

Различия не ограничиваются no-code/low-code. Безопасность варьируется у разных вендоров.

«Всегда полезно изучить страницу безопасности вендора, чтобы узнать их политики и процедуры обработки данных», — советует Гадхиа.

Оценщики могут запросить у вендоров детали сертификаций: ISO 27001 (управление информационной безопасностью) и SOC 2 Type II (контроли безопасности, доступности, целостности обработки, конфиденциальности и приватности).

Безопасность — только часть; понимание политики конфиденциальности не менее важно. Клиенты должны убедиться, что приложение, данные и интеллектуальная собственность принадлежат им, а не вендору. Также нужно гарантировать, что информация не будет продана или передана третьим лицам.

Ценность low-code/no-code — не только в составлении приложений, но и в их постоянном сопровождении и обновлении жизненных циклов платформы при использовании на мобильных устройствах или в вебе, подчеркивает Росс. Именно здесь часто возникают проблемы с корпоративным ПО.

«Идея "построил один раз — и всё работает" обманчива. Тот факт, что приложение работает с мобильной ОС сегодня, не значит, что оно будет работать в следующем году при выходе iOS 13, 14 или 15».

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

«В качестве параллели я часто спрашиваю: "Какую версию Google вы используете?" Google обновляет поиск и браузер буквально каждый день, но мы не думаем об этом как о версии — это сервис. Именно к такому модели потребления платформ мы должны стремиться», — говорит Росс.

Сколамьеро добавляет, что при выборе платформы стоит спросить, является ли она cloud-native, то есть соответствует ли она принципам архитектуры, позволяющей работать не только в одном облаке, но и выполнять процессы в любом облаке, on-premise и интегрироваться со всем этим.

«Мы живем в гибридном мире: ПО выполняется внутри очень защищенных систем без доступа в интернет, но также должно работать в облаке и интегрироваться с ним», — отмечает он.

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

«Допустим, вы создаете приложение для осмотра оборудования на заводе. Оно берет данные об оборудовании из ERP и фиксирует результаты осмотра. При обнаружении повреждения можно сделать фото и уведомить ответственного за ремонт. Каждое утро руководству нужен отчет о повреждениях».