Как стать автором
Обновить

Комментарии 24

Расскажите заодно про другие фреймворки типа COBIT, TOGAF, BRMBOK, BABOK, SWEBOK и т.д.

Спасибо, что читаете. Да, планируем рассмотреть эти темы.
Как понять ITIL? Сколько не пытался читать/понять/смотреть содержимое — не дается. Любая тех.документация дается мне в разы проще, потому что есть четкие метрики, что мы получаем в замен производимых действий. В доках по ITIL этих метрик я не прослеживаю и трактовать значимые вещи можно по своему. Так что, без четких примеров «что сделали и что получили» все эти книги — набор красивых слов и формулировок. Но еще больше меня поразило — ITIL «пестрит» постоянным улучшением/модернизацией услуг, но думаю для всех не новость, что любое изменение это прежде всего изменение цены (не ценности) услуг. Поэтому улучшать услуги и их ценность без пересмотра цены — это работать себе в убыток. Другая позиция — цену можно не пересматривать, но чтобы не остаться «в минусе», нужно пересмотреть затраты, а один из самых больших источников затрат это что? Правильно — персонал. Вывод в соответствии с ITIL очевиден — сокращение персонала/затрат на персонал (страховка, питание, развозка и з/п), и перевод некогда своего персонала в какое-нибудь ТОО «Рога и Копыта», откуда все разбегутся как мыши. Я проходил через внедрения практик ITIL, не как внедренец, а как обычный сис.админ. Тот еще цирк. Может быть «внедритель» был некомпетентен — хз. Но осадок остался. Перспектива перехода в ТОО «Рога и Копыта» и впахивание за троих не доставляла положительных моментов. Послал весь этот цирк «до начала представления».
Ну вот открыл навскидку ITIL v3 Incident Management, метрики:
■ Total numbers of Incidents (as a control measure)
■ Breakdown of incidents at each stage (e.g. logged,
work in progress, closed etc)
■ Size of current incident backlog
■ Number and percentage of major incidents
■ Mean elapsed time to achieve incident resolution or
circumvention, broken down by impact code

И далее т.п.
По мне, так вполне себе конкретные метрики.

А проблема внедрения — это верно подмечено, режет все на корню. Но очевидно, это не проблема ITIL (или PMI, или ...)

Метрики есть, а дальше? Как всё это начать «митигировать»? Как должна работать та же самая система trouble-тикетов. Как понять, что у нас всё хорошо? Понятно, что инциденты будут всегда — мелкие/крупные — не важно. Или как понять, на что можно забить? А самое главное — как весь этот фрэймворк безболезненно и с умом внедрить? Пока для меня ITIL даёт больше вопросов, чем ответов, особенно на стадии внедрения. ITIL предполагает детальное логирование в тикет-системе, которое отнимает кучу времени. Много ли здесь желающих отдать хотя бы час в день, чтобы всё логировать все действия, инценетды, решения к ним (база знаний)?
На вопрос «как делать?» ИТИЛ не отвечает, он отвечает на вопрос «что надо делать?». Как — это уже зависит от предприятия.
Это значит процесс внедрения пойдёт таким образом, как будет угодно «внедрителю». По мне — уже не правильно.
Лет 10 назад, когда знакомился с ITIL, понял для себя так:
ИТ- подразделение должно стать как-бы государством в государстве; начать работать как подрядчик по отношению к основной компании-заказчику; все сотрудники ИТ должны начать вести учёт для того, чтобы можно было подтвердить перед заказчиком объёмы и затраты и получить соответствующее обеспечение (или оправдать бюджет).

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

Не уверен, что понял верно, но у меня именно такая сложилась картинка.
ITIL это не волшебная палочка. При внедрении ITIL и софта, автоматизирующего ITIL процессы _НЕОБХОДИМО_ активное участие заказчика. Причём как бизнес-подразделений и ответственных, так и IT. Т.к. обычно компаниям без ITIL прийдётся поменять парадигму работы.
ITIL как методология даёт общие рекомендации в части набора процессов, основных схем этих процессов, взаимосвязей этих процессов
Именно поэтому многие внедрения ИТИЛа проваливаются. Люди думают, что внедрение ИТИЛа — это сделать так, как написано в книге, но ИТИЛ — это выжимка, основа для построения ИТ-процессов по ИТИЛ исходя из жизни и целей конкретного бизнеса. Любая система связанная с построением процессов на предприятии, при внедрении предполагает изменения существующих процессов для обеспечения достижения поставленных целей, а не для того, чтобы их внедрить.
То есть, сначала определить цель изменения процесса или процессов — уменьшить расходы на ИТ, уменьшить время реакции ИТ-отдела на проблемы, уменьшить срок простоя при сбоях и т.д.
Затем надо решить что делать, для этого берём ИТИЛ, или, в случае других процессов — COBIT, AGILE. Пример (навскидку) — уменьшение времени реакции требует наличия HelpDesk системы с такими-то возможностями и вот таким процессом организации работы первой линии обороны ИТ.
И только после этого идёт «как» — поиск, выбор, тестирование подходящей системы, её внедрение, затем анализ (подошла ли, или мы накосячили на этапе «что делать»), затем корректировка и если всё нормально, то живём и радуемся тому, с какой скорость обрабатываются заявки пользователей.
Обсуждения проблем внедрения ITIL мне поразительно напоминает обсуждение проблем например внедрения Scrum. Здесь много публикаций посвященных оному, и в комментариях ожесточенная полемика.

Имхо, первая ошибка — ошибка целеполагания. Что мы хотим? Какую проблему решаем?
Если цель, безболезненно и с умом внедрить ITIL, скорее всего получится что-то, что будет вызывать вопросы у первого руководителя, на хера все это. И вопросы справедливые.
Если цели бизнес-ориентированы, например 20% звонков клиентов теряется, давайте сделаем так, чтобы терялось не более 3%, то это понятно сколько стоит(убытки), и сколько за это бизнес готов платить. Дальше начинаем погружаться в решение вопросы и становится понятен, а про что Event Mgmt, как он смотрит на Incident Mgmt, а тот в свою очередь на Problem Mgmt, Change Mgmt и пошло поехало.

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

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

Традиционное заблуждение.
Логироваться должно ровно то, и с таким уровнем детализации, и таким способом, который позволяет с одной стороны не тратить много ресурсов на логирование, с другой — решать бизнес-проблемы с нужным уровнем качества. Т.е. не тратим усилия на достижение каких-то мифических метрик, потому что вычитали эту метрику в талмуде по ITIL (или консультант так насоветовал), а тратим усилия на достижение понятных бизнесу целей, которые выражаются в очевидных бизнесу метриках, типа теряем 20% звонков, хотим терять 3%, когда достигли этого, удерживаем, и ставим вторую цель (ну например, время на релокацию одной точки продажи не более 3 дней)
Сам насколько раз читал ITIL — просвещение пришло не сразу. После первого прочтения в голове был бардак. Но когда начал погружаться в тему изучая профильные сайты и форумы, то пришло понимание.
Сокращение персонала подразумевает переделку ИТ-процессов так, чтобы хватало минимального количества людей на поддержку ИТ, что и является в некой степени тем, для чего ИТИЛ и сделан.
Если где-то рассчитано на «минимально», то где подразумевается максимально — в смысле загруженности персонала вне своего рабочего времени 5*8. Простой закон если где-то убыло, значит где-то прибыло.
Убыло у нас — прибыло у других, закон работает. :) Закон, ведь так работает?

Сам лично создал и поддерживал инфраструктуру на 200 рабочих станций, пять серверов и 4К юзеров. Но это поддержка была чисто техническая (что-то перестало запускаться) и управленческая (учётки юзеров, права), всё вопросы «как в Экселе уместить табличку в A4» отправлялись в Гугл и иногда решались лично. При этом никакого ИТИЛа и 98% свободного времени в рабочее время.

PS. Если где-то один и тот же конкретный персонал загружен 24*7, то в этом где-то что-то не так. И не понятно, как этот персонал такое выдерживает.
«Как понять ITIL?» Очень просто — это бизнес, кстати очень доходный, такой же как и MBA и прочая лабуда. Все правильно ты и не должен понимать о чем там речь, ведь есть чудесные платные курсы))).

Еще не в одной большой компании мне не встречалась нормальная реализация ИТ процессов. А я работал с Пепси, Кока-колой и еще +10500 брендов.

Проблема одна и таже:
1) руководитель ИТ не заинтересованный словоблуд, задача которого клепать красивые отчетики для начальства
2) раздутый штат
3) уход в формальности(заполните 10500 заявок)
4) долгие сроки реакции
5) cложная схема иерархии.
6) переключение задач с сотрудника на сотрудника.

1) руководитель ИТ не заинтересованный словоблуд, задача которого клепать красивые отчетики для начальства
2) раздутый штат
3) уход в формальности(заполните 10500 заявок)
4) долгие сроки реакции
5) cложная схема иерархии.
6) переключение задач с сотрудника на сотрудника.


Разве это не следствие применения ITIL?
ITIL, DevOps, Agile, Lean… Цифровизация!!!

Как же я понимаю некоторые песни Шнура…

Крик души в тему:
Опуститесь на бренную землю
Посмотрите правде в глаза
Какая на… й цифровизация
Когда кругом тормоза!

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

Поговорите об ИТИЛ с «хозяевами» — владельцами, руководителями, старшими менеджерами.
Им надо ДРУГОЕ!!! Увеличение прибыли, сокращение затрат, минимизация рисков. Вот их язык.
С 2000 года прохожу «внедрения ИТИЛ» в разных компаниях, в разных ролях — от инженера поддержки, до руководителя. Классная это штука. Вот только применять ее у нас надо с учетом особенностей наших. Местных. Знаете, как продавцы говорят? Продать самовар в Туле и в Москве — это совершенно разные вещи! ITIL там и тут — это тоже совершенно разные вещи!

Для себя нашел такую его реализацию — Менеджер по счастью. Приношу счастье используя принципы сервисного подхода для оптимизации бизнес-процессов. Слова «ITIL, DevOps, Agile, Lean» — НЕ УПОТРЕБЛЯЮ!
Проходит на «отлично» (смотрите мой блог, писал об этом ранее).

Статья хорошая, для понимания «откуда ноги растут» — нужная.
Но я за «бренную землю» и реалии.
Им надо ДРУГОЕ!!! Увеличение прибыли, сокращение затрат, минимизация рисков. Вот их язык.

ITIL и есть про сокращение затрат, минимазацию рисков и увеличение прибыли. Это и есть язык ITIL. Он вот прямо целиком обо всём вот этом вот и для этого в первую очередь и нужен.
Чтобы можно было деятельность как минимум ИТ обмерять целиком в деньгах, и даже риски измерить в деньгах.
Incident — про сокращение затрат из-за прерываний оказываемых услуг(в т.ч. про стоимость устранения инцидентов т.к. у людей работающих над инцидентом есть почасовая цена).
Change — про расчёт рисков, затрат на исполнение RFC, стоимости необходимых активов и денег на оплату человеческого времени, необходимого для внедрения RFC
Problem — для группировки инцидентов и ведения сложноустранимых ошибок, вызывающих множественные инциденты с разных сторон
Workorder — учет затрат времени/денег на выполнения какой-либо базовой работы, чаще всего в рамках change.
Config& Asset — думаю и так понятно что в конфигах и asset калькулируется стоимость актива/софта на КЕ и т.Д

абсолютно все процессы в ITIL ориентированы на то чтобы:
1)Бизнес знал сколько стоит ИТ и почему столько стоит и увидеть дыры, которые заставляют компанию терять деньги
2)измерить эту самую деятельность ИТ загоняя всех в процессы, по которым можно отслеживать сколько и над чем именно работал Инженер1, Инженер2, Инженер3

Возможно вы просто ITIL не с той стороны щупали. ITIL просто насквозь про бабки и про учет времени
Попробуйте то же самое написать кратко для бизнес руководителя.
Которому пофиг Incident это или Problem в терминологии ITIL.
Повторюсь,
ITIL — не волшебная палочка, и он нацелен как раз на то чтобы у бизнес-руководителя появилсь инструменты, которые помогут ему понять текущую ситуацию с ИТ и адекватно что-то прогнозировать.
При этом как бизнес, так и ИТ руководство должны погрузиться в свои срезы ITIL, чтобы с этого был выхлоп. Не просто так речь о процессах. Как можно выстроить в компании какой-либо процесс, если даже руководство не имеет понятия о том как они протекают?
«руководство должны погрузиться в свои срезы ITIL»…
Повторюсь — опуститесь на бренную землю.
Руководство — должно. Вы сами-то в это верите?

Бизнес-руководителю можно и нужно это донести. Вот тут я с вами согласен. Хорошо, если есть кому это сделать. Чаще — некому.

Знаете какой наиболее частый вопрос мне задают после выступлений на ИТ-мероприятиях?
— Как вам удалось донести это до бизнес-руководителей?
Вот это реально интересно. Как донести до бизнеса принципы ITIL доходчиво.
Вот это реально интересно. Как донести до бизнеса принципы ITIL доходчиво.

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

Верю, но под этим подразумеваю участие консультантов, которые помогут разобраться.
Вот и пришли к взаимопониманию!
Я как раз и занимаюсь консультациями бизнеса, используя индивидуальный подход. С учетом знаний и опыта ИТ + ITIL, реально интересно!
А иначе это как сказать человеку: «Через два дня чтобы рассказал войну и мир», потом взять 4 тома и каждым из них настучать по морде, в надежде что это поможет человеку понять суть:-)
В это нужно очень хорошо погрузиться чтобы понять всё со всех сторон(как с бизнеса, так и с ИТ, не говоря уже об ролях в каждом из процессов). Слишком всё глубоко связано между друг другом
Зарегистрируйтесь на Хабре , чтобы оставить комментарий