Скопировать ссылку
Многократно повторенные, даже хорошие, слова начинают вызывать негативную реакцию всего организма при их многократном воспроизведении без видимого и осязаемого результата.
Ситуация с созданием повсеместного проектного управления это утопия, которая спустя некоторое время сделает термин «Проектное управление» еще одним словом, вызывающим негативную реакцию.
2015 и начавшийся 2016 год сопровождается таким количеством материалов и публикаций про проектное управление, что понимая, что сами слова ничего не значат и даже сама методология проектного управления ничего не значит, можно только предпринять усилия, чтобы объяснить суть этой простой ошибки, чтобы её было возможно понять без предварительной на то подготовки. Это возможно, достаточно уловить тонкую грань между, на первый взгляд, одним и тем же.
Теперь объясню суть этой утопии:
На поверхности лежит технологическая неспособность проектного управления решать задачи операционной деятельности, из которой состоит вся наша жизнь, будь то Человек или управление в организации, холдинге, корпорации, государстве.
Люди, которые испытали проектное управление сами на себе и даже те, кто его тиражируют и даже те, кто его разрабатывают, знают об этом более чем хорошо, но, тем не менее, колесо крутится, консалтинг и промоушн работает, потому что это создает видимость работы, которая не будет иметь результата, но на какое-то время даст оборот средств, позволяющий этот короткий промежуток времени просто просуществовать.
Почему это происходит?
Потому что часто бывает, что Человек в рутине своей работы настолько крепко придавливает табуретку на которой сидит как можно крепче к полу и не хочет привстать, чтобы увидеть горизонт своего местонахождения в более длительном периоде, чем тот горизонт, который виден, сидя на табуретке.
Являясь и потребителем и разработчиком программного обеспечения и зная, что является потоками данных и как они формируются в качестве планируемых и исполняемых действий и отражаются на системе хранения (СУБД) я утверждаю:
Проектное управление, само по себе, как инструмент управления, ничего из себя не представляет. Это муда, выражаясь терминами «кайзен» (непрерывные улучшения).
Проектное управление — это инструмент формирование плана, он же стратегия чего-либо, он же проект чего-либо, но не более того. План, стратегию, проект можно формировать хоть в табличной форме, хоть в текстовой, от этого конечный результат не изменится.
Проектное управление не способно технологически реагировать на изменения внутренней и внешней среды, которая является, по своей сути, средой, в которой нет стабильного состояния.
Что такое Проектное управление?
Объясню на простом примере:
Вот проектное управление (ниже анимация), где маленькой стрелкой является «цель», постоянно перемещаемая в пространстве, которую Проектное управление в режиме реального времени не в состоянии поймать и управлять ею.
Те, кто занимается проектным управлением как таковым, гоняется за черной кошкой в темной комнате.
Именно поэтому, те, кто занимается «процессами», так характерно одинаково скептически смотрят на тех, кто занимается «проектами».
Однако отмечу, что и для процессов и программного обеспечения (технологии) результат этой болезни одинаков, отличаются только симптомы.
Чтобы понять источники возникновения болезни тем, кто вводит проектное управление, как средство оптимизации качества управления, необходимо досмотреть анимацию до конца (смотреть несколько минут), до того момента, когда голова поглотит хвост.
Что может быть альтернативой?
Необходима быстрая реакция на изменения внутренней и внешней среды, а сама технология проектного управления не способна решать задачи операционной деятельности.
Для решения этой задачи чаще всего инициаторы введения проектного управления после его внедрения в организации, холдинге, корпорации, государстве в ответ на возникающий вопрос «А как этим управлять?» дают один и тот же ответ — так это же другая предметная область знаний, у нас этой части нет, но если Вам очень нужно, можно, всего навсего, интегрировать информационную систему, используемую для проектного управления с системой, в которой формируются данные о первичной и налоговой документации, иначе говоря, интегрировать систему проектного управления с системой учета.
Но и это является ошибкой, поскольку с одной стороны проектное управление — это формирование «будущего», а система учета — это «отражение прошлого».
Последнее время возникают публичные утверждения, что методология «Agile» которую теперь нужно всем срочно брать на вооружение, устраняет эту проблему проектного управления.
Но что такое методология «Agile»?
Это методология. С помощью методологии не удается решать технологически задачи управления ресурсами. Проблема интеграции ПО, используемого для проектного управления, с ПО, используемого для учета операций постфактум, сохраняет одну и ту же болезнь в том же состоянии.
Представьте, что мы с Вами интегрировали проектное управление с системой учета и утверждаем, что, используя методологию «Agile», теперь результат будет иным.
Чтобы понять к чему это приведет, Вам придется потратить еще несколько минут чтобы увидеть к чему приведет второй вариант в прилагаемой анимации:
Если не хочется ждать завершения второго эксперимента, скажу, результат в первом и втором случае будет одинаков.
Почему?
Потому что системы учета не являются системами, в которых осуществляется операционная деятельность, а автоматизация интеграции разнородных информационных систем есть процесс, в то же время отдельный проект, требующий новых ресурсов и инвестиций, отнимающий время, исчисляемое годами, и чаще всего (успех зависит от объемов обрабатываемой информации), результат не оправдывает ожиданий, поскольку интеграция не предусматривает предварительного описания всех возможных итераций возможных событий, описываемых ниже в видеоролике «Антикейс».
Причина более подробно описана и показана здесь:
Так что же является альтернативой?
В первую очередь понимание, что операционная деятельность — это не системы учета отражения операторами ввода информации действий постфактум (результаты такого ввода представлены в «Антикейсе»), операционная деятельность — это технологии, способные отражать саму деятельность в момент её возникновения и обратной реакции на изменение внутренней и внешней среды.
Как только это понимание возникает, возникает второй вопрос: Что является технологиями, способными объединять стратегическое планирование с операционной деятельностью?
Как только этот вопрос возникает, у меня есть к Вам предложение, не тратить больше время на скрещивание нескрещиваемого и узнать об этих технологиях несколько больше, чтобы у Вас была возможность понять, что в обоих примерах голова достигает хвоста и упирается в него исключительно потому, что отражение плана и факта происходит в будущем и прошлом, но никак не в настоящем, что и является проблемой и первопричиной существования до настоящего времени функционального подхода к Управлению (Менеджмент). Менеджмент требует объективного отражения состояния чего-либо для эффективного принятия управленческого решения, а эта информация в интегрированных системах планирования будущего и системах учета прошлого отсутствует.
Управление в режиме реального времени требует синхронизации потоков данных, а это уже принципиально иная технология, отличающаяся от способов интеграции, описанных в «Антикейсе» выше.
И тогда возникает понимание представленного ниже объяснения причин и следствий:
и решения:
верно, мы имеемм в совокупности свойств методологии и технологии задать плавающую точку Б как цель, и идти из точки А к ней, не имея предварительно заданного алгоритма, хотя и многовариантность инструментов и создаваемый набор CaseStore позволяет либо использовать цепочки действий чтобы строить всю цепь из А к Б, либо исплльзовать короткие цепи, назовем их "несколько ступенек" для создания лестницы.
Ваша аллегория с элеронами, рулем высоты и направления очень похожа на выступление Виктора Франкла (по моему 1972 год).
я безусловно учитывал сказанное им, когда создавал исходную модель с набором совокупности свойств, позволяющих решать такие задачи.
мы именно это и намерены вывести на рынок, как средства, доступные кадому участнику рынка.
общее описание этой модели есть в подборке моих публикаций на этом ресурсе, там Вы можете найти много того, что последнее время представляют под другими брендами просто как идеологию.
одна из них: http://delovoymir.biz/2012/03/12/edinaya-tochka-vhoda-kak-ocenit-informacionnuyu-model-obschestvom-i-uchest-mnenie-kazhdogo-potencialnogo-uchastnika-sistemy.html
Благодарю за приглашение в данный диалог.
Я ознакомился "по диагонали" с проектом. Направление мне близко. Вот только (точно без осуждений и не инициируя споров), проект-решение, как я понимаю, всё ещё на том ещё, условно "уровне" сознания, что и происходящие возможности, которые называют многие ещё, "проблемами", которые важно в себе менять. Единому (как я это понимаю) ведь не важно - контроль, выгода, эффективность.
Автор и коллектив, который он представляет, в любом случае Молодцы!
Предлагаю ответить, себе же, честно на вопрос - какой мотив создания и продвижения проекта?
Если в поиске личной выгоды, также Слава Единому.
Если же, для того, чтоб воспроизвести нечто, минимум в разы ещё эффективней предлагаемому, после запроса, готов без корысти, от Сердца - предложить информацию-возможность, которая может "развернуть на 360 градусов" ваше мировоззрение, а соответственно и качество Жизни (также и проект). Выбор!
В любом случае, Всех Истинных Благ!
спасибо, отвечу на оба вопроса про мотивацию и продвижение проекта:
1. формальный, представлен как техническое решение, позволяющее то то и то то, решая задачу взаимодействия участников одного рынка https://alteragent.wordpress.com/2015/10/12/about/
2. Для улучшения качества жизни, при этом эта часть имеет очень много способов и вариантов реализации, я уже предположил что Вы имели в виду, буду рад общению https://aliveflow.wordpress.com/2015/10/20/everyone-2/
общее понимание возможностей и следствий создания такой модели взаимодействия участников рынка представлен ов 8-ми минутном ролике, в котором на абстрактном уровне (без необходимости знания каких либо предметных областей) дается понимание всех возможностей и следствий
в начале ролик, а ниже каждый слайд отдельно https://alteragent.wordpress.com/2015/12/09/alive/
И приведенные Автором примеры, на мой взгляд, авторитетны и доказательны для него самого
Если цель статьи - побудить интерес к Автору, видимо это имеет некий смысл. Если же "открыть глаза невежам", то для меня сама потуга Автора - утопия...
Вы были бы правы, если предполагать что технологии проектного управления и технологии для операционной деятельности отличаются в способе их реализации на уровне архитектуры ИТ решения.
поскольку я опираюсь на российскую технологию поздания АСУ с набором уникальных для рынка ИТ решений свойств, я предлагаю Вам в 8-ми минутах познакомиться с принципами и технологии и самих возможностей исполняемой модели взаимодействия.
После просмотра и понимания способа слияния "проектного" и "операционного", еще раз иначе взглянуть на ролики 1. ПРИЧИНЫ и СЛЕДСТВИЯ и 2. Возможности слияния....
Мы с Андреем Вахиным занимаемся широким спектром проектов. И предлагаемые модели к ним надо, увы, сильно адаптировать.
Предлагаю кейс: приземлить на заводе в Москве изготовление некоего узла (ладно, хоть детали) для самолёта, которую всегда покупали в ФРГ.
Это - проект?
Если да, как к нему прилагается предложенная автором модель?
Или давайте по-честному: мы говорим не о проектном менеджменте в целом, а только об одной, узкой и специфичной, области: ИТ.
и проект и процесс это всего лишь цепочка действий, которая может быть либо формализованной, либо творческой.
Вы привели пример, кейс сборки узла. в машиностроении сборку узла принято обеспечивать средствами PLM (Product Lifecycle management), в строительстве сборку узла (сложный проект строительства чего либо) до недавнего времени было принято реализовывать средствами архитектурного проектирования и задем календарно сетевого планирования, в настоящем времени в РФ в строительной отрасли, это становится уже требованием, принято реализовать с помошью BIM (building information modeling).
и в случае PLM и в случае BIM это проекты сборки сложного изделия.
на этапе форимрования алгоритма сборки эти сложные изделия (в вашем примере узел) традиционно этот алгоритм является моделью сборки компонент с использованием библиотек с исходными данными и родевыми участниками. Точка.
Дальше тупик.
поскольку нет исполняемой части.
я пишу о том, что технология о которой идет речь, позволяет строить сразу исполняемую модель сборки сложного изделия, независимо от отрасли и по мере реализации создания сложного изделия узла, быстро реагировать на изменения внутренней и внешней среды, используя совокупность свойств технологии построенных в однороной среде, не требующей интеграции разнородного ПО.
Уверен, Вы поймете о чем я сейчас написал.
с Уважением,
P.S. Жвль что уведомления о постаж не приходят рассылкой, было бы удобнее отвечать сразу по мере поступления комментариев.
Пример из вашего текста:
Вы привели пример, кейс сборки узла. в машиностроении сборку узла принято обеспечивать средствами PLM (Product Lifecycle management), в строительстве сборку узла (сложный проект строительства чего либо) до недавнего времени было принято реализовывать средствами архитектурного проектирования и задем календарно сетевого планирования, в настоящем времени в РФ в строительной отрасли, это становится уже требованием, принято реализовать с помошью BIM (building information modeling).
и в случае PLM и в случае BIM это проекты сборки сложного изделия.
на этапе форимрования алгоритма сборки эти сложные изделия (в вашем примере узел) традиционно этот алгоритм является моделью сборки компонент с использованием библиотек с исходными данными и родевыми участниками. Точка.
Дальше тупик.
Я, к сожалению, ничего не понял. Простите за сравнение, этот текст напоминает Известные Речи Мэра Киева В.Кличко.
несмотря на допускаемые Вами сравнения, позвольте Вам дать нужное направление изучения матчасти:
Есть технологии моделирования чего-либо, не предполагающие наличие исполняемой части у этой модели.
Есть симуляторы моделей, позволяющие увидеть как эта модель будет действовать в идеале, согласно заданных при моделировании параметрах, что тоже не предполагает исполняемой части у этой модели.
Есть альтернативный способ построения ИС, при котором создается сразу исполняемая модель.
Об этом подробнее в публикации, ролик с названием Антикейс.
Если хватит желания и терпения его посмотреть, посмотрите пожалуйста прежде чем писать в следующий раз подобные эпитеты.
Проектное управление не позволяет решать задачи управления, о чем и написано в публикации. Есть способ решения этой задачи.
с Уважением к Вам,
Важно: проектное и операционное управление - это набор управленческих инструментов для 2-х принципиально разных ситуаций. Для отлаженного "конвейерного" (в широком смысле, так работает и бухучёт), нужны одни инструменты. Для неопределённого, где сами предприниматели ещё не понимают толком, чего хотят и как это сделать, - другие (именно проектные).
Как всегда жму руку! Напоминаю: за тобой уже 1, 5 года должок: кофе :)
может возникать представление о подмене понятий только по одной причине, восприятие информации происходит, исходя из имеющегося у читателя представления о применении той или иной методологии. Вы пишете о разлияии проектного и операционного управления.
Поставьте себя в условия, когда Вам дается однородная среда, в которой объединены возможности и проектного и операционного управления? Как Вы будете реагировать на эти возможности?
я прошу обратить внимание на однородность среды, в которой происходит управление ресурсами.
ниже об этом как раз написал ответ на пост Кириллу Зубареву, дублирую:
Если Вы имеете возможность модифицировать "на лету" контур управления, ролевых участников и использование необходимых наборов библиотек, Вы (я, он, она, они), кто угодно, имея инструменты управления в однородной среде, может в режиме реального времени создавать и управлять нужными наборами деятельности.
суть такого управления не меняется, будь то управление одним или несколькими предприятиями или холдингом, либо это будут более крупные организационно технические системы.
мы не исключаем примерение проектов и процессов для решения частных, простых задач в системе управления, но для того чтобы сохранить адаптивность изменениям, мы создали технологию, в которой инструменты управления взаимосвязаны однородной информационной средой взаимодействия.
в основе одна технология, что позволяет как частично, так и полностью отказаться от интеграции.
Вы пишете: "Это примерно, как в ИТ управлять существующей сетью или внедрять новую ОС." = я поясняю = Вы предполагаете разделение управления чем-либо существующим и формирование котура чего-либо в будущем, предполагая эту корректировку как проект автоматизации. Мы говорим, что эта корректировка, являющаяся необходимой "здесь и сейчас" реакцией на изменение внутренней и внешней среды, и это возможн без дополнительных проектов автоматизации в работающей системе управления в тот момент, когда необходимость это корректировки возникла.
Ещё цитата из вашего текста:
"Здравствуйте Александ Крымов!
может возникать представление о подмене понятий только по одной причине, восприятие информации происходит, исходя из имеющегося у читателя представления о применении той или иной методологии. Вы пишете о разлияии проектного и операционного управления."
Простите, но - прощайте!
Всегда с Уважением к каждому задавшему вопрос,
В статье представлено мнение, которое ошибочно по след. причинам. Имеют место непонимание сути управл. проектами и предмета корпоративного менеджмента. Явно выражен сугубо технический взгляд на управление, хотя любое предприятие - это социо-техническая система. Этот термин используется в отношении запуска технологий или изменений в менеджменте и т.п.
Не стоит судить исходя из сомнительных частных позиций, лучше заглянуть в толковый словарь и разобраться с термином.
социотехническая часть учитывается.
я пишу о технологии с помощью которой формируется организационно техническая ДЕцентрализованная система управления, не имеющая единого центра управления.
т.о. это одновременно и социотехническая система.
Эта совоупность свойств позволяет создавать исполняемые модели управления простыми и сложными, территориально распределенными вертикально интегрированными объединениями (холдингами, корпорациями, государством.
Выше была в комментариях уже ссылка на общую модель и описание совокупности свойств, после просмотра предположу что Ваше мнение может измениться.
https://alteragent.wordpress.com/2015/12/09/alive/
И, прошу прощения, презентации, сдобренные музыкой, а не комментариями голосом, со слайдами, забитыми текстом - признак того, что результат будет весьма далек от ожидания...
на основании чего Вы предполагаете что проектное и операционное управление в производстве несовместимы? Совместимы, объясняю почему:
Если Вы имеете возможность модифицировать "на лету" контур управления, ролевых участников и использование необходимых наборов библиотек, Вы (я, он, она, они), кто угодно, имея инструменты управления в однородной среде, может в режиме реального времени создавать и управлять нужными наборами деятельности.
суть такого управления не меняется, будь то управление одним или несколькими предприятиями или холдингом, либо это будут более крупные организационно технические системы.
мы не исключаем примерение проектов и процессов для решения частных, простых задач в системе управления, но для того чтобы сохранить адаптивность изменениям, мы создали технологию, в которой инструменты управления взаимосвязаны однородной информационной средой взаимодействия.
в основе одна технология, что позволяет как частично, так и полностью отказаться от интеграции.
Вы пишете: "Это примерно, как в ИТ управлять существующей сетью или внедрять новую ОС." = я поясняю = Вы предполагаете разделение управления чем либо существующим и формирование котура чего-либо в будущем, предполагая эту корректировку как проект автоматизации. Мы говорим, что эта корректировка, являющаяся реакцией на изменение внутренней и внешней среды, возможна без дополнительных проектов автоматизации в работающей системе управления в тот момент, когда необходимость это корректировки возникла, т.е. здесь и сейчас.
По статье. Я бы ее назвал как "Пчелы против меда":)
"На поверхности лежит технологическая неспособность проектного управления решать задачи операционной деятельности, из которой состоит вся наша жизнь, будь то Человек или управление в организации, холдинге, корпорации, государстве."
Источник: https://delovoymir.biz/proektnoe-upravlenie-eto-utopiya.html
© Деловой мир
При чем тут проектное управление и операционная деятельность?:) Задачи операционной деятельности - одни, а проектного управления - другие. Операционная деятельность - это аналог "производственного конвейера", а проектное управление - как в ограниченные проектные ограничения (сроки, деньги, например) получить уникальный результат (продукт). Причем, проектное управление может хорошо решать задачи изменения операционной деятельности, через реализацию проектов, направленных на изменения (как правило улучшение) тех или иных аспектов функционирования деятельности.
Да и сама основная суть проектного управления управления состоит не в планировании и контроле графика проекта или реализации интераций-спринтов по Agile или с использованием другой технологии (если про говорим про ИТ)(не затрагиваю другие предметные области проектного управления).
По моему мнению и опыту, основное в проектном управлении - это организация структуры управления проектом таким образом, чтобы между участниками проекта и внешней средой были организованы информационные каналы и механизмы по управлению изменениями в проекте таким образом, чтобы глобальная цель проекта была реализована. И это относится ко всем видам деятельности, не только к ИТ, можете сюда добавить и проекты строительства, коммерческие проекты и т.д.)
И все проектное управление говорит о лучших практиках и как такое управление проектное организовать (отдельный вопрос и предмет обсуждения - как встроить проектное управление в операционную деятельность компании (или наоборот:)), если основная деятельность компании - это управление проектами или проектная деятельность занимает значительную часть ее деятельности).
Поэтому, я бы не стал говорить, о том, что проектное управление не работает, если кто-то по различным причинам в своем опыте по субъектным и объектным (такое тоже бывает) причинам не смог добиться реализации правильной конфигурации управления проектом(ами), а использование отдельных инструментов, покрывающих лишь некоторые аспекты реализации проекта показало только ограниченную эффективность. Значит, что-то не так организовали, что-то отсутствовало.
Напишу следующий тезис: отсутствие необходимых компонент, выделенных с точки зрения лучших практик управления проекте, с очень большой вероятностью приведет к провалу или не будет достигнут потенциально возможный результат проекта (проект, если и будет выполнен, то, скорее всего, с большими затратами средств и времени и т.д.). Наоборот, наличие необходимых компонент управления проектом значительно повышает вероятность успешной реализации проекта (в случае наличия технологической возможности его реализации и достаточного объема ресурсов и времени).
Напоследок процитирую: "Именно поэтому, те, кто занимается «процессами», так характерно одинаково скептически смотрят на тех, кто занимается «проектами».
Источник: https://delovoymir.biz/proektnoe-upravlenie-eto-utopiya.html
© Деловой мир"
Я бы не стал так говорить. Кто занимался ИТ знает, что есть такие термины как "процессный объем", или роль "процессный бизнес-аналитик". Если мы говорим про другие отрасли, то я согласен с коллегами, то при реализации задач а-ля "в крупном машиностроении достигнуть локализации к 202..году 100% при текущем уровне менее 10%" вопросы интеграции систем управления проектами и систем, поддерживающих операционную деятельность - не стоят. Ничего нет. Что-то и кем-то нужно сделать то, что никто и никогда у нас в стране не делал. Подключаются специалисты из другой области знаний и первым шагом будет проект по...