Diasoft FA#
Содержание
2020: Использование в качестве АБС для киберполигона «Ростелекома»
Компания «Диасофт», российский разработчик ИТ-решений для финансового сектора, заключила соглашение с «Ростелекомом» в лице дочерней компании «Ростелеком-Солар», национального провайдера кибербезопасности. Целью сотрудничества является построение банковского сегмента киберполигона, который предоставит банкам возможность отрабатывать практические навыки отражения кибератак. Об этом «Диасофт» сообщил 3 сентября 2020 года.
В качестве автоматизированной банковской системы было выбрано соответствующее решение компании «Диасофт», которое используется кредитно-финансовыми организациями России. Полробнее здесь.
Приказом №426 Минкомсвязи Российской Федерации 6 сентября 2016 года решения компании «Диасофт» – ИТ-система Diasoft FA#, финансовая архитектура FLEXTERA и аналитическая платформа FLEXTERA BI – включены в Единый реестр российских программ для электронных вычислительных машин и баз данных.
В августе 2011 года «Диасофт» предоставила кредитным организациям, использующим систему Diasoft FA#, возможность автоматизировать ведение договоров банковского счета юридических лиц. Программный продукт «Ведение договоров банковского счета юридических лиц» меняет идеологию системы Diasoft FA# в части проведения таких операций как заключение договоров с клиентами, открытие расчетных счетов и подключение к ним набора необходимых услуг, за предоставление которых производится взимание комиссий. Теперь в продукте выделена новая сущность – договоры банковского счета юридических лиц, с которых и начинается работа с клиентом.
Внедрение программного продукта Diasoft FA# Bank, Ведение договоров банковского счета юридических лиц позволит кредитным организациям:
С октябре 2011 года компания «Диасофт» предоставляет кредитно-финансовым организациям, использующим систему Diasoft FA#, функционал, который позволяет автоматизировать «сквозной» бизнес-процесс работы с документами электронного вида, возможность их визирования и передачи в электронный архив. Программный продукт «Учет электронных сигнатур документов дня» предназначен для установки подписей на документах дня. Новая функциональность обеспечивает явную связь первичного документа в АБС и документа в электронном виде (ДЭВ) в электронном архиве. На каждый первичный документ формируется отдельный ДЭВ, который в АБС визируется необходимыми подписями в заданной последовательности. После завершения обработки документ выгружается в электронный архив. Такой подход исключает случаи расхождения данных в первичных документах АБС и электронного архива.
Также программный продукт «Учет электронных сигнатур документов дня» обеспечивает:
С декабря 2011 года клиенты компании «Диасофт», бизнес которых поддерживает система Diasoft FA#, получили возможность использовать решение «Пятый Уровень» компании ProLAN для повышения качества ИТ-услуг, управления себестоимостью банковских продуктов, нормирования труда и управления численностью персонала.
ProLAN — разработчик программных продуктов, решений и программно-аппаратных комплексов для диагностики, тестирования и управления информационными системами — включила автоматизированную банковскую систему Diasoft FA# в состав поддерживаемых решений. Как ожидается, «Пятый Уровень» от ProLAN повысит эффективность эксплуатации Diasoft FA# в финансовых институтах. Теперь в автоматическом режиме можно контролировать время выполнения критически важных бизнес-транзакций системы Diasoft FA# (например, транзакцию выдачи потребительского кредита), производительность и доступность Diasoft FA#, а также производительность труда пользователей АБС.
Потребителями получаемой информации могут быть специалисты различных подразделений кредитно-финансовой организации. Так, ИТ-служба получает инструментарий для повышения качества ИТ-услуг; бизнес-подразделения — дополнительные KPI бизнес-процессов, которые можно контролировать в режиме реального времени; HR-служба — инструментарий для определения нормативов и построения динамической модели численности персонала; финансовая служба — инструментарий для внедрения методики Time-Driven Activity Based Costing (разработанная Робертом Капланом и Стивеном Андерсоном, эта методика позволяет эффективно управлять себестоимостью банковских продуктов).
Одной из особенностей решения «Пятый Уровень» является его простота и экономичность — для внедрения решения достаточно установить на автоматизированные рабочие места пользователей программу «EPM-Агент», которая собирает информацию о работе бизнес-приложения и в режиме реального времени передает ее в различные системы управления.
«Вопросам Quality Assurance, в частности, вопросам производительности наших программных продуктов, мы традиционно уделяем очень большое внимание, — рассказал Николай Ипполитов, директор департамента «Партнерские решения» компании «Диасофт». — До последнего времени эта задача решалась, в основном, средствами нагрузочного тестирования, которое является обязательным этапом перед выпуском любого нашего программного продукта на рынок. Однако нагрузочное тестирование не позволяет управлять производительностью АБС во время ее эксплуатации в условиях реальной ИТ-инфраструктуры клиента, которая, зачастую, далека от идеальной. Продукты категории Real User Monitoring компаний IBM, HP, BMC и других крупных международных вендоров ориентированы, в первую очередь, на управление производительностью `тонких клиентов`, что не позволяет использовать их для управления производительностью Diasoft FA#. Поддержка АБС Diasoft FA# с помощью решения `Пятый Уровень` для нас очень важна, так как позволяет не только повысить качество обслуживания наших клиентов, но и сделать это эффективно. Стоимость решения `Пятый Уровень` на порядок ниже стоимости HP RUM или BMC EUTM».
В 2010 году завершена модернизация текущего поколения продуктов компании – линейки Diasoft FА#: в недавнем прошлом монолитная клиент-серверная система разделена теперь на отдельные специализированные приложения, между которыми создан слой межмодульного и внешнего API – при этом отдельные части комплексной системы теперь могут работать на отдельных базах данных и серверах. Выпуск новой версии комплексной системы Diasoft FA# v.7.2 обеспечил необходимые условия для последующего перехода сотен клиентов компании на новейшие SOA-технологии.
Программные продукты Diasoft FA# Beans
Информационная архитектура Diasoft FA# Beans
Diasoft FA# Beans (Diasoft Financial Architecture) – это комплексная система автоматизации деятельности финансовых институтов. Система имеет компонентную структуру и состоит из 56 компонентов, автоматизирующих следующие области бизнеса: розничный банкинг, корпоративный банкинг, депозитарный учет, деятельность управляющих и инвестиционных компаний, банковские операции на фондовом и денежном рынках.
В системе Diasoft FA# Beans реализовано несколько типов отчетности:
Прикладная отчетность строится по данным какого-либо модуля и входит в состав соответствующего продукта.
Общесистемная отчетность строится по данным нескольких модулей, этот вид отчетности выделен в отдельный модуль.
Функциональная архитектура:
Хозяйственная деятельность и управление персоналом
Diasoft FA# (Diasoft Financial Architecture) — это хорошо известная на рынке система автоматизации бэк-офисной деятельности финансовых организаций. Среди клиентов компании «Диасофт», использующих систему Diasoft FA#, более 30% российского банковского рынка, в том числе более половины российских банков из списка топ-100 и 31 банк из 75-ти со стопроцентным иностранным капиталом.
Компоненты Diasoft FA# могут быть выпущены, установлены и заменены автономно, независимо друг от друга. Каждый из таких компонентов является полноценным сервис-провайдером в терминах сервис-ориентированной архитектуры.
Использование принципов SOA в построении ИТ-архитектуры дает ряд преимуществ:
Интеграция с внешними системами
Diasoft FA# предоставляет широкие возможности по интеграции с информационными системами сторонних поставщиков для обеспечения работы в составе комплексных ИТ-решений.
Кастомизация и конфигурирование
Поддерживается возможность кастомизации системы на следующих уровнях:
Поддержка локальной специфики
Аутентификация пользователей в системе базируется на механизмах, встроенных в используемую СУБД (Microsoft SQL Server или Sybase Adaptive Server). При этом используется концепция «сквозной» аутентификации и авторизации, которая подразумевает использование единой учетной записи как на уровне системы, так и на уровне СУБД.
Таким образом, все операции с данными в СУБД осуществляются пользователями с использованием персональных учетных записей, что позволяет отслеживать действия пользователей не только средствами системы, но и с использованием средств мониторинга и аудита используемой СУБД.
В системе поддерживается следующая политика по работе с паролями:
В системе предусмотрены следующие категории прав:
Система позволяет выполнять верификацию (авторизацию) проводимых операций уполномоченным сотрудником. Верификация операций может быть выполнена путем просмотра и подтверждения данных по операции другим сотрудником.
Ограничение полномочий администраторов
Для защиты информации от несанкционированного доступа и изменения лицами, обладающими административными полномочиями, в системе приняты специальные меры по разделению сфер ответственности администраторов и ограничению их полномочий.
В частности поддерживаются следующие виды пользователей:
Используемая политика безопасности лишает администраторов системы возможности раздавать прикладные полномочия самому себе или на время сменить пароль пользователю и совершить действия от его имени.
Аудит действий пользователей
Все действия пользователей с объектами системы (документами, счетами, проводками и т.д.) фиксируются подсистемой аудита. По каждому действию фиксируется дата и время его выполнения, пользователь, выполнивший данное действие и дополнительная информация по операции. Для ряда объектов (таких как сделки, документы и.т.д.) предусмотрена возможность по каждому изменению объекта просмотреть состояние объекта до изменения, текущее состояние объекта, а также сравнить два любых изменения. Для просмотра данных аудита используется «Журнал операций».
АБС из облака (Diasoft FА )
Компании «Диасофт» и «Онланта» (входит в ГК ЛАНИТ) объявили в начале 2013 года о начале сотрудничества для предоставления кредитно-финансовым организациям автоматизированной банковской системы Diasoft FA# по модели SaaS из «облака» OnCloud.ru компании «Онланта». Новый сервис «АБС из облака» ориентирован на малые и средние банковские организации.
В рамках сотрудничества «Онланта» обеспечивает хостинг системы Diasoft FA# на вычислительных ресурсах в «облаке» OnCloud.ru. Специалисты «Диасофт» занимаются поддержкой и развитием автоматизированной банковской системы Diasoft FA#. Новый сервис даёт возможность банкам снизить операционные и инвестиционные риски, связанные с внедрением и использованием комплексной АБС, а также позволяет в сжатые сроки получить доступ к полноценной банковской системе.
Предложение «Диасофт» и «Онланты» обеспечивает высокую производительность решений даже при использовании медленных каналов связи, что крайне важно для банков с развивающейся филиальной сетью – для быстрого старта, открытия новых офисов и поддержки мобильности.
Среди преимуществ размещения автоматизированной банковской системы и информации в «облаке» – снижение ИТ-затрат на поддержку программного обеспечения и обслуживание рабочих мест бизнес-пользователей, в том числе за счёт исключения необходимости обслуживания АБС на рабочем месте персонала. По экспертным оценкам, банки, применяющие «облачные» технологии, уже в пятилетней перспективе сократят бюджетные затраты на ИТ до 40%.
Автоматизированное тестирование производительности
Необходимые процессы и изменения – обновление версий программного обеспечения, внедрение нового функционала и его дополнений в текущую инфраструктуру – несут существенные риски для работоспособности системы. Правильно организованный процесс тестирования, включающий в себя большинство критичных с точки зрения бизнеса операций, позволяет без возникновения кризисных ситуаций ввести изменения в эксплуатацию.
«Диасофт» предоставляет комплексные услуги по созданию и настройке тестовой среды, предназначенной для организации функционального и нагрузочного тестирования изменений в системе, а также автоматизации процесса их проведения.
Создание тестовой среды позволяет решить следующие задачи:
«Диасофт» имеет обширный опыт как в нагрузочном, так и функциональном тестировании программных продуктов.
Тестирование производительности изменений Diasoft FA# Beans
Услуга тестирования производительности изменений Diasoft FA# Beans предназначена для автоматического воспроизведения работы пользователей информационной системы без привлечения сотрудников заказчика.
Сервис позволяет в любой момент, не отвлекая пользователей, воспроизвести их работу в течении дня в информационной системе Diasoft FA# Beans, что дает возможность протестировать обновления, в частности:
Услуга позволяет записывать работу пользователей (выборочно или всех) в течение рабочего дня (одного или нескольких) и предоставляет «список» для последующего автоматического воспроизведения.
Простая и прозрачная работа сервиса тестирования производительности
Для записи работы пользователей и ее воспроизведения достаточно проделать несколько шагов:
Воспроизвести записанную работу пользователей на тестовой среде в исходной конфигурации.
Поднять эталонный бэкап на тестовой среде, провести целевые изменения, воспроизвести записанную работу пользователей и сравнить результаты.
Преимущества использования сервиса Diasoft FA# Player:
FLEXTERA Accounting Engine: по дороге из желтого кирпича
Читать статью в pdf-формате
В 2006 году мы начали создавать линейку продуктов FLEXTERA. Базовым архитектурным принципом FLEXTERA является разделение продуктов на функциональные слои, в том числе разделение продуктового и бухгалтерского учета. Так на схеме функциональной архитектуры новой линейки продуктов появился новый сервис преобразования учета – Accounting Engine. Это была не просто дань модным архитектурным веяниям. Зависимость продуктовых систем от изменений учетного законодательства мешала нам быстро развивать продукты и качественно их сопровождать. Преимущества новой архитектуры казались очевидными.
В этой статье мы делимся знаниями и опытом, которые приобрели на пути к правильной архитектуре, и рассказываем о решении, которое создали в этом процессе.
Когда Accounting Engine нет
За 20–25 лет развития АБС сложилась традиционная для большинства из них архитектура. Это многофункциональная система, которая совмещает функции бэк-офиса, бухгалтерского и налогового учета, регуляторной и оперативной отчетности.
Что характерно для такой архитектуры?
• Единый баланс организации собирается из разнородных продуктовых систем на уровне Главной книги банка. Информация из внешних продуктовых систем на данном уровне недоступна, поэтому вся необходимая аналитика кодируется в номере лицевого счета.
• Продуктовые системы ведут свой собственный бухгалтерский учет, данные которого используются для продуктового учета. Например, в качестве остатка по депозитному договору используется остаток на соответствующем лицевом счете.
• В каждой продуктовой системе есть собственные встроенные механизмы формирования проводок и открытия счетов.
• Консолидированная отчетность организации формируется на уровне Главной книги. Дополнительные расшифровки стоят в продуктовых системах. Поэтому отчетность часто собирают вручную.
Аналогично развивались и бизнес-процессы кредитной организации, подстраиваясь и под особенности бизнеса, и под возможности АБС.
Распространено следующее распределение ролей и обязанностей пользователей системы:
• сотрудники операционного департамента кроме оформления и сопровождения операций отвечают за их бухгалтерское отражение, вносят «ручные» проводки и контролируют работу с лицевыми счетами;
• бухгалтерия отвечает за последующий контроль учета операций и при этом зачастую не имеет доступа к продуктовым системам. При сверке приходится ориентироваться на бумажные документы или отчеты из продуктовых систем;
• методология учета — это бумажный документ, который внедряет IT-служба банка, сами методологи не работают в системах, автоматизирующих правила учета;
• при появлении новых требований учетного законодательства IT-служба банка вносит изменения не только в Главную книгу, но и в продуктовые системы.
Когда Accounting Engine есть
Альтернативное решение, которое было сформулировано BIAN (Banking Industry Architecture Network) и поддержано IBM, предполагает разделение сервисов на учетные слои. Почему важно отделять продуктовый учет от бухгалтерского и какую роль в этом подходе играет решение класса Accounting Engine?
При разделении на слои в продуктовых бэк-офисных системах отсутствуют объекты учетного слоя, такие как бухгалтерские синтетические и аналитические счета, документы, транзакции двойной записи (проводки) и прочие атрибуты бухгалтерской книги. Для поддержки своих операционных функций продуктовая система опирается на продуктовые регистры, спроектированные специально для решения задачи конкретного банковского продукта. Наполнение Главной книги бухгалтерскими данными и преобразование продуктовых событий в бухгалтерский учет осуществляет Accounting Engine
Характеристики АБС, построенной по принципу разделения продуктового и бухгалтерского учета:
• продуктовые системы ориентированы исключительно на основные функции бэк-офиса. Продуктовый учет сконцентрирован на продуктовых регистрах;
• взаимодействие между продуктовыми системами и Главной книгой организовано посредством обработки продуктовых событий Accounting Engine;
• продуктовые события отражают исключительно пошаговые бизнес-процессы бэк-офиса и содержат только операционные данные;
• Accounting Engine содержит сценарии обработки продуктовых событий, правила открытия лицевых счетов и формирования бухгалтерских документов.
Изменение архитектуры АБС влияет на бизнес-процессы, распределение ответственности между бэк-офисом и бухгалтерией и подходы к сопровождению АБС следующим образом:
• сотрудники операционного блока сосредоточены на своей непосредственной функции сопровождения операций;
• бухгалтерия, осуществляя последующий контроль, имеет доступ к просмотру продуктовых операций и событий на уровне Accounting Engine и контролирует все «ручные» корректировки;
• методолог может сопровождать и менять правила бухгалтерского учета через пользовательский интерфейс Accounting Engine без привлечения IT-службы;
• продуктовые системы исключаются из контура изменений для поддержки новых требований учетного законодательства.
Как мы сделали Accounting Engine
В 2008 году после поистине героического проекта по поддержке новых требований бухгалтерского учета, который вошел в историю как проект «302-П», мы, что называется, на собственной шкуре испытали всю сложность задачи и поняли, что разделение продуктового и бухгалтерского учета — жизненно важный принцип проектирования автоматизированных систем. Мы очень хотели выстоять и в следующих учетных революциях. Так что рекомендации BIAN по этому вопросу легли на уже подготовленную почву.
Начало пути
Создание линейки FLEXTERA началось в 2006 году. Что делать с большинством новых сервисов, мы понимали. Мы знали функциональные требования к продуктам бэк-офиса. За предыдущие годы мы накопили колоссальный прикладной опыт в этом направлении. А вот наше представление об Accounting Engine основывалось на поверхностных описаниях BIAN, элементах этого функционала в линейке Diasoft FA# и мечтах об идеальном продукте.
Наше первое вИдение исходило из постулата, что Accounting Engine — это простая и быстрая «молотилка» для продуктовых событий. Сам сервис не должен быть мастер-системой для операционных данных — только для правил и настроек. Мы представляли его как своеобразное интеграционное приложение. С этого начался наш путь «по дороге из желтого кирпича» — к Accounting Engine, с которым можно будет построить архитектуру нового поколения.
Первый поворот
В первом пилотном проекте мы столкнулись с обстоятельствами, которые заставили нас пересмотреть предыдущий подход к решению задачи. Продуктовая система, являющаяся для нас источником событий, депозитный бэк-офис французского производства, не имела функционала для связи лицевых счетов и проводок с договорами и операциями. Кроме того, она не формировала набор событий с необходимым для российского учета атрибутным составом. Например, в событии заключения депозитного договора продуктовая система передавала идентификатор клиента, но не передавала форму собственности и резидентство. Такой поворот на нашем пути привел к тому, что в сервисе Accounting Engine появились новые функции: полное сохранение связей между продуктовыми объектами, событиями и объектами учета, а также обогащение события необходимыми для учета атрибутами.
Второй поворот
Особенностью следующего проекта стала задача поддержки учета по РПБУ в некредитной финансовой организации. С одной стороны, процесс настройки был простым — в этом стандарте отсутствуют лицевые счета. С другой стороны, нужен был аналитический учет на уровне субконто. На этом отрезке пути мы поняли, что спроектированный ранее механизм настройки справился с задачей без существенных доработок. Accounting Engine сформировал проводки для выгрузки в NAVISION AXAPTA, а мы зафиксировали функциональную возможность поддержки правил и механизмов формирования проводок в разрезе субконто.
Серьезное испытание
Следующий проект стал серьезным испытанием для Accounting Engine. «Дорога из желтого кирпича» наконец привела нас к задаче поддержки требований бухгалтерского учета операций на финансовых рынках по требованиям IFRS. Требования проекта задали высокую планку: нужны были очень гибкие механизмы настройки, потому что учет операций на финансовых рынках крайне сложен. В результате мы доработали механизмы настройки и обработки событий, полностью изменили правила открытия лицевых счетов и настройки схем счетов и получили решение на более высоком уровне зрелости.
Кроме того, важным компонентом преобразования учета операций на финансовых рынках стал новый аналитический сервис «Инструментарий вычислений». В 90% случаев по операциям на финансовых рынках невозможно сформировать полноценный бухгалтерский учет только на базе продуктовых событий. Универсальная продуктовая система ничего не знает о расчете финансового результата, об особенностях применения метода начислений, о правилах переоценки по справедливой стоимости, амортизации затрат и т.п. Эти алгоритмы являются частью учетных стандартов, а значит, входят в платформу преобразования учета и поддерживаются в специальном сервисе — FLEXTERA «Инструментарий вычислений».
Новые вызовы
Наш текущий проект — это поддержка перехода на отраслевые стандарты бухгалтерского учета Банка России для НФО. Наконец идея Accounting Engine развернулась в полный рост. Источником продуктовых событий являются сразу несколько систем: Calypso, Diasoft FА#, 1C Казначейство. Чтобы не строить отдельное интеграционное решение для каждой системы, мы разработали стандарт продуктовых событий в формате XML для всех операций на финансовых рынках и спроектировали события, исходя из реального бизнес-процесса, без учета специфики реализации продуктовых систем. Этот подход позволяет получить интерфейс, независимый от системы источника.
Какой Accounting Engine действительно работает
В результате эволюции развития Accounting Engine получилась система, функциональные блоки которой представлены на рис.
Мы прошли большой путь и понимаем, что Accounting Engine — это не просто «молотилка», не просто интеграционная функция. Для «честного» разделения продуктового и бухгалтерского учета такого «просто» недостаточно. Мы еще идем «по дороге из желтого кирпича», но уже точно знаем, что такое Accounting Engine, который действительно работает. Мы видим новые функциональны возможности, готовы к новым вызовам и испытаниям. Уже видны башни Изумрудного города, и впереди нас ждет самое интересное.
Наталья Татарникова,
главный бизнес-архитектор департамента
«Финансовые рынки FLEXTERA» компании «Диасофт»