Как закупать услуги для цифровой трансформации

01.11.18

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

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

Почему классический запрос предложений больше не подходит

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

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

При закупке услуг для создания и поддержания цифровой платформы акцент следует сместить с ее компонентов на (a) сроки и риски при тестировании, а также (b) развитие компании таким образом, чтобы она могла использовать преимущества платформы в полном объеме.

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

Варианты решения закупочной дилеммы

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

  • построение;
  • запуск (тестирование и оптимизация);
  • эксплуатация в стабильном режиме.

Объединять эти три фазы в рамках одного процесса запроса предложений ― слишком рискованно. Теоретически компания может объединить этапы построения и запуска, однако потребуется время, чтобы оптимизировать платформу, организовать и переорганизовать ее, и затем настроить платформу для ее более эффективной интеграции. Развитие платформы и развитие компании должны происходить параллельно, а для этого необходимо масштабное изменение мышления, что требует времени.

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

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

Эту дилемму можно разрешить двумя путями.

Вариант 1: отделить фазу построения от фазы эксплуатации

Если компания объединяет фазы построения и запуска, не владея достаточной информацией об операционной среде, которая разовьется на базе бэк-энда платформы, и не будучи в состоянии адекватно описать эту операционную среду, она рискует получить платформу, которая не работает. Почему? Когда фазы построения и запуска объединены, поставщик услуг будет постоянно изменять начальную заявленную стоимость услуг на этапе фазы запуска и эксплуатации. Это будет мешать построению оптимальной платформы.

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

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

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

Вариант 2: подход «Построить-Запустить-Передать»

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

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

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

Питер Бэндер-Сэмьюэл, Forbes.com

Перевод: Кристина Мелюк, B2B-Center

Другие статьи:

Этот веб-сайт использует файлы cookie для повышения удобства работы. Работа на веб-сайте подразумевает согласие со сбором данных посредством файлов cookie.
Принять