В книжках давно и часто говорят, что ERP-системы должны быть онлайновыми — то есть, отражать состояние бизнеса в режиме «сейчас» или даже немного прогнозировать будущее; то же самое говорят и про управленческий учет.

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

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

Что нужно бизнесу. Пример 1


Рассмотрим некий тип операций: например, закупки. Каждая закупка проходит минимум три этапа информации о себе, которые фиксируются разными документами:

  • заявка на закупку, поданная сотрудником руководству компании;
  • заказ поставщику;
  • документ о получении товара от поставщика (рис. 1).


Рис. 1. Последовательность документов о закупке

Если мы строим отчеты за прошлый год — понятно, что в них нужно учитывать только фактические закупки (по данным документов «Поступление товара»).

Но когда мы строим оперативные отчеты (которые строятся за «сегодня», за «завтра», за текущую неделю/месяц, которые еще не завершились), нельзя дожидаться, пока в систему будут введены фактические поступления. Наряду с ними, нужно учитывать и заказанные, и заявленные закупки.


Рис. 2. Правила среза данных о закупках в отчетах и аналитике

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

Это касается как отчетов, так и любых расчетов (аналитики).

Например, при попытке создать новую заявку, нужно проверять доступные остатки лимитов закупок по статье:

Доступный остаток = Лимит на месяц — Сумма закупок за месяц

И здесь сумма закупок должна включать: фактически прошедшие поступления товаров; поступления, ожидаемые по заказам; заявки на закупку (как минимум, утвержденные) на данный месяц.
Брать последнюю информацию особенно важно, поскольку данные об одной и той же операции в разных документах могут различаться.
Это нормально: например, в заявке на закупку может предполагаться одна дата поступления товара, в заказе поставщику она может совпадать с заявочной, а фактическое поступление — пройти в другой день.

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

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

Пример 2 (посложнее)


Рассмотрим более сложный пример из другой сферы: управление платежами. Здесь точно так же используется три документа:

  • заявка на оплату (поданная руководству компании одним из подразделений);
  • платежное поручение (поданный компанией в банк «заказ» списать денежные средства с расчетного счета);
  • банковская выписка (отчетный документ от банка о фактически проведенном платеже).

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


Табл. 1

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

И, естественно, каждый платеж также должен попадать в аналитику только по самой «свежей» информации о нем.


В каких еще сферах может встречаться эта задача?


Возможно, во всех. Как минимум:

  • в производстве (где используется заказ на производство, план производства);
  • в транспортной логистике (заказ на транспортировку);
  • в управлении складом (расходные ордеры).

Как происходит сейчас


Обычно в ERP-системах логика ввода и хранения данных, отчетов и расчетов привязывается не к сквозному объекту учета («платеж» или «закупка»), а к отдельным документам. В результате складываются различные проблемные ситуации.

1) Отчеты и аналитика только по фактическим документам.

Утвержденные заявки и даже заказы при этом не учитываются, хотя, как мы уже рассмотрели выше, для бизнеса это необходимо.

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

3) Со временем, по мере возникновения потребности, фактические отчеты и расчеты иногда дорабатывают так, чтобы в них «попадали» еще и плановые документы. Но в них обычно не прописывают условие для плавной актуализации данных, например: [Если в выписке заполнена дата платежа — использовать её; если нет — использовать ожидаемую дату по заявке]. А значит, если в выписке пропущены какие-то отдельные поля — они не заместятся заявочными.

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

5) Информацию, полученную на этапе «звонок из банка», вписать элементарно некуда.
Для этого этапа нужно либо создавать отдельный документ, хотя с точки зрения логики бизнеса это не обосновано, либо позволять изменять уже зафиксированный документ (например, платежное поручение или даже заявку на оплату), что также неправильно: каждый документ должен хранить те данные, которые были актуальны на момент его фиксации.

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

Логика решения


Паттерн 1: все о платеже — в одну строку


Самый простой вариант решения — создать объект «платеж», всю информацию о котором записывать в строку: всё новые данные о нем просто дописываются всё правее и правее во всё новые столбцы.


Рис. 3. Продольная информация о платеже

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

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

Плюсы этого паттерна:

  • Такая таблица максимально приближена к логике бизнеса, и по ней легко проверять данные
  • В отчетах можно легко фильтровать нужные версии (этапы) данных о платеже, принимая/убирая из внимания те или иные столбцы
  • При такой конструкции dramatically проще анализировать расхождения между разными документами по одному платежу (поскольку сравнивать колонки одной таблицы в реляционных ERP очень несложно даже с помощью пользовательских конструкторов отчетов). Тогда как при другой архитектуре это может быть непросто

Минусы:

  • Такой подход хорош только когда число этапов (версий данных об операции) заранее известно. Но если этапов много и они могут периодически добавляться, в систему придется добавлять много столбцов, и каждый раз делать это программно. А в базах данных (SQL), как мы знаем, столбцы обходятся дороже строк

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

  • В этом варианте система сама по себе не будет «знать», что «Дата платежа» из заявки и «Дата платежа» из выписки — с точки зрения бизнеса один и тот же реквизит платежа. Таким образом, каждый раз при добавлении каждого столбца в таблицу, код каждого отчета и расчета скорее всего придется дописывать, добавляя в него чтение и интерпретацию этого столбца.

Паттерн 2: каждый новый этап данных — новой строкой


В более универсальном виде можно сделать так: записывать каждый новый этап (версию) данных не в столбцы, а в строки. При этом id у каждого платежа будет одним и тем же по всем строкам (см. нижняя таблица на рисунке).

А на основе этой таблицы будет постоянно обновляться срез, который содержит только одну — самую актуальную — версию данных по каждому реквизиту (см. верхняя таблица).


Рис. 4. Построчная информация о платежах

По этой схеме лучше всего видно, что задача в общем виде становится очень похожей на те задачи, которые решаются при построении хранилищ данных (DWH). При этом таблицу версий можно рассматривать по смыслу близкой к таблице-сателлиту в методологии Data Vault.

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

Плюс такой логики:

  • У каждого платежа есть единая структура реквизитов. Система будет знать, что дата — это дата, а банковский счет — это банковский счет
  • При этом для каждого платежа можно создавать сколько угодно новых этапов (в том числе, новых документов) — причем делать это значительно проще, чем в другой бизнес-архитектуре. Несложно сделать так, чтобы новые этапы создавались в пользовательском режиме

А вот дальнейшие плюсы и минусы будут зависеть от выбранного варианта реализации.
А теперь наконец о прикладной архитектуре

ВАРИАНТ РЕАЛИЗАЦИИ 2.1: ОБЕ ТАБЛИЦЫ ПОСТОЯННО СУЩЕСТВУЮТ В СИСТЕМЕ

Плюсы

  • Максимальная скорость формирования отчетов

Минусы

  • В отчетах нельзя будет задавать фильтры по версиям данных.

Подробнее
Если для разных отчетов нужно использовать разные версии данных (например: одни отчеты строятся только по фактическим выпискам; другие — включают также утвержденные заявки; третьи — также заявки, которые только находятся на согласовании и т.д.) — эту архитектуру придется усложнять. Например, в системе придется создавать разные срезы и вести их параллельно.

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

Основная трудоемкость:

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

ВАРИАНТ РЕАЛИЗАЦИИ 2.2: ТАБЛИЦА ВЕРСИЙ ПОСТОЯННО СУЩЕСТВУЕТ, АКТУАЛЬНЫЙ СРЕЗ — НЕТ

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

Плюсы:

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

Минусы
  • Низкая скорость. Проверять полную таблицу версий при каждом формировании отчета — достаточно долго. На больших объемах данных такая архитектура может вызывать критичное падение производительности отчетов и расчетов.

Основная трудоемкость:

При этом для всех отчетов можно разработать единый механизм получения данных (правила которого должны настраиваться пользовательском режиме)

Выводы


  1. Мы в общем виде сформулировали задачу: необходимость работы со сквозной информацией о хоз. операции (начиная с ее предварительного прогнозирования в графиках движения активов, заявках и внутренних заказах и заканчивая фактическими документами и их дальнейшими корректировками), постоянно срезая о ней самую последнюю информацию в разрезе каждого реквизита.
  2. На мой взгляд, важно помнить об этой задаче и проектировать способы ее решения заранее. Решать ее лучше на этапе разработки ERP-продуктов (тиражных и заказных), а не на этапе их внедрения и сопровождения.
  3. Очевидно, что кроме двух приведенных подходов, могут быть другие, в том числе промежуточные и смешанные варианты решения этой задачи. Было бы интересно послушать опыт других людей и обсудить оптимальные прикладные варианты, адаптированные к разным бизнес-условиям.
  4. В представленной постановке видно, что задача сводится к логике и проблемам, которые встречаются в сфере Data engineering. Надеюсь, что мои публикации помогут сблизить архитекторов транзакционных (классических ERP) и аналитических (DWH) систем в понимании задач управленческого учета.
  5. Если в будущем найдется время, было бы неплохо опубликовать более развернутое описание проблем и решений, с учетом ввода информации на разных этапах и возможного отказа от документов в их классическом понимании в ERP.

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

Рекомендации бизнесу


По каждой операции выясните:

  • отражается она только фактическим документом или также используются предварительные (заказы, заявки, графики)?
  • существуют ли другие предварительные события, которые вносят уточнения в предстоящую хоз. операцию (например, звонки от поставщика с уточняющей информацией о поставке), но которые не требуют создания на них отдельного документа?
  • с какой задержкой отражается фактический документ в информационной системе?
  • должна ли предварительная информация об операции учитываться в отчетах и расчетах; если да — какая именно и при каких условиях?

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

Рекомендации разработчикам и специалистам по внедрению


  1. Помните об этой проблеме всегда, когда приступаете к автоматизацию любой задачи оперативного учета и управления.
  2. Перед внедрением, заранее предупреждайте бизнес об этом проблеме (лучше письменно), учитывайте ее в бюджетах и оценках.
  3. Если связка разных этапов информации (документов и иных) по определенному сквозному виду операций понадобится — разрабатывайте эту связку до того, как начнете разрабатывать отчеты и алгоритмы. Чем позже вы начнете ее проектировать — тем сложнее и дороже она обойдется.

Рекомендации вендорам (разработчикам тиражируемых программных продуктов)


Не пожалейте ресурсов на системное решение этой проблемы. Или, по крайней мере, не создавайте архитектурных препятствий для ее решения «внедренцами».