Комментарии 18
Без привязки к целям, что Стюард предлагает измерять?
Уточните, пожалуйста, вопрос. Для чего такие измерения проиводятся?
Для чего используются показатели? Любые, не только KPI.
Cпасибо, в такой формулировке смогу ответить.
Попробуйте почитать еще одну статью Рейнса «Осторожно. Как использовать метрики процессов без вреда для здоровья процессов» habr.com/ru/post/359206, если она не ответит на Ваш вопрос, посмотрю, что еще можно найти.
PS Рейнс, как и многие, кто связан с любыми best practics, очень не любят давать рекомендации, что именно делать и измерять, предпочитая описывать подходы и в качестве примеров давать кусочки свой удачной практики.
Попробуйте почитать еще одну статью Рейнса «Осторожно. Как использовать метрики процессов без вреда для здоровья процессов» habr.com/ru/post/359206, если она не ответит на Ваш вопрос, посмотрю, что еще можно найти.
PS Рейнс, как и многие, кто связан с любыми best practics, очень не любят давать рекомендации, что именно делать и измерять, предпочитая описывать подходы и в качестве примеров давать кусочки свой удачной практики.
В этом и есть основная проблема всей серии, пытаться измерить сферического слона без понимания зачем это нужно.
Как подсказка: попробуйте определить цель существования процесса (любого из ITSM)
Как подсказка: попробуйте определить цель существования процесса (любого из ITSM)
серия про технологию формирования метрик через последовательное формулирование целей — критических факторов успешности — ключевые показатели — метрики.
цели выбираете сами, и в каждой заметке есть оговорка, что приводимые примеры не универсальные, не нужно их бездумно использовать. примеры лучше использовать, как вектор мысли.
данная стать про расширение это йтехнологии через добавление на каждом уровне четырех разрезов (проекций), чтобы связать процессы ITSM с целями, кто за них платит деньги, и быть им более понятными.
цели выбираете сами, и в каждой заметке есть оговорка, что приводимые примеры не универсальные, не нужно их бездумно использовать. примеры лучше использовать, как вектор мысли.
данная стать про расширение это йтехнологии через добавление на каждом уровне четырех разрезов (проекций), чтобы связать процессы ITSM с целями, кто за них платит деньги, и быть им более понятными.
Если нужны подробные примеры по показателям ITSM процеесом, можно посмотреть на COBIT.
Его позиционируют, как reference (образцовая, примерная) модель процессов, в отличие от ITIL, которую выпускают в мир, как best practics (только best трактуют, как хорошие, а не лучшие :) ).
Кстати, в COBIT для показателей используется сбалансиованная система…
Его позиционируют, как reference (образцовая, примерная) модель процессов, в отличие от ITIL, которую выпускают в мир, как best practics (только best трактуют, как хорошие, а не лучшие :) ).
Кстати, в COBIT для показателей используется сбалансиованная система…
Не важно, любой процесс.
Его цель, входы и выходы. Для начала.
Пока это не определено, конкретных(по SMART-у) показателей не может быть.
Позже на каждый вход или выход создается и согласуется обеими сторонами SLA с конкретными показателями.
Еще позже можно посчитать стоимость исполнения экземпляра процесса, в часах и рублях.
Если уж совсем примитивно — Заказчик всегда прав.
и именно он выставляет нам (IT) цели и критерии оценки их достижения.
Его цель, входы и выходы. Для начала.
Пока это не определено, конкретных(по SMART-у) показателей не может быть.
Позже на каждый вход или выход создается и согласуется обеими сторонами SLA с конкретными показателями.
Еще позже можно посчитать стоимость исполнения экземпляра процесса, в часах и рублях.
Если уж совсем примитивно — Заказчик всегда прав.
и именно он выставляет нам (IT) цели и критерии оценки их достижения.
Это же ничем не противречит статьям… В них идет рассказ об одном из вариантов (а именно вараинте рекомендуемом в ITIL) как имея цель, cформулированную в понятных для бизнеса категориях (сбалансированная система показателей), плучить ключевые показатели для оценки, которые также можно показывать заказчику, т.к. они сформулированы в его терминах.
«процент расходования годового бюджета ИТ» — о чем может сказать?
«рейтинг удовлетворенности по закрытым инцидентам» — где использовать,?
«количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения» — как быть с неприемлемыми или отозванными предложениями?
Не стоит бороться с "фатальным недостатком", лучше взять наработанные в других сферах методики. Тот-же кайдзэн полностью покрывает «эксплуатацию ИС». А проекты/микропроекты развития, даже в гибкой форме вполне самодостаточны в плане оценки результата.
«рейтинг удовлетворенности по закрытым инцидентам» — где использовать,?
«количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения» — как быть с неприемлемыми или отозванными предложениями?
получить ключевые показатели для оценки, которые также можно показывать заказчику,вообще-то это заказчик выставляет вам цели и критерии оценки их достижения.
Не стоит бороться с "фатальным недостатком", лучше взять наработанные в других сферах методики. Тот-же кайдзэн полностью покрывает «эксплуатацию ИС». А проекты/микропроекты развития, даже в гибкой форме вполне самодостаточны в плане оценки результата.
KPI — дословно «ключевые индикаторы результативности», они являются лишь «светофорами» или «градусниками» показывающими текущее состояние «здоровья» той или иной цели. Они не являются доказательством достижения или не достижения цели. поэтому:
отклонение от ожидаемых показателей верхне уровнево показывает, что есть риски или что денег не хватит, и компании придется тратить резервы, или наоборот деньги останутся замороженными, а вообще нужно лезть в подробности и разбираться, что идет не так
индикатор, что работа ИТ не соотвествует ожиданиям заказчиков, нужно встречаться и разговаривать для определения это ожидания завышены, или что-то изменилось в среде заказчика и старые SLA (не важно в виде документов или в виде устных договренностей) стали плохо описывать потребности.
как посчитаете правильным, так и cделайте. многие вообще живкт без оформленного процесса непрерывного улучшения (CSI), вполне обходясь локальными улучшениями без огласки и тушением пожаров.
В случаях низкого доверия, да, жестко выставляет. Если доверия побольше, то идет обсуждение. Бывают случаи, когда заказчику все равно, единственное его требование: «чтобы все работало», и тогда приходится выпытывать его процессы и операции, которые поддерживаются ИТ-системами, и из этого получать требования к ИТ.
Каждый решает для себя сам, чем ему пользоваться. Считаете, что для Вас более приемлем lean и готовы сделать его адаптацию под не производство, делайте. Другие выберут ITIL, а третьи поймут что им нужен только COBIT, т.к. внешние аудиты, четвертые выберут IT4IT, а пятые придумают свой уникальный фреймфорк, а еще кто-то скажет, что процессы — это бюрократия и они им не подходят.
«процент расходования годового бюджета ИТ» — о чем может сказать?
отклонение от ожидаемых показателей верхне уровнево показывает, что есть риски или что денег не хватит, и компании придется тратить резервы, или наоборот деньги останутся замороженными, а вообще нужно лезть в подробности и разбираться, что идет не так
рейтинг удовлетворенности по закрытым инцидентам» — где использовать,?
индикатор, что работа ИТ не соотвествует ожиданиям заказчиков, нужно встречаться и разговаривать для определения это ожидания завышены, или что-то изменилось в среде заказчика и старые SLA (не важно в виде документов или в виде устных договренностей) стали плохо описывать потребности.
«количество реализованных предложений об улучшении из регистра процесса непрерывного улучшения» — как быть с неприемлемыми или отозванными предложениями?
как посчитаете правильным, так и cделайте. многие вообще живкт без оформленного процесса непрерывного улучшения (CSI), вполне обходясь локальными улучшениями без огласки и тушением пожаров.
вообще-то это заказчик выставляет вам цели и критерии оценки их достижения.
В случаях низкого доверия, да, жестко выставляет. Если доверия побольше, то идет обсуждение. Бывают случаи, когда заказчику все равно, единственное его требование: «чтобы все работало», и тогда приходится выпытывать его процессы и операции, которые поддерживаются ИТ-системами, и из этого получать требования к ИТ.
Не стоит бороться с «фатальным недостатком», лучше взять наработанные в других сферах методики. Тот-же кайдзэн полностью покрывает «эксплуатацию ИС». А проекты/микропроекты развития, даже в гибкой форме вполне самодостаточны в плане оценки результата.
Каждый решает для себя сам, чем ему пользоваться. Считаете, что для Вас более приемлем lean и готовы сделать его адаптацию под не производство, делайте. Другие выберут ITIL, а третьи поймут что им нужен только COBIT, т.к. внешние аудиты, четвертые выберут IT4IT, а пятые придумают свой уникальный фреймфорк, а еще кто-то скажет, что процессы — это бюрократия и они им не подходят.
«риски или что денег не хватит» — для чего нужны?
«работа ИТ не соотвествует ожиданиям заказчиков» — для чего? В SLA это не прописано?
«процесс непрерывного улучшения» — зачем нужен? Если на него нет спроса.
ITIL, COBIT, IT4IT — предполагают что IT это нечто обособленное. Если компания и ее продукты чистый IT — их вполне достаточно.
В большинстве крупных компаний IT это одна из составляющих, тесно с переплетенная с остальными. IT-шные методологии плохо ложатся на весь бизнес, а бизнесовые (тот же lean) в большей части покрывают IT.
Про «Цифровую трансформацию» каждый утюг вещает. А она предполагает еще более тесное переплетение, и самое главное — единое управление.
«работа ИТ не соотвествует ожиданиям заказчиков» — для чего? В SLA это не прописано?
«процесс непрерывного улучшения» — зачем нужен? Если на него нет спроса.
ITIL, COBIT, IT4IT — предполагают что IT это нечто обособленное. Если компания и ее продукты чистый IT — их вполне достаточно.
В большинстве крупных компаний IT это одна из составляющих, тесно с переплетенная с остальными. IT-шные методологии плохо ложатся на весь бизнес, а бизнесовые (тот же lean) в большей части покрывают IT.
Про «Цифровую трансформацию» каждый утюг вещает. А она предполагает еще более тесное переплетение, и самое главное — единое управление.
«риски или что денег не хватит» — для чего нужны?
«работа ИТ не соотвествует ожиданиям заказчиков» — для чего? В SLA это не прописано?
«процесс непрерывного улучшения» — зачем нужен? Если на него нет спрос
В игру «зачем?» можно до бесконечности играть. Я считаю, что уже достаточно пояснил мысль, заложенную в статье.
ITIL, COBIT, IT4IT — предполагают что IT это нечто обособленное.
Вы не правы, но обсуждение этих вопросов к статье не относится.
В игру «зачем?» можно до бесконечности играть.
Что возвращает нас к изначальному комментарию. А должно было вывести на «цель» всей компании.
Вы хотите, чтобы я додумал ход мыслей автора статьи, для какой именно среды компании сформулироавны ключевые показатели в этой статье?
Нет, я планировал дать читателям дискуссии видение процесса формирования целей. Без понимания которого, на практике, невозможно создать «Сбалансированную систему показателей». Которая, на мой взгляд, подменяет стратегию «Карго-культом» (судя по статьям).
По нормальному «система показателей» должна быть включена в стратегию, как один из механизмов управления ей.
UPD: У любой коммерческой компании всего одна цель — Добывать деньги акционерам.
По нормальному «система показателей» должна быть включена в стратегию, как один из механизмов управления ей.
UPD: У любой коммерческой компании всего одна цель — Добывать деньги акционерам.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Сбалансированная система показателей для ключевых показателей IT