Однажды мы уже упоминали в новостном потоке об основном тезисе использования идей 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"), адаптировать, к конкретным условиям организации, а не просто скопировать.
«…ITIL — это не стандарт, это сборник лучших практик.»
Это не совсем сборник лучших практик. История была следующая — английское правительство попросило группу ученых товарищей дать описание роли и места ИТ. Для анализа были выбраны несколько ИТ организаций, зарекомендовавших себя в глазах пользователей наилучшим образом. В результате было получено не совсем профессиональное описание некоей общей для этих организаций модели процессов. Не совсем профессиональное, поскольку в группу входили не только ИТ специалисты. Один, на пример, был биохимиком. И результат трудно назвать полноценной моделью. Это просто набор процессов, для которых обозначены цели и результаты(выходы), кое как обозначены связи/входы (без разделения входов по типу — управление, инструмент и собственно вход). Полученный набор процессов был наиболее характерен для компаний, занимающимися предоставлением услуг. Из этого и был сделан вывод о том, что суть ИТ есть предоставление услуг. Поскольку для анализа были выбраны лучшие, то вроде как и лучшие практики.
«"Adopt". Что значит "принять" процесс или любую другую идею из сборника лучших практик? Это означает, что вы решаете, что этот процесс (или идея) нужны вам.»
Всё это напоминает одного персонажа, который с удивлением узнал, что он всю жизнь говорил прозой. Дело в том, что любая деятельность осуществляется в виде процессов. Вы в любом случае решаете/устраняете сбои/инциденты, не зависимо от того, внедрен у вас ITIL Incident Management или нет. И внедрение означает, что этот процесс у вас формализован(описан) и выполняется по формализованному алгоритму, а не как Бог надушу положит, или, как предлагается в соседнем сообщении, на основе прекрасных душевных порывов сотрудников. Но дело в том, что в ITIL не то что алгоритмов конкретных нет, там даже просто нормальной модели бизнес процессов нет. Так, что «ADOPT» , в моем понимании, это признание необходимости внедрения процессного подхода к организации своей деятельности — формализация и анализ, причем постоянный (CSI), определение на основе анализа показателей качества процесса, определение ролей и т.д.. А «ADAPT» – это как раз разработка конкретных алгоритмов реализации этих процессов. И они (алгоритмы) по объективным причинам достаточно специфичны для каждой организации и поэтому не следует их копировать.
Ииииэээххх, Остапа несло :))))