Про BPMN-подход к описанию процессов и недостаточную наглядность иных подходов

На прошедшей неделе появилась статья с обзором индивидуального подхода к архитектуре проекта: Свое отношение я выразил по этому комментарию: #comment-8690 Я покритикую с долей эмоций, которые важны именно с материалами, которые хотят выехать на эмоциях, а не сути. Во-первых, «Описание бизнес-процесса» в любой нотации является ОПИСАНИЕМ, а не проектированием. Это важный этап фиксации того, что уже есть в компании. Без него настраивать практически нечего. Во-вторых, отрыв от Планфикса важен именно потому, что бизнес живет независимо от системы управления. Инструментом может быть много, на Планфиксе мир клином не сошелся. Схемы и описания — промежуточный этап между «Давайте наведем порядок» и «Оцените стоимость настройки». Без описания процессов на любой системе будет ступор. В третьих, ваши аналогии между замком и хибарой, а так же пассажи про «Есть спальня на 3-м этаже? Есть!» — это все манипуляции с неподготовленным сознанием. Любой специалист, который может построить более-менее адекватную систему по нормально сформулированным процессам никогда так не ответит. Ровно потому, что его задача помогать бизнесу и работать должно все вместе, а не только в отдельно взятом блоке. По вашему подходу к описанию. Вот та длинная портянка со статусами в разделе «Активные статусы» — это что? Это просто цепочка статусов в одном процессе, что в корне неверно, и особенно на базе Планфикса. Эти статусы ничего не говорят про ролевую модель предприятия, кто кому что и когда передает, и развитие сделки по ЭТАПАМ, а не по статусам, всегда успешное, мы банкротим всех удачно, никто не уйдет раньше. Вы ведете объекты в аналитиках, а не в справочниках и не в задачах, а значит нет никакого развития у объекта, никто не может им оперировать, кроме тех участников задачи, где аналитика была использована. Где же тут гибкость и масштабируемость системы? Единственная полезная вещь, которую несет ваш подход — скучковать все то, что разбросано по Планфиксу в разных местах. Но это нужно только для helicopter view в разных ситуациях принятия решений. В остальных случаях она ничем не поможет ни бизнесу, ни интегратору, никому. Это мое личное мнение на базе более чем 100 интеграций и поддержки десятка аккаунтов. Я рекомендую всем, кто ни разу не сталкивался с этой работой крайне скептически отнестись к материалу. И задать себе несколько вопросов: — Как руководители принимают решения в этой схеме? — Как понять состояние сделок в разрезе планируемых встреч и их итогов? — Какая информация должна и может быть доступна всем сотрудникам, а какая их совсем не касается? — Сколько времени уходит на сделку, как это проверить? — Какие документы сопровождают сделку и кто их готовит и когда? И многое-многое другое, чем живет руководитель отдела/компании каждый день. Степан Чельцов официальный партнер-интегратор «Планфикса» — Кратко: подход автора статьи очень спорен и недостаточно глубоко проработан, таит много рисков с выходом проекта на излишние траты, негибкость и даже вполне реальную проблему достоверности данных.