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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Оборудование

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

Ни один производитель не в состоянии протестировать ПО во всех возможных вариантах использования. Например, одна из наших программ для КПК содержит более 150 настроечных параметров для учета специфики клиента. Количество всех возможных конфигураций для тестирования равно 10 в 45-й степени — невероятно большое число вариантов. Даже если бы все население Земли круглосуточно занималось тестированием нашего ПО, понадобилось бы время, в сотни миллиардов раз превышающее возраст нашей Галактики! Поэтому ПО всегда тщательно тестируется лишь для небольшого количества очевидных ситуаций, а их подбор определяется опытом производителя. В конкретном случае всегда может сложиться ранее не проверенная комбинация параметров, в которой ПО даст сбой.

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

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

Особенности формирования бюджета

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

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

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

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

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

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

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

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

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

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

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

Сергей Максименко — генеральный директор OOO «Системные технологии»; S.Maksimenko@sys4tec.com

Жесткие и мягкие сети

Жесткой называют территориально распределенную дистрибьюторскую компанию с централизованным управлением системой региональных подразделений, едиными стандартами ведения бизнеса и общей системой управленческого и бухгалтерского учета. Мягкой — сеть, организуемую производителем из локальных дистрибьюторсих компаний. Фактически существует множество локальных дистрибьюторов, которые предоставляют производителю услугу на определенной территории, а производитель только структурирует данную услугу. Структура существует только с точки зрения производителя, так как с точки зрения локального дистрибьютора он просто оказывает услугу по заданным извне стандартам в силу своих возможностей. Подробно о проблемах автоматизации тех и других рассказывается в статье «Масштаб имеет значение» (см. «Директор ИС», № 6/2008).

Ключевые уроки

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

Качество системы SFA — это не безошибочный код, а, прежде всего, способность поставщика быстро и эффективно решать возникающие проблемы.

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

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

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

Для успеха проекта юридические отношения между поставщиком и клиентом должны отражать эффективное распределение ответственности и рисков проекта.

Идеальные отношения между поставщиком и клиентом в проекте SFA для большой сети — стратегическое партнерство.