Разоблачаем заблуждения о российских системах бюджетирования.
👇
ЗАБЛУЖДЕНИЕ:
Отечественные системы бюджетирования уступают по функционалу иностранным.
А НА САМОМ ДЕЛЕ:
Отечественные системы в OLTP-архитектуре предложат больше возможностей в части контроля и учета исполнения бюджета, чем иностранные OLAP-решения.
Функциональность большинства иностранных платформ охватывает только процессы бюджетного планирования и не имеет механизмов для контроля и учета исполнения бюджета. Это ограничение многомерной OLAP-архитектуры, которую реализуют западные решения. Его также имеют российские разработки, созданные по иностранным образцам на базе OLAP-кубов.
Отечественные платформы бюджетирования на основе транзакционной архитектуры (OLTP), например, приложение «Бюджет хозяйственных расходов» от компании «Интерсофт Лаб», лишены этого недостатка. Их функциональность гораздо шире и обеспечивает поддержку всего комплекса управления затратами, включая процессы сметного планирования и контроля исполнения бюджета.
👇
ЗАБЛУЖДЕНИЕ:
Отечественные системы бюджетирования уступают по функционалу иностранным.
А НА САМОМ ДЕЛЕ:
Отечественные системы в OLTP-архитектуре предложат больше возможностей в части контроля и учета исполнения бюджета, чем иностранные OLAP-решения.
Функциональность большинства иностранных платформ охватывает только процессы бюджетного планирования и не имеет механизмов для контроля и учета исполнения бюджета. Это ограничение многомерной OLAP-архитектуры, которую реализуют западные решения. Его также имеют российские разработки, созданные по иностранным образцам на базе OLAP-кубов.
Отечественные платформы бюджетирования на основе транзакционной архитектуры (OLTP), например, приложение «Бюджет хозяйственных расходов» от компании «Интерсофт Лаб», лишены этого недостатка. Их функциональность гораздо шире и обеспечивает поддержку всего комплекса управления затратами, включая процессы сметного планирования и контроля исполнения бюджета.
Разоблачаем заблуждения о российских системах бюджетирования.
👇
ЗАБЛУЖДЕНИЕ: Автоматизация бюджетирования на российском ПО - это бесконечный процесс.
А НА САМОМ ДЕЛЕ:
Внедрить тиражное отечественное ПО для бюджетирования можно даже за 6 месяцев.
Иностранные поставщики, продвигавшие прикладные платформы для разработки систем бюджетирования, много лет приучали российских заказчиков к мысли о том, что процесс внедрения такого ПО сложно завершить, потому что каждая бюджетная кампания требует новых доработок функциональности.
Тиражные системы с готовым инструментарием для бюджетирования, имеющие механизмы быстрой настройки под методологии банка, имеют сроки внедрения от 6 до 12 месяцев в зависимости от состава решаемых задач.
Для сопровождения и адаптации тиражных механизмов к изменениям методологии бюджетирования, для заведения новых ролей и пользователей и для иного редактирования настроек не требуется привлекать ИТ-специалистов. Справиться с этим смогут и сотрудники отдела бюджетирования.
👇
ЗАБЛУЖДЕНИЕ: Автоматизация бюджетирования на российском ПО - это бесконечный процесс.
А НА САМОМ ДЕЛЕ:
Внедрить тиражное отечественное ПО для бюджетирования можно даже за 6 месяцев.
Иностранные поставщики, продвигавшие прикладные платформы для разработки систем бюджетирования, много лет приучали российских заказчиков к мысли о том, что процесс внедрения такого ПО сложно завершить, потому что каждая бюджетная кампания требует новых доработок функциональности.
Тиражные системы с готовым инструментарием для бюджетирования, имеющие механизмы быстрой настройки под методологии банка, имеют сроки внедрения от 6 до 12 месяцев в зависимости от состава решаемых задач.
Для сопровождения и адаптации тиражных механизмов к изменениям методологии бюджетирования, для заведения новых ролей и пользователей и для иного редактирования настроек не требуется привлекать ИТ-специалистов. Справиться с этим смогут и сотрудники отдела бюджетирования.
Media is too big
VIEW IN TELEGRAM
Хотите узнать будет ли работать хранилище данных банка размером 200 Тб на СУБД Postgres?
Тогда смотрите первый в этом году выпуск видеоцикла "200 слов о банковской аналитике".
Тогда смотрите первый в этом году выпуск видеоцикла "200 слов о банковской аналитике".
Специально для раздела «Аналитика» на сайте Ассоциации российских банков Интeрсофт Лаб подготовила инфографику, иллюстрирующую предварительные итоги развития рынка систем банковской аналитики за 2024 год.
Знакомьтесь с публикацией «Импортозамещение банковской аналитики 2024: лед тронулся» и узнайте, как финансовые организации перестраивались на отечественное ПО для построения хранилищ данных и систем управления корпоративной эффективностью:
https://www.arb.ru/banks/analitycs/importozameshchenie_bankovskoy_analitiki_2024_led_tronulsya-10680053/
Знакомьтесь с публикацией «Импортозамещение банковской аналитики 2024: лед тронулся» и узнайте, как финансовые организации перестраивались на отечественное ПО для построения хранилищ данных и систем управления корпоративной эффективностью:
https://www.arb.ru/banks/analitycs/importozameshchenie_bankovskoy_analitiki_2024_led_tronulsya-10680053/
👉 Вы не забыли, что в 2024 году на базе отечественных хранилищ данных банки чаще всего автоматизировали регуляторную отчетность? Мы писали об этом здесь: vk.com/intersoftlab?z=photo....
И этот тренд набирает обороты в 2025м.
Знаете почему?
Во-первых, датацентричная архитектура является более правильной для подготовки надзорных данных, в том числе с позиции регулятора.
И раз уж банкам все равно предстоит переводить процессы подготовки отчетности на отечественный софт, то разумно заменить сложившиеся годами выгрузки из АБС и Excel-таблицы на более технологичное решение на основе хранилища данных.
Во-вторых, банки хотят обеспечить бесперебойную подготовку обязательной отчетности после перехода на отечественные версии АБС.
Ведь не все разработчики АБС ставят высокий приоритет портации своих отчетных модулей на разрешенные технологические компоненты. Да и банки традиционно отдавали предпочтение не им, а собственным наработкам для подготовки отчетности, построенным «вокруг АБС». Так вот, все они перестанут функционировать после перехода на новые версии банковских систем.
Стоит подстраховаться и заранее перевести критически значимые процессы подготовки регуляторной отчетности на отечественное хранилище данных. Будет и надежно, и стратегически верно.
Согласны?
И этот тренд набирает обороты в 2025м.
Знаете почему?
Во-первых, датацентричная архитектура является более правильной для подготовки надзорных данных, в том числе с позиции регулятора.
И раз уж банкам все равно предстоит переводить процессы подготовки отчетности на отечественный софт, то разумно заменить сложившиеся годами выгрузки из АБС и Excel-таблицы на более технологичное решение на основе хранилища данных.
Во-вторых, банки хотят обеспечить бесперебойную подготовку обязательной отчетности после перехода на отечественные версии АБС.
Ведь не все разработчики АБС ставят высокий приоритет портации своих отчетных модулей на разрешенные технологические компоненты. Да и банки традиционно отдавали предпочтение не им, а собственным наработкам для подготовки отчетности, построенным «вокруг АБС». Так вот, все они перестанут функционировать после перехода на новые версии банковских систем.
Стоит подстраховаться и заранее перевести критически значимые процессы подготовки регуляторной отчетности на отечественное хранилище данных. Будет и надежно, и стратегически верно.
Согласны?
ВКонтакте
Intersoft Lab
Мы создаем решения для автоматизации задач финансового и риск-менеджмента, которые помогают банкам быть гибкими и достигать лучших результатов даже в сложные времена. Intersoft Lab – ведущий российский поставщик программного обеспечения и консультационных…
Писала об этом 100 раз. Этот – 101й.
Потому что снова возникла путаница между Вusiness Performance Management и Business Process Management.
А было так: в честь 25-летия Интерсофт Лаб в ноябре 2024 года на сайте компании был опубликован специальный он-лайн проект «25 лет CPM: новая волна». Он стал третьим после своих предшественников: «15 лет ВРМ» в 2014м году и «(R)СРМ: 20 лет спустя» в 2019м.
На мой профессионально деформированный взгляд все было логично: проекты выходили в разные годы, а их названия отражали эволюцию развития платформ управления эффективностью: от ВРМ к СРМ.
И я порекомендовала все три материала для прочтения одному уважаемому ИТ-эксперту, который ранее не сталкивался с ПО для управления эффективностью.
Эксперт проштудировал материалы, изучил Классификатор российского ПО и вернулся с вопросом о том, как связаны между собой Вusiness Performance Management и Business Process Management, а заодно и два класса ПО: 09.05. «Средства управления эффективностью предприятия (СРМ/ЕРМ)» и 09.01. «Средства управления бизнес-процессами (ВРМ)».
В этот момент стало ясно, что вопрос требует 101го пояснения. Для тех, кто раньше про ВРМ-EPM-CPM-RCPM ничего не слышал, а теперь надо разобраться.
Рассказываю.
Про историю класса 09.05. «Средства управления эффективностью предприятия (СРМ/ЕРМ)», который когда-то начинался, да-да, как ВРМ.
Аббревиатуру BPM для обозначения концепции и информационных систем для управления эффективностью бизнеса (Вusiness Performance Management) на рубеже веков ввела в обращение аналитическая компания IDC. Примерно в то же время другая исследовательская организация - Gartner предложила синоним - СРМ (Corporate Performance Management, управление эффективностью корпорации), а еще позднее на рынке появился третий аналог для обозначения того же самого ПО – EPM (Enterprise Performance Management, управление эффективностью предприятия).
Согласно идее авторов, Вusiness Performance Management - это методология, которая позволяет планировать, измерять и управлять эффективностью деятельности организации, направленной на достижение финансовых целей при оптимальном использовании имеющихся ресурсов. Ключевые процессы ВРМ включают финансовую консолидацию, стратегическое и оперативное финансовое планирование, подготовку финансовой отчетности, анализ показателей эффективности/результативности и регулирование финансовых целей.
Автоматизацию системы финансового менеджмента, построенной на принципах управления эффективностью бизнеса, обеспечивает ПО с аналогичной аббревиатурой – ВРМ.
После появления на рынке средств управления бизнес-процессами, которые оформились в отдельный класс ПО с идентичной аббревиатурой, происходящей от Business Process Management, сокращение ВРМ применительно к системам управления эффективностью перестали использовать, ограничившись двумя оставшимися - СРМ и EPM.
Сегодня аббревиатуру ВРerformanceМ для обозначения систем класса 09.05. (СРМ/ЕРМ) можно встретить разве что в историческом контексте – в публикациях двадцати-пятнадцатилетней давности или в нашем спецпроекте, иллюстрирующем эволюцию ПО для управления эффективностью бизнеса/корпорации/предприятия за 25 лет его существования. И к системам класса 09.01. «Средства управления бизнес-процессами (ВProcessМ)» она не имеет никакого отношения.
Потому что снова возникла путаница между Вusiness Performance Management и Business Process Management.
А было так: в честь 25-летия Интерсофт Лаб в ноябре 2024 года на сайте компании был опубликован специальный он-лайн проект «25 лет CPM: новая волна». Он стал третьим после своих предшественников: «15 лет ВРМ» в 2014м году и «(R)СРМ: 20 лет спустя» в 2019м.
На мой профессионально деформированный взгляд все было логично: проекты выходили в разные годы, а их названия отражали эволюцию развития платформ управления эффективностью: от ВРМ к СРМ.
И я порекомендовала все три материала для прочтения одному уважаемому ИТ-эксперту, который ранее не сталкивался с ПО для управления эффективностью.
Эксперт проштудировал материалы, изучил Классификатор российского ПО и вернулся с вопросом о том, как связаны между собой Вusiness Performance Management и Business Process Management, а заодно и два класса ПО: 09.05. «Средства управления эффективностью предприятия (СРМ/ЕРМ)» и 09.01. «Средства управления бизнес-процессами (ВРМ)».
В этот момент стало ясно, что вопрос требует 101го пояснения. Для тех, кто раньше про ВРМ-EPM-CPM-RCPM ничего не слышал, а теперь надо разобраться.
Рассказываю.
Про историю класса 09.05. «Средства управления эффективностью предприятия (СРМ/ЕРМ)», который когда-то начинался, да-да, как ВРМ.
Аббревиатуру BPM для обозначения концепции и информационных систем для управления эффективностью бизнеса (Вusiness Performance Management) на рубеже веков ввела в обращение аналитическая компания IDC. Примерно в то же время другая исследовательская организация - Gartner предложила синоним - СРМ (Corporate Performance Management, управление эффективностью корпорации), а еще позднее на рынке появился третий аналог для обозначения того же самого ПО – EPM (Enterprise Performance Management, управление эффективностью предприятия).
Согласно идее авторов, Вusiness Performance Management - это методология, которая позволяет планировать, измерять и управлять эффективностью деятельности организации, направленной на достижение финансовых целей при оптимальном использовании имеющихся ресурсов. Ключевые процессы ВРМ включают финансовую консолидацию, стратегическое и оперативное финансовое планирование, подготовку финансовой отчетности, анализ показателей эффективности/результативности и регулирование финансовых целей.
Автоматизацию системы финансового менеджмента, построенной на принципах управления эффективностью бизнеса, обеспечивает ПО с аналогичной аббревиатурой – ВРМ.
После появления на рынке средств управления бизнес-процессами, которые оформились в отдельный класс ПО с идентичной аббревиатурой, происходящей от Business Process Management, сокращение ВРМ применительно к системам управления эффективностью перестали использовать, ограничившись двумя оставшимися - СРМ и EPM.
Сегодня аббревиатуру ВРerformanceМ для обозначения систем класса 09.05. (СРМ/ЕРМ) можно встретить разве что в историческом контексте – в публикациях двадцати-пятнадцатилетней давности или в нашем спецпроекте, иллюстрирующем эволюцию ПО для управления эффективностью бизнеса/корпорации/предприятия за 25 лет его существования. И к системам класса 09.01. «Средства управления бизнес-процессами (ВProcessМ)» она не имеет никакого отношения.
Отвечаем на один из самых популярных вопросов по автоматизации регуляторной отчетности.👇
ВОПРОС: Сколько времени нужно на автоматизацию обязательных нормативов?
ОТВЕТ: Срок зависит от многих факторов:
- какие финансовые инструменты использует банк,
- сколько сейчас в 135й форме ненулевых кодов,
- эксплуатируется ли в банке хранилище данных «Контур», и загрузка каких портфелей договоров в него налажена,
- как планируется организовать процесс внедрения,
- и т.д.
В среднем, если есть общая цель и воля руководства, задача автоматизации расчета обязательных нормативов может быть решена за 1,5-2 года.
ВОПРОС: Сколько времени нужно на автоматизацию обязательных нормативов?
ОТВЕТ: Срок зависит от многих факторов:
- какие финансовые инструменты использует банк,
- сколько сейчас в 135й форме ненулевых кодов,
- эксплуатируется ли в банке хранилище данных «Контур», и загрузка каких портфелей договоров в него налажена,
- как планируется организовать процесс внедрения,
- и т.д.
В среднем, если есть общая цель и воля руководства, задача автоматизации расчета обязательных нормативов может быть решена за 1,5-2 года.
В конце прошлого года мы завершили проект автоматизации подготовки управленческой отчетности в АО «ГЕНБАНК».
Банк внедрил хранилище данных «Контур», автоматизировал подготовку управленческой отчетности и расчет трансфертных доходов и расходов.
Проект был реализован с целью повышения эффективности и прозрачности корпоративного управления и позволил:
✅ сосредоточить всю информацию о деятельности банка в едином хранилище данных,
✅ сократить время на подготовку управленческой отчетности, и повысить ее детальность и качество,
✅ обеспечить быстрый доступ руководства к необходимой отчетности,
✅ поддержать методологию внутренней отчетности, которую банк постоянно совершенствует, чтобы точнее оценивать прибыльность активных и пассивных ресурсов и анализировать финансовый результат по разным направлениям.
Подробнее о проекте и его результатах можно узнать на нашем сайте - https://iso.ru/ru/projects/03952-Avtomatizaciya-podgotovki-upravlencheskoj-otchetnosti-v-AO-GENBA.phtml
Банк внедрил хранилище данных «Контур», автоматизировал подготовку управленческой отчетности и расчет трансфертных доходов и расходов.
Проект был реализован с целью повышения эффективности и прозрачности корпоративного управления и позволил:
✅ сосредоточить всю информацию о деятельности банка в едином хранилище данных,
✅ сократить время на подготовку управленческой отчетности, и повысить ее детальность и качество,
✅ обеспечить быстрый доступ руководства к необходимой отчетности,
✅ поддержать методологию внутренней отчетности, которую банк постоянно совершенствует, чтобы точнее оценивать прибыльность активных и пассивных ресурсов и анализировать финансовый результат по разным направлениям.
Подробнее о проекте и его результатах можно узнать на нашем сайте - https://iso.ru/ru/projects/03952-Avtomatizaciya-podgotovki-upravlencheskoj-otchetnosti-v-AO-GENBA.phtml
«Нет адекватной замены офисных приложений на отечественные аналоги. Будем еще лет 5 работать на MS. А там поглядим…»
Наверняка такие разговоры ведёте регулярно, да? И давно пересмотрели все разрешенные заменители и не впечатлились?
Когда же банкам ждать отечественный офис? И можно ли не ждать?
Давайте немного разберемся.
Напомню, что русифицированные версии иностранного офисного ПО вышли на рынок аж в 93-94гг. Они быстро обошли отечественные аналоги по объемам продаж, а после кризиса 98-го года окончательно заняли доминирующее положение. Потом лет 15 разработкой отечественных аналогов MS офиса никто не занимался. Ну и правда, зачем российским ИТ-шникам вкладываться в заведомо неуспешный с коммерческих позиций софт?
Начиная с 2013-2014 гг., единичные разработки российского офисного ПО стали появляться. Определенное ускорение им придали сначала планы перевода госорганизаций на отечественный софт, потом санкции и уход с нашего рынка иностранных вендоров.
Но каким оказалось это ускорение? Мнимым или реальным?
Конечно, крупнейшими банками были проведены отдельные закупки отечественных офисных пакетов на большие миллиарды. Но по мнению остальных представителей финансовой отрасли это не повлекло прорывного увеличения качества российских разработок. Они совершенствуются гораздо медленнее, чем хотелось бы. И это тоже понятно – объективно масштаб задачи слишком велик и требует соответствующих сроков.
Что же делать тем, кто не готов закупать офисный софт для галочки и продолжает использовать запрещенный MS, как минимум, в процессах планирования, бюджетирования и подготовки внутренней и регуляторной отчетности банка?
Универсального выхода, увы, нет. Можно до последнего работать на сером ПО и надеяться на лучшее. Или экспериментировать с отечественными аналогами и ждать, когда они нарастят мощности.
Еще один способ обрести импортонезависимость на «поляне» MS Excel – заменить табличные технологии во внутренних процессах банка на специализированный управленческий софт из Реестра российского ПО. Например, планировать и контролировать расходы банка не в таблицах, а в отечественной системе бюджетирования.
Да, функционал любого прикладного ПО будет не таким универсальным, как у табличного редактора. Но он «заточен» решать специализированные задачи – например, бюджетирование или расчет аллокации расходов – намного лучше электронных таблиц.
Да, прикладной отечественный софт не закроет все потребности банка в офисном ПО. Но это и не его задача. Однако часть процессов управления банком обретут технологический суверенитет и выйдут на новый качественный уровень.
Тем более, что опыт использования управленческого ПО российской разработки в банках измеряется десятилетиями, и он гораздо успешнее, чем у новых офисных приложений.
Сегодня в Реестре российского ПО достаточно именно таких альтернатив. И уже имеется опыт внедрения и промышленной эксплуатации именно отечественных версий прикладного управленческого ПО в банках. Когда российский софт приобретен не для проформы, а реально интегрирован в управленческие процессы банков.
Подумайте. Возможно, это ваш вариант?
Наверняка такие разговоры ведёте регулярно, да? И давно пересмотрели все разрешенные заменители и не впечатлились?
Когда же банкам ждать отечественный офис? И можно ли не ждать?
Давайте немного разберемся.
Напомню, что русифицированные версии иностранного офисного ПО вышли на рынок аж в 93-94гг. Они быстро обошли отечественные аналоги по объемам продаж, а после кризиса 98-го года окончательно заняли доминирующее положение. Потом лет 15 разработкой отечественных аналогов MS офиса никто не занимался. Ну и правда, зачем российским ИТ-шникам вкладываться в заведомо неуспешный с коммерческих позиций софт?
Начиная с 2013-2014 гг., единичные разработки российского офисного ПО стали появляться. Определенное ускорение им придали сначала планы перевода госорганизаций на отечественный софт, потом санкции и уход с нашего рынка иностранных вендоров.
Но каким оказалось это ускорение? Мнимым или реальным?
Конечно, крупнейшими банками были проведены отдельные закупки отечественных офисных пакетов на большие миллиарды. Но по мнению остальных представителей финансовой отрасли это не повлекло прорывного увеличения качества российских разработок. Они совершенствуются гораздо медленнее, чем хотелось бы. И это тоже понятно – объективно масштаб задачи слишком велик и требует соответствующих сроков.
Что же делать тем, кто не готов закупать офисный софт для галочки и продолжает использовать запрещенный MS, как минимум, в процессах планирования, бюджетирования и подготовки внутренней и регуляторной отчетности банка?
Универсального выхода, увы, нет. Можно до последнего работать на сером ПО и надеяться на лучшее. Или экспериментировать с отечественными аналогами и ждать, когда они нарастят мощности.
Еще один способ обрести импортонезависимость на «поляне» MS Excel – заменить табличные технологии во внутренних процессах банка на специализированный управленческий софт из Реестра российского ПО. Например, планировать и контролировать расходы банка не в таблицах, а в отечественной системе бюджетирования.
Да, функционал любого прикладного ПО будет не таким универсальным, как у табличного редактора. Но он «заточен» решать специализированные задачи – например, бюджетирование или расчет аллокации расходов – намного лучше электронных таблиц.
Да, прикладной отечественный софт не закроет все потребности банка в офисном ПО. Но это и не его задача. Однако часть процессов управления банком обретут технологический суверенитет и выйдут на новый качественный уровень.
Тем более, что опыт использования управленческого ПО российской разработки в банках измеряется десятилетиями, и он гораздо успешнее, чем у новых офисных приложений.
Сегодня в Реестре российского ПО достаточно именно таких альтернатив. И уже имеется опыт внедрения и промышленной эксплуатации именно отечественных версий прикладного управленческого ПО в банках. Когда российский софт приобретен не для проформы, а реально интегрирован в управленческие процессы банков.
Подумайте. Возможно, это ваш вариант?
Как выглядит типичная аналитическая инфраструктура большинства банков? Это «зоопарк» из нескольких хранилищ данных масштаба отдельных подразделений, ETL-платформ, отчетных систем, BI-платформ и других систем.
Так уж исторически сложилось: подразделения внедряли системы аналитики только «под себя» и не учитывали наличия аналогичного ПО в банке. Да еще и процессы консолидации приводили к разрастанию числа схожих систем в организации.
Наверняка и ваш банк испытывает трудности с сопровождением подобного «зоопарка», а для решения различных аналитических и управленческих задач использует несогласованные данные из разных источников.
Сегодня, когда перед организациями стоит задача импортозамещения, есть шанс и рационализировать свою аналитическую инфраструктуру, и сократить расходы на ее поддержку. Стоит оптимизироваться и выстроить инфраструктуру по всем канонам на основе единого корпоративного ХД. Тогда все подразделения будут работать с одним источником выверенных и качественных корпоративных данных и многократно переиспользовать их для поддержки процессов управления и подготовки всех видов банковской отчетности: управленческой, регуляторной, аналитической.
Мы готовы вам в этом помочь. Обращайтесь.
Так уж исторически сложилось: подразделения внедряли системы аналитики только «под себя» и не учитывали наличия аналогичного ПО в банке. Да еще и процессы консолидации приводили к разрастанию числа схожих систем в организации.
Наверняка и ваш банк испытывает трудности с сопровождением подобного «зоопарка», а для решения различных аналитических и управленческих задач использует несогласованные данные из разных источников.
Сегодня, когда перед организациями стоит задача импортозамещения, есть шанс и рационализировать свою аналитическую инфраструктуру, и сократить расходы на ее поддержку. Стоит оптимизироваться и выстроить инфраструктуру по всем канонам на основе единого корпоративного ХД. Тогда все подразделения будут работать с одним источником выверенных и качественных корпоративных данных и многократно переиспользовать их для поддержки процессов управления и подготовки всех видов банковской отчетности: управленческой, регуляторной, аналитической.
Мы готовы вам в этом помочь. Обращайтесь.