Comments 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 тома и каждым из них настучать по морде, в надежде что это поможет человеку понять суть:-)
В это нужно очень хорошо погрузиться чтобы понять всё со всех сторон(как с бизнеса, так и с ИТ, не говоря уже об ролях в каждом из процессов). Слишком всё глубоко связано между друг другом
Only those users with full accounts are able to leave comments. Log in, please.

Information

Founded
Location
Россия
Website
www.naumen.ru
Employees
501–1,000 employees
Registered