Low-code BPMS — это класс продуктов для разработки корпоративных приложений, которые сильно сокращают сроки разработки и обеспечивают вовлечение большего количества сотрудников. Это возможно за счет того, что решение создается не программированием, а при помощи моделирования из готовых для использования блоков, как в конструкторе. Если же на каком-то этапе нам не хватает того или иного блока — мы можем его самостоятельно разработать, а затем переиспользовать. По сути, Low-code BPMS — это инструмент с безграничными возможностями, который не имеет отраслевой привязки подобно классической разработке.
Внедрение Low-code BPMS похоже на внедрение любого ИТ-продукта со всеми типовыми сложностями. Необходимо:
учесть интересы всех заинтересованных сторон;
реализовать классический проект в виджетах, с соблюдением сроков, с должным качеством и необходимой функциональностью;
заложить фундамент для будущих проектов, чтобы защитить вложенные инвестиции. Об этом часто забывают, но это важно (когда мы разрабатываем на платформе, неразумно предполагать, что это будет единственное реализованное на ней решение).
Что здесь главное:
Определить цели, ради которых этот проект реализуется, чтобы легче было анализировать получившийся результат.
Определить метрики, по которым этот результат будет оцениваться.
Подготовить команду и всю компанию к внедрению нового решения. Это очень важно с точки зрения борьбы с потенциальным саботажем.
Шаг № 1. Погрузиться в контекст
Первоочередная задача – погрузиться в тему low-code, чтобы лучше и правильнее составить задачи на проект и понимать философию продуктов, которые составляют этот рынок.
Сейчас публикуется масса материалов о том, как применить low-code для различных отраслей и задач. Изучение этих материалов, поданных в простой (иногда даже развлекательной) форме, поможет определиться с контуром будущего проекта и понять, как лучше использовать продукт, а как лучше не использовать. Мы в нашей компании регулярно практикуем вебинары — на нашем сайте представлен огромный архив накопленных знаний, который может быть полезен компаниям самых различных отраслей.
Шаг № 2. Реализовать пилотный проект
Если у вас еще нет опыта внедрения подобных решений — важно не пытаться автоматизировать всё и сразу. Нужно поделить ваши запросы на этапы и для начала запустить пилот — небольшой и быстро реализуемый, но при этом обязательно полезный. Делать небольшую бесполезную вещь нет смысла, потому что будет сложно оценить выгоды от этого решения. Если же пилот слишком большой — вы можете не оценить свои силы, утонуть во внутренней бюрократии, неправильно сформулировать задачи.
Шаг № 3. Выбрать инструмент для реализации
Нужно выбрать систему Low-code BPMS, которая и станет фундаментом для всех будущих изменений. Нет смысла реализовывать каждый проект на отдельной платформе, потому что в ходе проекта накапливаются знания, опыт. Лучше сделать ставку на один конкретный продукт, чтобы легче, проще и дешевле реализовывать следующее решение.
Конечно, первое, о чем стоит подумать, – функции и качества продукта, чтобы он отвечал вашим требованиям. Не менее важно обратить внимание еще и на вендора:
оценить инфраструктуру и уровень поддержки, которую он предлагает;
оценить риски и историю продукта — есть ли у разработчика награды или опыт реализованных продуктов масштаба вашей компании (особенно важно для крупных организаций, потому что небольшие продукты могут просто не вытянуть нужную вам производительность);
оценить, давно ли продукт на рынке и как он будет развиваться.
Иногда появляется соблазн сделать выбор в пользу продуктов, которые появились совсем недавно, имеют красивый и интересный интерфейс, более мобильны и динамичны, нежели продукты бывалых игроков рынка. Но часто за такими компаниями скрываются два-три разработчика, полное отсутствие инфраструктуры, и непонятно, будут ли эти разработчики существовать через год и станут ли они вас поддерживать. Поэтому все-таки меньше рисков с компаниями крупными и опытными.
Шаг № 4. Обучить команду
После выбора правильного инструмента и его объема на пилотный проект важно провести обучение собственной команды — сформировать экспертизу, которая позволит понимать, как работает продукт, какова его философия и как правильно формировать требования. Это необходимо потому, что неверные требования могут привести к лишним работам. Если вашей внутренней экспертизы будет достаточно для формирования требований (даже если вы реализуете проект не собственными силами) — вы придете к гораздо более качественному результату и намного быстрее. И наоборот: не зная, чего попросить, вы будете просить вещей, логичных и базовых с точки зрения вашего предыдущего опыта, но абсурдных с точки зрения философии нового продукта. И реализация этих требований будет выливаться в лишние, сложные и дорогие работы, хотя по итогу для бизнес-задач разницы не будет никакой.
Шаг № 5. Сформировать культуру непрерывного обучения
Ваши сотрудники действительно будут учиться на проекте. Важно сформировать культуру непрерывного обучения, потому что продукты класса Low-code BPMS — это не монолит навечно. Мы делаем гибкое, изменяемое решение, которое будет непременно развиваться, и это одна из его сильнейших сторон. Без практики непрерывного обучения вы получите просто тот самый «монолит» и потеряете возможность для его развития. Очень важно не покупать этот продукт «под ключ», полностью поручив дела внешнему подрядчику. Конечно, львиную долю работ вы можете отдать на подряд компаниям-интеграторам, но всегда важно, чтобы у вас была собственная экспертиза внутри компании.
Шаг № 6. Провести предварительную оценку проекта
Это важно, чтобы понять узкие места и оценить риски. Особое внимание следует уделить интеграциям, то есть предоставить компании-интегратору информацию обо всех системах, которые необходимо интегрировать, и их возможностях. В Low-code-BPMS-системах с интеграциями все замечательно, но ваша legacy-система может не соответствовать некоторым желаемым уровням, и крайне важно уделить внимание миграции данных, их количеству, типам и т. п. Все это поможет компании, которая будет реализовывать проект, лучше оценить объем работ, риски, сроки и т. п.
Не менее важно обратить внимание на объем кастомизации. В идеале кастомизации должно быть как можно меньше, потому что это не сильная сторона Low-code-BPMS-систем и переделка абсолютно ничего не значащих визуальных компонент может занять больше времени, чем реализация полезных функций. Это тоже необходимо проработать вместе с вендором либо системным интегратором, который реализуют решение, чтобы лучше понимать продукт и его возможности — какие доработки просты и недороги, а чем лучше бы пренебречь.
Шаг № 7. Подготовить внутренний PR нового решения
Внедрение любого ИТ-продукта – всегда страх изменений для сотрудников. Для тех, кто не подготовлен, эти изменения к худшему, потому что люди не знают, чего ожидать, а когда они слышат такие слова, как «искусственный интеллект», «роботы», начинают бояться за свое место, за свои привычные механизмы работы. Важно объяснить каждому, что внедрение системы сделает жизнь всех сотрудников лучше: работать станет удобнее, ерундой придется заниматься меньше и увольнять никого не собираются (если это действительно так, конечно). Ведь, большинство проектов нацелены на улучшение качества жизни сотрудников. И это тоже важно донести. В противном случае вы столкнетесь с саботажем на самых разных уровнях.
Некоторые наши заказчики даже снимали фильмы о внедряемых системах, чтобы показать, как удобно сотрудникам будет работать или насколько легче поставщикам будет размещать заявки.
Важный момент: в этот внутренний пиар-проект нужно вовлечь самых различных сотрудников.
Шаг № 8. Сформировать процессный офис
Этот пункт опционален, но крайне рекомендуется. Удобнее всего сформировать процессный офис — организацию, которая будет накапливать не только продуктовую экспертизу, но еще и управлять изменениями, отслеживать проект в целом и служить осью для всех будущих проектов внедрения в рамках Low-code BPMS.
Шаг № 9. Прописать процедуру приемки и тестирования
Заказчики часто забывают об этом пункте. По каким критериям считать, что проект выполнен? По каким критериям определять, что пора запускаться, а не постоянно что-то переделывать и стремиться к совершенству?
Очень важно запустить решение вовремя. Внедрение Low-code=решения — это участие большого количества бизнес-пользователей и citizen-девелоперов, включенных в проект. Все они – творцы, и все могут иметь свое видение, что и как лучше сделать. Часто проекты расползаются, задерживаются по срокам именно из-за внутренних споров, пора или не пора запускать продукт и в каком виде. Важно договориться об этом на старте, потому что часто финальное решение благодаря различным пожеланиям и изменениям отличается от того, что вы запланировали в начале.
Шаг № 10. Сформировать концепцию развития проекта
Что вы будете делать после того, как закончите пилот или другой этап? Важно заложить фундамент и использовать платформу для широкого круга задач — это сильная сторона Low-code BPMS.
Шаг № 11. Освоить механизм непрерывных улучшений
Лучше всего делать это в рамках процессного офиса, но не менее важно собирать обратную связь от пользователей — что им удобно делать, что нет, что хотелось бы изменить. Крайне рекомендуется отслеживать метрики процессов и проектов, чтобы видеть, как работает решение, и настроить механизм по поиску узких мест в процессе, чтобы понимать, где решение можно улучшить.
Внедрение Low-code BPMS похоже на внедрение любого другого ИТ-продукта со всеми его типичными сложностями, но имеет свою специфику: Low-code BPMS – это все-таки платформа, на которой создаются гибкие адаптивные решения, которые будут и должны развиваться. Существенные изменения в общий ход проекта внедрения вносит и то, что разрабатывают решение не только программисты, но и широкий круг сотрудников компании.
Журнал IT Expert
Источник новости: www.it-world.ru
