Какова ценность инструментов рабочего процесса? [закрыто]

Я новичок в разработке Workflow, и я не думаю, что я действительно получаю "общую картину". Или, другими словами, эти инструменты не «щелкают» в моей голове.

Похоже, что компаниям нравится создавать бизнес-чертежи для описания процессов, и в какой-то момент кто-то решил, что они могут использовать программу типа конечного автомата для фактического управления процессами из линии и блоков, подобных диаграмме. Десять лет спустя, эти инструменты огромны, чрезвычайно сложны (моя компания в настоящее время играет с WebSphere, и я посещал некоторые тренинги, это чудовище, даже так называемые "минималистские" версии этих инструментов рабочего процесса, такие как Activiti, огромный и сложный, хотя и не такой сложный, как зверь, который является WebSphere afaict).

Какая большая польза от этого? Я могу понять, что простые линейные и прямоугольные диаграммы полезны, но, насколько я могу судить, на данном этапе это визуальные языки программирования, дополненные условными обозначениями и циклами. Программисты здесь, кажется, выполняют значительный объем работы в слое строк и блоков, который для меня выглядит просто дурацким, действительно базовым языком визуального программирования.

Если вы собираетесь зайти так далеко, почему бы просто не использовать какой-нибудь язык сценариев? Люди бросали ребенка с водой из-за этого? Были ли строки и рамки перенесены на абсурдный уровень, или я просто не понимаю значения во всем этом?

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

С точки зрения разработчика, вы правы, говоря, что с этими «визуальными» средами действительно сложно работать. Рабочие процессы SharePoint 2010, которые я использую, отбрасывают все лучшие практики создания хорошего корпоративного программного обеспечения - без автоматизированного тестирования, без повторного использования кода, нечитаемого программного обеспечения ... Любое более сложное, чем готовый шаблон, может быть болезненным в обслуживании , как вы испытываете.

Но с точки зрения бизнеса рабочие процессы имеют огромные преимущества - по крайней мере, теоретически. Цитируя этот технический документ , эффективность, ответственность, контроль и простота использования автоматизированного рабочего процесса обеспечивают огромный прирост производительности. Представьте себе, насколько более неэффективным будет простой процесс утверждения или адаптации без этой автоматизации. Кроме того, сам процесс определения рабочего процесса полезен для организации, которая пытается получить контроль над своими бизнес-процессами.

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

1. Для того, чтобы не быть более прозрачным с бизнесом о том, насколько сложна и хрупка система на самом деле. Мы скрываем всю сложность.
2. За то, что мы не можем «почесать свой зуд» с помощью интуитивно понятных и простых решений для рабочих процессов. Вероятно, это скорее разглагольствует против крупных корпоративных пакетов, таких как SharePoint и SAP, но они лучше, чем пользовательские решения, существующие там.

Есть только одно реальное преимущество, но оно огромно: разделение проблем .

Таким образом, вместо логики управления процессом, внедряемой в нашу систему, становится и внешняя конфигурация. Карта, в основном. Вы можете изменить его (намного больше) независимо, у вас может быть несколько процессов, несколько версий процессов, несколько версий нескольких процессов, запущенных одновременно, и это все из коробки в любом приличном решении.

Исторически концепция SoC неоднократно побеждала - начиная с принципа Unix «делай одно, но делай это хорошо» и применяя снова и снова - например, с выделенными серверными компонентами, такими как ESB, различными системами персистентности, кэшированием, балансировкой нагрузки , мониторинг, как отделение CSS от HTML и т. д.

Ваш бизнес-процесс и его правила потока часто ортогональны вашим данным, пользовательскому интерфейсу или пользовательской иерархии. Таким образом, имеет смысл разработать и изменить его отдельно от других аспектов системы. Это была предпосылка, на которой BPM появился в начале 1990-х годов.

С тех пор было создано множество инструментов и языков для поддержки этой концепции, наиболее известным из которых является BPMN - графический язык для создания «потоковых диаграмм», которые напрямую отображаются на процессы. В то время как люди жалуются на то, что он большой и громоздкий (имеет более 100 символов в словаре), и отстаивает современные подходы, такие как S-BPM (имеет только 5 базовых символов), современная отраслевая практика заключается в том, чтобы придерживаться BPMN или его производных, подмножеств или родственных элементов.

Вы не выглядите довольными с BPMN:

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

Но это не так уж и плохо) За этим стоит теория. И версия 2.0 получила хорошее представление о недостатках 1.0.

Если вы собираетесь зайти так далеко, почему бы просто не использовать какой-нибудь язык сценариев?

Императивная парадигма и языки сценариев не всегда являются лучшим ответом. Как вы, вероятно, видели в декларативных языках (таких как HTML, CSS, SQL, Drools или внутренние в Nginx, Graddle и Maven, Puppet и т. Д.), Результирующий код может быть намного меньше и чище, чем версия, написанная на « приличном языке», как Java или C ++ ".

Что касается вашего другого пункта:

насколько я могу судить, языки визуального программирования на данный момент дополнены условными обозначениями и циклами.

Вы смотрели на события и триггеры ? BPMN - это язык, и вы должны изучить его перед использованием или, по крайней мере, ознакомиться с ним.

Под капотом BPMN находится XML, поэтому вы можете редактировать его вручную или генерировать. И вы можете контролировать их версию, потому что XML основан на тексте. Однако, просто наличие XML, который можно преобразовать в потоковые диаграммы, не похоже на то, что его goona поможет вам, и это правильно - написание собственного анализатора или редактора для него - сложная и дорогостоящая задача с сомнительными преимуществами.

К счастью, на рынке уже есть инструменты, которые делают это точно.

Activiti является бесплатным и довольно популярным среди разработчиков и владельцев бизнеса из-за своей начальной цены ( ноль ), доступности информации и скромности. Последний пункт действительно уникален, так как Activi фокусируется только на управлении вашими бизнес-процессами, не пытаясь связать вас с комплексными решениями. Кроме того, он открыт - так что вам нужно только знать Java и REST, чтобы запустить его. Недостатком является то, что клиентская сторона, логика интеграции и приложений / бизнеса и вся архитектура оставлены на усмотрение разработчика, поэтому, если ваша команда разработчиков слаба - подготовьтесь к неудаче. Общая стоимость владения может быть удивительно высокой для бесплатного инструмента;)

С другой стороны спектра находится Pega (Pega PRPC), правящий король систем BPM (по данным Gartner и Forester), который выглядит удивительно хорошим для своего возраста. Этот чудовище с умелой кухней даже способен работать с CRM, OCR и (если я не ошибаюсь) возможностями распознавания речи, прогнозирующей аналитикой, управлением бизнес-правилами и редактором интерфейса пользователя WYSIWYG. Это идет с серьезным ценником, все же. Мало того, что это стоит целое состояние, но вся разработка выполняется в веб-приложении, что означает, что вы должны использовать браузер, который является IE8 (плюс некоторые плагины, плюс уродливые хаки, как использование Excel для редактирования таблиц данных). Кроме того, с помощью веб-браузера также выполняется редактирование Java, Javascript или HTML / CSS - попрощайтесь с юнит-тестами, подсветкой кода IDE, рефакторингом и всеми вашими игрушками, которые вы любили.

Хорошая сторона этого? Вы можете реализовать сложную систему в течение недели [ PDF , см. стр. 22]. И да, результат не гарантирован.

В последнее время IBM (в соответствии с темпами корпоративного времени) купила Lombardi и теперь предлагает очень конкурентоспособное решение (но тогда вам придется покупать все , что вам нужно, вы знаете). Appian - молодой поставщик, у которого есть интересные идеи и положительные отзывы, но способ их написания (два дополнительных языка DSL в дополнение к визуальному) мне просто не нравится.

Есть и другие игроки, и их решения. Большинство из них просто ужасны. Мол, ваши глаза, мозг и сердце буквально кровоточат, когда вы просто смотрите на них. Так что доверяйте своим внутренностям и не заставляйте своих разработчиков и пользователей ненавидеть вас.

Заключительная записка:

BPM-система одинакова для процессов, как Photoshop для изображений. Не бойтесь, что это визуально. Не заставляйте его выполнять работу, которая ему не подходит (помните веб-сайты, созданные полностью в Photoshop, которые практически невозможно было отредактировать?). Сохраняйте это простым и не делайте ошибок;)

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

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

В последние 10–15 лет ИТ-отделы осознавали, что логика хореографии и / или организации бизнес-процессов настолько распространена, что она также должна быть ее собственным компонентом, что привело к появлению всевозможных инструментов рабочего процесса.

Есть 3 основных преимущества инструмента рабочего процесса:

1. Время, необходимое для внесения и развертывания изменений : вы можете разрабатывать и изменять логику рабочего процесса без тех же технических рисков, что и при изменении части кода.
2. Прозрачность : бизнес-логика в системе на основе BPM немедленно доступна и доступна для чтения бизнес-аналитику, тогда как только разработчики смогут читать бизнес-логику в системах, основанных на коде.
3. Повторное использование технических компонентов : инструменты BPM часто используются вместе с системами, которые имеют сервис-ориентированную архитектуру. Отделяя бизнес-логику от технических компонентов - особенно для корпоративных систем, которые должны реализовывать сотни или тысячи различных бизнес-процессов - вы можете повторно использовать технические компоненты, затрачивая относительно мало времени на разработку бизнес-логики (с рабочим процессом орудие труда).

Однако одна из наиболее распространенных проблем, с которыми я сталкиваюсь при использовании рабочих процессов и инструментов BPM, заключается в том, что разработчики все еще пытаются «похоронить» бизнес-логику в непрозрачном коде.

Все время я вижу, что разработчики все еще пытаются добавить бизнес-логику наиболее технически возможными способами, а не наиболее прозрачным из возможных. Это естественно, потому что разработчики по своей природе гораздо более удобны с кодом, чем с инструментом рабочего процесса. Кроме того, чем больше логики вы придерживаетесь в техническом плане, тем больше вам понадобится как разработчику. К сожалению, это худшее, что разработчик может сделать с системой BPM, потому что он или она подрывают основные преимущества использования BPM.

Наконец, большинство инструментов BPM недостаточно далеко, чтобы бизнес-аналитики могли сами разрабатывать рабочие процессы: однако, это и есть цель. В идеале бизнес-аналитики должны разрабатывать диаграммы рабочих процессов / бизнес-процессов, а разработчики должны работать только с техническими компонентами, вызываемыми механизмом рабочих процессов.

Ниже приведены мои личные сведения об использовании инструментов рабочих процессов, в частности Oracle BPM Suite (10.3G и 11G). Прежде всего, чтобы указать, ваш вопрос сосредоточен на инструментах рабочих процессов, которые позволяют моделировать исполняемые модели процессов, эти инструменты являются частью систем управления бизнес-процессами (BPMS). Этот конкретный процесс моделирования определенно развивается, и вы можете называть его визуальным языком программирования.

Основным преимуществом является гибкость понимания и изменения логики процесса

Модели бизнес-процессов включают в себя визуальное объяснение логики процесса и одновременно исполняемый интеграционный компонент. Это позволяет быстрее включать и выключать программистов, поскольку необходимо документировать меньшее количество документов о переходах, условных выражениях (шлюзах или бизнес-правилах) и ходе процесса в целом, поскольку это является частью разработки.

Кроме того, вы добавили функции отчетности / мониторинга, которые вам нужно будет разрабатывать индивидуально для каждого приложения, что покрывается большинством BPMS.

Более того, в большинстве сред разработки BPM сервисные адаптеры предварительно собраны (например, JMS, Web-сервисы, JDBC и т. Д.), Что позволяет быстрее разрабатывать промежуточные программные продукты за счет пошаговой интерактивной интеграции, уменьшая человеческие ошибки при кодировании.

Следование платформе рабочих процессов дает много преимуществ, упомянутых выше - основанный на платформе подход для автоматизации рабочих процессов

Значение

Ценность предложения заключается в том, что рабочие процессы могут создаваться или изменяться быстро и легко в соответствии с меняющейся природой бизнеса. Важной частью реализации этого ценностного предложения является то, что сами бизнес-процессы являются единицами ресурса в системе.

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

Почему ценность не может быть реализована

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

Плохая конструкция самих инструментов может быть ограничивающим фактором. Примером может служить инструмент, который требует, чтобы все параметры, передаваемые между процессами, были в карте Java, с ограничениями на то, какие значения вы можете фактически поместить на карту, вместо простых параметров старого метода (я думаю об одном из в частности, популярные инструменты, которые делают это).

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

Совершенно верно, что усилия по написанию взаимодействия между инструментом рабочего процесса и другими частями системы могут полностью свести на нет все ценностное предложение. Всегда стоит подумать, есть ли лучший способ сделать что-то.

Программирование - это рабочий процесс

Правда в том, что программирование (по крайней мере, на императивных языках) уже работает. У вас может быть код, который реализует рабочий процесс, связанный с обработкой технологии системы; доступ к файлам и выполнение SQL-запросов и так далее. У вас может быть код, который реализует бизнес-процесс; например, установить состояние документа и передать его рецензенту.

Признать это и разработать свой код, чтобы четко разделить эти отдельные проблемы, сложно полностью отработать, но вы, безусловно, сможете проделать долгий путь, сделав именно это.

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

Не очень понятно, какой инструмент вы используете. Я полагаю, что вы имеете в виду общий набор инструментов, называемых инструментами моделирования бизнес-процессов. Есть веская причина для использования таких инструментов. Любой качественный бизнес определяет свои функции с точки зрения процессов, и аналитики, а также бизнес-эксперты могут удобно рисовать такие процессы (пока вы не свяжете их со стандартами ...). Вы можете создавать такие процессы на концептуальном уровне без каких-либо знаний о веб-программировании, и, если у вас есть подходящий инструмент, вы также сможете преобразовать процесс в работающее приложение (опытные люди должны прийти на борт для того, чтобы это волшебство пошло в производство. конечно). Так что идея хорошая.

Цель визуальных инструментов - не просто документирование процессов. Использование этих инструментов предназначено для того, чтобы помочь профессиональным специалистам по реинжинирингу процессов и, в разы, запускать симуляции для выявления точек, где процессы менее эффективны, чем хотелось бы, чтобы можно было разработать планы по устранению узких мест.

В настоящее время многие компании используют стандартный способ, называемый BPMN 2.0 (нотация моделирования бизнес-процессов). Я рекомендую вам понять это обозначение, если ваш инструмент его использует.

Business Process Management Свод знаний является известным ресурсом, который вы можете рассмотреть , как хорошо.

Вышесказанное охватывает деловую сторону. Техническая сторона требует SOA и BPEL, но я не уверен, что смогу дать совет по этим вопросам здесь и сейчас.

В простом примере по истории.

Каменный век

Сначала у вас были небольшие менгирские компании, где люди просто говорили, что делать, и они это делали. Иногда что-то не так, и обвиняют Человека X или Y (никогда не знаешь, кто на самом деле это сделал).

Следующий интернет и электронная почта были изобретены.

Люди теперь писали другим, что делать, и у этих людей часто возникали проблемы с электронной почтой, они читали неправильно или просто удаляли электронную почту, даже не читая ее; так часто вещи, где не надо обвинять в плохой электронной почте

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