andbaryПока эти БП не проверены практикой, они НИЧТО... Что то моделировать по кривым схемам, я бы не стал. Золотые слова, подписываюсь. Нет ничего хуже, чем автоматизировать не до конца понятые, отставшие от жизни или явно не оптимальные бизнес-процессы.

andbaryP.S. Загонять в BPM я бы не стал, я не очень хорошо отношусь к данной методике и считаю ее очень сырой (IMHO).
P.P.S. Мой опыт, горькая практика... А вот этого совершенно не понимаю. Для меня лично BPMS - это как раз отличный способ проверить БП практикой. Сначала - быстро в виде прототипа, потом плавно переходя к промышленной системе. Откуда у Вас такой негатив - расскажите пожалуйста, правда интересно. Может быть из-за того, что Вам под видом BPM пытались вручить голый BPEL?

shelsoftТаким образом, перед внедрением концепции "BPM", "SOA" & etc. должен быть проведен аудит текущих бизнес-процессов. Согласен (+100), это уже более похоже на правду .. Нет, это на правду не похоже. "Сначала бизнес-процессы, потом BPM" - категорически неправильный подход. BPM - это не однократная автоматизация, а выявление бизнес-процессов и последующее непрерывное их усовершенствование.

shelsoftОбожаю аполетов :o) love you too

shelsoftВопрос "Могут ли существовать бизнес-процессы без BPM ?
Или специально для вас, "Как ЖЕ раньше могли существовать бизнес-процессы без BPM ?" Отвечаю: могут, но хреново. Если бизнес-процесс "как-то" протекает, но никто не знает как именно - можно это называть бизнес-процессом или нет? Вопрос терминологии. Или кто-то (например, отдел качества) считает, что знает, но в реальности он протекает совсем не так, как описано в документации для ISO? Если клерк уходит в отпуск и добиться от компании счета становится затруднительно - это бизнес-процесс или бардак? (Только не говорите, что такого не бывает.) Если бизнес-процесс поддерживается в основном служебными записками - это бизнес-процесс?

shelsoftИ мне ИХМО ближе позиция Rome&Ko , главной методологией работы которого является методология "здравого смысла". Судя по вашим высказываниям, вы оба придерживаетесь традиционного взгляда на бизнес-процессы: as-is, to-be, waterfall от диаграмм к кодированию ИС, люди-винтики... С появлением концепции BPM (примерно с 2003г.) преобладающим постепенно становится другой взгляд - как на нечто постоянно изменчивое. Соответственно, BPMS предназначены не для однократной автоматизации жестко заданных процессов, а для управления изменчивыми бизнес-процессами. Вместо as-is и to-be - iterative process inspection; вместо waterfall - agile development; вместо кодирования бизнес-процессов - непосредственно исполняемые схемы.

LR АБBPM - это не однократная автоматизация, а выявление бизнес-процессов и последующее непрерывное их усовершенствование.
Т.е., если нет необходимости в усовершенствовании, то нет и резона использовать BPM?

«Управлять можно только развитием, а управление функционированием есть бессмыслица» (Г.П.Щедровицкий) Хороший вопрос. Технически, основное преимущество BPM - в способности относительно легко (с небольшими трудозатратами вообще и программистскими в частности) менять схему бизнес-процесса. Соответственно, если пытаться применять BPM, не задействуя это преимущество - например, для однократной автоматизации процесса по жестко заданному ТЗ - то можно получить в итоге вопрос "ну и что?" и тем самым скомпрометировать все дело. Что по-видимому, часто и просходит, порождая скепсис в отношении BPM.

Где это преимущество может быть востребовано? Для усовершенствования (оптимизации) процесса - раз, но это не все.

Предположим, мы не собираемся менять процесс, а ограничиться только автоматизацией существующего. Оказывается, реальный процесс практически невозможно выявить с первой попытки. То есть: аналитики работают, рисуют диаграмму, вроде все правдоподобно, загоняют схему процесса в ИС, внедряют... и тут выясняется - не хватает шага, не тот исполнитель, не предусмотрели возврат или развилку и т.д. Отправляем систему на доработку, бизнес нервно курит. И так раз 7-8, пока система не станет пригодна к промышленной эксплуатации или бизнес не скажет: "все, задолбали, пойду отдамся САП или 1С". (Хитрый разработчик, предвидя все это заранее, сразу оставит в ИС только бизнес-функции, а процессную спихнет, например, на должностные инструкции, которые типа к нему не относятся.) BPM позволяет прокрутить эти итерации быстро, на упрощенных формах и структурах данных, и приступать к кодированию только верифицированной схемы процесса. Итак, итерационное выявление процесса - это два.

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

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

shelsoft1) Опровергается всей историей человечества бизнес-процессы которого "как-то протекали" К Вашему сведению, вся история человечества состоит из того, что кто-то начинал делать то, чего до него никто не делал. Те же, кто занимал позицию "наши деды этого не делали, значит и нам негоже", в истории заметного следа не оставили. Вот кто сейчас помнит имена палачей Джордано Бруно?!

shelsoftПриведите пожалуйста пример управления изменчивым бизнес-процессом с итерационным его усовершенствованием на основе решения с использованием BPM-системы. Мы так выполняем все проекты BPM без исключений. Например, один из проектов недавно упоминал Garya: Процессинг.... Изменчивости и итерационного усовершенствования в нем было предостаточно.

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

LR АБBPM позволяет прокрутить эти итерации быстро, на упрощенных формах и структурах данных, и приступать к кодированию только верифицированной схемы процесса. Итак, итерационное выявление процесса - это два.
А что еще, кроме "верифицированной схемы процесса" мы можем получить от BPM в результате "исполнения процесса", как элемент _фиксированного_ знания(о предметной области)?

Ведь для этого
АБСпособность (т.е. внутренняя готовность, подкрепленная соответствующими техническими возможностями) быстро перестроить или создать новый бизнес-процесс для того, чтобы воспользоваться бизнес-возможностью, которой сегодня даже не видно - это ведь тот же запасенный темп!
"правильно происходящих" процессов, которые можно быстро перестроить, зачастую наверное будет недостаточно... для принятия бизнес-решений потребуется аналитика основанная на (чем-то _фиксированном_? может это дать BPM?) Извините, не понял вопрос. Вы имеете в виду решение о необходимости/целесообразности изменения бизнес-процесса? Фактическую информацию для этого должны дать система KPI, BAM, BI. Вот Garya - энтузиаст статистических методов в бизнесе, я же лично больше верю в разум, здравый смысл и интуицию владельца бизнес-процесса, хоть и занимался матстатистикой профессионально. (Или может как раз вследствие этого?) BPM - это всего лишь инструмент, он мозги не заменяет, а высвобождает для творческой деятельсности.

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

Дело не в том, может схема формально быть исполнена, а в том, насколько хорошо видна ее кривизна. По моему опыту, пока занимаешься чистым моделированием ("рисованием"), легко получаешь схему, которая вроде бы правильна. Но как только начинаешь ее исполнять в BPM (даже на прототипе, с автоматическими формами, не ввязываясь в серьезную разработку), обнаруживается куча неувязок, ошибок смешных и концептуальных. В этот момент представляешь себе в какие затраты по переделке вылилась бы вся эта кривизна при традиционном подходе и испытываешь катарсис :)

Причем такой результат достигается именно исполнением. Имитационное моделирование (simulation), которое предлагают некоторые BPMS, выявить кривизну не помогают. Его назначение в другом: когда схема процесса уже в достаточной степени достоверна, погонять ее методом Монте-Карло, оценить вероятность тех или иных исходов, распределение ключевых показателей, загрузку ресурсов, длины очередей и т.п.