Бюджетирование и управление проектами

[Padre Quart]

Мы не по этой части,...

Да я тоже все больше грехи отпускаю, но ...

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

Мухи - отдельно, кебаб - отдельно.
Речи пока об оптимизации не шло. Можно ограничиться для начала допустимым решением. О минимизации переналадок речи тоже не шло, они просто должны учитываться. Относительно времени исполнения проекта - критерий Cmax, об этом чуть позже.
Речь пока идет о том, может ли какая система класса PM управлять портфелем проектов при том, что каждый проект, каждая его стадия (фаза, операция) претендует во времени на те или иные общие ресурсы. Сахават был прав, когда сказал, что любой проект, если к нему внимательно присмотреться, - это технологический процесс. В результате мы имеем задачу планирования множества проектов во времени при ограничениях на ресурсы.
Что Вы можете сказать по этому поводу?

[Равиль]

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

Так что Ваш пример (с переналадками), уважаемый Padre Quart, к управлению проектами в смысле PM, по-моему, отношения не имеет. Увы.

Присоединяюсь к сказанному. Кстати, такие задачи, ПО МОИМ ДАННЫМ, умеет "решать" PRIMAVERA. Только не "решать", а с помощью этой программы можно составлять расписания (графики работ) и отслеживать их выполнение, а также делать многое другое. Насколько мне известно она не "заточена" для решения задач оптимизации.

По Спайдеру лучше и подробнее Либерзона В.И. никто ничего сказать не может, так как он автор и создатель данной программы. Эта одна из лучших российских разработок, которая отлично работает в сотнях компаний, как в России, так и за рубежом. И характеристики данной программы соответствуют мировому уровню. Для этого просто надо с ней познакомиться и ПОРАБОТАТЬ, а не читать рейтинги и оценки кого-то (ничего личного).

[air]

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

Было время, когда Сахават утверждал, что процессов, вообще, не существует,... тем более технологических.

А ситуацию я вижу так:
1. Приготовить курицу (по возможности быстрее) - это проект.
2. Приготовить на кухне ресторана одновременно и курицу и индейку и блюда из говядины (и даже свинины) при ограниченных производственных мощностях - это мультипроект.
3. Обеспечить непрерывное обслуживание посетителей ресторана (где каждый посетитель может заказать из меню индивидуальное блюдо) - это уже не мультипроект, как могло бы показаться на первый взгляд, а совсем другая задача, - задача, которую именуют в определенных кругах задачей организации мелкосерийного и единичного (уровня VIP обслуживания) производства.
По моему мнению, которое я уже сформулировал ранее, для решение последней из трех упомянутых задач софт класса PM, увы, неприменим, - здесь нужен MES.

[Сахават]

Было время, когда Сахават утверждал, что процессов, вообще, не существует,... тем более технологических.

Атомарный Процесс - агрегатная сущность = Сумме элементарных активаций ресурсов(входов, выходов, процессоров).
Деление на БП,ТП,и тдП - дело вкуса классификатора.

[Padre Quart]

Было время, когда Сахават утверждал, что процессов, вообще, не существует,... тем более технологических.

До тех пор, пока он не купил книгу Б.С. Балакшина "Основы технологии машиностроения".

А ситуацию я вижу так:
1. Приготовить курицу (по возможности быстрее) - это проект.
2. Приготовить на кухне ресторана одновременно и курицу и индейку и блюда из говядины (и даже свинины) при ограниченных производственных мощностях - это мультипроект.
3. Обеспечить непрерывное обслуживание посетителей ресторана (где каждый посетитель может заказать из меню индивидуальное блюдо) - это уже не мультипроект, как могло бы показаться на первый взгляд, а совсем другая задача, - задача, которую именуют в определенных кругах задачей организации мелкосерийного и единичного (уровня VIP обслуживания) производства.

Здесь Вы ошибаетесь, air. Задача #3 отличается от задачи #2 только повышенной размерностью (заметьте, не наличием размерности как следствием перебора вариантов, а просто повышенной размерностью).
В третьей задаче мы имеем те же индивидуальные проекты, как и во второй задаче.
Что касается того, что эти задачи относятся к "задачам организации мелкосерийного и единичного производства", то это лишь определение как следствие постановки задачи.

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

По моему мнению, которое я уже сформулировал ранее, для решение последней из трех упомянутых задач софт класса PM, увы, неприменим, - здесь нужен MES.

MES - всего лишь класс систем. Речь идет об управлении, о планировании - категории выше на порядок.

Большой вкусный пирожок с мясом достается Сахавату

[Genn]

Большой вкусный пирожок с мясом достается Сахавату.

Если он сделает add-on к MS Project Server.

[Padre Quart]

Если он сделает add-on к MS Project Server.

MS Project - абсолютно бесполезная программа, как и все остальные в классе PM. Поэтому для MSP лучше сделать хороший деинсталлятор.

Да и вообще, все эти вопросы, как и классы задач (там и задача столь любимого air общепита есть ... ) неплохо описаны в книге
Padre Quart, Machine-building production Management by means of systems MES, APS, ERP. Vatican: TNT-Press. - 2011. - 372 p.
http://tntpress.ru/262-upravlenie-ma...s-aps-erp.html

[Andruxa]

А ситуацию я вижу так:
1. ...
2. ...
3. ...

Примерно так. Только управление портфелем проектов - это в первую очередь принятие решений, что включать в портфель, а что нет.

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

Что касается MS Project - или даже Spider - это системы управления проектами, которые в том числе позволяют находить межпроектные несоответствия по использованию ресурсов.

В части управления портфелем проектов - по моим достаточно глубоким исследованиям - решений хороших нет. Нравился Atlantic Global, но с деньгами там плохо.

Для портфеля необходимы следующие показатели:
1. Суммарные затраты (как в людях, так и в деньгах), чтобы знать - проходим или не проходим,
2. Фин. рез. и NPV портфеля,
3. Рентабельность,
4. Риски.

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

Я вот не знаю правда что умеет Спайдер в части PPM - если там есть NPV, как говорит Владимир Либерзон, то это уже лучше чем MS Project. Ну и лучше Project Expert, в котором управление проектами практически не представлено.

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

[Genn]

Для портфеля необходимы следующие показатели:
1. Суммарные затраты (как в людях, так и в деньгах), чтобы знать - проходим или не проходим,
2. Фин. рез. и NPV портфеля,
3. Рентабельность,
4. Риски.

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

Не совсем.

1. Нужна не просто сумма, а график во времени.

2. Все зависит от направления бизнеса. Для каких-то направлений бизнеса (консалтинг, создание на заказ) - сумма денег за проект определена, и что-то такое можно придумать. Но есть проекты - для которых фин.результат не детерминирован. Смысл добавления "гадания на кофейной гуще" сомнителен.

3. А чем это отличается от второго.

4. Может быть.

Проблема состоит еще и в том, что изобретать велосипед могут только "уважаемые математики" в своих "башнях из слоновьей кости". На практике есть широко распространенные методологии - их и надо использовать. А в РМВОК проект заканчивается при создании объекта, и продажи там нет.

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

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

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

[Елена И. Яковлева]

Я вот все жду, когда же вы начнете писать по делу. Дождусь?

Легче Вам научиться вчитываться.
Вы не построите этот генератор значений функций многих переменных на основе цифровых конечных автоматов. Возможно, сможете воспользоваться аналоговыми. На данный момент из таких лучшим есть лишь человеческий мозг, в переводе на Ваш птичий язык это означает, что Вам придется воспользоваться услугами живых людей.
Современная цивилизация существует исключительно благодаря "простым" изобретениям Николы Теслы - переменный ток и т.д. Свои изобретения Тесла конструировал и проверял в мозгу (почитайте с помощьью Kindle).

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

Никола Тесла

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

[Genn]

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

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

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


Если вы хотите - заведите отдельную тему.

[Andruxa]

1. Нужна не просто сумма, а график во времени.

Ну да, потоки.

2. Все зависит от направления бизнеса. Для каких-то направлений бизнеса (консалтинг, создание на заказ) - сумма денег за проект определена, и что-то такое можно придумать. Но есть проекты - для которых фин.результат не детерминирован. Смысл добавления "гадания на кофейной гуще" сомнителен.

Можно использовать прогнозирование по сценариям и последующее усреднение оценки. Это отдельная целая проблема - прогнозирование продаж, особенно новых продуктов (например, есть модель Басса, но подобрать её коэффициенты сложно). Можно отталкиваться от емкости рынка, да и вообще весь возможный маркетинговый инструментарий. В общем, маркетологи знают как сделать прогноз, это их работа. Конечно, конъюнктура может поменяться - но это и надо закладывать в сценарии.

Можно использовать качественную оценку, как MS Project, но это не так интересно.

3. А чем это отличается от второго.

Да ничем, конечно (это просто 2./1.), просто показательно, как отдача в портфеле - и сколько на вложенный рубль прибыли. Это хороший показатель эффективности - и видеть, как он меняется "с проектом" и "без проекта" - весьма полезно, так же, как и сравнивать его с отраслевым.

Кстати есть книжка по максимизации ROI (Кендалл, Роллинз, можно найти в инете в открытом доступе), так она вся посвящена управлению рентабельностью бизнеса (правда) через проектный офис.

4. Может быть.

Прямой аналогии с портфелем ц.б. нет (при заданном уровне риска, доходность ограничена) - ввиду нетиражируемости и неделимости реальных проектов. Но показатели риска какую ценность имеют: допустим, проект мало добавляет в портфель, но риск из-за него для портфеля растёт. Это ценная информация для ЛПР.

Проблема состоит еще и в том, что изобретать велосипед могут только "уважаемые математики" в своих "башнях из слоновьей кости". На практике есть широко распространенные методологии - их и надо использовать. А в РМВОК проект заканчивается при создании объекта, и продажи там нет.

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

Я всё же пользуюсь The Standard For Portfolio Management 2006 (первый). Там есть ценный мысли по списку ключевых показателей (key descriptors) проекта. В частности

Component number
● Component description
● Class of component
 Project
 Program
 Business case
 Subportfolio
 Other work.
● High-level plan
● Strategic objectives supported
● Quantitative benefits
 New revenues
 Cost reduction
 Return on investment
 Internal rate of return
 Net present value
 Reduced cycle time
 Quality improvement.
● Qualitative benefits
 Strategic alignment
 Risk reduction
 Legislative requirements
 Platform development
 Business opportunity.
● Component customer
● Component sponsor
● Key stakeholders
● Resources required
● Timescale
● Project dependencies
● Key deliverables
● Budget estimates
● Business unit
● Market risk level estimates
● Market definition and impact.

Жирное выделение моё.
PMBoK ограничивается продуктом, но анализ (инвест.) проекта (или портфеля) не ограничивается на мой взгляд PMBoK.
Еще согласно стандарту, используется

Cost Benefit Analysis
Any financial analytical method preferred by the organization. These methods
may include: Net Present Value (NPV), Discounted Cash Flow (DCF), Internal
Rate of Return (IRR), cost benefit ratio, payback, and options analysis.

при балансировке портфеля.

Но я это к чему. Даже не очень хороший прогноз лучше его отсутствия. А получить прогноз - творческая задача.

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

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

Если так ставить вопрос, то упирается, но не стоит вопрос "детального пошагового анализа загрузки". То есть задача спланировать ресурсы в портфельном анализе на 3 года вперед не содержит в себе подзадачу "спланировать загрузку всех ресурсов на 3 года". На таких масштабах проще расширить штат или докупить оборудования. Кстати в Кендалле-Роллинзе есть и про этот вопрос - там речь идёт о том, что портфель проектов планируется совместно с портфелем целей, портфелем активов, и портфелем ресурсов. Это я к тому, что MES-системы решают локальные задачи нагрузки (на 3-5 лет я думаю они фиг там что обсчитают, и даже если обсчитают, то аналитическим выхлопом будет пшик, особенно по сравнению с затратами на подготовку данных), а Portfolio Management - высвечивает потребности.

[Елена И. Яковлева]

...

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

[Владимир Либерзон]

В части управления портфелем проектов - по моим достаточно глубоким исследованиям - решений хороших нет.

Я вот не знаю правда что умеет Спайдер в части PPM...

Добавьте http://spiderproject.com/images/img/pdf/Portfolio%20Planning%20Challenges.pdf к своим достаточно глубоким исследованиям.

[Andruxa]

Добавьте http://spiderproject.com/images/img/pdf/Portfolio%20Planning%20Challenges.pdf к своим достаточно глубоким исследованиям.

Хм. А почему этого нет на русском сайте, по-крайней мере навигацией не найти? Меня больше интересует как раз Selection. То, что написано на сайте - ну просто совсем малое представление дало мне в своё время, поэтому я вообще Спайдер в своё время из списка исключил.

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

Пока скажу что для нормального PPM вроде в Спайдере всё есть. По сравнению с около 20-ю другими отсмотренными решениями (они кстати все по больше части вебовские, за что им минус).

[Genn]

В общем, маркетологи знают как сделать прогноз, это их работа. ...
Я всё же пользуюсь Standards for Portfolio Management (первый). Там есть ценный мысли по списку ключевых показателей (key descriptors) проекта. ....
Если бы я не сталкивался с тем, что люди прогнозируют (продажи), я бы наверное согласился, что блоху подковать нельзя.

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

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

есть книжка по максимизации ROI (Кендалл, Роллинз, ...

Будет любопытно почитать/полистать. Полное название - на русском и английском не приведете? Спасибо.

Если так ставить вопрос, то упирается, но не стоит вопрос "детального пошагового анализа загрузки".

Я не зря привел пример скользящего бюджетирования. Там этот вопрос решен с помощью бюджетов (планов) разного уровня.

[Владимир Либерзон]

. В демо-версии, понятно дело, ничего такого нет.

И в Демо Spider Project Professional есть, только проекты должны быть ну очень маленькими, потому что ограничение в 40 операций относится и к расчету портфеля.

[Елена И. Яковлева]

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

теплее. теперь избавиться от любви к продуктам мелкософт.

[Andruxa]

И в Демо Spider Project Professional есть, только проекты должны быть ну очень маленькими, потому что ограничение в 40 операций относится и к расчету портфеля.

У меня когда было демо, оно было какое-то простое. Хотя брал я его давно, пару лет назад.

Будет любопытно почитать/полистать. Полное название - на русском и английском не приведете? Спасибо.

Название на англ. не помню, но том же сайте есть на русском.

[Елена И. Яковлева]

Так вы с 16 типами автоматов то разобрались?

В Вашей теме исследуются конструкции вашего типа.

[Владимир Либерзон]

У меня когда было демо, оно было какое-то простое.

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

[Елена И. Яковлева]

Вы ошиблись.

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

[Genn]

измените постановку задачи и систему взглядов.
ничего личного.

Вы про 16 типов автоматов почитайте. Потом подумаете, как это применить на практике. Может быть поймете ограниченность своих попыток придумать дверь в стене посреди чистого поля и потом вломиться в нее.

[Елена И. Яковлева]

Вы про 16 типов автоматов почитайте. Потом подумаете, как это применить на практике. Может быть поймете ограниченность своих попыток придумать дверь в стене посреди чистого поля и потом вломиться в нее.

Это очевидно. Рецепт проще. Наймите толковых сотрудников, они будут использовать свои инструменты, в т.ч. и программные - и получите результат. Spider - так спайдер. Инструмент, что делает Сахават - а почему нет?и т.д. Ферштейн?

[Игорь Захарченко]

Рецепт проще.

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

"Обходят его, короче", - констатировал Путин.

http://www.segodnya.ua/news/14332734.html

[Сахават]

Добавьте http://spiderproject.com/images/img/pdf/Portfolio%20Planning%20Challenges.pdf к своим достаточно глубоким исследованиям.

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

[Владимир Либерзон]

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

Да нет, в презентации показано, что расчет проектов по отдельности для определения того, какие включить в портфель, а какие отложить, неправомерен.

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

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

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

Все это показано на простых примерах.

Это очевидно, но большинство методик и программ (MS Project в частности) рассматривают портфель как сумму проектов, расчет расписания портфеля в целом с учетом всех имеющихся ограничений даже не предусматривается. И, как ни странно, большинство этой проблемы не понимает. Наверное полагаются на Гартнера, специалисты которого так глубоко не копают.

[Сахават]

То есть задача спланировать ресурсы в портфельном анализе на 3 года вперед не содержит в себе подзадачу "спланировать загрузку всех ресурсов на 3 года". На таких масштабах проще расширить штат или докупить оборудования.

Без этого никуда не деться.

Кстати в Кендалле-Роллинзе есть и про этот вопрос - там речь идёт о том, что портфель проектов планируется совместно с портфелем целей, портфелем активов, и портфелем ресурсов.

Все правильно, токо это слишкоб общий случай, почти блабла.
Есть разные задачи.
1. Моделирование для достижения целей с открытыми (относительно) ограничениями.
При этом определенные ресурсы можно привлечь (кредиты, закупка ОС, построение завода и т.д.)
2. Моделирование с частично закрытыми ограничениями.
При этом некоторые ограничения жесткие (например - кредит на закупки материалов разрешен, а для закупки ОС и т.д. нет, низзя набрать рабсилу и т.д.)
3. Моделирование с закрытыми ограничениями.
думаю ясно (внутри предприятия обычно)

Это я к тому, что MES-системы решают локальные задачи нагрузки (на 3-5 лет я думаю они фиг там что обсчитают, и даже если обсчитают, то аналитическим выхлопом будет пшик, особенно по сравнению с затратами на подготовку данных), а Portfolio Management - высвечивает потребности.

Тут можно и послать.
ПМ - вырожденный сМЕС (под МЕС каждый свою фигню понимает)

[Сахават]

Да нет, в презентации показано, что расчет проектов по отдельности для определения того, какие включить в портфель, а какие отложить, неправомерен.

ну, тогда все гут.
эх, надо учит язык чертов этот

[Сахават]

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

Какого типа "межпроектные зависимости" имеются ввиду? Откуда они берутся?

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

Ну приоритеты тоже не есть гут, это почти то же самое, что ругали.
Какие способы приортетизации?