In the previous post, The Value of Data Part 1: Business Functionality I discussed the costly process of capturing attributes of business events, and the value in understanding them over time. In this post I’ll discuss various types of business events and their potential impact and use in financial and analytical processes.

Data Supply Chain Defined

Layers of a Data Supply Chain

A data supply chain is defined as a process that turns recorded business events and transactions into analytical outputs. The term “supply chain” is used to reflect that, like a manufacturing supply chain, data goes through various steps to become a finished good.

Data supply chain unfortunately have not undergone the same kind of transformation that happened with Just-In-Time inventory systems; they are for the most part stuck in the Henry Ford assembly line model, whereby every question to be answered has to be defined when the system is built, and once started, they only produce that specified good. This results in “shortages” of analytical outputs, and at times “inventory obsolescence” when the analytical outputs become less useful.

>>> Related Post: Metric Engine Monograph <<<

Simplistic View

A simple view of our financial analytical processes is that all business events are captured in some operational system or subledger, stored in a database of some kind, and then accumulated to produce the financial, management, risk and other analytical reports.

This is true for perhaps most of the financial data, but it ignores broad sets of data also used in financial and analytical processes. These additional events, be they temporal events, accounting events, or analytical events, serve important purposes in our analytical processes.

Unlike the original business events or transactions, these events are typically not entered by a person, or captured through a webpage, an app, a cashier, or clerk. They typically are in reaction to or build upon the business events and transactions. They are more automated, created through rules or code.

But as emphasized in the Business Functionality post, these types of events are also aggregated to produce perspectives over time. And the hard fought battle of creating them, and translating from the attributes of the original transactions into them, can be wasted if there is no way of aggregating them to positions efficiently.

Again, the greatest business need is the ability to analyze these types of transactions as well.

Let’s describe these categories of events beginning with perhaps the easiest to understand, the analytical events.

Analytical Events

Analytical events tend to be created near the end of a data supply chain. They might be something as simple as recasting business events into a different form for a one time or narrow use.

Report Translation

For example, financial services typically have many types of regulatory reports. Some of these specify defined categories of things that must be reported, in specific formats. Creation of these translation outputs might be termed analytical events. They create new outputs in a specific format, using other business events (or at times positions).

Allocations

Another type of analytical event is an allocation. In allocations, one generates a new perspective of existing business events. For example, clerks, HR professionals, managers and executives, and janitors typically don’t work directly on producing products or services for a company. Yet at times we want to know what portion of the product cost is attributable to this type of overhead.

Dividing some overhead cost by the number of units produced creates a set of analytical events.

>>> Related Post: Introduction to the Allocation Series <<<

Characteristics of Analytical Events

Analytical events typically are generated once as of a point in time based upon a set of business events and business rules, for a specific set of analysis. When the input data or rules change, the prior set of analytical outputs are typically discarded, and a new set of analytical events is generated. In other words, analytical events are typically not involved in posting processes.

Because analytical events are based upon a set of rules, which might be externally defined–like the regulator reporting rules–or in a sense be a bit arbitrary based upon some set of rules–like dividing a clerk’s salary by the units the company produced–these types of events typically have lower value than analysis of business events and transactions.

>>> Related Post: Metric Engine and Master File Update <<<

Temporal Events

Temporal events refer to things that happen because of the passage of time. In accounting a common type of temporal event is an accrual, for example, for rent. If it is the 15th of the month and rent is due on the 1st, then there may be no transaction recorded to reflect that liability for rent that has accumulated since the last payment, but a temporal event could reflect this condition.

>>> Related Post: Temporal Events, Posting and Data Supply Chains <<<

Sometimes temporal events are used to be more efficient than using the actual business event that happens very frequently.

For example in multi-currency situations, a balance in one currency (US Dollars for example) can change every second as current rates change when stated in another currency (say Canadian Dollars). But recording these changes as business events results in enormous volumes of data of little value. Instead, in most cases, the exchange rates at the end of a business day in the major financial centers are used, and a temporal event is recorded for the change in the asset value since the last rate change was recorded.

Unlike analytical events, temporal events are at times used in posting processes, whereby they are added to balances to maintain running totals. But like analytical events, depending on the nature of the thing being measured, they can have lower value than the business events or transactions.

>>> Related Post: Details on Temporal Events in Data Supply Chains <<<

Accounting Events

As noted in the Accounting Cycle Step 2: Create Journal Entries post, bookkeeping entails a flow through accounts. This flow is often created by turning business events or transactions into journal entires, a debit and a credit.

If each business event were translated into one debit and one credit, then they might be captured on the business event as two sets of attributes on the same record. But quite frequently the flow though the accounts means that a transaction can generate multiple debits and multiple credits.

Sample Journal Entries

For example, one might define the exchange of payment for some good or service as a single transaction, but this transaction will typically involve multiple debits and credits: additions to the receivable or cash assets and to the company revenue; releases of inventory and the related cost of good sold.

Accounting events are almost always subject to some level of a posting process. Again, the ability to use the attributes captured on these accounting events in different types of analysis can provide tremendous benefits to the business, but only if accessible at the appropriate time, in accurate ways, in a cost effective manner.

>>> Related Post: Pacioli, Debits and Credits <<<

Independent Business Events

This last entry isn’t so much about a different class of business events, but more about the complexity in much of the analytical space of making sense of disparate business events and transactions in relation to other business events.

For example, the act of a customer changing their state of residence is a business event that typically results in an update to the customer record. There may be some limited reporting that occurs around this type of business event by itself.

But the much more common use of this business event is to categorize customer transactions by state of residence. This joining of the business events is a common need in analytical processes.

Time Impact

In a very powerful analytical reporting process, the impact and comparison of time can be controlled. For example, if one frequently produces a report categorizing customer transactions by customer state of residence, when the customer changes states, it can affect the analysis that has historically been used. Time based reporting processes can help isolate what are termed reclassification events (i.e, moves) from changes in state (a customer stops buying in one place and a different customer starts buying in another).

>>> Related Post Reclassification Problems Overview <<<

Summary

Data Supply Chain Layers and Data Volumes

Data supply chains that appropriately deal with these conditions, but which are enhanced from traditional means of doing so–perhaps most importantly by maintaining access to the transaction attribution at greater levels of detail and aggregating to positions on demand–are powerful but expensive to build. There are organizations that have them in place. Advancing them rather than retreating from them is likely the best course.