Правильная поддержка замещающих проектов

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

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

Критерий качественного ИТ-обслуживания сегодня хорошо известен. Это жесткие и юридически значимые соглашения о качестве обслуживания (SLA). В простейшем случае они фиксируют максимально допустимое время реагирования на ИТ-проблемы и предельные сроки их устранения. Причем крупным территориально распределенным организациям принципиально важно, чтобы подобные соглашения реально отрабатывались по всей стране, а не только в столице. Однако сейчас выполнить данное требование весьма непросто даже для традиционного проприетарного ПО, для которого есть рынок специалистов, существует поддержка вендоров и действует своего рода страховка для CIO (за выбор крупного международного бренда CIO не увольняют, даже если вендор фактически игнорирует сложные запросы российского клиента). В случае новых для нашего ИТ-рынка видов ПО (входящее в реестр отечественное ПО или OpenSource-решения, развиваемые международным сообществом) ни экспертной поддержки вендора, ни армии готовых специалистов нет. Да и спрятаться за мощь международного бренда не получится. Что повышает риски как CIO, так и руководителей компаний и регионов, курирующих ИТ.

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

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

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

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

А эта технология, в свою очередь, не может функционировать отдельно от «лестницы компетенций» в службах технической поддержки. Потому что такая «лестница» позволяет правильно и в срок классифицировать, обрабатывать и закрывать ИТ-запросы, инциденты, проблемы и делать это с помощью минимально достаточных компетенций. Так, ИТ-процесс управления инцидентами (на базе методик ITIL и ITSM) в крупном проекте по миграции с MS SQL на PostgreSQL должен каждый день «вытягивать» из инженеров первой, второй и экспертов третьей линии техподдержки точно отмеренный объем компетенций по работе «1С» и обеих СУБД. А согласованные с заказчиком SLA задавать количественные параметры входов и выходов черного ящика, скрывающего этот «насос компетенций». Внутри же «ящика» надо тщательно следить за тем, чтобы отмеренный для каждой линии объем не был превышен и при этом не оставались неиспользуемые излишки компетенций.

Если подобного равновесия не появится, решение непрофильных проблем на каждой линии будет обходиться крупной компании как минимум в 1,5–2 раза дороже, чем в оптимальном варианте. И это в лучшем случае. В худшем — сломается и рухнет вся структура техподдержки, что неизбежно похоронит и весь проект. Вложенные деньги заказчика не вернутся, а пятно на репутации центральной компании и ее партнеров может оказаться несмываемым.

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

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

В такой ситуации вторая линия вместо того, чтобы 80% времени администрировать серверы и только 20% тратить на законную помощь инженерам первой линии, начинает функционировать в соотношении 50% на 50%. Или даже 40% на 60%. То есть устойчиво загружена чужой работой. Естественно, это не может не отразиться на качестве решения своих задач. А первая линия, между тем, остается сильно недогруженной. Мало того, она еще и занимается долгой эскалацией ИТ-инцидентов и проблем, тогда как ее прямая обязанность — решать типовые задачи по ясным инструкциям («не разворачивается продукт из пакета LibreOffice», «не устанавливается русский язык», «перестала работать печать», «пропал Интернет»). Общий итог: выброшенные на ветер деньги (оплата простоя первой линии), потерянное время (простые вопросы решаются долго), неоправданное расходование дорогих компетенций на задачи, которые того не стоят. Только на первой линии расходы заказчика повышаются на 50–60%, а качество поддержки при этом ухудшается!

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

Третья линия начинает спасать вторую, брать на себя часть ее задач по серверам, которые находятся ниже ее компетенции. Для клиента такая «поддержка» будет стоить уже на 60–80% дороже, чем на привычных проектах на базе проприетарного западного ПО. К тому же растут не только расходы, но и недовольство клиента. Начинается эрозия клиентской базы, увеличиваются репутационные издержки. Но есть и другой негативный эффект, ускоряющий деградацию всех трех линий: дорогие эксперты очень быстро уходят, а специалисты ниже уровнем терпят до последнего. И вскоре служба техподдержки не только не справляется с требованиями к SLA, но и теряет способность к тому, чтобы повысить квалификацию и выбраться из ямы.

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

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

SLA второй линии я бы, наоборот, посоветовал смягчить на 30–50%, чтобы не загонять перегруженных специалистов в жесткий цейтнот и не множить выпадения из согласованных с клиентами параметров качества. Скорее всего, для такой деятельности придется выделить больше сотрудников.

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

Однако, несмотря на эти меры, вопрос «вендорозамещающей» (третьей линии) все равно не снимается.

Оптимальным решением даже для средней ИТ-компании, намеренной поддержать одинаково высокое качество ИТ-обслуживания для привычного и нового ПО, становится создание собственного центра компетенции (ЦК) по импортозамещению и Open Source. В этом центре есть группы экспертов, специализирующиеся по двум — пяти продуктам (в зависимости от масштаба ИТ-компании). Решая ключевые задачи, ЦК действует сразу на нескольких взаимосвязанных направлениях.

Техническое направление — это выбор и тестирование основных и дополнительных цепочек продуктов на совместимость, их доработка. И двустороннее пополнение базы знаний по проектам (владелец ЦК, партнеры).

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

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

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

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

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

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

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

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

Аутсорсинговые компании, имеющие партнерскую сеть из 100 и более региональных ИТ-компаний, могут создавать совместные центры компетенции с партнерами. В этом случае, выигрышном для обеих сторон, происходит объединение сильных (но узких) компетенций центральной компании и ее партнеров. Такие центры в чем-то даже выгоднее для участников, потому что все стороны, используя преимущества специализации, взаимодействуют и выступают как единое целое. Причем методики обучения, способы управления базами знаний, регламенты и инструкции исходят из ЦК головной компании. И это — хорошая основа для сильных внедрений и стабильной поддержки замещающих проектов.

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

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

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

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

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

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

И сделать для этого надо совсем немногое: временно «подвинтить» внутренние SLA, запустить генераторы недостающих знаний (три линии техподдержки и корпоративные ЦК по импортозамещению), потом наладить их передачу на первую и вторую линии.

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

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