Практика постоянного улучшения требует определённой технологии. С чего начать? Как управлять улучшениями? Своим опытом и наработками в этом направлении решил поделиться уже знакомый нам Стюарт Рэнс. Автор выделил четыре области, которые подробно рассматривает в своей заметке.
Во-первых, для начала нужно составить реестр, наполнив его записями об улучшениях. Где их взять? Помимо результатов вашего собственного исследования и наблюдения, есть множество других источников: жалобы заказчиков и обратная связь с ними, пожелания ИТ-команд – как со стороны эксплуатации, так и со стороны развития, реестры рисков, процессные KPI и оценки процессов, зарегистрированные проблемы, регулярные обзоры по управлению ИТ-услугами.
Во-вторых, нужно структурировать реестр, снабдив каждую запись об улучшении необходимой информацией. Не нужно превращать реестр в сложную штуковину – вести его можно и в Excel, используя следующие (но и не только) поля:
- "id" – уникальный номер каждой записи в реестре.
- "Описание" – что это за улучшение.
- "Польза" – почему это улучшение необходимо. Имеет смысл выставлять признак для каждого улучшения по простой шкале: "Большая / Средняя / Маленькая".
- "Срочность" – к какому сроку улучшение необходимо. Это может быть привязка к какому-либо конкретному ожидающемуся событию. В других случаях – определяться размером денежных потерь. Аналогично используем шкалу "Высокая / Средняя / Низкая".
- "Длительность" – сколько займёт реализация улучшения. Грубой оценки здесь достаточно, ведь главный вопрос – это потребует недели, месяца или года?
- "Стоимость" – насколько улучшение дорого. Достаточно оценить её по уже принятой шкале: "Высокая / Средняя / Низкая".
- "Владелец" – на ком будет лежать ответственность за последующий анализ и принятие решений по данному улучшению.
- "Дата регистрации" – можно увидеть, с какого момента запись находится в реестре.
- "Статус" – для отслеживания, что происходит с улучшением.
- "Доля выполнения" – для улучшений, требующих большого количества времени.
В-третьих, нужно выработать практику отбора реализуемых улучшений. После того, как вы заполните реестр – внезапно! – станет ясно, с каких улучшений стоит начать в первую очередь. Можно, конечно, создать правила отбора, но, кажется, всё понятно и так:
- улучшения с признаками "большая польза", "высокая срочность", "низкая стоимость" сразу отправляются в разработку;
- на улучшения с "большой пользой", "высокой срочностью", но при этом "средней" или "высокой" стоимостью нужно посмотреть более внимательно, возможно, создать бизнес-кейс, защитить бюджет на его реализацию;
- улучшения с "маленькой пользой" и "высокой стоимостью", обычно, сразу исключаются из дальнейшего рассмотрения – в корзину;
- оставшиеся можно проранжировать по "пользе", "срочности" и "стоимости" и отобрать самые ценные.
В-четвёртых, нужно управлять улучшениями. Единственно верного пути здесь нет. Важно, чтобы улучшение, которое было затеяно и реализовано, принесло пользу. Какой бы подход (Agile, управление проектами и пр.) вы не использовали, необходимо сделать итоговый обзор по завершении улучшения. Обзор должен не просто констатировать факт реализации, но и давать количественную оценку той пользы, что была принесена улучшением.
С одной стороны странно, что такая глобальная вещь как посотянное улучшение сужена до работы с реестром. С другой строны понятно, поскольку реестр единственная более или менее конкретная вещь, присутствующая в описании CSI. Всё остальное – набор стандартных кричалок типа цикла Деминга, Agility и т.д. Понятно, что с Agility никто спорить не будет, но ясности по поводу того, что, кто и как конкретно должен делать всё это не вносит. Да и с реестром тоже не всё слава Богу – если заменить "улучшение" на "инициативу", то получим Project Management в чистом виде со всеми его оценками рисков, приоритецацией инициатив и т.д. Путаница даже на уровне определения CSI – в Библиотеке оно обозначено как стадия/этап (stage). Но у этапа есть начало и есть окончание, что (окончание) не согласуется с постоянным(continual). Далее, CSI – это что? Группа процессов? Но описанные для него процессы явно присутствуют в других группах и я сомневаюсь, что кто-то будет организовывать отдельные копии именно для CSI. Стратегия CSI будет разрабатываться в рамках Service Strategy, мониторинг будет осуществляться в рамках общего мониторинга, ну и так далее. Короче:))), я тут решил порассуждать на эту тему немного, вроде правила портала не запрещают давать ссылки на материалы.