Платформа управления заданиями

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

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

Основная идея платформы управления заданиями следующая.
Приложение разбивается на две части. Первая представляет собой базу данных, которая хранит задания, их статусы, историю изменений и т.д. Заодно в этой базе хранится список сотрудников, их группы, роли и естественно назначения конкретного сотрудника на ту или иную задачу. К этому компоненту примыкает пользовательский интерфейс, позволяющий людям просматривать свои задачи, редактировать их статусы, добавлять необходимую информацию. В общем, все то, что обычно съедать огромное количество трудозатрат на разработку такого приложения с нуля. Однако вся логика работы с заданиями вынесена в другую часть приложения, называемую process manager. Вся специфика конкретного процесса реализуется именно там. Мы можем реализовать в этой части множество различных процессов, и все они будут использовать функционал первой части. Более того, мы можем добавлять в этот компонент задания из других приложений, что избавит пользователей от необходимости работы с несколькими приложениями.

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

Платформа управления заданиями: 8 комментариев

  1. Думаю, на III BPM был затронут ещё один немаловажный аспект для заданий – пересчёт для приоритизации (доклад Дмитрия Бацюро из компании “Атлантик”) заданий для пользователя с учётом всех заданий в системе.
    Любопытно, насколько сильно может оказаться перегруженной система из-за регулярных пересчётов (в докладе прозвучало, для для 1300 заданий каждые 10 минут по 3 минуты пересчёт) при росте масштаба. И являются ли подобные пересчёты необходимостью?

    1. Этот пример еще раз подчеркивает, что элементарные задачи(поручения) – это основной элемент, своего рода “атом” управления в компаниях. Пока мы их не вытащим на свет, разобраться в том, как работает предприятие крайне затруднительно.

      PS: В сообщении про use case у меня, похоже, закончилась разрешенная глубина вложенности комментариев(буду смотреть настройки) и ответить на Ваш #12 комментарий я уже не могу. В той ветке, я интересовался именно документами со списками действий, которые, как я понял из ответа, Вы ассоциируете с пиктограммой UC в Rational Rose. У нас просто таких описаний очень много и мы пытаемся их каким-либо образом упорядочить

      1. Декомпозиция как борьба со сложностью. 🙂 У меня в практике не было слишком сложных UC, поэтому отношение пиктограмм к текстовому описанию UC было всегда 1:1, а число UC редко переваливало за 50 с учётом и . Были также версии текстовых описаний, но с ними как-то проблем не возникало.

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

  2. Гм… Не все символы в тексте корректно передаются (я про угловые скобки), поэтому добавлю после “… с учётом…” слудующее: “отношений include и extend”.

  3. Есть теория автоматов, и все BPEL и XPDL растут оттуда. Ты же хочешь получать сведения о состояниях автоматов своих и своих подчиненных.

  4. Не-а…сам процесс это описание автомата.
    Т.е. когда инициируется процесс создается его экземпляр. Этот экземпляр и является автоматом. У этого автомата есть абстрактный вход, куда поступают внешние воздействия от внешних систем, и в зависимости от этого он меняет свое состояние и что-то поступает на абстрактный выход, т.е. воздействия от “движка” на внешние системы.
    Теперь выворачиваем это все наизнанку и смотрим, у каких автоматов на выходе воздействия на тебя и твоих подчиненных(опосредованно, через системы, внешние по отношению к “движку”, но непосредственно взаимодействующие с пользователями)

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *