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

Риски ИТ-проектов: те из них, которые непосредственно связаны со взаимоотношениями с поставщиками. Как их можно снижать, как управлять этими рисками?

Михаил Заборов: Если работать по модели фиксированной цены, жестко требовать соблюдения сроков и бюджета, то поставщики стараются все возможные риски сразу заложить в цену. С рисками можно обращаться по-разному. Можно предотвращать, а можно заранее думать о том, что делать, если они реализуются. Предотвращать риски — это не единственный способ работать с ними и не самый правильный.

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

Чтобы это было возможно, мы максимальное число своих разработчиков знакомим с этими ключевыми процессами. Скажем, критичный объект — склад. Какое-то время непосредственно поработать там на внедрении должны все наши разработчики. Тогда у них не возникает безумных идей и попыток написать универсальное решение на все случаи жизни.

Мы говорим, что поставщик несет часть рисков заказчика, а заказчик — часть рисков поставщика. Как это делается? С одной стороны, поставщик говорит заказчику: мы понимаем, что есть ключевые бизнес-процессы, которые не должны останавливаться. И если в них происходит сбой, мы устраняем его любой ценой, в любое время, любыми своими ресурсами. Деньги обсуждаются потом, главное — не допустить простоя процесса или как можно быстрее устранить его. При этом заказчик должен понимать, что точно описать задачу — это практически решить ее.

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

Анатолий Третьяков: Прекрасно, все заказчики без ума от такого подхода, но не всегда возможно его реализовать. Всё же риски и их снижение — это проектное управление. Менеджер проекта принимает участие в проектировании систем и выполнении работ. Его прямая обязанность — своевременно выявлять и оценивать риски. Если что-то не определил — виноват, не компетентен. Это его профессиональная ошибка.

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

Это к вопросу о страховании рисков. Полного страхования рисков не существует. По моему опыту такого не происходит, в Европе в том числе. Риски минимизируются другим путем, например с использованием новых технологий, дублирования, катастрофоустойчивости и т. д.

Тогда остаются риски, которые можно измерить. Их может и должен фиксировать менеджер проекта. Если он долго проработал в компании, он может риски адекватно оценивать и сделать проект с высоким качеством. Ключ к минимизации рисков — качество управления и уровень зрелости процедур подрядчика.

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

Анатолий Третьяков: Но они минимизируются. Сделайте пилотный проект, попробуйте функционал.

Ольга Щепунова: Это время и деньги, что не всегда возможно, поскольку собственникам, например, хочется результата вчера. Вот буквальная цитата: «Я хочу от вас слышать, что то, что мне нужно, можно сделать быстро и дешево».

Рашид Амиров: В PMBook есть целая глава по управлению рисками, все это хорошо и правильно. Но есть риски прогнозируемые, и ими можно так управлять, а есть непрогнозируемые. Скажем, кто-то из клиентов может в любой момент изменить правила игры. Могут и регуляторы внести свой вклад. И что тогда делать? Или принимать риски, или не начинать.

Инфраструктурные проекты для нас обычно менее рискованные. В отличие от тех, что связаны с внедрением бизнес-ПО.

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

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

Обычно оценивают вероятность и критичность как две основные координаты. По ним можно оценивать, классифицировать риски. Результат оценки риска — действие. Если мы понимаем, насколько он вероятен и критичен, мы можем предпринять что-то адекватное для его устранения или компенсации последствий.

Но самое важное — это непрерывность работы с рисками. Мы перечислили их один раз, в начале проекта. Потом все намеченные действия, связанные с рисками, попадают в план проекта, в проектные документы, на которые опирается руководитель проекта. Но на этом в работе с рисками часто всё заканчивается, про них забывают. Это неправильно.

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

Есть смысл назначать и специальные встречи для анализа рисков. Но так или иначе, если проектная команда все время отслеживает риски, обсуждает их, это само по себе делает проект более предсказуемым, позволяет не довести риск до прокола, срыва.

Кирилл Алифанов: Классическая роль CIO — коммуникация: говорить с бизнесом, понимать его потребности, трансформировать их в ИТ-задачи. В области управления рисками — то же самое. Надо разговаривать с бизнесом. В моем опыте управления портфелями с большим числом проектов, проектным офисом и проч. начиная с третьей встречи о рисках практически забывали. Как идет проект? Да идет, продвигаемся, вроде бы всё в порядке. А о том, что риски, которые мы выявили в самом начале, вот-вот могут наступить, думают существенно меньше. Поэтому первое — это контроль рисков, их выявление и отслеживание. Второе — коммуникации.

Михаил Заборов: По поводу ожиданий. Удовлетворенность заказчика формируется так: восприятие того, что сделано, минус ожидания. Если ожидания были завышены, то даже получив что-то хорошее, человек останется недоволен. И точно так же он будет недоволен, если недостаточно хорошо сознает ценность того, что для него сделали (заниженное восприятие).

Я понимаю вашу веру в искусство управления, Анатолий. Но тут есть два подхода. Один — пытаться предвидеть будущее и спланировать его насколько возможно точно. Любое изменение плана — это катастрофа. Второй подход заключается в том, что не надо и пытаться полностью спланировать будущее и работы, не нужно предусматривать всё. Важно выделить те факторы, обстоятельства, особенности архитектуры, которые не изменятся. Если мы долгосрочно планируем в крупном, а детально — только на два-три месяца вперед и движемся небольшими шагами, то получим лучшие результаты, чем в попытках точно спланировать развитие событий и изменение требований на больших го­ризонтах.

Сергей Потапов: Снижение рисков проектов в условиях быстрой смены требований и условий — это вопрос архитектурный. Нужно найти такую архитектуру системы, которую не придется перестраивать при изменении, пусть даже значительном, внешних условий. Архитектурное решение должно быть гибким, настраиваться под изменения бизнеса.

Канал продвижения товаров и услуг, конфликты в нем. Чего желают от него клиенты, в чем видят противоречия?

Рашид Амиров: В канале происходит безобразие. Скажем, пришел ко мне интегратор, предлагает некий продукт. Предположим, мне это действительно нужно. Всё, он меня как клиента «столбит» у вендора, и больше никакой другой партнер этого вендора со мной работать не может. Я даже тендер провести не могу — с одним-то участником. Мне нужно, чтобы со мной в условиях конкуренции работали несколько фирм, но вендор им такого не позволяет. Кроме всего я еще и не могу выяснить, какую скидку этому единственному партнеру дали. Может, ему дали 30%, а он мне говорит, что пять, — в итоге я теряю 25%...

Анатолий Третьяков: Не совсем так. Конечно, существует система защиты сделок, обеспечение лояльности канала, но конкуренция есть всегда. Если у нас прямой выход на клиента, но мы вынуждены работать через канал, мы можем согласовать с этим первым застолбившим партнером цену для клиента. Тут все равно есть конкуренция — между вендорами, каждый из которых работает с этим заказчиком через своих партнеров.

Рашид Амиров: Нет тут никакой конкуренции. Если вы даете спеццены только тому своему партнеру, который первым поднял флаг, то из кого я буду выбирать? Этот партнер оказывается в неравных, лучших условиях.

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

И интересно еще, что скажут аудиторы и безопасники, когда увидят, что в тендере один участник.

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

Ольга Щепунова: Нет, люди не готовы к облачным технологиям, частично не готово ПО, не готовы технологические и законодательные платформы. Готовность людей будет определяться готовностью технологической, это как минимум.

Рашид Амиров: Даже если готов вендор, то у нас нет поставщика, который готов его здесь представлять. Кроме того, свои очень сильно кастомизированные приложения я могу вынести в облако только на колокейшн, не больше.

Кирилл Алифанов: Запад начал «дружить» с облаками на несколько лет раньше, чем Россия. И что я слышу сейчас от европейских коллег? Европа не в восторге от облаков, нет полного перехода к ним — здесь вопрос целесообразности: такой переход пока не показывает ожидаемого снижения затрат и по-прежнему несет риски для бизнеса. Кардинальные изменения начнутся, когда экономика предъявит серьезные требования к снижению затрат.

С другой стороны, сидеть сложа руки тоже нельзя: когда поставили задачу сократить ИТ-бюджет на 20–30%, в ИТ-департаменте уже был готов план перехода на виртуальную платформу и использование тонких клиентов. Описали для бизнеса, какие инвестиции потребуются и какой он получит от этого эффект. Именно эти требования формируют спрос к решениям вендоров и позицию заказчиков.

Анатолий Третьяков: У нас есть четыре референсных проекта в России, они были сделаны с привлечением партнеров — ведущих инте­граторов. Мы совместно переносили всю инфраструктуру заказчика в коммерческое облако. В одном из проектов мы предоставляем SAP ERP как сервис, где на базе нашей инфраструктуры интегратор предлагает свои услуги.

В наших международных датацентрах уже сегодня можно выбирать необходимую инфраструктуру онлайн, с динамически изменяемыми ресурсами, уровня Tier3+. Эта общая облачная инфраструктура базируется на шести собственных ЦОДах по всему миру. Кроме того, существует более сотни частных и коммерческих облачных инфраструктур с использованием наших решений на базе ЦОДов партнеров, которые уже практически полностью загружены.

В долгосрочной перспективе без резких изменений бизнес-среды выгоднее будет собственный ЦОД, но если говорить о быстрорастущем бизнесе — то облачный.

Сергей Потапов: Развитие идет, и идет адекватно. Облака станут превалирующей формой предоставления услуг, но насчет двух лет — не знаю. Если кто-то из больших игроков в России оценит риски, решится, сделает облачный проект, который окажется удачным, убедительным примером, тогда маховик закрутится и новая модель быстрее приживется.

Что же такое клиенториентированность?

Григорий Шевченко, коммерческий директор компании «Открытые Технологии»

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

Вот те роли, в которых, на мой взгляд, должен выступать партнер, чтобы его работа с клиентом из отношений, основанных на деньгах, превратилась в по‑настоящему партнерские отношения, основанные на поддержке и взаимном доверии.
1. Консультант. Партнер должен стать для клиента консультантом в той области, в которой развивается партнерство. Это накладывает на него обязательство постоянно быть в курсе происходящего: знать цели и задачи заказчика; принимать непосредственное участие в обсуждении и подготовке планов развития и обеспечения работоспособности ИТ‑систем; предоставлять аналитические и статистические данные, связанные с развитием бизнеса.
2. Организатор. Партнер является организатором развития ИТ‑систем клиента. Он становится не единственным, но старшим партнером, через экспертизу которого проходит вся модернизация ИТ‑систем. При этом речь не идет об аутсорсинге, поскольку этой формы отношений многие клиенты как раз побаиваются. К тому же у плохих аутсорсеров предполагается очерчивание с помощью SLA их зоны ответственности по типу: «К пуговицам претензии есть?». И что важно: бесплатно аутсорсинг не предлагается.

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

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

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

Что касается канала продвижения товаров и услуг, то в моем понимании канал — это дистрибьютор. От него требуется высокая скорость работы, низкая цена и отсутствие ошибок. Может ли клиент работать непосредственно с дистрибьютором? Может, если захочет. Но не предъявляя к нему дополнительных требований и не завышая своих ожиданий. Еще есть так называемые эксклюзивные парт­неры каких‑то вендоров, продукцию которых ни у кого, кроме них, не купишь. В этом случае говорить о клиенториентированности не приходится. В отсутствие конкуренции их главная задача — продать, а о качестве помнить не так важно.

Удачной альтернативой продажам стандартизированных ИТ-услуг для СМБ‑сегмента являются облака. Основная стратегия облачных провайдеров — максимально тиражировать свои услуги, расширяя их ассортимент. Клиенты облаков получают удобный и быстрый сервис, которому, однако, не хватает гибкости. Крупным же корпоративным клиентам нужна как раз та клиенториентированность, которую облака предоставлять не могут, да и не должны.