Pull to refresh
7
0
Сергей Семикин @GreyBear

Управление ИТ услугами

Send message
Здорово, классная цель для дискуссии. А какие на Ваш взгляд могут быть цели на входе в ИТ? Для экономии времени ИТ упростим до отдела техподдержки и процесса решения обращений.
Вы хотите, чтобы я додумал ход мыслей автора статьи, для какой именно среды компании сформулироавны ключевые показатели в этой статье?
«риски или что денег не хватит» — для чего нужны?
«работа ИТ не соотвествует ожиданиям заказчиков» — для чего? В SLA это не прописано?
«процесс непрерывного улучшения» — зачем нужен? Если на него нет спрос

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

ITIL, COBIT, IT4IT — предполагают что IT это нечто обособленное.

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

«процент расходования годового бюджета ИТ» — о чем может сказать?

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

рейтинг удовлетворенности по закрытым инцидентам» — где использовать,?

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

«количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения» — как быть с неприемлемыми или отозванными предложениями?

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

вообще-то это заказчик выставляет вам цели и критерии оценки их достижения.

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

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

Каждый решает для себя сам, чем ему пользоваться. Считаете, что для Вас более приемлем lean и готовы сделать его адаптацию под не производство, делайте. Другие выберут ITIL, а третьи поймут что им нужен только COBIT, т.к. внешние аудиты, четвертые выберут IT4IT, а пятые придумают свой уникальный фреймфорк, а еще кто-то скажет, что процессы — это бюрократия и они им не подходят.
Это же ничем не противречит статьям… В них идет рассказ об одном из вариантов (а именно вараинте рекомендуемом в ITIL) как имея цель, cформулированную в понятных для бизнеса категориях (сбалансированная система показателей), плучить ключевые показатели для оценки, которые также можно показывать заказчику, т.к. они сформулированы в его терминах.
Если нужны подробные примеры по показателям ITSM процеесом, можно посмотреть на COBIT.
Его позиционируют, как reference (образцовая, примерная) модель процессов, в отличие от ITIL, которую выпускают в мир, как best practics (только best трактуют, как хорошие, а не лучшие :) ).
Кстати, в COBIT для показателей используется сбалансиованная система…
серия про технологию формирования метрик через последовательное формулирование целей — критических факторов успешности — ключевые показатели — метрики.
цели выбираете сами, и в каждой заметке есть оговорка, что приводимые примеры не универсальные, не нужно их бездумно использовать. примеры лучше использовать, как вектор мысли.
данная стать про расширение это йтехнологии через добавление на каждом уровне четырех разрезов (проекций), чтобы связать процессы ITSM с целями, кто за них платит деньги, и быть им более понятными.
Cпасибо, в такой формулировке смогу ответить.

Попробуйте почитать еще одну статью Рейнса «Осторожно. Как использовать метрики процессов без вреда для здоровья процессов» habr.com/ru/post/359206, если она не ответит на Ваш вопрос, посмотрю, что еще можно найти.

PS Рейнс, как и многие, кто связан с любыми best practics, очень не любят давать рекомендации, что именно делать и измерять, предпочитая описывать подходы и в качестве примеров давать кусочки свой удачной практики.
Уточните, пожалуйста, вопрос. Для чего такие измерения проиводятся?
Спасибо, исправил ошибку.
Любую компанию делают люди, если кто-то прочитав статью опробует при создании показателя любого процесса (даже не IT-шного), уже будет неплохо. Я чуть раньше этой статьи пробовал рассказать идею коллеге, когда он не мог сформулировать показатели, и она вполне зашла и ступор был убран.
Примеры, для внутреннего ИТ, хотя, на мой взгляд, вполне применимо и для оказания внешних услуг. А вот сама метология декомпозита: цели — показатели — метрики, универсальна.
Если интересно можем обсудить.
А как рассказать тем, кто платит деньги, что кто-то «реально работает» и самое главное при этом делает то, что нужно тем, кто заказывает и платит?

Читал несколько раз. Судя по Вашей оценке, Гугл бы лучше справился :)

Так сами же призываете чтить оригинал. А там нет потребителя.
ITIL же, здесь при том, что статья опирается на понятийный аппарат данного фреймворка ITSM, ну и автор не чужой человек для этого свода практика.
Про риски, согласен, есть два предложения с упоминанием понятия.
Но в статье нет ни слова про потребителя. Есть Заказчик (customer), есть Пользователь (user), но Потребитель (consumer) не упоминается. Более того такого понятия, как потребитель в принципе нет в Глоссарий ITIL.
Спасибо за восторженный отзыв. А чем заказчик отличается от «консьюмера»? И разве обратная связь это не частный случай коммуникации? И нет в этой статье никакого Управления Рисками, только предостережение не брать на себя то, что не сможешь выполнить.
А как же итеривные методики проектов? Тот же Agile.
Они вне ограничений проектного треугольника (результат, ресурсы, срок) пна всю длину проекта.
Не нравится мне слово «снабженские», душа протестует. Я бы заменил его на «поддерживающие» или на «эволюционные» процессы, когда задачи не захватить новые для себя позиции, а удержать.
Как основной идеей, да, вы почти правы (есть еще пара моментов, например, про формулировку целевого показателя в SLA), но статья для того и пишется, чтобы убедить читателя в этой идее.
1

Information

Rating
Does not participate
Location
Самара, Самарская обл., Россия
Date of birth
Registered
Activity