Что за программа спайдер проджект

Без преувеличения можно сказать, что Spider Project лучшая отечественная система управления проектами. Минимальные требования к системе: процессор i486 или выше; операционная система Windows (95, 98, 2000, ХР); оперативная память не менее 32М; свободное место на диске для установки программы не ме­нее 25М, свободное место на диске для хранения проектов около 1500К на каж­дые 1000 операций проекта.

Рабочее пространство главного окна разбито на три функциональные зоны. В левой части — ярлыки к открытым проектам. В средней части — ярлыки на шаблоны представления и данные проекта. В правой части располагаются ярлыки на откры­тые документы проекта.

Документ проекта можно создать из текстовых файлов, html-файлов или фай­лов баз данных. Главным отличием Spider Project от западных собратьев является подход к определению длительности операций. В большинстве известных пакетов операции характеризуются длительностью их исполнения. В Spider Project наряду с длительностями можно задавать физические объемы работ на операциях.

Spider Project. FAQ

Длительность определяется в процессе составления расписания работ в за­висимости от производительности назначенных ресурсов. Spider Project позволяет создавать положительные и отрицательные временные задержки, можно также использовать и «объемные» задержки, которые предназначены для тех ситуациях, когда работа началась, но исполняется медленнее, чем было запланировано, по­тому что временная задержка может исчерпаться раньше, чем будет выполнен за­планированный объем работ. Кроме отдельных ресурсов можно задавать мультиресурсы и пулы.

Мультиресурсы — это группы ресурсов, которые используются для выполне­ния работы, в том числе это могут быть и исполнители работ (например, бригада). Мультиресурсы можно назначать на исполнение операций. Пулы — это группы взаимозаменяемых ресурсов. Spider Project позволяет использовать неограничен­ное количество составляющих стоимости, причем в разных валютах. Таким же об­разом можно создать неограниченное количество различных иерархических струк­тур работ и ресурсов.

Данная СУП имеет возможность хранить неограниченное количество версий проекта и анализировать ход исполнения работ не только по сравнению с какой-то базовой версией, но и с любой другой.

При расчете расписания проекта Spider Project учитывает ограниченность ре­сурсов и резервы сроков исполнения. Алгоритм анализа рисков так же отличается от других систем. При моделировании рисков в качестве исходной информации используются не оценки длительности (оптимистические или пессимистические), а оценки производительности ресурсов.

Непривычно реализована и поддержка групповой работы над проектом. В Spider Project нет одновременного доступа на изменение данных. Ответственный за свою часть проекта (фазу) представляет менеджеру проекта свои файлы, а ре­шение принять или отвергнуть изменения остается за менеджером проекта. По мнению разработчиков, именно такое решение позволяет избежать неразберихи при изменении проектных данных, и траты времени на «выкусывание блох».

Спайдер Проджект. Планирование — от производственной программы до ежесуточных заданий

С применением таких же принципов разработана и система групповой работы через Интернет. Обмен данными между сервером и клиентами осуществляется с использованием протокола FTP, что позволяет развернуть систему на любой плат­форме. Система взаимодействия между участниками проекта с использованием Intranet или Internet по следующему механизму:

• созданная главным менеджером полная версия проекта передается на сервер с указанием списка пользователей и уровня доступа тех, которым она предназначается;

• пользователи системы согласно включенным в список ограничениям по доступу к проектам, могут получить план проекта — только для чтения или его часть проекта для управления реализацией;

• в результате выполнения функции управления пользователь передает измененный план обратно на сервер, откуда он может быть получен руководителем проекта;

• получая доступ к серверу, пользователь видит список доступных для него проектов и открывает их прямо в Spider Project.

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

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

Можно назвать несколько известных проектов, при управлении которыми применялся SpiderProject. Это строительство в 1997г. Олимпийской деревни для Всемирных Юношеских Игр в Москве, строительство Каспийского трубопровода, газопровода Ямал-Европа, реконструкция Рязанского НПЗ.

Заключение

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

Источник: studopedia.su

Что за программа спайдер проджект

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

Отчетные данные в Гантте работ

Представление Диаграмма Гантта является одним из самых наглядных представлений модели проекта. Списочное отображение перечня задач проекта с возможностью группировок и создания различных структур (см. пример Множественные структуры) и графическая часть с расположением задач на временной шкале позволяют максимально быстро оценить текущее состояние проекта. Для оперативных совещаний, отчетов перед руководством, заказчиками это представление наиболее удобно. Но в Диаграмме Гантта мы имеем возможность выводить информацию по всем показателям (объем, стоимость, трудоемкость и т.д.) исключительно в виде трех основных категорий: План, Факт и Итог (Итог=План+Факт). Штатных колонок временных интервалов (В день, В неделю, В месяц) и подобных Диаграмма Гантта не имеет.

График движения рабочей силы

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

Ограниченное пространство производства работ

На практике часто возникают ситуации, когда оптимально было бы производить несколько работ параллельно, поскольку это позволит сократить длительность проекта, но какие-либо ограничения не позволяют это сделать. В сложной модели проекта подобное косвенное влияние друг на друга могут оказать Операции, технологически не связанные или даже относящиеся к двум различным Фазам проекта (двум проектам в портфеле). Учитывать подобное влияние при моделировании необходимо, поскольку в противном случае мы получим в модели неверные сроки производства работ, считая, что работы возможно производить параллельно, а также сформируем некорректное плановое задание, которое физически Ресурсы выполнить не в состоянии.

Множественные структуры

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

Но так же распространена ситуация, когда по одному из признаков (принадлежность к исполнителю, департаменту, филиалу, объекту, поставщику и пр.) операции одного блока (Фазы проекта) могут быть не родственными. При планировании и анализе модели возникает потребность видеть суммарные бюджеты, трудоемкости, объемы и прочие показатели проекта по группам операций, не входящих в одну фазу технологической модели. Также часто возникает потребность предоставлять для мониторинга и работы ответственному лицу только небольшой фрагмент модели (группу операций), попадающий в зону его компетенций для актуализации модели или формирования плановых заданий исполнителям. Для решения подобных задач используется инструмент Структуры Работ.

Оплачиваемый простой

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

Переключатель тепло-холод

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

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

Взаиморасчеты по выполненным работам всегда c 20 по 22 число

Иногда компания-подрядчик хочет в своей модели учесть поступающие оплаты произведенных работ от заказчика. Но заказчик поставил условие: оплата производится только для полностью выполненных работ и только с 20 по 22 число каждого месяца. Если к указанной дате плановый объем работы не выполнен (или не принят заказчиком), то оплата будет перенесена на 20-22 число следующего месяца.

Ежемесячные оплаты

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

Одинаковые задачи. Разные графики исполнения.

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

График работы «сутки-трое»

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

Источник: slovopisec.ru

Управление проектами, международная практика. Этапы Внедрения Спайдер Проджект

1. Управление проектами, Международная практика, Этапы Внедрения

Спайдер Проджект

2. Введение

• Проект — это временное предприятие,
предназначенное для создания
уникальных продуктов, услуг или
результатов.
• По американской исследованиям одна
треть мировой экономики – это проекты!
• Экономика становится все более
динамичной и доля проектов
непрерывно растет. Растет и интерес к
управлению проектами.
2

3. Введение

• Сегодня Управление проектами (Project
Management) – признанная область
менеджмента со своими стандартами,
сертификацией, специальностью в
Университетах и MBA программами.
• Наиболее крупной Ассоциацией
специалистов в области управления
проектами является PMI (Project
Management Institute), которая скоро
отметит свое сорокалетие.

4. История

• Управление проектами как наука
зародилась в конце 50-х годов в связи с
появлением компьютеров и методов
расчета проектов (сетевое планирование,
метод критического пути и т.д.).
• Бурное развитие началось в середине 80-х
с появлением персональных компьютеров
и программ управления проектами на
рабочих местах менеджеров.

5. ЭФФЕКТИВНОЕ УПРАВЛЕНИЕ ПРОЕКТАМИ

• Эффективное управление проектами
требует:
– Четкой постановки целей, которых следует
достигнуть за ограниченное время, а также
критериев успеха проектов,
– Применения программных средств,
– Матричных и проектных форм организации
управления,
– Системы мотивации участников проектов.

6. ЗАДАЧИ УПРАВЛЕНИЯ ПРОЕКТАМИ

• Практически Управление Проектами помогает
решить следующие основные задачи:
– обосновать целесообразность и оптимизировать
инвестиции,
– разработать оптимальную схему финансирования
работ, поставок материалов и оборудования,
– составить план работ, включающий сроки исполнения
работ, потребление ресурсов, необходимые затраты,
– проанализировать проектные риски,
– обеспечить эффективное взаимодействие участников
проекта,

7. ЗАДАЧИ УПРАВЛЕНИЯ ПРОЕКТАМИ

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

8. ЭФФЕКТИВНОСТЬ УПРАВЛЕНИЯ ПРОЕКТАМИ

• Исследования, проведенные в США,
показали, что внедрение управления
проектами сокращает затраты на
проекты на 10-15% при том, что
затраты на управление проектами
составляют в среднем 6.5% стоимости
проекта.

9. ЭФФЕКТИВНОСТЬ УПРАВЛЕНИЯ ПРОЕКТАМИ

• Динамика времени строительства этажа
монолитного здания в днях (внедрение СУП в
Зеленоградстрое) в процессе внедрения
системы управления проектами:
22 – 19 – 16 – 14 – 13 – 13

10. МОДЕЛИРОВАНИЕ ПРОЕКТОВ

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

11. ЗАДАЧИ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ

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

12. ЗАДАЧИ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ

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

13. ЗАДАЧИ КОМПЬЮТЕРНОГО МОДЕЛИРОВАНИЯ

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

14. Основные этапы внедрения корпоративной системы управления проектами

Спайдер Проджект

15. Этапы внедрения системы управления проектами

1) Обучение руководства и планирование внедрения
2) Разработка прототипов корпоративных стандартов
управления проектами и справочников норм и
расценок
3) Отработка системы на пилотном проекте
4) Внедрение системы управления проектами во
всех проектах и управления портфелем проектов
• Продолжительность внедрения системы в
большой организации – примерно 1.5-2 года, в
первом пилотном проекте – от 4-х месяцев.

16. Введение

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

17. Единая система кодирования

• Единая система кодирования проектов,
фаз, работ, ресурсов, материалов, типов
работ и ресурсов позволит объединять
проекты в систему управления
портфелем проектов организации,
получать кросс-проектные отчеты,
обеспечить применение во всех
проектах таких отчетов, которые
получаются в результате применения
стандартных фильтров и группировок.

18. Типовые Иерархические Структуры Работ

• Набор типовых Иерархических Структур
Работ позволит обеспечить
единообразные подходы к
декомпозиции работ проекта, получать
типовые отчеты, ускорит и облегчит
компьютерное моделирование
проектов, обеспечит быстрое вхождение
участников команд управления
проектами в новые проекты.

19. Корпоративные справочники типовых характеристик проектов

• Необходимо, чтобы во всех ведущихся
проектах использовались единые оценки
для типовых работ, ресурсов, материалов,
назначений ресурсов на исполнение
типовых операций.
• Система корпоративных справочников,
обязательных для использования в
проектах компании, обеспечивает
единообразие количественных оценок
выполняемых работ.

20. Типовые контракты

Необходимо разработать и типовые
контракты, чтобы ускорить процесс
контрактации и не допустить
возможных ошибок и упущений.

21. Реестр рисков

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

22. Руководство по управлению проектами

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

23. Пилотный проект

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

24. Управление пилотным проектом

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

25. Корпоративное управление проектами

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

26. Проектный Офис

Внедрение корпоративной системы
управления проектами подразумевает
создание Проектного Офиса и
внедрение управления всем портфелем
проектов компании.
Эта стадия внедрения требует
определенных организационных
изменений и вовлечение руководства в
управление портфелем проектов.

27. Проектный Офис

• Проектный офис обычно состоит из
следующих отделов:
–
–
–
–
Методологический
Аналитический
Архивный
Мультипроектного управления или
управления портфелем проектов

28. МЕТОДОЛОГИЧЕСКИЙ ОТДЕЛ

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

29. АНАЛИТИЧЕСКИЙ ОТДЕЛ

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

30. АРХИВНЫЙ ОТДЕЛ

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

31. ОТДЕЛ УПРАВЛЕНИЯ ПОРТФЕЛЕМ ПРОЕКТОВ

• Управляет портфелем проектов,
• Определяет приоритеты проектов и
распределяет общие ресурсы и
финансирование исходя из
приоритетов организации в целом,
• Разрешает конфликты между
проектами исходя из интересов
организации в целом.

32. КРИТИЧЕСКИЕ ФАКТОРЫ УСПЕХА

• Корпоративная система управления
проектами может быть успешно
внедрена только при наличии в
организации:
– Корпоративных стандартов,
– Системы мотивации участников проектов,
– Необходимых инструментов (программных
средств),
– Поддержки руководства

33. ПОДДЕРЖКА РУКОВОДСТВА

• Успех внедрения напрямую зависит
от степени поддержки руководства!
Сопротивление персонала – неизбежность при
внедрении в организации любых изменений, и
управление проектами – не исключение.
Не все в организации будут заинтересованы в
повышении прозрачности управления, контроле за
использованием ресурсов и затратами.
Именно руководство заинтересовано в этом
больше других и оно должно демонстрировать
свою приверженность внедрению системы
управления проектами, чтобы если не снять, то
ослабить сопротивление внутри организации.

34. Применение Spider Project

35. Использование пакета

• Спайдер Проджект используется
практически во всех отраслях экономики.
• С помощью Спайдер Проджект готовят
Олимпиаду в Сочи, строят небоскребы в
Гонконге, трубопроводы через Латинскую
Америку, оптоволоконные сети в Румынии,
железную дорогу в Греции, разрабатывают
программное обеспечение в Сингапуре и США
и т.д.

36. Использование пакета

• В настоящий момент Спайдер Проджект
используется в 26 странах на всех
континентах, кроме Антарктиды.
• И это несмотря на то, что пакет
абсолютно не рекламируется.
• Пакет заслужил известность и уважение
среди профессионалов всего мира и стал
российским брендом.

Источник: ppt-online.org