Собираюсь пойти поучиться на бизнес процессы сюда:
http://www.1c.ru/rus/partners/training/uc1/course.jsp?id=156
Месяц назад на это время планировалось тоже обучение только требования висели по 8.1.
Собственно вопрос - много ли отличий в бизнес процессах 8.1 и 8.2? Стоит ли идти зная 8.2 только в общих чертах?

развод. БП в текущем виде - мертворожденная хрень

посмотри на форуме Чистова видео-лекцию.

(1) Соглашусь. "Типовой" БП первый раз появился только в УТ 10.3.6.8. В ней же довольно подробно его посмотрел. Основное ощущение - в 1С сами толком не знают что это и как оно должно работать. Куча не слишком связного кода рассованого по самым разным местам. Необходимость руками дописывать элементарные вещи. Т.е. для нормального функционирования необходимо накрутить вокруг БП кучу инфраструктурных элементов. Хотя картинка карты маршрута в режмие Предприятия смотрится в целом симпатично.

(0) Хрень полная... Гибкости нет, куча нелогичного кода и т.д.

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

(4) Смотря что понимать под гибкостью

Ничем не отличаются, про бизнес-процессы можно почитать в толстой книге aka энциклопедия 1с-ника и поковырять конфигурацию от 1С (на диске итс есть). Ходить на курсы наверное смысла мало, т.к. это такая область в которой нужно сначала самому хоть в чем-то разобраться, а потом идти на курсы.

(3) а не в БП закрытие месяца?

(1) Ты не любишь кошек (бизнес-процессы)? Ты просто не умеешь их готовить.
БП в 8.1 - отличнейшая вещь, но это только каркас. А поводу 8.2 - хз, не видел.

(6) Не знаю как у вас в ларьках, но у нас БП меняются налету несколько раз в день. Это надо постоянно схему в конфигураторе править, которая жесточайшим образом привязана к коду. Короче полное гуано....

(10) а вы думаете, в других системах бизнес процессы можно менять находу несколько раз в день?

несколько раз в день это конечно перебор, но

(3) + 100

(11) боюсь, что такие бизнес-процессы в любой системе будут описываться одним квадратиком "сделать деятельность"

(11) Ну как минимум не в метаданных, а настраивая в данных справочную информацию. Согласитесь это намного приемлимей...

(0):)

(14) а в эске так тоже можно сделать... там есть БП без фиксированной карты...

+(16) И есть куча решенеий, в которых можно настраивать БП без конфигуратора.

(17) это через справочники, РС и прочую городьбу? Так зачем тогда БП?

(16)(17) А кто говорит что это нельзя сделать. Я говорю что механизм БП кривой напрочь, и нахен ни куда не годится.

Я считаю, что основная проблема в том, что идеологически БП не вписаны в систему. Т.е. вроде бы как должна быть цепочка БП -> Задача/Документ -> Проводка, а на деле получается, что такой схемы по факту нет. Основное назначение БП - визуализация процесса. На некоторых переходах могут возникать документы, элементы справочников, запси регистров и т.п., т.е. БП должен быть первичен по отношению к документу. А он получается сбоку.

(19) а без лозунга а ля "windows - must die" можно?
чего конкретно криво и что плохо?
по-моему очень удобный ИНСТРУМЕНТ.
(18) А за чем ПВХ и т.п.?

(20) Такую схему по факту никто не писал, ибо постановка процессинговый подход к управлению - это отдельная трудоемкая задача и навязывать готовое что-то от 1С? нееее, лучше не надо.

+ БП может быть не с боку, но для этого БП конкретной организации нужно сперва смоделировать, потом описать в программе, используя имеющийся инструментарий

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

БП в 8.0 и 8.2 почти не отличаются, так мелкие косяки исправлены... Основными проблеммами БП в 1с является:
1. очень слабая модель адресации задач
2. отсутствие возможности использовать отдельные точки БП как регистратор для регистров
3. отсутствие позможности раздельного завершения паралельных ветвей.

(22) Согласен. Потому и получается, что вроде бы БП в платформе есть и уже довольно давно. Но добавлены они были как "дань моде", а не от реальной в них потребности. Потому и нет до сих пор примером удачного их использования. У меня в одной из задач на основе переписанной УТ они используюся для согласования документов. Очень неудобно, когда нужно добавить согласование для еще одного вида документа, приходится писать МНОГО кода в РАЗНЫХ местах. Хотя там где есть работает вполне себе ничего. И пользователям нравится.

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

(24) 1. по поводу адресации - дык ты ничем не ограничен, можно адресовать задачу при её создании. Но думаю ты в курсе.
2. как ты себе это представляешь?) В качестве регистратора может выступать только документ, и точка. Но ничего не может помешать добавить на карту "точку обработки" и в ней создать ентот пресловутый док.
3. дык это вопрос логики бизнес-процесса. Опять же ничего не мешает передвинуть точку выполнения бп на любой момент.

Одна опытная тетя Маня сможет гораздо больше и дешевле. И еще смену обучит )

(20) дурдом. это уже не 1С.

А меня интересует всего лишь один вопрос - а-ля Арис в 1С все же не получилось, или мы все не умеем это готовить? (Мне в данный момент интересна реализация БП от вендора, а пока за продолжительное время ничего, кроме робкой попытки перевести отчет о регламентных операциях из УПП 1.0 в бизнес процессы. Можно конечно долго спорить - хороша или плоха функциональность БП в платформе, но есть ли на самом деле реальное применение от изготовителя?

БП - штука хорошая, но:

1) это все-таки ни в какой мере не готовое решение, а механизм

2) по моему мнению, БП в основном должны работать не через "визуализацию", а прозрачно, через работу документов, участвующих в этих БП

3) для того, чтобы использовать БП "по уму" - надо конфигурацию изначально делать от них. Натягивать БП на "готовую" конфу тяжко (хотя возможно). Отлаживаются они в таком варианте о-очень тяжко: сообщения "Документ ХХ не проведен, потому, что: Документ ХХ не проведен, потому что: Документ ХХ не проведен" отличаются особой информативностью :)

Но если "преодолеть все трудности" - то получается стройная  система.

P.S. насчет отличий БП в 8.2 не в курсах, но вроде бы особых нет

>А меня интересует всего лишь один вопрос - а-ля Арис в 1С все же не получилось

под этим что имеется ввиду? Мы чего-то формализовали в схемы процессов, запустили и нам автоматом нагенерилась логика в пофигуратор под это дело? Этого нет и врядли будет

(32) НЕ, вопрос быле не в "а-ля Арис в 1С все же не получилось", а в дальше "или мы все не умеем это готовить?" :) А расшифровка вопроса шла в скобках, которые я забыл закрыть... С первым и так все ясно...

>по моему мнению, БП в основном должны работать не через "визуализацию", а прозрачно, через работу документов, участвующих в этих БП

логично, но пока все хреново, есть явный перекос в сторону работу через гуи. Простой пример - открыв карту БП мы знаем актуальную точку БП - она подкрашивается и т.п. На уровне кода - без доп. костылей - нет.

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

(31) Нужно просто один раз понять, что не все задачи решаются через документ -> регистр накопления/регистр сведений. Нужно хоть раз вспомнить плоскую таблицу Екселя, переложить на нее задачу - и сразу часть проблем решится - пусть даже типовая методология от типовой 1С не поддерживает такого - реализовать то можно...

(34)

>> Простой пример - открыв карту БП мы знаем актуальную точку БП - она подкрашивается и т.п. На уровне кода - без доп. костылей - нет.

Дело в том, что в общем случае актуальная точка может быть не одна. Получить актуальные точки можно банальным запросом по невыполненным задачам бизнес-процесса. Соответственно, пройденные этапы - запросом по выполненным задачам.

(34) БП - это механизм, требующий особого подхода. И если он тебе не нравится, значит, либо ты с ним не работал, либо работал неправильно.

>БП - это механизм, требующий особого подхода

какого такого "особого"?

>И если он тебе не нравится, значит, либо ты с ним не работал, либо работал неправильно.

как с ним можно работать "неправильно"? Это не теория относительности. БП генерит таски, которые кому адресуются по РС. С чем тут можно работать "неправильно"?

>Дело в том, что в общем случае актуальная точка может быть не одна. Получить актуальные точки можно банальным запросом по невыполненным задачам бизнес-процесса. Соответственно, пройденные этапы - запросом по выполненным задачам.

это и есть костыли

(36) Соглашусь с (38). И еще - есть ребята, которые все это придумали. Вопрос - где реализация от этих ребят? Или пришли новые и решили, что три строчки внизу конфигуратора - мертворожденное дитя и не пользуются этим?

(34)
> Все предложенные схемы в типовых как раз исходят из работы с гуи.

Дело в том, что "негуевая" часть в БП весьма контекстно-зависима. Бизнес-процессы полностью управляемы из кода, но когда мы стыкуем их с первичными документами - все управление прописывается кодом, привязанным к отработке конкретных ситуаций.

Фактически, БП дает возможность вынести алгоритмы связки разных документов из их модулей. Но все равно алгоритмы останутся контекстнозависимыми.

(35) Не понял, причем тут я и ексель.  ИМХО, задачи, решаемые БП как раз к "ексель-образным" задачам отношения не имеют.

Вот на мой взгляд, пример типичной задачи для БП:
1) веб-заказ. Имеющийся товар зарезервился.
2) ждем оплату в течении установленного срока, нет оплаты - заказ закрылся
3) прошла оплата. Задача контроля у менеджера, отсутствующий товар - в потребность снабженцу
4) весь товар по заказу пришел - задача комплектовщику
5) комплектовщик собрал - задача проверить менеджеру
6) менеджер проверил - надо выписать документы
7) документы выписаны - задача в отдел доставки
8) доставка произведена - БП закрылся

А вот минусы БП вытекают из его же плюсов. Фактически, БП ориентированы на последовательность действий, а не на состояние системы. Из-за этого получается, что любое отклонение от сценария "выбивает" БП. В частности, в моем примере:
а) пришла оплата не полная, а частичная
б) по каким-то соображениям надо вернуть деньги обратно, а сборка заказа начата
в) на складе обнаружился пересорт
г) "заказную" позицию поставщик изъял из прайса, заменив на аналог
д) покуптель договорился на изменение заказа, а заказ уже наполовину собран
е) от поставщика под заказ пришло "не то"
и т.п.

По сути  дела, это не недостатки механизма БП, это недостатки процедурного подхода. Просто без БП - это разруливает человек; а с БП приходится прописывать все такие случаи "кодом".
Мне, например, пришлось менять "процедурный" БП на циклический обход со здоровым таким CASE в зависимости от состояния частей системы, завязанных в процессе.
После такой "замены" - задача решилась намного  быстрее.

(34) все минусы которые ты указал - это просто от непонимания, что нужно реализовывать не прямолинейный БП а сложный со всеми вариантами.

(27) как мне сделать адресацию нескольким группам пользователей? (с условием что группы пользователей нельзя обьеденять), или группа+1пользователь (например группа "Менеджеры" + "Автор заявки")

(41) А в чем проблема отдать программно список, а не гр+по? Или ты не программист?

(42) я подобные схемы реализую через реквизиты задачи, но тогда зачем тогда нужен регистр адресации????

(41) Если вдруг первая часть вопроса  - это мне (судя по тексту) - так я это прекрасно понимаю, но при этом подходе "ветвистость" растет в геометрической прогрессии. Соответственно результат получается сложным и негибким.

Это тупиковый подход.

В своей задаче я начал перекраивать в корне схему, когда картинка БП стала больше 4 листов А4 в распечатке (и при этом еще не решала задачу)- т.е. слишком много стало "веток".
Результат уложился в 1 головной циклический БП и примерно 6 мелких вложенных.
Просто "головной" процесс заключался в периодической проверке состояния разных показателей системы и в зависимости от результатов - запуска тех или иных вложненных БП.

(41.2)
> как мне сделать адресацию нескольким группам пользователей?

Скорее всего, задача поставлена неверно. Вариантов 2: или эти пользователи объединяются по роли в еще одну группу, или эти задачи немного разные, например - исполнение и контроль, а в этом случае - задач должно быть 2.

(41) Дмитрий, адресацию можно задать программно в "ПриСозданииЗадач".

(44) для этого делаются вложеные процессы

(45)(46)

есть группы пользователей

"ВасяПупкин"
"Руководитель"
"Менеджер"
"Куратор"

нужно организовать маршрут
------------
1. "ВасяПупкин" или любой "Менеджер"
2. "Менеджер" или "Куратор"
3. "Руководитель" или "Куратор"

(47)
1. Я и делал вложенные бизнес-процессы, но объединяющим фактором были не какая-то последовательность выполнения операций (процедурный подход), а состояние системы (событийный подход).

Т.е. пример: для принятия заказа в работу надо, чтобы сумма заказа была > 0 и сумма оплаты была >= суммы заказа.

А как сложилась эта ситуация, после каких документов (проведение оплаты через банк или кассу, взаимозачеты, корректировка заказа в "-") - не имеет значения.

При процедурном подходе требуется увязка всех документов, которые могут влиять на состояние в БП, что и придает ему излишнюю "ветвистость".

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

Поясню.

Адресация в БП - есть задание кому-то выполнить действие. Групповая адресация - значит, задание дается группе, но у группы имеется руководитель, который или прямым указанием, или некими "правилами" определяет, кто конкретно в каких случаях должен задачу выполнить. Иначе может сложиться картина "у 7 нянек дитя без глазу". Если задача адресуется разным группам одновременно, которые управляются в данной задаче разными людьми - то получается слабо контролируемая система; Вася решил, что задачу выполнит Петя - а Петя решил, что задачу выполнит Вася. В результате задача не выполнена, и нет единого руководителя, который надает по шапке. Если задача поручена нескольким группам одновременно под контролем, к примеру, верхнего руководства - то, возможно, корректнее организовать дополнительную группу "Группа, решающая задачу ХХ под контролем руководства", включив в нее обе группы. И адресовать задачу именно этой группе.

Бывают и другие варианты: сначала задача адресуется группе А, а по истечению времени Х - невыполненные задачи этого типа переадресуются группе Б.

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

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

(48) Привет Александр.=)