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

Влияние синих пробирок на совершенствование процессов

"У меня пробирки посинели", – такой простой, но емкой фразой пользователь описал сложившуюся у него ситуацию оператору Service Desk.

Таких примеров, уверен, каждый из Вас приведет сотни. Шутки шутками, но оператору такие обращения приходится регистрировать и классифицировать, в том числе определять, к какой ИТ-услуге относится данное обращение, чтобы правильно вычислить сроки по соглашениям, ответственных и т.д. Чтобы затем правильно построилась отчетность по ИТ-услуге, и менеджер принял верное решение по совершенствованию процессов.

При создании каталога ИТ-услуг мы обычно задумываемся над способом формирования каталога: от ИТ-систем, от бизнес-процессов, и т.д. И, рассуждая, говорим, что пользователям, конечно, ближе бизнес-процессы. Но на практике случается так, что пользователям, конечно, ближе ИТ-системы, которые они каждый день запускают, и видят их наименование в заголовках окон. Не каждый пользователь сможет точно определить, в рамках какого бизнес-процесса он выполняет работу или какую бизнес-функцию реализует. А вот название системы – пожалуйста, оно перед глазами.

Так что получается, что и ИТ, и бизнесу интереснее работать с каталогом от ИТ-систем. К сожалению, нет. Когда речь зайдет о параметрах предоставления ИТ-услуг, мы пойдем не к пользователям, а к их руководителям, а вот они уже будут думать (я надеюсь) в терминах выполнения бизнес-задач, которые возложены на их подразделение, некоторые – в терминах бизнес-процессов и влияния, скажем, простоя, на этот процесс. И ИТ-системы если и будут упоминаться, то в привязке к выполняемым операциям. 

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

* пост по следам вебинара "SLM: Структура каталога и SLA. Анализируем варианты". 

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

  • Pavel Solopov

    По хорошему необходимо ИТ-системы разбить на автоматизированные функции или операции, а автоматизированные функции уже включать в ИТ-сервисы, коль мы формулируем их от БП. Тогда проблем с классификацией будет меньше.
    Диалог при регистрации инцидента может быть примерно таким:
    – При работе в какой системе у вас возникла проблема?
    – Я работал в Super ERP.
    Специалист первой линии открывает в справочнике Super ERP и видит список всех автоматизированных функций, которые ей реализуются.
    – Что вы пытались в ней сделать?
    – Я формировал отчёт за квартал по остаткам на складе…
    Специалист выбирает пункт “Формирование квартального отчёта”, и система автоматом привязывает эту заявку к сервису “поддержка процессов обеспечения неснижаемого запаса комплектующих, запасных частей и материалов на складах центального региона”

  • Pavel Solopov

    При выборе формата каталога я бы ещё учитывал наличие на стороне бизнеса бизнес-технолога или бизнес-архитектора. Что я вкладываю в эти понятия?
    Это человек, который придумывает и проектирует, как должны быть построены БП компании. В том числе какие ИС, с какой целью и для чего должны использоваться. Этот человек должен обладать как хорошим пониманием бизнес-целей, пониманием бизнес процессов, так и хорошим уровнем компетенции в области информационных технологий, по крайней мере в части бизнес-приложений.

    Так вот при наличии такого технолога или архитектора правильней было бы строить ИТ-каталог из систем или даже автоматизированных функций, требование к которым будет определять этот самый технолог исходя из своего “проекта” бизнес-процессов.

    • Боюсь, в реальном мире это звучит как “При выборе формата каталога я бы ещё учитывал ОТСУТСТВИЕ на стороне бизнеса бизнес-технолога или бизнес-архитектора.”

      • Pavel Solopov

        Ну так это нам с вами, коллеги консультанты, информация для размышления. Поле-то не паханное, надо расширять диапазон действия, надо расширяться от управленческого консалтинга в ИТ к управленческому консалтингу в масштабах всего бизнеса.
        Надо учить бизнес, как ему надо меняться, хватит пытаться сделать бизнес счастливым без его ведома. 🙂

        • “Надо учить бизнес, как ему надо меняться, хватит пытаться сделать бизнес счастливым без его ведома. :-)”

          Совершенно верно. Нам тут изнутри ИТ очень хорошо видно. Они всё делают не так, а мы-то знаем как надо. Тоже мне, бизнесмены. Даже стратегии у них никакой нету – о чём тут говорить? 🙂


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM