2 АБ
Спасибо за активность и детальные разъяснения. Вот уж не думал, что этот понятный вопрос потребует выяснения "на ком стрелка". Неужели все так плохо в нашем доме :).
Вы заметили: противников ВРМ и их сторонников примерно 50/50, может соотношение еще хуже, причем противников убежденных. И не только в этом обсуждении, любой вопрос по бизнес-аналитикам скатывается (местами) к установкам типа: "рисуют картинки" и "хапают большие бабки". Это очень печально

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

И наконец "И это все работает. Не верите?" - конечно верю, иначе не поднимал бы тему. И работает без нас-программеров, и с этим придется смириться и выйти на более высокий уровень. Иначе закисать в кодах (да простят меня коллеги - никого не хочу обидеть).

АБ... А что делают наши "консультанты по РБП"?! Они рисуют на первом листе квадратик и пишут в нем "бизнес-процессы нашего предприятия". Затем приступают к "декомпозиции" и получают "бизнес-процессы бухгалтерии", т.е. в итоге получают чисто функциональное деление. Это у них называется "системный подход"...

Неужели такое возможно? Полная профанация.

А с этим " Поэтому я лично обеими руками ЗА бизнес-процессы и ПРОТИВ реинжиниринга.", будьте добры еще раз подробнее. Если можно.

"сегодня бизнес-процессы реорганизуются по-другому, без издержек традиционного реинжиниринга", если не секрет, то как это по-другому? Если ВРМ работает (я опускаю понятную фазу построения БП "as is"), если существует матрица ответствености, если ведется сбор и анализ показателей выполнения процессов, то есть имеется информация для определения узких мест и, соответственно, для выработки предложений по структурным либо другим преобразованиям. Приблизительно так, как Вы считаете?

2 Garya

BPEL и BPML это подходы к решению одной и той же проблемы: определение логики процессов в языке XML таким образом, чтобы результат мог использоваться как исполняемый код программными продуктами BPM.
Спасибо, что обратили внимание на сей факт.

И снова вопрос: найдем ли мы среди посетителей тех, кто хотя бы раз воспользовался Oracle BPEL Designer и/или Oracle BPEL Process Manager и/или Oracle Business Activity Monitoring? Именно эти средства позволяют выполнять BPEL - проектирование, исполнение, анализ и перепроектирование (реинжиниринг???) существующих БП.
И они отвечают на вопросы и должны развеять сомнения, высказанные участниками обсуждения.
Но найдется ли тот, кто знает не по наслышке об этих средствах?

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

А что Инженер, Вы уже внедрили Указ по РФ и СНГ "О запрете групповых спецификаций"? Может туда же и БП включить? :)
Да, не надо долго изучать, понятна связь БП с техпроцессами и не только. Вы же должны отметить и аналогии с процессом пищеварения (имеется вход, выход, алгоритмы управления и ресурсы) и еще с .... даже страшно сказать.
Но это безобидные шутки, не хочу никого обижать. А вот вопрос к Вам. как к спецу по планированию имеется. Не расскажите ли Вы нам о том, как осуществляется планирование (план производства???, закупки???, оперативное планирование - загрузка ресурсов, замены, календарный план??? и, наконец, продажи) на вашем предприятии. Судя по сообщениям Вы эти вопросы досконально знаете. Пожалуйста, поделитесь опытом.
Заранее спасибо за информацию.

Garya АБНе стоит и искать. BPEL на сегодня позволяет описывать только взаимодействие систем (программ). Проще говоря, это оркестровка вебсервисов, и только! Только недавно пошли разговоры о том, что надо бы добавить в BPEL расширение для описания межчеловеческого взаимодействия.BPEL используется в MS BizTalk Server начиная с версии 2004........
Лично я познакомился с BizTalk с версии 2000, и он сразу ошарашил меня, убил наповал. Впервые именно в нем я увидел реально работающую разработку "от бизнес-процессов"..........
И развитие его в последнее время предоставило весьма широкие возможности для рассмотрения этого продукта не только, как средства централизованной интеграции приложений, но и как собственно сервер приложений, разрабатываемых "от бизнес-процесса". За таким подходом - будущее. ИМХО.

Еще достаточно убедительное свидетельство правильности выбора стратегии разработки от БП. Спасибо.
Это MS, а что же стоит за Oracle BPEL - продуктами. Ведь еще и в OEBS стоит на средствах настройки от типовых БП.

Вот к этому:

АБ... Давайте я попытаюсь примирить ваши точки зрения. Для иллюстрации воспользуюсь моделью CMM (capability maturity model) от Software Engineering Institute, Carnegie Mellon University. По сути, это некий аналог ISO9000, но гораздо более конкретный, потому что нацелен на производство ПО.

Что интересно в этом примере: 1) все вертится вокруг процессов, практик, показателей эффективности -- тема близкая; 2) в этой модели определено 5 уровней зрелости, причем 1-й уровень -- это полное отсутствие процессов, все делается случайно, по наитию, а 5-й уровень -- это когда оформился процесс изменения процессов. Так вот, в реальности 5-го уровня достигают буквально считанные софтверные компании по всему миру, а кроме того, вообще не факт что всем необходимо к нему стремиться.


небольшой файл из первоисточника.

Вот к этому:

АБ... Давайте я попытаюсь примирить ваши точки зрения. Для иллюстрации воспользуюсь моделью CMM (capability maturity model) от Software Engineering Institute, Carnegie Mellon University. По сути, это некий аналог ISO9000, но гораздо более конкретный, потому что нацелен на производство ПО.

Что интересно в этом примере: 1) все вертится вокруг процессов, практик, показателей эффективности -- тема близкая; 2) в этой модели определено 5 уровней зрелости, причем 1-й уровень -- это полное отсутствие процессов, все делается случайно, по наитию, а 5-й уровень -- это когда оформился процесс изменения процессов. Так вот, в реальности 5-го уровня достигают буквально считанные софтверные компании по всему миру, а кроме того, вообще не факт что всем необходимо к нему стремиться.


интересная выдержка из: "Современные модели качества программного обеспечения"
Андрей А.Терехов, ведущий инженер "ЛАНИТ-ТЕРКОМ"
Вероника Туньон, менеджер Software Engineering Center Oy
Опубликовано в журнале BYTE/Россия, №12, 1999

"Начальный уровень (initial level) описан в стандарте CMM в качестве основы для сравнения со следующими уровнями. На предприятии начального уровня организации не существует стабильных условий для созданий качественного программного обеспечения. Результат любого проекта целиком и полностью зависит от личных качеств менеджера и опыта программистов, причем успех в одном проекте может быть повторен только в случае назначения тех же менеджеров и программистов на следующий проект. Более того, если такие менеджеры или программисты уходят с предприятия, то с их уходом резко падает качество производимых программных продуктов. В стрессовых ситуациях процесс разработки сводится к написанию кода и его минимальному тестированию.
Для достижения повторяемого уровня (repeatable level) на предприятии должны быть внедрены технологии управления проектами. При этом планирование и управление проектами основывается на накопленном опыте, существуют стандарты на разрабатываемое программное обеспечение (причем обеспечивается следование этим стандартам) и существует специальная группа обеспечения качества. В случае необходимости организация может взаимодействовать с субподрядчиками. В критических условиях процесс имеет тенденцию скатываться на начальный уровень.
Далее следует определенный уровень (defined level), который характеризуется тем, что стандартный процесс создания и сопровождения программного обеспечения задокументирован (включая и разработку ПО, и управление проектами). Подразумевается, что в процессе стандартизации происходит переход на наиболее эффективные практики и технологии. Для создания и поддержания подобного стандарта в организации должна быть создана специальная группа. Наконец, обязательным условием для достижения данного уровня является наличие на предприятии программы постоянного повышения квалификации и обучения сотрудников. Начиная с этого уровня, организация перестает зависеть от качеств конкретных разработчиков, и не имеет тенденции скатываться на уровень ниже в стрессовых ситуациях.
На управляемом уровне (managed level) в организации устанавливаются количественные показатели качества – как на программные продукты, так и на процесс в целом. Таким образом, более совершенное управление проектами достигается за счет уменьшения отклонений различных показателей проекта. При этом осмысленные вариации в производительности процесса можно отличить от случайных вариаций (шума), особенно в хорошо освоенных областях.
Наконец, оптимизирующий уровень (optimizing level) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например, с помощью создания и повторного использования компонент."