Всё о метриках, KPI, CSF, а также об измерении услуг, процессов, технологий. И про CleverKPI.
Компания Pink Elephant ведёт занимательный проект – сбор статистических данных о реальных значениях процессных метрик. Принять участие в опросе может любая компания, а результаты периодически публикуются в блоге компании. Сегодня появились обновлённые данные по процессу управления изменениями.
Немногим ранее Дима опубликовал свои мысли по поводу измерения Incident Management’а и придумал интересную метрику (https://realitsm.ru/2011/12/measuring-incident-management/). Как уже говорилось, выросла она не на пустом месте, а в результате реальной потребности заказчика – в организации задумались о системе оценки персонала ИТ. Показатель по нарушению сроков инцидентов должен был войти в эту систему, и заказчика очень не устраивало то, что фактически ответственность за нарушение срока падала на последнюю рабочую группу, которая участвовала в обработке инцидента. А так как показатели должны были влиять на зарплату сотрудников, то можете себе представить, с какой аккуратностью подходили к созданию метрик. Наличие в системе одного такого «несправедливого»…
Компания Volkswagen объявила об изменении режима работы корпоративной почты: внутренние письма не будут приходить на Blackberry сотрудников в нерабочее время. Правда, только в Германии и только для членов профсоюза.Крупнейшая ИТ-компания Франции, ATOS, планирует полностью отказаться от внутренней электронной почты с 2014 года. Компания Henkel сообщила о том, что в период с Рождества до Нового года электронная почта будет использоваться во внутренней переписке только для экстренных случаев. Все это стало частью одной публикации BBC, хотя мне кажется, что эти три новости суть проявления очень разных тенденций. ATOS планирует использовать корпоративные социальные сети для внутренних коммуникаций. Мне кажется, что это отчасти дань…
Несколько вредных советов из собственного опыта: Не готовьте повестку. Это позволит обсуждать множество вопросов, не имеющих отношения к заявленной теме. Времени уйдёт масса, зато все хорошо поговорят о наболевшем. Не назначайте докладчиков. Гораздо интереснее все вопросы обсуждать всем вместе – наверняка каждому найдётся что сказать. Особенно удобно, когда говорят одновременно несколько человек, это повышает активность и не даёт заснуть. Не принимайте решения. Намного дольше можно обсуждать способы, варианты, механизмы и нюансы; например, в ходе еженедельной оперативки можно спроектировать два-три процесса управления, ведь состав участников позволяет ставить себе такие амбициозные задачи, а совещание всё равно станет многочасовым. Чаще уходите в детали….
Некоторое время назад я предлагал обсудить различные аспекты оценки и измерения ИТ-процессов. Спасибо всем, кто высказался в обсуждении! Чуть позже я включил более-менее структурированное описание каждого направления оценки в свою колонку на itsmportal.com, посвящённую той же теме. В обсуждение колонки вступил Ян ван Бон, у которого, как обычно, нашлась в запасе пара слов. И вот она,эта пара слов: "Most important: there is no such thing as process maturity. Only organizations or functions of organizations can have a 'maturity'." Что в переводе на русский означает: "Не бывает у процессов зрелости. Зрелость бывает только одна – зрелость организации, в крайнем случае – какой-нибудь её функции."…
Продолжаем публикацию находок по измерению процессов управления ИТ, начатую в заметке «Измеряем Problem management». Примеров метрик по процессу управления инцидентами множество. Пожалуй, это самый изученный с точки зрения измерения процесс ITSM. Однако в очередном проекте мы в который раз столкнулись с вопросом: как реализовать метрику, которая бы показывала долю ответственности заданной группы поддержки в нарушении сроков обработки инцидентов. Вопрос давний и непростой. Сложности связаны с тем, что в обработке одного инцидента могут принять участие несколько групп (за счёт функциональной эскалации). Традиционное решение «вешать просрочку» на последнюю группу, обрабатывавшую инцидент, обладает рядом очевидных минусов. В самом деле, эта группа могла получить…
Боб Льюис (IT Catalysts) написал озаглавленную так статью в блоге на infoworld.com на тему связи целей и метрик. Из своего опыта, Боб выделяет четыре ошибки при выборе процессных метрик, которых следует избегать: Измерять то, что нужно, неточным образом Измерять не то, что нужно Отказываться измерять действительно важные вещи Мотивировать сотрудников на основании процессной метрики Как бы вам не хотелось совершить последнюю ошибку – делать этого не стоит. Сообразительные сотрудники (такие же, как и SMART-цели) почти всегда смогут "обыграть" систему измерения, вне зависимости от того, какие метрики вы им навяжете. Подробности читайте в статье Боба.
Журнал РБК в декабрьском номере опубликовал очередное исследование, в этот раз – рейтинг эффективности крупнейших российских продуктовых ритейлеров по итогам первой половины 2011 года. Чем хорош этот список: в нём эффективность оценивается всего по двум понятным и прозрачным критериям: чистая выручка на одного работника чистая выручка на 1 кв.м. торговой площади В первой пятёрке встречаются (что неудивительно) такие компании как "Ашан Россия" и "Метро Кэш энд Керри Россия". Можно предположить, что продуктовый ритейл достаточно зависим от информационных технологий, особенно когда число магазинов измеряется десятками, число сотрудников тысячами, ассортимент – десятками тысяч, а география вообще непонятно как измеряется. В задаче спрашивается…
У меня сложилась простая, полная и непротиворечивая картина мира. Опять. На этот раз – мира оценки процессов. Посмотрим, сколько продержится. Вот она. Оценка процессов выполняется для того, чтобы получить представление либо о потенциале процессов (что они могут), либо о фактической успешности (что они смогли). Потенциал оценивается с двух точек зрения – функциональных возможностей и уровня организации, соответственно capability и maturity. Проекты "внедрения процессов" направлены именно на формирование этого потенциала. В дальнейшем он может развиваться в результате работы механизмов оценки и совершенствования, причем сами эти механизмы – тоже частный случай capability, свойственной определенному уровняю maturity. Оценку Capability и Maturity можно выполнять…
Джон Рив в авторской колонке на портале itsmportal.com опубликовал свой взгляд на один из шагов цикла Деминга – Проверку (Check): Цикл Plan-Do-Check-Act все уважают, потому что он вполне разумен и проще уж не получится. И всё же, хотя собственных недостатков у него нет, он провоцирует ошибки. Каждый из четырёх шагов отлично выполняется при запуске проекта, или при выполнении значительного изменения. Однако, после успешного выполнения первого оборота этого цикла, внимание к этапам процесса немедленно спадает, и PDCA становится BAU (Business as usual, рутинным выполнением работы) Выполнению проверок уделяется мало усилий. Планирование всегда делается качественно, потому что это действительно интересное занятие, которое…
Роб Ингланд, на которого многие сделали ставку в книжном конкурсе, порадовал нас официальным выпуском своего свода знаний по управлению услугами. Про эту идею мы слышали уже давно, а теперь пилотная версия Tipu доступна всем. Роб использовал лучшие практики ITSM описанные в ITIL V3, СOBIT 4.1 и в других сводов знаний и стандартов, чтобы описать целостную идеальную модель из практик и функций, обеспечивающую управление услугами – в любой отрасли. С одной стороны, во вступлении указано, что Tipu является лишь "руководством", а не "законом" для построения системы управления услугами. С другой: В Tipu представлены почти все лучшие практики и функции управления услугами. Все они являются необходимыми. Если хотя…