Авторы текста: Максим Потапов
Руководитель проектов, эксперт по внедрению департамента CRM & BPM КОРУС Консалтинг
Татьяна Веселова
Руководитель направления ELMA департамента CRM & BPM КОРУС Консалтинг
Когда компании начинают планировать внедрение информационной системы или автоматизацию нового процесса, перед ними встает важный вопрос – как это реализовать? Выбор подходов зависит от многих факторов: есть ли сформулированные цели, объем неопределенности в бизнес-процессах, принятые в компании стандарты и ряд других факторов. Чтобы внедрение прошло максимально эффективно, и результат проекта удовлетворил заказчика можно, и даже нужно, выбирать разный подход, методологию, свой набор необходимых шагов.
В этой статье мы на основе своего опыта реализации проектов расскажем о вариантах и шагах для достижения цели на примере внедрения решений на платформе ELMA365.
Почему именно ELMA365
ELMA365 – BPM-платформа Enterprise уровня для автоматизации широкого круга бизнес-задач.
Преимущества этой платформы
в ELMA365 уже есть преднастроенные и готовые к использованию модули, такие как Документооборот, Архив, CRM, Service Desk
ELMA365 – Low code / No code система, обладающая широкими возможностями для кастомизации, настройки интеграций и автоматизации бизнес-процессов – от точечных до сквозных, затрагивающих большое количество подразделений компании
платформа используется для автоматизации бизнес-процессов компаниями самого разного уровня, с разной степенью зрелости.
И именно поэтому на примере внедрения именно ELMA365 можно хорошо посмотреть на необходимые шаги и сценарии для внедрения.
Какие шаги рассмотрим
С точки зрения проекта автоматизации можно выделить три основных шага при внедрении ELMA365:
Подготовка к проекту
Пилотный проект (или MVP)
Этапы внедрения и запуска полной функциональности решения. Само внедрение отдельно рассмотрим на примере двух разных методологий – waterfall и agile.
Не все обозначенные шаги обязательны для всех сценариев, но принимать решение об их необходимости нужно всегда.
Подготовка к проекту
В нашей статье «Как подготовиться к внедрению BPM-системы ELMA365» мы рассказывали о том, какие подготовительные работы в компании нужно выполнить до старта внедрения с тем, чтобы сформировать правильные ожидания от него и повысить вероятность успеха. Здесь выделим коротко основные пункты:
кристаллизация целей и ценности проекта
формирование команды специалистов, которые будут отвечать за проект
описание рамок и этапности
актуализация схем бизнес-процессов
наполнение реестра требований, либо описание требований.
Важно, чтобы по результатам этого шага были обозначены цели будущих изменений, сформирована дорожная карта, определены и описаны процессы и требования для будущей автоматизации.
Отдельным этапом подготовки проекта может стать ИТ бизнес-анализ – этап, при котором формируется стратегическое видение будущих изменений в компании, определяются метрики успешности, создается карта проектов. Возможности платформы ELMA365 помогают компании решать задачи разного уровня, и как следствие, предпроектное обследование позволит определить этапность и приоритеты задач.
Компания может провести этап подготовки к проекту самостоятельно, либо привлечь интегратора.
В чем плюсы работы с интегратором
широкий опыт реализации схожих бизнес-процессов, эксперты смогут посмотреть сторонним взглядом на процесс реализации/автоматизации
появляются четкие сроки, цели, задачи. С точки зрения управления это более эффективно, чем внутренняя команда. У команды внутри заказчика есть и другие задачи, а у интегратора это основной приоритет
интегратор имеет большую насмотренность с точки зрения смежных систем и может шире смотреть на архитектуру и предлагать больше решений
Если компания планирует с результатами подготовки к проекту пойти в дальнейший выбор платформы или поставщика решения, то результаты могут быть дополнены чек-листом с требованиями к будущему поставщику и проекту в целом – функциональные и нефункциональные требований, требования к отчетности, требования информационной безопасности, инфраструктуры, требования к поддержке и сопровождению.
Пилотный проект
Далеко не всегда компания сразу готова инвестировать значительные ресурсы в полноценный проект внедрения ELMA365. Причин этого может быть несколько: желание попробовать на небольшом процессе или небольшой группе пользователей, недоверие держателя бюджета к новому продукту, неуверенность в том, что итоговый результат в полной мере совпадает с ожиданиями, выбор между несколькими продуктами или между бизнес-процессами для автоматизации в первую очередь, желание получить результат быстрее и т.д.
В таких ситуациях можно реализовать пилотный проект (MVP). Выделяется небольшая проектная команда и ограниченный бюджет для реализации со сжатыми сроками и умеренными понятными требованиями. В качестве базы можно взять готовый функциональный модуль ELMA365 и по результатам пилота сформировать понимание полного объема необходимых кастомизаций.
Для пилотного проекта обычно выбирается наиболее проработанный контур бизнес-процессов, а при реализации изначально имеют в виду более широкий спектр ограничений и допущений, чем в большом проекте. Здесь ключевой метрикой является скорость. Для возможности эффективного сбора обратной связи количество пользователей по результатам пилота не должно быть очень большим – до 30-50, возможно увеличение количества, например, до 100, если сценарии их работы максимально идентичны.
Пилотный проект – это тоже проект, поэтому должен быть результат – пользователи, работающие в системе. По его итогам важно собрать и обработать обратную связь о работе в системе.
Пример 1. Реализация простого, базового процесса
Основой для реализации простого процесса может служить автоматизация с использованием готового модуля ELMA365.
Например, ИТ-компания, занимающаяся реализацией проектов, автоматизирует процессы продажи проектов. Сам по себе процесс состоит из ряда шагов разной сложности с точки зрения автоматизации – поиска клиента, обработка первичных требований, выделение экспертов для проведения качественного пресейла, формирование детальной оценки проекта, подготовка и согласование договора и пр. Индикативно компания оценивала сроки полного внедрения в 9-12 мес.
Помимо выбора платформы для автоматизации, у компании также стояла и задача выделения процессов для автоматизации на выбранной платформе, вынеся оставшиеся процессы в другие решения.
Было принято решение начать с автоматизации базовых функций продаж – профиля клиента, воронки продаж, расчета вероятности сделки, ведении активностей, отчетности для руководителя. В результате уже через полтора месяца была проведена полноценная загрузка данных из разрозненных экселей, в системе с клиентской базой и со сделками начали работать все менеджеры по продажам, а также сотрудники поддержки продаж.
При этом, в компании на периодической основе, раз в одну-две недели, проходил сбор обратной связи от пользователей и сотрудников поддержки системы. Несложные доработки и настройки выполнялись сразу, из более трудоемких формировался беклог. Параллельно, на уровне архитектурного комитета углубленно рассматривались варианты расширения области применения системы, опираясь на получаемый опыт.
Такой сценарий позволил компании принять уже взвешенное решение относительно будущего системы и грамотно вписать ее в общий ИТ-ландшафт.
Пример 2. Важный, прибыльный для компании процесс, но слабо автоматизированный, который требует большого количества ресурсов.
Страховая компания предлагает своим клиентам услуги автострахования КАСКО. В компании по данному направлению несколько миллионов клиентов-физических лиц. Данные о полисах хранятся в специализированных системах. При этом процесс пролонгации полиса автоматизирован крайне слабо – по сути на периодической основе проводятся ручные выгрузки полисов для пролонгации и дальше организуется взаимодействие с клиентами с предложением им продлить полис.
Компания понимает, что такого рода ручной требует огромного количества ресурсов. И даже выделение дополнительных ресурсов далеко не всегда позволяет решить задачу качественно. В частности, клиенты часто выражают недовольство, что им звонят, хотя они «только вчера продлили свой полис».
Пролонгация полисов КАСКО – не единственная область для автоматизации в компании, но при этом одна из наиболее важных и доходных. Компания принимает решение начать именно с нее.
За 2,5-3 месяца с помощью ELMA365 в компании были автоматизированы процессы выборки договоров на пролонгацию, были настроены каскадные кампании для автоматического уведомления клиентов. Для подразделения телемаркетинга было автоматизировано распределение задач на взаимодействие с клиентом. Как важная часть процесса были реализованы проверки на предмет того, не была ли клиентом выполнена пролонгация самостоятельно ранее.
За счет реализации таких сквозных процессов, компания получила возможность анализировать данные по пролонгации, ставить более четкие KPI и качественно их анализировать. Повысился процент пролонгированных договоров и уровень удовлетворенности клиентов.
Посмотрев на работу в рамках процесса, компания может теперь масштабировать использование платформы и на другие процессы, требующие автоматизации.
Каскадная методология (WATERFALL)
Методология, подразумевающая подход с последовательными этапами, при которой каждый этап начинается после окончания предыдущего. Waterfall активно применяется в проектах с четко определенными требованиями и минимальной вероятностью их изменений в ходе проекта. Одним из характерных признаков подхода является то, что уже на старте обозначены срок и ожидаемые результаты каждого этапа. Для компаний, в которых в силу внутренних регламентов важно иметь фиксированный результат в фиксированный срок – это наиболее подходящая методология.
За счет последовательного выполнения работ всегда можно сослаться на результат предыдущего этапа. Например, на первом этапе внедрения платформы ELMA365 мы формируем техническое задание, а на втором выполняем настройку системы в соответствии с этим заданием. Важно также иметь ввиду и оборотную сторону – если в процессе длительного этапа разработки (кастомизации) бизнес-требования поменялись, то это может привести к тому, что техническое задание станет неактуальным и возникнет необходимость делать запрос на изменение или иным образом переформатировать работы в проекте.
Особенности каскадной (или водопадной) методологии
компания получает результат в виде переданной в промышленную эксплуатацию системы или процесса только после окончания последнего этапа. С одной стороны – это плюс с точки зрения четкости планирования «результат-срок», а с другой – для больших проектов – часто это непозволительно долго. Пользователи хотят «потрогать систему», а не все этапы пока пройдены
низкий потенциал маневра в рамках действующих договоренностей для изменения требований по ходу проекта
высокий уровень формализации и бюрократизации
большой объем проектной документации.
Если компания идет в проект в каскадной методологии, то при планировании проекта важно закладывать ресурс на возможные изменения – по нашему опыту до 20-30% от первоначальных параметров. Это позволит избежать существенных простоев или даже срыва проекта в случае непредвиденных изменений.
Гибкая методология (AGILE)
Гибкая методология – это, скорее, философия проектного управления, которая подразделяется на множество методик. Мы не будем в этой статье углубляться в классификацию этих подходов и сделаем акцент на agile в целом.
Agile идеально подходит в тех ситуациях, когда на входе нет четких сформулированных требований и ограничений. Например, это может быть реализация нового для компании бизнес-процесса, либо сценарий, при котором нет ресурсов на формализацию начальных требований, либо формализация не эффективна.
Особенности гибкой методологии внедрения
есть возможность изменить требования или даже существенно перекроить проект в любой момент
минимум документации и формализма
быстрая демонстрация результатов разработки – этой методологии делается акцент на быстрое достижении ценности для конечных пользователей, результат выдается итерационно
возможности быстрой настройки системы ELMA365 с помощью Low code / No code инструментов позволяют двигаться вперед небольшими спринтами продолжительностью 2-3 недели. Можно начать с базовых возможностей того или иного готового модуля и затем наращивать функциональность от спринта к спринту не оглядываясь на какие-либо ограничения на старте.
Важно иметь ввиду, что гибкие методологии подразумевают тесное общение функциональных и технических команд на всем протяжении проекта. Для достижения результата нужно будет учитывать достаточно строгие правила – следование манифесту, проведение церемоний, наличие в команде обязательных ролей, таких как Scrum-мастер, Product owner и т.д.
Одним из недостатков гибких методологий часто называют «непрозрачный итоговый результат и размытые сроки проекта». Действительно, без соответствующей экспертизы команды именно в этой методологии, без не просто «обозначенной», а реальной готовности компании работать в проекте по правилам agile, сделать качественный проект вряд ли получится. Однако, с учетом обозначенных правил, применение гибких методологий в проектах дает свой бизнес-эффект, что неоднократно подтверждал наш опыт.
Чтобы эффективно подготовиться к использованию гибких методологий, нужно использовать классические подходы для сбора и анализа требований. При планировании проекта также важно иметь ввиду, что без соответствующей подготовки, без формирования концепции и стартового бэклога задач, начать работать в режиме коротких спринтов не получится. Поэтому многие компании, особенно на начальном этапе, используют гибридный подход, включающий в себя классические подходы к сбору и анализу требований.
Выводы
У каждой методологии есть свои правила. Если команда в какой-то момент отстраивается от них, это значит, что работа противоречит методологии, и ее нужно менять. Если заказчик уже имеет опыт и представление о желаемом результате, он сразу придет с запросом работать с конкретным подходом. Когда наша команда приходит на проект внедрения ELMA365, мы на старте обсуждаем, как принято работать в компании, какие методологии используются. Дальше мы смотрим на эту методологию с позиции – можем ли мы применить ее на конкретном проекте, получится ли идти по выбранным правилам с учетом всех вводных.
Чтобы выбрать правильный подход, важно проанализировать ситуацию в своей компании и ответить на вопросы – требуется ли и готовы ли вы делать предпроект? Используете ли вы гибкие подходы? Есть ли у вас задачи, которые закрываются коробочными решениями ELMA365, с которых можно было бы начать?
Оставим несколько ссылок, чтобы вы могли поближе познакомиться с нами и с платформой ELMA365