Воспоминания о будущем BPMS

Несмотря на разгар лета и надвигающуюся пору отпусков тема Social BPM продолжает активно обсуждаться (см. например Social BPM Update). Мне нравятся идеи, объединяемые вокруг термина Social BPM. Я думаю, что довольно быстро они прорастут в инструмент и, что боле важно, в практики совместной работы бизнеса и ИТ по кастомиизации, реализации и улучшению бизнес-процессов. Но есть еще одно направление развития BPMS о котором я хочу рассказать.

Прошедшие пару недель я активно вникаю в Service Order Management. Естественно, не только самостоятельно, но и с помощью экспертов ведущих поставщиков информационных систем для телекома. За эту помощь огромное им спасибо, сам бы в жизни не разобрался. Так вот, есть в телекоме процесс реализации клиентского подключения, называемый Service Fulfillment для которого и используются решения класса Service Order Management. Но прежде чем рассказать о процессе, необходимо немного погрузиться в используемую терминологию. С легкой руки TMForum в телекоме выделяются следующие основные сущности. Customers – те самые абоненты для которых производится подключение. Product – бизнес-услуга, продукт, одним словом то, что продается. Resources– провода, линии связи, самые разнообразные железки, в общем все то оборудование, которое необходимо для обеспечения связи. Продукт – понятие абстрактное. Разные клиенты могут использовать один и тот же продукт. Клиенты и ресурсы – понятия конкретные. И есть еще одно понятие, именуемое оригинальным словом Service, которое связывает между собой все остальные. Т.е. сервис объединяет конкретные ресурсы сети, используемые для предоставления продукта конкретному абоненту. Для предоставления продукта может потребоваться несколько сервисов. Разумеется, сервисы имеют определенный тип, но обычно, говоря о сервисе, имеют в виду конкретный экземпляр.

Теперь о процессе. Начинается все с клиентской заявки на подключение некоторого продукта (customer order). Для каждого продукта определен набор сервисов (классов, а не экземпляров сервисов), необходимых для его предоставления. Благодаря этим мета-данным осуществляется декомпозиция заявки и поиск конкретных сервисов и ресурсов. Какие-то ресурсы находятся и резервируются, какие-то надо закупить и установить, какие-то существуют, но требуют дополнительной настройки. На основании этой информации формируется service order, содержащий набор зарезервированных ресурсов и необходимых дополнительных работ, как ручных, так и автоматизированных. Естественно, работы могут быть упорядочены относительно друг друга, обладают определенным набором состояний, допускают обработку исключений, например сбой автоматической задачи может привести к запуску ручной операции и т.д. В общем, service order – это модель конкретного экземпляра процесса подключения, сгенерированного специально для данного экземпляра. На самом деле, изменение процесса может произойти и после формирования service order, например, в ситуации, когда клиент передумал и хочет скорректировать свою заявку. Но главное, в этой деятельности именно автоматическое создание модели для конкретного экземпляра бизнес-процесса. Т.е. телеком, как это часто бывает, оказался «впереди планеты всей». Интересно, что термин Dynamic Order Management появился чуть раньше, чем Dynamic Case Management и в чем-то его превзошел.

Задумайтесь над эволюцией взглядов на системы управления бизнес процессами. Сначала, мы предполагали, что бизнес-аналитики рисуют модель процесса в BPMN, программисты её имплементируют в ПО и с ним работают конечные пользователи. Затем появился adaptive (dynamic) case management ориентированный на корректировку модели бизнес процесса на лету. А теперь мы говорим, что работу knowledge worker-а в адаптивном процессе можно автоматизировать, сгенерив конкретную модель процесса для каждого экземпляра. Через годик другой на позицию руководителя будет назначен Искусственный Интеллект и начнет раздавать нам задания =)

Воспоминания о будущем BPMS: 8 комментариев

  1. как понимаю – насчёт обработки заказа (по oss/j) – вы имеете ввиду автоматическую активацию продукта, которая включает декомпозицию соответствующего заказа продукта на заказы услуг и ресурсов, которые, в свою очередь, инициируют активацию соответствующих услуг и ресурсов. По своему опыту, реально автоматически это всё может работать только в условиях достаточно сильных ограничений: не при “автоматической генерации модели процесса”, а максимум – параметризации одной или нескольких ранее фиксированных моделей…

    Например, есть некое решение, использующее принципы sid, etom, oss/j (правда, под-пилено под некую специфику, в детали не могу погружать:)):
    1. у Продукта, услуги и ресурса фиксированная структура жизненного цикла, параметризуемая в зависимости от типа. Таким образом, набор состояний, событий и управляющих команд почти для всех экземпляров компонентов одинаковый (API) и это достаточно легко упрощает биллинг их выработки и управление (поддержка и т.п.).
    2. есть т.н. Конструктор услуг и ресурсов, где можно построить спецификацию таких компонентов, указать правила на значения параметров, определить, какие параметры определяются при заказе, как компонент связан с другими (услуга может включать другие услуги или ресурсы и т.п.).
    Здесь же необходимо указать EPR (WS-Management) сервиса-фабрики компонента, а сам компонент после создания обязан возвращается с каким-то собственным EPR, сервис которого обязан поддерживать WS-Management API + команды п.1. Здесь же необходимо построить “спецификацию выработки” компонента для биллинга – т.е. какие параметры и как должны обсчитываться.
    3. есть т.н. “Конструктор продуктов и предложений”, где можно из услуг строить предложения продуктов, создавая правила ценообразования заказа продукта, выработки для биллинга – ну и собственно расписание биллинга этого продукта, его услуг или ресурсов.
    4. Жизненный цикл всех типов заказов (как и ЖЦ компонетов по биллингу) фиксирован и, таким образом, обработка заказов с активацией по-сути является одним и тем же , параметризованным процессом, который легко ложится на какой-нибудь BPM, особенно, если последний native state-machine.
    5. Отдельное внимание уделяется бизнес-правилам для ценообразования, которые описываются на специальном DSL, который выполняется в специальной среде интегрированной с Domain (БД предметной области), в реальном времени выполняет оценки стоимости заказов, сумм для биллинга и др. – причём, правила достаточно извращённые бывают и даже экспериментальные (маркетинг, всякие акции и т.п.).
    6. ну и события: они жгутся многими ресурсами, услугами и т.п. – которые поддерживаются в консистентном состоянии в Domain DB на основе событий от их WS-Management-поставщиков (см.п.2) и других управляющих событий процессов.

    Ну так вот, где тут волшебный BPM:):
    1. разработчики создают услуги и ресурсы, подключают провайдеров – всё регистрируют в спецификациях наборами параметров.
    2. менеджеры/аналитики (правда, не без помощи программистов:)), строят свои продукты, настраивая в основном бизнес-правила и включая/выключая их для продажи, создавая связи с услугами и наборами параметров.
    3. за WS-Management может стоять кто/что угодно, которое сможет сама обработать WS-Transfer.create услуги или др. по параметрам какой-то спецификации, а дальше за состоянием услуги следит биллинг и тех-поддержка:)
    4. система почти автоматически, во многих случаях может доставлять продукт от конструктора до клиента, используя только переданные значения параметров.

    И всё это оказывается возможным только вследствии фиксированности структуры процессов и api компонентов в них участвующих, которые довольно широко параметризуются (key-values) – собственно, поэтому в API используется ресурсная модель…

    П.С. для общего понимания, как вы считаете, услугу “доставка документов почтой России” (входит в какой-то продукт) какие ресурсы обеспечивают?

    1. Разумеется я писал не о банальной активации сервиса, когда абонента, с определенными параметрами, надо прописать на ряде сетевых устройств. В этом случае этапы декомпозиции сервиса и design&assign практически отсутствуют (вернее делаются при проектировании продукта) и процесс вырождается в service activation. И есть другой полюс процессов, когда для каждого подключения разрабатывается отдельный проект. Например, задача реализации VPN для регионально-распределенного корпоративного клиента может оказаться достаточно нетривиальной. Здесь появляется разрыв между design и implemetation. Эта тема, кстати, затронута в работе по ссылке Dynamic Order Managemet. Тенденция современного service order management заключается в объединении различных по своей сути сценариев подключений и автоматизации проектирования в максимально возможной степени (с активацией сервиса проще, чем с проектированием, хотя и там требуется внятная обработка исключений).

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

  2. я лишь хотел сказать, что такое: “…service order – это модель конкретного экземпляра процесса подключения, сгенерированного специально для данного экземпляра” – возможно только если сценарий активации услуг и ресурсов фиксирован для всех их типов и, максимум, что реально может происходить автоматически, так это обработка фиксированного набора входных параметров и вызовы какого-то стандартного API (также фиксированного в сценарии). Сценарии же активации/создания конкретной услуги – обычно – будут уникальными для конкретного типа услуги и будут доступным только через тот же стандартный API.
    Всё остальное, я бы назвал чудесами – как и реальность использования “Model-driven design”/MDA (модель->исполняемый код) в реальных, сложных проектах:).

  3. В инженерии я развожу два использования информационных систем:
    — для того, чтобы вводить мысль инженера (редакторы/CAD), а при коллективной работе предотвращать и выявлять коллизии (системы управления жизненным циклом — PLM всех мастей, т.е. объектные базы данных с workflow/BPM)
    — для того, чтобы сгенерировать какую-то модель (тут уже неважно, модель проекта/design или проекта/project/process

    Первым занимаются сегодня все подряд (постепенно сдвигаясь от “редакторов”/CAD к , а вот второе — очень отдельные люди, и общее имя этому generative design (в данном случае — generative process composing). Правда, пока в generative design много больше “художественных дизайнеров”, чем “дизайнеров хода работ”.

    Я время от времени пишу о таких вещах в своем блоге (http://ailev.livejournal.com/).

  4. Тогда сюда: http://ailev.livejournal.com/905099.html (и там дальше по ссылкам).

    Но ситуационная инженерия методов не является последним из интересных подходов к разработке организационного софта. См. также http://praxos.livejournal.com/12576.html — там помянуты и ACM, и SME, и ArchiMate и многое другое другое.

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

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