Как выстроить стратегию разработки приложений low-code/no-code

Инструменты low-code/no-code могут помочь облегчить давление на ИТ-команды и раскрыть инновационный потенциал сотрудников, но для этого требуется правильная корпоративная стратегия, пишет на портале Enterprise Projects Рик Круз, директор отдела прикладных и информационных решений и тестирования компании Computer Task Group.

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

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

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

1. Повышение осведомленности об официальных наборах данных и обеспечение легкого доступа к ним

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

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

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

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

2. Интеграция усилий бизнеса и ИТ для демократизации доступа к информации

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

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

3. Создание моделей бизнес-процессов, обеспечивающих масштабируемость для приложений low-code/no-code

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

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

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

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