Extended Business Analysis allows you to look at the performance of your enterprise in many other ways apart from just a single Company-Wide Profit and Loss, Sales and Balance Sheet view. For example, if your Company has several Locations, you might want to know how each Location is doing and, if you have different Customer Categories such as Retailers, Wholesalers, Internet Resellers, etc., how each of these Categories is performing. Similarly, if you have multiple Departments, you may want to see how each Department is doing compared to others - or indeed how each Department is performing within each Location by comparison to others.
The system facilitates such extended analysis by setting up the Locations, the Customer Categories, and the Departments, etc. in separate tables (up to 6) called “Business Dimensions”. Each Business Dimension can be allocated to a differing aspect of the Business. For example, one Dimension can be set up as “Location” and each Location within that Dimension is then allocated a Code to uniquely identify it – called a “Dimension Element” (or, if you like, a “Location Code”). Similarly, if desired, each Customer Category is allocated a unique Code within a separate Customer Category Dimension table, and so on. Each of the six Business Dimensions are user definable and it is up to you to decide what the “Dimensions” are for - as they could equally be based around Product Type and/or Activity, or something completely different like Projects.
Many older and indeed many contemporary General Ledger Systems require this Analysis Group Coding (sometimes called Cost Centre or Profit Centre coding) to be combined with the General Ledger Coding (Revenue, Expenses, Assets, etc.) together into one single code such as Branch-Department-Expense Code for example. However, this combined code approach places significant limitations on the subsequent analysis which can be achieved - and on the extraction of data for reporting purposes. It can also be the cause of excessive General Ledger Master records being created - since every General Ledger Code must now be combined with every Branch and every Department within every Branch as part of the setup of the General Ledger Accounts Code Table.
This System, exploiting modern Relational Database architecture to its full potential, takes the construction and maintenance of the Extended Business Analysis coding structure away from the General Ledger Revenue/Expense structure. Thus, the General Ledger Revenue & Expense Code tables exist in only one instance while the Business Dimensions and their Elements structure are maintained separately - where both sets can be extended or changed independently without reference to each other. It only requires both Codes to be presented, separately and individually, when Transaction Entry takes place (usually from convenient “drop-downs”).
1.1 Dimensions and Elements: The way we do this is to facilitate the set-up of up to 6 separate “Business Dimension” Tables each of which can have any number of members or “Elements” defined within them; For example, if we set up a Dimension called “Location” then it is possible to nominate all your business Locations, as the components (i.e. “elements”) of that Dimension and allocate a Dimension Element Code (“Location Code”) to each Location. Another Dimension Group might be set up as “Customer Category” (with elements, for example, being “Retailer”, “Wholesaler”, “Distributor”, “Internet”, “Industrial”, etc.). And, so on in respect of other Extended Business Dimensions which you might want to set up within the system.
1.2 BI Codes: In the system you can now combine each required element of each Dimension into a single set of Codes which we have chosen to call the “Business Intelligence Codes” here - although you can name it as anything you want (see below). This is the Code that is entered (along with the General Ledger Code) at Transaction entry stage to identify the originating Location, Customer Category and Department.
When you quote a BI Code during Transaction data entry, its relationships to the Elements of each Dimension (e.g. “BRI”, “INT”, “CLO”) are inherited and carried on into the resulting Transaction Database Posting. Thus, every transaction line not only carries the General Ledger Expense/Revenue Code and the entire BI Code (e.g. “BRI-INT-CLO”), but also the (up to six) individual Dimension Element Codes - all of which are individual database access keys. For reporting purposes, any one or, any combination of these 8 separate access keys can be used to build the required reports or queries. In the example above, you might want to enquire or report on the performance of all Sales to Retail Type Customers in the Manchester Location, or, all Internet Customers by Department.
Thus, as the Sales Transactions and Purchase Transactions, etc., are entered as part of the day to day operation of the system, the only required codes for Extended Business Analysis are the BI Codes and the Revenue/Expense Codes – many of whom will, in any event, be presented as inherited default codes from Master Data Records, which of course, can be over-ridden as required. For example, here is what a Purchase Invoice entry will look like;
Similarly, when Budget data is entered at the General Ledger Code and BI Code level, such data will be posted to the Database and presented, when requested, for enquiry and reporting purposes against the Actual data.
2. Setting up your Dimensions and Elements:
If you have a less complex business structure then it is quite straight forward to operate the system without these Dimensions or BI Codes (or, indeed, you can just use BI Codes only). If, however, and using the example sketched out above, your business entails multiple Departments (Food, Clothing, Footwear, etc.) in a number of different Locations (e.g. London, Manchester, Leeds, Coventry, etc.) then it is most likely that you will want to monitor the performance (Profit & Loss reporting against Budgets) of each Department and/or each Location, and perhaps Department within Location – as well as overall.
Extended Business Analysis facilitates this by allowing you to set up the individual Departments, individual Locations, etc. and then create all the required combinations of both – while also excepting un-used combinations (e.g. The Leeds Branch doesn’t do Food, the Coventry Location doesn’t have a Pharmacy and Head Office doesn’t sell anything at all).
This is only one example of the use of Business Analysis. For example, if you are in the Transport Sector you might want to set up each Truck as a Profit Centre, or in Retail, you might want to Analyse and Report on the performance of your Product Lines in each individual Store outlet.
Let’s say you have coded “Northern Branch” as one element (= “NOR”) in the Dimension which you have called “Location” and the “Manufacturing” Division as “A02” as one element in the Dimension known as “Activity” and the Department as ”QCL” (for “Quality Control”) as one element in the Dimension = “Department”, then the BI Code to be used, in say the final stage of Manufacturing in the Northern Branch, is “NOR-A02-QCL”.
However, for the purpose of this example we are going to demonstrate how Branch (or Location), Customer Category and Department might be accommodated within the system.
2.1 Nomenclature: The first task is to implement the nomenclature you require throughout the system: You first need to name the “Business Intelligence Code” to one which is most apt for your business. This Code is the combination of the elements from each of the Dimensions and which we have hitherto called the “BI Code” although you might like to call it “Cost Centre” or something else.
To do this, from the Main Menu Go to Analysis > Create Dimensions & Codes > Dimensions; This will bring up the screen shown below; Click on the second Tab and change the entry therein to “BI Code” or whatever other name you want to call your combination of Branch, Customer Category and Department elements (i.e. the name which you wish the Business Intelligence Code to be known throughout the system). To implement, click on “Save”. This new Name will now be retained and subsequently be used throughout the system as required. For example, in all Transaction Entry routines.
2.2 Setting up your Dimensions: Next Go to the “Set up Dimensions” Tab and set up the first Dimension by clicking on (+ Add New Dimension).
In our example, we are adding “Branch” as the first Dimension. The Element Length Code is important to ensure that the subsequently combined Costs Centre Code is not unwieldy. Now add the other Dimensions – in this case “Customer Category” and “Department”.
2.3 Setting up the Dimension Elements: You now need to add the Elements for each Dimension;
Click on the “Branch” Tab, which will bring up the “Add Element” button in the bottom right hand corner; Click on this to open up the following window where you can enter the first 3 letter Element Code for that Dimension, along with a free form description. Now click on “Save” and enter further elements by clicking on “Add Element” as above.
When you are finished adding all the Elements for this Dimension, move on to the next Dimension.
N.B. It may well be the case that some of these Dimensions duplicate some of the Codes set up under Codes Maintenance in “Setup” (e.g. Regions and Areas). Dimensions provide P & L reporting, whereas “Codes” provide Sales Analyses.
You now need to selectively combine the Dimension Elements to produce the BI Codes (which will be used during transaction entry). You should only make those combinations that you actually need, and which reflect your reporting requirements. For example, referencing our original example, you may have no “Wholesalers” in “Bristol”, there may not be a Pharmacy in Coventry and “Head Office” is unlikely to have “Sales”. Cutting down on the number and extent of BI Codes makes it a lot easier for data entry operators to choose the correct one during Data Entry.
Again, Go to Analysis > Create Dimensions & Codes > Dimensions;
Click on the “Add & Tag BI Code” Tab followed by “Add BI Code” which will open up the following area where you can create your first BI Code;
Fill in the BI Code field (normally, but not necessarily, made up of the Dimension Elements separated by dashes) and Description field and then use the Drop Downs to tag each of the appropriate Dimension Elements to the BI Code. Followed by “Update”. Continue by setting up the remaining BI Codes.
However, it is possible that, for historical or some other reasons (for example, see the “How Do I Implement Project or Job Costing Analysis” paper), you might already have BI Codes numbering or lettering which bears no relation to the logic of the Dimensions and their Elements (e.g. “2902” has some previous context within your organisation). Again, having set up the required Dimensions and Elements, you can add a BI Code “2902” and attach it to the relevant Dimension Elements;
3.1 Editing and Deleting BI Codes: You can Edit and/or Delete BI Codes. To Edit a BI-Code, click on “Edit” beside the entry you want to modify;
In this example, we are changing the Customer Category of one of the BI Codes. When you click on “Save” below all the existing system transactions which contain the former code or will be converted to the new code. To retain the existing Codes, cancel the change and simply create a new BI Code for all subsequent transactions.
While you can’t actually delete a BI Code, you can make it Inactive. Edit the relevant entry and click on the “Inactive” tick box.
To re-activate the BI Code, click on “Edit”, click the “Active” Tick Box and followed by “Save”.
4. Using BI Codes:
4.1 Ensuring Compliance and Gradual Deployment: As far as possible you should set BI Codes at the Master Record level as Default Entries in order to ensure accuracy and reduce data entry during subsequent transaction processing (e.g. Invoice Entry, etc.). In this example, when a New Supplier is set up, the “BI Code”” to which the Supplier normally supplies is set up as the Default – in which case every time this Supplier is called up in transaction processing, this BI Code is presented as the default entry (which can then be overridden, if required). The same facilities are available in Product, Stock and Sales Master Data records.
You can also enforce the entry of a BI Code (highly recommended) during Transaction entry and Processing against any number of General Ledger Codes by setting the check box to “Yes” as follows (General > Add/Edit GL Codes);
Codes with this Box left unchecked do not necessarily require a BI Code to be entered – but do provide the opportunity to do at transaction entry stage.
One advantage of not enforcing the entry of BI Codes is that you can introduce Extended Business Analysis gradually. For example, you might decide to implement the system initially without any Business Analysis, then, later on, decide to implement it just for Revenue GL Codes and later on still extend it to Expense Codes and fully exploit the Extended Business Analysis facilities of the system.
4.2 Overly Complicated BI Codes: Be careful not to over complicate your data entry BI Codes. Let’s say you have Dimensions = Region, Branch, Product Group and Product Type. The temptation here is to set up your BI Code as RE-BR-PG-PR where RE represents the Region, BR represents the Branch, PG represents to Product Group and PR is the Product Type. However, it’s pretty obvious that Glasgow is in Scotland (and only in Scotland) and Televisions can only belong to a Product Group “Electrical”. Therefore, it is not necessary to include the Region Code and the Product Group Code in the data entry BI Code. In this example the Code should only comprise BR and PR which can then be “attached” to the Region Dimension and the Product Group Dimension (as well as to the Branch Dimension and Product Type Dimension).
Also, it is advisable to remember that other parts of the System might very well meet your requirements for some of your proposed Dimensions. For example, might not the Dimension in the foregoing called Product Type just as equally be accommodated within the standard Sales Analysis and Purchasing Analysis Reports in the System?
4.3 Modification and Merging of Dimension Elements: As mentioned previously, addition of new Elements Codes to existing Dimensions and, indeed, addition of entirely new additional Dimensions, is facilitated. As is also the De-Activation of redundant BI-Codes.
However, as your Enterprise evolves, as well as setting up new Dimension Elements for new Branches, Product Groups, etc., you may also want to merge Dimension Elements as Branches are closed or amalgamated. You can do this by “Re-Attaching” the old BI Codes to the appropriate new Dimension Element. In the example below we are merging the Coventry Branch with the Manchester Branch by changing the Coventry BI Codes to Manchester (which must be done for all Coventry BI Codes – unless only some Departments are being merged). You have the option to retain, for historical purposes, the transactions with the redundant BI Codes or to convert and transfer them over to the new BI Codes. If you wish to prevent the use of the old Codes in the future, you should de-activate them.
4.4 Using BI Codes without Dimensions: Some Companies may have quite limited requirements in the area of Business Analysis. In this case it is entirely possible to operate the system with just the BI Codes only – i.e. without setting up or attaching them to Dimensions.
Alternatively, some Companies might decide to implement Business Analytics in a limited way to start with and then, as the need for more extended analysis and reporting grows, decide to add Dimensions later on.