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

Сервис-менеджер и сервис-менеджмент

Опубликовано 19 февраля 2011
Рубрики: ITSM, Обо всём на свете
Комментарии

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

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

Советское прошлое такой образ практически стерло. Из детских кинофильмов помню персонаж официанта в буржуйском ресторане, который все время суетится, кланяется, идиотски выглядит и злоупотребляет буквой "с" (слушаю-с! чего изволите-с? не угодно ли-с?). На фоне тех, кто скакал на конях в кожаных куртках и здорово стрелял из нагана, борясь с теми, кто пользовался услугами этих самых официантов, шансов захотеть оказывать услуги не оставалось. Никаких.

Вместе с тем, персональная позиция здесь принципиально важна. Хороший сервис-менеджер — это человек, на которого заказчик может положиться. Которому доверяют, к которому можно обратиться не только "по процедурному вопросу", а за помощью. Вот картинка про отличного сервис-менеджера из "ненашего" кино. Думаю, и кино узнать нетрудно 🙂

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

В управлении ИТ-услуг это далеко не всегда реализуется на практике. Действительно, во многих организациях на позицию сервис-менеджера назначают людей уровня старших специалистов, ответственных за те или иные бизнес-системы. Такой подход как правило работает лишь до тех пор, пока вопросы касаются прикладной логики систем (при соблюдении пункта 1 выше). Но если вопрос "выходит за рамки", начинает касаться смежников (например, сложности с быстродействием систем или с процедурами получения поддержки и так далее), все становится гораздо сложнее. Поэтому слово "менеджер" почти ничего не значит (см. картинку ниже). Гораздо больше соответствует содержанию русское "управляющий". Почувствуйте разницу: менеджер по продажам и управляющий отеля 🙂

Фактически, пункт 1 — о сервисе, пункт 2 — о менеджере. Так и получается "сервис-менеджер". Из песни слова не выкинешь, все на своих местах.

Однако на своей практике я видел не очень много организаций, которые серьезно продвинулись в сервис-менеджменте в ИТ. Я имею ввиду не наличие формальных процессов, а культурные изменения. Декларативные подходы к управлению, так распространенные в сегодняшних пост-советских организациях, не часто оставляют шансы на реализацию концепции сотрудничества бизнеса и ИТ. То есть я хочу сказать, что сервисная культура ИТ-департамента очень слабо востребована бизнесом. Поэтому принципиально любопытна проработка такого подхода, в котором из ITSM останется только IT_M — целепостановка, организация, контроль, оценка и совершенствование в области управления ИТ, но БЕЗ использования концепции услуг, как чуждой многим организациям. Ведь часто управление ИТ-услугами сводится к управлению операционной деятельностью ИТ-департамента, то есть существенно Уже ITSM. Зачем же "умножать сущности без надобности"?

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

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

  • Юрий Ерин

    «...принципиально любопытна проработка такого подхода, в котором из ITSM останется только IT_M — целепостановка, организация, контроль, оценка и совершенствование».

    А почему бы и нет? Чем принципиально управление ИТ департаментом отличается от, например, от управления службой главного энергетика производственного предприятия или гостиницей?

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

  • Анатолий Павлюченко

    «Ведь часто управление ИТ-услугами сводится к управлению операционной деятельностью ИТ-департамента, то есть существенно Уже ITSM.»

    Сужение охвата отнюдь не отменяет «сервисный» подход к организации ИТ производства. Хороший пример — Microsoft Operations Framework, ещё лучше — FITS.

    Выявить и формализовать востребованность ИТ сервисов бизнесом, я думаю, это и есть задача для ИТ директора (совместно с сервис-менеджером). Если «концепция услуг» чужда руководству в принципе, то для «целепостановки, организации, контроля и оценка» всё равно необходима какая-то концепция или база. Если не ITSM, то какая другая?

    При этом на фасаде можно написать любую табличку, а внутри будет работать хорошо зарекомендовавший себя движок.


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

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

  • Рубрики

  •  
  • Авторы

  •  
  • Самое свежее

    • 3 стратегии, которые помогут вашей команде принять метрику потока
      Вам необходимо эффективно управлять рабочими процессами, чтобы иметь возможность постоянно предоставлять ценность своим клиентам. Именно здесь в игру вступают метрики потока. Метрики потока являются основной движущей силой оптимизации процессов.
    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как DevOps-командам следует использовать метрики DORA
      С момента выхода в 2018 году книги «Accelerate: Наука о бережливом программном обеспечении и DevOps», показатели DORA, которые она представила, стали популярным
    • Лучше делать хоть что-то, чем не делать ничего
      На конференциях по всяким Agile и DevOps мы часто слышим слово «unlearn» — забудьте то, что вы знали ранее! Измените свои представления о мире! Всё устроено
    • VI форум «Управление данными — 2021»: наведите порядок в данных!
      23 сентября 2021 года издательство «Открытые системы» в шестой раз проведет в Москве масштабный форум «Управление данными — 2021», объединяющий всех, кто определяет стратегию работы с данными, воплощает ее в жизнь и управляет предприятием на основе объективных достоверных данных. Участники форума обсудят не только инновационные стратегии и бизнес-модели работы с корпоративными данными, но и конкретные архитектурные и технологические решения.
    • Простые уловки, как ускорить процесс разработки программного обеспечения
      С некоторыми вещами люди из бизнеса вынуждены соглашаться, и одна из них заключается в том, что никто не хочет сердить свою команду разработчиков. Часто они являются краеугольным
    • Почему каждая инициатива DevOps должна начинаться с оценки возможностей
      Внедрение практики DevOps идет полным ходом. Организации сосредоточены на том, как внедрить возможности DevOps в командах и как масштабировать DevOps в масштабах предприятия. Но важным аспектом любого пути масштабной трансформации является оценка возможностей команды или организации на этом пути.
    • Что такое процесс и что такое практика в ITIL®4
      Продолжаем публиковать короткие видеоролики, посвященные актуальным вопросам управления ИТ. Сегодня поговорим о том, что такое процесс и что такое практика в ITIL4. Это не переименование процессов в практики, это два отдельных понятия. Рассказывает Игорь Фадеев, ITIL 4 Managing Professional и ITIL 4 Strategic Leader, аккредитованный тренер по ITIL4.
    • Аудит. Что может быть скучнее?!
      На прошедшей неделе участвовал в аудите (в качестве объекта аудита). Большинство людей, проходивших аудит, подозреваю, разделяет это ощущение: «Бюрократия, формальности и т.п.»
    • Как технический долг вредит вашей команде программистов — и вашей безопасности приложений
      Техническая долг может серьезно повлиять на здоровье организации - и на психическое здоровье ваших разработчиков. Более половины из 200+ членов инженерных команд, опрошенных в рамках отчета Stepsize "Состояние технического долга в 2021 году", считают, что технический долг негативно влияет на моральное состояние их команд.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT