Однажды мы уже упоминали в новостном потоке об основном тезисе использования идей ITIL – "принимай и приспосабливай" ("adopt and adapt"). Небезызвестный Стюарт Рэнс, не понаслышке знает, что этот посыл не всегда находит понимания. Люди, пытающиеся использовать идеи ITIL, зачастую формально подходят к их применению, не разбирая, что стоит, а что не стоит брать на заметку в контексте конкретной организации. Это приводит к тому, что и бизнес, и ИТ оказываются неудовлетворёнными такими огульными "внедрениями".

Видя и глубоко понимая проблему, Стюарт опубликовал в своём блоге развёрнутое описание тезиса в виде двух частей – двух заметок. Первая часть посвящена "adopt", вторая – "adapt".

Первое, что стоит отметить, что ITIL – это не стандарт, это сборник лучших практик. В чём различие? Стандарт описывает требования, которым нужно соответствовать. Если нет соответствия требованиям, нет соответствия и стандарту. А сборник лучших практик это перечень вещей, которые хорошо себя зарекомендовали в других организациях. Знать, что хорошо показало себя на практике в других компаниях, очень полезно. Можно не создавать свою систему управления с нуля, а сэкономить время и ресурсы, ознакомившись с тем, как она реализована у других. При этом стоит помнить, что как бы ни была хороша идея, нет никакой гарантии, что она будет применима для ваших условий. ITIL – набор отличных идей, которые можно скопировать. Но не нужно делать всё так, "как описано в ITIL". ITIL – это не конкретный алгоритм, это отправная точка.

"Adopt". Что значит "принять" процесс или любую другую идею из сборника лучших практик? Это означает, что вы решаете, что этот процесс (или идея) нужны вам. И первый вопрос, на который требуется ответить – почему он вам нужен? Простой пример. В ITIL есть процесс "управление запросами на обслуживание" (Request Fulfilment). Процесс предназначен для обработки заранее предопределённых стандартных запросов сотрудников компании. При этом у вас уже существует прекрасно работающий процесс управления инцидентами. Вы понимаете, что запросы на обслуживание отличаются от инцидентов, что порядок обработки другой, что требуются другие метрики и KPI. Так вы приходите к мысли, что нужен процесс управления запросами на обслуживание, "принимаете" его необходимость.

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

"Adapt". Определённо, это самая трудная часть. Как можно "приспособить" те идеи, те процессы, что вы приняли, чтобы они заработали? Худшее, что можно сделать – просто скопировать. Вставлять в регламенты процессов описания потоков работ и процедур из ITIL, заставлять затем работать по ним сотрудников – плохая идея! Суть "приспособления" в том, что вы действительно можете применить идеи ITIL в любом окружении, но для этого нужно прекрасно понимать и разбираться в особенностях вашей среды. Снова пример. Представьте себе организацию, которая решила организовать управление изменениями. При этом она уже используют подход DevOps, который позволяет ей быстро и эффективно проводить изменения в продуктивной среде. Сотрудники понимают, что формализованный процесс поможет им оптимизировать бизнес-риски, формировать записи, необходимые при проведении аудитов. Худшее, что можно сделать в данной среде – "внедрить" CAB и закрепить в регламенте сроки обработки запросов на изменения в течение, например, одной недели. К счастью, ITIL предлагает разные способы организации подобных вещей:

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

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

Таким образом, приняв ("adopt") какую-либо идею из ITIL, необходимо её приспособить ("adapt"), адаптировать, к конкретным условиям организации, а не просто скопировать.