Технологии и методологии проектирования автоматизированных систем управления документооборотом

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Одним из главных факторов, влияющих на принятие решения о создании информационных систем в архитектуре «клиент-сервер», является потенциальная возможность повышения производительности работы пользователей, особенно в тех случаях, когда находящиеся в эксплуатации приложения не удовлетворяют требованиям, предъявляемым к скорости обработки данных ввиду их большого объема, а также высокой интенсивности и сложности запросов Каменнова М., Громов А., Ферапонтов М., Шматалюк А. Моделирование бизнеса. Методология ARIS. Практическое руководство. М.: Весть-Мета Технология, 2011; Орлов С.А. Технологии разработки программного обеспечения: Учебник для вузов. -3-е издание. - СПб.: Питер, 2014; Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. 4-е изд., доп. и перераб. - СПб.: КОРОНА принт, 2014 Известно, что информационные системы, основанные на архитектуре «клиент-сервер», могут обладать существенными преимуществами перед информационными системами, базирующимися на сетевых версиях настольных СУБД, такими, как существенно меньший сетевой трафик, меньшее время обработки запросов, меньшая ресурсоемкость клиентских приложений и меньшие трудозатраты при их разработке.

Определим цели, задачи, решаемые проектируемой АСУ (табл. 7).

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

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

Очевидно, что цели и задачи, которые решает автоматизация документооборота на каждом следующем уровне увеличивает её фактическую стоимость, что является немаловажным фактором в настоящее время, при этом важно отметить, что инвестиции в автоматизацию, как отдельных элементов документооборота, так и в полную автоматизацию бизнес-процессов определяются усиливающейся турбулентностью бизнес- среды. По мнению многих исследователей Дафт Р. Менеджмент. Издание 6-е. СПб: Питер, 2008 в условиях высокой турбулентности бизнес-среды эффективность неавтоматизированных бизнес- процессов резко снижается, увеличивает скрытые и явные потери предприятий и организаций. Оптимизация бизнес-процессов, а в отдельных случаях и реинжиниринг в современном развитии бизнеса сложно представить без использования современных IT, которые автоматизируют процессы управления, оптимизируют и повышают эффективность деятельности предприятий.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- сетевая;

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Цена услуг

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

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

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

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

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

- Цена

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

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

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

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

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

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

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

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

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

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

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

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

- Цена

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

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

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

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

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

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

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

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

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

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

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

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

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

В качестве среды разработки для клиентской части АСУ используется среда разработки C++ Builder, разработка компании Borland. С++ Builder относится к системам визуального проектирования, называемым также системами RAD. Разработка приложения в C++ Builder проходит в два взаимосвязанных этапа: Хомоненко А.Д., Цыганков В.М., Мальцев М.Г. Базы данных: Учебник для высших учебных заведений. - 4-е изд., доп. и перераб. - СПб.: КОРОНА принт, 2014. с 382-383

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

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

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

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

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

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

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

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

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

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

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

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

В качестве СУБД для проектируемой АСУ выбрана система MS SQL Server. Эта СУБД, создана компанией Microsoft и является в настоящее время одной из самых распространённых, кроме этого предлагаемая СУБД фактически в настоящее время является стандартом в области хранения данных Сертифицированный курс Microsoft «М 2781 Разработка серверных решений в Microsoft SQL Server 2008». Отличительные качества:

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

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

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

Требования к аппаратному обеспечению определяются требованиями к используемым операционным системам и серверным продуктам (Windows 7 Professional, Windows 2008 Server, SQL Server 2008) Там же:

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

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

II. Жесткий диск - 1 ТБ свободного места при установке полного пакета

III. Память - 1024 МБ. Требования к рабочей станции:

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

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

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

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

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

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

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

2.4 Разработка базы данных

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

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

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

Очевидно, что для одной и той же предметной области реляционные отношения можно спроектировать множеством различных способов. Далее определим критерии качественности базы данных Фрост Р., Дей Дж., Ван К., Базы данных. Проектирование и разработка. М.: NT Пресс, 2010:

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

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

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

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

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

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» приведена ниже.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Таблица 8 Структура таблицы «obects»

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

Таблица 9 Структура таблицы «Operations»

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

- Просмотр,

- Правка,

- Добавить,

- Удалить.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

информационный бизнес управление интерфейс

Глава 3. Анализ эффективности внедрения АСУ

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

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

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

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

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

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

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

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

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

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

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