Comments 18
опять активити, это наверное уже второй раз, до этого была суба платформ, интересно как идут продажи!
А потом отдел кадров или бухгалтерия вам скажет — а нам нужно на форме показывать, сколько в отпуске рабочих и выходных/праздничных дней… и… и опаньки.
А вот и не опаньки! Прямо сейчас в Гидру OMS встроен плагин для извлечения информации из RDBMS посредством настраиваемого в конфиге SQL-запроса (маленький нюансик: пока поддерживается только Oracle). И есть два типа лукапа — один в виде обычного комбобокса, а второй для подбора из большого количества вариантов. И можно добавлять свои типы полей и справочного текста.
Вообще, главной причиной создания Гидры OMS было то, что у всех изученных нами BPMS отсутствует возможность вменяемо настроить/допилить/встроить мастер выполнения «ручных» задач бизнес-процесса, не написав при этом миллиона строк кода на джаве.
TL;DR: Возможность подгружать на форму задания информацию из внешней системы, необходимую сотруднику для исполнения задачи — критически важная фича Гидры OMS, она уже есть и мы планируем развивать ее дальше.
Вообще, главной причиной создания Гидры OMS было то, что у всех изученных нами BPMS отсутствует возможность вменяемо настроить/допилить/встроить мастер выполнения «ручных» задач бизнес-процесса, не написав при этом миллиона строк кода на джаве.
TL;DR: Возможность подгружать на форму задания информацию из внешней системы, необходимую сотруднику для исполнения задачи — критически важная фича Гидры OMS, она уже есть и мы планируем развивать ее дальше.
Видите ли, я не знаю, какие там BPMS вы изучали, а я три с лишним года проработал на IBM BPM. И там можно не просто писать запросы — там полноценный язык программирования, на выбор — либо javascript (Mozilla Rhino) либо чуть посложнее — Java. И формы там допиливаются до любого состояния — с лукапами, с rest запросами, направо и налево. И SQL-запросы пишутся какие угодно, к любой базе. Только все равно получается паршиво.
В принципе, можно интегрироваться с чем угодно. Но только в принципе.
Проблема в том, что как только вы начали писать такой код — вашему процессу как раз и будут опаньки, потому что глядя на диаграмму вы больше ничего уже не понимаете. Вы не видите кода, вы не знаете, что он делает, откуда берет и куда кладет данные. Диаграмма больше не отражает почти ничего. И самый лучший, по моему опыту, способ интегрироваться с каким-либо UI, если он вам нужен — это не делать его в BPM системе вообще. Делать где угодно, в каком угодно виде. На любом инструменте.
В принципе, можно интегрироваться с чем угодно. Но только в принципе.
Проблема в том, что как только вы начали писать такой код — вашему процессу как раз и будут опаньки, потому что глядя на диаграмму вы больше ничего уже не понимаете. Вы не видите кода, вы не знаете, что он делает, откуда берет и куда кладет данные. Диаграмма больше не отражает почти ничего. И самый лучший, по моему опыту, способ интегрироваться с каким-либо UI, если он вам нужен — это не делать его в BPM системе вообще. Делать где угодно, в каком угодно виде. На любом инструменте.
Конечно же, адские BPMS позволяют делать все эти вещи, но их и покупают за адские деньги, чтобы делать адски сложные процессы. И при всем описанном вами геморрое использовать BPMS все равно будет дешевле, чем программировать (а потом постоянно изменять) бизнес-логику.
Вообще-то в тех реальных «адски сложных» бизнес процессах, которые я делал лично и видел, часть BPM была где-то процентов 10 от силы. Ну может иногда 30. А остальные 70 как раз составляли логика UI, и работа с разного рода интеграциями. Поэтому насчет «дешевле» у меня как раз масса вопросов. По той простой причине, что программировать в виде диаграмм в BPM — это ужасно. По сравнению с нормальным процессом разработки на нормальных инструментах — это как в каменный век вернуться.
Похоже, вам не повезло :). Если основной геморрой — это UI, а сами процессы несложные и редко меняются, то, конечно, BPMS не нужна и помимо раздолбайства есть только одна причина использования BPM-движка — распил.
Я подозреваю, что все еще хуже ;)
Вот смотрите — вы нарисовали красивую картинку «Запрос на предоставление отпуска». Выглядит неплохо, если забыть на время, что это — код. И понять можно. А теперь представьте себе процесс, где диаграмм штук скажем 50 (а это не самый крупный, какой я видел и делал), и каждая из них содержит штук 20 и более элементов. И вы допустим разработчик, и пошли вы в отпуск. Все было хорошо, до тех пор, пока вы не вернулись, и не увидели, что процесс кто-то поменял.
Вот у IBM в этом случае все фигово до безобразия. Диффа нет, merge тоже нет.
Расскажите, что у вас? Есть ли версионирование процессов, можно ли сделать ветку, можно ли сравнить, что было неделю назад с тем что сейчас, можно ли сделать merge?
Вот смотрите — вы нарисовали красивую картинку «Запрос на предоставление отпуска». Выглядит неплохо, если забыть на время, что это — код. И понять можно. А теперь представьте себе процесс, где диаграмм штук скажем 50 (а это не самый крупный, какой я видел и делал), и каждая из них содержит штук 20 и более элементов. И вы допустим разработчик, и пошли вы в отпуск. Все было хорошо, до тех пор, пока вы не вернулись, и не увидели, что процесс кто-то поменял.
Вот у IBM в этом случае все фигово до безобразия. Диффа нет, merge тоже нет.
Расскажите, что у вас? Есть ли версионирование процессов, можно ли сделать ветку, можно ли сравнить, что было неделю назад с тем что сейчас, можно ли сделать merge?
Это большая проблема: поскольку речь идет об автоматизации типовых и рутинных бизнесс-процессов, то работой с BPM-софтом занимаются низкоквалифицированные сотрудники, которые не знают английский язык. Поэтому локализация крайне важна для таких систем.
А пример приведен на английском языке, так сказать чтобы было понятно :)
А пример приведен на английском языке, так сказать чтобы было понятно :)
А онлайн демо-версии нет? Или видеодемонстраций, уроков?
http://hydra-oms.com, там на главной кнопка Try Demo. Видеоуроков пока нет, но пошаговое описание настройки бизнес-процесса есть в документации.
Ребята поясните как это использовать с CRM системой, или допусти с 1с УТ.
Не совсем понял, сути.
Не совсем понял, сути.
для заполнения полей заказа обычно требуются НСИ, их нужно как-то синхронизировать. Кроме этого может быть еще бизнес-логика заказа, которая реализована в подключенной системе. как эти задачи решаются в Гидре?
Есть два способа синхронизации НСИ. Первый — вручную (варианты выбора зашиваются в конфиге мастера). Понятно, что это для редко обновляемой информации. Второй способ — вообще не синхронизировать информацию, а подсасывать ее на лету из внешней системы в момент рендеринга формы. Так работает сейчас интеграция OMS с обычной Гидрой (биллингом).
Sign up to leave a comment.
Как автоматизировать бизнес-процессы от заявки до продажи с помощью открытого софта