Большинство компаний представляют проектирование услуг (service design) как средство улучшения потребительских свойств ИТ-услуг, но мало кто говорит о том, за счет чего это происходит.
Существует ложное представление о том, что если использовать определенные рамки и стандарты при проектировании, то сразу же можно увидеть глобальные изменения, и ваши ИТ-услуги станут идеально соответствовать потребностям ваших клиентов. На самом деле, всё будет происходить несколько иначе. С одной стороны, вы заметите определенный прогресс, который подтолкнет вас к продолжению. Но с другой стороны, фундаментальные негативные факторы, мешающие продвижению услуги, не исчезнут.
Факторы, которые мы упускаем.
Основной показатель успешного проектирования услуг – это эффективность ваших соглашений об уровне качества услуг (SLA). Давайте рассмотрим такой пример. Вы подписываете два соглашения – одно по услуге, критичной для бизнеса, и второе – по услуге, которая не является для бизнеса критичной. Будут ли эти соглашения выглядеть одинаково? Будут ли там одинаковые уровни доступности услуги? Каким образом будут зафиксированы отличия этих услуг? И более того, каким образом он будет отражен в отчетности? Вы формируете отчетность только по производительности структурных компонентов или же по услуге в целом?
Как только вы начнете детально разбираться в формировании SLA, вы начнете понимать, почему проектирование услуг не работает. Например, если вы в конце дня отчитываетесь только по инфраструктуре, то вы вполне можете столкнуться с ситуацией, когда клиент удивлен вашим докладом о бесперебойной работе услуги, при том, что в реальности столкнулся с несколькими серьезными проблемами.
Подготовка правильной основы для проектирования услуг.
Помимо самих SLA, самое важное – это произвести полную оценку рисков, проблем, зависимостей и предпосылок например, оценка дискового массива (RAID). Фокусируясь рисках и проблемах вы получите похожие результаты. Однако в своем реестре ИТ-рисков вы найдете не только риски и проблемы, но и всевозможные намеки на то, что не было учтено. Например, что-то вроде «нам не удалось достичь запланированного роста обработки контрактов аренды с 400 000 до 600 000 в связи с множественными техническими проблемами». Подобный отзыв отчетливо сигнализирует о проблемах с управлением мощностями, в данном случае, необходимо обязательно проверить, насколько правильно были сформированы требования, происходили ли какие-то изменения, которые могли стать причиной значительных инцидентов и т.д.
Чем рассматривать дисковый массив с технологической точки зрения, подойдите к этому с точки зрения процесса. Не так важно, какие именно методологии вы используете – ITIL, PRM-IT, COBIT или что-то другое, возьмите это за референсную модель. Когда вы обнаружите риски и проблемы внутри бизнеса и ИТ-функции, вы оценивая вероятность возникновения рисков и их относительное влияние, а в дальнейшем – и реальное влияние рисков в рамках процессов. После этого вы сможете проанализировать результаты и обнаружить основные факторы, негативно влияющие на проектирование услуг и угрозы повторного возникновения проблем. Из реестра рисков вам также станет очевидно, какие именно действия работают на сокращение негативных факторов. И вы сразу же увидите сокращение количества негативных факторов в реестре рисков. В результате предпринятого вами анализа, вы составите план действий, который значительно изменит проектирование услуг. Повторять этот процесс необходимо ежегодно, иначе вы сведете на нет эффективность проектирования услуг.
По мнению Карен Буш, автора этой заметки (оригинал читайте здесь What Makes Service Design Successful?), управление рисками – это основа основ. Наше понимание для чего используется услуга, каковы риски для бизнеса в случае недоступности данной услуги или её несоответствия потребностям бизнеса? Дальнейшее во многом зависит от культуры организации: работа в сотрудничестве или же обособленная деятельность . Вы удивитесь, как сильно от этого зависит проектирование услуг.
