Файл: Концепция сервисноориентированной архитектуры.rtf

3. Анализ практического применения SOA в ИТ компании

Данный раздел работы посвящен анализу интеграции систем при использовании в компании сервисно-ориентированного подхода. В этой главе будет рассмотрен один бизнес-процесс и его протекание в нескольких смежных системах. Также будет описано взаимодействие систем при помощи вызовов веб-сервисов и передачи сообщений в XML-формате на примере одной точи интеграции (ТИ). В качестве объекта исследования выбрана модель сервисно-ориентированной архитектуры, развернутая в российской компании-интеграторе «ЗАО КРОК инкорпорейтед». На практических примерах будут раскрыты преимущества веб-сервисов, и будут приведены доказательства эффективности их использования. В Приложении 1 приведен глоссарий терминов и аббревиатур, используемых в Компании.

3.1 Описание деятельности компании «ЗАО КРОК Инкорпорейтед»

ЗАО «КРОК Инкорпорейтед» (далее - Компания) - российский системный интегратор, который работает на ИТ-рынке c 1992 года и входит в топ-10 крупнейших ИТ-компаний России [11].

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

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

---

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

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

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

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

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

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

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

---

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

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

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

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

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

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

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

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

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

---

CRM значится Директор клиента.

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

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

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

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

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

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

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

---