Автоматизация управления проектной организацией и управление разработкой проектной документацией

МИНИСТЕРСТВО ОБРАЗОВАНИЯ И НАУКИ

РОССИЙСКОЙ ФЕДЕРАЦИИ

 

ФЕДЕРАЛЬНОЕ БЮДЖЕТНОЕ ГОСУДАРСТВЕННОЕ ОБРАЗОВАТЕЛЬНОЕ УЧРЕЖДЕНИЕ

ВЫСШЕГО ПРОФЕССИОНАЛЬНОГО ОБРАЗОВАНИЯ

«УФИМСКИЙ ГОСУДАРСТВЕННЫЙ НЕФТЯНОЙ

ТЕХНИЧЕСКИЙ УНИВЕРСИТЕТ»

 

Кафедра «Экономика и управление на предприятии

нефтяной и газовой промышленности»

 

 

 

 

 

 

 

КУРСОВАЯ РАБОТА

по дисциплине «Управление разработкой проектов»

 

на тему: «Автоматизация управления проектной организацией и управление разработкой проектной документацией»

 

 

 

 

 

 

 

 

ВЫПОЛНИЛ студ. гр. БСП-11-01	А.А. Набиуллина
РУКОВОДИТЕЛЬ доц., канд.техн.наук	Е.В. Кузнецова

 

 

 

 

 

 

 

 

 

Уфа  2013

 

Содержание

ВВЕДЕНИЕ             3

1 УПРАВЛЕНИЕ ПРОЕКТНОЙ ОРГАНИЗАЦИЕЙ И

УПРАВЛЕНИЕ РАЗРАБОТКОЙ ПРОЕКТНОЙ ДОКУМЕНТАЦИИ  6

1. Место управления основным процессом в управлении проектной организацией          6

1.2.  Обмен данными между подсистемами             10

1.3.  Основные принципы организации обмена             15

1.4. Построение процессов экспорта и импорта            19

2 СОСТАВЛЕНИЕ ЛОКАЛЬНОЙ СМЕТЫ  НА СТРОИТЕЛЬСТВО ПРОИЗВОДСТВЕННОГО ЗДАНИЯ БАЗИСНО–ИНДЕКСНЫМ

МЕТОДОМ                            23

2.1 Определение понятия локальной  сметы Методы составления локальных  смет                              23

2.2 Локально-сметный расчет базисно - индексным методом на строительство  производственного здания в городе  Уфа              24

ЗАКЛЮЧЕНИЕ                   27

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ            29

Приложение 1

Приложение 2

 

ВВЕДЕНИЕ

 

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

В конце 60 гг. XX века темпы роста социалистической экономики замедлились. Среди других мер, которые должны были ускорить развитие, правительство предприняло попытки использовать некоторые методы управления, которые успешно применялись в западных странах. Это направление получило название «научной организации труда». Применительно к проектным работам эти методы сводились к диспетчеризации управления выполнения проектных работ на основе графиков [3].

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

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

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

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

 

Предметом исследования является автоматизация управления проектной организацией и управление разработкой проектной документацией

Целью курсовой работы является:

- с помощью трудов отечественных  и зарубежных теоретиков изучить  теоретические аспекты автоматизации  управления разработкой проектной  документации;

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

Задачей курсовой работы является:

- выявить роль и значение места управления основным процессом в управлении проектной организацией

-  изучить обмен данными  между подсистемами

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

- изучить основные принципы  организации обмена

- рассмотреть построение  процессов экспорта и импорта

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

 

1 УПРАВЛЕНИЕ ПРОЕКТНОЙ  ОРГАНИЗАЦИЕЙ И УПРАВЛЕНИЕ РАЗРАБОТКОЙ  ПРОЕКТНОЙ ДОКУМЕНТАЦИЕЙ

 

1.1. Место управления основным процессом в управлении проектной организацией

 

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

Наиболее важной системой, находящейся в центре информационных потребностей организации, является ERP-система – система управления предприятием, как именуют подобные системы российские разработчики. Среди наиболее распространенных систем этого типа – 1С, «Галактика», ПАРУС и ряд других. Главным звеном этих систем, вокруг которого строятся все остальные, является бухгалтерская подсистема, обеспечивающая реализацию основных функций общего управления – учет основных средств, расчет заработной платы, ведение бухгалтерского и налогового учета, складской учет. Естественным и широко распространенным дополнением к бухгалтерской подсистеме является информационно связанная с ней подсистема управления персоналом. Однако управление основной деятельностью организации в таких системах редко находит удачное решение; как правило, это удается в таких массовых видах деятельности, как производство – от мелкосерийного до массового, торговля, логистика. Именно здесь специфика каждой организации в наибольшей степени препятствует унификации решений в области автоматизации управления. Это приводит к необходимости выделения систем управления основной деятельностью в отдельный класс – MES-систем (см. п.1.6). Собственно, и 1С-предприятие, и 1С-магазин, и 1С-склад являются MES-системами для соответствующих видов деятельности. Комплекс ПЛАН-Про является такой системой для управления основной деятельностью проектных организаций.

 

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

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

Другой важной системой, которая, в отличие от ERP-систем, специфична для проектных организаций, является система электронного технического документооборота и электронный архив. Такого рода системы получают все большее распространение в проектных организациях; к этому побуждает технологическая «революция» в проектировании, связанная с вторжением и быстрым развитием электронных технологий не только в сам процесс проектирования, но и в строительство и эксплуатацию объектов. Эти процессы, в частности, приводят к постепенному переходу на трехмерные модели объектов как технологическую основу разработки проектной документации, причем эти модели рассматриваются уже не только как средство получения чертежей объекта, но и как основу для применения современных строительных технологий и последующей автоматизации управления эксплуатацией объекта, вплоть до его демонтажа. Рождающаяся в процессе проектирования трехмерная модель становится, таким образом, основой всего жизненного цикла объекта.

Есть целый ряд систем, реализующих электронные архивы проектной документации. Среди них – Search (ОДО Интермех), TDMS (C-Soft), Lotsia PDM (Lotsia Soft) и ряд других.

Понятно, что структура электронного архива является производной от структуры договоров или, точнее, объектов проектирования, к которым относятся договоры. Уже поэтому обмен информацией между MES-системой управления основным производством и электронным архивом неизбежен. Однако тесно связанный с электронным архивом электронный технический документооборот даже в самых примитивных своих формах обеспечивает как минимум обмен заданиями между подразделениями – участниками работы в электронном виде, а при более совершенных формах своего развития – параллельный процесс разработки нескольких или всех частей проектной документации в едином виртуальном пространстве (технология «единого проекта»). Здесь обмен информацией с MES-системой становится еще более интенсивным.

Так же, как в отношении ERP-системы, возникает аналогичный вопрос: где должна пролегать граница между этими системами? К примеру, где разумней формировать накладную на выпускаемую проектную документацию – в MES-системе (в частности, в ПЛАН-Про) или в системе электронного архива? С одной стороны, в ПЛАН-Про есть все необходимые реквизиты заказчика, которых может и не быть в системе технического электронного документооборота. С другой стороны, в системе электронного документооборота имеется полный перечень выпускаемых документов, которые составляет основное содержание накладной.

 

Можно поставить вопрос в более общем виде. Есть две системы, функционирующие в организации и имеющие пересекающиеся информационные области. Где разумно провести границу между ними?

 

Если рассматривать обе системы как подсистемы общей системы управления, то наилучшим решением следует признать такое, которое минимизирует объем обмена данными между ними.

Такой ответ проясняет общие подходы, которые хорошо помогают при решении частных, казалось бы, вопросов. Так, например, выпуск накладных в ПЛАН-Про потребовал бы передачи из системы документооборота в ПЛАН-Про перечня выпускаемых проектных документов. Этот перечень может оказаться существенно более обширным, чем реквизиты заказчика, необходимые для выпуска накладной; поэтому накладную следует формировать в системе документооборота. Тогда, скажем, для формирования на ее основе акта сдачи-приемки достаточно будет передать в ПЛАН-Про только номер и дату накладной.

Аналогично решается вопрос с данными по оплате работ. Если в ERP-системе (в частности, в бухгалтерской подсистеме) хранятся все проводки, фиксирующие даты и суммы поступивших от заказчиков оплат, то для подавляющего большинства отчетов в ПЛАН-Про достаточно сведений о состоянии оплаты на данный момент, т.е. о текущем сальдо по тому или иному договору. Это в разы сокращает объем данных, которые необходимы в ПЛАН-Про, хотя происходят из бухгалтерской подсистемы.

 

 

 

1.2. Обмен  данными между подсистемами

 

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

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

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 34.

 

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

 

Для анализа рассмотрим основные информационные потоки обмена данными между комплексами (табл.5).

 

 

Информационные потоки обмена данными

 

Таблица 5

 

Информа-			Направле-		Комплекс-	Используемые таблицы		Примеча-
ционный			ние потока		партнер по об-	ПЛАН-Про		ния
поток			(по отно-		мену
			шению к			Справо-	Другие таб-
			ПЛАН-Про)			чники	лицы
Контраген-			Экспорт		Управление	Контраген-
ты и их рек-					деятельностью	ты, банки,
визиты					предприятия	реквизиты
Структура			Импорт		- « -	Отделы, спе-		Прим.1
организации						циальности)
Производст-			Импорт		- « -	Сотрудники,
венный пер-						численность
сонал
Договоры			Экспорт		- « -	Контрагенты	Картотека	Прим.2
Акты			Экспорт		- « -	Контрагенты	Картотека,	Прим.3
							акты
Данные	об		Импорт		- « -	Контрагенты	Картотека,	Прим.4
оплате							(акты)
Трудозатра-			Экспорт		- « -	Отделы	Договоры	Прим.5
ты						(специаль-
						ности)
Графики			Экспорт		Электронный	Отделы	(Объекты),	Прим.6
					технический	(специаль-	Картотека
					документо-	ности), клас-
					оборот	сификатор
Графики	–		Импорт		- « -	Отделы	Графики	Прим.7
фиксация						(специаль-
выполнения						ности),
						класс-
						сификатор
Timesheet			Импорт		- « -	Сотрудники	Трудозатра-	Прим.8
							ты

 

 

Примечания.

1. Импортируются  только производственные отделы. Специальности (или группы, секторы) импортируются только в случае, если денежные или трудозатратные показатели планируются по специальностям.

2. Экспортируются  данные только оформленных договоров. Этапы экспортируются только  в случае наличия соответствующей  структуры в системе управления  предприятием.

3. Экспортируются акты как собственные (с момента их формирования), так и субподрядные, но только подписанные собственным руководством.
4. Импортируются данные об оплате, как полученной от заказчика, так и произведенной субподрядчику.
5. Экспортируются отчетные данные, если в системе управления предприятием организован учет трудовых ресурсов.
6. Экспортируются только утвержденные графики.

7. Импортируются даты последней предусмотренной маршрутом документа подписи.
8. Импортируются автоматически фиксируемые системой документооборота часы работы над документами данного договора (объекта) с последующей корректировкой при необходимости.

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

Схема взаимосвязей элементов ПЛАН-Про, участвующих в процессах обмена, приведена на рис. 35.

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис.35. Взаимосвязи участвующих в обменах элементов данных системы управления проектированием

 

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

 

Передача данных справочников может иметь две различные цели:

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

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

В соответствии с этим выбором каждый процесс представляет собой обработку подмножества выбранных элементов. Необходимость поддержки логической целостности баз данных при этом требует, чтобы при выборе определенного элемента автоматически выбирались бы также те элементы, которые лежат ниже по траекториям связей, т.е. против направления стрелок на рис.35. Например, при выборе «договоры» должны автоматически выбираться также «контрагенты»; при выборе «графики» выбирается также «классификатор событий» и либо «отделы», либо «специальности» - в зависимости от настройки. Таким образом определяется полный набор элементов, подлежащих обмену в данном сеансе.

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

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

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

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

 

1.3.  Основные принципы организации обмена

 

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

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

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

Рис. 36. Общая схема обмена данными между комплексами.

 

 

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

Состав транзитной базы определяется полным набором обмениваемых элементов. Для каждого пары соответственных элементов исходного и конечного комплекса создается обменная таблица. Состав ее полей представлен в таблице 6. Кроме того, в составе транзитной базы имеется сводная таблица, структура которой приведена в таблице 7, и таблица логики (структура приведена в таблице 8).

 

		Таблица 6
	Состав полей обменных таблиц транзитной базы
Поле	Назначение	Примечание
K0	Уникальный ключ таблицы
K1	Ключ в таблице экспорта	Переносится  из  таблицы  экспорта  одно-
		временно   с   соответствующим   опреде-
		ляющим полем (полями)
OP1	Определяющее поле (поля) в таблице	Переносится  из  таблицы  экспорта  одно-
	экспорта	временно  с  соответствующим  содержа-
		тельным полем (полями)
OP2	Определяющее поле (поля) в таблице	Переносится из таблицы импорта
	импорта
K2	Ключ в таблице импорта	То же
E	Признак ―найдено при экспорте»	Устанавливается  в  1  при  экспорте,  если
		найдено, и в 2 - если добавлено в транзит-
		ную таблицу
PI	Признак ―найдено при импорте»	Устанавливается в 1 импорте, если найдено, и во 2 – если не найдено в таблице импорта
SPi	Содержательные поля обменной таблицы	Обновляются при экспорте
APi	Алгоритмы вычисления соответствующих полей	Редактируются  при  настройке  приложения

 

 

 

Состав полей cводной таблицы транзитной базы
			Таблица 7
Поле			Назначение
Уникальный ключ	В частности, связь «один ко многим» с таблицей логики
Наименование элемента обме-	Служит для выбора режима элементов обмена со сторо-
на по комплексу 1	ны комплекса 1
Наименование элемента обме-	Служит для выбора режима элементов обмена со сторо-
на по комплексу 2	ны комплекса 2
Признак экспорт/импорт	Определяет режим работы с соответствующей таблицей
	транзитной базы в данном приложении: 1 – экспорт со
	стороны комплекса 1, 0 – со стороны комплекса 2
Характер работы при импорте	0	-	работа на соответствие,
	1	-	работа на пополнение
Текущее   состояние   таблицы	1	– последним был экспорт,
транзитной базы	0	– последним был импорт. Переключается последней
	транзакцией

 

 

Состав полей таблицы логики

Таблица 8

 

 

Поле	Назначение
Ключ  элемента  1  в  сводной	Поиск ведомого элемента в сводной таблице
таблице
Ключ  элемента  2  в  сводной	Поиск ведущего элемента в сводной таблице
таблице

 

Обменная таблица предназначена для сравнения данных, относящихся к одному и тому же элементу обмена из обоих комплексов. Она содержит ссылки на ключи (K1, K2) соответствующих записей в каждом из комплексов. Однако сами по себе ключи, конечно, не позволяют идентифицировать принадлежность записей одним и тем же объектам в базах данных; для идентификации нужны другие, содержательные поля, которые позволяли бы установить соответствие объектов из разных баз друг другу. Эти поля (их может быть несколько) назовем определяющими. Например, для отделов это могут быть их наименования или обозначения, для договоров – их шифры и т.д. Обозначим эти поля ОP1 и ОP2 соответственно. Необходимы также два логических поля PE и PI, которые будут фиксировать факт нахождения соответствующих записей при экспорте и импорте данных в эту таблицу соответственно. Набор остальных полей обменной таблицы определяется составом обмениваемых данных того элемента, к которому относится данная таблица.