Комментарии 26
Было бы неплохо если бы была Developer Express версия для разработчиков. Если Pega не жадины конечно !
И всегда за этим всем маркетинговым трешаком, решительно непонятно что там продать пытаются. Скажем, ни у кого демку на сайте потыкать нельзя. Максимум — видосики, где UI стыдливенько-ссыкливенько врезочками показывают, а 90% — всё тот же булщит.
Хоть на Хабре рассказывали бы честно что за штука, без этого продажнического слога.
Ну, я вроде про то же и говорю — там такой треш, что если дать посмотреть — не купят. Поэтому эти все CRM/ERP/BPM пытаются втюхать, не дав их потрогать :)
Относится это ко всем CRM/ERP/BPM — коих миллион видов, и кои все являются продвинутыми аналогами MS Access: задали схему данных, получили UI для вбивания данных, репортинг, и какие-нибудь там базовые конфигурации. Ну и vendor lock-in в нагрузку — с тупыми API, и хорошо еще если без самодельных языков программирования.
Сотрудники абсолютно всех компаний — от микробизнеса до транснациональных холдингов — недолюбливают внедрение корпоративных систем.Вовсе не по указанным причинам. А потому, что очень часто такие корпоративные системы — это «крутой космический корабль» на котором можно передвигаться и летать, даже в космос
Но и из всего функционала пользователь будет только изредка заходить в эту кабину пилота, и только пользоваться туалетом (нажимать 2-3 кнопочки). И каждый раз испытывать дискомфорт из-за того, что «чтобы использовать туалет» нужно прогреть двигатели, включить зажигание, не забыть снять тормоз, включить тумблер «полёт разрешён», и только тогда включится вода в толчке.
И если раньше внутреннему пользователю всего лишь нужно было отправить письмо в нужное подразделение, то теперь сделать -дцать кликов, и лишь там набрать письмо.
Другими словами, корпоративные системы зачастую слишком перегружены ненужными кнопками, лишними интерфейсами, а об удобстве пользователя задумываются в последнюю очередь, ведь главное: «на этом можно летать даже в космос — нам точно стоит заменить этим наши колхозные тракторы!»
Если бы космический корабль!
Когда клиенту нужно наладить доставку продуктов из пункта А в пункт Б, где хватило бы мотоцикла с коляской или для особо продвинутых — электромобиля на солнечных батареях, тебе продают железную дорогу, позиционируя как наилучшее и самое перспективное решение на рынке грузоперевозок. Комплект включает в себя: рельсы, шпалы, паровоз (1шт.), лицензию на использование, толстую инструкцию по монтажу, экспресс-курсы для клиента на роль путейцев, машинистов, кочегаров, вагоновожатых и станционных диспетчеров.
Далее за отдельную плату провайдер продает вагоны, но как правило весь комплект имеющихся вагонов задвигается клиенту сразу и полностью: и пассажирские, и цистерны, и холодильники, и вагоны для перевозки автомобилей, и крупного рогатого скота, и австралийских кенгуру, и впридачу вагон-ресторан, вагон-туалет, вагон-интернет и вагон-казино с блекджеком и женщинами (просто раньше были юзкейсы, а вагоны остались). И вот все это добро зачастую колесит в одном составе.
Весь монтаж и использование делается исключительно силами свежеобученных "специалистов" клиента под зорким присмотром провайдера, который следит за соблюдением концептуальности монтажа (best practices) и правильным использованием "средств разработки" — лопаты, лома и кувалды. Обязательная "поддержка" паровоза производится провайдером за периодическую плату, которая состоит в оперативном объяснении клиенту, в чем была его вина в случае взрыва котла или схода поезда с рельс: неправильная эксплуатация локомотива или некачественный монтаж путей.
Любые претензии к провайдеру не принимаются во внимание. Низкая скорость доставки или паровоз не едет в горку — покупайте второй паровоз и используйте в сцепке! Поэтому большинство клиентов на особо сложных участках колеи использует своих лошадей для "подтаскивания" локомотива (а иногда и поездную бригаду), т.к. на второй паровоз денег запланировано не было. Доходит даже до случая, когда поезд с локомотивом на всем участке приводится в движение исключительно лошадьми, но это уже крайность.
Требуется чуток изменить маршрут — нет проблем. Только стоит спроектировать, пригласить инженеров, геодезистов, проектировщиков, подготовить местность, дождаться свободного окна, вызвать путейцев, поставить стрелочные переводы и проложить новый путь. В компании с правильной методологией работы со всем этим не должно быть никаких проблем.
Звучит шизофренично, но это краткое иносказательное описание моего более-чем-десятилетнего опыта работы с BPM.
Весь монтаж и использование делается исключительно силами свежеобученных «специалистов» клиента под зорким присмотром провайдера, который следит за соблюдением концептуальности монтажа (best practices) и правильным использованием «средств разработки» — лопаты, лома и кувалдыК сожалению, «специалисты» могут быть не только у клиента, но и у поставщика. И почему среди средств разработки не указан мешок напильников разных видов (которые кстати тоже могут быть на отдельный прайс)?
Зачем BPM бизнесу? BPM — это концепция управления бизнесом через бизнес-процессы.
Просто в такой форме бизнесу наглядно и доходчиво объясняют концепцию конечного автомата и срубают за это деньги.
У нас для вас две новости: хорошая и так себе. Хорошая: BPM уже существует. Так себе: мало кто знает, что с этим делать.
Это я все периодически слышу более чем 10 лет. Уж извините за упоминания, "работал" (хотя тут больше подходит глагол, обозначающий действие сексуального характера) со стеком IBM Websphere, с Oracle SOA Suite, немного ковырял JBoss SOA platform и небольшие BPM вроде Activiti и Bonita — все клянутся, что это вазелин для вашего бизнеса и без него никак. В итоге практически нигде эти решения не работают по-нормальному по ряду причин концептуального, технического и политического характера. А возни и расходов с ними на порядок больше.
Среди использующих Pega компаний — лондонский аэропорт Хитроу, MasterCard, City Bank, Morgan Chase и многие другие.
А это вообще ни разу не показатель качества платформы. Чем мажорней компания, тем больше люди, принимающие стратегические решения, оторваны от технической области.
В банках кейс, как правило, включает в себя все действия с момента обращения клиента (например, запрос на получение кредита, опротестование операции по карте) до полного решения данного вопроса (к примеру, выдача кредита)
Это то, что продают на презентации продукта. Первый пример процесса в tutorials ко всем BPM — это Loan Broker. И как правило на этом все заканчивается.
Работая в действительно нетривиальных и сложных проектах, разработчики могут использовать и прокачивать свои навыки: Java SE, Java EE,
Согласно моему плачевному опыту, основную часть работы все-равно приходится делать именно в "этих самых навыках": Java SE, Java EE, и пр. И в определенный момент сама БПМ начинает уже мешать, а потом сильно мешать. И в итоге принимается решение переписать весь модуль на Java без участия БПМ.
На самом деле, Pega сама по себе — будущее автоматизированных систем управления (АСУ) и корпоративных информационных систем (КИС).
Это будущее уже на горизонте лет этак 15, еще когда BPM скромно называли Workflow. Но все никак не наступит. Так что определенная ниша у подобных решений будет всегда, но далеко не в каждом доме. А связывать свое будущее с программированием мышью, клепанием бесконечных формочек и меппингу данных — удовольствие на любителя.
Просто в такой форме бизнесу наглядно и доходчиво объясняют концепцию конечного автомата и срубают за это деньги.
BPM-движок — это в первую очередь не просто конечный автомат, а все-таки движок, который может «проигрывать» схему, нарисованную бизнес-аналитиком в BPMN. И это действительно полезно, когда использовать BPM правильно, а не как «волшебную таблетку» для своего бизнеса.
Согласно моему плачевному опыту, основную часть работы все-равно приходится делать именно в «этих самых навыках»: Java SE, Java EE, и пр. И в определенный момент сама БПМ начинает уже мешать, а потом сильно мешать. И в итоге принимается решение переписать весь модуль на Java без участия БПМ.
Что касается Pega, это уже давно не BPM-движок, это целая платформа для разработки приложений. Другое дело, что специфика все-равно имеется, например: «все есть процесс/кейс», отсутствие ORM, сложности с разработкой/доработкой интеграций, свой скриптовый язык, сложный деплой приложений и т. д. Но опять же, если правильно осознавать возможности, правильно проектировать свое приложение, то BPM может облегчить ряд задач, например: процесс изменений бизнес-сущностей (оно может быть реально сложным), SLA на обработку обращений клиента, и т. д. Проблема только в том, что никто не знает «как правильно?» и большинство проектов в BPM слишком политизированы — это значит, что стоимость проприетарной BPM-платформы настолько высока, что клиент ожидает от нее чудес — автоматизацию своих непонятных производственных процессов, без оглядки на возможности выбранной платформы. Чудес не будет, ни за 100 руб, ни за бесплатно. Все это лишь инструмент и основные проблемы в наших головах.
BPM-движок — это в первую очередь не просто конечный автомат, а все-таки движок, который может «проигрывать» схему, нарисованную бизнес-аналитиком в BPMN.
Вы знаете, возможноть написать схему силами аналитика — это такой распространенный миф. Любая реально интересная схема процесса должна интегрироваться с другими процессами и системами в компании — а это уже обычно не BPMN, и в этой интеграции платформа как правило быстро начинает мешать.
Более того, после завершения обвешивания схемы всякого рода не-BPM кодом, аналитик уже как правило ничего в ней не понимает :)
Я лично хочу верить, что где-то на западных проектах, все-таки это работает. Я не вижу в этом ничего нереального, это правда может работать, при должной степени погружения в проект автоматизации бизнес-экспертов и аналитиков. Понятное дело, что разработчики могут "допиливать" схему, но, в идеале, не bpmn-кода в ней быть не должно. Все это возникает, как я уже писал выше, потому что никто не умеет делать "правильно", а всем нужно "быстро", потому что коробка куплена за 100р в комплектации с обещаниями о быстрой разработке без кода. В реальности же, оказывается, что это лишь инструмент, который нужно уметь использовать для промышленных решений, появляется куча кода, логики, и т.д.
Ну вот смотрите… насчет "умеют ли как правильно". Я попробую показать на примере IBM BPM, которую знаю. Ее авторы попробовали уложить вообще всю логику в схемы, расширив BPMN на такие вещи, как обычный (по сути процедурный) код, который грубо говоря, не является процессом, и на UI. И еще дополнив систему обычным языком программирования, в качестве которого используется javascript.
Так вот, очень быстро выясняется, что многие вещи намного проще делать на javascript. Ну хотя бы потому, что эти решения намного лучше используются повторно. Некий "компонент", выполненный в виде кода, и он же в виде BPMN, это небо и земля с точки зрения а) понимания, как он устроен б) простоты повторного использования в другом месте в) внесения изменений. javascript тривиально проще, хотя и сделан "не по канонам".
Ну т.е., с одной стороны, "не bpmn-кода в ней быть не должно", и все может нарисовать аналитик в IDE, не написав ни строчки кода, а с другой — решения, выполненные именно в виде самого обычного кода являются намного более удобными с точки зрения затрат усилий на их создание и сопровождение.
А вот если представить на минуточку, что в компании есть CRM/ERP/<что-то еще>, который управляет клиентами компании, а так же ведет некие учетные данные и нужно автоматизировать процессы изменения сущностей, например «Обновление данных клиента». Это может быть простой процессик из пары шагов. «Стартует» процесс из данной нам системы и исполняется в БПМ. Такой процесс по силам аналитикам и не требует переиспользования. Ну а можно, конечно, перенести процесс продажи полностью в БПМ, отказавшись или частично отказавшись от изначальной системы — это будет долго, дорого, и «не правильно».
Я лишь хочу сказать, что каждый инструмент хорош для своих целей и задач. Но при этом я не отрицаю ваши утверждения, так как я ни разу не встречал на практике, чтобы аналитик рисовал схему в bpmn и она без доработок «исполнялась» в движке. Обычно «хотелки» пользователей шире предметной области BPM и пользователи не всегда мыслят процессами.
BPM-движок — это в первую очередь не просто конечный автомат, а все-таки движок, который может «проигрывать» схему, нарисованную бизнес-аналитиком в BPMN. И это действительно полезно, когда использовать BPM правильно, а не как «волшебную таблетку» для своего бизнеса.
Этот движок занимает 70кб джарник, их полно в инете. Плюс средства разработки — BPMN-редактор, где человек с ограниченными интеллектуальными возможностями, гордо называющий себя бизнес-аналитиком, сможет почувствовать себя разработчиком, расставляя на диаграмме ящики и стрелки при помощи мышки, концептуально называя все это бизнес-процессом. А дальше требуется нехилая бригада чертей, которые заставят все это хоть как-то шевелиться — заполнить каждый ящик реальной логикой, используя предоставляемую провайдером "платформу", которая по-сути есть фоллбэк в какой-нибудь фреймворк (Spring, JEE, JBI, SCA, etc) или язык программирования, но только с сильно ограниченными возможностями.
За работу чертей никто никогда не волнуется, поэтому их средства разработки — как правило неудобоваримое глючное говно. Все визуальные "ништяки", демонстрируемые на поверпоинтах в реале оказываются либо ненужными, либо неудобными, либо вообще противоречащие основным концептам программирования. Отдельным вопросом стоит интеграция средств разработки аналитика и программиста и и их колаборативной разработки. Все хотели, чтобы когда аналист что-то меняет, у разработчика автоматически апдейтится проект, и он видит изменения. Реально же почти всегда есть два проекта — красивая схемка и реальный процесс.
Однажды запустив процесс, начинается свистопляска с его поддержкой и версионированием. Причем, версии могут меняться как у самого процесса, так и у внешних сервисов и структур данных. До сих пор ни одна BPM так и не решила по-нормальному этот вопрос, потому что нормального решения просто нет. Нормальное решение — это при выкатывании новой версии апдейтнуть состояния всех запущенных процессов. Но поскольку у нас не простенькая state machine, а BPMN, выполняемая пропиетарным движком, то нифига не получится.
Тут вопросы больше не к инструменту(-ам), а вообще к концепции BPM, такое ощущение, что до сих пор BPM так и остался концепцией. Ни один движок не решает концептуальных вопросов по работе с данными, интеграциями, «удобной» разработкой. Следует рассматривать любую BPM-платформу только, как часть вашего продукта, а не центр, что, к сожалению, в реальности не так.
Camunda вообще красавица! Делаешь из Maven'овского архетипа проект. Там уже все разложено по папочкам. Открываешь в Camunda Modeler файлик src/main/resources/process.bpmn. Рисуешь процесс как тебе надо. На Start Event и/или User Task можешь добавить форму. Форму можешь сделать тут же в Modeler'е. Это будет Generated Form и ее описание будет храниться тут же в .bpmn файле. Если нужна понавороченней и с загрузкой файлов — то делаешь отдельно ручками (Embedded Form) и кладешь в директорию src/main/webapp/forms. Как "привязывать" формы в Modeler'е — это уже в документацию. Завершил работу в моделере, делаешь
В директории target теперь появился .war файл, который теперь копируешь в папочку деплоя веб-приложений. В Tomcat, например, это webapps. Заходишь в Task List и видишь свой процесс и можешь его запускать.$ mvn clean package
Есть PHP SDK — сейчас как раз "скрещиваю" Camunda с SuiteCRM. Есть JS SDK c Angular 1.2 и без, чтобы встраивать Embedded Forms в свое веб-приложение.
Можешь делать Service Task и писать свои классы на Java. Можешь делать Script Task и писать на скриптовых языках.
Кроме Camunda ничего другого BPM'ного руками не трогал. Поэтому мнение субъективное. Но имхо Camunda очень хороша. От одного чтения документации уже хорошо на душе становится! :)
При этом основные преимущества платформы особенно ощутимы при большом количестве пользователей (от 100), экземпляров процессов (от 500 в день), интеграции с внешними системами (более 10 систем, 20-30 интеграционных точек), а так же необходимости частого (не мене 1 раза в неделю) бизнес-администрирования элементов решения (этапы процессов, справочники, алгоритмы, шаблоны и др.).
Специалисты нашей компании с радостью обсудят с вами текущие потребности и проконсультируют по вариантам решения, а так же стоимости.
BPM в компании: пусть решают процессы