Комментарии к записи: Расскажите историю

Автор: Anatoly Belychook

Anatoly Belychook — Sat, 03 Oct 2015 16:41:24 +0000

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

Объективности ради, по этому вопросу существуют разные мнения: например, есть нотация S-BPM, которая утверждает прямо противоположное.

Что касается финансового директора, к которому нелегко попасть, то это законный вопрос. Он подробно разбирался тут: http://mainthing.ru/ru/item/403/

Автор: Alexx

Alexx — Wed, 30 Sep 2015 13:54:43 +0000

Может это уже неактуально, но возник такой вопрос: счет подписал член правления, а потом рядовой бухгалтер нашел ошибку и завернул счет.
Вопрос: как вы будете объяснять члену правления, зачем ему нужно еще раз подписывать счет ? Также очень может быть, что к члену правления нет так просто попасть/положить счет на подпись (командировки, совещания) .
Я хочу сказать, что к руководителю должен попасть документ, который проверен и согласован всеми нижестоящими сотрудниками фирмы, которые согласно правил документооборота фирмы работают с данным документом(счетом), а то иногда будет как в анекдоте про поручика Киже.

Автор: Anatoly Belychook

Anatoly Belychook — Fri, 19 Jul 2013 08:53:39 +0000

Еще вдогонку к вопросу о том что является и что не является бизнес-процессом - цитата из ABPMP CBOK:

In the context of business process management, a “business process” is defined as end-to-end work which delivers value to customers. The notion of end-to-end work is critical as it involves all of the work, crossing any functional boundaries, necessary to completely deliver customer value.

Автор: Anatoly Belychook

Anatoly Belychook — Tue, 16 Jul 2013 18:36:20 +0000

Сергей Ладнич>> в каком то из своих постов повествовали о том, что нужно разрывать сплошные процессы с целью оптимизации процесса, например, в узких местах… Думаю первая диаграмма может быть порождена в таких условиях

Совершенно верно, говорил вот здесь - http://mainthing.ru/ru/item/403/. Но я следую правилу: “пока возможно, оставайся в рамках оркестровки”. Переход к межпроцессному взаимодействию должен быть обусловлен какими-то весомыми аргументами. А в данном случае просто “рисовали как видели”, одобрить не могу.

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

Вот как раз пример такого весомого аргумента. Да, в этом случае придется перейти к схеме с нескольми пулами. Но это будут процессные пулы, а не функциональные.

Алексей Громыко>> этот пост очень тесно перекликается с постом “дирижировать или реагировать” ( http://mainthing.ru/ru/item/613/ ) с вытекающими из него выводами о том, когда уместно обойтись оркестровкой, а когда необходимо межпроцессное взаимодействие.

Справедливо. Но та заметка несколько абстрактная, а здесь - конкретная таблетка для конкретного заболевания с четкими симптомами.

dyadyalyonya>> У Репина и Елиферова, например, можно почитать почему “бизнес процесс бухгалтерии” совершенно укладывается в процессный подход

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

Автор: Юля

Юля — Tue, 16 Jul 2013 11:37:56 +0000

dyadyalyonya,
в первом случае вы предлагаете “все в код”, но это не наш метод)
а насчет высокоуровневости первой схемы - это как раз нет. Это вполне себе уровень исполнения. Другой вопрос, что это избыточная “межпроцессность”, я бы так не делала.

Автор: dyadyalyonya

dyadyalyonya — Tue, 16 Jul 2013 10:19:06 +0000

Юля,
вопросы просто отличные!

Моё мнение такое:
по 1-вопросу - это просто лишняя проверка, которая “спрятана” в активности “Утвердить дату оплаты”
по 2-вопросу - эта ветка упущена на 2 схеме, а в 1й схеме, за счёт её высокоуровневости, нельзя определённо сказать - есть она там или нет.

Автор: Юля

Юля — Tue, 16 Jul 2013 09:51:07 +0000

Дмитрий, я думаю, что Анатолий изначально предполагает, что схема будет реализована в BPMS. Иначе мы придем к тому, что она вообще будет распечатана, и никто никаких форм открывать не будет.
А вот по второму предложенному варианту предлагаю решить задачку. Точнее - две.
1. Предположим, что дата оплаты может быть с отсрочкой. Например, счет акцептовали 1-го числа, а дату оплаты назначили на 14-е. И так же с другими счетами. И финикам нужно будет каждый раз, прежде чем назначить дату платежа, как-то проверять, сколько на эту дату платежей уже назначено.
2. И продолжим ту же ситуацию. По мере приближения к 14-му числу количество запланированных платежей приближается к некоторому лимиту. Но может возникнуть ситуация, что лимит уже достигнут, но появился счет, который необходимо оплатить 14-го числа. И в этом случае какой-то из ранее запланированных платежей необходимо будет перенести на более позднюю дату. Первая схема это сделать позволит, а вторая - нет.

Автор: Алексей Громыко

Алексей Громыко — Tue, 16 Jul 2013 09:43:43 +0000

Анатолий, мне кажется, этот пост очень тесно перекликается с постом “дирижировать или реагировать” ( http://mainthing.ru/ru/item/613/ ) с вытекающими из него выводами о том, когда уместно обойтись оркестровкой, а когда необходимо межпроцессное взаимодействие.

Автор: dyadyalyonya

dyadyalyonya — Tue, 16 Jul 2013 09:41:09 +0000

Про DFD:
первая диаграмма - типичная DFD, наличие в ней потоков управления и плавательных дорожек не меняет этого (Калянова можно, например, почитать на тему потоков управления в DFD). И , как вы верно заметили про DFD-диаграммы, она и получилась заметно более высокоуровневой, чем 2-я диаграмма.

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

Смутили, скорее, сделанные в посте обобщения про “бизнес-процесс бухгалтерии” и прочую “процессную перестройку мышления”. У Репина и Елиферова, например, можно почитать почему “бизнес процесс бухгалтерии” совершенно укладывается в процессный подход. Для затравки, нарисованное воркфлоу счёта - может и не являться бизнес-процессом с точки зрения менеджмента корпорации. Например, у такого процесса может не быть единого Владельца,и могут быть не установлены общие KPI. Зато в Бухгалтерии могут быть ясные Владелец и KPI на функции “проверить счёт” и “оплатить счёт”.

Автор: Сергей Ладнич

Сергей Ладнич — Tue, 16 Jul 2013 08:51:25 +0000

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