УправлениеИТ в бизнесе

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

Дмитрий Бессольцев | 07.04.2019

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

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

Во-первых, в современных ИТ-решениях довольно высока доля нового программного обеспечения – российского и 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 на свою услугу сопровождения ИТ-решения, хотя он сам и не располагает компетенциями по большей части использованных продуктов. Так интегратор сокращает расходы и снижает риски. Сервисная компания повышает объем предоставляемых услуг и, соответственно, сокращает их себестоимость. А заказчик получает сервис поддержки внедренного ИТ-решения с гарантированными параметрами. Еще недавно такого не было. А сейчас это наиболее перспективная схема, на которую только и могут опираться современные ИС, значительно отличающиеся от своих предшественниц.

 

Аутсорсинг

Горячие темы: Бизнес в цифре

Журнал: Журнал IT-Manager [№ 03/2019], Подписка на журналы

ALP Group


Поделиться:

ВКонтакт Facebook Google Plus Одноклассники Twitter Livejournal Liveinternet Mail.Ru

Также по теме

Мысли вслух

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

Компании сообщают

Мероприятия