Прочитал перевод забавной статьи Как ACM позволяет достичь гибкости бизнеса Деба Миллера, в которой автор сравнивает ACM c Dog Agility. Аджилити – это соревнование, в которых человек, называемый хэндлером, направляет собаку по полосе препятствий. Собака преодолевает препятствия, человек – бежит рядом и подает ей команды. Хэндлер не имеет права трогать собаку или препятствия, поощрять собаку едой или заманивать игрушкой. В его арсенале только команды жестом и голосом. Честно говоря, это действительно напоминает современные нам способы управления информацией через интерфейсы заказных программных систем. Только у одной собаки сразу несколько хозяев, расставленных по клеточкам бизнес-процесса
Прочитал статью и задумался над тем, что adaptive case management все больше и больше воспринимается не как инструмент, информационная система, бизнес-приложение, а как определенный набор практик сотрудника умственного труда (knowledge worker), работающего в современной организации. Это, безусловно, хорошо. Но чем дальше мы будем уходить от простых и конкретных понятий, тем меньше мы будем понимать, что же такое adaptive case management на самом деле. Поэтому, позволю себе вернуться к одному из первых определений ACM, предложенному Workflow Management Coalition. Возможно, это позволит избежать некоторого числа ненужных вопросов. Итак,
Adaptive Case Management (ACM) is information technology that exposes structured and unstructured business information (business data and content) and allows structured (business) and unstructured (social) organizations to execute work (routine and emergent processes) in a secure but transparent manner.
Т.е., во-первых, ACM – это информационная технология. Во-вторых, это технология для работы с структурированными и неструктурированными данными. В-третьих, эти данные доступны не только для приложений, но и для пользователей, причем пользователи не ограничены в возможности управления этими данными ничем, кроме правил разграничения доступа. Они могут их добавлять, изменять, консолидировать, структурировать или организовывать каким-либо другим способом. В-четвертых, бизнес-процессы, бизнес-правила, орг. структура и пр. так же являются частью этих данных и доступны пользователям для создания, использования и изменения, что позволяет совместить во времени фазу проектирования процессов и фазу их исполнения.
Далее следуют две не очень внятные картинки о том, что в случае BPMS в центре нашего внимания процессы, а в случае ACM – данные. Думаю, эти картинки вносят больше путаницы, чем понимания. BPMS, СЭД и прочие приложения тоже работают с данными. Но эти данные пользователям недоступны. Т.е. пользователи их, конечно, видят, но только на определенных шагах бизнес-процесса и только через те экранные формы, которые разработал для них программист. Возможности просмотра, изменения, добавления данных, ассоциирования их друг с другом ограничены дизайном экранных форм. Хочешь сделать что-то непредусмотренное в экранной форме – пиши change request разработчику, через полгода включат с очередной релиз или беги к знакомому сисадмину. Айтишники при этом очень любят посетовать на бестолковость пользователя, который не может изначально четко сформулировать требования. В ACM подход совершенно иной. Данные принадлежат пользователям.
Как это реализовать? Да, безусловно, через RESTful архитектуру. На веб-странице с адресом http://acms/case/7654 отображаем основную информацию по кейсу, свойства, ссылки на историю изменений и вовлеченных сотрудников.
http://acms/case/7654/history — история изменений кейса
http://acms/case/7654/workers — коллекция пользователей и групп
http://acms/case/7654/owner — ссылка на пользователя John Smith
http://acms/case/7654/content/filename.doc — вложение
и т.д.
Разумеется, что при обращении по этим ссылкам из браузера возвращается HTML страничка, а из приложения – информация пригодная для парсинга в форматах XML или JSON.
Все что и нужно-то сделать для успешного развития ACM, так это стандартизировать интерфейсы к хранилищу кейсов, определить минимальный набор обязательных свойств и способы его расширения (конечно же, просто добавляем “key = value”), зафиксировать основные коллекции: люди, связанные процессы, связанные кейсы, вложенные задачи, история изменений. Не знаю, почему OMG этого до сих пор не сделала. Наверное, там просто не умеют стандартизировать программные интерфейсы, а описать структуру данных в BPMN задача, действительно, нереальная.
Похожие сообщения: