Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Топик открыт для обсуждения вопросов, заданных здесь . С надеждой на ответ АБ... :) Привожу копию вопроса: Garya АБ Vasiliy VladimirovithА чем плох Business Process Execution Language Тем, что в нем не предусмотрены средства для описания шагов бизнес-процесса, выполняемых людьми. Такой вот развесистый bat-файл с приделанным к нему графическим редактором.А можно поинтересоваться, в каком языке описания бизнес-процессов (исполняемых, разымеется) такие средства есть? И если можно, поясните, как Вы себе на практике представляете выполнение иструкций этого языка, описывающих операции, выполняемые людьми. К сожалению, я знаком с предметом только посредством MS BizTalk Server. Так вот, в нем используется именно BPEL, и нет никаких ограничений по взаимодействию с людьми. Просто между языком и человеком, исполняющим бизнес-процесс, как я понимаю, в любом случае находится какое-то программное обеспечение (иначе просто и быть не может), которое реализует некоторый визуальный интерфейс и функциональность для диалогового взаимодействия. В случае с MS BizTalk Server взаимодейсвтие с людьми осуществляется преимущественно через MS Office InfoPath. Поскольку последняя является программой, то средств взаимодействия с программами в BPEL вполне хватает. Описание визуального интерфейса, его оформление, функциональность, механизмы обращения к данным и т.д. и т.п. закладываются в настраиваемых формах InfoPath, которые могут быть связаны также и друг с другом, образуя некоторую совокупность взаимодействующих форм. В этом смысле четко разграничиваются средства, которыми описывается бизнес-процесс и средства, которыми описываются реакции на шевеления мышкой. Я считаю такой подход вполне оправданным и логичным. В общем-то суть моего вопроса заключается в следующем. Неужели существуют языки описания бизнес-процессов, в которых можно от и до описать, что и в каком виде должен видеть на экране человек (пользователь) и как эта видимость на экране должна реагировать на шевеления мышкой? Если нет, то поясните, пожалуйста, что же есть такое в этих языках? Или они ориентированы на какие-то конкретные продукты со специфическим для этого продукта настраиваемым пользовательским интерфейсом? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.04.2006, 20:07 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
GaryaВ общем-то суть моего вопроса заключается в следующем. Неужели существуют языки описания бизнес-процессов, в которых можно от и до описать, что и в каком виде должен видеть на экране человек (пользователь) и как эта видимость на экране должна реагировать на шевеления мышкой? Если нет, то поясните, пожалуйста, что же есть такое в этих языках? Или они ориентированы на какие-то конкретные продукты со специфическим для этого продукта настраиваемым пользовательским интерфейсом? Про языки не знаю. Но, конечно, возможность описания существует, например, с применением онтологий. (По крайне мере диссертации защищаются ;)) Как описать интерефейс, и что по шевелению мышкой делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 04:31 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
BPEL конечно не мешает бизнес-процессу взаимодействовать с людьми. Но и не помогает, вот в чем беда. По этому поводу много чего можно сказать. Пожалуй начну со ссылок на авторитеты, потом поделюсь собственными соображениями. Сразу предупрежу, что моя исходная позиция строго противополжна позиции Garya: практический опыт в human-to-human BPM и теоретическое представление о system-to-system и BPEL. Нам обоим больше нравится то, с чем приходилось сталкиваться :) Для начала свежая заметку на эту тему: BPEL4People Revisited . Bruce SilverThe first part (of BPEL4People whitepaper) basically recites the core concepts of traditional workflow software – activities and tasks, roles and role resolution, deadlines and escalation, worklists and task claiming – familiar to any bank, insurance company, utility, or government agency who has implemented workflow since the late 1980s. В этой цитате перечислен тот фунционал, которого нет в BPEL, но который воспринимается как стандартная составляющая human workflow. WS-BPEL Extension for People – BPEL4People. A Joint White Paper by IBM and SAPAbstract: Human user interactions are currently not covered by the Web Services Business Processes Execution Language (WS-BPEL), which is primarily designed to support automated business processes based on Web services. In practice, however, many business process scenarios require user interaction. This paper describes scenarios where users are involved in business processes, and defines appropriate extensions to WS-BPEL to address these. SAP и IBM никак не заподозришь в недостаточной любви к BPEL, так что если уж они признают что в нем чего-то не хватает... Нехороший признак: этот whitepaper выпущен в июле 2005, и с тех пор по существу прогресса никакого нет. Еще пятак в копилку: этот документ еще очень далек от спецификации, в нем всего лишь рассмотрены 5 use-cases которые должны рассматриваться при разработке такой спецификации. И еще один: речь идет об extension к версии 2.0, которой пока в природе-то нет. И даже когда появится стандарт и его реализации, то вовсе не факт, что они будут поддерживать это расширение, ведь в нем вводится новый тип activity: People activity. Это еще не все, продолжение следует. Не торопитесь отвечать, копите аргументы :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 16:21 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Еще одна цитата из той же заметки Силвера: авторOf course, if you’re a BPEL vendor interested in selling to the BPM market, you have to integrate human tasks somehow, and they all do already. It’s just that they all do it slightly differently. Тут два утверждения: во-первых, с "голым" BPEL на рынке BPM, по сути, делать нечего. Во-вторых, все BPEL вендоры как-то эту проблему затыкают, но каждый по своему. (Поэтому, кстати, не стоит сильно превозносить "стандартность" BPEL, по крайней мере в его нынешнем виде -- ведь существенная часть остается за рамками стандарта.) Как же именно они выходят из этого положения? Брюс рисует некую "усредненную" картину. (В принципе, доверять ему можно -- он штатный независимый аналитик BPM, ведет постоянную колонку в bpminstitute.org. Пишет, в числе прочего, аналитические отчеты по BPM-продуктам, с разработчиками на короткой ноге.) Насколько эта картина соответствует тому что делает BizTalk, надеюсь, узнаем у Garya. Bruce SilverBefore describing BPEL4People, here is what I call the “typical” way I believe most BPEL vendors do human workflow today, using standard Invoke. BPEL Invoke is a web service call addressed to a service endpoint, or URL. If the service is long-running, like a human task would be, the calling process waits for a callback message in a Receive or Pick activity, reporting that the human task has completed (successfully or otherwise) and returning result data. But unlike normal services, which appear to the process as stateless “black boxes” described only by their WSDL interfaces, human tasks are complex state machines (e.g. ready, claimed, completed, failed) governed by performer assignment and escalation rules that are conceptually part of the “process logic” but have no home in BPEL. For that reason, BPMSs today typically provide a task management service – a single service endpoint ant portType for all human tasks – plus a web application, typically called a Worklist, through which participants view, claim, and perform their assigned tasks. The process Invoke creates a task in the task management service, which performs task assignment and state management based on calls from the Worklist, process-defined deadlines and escalation logic, and other Invoke parameters. When the task is complete (or failed), the task management service calls back the process with the results. В меру способностей перевожу: когда дело доходит до шага процесса, выполняемого людьми, движок BPEL шлет WS-вызов отдельной софтине, отвечающей за назначение задания пользователю и за его исполнение. Вызов просто ставит задание в очередь, управление сразу же возвращается в движок BPEL, тот переходит к следующему шагу и на нем засыпает в ожидании прихода обратного вызова WS. То есть: каждый раз, когда что-то должен сделать не робот, а человек, на диаграмме BPEL рисуются два квадратика . Один вызывает внешний сервис, который будет иметь дело с человеком, второй ждет прихода обратного сообщения. Не знаю как вы, но я, если много раз приходится рисовать по два квадратика там, где по смыслу должен быть один, обычно начинаю испытывать рвотные позывы :Q Кому-то может показаться, что я полагаюсь на мнение одного автора. На самом деле это не так. Во-первых, похожие криические высказывания по поводу BPEL встречал неоднократно у разных аналитиков; во-вторых, они перекликаются с моими собственными мыслями. (Это еще не конец. Продолжение следует...) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 17:03 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Итак, что мы имеем в сухом остатке у BPEL-ориентированной системе? Две компоненты: system-to-system (собственно движок BPEL), вызывающая human-to-human (менеджер "человеческих" заданий). Посмотрим теперь как (в самом общем виде) обстоит дело в human-to-human BPM-системах. Тут движок умеет менеджировать человеческие задания и вызывать вебсервисы. Поскольку BPEL-процесс выглядит для внешнего мира как вебсервис (это то что мне нравится в BPEL), он с таким же успехом может вызвать system-to-system подпроцесс. Казалось бы, все симметрично: что этот вызывает того, что наоборот. Но у меня есть 3 аргумента в пользу второй схемы: 1) В тех бизнес-процессах, с которыми мне приходилось иметь дело, "человеческие" шаги составляют подавляющее большинство (навскидку -- не менее 80%). Поэтому неправильно делать их "гражданами второго сорта". 2) Человек -- это "самая универсальная программа". В контексте бизнес-процесса человек всегда может заменить программу и только иногда программа может заменить человека. Вы всегда можете ввести в бизнес-процесс "человеческий" шаг, в котором только и будет инструкция "введи такие-то данные в такую-то программу, после этого нажми ОК". 3) "Человеческие" шаги всегда продолжительные, "системные" почти всегда короткие. Поэтому если "человеческий" движок вызывает системные сервисы, то он, в большинстве случаев, может не заморачиваться с асинхронностью, и вам не придется везде и всюду рисовать два квадратика вместо одного. (Продолжение следует.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 17:59 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
"Аффтар -- ты чо, самый умный? Все за BPEL, а ты против?" Во первых, я не против. Я просто считаю, что его место -- пониже human workflow. Во-вторых, я слишком хорошо понимаю почему "все за", и поэтому не склонен за ними следовать. Как известно, BPM -- это одновременно и управленческая методология, и софт. BPM также грозится "стереть грань между ИТ и бизнесом". Соответственно, BPM можно реализовывать либо сверху-вниз (идя от бизнеса), либо снизу-вверху (идя от ИТ). Теоретически правильно идти от бизнеса, тогда вы будете сфокусированы на ценностях, а не на затратах. На практике до бизнеса все доходит туго, и проводником идей BPM становится ИТ. А на его менталитете сказывается длительное общение с софтом, люди для ИТ-шников -- это пользователи. ("Не люблю живых" (c) патологоанатом из "Людей в черном".) Поэтому они склонны брать программы, какие есть, и цеплать к ним людей. Вендоры, в большинстве случаев имея налаженные контакты с ИТ, а не с бизнесом, этому потакают. К тому же и для вендоров, и для ИТ привычно продавать-покупать всякую инфраструктуру и middleware. BPEL туда хорошо вписывается, вот в результате и получается, что BPM в представлении многих сводится к BPEL. из комментариев читателей к той же заметке Брюса СилвераRetro-fitting human elements into BPMS are just another IT legacy that persists when IT mindset prevails. As long as users are always outside the boundary of a system, that is what one would expect. Not everything can be or should be automated. Technologies are just tools that assist human beings to perform work more efficiently. (Продолжение следует. А может получится уже и окончание.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 18:17 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Теперь об альтернативах BPEL. Язык схем бизнес-процессов, в котором предусмотрены средства описания человеческих заданий, есть: XPDL. Если подходить строго, то это не язык описания, а язык обмена, но какая в сущности разница? Главное, схему, нарисованную бизнес-аналитиком в ARIS, можно выгрузить в этом формате и загрузить в BPM-движок. Не во всякий, но серьезные вендоры этот стандарт поддерживают. Как и BPEL, XPDL есть подмножество XML. Надо признать, что такого единообразия, как BPEL в случае system-to-system, в случае human-to-human нет, и некоторые системы реализуют свой собственный формат. Впрочем все они остаются workflow диаграммами и похожи друг на друга. Видел одну -- сразу поймешь что к чему в другой. С другой стороны, как было отмечено выше, стандартность BPEL тоже вещь лукавая: ведь на "ручные" шаги эта стандартность не распространяется, а таковых обычно большинство. Так что взять схему бизнес-процесса из BPM от MS и перенести в IBM фиг получится, хотя и там и там BPEL. (За исключением чисто автоматических бизнес-процессов, которые встречаются не часто.) А с XPDL -- получится. GaryaА можно поинтересоваться, в каком языке описания бизнес-процессов (исполняемых, разымеется) такие средства есть? И если можно, поясните, как Вы себе на практике представляете выполнение иструкций этого языка, описывающих операции, выполняемые людьми. На практике я это себе не представляю, а делаю теми же руками, которыми сейчас это пишу :) В описании бизнес-процесса для определенного шага задано: кто является его исполнителем (визуально, при помощи swimlane), какие атрибуты из контекста бизнес-процесса должны на нем показываться пользователю, какие переходы возможны для данного шага (тоже визуально, именованными стрелками). Дальше возможны два варианта: движок либо сам автоматически генерит веб-форму, либо, если в схеме бизнес-процесса в дополнение к вышеуказанному задан URL веб-приложения, которую для этого шага создал программист, то движок запускает его. Приложение относится к разряду композитных: оно взаимодействует с движком через его API, а кроме того обычно взаимодействует с внешними системами или источниками данных. Некоторые вендоры в комплекте с BPM предлагают RAD-средства для разработки таких композитных приложений. Если позволите, я дальше на словах объяснять не буду, а посоветую интересующимся посмотреть видеоролик на www.bpms.ru Вот вкратце и все, на вопрос Garya я вроде ответил, готов дискутировать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 19:09 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Прежде всего, огромное спасибо за столь обстоятельный ответ. Даже дискутировать после этого как-то неловко... :) Хотя, мне кажется, предполагается даже не дискуссия, а уточнение точек зрения. Наиболее ценную информацию я почерпнул из видеороликов. Поскольку речь идет о возможностях языков описания бизнес-процесса (прежде всего - о них), то, как я понял из просмотренных мной видеороликов, визуальный интерфейс (уровень представления - так IT-шникам более понятно) может быть описан собственно в самом языке только в самом примитивном виде - в виде набора полей, их типов, видимости/невидимости и т.п. Во многих реальных ситуациях (по сути, в большинстве из них) этих возможностей совершенно не достаточно. Чаще всего требуется, чтобы в процессе заполнения полей информацией выводились диагностические сообщения и подсказки, происходило изменение доступности одних полей в зависимости от изменения содержимого других полей, производилась подкачка в комбобоксы различных наборов данных в зависимости от значений, выбранных в других полях... Разумеется, для этого можно сгенерить на полуавтомате заготовку WEB-формы и... погнали ваять на скриптовом языке... Стоп!!! Но мы ведь обсуждаем возможности НЕ СКРИПТОВЫХ языков? А языков описания бизнес-процессов, не так ли? Так какой глубинный смысл заложен в способности в языке описания бизнес-процесса реализовывать куцый кусочек от того, что на самом деле требуется для визуализации, если все равно наверняка придется реализовывать уровень визуального представления совершенно другими средствами? Как поддерживается логическая целостность между полноценной визуализацией и параметрами бизнес-процесса в случае изменения бизнес-процесса (например, в случае удаления одного из его параметров)? Подозреваю, что никак (поправьте меня, если я ошибаюсь). Если это предположение соответствует действительности, то разве по факту не происходит разделения на отдельную разработку собственно бизнес-процесса и визуального интерфейса пользователя? Где те плюсы, которые связаны с возможностью внесения постоянных изменений в ранее настроенную схему? Они, надо полагать, как раз на уровне языка проектирования бизнес-процессов. А вот на уровень визуализации так или иначе гарантированно к этим изменениям сам собой не адаптируется. Его нужно адаптировать "врукопашную" . Я, разумеется, IT-шник. И насквозь пронизался догмой о пользе раздельного проектирования бизнес-логики и визуального представления. :) Я вижу в их разделении больше положительного, нежели отрицательного. Поэтому расставленные мной акценты говорят не о вреде подобного разделения, а о том, что такое разделение просто ЕСТЬ . Даже при использовании языков, ориентированых на Human-To-Human взаимодействие. Мне кажется, было бы неправильным утверждать, что эти языки такое разделение устраняют. Возможно, они делают его менее заметным, но не более того. Запустите InfoPath. Выберите "Файл" -> "Заполнить форму" -> "Запрос на обслуживание" (из категории "Образцы форм"). Попробуйте изменять содержимое поля "Услуга", и понаблюдайте, как изменяются при этом доступные для выбора варианты в поле "Проблема". Реализация, разумеется, на скриптовом языке. Если использовать InfoPath совместно с SharePoint Portal Server и с BizTalk, то идеология работы с ним во многом будет схожа с продемонстрированной в видеоролике. Выберите "Файл" -> "Конструктор форм" - "Настроить образец" -> "Запрос на обслуживание". Поиграйтесь конструктором, чтобы убедиться, какие в нем широкие возможности. Разумеется, там тоже всё базируется на XML - как шаблон сконструированной формы, так и заполненная данными форма - всё это XML. Но InfoPath позволяет работать людям даже БЕЗ ПОРТАЛА! Например, на основе сообщений с XML-вложениями (или InfoPath-вложениями) по "голой" электронной почте. Не знаю, до какой степени этот аргумент может показаться существенным, но, насколько мне известно, не все любят работать с порталами хотя бы потому, что в них нужно проходить авторизацию. Если пришло сообщение по электронной почте, значит почтовый клиент уже прошел авторизацию (на почтовом сервере), и, вполне возможно, что этого уже достаточно. Однако, я не настаиваю... :) Вцелом впечатление от ролика очень положительное. Я обратил внимание на некоторые преимущества Unify по сравнению с BizTalk. Любой участник бизнес-процесса может посмотреть в любой момент в графическом виде схему бизнес-процесса и ту стадию, на выполнении которой он сейчас находится. В BizTalk есть мониторинг, трэкинг и отладка, но доступны эти штуки только администратору. Выполняющиеся процессы нельзя мониторить в графическом виде - только в табличном. Для того, чтобы ориентироваться в табличном представлении выполняющихся процессов, нужно сначала приобрести некоторый опыт. Возможно, это связано и со спецификой данных продуктов... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.04.2006, 23:37 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Посмотрел случаем на bpms.ru пример bpm в действии. Вопрос к адептам: это то что изменит мир? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 00:35 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
поясню. Это все делается непринужденно и не в bpms системах. В чем новизна? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 00:43 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
GaryaПоскольку речь идет о возможностях языков описания бизнес-процесса (прежде всего - о них), то, как я понял из просмотренных мной видеороликов, визуальный интерфейс (уровень представления - так IT-шникам более понятно) может быть описан собственно в самом языке только в самом примитивном виде - в виде набора полей, их типов, видимости/невидимости и т.п. Я кажется понял в чем дело: мы с Вами используем один и тот же термин "взаимодействие с людьми", трактуя его по-разному. Я понимаю под ним те аспекты бизнес-процесса, которые отличают шаги, выполняемые людьми, от выполняемых программами (пользовательские роли, эскалация и делегирование, контрольные сроки и т.д.), Вы "копаете" глубже -- до пользовательского интерфейса. Я (впрочем как и Вы, кажется) не считаю, что на уровне описания бизнес-процесса имеет смысл доходить до логики пользовательского интерфейса. Моделирование бизнес-процесса -- это (по крайней мере в идеале) занятие для бизнес-аналитика. Задать атрибуты и их видимость/обязательность для каждого шага бизнес-процесса -- это максимум того, что можно/имеет смысл от него требовать. GaryaЧаще всего требуется, чтобы в процессе заполнения полей информацией выводились диагностические сообщения и подсказки, происходило изменение доступности одних полей в зависимости от изменения содержимого других полей, производилась подкачка в комбобоксы различных наборов данных в зависимости от значений, выбранных в других полях... Разумеется, для этого можно сгенерить на полуавтомате заготовку WEB-формы и... погнали ваять на скриптовом языке... В рассмотренном демо-примере мы видим две крайности: 1) примитивный интерфейс, использующий только информацию из модели (видимость/обязательность атрибутов, доступные переходы); 2) J2EE-интерфейс со сколь угодно сложной логикой. Такой подход из двух крайностей я встречал и в других продуктах, и мне он кажется разумным. Либо простая функциональность с нулевыми затратами на разработку, либо неограниченная функциональность с ценой... Понятно, что цена этой разработки становится важным, если не решающим фактором. Что толку с молниеносной быстротой менять схему бизнес-процесса, если интерфейсные формы бизнес-процесса потом программисту придется переписывать месяцами?! Осознавая это, вендоры вспоминили о RAD (Rapid Application Development) со всеми его давно наработанными приемами (разработка от событий, визуальное программирование, повторное использование и т.д.) и ввели новый термин -- "композитные приложения", в которых логика бизнес-процесса "легко комбинируется" с данными и логикой унаследованных приложений и источников данных. Особенно если они оформлены в виде вебсервисов, но не обязательно -- базы данных и коннекторы к прикладным системам (JCA) должны подключаться столь же легко. И потом, не будем забывать, что автоматически сгенерированный BPM-системой интерфейс конечно убог, но не настолько чтобы им вообще нельзя было пользоваться. Если дать пользователю выбирать -- работать по-старинке вручную, пока не разработают качественный интерфейс, либо в то время пока его разрабатывают пользоваться примитивным -- он скорее всего выберет второй вариант. К решениям, занимающими промежуточное между этими двумя крайностями положение, я изначально отношусь скептически. Можно легко представить себе описание пользовательского интерфейса на каком-нибудь подмножестве XML, который будет намного перекроет по функциональности автоматические формы шагов бизнес-процесса. Но трудоемкость разработки на нем уже не будет нулевой, как в одной крайности, а с другой стороны, до функциональности полноценного языка типа Java (или, что то же самое :) C##) он все равно не дотянет, а значит, вы всегда будете ожидать от него подлянки в самый неподходящий момент, если не с функциональностью, так с масштабируемостью. Это как с продуктами Microsoft: с ними все идет хорошо только до того момента, пока все не начинает идти очень плохо. 30 тысяч строк в Excell обрабатываются на ура, а 40 тысяч -- никак, и хоть убейся! Разумеется, это всего лишь абстрактные домыслы. К сожалению, я сейчас не готов обсуждать Infopath. Когда-то с ним разбирался, но все забыл. Что ж, есть хороший повод к нему вернуться. Обязательно воспользуюсь Вашими советами и потом поделюсь впечатлением. Либо подкреплю свои абстрактные соображения конкретикой, либо скорректирую свое мнение. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 11:30 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
GaryaЗапустите InfoPath. Запустил. Нашел шаблон, с которым когда-то экспериментировал: "Листок учета рабочего времени". И вспомнил почему я его в свое время "задвинул": в нем нет пункта меню "Опубликовать как веб-страницу". Может плохо искал? Правильно ли я понял: воспользоваться InfoPath, имея на компьютере только браузер, невозможно? Если да, то XForms выглядит более привлекательно. Правда, если MS будет его топить, продвигая InfoPath, то у этой технологии будет трудная судьба. К тому же остается сомнение уже высказанные -- о том, что InfoPath решение половинчатое, и с ним все равно в какой-то момент упрешься в стену. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.04.2006, 18:35 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
АБвспомнил почему я его в свое время "задвинул": в нем нет пункта меню "Опубликовать как веб-страницу". Может плохо искал? Файл -> Конструктор форм -> Настроить образец -> (Выберите какую-нибудь форму) -> (Измените ее состав или функциональность в конструкторе) -> Файл -> Сохранить как -> Опубликовать -> Запускается мастер, который предлагает опубликовать форму: 1) В общей папке на этом компьютере или в сети 2) В библиотеке форм портала SharePoint 3) На web-сервере. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 11:01 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Да-да, но это "типичное не то": тонкого клиента нет и не предвидется. Вам улыбается использовать решение нестандартное, поддерживаемое только одним производителем и вдобавок требующее наличия на клиентской машине MS Office? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 11:13 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
2 АБ Большое спасибо за ответ. GaryaЯ, разумеется, IT-шник. И насквозь пронизался догмой о пользе раздельного проектирования бизнес-логики и визуального представления. :) Я вижу в их разделении больше положительного, нежели отрицательного. Поэтому расставленные мной акценты говорят не о вреде подобного разделения, а о том, что такое разделение просто ЕСТЬ. Даже при использовании языков, ориентированых на Human-To-Human взаимодействие. Мне кажется, было бы неправильным утверждать, что эти языки такое разделение устраняют. Возможно, они делают его менее заметным, но не более того.Мы постоянно говорим о том, что возможность для бизнес-аналитиков самостоятельно проектировать бизнес-логику - это один из наиболее привлекательных жирных плюсов BPM-систем. И при этом можно сразу выполнять процесс. Это то, что надо. А вот говорить о том, что они будут и сами разрабатывать экранные формы - это отпугнет, поскольку требует определенной квалификации, которой аналитик обладать не обязан. Поэтому развести проектирование процесса и визуального представления - это даже не техническая, а, скорее, идеологическая необходимость. GaryaГде те плюсы, которые связаны с возможностью внесения постоянных изменений в ранее настроенную схему? Они, надо полагать, как раз на уровне языка проектирования бизнес-процессов. А вот на уровень визуализации так или иначе гарантированно к этим изменениям сам собой не адаптируется. Его нужно адаптировать "врукопашную".Да, чудес не бывает, даже если это BPMS:) Если в настроенную сжему вносить изменения, то формы придется править ручками. Дело в том, что не в каждой форме задействуются абсолютно все операнды, участвующие в процессе. И как бы мы того ни хотели, определить доступность, способ представления и прочие параметры нам все равно придется. Но есть все же и плюсы. В первом Вас убеждать, я думаю, не надо - это то, что изменяя процесс всегда можно пользоваться некоторое время дефолтными формами, для того, чтобы не останавливать работу. А второй плюс - это то, что имея RAD-средства разработки композитных приложений создание новой формы - это вопрос не дней, а часов (иногда и получасов). Понятно, что дефолтные формы не позволяют в полной мере реализовать все "хотелки" проесса - обращений к базам данных, к другим приложениям. Однако, это все же лучше, чем ничего. iscrafmПосмотрел случаем на bpms.ru пример bpm в действии. Вопрос к адептам: это то что изменит мир?Смотря о чем Вы. Мир изменит сама концепция. Посчитайте, сколько по времени занимают все ролики? А теперь честно скажите: в Вашей системе (или другой, которую Вы можете назвать) за такое время можно 1) создать схему процесса, 2) написать к ней формзы и прописать связи хотя бы только с базами данных 3) продемонстрировать работающий процесс заказчику? Вы беретесь проделать весь этот цикл в рамках одной презентации? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 11:16 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
WJСмотря о чем Вы. Мир изменит сама концепция. Посчитайте, сколько по времени занимают все ролики? А теперь честно скажите: в Вашей системе (или другой, которую Вы можете назвать) за такое время можно 1) создать схему процесса, 2) написать к ней формзы и прописать связи хотя бы только с базами данных 3) продемонстрировать работающий процесс заказчику? Вы беретесь проделать весь этот цикл в рамках одной презентации? Именно поэтому и спрашивал. Да, можно. Только формы конечно не такие обделенные получаются. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 12:04 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
2 iscrafm Ну так что же Вам мешает сделать аналогичные ролики и разместить их в доступном месте? Думаю, что такая презентация займет достойное место на bpms.ru ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 12:09 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
WJ2 iscrafm Ну так что же Вам мешает сделать аналогичные ролики и разместить их в доступном месте? Думаю, что такая презентация займет достойное место на bpms.ru В том то и дело, не вижу связью именно с bpms. Таким образом к bpms все что угодно можно отнести. Вот пример. Создание связанных форм . Отличается отсутствием диаграммы процесса. Для просмотра нужен Webex плейер (1.3МБ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 12:26 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
АБДа-да, но это "типичное не то": тонкого клиента нет и не предвидется. Вам улыбается использовать решение нестандартное, поддерживаемое только одним производителем и вдобавок требующее наличия на клиентской машине MS Office?Ну, улыбаться - не улыбается. Но к этому факту, по крайней мере, я отношусь двольно терпимо. Как-то не приходилось еще видеть людей, которые бы прислыли информацию своим партнерам в формате MS Word или MS Excel, и при этом встречались бы с недоуменным вопросом "Что это вы мне такое прислали? И чем это открывать?". Жизнь есть жизнь. MS Office, положа руку на сердце, имеется практически у всех. Ну или почти у всех. По крайней мере, для взаимодействия сотрудников собственного предприятия и его близких партнеров я полагаю это средство вполне приемлемым. Другое дело - это разработка WEB-форм для потенциальных клиентов, создание портала общего доступа, интернет-магазина и т.п. Размещать на таких ресурсах WEB-формы, требующие наличия установленного MS Office, разумеется, не корректно. В этом плане Unify выглядит более выигрышно. Но поскольку конкретно для нас в этом большой проблемы нет, я отношусь к ней с юмором... :) Хотя, в некоторых смежных вопросах MS ведет себя, как мне кажется, некорректно. Например, InfoPath проверяет, установлен ли MS Outlook из состава MS Office, и если нет, то все возможности обмена InfoPath информацией по электронной почте становятся просто недоступными. А нам не нравится Outlook, мы пользуемся The Bat! Зачем же так насиловать всех своими продуктами? Мне очень нравится BizTalk и InfoPath, но, возможно, его привязка к Outlook и окажется той последней каплей, по которой мы выберем другой продукт. isfarmВот примерЧто-то у меня не получилось этот пример посмотреть. Смотрелка "знает" только расширения WOT. Если переименовать WRF-файл в WOT-файл, то в нем кроме "голубого экрана" ничего не видно. :) isfarmОтличается отсутствием диаграммы процессаСкажите честно - это отличие в лучшую или в худшую сторону? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 14:56 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Garya isfarmВот примерЧто-то у меня не получилось этот пример посмотреть. Смотрелка "знает" только расширения WOT. Если переименовать WRF-файл в WOT-файл, то в нем кроме "голубого экрана" ничего не видно. :) Сорри, не тот проигрыватель. Тот . Разрешение ролика 1400*1050, делался по случаю, не для демонстрации, а для ответа на вопросы пользователей. Здесь есть еще , если 5МБ не лень качать. isfarmОтличается отсутствием диаграммы процесса GaryaСкажите честно - это отличие в лучшую или в худшую сторону? Честно,... просто отсутствие. Возможно наличие диаграммы в этом примере было бы полезным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 15:14 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
GaryaMS Office, положа руку на сердце, имеется практически у всех. Ну или почти у всех. По крайней мере, для взаимодействия сотрудников собственного предприятия и его близких партнеров я полагаю это средство вполне приемлемым. Требовать, чтобы у бизнес-партнера был установлен InfoPath, да еще, поди, той же версии что и у вас?! А как быть с мобильными пользователями -- продавцами, инженерами, консультантами? Вот сидит он на площадке у клиента, дали ему комп с инетом, а он вместо "спасибо" требует InfoPath. Не слишком ли? Или топ-менеджер, который желает работать через смартфон? Я понимаю: есть бизнес-процессы, которые не выходят за рамки предприятия, где теоретически можно было бы сказать "у всех будет InfoPath, иневолнует" :) Но, во-первых, начиная работать с бизнес-процессом, никогда не знаешь куда это тебя заведет. Планировали внутренний бизнес-процесс, а через некоторое время хозяева решили перейти на аутсорсинг -- и давай, быстро-быстро делай его кооперативным. Или прикупил холдинг новое предприятие и надо его включать в бизнес-процесс, причем хотелось бы сделать это не дожидаясь пока будет интегрирована его инфраструктура. Да он может вообще Маки использует! Во-вторых, платформу BPM ведь выбирают не для одного бизнес-процесса, а для всех, значит надо рассчитывать на тяжелый случай. В-третьих, апгрейды софта на клиентских компьютерах любите делать? Нет, современное корпоративное приложение и тонкий клиент -- это синонимы. А если уж Вам так нравится идеология InfoPath (хотя у меня и в этой части есть возражения, которые я уже изложил), то есть XForms, который идеологически есть то же самое, но исполняется прямо в браузере, стандартен (W3 Recommendation), поддерживается IBM, Sun, Oracle, SAP и еще многими, за исключением Microsoft. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 15:26 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
Когда говорят "требуется только браузер" скромно умалчивается, что его еще нужно напичкать всякими расширениями, типа JInitiator, FormsPlayer, X-Smiles, FormFaces и т.д. и т.п. Вопрос, чем инсталляция скрытых приблуд в браузер отличается от установки нового приложения? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 16:00 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
iscrafmКогда говорят "требуется только браузер" скромно умалчивается, что его еще нужно напичкать всякими расширениями, типа JInitiator, FormsPlayer, X-Smiles, FormFaces и т.д. и т.п. Вопрос, чем инсталляция скрытых приблуд в браузер отличается от установки нового приложения? Вот не надо! Для AJAX и подобных ему технологий достаточно Javascript, т.е. годится любой более-менее современный браузер, без плагинов или модулей. Что касается XForms, то да, он браузерами "из коробки" не поддерживается, спасибо M$. (Пока одна только Mozilla модуль XForms выпустила.) Что касается FormFaces, то это просто-напросто один файл на Javascript, и тут тоже не нужны плагины. Есть разница с InfoPath? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 16:16 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
АБВот не надо! Ок, не буду :) А JVM в зачет не идет? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 16:51 |
|
||
|
Как в исполняемых языках описания бизнес-процессов описывается взаимодействие с людьми?
|
|||
|---|---|---|---|
|
#18+
iscrafmОк, не буду :) Вот так с Вами всегда :) говорите "не буду", а сами продолжаете: iscrafmА JVM в зачет не идет? Ее там нет. (Имеется в виду AJAX и FormFaces.) Еще вопросы? Истинный тонкий клиент = браузер без java, плагинов или загружаемых модулей на стороне клиента. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.04.2006, 17:00 |
|
||
|
|

start [/forum/topic.php?fid=29&msg=33689022&tid=1528088]: |
0ms |
get settings: |
9ms |
get forum list: |
18ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
45ms |
get topic data: |
8ms |
get forum data: |
2ms |
get page messages: |
63ms |
get tp. blocked users: |
1ms |
| others: | 250ms |
| total: | 402ms |

| 0 / 0 |
