Недавно мой коллега Роман Блинов поделился с читателями опытом по организации интеграционных процессов. И хотя в теории все звучит довольно просто, на практике мы зачастую сталкиваемся с ситуациями, когда заинтересованные стороны интеграции не знают, как ней подступиться и с чего начать. Аналогичные проблемы возникают, когда клиенты только планируют внедрение OBT или хотят доработать уже используемую платформу «под себя». Предлагаю подробнее поговорить о практической части этих процессов и подсветить важные шаги реализации подобных проектов.
Рис. 1 Основные шаги в процессе внедрения цифровизации
Безусловно, конкретные задачи, будь то простой переход от офлайн-заказов к использованию OBT или серьезная интеграция с учетом многолетнего опыта онлайн-бронирования, имеют свои особенности и нюансы, которые будут влиять на используемый подход к их решению. Многое также зависит от возможностей конечного заказчика или от участвующих сторон — планируется ли все делать своими силами, с использованием ресурсов обслуживающего агентства или бюджеты позволяют привлечь профессиональных интеграторов — консалтинговые компании. Общие вопросы и сложности, связанные с внедрением цифровизации командировок на стороне клиента, были уже освещены на BBT Russia. Мы же рассмотрим ситуацию, когда решение о движении в онлайн уже принято и пришла череда проектных вопросов, а также постараемся обратить внимание на ключевые процессы, которые должны присутствовать в реализации проекта, независимо от его масштабов.
1. Анализ текущего процесса оформления командировок и принятие решение о следующем шаге. Очень важно, на каком уровне цифровизации с точки зрения оформления командировочных услуг находится клиент перед началом активной стадии работы над проектом. Нередки ситуации, когда компания долгие годы бронировала услуги офлайн, и вот было принято решение о переходе на использование OBT. Многие клиенты хотят не просто внедрить онлайн, но и сразу доработать платформу под свои бизнес-процессы (хотя зачастую это не нужно и имеющийся функционал позволяет реализовать привычный бизнес-процесс) или даже осуществить интеграцию с внутренней учетной системой.
На наш взгляд, более корректным будет внедрение на первом этапе платформы as is и откатка работы с ее помощью в рамках пилотного проекта на фокус-группе. Это позволит выявить реальные, а не гипотетические ограничения платформы по отношению к имеющемуся бизнес-процессу, собрать обратную связь от своих же коллег, подготовиться к масштабированию системы на всю компанию и получить четкое представление о требуемых доработках. Такого же подхода стоит придерживаться и при интеграции уже используемой платформы с внутренней ИС: откатка процесса интеграции с учетом уже имеющегося функционала — анализ результатов и проблем — расширение возможностей в том числе с учетом доработок.
2. Определение целей проекта цифровизации для клиента. Независимо от реализуемого проекта, необходимо четко понимать преследуемые им цели, что поможет лучше определиться с постановкой задач, выделением ресурсов и в конечном итоге позволит довести проект до конца. Например, если конечной целью является оптимизации процесса заказа услуг и удобство пользователя, она оправдывает увеличение бюджета на те или иные доработки платформы или ее кастомизацию. Если же цель — только оптимизировать затраты на командировки, от некоторых пожеланий можно и отказаться.
3. Отрисовка блок-схемы планируемого бизнес-процесса. То, что может звучать легко и понятно в голове руководителя проекта или тревел-менеджера, может быть не так очевидно остальным, порой ключевым участникам процесса. Не будет лишним изобразить идеальный процесс в виде простой пошаговой блок-схемы. А в случае с планируемой серьезной интеграцией этот шаг вообще является обязательным. Такой документ можно использовать при будущем обучении сотрудников или для обсуждения с агентством, разработчиком, с целью определения функциональных требований к платформе и для разработки технического задания на доработки или интеграцию.
4. Организация встречи с ключевыми участниками проекта, определение проектной команды и распределение ролей. Итак, вы понимаете на какой стадии цифровизации находитесь, какие преследуете цели, вы даже нарисовали блок-схему своего идеального бизнес-процесса! Самое время обсудить проект с теми, кто будут принимать непосредственное участие в его реализации. Обычно это команда клиента, обслуживающее агентство и разработчик платформы. Сюда также можно добавить заинтересованных лиц со стороны клиента (IT, бухгалтерия, сотрудники отдела оформления командировок, юристы и так далее). Возможно, в проекте будет участвовать интегратор или консалтинговое агентство, тогда роль организации проектного управления оно берет на себя. В процессе обсуждения необходимо собрать замечания и предложения участников, определиться с ролями, зонами ответственности, основными этапами и регламентом жизненного цикла проекта.
5. Подготовка дорожной карты проекта. Проектное решение. Определившись с участниками и основными этапами проекта, вы должны составить его дорожную карту. В нее следует включить не только очевидные шаги (подключение OBT на стороне агентства или доработки платформы разработчиком), но и все остальные этапы, без которых проект не сможет прийти к своему логическому завершению — подписание договоров, защита проекта перед специалистами по информационной безопасности, тестирование в тестовой среде, отладка, обучение сотрудников клиента и при необходимости агентства и так далее. Наличие продуманной дорожной карты даст возможность определить сроки проекта, зоны ответственности и позволит осуществлять контроль за его претворением в жизнь. Для больших проектов, особенно предполагающих существенные объемы доработок, имеет смысл также разработать и проектное решение — описание в текстовой и/или графической форме объекта проектирования (например, кастомизированной платформы OBT), необходимое для создания этого объекта и удовлетворяющее заданным требованиям. Проектное решение в дальнейшем в разы облегчит формирование технического задания на разработку.
6. От бизнес-требований к функциональным. От ФТ к ТЗ. Бизнес-требования представляют собой высокоуровневые цели заказчика, определяют образ и границы проекта. Они задают общий вектор, но не дают представления о конкретных задачах, которые стоят перед участниками. Для этого необходимо сформировать функциональные требования. Они определяют функциональность платформы или процесса, который необходимо построить, чтобы выполнить задачи в рамках бизнес-требований. Иногда для реализации проекта достаточно функциональных требований (допустим, простое внедрение OBT в компании, где командировки ранее оформлялись по почте с помощью сотрудника агентства). Но иногда, особенно, когда речь идет о существенных доработках функционала платформы, не обойтись без технического задания. Тогда как функциональные требования представляют собой описание того, как должны осуществляться те или иные процессы, ТЗ формально указывает на то, что необходимо сделать разработчику для того, чтобы требования были реализованы. Учитывая специфику подготовки ТЗ, обычно эта задача возлагается на плечи аналитика со стороны агентства. В некоторых случаях возможно обращение к разработчику с целью формирования ТЗ в рамках дополнительной услуги.
Но необходимо понимать, что разработчику скорее всего все равно понадобится участие заказчика, так как именно он лучше всех понимает свои собственные функциональные требования.
7. Реализация. Статусы проекта. При наличии отрисованного бизнес-процесса, дорожной карты, собранной проектной команды и грамотном управлении реализация проекта не станет столь сложной задачей, какой она может показаться в самом начале. Стоит придерживаться договоренностей, достигнутых всеми сторонами на этапе планирования, с уважением относиться к партнерам и с ответственностью к своим задачам. С точки зрения разработки и доработок платформы мы рекомендуем придерживаться «цикличной» модели, совмещающей в себе итеративный подход (англ. iteration — «повторение») и пошаговый метод — то есть выполнение работ параллельно с непрерывным анализом полученных результатов и корректировкой последующих этапов работы. (рис. 2) Что касается контроля сроков и исполнения проекта, то необходимо проводить периодические «статусы» — общие собрания проектной команды с кратким отчетом по текущему состоянию.
Рис. 2 «Цикличная» модель (Incremental build model), характерная для Agile-подхода к разработке
8. Закрытие и дальнейшее развитие. Готовый к завершению проект передается в «опытно-промышленную эксплуатацию», во время которой пилотная группа заказчика приступает к работе с продуктом. Во время выполнения рабочих задач в реальных условиях анализируется разработанный функционал или внедренный продукт, собирается обратная связь и замечания, осуществляется исправление ошибок критичного, высокого и среднего уровня. Логичное завершение — закрытие проекта, процесс официального завершения его основных итераций. При закрытии рассматривается итог промежуточных фаз, подтверждается, что работы по проекту завершены и он достиг своих целей. Подготавливается необходимая документация и отчетность, при необходимости проводится защита результатов перед внутренним заказчиком.
Окончание основных работ над проектом не говорит о том, что его развитие на этом заканчивается, путем инициации новых проектов, доработок и обновлений происходит поддержка и его дальнейшее усовершенствование.
Несомненно, как мы уже отмечали, указанные шаги не будут 100% универсальными и исчерпывающими для реализации любого проекта цифровизации оформления командировок или интеграции, но, придерживаясь этих основ и дополняя их своими знаниями и опытом, вы обязательно добьетесь нужного результата и принесете пользу своим коллегам и клиентам.
Михаил Радченко,
руководитель отдела управления проектами Corteos Platform
