При внедрении программных систем управления проектами западного происхождения, приходится встречаться с различными проблемами, относящимися к отличиям как в традициях подходов к управлению производством, так и традициях отчетности. Представляется, что самым серьезным отличием и как следствие, самой серьезной проблемой, является отсутствие понятия «физобъем».
Строительная отрасль имеет свои давние традиции. Мерой работы (операции) традиционно является её физический объем, а не продолжительность. Поэтому можно утверждать, что без понятия «физобъем» серьезно говорить о создании модели строительного проекта в системах управления проектами - несерьезно.
Во всех, известных авторам западных пакетах для управления проектами, распространенных на российском рынке отсутствует понятие физобъем. Работа измеряется длительностью. Нет его в TimeLine, P3, OpenPlan, SureTrak, MS Project. Поэтому при внедрении и использовании СУПов приходится заниматься решением этой проблемы. Представляется, что существует как минимум два способа решения.
Первый способ - использовать программный комплекс, «знающий» что такое «физобъем» и умеющий с этим понятием работать. Примером такого пакета может служить Spider Project, российской компании «Технологии управления Spider». Если же требуется адаптировать западную систему, то проблему можно решить с помощью добавления в стандартную модель проекта пользовательских полей для хранения данных об объемах работ или изменения структуры баз данных системы. Предпочтительно использовать второй способ. Затем, с помощью встроенных в СУПы макроязыков, пользовательские поля любыми необходимыми алгоритмами связываются со стандартными полями систем. В некоторых случаях это позволяет решить проблему.
Плюсы и минусы при использовании СУП на этапе планирования:
Как и любые программные системы (бухгалтерские, сметные, САПР и.т.п.) системы управления проектами несвободны от недостатков. Представляется, что весовой коэффициент достоинств заметно больше. Ниже мы перечислим наиболее очевидные достоинства и недостатки.
Достоинства
Всё зависит от интерфейса системы, но, как правило, с помощью СУП очень удобно составлять расписания, кстати, именно для этого их и писали;
Работа всех участников проекта с единой моделью проекта и с едиными данными;
Возможность хранить сколь угодно много вариантов проекта;
Оперативное обновление измененной информации у всех участников проекта;
Немаловажным фактором является легкость и удобство получения различной отчетной и аналитической информации по проекту в графическом, табличном виде, диаграмм Ганта, сетевых графиков и т.д
Недостатки
Необходимость обучения большого количества людей использованию СУП на достаточно высоком уровне;
В связи с большим количеством лиц, имеющих доступ к данным – достаточно сложное и напряженное администрирование системы;
Необходимость использования одного программного продукта, или, как минимум, договоренности и согласования используемых форматов данных.
Хотелось бы так же затронуть методы разработки расписаний. На наш взгляд, их может быть как минимум два:
1. Метод «от смет» - при этом расписание формируется из сметы. Позиции сметы экспортируются в СУП (конечно же, включая кроме наименования и все другие данные – объемы, ресурсы, стоимостные характеристики и т.д.), затем в СУП накладываются технологические связи, ограничения по срокам, ресурсам; накладываются соответствующие кодировки (топология, WBS и т. п.). После расчета расписания получается проект. Такой проект может быть весьма подробным, но при этом не совсем удобным при отслеживании прогресса.
2. Метод «от технологии» заключается в том, что расписание делается «с нуля», причем имеет значение только технология производства, а дискретность выбирается исходя из разумной конечности операций. И уже после оптимизации расписания с технологической точки зрения, начинается наполнение голого расписания сведениями о ресурсах, стоимостях. При этом сведения о затратах могут быть учтены разными способами.
Достаточно сложно говорить о том, какой метод наиболее оптимальный. На рынке есть готовые решения для использования первого метода (примеры: «А-ноль» и «Примавера», «WinАВеРС» и MS Project/ Open Plan). В зависимости от традиций, каждая строительная организация может выбрать любой метод. Причем нет никаких особых проблем при комбинировании этих методов. Нам известны разные случаи. Например, одно из подразделений МВКС («Луч») использует практически в чистом виде первый метод (информация компании «Технологии управления Спайдер»). Если речь идет о желании получать процентовки после внесении сведений о прогрессе, то речь наверняка пойдет о первом методе. Если же мы говорим о том, что важно отслеживать проект – вероятнее всего оптимальней использовать второй метод. Хочется отметить, что эта тема активно обсуждалась на семинаре «Управление проектами» московского отделения PMI (https://www.pmi.ru).
Рассмотрим основные задачи, относящиеся к процессу контроля исполнения и управления проектом
Своевременный сбор фактических данных о ходе реализации проекта;
Оперативная авторизованная корректировка проектных данных;
Оценка способов и методов сбора фактических данных, при необходимости их корректировка;
Анализ состояния проекта по срезам (сроки, освоенный объем, работа ресурсов, оценка рисков)
Достоинства использования СУП на этапе реализации проекта
СУП позволяют хранить в своей модели проекта плановые показатели по проекту (сроки, стоимости, объемы и т.д.) и вводить фактические данные по ходу реализации проекта. Конечно же, исходный календарный план «плывет». Но система позволяет увидеть эти отклонения, оценить их последствия на проект в целом, проиграть и выбрать оптимальный вариант реакции на изменения, при необходимости перепланировать оставшуюся часть проекта с учетом новых реалий, оперативно внести изменения в документацию по проекту. Именно на этом этапе система проявляет свои лучшие качества - модель проекта «живет» вместе с реальным проектом. Менеджер проекта получает в свои руки инструмент не только контроля за свершившимися событиями, но и возможность прогнозирования предстоящих. В то же время, удобные, простые средства генерации отчетности по проекту позволяют легко довести необходимую информацию по проекту до всех заинтересованных лиц в требуемой форме. Кроме того, использование современных Internet-технологий позволяет получить доступ к проектным данным с любой точки земного шара.
Сами заметными ложками дегтя в этом случае являются проблема обеспечения достоверными и своевременными данными для отслеживания текущего состояния проекта (решается, как правило, административными мерами) и проблема обеспечения безопасности. В этой статье, мы не будем подробно останавливаться на рассмотрении указанных проблем, ввиду их объема и специфики.