Научная работа на тему ис строительной компании. Разработка информационной системы для строительной фирмы «ЛьвоffСтрой. С чего начинать внедрение информационной системы

2/2009 ВЕСТНИК

ИНФОРМАЦИОННЫЕ СИСТЕМЫ УПРАВЛЕНИЯ СТРОИТЕЛЬНЫМИ ПРОЕКТАМИ

Е.Г. Пенкина

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

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

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

Внедрение системы планирования и управления проектами может существенно повысить эффективность реализации строительных проектов. Основными преимуществами использования информационной системы управления проектами являются:

Возможность регламентирования процедур управление проектами;

Определение и анализ эффективности инвестиций;

Использование математических методов расчета временных, ресурсных, стоимостных параметров проектов;

Централизованное хранение информации по графику работ, ресурсам и стоимостям;

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

Обеспечение контроля выполнения работ проектов;

Возможность автоматизированной генерации отчетов и графических диаграмм, разработки документации по проекту;

Использования архива проектов и накопления знаний.

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

ВЕСТНИК 2/2009

В настоящее время вопрос организационного обеспечения ИСУСП проработан недостаточно хорошо.

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

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

При этом, алгоритм выбора выглядит следующим образом:

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

2. Составить таблицу сравнения спецификаций функций различных систем. Один из возможных вариантов представлен в табл. 1.

3. Оценить предложения поставщиков программного обеспечения, их сервиса, помощи при внедрении и т.п.

Табл. 1. Сравнения спецификаций функций различных систем

Требования при выборе ПО Функции, реализуемые в системе

Пользовательский интерфейс Настраиваемый интерфейс

Контекстная помощь

Удобство доступа к данным

Графические возможности

Разделение интерфейса по ролям

Стандартные мастера, шаблоны и представления экрана

Управление данными Удобство доступа и передачи информации

Защита от несанкционированного доступа

Интеграция данных с другими приложениями

Возможности разграничения прав доступа

Наличие функций OLAP

Механизм планирования Использование иерархической структуры ресурсов

Временной анализ по методу критического пути

Анализ стоимости и освоенного объема

Анализ рисков

Использование нескольких исходных планов

Использование шаблонов отчетов

Обеспечение совместной работы Наличие Web-приложений

Архитектура клиент-сервер

Представление доступа к данным удаленным пользователям

Оповещения и напоминания о работах

2/2009 ВЕСТНИК

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

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

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

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

Управление стоимостью проекта

Управление качеством проекта

Управление целями проекта

Основные

Управление интеграцией (завершением) _проекта_

Управление человеческим и ресурсами

Управление поставками и контрактами

Управление информацией и коммуникациями

Управление рисками проекта

Вспомогательные

Рис. 1. Критерии оценки эффективности проекта

Требования при выборе ПОФункции, реализуемые в системеПользовательский ин-терфейсНастраиваемый интерфейсКонтекстная помощьУдобство доступа к даннымГра-фические возможностиРазделение интерфейса по ролямСтандартные мастера, шаблоны и представления экранаУправление даннымиУдобство доступа и передачи информаци-иЗащита от несанкционированного доступаИнтеграция данных с другими приложения-миВозможности разграничения прав доступаНаличие функций ОЬЛРМеханизм плани-рованияИспользование иерархической структуры ресурсовВременной анализ по методу критического путиАнализ стоимости и освоенного объемаАнализ рисковИспользование нескольких исходных плановИспользование шаблонов отчетовОбеспечение совместной работыНаличие Web-приложенийАрхитектура клиент-серверПредставление доступа к данным удаленным пользователямОповещения и напоминания о работах

Количественная оценка эффективности информационной системы может рассчитываться по следующим основным критериям:

Отклонения по времени - сдвиги в расписании проекта, вызванные отставанием или опережением работ;

Отклонения по стоимости проекта - отклонения бюджета проекта, вызванные его перерасходом или недорасходом;

ВЕСТНИК 2/2009

Отклонения по качеству - устранение недостатков, найденных при проверке и оценке качества - оценка эффективности работы команды проекта по устранению недостатков, выявленных в ходе выполнения проекта.

Для каждого определенного критерия проекта вырабатываются весовые показатели (к1, к2, к3 и т.д.), которые соответствуют важности данного критерия.

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

(к1* АТ + к 2* АС + к 3* АО) АЕ = --- (1)

ДЕ - отклонения от применения информационной системы управления

АТ - отклонения по времени

АС - отклонения по стоимости проекта

АО - отклонения по качеству

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

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

Эффективность ИСУП зависит от таких факторов, как:

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

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

Учет требований пользователей - определяет удовлетворенность системой в практической работе;

Наличие необходимых технологических и финансовых средств;

Наличие подготовленного персонала (подготовленность сотрудников к осуществлению проекта конкретного профиля, готовность провести обучение сотрудников или набор соответствующих специалистов, иногда привлечение консультантов).

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

Рецензент: д.т.н., проф. С.А. Синенко, кафедра САПР в строительстве МГСУ

Журнал "Строительная техника и технологии", №4, 2008

Основная составляющая. Роль информационных систем в процессах управления строительными и девелоперскими проектами. Вадим Цветков, коммерческий директор "Вест Концепт".

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

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

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

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

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

Считается, что организация имеет общий централизованный штаб, и это позволяет ей экономить на издержках, связанных с содержанием дополнительных бухгалтеров, сметчиков, юристов и т.п. Здесь нелишне вспомнить о том, из кого такой штаб состоит физически: это, как правило, те же самые люди, которые 5-7 лет назад начинали девелоперский бизнес вместе с владельцами, решая исключительно оперативные задачи управления, связанные со строительством того или иного объекта. С одной стороны, они привыкли мыслить в категориях конкретного договора строительного подряда, расценок на тот или иной вид СМР и материалов или, например, недельной заявки на расходование денежных средств. С другой - они параллельно с работой учились на курсах, получали вторые и третьи дипломы, рос уровень их самооценки. И вот теперь этот штаб не склонен больше обслуживать проекты (только контролировать!), другого же штаба у новых руководителей проектов нет.

В результате десяток новоиспеченных проектных менеджеров неделями стоят в очереди на прием к финансовому директору компании.

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

Если выделить основные сложности проектов в строительстве, то они в общем и целом сводятся к следующим тезисам:

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

И ниже приведем немного статистики от консалтинговой компании Standish Group:

• 31% проектов завершаются провалом;
• 53% проектов завершаются с перерасходом бюджета в среднем в 1,9 раза;
• только 16% проектов укладываются в срок и бюджет.

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

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

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

Основными преимуществами использования информационной системы управления проектами являются:

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

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

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

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

Во многих системах управления проектами графики получаются автоматически, если определены задачи и ресурсы:

• календарно-сетевые графики проекта;
• график проведения тендеров;
• план заключения договоров;
• бюджет движения денежных средств, план платежей и поступлений.

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

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

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

• утверждение менеджером проекта;
• утверждение куратором проекта;
• утверждение финансовым департаментом.

После утверждения формального плана на менеджера ложится задача по его реализации.

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

Сотрудники, участвующие в проекте, получают список своих задач и проставляют факт их выполнения:

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

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

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

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

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

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

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

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

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

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

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

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

Метод оценки «сверху вниз»
Метод оценки стоимости «сверху вниз» (top down estimate) используется для оценки затрат на ранних стадиях проекта, когда информация о проекте еще очень ограничена. Смысл такой укрупненной экспертной оценки в том, что она производится обобщенно и проект оценивается в целом по одному показателю. Оценка удобна тем, что не требует больших усилий и времени. Недостатком же является не такая высокая точность, какая могла бы быть при более детальной оценке.

Метод оценки «снизу вверх»
Метод оценки «снизу вверх» нужен для выработки согласованной базовой цены проекта или окончательной стоимостной оценки проекта. Название метода отражает способ расчета стоимостной оценки - метод предусматривает оценку затрат на детальных уровнях проекта, а затем суммирование затрат наболее высоких уровнях обобщения для получения оценки стоимости (сметы) всего проекта. Для осуществления такой «свертки» затрат можно использовать структуру декомпозиции работ (СДР или WBS) проекта. Преимущество этого метода состоит в точности получаемых результатов, которая, в свою очередь, зависит от уровня детализации при оценке затрат на начальных стадиях рассмотрения. Из математической статистики известно, что чем больше деталей добавляется в рассмотрение, тем выше точность оценки.

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

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

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

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

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

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

Управление рисками в проекте
Очень большое значение в проектном менеджменте имеет процесс управления рисками. Информационная система позволяет наглядно и удобно обеспечить возможность управления следующими задачами:

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

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

• хранить проектную документацию «внутри» проекта;
• привязывать документы к задачам и проектным работам;
• утверждать и согласовывать документы;
• нескольким пользователям работать с одним документом;
• обсуждать документы;
• хранить их версии.

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

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://www.allbest.ru/

Оглавление

• Введение
• 2.2 Нормальные формы
• 2.5 Алгоритм синтеза
• 2.8 Создание схемы данных
• 2.9 Выбор средств разработки
• 3. Разработка информационной системы
• 3.1 Пользовательский режим работы
• 3.2 Режим работы инвестором
• 3.3 Режим работы управляющего
• 3.4 Режим работы директором
• 4. Безопасность и санитарно-гигиенические условия труда на рабочем месте пользователя ПЭВМ
• 4.1 Характеристика санитарно-гигиенических условий труда
• 4.2 Вентиляция
• 4.3 Расчет осветительной установки
• 4.4 Режим труда
• 4.5 Требования по организации рабочего места
• 4.6 Электрическая безопасность
• Выводы
• 5. Расчет экономической эффективности проекта
• 5.1 План маркетинга
• 5.2 Цели, задачи и методы оценки инвестиций
• 5.3 Выбор и описание разрабатываемого и альтернативного вариантов
• 5.4 Расчёт вложений на этапе разработки и отладки основного варианта
• 5.5 Расчёт вложений на этапе разработки и отладки альтернативного варианта
• 5.6 Расчёт вложений по годам этапа эксплуатации
• 5.7 Итоговые показатели технико-экономической эффективности
• Выводы
• Заключение
• Приложение 1Скрипт создания БД в MYSQL

Введение

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

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

В инвестиционно-строительных компаниях широко применяется инженерная системотехника строительства, а именно: автоматизированные системы управления строительством (АСУС), системы автоматизированного проектирования (САПР), автоматизированные системы обработки данных и документации (АСОД) и другие, которые способствуют повышению эффективности и качества управления.

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

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

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

1. Проектирование информационной системы

1.1 Сущность информационной системы

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

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

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

1.2 Функциональная спецификация

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

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

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

Инвесторы осуществляют финансирование и следят за ходом строительства. У каждого объекта может быть несколько Инвесторов, а также один Инвестор может финансировать несколько объектов недвижимости.

автоматизация информационная система пользовательский

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

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

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

1.3 Подходы к проектированию ИС

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

· Функционально модульный или структурный - в основу положен принцип функциональной декомпозиции, в котором система описывается в терминах иерархии ее функций и передачи информации между отдельными функциональными элементами

· Объектно-ориентированный подход - использует объектную декомпозицию. Система описывается в терминах объектов и связей между ними, а поведение системы в терминах обмена между ними.

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

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

Во второй половине 80х годов появилось методология объектно-ориентированного программирования

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

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

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

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

1.4 Унифицированный язык моделирования UML

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

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

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

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

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

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

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

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

Предварительные версии UML начали использоваться в области создания программного обеспечения, а на основании отзывов потребителей производились существенные доработки. Многие корпорации ощутили, что язык UML может оказаться полезным для достижения их стратегических целей. Это привело к возникновению консорциума UML, в который вошли такие компании, как DEC, Hewlett-Packard, Intellicorp, Microsoft, Oracle, Texas Instruments, Rational и другие. В 1997 году консорциум выработал первую версию UML и представил ее на рассмотрение группе OMG (Object Management Group), откликнувшись на ее запрос о подаче предложений по стандартному языку моделирования.

После расширения консорциума вышла версия 1.1 языка UML, которую группа OMG приняла в конце 1997 года. После этого OMG приступила к сопровождению UML и выпустила в 1998 году две его новые версии. Язык UML стал стандартом де-факто в области разработки программного обеспечения. В настоящее время этот язык продолжает активно развиваться

Язык UML предназначен для решения следующих задач:

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

o Снабдить исходные понятия языка UML возможностью расширения и специализации для более точного представления моделей системы в ООАП (объектно-ориентированный анализ и проектирование) конкретной предметной области.

o Ни одна из конструкций языка UML не должна зависеть от особенностей ее реализации в известных языках программирования.

o Поощрять развитие рынка объектных инструментальных средств.

o Способность совершенствоваться.

o Интегрировать в себя новейшие и наилучшие достижения практики

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

· Диаграмма вариантов или прецедентов использования (use case diagram)

· Диаграмма классов (class diagram)

· Диаграммы поведения (behavior diagrams)

o Диаграмма состояний (statechart diagram)

o Диаграмма деятельности (activity diagram)

· Диаграммы взаимодействия (interaction diagrams)

o Диаграмма последовательности (sequence diagram)

o Диаграмма кооперации (collaboration diagram)

· Диаграммы реализации (implementation diagrams)

o Диаграмма компонентов (component diagram)

o Диаграмма развертывания (deployment diagram)

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

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

1.5 CASE средство Rational Rose

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

CASE-средство Rational Rose со времени своего появления претерпело серьезную эволюцию и превратилось в современное и мощное средство анализа, моделирования и разработки программных систем. Именно в Rational Rose 98/2000 язык UML стал базовой технологией визуализации и разработки программ, что определило популярность и стратегическую перспективность этого инструментария.

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

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

· сокращение время разработки;

· уменьшение ручного труда, увеличение продуктивности;

· улучшение потребительских качеств создаваемых программ;

· способность вести большие проекты или группу проектов;

· позволяет быть языком общения между различными разработчиками.

В виду того, что разрабатываемая система представляет собой создание БД, то не стоят задачи полной разработки автоматизации процесса моделирования, т.е. написание кодов программ при помощи Rational Rose. Решение поставленных задач позволяют не пользоваться этим на данной точке проектирования, но в свою очередь является полезной стартовой площадкой для возможного дальнейшего использования, данного разработанного проекта, для внедрения в состав какого-либо другого программного продукта. Построенные модели помогают точнее понять задачи, которые должна выполнять система и являются понятным средством общения с заказчиком или в дальнейшей работе с другими разработчиками. Рассмотрим сначала функциональную модель нашей системы. Наша система имеет ряд пользователей, объединенных определенными задачами, что позволяет нам разделить систему на несколько подсистем и описать их по отдельности не создавая большого объема и избыточности. Рассмотрим некоторые из диаграмм, которые активно помогли мне в определении большинства тех вещей, которые будет выполнять данная информационная система.

1.6 Диаграмма вариантов использования

Разработка данной диаграммы преследует следующие цели:

· Определить общие границы и контекст моделируемой предметной области на начальных этапах проектирования системы

· Сформулировать общие требования к функциональному поведению проектируемой системы.

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

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

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Use Case диаграмм (сценариев). Опишем основные элементы см. таблице 1.1.

Рис 1.1 Диаграмма прецедентов

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

Рис.1.2 Диаграмма управляющего

Диаграммы состояний .

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

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

Процессы, происходящие в этот момент, когда объект находится в определенном состоянии, называются действиями (actions).

С состоянием можно связывать следующие данные: деятельность, входное действие, выходное действие и событие.

Деятельность (activity) - это поведение, реализуемое объектом, пока он находится в данном состоянии. Деятельность изображают внутри самого состояния; ее обозначению должно предшествовать слово do (делать) и двоеточие.

Входное действие (entry action) - это поведение, которое выполняется, когда объект переходит в данное состояние. Входное действие также показывают внутри состояния, его обозначению предшествуют слово entry (вход) и двоеточие.

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

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

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

Рис.1.3 Диаграмма состояний "Объекта строительства"

Диаграмма деятельности

Выделен объект, данные о котором необходимо хранить в базе данных.

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

Средства Rational Rose позволяют для описания функциональной системы воспользоваться графическим редактором для построения Activity диаграмм (деятельности).

Диаграммы деятельностей предпочтительнее использовать в следующих ситуациях:

· анализ варианта использования. На этой стадии нас не интересует связь между действиями и объектами, а нужно только понять, какие действия должны иметь место и каковы зависимости в поведении системы. Связывание методов и объектов выполняется позднее с помощью диаграмм взаимодействия;

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

Рис.1.4 Диаграмма активности "Создание объекта"

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

Диаграммы взаимодействия

Диаграммы взаимодействия (interaction diagrams) описывают поведение взаимодействующих групп объектов. Каждая диаграмма описывает поведение объектов в рамках только одного прецедента. На диаграмме изображаются объекты и те сообщения, которыми они обмениваются между собой. Определяют три типа сообщений:

· информационные (informative) - сообщения, снабжающие объект-получатель информацией для обновления его состояния;

· сообщения - запросы (interrogative) - сообщения, запрашивающие выдачу информации об объекте-получателе;

· императивные (imperative) - сообщения, запрашивающие у объекта-получателя выполнение действия.

Существует два вида диаграмм взаимодействия:

· последовательности (sequence diagrams);

· кооперативные (collaboration diagrams).

На диаграмме последовательности объект изображается в виде прямоугольника на вершине пунктирной вертикальной линии. Эта вертикальная линия называется линией жизни (lifeline) объекта. Она представляет собой фрагмент жизненного цикла объекта в процессе взаимодействия.

Каждое сообщение изображается в виде стрелки между линиями жизни двух объектов. Сообщения появляются в том порядке, как они показаны на странице, сверху вниз. Каждое сообщение помечается как минимум именем сообщения; при желании можно добавить также аргументы и некоторую управляющую информацию и, кроме того, показать самоделегирование (self-delegation) - сообщение, которое объект посылает самому себе, при этом стрелка сообщения указывает на ту же самую линию жизни.

Рис.1.5 Диаграмма последовательности "Назначение строителя на объект"

Вывод по диаграмме: выделены объекты сущности (список пользователей, объект, список строителей) и граничные объекты - страницы (окно ввода пароля, окно текущего объекта).

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

Рис.1.6. Кооперативная диаграмма "Назначение строителя на объект

Алгоритм работы с системой через WEB-интерфейс

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

Для проектирования сайта используется диаграмма классов.

В Rational Rose включен Add In под названием Web Modeler для проектирования сайтов.

Последовательность действий при создании Web приложения:

ь Подключить Web Modeler при помощи пункта меню Add In - Add In Manager - Web Modeler. В меню Tools появится новый пункт Web Modeler

ь Изменить установки принятые по умолчанию Tools - Options - Notation - Default Language - Web Notation

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

Рис.1.7 Алгоритм работы с программой

2. Проектирование базы данных

2.1 Требования, предъявляемые к базе данных

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

2) Целостность данных. Целостность данных состоит в поддержании правильности данных. Обеспечивается восстановлением данных после разрушения в результате случайных сбоев в работе ЭВМ, а также устранения противоречивости данных, которое заключается в появлении различных экземпляров для одних и тех же атрибутов. Противоречивость может появиться при обновлении избыточных данных в том случае, если обновление будет выполнено только на части данных.

3) Безопасность и секретность. Обеспечивает защиту данных от аппаратных и программных сбоев, от катастрофических и криминальных ситуаций, а также от некомпетентного доступа к ним.

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

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

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

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

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

2.2 Нормальные формы

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

В настоящее время известно несколько нормальных форм. Первая нормальная форма (будем обозначать 1НФ), далее - по мере "усиления" - 2НФ, 3НФ, нормальная форма Бойса-Кодда (НФБК) и 4 НФ. Практика показывает, что приведение БД хотя бы к 3НФ позволяет избежать в большинстве случаев почти всех недостатков.

Первая нормальная форма (1НФ).

Отношение со схемой R и множеством функциональных зависимостей F находится в 1НФ, если любой экземпляр схемы R удовлетворяет следующим условиям:

каждый атрибут схемы R имеет уникальное имя;

элементы кортежей с одним и тем же именем должны быть определены на одном и том же домене;

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

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

в отношении не должно быть повторяющихся кортежей.

Вторая нормальная форма (2 НФ).

Отношение со схемой R и множеством функциональных зависимостей F находится во 2НФ, если оно находится в 1НФ, и каждый неключевой атрибут функционально полно зависит от любого возможного первичного ключа схемы-отношения R.

Однако, схема отношения, находящаяся во 2 НФ, также имеет недостатки. В частности, множество зависимостей, определённое на этой схеме, может содержать транзитивные зависимости, которые могут приводить к нежелательным последствиям (аномалиям удаления).

Третья нормальная форма (3 НФ).

Схема отношений R с множеством функциональных зависимостей F находится в 3НФ, если оно находится во 2 НФ, и каждый неключевой атрибут прямо, а не транзитивно зависит от любого возможного ключа схемы отношения.

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

Нормальная форма Бойса-Кодда (НФБК).

Нормальная форма Бойса-Кодда более "сильная", чем третья нормальная форма. Схема отношений R с множеством функциональных зависимостей F находится в НФБК, если левая часть каждой зависимости (ХА) F, где А Х, есть первичный или возможный первичный ключ.

Если отношение находится в НФБК, то оно находится и в третьей нормальной форме, но не наоборот.

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

2.3 Нормализация схем отношений

Для построения реляционной реализации концептуальной схемы БД, которая находилась хотя бы в 3 НФ, можно использовать два способа:

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

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

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

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

Сложность алгоритма выше, чем полиномиальная.

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

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

2.4 Интеграция пользовательских представлений

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

Интегрированное представление пользователей, представленное в виде диаграммы

2.5 Алгоритм синтеза

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

Результатом работы алгоритма является схема автоматизированной системы управления в виде набора декомпозиционных подсхем {R 1 , R 2 ,., Rp}, удовлетворяющих следующим условиям.

Каждая подсхема Ri с БД должна находится хотя бы в ЗНФ относительно множества функциональных зависимостей F и соответственно G.

Синтезируемая информационная система содержит минимальный набор декомпозиционных подсхем Ri, I == 1,., Р. Это условие защищает информационную систему от избыточности.

Для любого экземпляра r (БД), удовлетворяющего F, выполняется соотношение. Это условие гарантирует выполнимость свойства соединения без потерь информации.

Схема автоматизированной системы управления, удовлетворяющая условиям 1,2 и 3, называется полной схемой автоматизированной системы управления.

Рассмотрим шаги алгоритма.

Шаг 1 . Строим расширенное множество F функциональных зависимостей, которое имеет следующую структуру зависимостей:

F = { (X I - > Y I) | (X I - >Y I) F, Y I = X I + \ X I }. Этот шаг делается с целью построения неизбыточного или условно неизбыточного покрытия F, что позволит в некоторой степени удовлетворить условию 3. Полностью обеспечить условие 3 удастся после введения в рассмотрение понятия эквивалентности функциональных зависимостей на шаге 5.

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

Очевидно, это покрытие не является каноническим.

Шаг 3 . Если среди функциональных зависимостей из F" нет зависимости, включающей все атрибуты из U, то добавляем к F" тривиальную зависимость U-> Ш.

Шаг 4 . Преобразуем полученные нетривиальные зависимости к элементарному виду (без лишних атрибутов в левых частях).

Зависимость X I - > Y I является элементарной, если не существует таких наборов атрибутов X J X I , что (X j - > Y I ) . Если - существует, то зависимость X I - >Y I заменяется зависимостью (X J - >Y I).

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

Зависимости X I - >Y I и X J - > Y J будем называть эквивалентными, если

, т.е. минимальный ранг имеет зависимость, содержащая все атрибуты из U, а, если ее нет, то - тривиальная зависимость U - > Ш. Всем зависимостям из одного класса эквивалентности назначаем одинаковый ранг. Несравнимым зависимостям ранги назначаем произвольно.

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

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

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

Множество атрибутов :

U = {mNo, mName, mCost, count, oNo, oAddress, oType, oStoreys, oState, eNo, eName, ePost, eState, eSalary, sum, iNo, iName, iPhone}

Множество функциональных зависимостей :

F = {mNo®mName, mNo®mCost, mName®mNo, mName®mCost,

(oNo, mNo) ®count,

oNo®oAddress, oNo®oType, oNo®oStoreys, oNo®eNo, oNo®oState, oNo®oCost

eNo®eName, eNo®ePost, eNo®eState, eSalary

iNo®iName, iNo®iPhone,

(iNo, oNo) ®sum }

Шаг 1. Расширенное множество функциональных зависимостей:

mNo + =mNo, mName, mCost =>mNo® (mName, mCost)

mNo + =…=>mNo®…

(oNo, mNo) + =oNo, mNo, count=> (oNo, mNo) ?®count

oNo + =oNo, oAddress, oType, oStoreys, oState, oCost, eNo =>oNo® (oAddress, oType, oStoreys, eNo,oState, oCost)

oNo + =…=>oNo®…

eNo + =eNo, eName, ePost, eState, eSalary=>eNo® (eName, ePost, eState, eSalary)

eNo + =…=>eNo®…

iNo + =iNo, iName, iPhone=>iNo® (iName, iPhone)

iNo + =…=>iNo®…

(iNo, oNo) + =iNo, oNo, sum=> (iNo, oNo) ®sum

(mNo, oNo, iNo, eNo) + =mNo, mName, mCost, count, sum, oNo, oAddress, oType, oStoreys, iNo, iName, iPhone, eNo, eName, ePost, eState, eSalary, oState, oCost

=> (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary, oCost)

F = {mNo® (mName, mCost), mNo®…, (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, eNo, oState, oCost), oNo®…, eNo® (eName, ePost, eState, eSalary), eNo®…, iNo® (iName, iPhone), iNo®…, (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, oState, iName, iPhone, eName, ePost, eState, eSalary) }

Шаг 2. Неизбыточное покрытие

F" = {mNo® (mName, mCost), (oNo, mNo) ?®count, oNo® (oAddress, oType, oStoreys, oState, oCost, eNo), eNo® (eName, ePost, eState, eSalary), iNo® (iName, iPhone), (iNo, oNo) ®sum, (mNo, oNo, iNo, eNo) ® (mName, mCost, count, sum, oAddress, oType, oStoreys, iName, iPhone, eName, ePost, eState, eSalary) }

Шаг 3. Тривиальная зависимость

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

Шаг 4. Элементарный вид зависимостей

Все зависимости элементарные.

Шаг 5. Эквивалентность зависимостей

Эквивалентных зависимостей нет.

Шаг 6. Ранжирование зависимостей

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

Зависимости X I Y I и X J Y J будем называть эквивалентными, если (X I Y I) = (X J Y J).

Ранжируем полученные зависимости по следующему правилу rang (X I Y I) > rang (X J Y J), если (X I Y I) (X J Y J).

Всем зависимостям из одного класса эквивалентности назначаем одинаковый ранг. Несравнимым зависимостям ранги назначаем произвольно.

Шаг 7. Диаграмма ранжированных зависимостей (2 НФ):

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

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

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

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

Шаг 8. Получаем совокупность декомпозиционных подсхем

После прохождения алгоритма было получено 6 таблиц с соответствующими первичными ключами:

R1 = oNo, oAddress, oType, oStoreys, oState, oCost, eNoс ключом oNo

R2 = eNo, eName, ePost, eState, eSalaryс ключомeNo

R3 = oNo, mNo,countс ключом (oNo, mNo)

R4 = mNo, mName, mCostс ключомmNo

R5 = iNo, iName, iPhoneс ключомiNo

R6 = iNo, oNo, sumс ключом (iNo, oNo)

Rational Rose Data Modeler средство проектирования БД

Авторы Data Modeler прежде всего ориентировались на создание инструмента проектирования физической модели данных. При этом не произошло отказа от UML как от средства моделирования данных, а некоторым образом были смещены акценты: теперь UML предполагается использовать для построения логической модели. По сути, логическая модель - это та же объектная модель, состоящая из объектов - сущностей. Переход от логической модели к физической и наоборот в части моделирования данных обеспечивается Rational Rose автоматически. Для этого введено соответствие элементов моделей.

Таблица 2.1 Соответствие элементов логической и физической модели

Таким образом, концептуально модуль Data Modeler не является заменой UML в некотором его подмножестве, а всего лишь дает приверженцам объектных технологий мощное средство эффективного построения физических схем БД.

Перечень основных возможностей Data Modeler включает в себя:

1. Data Modeler поддерживает большинство возможностей структурных CASE-средств в плане физического моделирования данных;

2. Data Modeler обеспечивает генерацию эффективной физической структуры БД, поддерживающей механизмы обеспечения ссылочной целостности;

3. Data Modeler тесно интегрирован с Rational Rose, а диаграмма Data Model естественным образом вписывается в общую технологию разработки ПО с использованием линейки продуктов фирмы Rational Software Corporation;

4. Можно отказаться от интеграции Rational Rose с другими средствами генерации физических моделей.

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

Создание логической модели

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

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

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

Подобные документы

Изучение теории управления образовательными учреждениями и ВУЗами. Проектирование, реализация и внедрение автоматизированной информационной системы для автоматизации кафедры ВУЗа. Описание разработанной системы, расчет экономической эффективности проекта.

дипломная работа , добавлен 09.03.2010


Изучение деятельности компании "Питер-Лада". Структура управления сети автосалонов. Унифицированный язык моделирования UML. Проектирование логической модели базы данных. Средства, используемые для построения системы учета. Расчёт эффективности инвестиций.

дипломная работа , добавлен 05.06.2011


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

курсовая работа , добавлен 26.05.2015


Проектирование функциональной структуры подсистемы "Склад". Даталогическое проектирование информационной базы данных и описание применяемых средств защиты информации. Особенности работы с NET Framework. Расчет экономической эффективности проекта.

дипломная работа , добавлен 29.06.2011


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

дипломная работа , добавлен 22.03.2017


Создание информационной системы для автоматизации деятельности компании по регистрации доставки грузов транспортной компании. Анализ предметной области. Методология функционального моделирования IDEF0. Контекстная диаграмма. Стоимостный анализ в BPwin.

контрольная работа , добавлен 05.02.2014


Понятие базы данных, модели данных. Классификация баз данных. Системы управления базами данных. Этапы, подходы к проектированию базы данных. Разработка базы данных, которая позволит автоматизировать ведение документации, необходимой для деятельности ДЮСШ.

курсовая работа , добавлен 04.06.2015


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

курсовая работа , добавлен 11.05.2014


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

курсовая работа , добавлен 07.02.2016


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

Введение 3

1. Автоматизация строительных компаний 5

1.1. Необходимость автоматизации 5

1.2. Комплексная автоматизация строительных компаний 10

Минусы комплексной автоматизации 12

Плюсы комплексной автоматизации 12

Минусы комплексной автоматизации 13

Плюсы комплексной автоматизации 13

1.3. Решения в области автоматизации 13

2. Краткий анализ деятельности компании 23

3. Предложения по автоматиизации процесса управления строительной компанией 30

Заключение 33

Библиографический список 34

Введение

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

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

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

В строительных компаниях широко применяется инженерная системотехника строительства, а именно: автоматизированные системы управления строительством (АСУС), системы автоматизированного проектирования (САПР), автоматизированные системы обработки данных и документации (АСОД) и другие, которые способствуют повышению эффективности и качества управления.

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

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

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

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

1. Автоматизация строительных компаний

1.1. Необходимость автоматизации

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

На многих стройках (особенно в Москве) АСУС функционировали довольно успешно, но в целом такие системы приживались плохо. В условиях "дефицитной" экономики получаемые решения оптимизированных задач далеко не всегда оказывались реалистичными, а большой объем распечатываемой документации обычно изучался строителями плохо. Руководители строительного производства не были готовы к столь сильной перестройке стиля своей работы. ВЦ хорошо использовались лишь для решения задач учета - составления ведомостей ресурсов, подсчета заработной платы и т.д.

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

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

По сравнению с программами "старых" АСУС АРМы обладали значительно большими возможностями, однако с программистской точки зрения они были намного сложней, и по занимаемой памяти (в килобайтах) они в десятки и даже сотни раз превышали наиболее типичные программы АСУС 70....80-х годов. Как правило, АРМы охватывают все основные задачи, решаемые соответствующим специалистом (бухгалтером, кладовщиком и проч.), однако они могут требовать привязки к условиям конкретной организации или обновления применительно к новому законодательству, новым нормам. Естественно, что такая доработка по трудоемкости несопоставимо меньше составления новых программ.

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

К концу 90-х годов автоматизация большинства строительных организаций находилась на описанном 2 этапе, т.е. на стадии использования отдельных компьютеров и АРМов.

Недостатком автоматизации данного этапа явилось несовершенство связи между отдельными АРМами и связанная с этим необходимость дублирования информации при ее "переброске" с одного компьютера на другой. По этой причине дальнейшим этаном развития автоматизированных систем стало создание на базе разрозненных АРМов единой информационной системы предприятия, охватывающей все основные сферы era деятельности. Для использования такой системы компьютеры строительной организации, а иногда и связанных с нею сторонних организаций должны объединяться в единую компьютерную сеть. При этом программное обеспечение значительно усложняется, как и усложняется сама аппаратная часть, т.е. появляется множество дополнительных, устройств, связанных с хранением и передачей информации по различным каналам связи. Возникающие текущие задачи в любой сфере деятельности могут решаться с использованием: данных всей информационной ("корпоративной") системы. Основанные на этом системы управления получили название корпоративных информационных систем (КИС). Иными словами КИС - это единая информационная система, связывающая, между собой руководство организации, ее структурные подразделения, иногда и смежные предприятия, вспомогательные службы, и охватывающая все основные сферы деятельности -бухгалтерию, материально-техническое обеспечение, общую техническую политику, текущие организационные вопросы и т.д. Это человеко-машинная система, при которой производственная, хозяйственная и финансовая стороны деятельности предприятия становятся как бы полностью "прозрачными", т.е. можно непрерывно анализировать все получаемые результаты, тенденции, положение на строительном рынке, обеспечивая этим наибольшую эффективность управления. В зарубежной практике примерно такие же функции выполняют "системы управления ресурсами" ERP.

Как и САПР, такие системы содержат множество стандартных и специализированных модулей, причем каждая конкретная система MOJKIST включать, в зависимости от требований заказчика, свои дополнительные модули и допускать их последующее расширение. КИСы обладают широкими возможностями: они могут взаимодействовать с программами САПР, в первую очередь с модулями САМ- и САЕ-систем методы обработки информации в них включают выполнение функций текстовых редакторов, электронных таблиц, баз данных и т.д. Модули CAD-систем (графические), характерные для САПРа, в системах управления имеют меньшее значение, по большую роль приобретают модули управления документооборотом (PDM-системы). Для решения хозяйственных задач используются экономико-математические модели, в первую очередь различные модели бизнес-процессов.

Обычно КИС содержит несколько подсистем охватывающих то или иное направление деятельности организации. Например, это могут быть такие подсистемы как "административное управление", "бухгалтерский учет", “оперативное управление", "управление производством" и т.д. Подсистемы содержат модули, связанны, с более конфетными видами деятельности. Например, подсистема административного управления может содержать модули:строительной компании Реферат >> Строительство

... СТРОИТЕЛЬНЫХ КОМПАНИЯХ 2.1Характеристика проектной строительной компании « АК –Марал» 2.2 Система качества в соответствии с ИСО 9000 2.2.1МС ИСО ... разработки , внедрения и функционирования систем менеджмента; - разработка ... построения, - автоматизации и новых...

Отправить свою хорошую работу в базу знаний просто. Используйте форму, расположенную ниже

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

Размещено на http://allbest.ru

1. Информационная система Apache

1.1 Описание Apache

2. Информационные системы для строительной компании

2.1 Информационная система 1С: Торговля и склад

2.1.1 Описание программы

2.1.2 Работа с распределенными информационными базами

2.1.3 Надежность и безопасность

2.1.4 Гибкость и настраиваемость

2.1.5 Интерфейс

2.1.6 Открытость и доступность

2.1.7 Работа с торговым оборудованием

2.2 Информационная система CRM

2.2.1 Автоматизация бизнес-процессов

2.2.2 Управление информацией о клиентах

2.2.3 Управление продажами

2.2.4 Управление продуктовым портфелем

2.2.5 Управление рабочим временем

2.2.6 Автоматизация документооборота

1. Информационная система Apache

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

В 1994 году сотрудник Национального центра приложений для суперкомпьютеров в Университете Иллинойса США (NCSA) Роб Маккул выложил в общее пользование первый веб-сервер, который так и назывался -- NCSA HTTP daemon. Сервер получил популярность в узких кругах, но в середине 1994 года Маккул покинул университет, и разработки прекратились.

Небольшая группа заинтересованных веб-мастеров начала совместную работу над продуктом. Общаясь в дискуссионном листе по электронной почте, они разрабатывали "заплатки" и нововведения для сервера. Именно они и создали Apache Group, разработавшую первую версию Apache-сервера. Произошло это в апреле 1995 года, когда на основу (NCSA Server 1.3) были наложены все существующие "заплатки". Так появился первый официальный публичный релиз Apache 0.6.2.

Работа над сервером не прекращалась ни на день, и очень скоро он стал одним из самых популярных. После многочисленных испытаний 1 декабря 1995 года появилась версия 1.0, устойчивая и надежная. На протяжении всех этих лет и по сей день Apache остается совершенно бесплатным. Возможно, это тоже определило успех сервера, ведь, по данным NetCraft, Apache в данный момент установлен на 67% всех серверов в мире.

1.1 Описание Apache

В данный момент параллельно развиваются две ветки Apache - версии 2.0 и 1.3. Вторая версия претерпела значительное количество изменений, которые в первую очередь коснулись ядра программы и некоторых важных модулей. Так как модули, написанные сторонними разработчиками для версии 1.3, не будут работать в версии 2.0, "старый" Apache также поддерживается. Однако если впервые установить Apache, то стоит присмотреться к новой версии.

Apache это полнофункциональный, расширяемый веб-сервер, полностью поддерживающий протокол HTTP/1.1 и распространяющийся с открытым исходным кодом. Сервер может работать практически на всех распространенных платформах. Существуют готовые исполняемые файлы сервера для Windows NT, Windows 9x, OS/2, Netware 5.x и нескольких UNIX-систем. При этом он очень прост в установке и конфигурации. Apache настраивается с помощью текстовых конфигурационных файлов. Основные параметры уже настроены "по умолчанию" и будут работать в большинстве случаев. Если возникает нехватка функциональности штатного "Апача", то стоит присмотреться к распространяемым модулям, написанным Apache Group и сторонними разработчиками. Немаловажным преимуществом является то, что создатели активно общаются с пользователями и реагируют на все сообщения об ошибках.

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

Функция посложнее, которая заложена в протоколе HTTP/1.1 - аутентификация пользователей. С помощью штатных средств сервера Apache есть возможность разграничить доступ к определенным страницам сайта для разных пользователей. Это нужно, например, для того чтобы сделать администраторский интерфейс к сайту. Для этого используются файлы.htaccess и.htpasswd, а также модули mod_auth и mod_access. Пользователи могут быть разбиты на группы, и для каждой из них можно назначить свои права доступа.

Для разделения дизайна и функциональной части сайта, а также для упрощения изменения статических объектов существует технология SSI*. Она позволяет поместить всю повторяющуюся информацию в один файл (например, top.inc), а затем вставлять в страницы ссылку на нее. Затем, если понадобится изменить несколько строк в этой информации, то придется поменять их только в одном файле. Сервер Apache поддерживает эту технологию и позволяет использовать серверные включения в полном объеме.

Если на одном сервере с установленной операционной системой семейства Unix и сервером Apache заведено несколько пользователей, то каждому из них можно создать отдельную директорию. Точнее, она будет создаваться автоматически вместе с псевдонимом. Это делается с помощью модуля mod_userdir и директивы UserDir. Так, например, можно папке public_html в домашней папке пользователя сопоставить адрес www.site.ru/~user. В общем-то, так и делается на серверах большинства сайтов, предоставляющих бесплатный хостинг. Администратор сервера может разрешить или запретить определенным пользователям создавать домашние страницы, использовать SSI и другие функции сервера. Полноценный же хостинг обычно предусматривает создание отдельного виртуального сервера для каждого пользователя.

Сервер Apache был одним из первых серверов, которые начали поддерживать виртуальные сервера (хосты). Эта возможность позволяет размещать на одном физическом сервере несколько полноценных сайтов. У каждого из них может быть свой домен, администратор, IP-адрес и так далее.

Если необходимо разместить на сервере домены domain.ru и domain.com, то для начала надо сделать так, чтобы в системе DNS им был сопоставлен IP-адрес. После этого в конфигурационном файле Apache создаете две директивы , где описываете каждый виртуальный хост. Таким образом, сервер будет знать, на какую папку "отправлять" пришедший запрос.

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

Модуль mod_cgi позволяет размещать на сервере CGI-скрипты. Это всего-навсего исполняемые файлы, написанные на одном из допустимых языков программирования. Они могут содержаться как в откомпилированном виде например, так делают, если пишут CGI на языке C++, так и в виде исходного текста если на сервере установлен Perl, то программист может помещать и такие файлы. Иногда они имеют расширение.pl.

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

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

2 . Информационные системы для строительной компании

2.1 Информационная система 1С: Торговля и склад

2.1.1 Описание программы

"1С:Торговля и склад" представляет собой компоненту "Оперативный учет" системы "1С:Предприятие" с типовой конфигурацией для автоматизации складского учета и торговли.

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

"1С:Торговля и склад" предназначена для учета любых видов торговых операций. Благодаря гибкости и настраиваемости, система способна выполнять все функции учета - от ведения справочников и ввода первичных документов до получения различных ведомостей и аналитических отчетов.

Автоматизация любых торговых и складских операций

"1С:Торговля и склад" автоматизирует работу на всех этапах деятельности предприятия.

Типовая конфигурация позволяет:

· вести раздельный управленческий и финансовый учет;

· вести учет от имени нескольких юридических лиц;

· вести партионный учет товарного запаса с возможностью выбора метода списания себестоимости (FIFO, LIFO, по средней);

· вести раздельный учет собственных товаров и товаров, взятых на реализацию;

· оформлять закупку и продажу товаров;

· производить автоматическое начальное заполнение документов на основе ранее введенных данных;

· вести учет взаиморасчетов с покупателями и поставщиками, детализировать взаиморасчеты по отдельным договорам;

· формировать необходимые первичные документы;

· оформлять счета-фактуры, автоматически строить книгу продаж и книгу покупок, вести количественный учет в разрезе номеров ГТД;

· выполнять резервирование товаров и контроль оплаты;

· вести учет денежных средств на расчетных счетах и в кассе;

· вести учет товарных кредитов и контроль их погашения;

· вести учет переданных на реализацию товаров, их возврат и оплату.

В "1С:Торговля и склад" вы можете:

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

Работать со взаимосвязанными документами;

Выполнять автоматический расчет цен списания товаров;

Быстро вносить изменения с помощью групповых обработок справочников и документов;

Вести учет товаров в различных единицах измерения, а денежных средств - в различных валютах;

Получать самую разнообразную отчетную и аналитическую информацию о движении товаров и денег;

Автоматически формировать бухгалтерские проводки для 1С:Бухгалтерии.

apache информационный программа автоматизация

2.1.2 Работа с распределенными информационными базами

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

· ведение неограниченного количества автономно работающих информационных баз;

· полная или выборочная синхронизация данных;

· настройка состава синхронизируемых данных;

· произвольный порядок и способ передачи изменений;

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

Компонента "Управление распределенными информационными базами" поставляется отдельно

2.1.3 Надежность и безопасность

"1С:Торговля и склад" содержит средства обеспечения сохранности и непротиворечивости информации:

· возможность запрещения пользователям "прямого" удаления информации;

· специальный режим удаления данных с контролем перекрестных ссылок;

· возможность запрещения пользователям редактировать данные за прошлые отчетные периоды;

· установка запрета на редактирование печатных форм документов;

· "запирание" системы пользователем при временном прекращении работы.

2.1.4 Гибкость и настраиваемость

"1С:Торговля и склад" может быть адаптирована к любым особенностям учета на конкретном предприятии.

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

· редактировать существующие и создавать новые необходимые документы любой структуры

· изменять экранные и печатные формы документов

· создавать журналы для работы с документами и произвольно перераспределять документы по журналам для эффективной работы с ними

· редактировать существующие и создавать новые справочники произвольной структуры

· редактировать свойства справочников:

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

2.1.5 И нтерфейс

"1С:Торговля и склад" следует современным стандартам пользовательского интерфейса:

- "советы дня" подскажут вам эффективные приемы работы и удобные возможности системы

Служебные окна умеют "прикрепляться" к границам главного окна программы

Главное меню системы содержит "образы" команд - такие же образы помещены на кнопках панелей инструментов

кнопки панелей инструментов могут быть обозначены не только рисунками, но и текстом.

2.1.6 Открытость и доступность

"1С:Торговля и склад" содержит разнообразные средства для связи с другими программами.

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

Кроме этого, встроенный язык содержит средства работы с файлами формата DBF.

Также "1С:Торговля и склад" поддерживает современные средства интеграции приложений: OLE, OLE Automation и DDE. Использование этих средств позволяет:

· управлять работой других программ, используя встроенный язык "1С:Торговля и склад", - например, формировать отчеты и графики в Microsoft Excel

· получать доступ к данным "1С:Торговля и склад" из других программ

вставлять в документы и отчеты "1С:Торговля и склад" объекты, созданные другими программами - например, помещать в первичные документы логотип фирмы

· размещать в документах и отчетах рисунки и графики.

В "1С:Торговля и склад" реализована поддержка открытых стандартов: обмена коммерческой информацией (CommerceML) и обмена платежными документами (1С:Предприятие - Клиент банка).

Это дает возможность: формировать и выгружать коммерческие предложения на Web - витрины, поддерживающие стандарт организовывать электронный обмен каталогами, прайс-листами и документами со своими контрагентами обмениваться платежными документами (платежными поручениями и выписками) с системами Клиент - банка 1С:Торговля и Склад интегрирована с базой данных Ассоциации ЮНИСКАН/EAN Россия.

2.1.7 Работа с торговым оборудованием

"1С:Торговля и склад" обеспечивает работу с торговым оборудованием: контрольно-кассовыми машинами, чековыми принтерами, сканерами и принтерами штрих-кодов, электронными весами, терминалами сбора данных, дисплеями покупателя и другими видами оборудования.

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

Дополнительные компоненты и методики работы с торговым оборудованием поставляются отдельно.

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

В данной работе рассматривается строительная компания в которой организованно 40 рабочих мест, средняя стоимость одного рабочего места на 2016 год с установкой, внедрением и приобретением ключей к рабочему месту составляет ~ 17,5 тыс. рублей

2.2 Информационная система CRM

Существуют разночтения концепции CRM (Customer Relationship Management): кто-то под этим буквосочетанием видит методологию ведения бизнеса, а кто-то -- программное обеспечение для автоматизации работы с клиентами. И те, и другие правы. Но расставим правильные акценты.

CRM -- это стратегия . Термин Customer Relationship Management можно перевести на русский язык как «управление взаимоотношениями с клиентами».

Этот буквальный перевод вполне соответствует истине, но не рисует очевидной картины.

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

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

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

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

Управлять взаимоотношениями означает привлекать новых клиентов, нейтральных покупателей превращать в лояльных клиентов, из постоянных клиентов формировать бизнес-партнеров.

CRM-система -- это воплощение автоматизации CRM-стратегии. Очень важную роль в воплощении CRM-стратегии в жизнь играют информационные технологии.

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

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

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

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

2.2.1 Автоматизация бизнес-процессов

Разложить все рабочие процессы по полочкам, формализовать их -- нетривиальная задача, решаемая бизнес-аналитиками.

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

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

Эти задачи могут быть решены с помощью автоматизации процессов, с использованием CRM-системы.

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

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

Обеспечивая автоматизацию и оперативный контроль хода выполнения бизнес-процессов компании, CRM-система повышает вероятность их своевременного и качественного исполнения.

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

2.2.2 Управление информацией о клиентах

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

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

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

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

2.2.3 Управление продажами

Главная функция CRM-системы - помогать менеджерам планировать продажи, организовывать прозрачное управление сделками и оптимизировать каналы продаж.

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

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

Руководители предъявляют особые требования к CRM. С помощью инструментов CRM-системы руководители могут контролировать качественные показатели работы менеджеров (воронка продаж), выполнение планов продаж, соблюдение сроков оплаты и поставки.

Система позволяет оценивать объем и вероятность сделок, управлять бизнес-процессами продаж, следить за состоянием сделки и анализировать действия конкурентов.

Одна из важнейших задач, которую помогает решить CRM-система, -- организация cross-sales, up-sales.

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

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

2.2.4 Управление продуктовым портфелем

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

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

2.2.5 Управление рабочим временем

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

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

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

Генерация 80% задач автоматически по бизнес-процессу позволяет освободить сотрудников от рутинных операций, наиболее рационально распределяя рабочее время, и не забыть ни об одном важном деле.

2.2.6 Автоматизация документооборота

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

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

2.2.7 Аналитические возможности программы CRM

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

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

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

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

Размещено на Allbest.r

Подобные документы

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

курсовая работа , добавлен 29.04.2015


Создание автоматизированной системы учета заказов и их выполнения в строительной фирме по ремонту квартир. Общие требования к информационной системе. Проектирование структуры базы данных. Построение ER-диаграммы. Реализация информационной системы.

курсовая работа , добавлен 24.03.2014


Описание структуры управления компании. Структура программно-аппаратных средств. Анализ технического задания. Расчет обобщенного критерия эффективности информационной системы ведения проектов строительной компании. Выбор языка программирования и СУБД.

дипломная работа , добавлен 29.06.2013


Программные продукты компании Microsoft: Access, Visual FoxPro7.0, dBASE. Возможности интеграции, совместной работы и использования данных. Системы управления базами данных (СУБД), их основные функции и компоненты. Работа с данными в режиме таблицы.

курсовая работа , добавлен 15.12.2010


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

дипломная работа , добавлен 20.12.2012


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

презентация , добавлен 14.10.2013


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

контрольная работа , добавлен 16.11.2010


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

курсовая работа , добавлен 31.03.2010


Определение CRM как информационной системы, назначением которой является автоматизация бизнес-процессов компании, обеспечивающих взаимодействие всех ее подразделений с клиентами. Классификация систем: оперативные, аналитические и коллаборационные.

курсовая работа , добавлен 05.06.2014


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