ВКР

ОГЛАВЛЕНИЕ АННОТАЦИЯ.................................................. Ошибка! Закладка не определена. ВВЕДЕНИЕ .................................................................................................................. 3 ГЛАВА 1. АНАЛИЗ ДЕЯТЕЛЬНОСТИ ДИДЖИТАЛ ДИЗАЙЕ И ОБОСНОВАНИЕ НЕОБХОДИМОСТИ АВТОМАТИЗАЦИИ.............................. 4 1.1. Общая характеристика деятельности «Диджитал Дизайн» .......................... 4 1.2. Описание организационной структуры компании ......................................... 5 1.2.1. Общая характеристика отдела Разработки ................................................ 10 1.3. Описание программного и технического обеспечения ............................... 12 1.4. Описание бизнес-процесса обработки заявки на экспертизу ..................... 14 1.4.1. Анализ современного рынка программных средств оптимизации бизнеспроцессов ................................................................................................................... 14 1.4.2. Описание процесса проведения предпроектной деятельности ............... 18 1.5. Обоснование необходимости автоматизации бизнес-процесса «Обработка заявки на экспертизу» ............................................................................................... 20 ГЛАВА 2. ОБОСНОВАНИЕ СОСТАВА РЕШАЕМЫХ ЗАДАЧ И ОПИСАНИЕ ПРЕДЛАГАЕМОГО ПРОЕКТНОГО РЕШЕНИЯ ................................................. 22 2.1. Функциональное моделирование ..................................................................... 22 2.2. Состав задач подлежащих автоматизации ...................................................... 34 2.3. Описание методики и обоснование выбора технологии для решения поставленной задачи ................................................................................................. 37 2.4. Описание входной и выходной информации. ................................................. 50 2.5. Информационно-технологическая схема решения задачи «Обработка заявки на экспертизу» ........................................................................................................... 53 2.6. Проектирование запросов web-cервиса ........................................................... 55 2.7. Проектирование и настройка объектов СЭД .................................................. 60 2.8. Проектирование пользовательского интерфейса............................................ 63 ГЛАВА 3. ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ И РАСЧЕТ ПОКАЗАТЕЛЕЙ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ ........................................................... 66 3.1. Инструкция пользователя.................................................................................. 66 3.2. Расчет показателей экономической эффективности ...................................... 69 ЗАКЛЮЧЕНИЕ ......................................................................................................... 77 СПИСОК ЛИТЕРАТУРЫ............................... Ошибка! Закладка не определена. ПРИЛОЖЕНИЕ 1 ............................................ Ошибка! Закладка не определена. ПРИЛОЖЕНИЕ 2 ............................................ Ошибка! Закладка не определена. ПРИЛОЖЕНИЕ 3. ........................................... Ошибка! Закладка не определена. 2 ВВЕДЕНИЕ Повышение уровня автоматизации бизнес-процессов документооборота является одной из важных задач управления в современной рыночной экономике. Постоянный контроль перемещения документации, ее согласования и исполнения позволяет экономить время, трудозатраты и повышать производительность труда и оптимизировать рабочее время сотрудников, что чрезвычайно важно в условиях кризиса, когда необходимо получать наибольшую эффективность с наименьшими затратами. На сегодняшний день одним из векторов развития систем электронного документооборота является разработка веб-приложений, повторяющих функционал полнофункциональных клиентов, но при этом более лояльных к характеристикам аппаратного обеспечения. Также интерфейс веб-приложений легко модифицируем. Веб-приложение является кроссплатформенным решением для системы документооборота, так как работает через браузеры, доступные на любой платформе. В рамках данной работы рассматривается концептуальное решение по повышению уровня экспертизу с автоматизации помощью процесса веб-приложения формирования системы заявок на документооборота, работающего на основе веб-сервиса. Для решения поставленной задачи проведено обследование предметной области, в процессе которого была рассмотрена технико-экономическая характеристика подлежащие организации, автоматизации, выявлены и основные описана бизнес-процессы, функциональная модель рассмотренных бизнес-процессов. В данной работе были решены следующие задачи: проектирование вебсервиса доступа к системе документооборота; сформированы функциональная и логическая модели системы. Произведено проектирование и настройка объектов системы электронного документооборота для поддержки работы процесса формирования заявок на предпроектную экспертизу. 3 ГЛАВА 1. АНАЛИЗ ДЕЯТЕЛЬНОСТИ ДИДЖИТАЛ ДИЗАЙЕ И ОБОСНОВАНИЕ НЕОБХОДИМОСТИ АВТОМАТИЗАЦИИ 1.1. Общая характеристика деятельности «Диджитал Дизайн» «Диджитал Дизайн» – одна из ведущих российских ИТ-компаний, оказывающая комплексные услуги по автоматизации бизнес-процессов, обеспечивающих эффективную деятельность предприятий и организаций: внедрение мобильных решений, систем электронного документооборота, корпоративных порталов, инфраструктурных решений, разработке программного обеспечения на заказ. Главная цель работы – повышение эффективности деятельности заказчиков при помощи информационных технологий. Со дня основания экспертами компании реализовано более двух тысяч проектов в различных проектов в государственных организациях и различных отраслях бизнеса: строительстве, торговле, страховании, транспорте. Надежные отношения с партнерами и заказчиками, а также высокий уровень качества выпускаемого продукта позволяют компании не терять лидирующие позиции на рынке информационных технологий и привлекать новых клиентов []. «Диджитал Дизайн» — обладатель многочисленных сертификатов качества (ISO 9001, SEI CMMI, EFQM). В настоящее время в компании работает около 500 высококвалифицированных специалистов. Компания имеет два представительства, которые расположены в Санкт-Петербурге и Москве. «Диджитал Дизайн» ведет деятельность в следующих направлениях 1. Проектирование, разработка, внедрение и сопровождение заказного и тиражируемого программного обеспечения; 2. Проектирование, реализация и сопровождение инфраструктуры ИС; 3. Обучение в области ИТ. Каждое направление деятельности развивается одной или несколькими бизнес-единицами (департаментами или отделами), в которых могут быть выделены линии соответствующие разрабатываемыми в компании. 4 определенным продуктам, 1.2. Описание организационной структуры компании Рассмотрим организационную структуру компании. Организационная структура компании «Диджитал Дизайн» линейно-функциональная (рисунок 1.1). Об этом можно судить исходя из линейного подчинения каждого подразделения руководителю компании и функционального деления компании на подразделения. Также в основе данной схемы лежит принцип функциональной департаментализации (процесс деления организации на отдельные элементы, каждый из которых имеет свою четко определенную, конкретную задачу и обязанности). А именно, характеристики и черты деятельности каждого отдела соответствуют наиболее важным направлениям деятельности всей организации [5]. Из схемы видно, что в структуре компании выделяются отделы и департаменты, которые формируются в соответствии с направлениями бизнеса компании и являются самостоятельными производственно-коммерческими подразделениями. Руководство подразделений находится в линейном подчинении высшего руководства компании. Внутри бизнес-единиц организационная структура матричная, так как в них выделяются группы сотрудников, отвечающие за определенный продукт, разрабатываемый конкретным отделом. Ниже, в таблице 1.1 приведено сопоставление направлений деятельности и бизнес-единиц компании. 5 Рисунок 1.1. Организационная схема компании Диджитал Дизайн 6 Таблица 1.1. Направления бизнеса бизнес-единиц Компании № Направление 1 Департамент по работе стратегическими клиентами 2 3 Задачи со Проектирование, разработка, внедрение и сопровождение заказного программного обеспечения ИС; Проектирование, реализация и сопровождение инфраструктуры ИС; Обучение в области ИТ. Бизнес-подразделение Проектирование, разработка, поставка и автоматизации документооборота и сопровождение тиражируемого программного бизнес-процессов обеспечения; Проектирование, настройка, внедрение и сопровождение ИС. Направление Аутсорсинг Проектирование, разработка, внедрение и сопровождение заказного программного обеспечения ИС для зарубежных Заказчиков. Также в структуре компании выделен Корпоративный центр, который состоит из подразделений, которые направляют, контролируют и координируют деятельность других подразделений в соответствии со своими функциями и обеспечивают общие для подразделений ресурсы и услуги. Департамент управления качеством обеспечивает технологические функции; дирекция по маркетингу занимается продажами; департамент управления персоналом обеспечивает компанию квалифицированным персоналом, отвечает за охрану труда и повышение квалификации работников; финансовоэкономический департамент отвечает за финансово-экономическую деятельность компании; юридический отдел, осуществляет юридическое сопровождение; служба информационных технологий занимается информационно-технологическим обеспечением деятельности организации. Более подробно рассмотрим, бизнес-подразделение автоматизации документооборота и бизнес-процессов, так как дипломная работа посвящена автоматизации одного из процессов данного подразделения. Бизнес-подразделение автоматизации документооборота и бизнес- процессов является самостоятельным подразделением компании «Диджитал Дизайн» и относится к числу её бизнес-единиц. Подразделение возглавляет заместитель генерального директора компании. 7 Главной задачей подразделения является предоставление клиентам компании услуг по бизнес-направлению «Консалтинг, разработка и внедрение информационных систем для повышения эффективности документооборота и других бизнес-процессов управления компанией». Для решения данных задач подразделение автоматизации документооборота и бизнес-процессов, выполняет следующие основные функции: - разработка и реализация стратегии направлений подразделения. - анализ потребностей рынка и конкурентного окружения; - планирование и проведение маркетинговых инициатив по продвижению продукции и услуг подразделения; - анализ потребностей заказчиков, разработка предложений и оценка затрат на их реализацию; - продажа продуктовых решений и сопутствующих услуг (обучение и сертификация специалистов, консалтинг, техническая поддержка); - подготовка коммерческих предложений и заключение договоров. - выполнение проектов по внедрению информационных систем, включая анализ, проектирование, разработку, тестирование, документирование, внедрение и сопровождение; - выполнение консалтинговых проектов в области бизнес-анализа и постановки бизнес-процессов управления; - формирование требований и составление планов выпуска продуктов; - разработка методических материалов и оказание консалтинговых услуг по внедрению и использованию продуктов; - организация и осуществление технической поддержки внедряемых продуктов; - подготовка бюджета доходов и расходов подразделения и контроль его исполнения; - разработка и регламентация процессов подразделения, направленная на обеспечение качества продукции, 8 на основе регламентирующей документации компании и требований применяемых национальных и международных стандартов. В подразделении автоматизации документооборота и бизнес-процессов, выделены структурные направления, осуществляющие работы по коммерческим проектам внедрения решений подразделения, техническую поддержку данных решений. Направления деятельности подразделения:  Направление систем документационного управления (СДУ) – занимается внедрением СДУ «Приоритет» на платформе Docsvision Core, автоматизирующей задачи документооборота и управления для государственных органов.  Направление автоматизации бизнес-процессов (АБП) – занимается автоматизацией бизнес-процессов предприятий и типовых задач систем электронного документооборота на платформе Docsvision.  Направление портальных решений – занимается автоматизацией бизнес-процессов компаний на платформе Microsoft Share Point Server.  Отдел разработки подразделения автоматизации документооборота и бизнес-процессов – осуществляет разработку решений для выполняемых проектов, а также занимается разработкой новых программных продуктов.  Отдел продаж – подразделения автоматизации осуществляет коммерческую деятельность документооборота, отвечает за обеспечение доходов всех направлений подразделения.  Отдел маркетинга – осуществляет маркетинговую деятельность, отвечает за привлечение клиентов бизнеса.  Группа обеспечения качества – осуществляет деятельность по регламентации деятельности. бизнес-процессов и контролирует ведение проектной В состав группы входят проектировщики пользовательских интерфейсов и дизайнеры, привлекаемые производственными подразделениями с целью выполнения проектных работ. 9 1.2.1. Общая характеристика отдела Разработки Перейдем к детальному рассмотрению деятельности Отдела разработки, который является самостоятельным подразделением компании «Диджитал Дизайн» и относится к числу бизнес-единиц. Отдел разработки осуществляет разработку решений для выполняемых проектов, а также занимается разработкой новых программных продуктов. В рамках решения данной задачи департамент выполняет следующие функции: - разработка и реализация стратегии бизнес-направлений департамента; - анализ потребностей рынка и конкурентного окружения; - формирование портфеля продуктов и предложений департамента; - анализ потребностей заказчиков, разработка предложений и оценка затрат на их реализацию; - выполнение проектов по внедрению информационных систем, включая анализ, проектирование, разработку, тестирование, документирование, внедрение и сопровождение; - выполнение консалтинговых проектов в области бизнес-анализа и постановки бизнес-процессов управления электронным документооборотом; - формирование требований заказчика к системе электронного документооборота (СЭДО); - организация и осуществление работ по внедрению СЭДО; - разработка методических материалов, а также оказание услуг по внедрению и использованию СЭДО; - организация и осуществление технической поддержки внедряемой СЭДО. Рассмотрим организационную структуру подразделения. Руководитель отдела находится в линейном подчинении у заместителя генерального директора. Внутри отдела организационная структур матричная, так как в отделе выделены группы сотрудников (различных специализаций) отвечающие за определенные проекты, но чаще всего сотрудники учувствуют в 10 нескольких проектах одновременно. Организационная схема отдела представлена на рисунке 1.2. Рисунок 1.2. Организационная схема отдела разработки. Основной функцией отдела является проведение проектных работ по разработке программного обеспечения и сопутствующих ей работ, которые проходят по типизированному плану и включают в себя несколько этапов [1]. Это предпроектная деятельность, целью которой является создание, продажа, описание и проработка проекта. Проектная деятельность, в ее рамках происходит разработка программного обеспечения, его документирование. И сопровождение, целью которого является исправление ошибок и техническая поддержка пользователей. 11 1.3. Описание программного и технического обеспечения В рассматриваемом отделе используется большой комплекс современного программного обеспечения для поддержки работы пользователей. Помимо прикладного программного обеспечения (ПО), в отделе используется инструментальное ПО, позволяющее выполнять основную деятельность компании. Рассмотрим основное ПО, используемое в отделе. На большинство клиентских рабочих станций отдела установлено следующее ПО: Операционная система Windows версий 7, 8, 8.1 редакция Enterprise, в основном отличающаяся от других редакций (Professional, Ultimate) схемой лицензирования; Современные пакеты прикладного ПО: пакет MS Office 2013 редакция Enterprise, имеющая в своем составе, в отличие полнофункциональные средства управления возможности данных. MS Lync анализа от стандартной, групповыми политиками, 2013, средство внутренней коммуникации. MS Project 2010 Professional, используется для составления планов проектов. СЭД Административное Делопроизводство 4.5 (АДП 4.5 или СЭД) на платформе DocsVision , обеспечивающая документооборот в компании; Adobe Acrobat Reader; браузер Google Chrome; антивирусное ПО Kaspersky Internet Security и др. Инструментальное ПО, которое используется для разработки, проектирования программных решений: Microsoft (MS) Visual Studio 2012 Ultimate (и выше), MS SQL Management Studio 2012 (и выше); MS Visio 2013 и др. Серверное ПО, обеспечивающее поддержку IT-инфраструктуры предприятия: операционная система серверов Windows Server 2012R2. Пакет прикладного программного обеспечения SQL Server 2012/2014; MS Project Server 2010, MS Exchange Server, MS Серверный пакет СЭД DocsVision. Все рабочие места сотрудников оснащены персональными компьютерами, с обеспечением выхода в интернет по локальной сети, 12 безопасность доступа к рабочим местам обеспечена программными средствами операционной системы Windows. Локально-вычислительная сеть компании состоит из следующих элементов: - сервер приложений, на котором выполняются прикладные части клиентсерверных программных приложений; - файловый сервер, служит для выполнения функций по управлению локально-вычислительной сетью, в также обеспечивает хранение и обмен файлами, предоставляет доступ к совместно используемому дисковому пространству; - почтовый сервер, обеспечивает передачу и получение электронных сообщений как внутри сети, так и вне ее; - сервер удаленного доступа, предоставляет возможность удаленного доступа к информации, хранящейся в сети предприятия; - коммутатор, необходим для соединения в единый узел нескольких компьютеров (узлов) или сегментов сети; - маршрутизатор – он связывает узлы локально-вычислительной сети и обеспечивает наиболее оптимальный маршрут доставки пакета данных до его получателя; - сервер служб каталогов, используется для хранения, поиска и защиты данных и информации от несанкционированного доступа. Инфраструктура программно-технического обеспечения в компании находится на высоком уровне: используются актуальные версии программных продуктов, технические средства проходят модернизацию, в соответствии с производственными потребностями. 13 1.4. Описание бизнес-процесса обработки заявки на экспертизу 1.4.1. Анализ современного рынка программных средств оптимизации бизнес-процессов Одним из важных моментов описания деятельности организации является формализация его бизнес-процессов или, как ее еще называют, функциональное моделирование. В настоящее время существует множество различных методологий и программных средств моделирования и оптимизации бизнеспроцессов. Моделирование бизнес-процессов является средством описания деятельности организации, позволяющее находить пути устранения узких мест в её деятельности [6]. Функциональное моделирование позволяет определить процессы деятельности предприятия и выделить узкие места, построить модели изучаемых процессов, позволяющие оптимизировать существующий процесс. Методологией описания бизнес-процессов называют совокупность способов, с помощью которых можно представить в виде модели объекты реального мира и их взаимосвязи, причем каждому объекту соответствует ряд характеристик (атрибутов) [8, 15]. Наиболее распространенными в современном мире методологиями описания бизнес-процессов являются: нотация IDEF0, IDEF3, BPMN, UML и другие. Рассмотрим подробнее некоторые из них. Нотация IDEF0, задает логическое описание структуры процесса, и представляет собой набор взаимосвязанных функций. Данная методология описывает функциональную модель организации, когда объект изучения представляет собой набор взаимосвязанных функций, то есть функциональных блоков [2]. Обычно IDEF0 применяют на начальных стадиях проектирования систем для решения таких задач как: - построение и оптимизация производственных бизнес-процессов; - оптимизация управленческой деятельности; - комплексное проектирование информационных систем; - описание функциональных возможностей информационной системы [13]. 14 IDEF0 широко известен и распространен в области информационных технологий, он относительно прост в применение и достаточно лаконичен, модели, строго формализован, описанные в соответствии со стандартом IDEF0, имеют высокую информативность. Методология IDEF0 имеет некоторые недостатки, например, сложность понимания моделей больших иерархических систем; отсутствие поддержки объектно-ориентированного проектирования; невозможность отобразить неидеальные варианты выполнения процесса из-за линейного описания бизнеспроцессов, отсутствует возможность добавления атрибутов к элементам модели [15]. IDEF3 является методологией поведенческого моделирования: документирования процессов, происходящих в системе. Она основана на построении сценария процесса, моделирующего последовательность действий, происходящих в системе. Модель предполагает структурное описание процессов и представляет собой упорядоченную последовательность событий [7]. Методология IDEF3 применяется для решения таких задач как: - документирование технологии процессов; - анализ влияния сопутствующего документооборота на сценарии технологических процессов; - разработка имитационных моделей процессов; - выявление ситуаций, влияющих на жизненный цикл процессов и требующих незамедлительного принятия решений. В целом IDEF3 применяется для описания процессов нижнего уровня и выбора альтернатив возможных решений, в зависимости от окружения бизнеспроцесса. Основным преимуществом нотации IDEF3 является возможность описания последовательности выполнения процесса в концепции «если то, иначе». Недостатком моделей, описанных по данному стандарту, является 15 слабая информативность и, в следствие, необходимость использования при моделировании моделей IDEF0 [14]. Нотация BPMN описывает бизнес-процессы нижнего уровня и является одной из нотаций построения процессных моделей. Модель процесса в BPMN – это алгоритм выполнения процесса, с возможностью детализации на более низкие уровни. Преимуществами методологии BPMN является использование интуитивно понятного набора элементов, высокая информативность моделей, моделирование алгоритма выполнения процесса. Методология BPMN не описывает модель данных, бизнес-правила, функциональные схемы, организационные процессы - это является одним из недостатков нотации моделирования [9]. Также недостатками являются отсутствие элементов, представляющих материальные потоки; сложность моделирования больших иерархических систем; сложность освоения нотации. UML - является графическим объектно-ориентированным языком моделирования, предназначенным для документирования, визуализации, конструирования программных систем [10]. Он формализует функциональные требования к системе, описывает поведение проектируемой системы, описывает архитектуру программной системы, ее элементы и способы их взаимодействия, позволяет описывать сложные системы, путем детального проектирования. Явными преимуществами языка моделирования UML являются, поддержка объектно-ориентированного проектирования, описание возможных аспектов поведения системы, изучение системы с различных точек зрения. Недостатками языка UML являются неоправданная избыточность диаграмм и конструкций и сложность языка; абстрактный синтаксис противоречащий семантике английского языка; необходимость специальной подготовки для работы с инструментами моделирования [10]. Итак, каждая методология имеет недостатки и преимущества в описании бизнес-процессов и используется для решения определенного круга задач. Для описания рассматриваемого процесса проведения предпроектной деятельности 16 наиболее подходящей будет нотация моделирования IDEF0, так как нам необходимо построить и оптимизировать производственный процесс, а также представить функции, выполняемые в рамках процесса проведения предпроектной экспертизы. Также процесс, описанный в данной нотации, будет наглядно показывать все функции, который должны быть учтены при его оптимизации. Стандарт IDEF0 основывается на четырех основных понятиях: это функциональные блоки, которые представляют собой определенную функцию в рассматриваемом процессе системы. Графическое представление функционального блока – прямоугольник, каждая сторона которого несет определенное значение: верх – управление, нижняя сторона – механизм, левая сторона – вход, правая – выход [2]. Интерфейсные дуги (или стрелки), которые используются для описания входов и выходов. Стрелки бывают четырех типов в соответствии с той стороной, в которую они входят: входы, это объекты или ресурсы, которые преобразуются в результате выполнения процесса. Управление, определяет условия и ограничения описываемого процесса. Механизмы, это средства или ресурсы, поддерживающие выполнение процесса. Выходы - это материальные или нематериальные объекты, произведенные в рамках выполнения процесса. Третье основное понятие стандарта IDEF0 – принцип декомпозиции, заключающийся в представлении сложной функции (процесса) в виде более простых, взаимосвязанных элементов, при этом глубина декомпозиции задается целями построения модели. И четвертое понятие, глоссарий. Под глоссарием в стандарте IDEF0 понимается набор ключевых слов, понятий, определений, связанных с функциональными блоками, интерфейсными дугами и характеризующий объект представленный данным элементом [2]. 17 диаграммами, 1.4.2. Описание процесса проведения предпроектной деятельности Изучив особенности деятельности отдела разработки, я хотела бы обратить внимание на процесс проведения предпроектной деятельности. Ведь она является основой для всей дальнейшей деятельности отдела. При своевременном предоставлении результатов проведения предпроектной деятельности и их высоком качестве, отдел разработки получает проект, выполнение которого приносит компании прибыль. Поэтому чрезвычайно важно, чтобы данный этап проходил без лишних задержек, слаженно и качественно. Основными задачами предпроектной деятельности являются: выявление всех пожеланий заказчика в рамках предполагаемой сделки по приобретению программного продукта и оценка трудозатрат на разработку (доработку)функциональности программного обеспечения на основе заявки на экспертизу (проведение экспертизы), подготовка коммерческого предложения, подготовка и подписание договора на оказание услуг и технического задания. Функциональная модель бизнес-процесса ASIS проведения предпроектной деятельности в нотации IDEF0 представлен на рисунках 2.1, 2.2 и 2.3 во второй главе в разделе 2.1. Хочу обратить особое внимание на процесс «Провести экспертизу», основной целью которого является оценка трудозатрат на выполнение проекта и подготовка плана работ. Декомпозиция бизнес-процесса представлена на рисунке 2.3 во второй главе разделе 2.1. Текущий алгоритм процесса выглядит следующим образом: продавцом создается заявка на проведение экспертизы, с указанием конкретного заказчика и требований к ожидаемым результатам проекта. В СЭД создается регистрационная карточка заявки на экспертизу, на основе которой владелец ресурсов определяет экспертную группу и сроки выполнения экспертизы. В СЭД экспертам высылается задание на выполнение экспертизы. В результате выполнения задания готовятся меморандум и план 18 работ, которые посредством совещаний и электронной почты согласуются между членами экспертной группы, главным экспертом и руководителем членов экспертной группы. В СЭД создается регистрационная карточка внутреннего документа «Экспертиза», к которой прикрепляются согласованный в экспертной группе меморандум и план работ, данная карточка является документом «во исполнение» к заданию, расписанному на основании заявки на экспертизу. После исполнения задания, результаты приходят инициатору экспертизы, то есть продавцу, который после проверки и необходимых обсуждений с заказчиком, может либо принять результаты экспертизы и начать готовить коммерческое предложение и техническое задание для заказчика, либо отправить экспертизу на доработку с замечаниями, тогда процесс повторяется. Бизнес-процесс и функциональная представлен в главе 2 разделе 2.1. 19 модель данной деятельности 1.5. Обоснование необходимости автоматизации бизнес-процесса «Обработка заявки на экспертизу» Подпроцессы «Инициализировать экспертизу» и «Назначить исполнителей и сроки исполнения» составляют собой процесс «Обработка заявки на экспертизу». Повышение уровня автоматизации именно этого процесса и будет рассматриваться в данной работе. В целом используемая настольная СЭД справляется с задачей обработки заявок на экспертизу. Но, так как технологии не стоят на месте, в рамках дипломного проекта предлагается перейти на использование web-версии системы для проведения предпроектных работ. Существующее решение требует размещения клиентского приложения у каждого сотрудника на рабочем компьютере, а, следовательно, дополнительных ресурсов рабочей станции. Также существующее решение не имеет клиенториентированного дизайна, дизайн достаточно лаконичен и невыразителен. В настольной версии системы много функций, неиспользуемых нашими пользователями, что с пользовательской точки зрения перегружает интерфейс программы. Таким образом, переход на web-версию СЭД позволит – - повысить мобильность СЭД (возможность обращение к системе с любого устройства через браузер); - устранить необходимость разворачивать клиентское приложение на рабочих станциях; - повысить удобство пользовательского интерфейса; - обеспечит возможность исключения из интерфейса некоторых неиспользуемых функций; - изменять дизайн сайта под свой бренд; Более того веб-версия СЭД для отдела станет пилотной разработкой, которая в дальнейшем, после устранения всех ошибок, определения путей развития, станет новым качественным продуктом, приносящим прибыль компании. 20 Вопрос о выборе пути автоматизации в данном случае не стоит. Разработка программного обеспечения будет проводиться своими силами. Во-первых, подразделение, в котором проходит автоматизируемый процесс, является разработчиком основной системы документооборота, используемой на данный момент для организации внутренних процессов отдела. Специалисты знают все особенности бизнес-процесса подразделения. А также, что в данном случае играет важнейшую роль, специалисты знают все тонкости работы основной СЭД, что позволит в кратчайшие сроки осуществить разработку базового веб-приложения, на основе функционала приложения АДП 4.5. Во-вторых, после внедрения и апробации нового решения во внутренней деятельности подразделения, отдел разработки сможет продать свою разработку заказчикам, что позволит списать все затраты на разработку приложения на стоимость готового решения при продаже. В-третьих, при разработке собственными силами нет необходимости ежегодно тратить средства на лицензирование продукта; не потребуется тратить дополнительное время на ожидание технической поддержки при возникновении проблем с приложением, как например, может случиться при покупке готового решения или привлечении сторонних разработчиков. Возможно, данный путь потребует выделения дополнительных трудовых ресурсов, но разработка собственными силами, позволит не только сделать качественный продукт, удовлетворяющий нуждам пользователей, но и повысить уровень интеллектуального капитала в компании. Привлечение сторонней организации для разработки данного приложения повлечет большие денежные и временные затраты на выполнение проекта, а также не позволит отделу развивать компетенции сотрудников в новых областях знаний, в данном случае веб-технологий. 21 ГЛАВА 2. ОБОСНОВАНИЕ СОСТАВА РЕШАЕМЫХ ЗАДАЧ И ОПИСАНИЕ ПРЕДЛАГАЕМОГО ПРОЕКТНОГО РЕШЕНИЯ 2.1. Функциональное моделирование Рассмотрим подробно модель ASIS процесса «Провести предпроектную деятельность» в нотации IDEF0 (рисунок 2.1). В бизнес-процессе «Провести предпроектную деятельность» входом является Запрос заказчика, под которым понимается обращение Заказчика в компанию с целью получения услуг в области автоматизации процесса документооборота. Запрос поступает в отдел продаж, где продавец, определяет необходимость обращения к техническому специалисту по ходу ведения переговоров с клиентом, необходимости дать ориентировочную прикидку по стоимости договора или предоставить коммерческое предложение. Выходом данного процесса является подписанный договор на оказание услуг, техническое задание на разработку, календарный план работ, а также рабочая отчётность и ключевые показатели эффективности по определенному проекту. Управляющими элементами процесса «Провести предпроектную деятельность» являются: утвержденная в организации технология работ на преддоговорном этапе и различны корректирующие мероприятия (такие как контроль со стороны руководства, консультации технических экспертов, другие инструкции и регламенты действующие в компании). Механизмом процесса является: персонал компании, и программное обеспечение (сервис экспертиз и Система Электронного Документооборота Административное Делопроизводство на платформе «Docsvision Core» (АДП 4.5 или СЭД)), электронная почта. Сервис экспертиз это портальное решение, развернутое на платформе SharePoint. В сервисе экспертиз фиксируется заявка продавца на экспертизу. В СЭД происходит процесс постановки задач на исполнение, согласование, утверждение экспертизы, Электронная почта служит средством согласования экспертизы, внутри экспертной группы. 22 Рисунок 2.1.Контекстная модель бизнес-процесса «Провести предпроектную деятельность» в нотации IDEF0 (AS IS) Процесс проведения предпроектной деятельности делится на три основных этапа. Это - Проведение экспертизы, Подготовка коммерческого предложения, Запуск работ по ходатайству (рисунок 2.2). В рамках процесса «Провести экспертизу» на основании запроса заказчика подготавливаются и утверждаются меморандум (под меморандумом понимается документ, разъясняющий работы, планируемые к проведению, в рамках заявленного для экспертизы проекта) и план работ. Входом бизнеспроцесса является Запрос заказчика, выходом – утвержденный меморандум и план работ. Управление процессом осуществляется технологией работ на преддоговорном этапе и корректирующими мероприятиями. Механизмом процесса является персонал, выполняющий роли продавца, рабочей группы, согласующих лиц и утверждающего лица, и сервис экспертиз посредством которого происходит работа по оформлению запроса заказчика, электронная 23 почта, посредством которой согласуется экспертиза и вносятся замечания внутри экспертной группы. Утвержденный меморандум и план работ – это вход бизнес-процесса «Подготовить коммерческое предложение». Результатом данного процесса, а также его выходами, являются проект договора и сам договор с заказчиком на оказание услуг, техническое задание на разработку (доработку) программного обеспечения и календарный план выполнения и сдачи работ. Причем проект договора является входом для следующего бизнес-процесса. Управление процессом осуществляется технологией работ на преддоговорном этапе и необходимыми корректирующими мероприятиями. Механизмом данного процесса служит роль продавца. Как уже было сказано выше входом бизнес-процесса «Запустить работы по ходатайству» является проект договора с заказчиком. На его основе формируется ходатайство на начало работ, (ходатайство – это документ, представляющий собой договор о начале работ, когда основной договор проходит процедуру согласования, в процессе которой уточняются и прорабатываются детали проекта, при этом фактически сделка является заключенной). Выходом этого бизнес-процесса являются различные формы отчетности и ключевые показатели эффективности работы компании. Механизмом процесса является персонал компании, выполняющий роли: продавца, руководителя бизнес-единицы и заместителя генерального директора, а также СЭД АДП 4.5, в которой проходит процесс согласования выполняемых работ по ходатайству. Рассмотрим подробнее бизнес-процесс «Провести экспертизу», ведь именно к его деталям обращена тема данной работы. На рисунке 2.3 представлена декомпозиция бизнес-процесса «Провести экспертизу»: Итак, в рамках проведения предпроектной деятельности отдела разработки осуществляет подготовку предпроектной экспертизы по заявке от продавца. 24 Целью проведения экспертизы является выявление целей проекта, оценка трудовых и денежных затрат на проведение проектных работ, постановка первоначальное минимальное планирование работ и разбиение их по этапам. 25 Рисунок 2.2. Декомпозиция контекстной модели бизнес-процесса «Провести предпроектную деятельность» в нотации IDEF0 (ASIS) 26 Во время проведения экспертизы разрабатываются, согласуются и утверждаются следующие документы: экспертиза (заявка на экспертизу задачи на согласование и выполнение экспертизы), план работ, меморандум. Процесс «Провести экспертизу» включает в себя следующие подпроцессы: 1. «Инициализировать экспертизу». Экспертизу техническую инициирует консультацию, Продавец, когда ориентировочную необходимо прикидку по получить стоимости договора или предоставить коммерческое предложение. Экспертизы бывают трех типов: - Подготовка материалов – деятельность производственного сотрудника, направленная на сопровождение и поддержку продажи, не нуждающаяся при этом в согласовании и утверждении; например, разработка макетов, формировании презентации, проведении презентации Заказчику и т.п. - Экспресс-оценка – деятельность, направленная на ориентировочную оценку трудоёмкости и длительности будущего возможного проекта. Характеризуется низкой степенью детализации оценки, не используется для формирования коммерческого предложения. - Точная оценка – направлена на максимально точное и детализированное прогнозирование длительности, трудоемкости, и состава работ по будущему проекту. На основе точной оценки впоследствии готовится коммерческое предложение, заключается договор и выполняются сами работы. Далее Продавец, создает заявку в сервисе экспертиз, где указывается следующая информация:  направление, в рамках которого будет проводиться экспертиза;  заказчик, для которого проводится экспертиза;  ссылка на возможную сделку;  набор уникальных артефактов, которые необходимо разработать (презентация, скриншоты, Меморандум, план работ и т.п.); 27  описание ограничений, уточняющие условий, формулировку задачи допущений, комментарии, и необходимого описание результата;  желаемую дату выполнения;  тип экспертизы. В зависимости от преследуемых целей выбирается один из нижеследующих типов: - Подготовка материалов, если нет нужды оценивать объём и сроки работ; - Экспресс-оценка, если необходима ориентировочная стоимость; - Точная оценка, если необходимо выставить коммерческое предложение и подготовить договор; - Уточняющая оценка, если необходимо доработать по измененным требованиям уже сделанную оценку по теме; - Техническое задание к договору, если коммерческое предложение принято Заказчиком и необходимо подготовить договор. Входом процесса «Инициализировать экспертизу» является запрос заказчика. Выходом – заявка на экспертизу в Сервисе экспертиз и в СЭД, оформленная продавцом, и задание типа «Передача получателям» на рассмотрение руководителю. Механизмом компании, выполняющий роль продавца процесса является персонал и Сервис экспертиз, СЭД. Управлением, как и в предыдущих бизнес-процессах, является технология работ на преддоговорном этапе и различны корректирующие мероприятия. В ходе данного процесса в СЭД создается Регистрационная карточка внутреннего документа типа «Заявка на Экспертизу», в карточку заносятся цели экспертизы и требования к результатам. Продавец назначает получателем карточки владельца ресурсов, регистрирует карточку и выполняет операцию «Передать получателям», в процессе выполнения которой формируется задание на рассмотрения карточки документа. Перейдем к рассмотрению второго процесса – «Назначить исполнителей и сроки исполнения». 28 2. «Назначить исполнителей и сроки исполнения» Этап назначения исполнителей и сроков выполнения экспертизы подразумевает назначение исполнителей и формирование им задания на выполнение экспертизы. Также на данном этапе уточняются сроки, содержание, условия выполнения экспертизы с продавцом. В СЭД руководитель отдел берет задание на рассмотрение «Заявки на Экспертизу» в работу и создает задание на выполнение экспертизы (в рамках создания задания назначаются исполнители и сроки проведения экспертизы). Далее происходит планирование времени проведения экспертизы и срока выполнения заявки на экспертизу. Планирование проводится в соответствии текущей загрузкой трудовых ресурсов и желаемой датой получения результатов, указанной при создании заявки продавцом, или устанавливается компромиссная дата, если невозможно выполнить экспертизу в срок. Входом процесса «Назначить исполнителей и сроки исполнения» является Заявка на экспертизу в Сервисе экспертиз. Выходом – задача на выполнение экспертизы в Сервисе экспертиз. Механизмом подпроцесса является персонал компании, выполняющий роль владельца ресурсов, СЭД и Сервис экспертиз. Управление - технология работ на преддоговорном этапе и различные корректирующие мероприятия. В СЭД владельцем ресурсов создается задание на выполнение экспертизы, в котором назначается рабочая группа, главный эксперт, расписывает задание выполнение, назначаются сроки исполнения экспертизы. Расписанное задание утверждается, в СЭД создается задание/я для выбранных исполнителей. 3. «Выполнить экспертизу» На данном этапе главному эксперту ставятся следующие задачи: - обеспечить оптимальное распределение задач между членами рабочей группы для сокращения продолжительности и трудоемкости выполнения экспертизы; - объединить и консолидировать при необходимости результаты работы разных членов рабочей группы; 29 - выдвинуть замечания и требовать их исправления; - исполнитель в ходе выполнения экспертизы обязан следить за расходованием трудозатрат и соблюдением сроков выполнения. Результатами процесса выполнения экспертизы, в зависимости от ее типа могут являться (таблица 2.1): Таблица 2.1. Результаты выполнения экспертизы № 1 2 3 4 Тип экспертизы Подготовка материалов Артефакты Определяются индивидуально продавцом на этапе инициации экспертизы и согласуются впоследствии. Например, могут быть: Макеты, скриншоты, прототипы решения, схемы; Заполнение анкет; Презентация, описание решения; Подготовка стенда. Экспресс-оценка Обязательные: План работ в MS Project (низкая степень декомпозиции задач) Меморандум (низкая степень детализации) Точная оценка/ Обязательные: Уточняющая оценка План работ MS Project (детальный, оформленный в полном соответствии с регламентом) Меморандум (детальный, в полном соответствии в принятом в подразделении шаблоном меморандума) Опциональные: Прочие по индивидуальному запросу продавца ТЗ к договору Техническое задание к договору Меморандум и План работ в MS Project предназначены для внутреннего использования и не подлежат передачи заказчику. Входом процесса «Выполнить экспертизу» является Задача на выполнение экспертизы. Выходом – результаты экспертизы: т.е. меморандум, план работ, заявленные материалы; Задача на согласование и утверждение экспертизы. Механизм и Управление аналогичны предыдущим процессам. В СЭД эксперт берет свое задание в работу, выполняет его, прикрепляет необходимые материалы и добавляет (создает) регистрационную карточку внутреннего документа «Во исполнение» задания типа «Экспертиза». В данной регистрационной карточке указываются результаты проведения экспертизы, прикрепляются файлы отражающие результаты экспертизы. Эксперт переводит свое задание в состояние «Исполнено». 30 4. «Согласовать и утвердить экспертизу» Следующим этапом экспертиза проходит процесс согласования и утверждения, в котором участвуют следующие работники компании: Продавец - инициатор заявки на проведение экспертизы, Согласующие лица (экспертная группа), Утверждающее лицо. Согласование проходит в несколько этапов. В первую очередь формируется задание продавцу, который проверяет соответствие результатов экспертизы заявленным требованиям и условиям. В случае если результатов не достигнуто или есть замечания к результатам экспертизы, продавец отправляет заявку на доработку. Если у продавца нет замечаний, то запускается согласование экспертизы. Согласование экспертиз происходит параллельно или последовательно сотрудниками из числа списка согласующих лиц, заданного на этапе назначения исполнителей. Главный эксперт объединяет результаты согласования и, при наличии замечаний, устанавливает взаимодействие с согласующими лицами, чтобы устранить их. Следующим этапом является утверждение результатов экспертизы. Утверждение экспертизы производится руководителем направления или сотрудником, назначенным в качестве утверждающего лица. При утверждении результатов окончательно проверяется соответствие заявленным требованиям и соблюдение сроков выполнения экспертизы. Если в процессе утверждения возникли замечания, утверждающее лицо возвращает экспертизу главному эксперту на доработку. Главный эксперт организует исправление замечаний и повторное согласование результатов. Утвержденная заявка отправляется Продавцу для ознакомления с итоговыми результатами и использования их в дальнейших действиях в подготовке коммерческого предложения, технического задания. Входом процесса согласования и утверждения экспертизы являются задача на согласование и результаты выполнения экспертизы в зависимости от её типа. Выходом процесса являются утвержденный меморандум и план работ. 31 Механизм процесса - персонал: согласующие лица, утверждающее лицо и продавец, электронная почта, СЭД АДП 4.5. Управление – технология работ на преддоговорном этапе. В СЭД владельцу ресурсов приходит уведомление о завершении исполнения задания. Он рассматривает результаты исполнения задания и, если у него нет замечаний, направляет задание на проверку результатов: в регистрационной карточке документа «Во исполнение» им расписывается маршрут согласования результатов экспертизы. В Маршрут согласования добавляются ранее назначенные на этапе «Назначить сроки и исполнителей экспертизы» согласующие лица и утверждающее лицо. Запускается Маршрут согласования, формируются задания согласующим лицам, в маршрут также добавляется утверждающее лицо с отличным от согласующих лиц типом визирования - утверждение. После успешного исполнения всех заданий на согласование и утверждение, маршрут переходит в состояние «Завершен». Регистрационную карточку регистрируют и добавляют со связью «Во исполнение» в задание по регистрационной карточке «Заявка на экспертизу», исполняют задание. Продавцу приходит уведомление об исполнении задания, он окончательно проверяет результаты экспертизы и, если нет замечаний, принимает результаты или, если есть замечания, отправляет задание на доработку. 32 Рисунок 2.3. Декомпозиция бизнес-процесса «Провести экспертизу» подпроцесса контекстной модели бизнес-процесса «Провести предпроектную деятельность» в нотации IDEF0 (AS IS) 33 2.2. Состав задач подлежащих автоматизации В Web-версии СЭД будут решаться следующие задачи процесса «Провести экспертизу» Формирование заявки на экспертизу. Основанием процесса проведения предпроектной экспертизы является заявка на экспертизу. Продавец заносит информацию о заказчике, краткое содержание целей проведение экспертизы, предполагаемые результаты экспертизы, срок предоставления результатов. Вебприложение поможет достигнуть следующих преимуществ при выполнении данной задачи: единая страница ввода данных в систему, в отличии от настольной версии, где для ввода данных нужно переключаться между вкладками регистрационной карточки; возможность создавать заявку на экспертизу вне рабочего места продавца, что позволит сократить время между получением информации от заказчика и постановки задачи на проведение экспертизы. - Формирование задач исполнителям. После получения заявки на экспертизу для ознакомления, руководитель подразделения, в котором находятся сотрудники, обладающие соответствующими компетенциями для проведения данной экспертизы, расписывает задания эксперту или экспертной группе. В веб-версии СЭД, функциональность по созданию резолюций и отображению дерева расписанных заданий будет более наглядна, так как интерфейс приложения будет более эргономичным. Формирование документа Экспертиза. Выполнение данной задачи является результатом деятельности по проведению предпроектной экспертизы. Удобный интерфейс позволит быстро заполнить все данные, прикрепить файлы, подготовленные экспертом. Поиск карточек заявок на экспертизу и экспертиз. Так как объем создаваемых в СЭД документов с течением времени только растет, возникает необходимость быстро находить в системе карточки документов, созданных в определенный момент времени или конкретным сотрудником или просто найти какой-либо документ. Поэтому организация поиска в веб-приложении также 34 является важной задачей. Поиск помогает быстро найти необходимую карточку по заданным параметрам, или карточки с совпадающими значениями поискового параметра, например, карточки одного сотрудника. Также в веб-версии будут поддержаны и другие задачи, составляющие процесс документооборота и являющиеся этапами процесса проведения предпроектной экспертизы (в данной работе они подробно не рассматриваются): Контроль сроков исполнения заданий. Предполагает под собой установление срока исполнения задания, после его окончания задание будет помечаться как просроченное. Согласование результатов экспертизы. Согласование экспертизы проводится с целью внесения комментариев к результатам, выявления и исправления недочетов. Интерфейс веб-приложения будет построен таким образом, что пользователю не придется открывать несколько страниц для просмотра информации по карточке экспертизы, файлы которой пришли на согласование. Согласующее лицо сразу же увидит саму карточку, ее файлы, решения и комментарии других согласующих лиц и сможет вынести свое решение буквально одним кликом. Описание бизнес-процесса «Провести экспертизу» в нотации IDEF0 в результате повышения уровня автоматизации (TO BE) представлено на рисунке 2.4. 35 Рисунок 2.4. Декомпозиция бизнес-процесса «Провести экспертизу» подпроцесса контекстной модели бизнес-процесса «Провести предпроектную деятельность» в нотации IDEF0 (TO BE) 36 2.3. Описание методики и обоснование выбора технологии для решения поставленной задачи В результате изучения системы документооборота АДП на базе платформы Docsvision, для которой будет разрабатываться веб-приложение, были выявлены следующие особенности системы: Базовой и основной единицей системы является - карточка, которая представляет собой: - для пользователя: пользовательский интерфейс, предназначенный для работы с документом, заданием или справочником системы; - с точки зрения хранения в базе данных: набор таблиц и хранимых процедур, обеспечивающих доступ к таблицам; - для программного приложения: объектная модель, позволяющая сохранять информацию в нужном порядке на сервер. Вторая базовая единица системы - это справочник. Под справочником понимается карточка в системе, существующая в единственном экземпляре, примерами системных справочников служат: Справочник контрагентов, Справочник сотрудников, Справочник Типов, Справочник видов, Универсальный справочник и др. Итак, перейдем к представлению данных карточек в базе данных. С точки зрения технического специалиста карточка – это набор метаданных, которые представляют собой набор секций. Секция карточки это набор полей, поэтому секцию можно представить как таблицу базы данных. А поле - колонкой этой таблицы. Каждый объект системы (т.е. карточка) имеет собственный уникальный идентификатор типа карточки. Также каждая секция и поле имеют свои собственные идентификаторы. Как должно быть понятно из вышесказанного секция – это таблица, колонки таблицы – это поля секции. Помимо колонокполей, таблица, описывающая секцию, имеет системные колонки, такие как InstanceID, RowID, ParentRowID, ParentTreeRowID и др. [17]. Эти колонки служат для корректной идентификации какой карточке и какой секции 37 данной карточке принадлежит выбранная строка. RowID- идентификатор строки таблицы (непосредственно является первичным ключом в классическом понимании схемы данных). InstanceID— идентификатор конкретного экземпляра карточки, которой принадлежит данная строчка. Исходя из описания, можно сделать вывод о том, что база данных Docsvision не имеет как таковой «схемы данных» в классическом её понимании: база представлена набором таблиц, для каждой строки которой указан уникальный идентификатор. Тем самым к любому объекту данных можно обратиться по сцепленному ключу. Целостность поддерживается на основе логики, построенной на триггерах и хранимых процедурах. Сама по себе база имеет довольно внушительные объемы: это большое число таблиц, описывающих секции карточек и сами карточки, а также системные таблицы, описывающие настройки системы и системные данные. Логическая схема данных построена по ссылочной модели, которая характеризуется произвольным расположением данных и их атрибутов в реляционных таблицах. Ее преимущество состоит в том, что она описывает широкую область естественных структур данных, которые обычно описываются в виде деревьев. Так, на основе ссылочной модели, база данных СЭД описывает отдельно каждый объект системы (карточку). Поле таблицы может хранить: непосредственно сами данные, и ссылки на секцию (идентификатор секции), на строку секции (идентификатор строки), на другую карточку (идентификатор карточки). Схема хранения данных карточки в базе СЭД представлена на рисунке 2.5 [17]. СЭД выполняет следующие основные функции: Регистрация входящей корреспонденции, включает в себя первичную обработку входящей документации: регистрация документа и передача адресатам.  Наложение резолюции и выбор исполнителей, представляет собой процесс формирования распорядительного задания, которое передается исполнителям в виде документа (входящего, исходящего или внутреннего) с 38 наложенной резолюцией. Под резолюцией в терминах документооборота понимается указание о сроках исполнения, характере документа, список исполнителей. Рисунок 2.5. Схема хранения данных карточки.  Создание исходящих и внутренних документов, которые создаются либо в инициативном порядке, либо как документ во исполнение задания по резолюции, или в ответ на входящий/внутренний документ.  Согласование документов, предполагает процесс ознакомления с текстом документа всех заинтересованных лиц и возможность внесения комментариев, изменений в текст документа. В АДП есть возможность создания двух типов маршрута согласования: последовательного и параллельного, а также есть возможность выбрать тип согласующего лица (согласование, утверждение, визирование).  Осуществление контроля исполнительской дисциплины, заключается в постановке на контроль заданий исполнителей, который предусматривает назначение плановых сроков исполнения резолюции (задания). Завершается контроль снятием задания с контроля контролером организации. Модули платформы DocsVision: 39 - сервер хранилища данных DocsVision, на основе MS SQL Server и веб-сервера IIS. Осуществляет обработку запросов на выборку данных и хранение информации. - клиентское приложение представляет DocsVision, интегрированное в MS IE приложение собой и состоит из ядра (менеджера объектов) и набора управляемых им карточек. Прикладные серверные модули приложения АДП: - сервис журналирования, используется для учета действий по изменению состояний или данных карточек; - сервис безопасности, обеспечивает управление правами доступа пользователей к объектам системы; - сервис проверки прав, обеспечивает доступность операций производимых с карточкой в разных состояниях. Прикладные клиентские модули АДП: - модуль сканирования, документов и последующего предназначен для сканирования бумажных прикрепления электронных копий к регистрационной карточке документа; - модуль работы с заданиями, обеспечивает учет заданий по резолюциям и возможность контроля исполнения заданий; - модуль управления ролями пользователей, предназначен для управления правами пользователей системы на доступ к ее объектам, и правами на выполнение операций с данными объектами; - модуль работы с электронной цифровой подписью (ЭЦП), служит для подписания объектов системы цифровой подписью, проверки подлинности ЭЦП. Приложение АДП включает в себя следующие карточки: o регистрационная карточка документа, которая позволяет работать с входящими, внутренними и исходящими документами; o шаблон регистрационной карточки документа, для работы с типовыми документами; 40 o поиск регистрационных карточек, служит для поиска регистрационных карточек в системе; o карточка задания, позволяет создавать задания исполнителям, совершать отметки о ходе исполнения и завершения задания; o поиск карточек задания; o реестр приема/передач, необходим для формирования списков переданных или получаемых документов; o карточка Согласования, представляет собой описание маршрута согласования; Приложение АДП работает со следующими основными справочниками и системными карточками: o справочник сотрудников, служит для хранения, изменения информации о сотрудниках, в соответствии со структурой организации; o справочник контрагентов, предназначен для хранения информации о внешних организациях, с которыми осуществляется сотрудничество; o справочник нумераторов, формирует правила для автоматической нумерации документов; o справочник типов, служит для разработки новых видов карточек документов с уникальным набором полей на основе стандартных типов документов системы. o универсальный справочник, хранит описание однотипных объектов, для которых не предусмотрено отдельных справочников; o справочник категорий, представляет собой дерево тематик документации, позволяющее облегчить поиск документов; o справочник Ролевая модель, предназначен для настройки доступности операций для различных групп пользователей; o справочник Видов, необходим для создания новых видов стандартных карточек документов; o справочник системных настроек, отдельные модули системы; 41 позволяющий настраивать o справочник пользовательских настроек, предназначенный для настройки объектов приложения АДП для конкретного пользователя. Все данные модули, карточки и справочники используются для обеспечения работы основных функций приложения АДП. Таким образом, в веб-версии планируется поддержать основную функциональность приложения АДП: на данном этапе - это создание исходящих и внутренних документов, регистрация документов и передача адресатам, согласование документов, создание распорядительных заданий. Для обеспечения работы данных функций используются вышеуказанные объекты СЭД. Обращение к данным и объектам системы в веб-версии будет происходить посредством веб-сервиса, перейдем к его рассмотрению. Веб-версия системы документооборота функционирует на основе вебсервиса, разработанного по технологии rest-api. Далее предлагается рассмотреть, что представляет собой веб-сервис, и причины выбора для его разработки технологии rest-api. Под термином API понимают совокупность, предоставляемых программным приложением готовых классов, процедур, функций, структур и констант для их использования внешними программными продуктами. В вебразработке API это набор HTTP-запросов и заранее определенный формат структуры HTTP-ответов (в JSON или XML формате). Веб-сервис представляет собой интерфейс для обмена данными между приложениями, написанными на различных языках программирования, распределенных на разных узлах сети [11]. Именно с появлением веб-сервисов стала развиваться парадигма SOA — сервис-ориентированной архитектуры веб-приложений (Service Oriented Architecture). SOA является не чем иным как подходом в построении программных приложений, следующим трем основным принципам [18]: 42 - сервисы являются компонентами информационной системы, которые публикуют свои интерфейсы для взаимодействия с информационной системой по стандартизированным протоколам (HTTP, TCP, SMTP и др.). Интерфейсы изолируют технические особенности реализации, такие как платформа, язык программирования, операционная и т.п.; - сервис реализует отдельную бизнес-функцию, которая является логически обособленной, повторяющейся задачей, являющейся составной частью бизнес-процесса; - низкая связанность сервисов между собой, позволяющая динамически реализовывать каждый сервис, не затрагивая функциональность другого сервиса. Программы, разработанные по принципам SOA, обычно реализуются как набор веб-сервисов взаимодействующих между собой с помощью сообщений, который основываются на технологиях SOAP, XML-RPC, REST и др. [11]. Боле простыми словами веб-сервис реализует межпрограммное взаимодействие с помощью этих технологий. Выбор какой-либо технологий для реализации веб-сервисов зависит от ситуации и осуществляется разработчиками систем. Предлагаю сравнить две технологии используемых для реализации веб-сервиса: SOAP и REST. Технология XML-RPC не будет рассматриваться, несмотря на то, что в недавнем времени активно использовалась в разработке, она является устаревшей и считается, что непосредственно SOAP – это следующий этап развития XML-RPC [19]. SOAP (Simple Object Access Protocol) — протокол обмена сообщениями между потребителем и поставщиком веб-сервиса. Основой протокола является удаленный вызов процедур [19]. SOAP может использоваться с любым протоколом прикладного уровня: SMTP, FTP, HTTPS и др., но наиболее популярно его использование поверх HTTP. Транспортом для доставки данных в SOAP является XML – расширяемый язык разметки (eXtensible Markup Language), который позволяет производить автоматическую валидацию поступающих на сервер 43 данных от клиентов (посредством языка описания структуры XMLдокумента (XML-Schema) [19]. Все сообщения SOAP оформляются в виде структуры, называемой конвертом (envelop), включающей следующие элементы [19]:  Идентификатор сообщения (локальное имя).  Опциональный элемент Header (заголовок):  Обязательный элемент Body (тело сообщения, в котором передаются данные) Протокол SOAP тесно связан с WSDL (Web Services Description Language), языком описания веб-сервисов и доступа к ним, основанном на XML. WSDL позволяет «клиентам» взаимодействовать с сервером, с помощью информации содержащейся в файле с расширением «.wsdl»: используемые схемы данных; пространства имен; типы сообщений, ожидаемых веб-сервисом от «клиентов»; соотнесение данных и процедур веб-сервиса; процедуры веб-сервиса; способы вызова процедур веб-сервиса; адрес, на который отправляются запросы «клиента». Таким образом, данный файл описывает весь веб-сервис. Схема работы SOAP представлена на рисунке 2.6. Рисунок 2.6. Общая схема передачи данных в архитектуре SOAP. 44 REST (Representational – state transfer) это стиль построения архитектуры программного обеспечения для распределенных систем. Или, как его еще часто определяют, способ взаимодействия компонентов распределённого приложения в сети Internet, при котором вызов удаленной процедуры представляет собой HTTP-запрос (GET, POST, PUT, DELETE), а необходимые данные передаются в тела запроса. Если определять архитектуру REST более общими словами, то REST – это простой интерфейс для управления информацией без использования каких-либо дополнительных технологий для «обертки» данных, то есть данные передаются в виде «как есть»: сами данные, а не, например, XML как в SOAP. Каждая единица данных однозначно определяется глобальным идентификатором URL, являющимся ее первичным ключом и имеющим определенный формат [20]. Передача данных в архитектуре REST основывается на самом распространенном протоколе HTTP. Как мы знаем, для протокола HTTP действие над данными задается с помощью методов: GET, PUT, POST, DELETE. Так и REST использует данные методы. Но понятие CRUD (CreateRead-Updtae-Delete), для REST, является всего лишь рекомендацией проектирования REST-сервисов. Действия Create, Read, Updtae, Delete могут выполняться как четырьмя основными методами, так и только с помощью GET и POST (таблица 2.2)[21]. Таблица 2.2. Соответствие действий языка SQL HTTP запросам № Операция SQL HTTP 1 Создание (create) INSERT POST 2 Чтение (read) SELECT GET 3 Редактирование (update) UPDATE PUT 4 Удаление (delete) DELETE DELETE 45 Таким образом, любой запрос на действия с данными в REST-сервисе это простейший HTTP-запрос. Данная особенность архитектуры REST и является ключевым отличием от SOAP. В REST-сервисе обмен информацией по HTTP протоколу идет в различных форматах:  XML;  JSON (Java Script Object Notation- текстовый формат обмена данными, основанный на JavaScript, но являющийся независимым от него. Основная особенность – легко воспринимается людьми) [22];  Строка, и др.; REST архитектура очень проста в использовании: по виду запроса сразу можно определить, его функцию (в отличие от SOAP, XML-RPC); данные передаются в виде данных, поэтому REST считается менее трудозатратным, так как не нужно изменять формат данных и разбирать запрос, чтобы понять его цель [21]. Рисунок 2.7. Общая схема передачи данных в архитектуре REST Следует сказать, что технологии SOAP и REST не конкуренты, это два разных подхода, используемые для решения похожих задач, но в разном окружении. Рассмотрим сравнительную таблицу подходов разработки сервисориентированных приложений 2.3.: 46 Таблица 2.3. Сравнительная таблица походов к разработке сервисориентированных приложений № 1 2 3 4 5 6 7 8 9 10 11 12 13 14 Критерий Применимость для стратегических ресурсов Применимость для динамических ресурсов Необходимость наличия сервера приложений Затраты на встраивание Масштабируемость Величина загрузки вычислительных ресурсов Шаблон проектирования Кэширование на уровне сервера Быстродействие Работа с данными, представленными в разных форматах Объем ответных сообщений Протоколы, с которыми возможна работа Обработка ошибок Изучение спецификаций SOAP REST Нет Да Да Нет Да Нет Высокие Не высокая Высокая Малые Высокая Не большая Нет Нет Нет1 Только XML2 Да Да Да ASCII, XML, JSON и др.2 Избыточен Лаконичен HTTP, FTP, SMTP и Только HTTP3 др.3 Стандартизированная Использует коды ошибок HTTP дополнительных Да (например, WSDL) Нет 1. SOAP – семейство протоколов и стандартов, поэтому это более тяжеловесный и сложный вариант с точки зрения машинной обработки, REST работает быстрее [23]. 2. XML в архитектуре SOAP активно используется для кодирования запросов и ответов, отвечает за строгую типизацию данных, которая гарантирует целостность при передаче клиент-сервер. В REST ответы и запросы могут передаваться посредством JSON, XML, ASCII или других форматов представления данных, распознаваемых и клиентом и сервером. Помимо этого в модели REST отсутствуют встроенные требования к типизации данных. Именно поэтому пакеты запросов и ответов значительно меньше по размеру, чем соответствующие им пакеты SOAP. 3. В SOAP роль протокола HTTP ограничивается только использованием его как транспорта для передачи данных. Детали запроса 47 сервера кодируются в теле запроса, например, имя удаленной процедуры и входные аргументы. Для REST уровень передачи данных HTTP это непосредственный участник передачи данных, который использует методы НТТР (GET, POST, PUT и DELETE) для обозначения типа запрашиваемого сервиса, также в модели REST, в отличие SOAP, используются достоинства протокола HTTP: кеширование на уровне сервера, масштабирование [23]. В связи с этим, запросы REST считаются более простыми и понятными, так как используют широко известные и понятные интерфейсы HTTP. 4. REST избегает WSDL в пользу более удобного и понятного интерфейса, основанному на базовых методах HTTP. SOAP, в свою очередь, позволяет описывать API в файле WSDL, но создание WSDL-файлов довольно трудоемко, клиенты SOAP могут автоматически получать из этих файлов подробную информацию об именах и сигнатурах методов, типах входных и выходных данных и возвращаемых значениях. На основе проведенного сравнения, можно сделать вывод о том, для чего лучше использовать REST, для чего SOAP: REST подходит для сервисов, которые будут использоваться из java script, так как java script качественно работает с json. Также из языков, которые не могут генерировать прокси клиента, чтобы не разбирать вручную SOAP-конверт, так как это занимает время и ресурсы. И когда есть очень высокие требования к производительности, когда на API сервис ложится высокая нагрузка(интенсивность запросов). SOAP обычно используют, когда необходимо поддержать кроссплатформенное взаимодействие, под которое существуют инструменты для ускорения разработки с использованием SOAP. Например, правильно писать SOAP-сервис на JAVA, который будет использоваться из .Net и Flex [23]. Но следует еще раз сказать, что это два разных архитектурных подхода, и выбор, какой из них использовать, лежит на разработчике, которой, исходя из своих целей и возможностей, выбирает наиболее подходящий. 48 Для разработки был выбран именно подход REST, так как он наиболее прост и удобен. И так как система документооборота это система с высокими нагрузками, при большом количестве подключенных клиентов, то этот подход наиболее рационален для использования в данной ситуации. 49 2.4. Описание входной и выходной информации. Входными данными разрабатываемого приложения являются: - информация о заказчике; - информация об экспертизе; - регистрационные данные (Адресаты, Подписанты); - приложенные файлы (необязательные). Выходной информацией: - сформированная регистрационная карточка заявки на экспертизу; - сформированная регистрационная карточка заданий экспертной группе; - сформированная регистрационная карточка Экспертизы, с данными о результатах экспертизы и приложенными файлами, которые являются результатом выполнения экспертизы. Справочная информация: - справочник «Сотрудники»; - справочник «Контрагенты»; - справочник «Виды карточек»; - справочник «Типов карточек»; - справочник «Правила нумерации»; - универсальный справочник. Подробное описание входной, выходной и справочной информации представлено в таблице 2.4. Таблица 2.4. Описание входной и выходной информации № 1 Наименовани е Форма Откуда Куда Комментарий представления поступает передается Входная информация Информация о Поле Справочник В СЭД Наименование заказчике Регистрационной «Контрагенты Заказчика Карточки » секции Дополнительные реквизиты: - Заказчик 50 № 2 Наименовани е Информация об экспертизе: Форма Откуда представления поступает Поле Продавец, Регистрационной Организациякарточки – заказчик Содержание, - Код предложения в системе заявок, Куда Комментарий передается В СЭД Содержание – цель или краткая суть проведения экспертизы. Код экспертизы из сервиса экспертиз - Планируемая дата предоставления результатов 3 Адресаты Поле Регистрационной Карточки Справочник «Сотрудники » В СЭД Сотрудник, являющийся владельцем ресурсов подразделения (или проекта), в котором должна быть выполнена экспертиза 4 Подписанты Справочник «Сотрудники » В СЭД 5 Приложенные Файлы Поле регистрационной карточки «Подписанты» Поле регистрационной карточки «Файлы» От продавца В СЭД Сотрудники подготовившие Заявку на экспертизу Файлы, в которых более подробно излагается суть предполагаемого решения, которое требует экспертизы. 1 2 1 2 3 Выходная информация Вн. Документ Регистрационная СЭД Заявка на карточка экспертизу Задание на Карточка Задания СЭД, на Получатель рассмотрение основании вн. регистрпо вх. документа ационной Документу карточки Заявка на экспертизу Справочная информация Данные о Справочник СЭД контрагентах «Контрагенты» Данные о Справочник СЭД сотрудниках «Сотрудники» Виды карточек Справочник «Виды СЭД 51 Документ в СЭД Сотрудник, указанный в поле Адресаты регистрационной карточки Все справочники заполняются в толстом клиенте. Веб-клиент позволяет получать № Наименовани е 4 Нумератор 5 Дополнительн ые Реквизиты карточки Данные о Универсальный видах Справочник срочности, грифе документа 6 Форма представления карточек» Справочник «Правила нумерации» Справочник Типов Откуда поступает СЭД СЭД СЭД 52 Куда передается Комментарий данные справочников из 2.5. Информационно-технологическая схема решения задачи «Обработка заявки на экспертизу» Запрос на экспертизу обрабатывается Продавцом, который создает Регистрационную карточку внутреннего документа «Заявка на экспертизу» в СЭД и заносит в нее данные об экспертизе и, при необходимости, прикрепляет файлы. Далее Продавец регистрирует карточку в СЭД (в системе выделяется регистрационный номер, по заранее определенному правилу) и передает её получателям. В СЭД, на основе данных регистрационной карточки, формируется задание типа «Передача получателям», которое поступает исполнителю в настроенную поисковую папку. Информационно-технологическая схема решения задачи «Обработка заявки на экспертизу» представлена на рисунке 2.8 [3]. 53 Рисунок 2.8. Информационно-технологическая схема решения задачи «Обработка заявки на экспертизу» 54 2.6. Проектирование запросов web-cервиса В рамках реализации веб-версии системы были разработаны запросы доступа к данным, объектам, программным функциям и методам системы через веб-сервис. Запросы позволяют обращаться к бизнес-функциям, данным приложения АДП 4.5, а также к данным, хранящимся непосредственно в базе данных СЭД. Определим основные наборы параметров для объектов системы, передающиеся и вызывающиеся посредством веб-сервиса. Набор параметров Регистрационной Карточки документа, получаемых через веб-сервис, представлен в Приложении 1 Таблице 1. С помощью метода GET api/Documents/{DocumentID}, где DocumentID, это идентификатор регистрационной карточки в базе данных, мы можем получить набор значений параметров регистрационной карточки, на его основе. Методом создания Регистрационной карточки документа POST api/ Documents, передаем параметры, которые должны быть заполнены при создании карточки. В ходе выполнения метода вызываем серверную операцию приложения АДП «Выделить временный номер», номер записываем в параметр SystemNumber. Например, чтобы создать регистрационную карточку внутреннего документа типа «Заявка на экспертизу» нужно выполнить следующий запрос: POST api/ Documents И в теле запроса передать параметр Вид документа и Тип документа: { "Type": 2, "Content": "txt", "SystemNumber": "", "Kind": { "ChildKinds": null, "NotAvailable": false, "Name": "Заявка на экспертизу", "Id": "be0f2b93-1b78-4529-b84c-0353f22d3fac" } 55 } Обновить данные регистрационной карточки можно методом PUT api/ Documents/{DocumentID}, в результате его выполнении при передаче в теле метода новых значений параметров, для которых доступно выполнение метода PUT, записываем новые значения параметров в базу данных. Например, если в теле запроса передать следующие параметры, то мы обновим содержание документа: { "Type": 2, "Content": "Выполнить экспертизу", "SystemNumber": "", "Kind": { "ChildKinds": null, "NotAvailable": false, "Name": "Заявканаэкспертизу", "Id": "be0f2b93-1b78-4529-b84c-0353f22d3fac" } "Id": "c7ae0d0d-4561-47a3-9409-fd28ceba6497" } Метод DELETE/Documents/{DocumentID}, регистрационной карточки, выполняется метод через аннулирования бизнес-операцию «Аннулировать РК». А данным запросом мы выполним аннулирование документа, для выполнения данной операции сервису достаточно знать идентификатор документа: { "Type": 2, "Content": "Выполнитьэкспертизу", "SystemNumber": "", "Kind": { "ChildKinds": null, "NotAvailable": false, "Name": "Заявка на экспертизу", "Id": "be0f2b93-1b78-4529-b84c-0353f22d3fac" } "Id": "c7ae0d0d-4561-47a3-9409-fd28ceba6497" } } 56 Как было уже сказано выше, карточки состоят из секций и некоторые секции карточек требуют отдельных методов для их заполнения, поэтому рассмотрим набор параметров секции Регистрационной карточки «Адресаты» документа, который представлен в таблице 2 приложения 1. Для работы с данной секцией также разработаны api методы:  если необходимо карточки, получить нужно список будет адресатов вызвать api/Documents/{DocumentID}/Addressees, где регистрационной метод GET DocumentID – идентификатор документа в базе данных;  если мы хотим обновить данные какого-либо адресата в списке, то нужно вызывать PUT Documents/{DocumentID}/Addressees/{addresseeId}, api/ где передавать идентификатор обновляемого адресата и обновляемые данные;  для добавления адресатов следует использовать метод POST api/Documents/{DocumentID}/Addressees;  метод DELETE api/ Documents/{DocumentID}/Addressees/{addresseeId}, используется для удаления адресата из списка. Допустим, нам необходимо добавить адресатов в нашу заявку, тогда необходимо выполнить запрос api/Documents/{DocumentID}/Addressees и в теле запроса передать идентификатор сотрудника, который должен стать адресатом в данной карточке: { "OrderNumber": 1, "Reference": { "Id": "52ad3ce6-1f0d-4485-8336-c2b39b015c12" }, "Type": 0, "AddresseeType": 0, "OutgoingNumber": "", "OutRegDate": null, "OutSignedBy": null, "SendTo": null, "SendPaper": null, "CopyNumber": null, "BlankNumber": null, "NumberOfCopies": null, 57 "PageCount": null, "TaskId": null, "DeliveryTypes": [], } Также в регистрационную карточку входит секция «Исполнители» документа, набор параметров для нее представлен в таблице 3 приложения 1. Методы api для работы с секцией «Исполнители» также представлены 4 основными запросами:  метод позволяющий получить список исполнителей регистрационной карточки GET api/Documents/{DocumentID}/Executors, где DocumentID;  метод обновления параметров исполнителя PUT api/Documents/{DocumentID}/Executors/{executorId};  метод добавления исполнителей в регистрационную карточку POSTapi/Documents/{DocumentID}/Executors;  метод DELETE api/Documents/{DocumentID}/Executors/{executorId}, предназначен для удаления исполнителя из секции «Исполнители». При необходимости добавления исполнителя в карточку документа выполним запрос POST api/Documents/{DocumentID}/Executors следующими параметрами в теле запроса: { "Order": 2, "Employee": { "LastName": "Plankova", "FirstName": "M", "MiddleName": null, "DisplayString": "Plankova M.", "Position": null, "PositionImportance": null, "Phone": null, "MobilePhone": null, "RoomNumber": null, "Email": null, "Status": 0, "NotAvailable": false, "ActiveEmployee": "52ad3ce6-1f0d-4485-8336-c2b39b015c12", "Manager": { "Id": "e3362e9e-bc3b-409a-a4a3-8a142e80d561" } } 58 со } Таким образом, мы рассмотрели основные методы получения и отправки данных на сервер посредством веб-сервиса для регистрационной карточки. В приложении 1 в таблице 4 и 5 также подробнее рассмотрены запросы работы с файлами регистрационной карточки. Для удобного разработать поиска поисковый карточек запрос. документов Поисковые необходимо запросы для было системы разрабатывается как xml-документы. Для веб-версии было разработано несколько поисковых запросов: - для контекстного поиска по представлению; - для папок-фильтров, в которые должны отбираться карточки конкретного пользователя. Примеры поисковых запросов приведены в Приложении 2 данной работы. Также в процессе разработки данного решения было создано клиентское приложение – веб-клиент, рассмотрение интерфейса которого будет представлено в разделе 2.8. Веб-клиент представляет собой клиентсерверное приложение, где клиентом является интернет браузер, и сервером – веб-сервер. По своей сути веб-клиент - это сайт, на котором размещены элементы интерфейса, логика работы которого поддерживается с помощью веб-сервиса. 59 2.7. Проектирование и настройка объектов СЭД Для корректной работы веб-приложения, необходимо настроить справочники СЭД для работы, а также спроектировать дополнительные реквизиты для стандартной карточки внутреннего документа. Настройка объектов СЭД производится в приложении непосредственно в толстом клиенте системы документооборота. 1. Создание новых типов регистрационной карточки документа. Система документооборота позволяет создавать пользовательские типы карточек с уникальным набором полей (свойств), для использования в узкоспециализированных задачах. Для создания таких свойств используется «Справочник типов». Для решения текущей задачи были созданы два новых типа для объекта системы Регистрационная карточка документа: «Заявка на экспертизу» и «Экспертиза»: Регистрационная карточка документа «Заявка на экспертизу» будет содержать следующие дополнительные реквизиты: Наименование заказчика, Код предложения в системе заявок, Планируемая дата предоставления результатов. Таблица 2.5. Дополнительные реквизиты карточки «Заявка на экспертизу» № 1 Наименование свойства Заказчик 2 Код предложения системе заявок 3 Планируемая предоставления результатов Тип свойства Ссылка Организация (подразделение) справочника контрагентов в Строка дата Дата Обязательное Да Наименование заказчика Нет Код основания для экспертизы в системе заявок Предполагаемая дата получения результатов Да 60 Комментарий Регистрационная карточка документа «Экспертиза» будет содержать следующие реквизиты: Цель проведения экспертизы, Фактическая дата начала экспертизы, Инициатор экспертизы, Исполнитель, тип экспертизы. Таблица 2.6. Дополнительные реквизиты карточки «Экспертиза» № Наименование свойства 1 Цель 2 3 4 5 Тип свойства Строка Комментарий Описание цели проведения экспертизы со стороны исполнителя Фактическая дата начала Дата Дата необходима для экспертизы контроля сроков Инициатор экспертизы Ссылка на справочник Сотрудник создавший Сотрудников заявку на экспертизу или куратор проекта, от которого поступили требования Исполнитель Ссылка на справочник Фактический исполнитель Сотрудников экспертизы, также в поле может быть указан соисполнитель Тип экспертизы Строка Тип выполненной экспертизы Также, для отображения новых типов Регистрационной карточки в интерфейсе СЭД, требуется занести новые типы в «Справочник видов». Для этого необходимо внести псевдонимы новых типов через интерфейс СЭД или посредством редактирования файла XML, содержащего данные справочника. 2. Настройка Универсального справочника В Универсальный справочник необходимо занести данные об используемых типах Срочности, типах согласования, видах грифов. Таблица 2.7. Описание данных Универсального справочника № 1 Название объекта справочника Срочность Виды объекта Срочно - 2 Гриф ДСП Простой 3 Тип визирования Согласование 61 Описание Срочность необходима для приоритизации задачи на выполнение экспертизы Гриф необходим для обозначения типа доступа к данным объектов системы (внутри или вне организации) Тип визирования Утверждение позволяет определить роль согласующего лица в маршруте согласования. 3. Настройка Нумератора. Для настройки Нумератора в СЭД необходимо создать правило нумерации для подразделения: Префикс номера – буквенное, символьное или буквенно-цифровое значение – в нашем случае присваиваем префиксу значение «#». И настроить нумератор – определить границы выделяемых номеров (100-10000); определить период обновления, после которого выделение номеров осуществляется с первого номера в границах диапазона номеров. Таким образом, номера регистрационных карточек будут выглядеть следующим образом: от #100 до #10000, с периодом обновления номеров 1 год. 62 2.8. Проектирование пользовательского интерфейса Так как одной из основных причин создания веб-приложения стал современный и удобный интерфейс. Перейдем к его рассмотрению. Основная страница веб-приложения (рисунок 2.9) - это страница с набором папок-фильтров и табличной частью, кнопками создания новых карточек документа и задания. Табличная часть основной страницы – это список карточек или «представление», содержащее краткую информацию о карточке. Рисунок 2.9. Основная страница веб-приложения. Страница – форма регистрационной карточки состоит из нескольких блоков и имеет вертикальную прокрутку (рисунок 2.10). В первом блоке страницы расположена форма для ввода регистрационных данных (приложение 3 рисунок 1), во втором область для добавления файлов, в третьем область для добавления связей. На верхней панели страницы содержит: Заголовок карточки (дайджест, формируемый системой на основе типа и вида документа, а также выделенного регистрационного или системного номера). Кнопка смены состояния карточки документа. В зависимости от состояния имеет следующие функции: 63 - передача на регистрацию, - регистрация (выделение регистрационного номера); - передача получателям (формирование заданий по документу). Рисунок 2.10. Экранная форма регистрационной карточки. Страница - карточка задания также состоит из нескольких блоков: Блок информации о регистрационной карточке, по которой расписано задание. Блок Резолюция, позволяющий расписать задание нижестоящим исполнителям. Блок дерево резолюций, представляющий собой иерархию заданий, расписанных по данному документу. Форма карточки задания представлена в приложении 3 рисунки 2-5 . Как можно заметить интерфейс веб-приложения довольно простой и не перегружен лишней функциональностью. На одной странице можно увидеть всю информацию по регистрационной карточке или заданию. Пользователю нет необходимости постоянно переключаться между вкладками или ждать 64 открытия регистрационной карточки из задания, чтобы просмотреть ее основную информацию. Также легко заметить на верхней панели страницы логотип компании, который позволяет сделать интерфейс клиент-ориентированным. Также в веб-приложении легко сменить цветовое решение, используя заранее подготовленную таблицу стилей для основных элементов страниц. Также для удобства пользователей была разработана форма поиска карточек по атрибутам, представлена на рисунке 2.11. Рисунок 2.11. Экранная фора атрибутивного поиска Современная реализация интерфейса должна сделать работу пользователей с системой более качественной, так как не нужно отвлекаться на поиск нужной кнопки среди множества неиспользуемых, все необходимые данные находятся в рамках одной страницы и сам интерфейс более приятный. В веб-версии системы поддержана функциональность по разграничению прав пользователей, поэтому если у пользователя нет прав на просмотр какой-либо части карточки, то она будет скрыта от него в интерфейсе. 65 ГЛАВА 3. ИНСТРУКЦИЯ ПОЛЬЗОВАТЕЛЯ И РАСЧЕТ ПОКАЗАТЕЛЕЙ ЭКОНОМИЧЕСКОЙ ЭФФЕКТИВНОСТИ 3.1. Инструкция пользователя Основными пользователями системы являются следующие сотрудники: продавец, осуществляющий подготовку заявки на экспертизу; руководитель подтверждает необходимость выполнения экспертизы и, в зависимости от решения, назначает эксперта или отклоняет заявку; эксперт - сотрудник, назначенный руководителем, его функциями является исполнение заявки: получение задание, подготовка документации на утверждение, доработка по вынесенным замечаниям; ответственный сотрудник за производство, исполняет роль утверждающего лица, которое может внести замечания и отправить экспертизу на доработку или утвердить оценку. Кроме того, все сотрудники имеют возможность поиска карточек в базе данных СЭД. Подробная схема сценариев использования веб-клиента СЭД, в контексте проведения предпроектной деятельности, представлена на рисунке 3.1. 66 Рисунок 3.1. Диаграмма сценариев использования веб-клиента СЭД при проведении предпроектной деятельности в нотации UML. Для решения задачи обработка заявки на экспертизу было разработано веб-приложение системы электронного документооборота. Для того чтобы войти в приложение необходимо в веб-браузере ввести url-адрес размещения веб-приложения (предварительно сайт должен быть развернут администратором на web-сервере IIS): http://<имя__сервера>:88/#/. После перехода по ссылке пользователь попадает на основную страницу приложения, на которой расположены поисковые папки-фильтры, список карточек пользователя, соответствующий поисковому запросу папки, в которой находится пользователь, кнопки создания регистрационной карточки, карточки задания. Для создания Заявки на экспертизу необходимо нажать на кнопку «Создать документ». После клика по кнопке откроется страница выбора типа создаваемого документа: внутренний и исходящий, где необходимо выбрать тип документа, далее произойдет переход на страницу с пустой формой регистрационной карточки (приложение 3 рисунок 1). Чтобы создать документ вида «Заявка на экспертизу» выберите в поле «Вид документа» данный вид. Наименование вида сразу отобразится в шапке регистрационной карточки, и в карточке отобразится раздел: дополнительные реквизиты. Далее необходимо занести все регистрационные данные в карточку, а именно содержание, получателей карточки (адресатов), подписантов. Подразделение регистрации заполнится автоматически при заполнении поля «Подписанты». Также необходимо заполнить дополнительные реквизиты карточки, которые отмечены плейсхолдером «Обязательно». Таким образом, мы сформировали документ «Заявка на экспертизу». Если есть необходимость прикрепить файлы к документу, то выполнить данную операцию можно с помощью кнопки «Прикрепить файл», 67 откроется стандартное окно операционной системы для добавления файла, или при помощи перетаскивания файла в область «Прикрепить файл». Если все обязательные поля заполнены, то далее выполните операцию «На регистрацию» по соответствующей кнопке в правой верхней части страницы. Карточка сменит свое состояние с «Подготавливается» на «Регистрируется». Если все данные заполнены корректно, то зарегистрируйте карточку по кнопке «Зарегистрировать», чтобы карточка документа перешла в состояние «Зарегистрирован». Чтобы передать заявку адресатам и сформировать на них задание на рассмотрение заявки, выполните операцию «Передать получателям». В системе сформируются задания адресатам регистрационной карточки, которые попадут в соответствующую поисковую папку «На рассмотрении» назначенным получателям. 68 3.2. Расчет показателей экономической эффективности Оценка экономической эффективности является важной частью при разработке информационной системы. Рассчитав данный показатель, мы можем сделать вывод: стоит ли разрабатывать и внедрять информационную систему. А также оценить время, в которое окупятся затраты на создание системы [7]. Главным ожидаемым результатом применения веб-версии СЭД является - сокращение времени на обработку заявок на экспертизу, внесения результатов проведения экспертиз в СЭД. Если говорить о повышении качества обработки экспертиз, то его невозможно оценить количественно, но, несомненно, с обновлением системы эффективность принимаемых решений и их качество повысится. Для расчета эффективности создания и внедрения системы необходимо произвести расчет капитальных и эксплуатационных затрат: 1. Расчет затрат на создание ИС. Капитальные затраты, это затраты, которые в процессе выполнения проекта вносятся единожды. Таблица 3.1. Исходные данные для расчета капитальных затрат на создание ИС № 1 2 3 4 5 6 7 8 9 10 Наименование показателя Единицы Значение измерения Трудоемкость работ по созданию системы Чд 220 Объем машинного времени затраченный на создание Ч 1640 ИС Стоимость 1 машинного часа Руб/ч 30 Оклад программиста Оклад тестировщика Оклад аналитика Коэффициент дополнительной заработной платы Коэффициент отчислений на социально-страховые нужды Коэффициент накладных расходов Коэффициент прочих расходов 69 Руб. Руб. Руб. % % 45000 30000 35000 10 26 % % 40 10 Укрупненный расчет капитальных затрат на разработку производится по формуле: Кп= Фз/п[(1+βд)( 1+βс)+ βн +βпр]+tЭВМСм-ч (1), где Фз/п – фонд основной заработной платы исполнителей работ; βд – коэффициент дополнительной заработной платы; βс – коэффициент отчислений на социально-страховые нужды; βн– коэффициент накладных расходов; βпр – коэффициент прочих расходов; tЭВМ – машинное время, затраченное на создание ИС, ч.; См-ч – стоимость одного машинного часа работы вычислительных средств, р. Рассчитаем фонд основной заработной платы группы проекта: Фз/п=∑𝑖𝑗 t ij k У C (2), где ∑𝑖𝑗 𝑡𝑖𝑗 – общая трудоемкость проектных работ человеко-дней; 𝑘У – степень участия в проекте; С – средняя дневная ставка исполнителей работ. Примерное соотношение работы программиста, аналитика, инженера тестирования в проекте 40%, 40%, 20%. Фз/п= 220чд * 0,4 * 1904,8 руб/чд + 220 чд * 0,4 * 1428,6 руб/чд + 220 чд * 0,2 * 1428,6 руб/чд = 167622,4 + 125716,8 + 62858,4 = 356 197,6 руб Произведем расчет капитальных затрат на создание информационной системы по формуле 1: Кп= 356198 руб.* [(1+0,1)*(1+0,26)+ 0,4 +0,1]+1640 ч*30 руб/ч= 711 559 руб. Для выполнения проекта новых программных средств и оборудования не закупалось, поэтому не включаем их в расчет капитальных затрат на проектирование. 2. Эксплуатационные затраты 70 Эксплуатационные затраты это затраты, которые повторяются в каждой итерации производства. Таблица 3.2. Исходные данные для расчета эксплуатационных затрат на работу с ИС № Наименование показателя Единицы измерения Значение 1 2 Число рабочих дней в месяц системы Число рабочих часов в день системы д ч 22 8 3 Оклад инженера внедрения Руб 30000 4 Общее годовое время работы, затрачиваемое Ч инженером на обработку результатов в ИС 96 5 6 7 Ср. оклад продавца Ср. оклад экспертов Общее годовое время работы, затрачиваемое экспертами на обработку результатов в ИС Общее годовое время работы, затрачиваемое продавцами на обработку результатов в ИС Цена 1 кВт/ч электроэнергии. Руб. Руб. Ч 50000 45000 120 Ч 119 руб./кВт/час 3,84 % 5 8 9 10 Прочие неучтенные затраты Расчет эксплуатационных затрат производится за год, по следующей формуле: C = Сао + Сто + Син + Сэл + Спр (3),где Сао – амортизационные отчисления; Сто – затраты на техническое обслуживание, включая заработную плату персонала ИС; Син – затраты, связанные с использованием глобальных вычислительных сетей (Интернета и др.); Сэл – затраты на электроэнергию; Спр – прочие затраты составляют примерно 7%. При внедрении веб-версии СЭД не изменятся следующие затраты: амортизационные отчисления, в связи с тем, что не меняется аппаратное 71 обеспечение, и затраты на вычислительные сети, так как нет необходимости их улучшать или менять. Рассчитаем затраты на техническое обслуживание по формуле 4: Первой составляющей является зарплата инженера по внедрению (ЗПи): ЗПи=Осj*Tмес*((1+βд)( 1+βс)+ βн +βпр) (4), где Осji – оклад инженера, Tмес – время, затраченное сотрудником, работу в системе документооборота (рассчитывается в соответствии с формулой 5). Т мес  Т час (5), где Ч  Ч рч рд Ч рд – число рабочих дней в месяц; Чрч– число рабочих часов в день; Т мес  96 228  0,55 ЗПи= 30000 руб. * 0,55 * ((1 + 0,1) * ( 1 + 0,26) + 0,4 + 0,1) = 31 119 руб. Второй составляющей - заработная плата персонала (Зпп). Она складывается из заработной платы сотрудников использующих систему, это продавцы и эксперты (аналитики, руководители и т.п). Расчет произведем усредненным показателям времени работы в системе и оклада экспертов и продавцов, предоставленных бухгалтерией (Таблица 3.2): Время, затрачиваемое продавцом, на создание и обработку заявки на экспертизу в ИС, рассчитаем по формуле 5: Т мес  119  0,67 мес. 22  8 Время, затрачиваемое экспертами, на обработку заявки на экспертизу в ИС: Т мес  120  0,68 мес. 22  8 72 Зпп =(50 000 руб. * 0,67 мес.* ((1+0,1)*( 1+0,26)+ 0,4 +0,1))+ (45 000 руб. * 0,68 мес. * ((1+0,1)*( 1+0,26)+ 0,4 +0,1))=63 181+57 712 = 120 893 руб. Общие эксплуатационные затраты на техническое обслуживание в соответствии с формулой 3 будут равны: Сто= Зпп + Зпи=120 893 руб. + 31 119 руб. = 152 012 руб.; Затраты на электроэнергию рассчитываем по формуле 6: n (6), где Зэл  F   M   Ц П  1 кВт/ ч М·ρ – мощность ρ-го оборудования, входящего в электронновычислительный комплекс, кВт, средняя принятая мощность 0,45 кВт; ЦкВт/ч – цена 1 кВт/ч электроэнергии, руб./час. FП – фонд рабочего времени вычислительных машин в информационной системе. Зэл = 350 ч *0 ,45 кВт *3,84 руб./кВт/ч=605 руб. Общие эксплуатационные затраты: С= 152 012 + 605+ 5%= 160 248 руб. Экономия, полученная в результате использования веб-версии системы, будет равна: П = С + Е * К = 160 248 + 711 559 руб. * 8% = 217 172 руб. Для оценки эффективности необходимо рассчитать прямой экономический эффект, то есть определить разность затрат с существующей ИС и новому предложенному варианту ИС. Эпрям = П0 – П1=Сзп – ∑С – Е * К (7),где Сзп – сокращение заработной платы управленческого персонала при внедрении нового варианта ИС; ∑С –общие эксплуатационные затраты на новый вариант Ис без учета заработной платы управленческого персонала. 73 С применением усовершенствованного варианта СЭД снижать заработную плату или сокращать штат сотрудников не планируется, следовательно: Сзп = С0зп – С1зп =0 (8), где С0зп – заработная плата управленческого персонала в базовом варианте; С1зп – заработная плата управленческого персонала в предлагаемом варианте. Поэтому, в соответствии с формулой 7: Эпрям = 0 – 217 172 руб = – 217 172 руб. Прямой экономический эффект является отрицательным, так как нет экономии на заработной плате сотрудников, и для обоснования затрат на создание новой версии СЭД, необходимо рассмотреть косвенный экономический эффект. Косвенный экономический эффект рассчитывается по следующей формуле: Экосв = ΔА+ΔСсеб+ΔШ (9), где ∆А – годовой прирост выручки от реализации продукции; ЭИС напрямую не влияет на увеличение выпуска продукции, она помогает сократить риски потерь документов и время, затрачиваемое на обработку; ∆Ссеб – годовая экономия на себестоимости продукции объекта управления; ∆Ш – сокращение штрафов и других непланируемых потерь за год. При внедрении веб-версии СЭД мы главным образом сэкономим на времени проведения экспертизы, сократиться время обработки заявки и занесения данных в систему, что непосредственно скажется на себестоимости работ. Экономия времени на обработку данных в системе составит примерно 15%. Себестоимость работ при этом сократиться на 74 6%. Себестоимость проведения экспертиз в месяц составляет около 360 тыс. руб, поэтому в расчете будем использовать именно эту цифру. Как уже было сказано в первой главе разрабатываемая система является пилотной разработкой призванной в дальнейшем приносить выручку компании. Поэтому включим ожидаемый прирост выручки в расчет косвенного экономического эффекта. Годовой прирост выручки от реализации нового программного решения оценивается в 10%. Выручка за предыдущий год, согласно данным из Отчета о финансовых результатах за 2015 год составила 10 850 280 руб. С использованием веб-версии СЭД изменения непланируемых потерь не произойдет, поэтому не будем включать данную составляющую в расчет косвенного экономического эффекта (формула 9). Экосв= ((1 085 0280 руб.+ 10%) –10 850 280 руб.) + 259 200 руб.= 1 085 028 руб. + 259 200 руб. = 1 344 228 руб. Как мы видим косвенный экономический эффект – положительный, даже если мы не будем учитывать прибыль, которую мы ожидаем получить при продаже решения заказчикам. Итак, годовой экономический эффект рассчитаем по формуле 10: ΔЭгод = Экосв + Эпрям (10), ΔЭгод = 1 344 228 руб.– 217 172 руб. = 1 127 056 руб. Абсолютный показатель эффективности составит: Э = ΔЭгод – П = 1 127 056 руб.- 217 172 руб.= 909 884 руб. Если не учитывать прибыль, которую мы хотим получить от продажи решения, то экономический эффект составит: Эгод2= 259 200 руб.- 217 172 руб.= 42 028 руб. Э2= 259 200 руб.- 217 172 руб.= 42 028 руб. Помимо экономической эффективности можно рассчитать вспомогательные показатели экономической эффективности рентабельность и срок окупаемости проекта. Данные показатели рассчитаем на основе 75 эффективности полученной с учетом ожидаемой прибыли от продажи решения. Рентабельность рассчитаем по формуле 11: Р Э год (11) , К Э 1127 056 Р  год   1,58. К 711 559 Срок окупаемости, рассчитывается по формуле 12: Т ок  1 К  (12), Р Э год Т ок  0,63. Разработка проектного решения продлится около года. Срок окупаемости для такого проекта согласно расчетным данным достаточно хороший – примерно 7,5 месяцев. В результате разработки и внедрения вебверсии СЭД компания не только сокращает время обработки экспертиз, но и получает современный программный продукт, который при продаже позволит выполнять одну из главных задач компании: сделать работу клиентов с документами простой и эффективной, а также получить прибыль от нового решения. 76 ЗАКЛЮЧЕНИЕ В рамках выполнения выпускной бакалаврской работы был проведен анализ предметной области: проведение предпроектной экспертизы в рамках предпроектной деятельности компании «Диджитал Дизайн», описаны бизнес-процессы данной деятельности, проведен анализ и существующее программное обеспечение, обеспечивающее изучено обработку заявок на выполнение предпроектной экспертизы, произведен расчет экономической целесообразности создания веб-приложения. Построена функциональная модель предметной области, информационно-технологическая схема решения задачи обработки заявки на предпроектную экспертизу. Проведено сравнение основных подходов к проектированию веб-сервисов, позволившее обосновать используемый подход создания веб-сервиса. Для создания веб-приложения были решены следующие задачи: - описание входной и выходной информации; - проектирование запросов веб-сервиса и форм ответа на них; - разработка поисковых запросов для организации поиска; - проектирование и настройка объектов системы документооборота. Разработанное веб-приложение системы электронного документооборота сокращает время от момента получения информации от заказчика до создания заявки на проведение экспертизы, время на внесение данных экспертизы в систему, снижает затраты сотрудников на работу с системой, повышает уровень эргономики системы документооборота. Полученный опыт в проектировании веб-приложения повысил уровень интеллектуального капитала компании. А созданное приложение стало новым продуктом в портфеле компании, которое успешно внедряется заказчикам. Разработанное документооборота веб-приложение протестировано и системы внедрено в электронного эксплуатацию подразделении автоматизации документооборота и бизнес-процессов. 77 в

ВКР

Related documents

Products

Support

ВКР

Related documents

Add this document to collection(s)

Add this document to saved

Suggest us how to improve StudyLib