Overview
In this session, we’ll review some basic Kepion concepts, identify the forms we need to build, and use filters to consolidate the total number of forms we need.
Transcript
[transcript]
In part one of this series, we'll walk through the process of translating customer requirements into a Kepion application. In this session, we'll begin by reviewing some basic Kepion concepts. Then we'll tackle the first step of the architecture design process by identifying the forms we need to build. And lastly, we'll see how we can use filters to consolidate the total number of forms we need.
Let's start by looking at the fundamental concepts that drive Kepion.
We use dimensions to define models. Models are then used to store relational data and calculations in a database. Then we create forms as a window to view that data.
Let's see how we can identify the dimensions, models, and forms we need from spreadsheets provided by the customer.
In our example, the customer is a consumer packaged goods company, which sells four brands, each with multiple products, across several countries.
We currently have the revenue planning spreadsheets. The spreadsheet starts with a group of profit and loss, or P & L, reports. The reports are all structured in the same way. From the tab names, we can see that they're separated by the four brands: Adair, Aviva, Harper, and Sander.
The row headers are different accounts of the P & L.
The deflated percent form shows some percentage accounts by brands, and then there's a group of trade spend forms also divided by brands.
At the end, we have some base assumption tabs. Each of them contains a form for volume, cost, and price.
A link to download this spreadsheet is provided below the video. It's encouraged that you spend some time familiarizing yourself with it before moving on.
First, we'll need to clean up the customer spreadsheets and translate them into Kepion forms, which are defined by four regions: rows, columns, and filters, with data existing at the intersection between.
We should also determine which forms are read only reports and which will be input forms. By default in Kepion, read only cells are white, while input cells are yellow. The default color for all cells, including annotations and drop downs, can be configured however you'd like.
The P & L forms are reports because the data is calculated through formulas. The rest of our forms will be used to gather input.
Notice how all of the forms in the base assumption tab have exactly the same structure. To create a more efficient application, we should consider combining them together using a filter.
Filters allow us to switch between different contexts in a form.
For example, if we combine these three spreadsheets together, we could create a filter with options such as volume, price, and cost and use it to flip between the different sets of data.
By stacking more filters together, we could combine the data from hundreds of spreadsheets into a single form. Adding filters that allow us to switch between different fiscal years, scenarios, and entities would all be helpful.
In addition, we could use a brand filter to switch between the four brands. This means we only need a single form to represent the volume, price, and cost of our base assumptions.
So let's hide the extra ones.
Since we're also adding a filter to switch between the different brands, we can hide all the other base assumption tabs as well.
Using the same logic, we can remove the extra tabs for the trade spend forms, the brand information in the deflator percent form, and the extra P and L reports.
By adding filters to all of the forms, we can condense the customer requirements spreadsheet from twenty two forms to four.
I've added mock ups of each of these forms to our architecture document.
In this session, we reviewed the basic concepts that drive Kepion, analyzed the structure of the customer spreadsheets, and used filters to transform and consolidate them into Kepion forms.
In our next session, we'll begin step two of the architecture design process and determine the dimensions and hierarchies we'll need to build those forms.
[/transcript]