К наиболее сложным элементам затрат можно применить принцип сегментирования.

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

Но ваша деятельность охватывает широкий спектр взаимодействий с клиентами. Для одних видов взаимодействий высококачественный, тесный контакт действительно важен; для других нет. В некоторых случаях он может быть даже нежелателен, поскольку отнимает слишком много времени. Клиентская база также неоднородна: у одних клиентов активы составляют $5 млн, у других всего $100 000.

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

Или возьмем пример из индустрии программного обеспечения. У вас есть команда разработчиков в районе залива Сан-Франциско или в долине Темзы в Великобритании. Общие затраты на разработчика составляют $150 000, что очень много. Чтобы уменьшить расходы, вы хотите перевести операции за границу, в Индию, где затраты на разработчика даже с учетом дополнительных накладных расходов и расходов на коммуникацию не превышают $50 000.

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

Решение лежит в сегментировании проблемы. Чтобы уменьшить риски, связанные с переводом разработки ПО за границу, можно сначала опробовать этот подход на конкретных подзадачах, которые:

• удалены от конечного потребителя;

• не являются критическими для разработки продукта;

• требуют стандартных, широко распространенных технических навыков;

• не требуют тесного, интенсивного взаимодействия с командой разработчиков из головного офиса.

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

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