у меня тоже похожий опыт 13 лет) здесь я бы посоветовал разделять, что именно не понимают стейкхолдеры: технологию, методологию, или назначение отдельных элементов системы внутреннего контроля, поскольку все вместе они и определяют в конечном итоге процесс, но природа этих составляющих разная, а когда процесс "описывают", эти понятия смешиваются и информация о причинных связях теряется, из-за чего задачи могут решаться не очень эффективно
если вы не шутите и не разыгрываете меня, а я не исключаю этого, потому что наверняка может возникнуть соблазн, если видишь что-то совсем непохожее на общепринятое, то, например, в телеграме я lesokolov. Я, правда, не знаю, можно ли здесь делиться контактами, не нарушает ли это правил сообщества. И пока конечно не представляю, чем бы я мог помочь, но пообщаться не против)
в моей практике bpmn использовался на этапе подготовки и согласования BRD
не совсем понятно, как артефакты делятся по уровням. Если мы говорим об информационных элементах, то любой элемент может (в определенном контексте) входить в состав другого. Если мы говорим про моделирование свойств системы артефактами программного комплекса, то наверно там не будет полного совпадения уровней да и особо незачем их сравнивать
конкретика для программиста / дизайнера должна иметь четкое сопоставление с элементами информационной и бизнес-системы, то есть таким образом, чтобы в любой момент можно было получить ответ, какими элементами программы реализуется данная функция бизнен-системы и наоборот, какие элементы системы и ее свойства обеспечивает данный артефакт
например, бизнес-система может включать в себя такие элементы: заказы, платежи, акты, договоры, графики, классификаторы и т.д. Где например, определенный статус платежа будет является основанием для перевода заказа в нужный статус. Или платеж будет являться следствием договора и т.д. Установление причинно-следственной связи между конкретными элементами выполняется с помощью функций. Например, это могут быть правила бухгалтерского учета: для каждого основания в виде договора или платежа или акта должна быть сделана определенная запись.
у меня нет зуба на BPMN) просто я считаю согласование такой категории как "верхнеуровневое описание автоматизированного процесса" некорректным действием, потому что процесс - это следствие свойств системы, но один и тот же по форме процесс при определенным условиях может быть следствием свойств разных систем. Поэтому, логическая ошибка может возникнуть, когда мы перейдем от следствия к основанию, но у этого основания окажутся еще и незапланированные негативные для нас следствия.
вообще, разработчика, аналитика, тестировщика, директора и пользователя будут интересовать совершенно разные аспекты, поэтому для меня странно предоставлять всем этим людям одинаковую информацию
спасибо, негативный опыт отсутствует, завышенных ожиданий тоже не было, потому что я понимал, что с помощью такой нотации можно делать, подготовка тоже есть нормальная) мой подход в том, чтобы в основу проектирования системы брать не процессы (которые в том числе являются следствием применяемой технологии), а свойства бизнес-системы. И не использовать такие понятия как "пользовательская задача".
речь больше не про автомат, то есть не про инструмент, а про то, что ключевым является фиксация и учет логических связей причинности между элементами системы вместо таких неопределенных понятий как "действие" и "поток"
в общем и целом я не выступаю против наглядности, в заметке нет призыва использовать ненаглядные методы, там немного про другое: не как моделировать, а что моделировать
вообще речь шла больше не про недостатки нотации, потому что эти недостатки являются недостатками только в контексте предложенной идеи, а именно про недостатки выбора объекта моделирования
цель не совсем такая, то есть не конкретно BPMN, а цель объяснить, что моделировать нужно не бизнес-процесс, а систему, потому что бизнес-процесс и его характеристики определяются свойствами системы
сначала пара недостатков представленной схемы, которые сразу бросаются в глаза
1. Схема не дает информации, ведется ли в компании контроль статуса заказа покупателя.
2. Схема не гарантирует, что запрос в отдел закупки не будет выполнен, если товар есть в наличии.
3. Также не гарантирует, что запрос будет выполнен, если товара нет в наличии.
4. Схема не дает информации, как связан результат функции резервирования с учетом товара.
таким образом схема не несет самой важной информации для бизнес-процесса, а только дает «детское»объяснение как все работает. Невозможно представить ситуацию, в которой на основании этой схемы можно что-то предложить или изменить или принять какое-то решение.
на самом деле информационная модель бизнес-системы может быть следующая:
информационные элементы / информационные совокупности:
Товар – для учета движения и наличия товара,
соответственно учет движения Товара нужен в разрезе: покупателей, поставщиков
скорее всего понадобится следующее деление товара по категориям: в наличии, резерв, ожидает поставки.
Соответственно условия перехода товара между категориями будут зависеть от соответствующей характеристики сущности Заказ покупателя и Заказ поставщику, а также от их статусов.
Заказ покупателя – учет понадобится в разрезе покупателей, в разрезе менеджеров (для системы мотивации)
Состояния Заказа покупателя: получен, ожидает отгрузки, ожидает поставки, выполнен
Заказ поставщику – в принципе аналогично со своими особенностями, учет в том числе в разрезе поставщиков
Запрос на закупку отличается от упомянутых выше сущностей тем, что она может не быть самостоятельной сущностью. Если Заказ покупателя и Заказ поставщику – сущности для учета параметров взаимодействия с другими бизнес-системами, то Запрос на закупку – это внутренняя опосредованная сущность и может моделироваться через отдельное состояние самого Заказа поставщику. В данном случае, Запрос на закупку выполняет контрольную функцию для обеспечения разделения ответственности между работниками (участниками управляющей системы)
такой контроль моделируется через условие на Заказ на поставщику:
для бумажной технологии: полномочия подписи Заказа поставщику и подписи Заказа покупателя – взаимоисключающие
для электронной технологии (аналогично) функция создания объекта Заказ покупателя и Заказ поставщику взаимоисключающие в разрезе учетной записи пользователя.
Если мы хотим автоматизировать, то:
Функция резервирования: что делает: уменьшает категорию товара в наличии и увеличивает категорию товара зарезервированного на одну и ту же величину, инициирующее событие: переход Заказа покупателя в состояние «принят». Аргумент функции – количественная характеристика элемента Товар в Заказе покупателя
Если мы не хотим автоматизировать, то функция резервирования может быть описана примерно так: должен быть журнал с графами «В наличии», «Зарезервировано». «Заказано поставщику» где каждая новая запись показывает итоговое состояние. причем состояние графы Зарезервировано меняется только с состоянием В наличии. Запись сопровождается номером заказа и т.д.
все изложенное конечно можно изобразить более красиво, аккуратно и точно
основная идея, что переносим фокус с внешних несущественных признаков, таких как действие и последовательность, на логические связи элементов системы (не процесса), при наличии учета логических связей и свойств элементов, можно очень быстро моделировать любые изменения, в том числе автоматизацию. То есть модель должна быть такой, что взяв любой элемент, можно было одномоментно получить все его вхождения в состав сущностей, для какого элемента он является условием, а для какого – следствием и при каких условиях
просто я и есть бизнес-аналитик с приличным стажем) и с обязанностями своими всегда справлялся как минимум не менее успешно, чем другие бизнес-аналитики) оптимизацией бизнес-процессов занимался 10 лет, могу сказать, что собаку съел и не одну, в том числе выступал со стороны заказчика в оптимизационных проектах, где исполнителями были все самые крупные консультанты: макинзи, прайсы, янги, делойты. Знаком со всеми известными методиками, и не только для чайников) это я к тому, что содержание этой настоящей заметки не родилось в одночасье, а формировалось годами из своего и чужого опыта и из методических материалов, все не с бухты барахты, за каждым предложением в черновиках еще по 10 предложений осталось) над этой заметкой я работал недели две чистого времени)
уровень сложности - это различные участки работы банка и лизинговой компании, например, система обработки платежей, система учета договоров, кредитный конвейер, система документооборота и др.
Понятие "действие" очень нечеткое, контекстуальное, и из-за этого неоднозначное, и понятие "последовательность действий" тоже. То есть нет общего базиса, относительно которого мы могли бы классифицировать "действия". Поэтому определение процесса через действия и последовательности несет риск разночтений, неточностей и ошибок при принятии каких-либо решений на основании таких описаний. Предложенное мной определение через состояния лишено таких недостатков.
UML наиболее приближена к тому, что предлагаю я, но я в ней вижу избыточность и опять же логическую ошибку в смешивании физических действий с информационными сущностями. Я не то чтобы критикую, просто хотел объяснить проблематичность всех популярных языков моделирования. К сожалению, за долгие годы работы в сфере "управления бизнес-процессами" и "автоматизации бизнес-процессов" не встретил ни одного примера, который бы говорил в пользу применения этих языков. А предложение, косвенно подразумеваемое в заметке, заключается в том, чтобы изменить предмет моделирования: чтобы не описывать бизнес-процессы, а моделировать систему, свойства которой однозначно определяют процесс. То есть процесс - это вторичное, а мы сразу пытаемся смоделировать это вторичное, минуя его основания.
менеджменту будет понятно, если мы четко скажем какие параметры будут у системы: ее производительность, какими механизмами гарантируется защищенность от ошибок, какие ресурсы нужны для ее сопровождения. При желании эти параметры детализируются
разработчикам по имеющемуся у меня опыту понятны термины объектов, состояний, атрибутов, информационных сущностей и т.д.
у меня тоже похожий опыт 13 лет) здесь я бы посоветовал разделять, что именно не понимают стейкхолдеры: технологию, методологию, или назначение отдельных элементов системы внутреннего контроля, поскольку все вместе они и определяют в конечном итоге процесс, но природа этих составляющих разная, а когда процесс "описывают", эти понятия смешиваются и информация о причинных связях теряется, из-за чего задачи могут решаться не очень эффективно
если вы не шутите и не разыгрываете меня, а я не исключаю этого, потому что наверняка может возникнуть соблазн, если видишь что-то совсем непохожее на общепринятое, то, например, в телеграме я lesokolov. Я, правда, не знаю, можно ли здесь делиться контактами, не нарушает ли это правил сообщества. И пока конечно не представляю, чем бы я мог помочь, но пообщаться не против)
в моей практике bpmn использовался на этапе подготовки и согласования BRD
не совсем понятно, как артефакты делятся по уровням. Если мы говорим об информационных элементах, то любой элемент может (в определенном контексте) входить в состав другого. Если мы говорим про моделирование свойств системы артефактами программного комплекса, то наверно там не будет полного совпадения уровней да и особо незачем их сравнивать
конкретика для программиста / дизайнера должна иметь четкое сопоставление с элементами информационной и бизнес-системы, то есть таким образом, чтобы в любой момент можно было получить ответ, какими элементами программы реализуется данная функция бизнен-системы и наоборот, какие элементы системы и ее свойства обеспечивает данный артефакт
ваш опыт во многом совпадает с моим
например, бизнес-система может включать в себя такие элементы: заказы, платежи, акты, договоры, графики, классификаторы и т.д. Где например, определенный статус платежа будет является основанием для перевода заказа в нужный статус. Или платеж будет являться следствием договора и т.д. Установление причинно-следственной связи между конкретными элементами выполняется с помощью функций. Например, это могут быть правила бухгалтерского учета: для каждого основания в виде договора или платежа или акта должна быть сделана определенная запись.
у меня нет зуба на BPMN) просто я считаю согласование такой категории как "верхнеуровневое описание автоматизированного процесса" некорректным действием, потому что процесс - это следствие свойств системы, но один и тот же по форме процесс при определенным условиях может быть следствием свойств разных систем. Поэтому, логическая ошибка может возникнуть, когда мы перейдем от следствия к основанию, но у этого основания окажутся еще и незапланированные негативные для нас следствия.
вообще, разработчика, аналитика, тестировщика, директора и пользователя будут интересовать совершенно разные аспекты, поэтому для меня странно предоставлять всем этим людям одинаковую информацию
спасибо, негативный опыт отсутствует, завышенных ожиданий тоже не было, потому что я понимал, что с помощью такой нотации можно делать, подготовка тоже есть нормальная) мой подход в том, чтобы в основу проектирования системы брать не процессы (которые в том числе являются следствием применяемой технологии), а свойства бизнес-системы. И не использовать такие понятия как "пользовательская задача".
речь больше не про автомат, то есть не про инструмент, а про то, что ключевым является фиксация и учет логических связей причинности между элементами системы вместо таких неопределенных понятий как "действие" и "поток"
спасибо, все изучено достаточно хорошо, и токены и экземпляры, с этими понятиями я давно знаком)
в общем и целом я не выступаю против наглядности, в заметке нет призыва использовать ненаглядные методы, там немного про другое: не как моделировать, а что моделировать
речь не совсем про нотацию, больше про объект моделирования
вообще речь шла больше не про недостатки нотации, потому что эти недостатки являются недостатками только в контексте предложенной идеи, а именно про недостатки выбора объекта моделирования
цель не совсем такая, то есть не конкретно BPMN, а цель объяснить, что моделировать нужно не бизнес-процесс, а систему, потому что бизнес-процесс и его характеристики определяются свойствами системы
сначала пара недостатков представленной схемы, которые сразу бросаются в глаза
1. Схема не дает информации, ведется ли в компании контроль статуса заказа покупателя.
2. Схема не гарантирует, что запрос в отдел закупки не будет выполнен, если товар есть в наличии.
3. Также не гарантирует, что запрос будет выполнен, если товара нет в наличии.
4. Схема не дает информации, как связан результат функции резервирования с учетом товара.
таким образом схема не несет самой важной информации для бизнес-процесса, а только дает «детское»объяснение как все работает. Невозможно представить ситуацию, в которой на основании этой схемы можно что-то предложить или изменить или принять какое-то решение.
на самом деле информационная модель бизнес-системы может быть следующая:
информационные элементы / информационные совокупности:
Товар – для учета движения и наличия товара,
соответственно учет движения Товара нужен в разрезе: покупателей, поставщиков
скорее всего понадобится следующее деление товара по категориям: в наличии, резерв, ожидает поставки.
Соответственно условия перехода товара между категориями будут зависеть от соответствующей характеристики сущности Заказ покупателя и Заказ поставщику, а также от их статусов.
Заказ покупателя – учет понадобится в разрезе покупателей, в разрезе менеджеров (для системы мотивации)
Состояния Заказа покупателя: получен, ожидает отгрузки, ожидает поставки, выполнен
Заказ поставщику – в принципе аналогично со своими особенностями, учет в том числе в разрезе поставщиков
Запрос на закупку отличается от упомянутых выше сущностей тем, что она может не быть самостоятельной сущностью. Если Заказ покупателя и Заказ поставщику – сущности для учета параметров взаимодействия с другими бизнес-системами, то Запрос на закупку – это внутренняя опосредованная сущность и может моделироваться через отдельное состояние самого Заказа поставщику. В данном случае, Запрос на закупку выполняет контрольную функцию для обеспечения разделения ответственности между работниками (участниками управляющей системы)
такой контроль моделируется через условие на Заказ на поставщику:
для бумажной технологии: полномочия подписи Заказа поставщику и подписи Заказа покупателя – взаимоисключающие
для электронной технологии (аналогично) функция создания объекта Заказ покупателя и Заказ поставщику взаимоисключающие в разрезе учетной записи пользователя.
Если мы хотим автоматизировать, то:
Функция резервирования: что делает: уменьшает категорию товара в наличии и увеличивает категорию товара зарезервированного на одну и ту же величину, инициирующее событие: переход Заказа покупателя в состояние «принят». Аргумент функции – количественная характеристика элемента Товар в Заказе покупателя
Если мы не хотим автоматизировать, то функция резервирования может быть описана примерно так: должен быть журнал с графами «В наличии», «Зарезервировано». «Заказано поставщику» где каждая новая запись показывает итоговое состояние. причем состояние графы Зарезервировано меняется только с состоянием В наличии. Запись сопровождается номером заказа и т.д.
все изложенное конечно можно изобразить более красиво, аккуратно и точно
основная идея, что переносим фокус с внешних несущественных признаков, таких как действие и последовательность, на логические связи элементов системы (не процесса), при наличии учета логических связей и свойств элементов, можно очень быстро моделировать любые изменения, в том числе автоматизацию. То есть модель должна быть такой, что взяв любой элемент, можно было одномоментно получить все его вхождения в состав сущностей, для какого элемента он является условием, а для какого – следствием и при каких условиях
просто я и есть бизнес-аналитик с приличным стажем) и с обязанностями своими всегда справлялся как минимум не менее успешно, чем другие бизнес-аналитики) оптимизацией бизнес-процессов занимался 10 лет, могу сказать, что собаку съел и не одну, в том числе выступал со стороны заказчика в оптимизационных проектах, где исполнителями были все самые крупные консультанты: макинзи, прайсы, янги, делойты. Знаком со всеми известными методиками, и не только для чайников) это я к тому, что содержание этой настоящей заметки не родилось в одночасье, а формировалось годами из своего и чужого опыта и из методических материалов, все не с бухты барахты, за каждым предложением в черновиках еще по 10 предложений осталось) над этой заметкой я работал недели две чистого времени)
уровень сложности - это различные участки работы банка и лизинговой компании, например, система обработки платежей, система учета договоров, кредитный конвейер, система документооборота и др.
да, простой, если не успею в будни, то на выходных сделаю и скину
Понятие "действие" очень нечеткое, контекстуальное, и из-за этого неоднозначное, и понятие "последовательность действий" тоже. То есть нет общего базиса, относительно которого мы могли бы классифицировать "действия". Поэтому определение процесса через действия и последовательности несет риск разночтений, неточностей и ошибок при принятии каких-либо решений на основании таких описаний. Предложенное мной определение через состояния лишено таких недостатков.
UML наиболее приближена к тому, что предлагаю я, но я в ней вижу избыточность и опять же логическую ошибку в смешивании физических действий с информационными сущностями. Я не то чтобы критикую, просто хотел объяснить проблематичность всех популярных языков моделирования. К сожалению, за долгие годы работы в сфере "управления бизнес-процессами" и "автоматизации бизнес-процессов" не встретил ни одного примера, который бы говорил в пользу применения этих языков. А предложение, косвенно подразумеваемое в заметке, заключается в том, чтобы изменить предмет моделирования: чтобы не описывать бизнес-процессы, а моделировать систему, свойства которой однозначно определяют процесс. То есть процесс - это вторичное, а мы сразу пытаемся смоделировать это вторичное, минуя его основания.
менеджменту будет понятно, если мы четко скажем какие параметры будут у системы: ее производительность, какими механизмами гарантируется защищенность от ошибок, какие ресурсы нужны для ее сопровождения. При желании эти параметры детализируются
разработчикам по имеющемуся у меня опыту понятны термины объектов, состояний, атрибутов, информационных сущностей и т.д.