После 2022 года, когда компании начали массово выделять ИТ в отдельные юрлица и продавать сервисы внутри группы, тема «каталога» из теоретической превратилась в прикладную. Формализованный перечень услуг, SLA, прозрачная стоимость — все это стало частью взросления ИТ-функции. Этому был посвящен онлайн-круглый стол клуба «ИТ-Диалог» и IT-World, который модерировал Иван Козлов (ГК «Латео»). ИТ-директора обсуждали, как они сами оформляют эту роль внутреннего провайдера и где у подхода «ИТ как продукт» начинаются ограничения.
Каталог услуг. Сколько позиций выдержит бизнес?
В реальности первый шаг начинается не с красивой витрины, а с инвентаризации. В практике Сергея Анциферова ИТ-блок обслуживает сразу четыре завода, включая площадку «Энгельс. Свечи зажигания». Новый руководитель пришел туда в момент, когда ИТ уже работало для нескольких юрлиц, но формальных границ не было. Пришлось буквально с нуля описывать, что команда вообще в состоянии оказывать: какие сервисы, в каком объеме, с какими SLA и какой пропускной способностью. Именно так выстраивался каталог и отдельные листы по каждому SLA.
Поверх этого описания начали считать экономику. Речь не о заработке на своих заводах, а о прозрачности: по каждому сервису фиксируется, сколько времени и ресурсов уходит на его поддержку. Вся операционка проходит через сервис-деск на базе open-source-решения GLPI, к нему подключена BI-аналитика, и на дашбордах заказчики видят, сколько услуг фактически потребили и как это соотносится с заявленным уровнем сервиса. По сути, это внутренний прайс, который позволяет разговаривать с бизнесом на понятном языке.
В другой компании перечень разросся примерно до 600 услуг и живет сразу на двух уровнях. Сверху — бизнес-витрина: что это за услуга, зачем она нужна, куда идти, как ее заказать. Внизу — технический уровень для специалистов. Такой каталог не просто лежит в папке: его регулярно дорабатывают, добавляют себестоимость, TCO и другие параметры. Документ легко «тюнить до посинения», как иронизирует Евгений Капустин (ГМК «Норильский Никель»), но именно так получается максимально формализованный контракт между ИТ и бизнесом.
Часть CIO, напротив, сознательно ограничивает детализацию. В одной из практик для бизнеса выделено всего 35–40 сервисов — и этого уже достаточно, чтобы у пользователей возникал вопрос: куда отнести конкретную заявку. Все, что сложнее, прячется внутри ИТ: команда сама разносит обращения по внутренним классам. Такой подход, например, работает в «СМ-Клинике».
Есть и еще более минималистичная модель. В компании, где отвечает за ИТ Евгений Титов («Завод Продмаш»), формального документа «Каталог услуг» нет, и задача его создать в жестком виде пока не ставится. На верхнем уровне существуют договоренности о реакции на критические инциденты и понятные правила взаимодействия с бизнесом. Для внутреннего же учета используется классификация примерно на 20–25 тематик заявок. Этого достаточно, чтобы вести статистику и по запросу показывать аналитику, при этом не «кошмаря» пользователей сложным интерфейсом, где сначала нужно угадать правильный код услуги.
Где заканчивается сервис и начинается проект
Как только разговор переходит от «лужения принтеров» к развитию, сервисная модель начинает буксовать. На примере R&D это особенно заметно. Запрос «сделать чат-бота» формально можно повесить в каталог как услугу, но два таких бота по трудоемкости и срокам могут отличаться в разы. Это уже не типовой инцидент с предсказуемым временем реакции, а полноценный проект. Именно такие «плавающие» по объему услуги вызывают наибольший интерес у ИТ-директоров, признается Андрей Власенко (УК «Старт»): формально строка в каталоге есть, но ожидания заказчика и реальная цена сильно зависят от нюансов.
Есть и другой подход, в котором спорные запросы не пытаются подогнать под классификатор услуг. В «СМ-Клинике», по словам Константин Кутырло, для этого существует отдельный поток «заявок на изменения». Заказчик описывает не техническое решение, а проблему и желаемый результат: «хочу, чтобы чат-бот отвечал за меня на такие-то вопросы» или просто «надо решить вот эту боль». Дальше уже ИТ-команда определяет, в какой системе и какими средствами это реализовать. Все подобные изменения собираются в единый поток и проходят через общий процесс оценки, приоритизации и реализации. Тот же GLPI используется не только для ИТ, но и для других функций внутри компании, что позволяет держать единый реестр изменений.
На «Завод Продмаш» сложные запросы обрабатываются схожим образом, но без жестко оформленного каталога. Если речь идет об изменениях или новом функционале, команда сначала собирает всю информацию, оценивает трудозатраты, а затем вместе с бизнесом договаривается о приоритетах: что делается в первую очередь, что во вторую, от чего придется отказаться, добавляет ИТ директор Евгений Титов. При ограниченных ресурсах это неизбежно: часть задач откладывается, часть теряет приоритет. Принципиально важно другое — эти решения принимаются открыто, а не прячутся за красивой, но оторванной от реальности витриной.
Сколько сервисов выдержит каталог и зачем их делить
Сергей ГоршенинПрактика показывает, что главное в каталоге — не только наличие, но и масштаб. «Нормальное количество сервисов — это где-то 60–80. Если дробить сильнее, пользователи начинают теряться в «витрине сервисов». Если, наоборот, все чрезмерно укрупнять, руководитель ИТ теряет управляемость: сложнее выделять проблемные зоны, считать экономику и формировать адресные KPI», — считает Сергей Горшенин, ИТ-эксперт. Ключ к балансу — в двухслойной структуре: бизнес-каталог и технический каталог. Технический каталог служит фундаментом: это внутренний список сервисов, на котором строится бизнес-каталог. Последний по-хорошему должен быть написан «другими словами» — на языке маркетинга и бизнеса, а не «конфигураций и программных модулей». Чем проще и яснее будут формулировки, тем легче внедрять каталог и тем меньше сопротивление со стороны пользователей. Разовые запросы и мелкие проектные задачи не стоит раздувать в отдельные пункты «витрины». Для них достаточно нескольких обобщенных сервисов — «корзин», в которые складываются однотипные обращения. Детализация уже происходит на внутреннем уровне, ровно настолько, насколько это нужно для управленческого учета. Логика простая: отдельный сервис появляется только там, где возникает запрос на управляемость отдельным процессов или функцией. «Как только у тебя появляется бизнесовый вопрос “а сколько это стоит?” — говорит он, — добро пожаловать в конкретный сервис». В некоторых компаниях каталог ИТ-услуг формально создан и закреплен в регламентах и SLA, но со временем перестает быть живым инструментом. Марина Михейчикова, директор по цифровой трансформации ГК «Благо», отмечает: «Мы формировали каталог в период реорганизации ИТ-подразделения, описали порядка ста услуг, утвердили их в регламенте — и после этого операционная работа пошла дальше сама по себе». Запросы пользователей по-прежнему поступают через Service Desk, где первая линия поддержки самостоятельно классифицирует их по категориям и перенаправляет исполнителям. Пользователи выбирают типы обращений так, как им удобно, без строгой привязки к формальному перечню услуг. На практике документ востребован в основном при спорных ситуациях, связанных со сроками выполнения заявок: именно тогда специалисты обращаются к SLA, чтобы определить, к какой категории инцидентов относится запрос и были ли соблюдены регламентные сроки обработки. Как разделение сервисов помогает финансам Вопрос разделения ИТ-сервисов становится особенно чувствительным, когда речь заходит о развитии и бюджетировании. В одном из проектов, который описывает Сергей Горшенин, пользователей сначала даже не просили выбирать сервис при обращении в техподдержку: для них это было слишком сложно. Первые 6–7 месяцев классификацией занималась первая линия поддержки, вручную разнося обращения по нужным сервисам. Это требовало усилий, но позволило накопить корректную основу для аналитики и бюджетирования. Затем сервисы релевантно промапили на статьи ИТ-бюджета. Результат, по словам эксперта, оказался показательным: «Если сделать очень четкое мапирование сервисов и статей бюджета, то можно фактически 80% работы по обоснованию операционного бюджета переложить на статистику сервис-деска». Но как бы ни выстраивались бюджеты, лимиты часов и внутренние тарифы, без четкого каталога сервисов «а это очень большой пласт функций», ты не сделаешь от слова «совсем». Каталог остается тем самым базовым фундаментом, на котором держатся и SLA, и финансовые механизмы, и сама идея ИТ как внутреннего провайдера.
Константин Кутырло Управление изменениями в компаниях, где ИТ живет в режиме постоянного развития, оказывается не менее сложной задачей, чем поддержка. В «СМ-Клинике» развитие информационных систем вынесено в отдельные команды. Каждая такая команда одновременно тянет несколько пластов работы: сервисные запросы, которые, по сути, приходят из техподдержки как «третья линия», заявки на изменения разного масштаба и полноценные проекты. Время заранее делится между крупными инициативами, мелкими доработками, сопровождением и неизбежными «влетами», а затем фиксируется в ресурсном плане команды. Уже исходя из свободных слотов выбирается, какие заявки и проекты брать в работу и в какой последовательности. Планирование здесь двухуровневое. На год вперед формируется пул крупных проектов, по которым понятна целевая загрузка команд на 2026 год. Все, что мельче, живет в более коротком цикле: вместе с бизнесом регулярно проводятся сессии приоритизации. В одних командах они проходят раз в две недели, в других раз в месяц. На этих встречах представители заказчиков, которых бизнес специально выделяет для такой работы, выбирают, какие изменения пойдут в ближайший цикл, что подождет, а от каких задач можно отказаться совсем. Иван Козлов в какой-то момент заострил внимание на неизбежном конфликте интересов. Например, модель с лимитами часов по подразделениям хорошо дисциплинирует, но порождает другой эффект: каждый руководитель будет бороться за свои сто часов и доказывать, что «его» задачи важнее бухгалтерии или логистики. Возникает вопрос: кто выступает арбитром, который может сказать, какие инициативы приоритетны для компании, а какие можно отложить или вообще не делать. Отвечая на это, Константин Кутырло («СМ-Клиника») объяснил, что ИТ старается не брать на себя роль единственного судьи. Спорные решения выносятся на проектные комитеты — регулярные встречи с участием руководства холдинга, где обсуждаются приоритеты и расставляются акценты. Обычно до такой эскалации дело не доходит: большинство конфликтов удается снять на совместных рабочих сессиях, когда за одним столом собираются несколько заинтересованных подразделений. «Ресурсы у каждого подразделения конечны, — напомнил он, — Во-вторых, мы, как бизнес, все подразделения, идем к некоторой общей цели. И исходя из этого мы должны друг с другом договариваться». Проектный комитет в этой конструкции — инструмент, который помогает бизнесу брать на себя ответственность за выбор, а не перекладывать все на ИТ. Опасность «ручейка мелочей» участники тоже отдельно разобрали. Каждая доработка вроде галочки или автозагрузки контрагентов кажется невинной, но в потоке такие запросы легко забивают команду и вытесняют стратегические изменения. Здесь снова выручает каталог услуг с четко зафиксированными параметрами. Если заранее оговорены время реакции и окно на оценку, пользователю можно честно показать: сначала заявка попадает в обработку, потом в оценку и только затем — в очередь. Как ИТ делит capacity на изменения и где начинается «комитет» Когда разговор о сервисной модели доходит до заявок на изменения, на первый план выходят не только процессы, но и очень приземленный вопрос: кто и по каким правилам решает, что войдет в ближайший спринт, а что подождет. В одном из кейсов, о котором рассказывал Андрей Власенко (УК «Старт»), схема была почти как из учебника. Команда имела зафиксированное capacity на две недели, в общий бэклог стекались заявки на изменения — именно изменения, а не инциденты техподдержки. «Был бэклог, в который прилетали задачки, — вспоминает Андрей, — раз в две недели собирался комитет вместе с бизнесом... и посредством некоторых переговоров это все упаковывалось в двухнедельный спринт». Задач в таком спринте обычно было немного, порядка десяти–двадцати, поэтому обсуждение занимало полчаса-час и не превращалось в бесконечные споры.
Иван КозловОтдельный вопрос, который поднял модератор Иван Козлов, — кто вообще готов каждые две недели выделять на это время. Оказалось, что в том кейсе состав был вполне «тяжелый»: финансовый директор, генеральный, коммерческий директор, директор по логистике и сам директор по ИТ. Именно эта группа договорившихся людей и решала, чьи изменения попадут в спринт. Порог выноса на такой уровень тоже был очерчен, в бэклог для комитета обычно попадали задачи «от 10 часов и дальше», а все, что меньше, команда делала «на полуавтомате». Попытку считать «влияние на бизнес в рублях» как отдельную метрику в итоге признали слишком эмпирической и от нее отказались. В компании Сергея Анциферова управление изменениями закреплено прямо в регламенте технической поддержки, а приоритизация строится на трех критериях: требуется ли изменение по закону, остановится ли без него бизнес-процесс и есть ли ощутимый экономический эффект. «Если там три сразу, то наивысший приоритет, два — высокий, один — средний, если ни один из них — то низкий», — поясняет он. При этом небольшие доработки до десяти часов вообще не включаются в эту воронку: такие запросы просто выполняются без отдельной приоритизации, а матрица критериев применяется только к более крупным изменениям. В ГК «Благо» правила разграничения инициатив фиксируются заранее — на этапе годового бюджетного процесса. После утверждения бюджета компания работает в согласованных рамках, а пересмотр уровня принимаемых решений требуется только в тех случаях, когда новая инициатива выходит за пределы утвержденных лимитов или влияет на стратегические приоритеты. Для отделения операционного развития от проектной деятельности используется формализированный подход. Каждый запрос проходит оценку по четырем параметрам: сложность, новизна, срок реализации и бюджет. Итоговый коэффициент позволяет определить, относится ли инициатива к категории «проект». «Комбинация этих критериев дает нам понятный ответ — проект это или нет», — поясняет Марина Михейчикова. Финансовая модель и «третий путь» провайдерства Когда речь заходит о том, сколько ИТ на самом деле стоит бизнесу, на первый план выходит модель внутреннего провайдера с трансфертными ценами. Сергей Горшенин называет ее третьим путем: ИТ оказывает сколько угодно услуг, пока хватает ресурсов, а по итогам квартала «выставляет стоимость всех этих услуг соответствующим бизнес-подразделения». После этого, признается он, «со стороны бизнеса начинаются вопросы к руководителям бизнес-подразделений: ребят, а зачем вам в таком объеме айтишные услуги?». Любая «фишечка», например, кнопку перенести слева направо — это уже «пять часов разработчика», превращается в строку управленческого отчета и, как следствие, проходит управленческий фильтр.
Антон ВоронковАнтон Воронков («Красивый город») показывает, как по-разному это может работать. В крупном строительном холдинге, где он раньше работал, ИТ было выделено в отдельное юрлицо, и внутренние услуги реально покупались: счета, проводки, живые деньги. В нынешней производственной компании все организовано проще: письмо на определенный почтовый адрес автоматически превращается в заявку в 1С. И ранее все заявки распределялись на единственный сервис «Техподдержка». Сейчас в системе учета заявок заведены сервисы по различным услугам для приоритизации и на первой линии распределяются заявки в соответствии с типом запроса. А каталог услуг нужен прежде всего, «чтобы видеть срез, чем мы больше занимаемся, чем меньше», потому что «если не измеряешь, ты не можешь управлять». Жесткого деления на правильные и неправильные модели, по его словам, нет: «Если бизнесу подходит такой путь, значит, на данном этапе он оптимальный. Может быть, через год придет время трансформации, которая скажет: все, нельзя так жить и давайте по-другому. Роль ИТ-лидера в данном случае — оптимально управлять процессами с учетом вектора развития бизнеса и его актуальных потребностей». Во всех этих историях общее одно: прозрачные критерии и понятная финмодель переводят «хотелки» из эмоциональной плоскости в денежную, и тогда CIO легче выступать внутренним провайдером, а не «узким горлышком», которое якобы мешает бизнесу развиваться. Культура против регламентов После разговоров про каталоги, бюджеты и комитеты участники естественно вышли на тему, которая не прописана ни в одном регламенте, — культуру. Что происходит, когда формализованные SLA и каталоги сталкиваются с неписаными правилами, которые «висят в воздухе» и сильно влияют на то, как в компании обращаются с ИТ? Формальные документы сами по себе мало что дают: если управленческая зрелость низкая, регламенты остаются на бумаге. В одном из проектов, вспоминает Сергей Горшенин, команда сознательно начала не с жестких правил, а с привычки пользоваться сервис-деском: пользователям разрешили просто писать, что нужно сделать, без выбора сервиса, главное — «создать привычку в принципе использовать вот эту единую точку контакта», а классификацию заявок ИТ брало на себя. Параллельно шла «тихая работа в полях»: людям объясняли, что, если потратить минуту и выбрать нужный сервис, заявка уйдет в работу быстрее. Так, «по чуть-чуть, лавирующими движениями», формировалась информационная культура — сотрудники привыкали, что ИТ работает через систему, а не «по знакомству». При этом, подчеркивает он, «красной кнопочки нет»: за день или за полгода, когда новый ИТ-директор приходит с каталогом услуг, ничего не меняется. Это всегда долгосрочная стратегия, и в компаниях с низкой зрелостью ИТ хотя бы выстраивает базовый учет для себя, чтобы к моменту, когда «компания до этого дозреет», иметь историю в часах и фактах для разговора с руководством.
Евгений Капустин Сервисная модель, по наблюдениям Евгения Капустина (ГМК «Норильский никель»), рассыпается там, где лозунги заканчиваются и начинается рутина. В одном из прошлых проектов развернули общую ITSM-среду не только для ИТ, но и для юристов и бухгалтерии — формально победа, но на практике все ломалось в трех местах. Во-первых, ИТ по-прежнему воспринимали как обслуживающий персонал: без бизнес-спонсоров система запускается как проект, «становится мертвым грузом», который через несколько лет поддерживают ради одной «Марии Захаровны». Во-вторых, культура реагирования — «мы всегда гасим пожар, когда нас попросят», команда живет в режиме инцидентов и не успевает быть проактивной. В-третьих, фокус смещается на хайповые темы — «фокусируемся на каких-то новых технологиях… искусственный интеллект и так далее, а не на пользовательском опыте». В итоге на уровне слов сервисная модель есть, а на уровне поведения — нет. Опыт Марины Михейчиковой хорошо иллюстрирует, что культура взаимодействия с ИТ в офисе и на производственных площадках формируется по-разному. В управляющей компании сотрудники уже привыкли работать через Service Desk: любое обращение фиксируется в системе, и прямые звонки или «разговоры в коридоре» постепенно ушли в прошлое. На удаленных заводах ситуация была иной: по привычке сотрудники шли к местному ИТ-специалисту «просто попросить помочь» — от замены лампочки до настройки оборудования. Формальное включение локальных ИТ-команд в единый контур управляющей компании само по себе не изменило этот паттерн — потребовалась осознанная работа по изменению пользовательского поведения. Решение оказалось простым и прозрачным: вся поддержка стала привязана к официальным обращениям в Service Desk и учитывалась в KPI первой линии поддержки. Как только стало понятно, что помощь «неформально» не фиксируется в системе и, соответственно, не влияет на выполнение SLA и премирование сотрудников ИТ, поток запросов естественным образом переместился в Service Desk. Такой подход позволил выстроить единый порядок взаимодействия, обеспечить учет всех обращений, повысить прозрачность загрузки и качество сервиса без давления — через понятные правила, одинаково применимые как в офисе, так и на производственных площадках.
Евгений ТитовС точки зрения Евгения Титова («Завод Продмаш»), минимальное культурное условие работы сервисной модели — это умение выполнять договоренности. ИТ почти всегда находится «на стыке других подразделений» и внедряет системы, которые затрагивают несколько функций. Если участники процесса договариваются о шагах и сроках, а потом соблюдают эти договоренности, «все слаженно, нормально работает». Если кто-то «выбивается из этой цепочки», ломается вся конструкция, как бы красиво ни были прописаны SLA и регламенты. В этом смысле культура — это не только вопросы мотивации или привычек пользователей, но и готовность всех сторон воспринимать ИТ как партнера и держать слово по отношению к совместным изменениям. Метрики Тема культуры довольно естественно вывела круглый стол к еще одному чувствительному инструменту — KPI. Если через каталоги и регламенты ИТ задает «правила игры», то через показатели фактически формирует поведение людей: кого подталкивать к работе через сервис-деск, кого — к аккуратным изменениям, а кого — к более бережному отношению к инфраструктуре. Антон Воронков поделился опытом, где мотивация сервис-деска буквально разложена по параметрам. В премиальной части инженеров значимый вес имело отражение трудозатрат: существовала договоренность, что минимум 80% рабочего времени должно быть разнесено по заявкам. «Меньше, как Марина сказала, увидеть в отчете можно, но маловероятно, что это обосновывает тогда нахождение сотрудников техподдержки на рабочем месте», — признается он. Поверх этого накладывались показатели по количеству выездов (для внешних заказчиков), доле переоткрытых заявок и другим операционным метрикам. Все формулы были прозрачны: инженер в любой момент понимал, на какую премию может рассчитывать в этом месяце. При этом Антон честно признает, что система должна учитывать человеческий фактор: «бывают люди, которые горят работой и в 11 ночи будут подключаться и работать, и не любят заполнять показатели». С такими крайними случаями приходится отдельно разговаривать «по-человечески» и иногда делать осознанные скидки. С точки зрения взаимодействия с бизнесом Сергей Анциферов делает ставку на более «тяжелые» SLA-показатели. В его практике центральное место занимают RTO и RPO — время восстановления и максимально допустимая потеря данных при инциденте. Третий важный показатель — доля реализованных изменений от планового объема. В начале месяца формируется план по часам разработчиков, затем измеряется, какая часть этого объема выполнена. «Для сотрудников в принципе должно быть зеркально, — поясняет он. — Они же должны быть замотивированы, чтобы эти SLA перед бизнесом выполнить». Поэтому внутренняя мотивация тоже завязана на соблюдение RTO/RPO и отсутствие нарушений регламентов: все технические работы должны быть согласованы и корректно оповещены. Внешний подрядчик как часть сервиса По опыту Антона Воронкова, работа с внешними разработчиками почти всегда сводится к одному приоритету — контролю. Особенно это заметно на примере 1С-подрядчиков: «как только ослабляешь контроль, начинаются грабли, о которых очень сильно жалеешь». Баланс между ценой, скоростью и качеством держится только до тех пор, пока у ИТ «рука на пульсе постоянно и контроль, еще раз контроль». Под контроль попадает не только техника, но и коммуникации. Антон вспоминал ситуации, когда многолетние отношения с бизнес-заказчиком можно испортить одним неаккуратным сообщением человека со стороны подрядчика. Вежливость, ясность, нормальный русский язык — все это неожиданно становится частью ИТ-рисков: «ты выстраиваешь годами отношения, а один пришедший человек, который не очень хорошо общается, может многое порушить».
Марина МихейчиковаВ других моделях этот риск снимают архитектурно. В практике «Благо» заказчик вообще не видит разработчиков — ни внутренних, ни внешних. Связующим звеном выступают проектные менеджеры и аналитики, которые получают заявки от бизнеса, оценивают их, распределяют задачи между исполнителями и принимают результат. «Заказчик не знает разработчиков. И по сути, им все равно, кто это — внутренний или внешний», — подчеркивает Марина Михейчикова. Прямое взаимодействие подрядчика с бизнесом в прошлых кейсах приводило к «сильно непредсказуемым и чаще негативным последствиям», поэтому сейчас эта дверь закрыта по умолчанию, даже в схеме поддержки «Битрикс»: внешняя компания общается через проектного менеджера, а не с функциональным заказчиком. При этом у самого Ивана Козлова в карьере был и обратный пример, когда бизнес успешно работал напрямую с аутсорсером, и «все были довольны». Но даже он признает: такие истории скорее исключение, чем правило, и завязаны на очень зрелые команды по обе стороны. Там, где внешние исполнители все-таки встроены в конвейер, критически важен персональный контур ответственности. В обсуждении не раз звучала мысль о том, что у каждого подрядчика должен быть конкретный куратор внутри ИТ, отвечающий не абстрактно за «внешников», а за конкретных людей. Иначе «начинается свистопляска» — от хаотичных обсуждений в чатах до провалов качества. Даже самый «белый и пушистый» подрядчик, отмечает Сергей Горшенин, остается вопросом цены и риска: иногда честнее прямо сказать бизнесу, что за этот бюджет нужного качества на рынке не купить, и не выносить критичные сервисы во внешний контур. Не менее важна стабильность команды: в одном из проектов при запуске аутстаффа он лично отбирал разработчиков по тестовым кейсам и закреплял конкретных людей в договоре «минимум на такой период», иначе в критический момент смена исполнителя, не знающего внутренних процессов, неминуемо приведет к «просадке процессов». Есть и другая сторона медали — ситуации, где внешний провайдер вписывается в сервисную модель практически идеально. Андрей Власенко (УК «Старт») привел пример покопийной печати: консолидация принтерного парка у внешнего провайдера с понятной стоимостью за страницу и четким SLA. В такой схеме все прозрачно: какие сервисы оказывает подрядчик, как измеряется качество, сколько стоит единица услуги. «Работало идеально, всем все было понятно, какой SLA, сколько стоит, как измерять, там было без вопросов», — вспоминал он. Если же речь идет о R&D, сложных изменениях или индивидуальной разработке, картинка резко меняется: «здесь можно улететь в космос с точки зрения стоимости», если процессы измерения и контроля не выстроены должным образом. Именно поэтому участники многократно возвращались к тезису: внешний поставщик должен быть встроен в общую сервисную модель — с теми же принципами измеримости, прозрачности и ответственности, что и внутренние команды. В финале обсуждение каталогов услуг, управления изменениями, бюджетов, культуры, KPI и работы с подрядчиками в итоге свелось к простой формуле: «контроль, измерение плюс люди и доверие — два столпа, на которых в общем-то вся сервисная модель и строится». Один столп — про цифры: каталоги, SLA, RTO/RPO, доли реализованных изменений, понятные KPI для команд и подрядчиков, измеримость даже внешних услуг «для самого себя». Второй — про людей: корпоративную и информационную культуру, готовность соблюдать договоренности, умение выстраивать интерфейс между ИТ, бизнесом и внешними провайдерами так, чтобы внутренняя и внешняя части конвейера работали как единое целое. Именно в этой связке, по сути, и рождается CIO как внутренний провайдер: не только владелец технологий, но и архитектор сервисной модели, которая одинаково прозрачно работает и для своих команд, и для бизнеса, и для тех, кто помогает ИТ снаружи.
