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

Олег Фофанов, e-xecutive.ru

Заказчик хочет поручить сторонней организации (например, консультанту) решение некоторой проблемы (выполнение некоторой работы). Кто должен определить необходимый объем работ и перечень задач? Заказчик или исполнитель? Или может быть они должны совместно участвовать в формулировании «технического задания»?

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

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

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

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

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

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

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

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

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

На таком «зрелом» этапе мы можем увидеть другую картину — попытки оставить весь цикл разработок и производства в рамках одной компании уже не дают эффект (требуемый уровень качества уже достигнут), а затраты на поддержание такой интегрированной системы огромны и не окупаются. Как следствие, такая компания обречена проиграть в себестоимости и уступает долю рынка более стандартным продуктам (например, Apple в 90-е).

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

Таблица 1. Варианты работы над техническим заданием

Существует надежное решение

Известно консультанту

Решение известно Клиенту

Форма работы консультанта над проблемой

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

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

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

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

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

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

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