Процессы и жизненные циклы ресурсов

В первую очередь, я хочу выразить признательность участникам обсуждения сообщения Маргинальный подход к моделированию бизнес-процессов. Конструктивное обсуждение подходов позволяет не только взглянуть на проблему с различных точек зрения, но и своевременно отсеять неверные предположения.

В комментариях к этому сообщения я упомянул сделанный Анатолием Белайчуком перевод статьи Jean-Jacques Dubray Семь заблуждений из области исполнения бизнес-процессов Эта работа дает нам отличную возможность не просто порассуждать о преимуществах или недостатках того или иного подхода, но и проверить свои выводы на изложенном в статье конкретном примере. Dubray достаточно основательно расписывает задачу приема сотрудника на работу. Проанализировав возникшие при этом проблемы, он подводит нас к выводу о необходимости дополнения традиционного набора инструментов компонентной архитектурой (Service Component Architecture, SCA). Я не являюсь приверженцем SCA, но разделяю идею автора об использовании композитных приложениях в автоматизации управления процессами предприятия. Читать далее Процессы и жизненные циклы ресурсов

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

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

Прошло много времени. Мы были заняты другими делами: новые проекты, финансовый кризис и т.д. В общем, о сервис-ориентированной архитектуре все стали понемногу забывать. Читать далее Платформа управления заданиями

Назад в будущее

Я с большим интересом слежу за блогом, который ведет Keith Swenson и сегодня с удовольствием обнаружил в нем сообщение 15 Social Requirements for ACM Насколько мне известно, это первый список конкретных требований к социальной системе управления, по крайней мере, к системе класса adaptive case management. Мне нравится этот перечень, но для себя я бы скомпоновал требования немного иначе:

  1. Case – это ресурс в корпоративной информационной сети, обладающий уникальным неизменным идентификатором (URL) и доступный посредством простых операций CRUD (впрочем, насчет D[elete] я бы еще подумал). При описании требований к системе, я бы объединил понятия case и case folder, хотя эти понятия и используются для обозначения разных сущностей.
  2. Главным требованиям к структуре case folder(case) является freeform. Я бы ограничился статусом, коллекцией вложенных ссылок на бизнес-объекты и историей изменений. Впрочем, статусы можно реализовать набором меток(тэгов). Возможно, это предложение сейчас слишком инновационное, но по мере роста популярности Semantic Web, статус кейса станет семантической ссылкой на один из допустимых статусов.
  3. Безусловно, необходимы механизмы уведомления об изменениях кейса в виде RSS/Atom/e-mail, допускающие свободную подписку в соответствии с правами доступа.
  4. Связывание кейсов между собой производится на основе гиперссылок и меток(тегов). Причем, основное внимание надо уделить на использование меток для классификации кейсов. Некоторые метки могут обозначать использование в данном кейсе типовых сценариев и задач. Более того, когда Case Worker принимает решение о необходимости реализации в рамках отработки кейса той или иной активности, соответствующая метка типа активности должна добавляться к кейсу автоматически.
  5. Безусловно, отношения между кейсами и людьми – это самое главное. В этом Кейт абсолютно прав. Я считаю, что ассоциация кейса с сотрудником должна быть той самой задачей из check list. Другими словами, сотрудник привлекается к кейсу не просто так, а для того чтоб внести свой, вполне конкретный вклад в его решение, реализовав одну из задач кейса. Это не запрещает консультироваться с экспертами и взаимодействовать коллегами по поводу кейса. Но главный акцент остается на конкретном вкладе эксперта в достижение общей цели.

Возможно, после повторного прочтения сообщения Кейта Свенсона мне придет на ум что-то еще. Однако и первое прочтение меня достаточно впечатлило.

С чего начинается BPM

Мне кажется, что дискуссия с Анатолием Белайчуком в комментариях к предыдущему сообщению, оказалась достаточно продуктивной, чтоб кратко резюмировать её в отдельном сообщении.

Итак, во-первых мы определили подразделения на предприятии, которые можно называть термином «бизнес». Бизнес – это люди, участвующие в основных бизнес-процессах либо заинтересованные в их результатах .

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

При этом следует понимать, что подразделения, участвующие в основных бизнес-процессах довольно разные. И подходы к описанию процессов у них тоже разные. Кому-то нравится ARIS, кому-то Lombardi, а кого-то вполне устраивает письменная русскоязычная проза или картинки в Visio. Именно эти предпочтения и определят подход к выбору инструмента. Будет ли в компании единый BPMS, система Case Management или процессы расползутся в локальные workflow, уже существующие в большинстве систем.

Если мы чем-то и может помочь в этом процессе, так это объединить этих людей, например, в центр компетенции BPM и содействовать сближению их позиций. Задача эта не простая, требующая отказа от привычек и стереотипов, но вполне выполнимая

Маргинальный подход к моделированию бизнес-процессов

В 2002 году под заголовком «Современные методы описания функциональных требований к системам» на русском языке была выпущена книга Алистера Коберна «Writing Effective Use Cases» (скачать русскую версию в djvu можно по этой ссылке)
Книжка эта, конечно, в первую очередь о требованиях, но и не только о требованиях. В действительности, автор излагает подход к моделированию процессов, позволяющий не использовать графическую нотацию. Я предвижу праведный гнев бизнес-аналитиков. Однако считаю совершенно необходимым поделиться с экспертами, занимающимися бизнес-процессами, данным подходом к их моделированию.
Читать далее Маргинальный подход к моделированию бизнес-процессов

Connecting people & process

Собирался сегодня написать короткое сообщение в стиле «Мир без e-mail» о том, что клиент электронной почты должен уступить свое место с десктопа офисного работника другим приложениям, например списку задач BPM или ACM решения. Но наткнулся на еще один замечательный видеоролик на ActionBase

http://vimeo.com/6128705

Ну что тут можно добавить? Эти люди забрали себе все привлекательные идеи и реализовали их 🙁