Облачная консолидация: стоит ли ей доверять?

Financial Consolidation and Close — программный продукт для подготовки консолидированной отчетности сделанный на основе Oracle EPM Cloud. Это удобный и интуитивно понятный интерфейс, преднастроенная модель данных и встроенные функции для организации процесса консолидации.

Так как продукт реализован на облачной инфраструктуре, он не требует дополнительного ПО и серверов, его можно быстро внедрить, он требует минимальной ИТ-поддержки. Регулярные ежемесячные апдейты позволяют получать все последние нововведения и багфиксы автоматически без запрашивания специальных патчей, как это было в on-premise продуктах.

FCCS по умолчанию позволяет настраивать базовые группы пользователей для безопасности и разделения доступа к задачам и бизнес-процессам: группа администраторов управляет техническими настройками, стандартные пользователи загружают и консолидируют данные, есть пользователи с доступом только на чтение данных.

При проектировании системы со сложным бизнес-процессом и большим количеством пользователей часто необходимо распределение и гибкая настройка исполнителей и согласующих. Инструмент Task Manager вFCCS позволяет настроить процесс управления закрытием, включает в себя списки задач с графиками выполнения, ответственными и различные этапы согласования для гибкого управления рабочим процессом.

БОЛЬШОЙ ПЛЮС: ПРЕДНАСТРОЕННАЯ МОДЕЛЬ ДАННЫХ

При создании приложения FCCS вы получаете готовую преднастроенную модель данных, которая содержит в себе, по аналогии с HFM, основные обязательные измерения (Entity, Account, Scenario, Year и Period…), а также несколько пользовательских измерений, которые нельзя удалить или заменить (как показывает практика, без таких измерений не обходится ни одна система консолидации).

На наполняемость измерений влияют опции и параметры, определяемые в процессе создания приложения. Например, можно выбрать подход к формированию плана счетов: Traditional Approach, который рассчитывается как разница между активами и суммой обязательств и капитала, или Net-Asset Approach, который позволяет отслеживать чистые активы равные разнице между активами и обязательствами.

Пример

Рассмотрим два подхода к структуре плана счетов. Итоговые суммы по активам, обязательствам и капиталу одинаковые — отличается только их расположение в иерархии баланса.

В традиционном подходе мы имеем в отдельной ветке FCCS_Total Liabilities and Equity сумму обязательств и капитала, которая затем с противоположным знаком поднимается в итоговый баланс, и получаем FCCS_Total Balance Sheet-Traditional Approach = FCCS_Total Assets - FCCS_Total Liabilities and Equity.

В другом подходе, активы и обязательства собираются вместе в отдельной ветке FCCS_Net Assets для получения чистых активов, из которых затем вычитается сумма капитала при агрегации в итоговый баланс.

Несмотря на различия в структуре, и в том, и в другом подходе итоговая сумма баланса компании получается одна и та же – в данном примере баланс сходится в ноль.

При создании приложения есть возможность добавить специальное измерение, предназначенное для разделения локального учета компании и МСФО отчетности – Multi-GAAP (Рисунок 3). Как показывает практика, ни одна система консолидированной отчетности не обходилась без отдельного измерения, предназначенного для трансформационных корректировок, разделяющих индивидуальную и МСФО отчетность компаний. Измерение Multi-GAAP предназначено именно для этих целей, так как помимо фиксированных системных элементов туда можно добавить все специфичные для конкретной компании корректировки. В нашей практике были случаи, когда в корректировках не было необходимости: в систему отчетные данные попадали уже в формате МСФО — в этом случае измерение Multi-GAAP не требуется, и его можно просто не включать при создании приложения.

Все стандартные измерения содержат предустановленные системные элементы, не подлежащие удалению или изменению, но при этом не ограничивающие добавление новых, специфичных для конкретной модели, элементов. Например, в стандартном измерении Movement по умолчанию уже содержится баланс на конец периода, включающий в себя баланс на начало периода и сумму движений. В то же время, система не запрещает расширять структуру добавлением пользовательских элементов.

Пример

Ниже представлена сравнительная таблица измерений в FCCS и его on-premise аналога HFM

При внедрении систем на базе HFM по итогу обычно получалась такая же модель, которую FCCS предоставляет «из коробки» — это позволяет сократить время внедрения без значительной потери гибкости.

КОНСОЛИДАЦИЯ: КАК ЕЕ НАСТРОИТЬ?

Настройка процесса консолидации в FCCS состоит из кастомизации модели данных (метаданных), настройки процесса загрузки, написания бизнес-правил для необходимых расчетов и подготовки отчетных форм. Это минимально необходимые шаги для получения работоспособной системы консолидированной отчетности.

МОДЕЛЬ ДАННЫХ

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

При разработке FCCS Oracle постарался учесть все наиболее стандартные и типичные для систем консолидации вещи, при этом, не создавая существенных ограничений на кастомизацию. При создании приложения в нем «из коробки» уже содержится основа модели данных, которую необходимо дополнять для целей конкретного бизнеса.

FCCS позволяет добавлять до четырех пользовательских измерений. На первый взгляд кажется, что этого мало. На самом деле это не так: система уже содержит в себе измерения, которые обычно добавляются как пользовательские (Movement, Data Source и все в этом духе).

Перед тем, как создавать приложение и настраивать модель, необходимо тщательно продумать ее наполнение и количество пользовательских измерений, так как по умолчанию их максимальное количество – два. Для того, чтобы иметь возможность добавить четыре кастомных измерения, необходимо запросить у Oracle установку специального патча на систему. Для владельцев подписки он бесплатный, но его нельзя установить на работающую систему, так как после его установки приложение необходимо создавать и настраивать заново с нуля.

В остальном настройка модели ничем не отличается от настройки аналогичных многомерных систем для консолидации. Можно создавать базовые элементы измерений, добавлять динамические группировки элементов, писать расчетные формулы на элементах и создавать альтернативные отчетные группировки. Есть тонкие моменты, которые нужно учитывать: например, некоторые преднастроенные элементы запрещают добавление потомков или даже ввод данных. Если помнить о подобных ограничениях при настройке модели, они не создают сложностей и значительно упрощают взаимодействие с системой за счет отсутствия лишних настроек.

Кейс из жизни:

В недавнем релизе Oracle выпустил обновление, меняющее подход к расчету сальдо на начало периода для счетов. После релиза компания получила шквал жалоб от недовольных клиентов, которым новая функциональность сломала логику работы всей системы.

Нашей первой реакцией на эту новость была мысль «надо скорее бежать и чинить систему у клиента пока там все не сломалось». Но после анализа доработки мы выяснили, что никуда бежать и ничего чинить в реализованной нами системе не нужно: мы не делали кастомизаций противоречащих логике заложенной в FCCS и выпущенное обновление никак не сказалось на нашем приложении. Мораль: не стоило паниковать раньше времени — имело смысл взвешенно изучить суть нововведений.

В настройке — например, плана счетов — следует помнить выбранный при создании приложения подход к формированию баланса. При выборе подхода Traditional Balance Sheet Approach в итоговый баланс сумма всех активов поднимается со знаком «+», а сумма всех обязательств – со знаком «-». При этом базовые счета и активов, и пассивов хранят все данные со знаком «+». Это значит, что при добавлении новых счетов внутри иерархии в балансе необходимо придерживаться этой же логики. Такое поведение заложено в системе по умолчанию, но в одном из последних релизов было выпущено обновление, позволяющие изменять логику и хранить в системе счета обязательств со знаком «-», если вы предпочитаете этот подход.

ЗАГРУЗКА ДАННЫХ

После создания модели данных настраиваем процесс загрузки данных в систему. Загружать данные в FCCSможно различными способами. В приложение встроен облачный Data Management, являющийся упрощенным аналогом on-premise FDMEE. В нем отсутствует возможность писать скрипты для обработки данных или интегрироваться с базой данных, но он позволяет загружать содержимое различных файлов, настраивать мэппинги элементов и создать проверочные отчеты над загружаемыми срезами. Можно загружать данные в FCSS и через on-premise FDMEE, но в облачную подписку он не входит. В само приложение встроена возможность прямой интеграции с другими облачными сервисами. Ну и, кроме того, всегда остается старая добрая возможность ручного ввода данных через Smart View или web-формы.

В последних релизах Oracle выпустил новый интеграционный инструмент — EPM Integration Agent, который является неким дополнением к встроенному облачному Data Management и обещает функциональность, расширяющую его до on-premise FDMEE.

БИЗНЕС-ПРАВИЛА

Пишем спецификации пользовательских расчетов с последующей реализацией их в виде бизнес-правил в системе.

Расчеты в FCCS реализуются на специальном языке для многомерных хранилищ данных – Essbase. Технология не является новой, она уже давно используется в приложениях Oracle Hyperion Planning. В облаке технология Essbase ничем не отличается от on-premise версии: логика построения расчетов, синтаксис и используемые функции остались теми же.

Так как приложение уже содержит встроенные основные расчеты (трансляция валют, элиминация ВГО и консолидация), точки выполнения пользовательских расчетов строго определены и зафиксированы. Но это не вводит существенных ограничений и влияет только на порядок обработки данных в процессе консолидации. Можно добавить блок расчетов в бизнес-правило, выполняющееся на уровне базовой компании, или в другое правило, выполняющееся на уровне расчета вклада в группу.

Некоторые готовые расчеты можно включать или выключать на различных сценариях: правило, рассчитывающее балансировку в случае расхождения баланса, может быть отключено совсем или на определенных сценариях.

ОТЧЕТНЫЕ ФОРМЫ

Отчетные формы необходимы как для проверки загруженных данных, так и для просмотра итогового консолидированного результата.

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

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

Конечно, готовых отчетных форм не достаточного для полного анализа данных и для просмотра каких-либо специфичных кейсов, поэтому всегда есть возможность создать новые отчеты, отвечающие конкретным требованиям. Встроенные формы просты в использовании и настройке, но они, скорее, подходят для быстрого анализа данных, чем для подготовки строго форматированной книжки отчетов. Для более гибкого и настраиваемого форматирования лучше использовать специальный инструмент – Financial Reporting.

ИЗ КОРОБКИ: ГОТОВЫЕ КОНСОЛИДАЦИОННЫЕ ИНСТРУМЕНТЫ

Чтобы кастомизировать процесс консолидации без сложных скриптов и бизнес-правил, в системе есть специальные функциональные блоки.

ЭЛИМИНАЦИЯ ВГО. РАБОТАЕТ «ИЗ КОРОБКИ»

Тяжело представить себе систему консолидации без учета и автоматического исключения внутригрупповых операций дочерних компаний группы. В FCCS такой инструмент есть, он не требует ручного написания сложных бизнес-правил. Для настройки элиминации требуется выбрать компании, которые могут являться контрагентами, и выставить у них соответствующий признак, затем выбрать счета, по которым могут проходить ВГО и назначить им plug-счет для учета расхождений. Всё. При корректном выставлении всех необходимых настроек, при выполнении стандартного правила Consolidate будут автоматически рассчитаны все элиминационные срезы и внутригрупповые операции будут исключены из вклада в группу.

НАСТРАИВАЕМЫЕ КОНСОЛИДАЦИОННЫЕ КОРРЕКТИРОВКИ

Корректировки никак не влияют на индивидуальную отчетность компаний и выполняются только на уровне вклада в группу. В системе предусмотрены правила — например, расчет приобретения или выбытия компании и доли миноритариев. Все они являются необязательными, каждое можно включить или выключить отдельно от других, а также скопировать и модифицировать под свои потребности.

ГОТОВЫЕ МЕТОДЫ КОНСОЛИДАЦИИ

В приложении предусмотрено несколько готовых методов консолидации: Subsidiary, Proportional, Discontinued и другие. Они автоматически подставляются в зависимости от введенного процента владения, процента консолидации компании и доли миноритариев. От пользователя в данном случае требуется только ввести соответствующие значения в специальной форме.

Естественно, для корректного использования описанных инструментов потребуется понимание конечной бизнес-модели и технологических особенностей работы приложения FCCS.

ПОЛЕЗНЫЕ ФИЧИ

У FCCS есть много плюсов, в частности — некоторые функциональные блоки, которые можно назвать преимуществами системы.

РАСЧЕТ OPENING BALANCE

Один из базовых расчетов в системах для финансовой отчетности — расчет сальдо на начало периода по балансовым счетам. В основном все системы консолидации предназначены для МСФО отчетности, где данные удобнее всего загружать и видеть накопительно с начала года (Year-To-Date). На практике так же часто возникают случаи, когда помимо представления Year-To-Date в системе необходимо иметь корректные обороты за период (Periodic). И если с отображением загруженных данных проблем не возникает (в зависимости от того, в каком представлении были загружены данные, накопительно с начала года или периода второе представление рассчитается автоматически), то с расчетом сальдо на начало периода обычно всё сложно.

В on-premise аналоге FCCS – Hyperion Financial Management — вопрос расчета корректного баланса на начала в обоих представлениях всегда был одним из самых проблемных. HFM не позволяет реализовать подобный расчет. Самым оптимальным решением в этом случае было создавать 2 альтернативные ветки движений с двумя начальными балансами – один для просмотра только в YTD, другой – только в Periodic. В FCCS такой расчет предоставляется «из коробки» и позволяет видеть корректный начальный баланс на одном и том же элементе в обоих представлениях.

В измерении Movement присутствует pre-seeded элемент для хранения начального баланса, который рассчитывается автоматически для всех балансовых счетов и равен сальдо на конец предыдущего года в представлении YTD и сальдо на конец предыдущего периода в представлении Periodic. Расчет реализован на одном элементе, что позволяет смотреть корректную отчетность в обоих представлениях по одно иерархии движение и избежать дублирования информации.

АВТОМАТИЧЕСКАЯ БАЛАНСИРОВКА ДВИЖЕНИЙ

Еще одним часто автоматизируемым расчетом является балансировка движений при поэтапной загрузке данных, когда на первом этапе загружается целевое сальдо на конец периода без детализации по конкретным движениям, а на втором этапе отдельно загружаются движения статей. При этом, не всегда сумма движений полностью совпадает с целевым сальдо на конец, так как не под все обороты выделяются отдельные элементы в справочнике. В FCCS у каждого счета предусмотрено свойство, определяющее движение, используемое для балансировки при несовпадении целевого сальдо на конец периода с суммой загруженных движений.

АВТОМАТИЧЕСКИЙ РАСЧЕТ RE

При разработке систем консолидированной отчетности обычно требуется создавать счета для учета нераспределенной прибыли текущего и предыдущих периодов, а затем реализовывать расчет, формирующий прибыль прошлых периодов за счет добавления к ней прибыли текущего периода. В FCCSтакой механизм также предоставляется «из коробки». В иерархию капитала уже добавлены счета для учета НРП за текущий и за прошлый период. Перенос значения на счет FCCSRetained Earnings Prior происходит автоматически и формируется корректно в зависимости от View (YTD или Periodic).

АВТОМАТИЧЕСКИЙ РАСЧЕТ РЕЗЕРВА ТРАНСЛЯЦИИ

Часто корпорациям с большим географическим разбросом дочерних предприятий нужно загружать данные в различных валютах на различные компании с последующей трансляцией в валюту отчетности всей организации. При трансляции движений балансовых статей по среднемесячному курсу и трансляции сальдо по курсу на дату всегда приходится рассчитывать резерв, который обеспечивает отсутствие расхождений.
Раньше такой расчет писали вручную и создавали для этого дополнительные элементы в иерархии движений. При внедрении FCCS не нужно тратить на это время — он есть в системе «из коробки». На специальном движении FCCSMvmtsFXMovement формируется значение, пересчитываемое по разнице курсов, таким образом обеспечивается корректное сальдо на конец периода.

ТЕХНИКА ВОПРОСА: ЕЩЕ БОЛЬШЕ ПЛЮСОВ

Поговорим о технических деталях, которые делают работу с инструментом значительно удобнее.

НАДСТРОЙКА ДЛЯ РАБОТЫ С МЕТАДАННЫМИ В SMART VIEW

При внедрении больших многомерных систем анализа данных всегда встает вопрос о том, как обеспечить удобную для конечных пользователей работу с метаданными, чтобы они сами могли быстро вносить нужные изменения, загружать в систему и при этом не бояться всё сломать. Обычно это вопрос решался написанием сложных макросов для Excel файлов, преобразующих выгруженный из системы формат метаданных в понятный для конечного пользователя формат — и обратно. Естественно, такая процедура всегда занимала много времени и ресурсов.

В облачных продуктах такой проблемы больше нет. В комплекте с каждым продуктом идет специальная надстройка для Smart View, позволяющая вносить изменения в метаданные приложения сразу с листа Excel-файла без использования каких-либо макросов или специальных программ. Все что нужно – скачать и установить надстройку, подключиться через Smart View, открыть измерение и внести туда изменения (Рисунок 4). Чтобы загрузить их в систему достаточно нажать кнопку Submit на панели Smart View.

Работая через такую надстройку, очень сложно нанести непоправимый ущерб приложению, потому что она не позволяет удалять элементы. То есть даже если пользователь случайно удалит строку с элементом и нажмет Submit для загрузки изменений в систему, удаление не сохранится.

АВТОМАТИЧЕСКОЕ СОЗДАНИЕ БЭКАПОВ И АУДИТ ДЕЙСТВИЙ В СИСТЕМЕ

Еще одним техническим преимуществом является автоматическое ежедневное создание бэкапов всей системы и аудит действий пользователей.

Обычно процесс создания резервной копии системы и восстановление из нее занимает много времени и требует глубокого понимания технологий и взаимодействия компонент восстанавливаемой системы. Не всякий пользователь с этим справится.

В облаке процесс значительно упрощен. Резервная копия всей системы каждый день выгружается автоматически в виде единого архива. Для восстановления системы не требуется собирать кучу различных файлов из разных расположений и загружать их в строго определенной последовательности – всё содержится в одном файле, который нужно сохранить себе на компьютер и полностью восстановить из него систему по инструкции.

Также система автоматически фиксирует все выполняемые пользователями действия. Там можно увидеть, например, кто и когда запустил какое-либо расчетное бизнес-правило или же вручную изменил данные в системе. Записи можно отфильтровать по дате и категории действия и выгрузить в Excel для дальнейшего хранения или анализа. Конечно, такой функционал не заменяет полноценное логирование, в котором отображались возникающие в системе ошибки, интеграции с внешними системами. Но он прост в настройке и удобен в использовании через web-интерфейс, а значит, вполне может использоваться конечными.

ВЫВОД

В приложении FCCS хорошая преднастроенная модель данных предоставляет множество полезных функций «из коробки», которые раньше реализовывались и автоматизировались вручную. Конечно, у них есть свои ограничения и тонкие моменты, но, если их помнить и учитывать при настройке, они не только не создадут сложностей, но и заметно облегчат процесс внедрения и пользования системой.

Инструмент менее гибкий по сравнению с, например, on-premise аналогом HFM, но эта особенность не делает его хуже: встроенная модель является достаточно правильной с точки зрения бизнес-логики. Все это и отсутствие необходимости в закупке железа и дополнительного ПО значительно упрощает процесс внедрения и требует минимальной ИТ-поддержки.

Cтоит ли доверять FCCS построение консолидированной отчетности? Да, стоит. Так что вперед, строить консолидацию в облаках!