AK
Мы можем рассказать про концепцию построения флоу переиспользуемых юзер тасок, переход между которыми для пользователя бесшовный.
Это как раз UI на Camunda
Это как раз UI на Camunda
Size: a a a
2019 March 26
MD
Ну вот и есть 3 доклада получается.
MD
Дело за опросником )
KH
KH
пока предварительно ставлю вас на 30 мая
SN
Документооборот на bpms/bpmn это очень очень плохая идея.
AN
Sergey Novikov
Документооборот на bpms/bpmn это очень очень плохая идея.
А можно по подробнее резюмировать сказанное ?)))
DF
это типа алерта на электрощике "не влезай - убъет" и вообще кр. - с.т.)
AN
Не понимаю что в будущем будет плохо но вопрос на сколько и в каких местах
SC
Я готов поделиться своим опытом и готов к холивару.
Тема:
"Почему я делаю схемы такими, и во что все это в итоге превращается для Заказчика"
Кейсы от задачи Заказчика до представленного Заказчику результата - схема и настроенная платформа.
Тема:
"Почему я делаю схемы такими, и во что все это в итоге превращается для Заказчика"
Кейсы от задачи Заказчика до представленного Заказчику результата - схема и настроенная платформа.
AZ
Я готов поделиться своим опытом и готов к холивару.
Тема:
"Почему я делаю схемы такими, и во что все это в итоге превращается для Заказчика"
Кейсы от задачи Заказчика до представленного Заказчику результата - схема и настроенная платформа.
Тема:
"Почему я делаю схемы такими, и во что все это в итоге превращается для Заказчика"
Кейсы от задачи Заказчика до представленного Заказчику результата - схема и настроенная платформа.
мне кажется с таким докладом надо перед потенциальными заказчиками выступать. имхо)
SC
Митапы могут спонсироваться и потенциальными Заказчиками через билеты =)
MD
Пока что у нас бесплатные митапы были.
Надеюсь так и останется
Надеюсь так и останется
AK
Платформа не просто как рисовалка а реально работают диаграммы?
DK
в не-BPMS BPMN используется по-нормальному один раз - при разработке первой версии. Потом между кодом и схемой нужен переводчик и в BPMN нет смысла.
AE
A Z
Как считаете, знатоки, оркестрирование разными системами как элементами процесса - правильное ли применение BPM? . Например: подключение какого-нибудь сервиса клиенту может начинаться с CRM, далее переходить в Камунду, откуда идет «общение» с разными мастер-системами для обмена информацией (передача данных о клиенте и сервисе, получение подтверждения и тд) и в итоге возвращение финальных данных в какую-нибудь customer service catalog.
мы делаем такое на камунде, оркестрируем два десятка сервисов под CRM + делаем поверх этого валидацию инпут параметров с фронтов. Фронты над этим стоят кастомные, через камунду идёт полная оркестрация записи в бекенды / переключение переходов в процессе
SC
мы делаем такое на камунде, оркестрируем два десятка сервисов под CRM + делаем поверх этого валидацию инпут параметров с фронтов. Фронты над этим стоят кастомные, через камунду идёт полная оркестрация записи в бекенды / переключение переходов в процессе
А как у вас Камунда с итоговым софтом связана?
DK
в не-BPMS BPMN используется по-нормальному один раз - при разработке первой версии. Потом между кодом и схемой нужен переводчик и в BPMN нет смысла.
при таком рассладе можно вообще BPMN не пользоваться, а рисовать сразу в терминах планируемой платформы и стрелочек-квадратиков, всё равно переводчик нужен
AE
но сложные процессы в итоге на CMMN пересадили
DK
но сложные процессы в итоге на CMMN пересадили
это из какой предметной области? Можете пример сложного процесса назвать?