Вступительное слово журналиста:

Я шёл в студию с одним вопросом: «Неужели в автоматизации учёта и отчётности можно придумать что-то новое?». Мой собеседник — Денис Гончаров, кандидат экономических наук, специалист по инструментальным методам, человек с карьерой от помощника аналитика в ЛАНИТ до исполнительного директора Газпромбанка, а ныне — фулстек-разработчик и стартапер, — задал встречный вопрос. С этого момента сценарий полетел в тартарары, а интервью превратилось в дискуссионный клуб. К счастью, в роли «группы спасения» выступил эксперт нашей рубрики, Константин, два десятилетия внедрявший те самые корпоративные учётные системы. Втроём мы докопались до парадокса, который все видят, но предпочитают не замечать: чем сложнее и дороже становится софт для учёта и отчётности, тем прочнее бизнес цепляется за старый добрый Excel. И, кажется, наш герой нашёл способ этот порочный круг разорвать.

ИНТЕРВЬЮ

Журналист: Коллеги, давайте сразу к сути, без воды. Все уже устали кричать о цифровизации и бросаются на ИИ, а базовая автоматизация учёта, кажется, не предлагает ничего нового. Денис утверждает, что у него есть радикальный ответ на это, но нужно ли действительно что-то менять? Константин, скажите — вам, как практику с 20-летним стажем, интересны красивые теории в духе мейнстрима или в этом что-то есть?

Денис Гончаров: Стоп, стоп, стоп (смеётся). Наверное, вы ждали от меня услышать что-то про искусственный интеллект? Ну, да, без этого трудно сегодня оставаться в тренде. Скажу больше, я действительно вижу несколько областей, где, например, LLM, несмотря на вполне объективный скептицизм, уже сегодня могут оказаться весьма полезны в автоматизации учёта и отчётности. Откровенно говоря, мне даже есть, что показать. Но, увы, и это не панацея до тех пор, пока мы не перестанем делать ещё больше тех же самых ошибок, пытаясь решить с помощью технологий отнюдь не технические проблемы. Кстати, я бы с удовольствием поговорил и об утилитарном применении ИИ в учёте и отчётности, но отдельно. А сегодня, уж простите, давайте обойдёмся без хайпа. Коллеги, чтобы не превращать беседу в мой часовой монолог об очевидных вещах, позвольте мне задать вам встречный вопрос. Что вы знаете об учётных хабах, кроме того, что они теоретически существуют? Я вообще это правильно называю?

Эксперт Константин: Денис задаёт очень правильный стартовый вопрос. Учётный, вернее, Accounting Hub — это не выдумка, а устоявшийся и вполне современный класс решений. Если говорить технически, это специализированный слой (субкнига), который автоматически применяет единые учётные политики к данным из десятков операционных систем и формирует проводки для главной книги. Их цель — гарантировать консистентность и прослеживаемость учёта в сложных средах.

Журналист: Константин, прекрасно, спасибо за лекцию. Но давайте начистоту: это теория из учебника или в России есть реальные примеры, где это работает? Или мы опять говорим про западные практики?

Эксперт Константин: Безусловно, есть. Самый показательный и масштабный пример, известный в профессиональной среде, — это проект в Федеральном казначействе. Там была проведена полноценная замена западного вендорского решения на отечественную платформу «Смарт Виста». Это классический пример импортозамещения именно систем класса Accounting Hub. Такие проекты редко бывают публичными, но они есть.

Журналист: Хорошо, государство — особая статья. А коммерческий сектор? Банки, которые должны быть на передовой. Константин, вы же с ними работали. Где Сбер, ВТБ со своими учётными хабами? Или это всё закрытые проекты, о которых нельзя говорить, потому что их… просто нет? Денис, кстати, в Газпромбанке занимался чем-то похожим, но я ни разу не слышал, чтобы он называл это «учётным хабом».

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

Эксперт Константин: Прямых публичных кейсов с громкими названиями мне не встречалось, и это абсолютно нормально. Детализации таких глубоких back-office проектов банки почти никогда не раскрывают. Однако, основываясь на практике, могу сказать, что потребность есть. Например, компания «Диасофт» — ключевой игрок на рынке софта для банков — как раз развивает новое поколение продуктов класса Accounting Engine, входящих в их платформу Digital Q.Accounting. Они фокусируются на автоматизации формирования проводок и построении управленческой отчётности. Это говорит о востребованности именно такого функционала.

Журналист: (обращаясь к Денису) Рынок движется, продукты развиваются. В чём тогда претензия?

Денис Гончаров: Коллеги, а вас не смущает, что все разговоры постоянно сводятся к учёту? Интересно, а есть на рынке вообще такие решения, которые можно было бы назвать не Accounting, а Reporting Hub? Лично я не слышал, но вполне допускаю, что мог что-то упустить.

Эксперт Константин: Смотря что иметь в виду. На рынке есть даже коммерческий продукт именно с таким названием. Но там речь идёт о готовом решении для white-label распространения дашбордов. Если же говорить об архитектурной составляющей, то это логичное развитие: если Accounting Hub обеспечивает единые правила генерации данных, то Reporting Hub отвечает за их консолидацию, трансформацию и доставку в финальные отчёты. Вендоры крупных ERP часто имеют такие модули для финансовой консолидации и отчётности, но не позиционируют их как самостоятельные продукты.

Журналист: Константин, а если кратко, чем принципиально отличаются требования к этим двум «хабам»? Где заканчивается один и начинается другой?

Денис Гончаров: Да, если кратко обобщить основные функциональные требования к Accounting Hub и Reporting Hub, если они есть, разумеется. Важно только ничего случайно не придумать.

Эксперт Константин: Если обобщать, ничего не придумывая, то для Accounting Hub всё очень чётко: приём больших объёмов транзакций, движок правил для автоматического создания проводок по РПБУ, МСФО и обеспечение полного аудитного трека. А для Reporting Hub в широком смысле: сбор данных, в том числе из Accounting Hub, исключение внутригрупповых оборотов, трансформация данных под правила отчётности и подготовка финальных форм для регуляторов и менеджеров.

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

Денис Гончаров: Вот, да. Напрашивается вывод, что Reporting Hub может выглядеть или как модуль консолидации, или как недоделанный Accounting Hub. А уже Accounting Hub, в свою очередь, выглядит как попытка спасти главного бухгалтера и финансового директора от нескольких «неправильных» учётных систем с помощью одной, но на этот раз уж точно «правильной». Забавно, но это, кстати, отражает и то, что в научных кругах происходит. В фундаментальной экономической литературе, да даже студентам в вузах преподают бухгалтерский, управленческий, налоговый учёт, а не отчётность. Всё это пережитки прошлого. Это раньше не было корпоративных хранилищ данных, а специализированные модули учётных систем либо отсутствовали вообще, либо не кастомизировались, либо не справлялись с нагрузкой. Сегодня разумнее говорить не о разных видах учёта, а о единой учётно-операционной технике и развитии бизнес-функции аналитического учёта. Подчёркиваю, именно бизнес-функции. Она очень часто находится в зачаточном состоянии и исторически подменяется параллельным управленческим учётом. А учёт-то должен быть только один, это разных отчётностей может быть много. Переиспользование слова учёт привело к тому, что и экономисты, и автоматизаторы просто привыкли плодить учётные системы или их модули под каждый вид отчётности. Кстати, именно эта привычка вкупе с повсеместной недоразвитостью бизнес-функции аналитического учёта породили другую чудовищную проблему, которую принято именовать «низким качеством данных». Опять-таки, кто и как с этим борется? Те же специалисты и точно такими же методами. Беда, прям.

Журналист: Денис, так, получается, что из-за ошибочного смещения фокуса на учёт, а не на отчётность, мы создаём технологических монстров, которые только усугубляют проблему? Константин, вы, как человек, который эти монстры внедряет, согласны с таким жёстким диагнозом?

Денис Гончаров: Видите ли, в функционал Accounting Hub, внедрение которого, судя по заявлениям, должно решать все проблемы, попадает очень много того, что, полностью или частично, дублирует другие системы. При этом мы так и остаёмся на уровне учёта, а того, что действительно нужно для подготовки отчётности, не видно. Я говорю о трансформации. И я этот термин в экономическом контексте сейчас употребляю, он не имеет никакого отношения к ETL/ELT. Трансформация применительно к отчётности часто требует профессиональных суждений, сбора дополнительных аналитических атрибутов, реклассификаций по экономическому содержанию, а не по юридической форме, дополнительных итерационных расчётов. И, кстати, это утопия — думать, что трансформация в отчётности нужна лишь для превращения РПБУ в МСФО. Есть, как минимум, гэпы между публикуемой и регуляторной отчётностью. Есть ещё препятствия похуже, которые никакой автоматизацией не решить, — разные GAAP в международных группах и разные виды бизнеса внутри одной группы, когда внедрить единую учётную политику просто невозможно. Но с этим не все сталкиваются. Я хочу сказать, что все эти задачи не решаются какими-то более-менее простыми шаблонами и правилами. Что же остаётся для подготовки отчётности? Например, откат обратно на уровень ERP. Скорее всего, сразу же проявится та самая пресловутая проблема низкого качества данных. Другой вариант — скачок сразу в BI. Но BI просто технически не в состоянии делать такие вещи, как трансформация, потому что он придумывался для визуализации данных, а не для их производства. Вот проблема, с которой нужно бороться.

Эксперт Константин: С точки зрения чистоты архитектуры — Денис прав. На практике же из-за сложности предметной области системы Accounting Hub действительно часто «распухают». А задача сложной экономической трансформации данных либо остаётся нерешённой, либо перекладывается на кастомные разработки и те самые BI-инструменты, что ведёт к дублированию логики. Это известная боль, с которой сталкиваешься в проектах.

Журналист: Значит, сама терминология нас подводит? Accounting Hub — неверное, не совсем подходящее название? Мы двадцать лет называли вещи неправильно?

Денис Гончаров: Тут проблема шире, чем просто некорректное название класса систем. Думаю, что мы уже готовы разглядеть саму её суть. Я потому в начале беседы и спросил, есть ли такое теоретическое понятие, как Reporting Hub вообще. Очевидно, что первичная регистрация данных осуществляется в OLTP/ERP — без них никуда не деться, подготовка финальных отчётов — это функция BI, а посередине, по сути, зияющая пустота, которую иногда пытаются заполнить монстрами из склеенных ERP/ETL/DWH/BI или Accounting Hub.

Журналист: И как же тогда заполнить эту пустоту? Нужен новый термин и новый класс систем? Как бы они тогда назывались? Financial Transformation Hub?

Денис Гончаров: Знаете, а мне понравилась мысль с Transformation Hub. Введение третьего нового термина вместо Accounting (который, по моему убеждению, следует относить только к OLTP/ERP) и Reporting (который часто ошибочно ассоциируют только с BI) позволит навести порядок в головах и устранить недопонимание. При этом у нас уже есть в арсенале ETL и DWH — очень важные компоненты, которые объективно существуют сами по себе и часто используются посередине (в той самой пропасти), но они не могут решить проблему трансформации. Правила ETL слишком просты для трансформации данных в экономическом понимании термина. И это понятно, ведь ETL должны быстро и гарантированно обрабатывать гигантские массивы данных — это их основная функция. DWH, да простят меня коллеги, — это просто голая база данных. С её помощью мы можем создать единое пространство обо всех учётных событиях за все времена, но не более того. Я считаю, что на общем фоне Accounting Hub — это такой динозавр. Достаточно просто добавить в связку ETL/DWH/BI недостающий компонент для трансформации данных в экономическом смысле. Но мне не нравится добавление слова Financial, потому что тогда появится фокус на финансах. А как же, например, управление рисками? Для риск-ориентированного управления нужно всё то же самое!

Журналист: Тогда, может быть, Transformation Layer в DWH? Константин, что скажете? Как, по-вашему, стоит развивать эту идею, или это просто красивая философия?

Эксперт Константин: Концептуально идея Transformation Layer логична. ETL — это инженерная утилита для перемещения данных, DWH — хранилище. Поэтому для применения сложных бизнес-правил, финансовой консолидации, расчёта рисков в DWH нужен отдельный «интеллектуальный» слой. Но сразу же видна слабая сторона — попытка стандартизировать всё это многообразие. На рынке есть такие системы, как OFSAA, которые, по сути, уже пытались стать таким слоем, но, опять же, превратились в дорогие и неповоротливые монолиты. Не думаю, что они в этом смысле чем-то лучше Accounting Hub.

Журналист: Денис, ты слышишь? Эксперт подтверждает, что проблема осознана, но решения получаются слишком громоздкими. При этом ты тоже против сужения до финансов. Не пора ли признать, что идеального решения не существует?

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

Денис Гончаров: Кажется, вы начинаете думать, как я. Согласен, что речь должна идти о Transformation Layer. И я согласен с критикой систем вроде OFSAA. В первую очередь, из-за их ограниченной доступности и высокой стоимости владения. Так, какой же софт сегодня выполняет эти сложнейшие функции? Отчётность ведь регулярно выпускается! Сами догадаетесь?

Журналист: Наверное, что-то вроде тех самых комплексных аналитических платформ, о которых говорил Константин, но разработанных в России?

Денис Гончаров: Я говорю об Excel. Понимаете, в чём тут вся ирония?

Журналист: (Саркастично) Ты шутишь? Выходит, что ответом на все наши сложные архитектурные дискуссии является почти бесплатный инструмент, который установлен на каждом офисном компьютере? Константин, вы, как практик, согласны с этим горьким выводом? Это провал всей индустрии?

Эксперт Константин: Если так на это посмотреть, что глобальным Transformation Layer является Microsoft Excel… Тогда это не шутка, а констатация: по различным оценкам, более 90% компаний используют его для FP&A, эксперты реализуют в нём сложнейшую логику. Ирония в том, что Excel — это вообще-то антитеза всем принципам хорошей архитектуры: ручной труд, ошибки, отсутствие аудита, нулевая масштабируемость. Его доминирование — симптом:
1) спрос на Transformation Layer объективно огромен;
2) классические корпоративные системы и простые ETL не дали бизнесу нужной гибкости.
С помощью Excel бизнес вручную латает дыру в корпоративной ИТ-архитектуре. Другими словами, это грубая, но точная правда. Я видел сотни проектов, где финальные, самые важные расчёты для принятия решений делаются в Excel. Это индикатор провала попыток вендоров корпоративных систем дать эксперту адекватный инструмент.

Журналист: И как же выйти из этого тупика? Делать новые, ещё более сложные системы? Или идти по пути low-code, чтобы бизнес сам собирал себе логику, раз уж он так любит Excel?

Денис Гончаров: Вот! Уже очень близко. Но тут важно опять не сделать типичную ошибку технократов, упрощающих всё до платформ low/no-code. Это тоже путь в никуда. По сути, экономистов, как детей малых, вынуждают работать с картинками в GUI. Так и хочется предложить коллегам самим с помощью интерфейса drag-n-drop составить отчёт по форме ОКУД 0409303.

(прим. редакции: ОКУД 0409303 «Сведения о ссудах, предоставленных юридическим лицам» — одна из многочисленных форм ежемесячной банковской отчётности, состоящая из 10 разделов, включающих в общей сложности 116 колонок, которые глубоко взаимосвязаны и, как правило, рассчитываются на основании дополнительных разработочных таблиц, не включаемых в финальный отчёт).

Журналист: Тогда что? Усилить тот самый Excel, но как-то иначе? Использовать что-то вроде корпоративных Google Sheets или Яндекс Таблиц? Или вы предлагаете вернуться к бумажным гроссбухам?

Денис Гончаров: Не совсем. Электронные таблицы онлайн немного помогут снять архитектурный изъян в плане повышения надёжности хранения данных и появления хотя бы каких-то элементов контроля версий и разграничения доступа. Но глобально это ситуацию не улучшит. По крайней мере, полноценной командной работы, прозрачности трансформации данных и масштабируемости мы так точно не добьёмся. И заметьте, облачные решения подойдут далеко не всем, если речь идёт об обработке конфиденциальных данных. Я хочу предложить вариант получше. Как вам при достигнутом понимании вопроса такая идея: новый класс систем WiS (wide spreadsheets), то есть «огромные электронные таблицы». Он же идеологически и функционально, как ещё один типовой источник-приёмник данных для DWH, выполнит роль того самого Transformation Layer. Это как "Excel для Big Data". Главная мысль:
1) конструируем плоские таблицы в интерфейсе, как в Excel (без low/no-code, но и без программирования), а система уже сама создаёт и модифицирует соответствующие структуры для хранения данных в реляционной СУБД с разграничением доступа, контролем изменений и поддержкой полноценной командной работы;
2) все вычисления так же, как в Excel, делаются формулами, задаваемыми для колонок (опять-таки без no/low-code и программистов);
3) гибкие фильтры и, конечно, свободный экспорт-импорт через Excel.

Журналист: Константин, как эксперт, что ты скажешь на это? Это утопия или рабочий концепт, который может сдвинуть гору?

Эксперт Константин: Это очень смелая и принципиально верная по цели идея. Попытка дать бизнесу его родной инструмент, но с промышленной подкладкой. Главные вызовы — производительность вычислений на больших данных и работа со сложными, не плоскими структурами данных. Если эти вызовы можно решить, идея имеет право на жизнь.

Журналист: Денис, последний вопрос для ясности, и я жду чёткий ответ. Вы предлагаете заменить все существующие системы — ERP, DWH, BI — или встроиться между ними? Ваш WiS — это убийца или санитар?

Денис Гончаров: Это ключевой момент. Как раз, об этом мой стартап под названием BIRD. И это не какой-то прототип, а готовое вендорское решение класса WiS, которое уже работает. Для BIRD нет никакого смысла подменять собой другие компоненты корпоративной ИТ-архитектуры. Даже Excel никуда не денется. Просто он, наконец, сможет вернуться к своей естественной роли, для которой он идеален: экспериментальные расчёты и одноразовые красиво оформленные табличные отчёты. А всё, что одновременно требует сложной трансформации данных и масштабирования, BIRD возьмёт на себя. В этом смысле я изначально проектировал его как компаньона для OLTP/ERP, MDM, BPM/EPM/CRM, ETL, DWH, BI. Разумеется, за счёт повышенной гибкости WiS, унаследованной от класса систем-прародителей (электронных таблиц), BIRD сможет подставить технологическое плечо в случае отсутствия какого-либо компонента корпоративной ИТ-архитектуры и даже действовать как самостоятельное прикладное решение. Но всё-таки идеальное постоянное место BIRD — Transformation Layer внутри DWH, либо самостоятельный компонент. Это остаётся на выбор корпоративного ИТ-архитектора в каждом конкретном случае.

Журналист: Константин, финальный комментарий? Вы верите в это?

Эксперт Константин: Это эволюционный, а не революционный подход. Если такой «компаньон» сможет стать стандартным слоем, он действительно может сократить разрыв между бизнесом и IT, но для этого ему нужно доказать свою жизнеспособность в реальных проектах сложности, сравнимой с теми, о которых мы говорили в начале.

Денис Гончаров: Благодарю. Уверяю, мы с BIRD к этому полностью готовы.

Журналист: Что ж, наша дискуссия началась с вопросов, на которые, казалось бы, нет ответа, а закончилась чётким архитектурным манифестом с готовым программным решением. Кажется, новое — это иногда хорошо забытое старое, но доведённое до своего логического конца.
Спасибо за беседу.

Послесловие журналиста:

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

P.S.

Вы, наверняка, задались вопросом — кто эти замечательные ребята: напористый журналист и рассудительный эксперт Константин? В каком финтех-блоге, подкасте или журнале можно найти ещё материалы с их участием? И, да, вы правильно поняли, что обещание рассказать про ИИ — это рекламный ход. Будьте уверены, я сдержу обещание.

Если вы читаете это, значит, мои контакты у вас есть (см. страницу «Обо мне»).

Пишите, звоните, не стесняйтесь. Договоримся о встрече живьём или онлайн. Всё покажу и расскажу. С удовольствием помогу сделать пилотный проект с BIRD. Поверьте, вы можете себе это позволить.

Спасибо, что дочитали до конца!