Автоматизация процесса закупки в дистрибьюторской компании

Автоматизация закупок в дистрибьюторских компаниях редко существует изолированно: закупка оборудования и софта для SFA-проекта, распределение затрат между производителем и дистрибьютором, интеграция с учетными системами партнеров — все это часть более широкой задачи управления большим распределенным проектом автоматизации продаж (SFA, Sales Force Automation). Разбираем рычаги, на которых держится такое управление: от организационной структуры проекта до конфликтов интересов между производителем и его дистрибьюторской сетью.

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

Роли и оргструктура SFA-проекта

Наилучшая, с нашей точки зрения, схема руководства проектом выглядит так:

• Руководитель проекта со стороны клиента: осуществляет общее руководство, согласует ТЗ, сроки, бюджеты, выступает представителем проекта перед спонсором, обеспечивает вовлечение в проект ресурсов клиента, отвечает за решение юридических и финансовых вопросов с соблюдением интересов, правил и норм со стороны клиента.
• Технический руководитель проекта: согласует ТЗ, отвечает за технологическую сторону внедрения системы SFA (написание интеграций, работы по установке, настройке, обучению пользователей, разработку ПО и так далее), контролирует ход выполнения работ в рамках своей ответственности и обеспечивает соблюдение технических требований клиента и договоров о сервисном обслуживании.
• Куратор проекта со стороны исполнителя: обеспечивает успешное внедрение и сопровождение системы SFA, планирует, выделяет ресурсы, координирует и обеспечивает результаты в соответствии с целями, требованиями, сроками, объемом работ и бюджетом, отвечает за ведение всех юридических и финансовых вопросов.
• Секретарь проекта со стороны исполнителя: ведет протоколы встреч, организует и согласует встречи, составляет расписание командировок руководителей и так далее.

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

Устав, план и бюджет проекта

Устав проекта

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

План развития проекта во времени

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

Бюджет проекта и закупка ресурсов для автоматизации

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

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

Переговоры о детальном бюджете, включая закупку оборудования и лицензий, должны проходить на возможно более ранней стадии проекта. Поскольку большой распределенный проект развивается итерационно, а на каждой итерации основные параметры (ТЗ, объем работ, сроки) могут существенно меняться, бюджет нужно пересматривать и заново согласовывать сторонами по ходу проекта. Ошибки в бюджетировании — кратчайший путь к провалу проекта.

Внедрение как итерационный процесс

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

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

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

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

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

Роль пилотного проекта

Здесь важна роль пилотного проекта, который выполняет сразу несколько функций:

1. Проверка компетенций и способностей поставщика. Клиент внимательно присматривается к поставщику, пытаясь снизить риски неправильного выбора.
2. Переформулирование и уточнение требований к системе. Пилотный проект — первая итерация циклического процесса «уточнение требований → разработка и тестирование → внедрение → уточнение требований». После внедрения появляется опыт эксплуатации, рождаются новые и уточняются старые требования к SFA, поэтому ТЗ меняется. В сетевом проекте, где любое даже мелкое отклонение от идеала будет многократно растиражировано, лучше провести несколько итераций пилотных проектов, постепенно уточняя требования.
3. Проверка готовности клиента к внедрению. Уже на первом этапе проекта клиент часто узнает о себе много нового: например, может выясниться, что производителю сложно договориться с дистрибьюторами по вопросам управления дистрибуцией, или что организационная структура клиента не готова к масштабному проекту в заданные сроки. Это приводит к изменению границ проекта и пересмотру его траектории прямо в процессе исполнения.

Как «продать» проект дистрибьюторам

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

Жесткие и мягкие дистрибьюторские сети

Можно выделить два типа дистрибьюторских сетей:

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

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

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

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

Задачи автоматизации на разных уровнях

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

Общие задачи для всех трех уровней:

• увеличение эффективности работы полевых сотрудников;
• управление оборотом товаров через разные каналы сбыта.

Для локальной структуры и дистрибьюторской компании также важны:

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

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

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

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

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

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

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

Конфликты интересов при автоматизации дистрибуции

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

Проблема покрытия территории

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

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

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

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

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

Конкуренция интересов производителя и дистрибьюторов

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

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

Из опыта автоматизации мягких сетей можно сделать один принципиальный вывод: обязательна интеграция системы SFA с корпоративной учетной системой дистрибьютора. Без этого мотивация дистрибьютора использовать систему остается низкой, а ведь именно его сотрудники на своих рабочих местах могут вовремя заметить отклонение от нормы и не дать недостоверным данным попасть в систему.

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

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

Для консолидации данных сразу от множества дистрибьюторов в едином контуре, без ручного сведения таблиц из разных учетных систем, используется ST Full DMS.

Закупка оборудования для SFA-проекта

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

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

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

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

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

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

Юридические взаимоотношения сторон

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

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

Цель — стратегическое партнерство

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

Идеальный вариант взаимодействия для снижения таких издержек — стратегическое партнерство, которое включает:

• высокую степень взаимной открытости;
• высокий уровень понимания стратегии партнера;
• единую команду проекта;
• обязательный взаимный учет интересов партнера: и заботу поставщика об интересах клиента, и заботу клиента об интересах поставщика.

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

Риски стратегического партнерства

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

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

Чтобы подобные отношения стали реальностью вместо декларации на бумаге, нужно выполнение нескольких условий:

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