Тема является инструментальной.
Цель для автора - оценить отношение аудитории к современным технологиям и подходы, используемые при анализе таких тем.
Для участников это хорошая возможность продемонстрировать сои знания, аналитические способности, опыт и т.д. Т.е. все то, что хочется демонстрировать в дискуссиях. При этом, с учетом широты вопроса, принять участие смогу практически все.
Недавно (11.07.24) на РБК была опубликована статья о вреде современных "содных" технологий в менеджменте. На этом ресурсе уже возникали подобные дискуссии. Например, о циклах Адизеса или бирюзовых компаниях.
Однако, в каждой из этих тем рассматривался и обсуждался ровно один инструмент, что ограничивает возможность участия (не все разбираются в этом инструменте) .
Предлагаемая статья хороша тем, что рассматривает разные технологии и соответственно, повышает вероятность для участников найти "свою" тему.
Естественно, каждый участник будет писать то и так, как он хочет, но я бы предложил держать в фокусе внимания следующие вопросы:
1. Согласие ли несогласие с идеей в целом
2. Анализ конкретных технологий
3. Анализ используемой автором аргументации
Примечание:
Поскольку статья находится на РБК в разделе с ограниченным платным доступом, ссылка будет доступна не всем, а скопировать текст из таких разделов РБК не дает.
Поэтому, чтобы дать доступ всем участникам, я размещу эту статью в своих следующих сообщениях в виде набора из 13 скриншотов.
Средняя заработная плата в компаниях — участниках рейтинга составила около 155 тыс. руб. в месяц.
Число вакансий для студентов и начинающих специалистов выросло за год на 15%.
Основные требования – широкий социальный пакет, а также все условия для комфортного пребывания в офисе.
При этом дефицит кадров наблюдается во всех отраслях.
Спасибо.
Кстати, признаюсь, что если бы не Вы,и не Ваша реплика, я бы сделал ошибку с выбором фокуса внимания. В этот момент я склонялся к теме 6 сигма. Но как сейчас понимаю, она бы так не сыграла.
Это калька с западного Project Management System. Первоисточник найти не удается, о чем пишут в соответствующих научных статьях. Ссылаются на Ганнта и Файоля, но без аргументации.
В прямом переводе - это можно трактовать как "система управления проектами", что не совсем равно "проектное управление". Но несет тот же смысл. С этим понятием, как и с прилагавшейся к нему технологии проектного офиса я сталкивался в материалах американского института PMI. И именно в контексте материалов PMI я считаю перевод "проектное управление" корректным. Однако, не могу утверождать, что именно они эти понятия ввели в обиход.
Что касается видов деятельности, то если Вы про ОКВЭД, то это о том, чем занимается компания, а проректное управление - это о том, как она организует эту работу. Т.е. немноого разные вещи. Так, например, если компания реалищует типовые строительные проекты (ОКВЭД 71.12), то несмотря на проектный характер услуг, организовать их исполнение можно в операционном режиме.
Эти названия используются и определяются в уже упоминавшемся тут станларте РМ ВОК.
Да. Тут возражений нет.
Да. Это не о матричном управлении, а о выборе между стандартным решением и изобретением своего собственного уникального.
А вы обратили внимание, что поддержка исправила ошибку с открытием сообщений после перехода на новую страницу?
Так что им спасибо!
По поводу типов матрицы (мягквя, жесткая и т.д.) еще одна информация
В одной из статей, на которые у нас тут были ссылки в ряду контраргументов против моей позиции, как раз описываются эти понятия.
Вот данная ссылка:
https://www.indeed.com/career-advice/career-development/matrix-management
Если мы серьёзно, то это вовсе не калька и не прямой перевод. Всё хуже. Это пример потери смысла и источник дальнейшего непонимания.
PM - это Управление Проектом. а не Проектное Управление. Трактовать это не нужно.
А HRM касается управления персоналом, а не Человеческое Управление.
А Service Management - Управление Сервисом (ами), а не Сервисное Управление.
Уверен, что Вы меня поняли.
В какой версии - в первый раз?
Тогда предлагаю продолжить о матричном управлении - и как менеджеры.
Да, это мне знакомо. На практике это не так важно или содержательно, начиная с того, что менеджеру проекта не нужны ресурсы, пока нет нового проекта.
А после открытия проекта начинается стандартное планирование и согласование менеджеров, кто, где, когда, на кого и сколько работает. Человек может участвовать и в нескольких проектах одновременно, работая с несколькими менеджерами проектов, и не только на них - в зависимости от состава работ и разного рода обязательств. Так матрица рождается и меняется по ходу дела.
Но матричная схема и проекты изначально о разном. Может быть и то, и другое, что-то одно (любое) - или ничего,
Еще раз, для применения именно матричной схемы в компании нужна какая-то веская причина и обоснованное решение. При этом компания может вообще не работать в формате проектов.
Было-было ))
Когда очередная шттучка станет новомодной и песней-сиреной консультантов ))
Вы, вы, Анатолий ) подтверждаю )
В третьем издании (2004 год) это точно упоминается. (нашел).
При этом там дются типы орг структур. И это не виды деятельности а именно органищация работы.
Приведены следующие базовые структуры:
И если мы трактуем работу функциональной струкитуры, как функциональное управление, а не управление функциями, то и проектную структуру нужно трактовать, как проектное управленгие, а не управление проектами.
Это с опорой на РМ ВОК
Я же опирался на материалы PMI с более подробным описанием PMS (проектного управления), видов матриц и проектного офиса.
Хорошо. Но чтобы не было недопониманий, могли бы Вы сформулировать, что для Вас значит "как менеджеры" и какой именно аспект матричного управления Вы хотите обсудить с позиции менеджеров.
Наверно самый простой вариант - просто начните изложение своих тезисов
Да, спасибо. Нашел в четвертом, оно потолще и на расстоянии вытянутой руки. Третье издание слишком долго искать.
Нет, это, естественно, не виды деятельности. Примеры оргструктур, показывающие место менеджера проекта в организации..
Как в них организована работа - совершенно отдельный вопрос. На схемах этого нет.
В моём издании есть также Composite (стр. 31, если что). Но не важно.
Структуру можно нарисовать. Управление (менеджмент) нарисовать нельзя, но можно что-то прочитать. Или посмотреть, начиная с Файоля, который слово менеджмент вообще не употреблял, что в него входит, и как именно.
В данном случае мы поговорили об существующей организации, её возможной структуре, например - матричной (не важно, какой - слабое, обычное и крепкое пиво остаётся пивом) и об управлении проектом (!) - а не организацией - с точки зрения PMBoK v3 или v4. Отлично.
Для более содержательной беседы о матричной схеме (если это еще интересно) PMBoK нам больше не нужен. Есть гораздо более подробные книги с примерами в части Organizational Behavior и много хороших статей. Идеи матричного управления появились, если я не сильно ошибаюсь, когда PMI еще не было.
И мы ничего не трактуем без необходимости. Всё и так понятно .
С матрицами всё ясно, а PMO предлагаю пропустить.
Всё, что я мог для начала сказать, уже изложено выше в ветке. Буду рад ответить на вопросы, если они появятся.
Тема очень моя. Основная претензия к концепции Бережливого производства и объединённым ею инструментам, технологиям с цветными качествами компаний и руководителей заключается в неконкретности и упрощении подходов до маразма. Основная проблема заключалась в замене научных изысканий в менеджменте маркетингом попсовых инструментов повышения эффективности. Эффективность управления достигается применением инструментов содержащих конкретные методы основанные не на рекомендациях, а на инструкциях. Например, теория ограничения систем или методы статистического анализа. Но предложение на рынке технологий управления пошло по пути примата формы над содержанием.
Да. Я тоже наше и в четвертом и в пятом. Но просьба была - найти первое упоминание. Вторшго издания у меня нет, а в третьем нашел, о чем и написал. Было ли раньше - не могу сказать
Да. В РМ ВОК все очень куцо. Поэтому в свооей работе я и опираюсь на более подробные матриалы PMI.
************
Похожая история у меня была со стандартами IDEF.
Дочка ищзучала их в институте и выполняла курсовую. По методичке ничего не получалось. Препод объяснить не мога. Пришла ко мне. Я подсказал и пояснил, что в методичке написано неправильно. Описал как надо. В курсовой все сложилось.
Дочка пошла в институт и на леккции сказала преподу - вы нам все неправильно рассказываете. Возник скандал. Препод через интернет нашел переводы и тексты стандартов - вот доказателтсва, я права. Дочка ко мне - дай пруфы иначе я как дура. А пруфов нет. Весь интернет завален версиями как у препода.
При этом я знаю/помню, что все не так. В общем, с большим трудом нашел на американских ресурсах этот первоисточник. Доказали. Ходила героиней. Вся группа пришла ко мне на практику.
Но вообще все время имею в виду, что важну. инфу нужно скачивать. Но то забываю, то она по разным причинам теряется.
Да. Это есть и в третьем издании, Но не стал упоминать, чтобы не отвлекать.
Тут вопрос не такой простой. Я не специалист в пиве, но как понимаю, там разница только в процентах. А в типах матричного управления разница в алгоритмах. И в этих матрицах они очень разные. Я это изучал именно по материалам PMI. Детальные описания алгоритмов, процессов и решений. И это работает.
Вы правы насчет предыстории. Термин возник гораздо раньше, но изначально, как отмечала Ирина, понимание было другим. То старое понимание я никогда не использовал и не внедрял.
В целом соглашусь. Поэтому сильно возражаю против современных подходов, когда реальные алгоритмы прячутся (хотя они есть), а публикуются общие идеи с упрощениями. Но со словами "это и есть технология". Такой "нехороший" маркетинг, на основе которого потом возникают предложения "Не получается? Мы вам это сделаем".
Не научим, а именно сделаем за вас. Однако, пользователь прочитав общее описание со словами "это такая технология" и проникшись идеями, начинает делать как он понял, затыкая многчисленные дыры и нестыковки своими фантазиями. И оп=па - вот вам мои любимые карго-культы или рахзочарования в технологиях с последующим написанием разоблачающих статей
Алгоритмах, простите, чего? Есть примеры? И алгоритмы ли это, или какие-то различия в процессах и процедурах.
Но я бы предложил начать с начала (а не с середины, как в PMBoK, где некоторые варианты оргструктур перечисляются как данность) и ответить на первый вопрос: зачем нам может понадобиться матричная структура?
Для простоты можно не думать о проектах - только о ситуациях, когда схема двойного и более подчинения имеет очевидные преимущества.
Совершенно согласен. И позаботиться о системе учета, добавив туда же книги и статьи. Но это пока мечта. Только кусочками и на некоторые темы с классикаторами UDC и - отдельно - старой библиотечной системой в статусе EOL. Найдёте или подскажете что-то удобное - буду очень благодарен.
Да. Тут тогда нужно согласовывать терминологию. Я пока в своем ответе не придавал этому значения.
Отвечу на этот вопрос так, как это дается в материалах PMI.
Матричная структура нужна в ситуации, когда одни и те же ресурсы (сотрудники) на одном и том же промежутке времени должны выполянть одновременно и операционные и проектные задачи, находящиеся в зоне отвественности разных менеджеров, и при этом невозможно обеспечить фиксированное разделение этих задач по времени.
Тут у меня все плохо. Пока ни инструмента, ни решения. Еще и забываю.
Тут две задачи
У меня не решена ни та, ни другая.
Сейчас первую задачу решаю ведением четырех копий, но все время забываю (или ленюсь) синхронизироваться. Пробовал CD - весь архив потерялся. Сейчас два HD и два SSD.
Каталогизация самым тупым способом - распределение по папкам файловой структуры в соответствии с некоторой своей логикой. Но для поиска это не очень удобно
Идеал представлял следующим образом:
Физичисекое сохранение с датированием по факту появления и делением на папки по периодам.
Но при этом регистрация в каталоге с ключевыми словами (несколько на документ) и потом легкий поиск по этим словам.
Прошу прощения за вопрос, а какую зарплату получает сотрудник, который на одном и том же промежутке времени выполняет одновременно и операционные и проектные задачи?
Он получают один оклад или ему формируется надбавка или у него сдельная оплата?
Просто у меня возникает ассоциация, сотрудник за операционные задачи получает оклад, а проектные задачи оплачиваются как "халтура". Любой водопроводчик управляющей компании работает по такой схеме, ходит по заявкам за зарплату и одновременно с жильцами договаривается о "проектных работах", которые оплачиваются дополнительно (это есть халтура).
Нет. Ассоциация ошибочная. Вообще ничего общего.
Водопроводчик делает в один момент времени одну задачу, которую он получил по разнарядке от своего руководства.
Один руководитель и одна задача. Дальше он берет с заказчика "левые деньги" за дополнительное качество. Но при этом заказчик не выступает вторым менеджером и ничего не согласовывает с основным руководителем этого водопроводчика.
Либо другой вариант Он берет дополнительную задачу напрямую у заказчика. При этом снова никакого согласования и двойного управления. Просто обман менеджера.
Менеджер думает, что сотрудник все еще занят первым заказом, а он уже делает второй, который не числится в системе и просто кладет деньги в карман.
Либо третий вариант. Сотрудник выполняет халтуру в нерабочее время. СНова обычный обман компании - заказ мимо кассы. Но при этом рпять никакого двойного подчинения и согласования конфликта интересов на одном промежутке времени.
И давайте для начала определим, что такое операционные и проектные задачи.