Елена Истомина, Directum: Как no-code меняет стоимость проекта
В контексте бескодовой и малокодовой разработки часты рассуждения об их благотворном влиянии на стоимость проекта. Сама идея «разработки без разработки» была в том, чтобы упростить и ускорить внедрение изменений в информационную систему, а также снизить требования к квалификации исполнителей. Если программировать нужно меньше или не требуется вовсе, значит, не нужно нанимать много дорогостоящих профессионалов, и их можно заменить на кого-нибудь «попроще», и, следовательно, сэкономить. На деле все оказалось гораздо интереснее.
Содержание |
 | Елена Истомина Директор по консалтингу и внедрению Directum |
Такие разные проекты внедрения
Когда мы говорим о проектах внедрения информационных систем вообще, мы сильно упрощаем понятия. Система системе, и проект проекту — рознь. Остановимся на различиях между проектами подробнее. Но договоримся на берегу, что здесь и далее в статье мы будем рассуждать о проектах в контексте нашего опыта внедрения продуктов и решений Directum в крупных организациях со сложными процессами.
Компания может впервые внедрять ИТ-продукт, переводя процессы с бумаги или из множества разрозненных сервисов в единую систему автоматизации. Или это может быть проект перехода с одного продукта на другой — таких кейсов стало больше на волне импортозамещения. Кроме того, компания может со временем автоматизировать с помощью уже работающей системы какие-то новые бизнес-процессы или подключить другие подразделения. Для Directum это частый кейс.
Задачи проекта напрямую влияют на объемы, состав работ и инструменты, которые будут использоваться при внедрении.
Первичное внедрение
Оптимальный вариант при первичном внедрении — критичный взгляд на существующие процессы и поиск улучшений — словом, оптимизация процессов, и только потом их автоматизация. Так что инвестировать в анализ и проектирование процессов все равно придется.
Если на старте нет четкого понимания ожиданий от системы (все на уровне фантазий пользователей), самый экономичный вариант — использовать «коробочное» решение. Сложности перестройки рабочих привычек и традиций под систему будут выше, чем недостаток каких-то функций. В этом варианте заказчику может и не понадобится масштабная заказная разработка, и многое закроется готовыми ИТ-решениями и бескодовой адаптацией. Кстати, концепция экосистемы готовых решений Directum с возможностью no/low-code-доработки тут хорошо подойдет.
С помощью no-code можно также закрывать локальные потребности подразделений. Например, автоматизировать работу с заявками в ИТ-службу, на ремонт или другие сервисы. В таких случаях нет особых требований к масштабированию или к UI, и бывает достаточно базовых возможностей системы.
На длительность и стоимость проекта в большей степени могут влиять не применяемые технологии адаптации системы, а организационная сторона вопроса (например, долгое согласование проектных документов). Мы сами давно убедились, что для первичного внедрения оптимально применять гибкий итерационный подход. Когда работы ведутся небольшими итерациями, заказчик получает результат частями после каждой и может уточнять требования, а исполнителю быстрее на эти изменения реагировать.
| Получается, что дело не всегда в коде. Для того чтобы быстро и с меньшими затратами внедрить систему, важнее правильно управлять требованиями и грамотно расставлять приоритеты. |
Еще один большой пласт работ на таких проектах — интеграция новой системы в ИТ-окружение. У вендоров могут быть готовые коннекторы к популярным на рынке программным продуктам, но и их готовность не гарантирует, что не понадобится дополнительной доработки и отладки средств интеграции — любые системы, работающие у реальных заказчиков, обрастают локальными изменениями. И если стандартный коннектор можно настроить с помощью no-code, то для кастомной интеграции без кода не обойтись. Работы по настройке и доработке интеграций часто занимают до 30% от общего времени проекта.
Переход с другой системы
В этом случае заказчик обычно хочет с достоверной точностью повторить в новой системе привычные методы работы, либо немного их улучшить. В зависимости от степени различий между тем, как было/хочется и тем, что может внедряемый ИТ-продукт, будут увеличиваться или сокращаться расходы на разработку. По большей части клиентам всегда приходится выбирать между тем, чтобы подстроить свои процессы под систему, и тем, чтобы переделать систему под устоявшиеся процессы. Если эти процессы были ранее автоматизированы, то поменять их еще сложнее.
Важно не пытаться максимально повторить функционал старой системы на новой. С этим никакой no-code точно не справится! И даже low-code не особо поможет сократить трудоемокость. Чтобы сэкономить, надо отталкиваться от возможностей новой системы и критичных бизнес-требований.
| Не разрабатывать с нуля всю желаемую функциональность помогают готовые решения и low-code. Заказчик получает «заготовку» для своих бизнес-процессов, которая адаптируется под его требования с помощью разработки с низким содержанием кода. |
Изменение автоматизированных процессов
Цифровизация не разовое мероприятие. Реальность меняется вместе с людьми и подходами, и адаптировать автоматизированные процессы под новые требования приходится абсолютному большинству компаний. Для этих целей отлично подходят возможности no-code.
Добавить новое поле в карточку документа или скорректировать последовательность этапов процесса можно совсем без кода, если в системе есть соответствующие технологии.
Но и в этом случае не надо забывать об организационной стороне вопроса. Бывает, что маленькое изменение в карточке документа, например наименование какого-то поля, может согласовываться в компании в течение недели, а то и дольше. Внести это изменение легко и дешево, особенно без кода, но сколько времени потребуется на принятие решения? Чтобы компания могла долго и счастливо пользоваться благами бескодовой разработки и собирать новые процессы из «кубиков» под растущие потребности подразделений, важно при первом внедрении грамотно спроектировать систему, создав нужный набор «кубиков».
Причем, помимо набора «кубиков» из коробки, должна быть возможность самостоятельно создавать нужные «кубики», как это реализовано в системе Directum RX.
Разработчик vs аналитик
Программирование требует времени и серьезных компетенций. Хорошая квалификация специалистов требует высокой оплаты. Получается, если заменить всех дорогих программистов на специалистов «попроще» (с точки зрения скиллов разработчика), то дорабатывать, менять, адаптировать систему можно быстрее и дешевле. Звучит логично, но по факту не очень актуально.
Дело в том, что любое моделирование бизнес-процессов требует погружения в их специфику, изучения предметной области, понимания целей процессов, их логики, возможностей настройки конкретной системы — всего того, что нужно конкретному заказчику проекта автоматизации. Перед тем, как разработать что-нибудь очень нужное, надо это нужное спроектировать. И если вам для разработки не понадобятся компетенции программиста, без грамотного аналитика бизнес-процессов вы точно не обойдетесь.
В последнее время сильно вырос спрос на хороших бизнес-аналитиков, умеющих выстраивать и настраивать бизнес-процессы, выросли и цены на услуги таких специалистов. И зачастую стоимость аналитика не ниже услуг программистов.
Где no-code поможет сэкономить
Так на что же влияет no-code в контексте стоимости проекта внедрения? Неужели нет никакой разницы между проектом с программированием и без него (хотя бы частично)? Разница есть, но все зависит от проекта.
Если речь о первичном внедрении, затраты на проект будут зависеть от количества и сложности доработок. Дешевле всего использовать «коробочное» решение с элементами настройки. Не меньше влиять на стоимость будут организация проекта, его методология, управление требованиями и приоритизация работ.
Но если мы говорим о развитии системы, локальной адаптации в подразделениях, no-code и low-code имеют серьезное значение и могут заметно удешевлять внедрение изменений. Разработка без кода или с низким его содержанием дает возможность быть гибче — быстрее и проще менять процессы. То же актуально и для небольших организаций (но это уже тема для отдельной статьи).
