mad_nazgulИндусы убедительно доказали, что то что накодируют не профессиональные программисты, потом долго и упорно будут разгребать дорогостоящие квалифицированные программисты.
Это в случае, если индусами рулит полный даун.
mad_nazgulТак я и говорю, для МБ 1С - "стандартно".
Для СБ почти, но иногда проскакивают "хотелки".
Вы вроде про облака говорили? Хотя с натяжкой ваш пример можно принять. Но тогда появляется возможность для сравнения. С 1С бизнесу нужно найти бухгалтера, который в 1С шарит, а потом по требованию бухгалтера найти некоего мальчика, который будет всё это поддерживать (минимум обновления и постоянный фикс багов). С процессами интересующийся бизнесмен вполне сможет многое понять без бухгалтера, это раз (хоть про понимание некоторые по прежнему возражают, мол оно им по прежнему не надо), Далее поняв, он почувствует, что кое что может даже подправить, а это уже минус мальчик на поддержку, как минимум. Ну а бизнесы типа "открыл магазин и тупо продаю по одной схеме" постепенно сворачиваются, либо живут весьма скромно и без каких-либо перспектив, поэтому таких не рассматриваем, но думаем именно про интересующихся и способных хоть что-то понимать. Ну а на уровне среднего бизнеса вообще поляна расцветёт, там "проскакивают хотелки" даже в крайне дорогом варианте ручной писанины и поддержки мальчиками с улицы, а уж в экономном - бизнес вполне может расцвести.

КритерийОтборада проходили уже это. в конце 90-х. тот же БЭСТ-4. "каждая домохозяйка может взять и настроить". не полетело.
В конце 90-х ещё даже гугла не было, пень о ста мегагерцах был крутым процессором, а Apple вгоняло в мир PDA Newton с распознаванием рукопсиного текста, этакий огромный, тяжёлый и почти ни на что не способный кирпич в сравнении даже с самым дешёвым и страшным современным смартфоном.

В общем вы живите в своих 90-х, раз вам нравится. Но мы попробуем современный уровень технологий осилить.

ViPRosВсе эти нотации суть языки программирования.
Схема данных в БД - язык программирования? Но тоже нотация.
ViPRosИ как в любом языке - самая сложная часть это механизм компенсации (простейший случай - обработка ошибок, всякие там икзепшны и т.д.).
Дык вот, как только начинаешь рисовать этот механизм в реале, так сразу красивый алгоритмический граф превращается в клубок бабы яги.
В BPMN есть соответствующие средства (Error event, Compensation event, etc). Ну и технические проблемы вообще не рекомендуется в процесс включать, ибо тогда действительно миллион раз повторяющийся клубок будет. А бизнес-проблемы стоит осмыслить, ну и значит нарисовать. Хотя конечно, конкретная нотация и конкретный разработчик накладывают серьёзные ограничения, но в общем случае (BPMN ведь не панацея) можно элегантно развязывать проблемные ситуации и обычное течение дел.

В примере модели данных так же можно найти страшные схемы на лист А0 или несколько таких листов, но это не мешает использовать модели данных. Потому что часто они гораздо меньше, а в сложных случая можно выделить ключевой набор таблиц и работать только с ним. То есть решения есть, было бы желание их искать.

ОзверинКак реализуете , обязательно поделитесь?
Наблюдайте за IT ландшафтом. Он будет серьёзно меняться. Вот тогда всё и увидите.

mad_nazgulОн уже давно поменялся, а вы все еще позапрошлагодний навоз пытаетесь продать
Не так. Многие просто завязли в дерьме мамонта, а потому и не видят изменений.