«Integrated Measurement- KPIs and Metrics» - обзор

By | Published пятница, 3 июля 2015 г.


«Integrated measurement - KPIs and Metrics for ITSM».

Author: Daniel McLean
Publishers: ITGP
ISBN13: 9781849283830
Pages: 186
Published: 21 May 2013

Автор весьма плодовит в написании бизнес-романов на тему ITSM, и уже выпустил четыре (включая эту) книги. Главный герой - Крис, находится под угрозой увольнения, и ему необходимо успешно выполнить проект, чтобы сохранить работу. В качестве испытания Крису предложено уточнить метрики и отчетность для сервис-деска.

Мне не удалось уловить что понимает автор под integrated measurement. Ожидал увидеть что-то похожее на balanced scorecard, кстати, на обложке есть картинка напоминающая карту сбалансированных показателей, но в тексте об этом ничего нет. Если вы понимаете разницу между метрикой и KPI, а также то, что разрабатывая систему измерений следует отталкиваться от потебностей бизнеса и получателей отчетности, то можно и не читать.

Оценка - 2/5.

Несколько цитат, что мне понравились:
«...bringing impacted people into the decision process is essential, because it gives them a feeling of ownership.»
«In an ideal, academic world,” said Art. “I agree that KPIs should be measured against business or operational objectives. However, we live in the real world, and many of those objectives are nearly impossible to directly measure. How can you advocate we focus on objectives we cannot measure”? “Great question,” I said. “The key is to understand that any objective has certain things that must happen for it to be achieved. These are the critical success factors, or CSFs. If you can’t directly measure the achievement of something, measure the progress towards achieving the CSFs required to make it happen.»
«There are six things we must keep in mind when dealing with KPIs, whether they are for the service desk or the entire company, we need to consider them in a specific order, just like People, Process and Tools. I put a new slide up on the screen.
  • Understand what the business strategy or objective is, before worrying about how to measure it.
  • Decide on how to measure the data, before worrying about how to collect it.
  • Decide on how to collect the data, before worrying about how to analyze it.
  • Decide on how to analyze the data, before worrying about what is actionable.
  • Understand what your users need to take action, before designing how you report on it
  • If at any point your KPI stops making sense, either you don’t need it, or you didn’t do a good job on the previous steps.»

Posted in | Leave a comment

Новая сертификация по ITIL от AXELOS - ITIL Practioner

By | Published пятница, 3 апреля 2015 г.

13 марта AXELOS объявила о выходе новой сертификации под названием ITIL Practioner, которая является промежуточным звеном между Foundation и Intemediate экзаменами, и призвана оценить знания специалиста в области применения ITIL на практике.

Так видит AXELOS фокус сертификации Practitioner:
ITIL Practitioner will focus on:
  • Giving practical guidance on how individuals can leverage Continual Service Improvement (CSI), a fundamental lifecycle stage in ITIL, to maximize the benefits of its adoption and adaption
  • Aiming to improve the capability of individuals throughout the business, to adopt and adapt ITIL in their day to day roles for maximum business benefits
  • Making use of further evolved technological capabilities - such as automation, real-time reporting and Cloud computing - to increase the quality of service design and the efficiency of service delivery
  • Leveraging other philosophies, frameworks, good practices and methodologies - including e.g. Lean, DevOps, Agile and SIAM - to further enhance the value of ITSM.

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

Интересно, что среди заявленных особенностей сертификации упомянуты смежные методики и своды знаний - Lean, DevOps, Agile и SIAM. Будет интересно посмотреть как AXELOS видит увязывание этих техник с ITIL на практике, материалов на эту тему не так много.

Само название сертификации выглядит тоже привлекательно для тех кто ищет некого статуса, а не просто сертификата о сдаче экзамена. До появления Practioner, по сути, не было промежуточного уровня с названием типа Specialist, Auditor, Practitioner  или еще как-то. Или Expert, или кто-то в пути, но без «красивого» титула.

Интересные ссылки:
Оценка сертификации от Стюарта Рэнса (Stuart Rance) 
FAQ по сертификации (en)
FAQ по сертификации (ru) - переведен командой Cleverics

Posted in , | Leave a comment

Business Impact Analysis / Risks assessment - что сначала?

By | Published пятница, 20 февраля 2015 г.

Вопрос о том, что сначала выполнять: анализ влияния (аварий) на бизнес или анализ рисков (угроз), периодически возникает среди специалистов по управлению непрерывностью бизнеса. Различные своды знаний и методологии предлагают как очередность «BIA-RA», так и «RA-BIA».

NFPA 1600 «Standard  on disaster/emergency management and business continuity programs» (Edition 2013)
«Chapter 5 Planning
......
5.2 Risk Assessment
5.3 Business Impact Analysis»

«Good Practice Guidelines 2013 Global Edition: A guide to Global Good Practice in Business Continuity»
В редакции 2013 года GPG не указывает порядок выполнения этих активностей, но последовательность описания все же намекает на видение авторов: сначала BIA, потом анализ угроз.

Автор книги «Becoming resilient», известный блоггер Dejan Kosutic
«Which comes first – risk assessment or business impact analysis? This is a question I hear a lot – ISO 22301 actually allows both approaches. However, I prefer to do risk assessment first because this way, you will have a better impression of which incidents can happen (which risks you’re exposed to), and therefore be better prepared for doing the business impact analysis (which focuses on consequences of those incidents); further, if you choose the asset-based approach for risk assessment (see section 6.2), you will have an easier time identifying all the resources later on in the business impact analysis. What you definitely shouldn’t do is perform risk assessment and business impact analysis at the same time.»

 На мой взгляд, разумно сначала выполнить BIA для того, что определить критичные, с точки зрения очередности восстановления, бизнес-функции, а потом уже выполнить анализ угроз. Прежде всего, в рамках BIA нас не интересует природа инцидента, который нарушил работу процесса, более важно понимать к каким последствиям это приводят.

Зачастую, компания не располагает таким количеством ресурсов, чтобы охватить все бизнес-процессы и связанные с ними ресурсы в рамках business continuity инициативы. Приоритезация бизнес-функций (бизнес-процессов) позволяет изучать угрозы сузив область охвата анализа: начать с тех функций, что «критичней», и не подвергать исследованию все активности бизнеса, что было бы нерационально.

 Несмотря на логичность такой последовательности, я все же вижу один недостаток, который в «теории» не должен существовать, но на практике встречается весьма часто.

Выбор правильного способа восстановления бизнес-функции зависит от выдвинутых требований бизнеса ко времени восстановления. В ходе BIA это определяется показателем MTPD (Maximum Tolerable Period of Downtime). Если используется количественный подход к оценке влияния простоя, то, по идее, нужно получить  стоимость потерь для того, чтобы определить приемлемость или неприемлемость простоя для какой-то точки времени. В моей практике, бизнес либо не располагает такой информацией, либо весьма смутно представляет чего стоит простой конкретной активности для всей компании, а представители бизнеса настаивают на мгновенном восстановлении. Таким образом, показатель MTPD достаточно подвижен, и, если все же удается донести мысль, что мгновенное восстановление нерационально - например, потому что для этого нужно вложить огромные деньги, то в итоге MTPD будет определятся не риск-аппетитом компании, а сравнением затрат на DR-решение (т.е. на контрмеру) по отношению к стоимости простоя. Но контрмера зависит от риска, влияние которого мы пытаемся уменьшить, соответственно без понимания риска нужно либо выбирать одно решение для всех ситуаций, что явно нелучший вариант, либо параллельно изучать угрозы для бизнес-процесса. В итоге, определение MTPD превращается в «торг» между, например, ИТ (как владельцем ресурса) и бизнесом, где ИТ предлагает защитить бюджет под решение обеспечивающее восстановление ИТ-системы в заданное бизнесом время. А бизнес, понимая все расходы, либо расслабляет это время, если не готов оплатить предложенную смету, либо подтверждает готовность объяснить почему восстановление должно быть выполнено именно в указанное время.

Выбор «правильной» последовательности это решение, которое нужно принять индивидуально в каждом проекте. Важно понимать все последствия от выбранного порядка действий.

Posted in , | Leave a comment

ITSM: структура организации, роли и обязанности

By | Published пятница, 10 октября 2014 г.

Книжный магазин института BCS (http://shop.bcs.org/index.asp) анонсировал серию посвященную карьере в области ITSM профессий. На данный момент, выпущены книги «Business Relationship Manager», «Service Desk and Incident Manager», «Problem Manager».

«Business Relationship Manager» уже прочитан, на днях напишу о своих впечатлениях. Книжка о менеджере службы поддержки пользователей на пути к прочтению. Но больше интереса как раз к той, которая, пока что, в руки не попала: о работе менеджера проблем.

Тема построения ИТ-организации, распределения ролей и обязанностей, на мой взгляд, не особо раскрыта в литературе. Из того, что есть на рынке:

«Designing and Transforming IT Organizations»
     Author:Job ten Hagen
     Publisher:TSO (The Stationery Office)
'Designing and Transforming IT Organizations' is the introduction book to a series of (initially) six books that will provide background considerations, theory, instructions, and practical guidance for setting up organization structures in the context of improvement projects.
     Мое мнение: считать практическим руководством трудно, скорее основательное введение в вопросы создания ИТ-организации с точки зрения существующих подходов и практик.

«Service Level Management and the Service Manager»
    Author:William Redmond, Job Ten Hagen, Jan Van Bon
    Publisher:TSO (The Stationery Office)
'Service Level Management and the Service Manager ' is the second book of a series of (initially) six books that provide background considerations, theory, instructions, and practical guidance for setting up organization structures in the context of improvement projects'.
С нетерпением жду «COBIT 5 for Organizational Structures», как книги по одному из enabler.



Posted in | Leave a comment

Capability vs. Maturity assessment

By | Published четверг, 9 октября 2014 г.

В последней рассылке новостей от Центра исследований Анри Тюдора, посвященной методологии оценки процессов TIPA, есть ссылка на интервью с Аленом Рено (Alain Renault), где обсуждается разница между «capability» и «maturity» оценкой.

Вопрос и в самом деле интересный.Сами термины обычно переводятся следующим образом: capabilty - возможность, способность; maturity - зрелость. Коллеги из Cleverics провели замечательный вебинар, где эту тему раскрыли. Суть такова, что в отношении процессов корректно использовать термин «возможность», и, соответственно, проводить оценку возможностей процесса, а вот термин «зрелость» используется для оценки организации (или подразделения). Тем не менее, масса статей по тематике ITSM,  да и просто специалисты, используют выражение «оценка зрелости процессов».

Возвращаясь к интервью и методологии TIPA. Ален указывает на важное отличие (или свойство) оценки зрелости: «Maturity Assessments go a bit further and group processes in levels of maturity, which enables to get a single rating for a set of assessed processes in an organization». Таким образом, если выполнены некие условия для группы процессов, то организация оценивается как получившая определенный уровень зрелости. А вот процессы, по отдельности, могут быть оценены различным уровнем возможностей.

Зачем оцениваются возможности процессов? Что определяет полученная оценка? Уровень возможностей процесса - характеристика процесса, определяющая его способность соответствовать текущим и будущим бизнес-целям (ISO/IEC 15504-1:2004).
 Важный момент, который, по моему опыту, упускают заказчики сервисов диагностики или обследования возможностей процессов ITSM: полученный высокий уровень возможностей не гарантирует, что процесс будет в 100% случаев обеспечивать качественный результат своей работы. Высокий уровень возможностей всего лишь позволяет сделать предположение, что процесс с большей долей вероятности способен достичь поставленных целей, чем, если бы этот же процесс имел низкий уровень зрелости.

Публикация «COBIT 5: The Assessor's Guide» (раздел 1.6 The COBIT Assessment Programme Report) четко указывает на этот аспект:
«The report is not an attestation or assurance report on the effectiveness of the process or its internal controls. It is intended as an internal report to provide information for enterprise management use only and should not be relied on by others. Its purpose is to provide information about the capability of enterprise processes and to give management some indication of processes that need improvement.»


Posted in | Leave a comment

ISACA Journal Vol.4, 2014 - Governance and Management of Enterprise IT (GEIT)

By | Published среда, 6 августа 2014 г.

Свежий выпуск ISACA Journal (Vol.4, 2014) посвящен теме ИТ-руководства.
Помимо традиционного материала для аудиторов, есть несколько статей интересных и не-аудиторам:

Leveraging Metrics for Business Innovation (Yo Delmar, CISM, CGEIT). Есть перевод на русский .
Ключевое послание - результативные метрики критичны для обеспечения согласованности (alignment) ИТ и бизнеса,  повышают операционную эффективность, а также должны стать источником «репозиционирования» ИТ как источника инноваций и конкурентного преимущества. Достижение этих целей лежит в области выбора метрик наиболее сильно связанных со стратегией компании и показателями ее производительности (эффективности).
Автор предлагает обратить особое внимание на пять аспектов проектирования полезных метрик:
  • Тон задают стратегия, цели предприятия и ключевые целевые показатели результативности.
  • Разрабатывайте метрики с учетом динамичности среды.
  • Создавайте ключевые метрики, которые будут полезны в рамках разных инициатив
  • Не забывайте про простоту внедрения
  • Сохраняйте открытость к изменениям
Не скажу, что статья совсем оригинальная, но некоторые идеи можно использовать в качестве требований при разработке метрик.

Align Business Initiatives and IT Solutions  (Ikumi Miyagi, CGEIT, CRISC, Hiroshi Monden, CISA, CIA, CRMA, Mitsuko Azuma, CISA, Reiso Kimura, CISA, CIA, Masatoshi Aramaki, CISA, CRISC, CIA, Kan Hara, CISA, CPA, and Takashi Ishijima, Ph.D., CPA)

Извечная тема согласованности ИТ и бизнеса. Японские коллеги сообщают, что 70% ИТ-проектов в Японии признано проваленными, а причины их кроются в следующем: различное видение проекта у членов проектной команды и ключевых заинтересованных сторон ввиду нечеткого определения целей проекта; ожидания менеджмента не определены на первой фазе ИТ-проекта (видимо имеются в виду инициация проекта). Предлагается решить эти проблемы с помощью каскада семинаров, начиная с топ-менеджмента до исполнителей, на каждом этапе передавая результаты в качестве входных данных для семинара более низкого уровня.
Вообще, статья сильно напомнила табличку COBIT про pain points, а также каскадирование stakeholders needs в сами знаете что.
Меня заинтересовали ссылки на некую методологию «Proper Project Plan Creation Methodology, SUSD», откуда и якобы берется решение извечных проблем. Результаты поиска небогаты, но нашелся интересный документ http://dream-biz.jp/Reiso_Kimura_Report2012.pdf . Указан один из авторов статьи.

The Business Case as an Operational Management Instrument—A Process View (Kim Maes, Steven De Haes, Ph.D., and Wim Van Grembergen, Ph.D). 
Хорошо подготовленный бизнес-кейс повышает улучшает качество принимаемых решений об инвестициях, что очевидно; тем не менее, с процессной точки зрения, организация деятельности по подготовке бизнес-кейсов зачастую не очень качественна. 
Статья содержит мнения экспертов относительное практик, которые целесообразно использовать при подготовке бизнес-кейсов. Интересное отображение предложенных практик подготовки бизнес-кейсов на процессы COBIT 5 APO04 - Manage Innovation и BAI01 - Manage Programmes and Projects.
 Сделал себе пометку вернуться при случае (подготовки бизнес-кейса) и опробовать техники, которые обозначены как наиболее результативные.

Posted in , | Leave a comment

Видеоролики про COBIT - «COBIT Distilled»

By | Published вторник, 5 августа 2014 г.

Компания Orbus Software (http://www.orbussoftware.com/), которая регулярно спамит присылает мне письма об обучающих материалах по enterprise architecture, также записала серию роликов о COBIT 5 под названием «COBIT Distilled».

Каждый из роликов это двухминутный рассказ об одном из элементов COBIT. Довольно интересный материал для визуальной демонстрации понятийного аппарата и принципов методологии.

На данный момент, освещены следующие темы:

  • What is COBIT 5?
  • What are the Benefits of COBIT?
  • Dangers of Avoiding COBIT 5
  • Comparing COBIT 4.1 to COBIT 5
  • Creating value with COBIT 5
  • COBIT 5 Principles
  • COBIT 5 Goals Cascade
  • COBIT 5 Enablers
  • COBIT 5 Enabler Dimensions and Performance Management
  • COBIT 5 Principle One
  • COBIT 5 Principle Two

Posted in | Leave a comment
Блог Романа Лобуса © 2015. Технологии Blogger.

Swedish Greys - a WordPress theme from Nordic Themepark. Converted by LiteThemes.com.