Заказчик и Исполнитель – взаимоотношения как основа успеха проекта

Выстраивание взаимоотношений на начальном этапе

Итак, с чего начинаются взаимоотношения с клиентом?

Как приходит клиент? Либо он сам обращается, либо нам кто-то рекомендует его, как компанию, которая хочет автоматизироваться.

С чего мы начинаем? Мы не бросаемся к телефону сразу договариваться о встрече – мы начинаем собирать информацию об этой компании.

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

Для чего это нужно? Для эффективной работы, чтобы на основании полученной информации выработать тактику первоконтакта.

Потом происходит первоконтакт. На нем мы, в первую очередь, выясняем:

• Что нужно клиенту?
• Адекватен ли он с точки зрения своего представления о порядке рыночной стоимости за данную работу и согласен ли платить за то, что ему нужно? Это – очень важный вопрос. Естественно, на первой встрече никто не называет каких-то конкретных сумм, но может быть назван порядок цифр или некий интервал, куда скорее всего попадет проект. Выясняется отношение к этим цифрам. Например, если мы приблизительно оцениваем, что этот проект стоит 3-5 миллионов, а потенциальный заказчик считает, что миллион – это очень много, то, наверное, у нас с ним ничего не получится. К тому же часто бывает, что у клиента нет четкого представления о том, что ему нужно: просто хочет, чтобы все было хорошо.
• На основе этого мы уже можем сделать вывод – нужен ли нам такой клиент, и нужен ли такой проект.

Установление взаимоотношений

Второй этап – это установление отношений с клиентом:

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

Результатом этого этапа является предварительное решение о работе с данным клиентом и формирование положительного образа в глазах клиента.

Хочу остановиться на формировании положительного образа. На основе собранной первоначальной информации мы решаем, кому из наших сотрудников можно доверить представлять нашу фирму на первой встрече с клиентом. Это очень важный момент. Например, если мы отправим на первоконтакт прекрасного специалиста, но у него серьга в ухе, набриолиненный «кок» и т. д., то клиент может посмотреть и сказать: «да ну его!» Такое бывает. Или, например, пришел аккуратненький, подстриженный, в костюме с галстуком, но мальчик лет 20. И клиент смотрит и говорит: «Это же мальчишка, о чем с ним говорить? Как с ними работать – они меня совсем не уважают, прислали ко мне мальчишку!». Поэтому сбор этой информации нужен в том числе и для того, чтобы понимать, кому доверить первоконтакт и как себя вести контактеру, как выстраивать легенду, как преподносить себя.

Выявление лиц, принимающих решения

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

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

Цель, как вы уже видите, – это выявление ЛПР. И результат – это список ЛПР и лиц, влияющих на ЛПР.

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

Установление партнерских отношений

Следующий этап – установление партнерских отношений.

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

Ну и результатом этого этапа является фиксация (формальная или неформальная) отношений равных партнеров:

• Формальная фиксация – это договор.
• А неформальная – это могут быть какие-то служебные документы, в которых мы всегда стараемся прописывать «Первую и Вторую сторону» и их отношения.

Информирование Заказчика о технологии ведения проекта

Следующий этап – это информирование заказчика о технологии.

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

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

Организация отношений с Заказчиком

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

• Контракт-менеджер – это «плохой». Это может быть отдельный человек или кто-то из топ-менеджеров. Чаще всего функцию контракт-менеджера выполняет руководитель проекта (если он, конечно, в состоянии это сделать). Это человек «Нет» – он может прийти к лицу принимающему решения, и сказать: «у нас по контракту написано вот так, а вы сейчас делаете по-другому, и из-за этого возникает отклонение. Давайте разбираться». Он всегда указывает на недостатки, на несоблюдение технологии, призывает соблюдать документацию – поэтому он всегда «плохой».
• А объект-менеджер – это «хороший». Это человек, у которого в силу разных причин сложились хорошие отношения с лицом принимающим решения от заказчика. Может быть, он просто оказался ему симпатичен. Или, например, у них есть какие-то связи (родственные, клановые, дружеские – какие угодно). Главное, что клиент к нему расположен.
  Объект-менеджер у нас фактически ведет этот объект. Обратите внимание, это не проект-менеджер, это специальный человек, который занимается тем, что поддерживает хорошие отношения с руководством заказчика, и, когда возникают какие-то острые проблемы, он их сглаживает.
  Например, после того, как контракт-менеджер выговорил клиенту о несоблюдении каких-то условий наших договоренностей (это может закончиться, в общем-то, каким-то нелицеприятным для нас разговором), приходит объект-менеджер и начинает успокаивать клиента.
  Я не зря сказал, что объект-менеджер называется «хорошим». Обычно говорят, что «хороший парень» – не профессия. Но у нас это профессия. Объект-менеджер – это «хороший парень». Он может не быть специалистом-профессионалом ни в чем, но с ним клиенту хорошо – он пришел, поговорил с ним (может быть, о политике, о футболе и т.п.), и клиенту стало хорошо, у него изменилось отношение. Клиент до этого собирался нам что-то выговаривать, за что-то нас наказывать, но теперь он уже все понимает, ему вообще неудобно с нами плохо говорить.
  Вот это – функция объект-менеджера. Он закрепляется за каждым достаточно серьезным клиентом.

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

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

Организация проектных процессов

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

• Мониторинг хода проекта;
• И принятие управленческих решений по результатам мониторинга.

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

Иногда убедить заказчика работать по нашей технологии бывает очень сложно. Например, у нас был один клиент – очень крупная ИТ-компания. Причем она сама занималась автоматизацией на MS Navision, но в силу определенных причин решила позвать нас, чтобы мы их автоматизировали на 1С. Так вот, работа с ними была настоящим кошмаром – плакали все, и менеджеры, и программисты. Потому что это была очень крупная компания (мы по сравнению с ними мелкие), и они считали, что они все знают, и пытались нас учить. Они постоянно говорили: «ребята, вы не так все делаете, есть же такая-то технология, вы должны делать так». Естественно, это происходило только на уровне среднего звена, руководитель (который был основным собственником и генеральным директором компании), конечно, все прекрасно понимал, и после его вмешательства все решалось, но его очень трудно было достать. А на уровне среднего звена были постоянные проблемы, постоянные попытки научить.

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

Ограничение желаний клиента

Следующий этап – это ограничение желаний клиента. С этим, наверное, сталкивались все (когда начинаются так называемые «хотелки» – еще, еще и еще). Здесь мы поступаем достаточно просто:

• Например, когда клиент говорит, что в отведенные рамки бюджета и сроки надо еще сделать вот это и вот это, то начинается достаточно порой, сложная процедура объяснений, как все это работает. Мы напоминаем клиенту о том, что у нас с ним заложен бюджет, выделены люди (объединенная рабочая группа), каждая сторона проекта вкладывает свои ресурсы. Поэтому если возникает дополнительная работа, то требуются дополнительные часы, дополнительные люди. Откуда их брать?
  Или если клиент задерживает проект, то и наши,  и его люди простаивают, а им платятся деньги. Откуда брать эти ресурсы? Я уже не говорю о том, что эти люди не просто получают зарплату, но и приносят какую-то прибыль компании. Естественно, компания не хочет терять эту прибыль. Достаточно подробно клиенту объясняется, и клиент обычно очень хорошо реагирует.
• Мы разъясняем, даем подробную цифровую раскладку – откуда, что, до копеечки. И говорим, что если вы хотите, чтобы мы сделали еще и вот это, то – пожалуйста, это займет столько-то часов, и их надо оплатить. В конце концов, клиент с нами соглашается и либо отказывается от своей "хотелки", либо оплачивает дополнительные часы. Конечно, бывает по-разному – я сейчас немного идеализирую картину.

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

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

Кто занимается объяснением этого бюджета:

• Этим в рабочем порядке занимается проект-менеджер – руководитель объединенной рабочей группы, которая, собственно, и выполняет проект.
• Если у него не получается, то подключается контракт-менеджер, который объясняет по циферкам и говорит, что это – нарушение контракта, нарушение договоренностей.
• В самых сложных случаях подключается объект-менеджер, который старается объяснить (уже, конечно, без каких-то жестких рамок) заказчику то, почему ему необходимо ограничить свои желания.

Обычно, если цифры расписываются очень подробно, тогда этой раскладки и её объяснения бывает достаточно.

Сдача работ

Сдача работ. Здесь, в общем-то, больших проблем обычно не бывает, потому что процедура сдачи работ у нас очень подробно прописана в соответствующих документах.

Но на этом этапе элемент неформальности (хорошее отношение), конечно, также облегчает жизнь и нам, и заказчику тоже.

Цель этого этапа – добиться сдачи работ в полном соответствии с правилами, установленными в соответствующих документах, которые являются приложением к договору, подписанному и клиентом, и нами. Соответственно, всегда можно предъявить, что есть такие правила.

Постпроектные взаимоотношения

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

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

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

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

******

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.