В методичке к 3-му тренингу написано о кодировании на java script. Там же упоминаются библиотечный функции движка bisagi.
Я думал, что знание нотации (и умение её правильно применять) будет достаточно для составления исполняемых bpmn. А получается, что без программистов все-таки не обойтись?
Вопрос к практикам - как часто приходилось писать программный код? А то, может быть, лучше выучиться на программиста самому!? ;)
-
Опубликовано 11 лет назад #
-
Мечта о визуальном кодировании так и осталась мечто :(
Опубликовано 11 лет назад # -
Павел
Вам стоило прийти на третий тренинг и получить собственный опыт и исчерпывающий ответ на свой вопрос.
Не знаю кто Вам внушил мечту о визуальном кодировании, точно не я. Наличие встроенного языка программирования в BPMS - это благо. Не следует представлять дело так, что раньше все делали программисты, а теперь все будут делать аналитики. Хорошая система - это многослойный пирог; каждый делает свое дело.
Главное, что программистам больше не приходится заполнять белые пятна и догадываться, что же в этом месте ТЗ имел в виду аналитик. Но какие-то вычисления, какая-то автоматизация требуют программирования, и им пусть лучше занимается программист. Системы, в которых языка программирования нет в принципе, серьезно ограничены в своих возможностях; реальные задачи бизнеса с их помощью не решить.
Вопрос конечно в пропорции - сколько именно требуется кода. Если я скажу "мало" - Вас это устроит? Раз не смогли прийти на тренинг - изучите методичку и сделайте собственный вывод.
Опубликовано 11 лет назад # -
Анатолий!
Ведь я заранее предупредил, что не смогу быть на третьем тренинге в "своё расписание". Обязательно приеду на ноябрьский тренинг. У меня накопилось очень много вопросов.
По поводу визуального программирования. Настоящие специалисты-кодировщики становятся дороже год от года. Они и раньше были не по карману, а теперь и подавно. Для примера: за процесс согласования заявки на оплату внедренцы запросили 2 млн. рублей (реализация в 1С). Я совершенно случайно открыл для себя bpms и почему то подумал: вот оно - бесплатный сыр, и теперь я смогу сам собрать (автоматизировать) процесс согласования заявок.
p.s. За методичку - отдельное спасибо. Она "ум в порядок приводит" :)Опубликовано 11 лет назад # -
Павел,
мысль про бесплатный сыр правильная. Только не забывайте про мышеловку :)
Вы не сравнивайте программирование процессов (как это делается в 1С) с программированием интерфейсов (в BPMS).
Что касаемо объемов программирования, то тут правильнее было бы говорить не о кодировании в чистом виде, а о привлечении ИТ-специалистов к разным работам на разных этапах. Из своей практики могу сказать, что первое существенное обращение к программистам - это создание правильной модели данных. На каком-то простом уровне, тем более в BizAgi, это может сделать и аналитик, но, согласитесь, что "беда, коль сапоги начнет тачать пирожник". Серьезная модель данных требует специальных навыков, которыми аналитик может и не обладать.
Дальше - то, что называется "процесс без программирования". BizAgi действительно позволяет самостоятельно, без привлечения программистов, создать вполне рабочие интерфейсы и, в Ваших терминах, "исполняемый BPMN". Навороты появятся позже. И поверьте, начинать вы в любом случае будете с простых процессов, постепенно наращивая сложность. Поэтому: 1 - стоимость разработки (привлечения программистов) будет существенно ниже, поскольку половину работы вы уже сделали сами, и 2 - привлекать программистов вы будете "небольшими порциями" на вполне конкретные работы (например, написать веб-сервис или что-то в этом роде, а не за "один процесс"), т.е. затраты будут распределены во времени, а процесс в это время уже будет работать и, хочется верить, приносить прибыль или пользу. И, наконец, 3 - накопление знаний. Если вы не софтверная компания, и не занимаетесь изысканиями в области программирования, то копать вы будете не долго и не много. Как правило, большинство наработок являются повторно используемыми.
Так что экономить надо, но про мышеловку все же стоит не забывать.Опубликовано 11 лет назад # -
Юлия,
благодарю вас за ответ (и участие в дискуссии).
Увы, теперь я в еще бОльшем раздумье. Не думаю, что вариант, когда один рисует диаграммы и интерфейсы, другой проектирует БД, третий программирует web-интерфесы и т.д. - это есть правильный вариант. Опыт подсказывает, что "подружить" все эти мероприятия (и их участников) - задача не из простых. На мой взгляд проще (и, как часто бывает, в конечном итоге выгоднее по времени и финансам) заказать "весь пирог в одной кондитерской".
Сейчас мне кажется правильным вариант - использовать bpmn для составления аналитических диаграмм и не более того. Жду 3-го тренинга, чтобы окончательно определиться с выводами.Опубликовано 11 лет назад # -
Павел,
в разделении труда есть рациональное зерно, что доказано многолетней историей мирового менеджмента. Профессионализм сложно заменить универсальностью. Правильное слово здесь - "подружить", т.е. заставить работать как целое. Заказать может и проще, но если только речь идет об одном отдельно взятом процессе. Только для того, чтобы научиться самим. Если же целью является построение процессной системы, управление процессами в классическом понимании, то в последствии желательно аналитическую часть работы оставить у себя, отдав на сторону только техническую реализацию (если нет или не достаточно собственных ресурсов).
Думаю (и надеюсь), что третий тренинг позволит Вам правильно оценить масштаб "бедствия"Опубликовано 11 лет назад # -
Мне хотелось бы обратить внимание, что нотация BPMN прямого действия - с помощью нее вы описываете бизнес, программируете людей. В том числе участки, которые не имеют отношения к 1С и к прочим программам или системам автоматизации. Даете эти схемы работникам, которые по должности могут вообще не знать что такое 1С или компьютер - и они спокойно будут выполнять. Мне приходилось описывать сбор переработку и экспорт в европу сложного сельхозсырья со всеми разрешениями и контролем качества - и там (в деревнях) реально использовали схемы на пунктах сбора, но при этом никаких компьютеров не было. Реальная жизнь, производство - это не комплекс офисных зданий с рабочими местами и компьютерами. Это всего лишь МЕНЕДЖМЕНТ. А прелесть нотации именно в том - что она позволяет взаимодействовать ВСЕМ участникам бизнеса, общаясь на одном языке. В частности в моей практике печатались схемы на бумаге - простыни и пересылались наручно, ибо даже факса в некоторых пунтках не было. И прекрасно эти схемы со стрелочками работали!!!!!!!! А попробовали бы вы написать инструкции сплошным текстом - то бедные кладовщики контролеры сортировщики глаза бы сломали! Поверьте, у меня даже цыгане схемы с собой носили, чтобы знать порядок подготовки сырья к сдаче...
КАК ВИДИТЕ - У МЕНЯ БЕЗ ВАШЕГО ПРОГРАММИРОВАНИЯ ПРОЦЕСС ИСПОЛНЯЛСЯ БЕЗУПРЕЧНО)))) И ДАЖЕ БЕЗ КОМПЬЮТЕРОВ) Вы за деревьями не видите леса, извините за прямоту...
Опубликовано 11 лет назад # -
Цитирую neverpoint:
КАК ВИДИТЕ - У МЕНЯ БЕЗ ВАШЕГО ПРОГРАММИРОВАНИЯ ПРОЦЕСС ИСПОЛНЯЛСЯ БЕЗУПРЕЧНО)))) И ДАЖЕ БЕЗ КОМПЬЮТЕРОВ) Вы за деревьями не видите леса, извините за прямоту...Странно было читать с монитора этот ваш текст. Почему вы не попросили цыган разнести текст всем участникам форума?
Опубликовано 11 лет назад # -
Цитирую Pavel-Smirnov:
Странно было читать с монитора этот ваш текст. Почему вы не попросили цыган разнести текст всем участникам форума?Павел,
супер))))))))))))Опубликовано 11 лет назад # -
Цитирую Юлия Вагнер:
Павел,
супер))))))))))))Очень жаль что вы не услышали мой мессадж. Очень много процессов в реальной жизни компании выполняются без компьютеров и схемы помогают ее выполнять естесственно есть и процессы с участием автоматизированных систем, оргтехники. Привел пример с цыганами для наглядности - что не нужно стремиться все автоматизировать и найти некий великий инструмент. Такого никогда не будет слава богу
Опубликовано 11 лет назад # -
Цитирую neverpoint:
Очень жаль что вы не услышали мой мессадж. Очень много процессов в реальной жизни компании выполняются без компьютеров и схемы помогают ее выполнять естесственно есть и процессы с участием автоматизированных систем, оргтехники. Привел пример с цыганами для наглядности - что не нужно стремиться все автоматизировать и найти некий великий инструмент. Такого никогда не будет слава богуВы со своим мессаджем ломитесь в открытую дверь, извините.
Опубликовано 11 лет назад # -
Цитирую Pavel-Smirnov:
Мечта о визуальном кодировании так и осталась мечто :(Прочитал ваш пост про аналитическую диаграмму приемки на склад и порадовался. Вы задумались о регламентации и синхронизации обязанностей складских работников) ведь это одна из задач руководителя. Как видите компьютеры тут не участвуют (именно в вашей описанной ситуации), а польза от диаграммы огромная, выдали всем распечатки новым работкам, заставили проштудировать протестировали и вперед, через сутки они уже в строю. А не это ли вам я говорил, когда писал про цыган? У них были аналитичекие схемы подготовки к сдаче сырья на склад иначе мы не принимали его. Так что ничего смешного я тут не вижу) Юлия видимо не владелец бизнеса и не руководитель поэтому рассматривает BPMN через призму работника, создающего автоматизированные системы. А если судить с позиции руководителя, то диаграммы в первую очередь наводят порядок в бизнесе среди людей. А какой из участков автоматизировать вы решаете сами. В случае со складом наверное единственная автоматизация это контролер отмечает с помощью планшетника в базе прием груза и указывает сразу ячейку складирования, а погрузчик туда уже отвозит, чтобы потом по базе было легко найти в какой ячейке груз
Опубликовано 11 лет назад # -
Цитирую neverpoint:
Как видите компьютеры тут не участвуют (именно в вашей описанной ситуацииКомпьютеры не участвуют сейчас(!). И из-за этого проблемы. Вот разберусь с "как есть", а потом максимально автоматизирую "как должно быть".
Слава роботам, убить всех человеков!!!Опубликовано 11 лет назад # -
Цитирую Pavel-Smirnov:
Компьютеры не участвуют сейчас(!). И из-за этого проблемы. Вот разберусь с "как есть", а потом максимально автоматизирую "как должно быть".
Слава роботам, убить всех человеков!!!В любом случае это процесс не быстрый, тем более если процесс посложнее. К тому же не забывайте про роботов, одна из причин колоссальных убытков Philips в свое время это вложения в автоматизацию производства в махровые годы (не помню уже какие, в инете думаю можно найти, читал об этом когда еще инета не было).
Не всегда полная автоматизация это плюс. В некоторых процессах, странах, в разное время кризисов и т.п. применение ручного труда может быть рентабельнее, чем дорогостоящая автоматизированная линия - а не прибыль ли компании наша цель? Но с точки зрения эстетики автоматизация всего и вся это красиво). Убрать всех дворников и заменить на радиоуправляемые машины санации городских территорий из единого центра управления санации)Опубликовано 11 лет назад # -
Если всё-же кого-то в этой ветке ещё интересует сколько нужно кодировать, что бы получить исполняемый процесс, скажу из своего 4-х летнего опыта работы с Intalio: тут две крайности
1. Так называемый "zero coding", это когда sales manager за 10-15 минут перед потенциальным заказчиком строит что-то типа процесса "заявки на отпуск". Состоящей из 2-х ролей и 3-х форм с 5-ю элементами на каждой.2. Когда заказчик, купившийся на этот сыр вдруг понимает, что его совершенно не устраивает механизм обработки ошибок на форме, так как там кроме валидации по регулярному выражению ничего нет, оказывается нельзя проверить размер файлов перед отправкой на сервер, а некоторые стандартные элементы в FireFox и Internet Explorer работают по разному. Вот тут то на помощь приходит старый добрый JavaScript, на котором пишется 60-80% всей бизнес-логики процесса.
Конечно, Intalio это крайний случай, и уже клинический. В более совершенных BPMS на подобии Oracle BPM с GUI работать одно удовольствие. Но всё же, обработка XML'a пришедшего через Web Service будет происходить через XSLT и XPath. Хоть с лингвистической точки зрения обработка xml это скорее скриптование чем кодирование, но как ни называй, но уж лучше на JavaScript писать чем на XSLT сложный xml рбрабатывать )
А насчёт того что-бы привлекать айтишников порциями, на определённые задачи, постепенно наращивая функциональнось ... Хотел бы я попасть в такой прект!Опубликовано 11 лет назад # -
Цитирую Oleg L.:
Но всё же, обработка XML'a пришедшего через Web Service будет происходить через XSLT и XPath. Хоть с лингвистической точки зрения обработка xml это скорее скриптование чем кодирование, но как ни называй, но уж лучше на JavaScript писать чем на XSLT сложный xml рбрабатывать )Это дело вкуса - я лично от программирования на XSLT получаю удовольствие. Надо только прочувствовать его стиль, и тогда получается очень компактный код.
Но вообще-то обычно можно обойтись без этого, а мышкой определить мапирование между полями XML и атрибутами процесса. Я в нескольких системах такое видел, стандарт практически.
Опубликовано 11 лет назад # -
Цитирую Oleg L.:
Если всё-же кого-то в этой ветке ещё интересует сколько нужно кодировать, что бы получить исполняемый процесс, скажу из своего 4-х летнего опыта работы с Intalio: тут две крайности
1. Так называемый "zero coding", это когда sales manager за 10-15 минут перед потенциальным заказчиком строит что-то типа процесса "заявки на отпуск". Состоящей из 2-х ролей и 3-х форм с 5-ю элементами на каждой.Олег,
если бы идеологи-создатели систем BPMS узнали, что запуск процесса без программирования нужен только сэйлзам для того, чтобы впарить их систему потенциальному заказчику, то они бы горько плакали.
У так называемого "zero coding-а" есть более достойное применение.
Во-первых, именно запуск процессов на исполнение без кодирования позволяет осуществить быстрое прототипирование процессов.
Во-вторых, наличие готовой исполняемой модели позволяет программисту однозначно трактовать содержание каждой формы, не домысливая, что же это может понадобиться на этой форсе.
В-третьих, худо-бедно, но простые с точки зрения юзабилити формы вполне приемлемы на первых порах работы с процессом даже в промышленном варианте. Их наличие позволяет постепенно разрабатывать формы, в то время как процесс уже находится в работе. Это снимает напряженность со сроками. К тому же в процессе эксплуатации могут появиться дополнительные требования или пожелания, которые при прототипировании просто невозможно учесть.Опубликовано 10 лет назад # -
Юлия!
Насчёт идеологов полностью согласен, вот только как говориться "благими намерениями..." С первыми двумя пунктами тоже соглашусь, а вот третий пункт немного смущает. Никому не хочется платить за одно и то же два раза. Тем более что изменения на стадии эксплуатации в несколько раз дороже изменений на стадии разработки. Применения BPMS конечно сокращает этот вредный эффект, но всё же полностью от него не избавиться, риски будут всегда, или чрезмерные затраты на тестирование.
Мы тоже как-то "сняли напряжённость по срокам" за счёт встроенных в BPMS форм, и сейчас имеем проект с двумя UI технологиями. Причём первые, простые формы на встроенной технологии всё разрастаются и разрастаются, открытие самой лёгкой задачи уже давно перевалило за 1,5 Мб. Так что про мобильных пользователей уже можно забыть. А начиналось всё так как вы и говорите "сделаем на простых формах, потом если нужно будет перейдём на более совершенные". Так что принцип "нет ничего более постоянного чем временное" ещё никто не отменял. Конечно, наверняка есть заказчики, готовые оплачивать одно и тоже по нескольку раз, но я бы на это особо не рассчитывал.Опубликовано 10 лет назад # -
Олег,
мы имеем дело с классическим "водопадом"?
Насколько я понимаю, за разработку дефолтных форм заказчик не платит, не так ли? ;-) Тогда почему же два раза?
Не вижу ничего плохого в том, что большинство дефолтных форм прижились и работают. Работают? И пусть работают! Не сломано - не чини! Вот когда вы упретесь в ограничения производительности на каком-то шаге, связанные с недостаточной юзабельностью форм, то тогда и переделывайте.
Ваш пример очень показателен: для айтишников идеальные кастомизированные формы важнее, чем для конечного бизнес-пользователя.Опубликовано 10 лет назад # -
Юлия, в том то и дело, что если бы это был именно классический водопад, то всё было бы проще. Если под дефолтными формами вы понимаете то, что генерируется автоматически из модели данных, то конечно за это заказчик не платит. Я имел в виду интегрированный в BPMS GUI Builder. По поводу айтишников это вы зря обобщаете, те, кто понимают, что от их результативности зависит оплата их труда, работают эффективно, а не эффектно. Проблема с бизнес-пользователем, который до конца не знает чего он хочет, советов не слушает, скрывает информацию или просто играет в бизнес, вместо того, что бы им заниматься.
Вот то, что мы вывели эмпирическим методом.Файлы
-
BPMS_vs_Custom_Development.jpg (32 KB, 3 downloads) 10 лет old
Опубликовано 10 лет назад # -
-
Можно с этим соглашаться, можно нет, но это результат нескольких команд, не только нашей. В какой-то момент разработка на BPMS становится дороже разработки с нуля. Один из последних трендов BPM- iBPMS системы пошли по пути ERP, когда one size fits all. Т.е. либо используете наше видение вашего бизнеса и наши процессы as-is, либо идёте куда подальше. В банковской сфере, в разных странах (кроме Арабских) процессы на 80% совпадают. Но остальные 20% "фишек" каждого банка заставляют переделывать, а не адаптировать шаблонный процесс.
Опубликовано 10 лет назад #
Ответ
Вы должны авторизоваться, чтобы публиковать сообщения.