Проектирование системы электронного документооборота в SAP R/3 для автоматизации договорной работы группы компаний "САПРАН"

Размещено на http://www.allbest.ru/

Размещено на http://www.allbest.ru/

КУРСОВОЙ ПРОЕКТ

Проектирование системы электронного документооборота в SAP R/3 для автоматизации договорной работы группы компаний «САПРАН»



Определения и сокращения

Термины и сокращения с соответствующими определениями, применяемые в настоящем проекте приведены в таблице 1.

Таблица 1. - Определения и сокращения

Термин	Определение
АС	Автоматизированная система
АСУ	Автоматизированная система управления
Бизнес-процесс	Последовательность работ, направленных на решение одной из задач предприятия
ГОСТ	Государственный стандарт
ЖЦ	Жизненный цикл
ИС	Информационная система
ПО	Программное обеспечение
ТЗ	Техническое задание
CASE (Computer Aided Software/ System Engineering)	Автоматизированная разработка программного обеспечения
IDEF0	Методология моделирования бизнес-процессов
ERD	Диаграммы «сущность-связь»
Система	Система электронного документооборота на базе SAP RCM
Договор	Соглашение двух или нескольких лиц об установлении, изменении или прекращении гражданских прав и обязанностей, независимо от его конкретного наименования (контракт, соглашение, предварительный договор и т.п.)
Карточка договора	Объект системы SAP, содержащий атрибуты договора, графики поставок и оплат, маршрут и историю согласования. А также ссылки на файлы связанные с договором.
Рамочный договор	Договор на оказание услуг (поставку товара, выполнение работ), не имеющий стоимостного выражения.
Дополняющий документ	Документ, дополняющий условия договора. Как правило, это дополнительное соглашение, но также может быть приложение, заявка/заказ или иной дополняющий документ.
Документ без договора	Документ, служащий основанием для проведения расчетов с контрагентами, но не являющийся договорным документом. Например, товарный чек, счет на оплату.
Владелец договора	Сотрудник, ответственный за согласование договора и подписание договора контрагентом. Как правило, это сотрудник отдела продаж или директор будущего проекта. Если договор расходный, то функцию будет выполнять руководитель подразделения, которое закупает товары/услуги. Например, руководитель департамента информационных технологий или руководитель департамента управления персоналом.
Руководитель Владельца договора	Руководитель подразделения, в котором работает Владелец договора. Определяется по управленческой структуре SAP HR.
Исполнитель по договору	Сотрудник, ответственный за исполнение договора, выполняющий задачи по корректировке плановых дат в графиках оплат и поставок, оформлению заявки на формирование акта. Как правило, руководитель проекта
Лист согласования	Лист, который включает в себя все замечания, полученные на последнем круге согласования. Распечатывается сотрудником договорного отдела при передаче документа, согласованного в Системе, на подписание.



Введение

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

Ежедневно в масштабах организаций обрабатываются огромные массивы документов. Многие из них порождают большое количество сопровождающих документов. В результате появляются потоки документов, которые приходиться контролировать и перераспределять между различными подразделениями. Известно, что до 30% рабочего времени сотрудников уходит на поиск документов и другие рутинные операции, 15% документов безвозвратно теряется, а 80% времени руководитель тратит на работу с информацией^.

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

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

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

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

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

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

· Исследование функциональной и информационной структуры организации, разработка модели деятельности «как есть», анализ недостатков.

· Формулировка предложений по совершенству существующей системы, разработка модели деятельности "как должно быть".

· Разработка технического задания на разработку информационной системы.

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

· Рамочные соглашения.

· Договоры в административно-хозяйственной части

· Дополнительные соглашения

· Прочие виды документов (соглашение о неразглашении, разовые счета и т.д.)

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

· Снижение трудозатрат на поиск документов

· Автоматизация процесса согласования документов

· Контроль сроков согласования

· Организация хранения документов с поддержкой версионности

· Автоматизация формирования документов по шаблону

· Организация разграничения доступа к документам

· Автоматизация отчетности

Применяемые регламентирующие документы:

· Стандарт ARIS eEPC для моделирования бизнес-процессов и информационных потоков;

· ГОСТ 19.201-78 "Единая система программной документации. Техническое задание. Требования к содержанию и оформлению";

· ГОСТ 34.602-89 "Информационная технология. Комплекс стандартов на автоматизированные системы. Техническое задание на создание автоматизированной системы".



1. Задание на курсовое проектирование

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

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

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

· Исследование функциональной и информационной структуры организации, разработка модели деятельности «как есть», анализ недостатков.

· Формулировка предложений по совершенству существующей системы, разработка модели деятельности "как должно быть".

· Разработка технического задания на разработку информационной системы.

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

· Рамочные соглашения.

· Договоры в административно-хозяйственной части.

· Дополнительные соглашения.

· Прочие виды документов (соглашение о неразглашении, разовые счета и т.д.).

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

· Снижение трудозатрат на поиск документов.

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

· Контроль сроков согласования.

· Организация хранения документов с поддержкой версионности.

· Автоматизация формирования документов по шаблону.

· Организация разграничения доступа к документам.

· Автоматизация отчетности.

2. Общая характеристика объекта автоматизации

САПРАН - это группа компаний, специализирующаяся на внедрении ИТ решений для бизнеса на различных платформах. Сегодня компания насчитывает около 300 сотрудников, около 30 из них - непроизводственный персонал. Офисы САПРАН расположены в Москве, Санкт-Петербурге и Киеве. Начиная с 2008 года компанией САПРАН реализовано около 100 проектов, ежегодный рост оборотов от оказания сервисных услуг удваивается на протяжении последних трех лет. По итогам 2012 года САПРАН входит в 100 крупнейших и в 10 самых быстрорастущих ИТ компаний России. Организационно-штатная структура группы компаний Сапран приведена на рис.1. Инициатором заключения договора может выступать любое подразделение. Документ должен быть обязательно утвержден финансовым отделом, бухгалтерией и юридическим отделом. Только после утверждения всеми вышеперечисленными отделами документ поступает на подпись директору.

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

Организационно-штатная структура приведена на рисунке 1.



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

3. Анализ известных подходов к решению проблемы

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

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

· Системы обработки структурированной информации - класса ERP(SAP);

· Системы для обработки неструктурированной информации - скан-копии документов и сами документы как таковые - системы класса ECM.

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

1. DMS - Document Management System

2. RCM - Record and Case Management System

3. ECM - SAP xECM by OpenText

Необходимо отметить, что если первые два решения являются частью SAP ERP ECC, то третье, хоть и является тесно интегрированным в SAP ERP- представляет собой отдельную платформу. Для автоматизации электронного документооборота конкретной организации следует выбирать из компонентов, входящих в стандартную платформу, с целью уменьшения эксплуатационных расходов Заказчика. Так как DMS является хорошо известной и давно внедряемой на рынке компонентой, остановимся на RCM - достаточно недавно появившейся в линейке продуктов SAP и еще не завоевавшей широкого признания в России, как со стороны фирм интеграторов, так и со стороны клиентов. Тем не менее, SAP RCM обладает всеми традиционными возможностями современных систем электронного документооборота. Она охватывает практически все аспекты в области управления документами и позволяет организовать эффективную документационную поддержку бизнес-процессов компании в соответствии с требованиями государственных стандартов, нормативных документов и принятых в компании принципов работы в существующих регламентах. Необходимо отметить, что RCM построена с использованием методологии SOA. Это позволяет ей обладать достаточной гибкостью, в отличии от DMS.



4. Средства разработки системы

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

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

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

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

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

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

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

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

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

В настоящее время на практике количество CASE-средств, поддерживающих объектно-ориентированный подход, невелико по сравнению с поддерживающими структурный подход. В том числе, диаграммы, отражающие специфику объектно-ориентированного подхода, гораздо менее наглядны и плохо понимаемы непрофессионалами. Примерами объектно-ориентированных CASE-средств являются: Rational Rose фирмы Rational Software, Sybase PowerDesigner и Paradigm Plus фирмы Computer Associates, предназначенные для автоматизации этапов анализа и проектирования ПО.

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

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

1. целей проекта;

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

3. возможностей CASE-систем по описанию процессов с учетом требований п.2.

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

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

ERwin - средство проектирования баз данных. Отличительной чертой ERwin/ERX является высокая степень обеспечения согласованного взаимодействия между средствами создания баз данных и средствами разработки приложений. ERwin поддерживает все наиболее популярные реляционные СУБД, включая Oracle; Sybase; Informix; Microsoft SQL Server; FoxPro; InterBase; Paradox; Access и др. Одна и та же модель может быть использована для создания нескольких баз данных или для переноса приложения с платформы одной СУБД на другую. ERwin можно использовать совместно со многими популярными средствами разработки приложений.

Sybase PowerDesigner - комплексное решение для решения задач анализа деловой и производственной активности, задач проектирования баз данных, сочетающее в себе возможности BPWin и ERWin.

Aris Toolset - предоставляет визуальный инструментарий для обеспечения наглядности моделей. Также инструментарий поставляется с набором референтных моделей, заранее разработанных для типичных процессов в различных отраслях. Кроме того, в ARIS предусмотрена возможность создания сценариев автоматизации составления различных аналитических отчётов, нормативных документов, новых моделей. Каждый сценарий представляет собой подпрограмму, запускаемую в ARIS Business Architect (либо Toolset -- более ранней версии) или непосредственно на сервере ARIS. Сценарии пишутся на специальном языке программирования -- SAX Basic.

Продукт ARIS используется в различных проектах по реинжинирингу и оптимизации бизнес-процессов, ИТ-проектах типа внедрения и эксплуатации ERP-систем, в частности, есть проработанное интеграционное решение для SAP R/3. Также программное обеспечение ARIS составляет основу пакета Business Process Analysis Suite корпорации Oracle. Технически инструментарий ARIS достаточно простой для изучения, имеет интуитивно понятный интерфейс. Модели легко копируются и вставляются в файлы документов (например, формата doc) в виде рисунков. При этом инструмент обладает обширным функционалом: от описания до стратегического планирования

Для моделирования бизнес-процессов организации было выбрано CASE-средство ARIS Toolset.

Язык программирования - ABAP/4, так как это внутренний язык программирования системы SAP R/3. Язык реализует работу с внутренними структурами данных, интерфейсом пользователя SAP R/3, транзакциями, отчётами, интерфейсами загрузки и выгрузки данных. Используется исключительно для бизнес-приложений и промежуточного программного обеспечения компании SAP. Имеет возможности для объектно-ориентированного программирования. Имеет сборщик мусора.

5. Анализ информационных потоков

Информационные потоки - это физическое перемещение информации от одного сотрудника предприятия к другому или от одного подразделения к другому (Преобразование информации не рассматривается в качестве информационных потоков).

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

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

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

· несвоевременность предоставления информации;

· потеря информации;

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

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

· трудоемкость формирования типовых документов;

· трудоемкость осуществления массовых и типовых операций;

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

· непрозрачность процесса согласования, невозможность отследить степень готовности документа к подписанию;

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

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

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

Описание информационных связей организации приведено в таблице 2.

Таблица 2 - Описание информационных связей организации

№	Вид документа	Исполнитель	Получатель	Описание
1	Заявка на создание делового партнера	Владелец договора	Договорной отдел	Заполняется, если ранее не было договоров с этим контрагентом
2	Заявка на создание карточки договора	Владелец договора	Договорной отдел	Заполняется, если отсутствует проект договора. Содержит основные данные по договору
3	Проект договора	Владелец договора	Договорной отдел	Текст договора, предложенный контрагентом, или составленный юристом организации
4	Спецификация к договору	Владелец договора	Договорной отдел	Составляется только для доходных договоров. Содержит информацию о себестоимости
				проекта и о планируемой прибыли
5	Лист согласования	Договорной отдел	Директор	Содержит комментарии, полученные в ходе согласования проекта договора

6. Разработка модели деятельности «как есть»

Для достижения поставленных целей наиболее удобным языком моделирования бизнес-процессов является ARIS eEPC (Событийная цепочка процессов EPC, англ. event-driven process chain)

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

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

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

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

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

Логические взаимосвязи -- элементы управления, отвечающие за сочленение потоков -- конъюнкция, дизъюнкция или строгая дизъюнкция.

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

Функциональная модель предназначена для описания существующих бизнес-процессов (модель AS-IS) и идеального положения вещей - того, к чему нужно стремиться (модель ТО-ВЕ).

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



Описание функций

Передача информации в договорной отдел (функция № 1.1)

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

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

Роли: Владелец договора.

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

Результат функции: Сотрудник договорного отдела получает информацию, необходимую для заключения договора.

Анализ полученной информации (функция № 1.2)

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

Роли: Сотрудник договорного отдела.

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

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

Проверка предложенного проекта (функция № 1.3)

Входящие события: Проект договора был предложен контрагентом.

Входящие/исходящие документы: Проект договора, утвержденный юристом.

Роли: Сотрудник договорного отдела.

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

Результат функции: Проект договора утвержден юристом.

Составление нового проекта договора (функция № 1.4)

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

Входящие/исходящие документы: Проект договора, утвержденный юристом.

Роли: Сотрудник договорного отдела.

Описание функции: Сотрудник договорного отдела создает проект договора для предложения этого проекта контрагенту.

Результат функции: Проект договора утвержден юристом.

Передача проекта договора в финансовый департамент (функция № 1.5)

Входящие события: Проект договора был утвержден юристом.

Входящие/исходящие документы: Проект договора.

Роли: Сотрудник договорного отдела.

Описание функции: Сотрудник договорного отдела после утверждения проекта договора передает его на рассмотрение в финансовый департамент.

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

Договор согласован финансовым департаментом (функция № 1.6)

Входящие события: Проект договора поступил в финансовый департамент.

Входящие/исходящие документы: Проект договора.

Роли: Сотрудник финансового департамента.

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

Результат функции: Проект договора согласован финансовым департаментом и передан на подпись директору.

Договор подписан с нашей стороны (функция № 1.7)

Входящие события: Проект договора поступил на подпись директору.

Входящие/исходящие документы: Проект договора, Лист согласования с комментариями и замечаниями согласующих.

Роли: Директор.

Описание функции: Директор подписывает договор.

Результат функции: Договор подписан и отправлен контрагенту.

Договор подписан со стороны контрагента (функция № 1.8)

Входящие события: Договор отправлен контрагенту.

Роли: Владелец договора.

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

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

Договор принят на хранение в бухгалтерию (функция № 1.9)

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

Входящие/исходящие документы: Договор.

Роли: Бухгалтер.

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

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

Диаграмма процессов

При построении модели AS-IS были выявлены следующие недостатки:

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

· трудоемкость формирования типовых документов;

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

· непрозрачность процесса согласования, невозможность отследить степень готовности документа к подписанию;

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

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

· недостаточная степень разграничения доступа к конфиденциальным документам;

Выявленные недостатки можно исправить при создании модели TO-BE

7. Разработка модели деятельности «как должно быть»

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

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

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

Список процессов, подлежащих автоматизации:

1. Создание, согласование и перевод карточки договора в статус «Действующий».

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

2. Отражения факта актирования/поставки.

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

2.1 Исполнение доходных договоров.

2.2 Исполнение расходных договоров.

3. Корректировка плановых дат в графике оплат.

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

4. Отражение факта оплаты в графике оплат.

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

5. Закрытие договора, перевод в статус «Закрыт».

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

6. Создание нового проекта в справочнике проектов.

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

Описание функций

Процесс создания, согласования и перевода карточки в статус «Действующий»

Передача информации в договорной отдел (функция № 1.1)

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

Роли: Владелец договора.

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

Результат функции: Сотрудник договорного отдела получает информацию, необходимую для регистрации карточки договора в статусе «Проект».

Проверка наличия информации о контрагенте и проекте в системе (функция № 1.2)

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

Роли: Сотрудник договорного отдела

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

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

Создание контрагента (функция № 1.3)

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

Роли: Бухгалтер

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

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

Создание карточки договора, формирование графиков (функция № 1.4)

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

Роли: Сотрудник договорного отдела

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

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

Результат функции: Карточка договора создана, статус карточки «Проект».

Прикрепление проекта договора. Актуализация графиков. Отправка на согласование (функция № 1.5)

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

Роли: Сотрудник договорного отдела

Входящие/исходящие документы: Проект договора

Описание функции: Проект договора может быть получен от контрагента или сформирован по типовой форме. Если проект договора получен от контрагента, то сотрудник договорного отдела прикрепляет проект договора в компонент «Соединенные объекты». Если проект договора сформирован по типовой форме, то он будет прикреплен в компонент «Соединенные объекты» автоматически.

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

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

Результат функции: Договор отправлен на согласование в финансовую службу, карточка договора переведена в статус «На согласовании».

Согласование юридической службой (функция № 1.6)

Входящие события: Договор отправлен на согласование в юридическую службу

Роли: Юрист

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

Результат функции: Договор согласован юридической службой и отправлен на согласование в финансовую службу.

Согласование финансовой службой (функция № 1.7)

Входящие события: Договор отправлен на согласование в финансовую службу

Роли: Сотрудник финансовой службы

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

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

Результат функции: Договор согласован финансовой службой, отправлен на согласование в бухгалтерию

Согласование бухгалтерией (функция № 1.8)

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

Роли: Бухгалтер

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

Результат функции: Договор согласован бухгалтерией

Согласование исполнительным директором (функция № 1.9)

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

Роли: Исполнительный директор

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

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

Подписание договора с контрагентом (функция № 1.10)

Входящие события: Договор согласован бухгалтерией

Роли: Владелец договора

Входящие/исходящие документы: Договор, подписанный контрагентом

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

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

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

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

Результат функции: Договор подписан контрагентом, карточка договора переведена в статус «Согласован»

Передача оригинала в договорной отдел (функция № 1.11)

Входящие события: Договор подписан со стороны контрагента

Роли: Владелец договора

Описание функции: Владелец договора передает (контролирует передачу) оригинал договора, подписанного контрагентом, в договорной отдел.

Результат функции: Оригинал договора передан в договорной отдел

Передача на подписание и перевод договора в статус действующий (функция № 1.12)

Входящие события: Оригинал договора передан в договорной отдел

Роли: Сотрудник договорного отдела

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

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

После того, как оригинал договора подписан обеими сторонами, сотрудник договорного отдела сканирует документ, прикрепляет скан-копию к карточке договора и переводит договор в статус «Действующий».

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

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

Результат функции: Договор переведен в статус «Действующий»

Процесс исполнения доходных и расходных договоров

Формирование заявки на акт (функция № 2.1)

Входящие события: Работы по этапу проекта T&M завершены

Роли: Сотрудник, ответственный за исполнение договора. Как правило, руководитель или директор проекта, далее Исполнитель по договору

Описание функции: Если в договоре указан способ закрытия T&M, то Исполнитель по договору через корпоративный портал должен проверить и актуализировать сумму в графике поставок перед тем, как делать заявку на акт. К заявке на акт должны быть приложены листы учета рабочего времени, подписанные заказчиком.

Результат функции: Сумма в графике поставок актуализирована.

Формирование заявки на акт (функция № 2.2)

Входящие события: Работы по этапу проекта Fix Price завершены или сумма в графике поставок договора T&M актуализирована

Роли: Исполнитель по договору

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

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

Результат функции: Информация, указанная в заявке, передана в бухгалтерию.

Формирование акта (пакета документов) (функция № 2.3)

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

Роли: Бухгалтер

Описание функции: Бухгалтер, на основании информации, указанной в заявке, выставляет акт (формирует пакет документов) и отправляет его контрагенту для подписания.

Результат функции: Акт выставлен и отправлен контрагенту

Подписание акта контрагентом (функция № 2.4)

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

Роли: Исполнитель по договору

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

Результат функции: Акт подписан контрагентом и передан в бухгалтерию.

Получение акта, отражение факта актирования в графике поставок, прикрепление скан-копии акта к карточке договора (функция № 2.5)

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

Роли: Бухгалтер

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

Результат функции: факт актирования отражен

Процесс корректировки плановых дат

Отправка уведомления Исполнителю по договору (функция № 3.1)

Входящие события: Наступила дата рассылки

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

Результат функции: Сообщение отправлено Исполнителю по договору, Владельцу договора и в финансовую службу

Корректировка прогнозных дат в графике оплат (функция № 3.2)

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

Роли: Исполнитель по договору

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

обратиться в финансовую службу с просьбой проверить поступление оплаты.

Результат функции: График оплат актуализирован.

7.1.4 Процесс отражения факта оплаты

Отражение оплаты по договорам в графиках оплаты (функция № 4.1)

Входящие события: Получена банковская выписка

Роли: Бухгалтер

Описание функции: Сотрудник бухгалтерии отмечает фактическую дату оплаты в графиках оплат по договорам (доходным и расходным)

Результат функции: Факт оплаты отражен.

Процесс закрытия договора

Перевод договора в статус «Закрыт» (функция № 5.1)

Входящие события: Договор исполнен, все оплаты проведены.

Роли: Сотрудник договорного отдела.

Описание функции: Сотрудник договорного отдела вручную устанавливает статус «Закрыт» в карточке договора.

Результат функции: Договор переведен в статус «Закрыт».

Процесс создания нового проекта

Отправка заявки на создание нового проекта в справочнике проектов (функция № 6.1)

Входящие события: Требуется создать новый проект в справочнике проектов

Роли: Инициатор создания проекта

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

Результат функции: Заявка на создание проекта в справочнике проектов отправлена в договорной отдел.

Создание нового проекта в справочнике проектов (функция № 6.2)

Входящие события: Заявка на создание проекта отправлена в договорной отдел

Роли: Сотрудник договорного отдела

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

8. Разработка инфологической модели

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

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

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

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

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

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

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

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

Логическая модель

Жизненный цикл договора включает в себя следующие этапы:

· Подготовка спецификации, проекта договора

· Внесение информации в систему

· Согласование пакета документов

· Подписание обеими сторонами

· Принятие к действию подписанного договора

· Исполнение обязательств по договору

· Закрытие договора

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

Таблица 3 - Сводная таблица сущностей

Имя сущности	Описание
Логический уровень	Физический уровень
Карточка «договор»	ZTRCM_AGR	Карточка «Договор»
Тип документа	ZTRCM_DOC_TYPE	Справочник «Тип документа»
Вид документа	ZTRCM_DOC_KIND	Справочник «Вид документа»
Филиал	ZPROJ_BRANCH	Справочник филиалов
Валюта договора	TCURC	Справочник валют
Деловой партнер	BUT000	Справочник деловых партнеров
Платежные реквизиты	BUT0BK	Справочник платежных реквизитов
Условия оплаты	ZTRCM_PAY_COND	Справочник условий оплат по договору
График оплат	ZTRCM_PAYMENT_P	План платежей
График поставок	ZTRCM_DELIVERY_P	План поставки
Проект	ZPROJ	Справочник проектов
Этап проекта	ZPROJST	Справочник этапов проектов
Пользователь	USR02	Справочник пользователей

Атрибуты сущностей

Каждая сущность обладает определенным набором атрибутов. Атрибут - какая-либо характеристика понятия или предмета, смысл которого отражает сущность.