Примеры и описание
Примеры использования возможностей Spider Project, описание общих подходов в работе с программой.
Представление Диаграмма Гантта является одним из самых наглядных представлений модели проекта. Списочное отображение перечня задач проекта с возможностью группировок и создания различных структур (см. пример Множественные структуры) и графическая часть с расположением задач на временной шкале позволяют максимально быстро оценить текущее состояние проекта. Для оперативных совещаний, отчетов перед руководством, заказчиками это представление наиболее удобно. Но в Диаграмме Гантта мы имеем возможность выводить информацию по всем показателям (объем, стоимость, трудоемкость и т.д.) исключительно в виде трех основных категорий: План, Факт и Итог (Итог=План+Факт). Штатных колонок временных интервалов (В день, В неделю, В месяц) и подобных Диаграмма Гантта не имеет.
Компьютерная модель проекта позволяет производить вычисления множества показателей проекта, расчет которых при отсутствии компьютерного подхода чрезвычайно трудоемок, особенно при постоянном изменении исходных данных. Один из показателей, позволяющих оценить корректность планирования работ по проекту, а также производить анализ, как текущего состояния, так и перспективы — График движения рабочей силы.
На практике часто возникают ситуации, когда оптимально было бы производить несколько работ параллельно, поскольку это позволит сократить длительность проекта, но какие-либо ограничения не позволяют это сделать. В сложной модели проекта подобное косвенное влияние друг на друга могут оказать Операции, технологически не связанные или даже относящиеся к двум различным Фазам проекта (двум проектам в портфеле). Учитывать подобное влияние при моделировании необходимо, поскольку в противном случае мы получим в модели неверные сроки производства работ, считая, что работы возможно производить параллельно, а также сформируем некорректное плановое задание, которое физически Ресурсы выполнить не в состоянии.
Создавая модель проекта, планировщик производит декомпозицию проекта по принятым в компании регламентам. И чаще всего первоначально отображает в ней очередность операций так, как они будут происходить в реальности. Календарная последовательность операций наиболее понятна и удобна при составлении пакетов работ и установке технологических связей. Но так же распространена ситуация, когда по одному из признаков (принадлежность к исполнителю, департаменту, филиалу, объекту, поставщику и пр.) операции одного блока (Фазы проекта) могут быть не родственными. При планировании и анализе модели возникает потребность видеть суммарные бюджеты, трудоемкости, объемы и прочие показатели проекта по группам операций, не входящих в одну фазу технологической модели. Также часто возникает потребность предоставлять для мониторинга и работы ответственному лицу только небольшой фрагмент модели (группу операций), попадающий в зону его компетенций для актуализации модели или формирования плановых заданий исполнителям. Для решения подобных задач используется инструмент Структуры Работ.
При выполнении реальных проектов может возникать ситуация, когда, например, штатные (наемные) специалисты компании или техника выходят на площадку, а по каким-либо причинам фронт работ для них по основной задаче отсутствует. Причины такого срыва в производстве работ могут быть как объективные (риски), так и субъективные (ошибки планирования). В результате, компания несет убытки, поскольку оплата рабочего времени обязательна, даже если специалисты или техника ничего не делают не по своей вине. Специалистов практически невозможно оперативно перебросить на другие виды работ как разнорабочих или комплексную бригаду. Простаивающий мощный кран или буровую тем более — их брали в аренду под конкретную задачу.
Компания должна использовать собственные наработанные типовые модели (шаблоны) для похожих проектов или фрагментов новых проектов. Но при однотипных задачах их технологическая реализация может радикально отличаться в зависимости от региона, времени года, проходимости трасс, доступности ресурсов, наличия средств для реинвестирования и многих других параметров. Создавать множество похожих моделей, ориентированных на определенные условия, непродуктивно. Задача тем более усложняется, если в рамках одного длительного проекта технология однотипных задач в разных его фрагментах зависит от внешних условий и может меняться. Сложность еще возрастает с увеличением числа комбинаций влияющих условий, а также когда влияющие условия динамически изменяются в зависимости от исполнения проекта. Используя возможности программы необходимо на этапе создания модели заложить в нее разные варианты реализации работ с автоматическим выбором необходимого варианта в зависимости от исходных или меняющихся текущих условий.
Иногда компания-подрядчик хочет в своей модели учесть поступающие оплаты произведенных работ от заказчика. Но заказчик поставил условие: оплата производится только для полностью выполненных работ и только с 20 по 22 число каждого месяца. Если к указанной дате плановый объем работы не выполнен (или не принят заказчиком), то оплата будет перенесена на 20-22 число следующего месяца.
Бюджет реальных проектов часто зависит от периодических выплат. Это может быть ежемесячная лизинговая оплата техники, взаиморасчеты с городскими структурами, оплата аренды всевозможных вспомогательных ресурсов, оплата охраны территории, периодические авансы производителям материалов и т.д. То есть каждый месяц (квартал, полугодие) по одной из статей затрат происходит списание определенной повторяющейся суммы. В данном примере речь пойдет именно о повторяющихся определенное время в рамках проекта одинаковых суммах оплат. Моделирование разовых оплат и создание специальных графиков оплат будут рассмотрены в других примерах.
Часто в проектах возникают ситуации, когда одна и та же работа не может производиться всегда по одному и тому же расписанию в течение всего проекта. Например, в работающем офисном здании возникла необходимость прокладки новых коммуникаций через все этажи и подвалы — компания устанавливает систему безопасности, дублирующую силовую проводку или что-то подобное. Понятно, что в готовых зданиях подобного рода существуют специальные закладные для будущих систем, но для примера будем считать что их нет.
На практике график работы ресурсов на задачах может быть любым. Начиная с классической пятидневки и заканчивая вахтами. Реализация графика работы ресурсов осуществляется при помощи Календарей и Календарных исключений.