«Ингосстрах»: Мы открыты для рынка и строим партнерские отношения с нашими поставщиками

Иван Мартишевский: Компания «Ингосстрах» использует систему учета страховой деятельности, разработанную собственными силами с 1998 года — это система класса ERP, построенная на СУБД Oracle с высокими требованиями к производительности, надежности и квалификации инженеров сопровождения. Все это время система непрерывно развивается под требования бизнеса и регулятора. Кроме функционала страховой деятельности в системе есть большое разнообразие модулей общего назначения.

В настоящее время СПАО «Ингосстрах» двигается в направлении импортозамещения Oracle. Это масштабная работа, план перехода подразумевает постепенное замещение модулей существующей системы на новые системы на целевом стеке технологий. На время, необходимое для перехода (импортозамещения) на другую систему, техническая поддержка СУБД Oracle остается востребована в компании. Наша главная цель — поддержать работу системы и обеспечить безопасное и надежное хранение данных компании.

Для достижения цели нам необходима качественная 3 линия поддержки по СУБД Oracle. 3 линия поддержки является важным компонентом для обеспечения высокого уровня сервиса. Годами основными требованиями к технической поддержке в нашей компании являлись:

• Вендорская поддержка Oracle (прямая или через партнера).
• Доступ к базе знаний (My Oracle Support) под персональной учетной записью.
• Подтверждение регалий специалистов.
• Критические исправления, оповещения об угрозах безопасности.
• Доступ к репозиторию ПО, в т.ч. к репозиторию заплаток и квартальных обновлений.

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

Иван Мартишевский: В наше техническое задание мы включаем следующие основные требования:

1. Продукты, по которым нужна поддержка. Даем основной список, по которому мы будем обращаться.
2. Уровни критичности событий. Здесь должно быть конкретное ранжирование, чтобы не возникало разночтений.
3. Требования ко времени реакции и обновления информации в обращении в зависимости от уровня критичности. Подход очевиден: мы не требуем молниеносной реакции на инциденты низкой критичности, но по событиям первого приоритета ожидаем полного вовлечения в работу за минуты.
4. Мы разделяем SLA по запрашиваемым сервисам: SLA по инциденту, проблеме и проактивной поддержке отличаются. 24/7 и моментальная реакция — это исключительно инцидентная поддержка, все остальное в рабочие часы.
5. Фиксируем количество обращений, чтобы участникам было удобнее составлять предложение основываясь на лимите. Безлимит по обращениям — это неопределенность для исполнителя и как следствие рост стоимости услуг. На случай, если превысим лимит обращений, фиксируем стоимость часа по услугам.
6. Указываем требуемые компетенции команды ссылаясь на уровни сертификации Оracle (professional, expert, master).
7. Предоставляем выгрузку диагностических данных (AWRdump) для анализа и составления отчета в рамках домашнего задания.

Мария Маринина: Oracle обладал большим количеством авторизованных сервисных провайдеров технической поддержки, работающих на территории России. Из этих компаний многие со статусом сертифицированного партнера, а кто-то являлся дистрибьютором.

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

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

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

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

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

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

Придерживаемся подхода максимально возможной открытости и даем полную информацию всем участникам тендера об уровне услуге технической поддержки:

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

Насколько возможно отвечаем на вопросы участников, чтобы они наиболее точно смогли оценить объем своих затрат и рассчитать для нас соответствующее предложение, без работы себе в убыток, и чтобы у нас не было повода усомниться в отсутствии сверхприбыли по контракту.

Иван Мартишевский: В наших тендерных процедурах мы используем еще один этап проверки компаний участников тендера. Этап «тестовое задание» как дополнительный способ оценки компетенции команды поставщиков, т.к. оставшись без связи с производителем ПО локальные специалисты вынуждены полагаться на свой опыт и умение искать информацию в разных источниках. Тестовое задание сформировали в виде AWR dump за период три дня с БД нашей центральной системы. Задание — проанализировать AWR dump и составить отчет по анализу. Мы понимаем какие события произошли в этот период работы нашей системы, какие особенные настройки в БД, какой профиль нагрузки, и мы предполагаем, что участники на что-то из этого обратят внимание. У нас сильная команда и мы хорошо знаем свою систему, поэтому результатами анализа нас сложно удивить, но можно показать уровень компетенций. На руках у участников только AWR dump, обычно, этого мало для полноценной диагностики, но мы не хотим перегружать участников огромным набором диагностической информации, дав возможность делать предположения и не требуя выводов, претендующих на абсолютную истину. На что обращали внимание в отчетах по тестовому заданию:

• Находки.
  • События-всплески, которые явно выделяются на общем фоне.
  • «Хронические боли» или что-то, что «фонит» на протяжении всего периода анализа.
  • Любое другое явление, которое привлекло внимание.

• Качество рекомендаций. Тут мы смотрим на соответствие нашим подходам в работе, насколько рекомендации по выявленным замечаниям релевантны, осознанны, критически осмысленны, проактивны и целесообразны.
• Инструменты. У каждого свой набор и мы не требуем стандарта, но если нет визуализации событий, то участник сразу в аутсайдерах. Оцениваем, насколько развит инструментарий.

ИВАН МАРТИШЕВСКИЙ: Тестовое задание позволяет определить экспертизу, эффективность и заинтересованность поставщика в данной работе.

Экспертиза. С одной стороны, мы понимаем, что при выполнении домашнего задания может быть использовано «секретное оружие», которое не будет применяться в 90% наших обращений, с другой стороны нам важно иметь возможность получить результат от работы эксперта и в основном не в режиме пожаротушения, а в проактивном анализе.

Эффективность. Это все про инструментарий. По отчету можно оценить, насколько продвинутые инструменты в арсенале команды и как эффективно ими пользуются специалисты

Заинтересованность. Насколько участник заинтересован в работе с нами. Партнерские отношения возникают только при взаимной заинтересованности. Если интереса нет, то нам не по пути.

Этот способ тестирования сокращает время выбора поставщиков, т.к. позволят быстро определить какие поставщики могут быть потенциальными кандидатами для сотрудничества, а какие нет.

«Тестовое задание» — это уникальная возможность не только нам как заказчику оценить поставщиков, но и поставщикам выйти на прямой диалог с заказчиком и не пытаться угадать и предусмотреть все риски и объемы работы с новым заказчиком, а наоборот:

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

Лучше показать себя. Продемонстрировать на что способна команда на деле, а не в презентациях.

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

Анализ качественной и коммерческой части проводится отдельно разными специалистами нашей компании. Это позволяет получить непредвзятую оценку и выбрать оптимально поставщика. Эксперты оценивают качество, а закупщики оценивают стоимость согласно результатам качественной оценки, это позволяет найти самую компетентную команду за разумную стоимость. Мы не выбираем победителя перемножая качество на стоимость, мы не готовы жертвовать качеством в угоду самой низкой стоимости. Решение о выборе победителя принимается совместно заказчиком и закупщиком с утверждением на тендерном комитете.

Мы открыты для рынка и строим партнерские отношения с нашими поставщиками, нам важно получить качественные услуги, и мы готовы дать шанс всем профессиональным компаниям стать нашими партнерами.