Несмотря на разгар лета и надвигающуюся пору отпусков тема 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-а в адаптивном процессе можно автоматизировать, сгенерив конкретную модель процесса для каждого экземпляра. Через годик другой на позицию руководителя будет назначен Искусственный Интеллект и начнет раздавать нам задания =)