Разработка системы управления электронным документооборотом на примере ООО "Курортное"

 

ВВЕДЕНИЕ

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

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

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

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

Цель дипломного проекта - разработка системы управления электронным документооборотом на примере ООО «Курортное».

Предмет исследования: ООО Курортное

Объект исследования: управления электронным документооборотом на примере ООО «Курортное».

Задачи:

-Рассмотреть теорию основы систем управления электронным документооборотом

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

-Выполнить программную реализацию систем управления электронным документооборотом ООО Курортное

-Произвести тест программного продукта

-Разработать технологи пользователя

-Разработать технологическую инструкцию ООО Курортное

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

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

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

-снизить уровень загруженности агента туристической фирмы;

-повысить уровень оперативности обслуживания клиентов;

-сократить издержки связанные с оформлением документации;

-повысить оперативность формирования периодической отчетности;

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

-повысить уровень конкурентоспособности фирмы.

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

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

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

Разработка программного продукта предполагается с помощью объектно-ориентированного языка программирования Borland Delphi 7.0, системы управления базами данных Microsoft Access 2003.

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

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

1.1 Задачи, функции и структура ООО «Курортное»

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

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

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

Основными сферами деятельности компании являются:

1.Международный туризм:

-на базе чартерных программ с вылетом из Москвы по направлениям Болгарии, Греции, ОАЭ.

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

-на регулярных рейсах а/к Чешский авиалинии, а/к Lufthansa, а/к KДавиа свои собственные программы с вылетом из Москвы.

В целях реализации проектов на этих направлениях ООО «Курортное» получила аккредитацию в посольствах Израиля, Германии, Чехии, Швейцарии. Подписаны контракты с международными системами бронирования, а также с рядом зарубежных операторов и непосредственно с отелями, благодаря аккредитации в IATO.

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

2.Российский туризм:

Компания активно занимается формированием и реализацией туристического продукта на территории Российской Федерации. Основными направлениями являются:

-Пляжный отдых на Черноморском побережье, калининградская область, Среднее Поволжье.

-Экскурсионные программы в Москве, Санкт-Петербурге, золотом Кольце, городах Средней волги.

-Лечение в санаториях Черноморского побережья, Северного Кавказа, Самарской, Ульяновской, Пензенской областях, республиках Чувашии, Татарстана, Башкирии и других.

-Активный отдых. Лидеры в продаже горнолыжных туров на территории Российской Федерации.

-Реализуем путевки практически на все круизы Волжско-Камского водного бассейна.

3.Автомобильный и водный транспорт:

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

-Из активного отдыха предлагаются прогулки на яхтах, конно-верховые;

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

4.Продажа пассажирских перевозок:

Продажей пассажирских железнодорожных и авиаперевозок ООО «Курортное» занимается с 2008 г. Реализация авиабилетов производится на все авиакомпании Российской Федерации и, практически, на все крупные зарубежные авиакомпании, работаем в системе бронирования «Сирена», «Габриэль», «Сибр», «Экспресс-2» [24].

5.Корпоративное обслуживание:

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

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

Рис. 1.1 Организационная структура

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

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

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

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

Таким образом, компания ООО «Курортное» представляет собой небольшую, но довольно динамически развивающуюся компанию.

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

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

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

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

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

1.Применение стандартного программного обеспечения, например, использование программ Word, Excel, PowerPoint, Outlook, готовых баз данных Access, программ-переводчиков, бухгалтерских, финансовых, систем управления документами, знаниями.

2.Применение специальных типовых информационных технологий управления в туризме: «МАСТЕР-ТУР», «САМО-Тур» и др.

.Использование глобальных компьютерных систем бронирования: «AMADEUS», «GALILEO», «SABRE» и др.

.Сопряжение типовых информационных технологий управления с системами бронирования.

.Участие в электронной торговле или электронном бизнесе.

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

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

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

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

-от режима работы компьютеров (автономный или сетевой).

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

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

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

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

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

.Соответствовать нормам российского законодательства;

2.Охватывать все стороны производственно-хозяйственной и финансовой деятельности турфирмы, обеспечивая при этом:

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

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

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

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

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

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

3.Быть современным и конкурентоспособным информационным продуктом в своем классе, используя:

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

-передовые информационные технологии;

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

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

.Иметь гибкую и быструю настройку параметров на особенности конкретной турфирмы.

.Иметь фирменную техническую поддержку.

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

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

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

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

Рассмотрим основные понятия относящиеся к электронному документообороту:

Документооборот - движение документов в организации с момента их создания или получения до завершения исполнения или отправления (ГОСТ Р 51141-98); комплекс работ с документами: прием, регистрация, рассылка, контроль исполнения, формирование дел, хранение и повторное использование документации, справочная работа.

Электронный документооборот (ЭДО) - единый механизм по работе с документами, представленными в электронном виде, с реализацией концепции «безбумажного делопроизводства».

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

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

1.3 Анализ существующих разработок

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

1.3.1 Система электронного документооборота CompanyMedia

CompanyMedia - программный комплекс - система электронного документооборота и управления бизнес-процессами (СЭДиУП), производимая Компанией ИнтерТраст с 1998г. по настоящее время, на основе платформы совместной работы пользователей (GroupWare) IBM Lotus Notes/Domino. CompanyMedia является зарегистрированным товарным знаком производителя - компании "ИнтерТраст". Система CompanyMedia относится к классу систем управления корпоративным контентом(ECM). В настоящее время, в её состав входят 22 модуля, выполняющие различные задачи, от автоматизации классических задач общего и частного документооборота до поддержки групповой работы и автоматизации бизнес-процессов. В целом, эти предметные модули могут быть разделены на следующие пять категорий:

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

-управление типовыми деловыми процессами;

-управление документацией;

-управление регламентированными процессами;

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

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

Все модули СЭДиУП CompanyMedia имеют перед названием приставку CM-, обозначающую принадлежность модуля именно к этой системе электронного документооборота, что отличает их от другой разработки того же производителя - СЭД OfficeMedia, предназначенной для малых и средних организаций, но, в целом, поддерживающих стандартный функционал систем электронного документооборота. Модули системы разбиты на пять категорий по прикладным типам. Структура программного продукта представлена на рисунке 1.1.

Рис. 1.1 Структура программного продукта CompanyMedia

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

Таким образом систему «CompanyMedia» можно охарактеризовать как функциональную и удобную систему документооборота, специализированную на государственный сектор и органы федеральной, региональной и муниципальной власти, финансовый сектор, предприятия промышленности [26].

1.3.2 Система электронного документооборота «БОСС- Референт»

«БОСС-Референт» - система электронного документооборота (СЭД), предназначенная для автоматизации бизнес-процессов, связанных с документационным обеспечением управления предприятием. Разработчик системы - российская компания «Аплана», входящая в группу компаний «АйТи». Пользователи системы - органы федеральной, региональной и местной власти, государственные предприятия, коммерческие организации различной структуры.

Система обеспечивает поддержку следующих бизнес-процессов:

1.Работа с внутренними документами организации

-подготовка проекта документа, его согласование (визирование), утверждение;

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

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

-регистрация и архивирование;

-создание и хранение шаблонов документов.

2.Обработка входящей и исходящей корреспонденции

-регистрация, контроль и учет;

-создание резолюций по документу;

-настройка регистрационного номера в соответствии с номенклатурой дел;

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

-отправка в "Дело" после исполнения.

3.Работа с договорами организации

-создание и ведение шаблонов договоров;

-ведение реестра договоров;

-согласование договоров;

-формирование отчетов.

4.Ведение справочника организации

-создание и поддержка справочника организации в соответствии с организационной структурой;

-поддержка механизма делегирования полномочий;

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

5.Поддержка материально-технического обеспечения организации

-ведение реестра объектов МТО;

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

-поддерживается механизм инвентаризации объектов МТО.

Преимущества системы "БОСС-Референт":

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

-Пользователи могут работать как через клиент Lotus Notes, так и через Web-браузер.

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

Недостатки системы "БОСС-Референт":

-Относительная дороговизна (за счет необходимости приобретения платформы IBM Lotus Notes/Domino).

-Необходимость наличия на предприятии специалиста, компетентного в IBM Lotus Notes/Domino, который смог бы обеспечить грамотное сопровождение системы "БОСС-Референт".

-Ограничения по интеграции с не IBM решениями [19].

1.3.3 Система электронного документооборота «ДЕЛО»

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

На рисунке 1.2. представлен интерфейс данной информационной системы.

Рис. 1.2 Интерфейс системы «ДЕЛО»

Система «ДЕЛО» была выпущена в 1996 году. В 1996 году получила сертификат качества Госстандарта России, а в 2006 году - свидетельство об официальной регистрации в реестре программ для ЭВМ. Система постоянно обновляется в соответствии с принятыми стандартами и пожеланиями пользователей.

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

Система «ДЕЛО» полностью соответствует государственным нормативно-методическим требованиям в области управления документами. Наличие открытого API-интерфейса делает возможной интеграцию системы документооборота предприятия «ДЕЛО» с любыми используемыми в организации информационными системами и бизнес-приложениями.

Модули системы «ДЕЛО»:

-ДЕЛО-WEB - решение для предприятий с территориально распределенной структурой. С помощью web-технологий позволяет сотрудникам удаленного филиала оставаться равноправными участниками документооборота в рамках всего предприятия.

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

-Сканирование и поточное сканирование - позволяет осуществить сканирование и распознавание бумажных документов посредством программного обеспечения Abbyy Fine Reader 7.0 Scripting Edition.

-Защита от несанкционированного доступа - обеспечивает безопасность хранимой информации с помощью Secret Disk Server NG компании Aladdin.

-Подсистема оповещений и уведомлений - осуществляет автоматическую рассылку уведомлений и оповещений на электронную почту пользователей о различных событиях системы «ДЕЛО».

-Подсистема интеграция СЭД «ДЕЛО» и системы 1С - позволяет упорядочить работу с финансовыми документами.

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

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

электронный документооборот программный информация

1.3.4 Система электронного документооборота «EOS for SharePoint»

«EOS for SharePoint» - система электронного документооборота и управления корпоративным контентом, выполнена на платформе Microsoft Office SharePoint Server 2007. Система была выпущена в 2008 году и получила свидетельство об официальной регистрации в реестре программ для ЭВМ.

«EOS for SharePoint» - полноценное решение класса Enterprise content management, позволяющее объединить в одной системе комплексное управление всеми информационными ресурсами, процессами и коммуникациями организации.

«EOS for SharePoint» предоставляет одновременно средства совместной работы сотрудников с документами и готовые инструменты для автоматизации процессов документооборота и контроля исполнения поручений в соответствии с отечественной практикой и нормативными требованиями.

Функции системы:

-организация корпоративного централизованного электронного хранилища документов;

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

-поддерживается процедура общего документооборота (обработка входящих и исходящих документов)

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

-так же могут поддерживаться специфические для организации процессы обработки документов и форм [7].

1.3.5 Система электронного документооборота «ЕВФРАТ»

Система электронного документооборота и автоматизации бизнес-процессов ЕВФРАТ предназначена для построения полноценной системы управления бизнес-процессами и документами организации.

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

Система ЕВФРАТ разработана в полном соответствии с рекомендациями WfMC (Workflow Management Coalition) и удовлетворяет требованиям стандарта ISO 9000. Гибкость системы позволяет реализовать поддержку бизнес-процессов организации, обеспечивая:

-автоматизацию традиционного делопроизводства в соответствии с требованиями ГОСТ;

-электронный документооборот в соответствии с требованиями регламентов, положений и инструкций по работе с документами, разработанными и применяемыми организацией [16].

1.3.6 Система электронного документооборота «Directum»

DIRECTUM - система электронного документооборота и управления взаимодействием, нацеленная на повышение эффективности работы всех сотрудников организации[1] в разных областях их совместной деятельности.

Система DIRECTUM относится к классу ECM-систем (Enterprise Content Management) и поддерживает полный жизненный цикл управления документами, при этом традиционное «бумажное» делопроизводство органично вписывается [2] в электронный документооборот. DIRECTUM обеспечивает организацию и контроль деловых процессов на основе технологии Workflow: согласование документов, обработка сложных заказов, подготовка и проведение совещаний, поддержка цикла продаж и других процессов взаимодействия.

Состав системы DIRECTUM.

Управление электронными документами. Создание и хранение различных неструктурированных документов (тексты Microsoft Word, таблицы Microsoft Excel, рисунки Microsoft Visio, CorelDraw, видео и пр.); поддержка версий документов и ЭЦП; структурирование документов по папкам; назначение прав доступа на документы; история работы с документами; полнотекстовый и атрибутивный поиск документов.

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

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

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

Канцелярия. Регистрация бумажных документов в соответствии с требованиями ГСДОУ; ведение номенклатуры дел с гибкими правилами нумерации; рассылка и контроль местонахождения бумажных документов; организация обмена электронными документами с ЭЦП с другими организациями.

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

Возможности системы DIRECTUM существенно расширяются благодаря следующим компонентам:

-Предметно-ориентированный инструмент разработки IS-Builder. Модификация и разработка новых карточек электронных документов, справочников, отчетов, блоков типовых маршрутов; встроенный язык программирования ISBL; интеграция с другими системами.

-Службы файловых хранилищ (DIRECTUM Storage Services). Управление хранением большого объема данных в единой системе; архивное хранение документов; работа с медиа-данными; настройка политик хранения, обеспечивающих автоматическое перемещение данных по хранилищам.

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

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

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

-DIRECTUM OverDoc. Просмотр, редактирование и подписание документов ЭЦП вне системы DIRECTUM для обмена между разными организациями; распространяется бесплатно.

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

-Службы ввода документов (DIRECTUM Capture Services). Массовый ввод документов в DIRECTUM с различных источников (сканеры, МФУ, файловая система, факсы, электронная почта и т. д.).

-Службы преобразования документов (DIRECTUM Transformation Services). Преобразование документов в другие форматы, извлечение из документов полезной информации.

-Набор средств интеграции (DIRECTUM Integration Toolset). Легкая интеграция с ERP-системами: двухсторонняя синхронизация справочников, включение объектов системы в workflow, генерация документов и доступ к ним из ERP-системы [23].

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

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

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

1.4.1 Функциональные требования

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

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

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

-целостность - означает то, что все элементы системы функционируют как единое целое.

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

-следить за состоянием документа на любой его стадии;

-получать исчерпывающую информацию о документе;

-хранить данные о документах

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

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

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

1.4.2 Требования к удобству использования

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

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

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

-по поводу человеческого фактора.

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

-По поводу справочной системы.

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

-По поводу документации.

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

1.4.3 Требования к надежности

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

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

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

1.4.4 Требования к производительности

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

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

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

1.4.5 Требования возможности сопровождения

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

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

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

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

Выводы

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

ГЛАВА 2. Проектирование системы управления электронным документооборотом ООО «Курортное»

.1 Разработка концептуальной модели

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

С помощью концепции IDEF0 можно схематически отразить движение документов в организации.- Function Modeling - методология функционального моделирования и графическая нотация, предназначенная для формализации и описания бизнес-процессов. Отличительной особенностью IDEF0 является её акцент на соподчинённость объектов. В IDEF0 рассматривается логические отношения между работами, а не их временна?я последовательность (WorkFlow).

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

Методологию IDEF0 можно считать следующим этапом развития хорошо известного графического языка описания функциональных систем SADT (Structured Analysis and Design Technique). Несколько лет назад в России небольшим тиражом вышла одноименная книга, посвященная описанию основных принципов построения SADT-диаграмм. Исторически, IDEF0, как стандарт был разработан в 1981 году в рамках обширной программы автоматизации промышленных предприятий, которая носила обозначение ICAM (Integrated Computer Aided Manufacturing) и была предложена департаментом Военно-Воздушных Сил США. Собственно семейство стандартов IDEF унаследовало свое обозначение от названия этой программы (IDEF=ICAM DEFinition). В процессе практической реализации, участники программы ICAM столкнулись с необходимостью разработки новых методов анализа процессов взаимодействия в промышленных системах. При этом кроме усовершенствованного набора функций для описания бизнес-процессов, одним из требований к новому стандарту было наличие эффективной методологии взаимодействия в рамках «аналитик-специалист». Другими словами, новый метод должен был обеспечить групповую работу над созданием модели, с непосредственным участием всех аналитиков и специалистов, занятых в рамках проекта [17].

В результате поиска соответствующих решений родилась методология функционального моделирования IDEF0. C 1981 года стандарт IDEF0 претерпел несколько незначительных изменений, в основном, ограничивающего характера, и последняя его редакция была выпущена в декабре 1993 года Национальным Институтом По Стандартам и Технологиям США (NIST) [17].

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

Рис. 2.1 Контекстная диаграмма

Основной документооборот на предприятии связан с заявками от клиентов. На рисунке 2.2 отражена подробная схема утверждения документа клиента.

Рис. 2.2 Модель IDEF0. Уровень А0

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

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

Схематически данный процесс представлен на рисунке 2.3.

Рис. 2.3 Процесс оформления заявки

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

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

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

На рисунке 2.4 представлен более подробно процесс выполнения заявки.

Рис. 2.4 Процесс выполнения заявки

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

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

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

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

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

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

Стадия «Исполнен» означает, что заявка была утверждена, услуги оказаны и путешествие благополучно завершилось.

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

2.2 Характеристика нормативно-справочной, входной и оперативной информации

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

В данном случае к нормативно справочной информации можно отнести информацию о странах и курортах.

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

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

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

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

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

.3 Характеристика результатной информации

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

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

-страна, куда отправляется клиент;

-фамилия и инициалы клиента;

-название курорта;

-название гостиницы;

-количество детей;

-количество взрослых;

-дата заезда;

-дата выезда.

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

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

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

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

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

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

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

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

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

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

Иерархическая модель данных. Иерархическая БД состоит из упорядоченного набора деревьев; более точно, из упорядоченного набора нескольких экземпляров одного типа дерева. Тип дерева состоит из одного «корневого» типа записи и упорядоченного набора из нуля или более типов поддеревьев (каждое из которых является некоторым типом дерева). Тип дерева в целом представляет собой иерархически организованный набор типов записи.

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

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

Основным недостатком данной модели является необходимость использования той иерархии, которая была заложена в основу БД при проектировании. Потребность в постоянной реорганизации данных (а часто невозможность этой реорганизации) привели к созданию более общей модели - сетевой [14].

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

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

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

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

Принято считать, что реляционный подход к организации баз данных был заложен в конце 1960-х гг. Эдгаром Коддом. В последние десятилетия этот подход является наиболее распространенным (с оговоркой, что в называемых в обиходе реляционными системах баз данных, основанных на языке SQL, в действительности нарушаются некоторые важные принципы классического реляционного подхода). Достоинствами реляционного подхода принято считать следующие свойства: реляционный подход основывается на небольшом числе интуитивно понятных абстракций, на основе которых возможно простое моделирование наиболее распространенных предметных областей; эти абстракции могут быть точно и формально определены; теоретическим базисом реляционного подхода к организации баз данных служит простой и мощный математический аппарат теории множеств и математической логики; реляционный подход обеспечивает возможность ненавигационного манипулирования данными без необходимости знания конкретной физической организации баз данных во внешней памяти. Компьютерный мир далеко не сразу признал реляционные системы. В 70-е года прошлого века, когда уже были получены почти все основные теоретические результаты и даже существовали первые прототипы реляционных СУБД, многие авторитетные специалисты отрицали возможность добиться эффективной реализации таких систем. Однако преимущества реляционного подхода и развитие методов и алгоритмов организации и управления реляционными базами данных привели к тому, что к концу 80-х годов реляционные системы заняли на мировом рынке СУБД доминирующее положение [28].

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

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

-страна - это данные страны, в которую может поехать клиент на отдых;

-курорт - это данные курорта, с которыми сотрудничает туристическое агентство;

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

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

-отдел - это отдел в котором работает сотрудник туристического агентства, имеющий доступ к системе электронного документооборота;

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

-заявка - это заявка клиента на осуществление отдыха на одном из курортов;

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

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

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

Опишем реквизиты каждого выделенного информационного объекта.

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

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

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

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

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

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

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

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

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

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

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

Рис. 2.5 Информационно-логическая модель

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

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

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

На рисунке 2.5. представлено дерево функций разрабатываемого программного продукта.

Рис. 2.5 Дерево функций

На рисунке 2.6. представлен сценарий диалога с пользователем. Он осуществляется с помощью главного меню.

Рис. 2.6 Сценарий диалога с пользователем

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

Выводы

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

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

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

ГЛАВА 3. ПРОГРАММНАЯ РЕАЛИЗАЦИЯ ПРОГРАММНОГО ПРОДУКТА

3.1 Обоснование выбора средств разработки

Для реализации программного продукта была выбрана СУБД Microsoft Access 2003, что предъявляет требования к программному обеспечению, на который будет устанавливаться программный продукт.

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

-Microsoft Windows;

-Microsoft Office (Access и Excel);

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

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

Для создания базы данных автоматизированного рабочего места используется система управления базами данных Microsoft Access 2003. Данный программный продукт позволяет управлять всеми сведениями из одного файла базы данных. В основе выбора именно данной системы управления базами данных лежит отсутствие затрат на приобретение. На сегодняшний день в компании уже присутствует и используется данная система управления базами данных. В рамках этого файла используются следующие объекты:

-таблицы для сохранения данных;

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

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

-отчеты для анализа и печати данных в определенном формате;

-макросы для создания собственных сценариев обработки данных.

Запросы создаются для поиска и вывода данных, удовлетворяющих заданным условиям, включая данные из нескольких таблиц, для обновления, добавления или удаления группы записей одновременно, для выполнения стандартные или пользовательских вычислений, для создания новых таблиц. Для создания запросов, а также для обновления и управления объектами базы данных, применяется язык SQL (Structured Query Language) [1].

Язык SQL используется при создании запросов, а также для обновления и управления реляционными базами данных, такими как базы данных Microsoft Access. SQL является полным языком, в нем присутствуют не только операции запросов, но и операторы, соответствующие DDL - Data Definition Language - языку описания данных. Кроме того, язык содержит операторы, предназначенные для управления (администрирования) БД [29].

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

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

Для обработки событий в форме или отчете применяются макрокоманды (макросы) и модули на языке VBA (Visual Basic for Applications). Макрос - это группа команд, объединенных под одним именем и выполняющих определенную функцию (например, открытие/закрытие формы, отчета, запуск запроса и т. д.). Каждый макрос представляет собой небольшой отлаженный модуль на VBA, их применение значительно упрощает процесс программирования и уменьшает количество ошибок при разработке программы [10].

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

-Borland Delphi 7.0;

-Microsoft Visual Basic .NET;

-C++ Builder.

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

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

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

Таблица 3.1 Сравнительный анализ средств разработки

Параметр сравненияBorland Delphi 7.0.Microsoft Visual Basic . NetC++ BuilderБыстрота создания программного продукта (знание продукта разработчиком)544Наличие и доступность документации555Поддержка со стороны производителя555Инструментарий средств разработки555Итого:201919

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

Из всех известных сред разработки программных продуктов Delphi является одной из самых лучших по следующим причинам:

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

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

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

-Delphi имеет большую производительность и относительно небольшие размеры;

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

Кроме того, Delphi - это комбинация нескольких важнейших технологий:

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

-объектно-ориентированная модель компонент;

-визуальное (а, следовательно, и скоростное) построение приложений из программных прототипов;

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

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

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

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

Таким образом, СУБД Microsoft Access и язык программирования Borland Delphi 7.0. идеально подходят для реализации программного продукта. Наличие установленного языка программирования Borland Delphi 7.0 на компьютерах, где предполагается использование программного продукта после окончания разработки не является необходимым.

3.2 Физическое проектирование базы данных

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

В таблице 3.2 представлена структура реализуемой таблицы «Страна».

Таблица 3.2 Структура таблицы «Страна»

Имя поляТип данныхРазмер поляКлючКод страныСчетчик-ПервичныйСтранаТекстовый50-

В таблице 3.3 представлена структура реализуемой таблицы «Клиенты».

Таблица 3.3 Структура таблицы «Клиенты»

Имя поляТип данныхРазмер поляКлючКод клиентаСчетчик-ПервичныйФамилияТекстовый50-ИмяТекстовый50-ОтчествоТекстовый50-АдресТекстовый255-Дата рожденияДата--ПаспортТекстовый12-ТелефонТекстовый14-E-mailТекстовый50-

В таблице 3.4 представлена структура реализуемой таблицы «Должности».

Таблица 3.4 Структура таблицы «Должности»

Имя поляТип данныхРазмер поляКлючКод должностиСчетчик-ПервичныйДолжностьТекстовый50-

В таблице 3.5 представлена структура реализуемой таблицы «Права».

Таблица 3.5 Структура таблицы «Права»

Имя поляТип данныхРазмер поляКлючКод праваСчетчик-ПервичныйНазваниеТекстовый50-ФормированиеЛогический--УтверждениеЛогический--ИсполнениеЛогический--

В таблице 3.6 представлена структура реализуемой таблицы «Курорты».

Таблица 3.6 Структура таблицы «Курорты»

Имя поляТип данныхРазмер поляКлючКод курортаСчетчик-ПервичныйКурортТекстовый50-Стоимость билетаДенежный--Код страныЧисловой-Внешний

В таблице 3.7 представлена структура реализуемой таблицы «Пользователи».

Таблица 3.7 Структура таблицы «Пользователи»

Имя поляТип данныхРазмер поляКлючКод пользователяСчетчик-ПервичныйФИОТекстовый150-ЛогинТекстовый50-ПарольТекстовый50-Код должностиЧисловой-ВнешнийКод отделаЧисловой-ВнешнийКод праваЧисловой-Внешний

В таблице 3.8 представлена структура реализуемой таблицы «Заявки».

Таблица 3.8 Структура таблицы «Заявки»

Имя поляТип данныхРазмер поляКлючКод заявкиСчетчик-ПервичныйГостиницаТекстовый150-Количество людейЧисловой50-Количество детейЧисловой50-Дата заездаДата--Дата выездаДата--Код клиентаЧисловой-ВнешнийКод курортаЧисловой-ВнешнийСформировалЧисловой-ВнешнийУтвердилЧисловой-ВнешнийИсполнительЧисловой-ВнешнийДата формированияДата--Дата утвержденияДата--Дата исполненияДата--

Исходя из представленных выше таблицы были реализованы таблицы в системе управления базами данных Access. На рисунке 3.1 представлена таблица «Должности» в режиме конструктора.

Рис. 3.1 Таблица «Должности» в режиме конструктора

На рисунке 3.2. представлена таблица «Заявка» в режиме конструктора.

Рис. 3.2 Таблица «Заявка» в режиме конструктора

На рисунке 3.3. представлена таблица «Клиенты» в режиме конструктора.

Рис. 3.3 Таблица «Клиенты» в режиме конструктора

На рисунке 3.4. представлена таблица «Курорты» в режиме конструктора.

Рис. 3.4 Таблица «Курорты» в режиме конструктора

На рисунке 3.5. представлена таблица «Отделы» в режиме конструктора.

Рис. 3.5 Таблица «Отделы» в режиме конструктора

На рисунке 3.6. представлена таблица «Пользователи» в режиме конструктора.

Рис. 3.6 Таблица «Пользователи» в режиме конструктора

На рисунке 3.7. представлена таблица «Права» в режиме конструктора.

Рис. 3.7 Таблица «Права» в режиме конструктора

На рисунке 3.8. представлена таблица «Страна» в режиме конструктора.

Рис. 3.8 Таблица «Страна» в режиме конструктора

На рисунке 3.9. представлена схема данных.

Рис. 3.9 Схема данных

3.3 Физическая реализация программного продукта

У всех документов можно выделить три стадии:

-сформирован;

-проверен;

-исполнен.

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

Рис. 3.10 Макет главной формы

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

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

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

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

Рис. 3.11 Макет формы справочников

Кроме того необходимо выделить и формы клиентов. На рисунке 3.12 представлен макет формы клиентов.

Рис. 3.12 Макет формы клиентов

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

На рисунке 3.13 представлен макет формы входа в систему.

Рис. 3.13 Макет входа в систему

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

Переход между формами будет осуществляться преимущественно с помощью главного меню.

На рисунке 3.14. представлен макет формы отражающей полную информацию о заявке.

Рис. 3.14 Макет формы «Полная информация о заявке»

На рисунке 3.15. представлен макет формы администрирования.

Рис. 3.15 Макет формы «Пользователи»

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

3.4 Руководство для пользователей по эксплуатации программного продукта

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

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

При запуске программного продукта появиться окно входа в систему, представлено на рисунке 3.16.

Рис. 3.16 Окно входа в систему

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

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

Рис. 3.17 Главная форма программного продукта

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

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

На рисунке 3.18. представлена вкладка «Утвержденные к исполнению заявки».

Рис. 3.18 Главная форма. Утвержденные к исполнению заявки

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

На рисунке 3.19. представлены уже исполненные документы.

Рис. 3.19 Главная форма. Исполненные заявки

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

Рис. 3.20 Форма «Полная информация о документе»

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

Для того чтобы оформить нового клиента необходимо с помощью главного меню открыть форму «Клиенты» (меню «Справочники»).

На рисунке 3.21 представлена форма «Клиенты».

Рис. 3.21 - Форма «Клиенты»

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

Рис. 3.22 Навигационное меню

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

На рисунке 3.23. представлена форма «Страны».

Рис. 3.23 Форма «Страны»

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

На рисунке 3.24. представлена форма «Курорты».

Рис. 3.2 Форма «Курорты»

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

Выход из программы можно осуществить следующими способами:

-закрыть главную форму;

-выбрать пункт в главном меню «Выход».

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

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

3.4.2 Инструкция по работе с программным продуктом пользователю с набором прав системного администратора

При запуске программного продукта появиться окно входа в систему, представлено на рисунке 3.25.

Рис. 3.25 Окно входа в систему

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

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

Рис. 3.26 Главная форма

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

Системный администратор имеет несколько дополнительных таблиц, которые имеет право редактировать. На рисунке 3.27 представлен справочник «Пользователи».

Рис. 3.27 Справочник «Пользователи»

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

На рисунке 3.28. представлена форма «Права»

Рис. 3.28 Форма «Права»

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

На рисунке 3.29. представлена форма «Отделы».

Рис. 3.29 Форма «Отделы»

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

На рисунке 3.30 представлена форма «Должности».

Рис. 3.30 Форма «Должности»

Данная форма содержит информацию о возможных должностях сотрудников и отделах.

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

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

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

При запуске программного продукта появиться окно входа в систему, представлено на рисунке 3.31.

Рис. 3.31 Окно входа в систему

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

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

Рис. 3.32 Главная форма

Как видно из представленного выше рисунка кнопка «Добавить» заблокирована, зато кнопка «Проверен» разблокирована.

На рисунке 3.33. представлена главная форма программного продукта на вкладке утвержденные к исполнению заявки.

Рис. 3.33 Главная форма. Утвержденные к исполнению заявки

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

3.4.4 Внедрение информационной системы

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

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

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

Выводы

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

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

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

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

ЗАКЛЮЧЕНИЕ

Темой дипломного проекта являлась «Разработка системы управления электронным документооборотом на примере ООО «Курортное».

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

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

В процессе написания дипломного проекта было выполнено следующее:

-анализ предметной области;

-анализ деятельности предприятия;

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

-проектирование базы данных;

-физическая реализация базы данных;

-разработка приложения пользователя;

-физическая реализация приложения пользователя.

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

-снизить уровень загруженности агента туристической фирмы;

-повысить уровень оперативности обслуживания клиентов;

-сократить издержки связанные с оформлением документации;

-повысить оперативность формирования периодической отчетности;

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

-повысить уровень конкурентоспособности фирмы.

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

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

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

Программный продукт был реализован с помощью системы управления базами данных Microsoft Access 2003, а также языка объектно-ориентированного программирования Borland Delphi 7.0. Оформление отчета осуществлялось с помощью интегрированного пакета Microsoft Office 2003.

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

СПИСОК ИСПОЛЬЗОВАННЫХ ИСТОЧНИКОВ И ЛИТЕРАТУРЫ

1.Бакаревич Ю. Б. Самоучитель Microsoft Access / Ю. Бакаревич, Н.Пушкина.- 2003. - СПб.: БХВ-Петербург, 2002 - 402 с.

2.Барановская Т. П. и др. Информационные системы и технологии в экономике Т.П. Барановская.- Учебник. -2-е изд., доп. и перераб. - М.: Финансы и статистика, 2005 - 416 с.

.Благодатских В. А. и др. Стандартизация разработки программных средств / В.А Благодатских.- Учеб. пособие. - М.: Финансы и статистика, 2005. - 288 с.

.Бобровский С. Программирование в Delphi 7 / С.Бобровский. - СПб.: Информ-Пресс, 2003. - 806 c. : ил.

.Бойко В.В. Проектирование баз данных информационных систем / В. Бойко, В.М Савинков. - М.: Финансы и статистика, 2004.

.Бондарева Г.А. Информатика / Е.В. Сахарова, Л.Н. Королькова,- Ставрополь, СТИС, 2006

.Вендров А. М. Проектирование программного обеспечения экономических информационных систем / А.М. Вендеров.-Учебник. -2-е изд., перераб. и доп. -М.: Финансы и статистика, 2005. - 544 с.

.Гетия И. Г. Безопасность при работе на ПЭВМ / И.Г Гетия. - М.: НПЦ Профессионал-Ф, 2001. - 140 с.

.Гончаров А. Ю. Access 2003. Самоучитель с примерами / А.Ю Гончаров. М.: Инфра-М, 2004 - 385 с.

.Горев А. Эффективная работа с СУБД / А. Горев. - СПб.: Питер, 1997. - 704с.: ил.

.Гофман В. Э и др. Delphi 7 / В.Э Горфман, А.Д Хомоненко. - СПб.: BHV, 2004. - 1216 с. : ил.

.Дарахвелидзе, П.Г. Программирование в Delphi7 / П.Г Дарахвелидзе.- СПб.: БХВ-Петербург, 2003. - 784 с.

.Каймин В.А. Информатика: Учебник. - 5-ое издание / В.А Каймин. - М.: ИНФРА-М, 2007 - 244 с.

.Карпова Т. С. Базы данных: модели, разработка, реализация: учеб. пособие для вузов / Т.С Карпов.- СПб.: Питер, 2001. -304с.: ил.

.Конеев И. Информационная безопасность предприятия / И.Конеев. - СПб.: БХВ-Петербург, 2003. - 733 с.

.Лугачев М. И. и др. Экономическая информатика: введение в экономический анализ / М.И Лугачев. - М.: Инфра-М, 2005. -569 с.

.Маклаков С. В. ВРWin и ERWin. САSЕ-средства разработки информационных систем С.В Маклаков. - М.: Диалог-МИФИ, 1999 - 455 с.: ил.

.Мельников В. В. Безопасность информации в автоматизированных системах / В.В Мельников. - М.: Финансы и статистика, 2003. - 368 с.

.Мишенин А. И. Теория экономических информационных систем / А.И Мишенин. - М.: Финансы и статистика, 2000. - 240 с.

.Норенков И. П. Основы автоматизированного проектирования И.П Норенков.- Учебник для вузов. - М.: МГТУ им. Н. Э. Баумана, 2002. - 336

.Орлов С. Технологии разработки программного обеспечения / С.Орлов.- Учебное пособие. 2-е изд. - СПб.: Питер, 2003. - 480 с.

.Партыка Т. Л. Информационная безопасность / Т.Л Партыка. - М.ИНФРА-М, 2002. - 367 с.

.Петров, В. Н. Информационные системы: учеб. пособие для вузов / В.Н Петров. - СПб.: Питер, 2002. - 688 с.

.Савицкая Г. В. Анализ хозяйственной деятельности предприятия / Г. Савицкая.-Учебник. - М.: Инфра-М, 2003. - 400 с.

.Савицкий Н. И. Экономическая информатика / Н.И Савицкий. - М.: Экономист, 2004. - 429 с.

.Смирнова Г. Н. и др. Проектирование экономических информационных систем: Учебник / Г.Н Смирнова, Под ред. Ю. Ф. Тельнова. - М.: Финансы и статистика, 2002. - 512 с.

.Фаронов И. В. Программирование баз данных в Delphi 7: учебный курс / И.В Фаронов. - СПб.: Питер, 2005. - 295 с. : ил.

.Чекалов А. Базы данных: от проектирования до разработки приложений А. Чекалов. - СПб: BHV, 2003. - 384 c.

.Шкарина Л. Язык SQL:учебный курс / Л.Шкарина. - СПб.: Питер, 2001.

ПРИЛОЖЕНИЕ 1

Листинг программного продукта

Ниже представлен листинг программного продукта.

unit LogUnit;, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, ExtCtrls, StdCtrls, Mask, DBCtrls, jpeg;

= class(TForm): TPanel;: TImage;: TLabel;: TLabel;: TMaskEdit;: TButton;: TEdit;Button1Click(Sender: TObject);

{ Private declarations }

{ Public declarations };

: TLogForm;

DMUnit, MainUnit;

{$R *.dfm}

TLogForm.Button1Click(Sender: TObject);Access:boolean;,b,Empt:string;:=Edit1.Text;:=MaskEdit1.Text;:=false;(Dm.User.RecordCount=0) or (not Dm.ADOConnection1.Connected) then(Edit1.Text='Admin') and (MaskEdit1.Text='111') then Access:=true.User.First;not (Dm.User.Eof) do(a=Dm.User.FieldByName('Логин').AsString) and (b=Dm.User.FieldByName('Пароль').AsString) then Access:=true;.User.Next;;;Access then.User.Locate('Логин', a,[]);.StatusBar1.Panels[1].Text:=Dm.User.FieldByName('ФИО').AsString;.Filter:='';.Adm.Locate('КодПрава',Dm.User.FieldByName('КодПрава').AsInteger,[]);(Dm.Adm.FieldByName('Название').AsString='Администратор') or (Edit1.Text='Admin') then MainForm.N4.Visible:=trueMainForm.N4.Visible:=false;.Form:=Dm.Adm.FieldByName('Формирование').AsBoolean;.Utv:=Dm.Adm.FieldByName('Утверждение').AsBoolean;.Isp:=Dm.Adm.FieldByName('Исполнение').AsBoolean;.UserIndex:=Dm.User.FieldByName('КодПользователя').AsInteger;;.TabSheet1.Show;.Show;.Visible:=False;;;

.

MainUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,

Dialogs, ComCtrls, Menus, ExtCtrls, Grids, DBGrids, StdCtrls;

type= class(TForm): TPanel;: TPageControl;: TTabSheet;: TTabSheet;: TTabSheet;: TMainMenu;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TStatusBar;: TDBGrid;: TDBGrid;: TDBGrid;: TMenuItem;: TMenuItem;: TButton;: TButton;: TButton;: TButton;: TButton;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TMenuItem;: TTimer;TabSheet1Show(Sender: TObject);TabSheet2Show(Sender: TObject);TabSheet3Show(Sender: TObject);N5Click(Sender: TObject);N6Click(Sender: TObject);FormClose(Sender: TObject; var Action: TCloseAction);FormShow(Sender: TObject);N7Click(Sender: TObject);Timer1Timer(Sender: TObject);N11Click(Sender: TObject);N10Click(Sender: TObject);N14Click(Sender: TObject);N8Click(Sender: TObject);N9Click(Sender: TObject);N12Click(Sender: TObject);N13Click(Sender: TObject);Button4Click(Sender: TObject);Button5Click(Sender: TObject);Button3Click(Sender: TObject);Button2Click(Sender: TObject);Button1Click(Sender: TObject);

{ Private declarations }

{ Public declarations };: TMainForm;, Isp, Form:boolean;: integer;:string;

DMUnit, LogUnit, AdmUnit, ClientsUnit, CountryUnit, DepUnit, PostUnit,, RuleUnit, FIUnit;

{$R *.dfm}

TMainForm.TabSheet1Show(Sender: TObject);.Claim.Filter:='(([Сформировал]<>Null) and ([Утвердил]=Null) and ([Исполнитель]=Null))'+ Filter;.Visible:=true;.Caption:='Проверен';.Enabled:=Form;.Enabled:=Utv;.Visible:=true;;

TMainForm.TabSheet2Show(Sender: TObject);.Claim.Filter:='(([Сформировал]<>Null) and ([Утвердил]<>Null) and ([Исполнитель]=Null))'+Filter;.Visible:=true;.Caption:='Исполнен';.Enabled:=Form;.Enabled:=Isp;.Visible:=false;;

TMainForm.TabSheet3Show(Sender: TObject);.Claim.Filter:='(([Сформировал]<>Null) and ([Утвердил]<>Null) and ([Исполнитель]<>Null))'+ Filter;.Visible:=false;.Enabled:=Form;.Visible:=false;;

TMainForm.N5Click(Sender: TObject);.Hide;.Show;.Edit1.Text:='';.MaskEdit1.Text:='';;

TMainForm.N6Click(Sender: TObject);.Close;;

TMainForm.FormClose(Sender: TObject; var Action: TCloseAction);.Close;;

TMainForm.FormShow(Sender: TObject);.Claim.Filter:='([Сформировал]<>Null) and ([Утвердил]=Null) and ([Исполнитель]=Null)';.Visible:=true;.Caption:='Проверен';.Enabled:=Form;.Enabled:=Utv;.Visible:=true;.Checked:=true;;

TMainForm.N7Click(Sender: TObject);.Visible:=N7.Checked;.Top:=583;;

TMainForm.Timer1Timer(Sender: TObject);.Panels[3].Text:=DateToStr(Now);.Panels[5].Text:=TimeToStr(Now);;

TMainForm.N11Click(Sender: TObject);.Show;;

TMainForm.N10Click(Sender: TObject);.Show;;

TMainForm.N14Click(Sender: TObject);.Show;;

TMainForm.N8Click(Sender: TObject);.Show;;

TMainForm.N9Click(Sender: TObject);.Show;;

TMainForm.N12Click(Sender: TObject);.Show;;

TMainForm.N13Click(Sender: TObject);.Show;;

TMainForm.Button4Click(Sender: TObject);.Show;;

TMainForm.Button5Click(Sender: TObject);dm.Claim.Modified then Dm.Claim.Post;;

TMainForm.Button3Click(Sender: TObject);.Claim.Delete;;

TMainForm.Button2Click(Sender: TObject);.Claim.Insert;.Show;;

TMainForm.Button1Click(Sender: TObject);PageControl1.ActivePageIndex of

: Begin.Claim.Edit;.Claim.FieldByName('Утвердил').AsInteger:=MainUnit.UserIndex;.Claim.FieldByName('ДатаУтверждения').AsDateTime:=Now;.Claim.Post;;

: Begin.Claim.Edit;.Claim.FieldByName('Исполнитель').AsInteger:=MainUnit.UserIndex;.Claim.FieldByName('ДатаИсполнения').AsDateTime:=Now;.Claim.Post;;;;

.

PostUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, DBCtrls, ExtCtrls, Grids, DBGrids, StdCtrls, Mask;

= class(TForm): TDBGrid;: TPanel;: TDBNavigator;: TLabel;: TDBEdit;

{ Private declarations }

{ Public declarations };

: TPostForm;

DMUnit;

{$R *.dfm}

.

ResUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, DBCtrls, StdCtrls, Mask, ExtCtrls, Grids, DBGrids;

= class(TForm): TDBGrid;: TPanel;: TDBNavigator;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBLookupComboBox;

{ Private declarations }

{ Public declarations };

: TResForm;

DMUnit;

{$R *.dfm}

.

RuleUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, DBCtrls, Mask, ExtCtrls, Grids, DBGrids;= class(TForm): TDBGrid;: TPanel;: TDBNavigator;: TLabel;: TDBEdit;: TDBCheckBox;: TDBCheckBox;: TDBCheckBox;

{ Private declarations }

{ Public declarations };

: TRuleForm;

DMUnit;

{$R *.dfm}

.

SED;

,in 'LogUnit.pas' {LogForm},in 'DMUnit.pas' {DM: TDataModule},in 'MainUnit.pas' {MainForm},in 'CountryUnit.pas' {CountryForm},in 'ResUnit.pas' {ResForm},in 'ClientsUnit.pas' {ClientForm},in 'AdmUnit.pas' {UserForm},in 'RuleUnit.pas' {RuleForm},in 'PostUnit.pas' {PostForm},in 'DepUnit.pas' {OtdForm},in 'FIUnit.pas' {FIForm};

{$R *.res}

.Initialize;.CreateForm(TLogForm, LogForm);.CreateForm(TDM, DM);.CreateForm(TMainForm, MainForm);.CreateForm(TCountryForm, CountryForm);.CreateForm(TResForm, ResForm);.CreateForm(TClientForm, ClientForm);.CreateForm(TUserForm, UserForm);.CreateForm(TRuleForm, RuleForm);.CreateForm(TPostForm, PostForm);.CreateForm(TOtdForm, OtdForm);.CreateForm(TFIForm, FIForm);.Run;.AdmUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, DBCtrls, StdCtrls, Mask, ExtCtrls, Grids, DBGrids;

= class(TForm): TDBGrid;: TPanel;: TDBNavigator;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBLookupComboBox;: TLabel;: TDBLookupComboBox;: TLabel;: TDBLookupComboBox;

{ Private declarations }

{ Public declarations };

: TUserForm;

DMUnit;

{$R *.dfm}

.

ClientsUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, Mask, DBCtrls, ExtCtrls, Grids, DBGrids;

= class(TForm): TDBGrid;: TPanel;: TDBNavigator;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;

{ Private declarations }

{ Public declarations };

: TClientForm;

DMUnit;

{$R *.dfm}

.

CountryUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, Mask, DBCtrls, ExtCtrls, Grids, DBGrids;

= class(TForm): TDBGrid;: TPanel;: TDBNavigator;: TLabel;: TDBEdit;

{ Private declarations }

{ Public declarations };

: TCountryForm;

DMUnit;

{$R *.dfm}

.

DepUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, Mask, DBCtrls, ExtCtrls, Grids, DBGrids;

= class(TForm): TDBGrid;: TPanel;: TDBNavigator;: TLabel;: TDBEdit;

{ Private declarations }

{ Public declarations };

: TOtdForm;

DMUnit;

{$R *.dfm}

.

DMUnit;, Classes, DB, ADODB, XPMan;

= class(TDataModule): TADOConnection;: TADOTable;: TXPManifest;: TADOTable;: TADOTable;: TADOTable;: TADOTable;: TADOTable;: TADOTable;: TADOTable;: TAutoIncField;: TWideStringField;: TAutoIncField;: TWideStringField;: TBooleanField;: TBooleanField;: TBooleanField;: TAutoIncField;: TWideStringField;: TWideStringField;: TWideStringField;: TIntegerField;: TIntegerField;: TIntegerField;: TAutoIncField;: TWideStringField;: TWideStringField;: TWideStringField;: TIntegerField;: TStringField;: TAutoIncField;: TWideStringField;: TWideStringField;: TWideStringField;: TWideStringField;: TDateTimeField;: TWideStringField;: TWideStringField;: TWideStringField;: TAutoIncField;: TWideStringField;: TSmallintField;: TSmallintField;: TDateTimeField;: TDateTimeField;: TIntegerField;: TIntegerField;: TIntegerField;: TIntegerField;: TDateTimeField;: TDateTimeField;: TDateTimeField;: TAutoIncField;: TWideStringField;: TStringField;: TStringField;: TStringField;: TStringField;: TStringField;: TStringField;: TStringField;: TDataSource;: TDataSource;: TDataSource;: TDataSource;: TDataSource;: TDataSource;: TDataSource;: TDataSource;: TAutoIncField;: TIntegerField;: TStringField;ClaimAfterInsert(DataSet: TDataSet);

{ Private declarations }

{ Public declarations };

: TDM;

MainUnit;

{$R *.dfm}

TDM.ClaimAfterInsert(DataSet: TDataSet);.Claim.FieldByName('Сформировал').AsInteger:=MainUnit.UserIndex;.Claim.FieldByName('ДатаФормирования').AsDateTime:=Now;;

.

FIUnit;

, Messages, SysUtils, Variants, Classes, Graphics, Controls, Forms,, StdCtrls, Mask, DBCtrls;= class(TForm): TLabel;: TDBLookupComboBox;: TLabel;: TDBLookupComboBox;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TLabel;: TDBEdit;: TGroupBox;: TLabel;: TLabel;: TDBLookupComboBox;: TDBEdit;: TGroupBox;: TLabel;: TLabel;: TDBLookupComboBox;: TDBEdit;: TGroupBox;: TLabel;: TLabel;: TDBLookupComboBox;: TDBEdit;

{ Private declarations }

{ Public declarations };: TFIForm;DMUnit;

{$R *.dfm}.

ВВЕДЕНИЕ Потоки информации, циркулирующие в мире, который нас окружает, огромны. Во времени они имеют тенденцию к увеличению. Поэтому в любой организации

Больше работ по теме: