CSI: организация и работа с реестром улучшений

direction_2future

Практика постоянного улучшения требует определённой технологии. С чего начать? Как управлять улучшениями? Своим опытом и наработками в этом направлении решил поделиться уже знакомый нам Стюарт Рэнс. Автор выделил четыре области, которые подробно рассматривает в своей заметке.

Во-первых, для начала нужно составить реестр, наполнив его записями об улучшениях. Где их взять? Помимо результатов вашего собственного исследования и наблюдения, есть множество других источников: жалобы заказчиков и обратная связь с ними, пожелания ИТ-команд — как со стороны эксплуатации, так и со стороны развития, реестры рисков, процессные KPI и оценки процессов, зарегистрированные проблемы, регулярные обзоры по управлению ИТ-услугами.

Во-вторых, нужно структурировать реестр, снабдив каждую запись об улучшении необходимой информацией. Не нужно превращать реестр в сложную штуковину — вести его можно и в Excel, используя следующие (но и не только) поля:

  • "id" - уникальный номер каждой записи в реестре.
  • "Описание" — что это за улучшение.
  • "Польза" — почему это улучшение необходимо. Имеет смысл выставлять признак для каждого улучшения по простой шкале: "Большая / Средняя / Маленькая".
  • "Срочность" — к какому сроку улучшение необходимо. Это может быть привязка к какому-либо конкретному ожидающемуся событию. В других случаях — определяться размером денежных потерь. Аналогично используем шкалу "Высокая / Средняя / Низкая".
  • "Длительность" — сколько займёт реализация улучшения. Грубой оценки здесь достаточно, ведь главный вопрос — это потребует недели, месяца или года?
  • "Стоимость" — насколько улучшение дорого. Достаточно оценить её по уже принятой шкале: "Высокая / Средняя / Низкая".
  • "Владелец" — на ком будет лежать ответственность за последующий анализ и принятие решений по данному улучшению.
  • "Дата регистрации" — можно увидеть, с какого момента запись находится в реестре.
  • "Статус" — для отслеживания, что происходит с улучшением.
  • "Доля выполнения" — для улучшений, требующих большого количества времени.

В-третьих, нужно выработать практику отбора реализуемых улучшений. После того, как вы заполните реестр — внезапно! — станет ясно, с каких улучшений стоит начать в первую очередь. Можно, конечно, создать правила отбора, но, кажется, всё понятно и так:

  • улучшения с признаками "большая польза", "высокая срочность", "низкая стоимость" сразу отправляются в разработку;
  • на улучшения с "большой пользой", "высокой срочностью", но при этом "средней" или "высокой" стоимостью нужно посмотреть более внимательно, возможно, создать бизнес-кейс, защитить бюджет на его реализацию;
  • улучшения с "маленькой пользой" и "высокой стоимостью", обычно, сразу исключаются из дальнейшего рассмотрения — в корзину;
  • оставшиеся можно проранжировать по "пользе", "срочности" и "стоимости" и отобрать самые ценные.

В-четвёртых, нужно управлять улучшениями. Единственно верного пути здесь нет. Важно, чтобы улучшение, которое было затеяно и реализовано, принесло пользу. Какой бы подход (Agile, управление проектами и пр.) вы не использовали, необходимо сделать итоговый обзор по завершении улучшения. Обзор должен не просто констатировать факт реализации, но и давать количественную оценку той пользы, что была принесена улучшением.

ITIL ITIL Practitioner — новый учебный курс 2016

Правильный следующий шаг после ITIL Foundation.
 

Узнайте больше!

Комментарии и мнения

  1. Андрей

    С одной стороны странно, что такая глобальная вещь как посотянное улучшение сужена до работы с реестром. С другой строны понятно, поскольку реестр единственная более или менее конкретная вещь, присутствующая в описании CSI. Всё остальное — набор стандартных кричалок типа цикла Деминга, Agility и т.д. Понятно, что с Agility никто спорить не будет, но ясности по поводу того, что, кто и как конкретно должен делать всё это не вносит. Да и с реестром тоже не всё слава Богу — если заменить "улучшение" на "инициативу", то получим Project Management в чистом виде со всеми его оценками рисков, приоритецацией инициатив и т.д. Путаница даже на уровне определения CSI — в Библиотеке оно обозначено как стадия/этап (stage). Но у этапа есть начало и есть окончание, что (окончание) не согласуется с постоянным(continual). Далее, CSI — это что? Группа процессов? Но описанные для него процессы явно присутствуют в других группах и я сомневаюсь, что кто-то будет организовывать отдельные копии именно для CSI. Стратегия CSI будет разрабатываться в рамках Service Strategy, мониторинг будет осуществляться в рамках общего мониторинга, ну и так далее. Короче:))), я тут решил порассуждать на эту тему немного, вроде правила портала не запрещают давать ссылки на материалы.

  2. Анатолий

    У меня "узкий" вопрос. Прошу высказаться тех, у кто на практике использует в своей работе "процесс" CSI.

    Меня интерует, каки шаги (workflow) используются для "записи об улучшении", с описанием, что делается на каждом шаге.

    Например,

    Шаг 1 — Регистрация улучшения

    Шаг 2

    ...

    Шаг N -1

    Шаг N — Улучшение реализовано

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Ближайшие мероприятия

Зарегистрируйтесь, чтобы получить больше полезных знаний:

ИЮН
26