Искусство оптимизации ресурсов от 1988 года до наших дней
По отзывам я снял очень интересное учебное видео в котором многие впервые увидели первые версии Microsoft Project и с интересом узнали, что MS Project for MS DOS в 1988 году имел более "совершенный" алгоритм выравнивания ресурсов похожий на Spider Project. Почему Microsoft от него откажется и перейдет на другой алгоритм объяснено в фильме.
Думаю также многим интересна Success Story об Microsoft Project как двумя версиями продукта Microsoft убил 80% конкурентов на рынке и создал бизнес приносящий ему 1 миллиард долларов год.
После публикации видео разразилась дискуссия экспертов об практиках выравнивания ресурсов, обзор которой и результат опроса Oracle среди своих пользователей я решил дать в статье после этого видео.
Вообще найти пользователя использующего в реальных проектах выравнивание ресурсов в Spider Project не такое простое занятие. Не секрет, что у меня работали часть бывших сотрудников Spider Ukraine, так вот - ни одного клиента использующего выравнивание у них в Украине не было. Правда сейчас я понимаю, что это отчасти связано с компетенцией коллег в Spider Ukraine, т.к. в России такие пользователи есть, хотя и их тоже немного.
Мостотрест наверное главный "ресурсный кейс" Spider Project вообще в России и Владимир Шаринский поделился своим мнением об практическом опыте. К сожалению он согласен это делать только в нашей группе https://www.facebook.com/groups/msproject поэтому оригинальная орфография и стиль письма Сергея сохранен, хотя стиль несколько не академический.
Сергей рассказал об своем опыте в нескольких постах в группе, наверное этот пост самый содержательный.
https://www.facebook.com/groups/msproject/permalink/854301507938711/
Общая оценка Сергея, что Spider Project работает, но у него есть некоторые замечания к качеству отчетности из продукта. Обратите внимание на комментарий, что Сергей считает, что "все программы одинаковы" в том числе в качестве Resoure Leveling. Это не слова на ветер, действительно по его методу работы через приоритеты и Spider Project и Turbo Planner дадут абсолютно одинаковый результат ресурсной оптимизации.
Обратите внимание, что на мой прямой вопрос к Сергею в свободной форме готовы ли он доверять Spider Project самостоятельно решать какие задачи надо делать вперед, он отверг это и заявил об тотальном использовании ручных приоритетов, т.к. "машина-дура" и не способна мыслить как человек.
Если приоритеты заданы в системе управления проектами принудительно, то нет места никакой "свободе эвристик" выравнивания ресурсов. Все проектные системы выдадут одинаковое расписание и могут различаться только скоростью расчета, с небольшими особенностями в точности стыковки задач и стабильности расписаний при изменениях. С Сергеем Шаринским согласен опытный пользователь Spider Project Леонид Демидов. Он также подтверждает, что без приоритетов практическое использование выравнивания в Spider Project не имеет смысла, т.к. влечет нарушение технологии.
Почему Сергей и Леонид не доверяет автоматике Spider Project решать какие задачи в какой последовательности делать и апеллируют к нарушению технологии выполнения проектами при выравнивании ресурсов без приоритетов? Для ответа на этом можете прочитать эту статью как практик-строитель из Уфы просто разбил в пух и прах Владимира Либерзона в личной дискуссии доказав, что его Resource Leveling может выдавать фантомные расписания, над которыми можно только посмеяться типа телепортации рабочих над стяжкой. Сергей как практик, а не теоретик как Петр, прекрасно это понимая отказался от эвристик и контролирует на 100% расписание ручными приоритетами.
К слову. Мне как раз приходилось заниматься практической оптимизацией загрузки машин в полиграфическом производстве. Сценарий там также отрицает любую свободу эвристик. Поясню Петру как ему нужно внедрять в полиграфии оптимизацию загрузки оборудования, раз у него на Spider дальше красивых демопримеров дело не идет:
Как видим ни о какой "свободе эвристик" в выравнивании в полиграфии даже речи быть не может, там приоритеты используются еще более тотально, чем в стройке.
Если же вернуться к беседе с практиком Сергеем Шаринским, то он мне подтвердил, что использует технику оптимизации не на весь проект разом (обратите внимание на практическую бесполезность выравнивания портфеля проектов целиком, которые показывает Владимир Либерзон на пресейлах). Но что меня удивило, так слишком большое "скользящее окно оптимизации". Поясню. Действительно достижимая задача примерно на 20% повысить выработку машин путем ликвидации вынужденных простоев из-за ошибок планирования. Однако максимальная эффективность, как я покажу дальше с исследованием Oracle в руках в том числе, это окно оптимизации примерно неделя. Абсолютная реальная задача выйти на почасовое планирование ресурсов на горизонт недели причем настолько точное, что план будет настолько точно попадать в факт, что в ряде наших проектов с Microsoft Consulting Services типа Renessance Capital даже отказываются собирать факт за ненадобностью (он такой же как план один-в-один, такое качество расписаний). Сергей же заявил месячное окно, где такую качественную оптимизацию не сделать - на горизонте месяца вероятность непредвиденных рисков больше на порядок чем на горизонте недели. Как я потом понял, это связано с проблемами Spider Project в подневном планировании, которого там просто нет. Но об этом дальше.
Оптимизируют ресурсы почти все с разной степенью детализации, но Resource Leveling используют только 5%. Эксперты из Oracle подготовили интересную презентацию по уровням зрелости в управлении ресурсами Resource Mature Management Model
На слайде ниже показан опрос, какие практики управления ресурсами используются не по заявлением из башни из слоновой кости математиков-абстракционистов, а реально и практически.
Переведу результаты опроса Oracle. В процентах указано число пользователей считающий метод оптимизации ресурсов ниже главной своей практикой.
Этот опрос очень многое нам позволяет понять в стратегии Microsoft в решениях для оптимизации ресурсов. На заре создания проектных систем когда уже был Microsoft Project for MS DOS, а Spider Project for MSDOS еще был в процессе написания, доля использования пользователями Resource Leveling была... более 60% и сейчас упала более чем в 10 раз до 5%. Дело в том, что Microsoft одержал победу над системами класса Spider Project еще до того как они родились. Пока был MS DOS у планировщиков не было никаких средств визуализации ресурсных конфликтов и быстрых визуальных средств их разрешения, в такой ситуации выравниванием пользовались очень многие, т.к. других вариантов и не было. С появлением графических визуальных средств планирования как Microsoft Project 1.0 for Windows 3.11 разразился просто гром среди ясного неба. Огромное количество проектных систем просто погибли после появления визуального MS Project для Windows или стали нишевыми для гиков.
Сейчас 58% пользователей оптимизируют ресурсы визуальными средствами, т.е. смотрят на различные индикаторы перегрузок ресурсов и потом мышкой таскают задачи. Отсюда и "красные человечки" в Microsoft Project и визуальный планировщик ресурсов Team Planner. Это средства не для гиков, а для нормальных 58% пользователей. Справедливости ради отметим, что визуальными средствами обычного MS Project не так-то просто делать разрешение конфликтов в строительных проектах из-за того что строительные ресурсы всегда работают группой. Чтобы облегчить эту проблему я предложил корпорации Microsoft внести дополнительную функцию в Microsoft Project по группировке ресурсов и разработчики в штаб-квартире Microsoft со мной согласились. К слову, перевод "Визуальный оптимизатор ресурсов" для Team Planner придумал я когда занимался локализацией MS Project на русский язык. Но в целом я соглашусь с Леонидом Демидовым, что для строителей визуальные средства оптимизации ресурсов для MS Project если он используется без Turbo Planner имеют ряд проблем по эффективным сценариям применения.
Вернемся к опросу Oracle. Обратите внимание на вторую практику 11% пользователей. Перед назначением многие пользователи не пытаются оптимизировать план работы ресурса, а пытаются понять свободен ли он прямо сейчас. Microsoft безусловно лидер в визуализации как ресурсных конфликтов, так и визуализации доступности ресурсов.
Следующий раздел опроса Oracle объясняет нам, почему Microsoft сосредоточился на системе согласования выделения ресурсов в Microsoft Project 2016. Это базовая техника для 26% пользователей. Если только 5% доверяют выравниваниям ресурсов, то 26% доверяют своим ресурсным менеджерам, которые выделяют ресурсы не автоматически, а согласуя и снова по приоритетам компании.
Далее в опросе Oracle указано, что попытки делать оптимизации укрупненных ресурсных планов провалилась у всех пользователей и таких не удалось найти. Однако 5% пользователей используют оптимизацию Resource Leveling, но по чревычайно детализированным планам. Давайте разберемся с этим.
Дело в том, что если вы не хотите стать посмешищем на контрольных примерах практиков как описано в этой статье, то вам нужно подробнее рассказывать машине об том как ресурс работает. Недостаточно спланировать просто выработку машины, если вы хотите оптимизировать ее использование нужно учитывать ее перемещение, мелкие текущие ремонты, обслуживания и т.п. Тогда в проектной системе будет больше данных для правдоподобной оптимизации и действительно в окне 1 недели достижима близкая к идеалу оптимизация с почасовым планом работы ресурсов. Но почему же тогда Сергей Шаринский использует более грубые месячные окна оптимизаций? Давайте разберемся.
Мое личное мнение как практика в ресурсных оптимизация думаю уже понятно. Чем меньше квант ("гранула" по Oracle) оптимизации и чем короче окно оптимизации, тем выше качества оптимизации можно достигнуть. Мое мнение не оригинально. Поэтому Microsoft и перешел на алгоритм "бульдозер" способный работать с неравномерными подневными загрузками ресурсов, а также включил период для окна оптимизаций в настройках Resource Leveling.
На рисунке ниже я сделал типовую задачу подневного планирования указав уточненные часы работы машины по дням. Microsoft Project прекрасно понял, что имеется "окно" свободных часов и составил оптимальный подневный план.
Однако в Spider Project вам просто недоступно подневное планирование, оно там заблокировано. Не существует аналога Task Usage (Использование задач) и Resource Usage (Использование ресурсов) в Spider Project где бы вы могли ввести "окно" как я сделал легко на картинке выше в Microsoft Project. Но еще более серьезная проблема возникнет, если вы попробуете собирать данные по факту понедельно как на картинке ниже.
На следующей картинке видно как сработал Resource Leveling в Spider Project после получения факта. Это ошибочное расписание. Дело в том, что при сборе факта в модуле "учет" не было возможности указать подневные данные и таким образом программа просто не знает в какой день закончила работать машина по конкретным задачам. Она предполагает, что часы "размазаны" по периоду и не может определить когда нужно точно начинать работу. Фактически невозможна "скользящая" оптимизация на периоде недели, поэтому Сергей и использует оптимизацию в окне месяца.
Отметим, что в Turbo Planner можно собирать факт по ресурсам как за открытый период целиком, так и подневно внутри периода, поэтому MS Project получит полную и корректную информацию об использовании ресурсов и отработает верно.
Правда на это замечание Сергей Шаринский и Вадим Овечкин мне написали, что его можно обойти если поставить каждому пользователю вводящему факт Spider Project, провести серьезный тренинг, а потом он будет самостоятельно открывать периоды на 1 день и так вводить факт. Честно говоря меня шокировала такая практика, т.к. тогда обычный исполнитель может куда угодно записать факт в проект хоть в далекое будущее, хоть в далекое прошлое. Это не так-то просто будет потом найти. Также пользователь не видит что он вводит за другие дни недели как на форме из Turbo Planner выше. Но коллеги говорят, что смогли построить подневный процесс указанным образом, хотя признают трудозатратность его организации.
Кроме этого, Пётр Алмазов, продолжает поддерживать Владимира Либерзона, что в Spider Project не используются ресурсные связи, а ресурсные связи показанные в видео мной просто вариант визуализации. Я бы может и согласился, но посмотрите сколько проблем выше от отсутствия подневного учета в Spider Project. Сделать его технически естественно не так трудно, единственная принципиальная проблема в том, что неравномерные подневные данные никак не ложатся в концепцию оптимизации на ресурсных связях. Тоже самое происходит и с нашим модулем ресурсной оптимизации в Turbo Planner на ресурсных связях - невозможно таким средством оптимизировать детальные подневные планы ресурсов, если это критично.
В чем я согласен с Петром Алмазовым, то что по-сути задача Выравнивания Ресурсов (Resource Leveling) это задача об приоритетах задач, чтобы решить какие делают вперед.
Большинство практиков как Сергеем Шаринский исходят из того, что приоритеты должны быть ручными и они не доверяют "эвристикам" с непредсказуемыми результатами. Детские академические задачки закрученные для продажи ПО не в счет, речь идет о реальных проектах.
Для таких пользователей мы и сделали первую версию своего оптимизатора ресурсов на ресурсных связях в Turbo Planner. Он работает по приоритетам задач под ручным управлением, но это если нет серверной версии нашего продукта, который будет доступен одновременно с MS Project 2016. Если будет сервер, то клиент Turbo Planner будет получать серверные приоритеты задач и они будут отличаться в корне от логики Spider Project, которая не завоевала доверия надежных расписаний.
Если вникнуть еще раз в критику практика-строителя из Уфы, то он разгромил Владимиром Либерзона в дискуссии используя примеры по большей части основанной на том, что Владимир применяет только "одномерный" 1D-подход к оптимизации ресурсов считая что существует только время как координата ресурса и пространство можно игнорировать.
Реальный Мир Планеты Земля является конечно не одномерным, а 4D-мерным, т.к. кроме измерения времени есть еще ПРОСТРАНСТВО. Нужно учитывать положение ресурсов в пространстве при оптимизации загрузки ресурсов, т.к. телепортация ресурсов неявно заложенная в модель Spider Project где нет пространства, конечно выдает некорректные результаты в более чем половине случае, т.к. машинам нужно перемещаться ровно столько же сколько и работать.
На самом деле сейчас несколько команд в мире работают над 4D Resource Leveling, где геометрия Пространства становится определяющим фактором ресурсных оптимизаций. Мы входим в круг этих иноваторов и что получится покажем с выходом MS Project 2016. Но пока вы можете использовать нашу систему выравнивания ресурсов для Microsoft Project, которая примерно в 20 раз быстрее стандартной и дает более стабильные и точные расписания на ручных приоритетах.
Думаю также многим интересна Success Story об Microsoft Project как двумя версиями продукта Microsoft убил 80% конкурентов на рынке и создал бизнес приносящий ему 1 миллиард долларов год.
После публикации видео разразилась дискуссия экспертов об практиках выравнивания ресурсов, обзор которой и результат опроса Oracle среди своих пользователей я решил дать в статье после этого видео.
Практическое использование выравнивания ресурсов против математических абстракций
Вообще мне показалась очень символичной критика Пётра Алмазова на мой фильм, который мне стал рассказывать как же здорово оптимизировать ресурсы в Spider Project и как отлично у него работают в Спайдере пара тестовых примеров, но вот почему-то он никак не может внедрить оптимизацию ресурсов у себя в ВЕНТАНА-ГРАФ. Надо сказать, что Владимир Либерзон гениальный маркетолог, который вот так разогрел гиков, которые носят "благую весть об выравнивании в Spider" но почему-то никто не спрашивают, а почему они сами не пользуются им раз он им так нравиться. Далее, к слову, я расскажу Петру как ему внедрить выравнивание ресурсов в полиграфии, т.к. я этим занимался практически. Как мы увидим далее практики отрицают техники планирования, которые хороши только на демо-примерах, но не в реальных проектах.
Мостотрест наверное главный "ресурсный кейс" Spider Project вообще в России и Владимир Шаринский поделился своим мнением об практическом опыте. К сожалению он согласен это делать только в нашей группе https://www.facebook.com/groups/msproject поэтому оригинальная орфография и стиль письма Сергея сохранен, хотя стиль несколько не академический.
 |
| Сергей Шаринский из Мостотреста показал даже книжку с нормами по Spider, чтобы доказать, что он реальный пользователь |
https://www.facebook.com/groups/msproject/permalink/854301507938711/
Общая оценка Сергея, что Spider Project работает, но у него есть некоторые замечания к качеству отчетности из продукта. Обратите внимание на комментарий, что Сергей считает, что "все программы одинаковы" в том числе в качестве Resoure Leveling. Это не слова на ветер, действительно по его методу работы через приоритеты и Spider Project и Turbo Planner дадут абсолютно одинаковый результат ресурсной оптимизации.
Обратите внимание, что на мой прямой вопрос к Сергею в свободной форме готовы ли он доверять Spider Project самостоятельно решать какие задачи надо делать вперед, он отверг это и заявил об тотальном использовании ручных приоритетов, т.к. "машина-дура" и не способна мыслить как человек.
Если приоритеты заданы в системе управления проектами принудительно, то нет места никакой "свободе эвристик" выравнивания ресурсов. Все проектные системы выдадут одинаковое расписание и могут различаться только скоростью расчета, с небольшими особенностями в точности стыковки задач и стабильности расписаний при изменениях. С Сергеем Шаринским согласен опытный пользователь Spider Project Леонид Демидов. Он также подтверждает, что без приоритетов практическое использование выравнивания в Spider Project не имеет смысла, т.к. влечет нарушение технологии.
Почему Сергей и Леонид не доверяет автоматике Spider Project решать какие задачи в какой последовательности делать и апеллируют к нарушению технологии выполнения проектами при выравнивании ресурсов без приоритетов? Для ответа на этом можете прочитать эту статью как практик-строитель из Уфы просто разбил в пух и прах Владимира Либерзона в личной дискуссии доказав, что его Resource Leveling может выдавать фантомные расписания, над которыми можно только посмеяться типа телепортации рабочих над стяжкой. Сергей как практик, а не теоретик как Петр, прекрасно это понимая отказался от эвристик и контролирует на 100% расписание ручными приоритетами.
К слову. Мне как раз приходилось заниматься практической оптимизацией загрузки машин в полиграфическом производстве. Сценарий там также отрицает любую свободу эвристик. Поясню Петру как ему нужно внедрять в полиграфии оптимизацию загрузки оборудования, раз у него на Spider дальше красивых демопримеров дело не идет:
- Нужно создать типовой фрагмент для заказа в полиграфическое производство
Сам фрагмент очень просто prepress-press-postpress с разбивкой по оборудованию. - Дальше в типовой фрагмент забиваются нормативы работы печатных станков и оборудования постпресса от тиража (для разных видов продукции нужны разные шаблоны)
- Потом быстро вставляем производственный заказ в портфель проектов и масштабируем его на тираж печати
- Вставляем приоритеты заказов исходя в первую очередь из важности клиентов нам и доплат за срочность.
- Получаем оптимизированный график работы оборудования
Как видим ни о какой "свободе эвристик" в выравнивании в полиграфии даже речи быть не может, там приоритеты используются еще более тотально, чем в стройке.
Если же вернуться к беседе с практиком Сергеем Шаринским, то он мне подтвердил, что использует технику оптимизации не на весь проект разом (обратите внимание на практическую бесполезность выравнивания портфеля проектов целиком, которые показывает Владимир Либерзон на пресейлах). Но что меня удивило, так слишком большое "скользящее окно оптимизации". Поясню. Действительно достижимая задача примерно на 20% повысить выработку машин путем ликвидации вынужденных простоев из-за ошибок планирования. Однако максимальная эффективность, как я покажу дальше с исследованием Oracle в руках в том числе, это окно оптимизации примерно неделя. Абсолютная реальная задача выйти на почасовое планирование ресурсов на горизонт недели причем настолько точное, что план будет настолько точно попадать в факт, что в ряде наших проектов с Microsoft Consulting Services типа Renessance Capital даже отказываются собирать факт за ненадобностью (он такой же как план один-в-один, такое качество расписаний). Сергей же заявил месячное окно, где такую качественную оптимизацию не сделать - на горизонте месяца вероятность непредвиденных рисков больше на порядок чем на горизонте недели. Как я потом понял, это связано с проблемами Spider Project в подневном планировании, которого там просто нет. Но об этом дальше.
Только 5% пользователей используют Resource Leveling как оптимизацию ресурсов, 69% ставит на визуальные методы
Оптимизируют ресурсы почти все с разной степенью детализации, но Resource Leveling используют только 5%. Эксперты из Oracle подготовили интересную презентацию по уровням зрелости в управлении ресурсами Resource Mature Management Model
На слайде ниже показан опрос, какие практики управления ресурсами используются не по заявлением из башни из слоновой кости математиков-абстракционистов, а реально и практически.
 |
| Oracle провел опрос пользователей насчет практически используемых средств ресурсной оптимизации |
- 58% - Визуальное разрешение ресурсных конфликтов. Визуально наблюдаю перегрузку и убираю ею движением мышки.
- 11% - Назначение ресурсов по доступности. Смотрю по системе, что ресурс доступен прямо сейчас, тогда его и назначаю
- 26% - Назначение ресурсов по согласованию. Выделение ресурсов происходит через процесс согласования и согласно бизнес-приоритетам
- 0% - Выравнивание ресурсов по укрупненным блокам работ. Грубое выравнивание без детализации работ.
- 5% - Выравнивание ресурсов по детальному ("гранулярному") плану работы ресурсов. Оптимизация на уровне мельчайших шагов использования ресурсов
Сейчас 58% пользователей оптимизируют ресурсы визуальными средствами, т.е. смотрят на различные индикаторы перегрузок ресурсов и потом мышкой таскают задачи. Отсюда и "красные человечки" в Microsoft Project и визуальный планировщик ресурсов Team Planner. Это средства не для гиков, а для нормальных 58% пользователей. Справедливости ради отметим, что визуальными средствами обычного MS Project не так-то просто делать разрешение конфликтов в строительных проектах из-за того что строительные ресурсы всегда работают группой. Чтобы облегчить эту проблему я предложил корпорации Microsoft внести дополнительную функцию в Microsoft Project по группировке ресурсов и разработчики в штаб-квартире Microsoft со мной согласились. К слову, перевод "Визуальный оптимизатор ресурсов" для Team Planner придумал я когда занимался локализацией MS Project на русский язык. Но в целом я соглашусь с Леонидом Демидовым, что для строителей визуальные средства оптимизации ресурсов для MS Project если он используется без Turbo Planner имеют ряд проблем по эффективным сценариям применения.
Вернемся к опросу Oracle. Обратите внимание на вторую практику 11% пользователей. Перед назначением многие пользователи не пытаются оптимизировать план работы ресурса, а пытаются понять свободен ли он прямо сейчас. Microsoft безусловно лидер в визуализации как ресурсных конфликтов, так и визуализации доступности ресурсов.
 |
| 69% пользователей оптимизирующие ресурсы делают ставку на визуальные инструменты и тут MS Project лидер |
Далее в опросе Oracle указано, что попытки делать оптимизации укрупненных ресурсных планов провалилась у всех пользователей и таких не удалось найти. Однако 5% пользователей используют оптимизацию Resource Leveling, но по чревычайно детализированным планам. Давайте разберемся с этим.
Проблема детальных планов работ ресурсов для ресурсной оптимизации
Это слайд из презентации Oracle поясняет и прямо предупреждает, что оптимизация на уровне отдельных задач приводит к взрывному росту расписаний. В чем же дело? |
| Oracle отмечает, что Resource Leveling приводит к "взрывному росту" задач, т.к. без высокой детализации не работает |
Проблема подневной оптимизации ресурсов в старых системах как Spider Project
Мое личное мнение как практика в ресурсных оптимизация думаю уже понятно. Чем меньше квант ("гранула" по Oracle) оптимизации и чем короче окно оптимизации, тем выше качества оптимизации можно достигнуть. Мое мнение не оригинально. Поэтому Microsoft и перешел на алгоритм "бульдозер" способный работать с неравномерными подневными загрузками ресурсов, а также включил период для окна оптимизаций в настройках Resource Leveling.
На рисунке ниже я сделал типовую задачу подневного планирования указав уточненные часы работы машины по дням. Microsoft Project прекрасно понял, что имеется "окно" свободных часов и составил оптимальный подневный план.
 |
| Задача выравнивания ресурсов в "окне", которая по зубам MS Project, но не по зубам Spider Project, т.к. в Spider даже невозможно так указать неравномерную загрузку ресурсу по плану |
Однако в Spider Project вам просто недоступно подневное планирование, оно там заблокировано. Не существует аналога Task Usage (Использование задач) и Resource Usage (Использование ресурсов) в Spider Project где бы вы могли ввести "окно" как я сделал легко на картинке выше в Microsoft Project. Но еще более серьезная проблема возникнет, если вы попробуете собирать данные по факту понедельно как на картинке ниже.
 |
| Spider Project не умеет вести подневный учет факта и поэтому неверно может определить где механизм внутри недели остановился и поэтому Leveling выдаст ошибочное расписание |
 |
| Методологическая ошибка проектирования выравнивания в Spider Project. Продукт не можете догадаться в какие дни недели по факту техника заканчивала работать, поэтому оптимальная недельная оптимизация затруднительна |
 |
| В современных системах как Turbo Planner есть функция подневного учета факта и для объема и для ресурсов, поэтому Resource Leveling правильно понимает "окна" работы ресурсов |
Кроме этого, Пётр Алмазов, продолжает поддерживать Владимира Либерзона, что в Spider Project не используются ресурсные связи, а ресурсные связи показанные в видео мной просто вариант визуализации. Я бы может и согласился, но посмотрите сколько проблем выше от отсутствия подневного учета в Spider Project. Сделать его технически естественно не так трудно, единственная принципиальная проблема в том, что неравномерные подневные данные никак не ложатся в концепцию оптимизации на ресурсных связях. Тоже самое происходит и с нашим модулем ресурсной оптимизации в Turbo Planner на ресурсных связях - невозможно таким средством оптимизировать детальные подневные планы ресурсов, если это критично.
Настало время 4D Resource Leveling
В чем я согласен с Петром Алмазовым, то что по-сути задача Выравнивания Ресурсов (Resource Leveling) это задача об приоритетах задач, чтобы решить какие делают вперед.
Большинство практиков как Сергеем Шаринский исходят из того, что приоритеты должны быть ручными и они не доверяют "эвристикам" с непредсказуемыми результатами. Детские академические задачки закрученные для продажи ПО не в счет, речь идет о реальных проектах.
Для таких пользователей мы и сделали первую версию своего оптимизатора ресурсов на ресурсных связях в Turbo Planner. Он работает по приоритетам задач под ручным управлением, но это если нет серверной версии нашего продукта, который будет доступен одновременно с MS Project 2016. Если будет сервер, то клиент Turbo Planner будет получать серверные приоритеты задач и они будут отличаться в корне от логики Spider Project, которая не завоевала доверия надежных расписаний.
Если вникнуть еще раз в критику практика-строителя из Уфы, то он разгромил Владимиром Либерзона в дискуссии используя примеры по большей части основанной на том, что Владимир применяет только "одномерный" 1D-подход к оптимизации ресурсов считая что существует только время как координата ресурса и пространство можно игнорировать.
Реальный Мир Планеты Земля является конечно не одномерным, а 4D-мерным, т.к. кроме измерения времени есть еще ПРОСТРАНСТВО. Нужно учитывать положение ресурсов в пространстве при оптимизации загрузки ресурсов, т.к. телепортация ресурсов неявно заложенная в модель Spider Project где нет пространства, конечно выдает некорректные результаты в более чем половине случае, т.к. машинам нужно перемещаться ровно столько же сколько и работать.
На самом деле сейчас несколько команд в мире работают над 4D Resource Leveling, где геометрия Пространства становится определяющим фактором ресурсных оптимизаций. Мы входим в круг этих иноваторов и что получится покажем с выходом MS Project 2016. Но пока вы можете использовать нашу систему выравнивания ресурсов для Microsoft Project, которая примерно в 20 раз быстрее стандартной и дает более стабильные и точные расписания на ручных приоритетах.
Оставьте комментарий