Как получить быстрый результат в проекте внедрения
25 февраля 2020
Каждый проект внедрения уникален и зависит от задачи, которая стоит перед ИТ-директором. В некоторых из них необходимо внедрить решение целиком. Но часто важнее получить первые результаты, чтобы как можно быстрее дать сотрудникам компании новую функциональность. В таких случаях на помощь приходит так называемый продуктовый подход или, как мы ее называем, технология «быстрого результата». В этой статье я расскажу, в чем особенности этой модели и в каких случаях ее лучше применять.
Отходим от «классики»
«Классический» проектный подход не идеален. Часто формирование перечня функциональных требований к будущей системе приводит к эффекту «снежного кома». Клиент и поставщик действуют по принципу «Что еще мы могли забыть?» и добавляют к базовому функционалу все новые и новые слои. Оценить их адекватность бывает сложно.
Результатом становятся проекты, где 30%, 50%, а то и 70% реализованных возможностей оказываются никому не нужны. В итоге – выброшенные на ветер деньги, бесцельно израсходованные человеческие ресурсы, потерянное время. А главное — отсутствие удовлетворенности у заказчика. Многие требования оказываются вообще не учтенными: по нашей практике 20-30% «всплывают» уже в процессе запуска системы.
Чтобы этого избежать, и применяется продуктовый подход. Основные аргументы в его пользу – более узкие и четкие формулировки функциональных требований, быстрый запуск минимально жизнеспособных решений, экономия бюджета. Но и этот подход не идеален. Особенно если между продуктовой моделью и agile ставится знак равенства, что далеко не всегда правильно.
Гибкая разработка вполне уместна при развертывании сервисных приложений, но приводит к существенным сложностям при внедрении, например, ERP. Трудно себе представить ситуацию, когда коммерческий отдел уже начинает работать в новой системе, а все остальные подразделения продолжают пользоваться прежней.
При этом элементы продуктового подхода вполне применимы в рамках классической каскадной модели, поскольку позволяют увязать функциональные требования с реальными бизнес-целями заказчика.
Определяем цели
Ключевой элемент продуктового подхода — определение четко сформулированных и «оцифрованных» SMART-целей всех заинтересованных сторон в компании-заказчике. Вот только выявить их не так просто.
В разговоре с клиентом на этапе пресейла можно услышать: «Мы хотим автоматизировать учет, что тут непонятного?». Но «автоматизация» сама по себе не может быть в полном смысле целью. Это только способ достижения результатов. А продукт в рыночном понимании – это, прежде всего, концентрированное выражение ценности, которую можно получить при его использовании.
Отсутствие четких целей порождает множество проблем. Исполнитель приходит к заказчику, в полном соответствии с договором внедряет информационную систему, получает деньги и «закрывает тему». Но стало ли лучше предприятию после того, как решение развернуто? Весьма вероятно, что никаких существенных изменений не произошло. Просто одну систему заменили другой. Так что придется еще нанимать специальных людей, которые будут администрировать ее и объяснять всем остальным, как с ней работать.
Но благодаря «продуктовой» логике в каждом внедряемом блоке ИТ-инструментов мы можем нащупать безусловные ценности внутренних заказчиков, от гендиректора и вплоть до рядового менеджера.
Главное — обсуждать не абстрактную «автоматизацию». Нужно выделять конкретные экономические эффекты, которые прямо влияют на объем заработанных компанией денег. Благодаря этому и появляется возможность исключить лишние расходы, повысить темпы внедрения, минимизировать вероятность «нулевого результата» и продемонстрировать реальную отдачу от инвестиций в ИТ.
Как это работает
Один из примеров реализации продуктового подхода в нашей практике — внедрение инструментов управления денежными средствами по технологии «быстрого результата».
Мы постарались максимально четко определить, какие ценности вообще может принести автоматизация управленческого учета разным категориям внутренних заказчиков. Выделили три ключевые группы интересантов: генеральный директор, финансовый директор и финансовый менеджер. Анализ их запросов позволил понять, что именно представители каждой из этих групп понимают под «эффективностью».
● Генеральный директор: повышение сходимости с прогнозом, быстрое получение информации, стандартизация планирования, ускорение согласования договоров и платежей;
● Финансовый директор: высвобождение времени для анализа финансового состояния за счет автоматизации сбора «факта», повышение мотивации сотрудников, трансформация отдела из «учетного» в аналитический и … стремление к тому, чтобы вся команда гордилась тем, что делает финансовый директор (очень важное эмоционально-психологическое описание одной из ценностей!);
● Финансовый менеджер: анализ, а не «перебивание» данных из разных файлов, возможность активно участвовать в развитии системы управленческого учета компании, а также получение навыков работы с системой, которые высоко ценится на рынке труда.
Затем описываем те задачи, которые возьмет на себя внедряемая система. Например, финансовый менеджер, устраиваясь на работу, хочет заниматься интеллектуальной деятельностью, а не выступать «генератором отчетов». Отлично! Значит, решение должно, прежде всего, автоматизировать именно эту «генерацию». Менеджер наконец-то займется решением содержательных аналитических задач, то есть будут довольны и сотрудник, и его руководство.
На следующем шаге выделяем несколько инструментов, которые необходимо предоставить заказчику исходя из его реальных потребностей. В нашем примере это:
● автоматизированное казначейство;
● управление бюджетом движения денежных средств и лимитированием расходов;
● управленческая отчетность;
● план-фактный анализ и платёжный календарь;
● мобильное приложение для визирования документов.
Вовлекаем людей
В проектирование каждого из модулей новой системы нужно вовлекать сотрудников заказчика. Это очень важно: так они становятся полноценными соавторами системы. Например, казначеям были важны такие возможности, как работа в едином окне со всеми заявками, отображение кассовых разрывов, изменение заявок и их отправка в реестры платежей из списка с помощью специальных команд.
При разработке модуля учитывались еще легкость настройки «маршрутов» согласования и автоматическое информирование о новых документах для согласования на email или в Telegram. Шаблоны типовых отчетов для анализа «план-факт» и для данных в подсистеме бюджетирования тоже были сформированы с участием будущих пользователей системы.
При таком подходе сотрудники компании фактически сами осуществляют настройку модулей. А это позволяет им близко познакомиться с продуктами и вовремя внести в них необходимые коррективы. Наконец, снижается стоимость внедрения (в два раза и более), сокращаются сроки запуска в эксплуатацию.
Перейти к использованию такой системы можно уже через месяц, а традиционный подход растянул бы внедрение на пять этапов по 2 месяца каждый. Кроме того, проектный подход предполагает переход к обучению пользователей на последнем этапе внедрения (то есть на 6-8 месяце после старта). А в продуктовой логике пользователи уже через месяц умеют и эксплуатировать новую систему, и самостоятельно ее настраивать.
Единственное ограничение: если проектный подход обычно требует 10% времени сотрудников, то в продуктовой модели внедрения – около 50%. Но достигаемые преимущества окупают эти трудности.
Границы применимости
Технология быстрого результата не универсальна. Она хорошо подходит для проектов:
● которые делаются по гибким методологиям;
● в которых может быть выделен минимальный продукт, он же MVP (например, сайт или мобильное приложение).
Такой подход совсем не применим, если мы внедряем систему, в которой все элементы жизненно важны для функционирования предприятия: например, заменить на заводе ERP по такой модели нельзя. В остальных случаях это вопрос отдельного анализа.
Например, если у заказчика уже отлажена система оперативного учета, то он готов для применения продуктового подхода. Можно отдельно запустить казначейство, потом бюджетирование и управленческую отчетность. Более того, каждый из этих модулей можно внедрять отдельными сегментами (на примере казначейства — сначала простая обработка заявок, потом интеграция платежного календаря, управление маршрутами согласования).
Итерации позволяют выявлять дополнительные требования своевременно на ранних стадиях, а не когда проект уже близится к завершению. И заказчик получает действительно полезный продукт, наполненный ценностным содержанием.
Во многих случаях продуктовый подход сокращает время внедрения, экономит ресурсы ИТ-бюджета, обеспечивает соответствие возможностей системы реальным задачам пользователей. Но главное для ИТ-директора – существенно снижается риск того, что его внутренний заказчик за свои деньги получит нечто, не соответствующее его целям. Ведь главная задача любого ИТ-проекта — избавить сотрудников от головной боли и предоставить работоспособные инструменты, делающие бизнес эффективным.
