Управление ИТ

В понедельник утром перестает работать критичная информационная система. Пользователи обращаются в техподдержку, Service Desk регистрирует инцидент, определяет приоритет и подключает специалистов, создается аварийный чат. Через час работа системы восстановлена. В отчете все выглядит достойно: первая реакция заняла пять минут, ответственные подключились своевременно, пользователи получали информацию, сервис восстановлен в пределах SLA, инцидент закрыт. Команда действительно хорошо справилась с аварией.

Через два месяца ситуация повторяется. Снова обращения, аварийный чат и восстановление. Возможно, на этот раз уже за сорок минут. Формально показатели улучшились. Но фактически бизнес второй раз остановился по той же или близкой причине.

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

Именно поэтому полезен мысленный эксперимент: представьте, что техподдержка не получила звонок пользователя и не запустила привычный аварийный механизм. Обнаружила бы ИТ-служба нарушение самостоятельно? Поняла бы, какая бизнес-операция остановилась? Было бы ясно, кто и как должен действовать?

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

Отчет Service Desk видит только вторую половину инцидента

Разберем описанную ситуацию подробнее. Представим, что в 8:20 начала деградировать интеграция между внутренней системой электронного документооборота — СЭД — и оператором ЭДО. Согласованные и подписанные отгрузочные документы продолжали создаваться, но передавались все медленнее. В очереди накапливались сообщения, а статусы обработки перестали вовремя возвращаться во внутреннюю систему.

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

Некоторое время пользователи не замечали проблемы. Документы формировались, открывались и выглядели готовыми к отправке. Однако комплекты по ближайшим отгрузкам не получали требуемого статуса. В 9:05 специалист по оформлению отгрузок увидел, что машины готовы к выезду, а документы по ним продолжают находиться в промежуточном состоянии. Он обратился в поддержку. В 9:10 инцидент уже был в работе, а в 9:45 специалисты восстановили технический обмен.

В отчете результат выглядит хорошо: первая реакция — пять минут, восстановление с момента обращения — 40 минут, SLA выполнен. Но на самом деле бизнес жил с нарушением не 40, а 85 минут. Первые 45 из них не попали в отчет Service Desk, потому что никто еще не зарегистрировал инцидент.

Отчет при этом не ошибается. Он точно описывает работу поддержки с момента обращения. Просто он не показывает период, когда документы уже перестали проходить по цепочке, а ИТ еще не знало об этом. Это первая «слепая зона» реактивной модели — время до обнаружения.

Есть и вторая «слепая зона». В 9:45 интеграционная служба снова заработала, но процесс отгрузки еще не восстановлен. Нужно обработать накопившиеся документы без потерь и дублирования, синхронизировать их статусы с внутренней системой и проверить отгрузки, затронутые инцидентом.

Кроме того, причина сбоя может остаться. Если обмен восстановили перезапуском службы, организация уменьшила продолжительность текущего инцидента, но не обязательно снизила вероятность следующего. Показатель среднего времени, необходимого для устранения сбоя (Mean Time to Repair, MTTR) может улучшаться, а надежность сервиса — нет. Значит, вопрос уже не в том, как еще быстрее обработать заявку.

Что должно сработать без звонка пользователя?

До и во время инцидента должны были сработать три защитных механизма: раннее обнаружение, ограничение воздействия и восстановление согласованного состояния документов и систем.

Сначала — обнаружение. Деградацию можно было заметить по «возрасту» самого старого документа, ожидающего передачи, времени с момента последнего документа, успешно прошедшего контрольную точку, и количеству ближайших отгрузок, по которым еще не получен требуемый статус.

Полезный сигнал выглядел бы не «В очереди 500 элементов», а «Документы по трем отгрузкам ближайшего часа не получили статус, необходимый для выпуска машин. Самый старый документ ожидает передачи 28 минут». Такой сигнал показывает не только техническое отклонение, но и приближающееся воздействие на бизнес.

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

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

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

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

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

Здесь легко сделать неверный вывод: решить, что теперь нужно расширять мониторинг всех систем и покупать новые инструменты. Начинать следует не с технологий, а с нескольких действительно критичных бизнес-операций. Возьмите одну из них и спросите: узнает ли ИТ о нарушении без звонка пользователя? Через сколько минут появится сигнал и будет ли из него понятно, что именно идет не так? Если ответов нет, разрыв в обнаружении уже найден.

Затем посмотрите на повторяющиеся инциденты. Что остается после закрытия заявки: план корректирующих действий с указанием ответственных и сроков или только инструкция по перезапуску? Если систему месяцами восстанавливают одним и тем же способом, организация сокращает время реакции, но не снижает вероятность следующего сбоя.

Следующий вопрос — насколько далеко может распространиться локальная проблема. Можно ли остановить неудачное изменение до массового воздействия? Продолжит ли внутренняя система готовить и сохранять документы, если оператор ЭДО временно недоступен? Существует ли заранее согласованный порядок для отгрузок, которые нельзя отложить? Цель не в том, чтобы любой процесс бесконечно работал при любых отказах. Важно, чтобы граница допустимой деградации и действия после ее достижения не выяснялись впервые во время аварии.

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

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

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

Что можно изменить за один квартал

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

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

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

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

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

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

***

Управлять ИТ так, будто техподдержки нет, — значит заранее знать, когда мы сами увидим нарушение, кто начнет действовать и сможем ли мы восстановиться. Если отчет заканчивается на MTTR, он показывает работу аварийной команды — но еще не показывает надежность ИТ.

Автор – Андрей Шантарин, ИТ-директор завода «Уралхиммаш»

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

Бессмертный «зоопарк»

«Зоопарк» слабо интегрированных или вообще не связанных между собой программных продуктов, с которым бизнес активно боролся много лет назад, сегодня, похоже, наиболее характерен именно для вузов. Разносортный софт, которым пользуются деканаты и бухгалтерия, личные кабинеты студента и работодателя, расписание, рабочие приложения ректора, система управления учебным процессом (LMS) — все это надо увязывать. И нельзя сказать, что в этом направлении ничего не делается.

Как рассказал начальник управления информационных технологий, связи и информационной безопасности Омского государственного университета Сергей Барановский, цифровизация ОМГУ начиналась с самописных систем. «Но в 2020 году нас постигла катастрофа масштаба: замена каждого следующего сервиса требовала все большей трансформации существующей инфраструктуры, — поделился он. — С той поры мы начали радикально все менять, упорядочили самописные системы и положили в основу понятные платформы».

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

А вот тема совместной разработки или обмена уже созданным ПО как средства борьбы с «зоопарком» на рабочем месте буксует, и понятно почему. Во-первых, вузы конкурируют за бюджеты, за абитуриентов «высокобалльников» и «олимпиадников» по всей стране. Поэтому помогать разрабатывать решения конкурентам готовы далеко не все. Во-вторых, внутреннее решение развивается под требования внутреннего заказчика, а у следующего заказчика будут иные идеи. Вырвать любую инхаус-разработку из существующей инфраструктуры конкретной организации и куда-либо перенести — сложнейшая задача. В-третьих, даже передав свои наработки безвозмездно, поддерживать их в другой организации бесплатно никто не будет. Тиражирование внутреннего решения требует серьезного уровня партнерства, командной работы. Отнюдь не каждой организации под силу повторить опыт создания «ЛОГОСа», разработанного в контуре Росатома для внутренних нужд, но превращенного в рыночный продукт.

Дорогая безопасность

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

Еще один тонкий момент: вуз не имеет права хранить персональные данные студентов после окончания обучения — эти данные нужно перенести в архив, либо обезличить, либо уничтожить. Об это правило спотыкается организация эффективного взаимодействия с работодателями. Например, в МАИ создали цифровую кадровую платформу, чтобы пристраивать своих выпускников. Но, во-первых, на эти цели персональные данные не собирали, и, во-вторых, самые интересные работодателю студенты — выпускники, данные которых как раз и требуется убирать. МАИ должен готовить кадры, прежде всего, для авиационной промышленности и авиационно-ракетной отрасли. Однако ОАК, Ростех, Роскосмос и ОДК не могут конкурировать по стартовому уровню зарплаты для новичков с тем же «Яндексом». Поэтому кадровая платформа, где можно размещать вакансии, которые видят студенты, для них очень актуальна, подчеркнул Федор Васильев, заведующий кафедрой «Цифровые технологии и информационные системы» Московского авиационного института. Что касается вопроса, зачем государству готовить специалистов, которые потом уходят на свободный рынок, по его мнению, ответ прост: человек, который работает в условном «Яндексе», приносит государству налогов в разы больше, чем человек, работающий на авиационном заводе.

Федор Васильев: «Учить «буржуйскому» софту, который пока еще везде есть, или уже российскому, которого пока еще нигде нет?»

Обеспечить себя ИТ-специалистами высокого уровня для вузов тоже серьезная проблема. «Как затащить топ-айтишников в любую компанию, если это не «Сбер» и не «Яндекс», это большой вопрос», — обозначил проблематику Васильев. Возможность вырастить собственные кадры из студентов не спасает «кузницу кадров» от катастрофического кадрового голода. Сегодня вузам нужны любые ИТ-специалисты, которые способны самостоятельно и качественно решать различный спектр задач.

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

«Буржуйское», но сейчас, или свое, но потом?

Государственные вузы сегодня должны заменять иностранное ПО, в том числе операционные системы и офисные приложения, на российское. Но, помимо этого, есть еще один серьезный вопрос, связанный с импортозамещением: чему учить студентов? Учить «буржуйскому» софту, который пока еще везде есть, или уже российскому, которого пока еще нигде нет? И какие операционные системы, средства проектирования и прочие решения тогда устанавливать в компьютерных классах?

«Нам уже сейчас нужно готовить студента, который через 4-6 лет выйдет на предприятие и будет работать на том программном обеспечении, которое там будет использоваться», — говорит Сергей Попов, проректор по цифровизации МАИ. Только как обучить продукту, которого еще нет?

Сергей Попов: «Для понимания того, как сейчас учить студентов, нужна более плотная коммуникация с отраслью»

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

Пока же остается в запасе классический тезис, что вузы не учат конкретным инструментам. «Все-таки конкретные инструменты — это ремесло, а мы — про образование», — заметил Васильев. Поэтому студенты знакомятся с разными программными инструментами, но основное что дает вуз — базовая теория. Правда, работодателей возврат к такой установке вряд ли обрадует.

Для Президентской Академии РАНХиГС импортозамещение сейчас не самая критичная задача, тем не менее, ее решением занимаются. И Р7, и «Мой офис» уже давно включены в программы обучения, на которых учат всех чиновников. «Что касается внутренних систем, то в апреле, когда Microsoft заявила, что уходит из России в соответствии с пакетом новых европейских санкций, для нас это был хороший повод, — рассказал Павел Клепинин, проректор по информационным технологиям и цифровой трансформации Президентской Академии РАНХиГС. — И мы через пять дней перевели наших пользователей на сервисы «Яндекса» — почту, календарь, диск и мессенджер». Все встречи и рабочие совещания теперь проводятся в сервисе «Яндекс.Телемост», а дистанционный процесс обучения и в гибридном формате — через «МТС Линк». Смена любой системы — всегда стресс и нужно с ним работать. В управлении изменениями есть множество инструментов, как этот стресс снять и сделать людей сторонником изменений. При переходе большое внимание было уделено именно этому компоненту. Нужно обязательно транслировать опыт воздействия на сотрудников.

«ИТ-ночь на Ивана Купала» — традиционная встреча цифровых управленцев, с которой начинается отсчет очередного года сообщества «я-ИТ-ы», прошла насыщенно и плодотворно. Съехавшиеся со всех концов страны ИТ-руководители обсуждали интересные исследования и кейсы, делились полезным опытом, разбирали свои ошибки и тренировались в управленческих поединках. «я-ИТ-ы» активно растет и развивается: каждый день в сообщество добавляется один новый ИТ-управленец, сообщил один из учредителей сообщества «я-ИТ-ы» Павел Клепинин.

В числе обсуждаемых ИТ-директорами тем снова актуализировались вопросы эволюции роли ИТ-подразделений и необходимости ИТ-бизнес-партнеров. Согласно исследованию «Монитор технологий» компании РДТЕХ, в 28% компаний, опрошенных в прошлом году, ИТ-подразделение – это основной драйвер цифровой трансформации. При этом 48% ресурсов ИТ-подразделений направлено на разработку цифровых продуктов и сервисов.

Павел Клепинин: «Каждый день в сообщество добавляется один новый ИТ-управленец»

Некогда модный тренд на превращение ИТ-руководителей в ИТ-бизнес-партнеров так и не стал доминирующим, но и не растворился совсем. Как рассказала Людмила Трофимова, директор по цифровому развитию Президентской Академии РАНХиГС, опрос резидентов сообщества «я-ИТ-ы» подтвердил предположение, что массового появления ИТ-бизнес-партнеров не наблюдается, поскольку результаты запуска этой активности не стабильны и больше зависят от личных особенностей конкретного исполнителя, чем от системно выстроенной работы ИТ-бизнес-партнеров. Тем не менее, у 40% опрошенных в компании есть либо выделенная должность, либо роль ИТ-бизнес-партнера. Причем лидируют роли, связанные с глобальным развитием ИТ-функции и формированием отношений с заказчиком. ИТ бизнес-партнер – это специалист, который умеет вести диалог на уровне первых лиц компании/функции, обладает стратегическим видением и понимает взаимосвязь бизнес-задач с ИТ-решениями. По аналогии с семейным доктором он знает историю «болезни» своего бизнеса, персональные особенности, владеет полным «анамнезом», и его цель — упреждающе работать на сохранение «здоровья». Ключевые компетенции ИТ-бизнес-партнера явно связаны с цифровизацией бизнес-процессов: он должен знать бизнес-процессы функции и имеющиеся на рынке ИТ-решения, которые позволяют их автоматизировать, а также уметь инициировать и реализовывать необходимые проекты цифровизации. По мнению участников дискуссии на ИТ-Купале, наличие ИТ-бизнес-партнера ускоряет принятие управленческих решений, так как коммуникации входят в число его основных задач.

Людмила Трофимова: «Новые роли появляются тогда, когда влияние ИТ на эффективность бизнеса становится очень высоким»

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

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

Компания Enterprise Management Associates опубликовала результаты исследования «Сети после пандемии: предприятие, обеспечивающее работу из любого места», проведенного по итогам опроса 312 специалистов по сетевой инфраструктуре и операциям. Выяснилось, что почти все они составляют бюджет для инструментов мониторинга, помогающих улучшить поддержку пользователей, которые работают из дома. 

Администраторам сетей потребуется обновить свои инструменты сетевого мониторинга и диагностики неисправностей для поддержки огромного числа конечных пользователей, которые будут продолжать работать из дома и после окончания пандемии COVID-19.

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

В 85% ИТ-служб полагают, что пандемия навсегда увеличила базу пользователей, работающих из дома. К сожалению, только 31% групп, занимающихся сетевыми операциями, поддерживают расширяющуюся удаленную рабочую силу. Три основные проблемы, с которыми им приходится сталкиваться при попытках мониторинга и устранения неисправностей в домашних офисах связаны с недостатком финансирования (24%), сложностью инфраструктуры (24%) и слабым руководством со стороны ИТ-службы (22%).

Выделить бюджет на внедрение принципов NetOps

73% участников исследования уже выделили средства на устранение недостатков средств сетевого мониторинга и диагностики неисправностей. Еще 23% рассчитывают получить соответствующий бюджет после 2021 года.

Как будет потрачен этот бюджет? Вопрос многогранный. 64% выделяют средства собственным специалистами на разработку новых инструментов. 63% закупают новые средства у прежних поставщиков, вместе с тем, 57% планируют приобретать их и у новых.

Провести ревизию требований к управлению сетями при работе из дома

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

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

49% нужно увеличить масштабируемость своих инструментов. Выясняется, что данные собираются из большего количества источников, что отражается на производительности существующих инструментов. Например, до пандемии сетевой администратор мог контролировать 30 маршрутизаторов в 30 филиалах. Исследование EMA показало, что сегодня 75% организаций используют сетевое оборудование и в домашних офисах. Особенно это касается устройств сетевой безопасности и точек доступа Wi-Fi. Таким образом, в дополнение к уже упомянутым 30 маршрутизаторам в филиалах инструмент мониторинга должен будет поддерживать еще 500 сетевых устройств в 500 домашних офисах. Это может потребовать модернизации оборудования и получения дополнительных лицензий в соответствии с растущим числом управляемых сетевых элементов.

Улучшить интеграцию инструментов мониторинга с другими системами

Администраторам сетей нужно интегрировать свои инструменты с другими системами, с тем чтобы улучшить поддержку сотрудников, работающих на дому. 43% опрошенных заявили, что ужесточение требований к мониторингу домашних офисов заставляют их интегрировать инструменты мониторинга с решениями SD-WAN или SASE (secure access service edge). 33% респондентов указывают на необходимость расширенной интеграции со службой поддержки или с системами управления сервисами, что должно ускорить реакцию специалистов по сетевым технологиям на жалобы со стороны удаленных работников.

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

Инвестировать прямо сейчас

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

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

Возможно, этот вопрос покажется странным, но он действительно важен. Наряду с изменением характера использования приложений, облако изменило и типы затрат на их эксплуатацию.

Разные цвета денег

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

Капитальные затраты

Под капитальными затратами (Capital Expenditure, CapEx) обычно понимается покупка физического актива, который, как ожидается, будет использоваться в течение по крайней мере одного года.

Для производственной компании это может быть производственное оборудование. Для других – компьютерное или сетевое оборудование. Сюда можно отнести покупку транспортных средств, зданий или недвижимости.

Для капитальных затрат характерен ряд особенностей.

— Актив стоит относительно дорого. Обычно это одноразовая закупка (но одноразовая закупка может быть сделана в рассрочку).

— Приобретенный актив будет использоваться в течение длительного срока, как правило, несколько лет.

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

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

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

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

Довольно часто для оплаты капитальных затрат компаниям приходится занимать деньги. С учетом длительного срока использования покупки одолжить деньги, как правило, несложно, особенно если приобретение может быть использовано в качестве залога по кредиту, как это происходит с недвижимостью.

Постоянные затраты

Постоянные затраты (fixed-cost expenditure) – это покупка товара или услуги, которые потребляются предприятием за короткий период времени, не превышающий одного года. Постоянные затраты предусматривают короткий период использования или приобретение каких-то расходных материалов.

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

Другим примером являются приобретаемые услуги, в том числе услуги по уборке офиса. Коммунальные услуги – электроэнергия и вывоз мусора – также относятся к таким затратам. В области программного обеспечения это применимо к оплате за SaaS-сервисы.

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

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

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

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

Себестоимость реализованной продукции

Последним типом затрат являются затраты на себестоимость проданной продукции (cost of goods sold, COGS). Себестоимость может быть непосредственно связана с покупкой товаров или услуг.

Показатели COGS растут при увеличении продаж и снижаются, когда продажи падают. Если ваша компания создает какой-то продукт, стоимость материалов и труда, затраченного на его изготовление, относится именно к COGS.

Рассмотрим компанию, которая продает какие-то изделия. Для того чтобы продать изделие, его сначала нужно произвести. Расходы, связанные с покупкой деталей, из которых состоит изделие, выплаты работникам, осуществляющим его сборку, упаковку и доставку, относятся к категории COGS. Все это затраты на обеспечение продажи конкретного, отдельно взятого экземпляра конкретного товара.

Расходы на себестоимость обычно находятся в прямой зависимости от объема получаемой выручки.

С учетом тесной связи с доходами затраты на себестоимость отслеживаются по-разному. Затраты на себестоимость за месяц в абсолютном выражении обычно не так важны, как постоянные или капитальные затраты. Увеличение расходов на COGS в отдельно взятый месяц обычно считается положительным фактором, поскольку является, как правило, признаком роста продаж.

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

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

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

ЦОДы и облака

Когда компания принимает решение построить локальный ЦОД, растут ее капитальные затраты на закупку оборудования для этого ЦОДа. Много денег приходится выделять и на постоянные затраты, которые призваны покрыть расходы, связанные со строительством ЦОДа и оплатой коммунальных услуг в ходе его эксплуатации.

Получить кредит на капитальные и постоянные расходы обычно сложнее, поскольку они непосредственно не связаны с доходами – обычно сначала вы строите ЦОД и только потом получаете какую-то выручку. Нужно быть готовым обрабатывать дополнительный трафик для приложения еще до поступления доходов от продаж. Организация ЦОДа – у себя или даже у хостинг-провайдера – требует существенных предварительных капитальных и постоянных затрат.

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

При большом объеме трафика вы выделяете в облаке серверы для его обработки. При снижении трафика серверы освобождаются. То же самое относится к средствам хранения и сетевым ресурсам. Когда вы их используете, вы платите за них. Если они вам не нужны, вы за них не платите.

Затраты на облако непосредственно связаны с выделяемыми вам ресурсами, а следовательно, с вещами, которые генерируют доход – трафик, данные, сетевые компоненты. При росте продаж затраты растут, по мере снижения продаж снижаются и затраты.

Большая часть затрат на строительство облачного ЦОДа считается переменными расходами, которые относятся к категории COGS.

***

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

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

Цвет денег, которые вы тратите, очень важен для вашего облачного опыта.

Исследование рынка, проведенное компанией Enterprise Management Associates, показало, что специалисты, отвечающие в компаниях за сетевую инфраструктуру и операции, признают ценность применения AIOps при организации управления сетью.

Использование искусственного интеллекта в ИТ-операциях (Artificial Intelligence for IT Operations, AIOps) – развивающийся класс технологий, который объединяет машинное обучение, большие данные и другие виды продвинутой аналитики для автоматизации процессов управления ИТ. По сути, AIOps сопоставляет и анализирует различные наборы данных об ИТ-операциях, выявляет закономерности, делает на основании этих закономерностей определенные выводы и предоставляет соответствующую информацию персоналу ИТ-службы.

Недавно EMA опубликовала отчет «Революционные перемены в управлении сетью с помощью AIOps» ('Revolutionizing Network Management with AIOps'). Результаты проведенного опроса показали: 90% специалистов по компьютерным сетям убеждены в том, что использование AIOps при организации управления сетью может привести к улучшению бизнес-результатов предприятия в целом. Люди, решившие выйти за рамки этапа исследований, чтобы получить практический опыт работы с AIOps, оценивают потенциальные преимущества с наибольшим энтузиазмом.

Другими словами, управление сетью на основе AIOps способно улучшить ведение бизнеса. Проявлением этого становятся повышение производительности труда, улучшение клиентского восприятия и получение дополнительных доходов. Но каким образом AIOps придает дополнительный импульс развитию бизнеса?

Преимущества AIOps при организации управления сетью

В EMA попросили участников опроса перечислить потенциальные преимущества использования AIOps при организации управления сетью, которые они считают наиболее важными для своей ИТ-службы. В первую очередь специалисты по сетевой инфраструктуре и операциям отметили следующее:

— оптимизация сети;

— операционная эффективность;

— повышение уровня безопасности и соблюдение нормативных требований.

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

Оптимизация существующих инструментов управления сетью

В EMA поинтересовались, связан ли интерес специалистов по сетям к AIOps с недостатками существующих инструментов управления сетью. Выяснилось, что 91% опрошенных надеются устранить имеющиеся недостатки инструментов с помощью AIOps. Чаще всего при этом назывались следующие возможности:

— устранение противоречий и неточностей в данных;

— компенсация нехватки информации в реальном времени;

— устранение фрагментации инструментов за счет сопоставления информации, поступающей из разных источников.

Лучше всего это описал сетевой архитектор фармацевтической компании, оцениваемой в 40 млрд долл.: «Сегодня у нас имеется очень много инструментов и различных графических интерфейсов, причем каждый инструмент делает что-то одно. Весьма полезной была бы возможность объединения на базе искусственного интеллекта решений каждого конкретного поставщика с другими инструментами. Поэтому поставщикам нужно искать способы консолидации своих панелей управления с другими инструментами путем приобретений, информационного обмена или совместного использования данных».

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

В мире управления ИТ-системами AIOps относится к числу областей, которые пока находятся на ранней стадии своего развития, но в EMA убеждены, что она уже обладает немалой ценностью. Специалистам по сетям необходимо искать возможности повышения эффективности операций с помощью функционала AIOps. Большинство поставщиков сетевой инфраструктуры и средств управления сетями уже предлагают сегодня в своих продуктах какие-то функции AIOps. А покупателям нужно интересоваться у поставщиков их планами в отношении развития инструментария AIOps.

Более 80% компаний начинают разговор с интегратором или поставщиком услуг с того, что им надо провести цифровую трансформацию, вписаться в общий тренд. При этом, как ни странно, чаще всего речь вообще не идет о том, какие задачи стоят перед бизнесом, каких результатов необходимо добиться и как измерять эффективность проекта. Неудивительно, что при такой постановке вопроса исполнитель не готов отвечать за результат. В противном случае он должен был бы стать полноценным консультантом, но заказчик не готов за это платить. Сам же потенциальный клиент, пока живет в категориях «обеспечить», попросту не понимает, на что он должен тратить деньги.

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

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

Когда не хватает экспертизы

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

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

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

Что делать? Вариантов немного. Что-то создать своими силами не получится: здесь двумя-тремя сотрудниками не обойдешься – в серьезном проекте нужно больше десятка ролей: владелец продукта и менеджер проекта, бизнес- и системный аналитики, архитектор, тимлид, разработчики, внедренцы, техподдержка и пр. Другой вариант – раздробить сложную задачу на конкретные блоки и постепенно отдавать каждый из них на аутсорсинг. Получится, скорее всего, плохо: при таком подходе невозможен единый центр ответственности, временная шкала размывается, а руководитель бизнеса попадает в зависимость и от персонала, и от ряда сторонних разработчиков, при том, что каждый из них работает «индивидуально, уникально, и поэтому дорого».

В стабильной ситуации и при неограниченных ресурсах все это могло бы быть допустимо. А результат здесь мог бы гарантировать хороший системный интегратор. Но сегодня и в нашей стране, и во всем мире, мы видим совершенно иной тренд: ресурсы нужно оптимизировать, а на выходе должен быть еще более качественный проект, причем сделать его надо быстро. Это непростая ситуация, ведь мы опять можем попасть в 90-е годы, где властвовала «лоскутная» информатизация.

Стив Джобс говорил, что компаний, которые способны делать мир лучше, в мире не более 100. За последние 20 лет российский рынок, несмотря на все сложности, совершил немыслимый скачок: наши ИТ-разработчики, внедренцы, интеграторы, стартапы уже являются неотъемлемой частью мирового ИТ-сообщества, причем на уровне реальных проектов. А вот отечественный бизнес отстает. Значит, чтобы не плестись в хвосте, и чтобы наша экономика действительно заработала, нужно, чтобы на рынке были четкие механизмы решения бизнес-задач и компании, способные эти механизмы применять в конкретных проектах. При этом последние должны нести реальную ответственность.

Больше, чем аутсорсинг

В последние годы многие российские ИТ-компании пытаются переосмыслить понятие аутсорсинга. Лучшие из них давно разработали гибкие системы реализации и финансирования подобных проектов, научились работать по схеме SLA, управляют аккаунтом на уровне руководителей проекта, ресурсных менеджеров, рабочих групп и т.д. Но могут ли они дать результат, который ждет от них бизнес, причем быстро и качественно? Немногие. И, тем не менее, технологии и инструментарий для этого есть. Более того, он уже оформлен в совершенно конкретную услугу, получившую на российском рынке название «Внешний ИТ-отдел». По сути, воспользовавшись такой услугой, любое предприятие может получить предметные ответы на четыре ключевых вопроса: какие стратегические задачи бизнес может решить с помощью ИТ, какие технологии для этого необходимы, как и кто их внедрит на предприятии, и кто несет за это ответственность.

Услуга, которую поставляют сегодня пусть немногие, но высокопрофессиональные ИТ-команды, объединяет лучшие возможности консалтинга, качественного аутсорсинга и собственного корпоративного ИТ-департамента. Такое сочетание позволяет предприятию получить доступ к любым специализациям, квалификациям и компетенциям за счет внешних человеческих ресурсов. И это происходит в нужное время, в нужном количестве и без необходимости оплачивать простои, избыточный штат, резервирование специалистов. Следует обратить внимание, что в отличие от привлечения обычной аутсорсинговой команды, внешний ИТ-департамент всегда структурно и организационно близок к обычному внутреннему подразделению: он так же управляется, так же предоставляет отчетность, так же радеет за результат. Однако ответственность его несопоставимо выше, и эти гарантии должны закрепляться в юридических документах. Не менее важно, что при всех этих требованиях внешний ИТ-департамент (естественно, совместно с бизнес-подразделениями и топ-менеджментом компании) выступает полноценным и полноправным участником постановки задачи. Он глубоко погружен как в проблематику конкретного бизнеса заказчика, так и имеет возможность распоряжаться самым широким стеком технологий, чего, как правило, не может позволить себе небольшой «штатный» отдел ИТ.

И, пожалуй, самое важное. На деле, реализация проектов с помощью услуги «Внешний ИТ-отдел» не может не подкрепляться гарантиями об уровне обслуживания (SLA). Обычно такие гарантии выдаются заказчику по окончании проекта, когда весь комплекс неизбежных недоделок исполнитель берется устранить своими силами и за свой счет. Казалось бы, это хорошо, но при таком подходе все теряют время и деньги, а результат уходит куда-то за горизонт. Едва ли современный бизнес может себе это позволить.

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

Было бы преувеличением сказать, что разбивка на малые этапы и гарантированное их исполнение возникли именно в России. И все же, именно в нашей стране потребность современных предприятий оформилась в наиболее прогрессивные форматы взаимоотношений заказчика и исполнителя. И у нас научились применять эту схему для достижения оптимального результата. Бизнес же, в свою очередь, практически готов к тому, чтобы воспользоваться этой возможностью – либо в полном объеме, либо на уровне первых «пилотов». Воспользуемся ли мы ее плодами уже сегодня или опять будем ждать – зависит только от нас.

Автор — Кирилл Владимиров, генеральный директор компании ONLY

Запустить цифровую трансформацию не так легко, как кажется поначалу. Как определить, готова ли к этому ваша организация? На какой ступени «лестницы цифровой зрелости» стоит она, а на какой — ее конкуренты? О популярных методиках оценки цифровой зрелости компании расскажет Марианна Данилина, эксперт с многолетним стажем трансформационных практик в финансовой сфере. Ее выступление состоится 2 июня на форуме [it]MF 2021 издательства «Открытые системы». В преддверии форума Марианна согласилась ответить на несколько вопросов о целях использования таких методик и о том, что мешает российским компаниям повышать уровень цифровой зрелости.

- Как становятся специалистами в области цифровой трансформации? Расскажите немного о вашем профессиональном пути.

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

Все это помогло достичь понимания того, что нужно сделать организации, чтобы измениться. Цифровая трансформация — в большей степени касается не ИТ, а практик управления. Тенденции трансформации компаний начали появляться более 10 лет назад и включали в себя изменение бизнес- и операционных моделей. Начиная с 2016 года практики трансформации организаций стали фокусироваться на цифровизации и пришла мода на диджитал. Между тем очень многие технологии, которые сейчас подразумеваются под цифровой трансформацией, и средства «малой автоматизации» существовали задолго до этого. Например, скрипты использовались и до популярной ныне роботизации процессов. Но, благодаря развитию технологий и подходу low-code, теперь для их использования не обязательно быть программистом: сегодня бизнес-пользователи могут настраивать ИТ-инструменты самостоятельно. Соединяя цифровые технологии и людей, компании могут разрабатывать инновационные услуги и продукты, доступа к которым раньше не существовало.

- Что вас больше всего интересует на сегодняшний день в профессиональном плане?

Интересен опыт больших радикальных изменений в организации. Хочется применить свой опыт и знания, чтобы определить, как сбалансировать настоящее, обеспечивающее существование текущей бизнес-модели, и труднопредсказуемое желаемое будущее. Если совсем просто, change — это зона изменений, улучшения, нового. Run — регулярное, повторяющееся, имеющее цикличность. Мне нравятся «сhange-проекты», которые приносят изменения, развитие. Собственно, ими я и занимаюсь.

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

- Насколько такие проекты окупаются? В какой степени это интересная «игрушка» и в какой — реальный бизнес-инструмент, помогающий зарабатывать?

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

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

Я бы советовала оценивать применимость инновационного решения для компании не просто сквозь призму коммерческой выгоды, но и с учетом косвенных преимуществ. Бывает так, что для компании важна не только экономическая эффективность, но и другие моменты. Например, есть имиджевые проекты, когда внедрение технологии не несет значительного экономического смысла. Однако для компании важно сделать proof-of-concept, чтобы понять, как дальше работать с этой технологией или сформировать повестку для будущих стратегических изменений.

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

- С одной стороны, компании вкладывают ресурсы в изучение нюансов клиентского опыта, а с другой — роботизируют процессы поддержки клиентов, минимизируя возможности живого общения. Нет ли в этом противоречия, на ваш взгляд?

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

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

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

- В чем заключается ценность методик оценки цифровой зрелости? Зачем они нужны?

Такая оценка необходима прежде всего традиционному бизнесу, компаниям реального сектора. Прежде чем затевать цифровые перемены, они должны понять, зачем им это нужно. Чтобы подготовить фундамент будущих изменений, для начала нужно ответить на ряд базовых вопросов. Какие цели ставит перед собой компания с точки зрения цифрового будущего? Где компания находится сейчас и насколько готова к изменениям? Что именно нужно менять, чтобы получить эффект от цифровизации?

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

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

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

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

Более того, в России на государственном уровне запущены процессы цифровизации компаний. Министерство цифрового развития осенью 2020 года опубликовало «Методические рекомендации по цифровой трансформации государственных корпораций и компаний с государственным участием», в которых тоже рекомендуется оценивать уровень цифровой зрелости и на его основе определять цели цифрового развития компаний.

- На чем основаны эти методики? Откуда они выросли и насколько применимы?

Большинство методик оценки зрелости были разработаны консалтинговыми компаниями. Если говорить о цифровизации, то одной из первых методик оценки цифровой зрелости был «Индекс зрелости Индустрии 4.0.», разработанный компанией Acatech в 2011 году специально для программы трансформации немецкой экономики, так называемой Индустрии 4.0.

Сегодня методологий и фреймворков для оценки цифровой зрелости компании существует огромное количество.

Методики эти довольно субъективны. Все они (плюс-минус) сосредоточены вокруг оценки направлений работы компании, которые составляют ее бизнес-модель.

Можно воспользоваться любой методикой, если она есть в открытом доступе, — например методикой компании Cisco («Цифровое пианино»). А можно применить подход к оценке зрелости компании Arthur D.Little («Индекс цифровой трансформации») либо использовать фреймворки компаний «большой четверки». Также можно адаптировать или разработать собственный подход к определению готовности к цифровым изменениям, взяв за основу собственную шкалу оценки, исходя из направлений, важных для конкретной компании.

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

- Каков уровень цифровой зрелости российских компаний в разных отраслях?

Оценить готовность компаний в России можно только очень условно. Все попытки установить индекс цифровизации различных индустрий носят сугубо субъективный характер. Чтобы ответить на вопрос, могу сослаться на исследования компаний «большой четверки». Например, исследования КПМГ «Цифровые технологии в российских компаниях» и «Исследование по цифровизации и инновационной открытости российских предприятий», куда вошли результаты опросов крупнейших российских компаний. В 2019–2020 годах самыми зрелыми с точки зрения уже проведенных трансформаций и внедренных цифровых инструментов считались телекоммуникационные компании и компании металлургического сектора. Наиболее опробованные технологии — инструменты анализа больших данных, роботы, чат-боты и оптическое распознавание. Можно сказать, что к цифровизации лучше готовы компании финансового сектора (у них накоплено огромное количество клиентских данных) и нефтегазовые компании (у них больше возможностей в силу доступности инвестиций).

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

- Каковы основные препятствия на пути повышения цифровой зрелости российских компаний?

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

Главные подводные камни — отсутствие готовности к изменениям и незрелость бизнес-процессов. Низкий уровень зрелости текущих процессов и отсутствие необходимой инфраструктуры могут значительно усложнить путь к цифровым изменениям.

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

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

- Что полезного для своей практической деятельности смогут вынести слушатели из вашего выступления на форуме [it]MF 2021?

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

Вынужденный стресс-тест, который прошли в этом году ИТ-системы всех организаций, показал, что без реальных изменений в ИТ-службах цифровая трансформация рискует остаться абстракцией. Не случайно одна из основных сессий ежегодного форума IT Management Forum, организованного издательством «Открытые системы», была целиком посвящена практике трансформации управления сервисами в цифровой организации. (Подробнее о форуме читайте в статьях «ITMF 2020: Цифровая трансформация ИТ становится актуальной тенденцией» и «Культурное сближение: без чего невозможна трансформация».)

«Удаленка» остается

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

Наталья Погорелова-Триппель: «Удаленная работа уже никуда не денется»

Переводя сотрудников на удаленную работу, в «Банке Зенит» в первую очередь начали упрощать интерфейсы системы документооборота, оптимизировать процессы и повышать производительность. При этом фокус сместился на офисные приложения, которые раньше мало использовались. Так, деловые коммуникации сконцентрировались на платформе Microsoft Teams и в корпоративной соцсети Yammer. Также в практику ввели онлайн-обучение работе с самыми востребованными банковскими приложениями. Кроме того, пришлось уделить особое внимание отчетности, поскольку при дистанционной работе резко возросла важность контроля деятельности сотрудников.

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

Минимальное общение

Первым опытом трансформации работы ИТ-поддержки и ее результатами поделились сотрудники «Лаборатории Касперского». Они рассказали о внедрении порталов самообслуживания, новых каналов обращений в поддержку, вендоматов, а также об интеграции системы мониторинга и системы заявок.

Заготовка простых форм для сбора первичной информации от пользователей IT Service Desk позволила сэкономить две ставки в ИТ-поддержке и вдвое сократить время ожидания выполнения заявок. Посредством интеграции системы мониторинга и ITSM-системы были автоматизированы рутинные действия дежурного системного администратора, благодаря чему среднее время первичной обработки запросов уменьшилось в два раза еще на этапе пилотирования проекта.

В службе ИТ-поддержки компании заняты 80 сотрудников, которые обрабатывают 2,5 тыс. запросов и и более 7 тыс. инцидентов в неделю.

«Пользователи хотят двух вещей: иметь большую красную кнопку 'Сделать' и ограничить время общения с сотрудниками техподдержки», — отметил Денис Волошин, руководитель отдела экспертной ИТ-поддержки «Лаборатории».

Движение к этой мечте происходит сразу по нескольким направлениям. Пользователям предоставили инструмент, позволяющий им самостоятельно разрешать часть простых инцидентов за 10–15 мин. Раньше время на регистрацию запросов и ожидание в очереди достигало 3 часов. Два вендомата выдают пользователям около 1,5 тыс. устройств в месяц — это более 70% всей мелкой техники и аксессуаров, выдаваемых службой поддержки.

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

Максимальная скорость

Максимальная cкорость — приоритет в реализации проекта внедрения ITSM-системы, который сегодня близится к завершению в Государственной транспортной лизинговой компании.

«Быстро и с минимальными затратами внедрить продукт — вот что для нас было важнее всего», — сообщил Антон Жиряк, начальник управления автоматизированных информационных систем ДИТ ГТЛК.

Поскольку быстро кастомизировать предлагаемые на рынке решения невозможно, в компании искали отечественное коробочное решение, в котором уже реализован необходимый процессный подход, а также вендора с максимальным уровнем поддержки и экспертизы. В итоге выбор остановили на Naumen Service Desk Pro.

«Мы хотели использовать лучшие практики, а не пытаться сконфигурировать коробочное решение под себя», — пояснил Жиряк. Вместо долгого проектирования решения в компании сконцентрировались на приобретении навыков самостоятельной работы с ним и теперь уже могут настраивать процессы без привлечения подрядчика. Важным компонентом внедрения стало внутреннее обучение. Сотрудники ДИТ даже задерживались для этого после работы, понимая что внедрение системы позволит им в дальнейшем решать задачи намного быстрее, чем сейчас. Внедрение системы поддержки для 430 получателей ИТ-услуг заняло три месяца, причем половина этого срока была отведена опытной эксплуатации. В результате удалось минимизировать затраты времени сотрудников ДИТ.

«Несмотря на то что проект еще не завершен, уже сейчас мы видим ускорение обработки заявок за сутки», — отметил Жиряк.

Данные для трансформации

«Самое ценное в компании — ее данные, и эту ценность необходимо защищать», — напомнил Ингус Хомка, ведущий архитектор ИКТ-решений компании Tet. Ведь взломать можно любую систему, имея мотивацию и деньги.

«Количество атак стабильно растет каждый год, и свыше 90% из них направлены на финансово-банковские структуры, провайдеров разного рода интернет-сервисов и страховщиков. Между тем более половины компаний не имеют стратегии восстановления своих ИТ-систем после сбоев. Это страшные цифры», — отметил Хомка. И даже те, кто заинтересован в появлении такой стратегии, зачастую не хотят платить за ее реализацию.

Максим Афонасьев: «Трансформация бизнеса невозможна без трансформации ИТ-подразделения»

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

«Назначение нашей системы 'СДИ Базис' — предоставить удобные интерфейсы для прозрачного документирования технической информации, чтобы соответствующие службы могли централизованно получать достоверные данные об инфраструктуре в своей зоне ответственности и на стыках с соседями», — сообщил Довгань.

«Давайте честно признаемся: реальных примеров трансформации бизнеса не так много, — заявил Максим Афонасьев, директор по развитию Axus Group. — Такая трансформация невозможна без трансформации ИТ-подразделения».

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

Аренда вычислительных ресурсов часто считается синонимом экономии на ИТ, причем это подается как непреложная истина. Отчасти это правда: например, если речь идет о сокращении или отказе от капитальных затрат. Но капитальные затраты (CAPEX) – лишь один из параметров экономики коммерческих ЦОДов. Помимо него, существуют множество других факторов, влияющие на итоговую стоимость услуг. Стоит изучить чуть глубже этот вопрос, и мы видим, что аренда мощностей подходит лишь определенной части заказчиков, но далеко не всем из них. Давайте разбираться.

Размер имеет значение

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

Вывод: ориентируйтесь в первую очередь на параметр совокупной стоимости владения (TCO) и стратегию бизнеса.

Сочетание технологий

С облачными ресурсами ситуация тоже не всегда очевидна. При грамотном подходе можно и в самом деле сэкономить до 30-40% затрат на ИТ. Один из классических примеров – кейс крупного ретейлера бытовой техники: за год компания экономит порядка 20 млн руб. Секрет успеха – грамотное сочетание различных технологий: публичного облака и выделенного оборудования в коммерческом дата-центре. Использование лишь чего-то одного не привело бы к таким впечатляющим результатам. Дело в том, что каждая из указанных схем заточена под конкретную модель потребления. Если системы заказчика работают преимущественно ровно, без скачков нагрузки, их стоит размещать на физическом оборудовании. Если динамика потребления рваная, с непредсказуемыми пиками – лучшим выбором станет облако. Наконец, если в целом можно спрогнозировать изменение профиля нагрузки, что часто бывает у ретейлеров во время проведения акций и «черных пятниц» – гибридная модель подойдет как нельзя лучше.

Вывод: анализируйте реальную нагрузку на ИТ и выбирайте соответствующие типы вычислительных ресурсов.

Тяжелое наследие

Многие компании очень не любят расставаться со старым оборудованием. Примечательно, что это могут быть достаточно крупные организации, которые имеют средства для апгрейда инфраструктуры. По нашей оценке, фактически в любой компании, давно работающей на рынке, есть как минимум несколько аппаратных систем возрастом от 10 лет. Один такой заказчик – российский коммерческий банк – решил поставить архивное «железо» в ЦОД, чтобы проводить на нем различные тестирования. По предварительному расчету для размещения 40 стоек должно было потребоваться 300 кВт/ч в месяц, и набегала весьма круглая сумма за обслуживание. Вместо этого для решения бизнес-задачи было предложено использовать современное оборудование. Ту же мощность удалось уместить в 1,5 блейд-корзины за счет высокоплотной упаковки современных версий аппаратного обеспечения, то есть в меньшую сумму удалось «упаковать» еще и стоимость нового оборудования взамен старого. Результат – сокращение стоимости услуги и повышение качества и гибкости процесса тестирования.

Вывод: архивным системам место в музее, в реальной жизни выгоднее использовать новое оборудование.

Резервирование окупается

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

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

Вывод: на резервировании нельзя экономить, и стоит привлечь грамотных архитекторов к созданию инфраструктуры.

Аутсорсинг оправдан

Многие компании обращаются к коммерческим ЦОДам и облаку, чтобы снять с себя задачу администрирования оборудования. Обычно у них два мотива: первый – нет желания тратить ресурсы на рутинные процессы, второй – недостаточная загрузка на проекте собственных сисадминов. Бывает, что сотрудники тратят всего лишь 5-10% своего времени на поддержку систем во внешнем ЦОДе, но зарплату им работодатель перечисляет в полном объеме. Поэтому привлечение сотрудников провайдера чаще оказывается выгоднее, даже если в качестве инженеров у поставщика услуги работают более высокооплачиваемые специалисты, чем в штате у заказчика. Более того, многие провайдеры автоматизируют клиентские запросы, такие как настройка инфраструктуры, мониторинг и т.д. В выигрыше оказываются все: владелец ЦОДа снижает свои трудозатраты, а вместе с тем уменьшается и стоимость услуги для клиента.

Вывод: аутсорсинг – это в первую очередь про упрощение администрирования собственными силами.

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

Автор – Павел Колмычек, операционный директор «КРОК Облачные сервисы», PKolmychek@croc.ru