Дипломная (вкр): Модель сервисно-ориентированной архитектуры и концепция распределенных бизнес-приложений

3.2 Моделирование процесса, протекающего в смежных системах

В этом разделе будет рассмотрен процесс Согласования договора (СД), который главным образом протекает двух системах: в системе управления ресурсами компании 1С:ERP и системе автоматизации бизнес-процессов К2 с вызовами смежной системы финансового планирования Финансовый калькулятор (ФК).

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

- согласовать договор с юристом, бухгалтером;

утвердить рентабельность плановых данных при их наличии;

по итогам согласования проставить ЭЦП;

- отразить в карточке договора изменения, связанные с согласованием договора.

Автоматизация бизнес-процесса согласования договора выполняется с целями:

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

гарантировать наличие актуальной информации при согласовании договора;

обеспечить контроль проставления ЭЦП.

Описание процесса по шагам представлено в разделе «3.2.1. Описание инициации и шагов процесса». Для создания схемы процесса выбрана нотация EPC, поскольку она позволяет описать процесс в виде последовательности функций, не имеет жесткого определенного набора необходимых элементов для построения, а также позволяет дать ответы на вопросы «С чего началось?», «Что сделали?», «Кто выполнил?». Данная нотация позволяет выделить важную информацию, необходимую в дальнейшем для построения схемы интеграционного взаимодействия, и избежать перегруженности схемы за счет опущения некоторых деталей (например, входящих/исходящих бумажных документов, терминов или товарно-материальных ценностей), которые в контексте интеграции систем не важны. Схема процесса в нотации EPC представлена в Приложении 3.

3.2.1 Описание инициации процесса и его шагов

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

)        Формирование

Интерфейс формирования открывается в системе К2 после перехода на нее из карточки договора в 1С и является стартовой формой бизнес-процесса. Процесс формируется после отправки данных с этой формы.

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

)        Проверка администратором (ПА)

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

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

)        Согласование юристом (СЮ)

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

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

На данном шаге меняется ответственный за процесс, и ответственным становится юрист. Возможный исполнитель выбирается из заранее назначенной группы ответственных юристов. Любой из указанной группы имеет равные права для принятия решения на шаге, но решение принимается только одним участником - первым, кто обработал процесс. Юрист принимает решение о правомерности заключения определенного договора, проставляет ЭЦП на электронных документах. Если юрист замечает некорректность в заполнении договора, он имеет возможность отправить процесс обратно на Проверку администратором с соответствующим комментарием и статусом «Не утверждено». При успешном согласовании он также отправляет процесс на Проверку администратором со статусом «Утверждено».

)        Согласование менеджером (СМ)

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

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

)        Согласование Директором клиента (ДК)

Процесс должен быть отправлен на данный шаг процесс, если на этапе Формирования в карточке договора в 1С была указана организация, по которой в системе CRM значится Директор клиента.

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

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

)        Согласование бухгалтером (СБ)

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

)        Расчет рентабельности (РР)

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

3.2.2 Описание фрагмента интеграционной схемы

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

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

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

Таблица 3.1. Методы веб-сервиса

Описание шага «Формирование» с вызовами веб-сервисов: сотрудник создал в учетной системе 1С карточку договора и заполнил ее реквизиты (наименование, клиента и т.д.) и нажал на кнопку Согласование договора в карточке. Данное событие служит началом процесса Согласование договора, происходит переход в систему К2, открывается форма согласования К2. Система К2 вызывает метод GetAgreementData учетной системы 1С для получения заполненных реквизитов и вывода нужных из них на форму К2. По полученным сведениям К2 определяет, является ли это договором продажи или нет. Далее есть 2 сценария развития:

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

Далее есть 2 опции: отменить процесс (в таком случае происходит выход) или нажать «Запустить». При нажатии «Запустить» происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если черновики есть, пользователю выводится сообщение о необходимости сохранить или удалить черновик, и переход на следующий шаг не осуществляется. Если метод вернул успех, процесс переходит на Проверку администратором. В случае с договорами не продажи данный метод всегда возвращает успех в виду отсутствия плановых данных.

)        Если договор является договором продажи, вызывается метод веб-сервиса CheckAgreement, который проверяет наличие этого договора в системе ФК и, если договор есть, метод возвращает успех, иначе инициируется отправка датаграммы для вставки договора в ФК, которая собирается из данных, полученных от 1С методом GetAgreementData. После чего выполнение метода CheckAgreement возвращает успех. На форму К2 выводятся данные по договору, открытие формы на этом завершается, и пользователь видит полностью загруженную форму.

Если при этом договор является корректируемым, то происходит вызов веб-сервиса для получения из учетной системы иерархии договоров GetAgreementHierarchy. При нажатии с формы кнопки «Открыть контрол для заполнения ПД», К2 вызывает открытие формы ФК, и открывается интерфейс для заполнения ПД. Дальнейшие действия по заполнению плановых данных происходят уже в системе ФК. При сохранении версии плановых данных в контроле и нажатии кнопки «Вернуться к процессу К2» происходит переход обратно на форму К2, откуда можно также отменить процесс или запустить. При нажатии Запустить происходит проверка наличия черновиков в системе ФК методом CheckConfirmDocumentDrafts. Если метод возвращает успех, процесс переходит на шаг Проверка администратором. При возвращении неудачи выводится информационное сообщение о необходимости сохранить или удалить черновик плановых данных. При возвращении методом успеха процесс переходит на шаг Проверка администратором.

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

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