LC

Можно ли эффективно использовать low-code для реализации процессов в крупном бизнесе? Эту тему обсуждали на круглом столе «Игра в low-code: зачем это нужно enterprise», прошедшем в рамках конференции LOW-CODE 2022, организованной издательством «Открытые системы» (см. также «LOW-CODE 2022: Польза неоспорима, но не панацея» и «LOW-CODE 2022: Актуальность платформ для 'гражданских' разработчиков растет»).

Как признал Всеволод Шадрин, руководитель развития продуктов Naumen Platform, выступавший модератором дискуссии, при внедрении low-code часто приходится пресекать саботаж пользователей. Несмотря на, казалось бы, очевидную пользу такого подхода, сотрудники все равно сопротивляются насаждению новых инструментов. Еще чаще приходится сталкиваться с тем, что внедрение таких платформ саботируют внутренние разработчики, создающие «правильные» решения. Кроме того, в ходе дискуссии обсудили еще несколько актуальных вопросов. Как проще и правильнее проверить бизнес-гипотезу: по-быстрому «накодировать» или реализовать процесс в low-code? И уж если в компании случился low-code, то кто должен играть главенствующую роль для успеха работы: аналитики или разработчики?

Гражданские разработчики и ИТ-партизаны

«Low-code — это не только инструмент, но и средство изменения сознания. У айтишников и бизнеса головы работают принципиально по-разному: одни живут в пространстве векторов, объектов и свойств, а другие — в пространстве денег», — отметил Владимир Анисимов, директор по данным «Интер РАО-Онлайн». Перевод с одного языка на другой — наболевшая проблема, с которой сталкиваются почти все компании. Начиная жить в новом мире сложных конструкций, гражданские разработчики быстро приходят к пониманию того, что появление одной новой галочки в приложении может повлечь написание километров кода, то есть огромные доработки в унаследованных системах. Осознание принципов работы ИТ — очень важный результат усилий гражданского разработчика. До сих пор таких возможностей у бизнеса было мало.

Владимир Анисимов: «Осознание принципов работы ИТ — очень важный результат усилий гражданского разработчика. До сих пор таких возможностей у бизнеса было мало»

Разумеется, есть и обратная сторона медали. Когда бизнес приходит с запросами к ИТ, то часто слышит, что сделать это невозможно, долго или дорого. Однако уже реализованное low-code-решение перевести в продуктив гораздо проще. Именно поэтому роль low-code в современном бизнесе будет только расти.

«Без сомнения, low-code очень хорош для быстрого решения проблем, когда требуется буквально за несколько дней из подручных средств собрать и запустить какой-либо продукт. И по мере своего взросления low-code будет занимать все большее место в создании приложений», — уверен Дмитрий Калаев, директор акселератора ФРИИ. Популярность low-code растет — это бесспорно, причем в крупном бизнесе гораздо больше возможностей для его использования. Конечно, он не подойдет для решения всех корпоративных задач, но его применение может стать полезным для значительного числа перспективных направлений.

«У любого сотрудника есть поток задач. И чтобы с ними справиться, ему нужны компетенции и доступный инструментарий. Человек всегда зажат между скоростью потока задач и интенсивностью его обработки», — считает Станислав Фридкин, руководитель управления товародвижения и планирования компании Sunlight. Low-code — один из инструментов, с помощью которых люди могут выстроить свой рабочий процесс. У специалистов появляется выбор: либо по-прежнему абсолютно непрозрачно работать в электронных таблицах, либо выстроить процесс и добиться его прозрачности, попутно сняв с себя часть рутины и сократив трудозатраты. Не менее важен и другой аспект: когда визуально выстроена последовательность из квадратиков со стрелочками, всегда можно без труда точно повторить процесс.

«Low-code был и раньше. Лет пятьдесят назад могло бы быть точно такое же обсуждение: айтишники, писавшие программы для больших ЭВМ на ассемблере, презирали Фортран, который являлся языком высокого уровня (то есть был low-code по сравнению с ассемблером) и давал ученым возможность быстро делать расчеты», — напомнил Леонид Головин, советник генерального директора по цифровой трансформации «Газпромтранса».

Леонид Головин: «Low-code был и раньше. Лет пятьдесят назад могло бы быть точно такое же обсуждение: айтишники, писавшие программы для больших ЭВМ на ассемблере, презирали Фортран, который являлся языком высокого уровня (то есть был low-code по сравнению с ассемблером) и давал ученым возможность быстро делать расчеты»

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

Возможно, ИТ-директор должен действовать в тандеме с директором по развитию или инновациям. Именно так можно обеспечить правильную работу с гражданскими разработчиками.

Впрочем, как предположил Фридкин, ИТ-директор может и не знать, над какими проблемами бьются эти партизаны и какими средствами пытаются их решить. Аналогия с партизанами возникает не случайно: зачастую пользователи вынуждены скрывать свои разработки, чтобы не получить по рукам. «Мне приходилось видеть такие ситуации не только в наших, но и в зарубежных компаниях. Попытки делать собственные инструменты воспринимаются как проявление агрессии по отношению к корпоративным системам и могут иметь дисциплинарные последствия», — рассказал Фридкин.

Между жадностью и страхом

Почему внутренние разработчики противостоят внедрению low-code? Они ведут себя как снобы или просто больше знают и поэтому настроены скептически?

«Low-code по идеологии ближе к микросервисной архитектуре. Но в большинстве компаний до сих пор используются монолиты. Встраивать в них доработанные кусочки всегда долго, дорого и трудно, потому что после доработки систему приходится тестировать полностью», — пояснил Анисимов. Именно это и вызывает основное сопротивление: как только создан работающий прототип и встает речь о его внедрении, у разработчиков появляется очередная головная боль. В компании с микросервисной архитектурой это воспринимается гораздо проще. Однако, по мнению Анисимова, другого пути нет. Low-code на данный момент является единственным способом быстрой проверки бизнес-гипотез.

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

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

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

«Поспорю с тем, что настоящие программисты должны бояться лоукодеров. Скорее, лоукодеры должны бояться за себя», — заявил Головин. Еще два года назад нейросеть DALL-E, рисующая изображения по их текстовому описанию, казалась чем-то фантастическим. А сейчас таких систем уже много, и в результате дизайнеры начинают терять работу. Вполне вероятно, что через несколько лет введенной фразы с описанием желаемого результата будет достаточно для того, чтобы искусственный интеллект предложил готовый прототип системы. Бизнес-руководители будут аплодировать, и никакие гражданские разработчики уже не потребуются. Самым ценным сотрудником станет тот, кто знает, что ему нужно, и способен это сформулировать нормальным языком.

Обойтись без low-code?

«Сейчас почти все выпускники вузов и даже школьники знают Python и не горят желанием изучать другие варианты. У этого языка достаточно большие возможности, и проверить с его помощью гипотезу вполне возможно, даже если код не выдерживает критики», — утверждает Анисимов. Сторонники других языков относятся к Python практически как к low-code. По мнению Анисимова, сейчас сложилась неоднозначная ситуация. С одной стороны, подрастает поколение, владеющее настоящим языком программирования, и им инструменты low-code не слишком нужны. С другой стороны, для разработки на Python все равно требуется довольно большое время. Предлагая пользователям какой-либо инструмент, важно четко понимать их потребности.

«В скорости low-code точно выигрывает, но мы платим за это ограничением возможностей. По моим ощущениям, экономия времени составляет около 20–30%», — оценил Анисимов.

Дмитрий Калаев: «Исходя из моей практики, вручную можно проверить 80% гипотез. Еще 15% имеет смысл проверять с помощью low-code, а еще 5% — лишь полноценным программированием»

Калаев уверен, что с точки зрения проверки бизнес-гипотез идеальный вариант — не программировать вовсе. Некоторые из гипотез можно проверить в буквальном смысле вручную: с ручкой и бумагой. «Исходя из моей практики, вручную можно проверить 80% гипотез. Еще 15% имеет смысл проверять с помощью low-code, а еще 5% — лишь полноценным программированием», — отметил Калаев. Конечно, проще всего пользоваться привычным инструментом, а подумать и понять, как решить задачу проще, — отдельный навык изобретателя.

Как утверждает Калаев, команда, проверяющая гипотезы, обходится в 15–20 млн руб. в год. В зависимости от ее навыков и вида гипотез, она может проверять одну гипотезу в год, квартал или даже неделю.

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

Каждому свой инструмент

«Применять low-code или нет, должен решать бизнес, который больше всего в нем заинтересован. У аналитиков все и так неплохо, у разработчиков — еще лучше. А вот у бизнеса голова болит всегда», — объяснил Анисимов. Именно бизнес диктует требования к проверке гипотез на цифрах, и у него нет времени вставать в очередь на проверку, чтобы узнать, работает очередная идея или нет. А прототип, разработанный на low-code, позволяет не только оценить эффективность, но и «пощупать» созданное решение — это главный плюс такого подхода.

«Когда приходят бизнес-заказчики и требуют реализовать какую-то функцию, разработчики и аналитики испытывают лишь психологический дискомфорт. У них есть свои задачи, а главное — они все равно получат свои деньги», — иронизирует Калаев. А для бизнеса разработка новых приложений — это вопрос выполнения годовых показателей эффективности и получения премий.

Головин согласился с тем, что low-code как инструмент прототипирования более востребован у людей, работающих в бизнес-подразделениях, чем у системных аналитиков и разработчиков. Более того, он уверен, что low-code для ИТ-служб — очевидное зло. «Это все равно что предложить компании, которая строит здание, использовать алебастровую замазку. У нее есть свои инструменты и свои регламенты. А замазка — это скорее для тех, кто создает рядом киоск быстрого питания, чтобы быстро решить проблему с едой для строителей», — сказал Головин.

В итоге дискуссии эксперты сошлись во мнении, что каждому необходим свой инструмент: бизнесу — платформы low-code, а айтишникам — «нормальные» средства разработки. На данном этапе подход low-code, так же как некоторое время назад Agile, позволяет небольшими шагами прийти к тому, чего хотят бизнес-пользователи. Именно поэтому он стал так популярен.

В условиях пандемии COVID-19, роста расходов на здравоохранение и старения населения спрос на технологии искусственного интеллекта, адресованные отрасли здравоохранения, растет. Показательна динамика мирового рынка венчурного капитала: более 40 стартапов привлекли довольно значительное финансирование (20 млн долл. и более) для создания отраслевых решений на базе искусственного интеллекта. Как же на самом деле искусственный интеллект используется в здравоохранении?

Опрос '2022 AI in Healthcare Survey', в котором принимали участие более 300 респондентов со всего мира, был направлен на улучшение понимания проблем, достижений и примеров использования искусственного интеллекта в здравоохранении. Это второй такой отчет; по сравнению с первым результаты существенно не изменились, но указывают на некоторые интересные тенденции, предвещающие, куда качнется маятник в ближайшие годы. И если некоторые аспекты этой эволюции носят позитивный характер (демократизация искусственного интеллекта), то другие не вызывают особого энтузиазма (гораздо более протяженный фронт исследований и рост числа уязвимых мест). Перечислим три тенденции, о которых необходимо знать специалистам.

1. Простота использования и демократизация искусственного интеллекта; инструменты low-code/no-code

По оценкам Gartner, к 2025 году 70% новых приложений, разрабатываемых предприятиями, будут использовать технологии, не требующие написания программного кода или предполагающие минимизацию его объема (в 2020 году их доля не превышала 25%). Разработка в парадигме low-code снижает нагрузку на программистов, но наибольшее влияние окажут решения, не требующие написания кода и освоения науки о данных. Сегодня в среде пользователей систем искусственного интеллекта интересно наблюдать за явным сдвигом от технических специалистов непосредственно к экспертам в предметной области.

Более половины (61%) респондентов своими целевыми пользователями назвали практикующих врачей, далее следуют плательщики медицинских услуг (45%) и ИТ-компании, работающие в сфере здравоохранения (38%). В сочетании со значительными разработками и инвестициями в приложения искусственного интеллекта в сфере здравоохранения, а также с доступностью технологий с открытым кодом все это свидетельствует о расширении внедрения соответствующих технологий в отрасли.

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

2. Совершенствование средств обработки текстов и естественного языка

В ответ на вопрос о технологиях, которые планируется внедрить к концу 2022 года, руководители назвали интеграцию данных (46%), бизнес-анализ (44%), обработку естественного языка (43%) и аннотацию данных (38%). В настоящее время наиболее распространенным типом данных в приложениях искусственного интеллекта является текст с акцентом на обработку естественного языка (Natural Language Processing, NLP) и аннотирование данных.

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

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

3. Усиление угроз безопасности

Помимо прогресса в области искусственного интеллекта прошедший год продемонстрировал целый ряд новых векторов атак. На вопрос о том, какие типы программного обеспечения используются для создания приложений искусственного интеллекта, наиболее популярными вариантами ответов были: локально установленное коммерческое ПО (37%) и ПО с открытым кодом (35%). Наиболее заметным оказалось снижение использования облачных сервисов на 12% по сравнению с прошлогодним опросом (о них упомянули 30% опрошенных). Скорее всего, происходит это из-за проблем с конфиденциальностью при обмене данными.

Большинство респондентов (53%) при проверке моделей предпочитают полагаться на свои собственные данные, а не на показатели сторонних поставщиков программного обеспечения. 68% явное предпочтение отдают внутренней оценке и самостоятельной настройке своих моделей. С учетом строгого контроля и процедур, связанных с обработкой медицинских данных, очевидно, что пользователи искусственного интеллекта хотели бы, чтобы соответствующие операции выполнялись внутри компании — конечно, при наличии такой возможности.

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

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

Гиперавтоматизация – революционный подход, позволяющий предприятиям использовать преимущества цифровой трансформации максимально выгодно для себя. Гиперавтоматизация предусматривает применение передовых технологий автоматизации бизнес-процессов с помощью роботов (robotic process automation, RPA), искусственного интеллекта, машинного обучения, интеллектуального программного обеспечения управления бизнесом (intelligent business process management software, iBPMS) и процессного анализа в целях улучшения и автоматизации процессов способами более эффективными по сравнению с традиционными.

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

Почему необходим переход к гиперавтоматизации?

Гиперавтоматизация позволяет бизнес-командам переосмысливать свои процессы, не упираясь в ограничения какой-то одной технологии. Благодаря тщательному перепроектированию процессов они открывают для себя новые возможности, достигают более высокой степени удовлетворенности и вносят дополнительный вклад в решение когнитивных задач и вопросов, связанных с клиентами. Поскольку ключевое значение для гиперавтоматизации имеют платформы low-code, организации получают дополнительную гибкость, быстро адаптируясь к происходящим изменениям. В сочетании с «цифровыми сотрудниками» и программными ботами все это освобождает людей от необходимости выполнения рутинных операций, занимающих большую часть рабочего дня. Процессы модернизируются с помощью технологий искусственного интеллекта и машинного обучения.

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

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

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

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

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

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

Чего можно добиться?

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

Рассмотрим, к примеру, компанию медицинского страхования, которая обрабатывает почти 200 тыс. заявлений в год. Чтобы закрыть заявление, работник тратит в среднем полчаса в день на извлечение данных из системы CRM, вставку их в документ, вывод на печать и снабжение подписями. При использовании гиперавтоматизации процесс извлечения данных может быть автоматизирован за счет применения средств оптического распознавания символов, а информацию можно проверить при помощи инструментов автоматизации бизнес-процессов. Закрытие документа осуществляется с помощью электронной подписи. Время процесса в целом значительно сокращается, что приводит к существенному повышению окупаемости капиталовложений.

Улучшение клиентского восприятия. Согласно исследованию Zendesk, почти 80% клиентов при двух и более случаях неудачного опыта взаимоотношений с той или иной компанией пойдут к ее конкуренту. Чтобы клиенты лояльно относились к бренду, нужна персонализация ориентированных на них рабочих процессов. Технологии гиперавтоматизации, к примеру, могут использоваться для мониторинга взаимодействия с контактным центром. Использование средств обработки естественного языка помогает анализировать взаимодействие и настроения клиентов, проводить количественную оценку настроений, вычислять время задержки – то есть, рассчитывать все ключевые показатели клиентского восприятия (Customer Experience, CX), которые необходимы для понимания ситуации и принятия важных бизнес-решений.

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

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

Разработка low-code/no-code является центральным звеном гиперавтоматизации. Если гиперавтоматизация оптимизирует бизнес-процессы для беспроблемного проведения цифровой трансформации, то создание приложений с написанием минимального объема кода ускоряет эту процедуру, делая переход более быстрым и помогая поддерживать и модернизировать внедренные технологии. В условиях пандемии компании всего мира смогли по достоинству оценить гибкость и быстроту разработки low-code.

Сивашанкари Кришнамурти – менеджер компании Vuram по вопросам автоматизации доставки. На протяжении девяти последних лет она автоматизирует бизнес-процессов различных организаций. Имея опыт разработки более 100 бизнес-процессов с помощью инструментов гиперавтоматизации, основное внимание Кришнамурти уделяет вопросам успешного проведения клиентами цифровой трансформации. Она занималась реализацией различных программ с несколькими глобальными командами доставки и принимала участие в создании центров передового опыта.

Современные платформы для разработки без программирования или с написанием минимального объема программного кода (low-code/no-code) позволяют группам разработчиков ПО – и даже людям, не имеющим подготовки в области программирования – создавать, поддерживать и расширять достаточно большой спектр приложений. Среди наиболее распространенных сфер их применения следует отметить создание мобильных приложений, улучшение клиентского опыта (Customer Experience, CX), оптимизацию рабочих процессов, модернизацию унаследованных приложений, автоматическую интеграцию данных и поддержку их визуализации.

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

Затраты и экономия low-code/no-code

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

В качестве иллюстрации приведем следующие расчеты. Разработчики уровня бакалавра в США обходятся в год от 50 тыс. до 120 тыс. долл. (в среднем 72 тыс. долл.), а на создание с нуля простых приложений потребительского класса с написанием программного кода уходит от 6 до 25 человеко-месяцев (в среднем 12), так что разработка такого приложения обходится примерно в 72 тыс. долл. Разработка сложных приложений может стоить более 1 млн долл.

Если вы используете систему разработки low-code, которая сокращает время создания простого приложения до одного человеко-месяца (при затратах примерно в 6 тыс. долл.), но плата за лицензии составляет 10 долл. на пользователя, то при наличии 6600 пользователей ваши общие расходы превысят стоимость традиционной разработки. Но, опять же, это только приблизительная оценка.

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

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

No-code или low-code?

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

Для инструмента категории low-code, кривая обучения может оказаться круче, чем в случае no-code, но барьеры на пути расширения возможностей приложений здесь, как правило, ниже. Вместо покупки очередного компонента достаточно написать несколько строк кода, обращающегося к базовой системе, программе Open Source или API поставщика платформы.

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

Зачастую бывает так, что код, который требуется написать, семантически похож на уже знакомый вам язык. Например, инструмент Microsoft Power Fx базируется на Microsoft Excel, а Xbasic компании Alpha Software вырос из Microsoft Basic. Во многих инструментах low-code фигурирует язык, который либо тесно связан с JavaScript, либо использует реальный движок JavaScript, такой как V8.

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

Виды инструментов для разработки low-code/no-code

Прежде чем инициировать покупку инструмента для разработки low-code/no-code, следует задать себе несколько вопросов о приложении, которое вы будете предлагать, с тем чтобы понять, имеет ли все это для вас смысл. Предлагаю вам записать ответы на следующие вопросы.

— Вы собираетесь создавать настольное приложение? Для Windows? Для Mac? Для Linux? Для всего перечисленного?

— Собираетесь создавать веб-приложение? Для браузера на настольном ПК? Для планшетов? Для смартфонов? Для всего перечисленного?

— Планируете писать нативный код для мобильных устройств? Использовать гибридную веб-технологию? Использовать нативную среду и веб-контент? Использовать все перечисленное?

— У вас уже есть бюджет? Какой? Есть конкретные сроки? Насколько быстро надо все сделать? Сколько у вас разработчиков? Какими навыками они обладают? Согласуются ли ваш бюджет, сроки и ресурсы с целями создания приложения? Как вы это оценивали?

— Нужна ли вашему приложению база данных? Если да, идет ли речь об уже существующей базе данных или о новой? Будут ли клиенты обновлять базу данных?

— Нужно ли вашему приложению поддерживать связь с клиентами? Нужны ли другие специальные функции?

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

— Будут ли меняться или модернизироваться существующие бизнес-процессы? Пытаетесь ли вы оцифровывать существующую бумажную форму?

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

Настольные приложения могут создаваться для Windows, macOS, Linux, а иногда даже DOS. Мобильные – на Android, iOS и разновидностях этих операционных систем для планшетов и часов. К веб-приложениям относится практически все вышеперечисленное, а также дополнительная поддержка браузеров (Chrome, Edge, Safari, Firefox и Opera) и возможность адаптации к различным размерам экранов. Гибридные веб-приложения сочетают в себе свойства нативных приложений и веб-контента.

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

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

Известные платформы разработки low-code/no-code

В последний раз, когда я детально исследовал эту сферу, там было представлено более 400 вендоров. В Gartner своим анализом охватили около 250, пытаясь разбить их на постоянно меняющиеся категории. Многие вендоры и некоторые продукты подпадают под определение сразу нескольких категорий.

Не думаю, что средства управления бизнес-процессами (business process management, BPM) и роботизации бизнес-процессов (robotic process automation, RPA) следует объединять с другими инструментами low-code/no-code. Разница, на мой взгляд, заключается в том, что для инструментов BPM и RPA автоматизация и настройка систем является их основной целью. Обычные же инструменты разработки могут использовать корпоративные системы, но только в качестве средства для достижения другой цели.

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

В качестве иллюстрации я отобрал семь поставщиков систем low-code/no-code перечислив их в алфавитном порядке. Учтите, что включение в этот список не следует трактовать как рекомендацию, а исключение не является приговором.

- Alpha Software. Alpha Anywhere – инструмент полного цикла быстрой разработки low-code, который предназначен для создания разработчиками самой разной квалификации настольных приложений, веб-приложений и гибридных мобильных приложений, ориентированных на базы данных. Alpha TransForm – инструмент low-code/no-code, позволяющий разрабатывать мобильные формы с автономными возможностями и автоматической синхронизацией при возобновлении подключения.

- Appian. Appian предлагает визуальный конструктор no-code и инструменты low-code для создания веб-приложений и мобильных приложений, которые интегрируются с корпоративными данными без программирования. Кроме того, у Appian имеется платформа автоматизации для BPM и RPA.

- Claris. Claris FileMaker – система для разработки настольных, веб- и мобильных приложений категории low-code, включающая собственную базу данных. Она имеет встроенные шаблоны, поддерживает проектирование путем буксировки и интуитивный графический пользовательский интерфейс. Claris Connect – платформа автоматизации, построенная на том же ядре, что и FileMaker.

- Mendix. Mendix Studio – WYSIWYG-среда на основе браузера для разработчиков, которые создают приложения для массового потребителя. Mendix Studio Pro – среда с классическим интерфейсом дл ПК, включающая в себя все возможности, которые нужны для создания приложений, в том числе возможность добавления при необходимости программного кода. Mendix предлагает также платформу автоматизации и систему интеграции данных.

- Microsoft. Microsoft Power Apps – конструктор для Windows 10, требующий написания минимального объема программного кода и поддерживающий шаблоны, перетаскивание компонентов и Excel-подобный язык программирования Power Fx. В Power Apps используется языковая модель, способная генерировать код Power Fx из описаний на естественном языке. Профессиональные разработчики могут расширять возможности Power Apps с помощью Azure Functions и специальных коннекторов. Power Automate – отдельная RPA-платформа c поддержкой документооборота.

- OutSystems. Система OutSystems позволяет перетаскивать визуальные элементы для создания пользовательских интерфейсов, бизнес-процессов, бизнес-логики и моделей данных для веб-приложений и мобильных приложений, а также дополнять их программным кодом при возникновении такой необходимости. В ее состав входит 70 уже готовых шаблонов. Инструмент OutSystems Forge содержит тысячи модулей с программным кодом, которые можно перетаскивать в приложение и при желании расширять в среде IDE.

- Salesforce. Salesforce Lightning – инструмент для создания приложений на Salesforce Platform с возможностью буксировки и написанием небольшого объема программного кода. Lightning App Builder позволяет бизнес-пользователям выбирать модули для проектирования приложений. Lightning Web Components помогает создавать повторно используемые элементы.

Ключевые факторы при выборе платформы low-code/no-code

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

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

— Поддерживает ли предлагаемая платформа все желаемые цели? Если нет, продолжайте поиски. Если ни один из имеющихся вариантов не охватывает все желаемые цели, подумайте о сокращении списка целей с оставлением там наиболее важных устройств или браузеров.

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

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

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

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

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

Разработка приложений с написанием минимального объема программного кода сулит немалую выгоду. С одной стороны, слишком многие компании настаивают на том, что мобильные приложения должны иметь нативный программный код, после чего с изумлением узнают, что придется потратить 1 млн долл. и год на создание приложения для iOS, а затем еще 500 тыс. долл. и полгода на практически идентичное приложение Android. Имеет смысл сначала изучить альтернативные варианты с точки зрения как сокращения расходов, так и ускорения вывода приложений на рынок.

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

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

В общем случае, платформа разработки low-code предусматривает визуальный конструктор приложений посредством буксировки (drag-and-drop), модули, формы, процессы, потоки работ, модели данных, интеграции и один или несколько языков программирования, которые можете использовать в рамках этой платформы. Результатом разработки на такой платформе является спецификация, которую можно исполнить непосредственно либо компилировать в приложения. Приложение может взаимодействовать (а может и не взаимодействовать) с серверной частью платформы.

Существует несколько альтернативных парадигм проектирования приложений в режиме low-code — генераторы, шаблоны и простые языки конструирования. Например, генераторы, которые просматривают ваши базы данных и генерируют формы с привязкой к данным для каждой таблицы базы данных, позволяют начать работу очень быстро, в дальнейшем редактируя в соответствии с дополнительными требовании первоначально сгенерированные формы. Шаблоны более привлекательны, но менее гибки. Некоторые среды позволяют начать со сканирования форм, нарисованных на бумаге; другие позволяют начать с изображений, выполненных в Photoshop.

Задачи для разработки low-code такие же, что и для приложений, написанных вручную: настольных, веб- и мобильных. Настольные приложения обычно рассчитаны в рамках графических интерфейсов пользователя Windows, macOS и Linux. Веб-приложения должны работать во всех браузерах (Chrome, Edge, Safari, Firefox и Opera), и им необходимо оперативно обрабатывать различные размеры экрана. Мобильные приложения в первую очередь ориентированы на iOS и Android. Гибридные веб-приложения совмещают собственную оболочку с веб-контентом.

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

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

Что такое разработка no-code?

Разработка no-code — это, по сути, та же разработка low-code, но без языка программирования, который вы могли бы использовать в продукте. Создатели подобных платформ иногда создают ухищренные визуальные инструменты, призванные заменить написание фрагментов кода, но инструменты эти, как правило, неудобны и отнимают много времени.

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

Кто занимается разработкой low-code?

Продавцы low-code обычно говорят о нескольких типах пользователей своих продуктов. К ним относятся «гражданские разработчики» или «высококвалифицированные пользователи», а также бизнес-аналитики, администраторы баз данных и профессиональные программисты.

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

Существуют ли гражданские разработчики?

Термин «гражданские разработчики», похоже, пришел из мира аналитических систем, и у него тяжелое прошлое. Фактически, речь идет о не-разработчиках, не проходивших специального обучения, на которых тем не менее возложена ответственность за конфигурирование приложений. Я встречал несколько «гражданских разработчиков», так что они действительно существуют, но я обнаружил, что хорошие их представители быстро учатся кодировать на базовом уровне и свободно пользуются своим набором инструментов из разряда low-code. Однако большинство «гражданских разработчиков» знают только то, что им нужно, об инструментах, которые им необходимы для выполнения их обязанностей, оставляя собственно программирование другим людям.

В преимущества разработки low-code?

Разработка low-code часто сокращает время, необходимое для создания приложений, и снижает затраты. Она позволяет сотрудникам, обладающим лишь базовой квалификацией в сфере ИТ, вносить свой вклад в разработку, не полагаясь полностью на программистов и администраторов баз данных. На самом деле менее квалифицированные сотрудники могут оказаться теми, кто лучше всего понимает бизнес и цель приложения. «Менее квалифицированный» здесь относится лишь к их уровню знаний в области программирования.

Когда следует использовать разработку low-code?

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

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