Построение эффективного взаимодействия с Заказчиком

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

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

1. Как вовлечь Заказчиков в проект уже на этапе подготовки коммерческого предложения?

2. Чем сбалансировать загрузку проектных команд?

3. Все ли так гладко в технологиях внедрения проектов?

4. Можно ли управлять ожиданиями Заказчика на всем пути?

5. Что поможет заинтересовать пользователей при внедрении и не растерять энтузиазм к финишу?

Подробно рассмотрим каждый из этих вопросов ниже.

Клиент получает коммерческое предложение и не понимает, за что он должен заплатить деньги

Как вовлечь заказчиков в проект уже на этапе подготовки коммерческого предложения?

Официальное взаимодействие с клиентом начинается с подготовки коммерческого предложения по его запросу. Часто клиент, получая коммерческое предложение, не понимает, за что он должен заплатить деньги.

Предложение, которое клиенту неинтересно (стандартное КП):

• Включает в себя только план-график и стоимость. Большинство коммерческих предложений, которые я видел – это предложения на один-два листа: план-график, стоимость, название этапов.

• Содержит непонятные названия этапов работ. Клиент видит их впервые и не понимает, что означают эти непонятные слова.

• Не отражает особенностей Заказчика. Не учитываются особенности того, как он ведет свою учетную политику.

• Не содержит информации о подходах. Нет никакой информации о том, что мы ему предлагаем и с какими подходами будем работать.

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

КП формируется совместно с Заказчиком

Чем сбалансировать загрузку проектных команд?

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

Что мы сделали:

• Добавили цели и задачи, функциональность, которую Заказчик получит при работе с нами.

• Описали каждый этап проекта. Каждый этап разбили на виды работ, которые мы выполняем.

• Описали ожидаемые результаты. Какие результаты в рамках этих работ получит клиент и что мы можем ему предложить.

• Обозначили объем работ Заказчика в проекте для согласованности работ сторон при формировании КП.

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

Делаем все максимально прозрачным и понятным для клиента.

Что это дало:

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

• Корректные понятные вопросы «по делу». Клиент начинает эти вопросы нам транслировать, начинается общение. Итеративным способом коммерческое предложение корректируется до того момента, пока клиент не получит такой продукт, такой результат в рамках коммерческого предложения, который сможет понять.

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

Заказчики выбирают других исполнителей в рамках запросов предложений

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

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

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

Эти специалисты:

• Формируют команду,

• Готовятся к будущим встречам,

• Совместно изучают документы заказчика,

• Формируют перечень вопросов, которые необходимо задать,

• Совместно выходят на защиту коммерческих предложений.

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

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

Клиент готов сотрудничать, но имеет ограниченный бюджет на реализацию своих задач

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

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

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

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

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

Системные проблемы при реализации проектов на различных этапах (несоответствие ожиданий, отказ от приемки работ)

Все ли так гладко в технологиях внедрения проектов?

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

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

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

• Длительные согласования приводят к затягиванию сроков выполнения.

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

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

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

Понимание причин проблем. Мы начали анализировать и поняли, что наши проектные технологии по своему строению – это гибридные подходы с «отпечатками» нашей собственной компании. Анализируя наши методы, мы выявили причины, по которым возникают проблемы в тех или иных случаях.

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

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

Тренировка «на кошках». Внутренние проекты – это та сама тренировка «на кошках», которая позволяет научиться и в дальнейшем успешно участвовать в серьезных проектах с реальными клиентами.

Экологичная токсичность. Тренировка «на кошках» создает такую внутреннюю «экологичную» среду, которая и не слишком давит, и помогает расти.

Выдаваемые исполнителем продукты не соответствуют ожиданиям Заказчика

Можно ли управлять ожиданиями Заказчика на всем пути?

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

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

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

Что проработано в документе:

• Типовой формат коммерческого предложения. Документ стандартизирован и описан.

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

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

Договор становится достаточно объемным. Иногда его основная часть – это примерно одна четвертая или одна пятая, а остальное – шаблоны проектных документов.

Что получено в результате:

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

• Отработка замечаний по продуктам, корректировка под клиента. При старте проекта останется только небольшая корректировка.

• Юридически закрепленная документация. В работе с клиентом уменьшится количество итераций на документацию, потому что она юридически закреплена.

Это ведет к снижению трудозатрат на переработку документов в процессе реализации проекта и повышению скорости его выполнения.

Невовлеченность пользователей Заказчика при внедрении

Что поможет заинтересовать пользователей при внедрении и не растерять энтузиазм к финишу?

Пользователи заказчика при внедрении – одна из наиболее сложных и зачастую проблемных областей. Это такая «болезненная мозоль» у каждой проектной команды, которая занимается внедрением. Для нас проект – это всегда основная деятельность, а для Заказчика – прикладная. Выделить достаточный ресурс, несмотря на все объяснения на старте проекта, практически невозможно. Клиент обычно пребывает в гонке, а его пользователи часто отстают.

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

Вовлекаем команды Заказчика в этапы разработок проекта

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

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

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

Проводим тестовую эксплуатацию

• Разворачиваем отдельную базу,

• Переносим все ключевые НСИ, важные для пользователя,

• Берем какой-нибудь закрытый период,

• Переносим остатки,

• Тестируем.

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

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

Выводы

• С Заказчиком необходимо работать с самого начала, уже с первой встречи.

• Важно внимательно относиться к деталям и особенностям каждого клиента. Каждый клиент уникален, поэтому требуются индивидуальный подход и гибкость.

• Анализируйте и рефлексируйте всю собранную информацию – это особенно важно при запуске проекта.

• Чем бережнее мы относимся к клиенту, тем бережнее он будет относиться к нашим консультантам и тем проще ему будет работать в будущем.

*************

Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.