Кто и как должен поддерживать внедренную систему?

Казалось бы, ответ на вопрос: «Кто и как должен поддерживать внедренное ИТ-решение?» – очевиден. Конечно, крупный системный интегратор. Однако сегодня это утверждение может оказаться неверным сразу по нескольким причинам.

Во-первых, в современных ИТ-решениях довольно высока доля нового программного обеспечения – российского и Open Source. Для одних заказчиков это связано с требованиями нормативной базы в области импортозамещения ИТ, для других – со стремлением снизить санкционные риски, для третьих – с внедрением быстро набирающих популярность информационных технологий (например, BigData или ИИ). Здесь выбор идет не из продуктовых линеек двух-трех всем известных лидеров рынка, а из многих альтернатив, среди которых нет явного лидера. Соответственно, далеко не каждый системный интегратор успел накопить по ним компетенции, а многие не решаются на такой шаг из-за высокой вероятности ошибки. Это приводит к тому, что интегратору трудно или даже практически невозможно самостоятельно сопровождать систему, решать и предотвращать ИТ-инциденты, находить причины повторяющихся ИТ-проблем. И все это в рамках достаточно жесткого SLA.

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

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

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

Компетенция № 1. Решение корневых ИТ-проблем прежде, чем они повлияют на бизнес

По нашей статистике, 70–80% причин ИТ-проблем, возникающих в работе внедренной ИС, лежит в области глубокой ИТ-инфраструктуры. Причем на стыки программных продуктов приходится лишь 20% из них. Получается, что 50–60% ИТ-проблем оказывается непрофильной работой для системных интеграторов. И даже если им удается выявить и устранить большую часть этих проблем с инфраструктурой, скажем, в центральном офисе крупной организации, далее придется выполнить большую работу по устранению последствий в масштабах всей территориально распределенной ИС заказчика. То есть в момент, когда ИТ-проблемы уже успели повлиять на бизнес клиента. Например, в сети с 300 филиалами по России убытки могут составить 7–10 млн руб. в день, только из-за отсутствия раннего оповещения о проблемах с ИБ и эшелонированной системы защиты от атак вирусов-шифраторов. И это цена лишь одной ошибки у одного крупного заказчика.

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

Компетенция № 2. Работа с новыми типами ПО

Не секрет, что квадранта Гартнера для российского ПО так и не сложилось. Как и четыре года назад, большинству системных интеграторов неясно, по каким программным продуктам следует наращивать собственные компетенции, а по каким – нет. В обучение и переобучение каких специалистов лучше вложиться в этом году, а каких – в следующие.

Между тем, новых программно-управляемых ИТ-инфраструктур, построенных на базе российского ПО и Open Source-решений, становится все больше. И это в основном серверные ландшафты крупных коммерческих компаний. Или госорганизаций, ведущих проекты по импортозамещению и системно заменяющих Windows- на Linux-инфраструктуру.

Замечу, что сервисные компании в среднем вообще быстрее набирают компетенции по новым типам программных продуктов – потому что у них нет люфта по времени, который есть у системных интеграторов. Из-за особенностей своей модели бизнеса они не могут сказать: «Это не основные наши продукты, мы пока учимся». Профессиональная ИТ-поддержка подразумевает не только полностью приобретенные компетенции, но и доведенные до четко определенной технологии. И много раз обкатанные на десятках и сотнях клиентов – даже по новым для других компаний типам ПО. Именно поэтому поддержка критически важных новых ИТ-решений (например, ПАК CommuniGate Pro на «Эльбрусе») и стека встроенных в него продуктов (в этом примере: ОС «Альт», СУБД Postgres Professional и платформа унифицированных коммуникаций не только на x86, но и на «Эльбрусах») действительно становится спасательным кругом для заказчиков.

Если же у сервисной компании каких-то компетенций нет, нехватку должна компенсировать ее региональная партнерская сеть или столичные стратегические партнеры (обычно в форме услуг центров компетенций). Причем стек продуктов «сервисниками», как правило, выбирается точнее, чем интеграторами, так как на ошибки и постепенное «раскачивание» работы с ПО у сервисных компаний часто нет ни времени, ни денег – в отличие от имеющих больше ресурсов интеграторов. Низкая маржинальность сервисного бизнеса (15%) не оставляет права на ошибки – они становятся слишком дорогими. То, что мы видим сегодня, полностью соответствует этим утверждениям: зрелые сервисные компании уже умеют поддерживать в соответствии с жесткими SLA не только Windows и Linux, но и многосоставные стеки импортонезависимого ПО, располагают разными реализациями одноименных ITIL-процессов для разных типов ПО и для клиентов разного размера и разной степени ИТ-зрелости. А интеграторы пока только учатся этому (в той степени, в которой позволяет их модель бизнеса).

Компетенция № 3. Снятие тяжелых вопросов с производительностью приложений

Если внедренная система вдруг начинает работать медленно и нестабильно, у сотрудников компании-заказчика очень быстро накапливается недовольство. Обычно штатные ИТ-специалисты клиента и компании-интеграторы предлагают простое решение – купить еще больше дорогого оборудования (серверов, СХД) или ресурсов в облаке. И нередко заказчик так и делает, полагая, что другого пути нет. А потом выясняется, что в штате у клиента нет ИТ-специалистов, способных правильно работать с «железом», стоимостью в 10–20 млн руб., и выжимать из него максимум. Оно пылится в углу или выдает от силы 30% от того, на что способно (поскольку неправильно настроено и используется). Или же купленными втридорога ресурсами из облака «заливается», допустим, СЭД, а проблемы с 1С, CRM или профильными медицинскими сервисами, как мучили всю компанию – от бухгалтеров и продавцов до генерального директора, так и мучают. А ИТ-бюджета еще и на их решение уже нет! Сервисная компания может предложить другой, более продуманный и выгодный для заказчиков подход. Здесь не идет речи о «заливке» ИТ-проблем ресурсами. Во главу угла ставится точное выявление и устранение реальных «узких горлышек» в ИС с помощью современных инструментов экспертного уровня (СЦМК, доработанные и правильно настроенные системы мониторинга, в худшем случае, детальная аналитика за 3–6 месяцев в Service Desk).

Компетенция № 4. Сохранение функций ПО, которое купил заказчик

Почти 40% крупных госзаказчиков, которые обращаются в наш Центр компетенции по импортозамещению и Open Source, стремятся «успеть в последний вагон», то есть максимально быстро решить вопросы, связанные с импортозамещением. Они не хотят вовлекаться в проекты, которые займут год или два, а потому предпочитают покупать преднастроенные программно-аппаратные комплексы (ППАК), способные практически сразу начать работу. Но так же, как и крупные коммерческие предприятия, они не хотят оставаться один на один с ИТ-проблемами, которые могут возникнуть с ППАК. А проблемы вполне допустимы, ведь комплекс из ПО новых типов встраивается в уже существующую и постоянно меняющуюся ИТ-инфраструктуру, а его «части» непрерывно обновляются.

Но самое главное, госзаказчики справедливо не хотят терять те свойства ППАК, за которые они уже заплатили, и немало. Более того, переходя на незнакомое ПО, часто на незнакомой платформе, они хотят получить гарантированно работающее ИТ-решение – в оптимальной конфигурации. С минимальным сроком внедрения (от 1 до 6 мес.) и ясной для них схемой затрат.

Ответ на это требования один: предложить вместе с ППАК три уровня технической поддержки («Базовый», «Стандартный» и «Расширенный»). На первом уровне решаются вопросы типа: «Должно работать как написано, но не работает». На втором – к решению базовых технических вопросов добавляется проактивный мониторинг ИТ-инцидентов и проблем с помощью сервиса централизованного мониторинга и контроля над «здоровьем» ИС (СЦМК). На третьем – к стандартным функциям и мониторингу инцидентов добавляется практически непрерывное отслеживание производительности ПО, из которого состоит ППАК. Замечу, что СЦМК при этом должна пройти «курс молодого бойца», то есть накопить первоначальный архив данных о «здоровье» системы за 3–5 недель. Только после этого она начинает полноценно отслеживать производительность ПО и оборудования, сравнивая их состояние с имеющимися «эталонами».

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

Системные интеграторы, безусловно, тоже внедряют ППАК-и, а их техподдержку зачастую отдают более мелким сторонним компаниям. Сохранится ли ППАК в том состоянии, за которое заплатили его заказчики – неизвестно (поскольку неясно, есть ли у более мелкой сервисной компании, работающей на субподряде, например, зрелые ИТ-процессы или только практики). Это маловероятно, особенно если речь идет обо всем жизненном цикле комплекса российского ПО. Сервисные же компании предпочитают решать задачи клиентов системно – сразу разрабатывать и поддерживать как единое целое ППАК-и, сформированные из лидирующих в своем классе системообразующих российских продуктов (например, ОС «Альт Сервер» + МойОфис + SOGo или CommuniGate Pro и др.). И если они располагают технологией СЦМК, то могут гарантировать сохранение свойств комплекса на протяжении всего его жизненного цикла – что в идеале и требуется крупному клиенту.

Компетенция № 5. Работа с современными инструментами

Важно не только, кто и как поддерживает ИС, но и с помощью каких инструментов. Сервисные компании часто вынуждены ради снижения издержек использовать передовые инструменты или разрабатывать собственные (СЦМК, Service Desk в облаке, система для взаимодействия с сотнями региональных партнеров и т. д.). Это дает значительный эффект. Так, облачный Service Desk, например, позволяет крупным и средним заказчикам из ретейла получать качественную ИТ-поддержку «24×7». Это важно, потому что значительная часть магазинов в регионах работает у торговых сетей поздно вечером и ночью. Также у этих заказчиков вечером и ночью действуют склады, которые тоже поддерживаются и на которых постоянно идут важные отгрузки. Поэтому необходимо не только решение ИТ-инцидента в строго оговоренный с клиентом срок, но и оперативное попадание инцидента в систему, и 15-минутная реакция ИТ-специалиста на нее. Исполнитель должен видеть инцидент сразу же и сразу присвоить ему правильный приоритет, даже если он пришел поздно ночью. В противном случае сотрудник рискует пропустить действительно крупный ИТ-инцидент (например, массовый сбой в работе касс), способный негативно повлиять на все магазины сети. И привести к многомиллиардным убыткам. Так, у многих в ретейле до сих пор на слуху масштабный массовый сбой кассовых аппаратов, случившийся в декабре 2017-го и породивший многомиллиардные убытки.

Есть еще один важный момент – взаимная интеграция ServiceDesk – например, с системами стратегических партнеров и компаний, входящих в региональную партнерскую сеть. Такая интеграция избавляет от дублирования заявок на ИТ и, соответственно, от лишней работы по ним. Ведет к прозрачности взаиморасчетов и к понятности действий каждого участника процесса – даже если они отвечают за разные участки общего процесса и «сидят» в разных регионах.

Итого

Все компетенции, которые я отметил выше (заблаговременное выявление и решение корневых ИТ-проблем с Windows- и Linux-инфраструктурами; работа с новыми типами ПО; сохранение функций ИТ-решения, за которые заплатил заказчик и др.) доступны как клиентам, так и системным интеграторам, заказчикам которых не хватает сервисной составляющей. Такие компетенции традиционно для ИТ-рынка приобретаются в виде готовых услуг, отвечающих на потребности современных клиентов.

Опираясь на услуги сервисных компаний (максимально автоматизированные и поддерживаемые системой ITIL-процессов и СЦМК) с четкими, действительно соблюдаемыми SLA, интегратор может сформировать SLA на свою услугу сопровождения ИТ-решения, хотя он сам и не располагает компетенциями по большей части использованных продуктов. Так интегратор сокращает расходы и снижает риски. Сервисная компания повышает объем предоставляемых услуг и, соответственно, сокращает их себестоимость. А заказчик получает сервис поддержки внедренного ИТ-решения с гарантированными параметрами. Еще недавно такого не было. А сейчас это наиболее перспективная схема, на которую только и могут опираться современные ИС, значительно отличающиеся от своих предшественниц.

Автор

Дмитрий Бессольцев, директор департамента ИТ-аутсорсинга ALP Group