Я примерно представляю основные возможности BPMS систем. Мой вопрос был не про то что они могут. Мой вопрос был про то когда их целесообразно применять.
Статья по ссылке не даёт никакой информации на эту тему, к сожалению.
«Важно сделать любую схему доступным для максимального числа людей, в том числе – с умственными ограничениями, использующих специальное ПО и технологии для просмотра веб-сайтов.»
Хотелось бы узнать больше про проектирование схем информационной архитектуры для людей с умственными ограничениями :)
Или я неправильно интерпретирую?
По поводу:
«Каждый описанный бизнес-процесс должен визуально транслировать естественность, уверенность, позитивный и открытый настрой. „
Можно привести примеры описаний бизнес-процессов транслирующих всё вышеописанное?
Интересный комментарий. Была бы карма, поставил бы плюс
Но всё таки это, немного, видение ситуации со стороны программиста. Положительный эффект для организации от внедрения BPMS может достигаться несмотря на весь негатив от ИТ. Только сформулировать его для себя я пока не могу.
Автоматизация основных бизнес-процессов? Не лучше в ERP это сразу делать. Настраиваемые бизнес-процессы сейчас даже в 1С есть.
Автоматизация неосновной деятельности? Здесь есть СЭДО, всевозможные issue-tracker’ы. Тоже все с воркфлоу.
Интеграционная платформа? Тут тоже явно есть более зрелые кандидаты. BizTalk, например. Тоже с оркестрацией.
При этом рынок BPMS вроде растёт, какие-то внедрения идут.
Что это? Чистый гербалайф?
Хотелось бы услышать от автора статьи его мнение, какой он идеальный для клиента кейс внедрения BPMS?
Мне кажется, некорректно делать вводное описание систем BPMS ясно не позиционировав их относительно других типов систем, где широко используется такие понятия как workflow или бизнес-процесс. В первую очередь от систем документооборота\ECM, ERP и всевозможных issue-tracker'ов.
А то человек не в теме решит либо: «А у нас уже есть BPMS. СЭОДО 10 лет как внедрили», либо наоборот захочет проблемы подходящие, скажем для JIRA, решать через BPMS.
Мне кажется проблема не в том, что нарисовано на кнопке, а в том, что кнопку сложно найти визуально среди остальных.
Когда двери закрываются, мне проще подставить ногу, чем искать правильную кнопку на панели (хотя такая кнопка в лифте есть и я ей пользовался). Но запомнить где точно она находится не могу никак.
Для операции «не закрывать» лучше подошла бы стандартная аварийная кнопка «красный гриб», как на станках и прочем пром. оборудовании. Она хорошо видна. А вот кнопку «Да поехали уже» можно и не выделять особо. Когда ей пользуешься спешки особой нет.
:)
Не бывает 100% математически доказанных и практически применимых методов, чтобы защититься от того же террориста.
Думаю, на практике используется много маленьких «ловушек», каждая из которых достаточно тривиальна и легко обходится подготовленным человеком. Но их число и скрытность, приводят к тому что среднестатистический злоумышленник с достаточно высокой вероятностью что-то не учтёт.
Те же рамки — да они в основном имеют психологический эффект. Но в нескольких известных терактах, рамки сработали своеобразным образом. Террорист при виде рамки начинал нервничать и взрывался ДО рамки.
Думаю, тогда на горизонте в несколько лет ни у одной из этих программ нет шансов. Их задавят сотовые операторы с технологией RCS. Сотовые операторы — сейчас самые обиженные в ситуации бума мессенджеров и они умеют договариваться между собой о стандартах :)
По крайней мере, пострадают мессенджеры использующие номер телефона для адресации.
То что цифры растут — это, конечно, занимательно. Но пока, к сожалению, всё это напоминает СМС-сервисы 90х когда абонент сотового оператора, мог послать СМС только другому абоненту этого же сотового оператора.
Радикально что-то изменится в индустрии, если пользователь, скажем, WeChat сможет общаться с пользователем, скажем, WhatsApp и, при необходимости, с владельцем простой звонилки, которая понимает только СМС. Вот тогда бы обмен сообщениями перешёл в новое качество.
Отговаривать вас ввязываться в такой прожект, с учётом того, что вы свой движок уже сделали, думаю, поздно.
На данном этапе, можно только пожелать вам поскорее дойти до внедрений у реальных клиентов. С вашей энергией, есть вероятность, что вам удастся собрать единомышленников и даже что-то заработать на такой системе.
В любом случае, это будет интересный профессиональный опыт.
.В дангм случае бесплатная, кросплатформенная и простая. Что кстати не тносится ни к одному продукту названому вами выше
За БОСС не скажу, но исходники открыты. Nexus — бесплатная и простая, Compiere — бесплатная, не очень простая, но зато полная ERP.
.Предметную область понимает клиент — то есть бухгалтер. Зачем разрабу знать какие надо проводки — ему надо знать какой функцией их выполнить..
:) с таким видением предметной области увлечь других разработчиков, работать на новом движке будет проблематично. Их бы скорее увлекла идея пойти за человеком, который понял что-то важное про учёт, чего другие ещё не поняли. Все и так умеют написать функцию, которая делает проводки. Новый движок, единственным преимуществом которого является простота, но который надо изучать и с непонятными наперёд «особенностями» никому не нужен.
Сколько раз слышал уже размышления и даже про реальные продукты на эту тему :)
Вот например . А ещё есть Compiere, БОСС-Компания, Nexus и многие другие продукты с открытыми исходниками.
Ну вот написали вы такой движок, а что дальше то?
Сильно сомневаюсь, что ценность, добавленная этим движком, мотивирует сотни разработчиков забросить свои разработки и сделать на вашем движке бизнес-логику, достаточную для реальных внедрений. Вот если бы движок исполнял родные 1С конфигурации, тогда да :)
Ну и ИМХО ценность подобных систем, не в движке для хранения произвольных документов и не в языке для конфигурирования, а в глубоком понимании разработчиками предметной области.
У нас есть отдельный механизм, который гарантирует, что задание будет убито спустя указанный промежуток времени, и основывается он на системном вызове alarm() и на запрете перехвата сигналов процессом.
А когда вы убиваете процесс, что вы делаете с дочерними процессами, которые мог породить убиваемый процесс? Или в unix'е они самоубьются? Боролся с этим на windows и никакой приличной стратегии не нашёл, кроме как не порождать дочерних процессов из процесса под шедулером :)
к сожалению, чисто математически это нереально см. планарный граф
Статья по ссылке не даёт никакой информации на эту тему, к сожалению.
Хотелось бы узнать больше про проектирование схем информационной архитектуры для людей с умственными ограничениями :)
Или я неправильно интерпретирую?
По поводу:
Можно привести примеры описаний бизнес-процессов транслирующих всё вышеописанное?
Но всё таки это, немного, видение ситуации со стороны программиста. Положительный эффект для организации от внедрения BPMS может достигаться несмотря на весь негатив от ИТ. Только сформулировать его для себя я пока не могу.
Автоматизация основных бизнес-процессов? Не лучше в ERP это сразу делать. Настраиваемые бизнес-процессы сейчас даже в 1С есть.
Автоматизация неосновной деятельности? Здесь есть СЭДО, всевозможные issue-tracker’ы. Тоже все с воркфлоу.
Интеграционная платформа? Тут тоже явно есть более зрелые кандидаты. BizTalk, например. Тоже с оркестрацией.
При этом рынок BPMS вроде растёт, какие-то внедрения идут.
Что это? Чистый гербалайф?
Хотелось бы услышать от автора статьи его мнение, какой он идеальный для клиента кейс внедрения BPMS?
А то человек не в теме решит либо: «А у нас уже есть BPMS. СЭОДО 10 лет как внедрили», либо наоборот захочет проблемы подходящие, скажем для JIRA, решать через BPMS.
Когда двери закрываются, мне проще подставить ногу, чем искать правильную кнопку на панели (хотя такая кнопка в лифте есть и я ей пользовался). Но запомнить где точно она находится не могу никак.
Для операции «не закрывать» лучше подошла бы стандартная аварийная кнопка «красный гриб», как на станках и прочем пром. оборудовании. Она хорошо видна. А вот кнопку «Да поехали уже» можно и не выделять особо. Когда ей пользуешься спешки особой нет.
Не бывает 100% математически доказанных и практически применимых методов, чтобы защититься от того же террориста.
Думаю, на практике используется много маленьких «ловушек», каждая из которых достаточно тривиальна и легко обходится подготовленным человеком. Но их число и скрытность, приводят к тому что среднестатистический злоумышленник с достаточно высокой вероятностью что-то не учтёт.
Те же рамки — да они в основном имеют психологический эффект. Но в нескольких известных терактах, рамки сработали своеобразным образом. Террорист при виде рамки начинал нервничать и взрывался ДО рамки.
По крайней мере, пострадают мессенджеры использующие номер телефона для адресации.
Радикально что-то изменится в индустрии, если пользователь, скажем, WeChat сможет общаться с пользователем, скажем, WhatsApp и, при необходимости, с владельцем простой звонилки, которая понимает только СМС. Вот тогда бы обмен сообщениями перешёл в новое качество.
На данном этапе, можно только пожелать вам поскорее дойти до внедрений у реальных клиентов. С вашей энергией, есть вероятность, что вам удастся собрать единомышленников и даже что-то заработать на такой системе.
В любом случае, это будет интересный профессиональный опыт.
:) с таким видением предметной области увлечь других разработчиков, работать на новом движке будет проблематично. Их бы скорее увлекла идея пойти за человеком, который понял что-то важное про учёт, чего другие ещё не поняли. Все и так умеют написать функцию, которая делает проводки. Новый движок, единственным преимуществом которого является простота, но который надо изучать и с непонятными наперёд «особенностями» никому не нужен.
Вот например . А ещё есть Compiere, БОСС-Компания, Nexus и многие другие продукты с открытыми исходниками.
Ну вот написали вы такой движок, а что дальше то?
Сильно сомневаюсь, что ценность, добавленная этим движком, мотивирует сотни разработчиков забросить свои разработки и сделать на вашем движке бизнес-логику, достаточную для реальных внедрений. Вот если бы движок исполнял родные 1С конфигурации, тогда да :)
Ну и ИМХО ценность подобных систем, не в движке для хранения произвольных документов и не в языке для конфигурирования, а в глубоком понимании разработчиками предметной области.
А когда вы убиваете процесс, что вы делаете с дочерними процессами, которые мог породить убиваемый процесс? Или в unix'е они самоубьются? Боролся с этим на windows и никакой приличной стратегии не нашёл, кроме как не порождать дочерних процессов из процесса под шедулером :)