Рис. 5           - Организационная структура ООО «Анелик»

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

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

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

-                   Участие в тендерах, которые размещают заказчики, в том числе государственные и муниципальные органы;

-                   Разработка принципов ценообразования на готовые к продаже объекты туристической недвижимости;

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

-                   Эксплуатация объектов туристической недвижимости (техническое и технологическое обеспечение), оставленных на балансе предприятия.

Департамент Эксплуатации непосредственно взаимодействует с Департаментом Аренды в части передачи последнему объектов туристической недвижимости для предоставления таких объектов частным и корпоративным нанимателям на краткосрочный и долгосрочный период. В данном случае Департамент Аренды выступает посредником между ООО «Анелик» как собственником объектов туристической недвижимости и клиентами – потенциальными нанимателями.

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

Преимущества представленной матричной организационной структуры ООО «Анелик»:

-                   высокая гибкость;

-                   сокращение численности управленческого персонала по сравнению с иерархическими структурами.

Недостатки представленной матричной организационной структуры ООО «Анелик»:

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

-                   дробление ресурсов между проектами;

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

-                   усложнение процесса развития организации как единого целого.

Вывод: преимущества перевешивают недостатки на предприятиях с небольшим числом одновременно выполняемых проектов.

Далее рассмотрим основные финансово-экономические показатели предприятия за 2007 – 2008 гг.

Очевидно, что за исследуемый период предприятие увеличило свою выручку на 14,2%, при этом валовая прибыль и прибыль от продаж показали наименьший темп прироста 8,6% и 1,2% соответственно. Связано это в первую очередь с ростом затрат предприятия.




    Таблица 4   Анализ финансовых результатов ООО «Анелик», за 2007 – 2008 гг.

Показатель	2007 год	2008 год	(+,-)	в %
выручка-нетто	7764770	8867841	1103071	14,2
валовая прибыль	4278757	4648046	369289	8,6
прибыль от продаж	1499456	1517806	18350	1,2
прибыль до налогообложения	1141368	1540517	399149	35,0
чистая прибыль	780672	1139357	358685	45,9

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

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

Очевидно, что за исследуемый период у исследуемого предприятия эффективность его деятельности имеет тенденцию к росту – т.к. 4 показателя из 6 возможных имеют положительную динамику, кроме этого нужно обратить внимание на то, что два показателя, а именно рентабельность активов и операционная рентабельность показывают темп роста, превышающий 10% (13,6% и 18,2% соответственно).

Имеются два отрицательных момента – это снижение рентабельности продаж на 11,4%, что связано с ростом затрат, и снижение рентабельности инвестиций до налогообложения, что связано с меньшим темпом роста операционной прибыли по сравнению с чистой прибылью.




    Таблица 5   Анализ показателей рентабельности ООО «Анелик», за 2007 – 2008 гг.

Показатель	2007 год	2008 год	(+,-)	в %
Рентабельность продаж	19,31	17,12	-2,2	-11,4
Операционная рентабельность	14,70	17,37	2,7	18,2
Чистая рентабельность	10,05	12,85	2,8	27,8
ROI (рентабельность инвестиций) до налогообложения	44,40	44,05	-0,4	-0,8
ROI после налогообложения	30,37	32,58	2,2	7,3
ROE (рентабельность собственного капитала)	30,37	32,58	2,2	7,3
ROA (рентабельность текущих активов)	29,20	33,18	4,0	13,6

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

Весь документооборот Департамента Строительства и Департамента Эксплуатации реализован в единой корпоративной информационной системе (КИС) на платформе SAP ERP. Для промышленных и строительных предприятий система SAP выглядит более привлекательной из-за большого охвата бизнес-функций, наличия множества отраслевых решений, возможности совместной работы с существующим конструкторско-техническим программным обеспечением. Система SAP – это инструмент дисциплинированного пользователя, что психологически подходит для персонала предприятий уровня ООО «Анелик», т.к. это проектноориентированное предприятие с жёсткой дисциплиной и унифицированными правилами работы и поведения.

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

1.3.2Характеристика и анализ базовых бизнес-процессов

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

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

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

            Рис. 6           - Бизнес-направления Департамента Аренды ООО «Анелик»

-                   Выявление потребностей потенциальных клиентов (уровень класса объекта, географическое расположение, ценовая категория объекта);

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

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

-                   Пакет документов предоставляется клиенту, после подписания договора найма завершения всех организационных моментов по передаче объекта клиенту, сотрудники клиентского отдела ставят сделку на мониторинг;

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

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

-                   Финансовый и бухгалтерский отдел Департамента Аренды учитывает доходы и расходы, произведенные Департаментом;

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

-                   Менеджер по персоналу Департамента Аренды занимается поиском, побором, отбором и обучением персонала, по заявкам от руководителей клиентских отделов;

-                   Системный администратор обеспечивает:

ü                обслуживание автоматизированной системы управления в финансовом и бухгалтерском отделе;

ü                обслуживание корпоративной сети в Департаменте Аренды;

ü                техническую поддержку и поддержку пользователей Департамента Аренды;

ü                взаимодействие с отделом IT Департамента Эксплуатации.

Управленческие бизнес-процессы в Департаменте Аренды состоят в следующем:

-                   стратегическое планирование деятельности Департамента, которое осуществляет руководитель Департамента совместно с руководителями клиентских отделов;

-                   для определения сценариев развития руководитель Департамента Аренды непосредственно взаимодействует с руководителем Департамента Эксплуатации, который предоставляет данные о объект готовых с сдаче и остающихся на балансе ООО «Анелик»;

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

Бизнес-процессы развития (выполняются согласно стратегическому плану развития Департамента Аренды, исполнители – руководители и сотрудники клиентских отделов):

-                   Поиск и развитие клиентской базы;

-                   Заключение договоров о намерениях с корпоративным сектором;

-                   Разработка программ повышения лояльности корпоративных и частных клиентов;

-                   Разработка индивидуального плана сотрудничества с постоянными корпоративными и частными клиентами.

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

1.3.3 Выявление причин, обуславливающих необходимость автоматизации отдельных бизнес-процессов

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

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

                  I.                        поступил запрос (заявка) от клиента

               II.                        запрос регистрируется руководителем клиентского отдела на бумажном носителе в журнале регистраций, далее поступивший запрос передается:

a.                 в обработку заказов – продолжение основного бизнес-процесса (выписывается наряд-заказ сотруднику)

b.                в планирование – т.е. в обеспечивающие и управленческие бизнес-процессы (выписывается заявка на пакет документов)

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

            IV.                        данные запроса переходят к сотруднику, который назначается ответственным за выполнение заказа

               V.                        Сотруднику передается наряд-заказ на выполнение, в журнале регистрации напротив поступившего заказа указывается ответственный сотрудник.

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

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

Объекты уже сданные, по которым идет мониторинг, составляют в среднем 35% от общего ежемесячного экспозиционного количества объектов (т.е. от 42 до 45 объектов).

Количество сотрудников клиентских отделов, которые непосредственно занимаются предоставлением объектов в аренду, составляет в корпоративном клиентском отделе: 4 человека + 1 руководитель, в отделе, работающим с частными лицами: 3 человека +1 руководитель. Общее количество операционного персонала 7 человек, управленческого персонала 2 человека.

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

-                   Общение с клиентами занимает в среднем у сотрудников клиентского отдела ј рабочего дня или в среднем 90 – 100 мин.;

-                   Выезд с клиентом на объект занимает не менее ј рабочего дня или в среднем до 120 мин;

-                   Подготовка документации и оформление договоров занимает в среднем 50 – 60 мин. в день;

-                   Составление и предоставление отчетности занимает не менее ј рабочего времени или в среднем до 120 мин.

Таким образом, сотрудники клиентского отдела при существующем неавтоматизированном документообороте тратят от 65% до 80% своего рабочего времени не на основные, но на обеспечивающие виды деятельности. Далее проанализируем показатели производительности труда сотрудников департамента аренды (табл. 6). На производительность труда влияют следующие факторы: удельный вес (Уд) операционного персонала в общей численности персонала, количества отработанных дней одним операционным сотрудником за год (Д), продолжительности рабочего дня (П), среднечасовой выработки рабочих (ЧВ).

Первый и очевидный момент – эффективность деятельности Департамента Аренды снижается, т.к. выручка от реализации услуг сократилась на 8,7% за 2008 год. Но указанное снижение зависит не только внутренних, но и от внешних факторов – на снижение выручки также влияет объем снижения платежеспособного спроса на услуги, которые предоставляет Департамент Аренды.


    Таблица 6   Анализ производительности труда в Департаменте Аренды ООО «Анелик», за 2007 – 2008 гг.

Показатель	2007 год	2008 год	(+,-)	%
среднегодовая численность персонала Департамента Аренды	41	59	18,0	43,9
среднегодовая численность операционного персонала (ЧР)	24	28	4,5	19,1
удельный вес операционного персонала в общей численности (Уд)	0,58	0,48	-0,1	-17,2
отработано одним рабочим дней за год (Д)	215	216	1,0	0,5
отработано часов всеми сотрудниками	38857	51995,5	13139,0	33,8
средняя продолжительность рабочего дня (П), ч	7,6	8,5	0,9	11,8
реализовано услуг, тыс. руб.	25489	23276	-2213,0	-8,7
выработка на одного операционного сотрудника
среднегодовая (ГВ), тыс. руб.	1071,9	821,9	-250,0	-23,3
среднедневная (ДВ), тыс. руб.	118,6	107,8	-10,8	-9,1
среднечасовая (ЧВ), тыс. руб.	15,6	12,7	-2,9	-18,7
∆ГВуд = ∆Уд*Д0*П0*ЧВ0, тыс. руб.	-2548,9
∆ ГВд = Уд1*∆Д*П0*ЧВ0, тыс. руб.	56,9
∆ГВп = Уд1*Д1*∆П*ЧВ0, тыс. руб.	1455,6
∆ГВчв = Уд1*Д1*П1*∆ЧВ, тыс. руб.	-2574,7

Следующие отрицательные факторы влияния, которые снизили производительность труда персонала в Департаменте Аренды:

-                   Отрицательное влияние оказало на выработку одного операционного сотрудника сокращение удельного веса данной категории в общей численности персонала (стоимость фактора влияния -2548,9 тыс. руб.);

-                   Также отрицательное влияние оказало сокращение среднечасовой выработки при увеличении средней продолжительности рабочего дня (стоимость фактора влияния -2574,7 тыс. руб.).

Очевидно, что увеличение фактически отработанного времени в 2008 году связано в основном с отсутствием автоматизации деятельности в целом Департамента Аренды и отсутствием автоматизации документооборота в частности.

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

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

Кроме указанных выше основных причин, обуславливающих необходимость автоматизации документооборота в Департаменте Аренды, имеются следующие причины:

-                   Повышение уровня взаимодействия сотрудников Департамента Аренды (т.к. многие бизнес-процессы пересекаются и взаимосвязаны);

-                   Повышение уровня взаимодействия между сотрудниками Департамента Аренды и Департамента Эксплуатации (т.к. именно Департамент Эксплуатации предоставляет объекты туристической недвижимости Департаменту Аренды);

-                   Установление оперативной обратной связи между сотрудниками как внутри Департамента Аренды, так и вне его.

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

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




Глава 2. Выбор программного обеспечения
2.1 Проектирование архитектуры АСУ
Методологические аспекты при формировании автоматизированной системы документооборота предприятия базируются на следующих принципах: комплексность или системность, непрерывность, законность, плановость, экономичность, сочетание гласности и конфиденциальности[6].

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

-                   сокращения площадей, на которых хранится информация;

-                   уничтожения малоэффективных бумажных документов;

-                   более компактного хранения бумажных документов;

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

-                   увеличения скорости поиска и доступа к необходимым документам.

Существуют оценки, что до 90% времени сотрудников тратится на так называемую обеспечивающую функцию, а именно на поиск необходимых для работы документов[7]. Это проблема усугубляется при коллективном использовании документов, когда надо найти документы, созданные другим сотрудником, и наконец, она становится практически невыполнимой в том случае, если организация является территориально-распределенной. Соответственно существует возможность практически на порядок повысить:

-                   эффективность сотрудников;

-                   сократить расходы на копирование, канцелярские принадлежности и т.п.;

-                   сократить время на передачу документов между исполнителями.

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

Первоначально рассмотрим общие требования к системе автоматизированного документооборота[8]:

                  I.                        Масштабируемость

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

               II.                        Распределенность

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

            III.                        Модульность

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

            IV.                        Открытость

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

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

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

Второй подход носит название работо-ориентированный и его основным объектом является работа. К работе может быть прикреплен самый разнообразный список объектов, в том числе, и документы. Естественно, работа может существовать и без документов. Второй подход является более общим. Рассмотрим теперь типы систем маршрутизации[10] (приложение 3).

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

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

Свободная маршрутизация документов с контролем исполнения. Под контролем исполнения понимается следующая функциональность:

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

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

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

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

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

-                   История выполнения заданий.

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

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

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

-                   комбинированные из последовательных и параллельных элементов;

-                   условные, с переходами в зависимости от состояния тех или иных переменных маршрутов.

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

Таким образом, определив основные требования к системе документооборота, далее рассмотрим собственно требования к архитектуре проектируемой АСУ.

Уровень развития информационных технологий на сегодняшний день при построении автоматизированных систем управления позволяет выбрать архитектуру из достаточно широкого спектра. При проектировании разрабатываемой системы рассматривались различные архитектуры построения информационных систем.[11]

Важнейшим параметром для проектируемой АСУ является быстродействие (даже в случае значительного увеличения количества пользователей), а также надежность, масштабируемость и безопасность. Всё это обеспечивает архитектура «клиент-сервер». Такая архитектура позволяет оптимально распределить работу между клиентскими и серверной частями системы: теперь приложение, работающее на рабочей станции, не читает записи базы данных «напрямую», а посылает запросы на сервер, где они принимаются и последовательно отрабатываются специальными программами. В результате на рабочую станцию поступают только обработанные данные, что радикально сокращает информационные потоки в ЛВС[12].

Итак, проектируемая АСУ является клиент-серверной системой. С организационной точки зрения архитектура АСУ содержит две основные подсистемы:

1.                 Система хранения информации (сервер базы данных)

2.                 Клиентская часть.

Одним из главных факторов, влияющих на принятие решения о создании информационных систем в архитектуре «клиент-сервер», является потенциальная возможность повышения производительности работы пользователей, особенно в тех случаях, когда находящиеся в эксплуатации приложения не удовлетворяют требованиям, предъявляемым к скорости обработки данных ввиду их большого объема, а также высокой интенсивности и сложности запросов.[13] Известно, что информационные системы, основанные на архитектуре «клиент-сервер», могут обладать существенными преимуществами перед информационными системами, базирующимися на сетевых версиях настольных СУБД, такими, как существенно меньший сетевой трафик, меньшее время обработки запросов, меньшая ресурсоемкость клиентских приложений и меньшие трудозатраты при их разработке.

Определим цели, задачи, решаемые проектируемой АСУ (табл. 7). Очевидно, что цели и задачи, которые решает автоматизация документооборота на каждом следующем уровне увеличивает её фактическую стоимость, что является немаловажным фактором в настоящее время, при этом важно отметить, что инвестиции в автоматизацию, как отдельных элементов документооборота, так и в полную автоматизацию бизнес-процессов определяются усиливающейся турбулентностью бизнес-среды. По мнению многих исследователей[14] в условиях высокой турбулентности бизнес-среды эффективность неавтоматизированных бизнес-процессов резко снижается, увеличивает скрытые и явные потери предприятий и организаций. Оптимизация бизнес-процессов, а в отдельных случаях и реинжиниринг в современном развитии бизнеса сложно представить без использования современных IT, которые автоматизируют процессы управления, оптимизируют и повышают эффективность деятельности предприятий.


Таблица 7. Цели и задачи, решаемые Автоматизированной системой управления документооборотом

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

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

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

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

a.                 рост стоимости труда;

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

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

2.2 Проектирование архитектуры баз данных (БД)

Для того, чтобы непосредственно перейти к проектированию архитектуры баз данных необходимо четко основные цели, которые достигаются с помощью автоматизированной системы управления документооборотом. Целью внедрения автоматизации документооборота является[16]:

-                   Удешевление бизнес-процессов, временных затрат на осуществление операций персоналом предприятия

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

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

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

-                   Обеспечение возможности сбора статистической и аналитической информации о скорости и своевременности исполнения этапов бизнес-процессов

-                   Обеспечение возможности постепенного расширения автоматизированных процессов, а также возможностей их модификации по мере изменения процессов

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

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

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

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

На сегодняшний день можно выделить следующие модели данных:[18]

-                   иерархическая;

-                   сетевая;

-                   реляционная;

-                   постреляционная;

-                   многомерная;

-                   объектно-ориентированная.

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

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

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

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

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

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

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

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

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

Таблица имеет строки (записи) и столбцы (колонки). Каждая строка таблицы имеет одинаковую структуру и состоит из полей. Строкам таблицы соответствуют кортежи, а столбцам - атрибуты отношения.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

-                   Отчет «Клиенты»

-                   Отчёт «Объекты»

-                   Отчет «Количество объектов, сданных за период»

-                   Отчёт «Срок экспозиции объекта»

В отчет «Клиенты» должна быть включена информация:

-                   Наименование клиента

-                   Дата подачи заявки

-                   Категория желаемого объекта

-                   Тип взаиморасчетов

-                   Цена услуг

-                   Ответственный сотрудник

В отчёт «Объекты» должна быть включена информация:

-                   Наименование

-                   Дата постановки в базу

-                   Категория объекта

-                   Цена

-                   Отметка о статусе (сдан/не сдан/резерв/оформление)

-                   Ответственный сотрудник

В отчёт «Объекты, сданные за период» должна быть включена информация:

-                   Количество сданных объектов по категориям

-                   Тип взаиморасчётов (нал/безнал)

-                   Общий приход денежных средств по объектам за период

-                   Дебиторская задолженность

В отчёт «Сроки экспозиции объектов» должна быть включена информация:

-                   Наименование объекта

-                   Категория объекта

-                   Дата постановки объекта в базу

-                   Период присутствия в базе

-                   Цена

-                   Ответственный сотрудник.

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

2.3 Выбор средств, архитектуры для АСУ. Требования к аппаратному обеспечению

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

Использование архитектуры клиент-сервер:

1.                 резко уменьшает сетевой трафик;

2.                 понижает сложность приложений-клиентов (поскольку тем уже нет необходимости обеспечивать целостность и безопасность БД и следить за параметрами многопользовательской работы с БД);

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

4.                 повышает надежность БД, ее целостность, безопасность и секретность.

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

-                   распространенность реляционной модели;

-                   практически любой специалист в области информационных технологий знаком с теорией и практикой реляционных БД;

-                   поддержка реляционной модели большинством СУБД.

В качестве среды разработки для клиентской части АСУ используется среда разработки C++ Builder 6, разработка компании Borland. С++ Builder относится к системам визуального проектирования, называемым также системами RAD. Разработка приложения в C++ Builder два взаимосвязанных этапа:[21]

-                   создание пользовательского интерфейса приложения;

-                   определение функциональности приложения.

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

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

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

При разработке АСУ документооборотом использовались следующие основные факторы выбора средств реализации:

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

-                   удобный графический интерфейс;

-                   надежность и возможность работы в сетевом режиме;

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

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

-                   открытость – настройка на входные документы, логистику расчетов, отчетных документов;

-                   не высокое требование к аппаратным ресурсам при разработке программного обеспечения.

В качестве СУБД для проектируемой АСУ выбрана система MS SQL Server. Эта СУБД, создана компанией Microsoft и является в настоящее время одной из самых распространённых, кроме этого предлагаемая СУБД фактически в настоящее время является стандартом в области хранения данных[22]. Отличительные качества:

-                   Высокая производительность и надёжность при минимальных требованиях к техническим средствам;

-                   Высокая масштабируемость;

Структура сети представлена в приложении 4.

Требования к аппаратному обеспечению определяются требованиями к используемым операционным системам и серверным продуктам (Windows XP Professional, Windows 2003 Server, SQL Server 2005)[23]:

Требования к серверу

                  I.                        Процессор, совместимый с Pentium III или выше;

               II.                        Жесткий диск – 2 ГБ свободного места при установке полного пакета

            III.                        Память – 512 МБ.

Требования к рабочей станции:

                  I.                        Процессор Pentium с частотой 233 МГц или более быстрый (рекомендуется не менее 300 МГц)

               II.                        Не менее 64 МБ оперативной памяти (рекомендуется не менее 128 МБ)

            III.                        Не менее 1,5 ГБ свободного места на жестком диске

            IV.                        Необходимо наличие дисковода CD–ROM для инсталляции Системы.

Локальная вычислительная сеть

Для локальной вычислительной сети отметим необходимость использования подсоединения рабочих станций при помощи витых пар с пропускной способностью не менее 10Мбит с протоколом TCP/IP.

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




Глава 3. Разработка технического задания
3.1 Разработка базы данных
Целью разработки любой базы данных является хранение и использование информации о какой-либо предметной области. Для реализации этой цели имеются следующие инструменты:

-                   Реляционная модель данных - удобный способ представления данных предметной области.

-                   Язык SQL - универсальный способ манипулирования такими данными.

Очевидно, что для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Далее определим критерии качественности базы данных[24]:

-                   Адекватность базы данных предметной области;

-                   Легкость разработки и сопровождения базы данных;

-                   Скорость выполнения операций обновления данных (вставка, обновление, удаление кортежей);

-                   Скорость выполнения операций выборки данных.

База данных должна адекватно отражать предметную область. Это означает, что должны выполняться следующие условия[25]:

1.                 Состояние базы данных в каждый момент времени должно соответствовать состоянию предметной области.

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

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

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

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

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

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

База данных проектируемой Автоматизированной Системы Управления документооборотом Департамента Аренды (далее и везде АСУ Департамента Аренды) содержит 3 основных таблицы (Clients, Objects, Operations) на основании которых можно получить полную информацию по требуемым отчётам.

Таблица «Clients» является хранилищем информации о клиентах, обратившихся с заявками в Департамент Аренды, структура таблицы «Clients» приведена ниже.


    Таблица 7   Структура таблицы «clients»

Название поля	Тип	Описание поля
docid	integer	Номер документа
clientid	integer	Идентификатор клиента
clientname	varchar (150)	Наименование клиента
objectkat	char	Требуемая категория объекта (А, Б, В)
clientinput	datetime	Дата заявки
clientprice	integer	Цена
clientstatus	char	Отметка: заявка в работе/заявка на оформлении/заявка выполнена
clientmanager	varchar(40)	Ответственный сотрудник (исполнитель операции)

Внесем необходимые пояснения по описанию:

-                   Идентификатор клиента это уникальный индивидуальный номер клиента, под которым он внесен в базу данных;

-                   Наименование клиента по юридическому статусу (ООО либо ОАО/ЗАО в случае если клиент корпоративный), либо имя клиента, в том случае если клиент – частное лицо;

-                   Требуемая категория объекта и цена: в данном случае указывается, какой именно категории объект и по какой цене интересует клиента;

-                   Дата заявки – фактический день обращения клиента в Департамент Аренды;

-                   Отметка описывает процесс работы с клиентом (заявка в работе – клиенту предложены объекты из категории, идет практический выбор объекта; заявка в оформлении – клиент определил объект, идет оформление сопроводительной документации; заявка выполнена – сопроводительные документы оформлены, счет за услуги оплачен/оплачивается);

-                   Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, назначенного к данному клиенту руководителем клиентского отдела.

«Objects» – таблица служит хранилищем информации об объектах недвижимости, которые имеются в каталоге Департамента Аренды, структура таблицы «Objects» приведена ниже.
    Таблица 8   Структура таблицы «obects»

Название поля	Тип	Описание поля
docid	integer	Номер документа
objectid	integer	Идентификатор объекта
objectname	varchar (150)	Наименование объекта
objectkat	char	Категория объекта (А, Б, В)
objectinput	datetime	Дата постановки объекта в базу
objectprice	integer	Цена
objectstatus	char	Отметка: сдан/не сдан/резерв/оформляется
objectmanager	varchar(40)	Ответственный сотрудник (исполнитель операции)

Внесем необходимые пояснения по описанию:

-                   Идентификатор объекта это уникальный индивидуальный номер объекта, под которым он внесен в базу данных;

-                   Наименование объекта – фактическое название объекта;

-                   Категория объекта вносится в соответствие с принятой градацией объектов недвижимости (категория А – объекты, стоимость аренды которых составляет от 1 млн. руб.; категория В – объекты, стоимость аренды которых составляет от 500 тыс. руб. до 1 млн. руб.; категория С – объекты, стоимость аренды которых составляет до 500 тыс. руб.);

-                   Дата постановки объекта в базу – фактический день внесения объекта в базу;

-                   Цена – фактическая стоимость аренды объекта, определенная Департаментом Эксплуатации;

-                   Отметка описывает процесс работы с объектом аналогично отметке по клиенту;

-                   Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, за которым закреплен конкретный объект руководителем клиентского отдела.

«Operations» - таблица содержит информацию обо всех сделках с объектами недвижимости и клиентами за определенный период.

Внесем необходимые пояснения по описанию:

-                   Идентификатор объекта или клиента – уникальный номер, присваиваемый объекту или клиенту при внесении в базу;

-                   Дата совершения операции – фактический день заключения договора аренды с клиентом;

-                   Отметка расчета по операции ставится исходя из фактических расчетов уже произведенных клиентом (наличные денежные средства либо безналичные), в том случае если клиент не оплатил выставленный счет, ставится отметка «не определен»;
    Таблица 9   Структура таблицы «Operations»

Название	Тип	Описание поля
docid	integer	Номер документа
objectid/clientid	integer	Идентификатор объекта или клиента
operationdate	datetime	Дата совершения операции
operationcurrency	char	Расчёт по операции (нал, безнал, не определён)
operationincome	integer	Приход денежных средств
operationdebt	integer	Дебиторская задолженность
operationmanager	varchar(40)	Ответственный сотрудник (исполнитель операции)

Приход денежных средств отражает фактическую суммы оплаты счета клиентом;

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

-                   Ответственный сотрудник – фамилия ответственного сотрудника Департамента Аренды, за которым закреплен конкретный объект или клиент руководителем клиентского отдела.

Связь таблиц 8, 9 и 10 осуществляется по ключевому полю docid*, slitset таблица срезов, которые указывают на один аналитический счет в таблице account (ключ id). Программный код файла data.cpp, который отвечает за выполнение операций исполнения документов и функционирование АСУ Департамента Аренды в целом приведен в приложении А.

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

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

Сотрудники, ежедневно просматривая Журнал заявок, отбирают новых клиентов, закрепленных за ними. Формирование предложения идет на основании прайс-листа Департамента Аренды, который формируется в АСУ по категориям объектов и предлагается для изучения непосредственно клиенту.

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

После того, как клиент определил необходимый ему объект и готов заключить сделку, ответственный операционный сотрудник проставляет необходимые отметки в АСУ, как в Журнале клиентов, так и в Объектах (см. табл. 8 и 9 описание полей «отметка»), кроме этого, ответственный сотрудник предоставляет клиенту пакет документов по сделке, в соответствие с правилами заключения сделок и условиями договора клиенту выставляется счет или счет-фактура на оплату услуг Департамента Аренды, при этом также проставляются необходимые отметки в АСУ.

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

3.2 Разработка интерфейса пользовательской части

Прежде чем перейти непосредственно к разработке пользовательского интерфейса (ПИ), определим основные требования, предъявляемые к разработке интерфейса пользователя.

Разработка пользовательского интерфейса (ПИ) ведется параллельно разработке архитектуры Автоматизированной Системы Управления документооборотом и разработке баз данных в целом и в основном предшествует её имплементации. Процесс разработки ПИ разбивается на этапы жизненного цикла[26]:

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

2.                 Построение пользовательской модели данных, привязка объектов к ролям и формирование рабочих мест.

3.                 Формулировка требований к работе пользователя и выбор показателей оценки пользовательского интерфейса.

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

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

6.                 Разработка макетов и прототипов ПИ и их оценка в деловой игре, выбор окончательного варианта.

7.                 Имплементация ПИ, создание тестовой версии.

8.                 Разработка средств поддержки пользователя (пользовательские словари, подсказки, сообщения, помощь и пр.) и их встраивание в АСУ.

9.                 Usability тестирование тестовой версии ПИ по набору раннее определенных показателей.

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

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

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

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

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

-                   Какая информация необходима пользователю для решения задачи? (для операционных сотрудников основная информация заключается в данных по новым заявкам клиентов и фактического состояния каталога объектов; для руководителей клиентских отделов наиболее важна информация для составления отчетности: движение объектов и клиентов в базе);

-                   Какую информацию пользователь может игнорировать (не учитывать)? (соответственно операционные сотрудники могут не учитывать информацию за прошедший период, их интересует только фактическое состояние клиентов и объектов в базе данных; в свою очередь руководители клиентских отделов при стратегическом планировании о составлении отчетности могут игнорировать информацию о состоянии «сегодняшнем дне», для оперативного контроля руководителям клиентских отделов не обязательно учитывать информацию за прошедший период);

-                   Какие решения пользователю необходимо принимать в процессе работы с АСУ? (в данной части решения строятся как по стратегическому планированию, так и по оперативному планированию – рядовые сотрудники принимают только оперативные решения текущего характера, руководители клиентских отделов принимают как оперативные, так и стратегические решения);

-                   Может ли пользователь совершать несколько различных действий одновременно? (в данной части необходимо отметить, что проектируемая АСУ дает возможность решать несколько задач одновременно, следовательно, ответ на данный вопрос – положительный);

-                   Какие типовые операции использует пользователь при решении задачи? (типовые операции перечислены в п. 3.1. при проектировании таблиц баз данных).

Дизайн пользовательского интерфейса должен обеспечивать минимизацию усилий пользователя при выполнении работы и приводить к[28]:

-                   сокращению длительности операций чтения, редактирования и поиска информации,

-                   уменьшению времени навигации и выбора команды,

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

-                   увеличению длительности устойчивой работы пользователя и др.

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

Требования к удобству и комфортности интерфейса возрастают с увеличением сложности работ и ответственности пользователя за конечный результат. Высокая удовлетворенность от работы достигается в случае[29]:

-                   Прозрачной для пользователя навигации и целевой ориентации в программе.

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

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

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

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

-                   Совместное наращивание функциональности: возможность развивать проектируемую АСУ без разрушения (т.е. оставаясь в рамках) существующего интерфейса.

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

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

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

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

В соответствие с заявленными выше принципами, требованиями и условиями, интерфейс пользовательской части АСУ Департамента Аренды разрабатывался в среде Borland С++ Builder 6. Структура интерфейса пользовательской части представлена в приложении 6. Очевидно, что в структуре интерфейса проектируемой АСУ реализованы справочники и собственно отчеты. При этом очевидно, что в справочнике «Экспозиция» имеется только опция просмотра, иных опций не предусмотрено, т.к. любые изменения в этом справочнике приведут к изменениям в других справочниках, что может вызвать нарушение объективности и релевантности данных.

В справочниках «Журнал», «Объекты», «Операции» предусмотрены возможности редактирования и правки, т.к. это необходимо для описания функциональных процессов в проектируемой АСУ.

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

На основной форме находятся 5 основных пунктов меню: «Журнал», «Объекты», «Операции», «Экспозиция», «Выход».

Пункты меню «Журнал», «Объекты», «Операции», как уже было показано выше, содержат 4 подпункта, вызываемые через контекстное меню (правая кнопка мыши):

-                   Просмотр,

-                   Правка,

-                   Добавить,

-                   Удалить.

При выборе пункта «Журнал», откроется форма, которая имеет вид, представленный в приложении 8. В левой части расположены данные о клиентах Департамента Аренды: Наименование клиента и Идентификатор клиента согласно уникальному номеру клиента в базе. В правой части расположены данные по параметрам заявка клиента (требуемая категория объекта и цена), а также данные об ответственном лице, которое закреплено для взаимодействия с этим клиентом.

При выборе пункта меню «Объекты», откроется форма, представленная в приложении 9. В левой части расположены данные об объектах Департамента Аренды: Наименование объекта и Идентификатор объекта согласно уникальному номеру объекта в базе. В правой части расположены данные по параметрам указанного объекта, а также данные об ответственном лице, которое закреплено за указанным объектом.

При выборе пункта меню «Операции» имеется возможность просмотреть все операции, осуществленные как с клиентами, так и с объектами за определенный период (приложение 10 и приложение 11). Задача пункта меню «Операции» предоставлять детализированные отчеты по операциям, согласно условиям отбора, заданным пользователем.

Отбор в отчете «Клиенты» (приложение 10) идет по типу клиента, типу взаиморасчетов, с детализацией информации по каждому клиенту. В отчете «Объекты» имеется возможность, как детализировать информацию по каждому объекту (по аналогии с отчетом «Клиенты»), либо получать совокупную информацию по типу категории объектов за период (так, как представлено в приложении 11).

Пункт меню «Экспозиция» предназначен для получения данных по сроку нахождения объекта в базе и взаимосвязанной с ним информации, экранная форма представлена в приложении 12.

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

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

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

Все сотрудники филиала, имеющие отношение к работе с проектируемой АСУ (операционный персонал, руководители клиентских отделов, системный администратор, а также руководитель Департамента Аренды) прошли обучение.

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

Внедрение Автоматизированной Системы Управления документооборотом в Департаменте Аренды позволит:

-                   Автоматизировать процесс распределения заявок клиентов (снизить уровень хождения бумажных документов);

-                   Вести учет и мониторинг объектов недвижимости (в режиме on-line без обращения к бумажным носителям);

-                   Контролировать время экспозиции объектов недвижимости;

-                   Автоматически формировать и выдавать на печать отчёты, необходимые как для управленческой, так и для операционной деятельности;

-                   Хранить в базе данных информацию, как по клиентам, так и по объектам.




Глава 4. Анализ эффективности внедрения АСУ в Департаменте Аренды
Сокращение непроизводственных затрат и усилий пользователя - важная составляющая качества проектируемой АСУ, далее представлены основные преимущества внедряемой АСУ:

-                   Заявка клиента регистрируется в АСУ (ранее заявка регистрировалась на бумажном носителе, что обуславливало высокую вероятность полной или частичной утраты документов);

-                   Сейчас все операции по взаимодействию с клиентами и объектами будут отражаться в АСУ (бумажные носители будут использоваться операционными сотрудниками или руководителями отделов по собственному желанию);

-                   В АСУ в автоматизированном режиме формируются все необходимые отчеты для управленческих и обеспечивающих бизнес-процессов;

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

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

-                   Руководители клиентских отделов и руководитель Департамента Аренды имеют полную информацию в любой момент времени по всем проведенным операциям за произвольно выбранный период;

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

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

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

В первой главе данного дипломного проекта были представлены данные о производительности труда в Департаменте Аренды и данные о затратах рабочего времени на выполнение отдельных функций операционным персоналом. Предлагаемая АСУ позволяет сократить затраты рабочего времени на неосновные бизнес-процессы как минимум на 50%, следовательно операционный персонал не будет тратить рабочее время на следующие операции:

-                   Получение заявки клиента на бумажном носителе (все заявки можно просматривать в автоматизированном режиме);

-                   Выбор объектов для составления предложения клиенту (достаточно открыть пункт меню «Объекты», где все имеющиеся для предложения объекты разнесены по категориям, имеется возможность распечатать предложение для клиента на бумажном носителе или сохранить в файл и переслать по электронной почте)

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

Таким образом, высвобождается более от 32% до 40% рабочего времени операционного персонала, соответственно именно в равной степени должна увеличиться производительность труда (т.е. количество сданных объектов и полученных доходов Департаментом Аренды) без увеличения продолжительности рабочего дня.

Сравним показатели по имеющейся в настоящем производительности труда и показатели по планируемой производительности труда (таблица 11).

Очевидно, что при снижении затрат фактически отработанного времени на 8,2% производительность труда будет увеличена на 31,2% в основном за счет увеличения среднечасовой выработки (стоимость влияния фактора +4357,4 тыс. руб.). Кроме этого увеличивать численность персонала не планируется, следовательно все фактические затраты на персонал остаются на прежнем уровне. В свою очередь увеличение объемов сбыта, которое планируется получить по итогам внедрения Автоматизированной Системы Управления Документооборотом в Департаменте Аренды, позволит в дальнейшем увеличить материальное стимулирование сотрудников, что так же является немаловажным фактором социальной эффективности внедрения проектируемой АСУ.

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

Показатель	2008 год	проект	(+,-)	%
среднегодовая численность персонала Департамента Аренды	59	59	0,0	0,0
среднегодовая численность операционного персонала (ЧР)	28	28	0,0	0,0
удельный вес операционного персонала в общей численности (Уд)	0,47	0,47	0,0	0,0
отработано одним рабочим дней за год (Д)	216	216	0,0	0,0
отработано часов всеми сотрудниками	51408	47174,4	-4233,6	-8,2
средняя продолжительность рабочего дня (П), ч	8,5	7,8	-0,7	-8,2
реализовано услуг, тыс. руб.	23276	30540,9	7264,9	31,2
выработка на одного операционного сотрудника
среднегодовая (ГВ), тыс. руб.	831,3	1090,7	259,5	31,2
среднедневная (ДВ), тыс. руб.	107,8	141,4	33,6	31,2
среднечасовая (ЧВ), тыс. руб.	12,7	18,1	5,4	43,0
∆ГВуд = ∆Уд*Д0*П0*ЧВ0, тыс. руб.	0,0
∆ ГВд = Уд1*∆Д*П0*ЧВ0, тыс. руб.	0,0
∆ГВп = Уд1*Д1*∆П*ЧВ0, тыс. руб.	-909,7
∆ГВчв = Уд1*Д1*П1*∆ЧВ, тыс. руб.	4357,4

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

Итак, совокупные затраты на приобретение оборудования и СУБД MS SQL Server 2005 составят в среднем 1 100 тыс. руб. (в затраты включена дополнительная оплата сотрудников отдела IT Департамента Эксплуатации, затраты на обучение пользователей и формализацию бизнес-процессов). Срок внедрения проектируемой АСУ в Департаменте Аренды составляет 1 год. Планируемые доходы составляют, как было показано выше 4357,4 тыс. руб.

Экономическую эффективность внедрения Автоматизированной системы управления документооборотом целесообразно оценивать по следующим показателям[31]:

-                   чистый дисконтированный доход;

-                   индекс доходности;

-                   рентабельность инвестиций;

Чистый дисконтированный доход (ЧДД) – рассчитывается как разность накопленного дисконтированного дохода от реализации проекта и дисконтированных единовременных затрат[32].

где Di – доходы i-го периода (сальдо),

Ki – единовременные затраты i-го периода;

n – количество периодов реализации проекта;

d – ставка дисконтирования.

Обычно ставку дисконтирования принимают равной альтернативному вложению капитала, например ставки по ГКО – 10,3%. Т.к. внедрение проектируемой АСУ будет реализовано в течение одного года, то ставка дисконтирования не изменится.

Критерием экономической эффективности инвестиционного проекта по внедрению АСУ является положительное значение ЧДД (таблица 12).
Таблица 12. Расчет Чистого Дисконтированного Дохода (ЧДД) от внедрения АСУ в Департаменте Аренды

квартал	расходы, тыс. руб.	доходы, тыс. руб.	Коэффициент дисконтирования k = 0,103	Дисконтированные расходы, тыс. руб.	Дисконтированные доходы, тыс. руб.	ЧДД
1	275	0	0,897	246,7	0,0	-246,7
2	275	0	0,897	246,7	0,0	-246,7
3	275	2178,7	0,897	246,7	1954,3	1707,6
4	275	2178,7	0,897	246,7	1954,3	1707,6
итого	1100	4357,4		986,7	3908,6	2921,9

В нашем случае, очевидно, что предлагаемые мероприятия имеют высокую эффективность, т.к. очевидно, что ЧДД имеет положительное значение, в том случае если бы величина ЧДД была равна 0, можно было говорить, что вложение средств в Автоматизированную Систему Управления документооборотом в Департаменте Аренды равно альтернативному вложению капитала.

Индекс доходности проекта (ИД) – это отношение суммарного дисконтированного дохода к суммарным дисконтированным единовременным затратам[33].

Норма индекса доходности должна превышать единицу, в данном проекте индекс доходности составляет значение 3,96. Что является гарантией экономической эффективности данного проекта по внедрению Автоматизированной Системы Управления документооборотом в Департаменте Аренды.

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

Рентабельность проекта (среднегодовая рентабельность инвестиций) – является разновидностью индекса доходности, соотнесенного со сроком реализации проекта. Она показывает, какой доход приносит каждый вложенный в проект рубль инвестиций[34].
Ri =
где n – количество периодов, в течение которых реализуется проект.

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

Исходя из того, что индекс доходности составляет значение 3,96, были проведены необходимые расчеты по вышеуказанной формуле Ri, значение рентабельности инвестиций в проект по созданию Автоматизированной Системы Управления документооборотом в Департаменте Аренды составляет 70%. Необходимо отметить, что срок реализации проекта составляет 1 год или 4 квартала, при этом окупаемость проекта составляет период два квартала, т.к. затраты на создание проекта гораздо ниже, чем планируемые доходы.

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

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

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

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




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

-                   Функционал - набор возможностей, которые предлагает система;

-                   Бизнес процессы, которые данная система призвана улучшить;

-                   Стоимость системы;

-                   Сроки внедрения системы.

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

Создание Автоматизированной Системы Управления документооборотом в Департаменте Аренды ООО «Анелик» приносит тактические и стратегические выгоды. Тактические выгоды определяются сокращением расходов, связанных с:

-                   освобождением физического места для хранения документов;

-                   снижением временных затрат на обеспечивающие бизнес-процессы;

-                   уменьшением затрат на копирование и доставку документов в бумажном виде;

-                   снижением расходов на персонал и оборудование и др.

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

-                   значительное ускорение поиска и выборки документов (по различным атрибутам);

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

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

-                   улучшение контроля над исполнением непосредственных обязанностей операционных сотрудников Департамента Аренды.

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

Процесс создания АСУ состоит их нескольких этапов. Основными этапами являются следующие:

-                   Обследование организационной структуры предприятия, выявление основных бизнес-процессов, потоков работ;

-                   Составление номенклатуры документов, формирование справочников и классификаторов, составление инструкций;

-                   Адаптация системы на основе информации, полученной на этапе обследования;

-                   Установка и настройка программного обеспечения, и опытная эксплуатация;

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

-                   Обучение персонала организации.

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

Основные результаты дипломного проекта:

-                   Определено понятие корпоративной информационной системы;

-                   Выявлены основные этапы жизненного цикла информационных систем;

-                   Определены задачи моделирования бизнес-процессов на основе применения CASE- средств;

-                   Проанализирована организационная структура, направления деятельности компании ООО «Анелик» в целом и Департамента Аренды в частности;

-                   Построена модель «как есть». На этой модели была отработана методика построения структурных моделей бизнес-процессов для данного предприятия на базе методологии ARIS и IDEF0;

-                   Рассмотрены существующие архитектуры информационных систем и выбрана подходящая для реализации АСУ;

-                   Разработана и внедрена АСУ в Департаменте Аренды.

Внедрение АСУ позволило:

-                   Автоматизировать процесс создания заявки клиента;

-                   Вести учет объектов недвижимости;

-                   Контролировать время экспозиции объекта недвижимости в базе Департамента Аренды;

-                   Формировать отчеты в соответствие с потребностями пользователей;

-                   Выдавать на печать отчёты;

-                   Хранить в базе данных всю информацию по клиентам и объектам Департамента Аренды.

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




Список литературы и источников
1.                 Гражданский кодекс Российской Федерации (в четырех частях). – М., Ось-89, 2009.

2.                 Федеральный закон от 27.07.2006 N 149-ФЗ «Об информации, информационных технологиях и о защите информации»

3.                 Федеральный Закон «Об обществах с ограниченной ответственностью» № 14-ФЗ от 08 февраля 1998 года (в редакции от 27.10.2008 N 175-ФЗ)

4.                 ГОСТ Р 51141-98 Делопроизводство и архивное дело

5.                 ГОСТ 24.703-85 Единая система стандартов автоматизированных систем управления. Типовые проектные решения в АСУ. Основные положения

6.                 ГОСТ Р 6.30-2003. Унифицированные ​системы документации

7.                 РД 50-680-88 Методические указания. Автоматизированные системы. Основные положения.

8.                 Абдикеев Н.М., Данько Т.П., Ильдеменов С.В., Киселев А.Д. Реинжиниринг бизнес-процессов. Полный курс MBA. М.: Эксмо, 2007

9.                 Антикризисное управление: уч. пособие по единой программе подготовки арбитражных управляющих. М.: Инфра-М, 2008

10.            Дафт Р. Менеджмент. Издание 6-е. СПб: Питер, 2008

11.            Деминг Э. Выход из кризиса: Новая парадигма управления людьми, системами и процессами. М.: Альпина Бизнес Букс, 2007

12.            Гританс Я.М. Организационное проектирование и реструктуризация (реинжиниринг) предприятий и холдингов: экономические, управленческие и правовые аспекты (2-е издание). М.: Волтерс Клувер, 2008 г.

13.            Григорьев Ю.А., Ревунков Г.И. Банки данных: Учеб. для вузов. М: Изд-во МГТУ им. Н.Э. Баумана, 2002.

14.            Ильин В.В. Реинжиниринг бизнес-процессов с использованием ARIS. М.:ИД Вильямс, 2008

15.            Инструментарий ARIS. Методы. Версия 4.1 М.: Весть-Мета Технология, 2000

16.            Калянов Г.Н. Моделирование, анализ, реорганизация и автоматизация бизнес-процессов. М.: Финансы и статистика, 2007 г.

17.            Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS. Практическое руководство. М.: Весть-Мета Технология, 2001

18.            Крылова И. Ю. Документирование управленческой деятельности: учебное пособие. М.: Бизнес-пресса, 2007

19.            Крюкова Н.П. Документирование управленческой деятельности. Ростов-на-Дону: Феникс, 2005

20.            Новые тенденции в управлении. Дайджест McKinsey. М.: Альпина Бизнес Букс, 2007

21.            Непогода А.В., Семченко П.А. Делопроизводство организации: подготовка, оформление и ведение документации. М.: Омега-Л, 2009

22.            Оболенски Н. Практический реинжиниринг бизнеса: Инструменты и методы для эффективного изменения. М.: Лори, 2005

23.            Орлов С.А. Технологии разработки программного обеспечения: Учебник для вузов. ‑3-е издание. СПб.: Питер, 2004.

24.            Савицкая Г.В. Методика комплексного анализа хозяйственной деятельности. М.: Инфра-М, 2007

25.            Сертифицированный курс Microsoft «М 2781 Разработка серверных решений в Microsoft SQL Server 2005»

26.            Торрес Дж. Р. Практическое руководство по проектированию и разработке пользовательского интерфейса. М.: Вильямс, 2002

27.            Хаммер М., Чампи Д. Реинжиниринг корпорации: Манифест революции в бизнесе. М.: Манн, Иванов и Фербер, 2006

28.            Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. 4-е изд., доп. и перераб. СПб: КОРОНА принт, 2004

29.            Фрост Р., Дей Дж., Ван К., Базы данных. Проектирование и разработка. М.: NT Пресс, 2007

Приложение 1. Функциональная модель бизнес-процессов

Приложение 2. Модель основного бизнес-процесса, сформированная с помощью ARIS



Приложение 3. Объекты системы маршрутизации документооборота





Приложение 4. Структура сети





Приложение 5. Функциональная модель бизнес-процесса предоставления услуг в проектируемой АСУ



Приложение 6. Структура интерфейса пользовательской части



Приложение 7. Основная форма АСУ Департамента Аренды


Приложение 8. Экранная форма «Журнал»



Приложение 9. Экранная форма «Объекты»



Приложение 10. Экранная форма отчета «Клиенты»


Приложение 11. Экранная форма отчета «Объекты»


Приложение 12. Экранная форма «Экспозиция»