Платформы быстрой разработки (low-code) часто описывают как способ ускорить разработку или обойтись меньшим количеством кода. На практике при его использовании гораздо интереснее другой вопрос: какие задачи в принципе имеет смысл решать таким способом? Опыт компании «ФАРН» показал, что ответ находится где-то между возможностями Excel и затратами на создание полноценной корпоративной системы учёта.
Реклама. ООО «Хи-Квадрат» ИНН 7718990614
erid: F7NfYUJCUneVewx6NQqW
Компания «ФАРН» занимается буровыми и буровзрывными работами для горнодобывающих и строительных предприятий. Производство распределено по удалённым площадкам, поэтому первичные данные собираются оттуда и регулярно сводятся в единую картину.
Для каждой площадки нужно учитывать объём бурения, работу станков и машинистов, простои оборудования и их причины. Часть показателей, например, скорость бурения и коэффициент технической готовности, закреплена в договорах с заказчиками.
Отдельная задача — учёт номерного бурового инструмента и его фактического ресурса: это позволяет сравнивать инструмент разных поставщиков не только по закупочной цене, но и по стоимости эксплуатации.
Долгое время эти данные существовали в Excel. В таблицах уже были формулы и методика расчёта показателей, на их основе строились аналитика и формы отчётности, поэтому заново проектировать бизнес-логику не требовалось.
Задача заключалась не в замене Excel. Проблемой стал способ работы с данными. На удалённых участках сотрудники подключались к файлам через VPN, несколько человек одновременно не могли работать с одной таблицей, а случайное изменение формулы или структуры файла создавало дополнительный риск.
Нужно было перенести сложившуюся модель в многопользовательскую систему, где сотрудники разных площадок одновременно вносят данные, руководство видит актуальные показатели, а формы и логику можно менять вместе с производственными процессами.
Первым вариантом была разработка системы под заказ. Компании, к которым мы обращались, оценивали такой проект примерно в полгода и 1–2 млн рублей. Последующие изменения также потребовали бы возвращаться к подрядчику, ставить новую задачу и оплачивать доработку или изменения.
Помимо сроков и стоимости, для нас эта модель была неудобна ещё по одной причине. Производственные процессы и необходимая логика системы хорошо понятны внутри компании, но собственной команды разработки не было. Я работал единственным системным администратором и параллельно отвечал за остальную ИТ-инфраструктуру.
При заказной разработке предметные знания пришлось бы сначала переводить в требования для внешней команды, а самостоятельная разработка с нуля потребовала бы слишком много времени и дополнительных компетенций.
Поэтому мы стали искать low-code-платформу, которая позволила бы собрать систему своими силами. Основными требованиями были небольшой объём программирования, быстрое развёртывание и наличие технической поддержки. Я уже работал с SQL, поэтому искал решение, для которого этих знаний было бы в основном достаточно.
В итоге остановились на XSQUARE. Ключевым аргументом стала возможность самостоятельно менять приложение: добавлять показатели, перестраивать формы и корректировать логику по мере развития системы. Для производственных процессов, требования к которым уточняются уже в ходе эксплуатации, возможность быстро вносить такие изменения оказалась одним из основных критериев выбора
Технической основой пилота стали XSQUARE-PGHS и XRAD. PGHS использовался как сервер приложений, а в XRAD я собирал формы ввода и интерфейсы для работы с производственными данными. Основным рабочим инструментом был SQL; в отдельных местах потребовался JavaScript, но писать приложение с нуля на традиционном стеке не пришлось.
Первоначально этой связки было достаточно для работы с производственными данными. Затем понадобился отдельный отчётный контур. У каждого заказчика форма отчётности могла быть закреплена непосредственно в договоре, поэтому к системе подключили XSQUARE-REPORTS. Он использовался для формирования отчётов в формах, предусмотренных договорами с конкретными заказчиками.
В результате получилась достаточно простая схема: единая база производственных данных, прикладной слой с формами и рабочими интерфейсами и отдельный контур формирования отчётности. При этом компоненты приложения можно было дорабатывать по мере изменения требований, не перестраивая систему целиком.
Для пилота выбрали один производственный участок, где сотрудники параллельно работали в Excel и новом приложении. Так можно было сверять данные с привычными таблицами и одновременно проверять новую систему в реальной работе.
Разработка шла короткими итерациями: я создавал базу и формы, сотрудники начинали ими пользоваться и давали обратную связь, после чего интерфейсы дорабатывались. Некоторые формы и модули в ходе пилота приходилось перестраивать практически с нуля, но накопленные данные оставались в базе: менялись интерфейс и логика работы с ними, а не сами производственные данные.
От начала разработки до готового пилота прошло около четырёх месяцев.
Отдельной проектной команды не было: систему собирал я один, совмещая эту работу с поддержкой остальной ИТ-инфраструктуры компании. В пилоте пять сотрудников вносили производственные данные, а около десяти руководителей использовали получаемые показатели.
Это стало одним из главных результатов эксперимента с low-code. Он не отменил необходимость технических компетенций: для разработки потребовались SQL, базовый JavaScript и понимание структуры данных. Но этого набора оказалось достаточно, чтобы один специалист мог самостоятельно развивать систему без отдельной команды разработчиков.
Также между пользователем и разработчиком исчез длинный цикл согласований: зная производственный процесс, я мог сам изменить форму или логику приложения и сразу вернуть новую версию в работу.
Объектом пилота стал учёт буровых работ. В модели учитывались буровые станки и работающие на них машинисты, проекты и относящиеся к ним параметры скважин: координаты, глубина, плановый объём бурения и фактическое выполнение. Отдельно вёлся учёт бурового инструмента: каждая единица имела индивидуальный номер, что позволяло отслеживать её фактический ресурс.
Один из интерфейсов появился уже в ходе пилота. Изначально сменные данные вводились отдельно по каждому станку, причём дату и смену приходилось каждый раз указывать заново. При 10–15 станках это означало столько же однотипных операций.
Поэтому я сделал групповую форму: дата и смена задавались один раз, затем пользователь заполнял показатели по всем станкам, а после сохранения система создавала в базе сразу 10–15 отдельных записей. Первоначально даже в техподдержке XSQUARE сомневались, что такой сценарий можно реализовать средствами платформы.
Руководители получили сводную картину по каждому производственному участку: объём выполненного и забракованного бурения, время работы и простоев техники, скорость бурения. Отдельно контролировались договорные показатели: скорость и коэффициент технической готовности. Значения в пределах нормы отмечались зелёным, отклонения — красным.
Ещё один блок связал производство со снабжением. По номерному инструменту накапливались данные о фактическом ресурсе — сколько метров отработала каждая единица. Это позволяло при закупках сравнивать инструмент разных поставщиков не только по цене, но и по стоимости его фактической работы.
Эффект от пилота не измеряли в процентах. Формулы и методика расчёта показателей существовали и раньше, поэтому сама аналитика принципиально не изменилась. Изменился способ работы с данными.
В результате принципиально изменилась не столько сама аналитика, сколько качество работы с ней. Данные, которые раньше хранились и обрабатывались в отдельных Excel-файлах, стали частью единой многопользовательской системы: сотрудники участка вносят их в общую базу, а руководители сразу используют актуальные показатели для контроля производства.
Пилот показал, на каких этапах low-code действительно сокращает потребность в ресурсах. Для разработки не потребовалась отдельная команда аналитиков и программистов: предметная экспертиза и разработка были в руках у одного человека.
Мне не требовалось сначала объяснять внешней команде, как учитывается ресурс бурового инструмента или рассчитывается конкретный производственный показатель, а затем проверять реализацию. Та же логика работала при доработках: изменение формы или бизнес-логики не запускало новый цикл постановки задачи подрядчику.
Поэтому главным преимуществом low-code в нашем случае стала не «разработка без кода», а возможность сократить путь от знания производственного процесса до его реализации в системе.
Пилот показал, что тот же подход применим и за пределами буровых работ. В планах модули для охраны труда и пожарной безопасности. Например, контроль регламентных сроков, а также регистрация входящих и исходящих документов.
В результате low-code стал не просто заменой Excel, а основой для собственной специализированной системы учёта. По своей логике она уже приближается к «большим» корпоративным решениям: единая база данных, прикладные модули, многопользовательская работа, отчётность и централизованный доступ к актуальной информации. Отличие в том, что такую систему можно развивать постепенно, добавляя новые процессы и функциональные блоки по мере необходимости.
По мере появления новых модулей такая система может перерасти в собственную экосистему прикладных инструментов компании. На одной технологической основе можно последовательно автоматизировать разные процессы — от производственного учёта и отчётности до охраны труда, пожарной безопасности и документооборота. При этом отдельные приложения работают не изолированно, а становятся частями общей информационной среды, которую можно развивать под собственные процессы по мере появления новых задач.
В этом смысле low-code может занимать промежуточное место между таблицами и крупными корпоративными системами. По нашему опыту, он особенно уместен там, где предметная логика уже понятна внутри компании, требования продолжают меняться, а создавать для конкретной задачи отдельную команду разработки нецелесообразно.
Low-code — подход к разработке приложений, при котором значительная часть функциональности создаётся с помощью визуальных инструментов и готовых компонентов. В кейсе компании «ФАРН» он позволил одному системному администратору разработать систему производственного учёта с использованием SQL и отдельных элементов JavaScript.
В компании «ФАРН» сотрудники работали с производственными данными на удалённых площадках, а совместная работа с общими Excel-файлами через VPN была неудобной. Новая система позволила одновременно вносить данные, централизованно хранить их и предоставлять руководителям актуальные показатели.
Опыт компании «ФАРН» показывает, что это возможно для определённого набора задач. Пилотную систему создал один системный администратор за четыре месяца, используя low-code-платформу, SQL и базовый JavaScript. Однако необходимы понимание производственных процессов и технические компетенции.
В системе «ФАРН» учитываются объёмы бурения, работа и простои станков, показатели машинистов, параметры скважин и фактический ресурс бурового инструмента. Также контролируются договорные показатели, включая скорость бурения и коэффициент технической готовности оборудования.
В кейсе «ФАРН» формы и логика приложения дорабатывались по мере получения обратной связи от сотрудников. Например, вместо отдельного ввода данных по каждому станку была создана групповая форма: пользователь указывает дату и смену один раз, после чего система формирует отдельные записи для 10–15 станков.
Такой подход может подойти компаниям, у которых производственные процессы и требования к учёту хорошо известны, но нет собственной команды разработки. В случае «ФАРН» заказная разработка оценивалась примерно в 1–2 млн рублей и занимала около полугода. Low-code позволил создать пилот самостоятельно примерно за четыре месяца, однако эти сроки относятся к конкретному проекту и не гарантируют аналогичного результата в других компаниях.
Спасибо!
Теперь редакторы в курсе.