Work.дыбр

[dzz]

Изучаю наработки IDS Scheer / ARIS, BPMI и OMG на тему методологий представления бизнес-процессов.

Три нифига не стыкующиеся между собой языковые спецификации... Чувствую себя пророком ;)

Comments

[nine_k]

А всякий IDEFx вроде же открыт? Или оно не то?

Кстати, не бывает ли в природе обобщённой тулзовины для рисования диаграмм, которой можно объяснить предметную область, написав немного кода? В голову приходит Visio, к примеру.

[dzz.livejournal.com]

Визио, к сожалению, так не умеет.

IDEF0 - не тот уровень абстракции, да и стандартизованного представления в виде языка/формата данных не имеет. Большинством средств разработки БП IDEF0 поддерживается только на выход.

[movl.livejournal.com]

А зачем разные стандарты объеденять то? Вон, Aris нынче визуализировал BPEL, его поддерживают SAP, IBM и Microsoft, а с такой компанией никому не тягаться, так что, на мой взгляд смысла не вижу увязывать UML, BPML с BPMN с BPEL. Все все равно будут на последнем работать. Хотя это смотря какие цели конечно... Что касается управленя бизнес-процессами, так опять же у ARIS есть разработки, типа PPM, с помощью них и обратная отрисовка из workwlow систем предусмотрена. Так что, мне кажется надо на чем-то одном остановиться. Извините, если не совсем понял тему...

[dzz.livejournal.com]

Боже упаси, я не ставлю задачу унификацию стандартов представления БП, это неподъёмная задача для одного человека (да и для отдельно взятой компании тоже).

Цель несколько иная - построение системы для реверс-инжиниринга бизнес-процессов крупной компании на основании частных данных о бизнес-процессах подразделений, выраженных в неграфической (напр. анкетной) форме. Т.е. изначально у обследуемого заказчика нет ничего - ни workflow-систем, ни описаний БП подразделений. При традиционом подходе в организацию засылается 20-30 аналитиков, которые вручную за год и три миллиона долларов рисуют схемы и выставляют предложения по реинжинирингу. Автоматизация части этой деятельности и является моей скромной задачей :)

Что касается физических (напр. датабазных или xml-ных) представлений указанных нотаций БП, то, при прочих равных, я отдал бы предпочтение открытому стандарту, позволяющему вносить свои частные доработки, а не замкнутой системе-в-себе а-ля ARIS или AllFusion ModelMart, при всех их достоинствах.

[(Anonymous)]

Ну, скромной я такую задачу не назвал бы. Честно говоря, мне всегда казалось, что термин реверс-инжиниринг подразумевает извлечение данных из уже созданных систем, а если системы нет, то, о каком реверс-инжиниренге может идти речь? Если это данные анкетные, то мы сталкиваемся с огромным массивом неструктурированной информации, тогда мне не понятно каким образом это можно автоматизировать, а если и можно, то уж точно не скромно.
Что касается нотаций, то опять же, смотря, какая цель, лично я приверженец стандартов, и если есть необходимость в построении workwlow и использовании новомодных языков бизнес-процессов, а на сколько я понял ты и хочешь как раз видеть именно язык, типа BPEL или BPML, то лучше выбирать тот, у которого объективно есть будущее. А зачем тебе, кстати, открытый язык? На сегодняшний день, вся проблема то и заключается в том, что никто договориться не может, те же FWMC, BPMI, OMG и IBM с SAP да с Microsoft только и делают, что стандарты пытаются свои продвинуть, от этого страдает экономика в целом. На мой взгляд, в науке об автоматизации и управлении бизнес-процессами стандартизация и унификация приносит только пользу.

[(Anonymous)]

Насчёт "скромной задачи" я, конечно, поскромничал. Задачка достаточно объёмная.
Реверс-инжиниринг - это восстановление описаний из собранных данных.

Источник данных в данном случае достаточно специфический - это хранилище (data warehouse) информации комплексных обследований, структура которого сейчас проектируется. Кроме данных по бизнес-процессам там будут, к примеру, данные CMM (Common Maturity Model) и т.п. Структуризация и верификация данных - задача, решаемая на фазе построения хранилища. Средства моделировния БП тут несколько сбоку, сама система - "базоцентрическая".

Под открытостью я имел в виду не открытый код, а наличие у продукта открытых интерфейсных спецификаций (форматы данных, API), позволяющих решить две задачи:

1. Правильно сформировать описание БП, понимаемое средством моделирования/визуализации

2. Получить описание БП от системы моделирования/визуализации в виде набора объектов, атрибутов и связей, понимаемых софтом со стороны хранилища.

Само собой, спецификация не должна кардинально меняться с каждой версией и поддерживаться в течение обозримого времени. Лучше, если несколькими продуктами. Ещё лучше - если кроссплатформенно.

Унификация - это замечательно.