Поддержка 1С:УХ для аэропортового хэндлера. Интервью

Станислав Алексенко, руководитель проектов UTG Aviation services, в интервью Владимиру Малаху, управляющему партнеру ФТО, рассказал о сложностях и особенностях поддержки 1С в хэндлинговой компании, а также поделился опытом, что сделать, чтобы не оказаться в заложниках у подрядчика.

Владимир Малах
— Добрый день, Станислав. Расскажи, что такое хэндлинговая компания, чем она занимается?

Станислав Алексенко
— Добрый день, Владимир. Я работаю в компании UTG AVIATION SERVICES. UTG — это хэндлинговая компания, оператор наземного обслуживания полного цикла. Наша компания занимается организацией аэропортового и наземного обслуживания пассажиров. Например, если вы прилетите во Внуково обычным рейсом или бизнес-джетом в Домодедово, то обратите внимание: самолеты буксируются тягачами с логотипом UTG, заправляются заправщиками UTG, транспортировка пассажиров к самолету и от самолета производится автобусами UTG. Также на стойке регистрации вас обслужат сотрудники нашей компании. Такая деятельность называется хэндлингом.

Владимир Малах
— Насколько знаю, UTG –  одна из самых крупных компаний в России, которая занимается хэндлингом.

Станислав Алексенко
— Да. У нас более 3000 сотрудников. Обычно хэндлер аффилирован с аэропортом, но мы являемся независимой компанией.

Владимир Малах
— Давай поговорим, почему крупные компании отдают свои бизнес-системы, в которых ведется весь регламентированный, управленческий учет, на поддержку сторонней организации? Почему вы перешли на 100% аутсорсинг сопровождения 1С?

Станислав Алексенко
— Начну с предыстории. У нас много разных систем на платформе 1С: финансовые, кадровые, для управления транспортом и прочие. Все эти системы небольшие, локальные, компактные и вполне нормально сопровождались обычным способом — то есть те, кто их внедрял, тот и сопровождал. Работы было немного, мало пользователей, несложные процессы и немного доработок. Подрядчики справлялись.

Остро встал вопрос о сопровождении «1С:Управление холдингом», это самая крупная наша система на платформе 1С, в ней больше всего процессов, больше всего сотрудников в ней работают.

Мы хотели пойти по старому способу: отдать систему на поддержку тем, кто внедрял, но у нас не получилось успешное сотрудничество, потому что подрядчик продолжал применять проектный подход к поддержке 1С. Что это значит? Это значит, что любой тикет, который мы отправляли проходил тот же путь, что и заявка на изменение функциональности (а всё-таки сопровождение системы и её доработка – разные виды деятельности).

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

Станислав Алексенко
— Первое – должны быть технические навыки. Если их не так много, то желание освоить новое и так далее. Я помню, что одно из важных моментов было то, что компания ФТО хотела сопровождать 1С:УХ.

Владимир Малах
— Это да, мы давно занимаемся сопровождением 1С, поэтому и пришли к вам. Вполне очевидное требование.

Станислав Алексенко
— Второе – это SLA (Service Level Agreement – соглашение об уровне сервиса).  Для меня важно, чтобы у подрядчика, который возьмется поддерживать сложную систему с большим количеством бизнес-процессов, с пользователями всех уровней, было понимание, что такое качественное SLA и как оно работает.

Я общался с несколькими подрядчиками, на каждом из интервью задавал вопросы по оцифровке качества SLA. Часто сталкивался с непониманием наших требований. Трудность заключалась в том, что даже когда мы прописывали SLA, подрядчик все равно не мог реализовать его так, как мы это видели. Например, что нужно отмечать, какие задачи вовремя сделаны, а какие нет; какой уровень текущей поддержки и удовлетворенность пользователей; что нужно сделать, чтобы уровень стал выше и т.д. То есть для меня хорошая поддержка – это поддержка в цифрах.

Владимир Малах
— То есть для тебя важный критерий – это выстроенные процессы, которые ориентированы на то, чтобы гарантировать определенный уровень сервиса.

Станислав Алексенко
— Все так. У многих подрядчиков нет нормального трекера задач. Их трекер ориентирован на проектные работы, нет инструментов, которые позволили бы посчитать уровень сервиса (отчёт по выполнению SLA). Например, с одним подрядчиком мы вели задачи поддержки в google-таблице. Как-то я сам вручную посчитал по этой таблице уровень SLA, потратил на это неделю. Когда запрашиваю в ФТО отчет об уровне сервиса, мне высылают автоматически сформированный документ достаточно быстро. По нему ясно, как и что происходит в поддержке 1С.

Владимир Малах
—Для тебя важна также прозрачная отчетность и обратная связь. Понятно, спасибо.

Когда компании выбирают подрядчика, рекомендуется обращать внимание на количество сертификатов 1С, таких как «1С:Центр ERP», «1С:Центр КОРП», «1С:Центр реальной автоматизации», «1С:Центр сертифицированного обучения» и пр. Насколько важны для тебя статусы 1С при выборе подрядчика?

Станислав Алексенко
—Наличие статусов 1С – для меня не ключевая вещь при выборе подрядчика. Но обращаю на них внимание, они должны быть. Правда их наличие, к сожалению, не гарантирует успеха проекта внедрения 1С или качества поддержки 1С.

Владимир Малах
— Какие механизмы контроля подрядчика и обратной связи ты бы хотел видеть?
Какой вариант наиболее приемлемый для тебя?

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

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

Станислав Алексенко
— С самого начала хочется установить, по какой причине ошибка и далее конструктивно проработать вопрос, вынести его на обсуждение и решить.

Владимир Малах
— То есть не искать виноватых, а решать проблемы. Хотя люди тоже могут быть виноваты. Например, в рамках сопровождения сделали обновление, накатили новую функциональность (которая вышла в обновлении). Сделали модификации, которые несовместимы с новым функционалом. Не протестировали. Не работает. Вот типичная ошибка при обновлении.

Станислав Алексенко
— Задачи, связанные с обновлением, можно измерить по SLA. Приведу пример с прошлого места работы: обновление было полностью отдано программистам. Они обновляли, проверяли и, когда считали работу сделанной, выполняли обновление рабочей базы. Но, у них был свой взгляд на то, что это значит «работает», и для пользователей это “готово” выражалось в неделю ада.когда все «отваливается», и ничего не работает. Чтобы пользователям было легче, мы поменяли процессы и стали тщательно тестировать. Таким образом сократили с длительность проблемного периода с 7 до 1,5 дней (когда в поддержку приходит большое количество заявок и инцидентов). Можно было бы ещё уменьшить, но это может быть неразумно. Очень дорого, честно говоря, тестировать обновления, чтобы ошибок не было совсем.

Владимир Малах
—То есть вы выбираете баланс между объемом тестирования перед обновлением релиза и сроками, чтобы по ожиданиям уложиться в исправление ошибок в достаточно короткий срок, 1-2 дня.

Обновления выходят регулярно. По некоторым конфигурациям фирма 1С выпускает обновления ежемесячно. Выходит достаточно трудозатратное мероприятие, если мы говорим про сложную систему, такую как «1С:Управление холдингом» или «1С:ERP 2». Если система имеет в себе кастомизации, то обновление может занимать 40, 80 и 200 часов.  Какой твой подход к обновлению? Как часто ты обновляешься и почему?

Станислав Алексенко
— Мы обновляем «1С:УХ» около 2 раз в год. Это проектная задача, она не касается как таковой поддержки 1С.

Владимир Малах
— Согласен, такое обновление не входит в SLA. Но почему 2 раза в год, а не 4 или 8?

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

Владимир Малах
— Получается, что два обновления в год – это баланс между тем, чтобы не сильно отставать от текущего релиза, и той трудоемкостью, которую вы тратите на обновление. Это разумный баланс, разделяю его.  Зачастую исправляют изменения, которые вносятся даже в типовые релизы, допустим, исправляют ошибки, не связанные с изменением законодательства. Без них, конечно, можно жить.

Станислав Алексенко
— Да, иначе все ресурсы уходят на обновление. Не видим смысла делать бесконечные обновления.

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

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

Владимир Малах
— Какое время оцениваешь на передачу сопровождения 1С от одного подрядчика к другому?

Станислав Алексенко
— Смотря какая система, какой размер. Для передачи поддержки «1С:УХ» в ФТО было потрачено 2 месяца. Расскажу подробнее, как мы осуществили передачу поддержки 1С.

За передачей сопровождения 1С можно и нужно следить. Для этого у нас было два трекера задач: от старого подрядчика и нового (ФТО). Новый подрядчик брал время на изучение вопросов, ходил к экспертам по доработкам, «напитывался» знаниями. Далее мы с какого-то момента говорили старому подрядчику, что по вот этой теме (изученной теме новым подрядчиком) заявки не принимайте, и говорили пользователям, что по этой теме направляйте заявки другим. Так планомерно перетекал поток задач. Сравнивая два трекера можно увидеть, как уменьшается количество запросов у старых подрядчиков, а у новых увеличивается. Последние две недели (из 2 месяцев перехода) у старых подрядчиков почти не было задач.

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

Тут конечно немного получается наша реклама, но хочу подчеркнуть, что на данный момент все процессы по сопровождению вашей системы полностью отстроены (все инциденты документируются, есть актуальная база знаний, есть схемы решения типовых проблем, уровень сервиса устраивает ключевых пользователей). Соответственно, если сейчас возникнет потребность поменять текущего подрядчика (ФТО) на кого-то другого, то это может получиться даже быстрее чем 2 месяца, так как есть набор документации, который можно передать.

Станислав Алексенко
— Все верно. Кроме набора документации, сейчас есть удобная сервис-деск система, в которой отображается поток вопросов, которые идут в поддержку от пользователей.

Владимир Малах
— В заключении можно сделать вывод: передача поддержки 1С на аутсорс – это не страшно. Глобальной зависимости от подрядчика не возникает. У вас есть понятный договор на год, в рамках года цена за сопровождение 1С никогда не меняется.

Станислав Алексенко
— Зависимость от подрядчика даже ниже, чем от своей команды, так как добиться от своей команды полного документирования и ведения трекера бывает сложно. С подрядчиком более формальная коммуникация, можно эскалировать, пригрозить штрафами за невыполнение.

Владимир Малах
—Станислав, спасибо за беседу. Получилось интересно!

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