Они предлагают сервисы и продукты или их компоненты, которые покупает ИТ-департамент компании. После «сборки» купленных и самостоятельно созданных частей ИТ-департамент предоставляет услуги, поддерживающие бизнес компании в «боевом» состоянии. Равновесие между купленными и созданными собственными силами компонентами было нарушено еще на заре информатики — преобладать стали внешние разработки. Роль корпоративного ИТ-департамента все больше стала сводиться лишь к искусной сборке купленных элементов и предоставлению их в качестве услуги для бизнеса. Сейчас производственная цепочка из трех звеньев (поставщик — ИТ — бизнес) удлиняется. Порой  самих звеньев становится больше. Сложные взаимосвязи между ними закреплены контрактами, соглашениями и финансовыми потоками. ИТ-департамент теперь в состоянии продавать бизнесу только то, что было куплено у поставщика, зависимость от которого продолжает расти. Часто возникает ситуация, о которой Джерри Грегори, бывший президент фирмы Dell, метко сказал так: «Мы тратим огромные средства на аутсорсеров и консультантов, тормозящих развитие нашего внутреннего потенциала и вынуждающих нас отдавать будущее благосостояние нашей компании в руки людей незаинтересованных и не связанных с нашим бизнесом». Нехорошо получается. Однако, как бы в ответ на это утверждение, звучит заявление директора по ИТ в крупном бельгийском банке: «... пока наши бизнес-проблемы успешно решались группой внешних консультантов, жестко ориентированных на результат, наш департамент ИТ тратит много времени и энергии на обоснование их работы». Тоже вполне узнаваемая картина. Получается, что не только внешний консультант виноват в неудачных начинаниях и проектах, но и сам заказчик. По данным Gartner Group, 70% проектов разработки ПО неудачны по причине неадекватного управления требованиями пользователей и 62% — по причине неточно определенного функционального охвата (scope). Бизнес несет ответственность и за управление требованиями, и за определение охвата ПО, не говоря уже о сохранении ценности ПО для компании. И этим всем надо управлять. ИТ-департамент разделяет эту ответственность с бизнесом и прибегает к помощи внешних консультантов, сам выступая в роли заказчика определенных ИТ-услуг и продуктов. А поставщиками надо тоже управлять.

Основые принципы управления поставщиками можно найти в новой третьей версии ITIL (глава Supplier management в томе Service Design). Пользуясь весьма общими и абстрактными понятиями библиотеки, нельзя упускать из виду реальные условия работы с внешними консультантами. В отличие от многих процессов управления услугами, успех внедрения управления поставщиками во многом зависит от степени интеграции традиционного отдела закупок в новый отдел управления поставщиками ИТ-услуг и продуктов. Иногда будет крайне трудно вывести эти функции из-под ответственности финансовой службы. Задачей этого отдела будет теперь не только проверка соответствия закупки законодательству и бюджету, чем в принципе уже занимаются другие подразделения компании, но и мониторинг и улучшение процесса управления поставщиками, переговоры о ценах и уровнях закупаемых услуг и продуктов. Отдел будет нести ответственность за управление контрактами, внедрение и соблюдение тендерного процесса, включая сравнительный анализ рисков по каждому кандидату. Одним из основных положений контракта с поставщиком должна стать формализованная и тщательно документированная передача знаний и навыков внешних консультантов штатным специалистам и экспертам компании-заказчика. Готовность разделять удачи и неудачи, риски и выгоды проекта должна быть одним из основных критериев отбора поставщиков.

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

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

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

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

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

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

Естественно, если уделять больше внимания выгодам для бизнеса, чем цене, затраты будут расти. Да и само управление поставщиками тоже требует расходов. Соотношение цены и качества в области закупок — сложнейший вопрос, решение которого надо искать в плоскости межличностных отношений, а не в прейскурантах базовых стандартных услуг. Ведь если самим не делать рынок, то рынок «сделает» нас. Хотим мы этого?

Александр Левинсон — независимый международный консультант по стратегическому ИТ-управлению, al@tolkin.nl