Вышла RunaWFE Free 4.4.1 — российская система управления бизнес-процессами предприятия

Это не является ТЕОРЕМОЙ. Потому я и пишу, что не надо путать «следовательно» с «импликацией».

Что не является?

Теорема вот: «f непрерывна на отрезке [a, b] и Ф — её любая первообразная на этом отрезке => интеграл от a до b f(x)dx = Ф(b) - Ф(a).». Если логическая гипотеза этой теоремы, то есть «f непрерывна на отрезке [a, b] и Ф — её любая первообразная на этом отрезке» является ложью, то вывод теоремы «интеграл от a до b f(x)dx = Ф(b) - Ф(a).» может быть как истинен так и ложен. И теорема записывается именно импликацией.

Вообще не понял. Это не гипотеза, а условие теоремы. Если условие не выполнено, то данное правило вывода (теорема) не применимо.

«многие теоремы имеют форму условного обозначения : если A, то B. Такая теорема утверждает не истинность B, а только то, что B является необходимым следствием A. В этом случае A называется логической гипотезой теоремы, а B — выводом» (c) учебник.

что логически корректный вывод может быть фактологически неверным и чистая логика ничего с этим поделать не может

Не может. Если получен фактологически неверный вывод из логически корректной теоремы, значит фактологически не выполнена логическая гипотеза теоремы.

Вот то что ты описал скорее относится к ACM. Куча bpms в себя включила этот подход. Судя по их теориям из кучи этих кейсов должны сформироваться несколько бизнес процессов. Что нельзя формализовать останется кейсами. Как это соотносится с теорией вообще и есть ли такое в софтинке из новости это вопрос.

Прибыль фирмы увеличивается? Условия работы становятся комфортнее?

Три раза ха. Попытка автоматизировать БП была. Закончилось всё просто. Покажи строку бюджета что мы можем срезать после внедрения этой программы. Слова что у вас люди сидят по ночам, это не оплачивается, можно сделать то что не успевают сделать, внедрить что-то новое для увеличения прибыли - всё это ушло в никуда. Потом мне отдельно прояснили. То что ты хочешь сделать ведет к распутыванию и деланию прозрачной все структуры работы. Как только это поймут тебя просто сожрут все. Потому что сразу находится строка бюджета для срезания - это фот. А сила начальника в количестве подчиненных. Поэтому произойдут две вещи. При внедрении сократят работников а оставшихся заставят пахать за всех. Тебя сожрут все начальники. Так как ты понизил их значимость, а многих руководителей даже могут уволить в новой прозрачной структуре работ.

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

Поэтому все успешные внедрения БП всегда совмещают внедрение с новыми отчётами/задачами. Или делают не на администрацию, а на всё предприятие. Тогда строка бюджета сразу находится: от расхода топлива (благодаря планированию объединили заявки на транспорт) до расхода материалов (до БП заказывали на каждый цех впрок, потом через пару лет излишки списывали как уже неактуальные).

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

И вот эта фраза показывает что ты мало понимаешь в реалиях управления здесь «Поэтому все успешные внедрения БП всегда совмещают внедрение с новыми отчётами/задачами.» Любое внедрение новой системы всегда требует избыток свободных людей. Просто людей надо: А) научить работать в новой системе, Б) какое-то время заставить работать и по старому и в новой системе В) списать старую систему со всеми вытекающими.

Здесь большинство народа заоптимизировано донельзя. Разговоры в стиле - поработай ночью. А как же санпины, тк? Не, так мы никому не скажем - откуда они узнают? Это практически не шутка а прямой текст.

Их цель - резать косты.

Если дошло до этого, то организации уже ничего не поможет. Разве что выгнать всё управление, нанять кризис-менеджера и молиться.

Любое внедрение новой системы всегда требует избыток свободных людей.

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

Просто людей надо: А) научить работать в новой системе, Б) какое-то время заставить работать и по старому и в новой системе В) списать старую систему со всеми вытекающими.

А) инструкция на отдельное рабочее место на регулярные задачи заучивается за день

Б) не обязательно, можно и прыжком переходить

В) а здесь-то в чём проблема?

На А и Б нужны специалисты-внедренцы. Разово. При наличии старой системы есть ещё проблема переноса данных. Из-за которой списать старую систему вообще не всегда получается.

Здесь большинство народа заоптимизировано донельзя. Разговоры в стиле - поработай ночью.

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

В общем случае, нет.

Ты не понимаешь. Это печально. Попытаюсь ещё раз. В результате куче оптимизаций местные структуры выкинули всё и всех что можно. Оставшиеся работают с 146% загрузкой. Это именно вот так. мало того что они стандартные 8 часов вырабатывают в день. Они сверх того работают 3-5 часов неофициально. За просто так. Возможно в конце года им будет морковка в виде премии.

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

И как ты это сделаешь при перегрузке людей работой? У вас и таких как ты нет реальной морковки для этих людей. Да что там говорить. Вон на скриншотик новости посмотри. Ничего не смущает? Что для показа бп используется то что делает обычный трекер? Где сквозной бп по куче структур фирм? Хоть приём на работу, хоть закупочная деятельность, хоть логистика. Где красивая картинка что покажет преимущества бп? А потом удивляемся непониманию людей и почему большинство этих проектов тихо умирают.

Забыл ещё одно. Основное. Связь с текущими системами в фирме. Что бы в пару тыков мыши достать данные из большинства финансовых или проектных систем и использовать по ходу бп. Вот это по моему мнению основное.

В результате куче оптимизаций местные структуры выкинули всё и всех что можно. Оставшиеся работают с 146% загрузкой.

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

Я же пишу «в общем случае», а не в конкретном примере организации при смерти.

Где сквозной бп по куче структур фирм? Хоть приём на работу, хоть закупочная деятельность, хоть логистика.

А зачем, если они не пересекаются? Просто рядом нарисовать?

Связь с текущими системами в фирме. Что бы в пару тыков мыши достать данные из большинства финансовых или проектных систем и использовать по ходу бп.

Это реализуется, если эти самые финансовые и проектные системы позволяют вытащить из них данные. Или сами бп строятся на основе этих уже используемых систем (в 1С, например, есть, причём лучше, чем RunaWFE).

Это само по себе ненормально.

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

А зачем, если они не пересекаются? Просто рядом нарисовать?

Что не пересекается? Куча отдельных подразделений в одной фирме? Это должно быть странная фирма. Обычно труд одной структуры в фирме поступает на вход другой структуры фирмы. И вот здесь и возникают проблемы. Если у тебя внутри одного отдельчика проблемы то здесь рисовалка бп не поможет. Тут полная Ж в фирме. А вот возьми процесс закупок. Там почти все структуры участвуют в большой фирме. И именно в общении между ними основные проблемы выскакивают. Да тот же прием на работу. От херок на собеседовании до предоставления рабочего места и прав человеку. Вот это сквозной бп который можно покрутить и промоделировать. В результате могут возникнуть вопросы. А что это у нас выхлоп от 10 херок человек в полгода? Может их надо подсократить. А заодно и кадры, которые большей частью балду пинают. А почему у нас один человек отвечает за оснащение рабочего места и его поддержание в нормальном состоянии? Может туда пару херок надо перевести, а то он не справляется. Ну и т.д.

Это реализуется, если эти самые финансовые и проектные системы позволяют вытащить из них данные.

Они все позволяют. Вопрос в коннекторах. Нафиг не нужна система сокращающая труд программиста если вместо 2 кулибиных надо нанять десяток на вылизывание коннекторов. Для примера как это можно делать тыкательно - powerbi. Нет батареек в комплекте - попадалово на неизвестные сроки сращивания с текущими системами. Опять же никому из бизнеса такое не стучало никуда.

Обычно труд одной структуры в фирме поступает на вход другой структуры фирмы.

Вот есть бп приёма на работу: собеседование, отдел кадров, ТБ, выделение рабочего места, учётки в домене, …

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

Что тут из одного бп можно кинуть на вход другого?

Или речь про один бп на несколько подразделений? Так на снимке Инициатор и Разработчик явно из разных подразделений.

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

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

И потерю заявок фиксация задач позволяет предотвратить.

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

Это можно и без бп. Достаточно отчёт о работе за день/неделю вести (в любом виде).

Для примера как это можно делать тыкательно - powerbi.

Угу. Коннекторы в Azure, SQL и Excel. Хотел бы я увидеть как в этом чуде MS’овской мысли, например, остатки по складу из 1С получить. Или из OO.Calc по sftp.

Нет батареек в комплекте - попадалово на неизвестные сроки сращивания с текущими системами.

Для бп отсутствие сращивания сводится к одному лишнему нажатию для пользователя. Например, в бп закупок вместо автоматической проверки по складу будет пункт «убедитесь, что заказываемого материала меньше минимального остатка». И даже при наличии коннектора часто приходится втыкать подобный пункт, так как бывают аналогичные материалы.

Шутка /но может быть в ней что-то разумного и есть/.

Разработать БП для функционирования Linux.

Есть inet - «идешь на право», нет - «на лево» …

Владимир 123

Есть ли что-то подобное на ruby, python, tcl, lisp etc? Нужна визуальная система для описания процессов на предприятии - производство и отдел продаж.

есть на ruby но не очень визуальное: ruote workflow engine (dead, new fork: flor ) бложик

пример1 пример2

надо понимать, что с визуальностью тут не ахти (хотя floristry). у каждой системы свои плюсы и минусы.

если в BPM системах есть стандартизированый язык моделирования BPML и более-менее понятная общая методология (SADT: IDEF0 + IDEF3/DFD -> BPML) и более-менее переносимость наваяных схем между разными BPM системами ибо BPML стандартизирован, то в системах на более прог языке где-то визуальности меньше, где-то плагинов и программируемости (особенно в сторону DSL) больше.

ruote/flor это например такой декларативный DSL на руби для описания workflow бизнес-процессов. который далее может быть где-то запрограммирован плагином, скриптом, где-то накалякан в паинте метапроговом.

тащем-то, вот вам ребятки, параметрический синтез: логики бизнес-процессов из какого-то высокоуровневого описания. от более декларативного до менее декларативного, более конкретного (в конкретные блок-схемы алгоритмов бизнес-логики).

понятное дело, что чем высокоуровнее исполнитель и аморфнее модели данных – тем более декларативно это описание.

никлаус вирт из паскаля сказал: алгоритм + данные = программа.

роберт ковальски из пролога уточнил: управление + логика = алгоритм.

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

а управление можно eval-ом какого-нибудь dsl-я описать, да хоть тем же конечным автоматом dsl.

Есть ли что-то подобное на ruby, python, tcl, lisp etc?

вот на руби что вспомнил. если знает кто это самое etc приведите.

особенно лиспы интересуют. например, есть ощущение что вместо OSGi контейнера + метамоделей в Eclipse можно всё тоже самое на каком-нибудь пиколиспе написать, гораздо проще и легче.

только готового ЕМНИП, ничего нет, в отличие от. так что сабж нужен.

Нужна визуальная система для описания процессов на предприятии - производство и отдел продаж.

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

это требует отдельной работы по «организации», а не только прямого и недвусмысленного указания руководителя?!

опять же, прочитайте что ли хотя бы ту же методичку от бизнес студии про то, откуда эти указания и функциональная схема орг структуры берутся. (хинт: из постановки целей, проработки дерева целей и параметров целей, и организации процессов/плана мероприятий по достижению целей, с учётом рисков и прочего управления. здесь владельцы процессов = функциональные столоначальники для «недвусмысленных указаний». то есть, функциональное должно быть подчинено процессному, а не наоборот – иначе принцип питера во все поля)

а не только прямого и недвусмысленного указания руководителя?!

микроменеджмент такой микроменеджмент

Метапрог это

RunaWFE миллион лет назад

а разгадка одна: его «жгутики с квадратиками» недостаточно декларативны для проработки архитектуры (=модели алгоритмов+данных=логики+управления+данных/метаданных) чтобы сообразить 1) как на этом изобразить что-то полезное (высокоуровнево) 2) в какое (низкоуровневое) оно должно оттранслироваться 3) как именно должна происходить трансляция.

в том же EPC + BPML/блок-схемы/дракон есть какие-то E по которым сшивать можно. ну или точки принятия решения в IDEF3/DFD,WFD.

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

ну да удачи ему.

больше метапрогов хороших и разных :)