png png
к ленте

Как клиенту управлять реновацией ИТ-проекта. Интервью с ИТ-директором FESCO

Январь'21

В конце прошлого года прошел вебинар «Как перезагрузить ИТ-продукт. Рассказывают подрядчик и клиент». Спикеры говорили о трех сторонах реновации — процессуальной, визуальной и клиентской. По ссылке можно посмотреть всю трансляцию.

Со стороны клиента участвовал Михаил Семин — директор департамента информационных технологий компании FESCO. FESCO — одна из крупнейших компаний в России, которая занимается контейнерными перевозками и оказывает сквозной мультимодальный сервис. Помимо ЖД плеча, FESCO перевозит грузы своим парком контейнеров и платформ, есть морские плечи и компании автодоставки.

Павел Мелдажис, специалист корпоративных внедрений Ареал, поговорил с Михаилом об управлении реновацией со стороны заказчика на примере личного кабинета MY.FESCO.

Павел Мелдажис: Михаил, у вас большой опыт внедрения ERP-систем и разработки личных кабинетов. В чем, с вашей точки зрения, специфика веб-разработки?

Михаил Семин: Крупные компании специализируются на энтерпрайз решениях. Решениях с заранее предопределенным функционалом — SAP, Oracle, 1С. В этих случаях чаще используется проектный подход. Договор с подрядчиком заключается в режиме Fix Price — за одну итерацию нужно выйти на законченное решение. Далее последовательно идет: поэтапное проектирование, разработка, подготовка к опытной эксплуатации, внедрение.

Когда мы говорим про личный кабинет, некое инновационные решения, подход должен быть другим. Мы идем по тонкому льду, пытаемся проанализировать, найти решения, которых еще не существует. Да, до определенной степени хочется повторить опыт конкурентов, но нужно отличаться.

На проектах с веб-разработкой мы чаще используем технологию Agile. Нащупываем костяк системы, разрабатываем его и готовы постоянно развиваться, находить новые сервисы, решения, анализировать конкурентов. Эта динамическая живая работа требует понимания, готовности, организации проектной команды и зачастую реорганизации внутренней ИТ службы. Истины никто не знает, приходится проводить разведку боем.

П.М.: Как принимается решение о перезапуске, на какие факторы обращаете внимание?

М.С.: Проще всего выстроить мотивацию перезапуска системы, ориентируясь на базовые технические вопросы. Устаревшая платформа, проблемы с производительностью. Аргументация хорошая, но для внутреннеей мотивации ее недостаточно.

Самая востребованная мотивация смены системы — аргументированная позиция со стороны бизнеса и экономическое обоснование (насколько это позволит оптимизировать численность сотрудников). Я не адепт именно этого подхода. Скорее новая система должна развивать бизнес, увеличивать прибыль, снижать внутренние затраты. Вовлечение бизнеса в процесс размышления — залог востребованного проекта.

П.М.: Решение о перезапуске всегда плановое?

М.С.: Да, всегда плановое. Есть годовой бюджет и решение принимается на земле. На него влияет общение с бизнесом, целевое понимание, куда мы двигаем ИТ ландшафт и к каким решениям хотим прийти. В большинстве случаев, входя в новый год, мы знаем, какие системы заменим, какие решения реализуем. Основа — оценка эффективности реновации, согласованная с бизнесом.

П.М.: Раз заговорили о бюджете. Как вы оцениваете емкость проекта — стоимость и сроки? Ведь рынок подрядчиков большой и разношерстный. Кто-то говорит 1 миллион, кто-то 10, кто-то 50, каждый по-своему прав и кому верить? И всегда есть альтернатива делать инхаус командой.

М.С.: Помогает опыт. 25 лет в консалтинге дают мне понимание, как работают консалтинговые компании, как строится ценообразование, на что обратить внимание на пресейле. Когда мы заходим на внедрение системы под ключ, то проводим оценку, переговоры и сразу складывается картинка. Я точно не принимаю решение на основе только коммерческих предложений. Всегда организую очные встречи с тремя, четырьмя подрядчиками, которые себя хорошо показали. Важные факторы отбора — знакомство с руководителем проекта и ключевыми людьми. Решение с кем работать принимается только в режиме живого общения. Вопрос «Делать самим или с помощью подрядчика?», точно не должен решаться в момент выхода на конкурс. Выбор схемы реализации проекта первичен. Модифицировать ее в зависимости от того, что мы нашли на рынке, — не хорошая практика. Она приведет к потере времени — бессмысленный конкурс, дополнительное формирование своей проектной команды.

П.М.: Вы к нам приходите с задачей и заранее понимаете стоимость ее реализации. Иногда она совпадает с нашей оценкой, иногда не совсем и мы ищем решения. Откуда берется бюджет конкретной задачи?

М.С.: Сущность и оценка любой задачи не складываются в момент постановки. Оценка формируется, когда мы с вами исследуем, анализируем, встречаемся с бизнесом и выстраиваем канву того, что должны реализовать. Мы равноправные участники процесса. Подрядчик уходит описывать задачу, мы внутри также проводим анализ и формируем желаемый результат. Вы даете оценку по человеко часам, описание процесса. Мы сверяем наше понимание, накладываем на предложенный проектный подход, а там всегда есть что обсудить. Нужно ли обучение пользователей или увеличение часов на перевод функционала в опытную эксплуатацию. Дальше несложная математика. Фактически те ставки, по которым мы с вам работаем, нужно наложить на внутреннее восприятие реализации дискретной задачи. Содержание работ, план работ, декомпозиция по разработке, запуск в эксплуатацию, умноженная на стоимость человека часа. Поэтому, если мы находимся в одной системе координат, то дальше вопросы по согласованию цены сводятся к легкому тюнингу. А определить, в одной ли мы системе координат, нужно еще на этапе выбора подрядчика.

П.М.: Как задача появляется? Какие есть зоны ответственности внутри команды заказчика? Давайте разберем на примере модуля, который мы реализовали — заключение типового договора через ЭДО и на бумаге. Откуда появилась эта задача, как трансформировалась, с кем согласовывалась?

М.С.: Это очень показательный кейс и интересная задача. Мы в разговоре делали акцент, что личный кабинет — серьезное решение. Оно на самом деле очень функционально. И такие базовые вещи, как заключение договора, мы сделали относительно недавно. Это наша специфика и боль, на которую нанизано много вопросов. Один из них — мы работаем 100% на рынке b2b. Юридическая служба выдвигает серьезные требования на наличие бумажных версий договоров.

Абсолютного правильного ответа на вопрос «А кто должен решать те или иные задачи? И как должна выстраиваться команда?» нет. Чаще вводные задачи идут от бизнеса. Бизнес выделяет своего лидера, ИТ остаётся следовать требованиям и реализовывать их. В силу разных причин схема не всегда работает. Не потому что бизнес знает что-то хуже или лучше, а потому что бизнес не понимает того, что не должен понимать. Например, правильных классических решений, которые позволят получить быстрый результат, по факту постановки требований от бизнеса.

В нашем случае бизнес обозначил проблему. Во-первых, большое количество времени дорогостоящая коммерческая служба тратит на создание типового договора. Во-вторых, неудобство для клиентов. FESCO осуществляет большое количество перевозок по базовым ставкам. Клиент, который подпишет с нами договор без привлечения менеджера, получит те же самые услуги.

Реализация строилась по следующему типу. Выделен бизнес лидер, он точно знает специфику бизнеса, глубоко погружен в ИТ решение. Руководитель проекта — человек со стороны ИТ, глубоко погружен в процессы. Есть вы, как подрядчик. Отдельные функциональные переговоры с юристами, подразделением, которое заключает договоры, проводились без привлечения Ареал, мы выходили с готовыми решениями.

Так сложилось, что в нашей компании лидерские функции лежать на ИТ. Мы позволяем бизнесу выступать в роли постановщика задачи, активного деятеля в проектной команде, выслушиваем мнения, вовлекаем во все фазы процесса (приемка, сдача, согласование решений). Но итоговое решение и общее управление находится за ИТ.

Я не знаю насколько схема хорошая или плохая, но эта амбициозная история требует от ИТ глубокого погружения в специфику бизнеса. Проактивная позиция ИТ — хорошая вводная для достижения успеха.

П.М.: Техническая поддержка в динамичном ресурсе важна не меньше непосредственно разработки. На чьей стороне должна быть первая, вторая линии поддержки личного кабинета?

М.С.: Даже сейчас это открытый вопрос. По классическим бэкофисным системам все очевидно. Например первую, вторую и даже третью линии по 1С мы закрываем сами. Возможно привлекается подрядчик, но только на третью линию. Есть определенное количество систем для сопровождения, пул задач, мы набираем штат, он всегда будет загружен.

В личном кабинете своя специфика. Система существует для клиентов. Клиент, когда у него что-то не получается, общается с продавцом, либо сотрудником кастом сервиса. Он не будет писать задачи на техническую линию поддержки. «Не могу ввести заявку», «не могу получить информацию по взаиморасчетам», «запросил сканы документов по первичной перевозке, а пакет не сформировался». Для клиента это сервис, который не организовала FESCO, а не проблема ИТ.

Поэтому передовой, первой линии как таковой у нас нет. Есть возможность из любой точки личного кабинета задать вопрос или связаться со своим сотрудником. Но клиент уверен, что он общается на уровне бизнес-бизнес.

Первичная обработка бизнес-потребностей на нас, но опять же не ИТ. Личный кабинет работает довольно стабильно и большинство обращений первой линии поддержки бизнесовые (какую выбрать ставку, существуют ли перевозки по такому-то направлению). Все технические вопросы, которые отфильтровываются, поступают на техническую службу поддержки. Они поступают к вам, к подрядчику. Здесь и сейчас нам стоит задуматься, а не взять ли на себя часть ИТ задач технической поддержки. Но года полтора назад мы прошли большую встряску по замене подрядчика, поэтому сейчас наслаждаемся отлаженной работой с вами.

П.М.: Нужно ли бояться смены подрядчика? Как правильно выстроить процесс, если это необходимо?

М.С.: Слово бояться наверное неправильное, но совершенно точно смена подрядчика — не история про шапкозакидательство.

Надо быть готовым к негативной оценке. Кто бы ни пришел, ко всему, от архитектуры до программного кода, будут вопросы и предложения «Давайте перепишем и откатимся назад».

FESCO кейс по замене подрядчика прошла, он был одним из самых сложных. До начала конкурса мы провели серьезную внутреннюю подготовительную работу. Заказали у прошлого подрядчика полное описание системы, документации, переписали бизнес-процессы, которые были реализованы, собрали дополнения и замечания от бизнеса. Подрядчики, которые участвовали в конкурсе, располагали этой информацией.

Сознательно пошли на серьезный шаг — в рамках конкурса обозначили, что на время смены команды, в течение двух месяцев, будет работать и старый и новый подрядчик. Мы заручились поддержкой у предыдущих партнеров. Нам нужна была коммуникация и полная открытость при передаче дел. Да, это дополнительные затраты, но в момент смены подрядчика, стало понятно что кабинет — основная производственная система. Более 90% всех перевозок идет через кабинет. Если его отключить, то компания встанет.

Я считаю, что подготовившись к процессу, мы прошли его безболезненно. Правильно оценили подход к работам, цены, сроки. За полтора месяца закрыли этот вопрос.


Резюме от Ареал. Как качественно и эффективно провести реновацию ИТ-продукта:

  • Потребность в перезагрузке возникает не только из-за технического несоответствия системы. Важны задачи бизнеса и финансовое обоснование.
  • Перед выходом на рынок в поисках подрядчика, определите подход к разработке: отдать на аутсорс, развивать команду внутри компании. Решение на должно приниматься в момент, когда никто не подошел.
  • При выборе подрядчика ориентируйтесь не только на коммерческие предложения, но и на очную встречу, грамотную презентацию команды. Не стоит выбирать партнера, с которым возникли серьезные разногласия по цене уже на этапе конкурса.
  • Проекты веб-разработки, типа личного кабинета, имеют специфику — чаще их реализуют технологией Agile. Первый этап — создание скелета системы. Последующие — его развитие.
  • Выделите бизнес лидера и руководителя проекта. Оба полностью погружены в специфику бизнес-процессов и ИТ. Лидерские функции могут лежать как на стороне бизнеса, так и на стороне ИТ.
  • Все задачи должны быть согласованы и детально разобраны бизнесом и ИТ совместно. Это помогает подрядчику точнее оценить задачу. А клиенту сформировать ожидания по стоимости внутри.
  • Залог успеха — тесная и открытая коммуникация с подрядчиком.