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