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

Внутреннему ИТ-отделу портфель услуг не нужен

Одна из интересных дискуссий, возникающая во второй день учебного курса "Экономика и финансы ИТ" (он же – пятый день курса ITIL SOA) – что же такое портфель услуг и чем он принципиально отличается от каталога.

Многие, конечно же, вспоминают первое отличие – охват портфеля услуг шире, чем охват каталога. Услуги в портфель должны попадать сильно раньше, чем в каталог – возможно, в момент, когда провайдер только задумался "а не проработать ли мне вот эту идею?". А исчезают услуги из портфеля сильно позже, чем из каталога – когда предоставление данной услуги прекращено, ресурсы освобождены и такой вот точно услуги в ближайшие N лет провайдер предоставлять не планирует.

Но есть и второе отличие. Портфель – инструмент отражения стратегии бизнеса в стратегию ИТ. Мы же должны чётко понимать зачем мы оказываем услуги? Какие именно? Для чего именно? И что с ними, услугами, будет завтра? Должны. Вот нам и подсказывают подходящий инструмент.

На уровне идеи всё очень хорошо и стройно. Однако погружение в детали стройность нарушает. Рассмотрим, например, ключевые вопросы, на которые согласно ITIL должен отвечать хороший портфель услуг:

  1. Почему клиенты должны покупать эти услуги?
  2. Почему они должны покупать их именно у нас?
  3. Как мы придумываем цену услуг и как услуги монетизируем?
  4. Каковы наши сильные и слабые стороны, приоритеты и риски?
  5. Как нам распорядиться нашими ресурсами?

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

Попробуем для сравнения рассмотреть эти же вопросы для внутреннего ИТ-провайдера. Получится примерно так:

  1. Почему клиенты должны покупать эти услуги? 
    — Потому что мы обеспечиваем поддержку бизнес-процессов нашего единственного клиента, и без такой поддержки ему будет сложновато (а то и невозможно) работать. Поэтому купит.
     
  2. Почему они должны покупать их именно у нас? 
    — Потому что выбора у клиента нет, мы – единственный поставщик.
     
  3. Как мы придумываем цену услуг и как услуги монетизируем? 
    — Цену услуг мы не придумываем. В лучшем случае мы считаем себестоимость услуг, да и то по согласованной с клиентом методике. А монитизация наша проста, называется "мы долго бились и нам выделили бюджет".
     
  4. Каковы наши сильные и слабые стороны, приоритеты и риски? 
    — Наша сильная сторона – безальтернативность. Наша слабая сторона – бизнес нас рассматривает как центр затрат, а не центр инвестиций. Наш приоритет – максимально усиливать нашу безальтернативность, наш риск – возможная замена на другого провайдера для части предоставляемых нами ИТ-услуг.
     
  5. Как нам распорядиться нашими ресурсами? 
    — Как обычно. Получаем задачу – пишем ТЗ – запускаем проект – закупаем ресурсы – эксплуатируем результат.

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

Итак, получается, что внутреннему ИТ-отделу портфель услуг не нужен.

Или нет?

 

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

  • Vladimir Ivanov

    Vladimir Ivanov

    Или нет

  • Провокатор.

    • Ага. А по сути вопроса?

      • А по сути – как-то так:

        Ты приводишь ответы на 5 главных вопросов процесса в отношении всего множества оказываемых услуг, и эти ответы, как всегда бывает с широкими обобщениями, оказываются не очень полезными на практике. Если же отвечать на них про каждую услугу (группу услуг) в портфеле, пользы становится больше:

        Why should a customer buy these services? – вопрос про ценность. Вот эти услуги повышают производительность бизнес-процессов; вот эти – снижают риски; вот эти – обеспечивают возможности развития… и т.д. Стюарт Рэнс как-то сказал, что первое, что должен сделать поставщик услуг – это создать outcome portfolio, портфель бизнес-пользы. И уже от этих outcomes формулировать свои услуги. Собственно, это и есть первый вопрос SPM. И во внутреннем ИТ ответ на него ничуть не менее важен, чем во внешней сервисной компании.

        Why should they buy these services from us? Тут я согласен с Максимом – вопрос о сорсинге. Если смотреть на него с позиции ИТ-службы, то либо о защите инсорсинга (почему эту услугу надо получать у внутреннего поставщика, а не передать внешнему), либо об обосновании привлечения подрядчика (почему мы выбрали buy, а не build). Возможны и другие варианты, если используются более сложные организационные схемы (Shared service units, SIAM…)

        What are the pricing or chargeback models? Это совсем не обязательно вопрос про цену услуг для заказчика и вообще не вопрос про придумывание этой цены. И снова поддержу Максима – это прежде всего про понимание и отнесение стоимости услуг, про связь затрат на услуги с выгодами из первого вопроса. Управление портфелем – это же всегда про инвестиции, про оптимальный выбор в заданных ограничениях. И стоимость – одно из важных ограничений.

        What are our strengths and weaknesses, priorities and risks? Даже если говорить про поставщика в целом, предложенные тобой ответы – лишь один из вариантов, правда же? Но гораздо интереснее посмотреть на SWOT для отдельных услуг или пакетов услуг. И оказывается, что ответы (1) будут разными и (2) помогут сделать оптимальный выбор для оптимизации портфеля (в терминах ITIL – такой: Retain / Replace / Rationalize / Refactor / Renew / Retire).

        How should our resources and capabilities be allocated? Повторюсь: Управление портфелем – это всегда про инвестиции, про оптимальный выбор в заданных ограничениях. И этот последний вопрос – о приоритетах при выделении ресурсов, о поиске балансов: между инновациями и поддержанием штанов в печи, между производительностью и соответствием требованиям регуляторов, между гибкостью и надежностью и т.д.

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

        Как-то так я это вижу…

  • Сергей

    Нужен, технологическое назначение портфеля (база всех услуг) остается.

  • Сергей

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

    • Если в каталоге услуг добавить предварительный статус вроде "перспективная услуга" и завершающий статус "выводится из эксплуатации" – задача ведь будет решена?

      И никакой портфель для этого не требуется. Зачем плодить сущности, если каталога достаточно? Оккам был бы против.

  • Сергей

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

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

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

  • ЯZ

    Не согласаен! Я бы исходил их целей сервисного каталога, в том числе как главного инструмента для общения с бизнесом. А рассмотрены здесь – тонкости, специфика, которой не будет в случае если заказчик и потребитель услуг – одна компания! Да и брать практики и слепо применять – глупо! Это не стандарт!

  • Максим

    А если немного перефразировать?

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

    Почему они должны покупать их именно у нас? Вопрос sourcing-га (к сожалению, не придумал емкого перевода). Не пришло ли время выступить сервис брокером и подписать UC с внешним поставщиком.

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

    Каковы наши сильные и слабые стороны, приоритеты и риски? Занимаемся ли мы развитием ИТ или просто плывем по течению?

    Как нам распорядиться нашими ресурсами? А тут все зависит от ответа на предыдущий. Если у нас есть понимание сильных/слабых сторон, приоритетов и рисков – то у нас куча работы в условиях ограниченных ресурсов и даже ничего перефразировать не надо.

    • Сергей

      Максим, Вы правы, если сами ИТ будут пытаться повышать эффективность услуг, но в заметке вывод сделан для конкретных ответов на 5 "ключевых вопросов", но в них такого стремления не видно.


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

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM