SimbirSoft 0 комментариев

Как ускорить разработку систем для промышленности

Low code для промышленных систем: сначала сложно, но потом будет легче

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

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

Задачи системы

Low code-платформа подходит промышленным предприятиям и крупным компаниям с развитой сетью филиалов. 

Разработанное ядро системы управления производственными процессами (MES) имеет несколько подсистем. Отдельного внимания заслуживают:

  • BPMN-движок – система создания и управления бизнес-логикой
  • UI-конструктор, в котором можно генерировать интерфейс системы (модули и блоки для последующей работы) с помощью готовых компонентов или кастомных элементов. О нем мы расскажем далее.

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

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

Ядро выступает «оркестрантом» – оно позволяет получить единую экосистему для построения ИТ-ландшафта предприятия. 

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

Зачем был нужен UI-конструктор?

В рамках low code-подхода в системе реализовано:

1. Конструктор интерфейсов: позволяет создавать страницы портала без знания html и css, наполнять их данными, реакциями на события и действия пользователей. 

Решение упрощает жизнь специалистам, далеким от frontend-разработки и верстки, где одно неловкое движение может «сломать» отображение. Конструктор постоянно развивается и дополняется новыми функциями.

2. Конструктор запросов для получения данных, распределенных по разным базам. 

Для выгрузки информации из разных систем или баз данных (далее – БД) нужно владеть определенными навыками и знаниями по управлению БД и написанию необходимых для этого скриптов. Конструктор позволяет максимально упростить и ускорить составление запроса: пользователю достаточно указать необходимые поля, фильтры и сортировки, остальное преобразование будет происходить уже внутри системы.

На данном этапе подсистемы еще не позволяют полностью отказаться от специалистов с кодовой базой. Но при дальнейшем развитии продукта можно перейти на Low code-решение с минимальными затратами на разработку.

Но уже сейчас платформа открывает ряд возможностей:

  • предоставляет разработчикам функциональных модулей (про них мы рассказывали выше) инструмент для более быстрого создания интерфейсов работы с модулем.
  • обеспечивает единый вид и работу интерфейсов системы в условиях разработки модулей разными командами и постепенного добавления функциональности.
  • дает возможность конечным пользователям частично настраивать интерфейсы, адаптированные под нужды конкретного производства.

Кому могут быть интересны такие решения

Low code-платформа – универсальная система, которая покрывает потребности разных сфер бизнеса и позволяет:

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

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

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

Яркий пример – промышленные предприятия, где нужно настроить:

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

Тонкости создания Low Code-платформы

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

  • с её помощью создавать конечный продукт. 
  • непосредственно работать с этим продуктом. 

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

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

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

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

Подводные камни

При создании платформы не обошлось и без подводных камней. Далее расскажем, как их обойти.

Итак, при разработке UI-конструктора мы столкнулись с:

  • Необходимостью большого количества интеграционных тестов, не всегда очевидных из аналитики. 
  • Большим объемом тестовой документации, которую сложно поддерживать в актуальном состоянии. Как правило, такие крупные сложные системы имеют множество взаимосвязанных компонентов. Изменение в одном влечет изменения в других. Всё это нужно учитывать при будущих обновлениях продукта.
  • Выявлением недостающих критичных фич уже в процессе разработки. Это связано с масштабом системы, широким спектром компонентов и подсистем. 
  • Большое количество микросервисов в продукте влияет и на проработку архитектуры. Нужно заранее учитывать и предугадывать множество взаимосвязей и интеграций.

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

Предложили следующие решения:

  1. Мы проанализировали все баги и узкие места, которые возникали при использовании системы в промежуточном тестировании, и выявили часто повторяющиеся комбинации и проблемы. Все проверки включили в регресс.
  2. Воспользовались техникой попарного тестирования и составили максимально возможное количество комбинаций между элементами интерфейса, доступными действиями и событиями.
  3. После общения с заказчиком о задачах той или иной фичи и анализа бизнес-логики системы прописали основные интеграционные тесты.
  4. Поскольку без автоматизации тестирования невозможно быстро выпускать релизы, мы разделили процесс на этапы, чтобы снизить затраты и повысить эффективность. Совместно с заказчиком определили основные критичные сценарии, которые нужно проверять каждый раз при внесении правок в систему. Это позволило нам уже на самом начальном этапе запускать автотесты и покрывать критичный функционал, быстрее «заливать» хотфиксы или срочные доработки.

Выводы

В результате реализации проекта мы:

  • Выстроили процесс тестирования и адаптации требований под особенности системы.
  • Оптимизировали затраты на автотесты, чтобы они работали в минимально короткие сроки после внедрения на пользу проекта. 
  • Сделали продукт стабильным и отказоустойчивым.
  • Внедрили процесс нагрузочного тестирования, чтобы оценить отказоустойчивость системы и определить требования к оборудованию.

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

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

С помощью Low code предприятия могут выполнять широкий спектр задач:

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

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

Вам тоже нужна подобная система? Напишите нам. 

Реклама. ООО «СимбирСофт», simbirsoft.com

0 комментариев
Отправить
обсуждения
Здесь больше организационных вопросв, чем в самой платформе. Можно взять за основу Фабрику идей у Ев... СУМЗ: «Фабрика идей» и «Доска решения проблем» переходят на цифровую платформу
Белоярская АЭС принимает группы студентов, они могут быть и старше 18 лет. Но в целом да, в настояще... Туризм на АЭС: не развлечение, но просвещение
Отличный пример цифровизации или "умной фабрики", коллеги! А можете поделиться платформой ... СУМЗ: «Фабрика идей» и «Доска решения проблем» переходят на цифровую платформу
Узнайте больше Альманах “Управление производством” 300+ мощных кейсов, готовых к использованию чек-листов и других полезных материалов
Альманах “Управление производством”