Comments 3
Не первый раз встречаюсь с подобным конструктором бизнес-процессов (БП) и мое мнение двоякое на этот счет. С одной стороны для «внедренца» конечно же это подспорье, но немного сомнительное. Т.к. большинство БП «внедренец» все-равно будет описывать с применением программирования (внутренним API системы) и простыми функциями типа «Пуск-If Then Else-Стоп» вряд ли все закончится. Тогда по сути такого рода конструктор представляет собой типа редактора блок-схем программы (БП).
Когда-то мне озвучили, что подобная «приблуда» нужна для упрощения создания БП тем же ГИПом (ГАПом), или любым другим руководителем. Всё хорошо, если бы не «взаимоисключающие параграфы» — Руководитель и Создавать. В большинстве организаций руководитель даже разбираться не будет во всех этих «квадратиках», не говоря уже про что-то там запрограммировать.
Поделитесь пожалуйста статистикой из Вашего опыта по использованию конструктора БП при внедрениях.
Когда-то мне озвучили, что подобная «приблуда» нужна для упрощения создания БП тем же ГИПом (ГАПом), или любым другим руководителем. Всё хорошо, если бы не «взаимоисключающие параграфы» — Руководитель и Создавать. В большинстве организаций руководитель даже разбираться не будет во всех этих «квадратиках», не говоря уже про что-то там запрограммировать.
Поделитесь пожалуйста статистикой из Вашего опыта по использованию конструктора БП при внедрениях.
…
Как показал опыт конструктор используется очень часто. По крайней мере в тех случаях, когда приходится решать задачи не закрытые готовыми приложениями или в случае их расширения. Его использование имеет ряд преимуществ перед чистым программированием.
1. Моделировать процессы в конструкторе могут люди, которые не умеют программировать, таких достаточно много среди внедренцев нашей платформы. Благо набор сущностей достаточно богат, чтобы реализовать много сценариев без использования кода
2. В отличии от обычной программы процесс имеет средства визуализации и мониторинга, что-то типа визуального отладчика, это можно использовать как на стадии проектирования, так и при эксплуатации. По крайней мере при возникновении ошибки у вас есть визуальная возможность посмотреть где остановился процесс и прямо в карточке экземпляра процесса просмотреть журнал, определить источник проблемы, оставить процесс, что то в нем поменять и запустить далее. Хороший программист, хорошо понимающий код это сделает и безо всякого дизайнера процессов, но инженер сопровождения очень часто не является автором процесса, и мог получить его уже готовым в коробке.
3. Конечно менеджер не будет рисовать модели процессов в приложениях, это дело инженера. Но согласовать общую схему показанную в «упрощенном режиме» дизайнера или даже потыкать в кнопочки прототипа который собран с помощью конструкторов он может. И даже часто с удовольствием это делает. И это позволяет сокращать цикл и убирать гэп между моделированием и разработкой. Что же касается идеи что менеджер сам начнет себе рисовать процессы — это и правда утопия. Хотя она относится только к BPM системам. Для этого у нас есть другие упрощенные инструменты, но это уже отдельная история.
В общем конструктор процессов часто используют, почти во всех внедрениях. Да и мы сами часто его используем при создании приложений, например, модуль потокового ввода у нас реализован не в коде а с использованием конструктора бизнес процессов, что позволяет его достаточно просто модифицировать и расширять при внедрении.
Но если копнуть глубже, то на практике оказывается, что заменить десяток интерпретируемых функций настроенных в дизайнере на десяток другой строк скомпилированного кода оказывается не плохой идеей для повышения производительности системы. К чему части и прибегают разработчики. Но делается это не написанием какого-то модуля с нуля, а реализации новой функции в конструкторе в виде программного скрипта и функции расширения…
1. Моделировать процессы в конструкторе могут люди, которые не умеют программировать, таких достаточно много среди внедренцев нашей платформы. Благо набор сущностей достаточно богат, чтобы реализовать много сценариев без использования кода
2. В отличии от обычной программы процесс имеет средства визуализации и мониторинга, что-то типа визуального отладчика, это можно использовать как на стадии проектирования, так и при эксплуатации. По крайней мере при возникновении ошибки у вас есть визуальная возможность посмотреть где остановился процесс и прямо в карточке экземпляра процесса просмотреть журнал, определить источник проблемы, оставить процесс, что то в нем поменять и запустить далее. Хороший программист, хорошо понимающий код это сделает и безо всякого дизайнера процессов, но инженер сопровождения очень часто не является автором процесса, и мог получить его уже готовым в коробке.
3. Конечно менеджер не будет рисовать модели процессов в приложениях, это дело инженера. Но согласовать общую схему показанную в «упрощенном режиме» дизайнера или даже потыкать в кнопочки прототипа который собран с помощью конструкторов он может. И даже часто с удовольствием это делает. И это позволяет сокращать цикл и убирать гэп между моделированием и разработкой. Что же касается идеи что менеджер сам начнет себе рисовать процессы — это и правда утопия. Хотя она относится только к BPM системам. Для этого у нас есть другие упрощенные инструменты, но это уже отдельная история.
В общем конструктор процессов часто используют, почти во всех внедрениях. Да и мы сами часто его используем при создании приложений, например, модуль потокового ввода у нас реализован не в коде а с использованием конструктора бизнес процессов, что позволяет его достаточно просто модифицировать и расширять при внедрении.
Но если копнуть глубже, то на практике оказывается, что заменить десяток интерпретируемых функций настроенных в дизайнере на десяток другой строк скомпилированного кода оказывается не плохой идеей для повышения производительности системы. К чему части и прибегают разработчики. Но делается это не написанием какого-то модуля с нуля, а реализации новой функции в конструкторе в виде программного скрипта и функции расширения…
Sign up to leave a comment.
Приложения в системе электронного документооборота. Часть 4: Конструктор бизнес-процессов