«Создай себе досуг, чтобы научиться чему-нибудь хорошему и перестать блуждать без цели.»
 
Консалтинговая компания Марк Аврелий


Управление presale-проектом: продажа высокотехнологичных услуг в свете методологии PMBOK

 ЖУРНАЛ «УПРАВЛЕНИЕ ПРОДАЖАМИ», 4-2012.

Предпродажа – так буквально переводится прочно вошедшее в наш обиход, изначально, вообще-то, сленговое англоязычное слово «presale». В высокотехнологичных отраслях (системная интеграция, разработка ПО, консалтинг, телеком и др.) его все чаще в последние годы произносят в сочетании с понятием «проект». Но есть ли для этого достаточные основания? Не точнее ли – а главное, не продуктивнее ли – будет говорить лишь об этапе проекта? Или лучше о стадии функционального процесса продаж? Занимаясь в течение последних десяти лет практически в равном соотношении как продажей относительно больших (стоимостью до 10 млн $) консалтинговых и  IT-проектов, так и управлением ими, я составил собственное, пока далеко не полное и не окончательное мнение на этот счет. Этим мнением до сих пор я делился только со своими слушателями на MBA-программах по изучению Project Management в ведущих столичных вузах и бизнес-школах, а теперь хочу пригласить к участию  в обсуждении и читателей данного журнала.

Сразу оговорюсь, что в ряде известных мне интеграторских компаний presale-стадия процесса продаж высокотехнологичных услуг и продуктов играет часто значительно более важную роль в проекте, чем его последующие стадии. Разумеется, там, где есть хороший presale, автоматически должен иметь место и sale (заключение контракта, получение денег и т.п.), и after sale (уточнение потребностей, развитие концепции продукта, масштабирование, upsale – «допродажа»). Однако задачи этих, последующих стадий, за редким исключением, успешно решаются в проектных компаниях непосредственно в логике самого стандарта Project Management. Поэтому в данной статье я их не рассматриваю, хотя сама по себе тема взаимодействия процесса  продажи с процессом исполнения проекта (что как раз и составляет специфику продаж проектов) также представляется мне довольно продуктивной, малоизученной и практически не описанной в профессиональной литературе.

Согласно стандарту PMBOK «проект – это временное предприятие, предназначенное для создания уникальных продуктов, услуг или результатов» [2]. Ну, по поводу уникальности результата тут вряд ли поспоришь: продажа технически сложного, продолжительного по времени (иногда до года) и дорогого по стоимости проекта, скажем, внедрения ERP-системы или построения в организации системы показателей BSC – это всегда задача нетривиальная. Что касается определения «временное», тут все обстоит сложнее. Предсказать заранее, к какому конкретно сроку усилия продавца приведут к заключению контракта, как правило, никто не берется. Преодолению этого несоответствия проектному стандарту может поспособствовать, на мой взгляд, портфельное управление пресейл-проектами – если в портфеле конкретного продавца есть несколько независимых предпродажных тем (или «лидов»), то появляется скорее уже статистическая возможность заранее назначить каждой из них разумный срок реализации, по истечении которого проект лучше закрыть, вне зависимости от результата.

Следующая по важности методологическая проблема возникает при выявлении ролей стейкхолдеров (то есть заинтересованных лиц – буду писать их далее с заглавной буквы, чтобы не путать с реальными функциями контрагентов фирмы) пресейл-проекта. С Проджект-менеджером и Спонсором проекта все более или менее ясно: менеджер по продажам отвечает за продажу – ведь именно продажа (заключение контракта), собственно, и есть конечный «продукт» пресейл-проекта. Спонсирует пресейл-проект, очевидно, руководитель компании или ее функционального подразделения, выделяющий материальные и трудовые ресурсы для проведения презентаций, выездов на переговоры к клиенту, разработки коммерческих предложений и т. п. Но кто же тут выступает в роли Заказчика – потенциальный клиент компании? Вряд ли, ведь он пока ничего не платит. И ни за что не отвечает в плане корректности и осмысленности высказываемых им предварительных пожеланий и требований к будущему продукту…

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

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

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

Интеграция

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

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

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

·         проведение презентации
·         разработка технического обоснования
·         предварительная оценка рисков
·         расчет стоимости проекта
·         отправка коммерческого предложения
·         обсуждение с заказчиком этапов проекта и графика платежей
·         подготовка и подача конкурсной заявки…
    Этот список легко продолжить на основе, например, «Вопросника по открытию проекта» из приложения к великолепной книге Рассела Арчибальда «Управление высокотехнологичными программами и проектами», выдержавшей в России уже несколько переизданий [1].

Содержание

Начало процессов управления содержанием высокотехнологичного проекта традиционно вываливается из его самого первого «штатного» этапа (по разным современным методологиям он может именоваться, например, диагностикой, экспертизой, обследованием или анализом осуществимости) как раз в «незаконнорожденный», факультативный этап пресейла. Или же проект пресейла – и тогда требования именно к управлению содержанием (а не пассивному его накручиванию в угоду самым заоблачным пожеланиям клиента) становится гораздо легче формализовать, подчинив отраслевым ГОСТам и нормативам. Когда определяется персональный состав заинтересованных сторон проекта? В какой момент на самом деле происходит сбор требований стейкхолдеров? Когда концептуально (а значит, критически с точки зрения содержания) в реальной жизни определяются основные очертания будущего продукта, то есть так называемый Product Scope?

После недавней беседы с руководителем проектного офиса компании «Альфа-Страхование» Галиной Денищенко, известным бизнес-консультантом и методологом, автором популярного учебника «Управление внедрением информационных систем», я в очередной раз убедился, что в подавляющем большинстве случаев к моменту подписания контракта и открытия официального проекта все фундаментальные, необратимые решения по нему уже приняты. Что это значит практически? А это значит, что хорошо известная нам из PMBOK диаграмма «Влияние переменной, основанной на сроках проекта», если нанести на нее вертикальную черту подписания контракта, отделяющую пресейл от собственно проекта, для большинства реальных проектов будет выглядеть существенно пессимистичнее – см. рисунок.

Рисунок. Влияние переменной, основанной на сроках проекта, на его стоимость и риски с учетом средней сравнительной длительности этапа предпродажной подготовки и этапов реализации проекта

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

Сроки

Впрочем, прежде чем говорить о бюджете, куда более важно определиться со сроками. Тем более что как видно из приведенного выше рисунка, сроки пресейл-этапов, по мнению многих практиков проектного управления, в последние годы уже практически сравнялись с длительностью реализации самих проектов. При этом даже получившая широкое распространение идея управления продуктом проекта на протяжении всего его жизненного цикла (то есть и за пределами собственно сдачи готового изделия заказчику, вплоть до финальной его утилизации или перехода на новую версию) не мешает интеграторам игнорировать описываемые нами проблемы этапа предпродажи. Вот, например, как описан жизненный цикл типового проекта на сайте компании E-Style Software House: «Процесс разработки и ведения проектов в компании E-Style Software House организован в соответствии с моделью CMMI и стандартом ISO 9001, с использованием практик и рекомендации методологий MSF, RUP, PMBOK… Открытию проекта предшествует фаза предпроектных работ (Presale). Полный жизненный цикл состоит из следующих основных фаз:

·         Анализ осуществимости проекта (Feasibility Study)

·         Бизнес-анализ и проектирование (Elaboration)

·         Разработка (Construction)

·         Внедрение (Implementation)

Наличие фазы Feasibility Study зависит от специфики проекта. Анализ осуществимости проводится в случаях, когда для оценки всего проекта необходимо выполнить ряд предварительных работ исследовательского характера… После завершения проектных работ компания предоставляет гарантийную поддержку и услуги по сопровождению системы» [3].

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

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

Стоимость

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

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

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

Некоторые, не в меру опытные проджект-менеджеры и руководители подразделений компании-исполнителя начинают «играть» затратами по реальным и пресейловым проектам, перебрасывая с первых на последние все больше и больше совместно используемых в них человеческих и материальных ресурсов. В итоге по внутрифирменным документам проектного учета внешние проекты выглядят как просто сверхприбыльные (а значит, их менеджеры и команды заслуживают бонуса), а вот пресейловые проекты постепенно превращаются в так называемые «помойки», куда списывается не только вся сбытовая активность технических специалистов проектных команд, но и большая часть их малоэффективной производственной деятельности. В итоге общая прибыль компании критически снижается. Чтобы избежать этого, можно порекомендовать использование специальных методологических и/или программных решений, позволяющих четко разграничить бюджеты предпродажных и реальных проектов.
 
В этой статье рассмотрены только основные, наиболее бросающиеся в глаза особенности пресейл-проекта, относящиеся к первым четырем, ключевым, на мой взгляд, областям знаний стандарта PMBOK. В дальнейшем я надеюсь еще вернуться к теме и поговорить о таких ее аспектах, как качество, человеческие ресурсы, коммуникации, риски и закупки проекта.
 
ЛИТЕРАТУРА
 
1. Арчибальд Р.Д. Управление высокотехнологичными программами и проектами. — М.: Академия АйТи, ДМК Пресс, 2010.
2. Руководство к своду знаний по управлению проектами (Руководство PMBOK). — Project Management Institute, 2008.
3. Типовой проект. — http://www.estylesoft.ru/tip_proj.shtml