Аналитик внедрения АБС — бесплатный фрагмент

Введение

Почему эта профессия и почему сейчас

Банки массово меняют ядро. Кто-то уходит с зарубежной АБС, кто-то — с самописной системы, которой двадцать лет, кто-то консолидирует десяток разрозненных модулей в одну платформу. Каждый такой проект длится месяцами и требует людей, которые понимают, как банковский учёт ложится на конфигурацию АБС. Этих людей не хватает.

Аналитик внедрения АБС — не то же самое, что бизнес-аналитик «вообще». Это узкая роль на стыке трёх областей: банковский учёт (как формируются проводки, остатки, отчётность), конфигурация конкретной АБС (как это всё настраивается) и проектная дисциплина (обследование, постановки, миграция, тестирование). Войти можно из смежных ролей — системный или бизнес-аналитик, методолог, сотрудник банка из операционного или бухгалтерского блока, разработчик, уставший писать код. Порог входа — не диплом, а способность разобраться в предметке и говорить на одном языке с бизнесом банка и с разработкой вендора.

Спрос держат две силы: волна миграций с легаси-систем и дефицит специалистов с реальным проектным опытом. Зарплаты соответствуют дефициту. Этот гайд — дорожная карта входа: он не заменяет проект, но даёт каркас знаний, с которым на проекте вы не утонете.

Как устроено внедрение АБС

АБС — автоматизированная банковская система, операционное ядро банка. На неё опирается всё: расчётно-кассовое обслуживание, кредиты, депозиты, карты, финансовый мониторинг, отчётность в регулятор. Внедрение АБС — это не «установить программу», а перенести работающий банк на новую платформу без остановки бизнеса.

Типовой жизненный цикл проекта:

1. Обследование. Аналитик собирает у банка, как устроены его процессы и данные: какие продукты, как ведётся учёт, какие интеграции, какая отчётность. Инструмент — анкеты обследования по подсистемам.
2. Концептуальный дизайн и настройка. Решается, как процессы банка лягут на конфигурацию АБС: что настраивается штатно, что требует доработки. Пишутся постановки и технические задания.
3. Миграция данных. Данные из системы-источника переносятся в целевую АБС: клиенты, счета, договоры, остатки, история. Здесь всплывает большинство проблем — грязные данные, дубли, несовпадение справочников.
4. Тестирование. Функциональное, интеграционное, нагрузочное; сверка остатков и отчётности «было — стало».
5. Опытная эксплуатация и переход (cutover). Параллельная работа или резкий перенос, сверка, решение Go / No-Go, ввод в промышленную эксплуатацию с планом отката.
6. Сопровождение. Стабилизация, доработки, закрытие первого операционного и отчётного цикла.

В проекте участвуют руководитель проекта, аналитики, архитектор, разработчики и консультанты вендора, бизнес-подразделения банка, ИТ и сопровождение. Аналитик — связующее звено между бизнесом банка и реализацией.

Роль аналитика на проекте

Аналитик отвечает за то, чтобы бизнес-требования банка превратились в работающую настройку АБС. Конкретно:

• проводит обследование и фиксирует, как банк работает сейчас (AS-IS) и как будет в новой системе (TO-BE);
• пишет постановки на настройку и технические задания на доработки;
• готовит и проверяет маппинг данных для миграции — таблицы соответствия справочников и полей «источник → цель»;
• сопровождает тестирование: пишет сценарии, разбирает расхождения, ведёт диалог с разработкой вендора;
• участвует в сверке остатков и отчётности, в решениях по cutover;
• обучает пользователей банка и пишет инструкции.

Главные артефакты аналитика — заполненные анкеты обследования, постановки, таблицы маппинга, тест-сценарии, протоколы решений. Хороший аналитик отличается от среднего тем, что находит проблему на обследовании, а не на миграции.

Как пользоваться гайдом

Гайд построен вокруг учётного ядра — фундамента любой АБС. Каждая глава разбирает одну подсистему по единому шаблону: зачем это аналитику, как устроено, что выяснить у банка (чек-лист), грабли из практики, рабочие шаблоны и ключевые термины.

Читать можно подряд — главы выстроены в порядке, в котором подсистемы обычно осваивают на проекте. Можно и точечно: перед обследованием конкретной подсистемы откройте её главу, пройдитесь по чек-листу и шаблонам.

Материал вендоро-нейтральный: принципы и логика применимы к любой современной АБС. Конкретные экранные формы и названия настроек у каждого вендора свои — их вы добьёте по документации системы, а понимание того, что и зачем настраивается, даёт этот гайд.

---

Глава 1.1. Пользователи и организационная структура банка

Источник логики — подсистема пользователей и организационной структуры учётного ядра реальной АБС (вендоро-нейтрально). Врезки «Грабли из практики» — с живых проектов внедрения.

Зачем это аналитику

Это первая глава Части 1 «Архитектурный каркас». Каркас — потому что всё остальное в АБС ложится поверх него: клиенты, счета, документы, договоры открываются не в вакууме, а в конкретном подразделении конкретным пользователем. Прежде чем разбираться с продуктами банка, вы разбираетесь с тем, кто и где их ведёт.

У пользователя и подразделения в АБС двойственная природа, и это главный тезис главы. Каждый из них одновременно — субъект системы доступа (кому что разрешено видеть и делать) и объект банковской модели (на кого ссылаются счета, документы и договоры). Пользователь не просто «логинится» — он становится ответственным по счёту и исполнителем по платёжному документу. Подразделение — не просто строчка в штатном расписании, а обязательный реквизит учётных и платёжных объектов и точка привязки к балансовому учёту. Пропустите эту двойственность — и упрётесь в неё на миграции, когда окажется, что уволенного сотрудника нельзя не переносить, потому что на него ссылаются старые проводки.

От того, насколько аккуратно вы снимете оргструктуру и модель пользователей на старте, зависит, встанет ли потом отчётность и разграничение доступа. Эта глава даёт рабочую модель: как устроена иерархия подразделений, как пользователь связан с сотрудником, как операция привязывается к подразделению и балансу, что выяснить у банка и где обычно больно.

Банк как иерархия подразделений

Организационная структура банка в АБС — это дерево. В корне головной офис, ниже филиалы, под ними дополнительные офисы, операционные кассы, обменные пункты, внутренние подразделения. Каждый узел — запись в справочнике подразделений с типом, родителем, кодом и периодом действия.

Три вещи в этом дереве критичны и почти необратимы.

Первое — правило кодирования. Код подразделения обычно строится по принципу «код родителя плюс порядковый номер потомка». Количество символов на каждом уровне иерархии должно быть одинаковым (как правило, один–три), при необходимости номер дополняется нулями слева. Нарушите единообразие — и поедет сортировка, визуализация дерева и часть отчётности, которая разбирает код позиционно. Правило задаётся один раз и до начала ввода данных; переразметить дерево задним числом почти невозможно.

Второе — тип подразделения (дополнительный офис, операционная касса, обменный пункт и так далее). Тип влияет на регуляторную отчётность, поэтому это не справочное украшение, а классификатор, который надо согласовать с бизнесом.

Третье — период действия. После создания подразделения его период обычно изменению не подлежит. Закрытие подразделения (простановка даты окончания) во многих АБС учитывается только в подсистеме управления персоналом — для остальных подсистем закрытый узел продолжает считаться активным. То есть «закрыли офис» в кадрах и «офис перестал быть доступен для операций» — это не одно и то же событие.

При создании и изменении подразделения система обычно вызывает точку расширения с набором параметров узла (код, наименование, родитель, филиал, участник расчётов, период, тип, направление деятельности). Через неё, в частности, заполняется история структуры для кадровой подсистемы. Для вас это сигнал: вокруг оргструктуры может висеть кастомная логика банка, которую тоже надо перенести.

Пользователь системы и его связь с сотрудником

Пользователь регистрируется с уникальным системным логином. Логин обычно формируется из ФИО, после регистрации не меняется и допускает только латинские символы — это важно держать в голове при миграции учёток. Пользователь привязывается к должности и подразделению, оба значения берутся из справочников.

Отдельно — связь пользователя с физическим лицом из клиентского досье. Она нужна, когда сотрудник одновременно является клиентом банка: одно физлицо, две роли. На обследовании уточните, есть ли такие случаи и как связь должна отражаться при переносе.

Ещё один массив в карточке пользователя — основания подписи (доверенности, устав и тому подобное) в разрезе периодов действия. Если основание задано и в карточке пользователя, и в справочнике должностных лиц, приоритет обычно у справочника должностных лиц. Это тонкость, которую легко не заметить, пока подпись не «слетит» на проде.

И главное про пользователя как объект модели: он является реквизитом-ссылкой в счетах (поле ответственного) и в платёжных документах (поле исполнителя). Поэтому удалить пользователя можно только тогда, когда на него нет ни одной ссылки — он не проводил документов, не закреплён за счетами. Любой «живший» в системе сотрудник на миграции тащится за собой.

Роли и полномочия (обзорно)

Доступ пользователя задаётся через группы (роли) — наборы прав, которые ему назначают. Пользователь может входить в несколько групп. При регистрации в системе доступа часто автоматически создаётся индивидуальная группа под конкретного пользователя.

Здесь мы намеренно даём только каркас. Детально разграничение доступа — какие бывают права, как настраивается видимость объектов по двум измерениям (по филиалу и по подразделению), как ограничивается глубина распространения доступа вверх и вниз по дереву — разбирается в Главе 1.6 «Разграничение доступа». Сейчас важно одно: роли и периметр доступа жёстко завязаны на оргструктуру, поэтому дерево подразделений надо собрать раньше, чем настраивать права.

Привязка пользователя и операции к подразделению и балансовому учёту

Подразделение — обязательный реквизит учётных и платёжных объектов. Документ создаётся в подразделении, операция исполняется пользователем этого подразделения, и через подразделение операция связывается с балансовым учётом: на каком наборе лицевых счетов отражается, в чьём балансе филиала видна, как сворачивается в отчётности.

Для вас как аналитика это означает: «карта оргструктуры» — это одновременно карта балансовой привязки. Когда вы фиксируете узел дерева, рядом сразу фиксируете, к какому филиалу и какому балансу он относится. Операции между подразделениями разных балансов — это уже межфилиальные расчёты; их механика (счета межфилиальных расчётов, парные проводки) разбирается обзорно здесь и детально в Главе 1.5 «Межфилиальные расчёты». В этой главе достаточно понимать, что граница балансов проходит по дереву подразделений и что смена подразделения у объекта меняет его балансовую принадлежность.

Замещение и делегирование

Когда сотрудник в отпуске или уволен, его функции переходят к другому. В АБС это обычно решается не «передачей логина», а копированием наборов операций (пользовательских групп) от одного сотрудника к другому — при смене роли или приёме нового человека с аналогичными функциями. Основания подписи при этом ведутся отдельно и с периодами действия: делегирование права подписи — это не то же самое, что делегирование доступа к экранам.

На обследовании разделяйте два вопроса: «кто кого замещает по доступу» (роли и группы) и «кто за кого подписывает» (доверенности и основания подписи). Банк часто отвечает на них одной фразой, а в системе это две разные настройки.

История изменений оргструктуры

Структура банка живёт: офисы открываются, сливаются, переподчиняются, закрываются. Поэтому и подразделения, и связки «пользователь — подразделение — должность», и основания подписи ведутся с историей периодов, а не перезаписью «как есть сейчас».

Практический смысл истории — отчётность и аудит за прошлые даты должны собираться по той структуре, которая действовала тогда, а не по сегодняшней. И отдельная боль — реструктуризация: при слиянии или разделении офисов смена подразделения у пользователя влияет на доступ к уже созданным объектам и на их балансовую привязку. Это требует плана переходного периода, а не одной кнопки «переместить».

Что выяснить у банка (чек-лист)

Рабочий список на обследование. По нему за одну-две встречи снимается каркас оргструктуры и модели пользователей.

• Какова полная иерархия подразделений: головной офис, филиалы, доп.офисы, кассы, обменные пункты, внутренние подразделения? Сколько уровней?
• Каково правило кодирования подразделений: длина кода на каждом уровне, дополнение нулями, максимальная глубина дерева? Кто со стороны банка владелец этого правила?
• Какие типы подразделений реально используются и какие из них влияют на регуляторную отчётность?
• Где проходит граница балансов: какие подразделения ведут отдельный баланс, какие относятся к балансу филиала? Какие узлы — участники расчётов?
• Как формируется системный логин пользователя? Есть ли коллизии при переносе (одинаковые ФИО, нелатинские символы)?
• Есть ли сотрудники, одновременно являющиеся клиентами банка? Как связь пользователя с физлицом досье должна переноситься?
• Как ведутся основания подписи (доверенности, устав): где источник, какие периоды действия, что приоритетнее — карточка пользователя или справочник должностных лиц?
• Сколько в системе-источнике «мёртвых» учёток (уволенные, на которых есть ссылки в документах и счетах)? Переносим всех или только активных?
• Используются ли индивидуальные группы доступа на каждого пользователя? Кто отвечает за их инвентаризацию после миграции?
• Как организовано замещение и делегирование: копирование наборов операций, временные роли, делегирование подписи?
• Планируются ли реструктуризации (слияние, разделение офисов) в период проекта? Кто держит план переходного периода по доступу и балансовой привязке?
• Ведётся ли история изменений оргструктуры и нужна ли отчётность за прошлые даты по исторической структуре?

Грабли из практики

Реальные ситуации с внедрений (обезличено). То, о чём не пишут в документации вендора.

Правило кодирования подразделений нельзя «поправить потом». Длина кода на уровне, дополнение нулями, глубина дерева — всё это задаётся до ввода данных и потом протягивается в сортировку, визуализацию иерархии и позиционный разбор кода в отчётности. Ошибка в количестве символов на уровне — это не косметика, а критический дефект, который всплывает уже на собранной отчётности. Согласуйте правило с бизнесом и ИТ письменно и зафиксируйте владельца.

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

«Редкие» поля подразделения раздувают скоуп. На одном проекте всплыли поля регистрирующего органа, которых не было в исходной постановке: часть полей решили не реализовывать, часть пришлось допиливать. Вывод: на обследовании отдельно пройдитесь по «экзотическим» атрибутам подразделения и регистрирующего органа — именно они потом превращаются в незапланированные доработки.

Уволенных нельзя просто не переносить. Список сотрудников в источнике почти всегда содержит уволенных, на которых ссылаются старые документы и счета. В целевой системе таких пользователей придётся завести (пусть и без доступа), иначе ссылки «повиснут» и проводки потеряют исполнителя. Решите заранее, как маркируете «перенесён ради ссылок, доступ не нужен».

Индивидуальные группы доступа остаются после уборки учёток. Если в банке на каждого пользователя создаётся индивидуальная группа, то после миграции и удаления «мёртвых» записей эти группы в системе остаются — автоматически они не чистятся. Без отдельного регламента инвентаризации вы получите кладбище осиротевших ролей. Заложите задачу на ревизию групп в план сопровождения.

Закрытие подразделения видит только кадровая подсистема. Банк «закрыл офис» в управлении персоналом и считает, что узел недоступен. На деле для остальных подсистем подразделение с проставленной датой окончания остаётся активным, и в нём всё ещё можно создавать объекты. Сверьте на обследовании, что банк понимает под «закрытием» и где это должно отражаться, иначе закрытый офис продолжит «работать».

Рабочие шаблоны

Копируйте в свои рабочие документы и заполняйте на обследовании.

Карта оргструктуры банка. Заводится по всему дереву подразделений. Закрывает грабли с кодированием, дублями и балансовой привязкой.

Подразделение	Тип	Родитель	Код	Балансовая привязка	Открытый вопрос

Тип — из согласованного классификатора (головной офис, филиал, доп.офис, касса, обменный пункт). Балансовая привязка — собственный баланс или баланс филиала, к которому относится узел. Открытый вопрос — что не выяснено и на ком из банка решение.

Матрица ролей пользователей. Заполняется вместе с владельцем доступа со стороны банка. Одна строка — одна роль; периметр и подпись разводятся намеренно.

Роль (группа)	Подразделения периметра	Глубина по дереву (вверх/вниз)	Основание подписи	Замещает / замещается

Периметр — по каким подразделениям роль видит объекты. Глубина — до какого уровня дерева распространяется доступ. Основание подписи — заполняется, если роль даёт право подписи, отдельно от доступа. Детали модели доступа — в Главе 1.6.

Ключевые термины

Термин	Определение
Подразделение	Узел организационной структуры банка; реквизит учётных и платёжных объектов, точка привязки к балансу
Иерархия подразделений	Дерево организационных единиц банка; определяет распространение доступа и сборку отчётности
Правило кодирования	Принцип построения кода узла (код родителя плюс порядковый номер, фиксированная длина уровня); задаётся один раз
Тип подразделения	Классификатор узла (доп.офис, касса, обменный пункт); влияет на регуляторную отчётность
Участник расчётов	Атрибут подразделения, определяющий его роль в межбанковских и внутрибанковских расчётах
Пользователь системы	Учётная запись с уникальным логином; одновременно субъект доступа и реквизит-ссылка в счетах и документах
Системный логин	Уникальный идентификатор пользователя (латиница, из ФИО); после регистрации не изменяется
Связь с физлицом	Привязка пользователя к досье клиента, когда сотрудник одновременно является клиентом банка
Основание подписи	Документ (доверенность, устав), дающий право подписи; хранится в разрезе периодов действия
Группа (роль)	Набор прав доступа, назначаемый пользователю; пользователь может входить в несколько групп
Индивидуальная группа	Персональная роль, создаваемая автоматически при регистрации пользователя в системе доступа
Балансовая привязка	Принадлежность подразделения к собственному балансу или балансу филиала; граница межфилиальных расчётов
Точка расширения	Механизм запуска пользовательской логики банка при создании или изменении объекта (в т.ч. подразделения)

---

Это бесплатный фрагмент. Дальше в полной версии: Глава 1.2 «Универсальный механизм настроек АБС» — как одна параметрическая модель управляет поведением всех подсистем; затем клиенты и счета, документы и проводки, операционный день, регуляторный контур, отчётность и инструменты — всего шесть частей с чек-листами, граблями и шаблонами.