Умный консалтинг 2.0

• время – логично, что на этой оси есть три состояния: вчера, сегодня, завтра (ну или прошлое, настоящее, будущее);

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

Два критерия, где у каждого по три состояния дают нам поле три на три:

• в центре у нас всегда объект анализа в том виде, как он есть сегодня;

• вчера – это то, что предшествовало и привело к текущему состоянию;

• завтра – то, куда хотим попасть.

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

Объектом анализа может быть и отдельное подразделение или процесс: в этом случае надсистема это предприятие, а подсистема – отдельные сотрудники, функции.

Использовать инструмент можно:

• для диагностики проблем компании;

• для разработки стратегии бизнеса;

• для планирования программы внедрения изменений.

и вообще для любого вида анализа или моделирования, которое предполагает динамику. Именно в возможности рассматривать явления в динамике и заключается (для меня) полезность инструмента.

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

Пример: Запрос на информацию

#консультанту, #руководителю проекта, #инструмент

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

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

Помните! Этот список не догма (и в полном виде может оказаться Вам избыточным или), и должен адаптироваться под Ваши конкретные задачи.

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

Смотри также статьи:

«Профиль клиента»

Систематизация работы на проекте. Реестры

#консультанту, #руководителю проекта, #инструмент

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

• реестр юридических лиц, входящих в бизнес-систему консультируемой компании (особенно актуально для холдингов) – учесть, что разные люди могут именовать эти юрлица по-разному;

• реестр структурных подразделений, входящих в бизнес-систему, их абревиатуры (опять же – подразделения могут иметь разные именования);

• реестр продукции (если номенклатура большая, то по основным товарным группам);

• глоссарий основных терминов (в т.ч. технологических);

• реестр фамилий, имен сотрудников и их контактные координаты;

• реестр основных отчетных документов, имеющих хождение в компании;

• реестр нормативно-методической документации;

• реестр процессов, функций и так далее.

В каждом проекте может быть востребована своя структура списков.

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

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

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

Смотри также статьи:

«Пример: о порядке взаимодействия заказчика и консультанта»

Установочное совещание команды проекта

#консультанту, #руководителю проекта, #вывод из опыта, #коммуникации

Установочное совещание команды проекта служит реализации сразу нескольких целей:

• познакомить участников проекта друг с другом, что особенно важно для комплексных проектов, привлечения людей из разных подразделений (работа даже за соседними столами не гарантирует, что вы уже знаете друг друга, а не просто дежурно-вежливо здороваетесь или только вчера приняты в компанию);

• описать клиента: не только «техническую» часть (размер компании, доля рынка, производственная технология, число филиалов…), но и «психологическую» (характер руководителей, их предпочтения, взгляды, особенности речи, используемую терминологию);

• рассказать об ожиданиях клиента, о том, что должно измениться в компании-клиенте и что именно будет сделано в виде фактического результата проекта;

• описать методологию, предложенную клиенту (очень часто в компаниях нет единой методологии выполнения работ, а каждый продвигает что-то свое – но проект есть проект, выполняться будет так, как продали);

• настроить команду проекта на выполнение работы и достижение результатов, внушить им уверенность в успехе, в их знаниях и навыках;

• обменяться мнениями, задать вопросы;

• распределить задачи, установить сроки и условиться о коммуникациях.

Проводить совещание возможно по-разному: