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

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

Описание информационных связей организации приведено в  таблице 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 (как есть). Эта модель представляет собой «снимок» положения дел на момент обследования и позволяет понять, как функционирует организация с позиции системного анализа, выявить ряд ошибок и узких мест. Так же позволяет сформулировать ряд предложений по улучшению ситуации.

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

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

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

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

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

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

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

 

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Диаграмма процессов модели AS-IS приведена в приложении А.

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

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

 

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

 

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

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

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

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

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

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

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

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

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

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

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

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

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

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