Говы расстаться с Pega?

В нашей первой статье из этой серии, «Совокупная стоимость пребывания на Pega», вы уже поняли суть проблемы: привязка к экосистеме Pega незаметно накапливается, реальные расходы скрываются в услугах и знаниях, а не в строке лицензии, и компании, желающие расстаться с ними, застревают. Не потому, что они не понимают альтернативу, а потому, что уход исторически означал проект без четких сроков, за который никто не хочет браться.

Эта статья продолжает ту тему. Теперь вопрос не в том, «почему стоит уйти от Pega?». Вопрос в том, «чего ожидать после ухода?»

Начните с обнаружения процессов, а не с чистого листа

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

К счастью, теперь есть третий вариант. Компания Camunda создала ProcessOS — решение для трансформации на базе ИИ от Camunda, чтобы избежать этого выбора. Оно обнаруживает ваши существующие процессы, используя документацию, системные журналы и данные людей, которые реально с ними работают, примерно за 10 дней вместо обычных 2–3 месяцев для традиционной фазы обнаружения. Результат — это не буквальный перевод вашего старого процесса в новый синтаксис. Скорее, он использует то, что вы делаете сегодня, в качестве контекста для достижения желаемого результата, поэтому получаемый процесс заново проектируется, а не просто переносится.

Весь цикл — обнаружение, перепроектирование, создание и улучшение — обычно занимает около четырех недель для конкретного процесса. Это превращает фразу «нам, наверное, когда-нибудь стоит мигрировать» в проект с реальными сроками, устраняя одно из главных препятствий для клиентов Pega, готовых к переезду.

Эта скорость касается не только фазы обнаружения. Она распространяется и на всю остальную работу.

Не каждый процесс требует одинакового подхода

Вот что легко упустить из виду: реалистичная миграция — это не ставка на один инструмент по принципу «все или ничего». Некоторые из ваших процессов отлично подходят для ProcessOS: они хорошо задокументированы, стабильны и действительно заслуживают перепроектирования, а не просто сохранения в исходном виде. Другие могут быть достаточно простыми, чтобы ручное воссоздание было быстрее, или вы можете захотеть получить непосредственный контроль над тем, как именно перепроектируется конкретный процесс.

Для процессов, которые вы не запускаете через ProcessOS, также существуют инструменты миграции на GitHub, которые поддерживает команда консультантов Camunda. Это помощники, а не универсальное средство. Ни один из них не преобразует автоматизацию с одной платформы на другую по одному клику. То, что они генерируют, представляет собой файл BPMN, который пытается сохранить точность вашего исходного процесса. В зависимости от того, с чего вы мигрируете, вам все равно потребуется добавить код и коннекторы, чтобы сделать его исполняемым. Вам не нужно выбирать один подход к миграции для всего вашего портфеля. Вы можете принимать решение по каждому процессу отдельно, исходя из его потребностей.

Запущенные экземпляры по-прежнему остаются сложным решением

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

Вот два подхода.

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

Подход «большого взрыва» может быть привлекателен тем, что позволяет избежать работы двух систем в течение длительного периода. Но правильный выбор зависит от того, как долго выполняются ваши процессы, какой объем простоев вы можете терпеть и каковы требования вашей среды.

То, что реально разблокирует принятие решения

Давайте теперь вернемся к двум вещам, которые мешают клиентам Pega уйти, даже когда они этого хотят: ощущению, что они уже один раз заплатили за Pega, и отсутствию кого-либо, готового взять на себя ответственность за проект без фиксированных сроков.

Ни то, ни другое не является технологической проблемой, поэтому одна лишь ProcessOS их не решает. Она объединяет работу по перепроектированию с ограниченной по времени программой миграции: специализированной командой внедрения, фиксированными сроками и планом перехода, основанным на том факте, что некоторое время вы будете использовать две платформы, а не притворяться, что этого пересечения нет. В этом разница между «нам бы когда-нибудь мигрировать» и реальным планом с датой начала, датой окончания и командой, задача которой — довести вас до цели. Чтобы узнать больше, посмотрите вебинар по запросу и узнайте, как компании используют ProcessOS для модернизации сложных ландшафтов процессов и создания более гибкой оркестрации.

Готовы уйти от Pega, но не знаете, с чего начать? Подходящие клиенты получают кредит от Camunda в счет оставшихся обязательств перед Pega и выделенную команду, которая отвечает за миграцию от начала и до конца, так что вы не останетесь с этим один на один.

Заполните форму, чтобы узнать, как будет выглядеть ваш переход.