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

Функция

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

На одном из последних курсов ITIL® OSA (Operational Support and Analysis) собралась довольно сильная группа с весьма разнообразным практическим опытом. Представители внутренних ИТ-служб и внешних провайдеров ИТ-услуг (системных интеграторов и ИТ-дочек крупных компаний).
У каждого есть своя сложившаяся картина мира. Если говорить о вопросах эксплуатации и поддержки (а курс именно про это), то почти любой человек, даже не из ИТ, имеет какой-то опыт в этой сфере. Если не со стороны сервис-провайдера, то, как минимум, в роли заказчика и/или потребителя каждый сталкивался с поддержкой. Разумеется, такой контекст предопределяет возникновение жарких дискуссий сложных и интересных вопросов.

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

Речь про понятие «функция». Официальный перевод термина из ITIL:

«Команда или группа людей, а также инструментарий или другие ресурсы, которые они используют для выполнения одного или нескольких процессов или деятельности. Например, служба поддержки пользователей»

В книге «Эксплуатация услуг» (ITIL Service Operation) описываются:

  • Service Desk — Служба поддержки пользователей (Служба Service Desk)
  • IT Operations Management — Управление эксплуатации ИТ
  • Application Management — Управление приложениями
  • Technical Management — Управление технической поддержкой

Вроде бы всё понятно. Но!

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

Самый яркий пример, на мой взгляд, — Service Desk. Во многих организациях эта функция выделена в отдельное подразделение. Поэтому, произнеся фразу: «Пример функции ITIL – Service Desk, который решает следующие задачи», вы гарантированно получите корректное понимание функционала Service Desk (вряд ли в этой части можно чем-то удивить практиков – Service Desk есть у всех… почти. И, да, он решает именно те задачи, которые описаны в ITIL). Но единого понимания того, что такое «функция», скорее всего не добьётесь. Аналогично с прочими функциями. А вот тезис о том, что, например, сотрудники Technical Management могут находится в различных отделах, заставляет задуматься на разницей между оргструктурным подразделением и функцией.

Хотя, например, в бизнес-структуре (во всяком случае в крупных организациях матричного типа) редко у кого вызовет удивление разведение понятий «линейный руководитель» (line manager) и «функциональный руководитель» (dotted line manager). Первый – непосредственный руководитель подразделения, в котором работает сотрудник (например, руководитель регионального офиса), а второй – руководитель… функции  направления (например, руководитель по рознице или руководитель по маркетингу). То же самое в ИТ: директор по ИТ в Российском подразделении международной компании, подчиняющийся напрямую General Manager российского подразделения и имеющий функциональное подчинение IT Manager региона (Европа, worldwide и т.п.)

Во-вторых, несмотря на то, что это понятие подробно описывается в книге «Эксплуатация услуг» (ITIL Service Operation), деятельность функций не сводится к работе в рамках поддержки. То есть, ассоциация Service Desk – это первая линия поддержки, IT Operations – это вторая линия поддержки, а Application Management и Technical Management – это третья линия поддержки правильная. Но и это не вся правда 🙂

Функции могут участвовать не только в процессах поддержки. Это явно следует из огромного списка задач, которые перечислены в советующих параграфах по каждой из функций. Например, Technical Management может участвовать не только в качестве третьей линией поддержки в рамках процесса управления инцидентами, но и в процессе управления проблемами (кому ещё выполнять работу аналитиков по исследованию проблемы, поиску корневой причины и нахождению решения, как не наиболее квалицированным специалистам в вопросах инфраструктуры?). В процессах управления доступностью и мощностями. В управлении изменениями. В общем везде, где может потребоваться соответствующий уровень экспертизы.

Например, про управление приложениями в самом начале раздела сказано максимально кратко, четко и однозначно [ITIL Service Operation, 6.6]:

Application management is responsible for managing applications throughout their lifecycle. This differs from application development as application management covers the entire ongoing lifecycle of an application, including requirements, design, build, deploy, operate and optimize.
Управление приложениями ответственно за управление жизненным циклом приложений. Это отличает его от разработки приложений, поскольку управление приложениями занимается полным жизненным циклом приложений, включая сбор требований, проектирование, построение, развёртывание, эксплуатацию и оптимизацию.

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

Таким образом функции — это элементы (в общем случае организованные «над» структурой ИТ-службы), выделяемые для того, чтобы решать какие-либо задачи. В том числе играть определённые роли в процессах. Эта не единственная возможная картина. Но довольно стройная. И в ITIL, как мне кажется, она проглядывается довольно явно.

Разумеется, это не вся правда. Даже если мы пока оставим в стороне ключевое понятие «услуга», есть ведь ещё так называемые «виды деятельности» (Common service operation activities). Но о том, как эта сущность встраивается в вышеописанную модель, как-нибудь в другой раз. Например, после очередного курса 😉

«VAP: Управление поддержкой ИТ-услуг»
Концентрация знаний и опыта без натаскивания на экзамен

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

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

  • Рубрики

  •  
  • Авторы

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

    • Новая модель предоставления ИТ-услуг: почему вам нужно ориентироваться на продукт
      Традиционно ИТ-организации делят все предоставляемые ими услуги на три уровня: инфраструктура (инфраструктура как услуга), платформа (платформа как услуга) и приложения
    • Как 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 году", считают, что технический долг негативно влияет на моральное состояние их команд.
    • Что люди не понимают в управлении потоком создания стоимости
      Нет ничего плохого в самом управлении потоками создания ценности (VSM), но есть много плохого в том, как его рассматривают и обсуждают блогеры, отраслевые маркетологи и другие, которые часто смешивают его с DevOps и Agile. Это не одно и то же.
  •  
  • Вход

  • DevOps
    Kanban
    ITSM
    ITIL
    PRINCE2
    Agile
    Lean
    TOGAF
    COBIT