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

Вот такое краткое обоснование вопроса.
Буду признателен за проявленное внимание.

Guest_12345Хочется услышать как практиков, принимавших участие в такой ломке, так и предупреждения и советы теоретиков и вообще любые мысли в этом направлении, поскольку такого опыта думаю еще у нас маловато.
......
Буду признателен за проявленное внимание.

Господа! Я с этого пункта начал и хотелось бы услышать что-то об ОГРАНИЗАЦИОННОЙ ломке. Дискуссия же пошла в сторону, которая мне кажется заданной заранее: а возможно ли напрямую управлять бизнес-процессами? Но мы же уже давно имеем SAP и OEBS в основе настроек которых лежат БП. Или я ошибаюсь? Может OEBS-ники нас рассудят?

Раз так выглядит дискуссия, то действительно "опыта маловато". И все-таки есть живые участники большой организационной перестройки при внедрении, например, OEBS?

Спасибо всем за полезные мысли и ссылки.

Вдогонку...

"Появление BPMS как нового класса системного программного обеспечения по значимости сравнимо с появлением в начале 80-х коммерческих DBMS (СУБД) общего назначения. С появлением BPMS жестко зашивать схему конкретного бизнес-процесса в коды программы или использовать частные, нестандартные механизмы описания бизнес-процессов ERP-систем, стало столь же нерациональным, что и использование для хранения данных внешних файлов вместо СУБД."

Это выглядит целесообраным.

OA UserДело не в OEBS или 1С. Я участвовал в свое время в проекте, где для внедрения только управления поставками пришлось почти 100% директоров магазинов (их было почти 100) и людей над ними заменить. Вы, как внедренец, способны такое решение продавить?
Проблема в том, что когда Вы внедряете некие процессы, Вы неизбежно делаете компанию более прозрачной, и также неизбежно вступаете в конфликт с теми, кого существующее положение устраивает.

Очень верно - так говорит внедренец.

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

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) характеризуется тем, что мероприятия по улучшению применяются не только к существующим процессам, но и для оценки эффективности ввода новых технологий. Основной задачей всей организации на этом уровне является постоянное улучшение существующих процессов. При этом улучшение процессов в идеале должно помогать предупреждать возможные ошибки или дефекты. Кроме того, должны вестись работы по уменьшению стоимости разработки программного обеспечения, например, с помощью создания и повторного использования компонент."

инженер планового отдела
А слабо, WJ, привести пример "бизнес-процесса" типа B2B ?

Элементарно, Guest_12345. Есть заявки покупателей. Если они не покрывают производственные мощности, то дополняются "точно такими же" заявками нашего предприятия. И составляется (динамически) план производства. И точно в срок всем покупателям отгружается их любимая продукция. А почему Вы спрашиваете ? Это имеет какое-то отношение к "бизнес-процессам" ?

Я ведь спрашивал о планировании. И вот многим интересно, как это делается.


WJИнженер планового отдела
А вот это и вправду очень хороший вопрос.
Guest_12345 А вот вопрос к Вам. как к спецу по планированию имеется. Не расскажите ли Вы нам о том, как осуществляется планирование (план производства???, закупки???, оперативное планирование - загрузка ресурсов, замены, календарный план??? и, наконец, продажи) на вашем предприятии. Судя по сообщениям Вы эти вопросы досконально знаете. Пожалуйста, поделитесь опытом.

Думаю, он заинтересует многих из здесь "присутствующих". И тоже заранее благодарю за информацию, надеясь ее получить:)

А Вы отделались одной общей фразой "Есть заявки покупателей. Если они не покрывают производственные мощности..." А если перекрывают? А если нет материалов, комплектующих? А если в плановам периоде получен срочный высокооплачиваемый заказ? А если упал/поднялся рубль? А поставщик опоздал с поставкой - Вы же не на японском предприятии?
И таких вопросов масса. Вот что хочется знать читателю.
И это действительно интересно. Может все-таки напряжетесь?

Мы Вас поблагодарили за ценную информацию уже несколько дней назад.
И благодарим еще раз.

АБ GaryaBPEL используется в MS BizTalk Server начиная с версии 2004 Спасибо за подробный обзор. Я-то человек юниксово-жабовый, но тем интереснее информация "из чужого лагеря".

Мы в связке Java-Oracle, и вот я постоянно прошу OEBS-ников дать информацию о настройках типовых БП в OEBS. Может у Вас есть прямой контакт для такого вопроса?