Комментарии 10
:-) Судя по информации бюрократия банка не позволяла и не позволяет делать нормальных решений, когда только один человек координирует и отвечает за все функционирующие и планируемые IT системы. В "новом" бизнес-процессе получили ту же самую "размазанную коллективную ответственность" при запуске новых систем (ну хотя бы "закрепили ответственность" за уже существующие системы). Правда кто будет отвечать за новые, тесно взаимодействующие со "старыми", где у каждой свой ответственный/владелец который никогда не хочет чтобы именно его систему "трогали", не определили....
Тут вопрос а бюрократия ли это или скорее масштаб проектов. В крупных организациях и масштаб проекта и масштаб систем просто не позволяет одному человеку и координировать и отвечать за все системы. Систем очень много, системы масштабные, технологический стек может быть разнообразный даже в рамках одной системы, не говоря уже о различных системах. Одному человеку достаточно сложно быть компетентным во всем этом многообразии, к тому же что бы грамотно координировать разработку и одному за все отвечать. Поэтому каждый реально отвечает за выделенный участок системы, или систему целиком. Новые системы обязательно интегрируются со старыми. Системы которые развиваются всегда заинтересованы в изменениях и интеграциях с новыми системами. Это же изменение, а изменения всегда приветствуются.
Масса полезностей. Спер некоторые в копилку.
Следующий логичный запрос stakeholders - расширение услуг, выход за пределы банка, интеграции с другими банками и фин. организациями.
И вот тут капкан - нужна единая платформа для взаимодействия фин. организаций:
- схема банковских данных,
- процессы
- сервисы, опирающиеся на единую request/response схему для каждого типа сервисов.
Супер-интересная и сложная задача:
- создание единого реестра сервисов, схемы, стандартов на именование сущностей, связей, валидаций.
Без этого межбанковские интрефейсы - дикий запад.
В штатах эту задачу для банковского кредитования обозначили 20 лет назад (в 1999 году), сейчас 3я версия схемы и грядет версия 4.
Мы как раз переходим от Sparx на другое решение.
Удачи.
Верно ли я понял, что сейчас все системы, модули и компоненты каталогизированы в Едином общем реестре, но информация о том, как каждая из этих сущностей взаимодействует с другими, не ведётся? Возможно, этот момент я в статье упустил.
В статье уделено много внимания каталогизации потому что там пришлось много чего менять, выстраивать реестр, определять сущности, категоризировать и централизовать. И это по масштабу изменений затронуло много стейкхолдеров. Взаимодействие элементов при проектировании решения было и до изменений. Поэтому этой части не сильно много уделили внимания в статье, но конечно же при проектировании решения мы в основном фокусируемся на взаимодействиях и принципах интеграции. Эта часть не сильно поменялась при трансформации. Изменения в основном были связаны с внедрением единого репозитория, потому что и связи сущностей тоже стали централизованными едиными.
Единый репозиторий бизнес-процессов - вот с этого и надо начинать. Иначе - это "строительство дома без фундамента". У бизнес-процесса должен быть настоящий "владелец" от бизнеса, а не "рабочая группа", где вы никогда ничего не решите - будет как в миниатюре А.Райкина: "К пуговицам есть претензии? А к рукавам? Нет. Но костюмчик то не сидит...". Реестр основных бизнес - процессов с метриками, настоящими владельцами - основное. Тогда и роль автоматизации будет понятна и ее можно оценить. Остальное, конечно, лучше, чем чистый хаос, но например, представителю бизнеса неинтересно тратить время на ваши архитектурные изыскания. Не для этого ему денежку платят. В целом все это - уже пройдено многими банками на практике. Зачем вкладывать деньги в проект автоматизации, ежели он не окупится никогда или же вообще нет понимания об окупаемости! Скажите, к примеру, известна ли вам оценка операционной себестоимости микрокредита, выданного ИП или малому бизнесу? Или - какое изменение неценовых характеристик продукта повысит уровень его продаж , например, на 10% за полгода? Если хотя бы приблизительно известно - тогда понятна возможная роль автоматизации процесса и требования к автоматизации. Архитектура должна от бизнеса идти, а не от одного из инструментальных средств и абстрактных соображений типа "хорошо бы все по полочкам разложить".
Да, репозиторий бизнес процессов это один из важнейших элементов конструкции. С него не начали потому что это еще более масштабные изменения по сложности, по масштабу, по динамике изменений. Задачу просто отнесли на чуточку более поздний этап, когда каркас системы оформился и подтвердил свою жизнеспособность.
Все должно идти от бизнеса. Задача систематизации бизнес процессов, ведение репозитория бизнес процессов, закрепление владельцев бизнес процессов,метрики - это точно такие же задачи которые как и систематизация систем и ответственных влияет на достижения целей бизнеса скорее в долгосрочной перспективе и больше косвенно. Фундамент должен быть, но в нашем случае строить его можно и частями, главное что бы все было в одном месте. Поэтому решили просто начать с систем, подтвердить технологии и подходы, процессы а потом масштабировать на бизнес процессы.
Упорядочиваем архитектуру Банка