Преподаватель который помогает студентам и школьникам в учёбе.

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

Содержание:

ВВЕДЕНИЕ

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

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

Целью курсовой работы является автоматизация процесса управления документооборотом в филиале ФГУП «Почта России».

Объектом исследования данной курсовой работы является филиал ФГУП «Почта России».

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

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

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

- проанализировать процессы на предприятии

- разработать проекта автоматизации.

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

ГЛАВА 1. Аналитическая часть

1.1. Выбор комплекса задач автоматизации

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

Процесс управления документооборотом в филиале ФГУП «Почта России» включает несколько стадий. Рассмотрим их более подробно.

Учет и обработка входящих и исходящих писем;

Шаблон процесса доступен всем пользователям СЭД. В шаблоне процесса указаны следующие участники процесса:

- Генеральный директор (роль).

Шаблон процесса ассоциирован с видом документа «Входящее письмо».

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

Шаблон процесса доступен всем пользователям СЭД. В шаблоне процесса указаны следующие участники процесса:

1 шаг. Руководитель ИНСП (автоподстановка «Непосредственный руководитель ответственного за документ»);

2 шаг. Согласовывающие. При необходимости вводятся вручную при старте процесса. Список согласовывающих определяется автором документа;

3 шаг. Канцелярия (роль).

Шаблон процесса ассоциирован с видом документа «Исходящее письмо».

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

Обработка служебных записок;

Шаблон процесса доступен всем пользователям СЭД. В шаблоне процесса указаны следующие участники процесса:

- Руководитель ИНСП (автоподстановка «Непосредственный руководитель ответственного за документ»);

- Руководитель ИСП (автоподстановка «Адресат документа»).

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

Осуществление платежей.

Шаблон процесса доступен пользователям, входящим в рабочую группу «Конструкторский отдел» СЭД. Шаблон процесса включает в себя четыре шаблона подпроцессов: «Согласование», «Утверждение», «Исполнение» и «Ознакомление». Подпроцесс «Утверждение» автоматически запускается только при успешном завершении подпроцесса «Согласование». Подпроцесс «Исполнение» автоматически запускается только при успешном завершении подпроцесса «Утверждение». Подпроцесс «Ознакомление» автоматически запускается только при успешном завершении подпроцесса «Исполнение».

В шаблоне подпроцесса «Согласование» указаны следующие участники процесса:

Шаг 1. Казначейство (роль);

Шаг 2. Согласовывающие. Вводятся вручную перед стартом процесса.

Шаг 3. Контрактная служба (роль). Автоматически включается в маршрут, если сумма договора-основания Заявки более 100 т.р. И платеж НЕ авансовый И договор-основание Заявки НЕ КИ и НЕ ДСП;

Шаг 4. Начальник ФО (роль);

В шаблоне подпроцесса «Утверждение» указаны следующие участники процесса:

- Утверждающий Заявки на платеж (роль).

В шаблоне подпроцесса «Исполнение» указаны следующие участники процесса:

- Казначейство (роль);

В шаблоне подпроцесса «Ознакомление» указаны следующие участники процесса:

- Ответственный за документ (автоподстановка);

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

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

1.2. Характеристика существующих бизнес-процессов

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

Бизнес-процесс «Учет и обработка входящих писем» продемонстрирован в Приложении А.

Учет и обработка входящих писем

Канцелярия получает входящее письмо;
Канцелярия создает КД «Входящее письмо»;
Канцелярия регистрирует в СЭД входящее письмо;
Канцелярия вводит регистрационный номер в оригинал входящего письма;
Канцелярия сканирует и прикрепляет скан-копию оригинала входящего письма к КД;
Канцелярия запускает процесс «Рассмотрение»;
Канцелярия передает оригинал входящего письма Секретарю ГД;
Секретарь ГД получает оригинал входящего письма и задачу «Рассмотреть»;
Секретарь ГД передает оригинал входящего письма ГД;
ГД получает оригинал входящего письма и вводит резолюцию;
ГД передает оригинал входящего письма с резолюцией Секретарю ГД;
Секретарь ГД получает оригинал входящего письма с резолюцией ГД;
Секретарь ГД передает в Канцелярию оригинал входящего письма;
1. Канцелярия получает оригинал входящего письма и выдает под роспись в распечатанном из СЭД отчете «Список входящих документов»;
Секретарь ГД обрабатывает резолюцию и запускает процесс в соответствии с резолюцией;
Если в резолюции требуется ознакомление, Секретарь ГД запускает процесс «Ознакомление»;
1. ЗГД получает задачу «Ознакомиться»;
2. ЗГД знакомится с предметом задачи, решает требуется ли дальнейшее ознакомление;
3. Если не требуется, ЗГД обрабатывает задачу «Ознакомиться»;
4. Если требуется дальнейшее ознакомление, ЗГД запускает под процесс «Ознакомление» и обрабатывает задачу «Ознакомиться»;
5. Руководитель ИСП получает задачу «Ознакомиться»;
6. Руководитель ИСП знакомиться с предметом задачи, решает требуется ли дальнейшее ознакомление;
7. Если не требуется, Руководитель ИСП обрабатывает задачу «Ознакомиться»;
8. Если требуется дальнейшее ознакомление, Руководитель ИСП запускает под процесс «Ознакомление и обрабатывает задачу «Ознакомиться»;
9. Сотрудник ИСП получает задачу «Ознакомление»;
10. Сотрудник ИСП знакомиться с предметом задачи и обрабатывает задачу «Ознакомиться»;
Если в резолюции требуется исполнение, Секретарь ГД запускает процесс «Исполнение»;
1. ЗГД получает задачу «Исполнить»;
2. ЗГД знакомится с предметом задачи;
3. ЗГД запускает под процесс «Исполнение»;
4. Руководитель ИСП получает задачу «Исполнить»;
5. Руководитель ИСП знакомится с предметом задачи;
6. Руководитель ИСП запускает под процесс «Исполнение»;
7. Сотрудник ИСП получает задачу «Исполнить»;
8. Сотрудник ИСП знакомится с предметом задачи и фактически выполняет;
9. Сотрудник ИСП обрабатывает задачу «Исполнить»;
10. Руководитель ИСП получает задачу «Проверить исполнение»;
11. Руководитель ИСП проверяет фактическое выполнение;
12. Если не выполнено, Руководитель ИСП возвращает на доработку Сотруднику ИСП;
13. Если выполнено, Руководитель ИСП обрабатывает задачу «Исполнить»;
14. ЗГД получает задачу «Проверить исполнение»;
15. ЗГД проверяет фактическое выполнение;
16. Если не выполнено, ЗГД возвращает на доработку Руководитель ИСП;
17. Если выполнено, ЗГД обрабатывает задачу «Исполнить»;
18. Если требуется ознакомить с результатами, ЗГД отчитывается ГД об исполнение;
19. Если не требуется, ЗГД процесс завершается.

Бизнес-процесс «Обработка служебных записок» продемонстрирован в Приложении Б.

Обработка служебных записок

ИНСП создает КД «Служебная записка»;
ИНСП запускает процесс «Согласование служебной записки»;
Руководитель ИНСП получает задачу «Согласовать»;
Руководитель ИНСП проверяет содержание предмета задачи;
Если требуется направляет, Руководитель ИНСП
Если не согласовано, Руководитель ИНСП обрабатывает задачу «Не согласовать» и вводит комментарии;
1. ИНСП получает задачу «Ознакомиться с результатами согласования»;
2. ИНСП устраняет замечания в соответствии с комментариями;
3. Если в комментариях указан ЗГД по направлению, ИНСП добавляет ЗГД по направлению в маршрут процесса и повторяет процесс «Согласование»;
Если согласовано, Руководитель ИНСП обрабатывает задачу «Согласовать»;
Руководитель ИСП получает задачу «Согласовать»;
Руководитель ИСП проверяет содержание предмета задачи;
Если не согласовано, Руководитель ИСП обрабатывает задачу «Не согласовать»;
1. ИНСП получает задачу «Ознакомиться с результатами согласования»;
2. ИНСП устраняет замечания в соответствии с комментариями;
3. Если в комментариях указан ЗГД по направлению, ИНСП добавляет ЗГД по направлению в маршрут процесса и повторяет процесс «Согласование»;
Если согласовано, Руководитель ИСП обрабатывает задачу «Согласовать»;
1. ИНСП получает и обрабатывает задачу «Ознакомиться с результатами согласования»;
Руководитель ИСП запускает процесс «Исполнение служебной записки» (в качестве проверяющего указывается ИНСП);
ИСП получает задачу «Исполнение» и осуществляет фактическое исполнение;
ИСП обрабатывает задачу «Исполнить» (в комментарии вводит отчет об исполнении);
ИНСП получает задачу «Проверить исполнение»;
Если не выполнено, ИНСП возвращает на доработку в ИСП;
Если выполнено, ИНСП обрабатывает задачу «Исполнение».

Бизнес-процесс «Осуществление платежей» продемонстрирован в Приложении В.

Осуществление платежей (Текущие платежи)

ИНСП создает КД «Заявка на платеж»;
ИНСП запускает комплексный процесс по шаблону «Обработка заявки на платеж»;
ИСП получает задачу «Согласовать», «Согласовать заявку на платеж»;
ИСП проверяет предмет задачи;
Если не согласовано, ИСП обрабатывает задачу «Согласовано» с результатом «Не согласовано» с вводом комментария;
1. ИНСП получает задачу «Ознакомиться с результатом согласования»;
2. ИНСП устраняет замечания в соответствии с комментарием и повторяет процесс «Согласование»;
Если согласовано, ИСП обрабатывает задачу «Согласовать» с результатом «Согласовано»;
Согласовывающие получают задачу «Согласовать», «Согласовать заявку на платеж»;
Согласовывающие проверяет предмет задачи;
Если не согласовано, Согласовывающие обрабатывает задачу «Согласовано» с результатом «Не согласовано» с вводом комментария;
1. ИНСП получает задачу «Ознакомиться с результатом согласования»;
2. ИНСП устраняет замечания в соответствии с комментарием и повторяет процесс «Согласование»;
Если согласовано, Согласовывающие обрабатывает задачу «Согласовать» с результатом «Согласовано»;
Если сумма договора-основания заявки более 100 т.р. И платеж НЕ авансовый и договор-основание Заявки НЕ КИ и НЕ ДСП, КС получают задачу «Согласовать», «Согласовать заявку на платеж»;
1. КС проверяет предмет задачи;
2. Если не согласовано, КС обрабатывает задачу «Согласовано» с результатом «Не согласовано» с вводом комментария;
  1. ИНСП получает задачу «Ознакомиться с результатом согласования»;
  2. ИНСП устраняет замечания в соответствии с комментарием и повторяет процесс «Согласование»;
3. Если согласовано, КС обрабатывает задачу «Согласовать» с результатом «Согласовано»;
Начальник ФО получает задачу «Согласовать», «Согласовать заявку на платеж»;
Начальник ФО проверяет предмет задачи;
Если не согласовано, Начальник ФО обрабатывает задачу «Согласовано» с результатом «Не согласовано» с вводом комментария;
1. ИНСП получает задачу «Ознакомиться с результатом согласования»;
2. ИНСП устраняет замечания в соответствии с комментарием и повторяет процесс «Согласование»;
Если согласовано, Начальник ФО обрабатывает задачу «Согласовать» с результатом «Согласовано»;
1. ИНСП получает и обрабатывает задачу «Ознакомиться с результатом согласования»;
Утверждающий получает задачу «Утвердить»;
Утверждающий проверяет предмет задачи;
Если не утверждено, Утверждающий обрабатывает задачу «Утвердить» с результатом «Не утверждено» и вводом комментария;
1. ИНСП получает задачу «Ознакомиться с результатами утверждения»;
2. ИНСП решает продолжаем ли мы работу с документом;
3. Если не продолжаем работу, то ИНСП заканчивает процесс, Конец;
4. Если продолжаем работу, ИНСП устраняет замечания в соответствии с комментариями и повторяет процесс «Утверждение»;
Если утверждено, Утверждающий обрабатывает задачу «Утвердить» с результатом «Утверждено»;
1. ИНСП получает и обрабатывает задачу «Ознакомиться с результатом утверждения»;
ИСП получает задачу «Исполнить», «Осуществить платеж по заявке»;
ИСП регистрирует заявку на платеж и осуществляет платеж по заявке (вне СЭД);
ИСП обрабатывает задачу «Исполнить», «Осуществить платеж по заявке»;
1. ИНСП получает задачу «Ознакомиться» с комментарием «Платеж по заявке осуществлен»;
2. ИНСП обрабатывает задачу «Ознакомиться»;
ИСП размещает файл платежного поручения в разделе «Файлы»;
ИСП запускает процесс «Ознакомление» по шаблону «Ознакомление КС с платежным поручением»;
1. КС получает и обрабатывает задачу «Ознакомиться».

1.3. Характеристика документооборота, возникающего при решении задачи

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

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

Рисунок 1. Документооборот в компании «МТС»

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

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

Технические средства, применяемые на стадиях обработки заявки

Таблица 1

Этап №	Программные и технические средства
A1	Компьютер пользователя, почтовый клиент
A2, А3,А4	Сервер приложений, БД, ПО системы SD, почтовый сервер
A5	Компьютер инженера или администратора
A6	Компьютер администратора, ПО системы SD

Отразим соотношение текущих показателей затрат на реализацию анализа и исполнения заявки (таблица 2).

Соотношение показателей затрат на анализ и исполнение заявки

Таблица 2

Показатели	Имеется	Планируется
Число потерянных заявок за месяц	5-7 шт	0 шт
Время реакции на какую-либо претензию от клиента	1-20 мин	1-3 мин
Отношение числа обработанных заказов ежедневно вручную к автоматически обработанным	500\0 шт	500\350 шт

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

При применении CRM-системы оптимизированная диаграмма декомпозиции («TO-BE» – как должно быть) приведены на рисунке 2.

$Описание: C:\Documents and Settings\Admin\Рабочий стол\материалы д\скрины бп\4.JPG$

Рисунок 2. Диаграмма декомпозиции TO-BE

Необходимо автоматизировать процесс документооборота «МТС», прежде всего для того, чтобы выстроить эффективную систему работы компании в целом, а также при работе с клиентами. Каждая сделка не должна быть потеряна, должна сопровождаться определенной задачей. Автоматизация способствует сокращению временных затрат, а также постепенному наращиванию клиентской базы [18, c.61].

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

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

1.3. Обоснование проектных решений по информационному обеспечению

Информационное обеспечение (ИО) состоит из:

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

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

- информационной базы.

Классификатор – это систематизированный свод наименований группировок объектов, признаков и их кодовых обозначений [6, c.39]. Классификаторы являются средством описания сведений, аргументируют единство классификации и кодирования данных и необходимы для выполнения машинного анализа данных в удобной форме пользователям при выполнении разнообразных задач. Исходя из области применения, классификаторы делятся на 3 группы:

- общегосударственные;

- отраслевые;

- локальные [2, c.78].

В данной работе будет применяться лишь локальный классификатор, поскольку в иных классификаторах нет необходимости. Заказы будут делиться по приоритету, по компании и по зоне ИТ, к которой относится тот или иной заказ.

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

В данной работе применяются локальные документы: «Заявка на закупку материальных ценностей», «Заявка на регистрацию пользователя и доступ к программным ресурсам», «Заявка на устранение неполадок», «Заявка на доступ к сетевым ресурсам». Информационные файлы разрабатываются на базе исходных данных, имеющихся в названных первичных документах - ключевых носителях первичной экономической информации в системах ее машинной обработки [7, c.98]. Помимо всего прочего есть следующие требования, которые к ним устанавливаются:

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

- исключение избыточных данных;

- достоверность и актуальность данных;

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

- логичность создания документа.

Есть 3 способа организации информационной базы (ИБ): файловая, интегрированная, смешанная.

Под файловой организацией ИБ определено локальное расположение базы на ПК, доступ к которому других пользователей реализуется стандартными методами ОС для обмена данными по сети, например, в MS Windows – это Sharing и Security, что замедляет анализ информации в БД. Под смешанной организацией ИБ предполагается распределённая БД, установленная на нескольких серверах и создающая изменения в каждой из них по расписанию. Такая структура ИБ применяется в системах класса ERP для функционирования в одной ИБ территориально удалённым офисам одновременно.

Интегрированный способ организации ИБ является комплексом взаимосвязанных и расположенных вместе сведениях при такой наименьшей избыточности, которая позволяет их применение наилучшим образом для любых приложений, и в данном случае выполняется независимость сведений от программы, а для актуализации данных применяется общий способ управления [11, c.56].

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

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

В иерархической модели каждой информационной единице (сегменту), кроме корневого, соответствует один исходный сегмент и между ними создается лишь одна связь. В таких моделях экземпляру исходного сегмента соответствует в общем случае определенное количество экземпляров порожденного сегмента. Данные структуры удобны для отображения отношений типа «один ко многим» в предметной области. Обзор такой структуры имеет место быть лишь с корневой вершины. Пропуск сегмента в иерархическом пути при доступе к определенному сегменту не позволяется [8, c.65]. Ключевые недостатки иерархической структуры: сложность (неэффективность) отображения отношений типа «многие ко многим»; долгое время обеспечения доступа к сегментам, состоящих на нижних уровнях иерархии; направленность на некоторый тип (разрез) запроса.

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

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

Достоинства применения реляционных БД, следующие:

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

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

- независимость данных – когда нужно изменить структуру БД, то это ведет к минимальным изменениям в программе [27, c.15].

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

Исходные данные для выполнения установленной задачи получают из таких документов, как:

- e-mail от работника фирмы с описанием проблемы на неформальном языке в ИТ-области;

- регламент работы службы горячей линии;

- ежедневное письмо о нахождении работников ИТ-отдела по всем направлениям;

- письма, определяющие изменения ответственных лиц по установленным направлениям инцидентам и новым направлениям [6, c.55].

Результаты выполнения задачи видны в таких отчетах и документах, как:

- отчет по согласованным заказам;

- отчет заказов по местоположению клиента;

- отчет о логике назначения клиента.

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

Описание применяемых классификаторов Таблица 3
Наименование кодируемого множества объектов	Значимость кода	Система кодирования	Система классифи-кации	Вид классифи-катора
Регион	4	Порядковая	Нет	Локальный
Город	4	Порядковая	Нет	Локальный
Улица	4	Порядковая	Нет	Локальный
Код описания неисправности	4	Порядковая	Нет	Локальный

1.5. Обоснование проектных решений по программному обеспечению

Программное обеспечение (ПО) - комплекс программ системы обработки информации и программных документов, нужных для работы таких программ. ПО необходимо для придания ИС некоторых свойств, связанных с ростом производительности, достоверности получаемых результатов, надежности работы системы, оптимизации работы пользователя [18, c.35].

Критериями выбора ПО, присутствующего на ПК пользователей, является максимальное сокращение времени описания проблемы пользователей и отправки ее по e-mail. В разрезе корпоративного стандарта на предприятии ЗАО «Промет» применяется MS Outlook 2003. Для работы данной программы на ПК нужно установить ОС, которая поддерживает работу такого приложения. Ввиду корпоративного стандарта используется версия ОС MS Windows XP PRO, поскольку это самая ранняя версия ОС, поддерживаемая компанией Microsoft в нашей стране и способная функционировать в доменной инфраструктуре. Учитывая все вышесказанное, Win XP Pro sp3 Rus будет применяться в роли пользовательской ОС. Итог: на рабочих станциях пользователей нужно установить такие программные продукты, как:

- ОС Windows XP Pro sp3 Rus;

- почтовый клиент MS Outlook 2003.

Программа-служба (сервис) по обработке e-mail – это программа, созданная на скриптовом языке Python, постоянно анализирующая общий почтовый ящик ИТ-отдела и обрабатывающая входящие письма, формирующая и изменяющая заказы в БД, при этом распределяя их между свободными менеджерами, или ставящая их на поток [30, c.189]. Учитывая все факты, был выбран язык 1С для проектирования данной работы.

Критериями выбора архитектуры реализации проектируемого программного комплекса являются:

- совместимость с текущей инфраструктурой серверов;

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

При определении ОС под это решение был определен MS Windows Server 2003, поскольку такой вид серверных ОС не очень требователен к ресурсам, а также давно применяется в инфраструктуре компании «МТС».

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

Варианты СУБД систем Таблица 4
Название СУБД Характеристики	Microsoft SQL Server	InterBase	Oracle 11.2.0.1
Интегированная аутентификация пользователей	+	+	-
Мониторинг работы БД	+	+	+
Возможность создания временные таблицы	+	+	+
Ведение журнала действий с БД и подключение	+	+	+

СУБД для программы будет являться Oracle 11. Данный выбор сделан не просто так, главная ИС учёта заявок HP OpenView Service Desk строится как раз на этой БД.

Покупать новый сервер не нужно, поскольку БД программного продукта может находиться на уже существующем сервере «SD». При создании нового сервера фирмы заложила примерно половину мощности закупаемого сервера на дальнейшую масштабируемость ИС, но загруженность сервера увеличилась только на 15%, тогда как БД за 3 года непрерывно наращивалась [18, c.77].

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

ГЛАВА 2. Проектная часть

2.1. Информационная модель и ее описание

Для проектирования и реализации АИС на предприятии была выбрана технологическая платформа «1С: Предприятие 8.3». Это технологическая платформа мирового уровня, предназначенная для решения широкого спектра задач автоматизации управления и учета на современном предприятии.

Платформа «1С: Предприятие 8.3» обеспечивает эффективную работу и надежное хранение информации при одновременной работе в единой базе необходимого числа пользователей. Трёхуровневая архитектура системы позволяет сохранить высокую производительность при значительном росте нагрузки на систему и объёмов обрабатываемых данных. Высокая отказоустойчивость достигается за счет резервирования кластера серверов, а оптимизация быстродействия – за счет динамической балансировки нагрузки между кластерами [9].

Далее представлены основные возможности платформы «1С: Предприятие 8.3» [10]:

Масштабируемая отказоустойчивая архитектура;
Поддержка крупных корпоративных систем;
Многоплатформенность, поддержка открытого ПО:
- Linux, Windows, Mac OS;
- PostgreSQL, MS SQL Server, IBM DB2, Oracle Database.
Работа через интернет, облачные технологии (SaaS);
Работа на мобильных устройствах под Android, iOS, Windows;
Гибкость и настраиваемость. Кастомизация под специфику бизнес-процессов и ноу-хау организаций;
Встроенные средства бизнес-аналитики;
Построение территориально-распределенных систем;
Открытость, интеграция практически с любыми программами и оборудованием;
Разграничение и контроль доступа к данным;
Защита конфиденциальной информации, коммерческой тайны, персональных данных.

Использование промышленных СУБД PostgreSQL, MS SQL Server, IBM DB2, Oracle Database позволяет строить высокопроизводительные и надежные информационные системы. Тонкий клиент и веб-клиент обеспечивают работу пользователей через интернет, в том числе по мобильным каналам связи. Веб-клиент не требует предварительной установки на компьютер пользователя [8]. Все эти сетевые взаимосвязи показаны на рисунке 3.

Рисунок 3. Сетевые взаимосвязи технологической платформы «1С: Предприятие 8.3»

В технологической платформе «1С: Предприятие 8.3» встроена среда разработки и называется «Конфигуратор» со встроенным языком программирования 1С.

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

Рисунок 4. Окно системы в режиме «1С: Предприятие 8.3»

На каждом этапе разработки должны быть выработаны четкие критерии оценки успеха, а также желательно сопровождать их подписанием отдельных договорных документов. В плане также стоит предусмотреть возможность изменений, внесения корректив, и тогда итогом выполнения разработки будет прекрасно налаженная, хорошо адаптированная к работе предприятия и грамотно структурированная АИС [10].

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

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

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

На разработку ИС фирмы в настоящее время оказывает воздействие не только уровень организации формы управления и средств ТО, но и современные подходы к самой идее проектирования [22, c.41].

Рисунок 5. Декомпозиция проекта внедрения ИС

Создание проектной команды является ответственной стадией в ходе осуществления проекта. При создании проектной команды нужно принимать во внимание личностные и психологические качества участников проекта, а также руководствоваться критериями подбора участников проекта [11, c.234].

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

В данном разделе необходимо описать таблицы или файлы с указанием полей, образованных при реализации запросов. В данном случае необходимо также указать на основе каких таблиц с переменной или условно-постоянной информацией БД были получены таблицы с результатной информацией, и какой документ получается в результате. Затем нужно привести ключевые параметры каждой таблицы с указанием, подлежит ли она последующему хранению или нет [21, c.44].

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

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

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

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

Для конечных файлов описывается:

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

- частота их формирования;

- на основе каких таблиц они строятся;

- каким путем они доходят до ИС – получателя файла.

2.4. Общие положения (дерево функций и сценарий диалога)

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

Рисунок 6. Диаграмма прецедентов

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

Актёры:

«Генеральный директор» (владеет и управляет всей информацией на предприятии: о заказах, клиентах, сотрудниках, поставках, подрядчиках, материалах);
«Заместитель генерального директора» (ведет работу с клиентами до заключения договора);
«Канцелярия» (работает с документацией, её составление, редактирование, проведением, а также формирует отчеты);
«Бухгалтерия» (производит все бухгалтерские и сметные расчеты);
«Финансовый отдел» (создает финансовый план на год для предприятия).

На основе всего вышеперечисленного можно выделить следующие прецеденты:

Управление информацией о сотрудниках
Управление информацией о клиентах
Заключение договоров
Работа с клиентами
Управление информацией о поставках
Управление информацией о закупках
Регистрация документов
Составление документов
Анализ данных
Внутренние документы
Корреспонденция
Отправка на резолюцию
Составление отчетов
Работа с расчетами
Работа со сметами
Трудозатраты подчинённых
Ежедневные отчеты
Виды работ
Финансовый контроллинг
Казначейство
Учет
Управление бизнес-процессом
Формирование платёжного календаря
Организация и ведение бухгалтерского учета
Организация и ведение налогового учета

2.5. Структурная схема пакета (дерево вызова программных модулей)

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

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

В таблице 5 приведено описание всех модулей структурной схемы пакетов.

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

Таблица 5

Наименование модуля	Функционал модуля
Форма «Основная процедура работы сервиса»	Содержит в себе глобальные переменные, процедуры и функции. Основная работа начинается с этого модуля
Форма «Журнал созданных заявок в одну итерацию»	Форма формирования и отправки отчета созданных заказов в одну итерацию
Форма «Журнал обработанных заявок»	Форма формирования и отправки отчета обработанных заявок
Форма «Авторизация»	Содержит запрос логина и пароля для входа в web-интерфейс программы
Форма «О программе»	Краткая информация о созданной программе

2.6. Описание программных модулей

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

Этот программный код описан в виде блок-схемы, изображенной на рисунке 8.

Рисунок 8. Блок-схема функционирования главного модуля Main

2.7. Контрольный пример реализации проекта и его описание

Запускаем «1С: Предприятие». В открывшемся диалоге видим список информационных баз, с которыми мы работаем. Выбираем «1С: Предприятие», как показано на рисунке 9.

Рисунок 9. Выбор интерфейса «1С: Предприятие»

Далее перед нами выскакивает окно авторизации пользователя (рисунок 10). Если пароль или имя пользователя введены неправильно выскакивает окно ошибки авторизации, как показано на рисунке 11.

Рисунок 10. Авторизация пользователя

Рисунок 11. Ошибка авторизации пользователя

На рисунке 12 показан общий интерфейс программы.

Рисунок 12. Интерфейс программы внутренних документов

Далее мы переходим в иерархию внутренних документов, как показано на рисунке 13.

Рисунок 13. Иерархия внутренних документов в программе

На рисунке 14 показан пример создания служебной записки.

Рисунок 14. Создание служебной записки

ЗАКЛЮЧЕНИЕ

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

В проекте исследуются все стадии управления документооборотом, от аналитической разработки проекта до внедрения проекта в компанию «МТС».

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

Проект исследует задачи оптимизации процесса управления документооборотом применительно к компании «МТС».

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

В проекте выполнены задачи автоматизации процесса управления документооборотом компании «МТС», а именно:

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

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

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

СПИСОК ИСПОЛЬЗУЕМОЙ ЛИТЕРАТУРЫ

Абрютина М.С., Грачев А.В. Анализ финансово-экономической деятельности предприятия: учебно-практическое пособие / М.С. Абрютина. - 2-е изд., испр. - М.: Дело и сервис, 2014. - 256с.
Архипов, А.И., Сенчагов, В.К. Финансы. Денежное обращение и кредит: учебник / под ред. В.К. Сенчагова, А.И. Архипова. - М.: Проспект, 2013. - 496 с.
Чернышев, Ю.Г., Чернышев, Э.А. Анализ финансово-хозяйственной деятельности предприятия: учебное пособие / под ред. Чернышева Ю.Г. - М.: МарТ, 2014. - 304с.
Артеменко, В.Т., Белендир, М.В. Финансовый анализ: учебное пособие / под ред. Артеменко В.Т. - 2-е изд. - М.: Дело и сервис, 2017. - 190 с.
Баканов, М.И., Шеремет, А.Д. Теория экономического анализа: учебное пособие / под ред. Шеремета А.Д. - М.: Финансы и статистика, 2015. - 200 с.;
Балабанов, И.Т. Финансовый анализ и планирование хозяйствующего субъекта: учебное пособие / И.Т. Балабанов. - 2-е изд. доп. - М.: Финансы и статистика, 2014. - 208с.
Барановский, Н.Т. Автоматизированная обработка информации: учебник / Н.Т. Барановский. - М.: Финансы и статистика, 2014. - 94 с.
Бочаров, В.В. Финансовый анализ: учеб. пособие / В.В. Бочаров - СПб.: Питер, 2015. - 219с.
Васин, Ю.В., Лаврентьев, Л.Г., Самсонов, А.В. Эффективные программы лояльности: учебное пособие / под ред. Лаврентьева Л.Г. - М.: Альпина, 2013. - 340с.
Грузинов, В.П. Экономика предприятия: учебник / В.П. Грузинов - М.: Финансы и статистика, 2013. - 203с.
Захарьин, В.Р. Учет финансовых результатов: учебник / В.Р. Захарьин - М.: Финансы и статистика, 2014. - 139с.
Караваев В.С. Оцифровка архивных документов, 2014 – 243с.

Приложение А Бизнес-процесс «Учет и обработка входящих писем»

Приложение Б

Бизнес-процесс «Обработка служебных записок»

Приложение В Бизнес-процесс «Осуществление платежей»