Портал №1 по управлению цифровыми
и информационными технологиями

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

direction_2future

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

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

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

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

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

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

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

Учебные курсы и сертификация на русском языке
специалистов по ИТ-менеджменту

Комментариев: 2

  • Андрей

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

  • Анатолий

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

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

    Например,

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

    Шаг 2

    Шаг N -1

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


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM