Ну, нужно же ЦБ на ком-то «потренироваться» :) За НФО сказать не могу т.к. имею только базовые представления о текущем положении дел с ПО в данных организациях. Учитывая, что в данном случае речь идет о целом ряде организаций, деятельность которых сильно различается, подозреваю, что и в сфере применяемого ПО «зоопарк» тот еще.
Для банков переход на XBRL будет более простым, просто по причине достаточно ограниченного количества АБС (Автоматизированная Банковская Система) на Российском рынке.
Конечно, в первую очередь «под раздачу» попадут те банки, которые используют «самописные» АБС (in-house разработки) и гибридные решения типа back office «из коробки» + «самописная» АБС, ну или экзотические зарубежные варианты типа Olympic. Однако, иметь в России собственную in-house development АБС могут позволить себе только очень крупные кредитные организации, а у них, как правило, есть большой локальный штат собственных разработчиков, так что большой проблемой для них это не будет.
Остальная (большая) часть банков имеет АБС «из коробки» (Diasoft, ЦФТ, Афина и пр. список очень короткий). Тут все намного проще т.к. и поддержку XBRL они получат «из коробки» просто в рамках плановых обновлений АБС. Конечно, скорее всего, ряд АБС производителей не упустит возможности на этом немного «погреть руки», однако, большой проблемой для большинства банков это не будет.
Что касается технической реализации, был я в 2016 году на одной встрече по данной теме, там так же присутствовали (помимо ЦБ) еще и представители производителей ПО: Diasoft, 1C и ЦФТ. Причем, они все в один голос заявили, что не видят большой технической проблемы в переходе на XBRL отчетность. Так, представители 1С и Diasoft сказали, что просто добавят модуль конвертер текущей отчетности в XBRL без каких либо серьезных изменений в ядре систем. Учитывая то, что (сильно утрируя) основная «фишка» XBRL это введение множества дополнительных производных\промежуточных показателей, данный подход кажется абсолютно логичным и прозрачным. А вот ЦФТ говорили о глубокой интеграции логики XBRL в ядро, наверное, для того бы в очередной раз продать подороже .
В любом случае, пример с XBRL отчетностью, на мой взгляд, заставляет еще раз посмотреть в сторону и оценить плюсы именно проверенных отечественных решений «из коробки». Т.к. поддерживать собственные in-house разработки в таком быстро меняющемся мире становится все сложнее.
Прошу прощения, скорее всего, вы правы (если ЦБ в последний момент опять все не перенесет). Я как сотрудник кредитной организации (банка) со своей колокольни смотрю :) Для банков отчетность XBRL будет после 2018 года.
Для банков переход на XBRL будет более простым, просто по причине достаточно ограниченного количества АБС (Автоматизированная Банковская Система) на Российском рынке.
Конечно, в первую очередь «под раздачу» попадут те банки, которые используют «самописные» АБС (in-house разработки) и гибридные решения типа back office «из коробки» + «самописная» АБС, ну или экзотические зарубежные варианты типа Olympic. Однако, иметь в России собственную in-house development АБС могут позволить себе только очень крупные кредитные организации, а у них, как правило, есть большой локальный штат собственных разработчиков, так что большой проблемой для них это не будет.
Остальная (большая) часть банков имеет АБС «из коробки» (Diasoft, ЦФТ, Афина и пр. список очень короткий). Тут все намного проще т.к. и поддержку XBRL они получат «из коробки» просто в рамках плановых обновлений АБС. Конечно, скорее всего, ряд АБС производителей не упустит возможности на этом немного «погреть руки», однако, большой проблемой для большинства банков это не будет.
Что касается технической реализации, был я в 2016 году на одной встрече по данной теме, там так же присутствовали (помимо ЦБ) еще и представители производителей ПО: Diasoft, 1C и ЦФТ. Причем, они все в один голос заявили, что не видят большой технической проблемы в переходе на XBRL отчетность. Так, представители 1С и Diasoft сказали, что просто добавят модуль конвертер текущей отчетности в XBRL без каких либо серьезных изменений в ядре систем. Учитывая то, что (сильно утрируя) основная «фишка» XBRL это введение множества дополнительных производных\промежуточных показателей, данный подход кажется абсолютно логичным и прозрачным. А вот ЦФТ говорили о глубокой интеграции логики XBRL в ядро,
наверное, для того бы в очередной раз продать подороже.В любом случае, пример с XBRL отчетностью, на мой взгляд, заставляет еще раз посмотреть в сторону и оценить плюсы именно проверенных отечественных решений «из коробки». Т.к. поддерживать собственные in-house разработки в таком быстро меняющемся мире становится все сложнее.