Лично я с интересом читаю такие сборники некоторых конференций/университетов.
Да, много статей пустых, также как и на английском. Но в целом, можно выявлять тренды, изменение популярности ключевых слов, находить ссылки на новейшие работы/исследования/результаты, даже письма авторам писать, т.к. e-mail прилагается.
Win2D это:
— отскок в сторону от MVVM, нет привычного Binding, вся графика code behind
— развитие GDI+ поверх Direct3D (для любителей WinForms очень простой переход)
— ускорение графики раз в 100 в сравнении с MVVM векторной графикой.
Поэтому, если элементов у вас немного, тогда MVVM. Если элементов много или много анимации — Win2D.
Можно мешать MVVM и Win2D, т.к. CanvasXXX (а их сейчас уже четыре) является обычной прямоугольной областью, которая встраивается в визуальное дерево XAML
Понятно, что откаты нужно отдельно прграммировать. Минимально, что можно сделать автоматически, это запустить процесс с прежней точки и попросить пользователей подтвердить свое прежнее решение. И для разбора полетов хранить всю историю изменения переменных.
ошибочный процесс мог поменять что-то вне своих локальных переменных — как это откатить?
Опять же, универсальное решение вряд ли есть. Можно ограничить возможность редактирования переменных, а также хранить историю изменений. Можно реализовать механизм отката транзакций.
«возможность существенного отличия фактических действий от плановых» — что значит «существенного»? Если в процессе стоит ветвление по условию, это уже проект, или еще нет?
Вы наступили на любимую мозоль, начало истории которой можно найти в Древней Греции: Корабль Тесея — парадокс, который можно сформулировать так: «Если все составные части исходного объекта были заменены, остаётся ли объект тем же объектом?»
Ваш пример со строительством коттеджей ровно о том же.
Именно по этой границе происходит борьба автоматизаторов PM и BPM, особенно, если это две независимых команды. По мне так должна быть одна система, в которой гармонично переплетаются PM/BPM/ACM. И далее выясняется, что ИС должна быть тесно интегрирована с ERP & CRM.
«контроль ресурсов» — тут не понял. При выполнении процесса легче легкого контролировать ресурсы. Как и другие показатели.
Рискну ответить за автора: Тут речь о смещении с контроля ресурсов на планирование порядка выполнения набора работ в условиях ограничения ресурсов. Например, для рытья котлована можно взять 1 экскаватор, а можно 5 шт. Система «управления проектами» выстраивает «критический путь», который в условиях имеющихся ресурсов позволяет оценить сроки и стоимость всего проекта.
пользователь вбил адрес в каком-то новом формате, о котором аналитики не подумали. Код свалился с ошибкой, процесс остановился — ждем программиста.
Тут можно было бы сделать блокирвоку, что невалидная заявка не снимается с данного пользователя. Так и болтается в его списке задач. И еще продумать форму ввода адреса, чтобы не вбивали кривые адреса.
… если кому-то интересно — попробую сделать статью
Конечно интересно! Пишите!
Можно выстроить данные ИС-системы по оси PM-BPM. Первые могут быть и с генератором процесса (или браться из шаблонов), который затем вручную корректируются. Идеальная система должна быть где-то посередине, поддерживая обе парадигмы, как встраиваемые в друг-друга фрагменты. Похоже, у вас нечто похожее реализовано. Есть еще крайность Adaptive Case Management, который больше на чат с набором правил похож и накапливанием заполненных переменных.
Думаю, зря вы подстраиваетесь под менеджеров. Например, современная системная инженерия (та что про разработку железа и бетона) — берет из Software Engineering практики пачками и адаптирует их себе во благо. Например, agile методологию.
… постепенно улучшая и, с течением времени, заимствуя решения из Computer Science, можно широко внедрить этот подход в практику
Эта точка зрения понятна и допустима, если бы не 15...20 лет эволюции BPMS. Очень похоже, что не туда эволюционирует.
С течением времени все это должно «рассосаться», текущие проблемы будут решены, технология должна стать широко используемой в бизнесе.
За BPM системами я лет 15 слежу. Даже, все двадцать. Проблема BPMS в том, что разработчики процессного подхода пытаются повторить путь разработчиков информационных систем. Т.е. основателям BPMS нужно было бы изначально изучить Computer Science и уже затем бизнес.
А получилось, что ребята выучились на манагеров и пошли писать свой язык и его интерпретатор. Оделись в солидные костюмы, просят солидные финансы, а по факту их уровень алгоритмического мышления на уровне старшеклассника, и могут автоматизировать лишь не более 5% процессов предприятия, типа учета командировочных расходов, т.е. постфактум мелкий кусочек даже учетных систем. А когда речь заходит о планировании, о развитии предприятия, тут у них полный провал. Далее чеклистов согласования заявок мысль не работает. Поддержка версионности процессов вообще к хаосу ведет. А надо бы не шишки набивать, а детально изучить плюсы и минусы систем управления версиями и систем поддержки коллективной разработки ИС.
По мне так Adaptive Case Management и его совмещение с системами управления контентом, более полезное направления развития BPM в автоматизации постоянно эволюционирующих социальных процессов.
А за поднятую тему и детальный разбор плюс вам в карму и за статью!
Хорошую тему затронули. Больше бы таких статей. Впрочем, может это и не совсем тема хабра.
Было бы еще любопытно посмотреть примеры моделирования на Simit или Modelica.
Клавиши перемещения курсора прямо на буквах — руки не нужно переносить. Можно возразить, что курсором медленно позиционировать. Но учитывая время перемещения рук до мышки, позиционирование курсора и обратно на клавиатуру, перемещение сразу с клавиатуры может быть более быстрым. Ведь если нужно переместить на пять строчек вверх и 30 символов влево достаточно нажать клавиши вверх и влево по одному разу. А можно еще и через слова прыгать! А время нажатия определяет перемещение. Кажется удивительным, но после тренировки точность перемещения за одиночное нажатие клавиши управления курсором достаточно высока.
Да, много статей пустых, также как и на английском. Но в целом, можно выявлять тренды, изменение популярности ключевых слов, находить ссылки на новейшие работы/исследования/результаты, даже письма авторам писать, т.к. e-mail прилагается.
Можно попробовать отобразить фрагменты OpenStreetMap.
1. Нарисовать сетку
2. Нарисовать 10к Polyline полупрозрачных, чтобы лучше были видны сгустки.
По минимуму можно в десяток строк кода уложиться.
— отскок в сторону от MVVM, нет привычного Binding, вся графика code behind
— развитие GDI+ поверх Direct3D (для любителей WinForms очень простой переход)
— ускорение графики раз в 100 в сравнении с MVVM векторной графикой.
Поэтому, если элементов у вас немного, тогда MVVM. Если элементов много или много анимации — Win2D.
Можно мешать MVVM и Win2D, т.к. CanvasXXX (а их сейчас уже четыре) является обычной прямоугольной областью, которая встраивается в визуальное дерево XAML
Сходу могу предположить, что BPMS более социальные, а PLM/PDM более железные.
Опять же, универсальное решение вряд ли есть. Можно ограничить возможность редактирования переменных, а также хранить историю изменений. Можно реализовать механизм отката транзакций.
Ваш пример со строительством коттеджей ровно о том же.
Именно по этой границе происходит борьба автоматизаторов PM и BPM, особенно, если это две независимых команды. По мне так должна быть одна система, в которой гармонично переплетаются PM/BPM/ACM. И далее выясняется, что ИС должна быть тесно интегрирована с ERP & CRM.
Конечно интересно! Пишите!
Можно выстроить данные ИС-системы по оси PM-BPM. Первые могут быть и с генератором процесса (или браться из шаблонов), который затем вручную корректируются. Идеальная система должна быть где-то посередине, поддерживая обе парадигмы, как встраиваемые в друг-друга фрагменты. Похоже, у вас нечто похожее реализовано. Есть еще крайность Adaptive Case Management, который больше на чат с набором правил похож и накапливанием заполненных переменных.
Эта точка зрения понятна и допустима, если бы не 15...20 лет эволюции BPMS. Очень похоже, что не туда эволюционирует.
За BPM системами я лет 15 слежу. Даже, все двадцать. Проблема BPMS в том, что разработчики процессного подхода пытаются повторить путь разработчиков информационных систем. Т.е. основателям BPMS нужно было бы изначально изучить Computer Science и уже затем бизнес.
А получилось, что ребята выучились на манагеров и пошли писать свой язык и его интерпретатор. Оделись в солидные костюмы, просят солидные финансы, а по факту их уровень алгоритмического мышления на уровне старшеклассника, и могут автоматизировать лишь не более 5% процессов предприятия, типа учета командировочных расходов, т.е. постфактум мелкий кусочек даже учетных систем. А когда речь заходит о планировании, о развитии предприятия, тут у них полный провал. Далее чеклистов согласования заявок мысль не работает. Поддержка версионности процессов вообще к хаосу ведет. А надо бы не шишки набивать, а детально изучить плюсы и минусы систем управления версиями и систем поддержки коллективной разработки ИС.
По мне так Adaptive Case Management и его совмещение с системами управления контентом, более полезное направления развития BPM в автоматизации постоянно эволюционирующих социальных процессов.
А за поднятую тему и детальный разбор плюс вам в карму и за статью!
Было бы еще любопытно посмотреть примеры моделирования на Simit или Modelica.