Меня зовут Осипов Андрей. Я эксперт по управлению проектами. В области управления проектами работаю уже порядка 14 лет. Четыре последних года являюсь сертифицированным специалистом в 1С, работал в различных сферах: в электроэнергетике, в приборостроении, в машиностроении, с «железом» (программным обеспечением и программными продуктами).
Моя статья посвящена построению эффективного взаимодействия с Заказчиком. Мы все с вами занимаемся той или иной деятельностью, которая основана на общении с клиентом и его ключевыми пользователями. На протяжении всего процесса, от начала до завершения, мы сталкиваемся с различными проблемами. В этой статье я постараюсь рассказать об общих и индивидуальных трудностях и проблемах, которые приходится преодолевать.
-
Как вовлечь Заказчиков в проект уже на этапе подготовки коммерческого предложения?
-
Чем сбалансировать загрузку проектных команд?
-
Все ли так гладко в технологиях внедрения проектов?
-
Можно ли управлять ожиданиями Заказчика на всем пути?
-
Что поможет заинтересовать пользователей при внедрении и не растерять энтузиазм к финишу?
Подробно рассмотрим каждый из этих вопросов ниже.
Клиент получает коммерческое предложение и не понимает, за что он должен заплатить деньги
Как вовлечь заказчиков в проект уже на этапе подготовки коммерческого предложения?
Официальное взаимодействие с клиентом начинается с подготовки коммерческого предложения по его запросу. Часто клиент, получая коммерческое предложение, не понимает, за что он должен заплатить деньги.
Предложение, которое клиенту неинтересно (стандартное КП):
-
Включает в себя только план-график и стоимость. Большинство коммерческих предложений, которые я видел – это предложения на один-два листа: план-график, стоимость, название этапов.
-
Содержит непонятные названия этапов работ. Клиент видит их впервые и не понимает, что означают эти непонятные слова.
-
Не отражает особенностей Заказчика. Не учитываются особенности того, как он ведет свою учетную политику.
-
Не содержит информации о подходах. Нет никакой информации о том, что мы ему предлагаем и с какими подходами будем работать.
Чаще всего при таком подходе данное предложение бывает интересно клиенту только в одном случае: низкая цена. Многие компании готовы демпинговать. Но этот вариант интересен не всем, потому что хорошая, качественно выполненная работа стоит денег.
КП формируется совместно с Заказчиком
Чем сбалансировать загрузку проектных команд?
Мы изменили подход к формированию коммерческих предложений – расширили его по нескольким аспектам.
Что мы сделали:
-
Добавили цели и задачи, функциональность, которую Заказчик получит при работе с нами.
-
Описали каждый этап проекта. Каждый этап разбили на виды работ, которые мы выполняем.
-
Описали ожидаемые результаты. Какие результаты в рамках этих работ получит клиент и что мы можем ему предложить.
-
Обозначили объем работ Заказчика в проекте для согласованности работ сторон при формировании КП.
-
Добавили ограничения проекта. Если мы работаем с одним юридическим лицом, а у клиента их пять, это обязательно нужно добавить в коммерческое предложение.
Делаем все максимально прозрачным и понятным для клиента.
Что это дало:
-
Полноценную обратную связь. Клиент, читая такое коммерческое предложение, начинает его понимать, у него возникают вопросы – правильные, понятные, корректные, то есть по делу.
-
Корректные понятные вопросы «по делу». Клиент начинает эти вопросы нам транслировать, начинается общение. Итеративным способом коммерческое предложение корректируется до того момента, пока клиент не получит такой продукт, такой результат в рамках коммерческого предложения, который сможет понять.
-
Понимание клиентом, что он покупает. Чаще всего в компаниях заказчиков сбором коммерческих предложений занимается не директор или спонсор, а какой-либо исполнитель. Ему в любом случае нужно будет защищать это предложение перед спонсором. И если у него на руках есть документ, который в первую очередь понятен ему, он сможет корректно взаимодействовать со своим спонсором и качественно защитить это предложение.
Заказчики выбирают других исполнителей в рамках запросов предложений
Даже хорошее коммерческое предложение не всегда приводит к тому, что в итоге мы заключаем договор с клиентом. Часто бывает, что Заказчики выбирают других исполнителей. Одна из причин, с нашей точки зрения, в том, что недостаточно просто качественно подготовить коммерческое предложение, необходимо еще и качественно взаимодействовать с Заказчиком и понимать его, то есть выстраивать с ним взаимоотношения.
Мы, как и многие компании, раньше работали по принципу: есть менеджер отдела продаж, который ведет клиента. Он подключает проектный отдел тогда, когда нужно рассчитать трудоемкость будущего проекта и внести какие-то корректировки. После этого клиент вновь остается один на один с отделом продаж.
Этот подход не очень хорош, потому что, как говорят, «одна голова хорошо, а несколько лучше». Мы объединили проработку по лидам между отделом продаж и проектным отделом. На входе, когда у нас появляется входящий лид, мы формируем команду, которая состоит из специалиста отдела продаж, нескольких специалистов проектного отдела (чаще всего это руководитель проектов и архитектор) и иногда из специалистов по конкретному направлению.
Эти специалисты:
-
Формируют команду,
-
Готовятся к будущим встречам,
-
Совместно изучают документы заказчика,
-
Формируют перечень вопросов, которые необходимо задать,
-
Совместно выходят на защиту коммерческих предложений.
Таким образом, вся обратная связь от клиента, которую мы получаем, становится релевантной. Мы можем качественно отработать ее как во время встречи, так и в дальнейшем при проработке, чтобы выйти на хорошую защиту коммерческого предложения и учесть все замечания. Более того, этот формат расширяется за счет оффлайн-общения с клиентом.
Уже достаточно давно мы группируем клиентов по регионам и выезжаем к ним, иногда по нескольким лидам сразу. Например, последний раз мы за четыре дня посетили восемь клиентов в Москве и Московской области. Некоторые из них были достаточно «холодными». В результате у нас были четыре заключенных проекта, а с двумя клиентами мы продолжили вести диалог. Статистика сама за себя говорит: по сравнению с предыдущим финансовым периодом, когда мы еще не использовали такой подход, количество проектов увеличилось более чем в два раза. Что явно показывает эффективность этого метода.
Клиент готов сотрудничать, но имеет ограниченный бюджет на реализацию своих задач
Бывает так, что клиенты готовы с нами сотрудничать, им понравилось коммерческое предложение и команда, но у них есть ограничения по бюджету. Эти ограничения могут касаться разных подходов к реализации проекта.
Мы все понимаем, что подходы к выполнению работ могут быть разными, и каждый из них стоит своих денег. Например, можно реализовать комплексный проект по 1С:ТСВ или 1С:ТКВ. Также можно выбрать технологию 1С:ТБР – настроить что-то небольшими частями и при необходимости остановиться. Или работать с системой через небольшие доработки уже внедренных решений. Все эти подходы мы практикуем в компании.
Когда мы беремся за крупный комплексный проект, его реализация обычно идет с разной интенсивностью. Если в договоре не прописаны этапы согласований и сроки утверждения документов или продуктов, то на больших и сложных задачах Заказчик зачастую уходит в долгое согласование. В результате команда простаивает. Если в договоре этот момент прописан, то приходится вести диалог с Заказчиком о том, что простой необходимо оплачивать, определять дополнительный бюджет.
Чтобы избежать нагнетания ситуации и сохранить эффективность работы, мы берем проекты с разным бюджетом, применяя разные технологии. К крупному комплексному проекту мы можем дополнительно взять один проект поменьше, например, по технологии 1С:ТБР (настроить производственный учет) и небольшие доработки, которыми всегда можно будет дозагрузить команду.
В процессе выполнения большого проекта у нас есть возможность перераспределить ресурсы специалистов на менее сложные, но более длительные проекты. Это делается для того, чтобы по основному проекту у клиента не возникало простоев. Все работает по принципу win-win: наши специалисты не теряют темп работы, а у Заказчика есть возможность спокойно подумать и принять решения.
Системные проблемы при реализации проектов на различных этапах (несоответствие ожиданий, отказ от приемки работ)
Все ли так гладко в технологиях внедрения проектов?
На внутренних проектах нередко возникают системные проблемы применения технологий внедрения:
-
Несоответствие ожиданий. Чаще всего проблемы связаны с несоответствием ожиданий, и как следствие, заказчик может отказаться от приемки работы. С чем это связано, не всегда понятно.
-
Невовлеченность заказчика. Реализуя разные задачи внутри компании, мы пришли к выводу, что если задача более-менее глобальная и если в ней участвует много людей, то становится много ответственных. В итоге ответственность рассеивается, и задача может «зависнуть» или плавно загнуться.
-
Длительные согласования приводят к затягиванию сроков выполнения.
Внедрение различных инструментов, например СППР и Itilium, необходимо осуществлять с помощью проектных методологий.
У нас есть собственные проектные методологии. Мы организовывали такие проекты внутри компании и столкнулись с теми же проблемами, которые возникают у наших Заказчиков. Хотя, казалось бы, как проектные исполнители, мы знаем, как работать и как внедрять. Наши клиенты могут не иметь такого опыта и подхода к деятельности. Наши уставы и прочие внутренние процессы для них нерелевантны.
Внедряя внутри компании проекты по нашим же проектным технологиям, мы столкнулись с тем, что Заказчик не вовлечен, слишком занят, ожидания не совпадают, процессы затягиваются из-за длительных согласований. Почему так происходит и как с этим работать, изначально было непонятно.
Понимание причин проблем. Мы начали анализировать и поняли, что наши проектные технологии по своему строению – это гибридные подходы с «отпечатками» нашей собственной компании. Анализируя наши методы, мы выявили причины, по которым возникают проблемы в тех или иных случаях.
Сбор конструктивной обратной связи. Внутри компании легко построить конструктивный диалог с Заказчиком и внести необходимые исправления.
Внесение исправлений. После работы с этими замечаниями мы поняли, что становимся лучше. Каждая наша проектная технология может быть улучшена внутри компании на примере собственных проектов. Этот опыт также ценен для обучения молодых специалистов: новые сотрудники в компании не всегда знают все подходы сразу.
Тренировка «на кошках». Внутренние проекты – это та сама тренировка «на кошках», которая позволяет научиться и в дальнейшем успешно участвовать в серьезных проектах с реальными клиентами.
Экологичная токсичность. Тренировка «на кошках» создает такую внутреннюю «экологичную» среду, которая и не слишком давит, и помогает расти.
Выдаваемые исполнителем продукты не соответствуют ожиданиям Заказчика
Можно ли управлять ожиданиями Заказчика на всем пути?
По моему личному мнению, соответствие ожиданиям – один из самых важных аспектов при реализации любого проекта. Ожидания присутствуют практически в любой области, связанной с проектом, и всегда есть работа по управлению этими ожиданиями. Важная задача любой проектной команды – выстроить корректные, прозрачные взаимоотношения с клиентом и организовать свою деятельность так, чтобы свести к минимуму непонимание.
Наиболее остро проблема несоответствия ожиданий проявляется при сдаче продукта или результатов по этапу либо подэтапу, и это портит взаимоотношения.
Для профилактики несоответствия ожиданий мы выделили отдельную область – документальное сопровождение проекта. И постарались его стандартизировать, чтобы с самого начала, при входе в проект, у клиента была понятная картина: что он получит на каждом этапе работы проекта.
Что проработано в документе:
-
Типовой формат коммерческого предложения. Документ стандартизирован и описан.
-
Обезличенные проектные документы по аналогичным проектам. Эти документы создаются при старте работ с клиентами для того, чтобы клиент понял, что он получит на этапе обследования, моделирования, как будет выглядеть концепция или проект. Их можно сделать в рамках преддоговорной деятельности.
-
Шаблоны всех проектных документов в договоре. Клиент может проанализировать концепцию и дать свои замечания. Документы на ранней стадии проекта корректируются и выполняются в договоре в виде шаблонов.
Договор становится достаточно объемным. Иногда его основная часть – это примерно одна четвертая или одна пятая, а остальное – шаблоны проектных документов.
Что получено в результате:
-
Проработка основных аспектов проекта в рамках подготовки КП. Изначально подготовка такого пакета документов может занять некоторое время, но при переходе к стандартизации работать станет гораздо проще.
-
Отработка замечаний по продуктам, корректировка под клиента. При старте проекта останется только небольшая корректировка.
-
Юридически закрепленная документация. В работе с клиентом уменьшится количество итераций на документацию, потому что она юридически закреплена.
Это ведет к снижению трудозатрат на переработку документов в процессе реализации проекта и повышению скорости его выполнения.
Невовлеченность пользователей Заказчика при внедрении
Что поможет заинтересовать пользователей при внедрении и не растерять энтузиазм к финишу?
Пользователи заказчика при внедрении – одна из наиболее сложных и зачастую проблемных областей. Это такая «болезненная мозоль» у каждой проектной команды, которая занимается внедрением. Для нас проект – это всегда основная деятельность, а для Заказчика – прикладная. Выделить достаточный ресурс, несмотря на все объяснения на старте проекта, практически невозможно. Клиент обычно пребывает в гонке, а его пользователи часто отстают.
Чтобы нивелировать этот момент или хотя бы минимизировать нагрузку, мы разработали в рамках своей технологии несколько этапов, позволяющих распределить загрузку ключевых пользователей в процессе работы на проекте.
Вовлекаем команды Заказчика в этапы разработок проекта
Демо-показы учетной системы при старте проекта. Проводим демонстрацию учетной системы на ранней стадии, еще до входа в проект и обследования. Это позволяет за одну-две недели показать, как работает типовой продукт, что он из себя представляет. Особенно это важно для пользователей, переходящих с других учетных систем или с Excel – чтобы они понимали, что именно проектируется и как конечный продукт им предстоит использовать в будущем.
Совместное моделирование. После сбора требований мы приступаем к моделированию, разворачивая две базы данных. Одна база всегда располагается на сервере клиента и предназначена для пользователей. Это позволяет продемонстрировать, что и как будет работать. После этого ключевой пользователь может делать операции в своей базе, принимать решения и возвращаться с обратной связью. Такой подход дает хорошие результаты, поскольку исключает необходимость повторных встреч или напоминаний.
Проверка доработок. В рамках внедрения крупной системы всегда возникает необходимость в доработке типового функционала. Мы формируем техническое задание, в котором прописываем четкие тест-кейсы. Это позволит сначала консультанту, а затем пользователю проверить доработки по сценарию тестирования. После этого дается корректная, качественная обратная связь, которая позволяет устранить недочеты еще до запуска проекта.
Проводим тестовую эксплуатацию
-
Разворачиваем отдельную базу,
-
Переносим все ключевые НСИ, важные для пользователя,
-
Берем какой-нибудь закрытый период,
-
Переносим остатки,
-
Тестируем.
Подходы могут различаться: тестировать можно по волнам, в течение длительного времени, или сравнивать результаты работы с предыдущей учетной системой. Тестирование позволяет отработать все возможные вопросы у клиента. Обычно оно занимает 3-4 недели. Некоторые компании отводят на тестирование всего пару дней с перерывами. Мы считаем, что это создает чрезмерную нагрузку на пользователей и снижает эффективность. Лучше растянуть процесс, совместить с обучением и ставить задачи в течение месяца. Тогда в день у ключевых пользователей уходит на это не более полутора часов, что существенно уменьшает стресс и нагрузку.
Обучаем перед запуском. Если кто-то из сотрудников не участвовал в проекте, мы проводим обучение. Но чаще всего это не требуется, так как ключевые пользователи уже хорошо знакомы с системой и готовы к запуску в продуктив. Это позволяет сэкономить бюджет, время и сократить сроки запуска. Заказчики довольны, нагрузка распределена, стрессовых ситуаций – минимум.
Выводы
-
С Заказчиком необходимо работать с самого начала, уже с первой встречи.
-
Важно внимательно относиться к деталям и особенностям каждого клиента. Каждый клиент уникален, поэтому требуются индивидуальный подход и гибкость.
-
Анализируйте и рефлексируйте всю собранную информацию – это особенно важно при запуске проекта.
-
Чем бережнее мы относимся к клиенту, тем бережнее он будет относиться к нашим консультантам и тем проще ему будет работать в будущем.
*************
Статья написана по итогам доклада (видео), прочитанного на конференции Анализ & Управление в ИТ-проектах.
