Популярные практики и технологии менеджмента. Польза или вред. (с фасилитацией)

Анатолий Курочкин пишет:
Статья не стоит бумаги, на которой она написана. Тем не менее мы обсуждаем её. Мне пока не ясна Ваша личная позиция, Павел. Может быть и правда подошло время вынести некоторый вывод?

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

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

Что касается выводов, то это будут выводы не по статье, а по обсуждению.

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

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

Думаю, что тут мы влезаем в еще одну интересную сферу - компетентностные знания. Тут возникает то, что называют Best Practice (в русском переводе используют термин "лучшие практики", а в теориях обучения - противный на слух термин "истинное знание"). Соответственно, нужно разобратьсмя с этими понятиями в логике цикла Берча. А далее, когда начинаем говорить об изменениях проверенных технологий, возникает вопрос об основаниях для таких изменений и реализация идеи развития технологий (мастерства) в логиках восточной школы обучения (Сю-Ха-Ри).

Иначе мы все время изобретаем велосипеды с квадратными колесами

И хотя я согласен насчет гибкого использования разных методик, понятие гибкого использования разных методик не означает волюнтаристское выдергивание из методик каких-то элементов и их их соединение в своей личной логике 

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

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

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

Евгений Равич пишет:

Я - честно - не знаю, почему такой бурный интерес возник именно к матричномуу управлению. Идея достаточно проста, появилась очень давно,

Наверное, потому что это самая знакомая всем участникам дискуссии из перечисленных в статье  "модная штучка" )

Любопытный факт про реинжениринг) (японцы писали)

Когда популярная американская книга по реинжинирингу бизнес-процессо

Ирина Плотникова пишет:
Наверное, потому что это самая знакомая всем участникам дискуссии из перечисленного в статье  "модная штучка" )

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

Ирина Плотникова пишет:
"На самом деле в Японии предпринимается очень мало усилий по реинжинирингу; по оценкам некоторых экспертов, в этой области Япония отстает от Запада как минимум на пять лет.

Кто же тогда покупает книгу?

Практически каждый служащий не потому, что реинжиниринг захлестывает Японию, а потому, что хороший служащий хочет быть тщательно подготовленным на тот случай, если его босс спросит его, что такое реинжиниринг!" )

Очень хороший пример!

Могу привести аналогию, в СССР читали работы Ленина и иных классиков, изучали марксизм-ленинизм не потому, что в этом был какой-то практический смысл, но могли спросить и не только на экзамене.

Павел Вайнштейн пишет:
Взвимодействие и подчинение - это разные вещи. Исполнитель работает на заказчика, но не подчиняется ему. Как часто пишут в договорах - "выполняет запросы закачика, самостоятельно определяя способ и т.д." 

Но приведенный Вами пример показывает, что без правильной организации очень быстро может наступить бардак

Поэтому, руководители проводили планерки и совещания с участием всех заинтересованных сторон, на которых обсуждали проблемы, принимали решения, раздавали поручения.

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

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

Павел Вайнштейн пишет:

Евгений Равич пишет:
Это не обязательно - например, когда участие в проектах и есть основная обязанность сотрудника.

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

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

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

Возьмём условную компанию, честно работающую по нескольким типам  контрактов. Никак иначе она деньги не получит. Для выполнения контрактных обязательств у неё есть человеческие ресурсы - допустим, 100 занятых позиций в 10 категориях. Иногда этого достаточно, иногда нет. Иногда часть ресурсов простаивает. Ничего особенного.

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

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

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

Обратите внимание, что слово "проект" я вообще не употреблял, хотя в списке контрактов могут быть и такие.

Ирина Плотникова пишет:

Евгений Равич пишет:

Я - честно - не знаю, почему такой бурный интерес возник именно к матричномуу управлению. Идея достаточно проста, появилась очень давно,

Наверное, потому что это самая знакомая всем участникам дискуссии из перечисленных в статье  "модная штучка" )

Если не смотреть на возраст. И, как показывает беседа в этой ветке, мы пока обсуждаем, что же это такое.

Возможно, из-за того, что эта штучка - большая редкость, или используется слишком неформально и без указания её названия.

Кто же тогда покупает книгу?

Практически каждый служащий не потому, что реинжиниринг захлестывает Японию, а потому, что хороший служащий хочет быть тщательно подготовленным на тот случай, если его босс спросит его, что такое реинжиниринг!" )

Теперь я понял. Надеюсь, что босс остался доволен ответом, второй раз не спросит, всё это можно немедленно забыть и бежать за следующей книжкой.

Но как знать, о чём босс спросит в следующий раз? Не покупать же всё подряд.

Анатолий Курочкин пишет:

Евгений Равич пишет:

Павел Вайнштейн пишет:
Матричная - это когда один руководитель организует операционную деятельность сотрудника, а другой - его участие в проектах.

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

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

Согласен с вами - вариантов много! На мой взгляд, разделение матрицы на функциональное, административное, проектное, операционное как-то подустарело, особенно в ИТ. Конечно, систематизация в таком ключе, теоретическая попытка что-то каталогизировать всегда полезна, но участники могут одновременно работать в проекте, в своём чистом функционале, строгог стстоять в иерархии. Наглядный пример утраты таких границ- работа DevOps-инженера.

Матрица - это просто визуализация каких-то связей, существующих или планируемых. 

Но вопрос вовсе не в том, как нарисовать матрицу или - тем более - как её назвать. Базовых вариантов орг. схем не так и много - штуки три плюс любые гибриды в зависимости от уровня иерархии и от страны до комнаты включительно.

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

И без ответа на этот ключевой вопрос ожидаемого улучшения не будет.

Евгений Равич пишет:
Простите, не понял, что именно мы обсуждаем. Никогда не слышал ни о проектном управлении в таком контексте, ни о доминировании проектной работы, ни даже о таких названиях. Никакой простоты в этом названии я тоже не увидел.

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

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

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

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

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

Т.е. не начинаем с изобретения велосипеда, а берем готовый "велосипед" и проводим настройку его работы в конкретных условиях. Причем в рамках предусмотренных настройками этого "велосипеда".

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

А вот оставлять велосипед, но приматывать к нему моторчик исходя из своих представлений о велосипедах, моторчиках и всем остальном - не самый лучший подход.

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

********

Кстати, пример из другой сферы. Не самый близкий, но тем не менее.

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

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

Павел Вайнштейн пишет:

Ирина Плотникова пишет:
Наверное, потому что это самая знакомая всем участникам дискуссии из перечисленного в статье  "модная штучка" )

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

Добчинский. Нет, Петр Иванович, это я сказал: «э!»

Бобчинский. Сначала вы сказали, а потом и я сказал.
«Э! — сказали мы с Петром Ивановичем.

)))
Эту "модную штучку" поднял я, и про 10 начальников (у автора "несколько"):

Анатолий Курочкин 14 августа 2024, 16:08 пишет:

Евгений Равич пишет:

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

Но чем автору матричная модель не понравилась? Это далеко не "десять начальников".

Как ответ на это:

Дело конечно не в том, кто первый сказал "Э". )))

Благодарю Вас,Павел, за высказывание позиции:

Павел Вайнштейн пишет:

Анатолий Курочкин пишет:
Статья не стоит бумаги, на которой она написана. Тем не менее мы обсуждаем её. Мне пока не ясна Ваша личная позиция, Павел. 

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

Что касается выводов, то это будут выводы не по статье, а по обсуждению.

Но дальше уточню уже свою позицию.

Павел Вайнштейн пишет:

Иначе мы все время изобретаем велосипеды с квадратными колесами

И хотя я согласен насчет гибкого использования разных методик, понятие гибкого использования разных методик не означает волюнтаристское выдергивание из методик каких-то элементов и их их соединение в своей личной логике 

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

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

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

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

Но к лучшим практикам надо внимательно присматриваться, несомненно. И не пускать на самотёк, типа само собой построится.

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

Анатолий Курочкин пишет:
Эту "модную штучку" поднял я, и про 10 начальников (у автора "несколько"):

Совершенно верно..)))

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

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

Так что я не претендую на то, что первый начал говорить об этом. Я претендую на то, что как фасилитатор заметил Ваше начало и усилил его..)))))

Павел Вайнштейн пишет:

Кстати, пример из другой сферы. Не самый близкий, но тем не менее.

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

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

Всё-таки уточню. За спиной имею несколько удачных внедрений ЕРП. В историческом смысле было всё-таки не так. На время "истерики по ERP" (так назвал это А.Карпачёв, создатель Паруса) потребители не верили, что возможна универсальная база для множества операций разного типа, класса, сложности. Поэтому и цеплялись за отдельные системы кадрового, налогового, бухгалтерского, логистического учёта. Они прекрасно понимали величину доработок. Но дело не в вере в уникальность их компании. 

А затем, Вы правы, возникло понимание возможности любых доработок. 

Павел Вайнштейн пишет:

Анатолий Курочкин пишет:
Эту "модную штучку" поднял я, и про 10 начальников (у автора "несколько"):

Совершенно верно..)))

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

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

Так что я не претендую на то, что первый начал говорить об этом. Я претендую на то, что как фасилитатор заметил Ваше начало и усилил его..)))))

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

Павел Вайнштейн пишет:

Евгений Равич пишет:
Простите, не понял, что именно мы обсуждаем. Никогда не слышал ни о проектном управлении в таком контексте, ни о доминировании проектной работы, ни даже о таких названиях. Никакой простоты в этом названии я тоже не увидел.

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

Проекты - совершенно определённый формат работы. Он может сочетаться с любыми другими форматами в любой компании, чем бы она не занималась. Или быть отдельными продуктами.

Проектная организация - да, слышал. Их много. А в СССР было еще больше. Проектное управление - нет, не слышал. Кто автор этого термина - если это термин?

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

Виды деятельности (в РФ) для начала указаны в уставных, учредительных, лицензионных и прочих документах организации.

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

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

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

Совершенно верно. Это не обязательно. Есть факторы сезонности, есть смена продуктов и линеек, реорганизация производства и т.д.. Могу продолжить.

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

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

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

Анализируя деятельность компании, мы

Кто такие "мы" в этой фразе? Менеджеры и сотрудники компании? Приглашённые консультанты? Исследователи, собирающие материал для статьи?

Я бы начал с менеджеров.

идентифицируем одну из уже описанных стандартных ситуаций и определяем соответствующие этой стандартной ситуации описанные и опробированные инструменты.

Допустим, что данные собраны, анализ закончен, проблему мы обозначили. Осталось предложить решение и опробовать его на практике. И это пока всё.

О велосипедах, если не возражаете, поговорим отдельно.

********

Кстати, пример из другой сферы. Не самый близкий, но тем не менее.

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

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

О том, в чём когда-то были уверены практически все потребители, я бы не говорил.

Это обычный и понятный мне пример на тему COTS и проблем кастомизации и внедрения в крупных проектах. Может занять годы. Посмотрите при случае на статистику успеха проектов внедрения ERP и, заодно, CRM.

Но к матричному управлению именно этот пример отношения не имеет.

Анатолий Курочкин пишет:
На время "истерики по ERP" (так назвал это А.Карпачёв, создатель Паруса) потребители не верили, что возможна универсальная база для множества операций разного типа, класса, сложности. Поэтому и цеплялись за отдельные системы кадрового, налогового, бухгалтерского, логистического учёта. Они прекрасно понимали величину доработок. Но дело не в вере в уникальность их компании. 

Я в данном случае поделился своими наблюдениями. Причем я это наблюдаю порой даже сейчас (последний раз лет 5 назад). Более того, мы обсуждали данную проблемц как раз с "Парусом", когда они звали меня заниматься развитием их компании. Год не помню, но очень давно. Наверно конец 90-х. 

Так вот, в нашем обсуждении мы затрагивали две проблемы.

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

• непонимание идеи целостности системы
• флияние функционадьных колодцев
• неправильное понимание логик децентрализации
• недостаточность финансирования и стремление сэкономить

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

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