IT для неайтишников: Потеряли ключи от IT, что делать?

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

Меня зовут Константин Митин. 15 лет занимаюсь коммерческой IT-разработкой, прошёл путь от простого программиста до сооснователя и руководителя группы IT-компаний (АйТи Мегастар/АйТи МегаБокс/АйТи Мегагруп). Успел побыть тим-лидом, руководителем филиала разработки крупной федеральной IT-компании. Являюсь одним из идеологов концепции IT~BP (партнёрство между IT и бизнесом).

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

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

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

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

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

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

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

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

В какой-то момент встаёт вопрос, а что делать-то? Можно звать консультантов и дружественные IT-компании для подстраховки. А можно самим начинать выправлять ситуацию, потому что проблемы здесь скорее организационные, чем технические. Последовательность действий будет одна и та же, что с подрядчиком, что без.

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

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

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

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

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

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

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

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

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

Честно говоря, вся необходимая информация уже собрана и описана, например, в ITIL/ITSM. Однако, нужно понимать, что мало пройти обучение либо сертификацию, нужно еще внедрить и выполнять необходимые процессы.

Поговорим лишь о самых базовых и важных элементах.

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

То есть инцидент это когда нам что-то нужно для выполнения бизнес-процесса штатным образом, а мы не можем это получить. А что такое процесс управления инцидентами? Зачем нам ими управлять-то?

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

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

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

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

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

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

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

Специалист третьей линии это эксперт по системе, который может решать нестандартные проблемы. Часто это системные администраторы, которые могут переконфигурировать IT-инфраструктуру либо программист, который может исправить ошибку в коде.

В статье «IT для неайтишников: Какими бывают IT-шники? Часть 1» приведено чуть более подробное описание сотрудников второй и третьей линии технической поддержки. А в статье «IT для неайтишников: Какими бывают IT-шники? Часть 3» описан руководитель технической поддержки.

По инцидентам всегда ведётся статистика, которая регулярно анализируется. Без нее сложно понять насколько хорошо работает процесс управления качеством при разработке/доработке IT-сервисов. Кроме этого есть процесс управления проблемами, но о нем чуть позже.

В ITIL/ITSM используется удобная модель, в которой IT оказывает услуги внутренним заказчикам. А значит бюджет IT состоит из тех денег, которые на IT согласны выделить бизнес-заказчики из своих бюджетов.

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

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

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

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

Кроме того, между бизнесом и IT начинают заключаться контракты. Пример контракта из ITIL/ITSM это SLA (Service Level Agreement - Соглашение об уровне услуг). Например, SLA для процесса управления инцидентами включает в себя (но не только):

• Время в которое доступно оказание услуги.

• Способ определение приоритетов инцидентов (незначительный/обычный/важный/критический/массовый сбой/авария).

• Сроки реакции на инциденты в зависимости от приоритета инцидента.

• Сроки решения инцидентов в зависимости от приоритета инцидента.

• Количество инцидентов, при котором соглашение может выполняться.

Есть еще один вид контракта SLM (Service Level Management), но о нем чуть попозже.

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

Верно и обратное, если подрядчик начнёт раздувать бюджет, будет заметен большой контраст с затратами на внутреннюю команду.

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

Фактически процесс управления инцидентами перетекает в процесс управления проблемами. В рамках процесса управления проблемами не только выделяются, но еще и решаются проблемы.

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

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

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

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

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

Формирование каталога IT-услуг - это важный шаг. В компании должен появиться список тех услуг, что IT оказывает бизнес-подразделениям и формализованы правила их оказания. То есть кто имеет на них право, кто согласует предоставление конкретного доступа, какой бюджет на оказание услуги. Иначе говоря формируется тот самый Service Level Management (SLM).

Допустим, что к IT поступает запрос на предоставление доступа к 1С Бухгалтерии. Иначе говоря доступ к чувствительным финансовым данным компании. Если IT не знает с кем согласовать этот доступ, то доступ могут просто «случайно» выдать.

Вторая проблема - это стоимость лицензий. На каждого пользователя в 1С нужна лицензия. Лицензия стоит денег. Если бизнес не ощущает стоимость лицензий, их количество может очень быстро и непродуктивно расти.

Когда появляется каталог IT-услуг, у пользователей появляется единое окно входа в IT. Становится понятно, как заказать замену мышки, попросить заправить принтер, заказать второй монитор (и понятно, как его согласовывать), получить доступ к конкретной системе и так далее.

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

В целом процессы управления инцидентами и проблемами, каталог IT-услуг и контракты между бизнесом и IT ощутимо полезны не только в экстремальных ситуациях. Как и многие иные практики, которые уж собраны в ITIL/ITSM. На каком-то уровне развития компании очень желательно начать внедрять эти процессы.

Умело используя нужные процессы, можно восстановить контроль над IT. Процесс управления инцидентами позволит получить доступ к объективным показателям IT и оценить качество работы IT в целом. Без этого будет сложно оценивать эффект от изменения бизнес-процессов в IT.

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

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

Система контрактов между бизнесом и IT позволяет нижним уровням бизнеса и IT наработать горизонтальные связи. То есть уйти от проблемы «мостика» и интегрировать друг в друга бизнес-команду и IT-команду.

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

Если вы дочитали до конца и написанное было для вас полезным, то спасибо вам.

Полезные материалы по теме:

• IT для неайтишников: Зачем оно нужно?
• IT для неайтишников: Какими бывают IT-шники? Часть 1
• IT для неайтишников: Какими бывают IT-шники? Часть 2
• IT для неайтишников: Какими бывают IT-шники? Часть 3
• IT для неайтишников: Какими бывают IT-шники? Часть 4
• IT для неайтишников: Какими бывают IT-шники? Часть 5
• IT для неайтишников: Какими бывают IT-шники? Часть 6
• IT для неайтишников: Какими бывают IT-шники? Часть 7
• IT для неайтишников: Какими бывают IT-шники? Часть 8
• IT для неайтишников: Куда исчезают программисты после 40 лет?
• IT для неайтишников: Срывают сроки, что делать бизнес-заказчику?
• IT для неайтишников: Технический долг или почему теперь всё так долго?
• IT для неайтишников: Осторожно - JSDD (Бизнес в заложниках у IT)
• IT для неайтишников: Инженеры в заложниках у бизнеса
• IT для неайтишников: Потеряли ключи от IT, что делать?
  
• Как писать код, чтобы тебя не уволили? (про JSDD — Job Safety Driven Development)
• Процессы в ИТ: Долго, дорого и не то
• Саморегуляция в ИТ: минимально допустимая эффективность работы
• Telegram-канал Записки ITBP (короткие сообщения)
• Канал на Дзен Записки ITBP (статьи среднего размера)