Ну во-первых, у нас есть уже не только Pega :) мы еще разработчики девопс инструментов и улучшенной IDE pegadevops.com, правда там пока пишем на Java. У нас сейчас есть ряд проектов, один из которых внутренний, где мы используем Kotlin. pegadevops также в планах переводить на него.
Мы у себя в компании начинаем использовать Котлин на бэкенде. Показывает он себя очень хорошо. Котлин настолько хорош, что даже, если вы будете писать на нем Java-style код (а вы будете это делать по-началу), то он будет все равно читабельнее и безопаснее :)
Огромное спасибо за статью!:) как отрадно видеть, что международный гигант booking решает теже самые проблемы роста, развития и вовлеченности, что и небольшая локальная, российская компания, где я работаю. Сейчас как раз пытаемся выстроить структуру с автономиями и с лидами внутри, которые по сути будут являться servant leadership. После прочтения немного улеглось в голове все и стало больше уверенности, что идем верным путем! Спасибо!
Слишком дерзко «глаголите», но в целом, все по-делу.
Тут вопросы больше не к инструменту(-ам), а вообще к концепции BPM, такое ощущение, что до сих пор BPM так и остался концепцией. Ни один движок не решает концептуальных вопросов по работе с данными, интеграциями, «удобной» разработкой. Следует рассматривать любую BPM-платформу только, как часть вашего продукта, а не центр, что, к сожалению, в реальности не так.
Вы правы, к сожалению, на Pega BPM та же самая история. Чтобы сделать решение переиспользуемым и расширяемым, приходится «кодить» на схеме. Это плохо и все от того, что BPM используют, как решение всех проблем. Отчасти поэтому в Pega появился Case Management Designer, еще одна проекция отображения «workflow», которая пока тоже не используется.
А вот если представить на минуточку, что в компании есть CRM/ERP/<что-то еще>, который управляет клиентами компании, а так же ведет некие учетные данные и нужно автоматизировать процессы изменения сущностей, например «Обновление данных клиента». Это может быть простой процессик из пары шагов. «Стартует» процесс из данной нам системы и исполняется в БПМ. Такой процесс по силам аналитикам и не требует переиспользования. Ну а можно, конечно, перенести процесс продажи полностью в БПМ, отказавшись или частично отказавшись от изначальной системы — это будет долго, дорого, и «не правильно».
Я лишь хочу сказать, что каждый инструмент хорош для своих целей и задач. Но при этом я не отрицаю ваши утверждения, так как я ни разу не встречал на практике, чтобы аналитик рисовал схему в bpmn и она без доработок «исполнялась» в движке. Обычно «хотелки» пользователей шире предметной области BPM и пользователи не всегда мыслят процессами.
Я лично хочу верить, что где-то на западных проектах, все-таки это работает. Я не вижу в этом ничего нереального, это правда может работать, при должной степени погружения в проект автоматизации бизнес-экспертов и аналитиков. Понятное дело, что разработчики могут "допиливать" схему, но, в идеале, не bpmn-кода в ней быть не должно. Все это возникает, как я уже писал выше, потому что никто не умеет делать "правильно", а всем нужно "быстро", потому что коробка куплена за 100р в комплектации с обещаниями о быстрой разработке без кода. В реальности же, оказывается, что это лишь инструмент, который нужно уметь использовать для промышленных решений, появляется куча кода, логики, и т.д.
Просто в такой форме бизнесу наглядно и доходчиво объясняют концепцию конечного автомата и срубают за это деньги.
BPM-движок — это в первую очередь не просто конечный автомат, а все-таки движок, который может «проигрывать» схему, нарисованную бизнес-аналитиком в BPMN. И это действительно полезно, когда использовать BPM правильно, а не как «волшебную таблетку» для своего бизнеса.
Согласно моему плачевному опыту, основную часть работы все-равно приходится делать именно в «этих самых навыках»: Java SE, Java EE, и пр. И в определенный момент сама БПМ начинает уже мешать, а потом сильно мешать. И в итоге принимается решение переписать весь модуль на Java без участия БПМ.
Что касается Pega, это уже давно не BPM-движок, это целая платформа для разработки приложений. Другое дело, что специфика все-равно имеется, например: «все есть процесс/кейс», отсутствие ORM, сложности с разработкой/доработкой интеграций, свой скриптовый язык, сложный деплой приложений и т. д. Но опять же, если правильно осознавать возможности, правильно проектировать свое приложение, то BPM может облегчить ряд задач, например: процесс изменений бизнес-сущностей (оно может быть реально сложным), SLA на обработку обращений клиента, и т. д. Проблема только в том, что никто не знает «как правильно?» и большинство проектов в BPM слишком политизированы — это значит, что стоимость проприетарной BPM-платформы настолько высока, что клиент ожидает от нее чудес — автоматизацию своих непонятных производственных процессов, без оглядки на возможности выбранной платформы. Чудес не будет, ни за 100 руб, ни за бесплатно. Все это лишь инструмент и основные проблемы в наших головах.
Ну во-первых, у нас есть уже не только Pega :) мы еще разработчики девопс инструментов и улучшенной IDE pegadevops.com, правда там пока пишем на Java. У нас сейчас есть ряд проектов, один из которых внутренний, где мы используем Kotlin. pegadevops также в планах переводить на него.
Мы у себя в компании начинаем использовать Котлин на бэкенде. Показывает он себя очень хорошо. Котлин настолько хорош, что даже, если вы будете писать на нем Java-style код (а вы будете это делать по-началу), то он будет все равно читабельнее и безопаснее :)
И есть ли пруф «прошлого опыта»?
А у вас бывает такое, что у одного PO несколько команд?
Огромное спасибо за статью!:) как отрадно видеть, что международный гигант booking решает теже самые проблемы роста, развития и вовлеченности, что и небольшая локальная, российская компания, где я работаю. Сейчас как раз пытаемся выстроить структуру с автономиями и с лидами внутри, которые по сути будут являться servant leadership. После прочтения немного улеглось в голове все и стало больше уверенности, что идем верным путем! Спасибо!
Тут вопросы больше не к инструменту(-ам), а вообще к концепции BPM, такое ощущение, что до сих пор BPM так и остался концепцией. Ни один движок не решает концептуальных вопросов по работе с данными, интеграциями, «удобной» разработкой. Следует рассматривать любую BPM-платформу только, как часть вашего продукта, а не центр, что, к сожалению, в реальности не так.
А вот если представить на минуточку, что в компании есть CRM/ERP/<что-то еще>, который управляет клиентами компании, а так же ведет некие учетные данные и нужно автоматизировать процессы изменения сущностей, например «Обновление данных клиента». Это может быть простой процессик из пары шагов. «Стартует» процесс из данной нам системы и исполняется в БПМ. Такой процесс по силам аналитикам и не требует переиспользования. Ну а можно, конечно, перенести процесс продажи полностью в БПМ, отказавшись или частично отказавшись от изначальной системы — это будет долго, дорого, и «не правильно».
Я лишь хочу сказать, что каждый инструмент хорош для своих целей и задач. Но при этом я не отрицаю ваши утверждения, так как я ни разу не встречал на практике, чтобы аналитик рисовал схему в bpmn и она без доработок «исполнялась» в движке. Обычно «хотелки» пользователей шире предметной области BPM и пользователи не всегда мыслят процессами.
Я лично хочу верить, что где-то на западных проектах, все-таки это работает. Я не вижу в этом ничего нереального, это правда может работать, при должной степени погружения в проект автоматизации бизнес-экспертов и аналитиков. Понятное дело, что разработчики могут "допиливать" схему, но, в идеале, не bpmn-кода в ней быть не должно. Все это возникает, как я уже писал выше, потому что никто не умеет делать "правильно", а всем нужно "быстро", потому что коробка куплена за 100р в комплектации с обещаниями о быстрой разработке без кода. В реальности же, оказывается, что это лишь инструмент, который нужно уметь использовать для промышленных решений, появляется куча кода, логики, и т.д.
BPM-движок — это в первую очередь не просто конечный автомат, а все-таки движок, который может «проигрывать» схему, нарисованную бизнес-аналитиком в BPMN. И это действительно полезно, когда использовать BPM правильно, а не как «волшебную таблетку» для своего бизнеса.
Что касается Pega, это уже давно не BPM-движок, это целая платформа для разработки приложений. Другое дело, что специфика все-равно имеется, например: «все есть процесс/кейс», отсутствие ORM, сложности с разработкой/доработкой интеграций, свой скриптовый язык, сложный деплой приложений и т. д. Но опять же, если правильно осознавать возможности, правильно проектировать свое приложение, то BPM может облегчить ряд задач, например: процесс изменений бизнес-сущностей (оно может быть реально сложным), SLA на обработку обращений клиента, и т. д. Проблема только в том, что никто не знает «как правильно?» и большинство проектов в BPM слишком политизированы — это значит, что стоимость проприетарной BPM-платформы настолько высока, что клиент ожидает от нее чудес — автоматизацию своих непонятных производственных процессов, без оглядки на возможности выбранной платформы. Чудес не будет, ни за 100 руб, ни за бесплатно. Все это лишь инструмент и основные проблемы в наших головах.