Все о системах управления бизнес-процессами
 
Почитать
Поговорить
Побродить
Завершить


Вход в систему

Забыли пароль?


     
Семь заблуждений из области исполнения бизнес-процессов

Литература:

Автор: Jean-Jacques Dubray

Оригинал статьи: «The Seven Fallacies of Business Process Execution»

Извините, данная статья доступна только зарегистрированным пользователям. Войдите в систему или зарегистрируйтесь

Комментарии
#1 Анатолий Белайчук, 25.12.2007 17:54

Коллеги

Мне кажется, у нас спонтанно образовалась очень удачная серия из трех статей: статья про то, что "Worflow не тянет", статья Силвера про round-trip и эта статья. Она может показаться мутноватой, тяжеловесной и затянутой (и наверное, действительно таковой является, во всяком случае переводить ее было тяжким трудом). Но если потратить на нее время, то можно найти ответы (пусть частичные) на вопросы, поднятые первыми двумя.

Например такой: между "бумажным" и "полупроводниковым" BPM нет противоречия, нужно просто использовать тот и другой по назначению. Бумажный (a.k.a workflow, human2human, pure-play) необходим для наведения моста между бизнесом и аналитиком и создания быстро адаптирующегося (agile) ИТ и предприятия в целом. Полупроводниковый (BPEL) идеально подходит для моделирования жизненного цикла разнообразных бизнес-объектов: контрагентов, контрактов, платежей и т.д.

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

То есть, с одной стороны, можно удачно спарить workflow и collaboration. С другой стороны, к BPEL-хребту уместно прицепить MDM: когда состояние конечного автомата бизнес-объекта меняется, это изменение надо протиражировать на все базы и унаследованные системы, в которых этот объект каким-то боком участвует.

Не знаю как вы, а я заметно подобрел по отношению к BPEL, взглянув на него под ракурсом, заданным Жан-Жаком. Спасибо ему за это.

Остается только добавить к этой картине среду, в которой все компоненты (workflow, collaboration, orchestration, MDM) будут уживаться и общаться друг с другом: SCA, ESB, JBI... что это такое пока мне лично пока не очень понятно, буду рабираться.

#2 Анатолий Белайчук, 25.12.2007 18:17

Для иллюстрации высказанного выше приведу аналогию. Есть такое сравнение: "workflow - это excel для процессов". На самом деле, он не сколько таковым является, сколько хотелось бы чтобы он им стал: чтобы люди бизнеса, которые без конца меняют взгляды на свои процессы и тем самым отравляют жизнь ИТшникам, могли бы сами перестраивать логику систем, которыми они пользуются. Не целиком конечно, но хотя бы в части схемы workflow. Аналогично тому, как они сами проводят какие-то свои маркетинговые вычисления в Excel - представляете, чтобы было если бы всю эту муру для них делал бы программист? Ужас, хоть увольняйся!

В случае с Excel это работает отчасти благодаря тому, что программист дал этим power users четко определенный доступ к корпоративным данным и процедурам через взгляды на таблицы, хранимые процедуры, odbc-соединения. И архитектор корпоративной системы может спать спокойно: пусть себе "юзеры" резвятся, ничего испортить они не смогут.

Применительно к процессам, если мы хотим чтобы workflow мог выступать в роли excel, мы должны на back-end поставить BPEL-процесс жизненного цикла, чтобы он нам гарантировал то же спокойствие, которое в случае excel дает ограничение доступа к информационным ресурсам.

#3 Alexander Samarin, 30.12.2007 23:31

Статья интересная. Я ее откомметировал в оригинале
improving-bpm-systems.blogspot.com/2007/12/this-blog-posting-is-reply-to.html

Thanks,
AS

#4 Максим Косенко, 16.01.2008 23:18

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

Тут многое правильно сказано, но выводы о том, что надо забыть про конструирование BPM только аналитиками мне не кажутся верными.

Также мне не кажется, что IT-шники страждут опереться на что-то большое, надежное и проверенное временем вроде BPEL.

Я вообще смотрю на потребителя BPM в основном как на компанию, которая не очень то знакома с концепциями BPM. Это мой такой взгляд. Но из него мне видно, что BPM пугают компании своими сложностями кучей стандартов и отсутствием законченности как приложения, способного решать задачи.

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

Очень правильный довод - даже аналитики не знают толком BPMN. И надо сказать и не будут его знать. Если строить системы, которые основываются на предположении, что ты знаешь стандарт, то честно говоря, они обречены на исключительно профессиональное использование. Т.е. скажем J2EE это хороший стандарт (хотя бы потому что есть хоть какой-то). А еще есть его разные реализации. И произвольно взятый программист не осилит написание приложения на нем без того, чтобы кропотливо изучать, вникать, экспериментировать. Да, сделать что-то он может, а вот взять и просто начать работать основываясь на своем опыте как программиста - нет. К чему я привел пример этот - мое мнение, что рано хоронить BPMS как платформу для быстрого и надежного построения приложения автоматизирующего деятельность компании средним аналитиком самой компании (у которого нет такого опыта ранее).

Если он сможет справиться с помощью готовых заготовок, блоков, объектов и помощи обычного (не BPM-specific) программиста, подсказок в системе - то это большое дело.

Другой вопрос, что а) 95% систем либо отказались либо плюнули на эту тему (сосредоточившись на том, что это просто инструмент для интегратора) б) вот все вот такие соображения как в статье все больше помогают думать, что, ну да, это только для профессионалов, иначе это поделка и безделушка.

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

Потому что все эти темы это все то, что волнует только компании, подсевшие на огород систем, у которых уже IT специалисты по BPEL скоро на пенсию пойдут и т.д. Так мне кажется. Должно быть и то и другое - мое мнение. Но когда и pure-players все больше скатываются в дебри стандартов, методологий, взаимосвязей и возможностей, все больше уходя от того, чтобы просто дать приложение, которое работает сразу и подгоняется под нужды постепенно... Не знаю...

И еще раз скажу - я говорю пожалуй про малые и средние компании. Особо крупным предприятиям просто не нужны и не годятся никакие инструменты, которые работают сразу. Но ведь и первых просто огромное число (и объемы) и BPM им тоже может очень сильно помочь и вполне может быть центральной системой, оставив только узкие области деятельности в ответственности специализированных систем. А сейчас я даже в затруднениях о том, что им можно посоветовать...

#5 Максим Косенко, 16.01.2008 23:28

Да, еще хотел не в тему сказать... Пока тут уведомлений не будут присылать об ответах - тут жизни толком на форуме не будет... А жаль (правда это не форум, а комментарии к статьям, но обсуждение присутствует).

#6 Анатолий Белайчук, 18.01.2008 23:31

Максим

Мне кажется, Вы сделали из статьи неправильные выводы. (Хотя надо признать она довольно путано написана, так что возможны разные трактовки.) Нет, BPMS не должно быть еще одной тулзой для интеграторов и программистов, и по-моему автор к этому не призывает.

Проблематика статьи - задачи, выходящие за рамки простого workflow, выполняемого "от сих до сих". Представьте себе сквозной end-to-end процесс "от заказа до оплаты" производственной компании:
- предпродажный процесс в случае удачи запускает процесс заключения договора
- если договор подписан, то на определенные моменты в будущем должны быть запланированы продление и закрытие
- в связи с договором, но асинхронно, запускаются отдельные сделки (предположим, что договор рамочный)
- каждая сделка распадается на несколько самостоятельных процессов по разным видам товаро/услуг
- процесс отгрузки вызывает процесс производства, но не непосредственно - производство запускается асинхронно, собирая заказы из разных сделок
- похожим образом производство инициирует закупки
- и т.д.

Реализовать процессный подход значит управлять именно такими сквозными процессами. Получится это сделать усилиями одних аналитиков? Очевидно нет. И отрываться от крепкой интеграционной основы значит создавать ненадежные и недолговечные схемы процессов. Нужен баланс, и автор показывает вариант того, каким он может быть. Вариант достаточно интересный, на мой взгляд.

С одной стороны, Вы правы - такой глубокий взгляд кого-то может и отпугнуть. Можно не ставить столь масштабных задач, а реализовать для начала, например только заключение договора и получить положительные результаты для бизнеса. Можно и нужно: литература по BPM прямо советует начинать "с тех плодов, которые висят не высоко". Но учтите, что кого-то - например, грамотного системного архитектора - отпугнет, наоборот, чересчур облегченный подход.

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

Что касается стандартов: к ним все же надо стремиться, хотя и без фанатизма. Сравнение BPMN с J2EE на мой взгляд не слишком корректно: J2EE - это мета-стандарт, собрание из многих сотен API, BPMN по сравнению с ним гораздо проще. К тому же ведь он упакован в моделер BPM-системы. Но при всем при том мне лично BPMN не нравится, как-то не поворачивается язык назвать его удачным стандартом.

Насчет уведомлений об ответах Вы правы на 100%.

#7 Alexander Samarin, 19.01.2008 23:04

Сначала немного терминологии во избежании путаницы.

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

Чтобы это сделать в масштабах предприятия, нужны толковые наборы правил, моделей, и рекомендаций как создавать гибкие BPM системы с испольванием существующих технологий, включая BPM suites, SOA, ECM, BR, BI, EA и IT governance.

И общий комментарий насчет стандартов – многие из них довольно эклектичны. Поэтому вместо обучения стандарту (в частности, BPMN), я предпочитаю обучать как использовать стандарт для нужд клиента(аналогия с MS Word – обычно мы используем из него только 5% возможностей).

От Максима: ... что BPMS это тул (из коллекции других) для интегратора и не более? Или может это все-таки может быть средством, которое можно взять и с небольшим набором знаний, экспериментов, пониманий аналитики, небольшой помощью программистов, потихоньку втянуть в процесс работы компании, адаптируя и задействуя все больше процессов внутри?

Трактуя BPMS как BPM suite. Мой личный опыт – это как использовать такой инструментарий для совместной работы аналитиков, программистов и интеграторов по постепенной реализации процессов. Сначала берутся довольно “короткие” процессы, например, из ECM или типичные batch. Затем они используются как сервисы в более “длинных” процессах и т.д. Важно видеть что должно быть построено (enterprise architecture) и знать как сохранять гибкость системы (agility).

От Анатолия: ... Представьте себе сквозной end-to-end процесс "от заказа до оплаты" производственной компании:...

Я думаю, что в таком случае наиболее необходим архитектор BPM систем для того, чтобы доходчиво объяснить всем вовлеченным лицам (от руководства до простого рабочего и системного администратора – практически любому сотруднику) как BPM система решает их проблемы и как она изменит их работу к лучшему. Обычно архитектор работает с BPM артефактам (я их уже упоминал) и распределяет "поиск", реализацию и компоновку этих артефактов среди аналитиков, программистов и интеграторов.

От Анатолия: ... BPM для малых компаний?

Если такая компания сильно зависит от внешне регламентированных правил (compliance, ISO 9000, etc.) то BPM система, например на основе открытого ПО, очень может пригодиться.

Thanks,
AS

#8 Максим Косенко, 20.01.2008 04:28

>Мне кажется, Вы сделали из статьи неправильные выводы.

Это вполне вероятно. Чтение по диагонали подводит часто.
Но я скорее просто высказался на общую тему. Просто многие эти рассуждения и выводы, которые я вижу, все больше говорят мне о том, что среди производителей и интеграторов/консультантов бытует мнение, что BPMS это все-таки для крупных компаний, а остальным это и не нужно и недоступно.

Я все же найду время попозже, для того чтобы прочитать статью внимательно.

>Представьте себе сквозной end-to-end процесс "от заказа до оплаты" производственной компании:

Я хорошо представляю себе подобные процессы. Объектные (и в какой-то степени сервисные) методики и событийные модели позволяют не делать все и сразу, а постепенно и аккуратно приходить к надежной реализации таких и куда более сложно-интегрированных процессов. И главное, что они позволяют оставить описания довольно простыми, понятными и стройными. Попытка описать подобное целиком на правилах мало достижима, так как сложность описания слишком высока.

>И отрываться от крепкой интеграционной основы значит создавать ненадежные и недолговечные схемы процессов.

Я, честно говоря, в сомнениях что можно считать крепкой интеграционной основой. Скажем собрать имеющиеся системы в SOA это шаг, который позволяет проще интегрировать, снизить сложность и это хорошая интеграционная основа. Кто будет и как заниматься оркестрацией? Сомневаюсь, что BPEL для этого необходимость.

>С одной стороны, Вы правы - такой глубокий взгляд кого-то может и отпугнуть.

Этого я не очень опасаюсь, понятно, что подобные статьи и взгляды они доносятся до определенной аудитории, а для массового корпоративного клиента это просто рассуждения специалистов о квантовой физике. Другое дело, что попытка понять новому клиенту что есть BPM утыкается в 2 вещи - рассказы о том, что это серебрянная пуля и рассуждения о том как прикладывать один стандарт к другому так, чтобы реже болеть. Понятно, что 99% новых клиентов поищут что-нибудь попроще. Просто другую ERP/SCM/CRM/... С ними по крайней мере гора материалов, которые гораздо понятнее и не пестрят ворохом стандартов и новыми аббревиатурами типа BI/BAM и прочая.

>BPM для малых компаний? При всем моем личном энтузиазме - очень сомнительно.

Ну я понимаю логику. Это как раз то как сейчас выглядят большинство BPMS. Это то, куда они себя загнали в погоне за тем клиентом, который один приносит больше тысяч средних. Т.е. если вы настолько большая компания, то "попробуйте еще и BPM - знаете, это помогает". Есть конечно и продукты, которые стараются выглядеть попроще, но все-таки тоже туда хотят...

Но это проблема. Мне нравится подход Александра в первом абзаце. Так и есть - каждая компания так или иначе управляет бизнес процессами. У каждой организации хоть какой-то менеджмент их да есть. Вопрос в том, что во всех процессах компании есть какие-то этапы, которые было бы удобно автоматизировать. Да, их можно автоматизировать массой продуктов и способов. Придумано множество различных названий для систем автоматизирующих разные виды подобных процессов. И BPM может быть той системой, которая не обязательно используется для того, чтобы отказаться от гибкости, а та система, которая эффективно подхватывает определенные процессы и помогает компании автоматизировать те места, которые нужно. Она может помочь связать системы с людьми. Помочь связать разные приложения воедино.

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

Теперь вот насчет цены вхождения. Я молчу про заоблачные цены на лицензии. Во-первых это по-разному, а во-вторых все мы давно знаем, что цена это то, за сколько выгоднее всего продавать. Если все-равно компания не справится сама с тем, чтобы понять как она работает, то при цене 200 у.е. за час консалтинга, реинжиниринга и девелопмента уже не важно сколько стоят лицензии. Я не призываю продавать дешевле - это не имеет смысла. Кроме того, есть Open Source и просто недорогие решения. И не сказать, что они хуже или не заработают у больших клиентов - очевидно у них другая аудитория. Я просто говорю про то, что, конечно, такие BPM соизмеримые по цене с SAP R3, они не для средних компаний.

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

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

Но мое мнение, что это подход производителей к продажам создал такие условия, а не сама концепция BPM.

>Что касается стандартов: к ним все же надо стремиться, хотя и без фанатизма.
Стандарты это хорошо. Когда в тему. А когда надо написать много статей, чтобы притянуть их за уши - это мне кажется не в тему. Для полноценной интеграции BPM и для исполнения своих задач им не нужен BPEL. BPMN это хорошая опция, потому что это стандарт на нотацию - если его кто-то уже знает, ему будет легче создавать модели, но следовать ему один в один, чтобы полностью поддерживать из принципа - вряд-ли это так важно. Т.е. я вовсе не против стандартов. Но то, что творится в области BPM это на мой взгляд фанатизм + личные интересы некоторых вендоров. Продукт может быть хорошим и без этого. Совершенно ничего он не теряет отказавшись от поддержки этих стандартов, кроме клиентов, которым нужны шашечки.

>Сравнение BPMN с J2EE на мой взгляд не слишком корректно: J2EE - это мета-стандарт, собрание из многих сотен API, BPMN по сравнению с ним гораздо проще.

Я гораздо более метафорически сравнивал. Т.е. я просто говорил к тому, что BPM преподносится как сложная вещь, которая требует специалиста по BPM. А это не должно быть так. Т.е. оно того не стоит. Мое мнение.

>Если такая компания сильно зависит от внешне регламентированных правил (compliance, ISO 9000, etc.) то BPM система, например на основе открытого ПО, очень может пригодиться.

Да, это частый пример. Но вот, Александр, вам не кажется, что вообще говоря, даже и те компании, в которых нет жестких процессов, а есть повторяемость - им тоже может быть нужен BPM, но не как средство жесткого регулирования, а как вспомогательный инструмент? В конце концов малые компании используют workflow, crm, scm, docflow системы. И вполне эффективно.

Но ведь BPM может делать тоже самое, только гибче и более целостно. Конечно готовые решения обладают в какой-то степени более проработанным набором инструментов. Но и куда более жестким и однобоким. Это уже вопрос к вендорам BPM - почему они не предоставят гибкие инструменты? Почему у них, скажем в массе своей GUI сводится к Dashboard + Portal + Designer + Admin и при попытке заменить готовые решения BPM откровенно проигрывают своими пользовательскими инструментами...

#9 Анатолий Белайчук, 20.01.2008 23:56

"Каждое предприятие имеет свою собственную BPM систему..." - простите, коллеги, какого цвета небо на вашей планете?! smile Я понимаю, Александр обретает в краях может быть более просвещенных. Максим, но Вы-то оперируете российскими реалиями?

Даже если под BPM понимать управленческую методологию, которая может применяться вообще без софта - и тогда это утверждение мне представляется сильно натянутым. По моим наблюдениям, московским и российским, 95% компаний находятся на нулевом уровне зрелости BPM по Gartner Maturity Model. Помнится, мой сын в свое время пытался доказывать, что "двойка - это тоже оценка". Вы считаете, нулевой уровень BPM - это тоже BPM?!

Подавляющее большинство компаний, и даже разных специалистов по качеству/бизнес-процессам, не представляет себе отчетливо что такое BPM и чем он отличается от реинжиниринга или функционального управления. А 50% вообще слабо отличают процессное управление от проектного. Оптимизм внушает только одно: все без исключения думающие люди в бизнесе и ИТ проявляют к этой теме живой интерес.

Александр - "в таком случае наиболее необходим архитектор BPM систем". Понятное дело, о нем и речь. Вы много знаете архитекторов с опытом решения сформулированной мною задачи? Есть ли вообще такой опыт в природе? Удалось ли хотя бы кому-нибудь загнать в BPM сквозной процесс подобного масштаба или все пока ограничивается относительно скромными workflow и/или интеграционными сценариями? Теоретически я и сам могу рассказывать что надо делать: постепенно "выращивать" сеть взаимодействующих процессов. На практике пройдут годы пока наберешь такой опыт самостоятельно, и не обойдется без ошибок по пути.

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

"BPM преподносится как сложная вещь, которая требует специалиста по BPM." Дело не в том, что она сложная или там дорогая. Она требует *выделенного* специалиста, и это проблематично для компании мастштаба десятков человек.

Александр - мне обещали дать почитать Ваш незаконченный труд. Давно мечтал увидеть книгу, в которой собраны паттерны проектирования бизнес-процессов в BPM - не примитивные, а высокоуровневые. Успехов Вам в доведении труда до завершения!

#10 Максим Косенко, 21.01.2008 03:16

>Помнится, мой сын в свое время пытался доказывать, что "двойка - это тоже оценка". Вы считаете, нулевой уровень BPM - это тоже BPM?!

Да, я честно говоря, тоже так считаю. Т.е. как - получил двойку значит нет оценки? Оценка есть, но эта оценка не годится для каких-то задач (например сдачи экзамена). Но она есть. Нулевой уровень управления и контроля бизнес процессов по оценке Гартнер это на самом деле тоже уровень. Скажем многие компании успешно работают с таким нулевым уровнем - и не факт, что подняв этот уровень они будут работать лучше.

>Максим, но Вы-то оперируете российскими реалиями?

Да, но я другое здесь понимаю под BPM. Я имею в виду, что какие то ключевые процессы у компаний как правило как-то но управляются. Могут и лучше. Иногда сильно лучше - и станет хуже. Здесь речь не идет даже про осознанную методологию или автоматизацию. Речь идет про словосочетание Управление Бизнес Процессами. А не про BPMS или про стандарты на это.

>Оптимизм внушает только одно: все без исключения думающие люди в бизнесе и ИТ проявляют к этой теме живой интерес.

Я не знаю. Это уже конечно у нас с вами разный круг общения. smile По моим ощущениям, думающие люди в бизнесе больше уделяют внимания решению своих конкретных задач. И не так уж и часто проецируют их на методологии и системы решающие абстрактные задачи в сфере менеджмента процессов.

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

Если присмотреться к форумам того же Intalio (или других доведенных до полезного состояния Open Source BPMS) - отчетливо видно, что там довольно много мелких и средних компаний. Т.е. их там заведомо большинство. И вполне видно, что многие успешно используют на практике самостоятельно. И многие совсем не потому, что им надо следовать неким жестким стандартам.

Касательно выделения. Вообще надо сказать, что по моему впечатлению средней и мелкой компании куда проще наладить BPM. И пользы от него больше и найти того одного человека, который этим займется, как не парадоксально, куда как проще, чем в большой компании, так как энтузиазм на местах еще может быть, а реальные процессы можно вполне окинуть взором за короткое время. Я не согласен, что этот специалист во всех случаях должен быть навсегда оторван от компании. Но вообще любая современная автоматизация это уже довольно существенная часть компаний. И компаниям уже давно вполне посилу иметь своего сисадмина, своего завхоза и т.д. Очевидно, что автоматизация это очень важно и иметь Начальника Отдела АСУ вполне логично и прибыльно для многих компаний. Пусть поначалу и "приходящего".

Так что я все-таки не согласен. Предприятию из десятков человек часто и не нужен никакой внешний специалист. А если и нужен, то далеко не всегда он нужен даже и на полную ставку. Просто если рассматривать BPMS не как систему автоматизации произвольной деятельности компании в виде взаимосвязанных процессов и объектов, а как систему жесткой формализации типовых или вообще всех процессов компании, то ваш взгляд вполне логичен. Я лишь удивляюсь, тому что взгляд именно таков.

#11 Анатолий Белайчук, 21.01.2008 08:42

Пара уточнений:
1) Я говорил об интересе, проявляемом _когда_ты_им_о_BPM_рассказываешь_. Сплошь и рядом оказывается, что они о чем-то подобном мечтали. При этом я не имел в виду, что все они бросили свои дела и бегают в поисках BPM.
2) Я говорил о *выделенном* специалисте, т.е. штатном, а отнюдь не внешнем. Успешно практиковать BPM без такого специалиста на мой взгляд невозможно.

#12 Alexander Samarin, 24.01.2008 03:37

Извините, слегка выпал из дискуссии, т.к. сайт не был доступен для меня.

У меня небольшой вопрос – что подразумевается под « крепкой интеграционной основой » -- инфраструктура для SOA: ESB, registry, etc.?


От Максима ...Но вот, Александр, вам не кажется, что вообще говоря, даже и те компании, в которых нет жестких процессов, а есть повторяемость - им тоже может быть нужен BPM, но не как средство жесткого регулирования, а как вспомогательный инструмент? В конце концов малые компании используют workflow, crm, scm, docflow системы. И вполне эффективно.
Но ведь BPM может делать тоже самое, только гибче и более целостно. Конечно готовые решения обладают в какой-то степени более проработанным набором инструментов. Но и куда более жестким и однобоким. Это уже вопрос к вендорам BPM - почему они не предоставят гибкие инструменты? Почему у них, скажем в массе своей GUI сводится к Dashboard + Portal + Designer + Admin и при попытке заменить готовые решения BPM откровенно проигрывают своими пользовательскими инструментами...

По определению, хорошая BPM система нужна всем. Иногда на весь end-to-end процесс, иногда на его фрагменты, которые мы хотим контролировать в большей степени.
Strong coordination is used to guarantee that a promised outcome will be delivered with the expected customer satisfaction (quality, time, safety, etc.). This is obviously the case for automated control-oriented coordination, because many staff members, internal services and formal regulations are involved.

Исторически, небольшие фрагменты автоматизировались с помощью workflow, crm, scm, docflow. Но эти технологии сидели в своих silos и реализовали intra-application coordination. В тоже время, inter-application coordination реализовалось с помощью batch processing. В идеале, BPM система призвана реализовать единым образом intra-application и inter-application coordination. В реальности можно встретить смесь из новой BPM suite, которая использует как сервисы старые workflow.

“жестких процессов” вообще-то не существует, а есть бизнес потребности в эволюции процессов и ИТ возможности. Зачастую вторые определяют скорость реализации первых -- the tail wags the dog.

Насчет гибкости BPM систем – современные BPM suites (e.g. WebSphere, Oracle SOA) предоставляют очень широкие API. Если не нравятся или не подходит out-of-the-box Worklist manager, то он относительно легко переписывается. Как я уже говорил, проблема не в BPM suites, а в том как с их помощью построить конкретную BPM систему, которая будет довольно гибкой. Конечно с каждой BPM suite будет своя возня, но это проблемы другого порядка сложности.

Насчет готовых решений: Понимая это как off-the-shelf – они обычно ограничены, т.е. не реализуют end-to-end процесс. Понимая это как custom development – типично они не предназначены для эволюционного развития. Я видел как дорогие системы выбрасывались после года эксплуатации.

От Анатолия: ... "Каждое предприятие имеет свою собственную BPM систему..." - простите, коллеги, какого цвета небо на вашей планете?!

Но моему опыту BPM система – это логичная организация работы, которая очень много взяла из ISO 9000 особенно версии 2000 года. И хорошо известно, что ISO 9000 основывается на советской системе.

Правильная реализация BPM системы практически покрывает все основные требования ISO 9000. Я показывал наши исполняемые процессы внешним аудиторам и этого было достаточно для сертификации.

К сожалению многие существующие реализации ISO 9000 – это бумажное дублирование существующих систем.

От Анатолия: ... Понятное дело, о нем и речь. Вы много знаете архитекторов с опытом решения сформулированной мною задачи? Есть ли вообще такой опыт в природе? Удалось ли хотя бы кому-нибудь загнать в BPM сквозной процесс подобного масштаба...

Вся проблема в создании гибкой BPM системы. Сквозные системы есть но очень дороги в обслуживании. Даже использование индийских компаний уже не работает – слишком много тестирования после мелкой модификации. Другой пример, oil trader сделал свою систему на базе SAP/R3. После нескольких месяцев эксплуатации пользователи сказали, что система не соответствует их работе – рабочий процесс изменился.

Моя специализация – это практическое обеспечение гибкости BPM систем начиная со стадии их проектирования. Моя книга предназначена, в основном, для архитекторов BPM систем.

Так как книга еще не опубликована, она распространяется на соотвествующих условиях. Если хотите обсудить – пожалуйста звоните 0041 76 573 40 61.

Thanks,
AS

#13 Анатолий Белайчук, 24.01.2008 14:28

Александр - "что подразумевается под «крепкой интеграционной основой» -- инфраструктура для SOA: ESB, registry, etc.?"

Нет, это была отсылка к архитектуре, предложенной в статье. Бизнес-объекты, смоделированные через конечные автоматы и реализованные ИТ через BPEL, становятся фундаментом. Разнообразные и сильно изменчивые workflow создаются в основном усилиями аналитиков и служат "мостами" между объектами: они либо создают экземпляры одних объектов из других, либо меняют состояния каких-то объектов.

По собственному опыту я вижу, что в достаточно сложных задачах конструкции из workflow не хватает устойчивости, и такой фундамент может помочь. Намерен опробовать этот подход на практике - на самом деле это можно делать существующими системами, не обязательно создавать новое поколение BPMS.

#14 Alexander Samarin, 25.01.2008 01:43

Спасибо, Анатолий, за уточнение. Хорошие бизнес-объекты - это вещь в хозяйстве полезная (я их использую на втором снизу уровне). Главное, чтобы эти бизнес-объекты были достаточно атомарные, с интерфейсом интеллекуальнее чем CRUD, и не содержали бизнес-логики. Подробнее в improving-bpm-systems.blogspot.com в комментарии на Fallacy #5.

Thanks,
AS

#15 Михаил Манылов, 20.05.2008 17:49

Да, Марлон Думас, вероятно, родственник Александра Думаса, написавшего, к примеру, Граф Монте-Кристо =)

Для того чтобы добавить комментарий, вам нужно войти в систему или зарегистрироваться

Главная | О проекте | Введение | Софт | Литература | Форум | Семинары | Ссылки | Архив новостей | Подписка на RSS-каналы | Карта сайта | Авторские права | Версия для печати