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

Услуги поставщиков. Нужен ли учет возможностей?

Недавнее общение с представителями сервисной организации натолкнуло на следующие размышления. 

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

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

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

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

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

Есть один очевидный недостаток – подобная информация очень быстро устаревает.

Что скажете? Может у кого-то есть опыт подобной деятельности …

«VAP: Управление уровнем услуг и каталогом услуг»
Разработка каталога, SLA, метрик качества, расчёт доступности

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

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

    Чем больше изменений, развития, тем больше рисков и возможностей, связанных с внешними поставщиками (в т.ч. ИТ), и тем важнее наличие понимания их (поставщиков) ограничений и возможностей.

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

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

    Тогда получается, что мы говорим не о подобии CMDB, а о менеджере по работе с поставщиками. Человек лучше компьютера работает со слабо структурированной информацией (пока). Нет?

    • Со всем согласен. Но важно не только средство учета (голова или система), а еще и наличие такой практики в деятельности людей. Обычно контракт заключается исходя из текущих потребностей и редко кто задает вопрос “а вот если нас станет в два раза больше, вы сможете масштабировать свои услуг? до каких пределов?”. Вопрос простой, но требует понимания, как могут измениться потребности с нашей стороны и во что это выльется с точки зрения нашего поставщика услуг.

      • Рискну сказать глупость, но если менеджер по работе с поставщиками услуг не в курсе что из себя представляет конкретный поставщик услуг, да ещё важный для компании – то этот менеджер не на своём месте находится.

        • Не глупость конечно 🙂 Но ответ на вопрос “что из себя представляет” может быть достаточно объемным, если не понимать, что конкретно нам интересно. Для примера возьмем хостинг провайдера, мы знаем, что есть несколько тарифов, от тарифа зависит объем диска, набор сервисов, и еще 2-3 параметра. Но при этом этот же хостер предоставляет еще миллион услуг, о которых мы не думали, поэтому и не знаем.

  • В учебниках феномен усложнения и повышения зависимости от многочисленных поставщиков описан как переход от value chains к value networks. И недаром там же (в учебниках) четыре года назад появился отдельный процесс с отдельной базой информации о поставщиках. Это я к тому, что в очередной раз наблюдения за живой природой подтверждают тот факт, что учебники не дураки писали, и если мы там что-то не понимаем или не принимаем, то проблема очень может быть в нас, а не в них.

    Что же до выбора “голова-система”, тут, я думаю, опять прав Скептик: необходимо упорядочить базовую информацию, но полезной она станет только в руках у головы, простите за спорный образ. Строить мега-систему, заменяющую головы и руки, – утопия. Что равно справедливо для CMDB, CMS, SKMS, SCD и ТД, и ТП.

  • Если управление поставщиками организовано, то соответствующие менеджеры знают своих поставщиков (размер, специализацию, сильные и слабые стороны, ограничения). Поскольку управление поставщиками предоставляет информацию для проведения закупок (а это часто те или иные конкурсные процедуры), то накапливается также и информация об альтернативах. Хорошая и вполне реальная практика – ведение паспортов поставщиков (как тех, с кем заключены контракты, так и альтернативных).
    С другой стороны (опять же из практики), управление мощностями учитывает зависимость услуг и объёмов их потребления от ресурсов, в том числе от внешних услуг. Поэтому предсказать изменение требований к внешним услугам при изменении объёмов потребления внутренних услуг вполне возможно.
    То есть как организовать – ясно. Основная проблема, как мне кажется, в том, что управление поставщиками практикуется довольно редко. Конечно, есть отделы закупок, отделы ведения договорной работы, но они, как правило, занимаются не “предметной частью”, а формальными вопросами – договорами и иже с ними. При этом целый ряд вопросов “провисает”: регламентация работы с поставщиками, контроль фактического качества внешних услуг, организация каналов эскалации на руководство, решение оперативных вопросов с вовлечением руководства поставщиков, контроль рисков, связанных с поставщиками, мониторинг изменений поставщиков (а изменения происходят постоянно – мигрируют не просто отдельные специалисты, а целые команды, происходят слияния и поглощения и так далее). Для многих компаний, где поставщиков много, а вопросы управления ими, обозначенные выше, толком не решаются, это серьёзная головная боль.
    С другой стороны, всё это имеет смысл только на конкурентных рынках услуг. “Пятен на карте”, где такая конкуренция существует, в масштабах РФ не так уж и много (хотя, конечно, зависит от вида услуг).
    Поэтому мой вывод: учёт потенциальных возможностей поставщиков – это “хороший” и очень несложный в организации довесок к управлению поставщиками, которое решает базовые вопросы. Но поскольку базовые вопросы в среднем решены крайне слабо, а конкуренция поставщиков присутствует далеко не всегда, потребность в этом “довеске” невысока. Это как … выбирать красивую шляпу при отсутствии брюк.

  • Вадим

    IMHO есть еще один аспект данной темы.
    Во-первых, сразу возникает вопрос “Зачем?” Зачем знать, упорядочивать информацию, вести базу возможностей и т.п.
    Во-вторых, откуда узнать, что может понадобиться, пока не столкнешься с конкретной потребностью вчера получить нечто нужное (некую услуги, основанную на услуге(-ах) внешнего поставщика).

    На второй вопрос ответ достаточно прост – необходима стратегия (бизнеса и ИТ), необходимо отслеживания (если не мониторинга, что впрочем одно и то же) потребностей бизнеса, нужно уметь вовремя предложить (и продать) тот или иной сервис.

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


Добавить комментарий для Роман ЖуравлёвОтменить ответ

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

DevOps
Kanban
ITSM
ITIL
PRINCE2
Agile
Lean
TOGAF
ITAM