Что такое проектирование услуги и почему его пропуск дорого обходится

Зачем проектирование сервиса

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

ITIL описывает её от обратного, и это описание стоит прочесть целиком: без проектирования услугиУслугаСпособ дать потребителю нужный результат, не перекладывая на него управление затратами и рисками.ITIL 4, книга ITIL Foundation выходят дорогими в эксплуатации и склонными к отказам, ресурсы тратятся впустую, а удовлетворить нужды заказчика становится крайне трудно 1. ГОСТ Р ИСО/МЭК 20000-1 формулирует то же требованиями: новые и изменённые сервисы должны быть спроектированы и задокументированы так, чтобы отвечать заявленным требованиям 2.

Ключевое отличие от привычной проектной работы — предмет. Проектируется не система, а услуга целиком.

Проектирование учитывает влияние на другие услуги, на заказчиков, пользователей и поставщиков, на существующую архитектуру, на нужную технику, на практики управления и на измерения 1.

Из этого следует и то, о чём вспоминают позже всех: проектирование нужно и при выводе услуги из эксплуатации — иначе вывод бьёт по заказчику неожиданно 1.

Когда практика работает

Три вопроса, ответы на которые видны в момент передачи услуги в работу.

Услуга приходит в эксплуатацию с описанием, а не с паролями. Как проверить: вместе с услугой передаются перечень работ по обслуживанию, показатели и порядок поддержки.

Уровень проектной работы выбран осознанно. Как проверить: записано, какой объём проектирования нужен для каждой категории изменений, и этот порядок знают все в организации 1.

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

Что входит и что рядом

Годность для цели и годность к использованию

Две стороны, которые проектируются вместе, а обсуждаются обычно порознь 3.

Полезность — что услуга делает: годится ли она для той задачи, ради которой её заказали.

Гарантия — как услуга работает: доступность, мощность, безопасность, непрерывность. Годность к использованию.

ITIL связывает эту привычку с разделением команд разработки и эксплуатации и называет её причиной обрывочного понимания качества 3. На практике это выглядит так: систему сделали и она умеет то, что просили, а сколько выдержит пользователей, кто её обслуживает ночью и как её восстанавливать — выясняется в первый месяц работы.

Проектирование существует ровно для того, чтобы обе стороны попали в замысел до постройки.

Что на входе и что на выходе

Практика работает как перекрёсток. ITIL говорит об этом прямо: практика не описывает все части замысла сама, а согласует и сводит вместе ожидаемые результаты других практик 1 — архитектуры, безопасности, доступности, мощности, поставщиков, уровня услуг.

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

Пакет проектирования услуги

ITIL вводит понятие пакета проектирования: он связывает спрос с ценностьюЦенностьПольза и выгода, которые сторона получает от услуги; величина субъективная.ITIL 4, книга ITIL Foundation и служит внятным изложением того, «как выглядит хорошо» 1. Пакет покрывает четыре стороны 1:

ITIL советует держать несколько видов пакетов разной глубины и связывать их выбор с отношением организации к риску 1. Практический смысл: замысел небольшой типовой услуги не должен требовать того же объёма бумаг, что замысел системы, от которой зависит выручка.

ГОСТ Р ИСО/МЭК 20000-1 задаёт близкий по составу список того, что должно попасть в проект:

• полномочия сторон;
• требования к людям, технике, сведениям и деньгам;
• требования к образованию и подготовке;
• новые или изменённые соглашения и договоры;
• изменения в политиках и знаниях;
• воздействие на другие сервисы;
• обновление каталога услуг 2.

Как это работает

Работа делится на две части: наладить сам подход к проектированию — и провести конкретный замысел 1.

Цвет шага: приём, учёт, работа с обращением техническая работа решение и полномочия проверка, разбор, улучшение работа с людьми и сторонами

Два места стоит объяснить отдельно.

Первый шаг определяет всё остальное. ITIL перечисляет, что оценивают до выбора подхода:

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

Седьмой шаг ведётся регулярно. ITIL предлагает пересматривать подходы и модели раз в два-три месяца или чаще, если существующие плохо работают 1.

Два способа проектировать

Случая два, и требовать одинаковой процедуры от обоих бессмысленно 1.

Знакомая услуга. Похожее уже проектировали: берётся готовая модель и прошлый пакет, работа идёт линейно по описанным шагам.

Новая и незнакомая. Готовой модели нет: нужны эксперименты, проверка гипотез, короткие круги с быстрой обратной связью, особое внимание к разговору с заинтересованными и к обработке их отзывов. Такой замысел часто ведётся как проект и втягивает много команд.

Отсюда правило выбора: организация, у которой один порядок проектирования на оба случая, либо душит новое бумагами, либо проектирует привычное на глазок.

Что с чем путают

Проектирование услуги и разработка системы. Разработка отвечает за то, как работает программа; проектирование услуги — за то, как работает услуга целиком, включая людей, поставщиков и порядок обслуживания 1.

Проектирование и архитектура. Архитектура задаёт общее устройство и правила для всех услуг; проектирование применяет их к конкретной услуге. Это разные практики, и их положено согласовывать 1.

Проектирование и бизнес-анализ. Анализ выясняет, какая потребность у бизнеса и стоит ли её закрывать; проектирование отвечает, как именно закрывать.

Проект услуги и проектная документация. Пакет проектирования — не папка для сдачи, а изложение того, как выглядит хорошо, которым потом пользуются при постройке и приёмке 1.

Кто участвует

Главным в этой работе ITIL называет согласование: определить задачи, ключевые сведения и участников, а заодно подсказать порядок и приёмы работы при постройке 1. То есть роль ответственного здесь дирижёрская, а не авторская.

Как измерять

Самая полезная пара — инциденты первого месяца и доработки после передачи. Обе цифры показывают, что именно замысел не предусмотрел, и обе собираются без специальных усилий.

Брукс берёт не среднее, а минимум. В его наборе есть показатель «минимальная оценка удовлетворённости» — самая низкая из оценок по всем процессам, цель 4 из 5, тревога ниже 3 7. Приём переносится на что угодно и меняет поведение: среднее прячет слабое место за сильными соседями, минимум указывает на то, чем заниматься. Для проектирования это особенно к месту — услуга воспринимается по худшей своей части, а не по средней.

Сезонность он предлагает снимать скользящим средним. У числа инцидентов цель 100 при тревоге в 150, и рядом оговорка: чтобы краткосрочные всплески не выдавались за тенденцию, показатель считают скользящим средним 7. Совет дешёвый и почти никогда не выполняемый: сравнение «месяц к месяцу» остаётся самым частым способом увидеть в графике то, чего в нём нет.

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

Зрелость проектирования сервиса

✕

Где ломается чаще всего

Шесть мест, в порядке частоты.

Проектируют систему, а не услугу. Требования собраны к программе, а кто её обслуживает, как восстанавливать и сколько она выдержит — вопросы на потом 1.

Один порядок на все замыслы. Небольшое изменение проходит тот же путь, что новая услуга; объём проектной работы требуется определить по категориям 1.

Эксплуатацию зовут после постройки. Требования к обслуживанию появляются, когда услуга уже сделана, и превращаются в доработки.

Каталог не обновили. Стандарт прямо включает актуализацию каталога в состав проектирования 2, а на практике услуга живёт, но её никто не видит.

Вывод услуги не проектируют. Непродуманный вывод бьёт по заказчику неожиданно 1.

Пакет превратился в бумагу. Замысел оформлен, но им не пользуются ни при постройке, ни при приёмке.

Что говорят своды

69Своды знаний и стандарты — разобраны отдельноЧем ITIL отличается от COBIT и ISO, что из этого обязательно, а что на выбор, и где брать первоисточник. У каждого свода отмечено, развивается он или давно заморожен, и есть ли действующий ГОСТ. По 51 практикам из 62 проставлено соответствие COBIT.Открыть →

ITIL держит проектирование отдельной практикой, строит её вокруг пакета проектирования и требует единого подхода по организации при разной глубине работы 1.

ГОСТ Р ИСО/МЭК 20000-1 описывает проектирование и перенесение одним пунктом и задаёт состав планирования и проекта, включая критерии приёмки и измеримые результаты 2.

COBIT выделяет разработку и создание решений отдельной целью управленияЦель управленияЕдиница описания COBIT: цель с проверяемым содержанием, у которой есть процесс того же имени.COBIT 2019, книга Governance and Management Objectives 5.

MOF относит требования к надёжности будущей услуги к этапу планирования и оформляет их пятью планами 4.

Расхождение здесь одно и заметное: ITIL говорит о замысле услуги, а стандарт — о проектировании и перенесении как одной работе. Что из этого следует при внедрении: если разделить их полностью, между проектом и запуском появляется разрыв, а вместе с ним и вопрос «а кто это должен был предусмотреть».

Где описано

Что почитать дальше

Три соседние практики, между которыми живёт замысел услуги: BANБизнес-анализ — откуда берётся потребность, ARCУправление корпоративной архитектурой — какие правила задаёт общее устройство, TSTПроверка и тестирование услуг — как проверяют, что получилось задуманное.