Несколько лет назад наша компания столкнулась с задачей организации поддержки системы SAP BI для нескольких наших постоянных клиентов. В рамках поддержки требовалось осуществлять множество различных задач. Здесь я поделюсь практическим опытом.

Постановка задачи

Несколько лет назад наша компания столкнулась с задачей организации поддержки системы SAP BI для нескольких наших постоянных клиентов. В рамках поддержки требовалось  осуществлять: разбор инцидентов от пользователей системы с уровнем исполнения SLA 95% семь дней в неделю с 9-00 до 20-00 (2-я и 3-я линии обработки заявок), мониторинг и восстановление работы периодических заданий загрузки данных семь дней в неделю, 24 часа в сутки, архитектурный контроль, а также контроль качества разработок и документации при приемке нового функционала на поддержку в динамично развивающейся системе. В договоре был определен трехмесячный период стабилизации, в рамках которого целевой показатель выполнения SLA мог нарушаться без санкций к исполнителю.

Проблемы

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

  • Сложный график доступности сервиса.

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

  • Выгорание команды.

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

  • Отсутствие на рынке подготовленных кадров, желающих заниматься поддержкой системы.

Работа в поддержке требует тех же навыков работы с системой, что и на внедрении/развитии. Однако внедрение и развитие систем с точки развития специалиста имеет ряд, как объективных, так и субъективных преимуществ:

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

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

Организация работ. Сложный график. Решение проблем

Одной из главных задач, которые предстояло решить, была организация мониторинга и восстановления работоспособности ночных периодических заданий загрузки и расчета данных в ночное время. Работа высококвалифицированного специалиста в ночные часы стоит дорого, к тому же крайне мало специалистов на рынке согласятся такую работу выполнять на постоянной основе. В первую очередь была проведена работа над оптимизацией и повышению стабильности периодических заданий. Это позволило сократить продолжительность ночных периодических заданий и сконцентрировать их в промежутке с 04:00 до 09:00. Повышение стабильности ночных процессов позволило сократить трудозатраты по восстановлению работоспособности заданий. В результате получилось драматически сократить время привлечения специалиста поддержки к мониторингу и ограничить его периодом с 07:00 до 09:00, при этом пользователи системы гарантированно получали корректные данные в системе к началу рабочего дня (10:00). Дальнейшая работа по разбору и классификации возникающих проблем позволила частично автоматизировать перезапуск ошибочно завершенных процессов и частично описать решения проблем в подробных инструкциях. Это в свою очередь позволило привлекать на эту работу стажеров и младших специалистов, которые обращались за помощью к высококвалифицированному дежурному специалисту только в случае, если проблема новая и не описана в инструкции.

Еще одной сложностью

Если хотите прочитать статью полностью и оставить свои комментарии присоединяйтесь к sapland

У вас уже есть учетная запись?

Войти