Да, согласен, при 4–5 СА отдельный КА может быть избыточен.
Но если это лид и он начинает обладать экспертизой по всем доменам и формировать архитектурные стандарты и принципы всей компании, то по сути он уже постепенно превращается в корпоративного архитектора — именно поэтому я бы разделял эти роли и зоны ответственности.
А вот идея с ревью со стороны «соседнего» СА мне нравится: второй взгляд, больше контекста между доменами и одновременно снижение зависимости от конкретного человека. Я бы только оставил за КА уровень общих архитектурных решений и вопросов, которые выходят за рамки одного домена.
На самом деле, в статье я изначально хотел сфокусироваться именно на архитектуре процесса: какие системы участвуют, как они интегрируются, что под капотом происходит с заявкой с технической точки зрения. Но сильно увлекся)
Спасибо за подробный разбор! Вы правы в главном: "космос" — это про сложность систем, но не про идеальность процессов. Ваш кейс с "зависшей" ипотекой — классика: скоринг увидел открытый валютный кредит и отфильтровал, хотя по факту его не было. Это не проблема "одного if", это проблема качества данных в БКИ, которые система честно отработала.
По блокировкам — согласен: когда перед кассиром живой клиент, а система говорит "нет", а сотрудник не может ничего сделать — это провал. Но часто это следствие жестких регуляторных требований (115-ФЗ, антифрод), где человеческий фактор сознательно ограничен.
И да, "мы имеем право не объяснять" — это юридическая защита, но клиентский сервис здесь действительно страдает. Моя статья — про то, как устроен процесс. Ваш комментарий — про то, где он ломается. Оба важны.
Да, согласен, при 4–5 СА отдельный КА может быть избыточен.
Но если это лид и он начинает обладать экспертизой по всем доменам и формировать архитектурные стандарты и принципы всей компании, то по сути он уже постепенно превращается в корпоративного архитектора — именно поэтому я бы разделял эти роли и зоны ответственности.
А вот идея с ревью со стороны «соседнего» СА мне нравится: второй взгляд, больше контекста между доменами и одновременно снижение зависимости от конкретного человека. Я бы только оставил за КА уровень общих архитектурных решений и вопросов, которые выходят за рамки одного домена.
И такую практику используют разные компании)
Спасибо, что прочитали статью до конца)
На самом деле, в статье я изначально хотел сфокусироваться именно на архитектуре процесса: какие системы участвуют, как они интегрируются, что под капотом происходит с заявкой с технической точки зрения. Но сильно увлекся)
Надеюсь вы и для себя подчеркнули что-то новое
Спасибо за подробный разбор! Вы правы в главном: "космос" — это про сложность систем, но не про идеальность процессов. Ваш кейс с "зависшей" ипотекой — классика: скоринг увидел открытый валютный кредит и отфильтровал, хотя по факту его не было. Это не проблема "одного if", это проблема качества данных в БКИ, которые система честно отработала.
По блокировкам — согласен: когда перед кассиром живой клиент, а система говорит "нет", а сотрудник не может ничего сделать — это провал. Но часто это следствие жестких регуляторных требований (115-ФЗ, антифрод), где человеческий фактор сознательно ограничен.
И да, "мы имеем право не объяснять" — это юридическая защита, но клиентский сервис здесь действительно страдает. Моя статья — про то, как устроен процесс. Ваш комментарий — про то, где он ломается. Оба важны.