I spend a lot of time talking to customers whom have installed (or had installed for them) Oracle BI Applications and the lessons they have learnt from that process. If I couple those lessons with some of the items that Beyond deliver as part of a typical BI Applications installation, then here's my rather succinct list of some key deliverables that I think are important but are often not all delivered. This is applicable to both 18.104.22.168 and 22.214.171.124.1 customers.
See how many you score compared to your implementation! This isn’t intended to be exhaustive and is purely to get you thinking. Please also leave some comments as I’m always keen for a dialog on what people consider to be important and what isn’t.
(1) Pre-Installation Assessment Document.
Are you actually ready to commence – you need to know that the environment you’re considering installing on is fit for purpose. You should be able to work out an optimal blueprint for the architecture and how the software is to be installed. By this I mean that someone has taken the time to consider the licenses purchased or to allow for that to happen by devising the architecture that will underpin the implementation.
· Where are we to install the application? Across how many machines and are they physical tin or virtualised. Which O/S and which version and for how many environments (Dev, Test, Pre-production/UAT, Prod?).
· What’s the storage situation – dedicated or on a shared SAN? What’s the performance of that?
· Focus in on questions such as are you going to split the Warehouse and the metadata database and if so is that on different DB’s or different instances in one DB. What versions of the Database are you going to use?
· You need a diagram showing the machines that are going to support the apps and database tiers and the core factors/NUPs for each component.
· Cross check with Oracle’s latest certification documentation to make sure that your browsers ( and yes … that’s ALL the browsers that will be in play when you go live ), your O/S, your DB versions, BI EE versions, Java Versions, etc are all compatible and certified together. This needs to be detailed, right down to stuff like “open files” limits on Linux.
(2) Patch Analysis Guide
The base BI Applications can be downloaded and installed from Oracle E-Delivery. However, there are important quarterly BI APPS bundle patches (assuming you’re using 126.96.36.199.X version here which was current at time of writing as the older 7.9.6.X steam was handled differently) as well as frequent BI EE rollup patches that provide fixes and capability (e.g. the ability to use say IE11).
The patching that will be applied to the base downloaded BI Applications should be discussed, agreed and documented in a patch analysis guide. Exactly which rollup patches will be applied to the initial installation and propagated throughout Test/UAT/etc.
One thing to also keep in mind is that if you’re having a longer running project (a topic in itself) then you should monitor at least the quarterly patches and BI Enterprise Edition tech patches as the versions you start the project with may not be the versions you finally go live with, so make some provision upfront to assess throughout the project lifecycle.
(3) Your Installation Guide
It’s the “YOUR” bit that is key here. I rarely see this and yet what it gives you, I believe, is invaluable. What we do when installing for a customer is to fully screenshot and document the whole process. It’s a relatively painless process to do whilst the installation is being performed.
· It allows the customer to see all the steps that were followed, and in which sequence, to install BI Applications in THEIR development environment. This provides documented proof that everything was successful and nothing was missed (including patches agreed earlier …. ).
· This document can be used by the customer as a basis to do their own installation, perhaps in a test environment, knowing that the steps they are following have been successful in development and that the subsequent environments are all being created exactly the same. This is a pretty important point, as what you certainly don’t want are any “differences” between environments. This really helps with customer “self-sufficiency” for customers who want to be very closely involved with the project and be able to manage and support it going forwards.
(4) Configuration Document/Guide
A successful BI Applications installation requires user input into the configuration. A really successful project I believe works best with the users actually doing some of the configuration. So, whilst we typically ask the questions regarding “What do you want your balance sheet to look like” and we map the group accounts with the customer, we find that if the customer actually reviews their own key domain values and performs some mappings has a number of benefits. It certainly provides the customers with the opportunity to understand how the configuration tool works and how they can perform tasks such as adding new warehouse domain members to manage the system moving forwards.
That joint approach aside, and here the new Configuration tool in the 11.1.1.X version facilitates that by allowing us to create task owners and monitor their completion, I really do think that some supporting documentation for the decision making process is key. I would expect to provide customers with a document that explains the following
· A detailed list of ALL the tasks that constitute the functional areas that are being implemented with a description of their purpose.
· What decisions were made regarding setting any values associated with the task. E.g. The Initial Extract date …. What was this set to?
· Who decided the value above and why?
· Links to any supporting documentation
Having this is place is important as everyone can see from a single document the decision making process, which is quite important if questions are raised later in the project when perhaps personnel have changed and memories are dimmed by time.
(5) Security Matrix
I’m a firm believer of security being built in from the beginning of a project and not retrofitted later on. There’s a multitude of different security stripes that can be applied. The customer needs to be guided by a clear matrix that allows them to make decisions about the items such as:
· Which E-Business responsibilities need creating to access the Application (assume the same of other source systems )
· The dashboard access that is granted/secured
· The analytic access that is granted/secured
· The capabilities to create/amend objects
· The “security” stripes that are applied to the data ( restrict by Operating Unit, by Ledger, by Value set, etc )
A matrix that allows for each comprehension, discussion and amendment upfront really helps here and establishes any security ground rules that will need to be enforced, both “out of the box” or anything custom that may need applying.
(6) Cutover Guide
A successful BI system is one that is undergoing constant enhancement as it helps to drive forward business transformation and improvement. In order to achieve this, a sound process is required to dictate how to propagate the various components that constitute a BI system (catalog, repository, custom ETL processes, etc) through from development and into production. If the customer truly wants to gain a degree of self sufficiency then having a guide that takes them through this process on their environment is a key deliverable.
(7) Master Brand and Build Standards
With BI systems consistency is a key factor. Interactions with dashboard components need to look and feel consistent, not only to purvey a professional aesthetic, but to minimise and confusion and allow the users to quickly and easily adopt new analytics with minimal training or room for error. In this respect you need a “master brand” and build standards.
Unless you have this there is a danger of parallel developments not hitting that target and requiring refactoring. For example:
· Consistency in colours ( not just “a green” in a RAG status but A SPECIFIC ONE )
· Analytics all have the data and time executed on them and a standard title and set of links underneath them
· Consistency across all events ( e.g. perhaps with action links if only one link available then immediate drill to it don’t prompt the user )
· Company Logos are all consistent
You’ll soon see that having a guide to the form and function of dashboard components is absolutely vital and getting assistance in developing one prior to the commencement of any development is an important step.
There are plenty of courses available from a number of sources that can cover the core competencies of ETL (whether you’re using Informatica or ODI), Modelling, Presentation Services development, etc and these need sequencing. It’s my view that the customer benefits most from having some training in developing analytics/dashboards very early in the project as that then gives them the capability to “explore” the out of the box deliverables within the first few weeks of the project when the installation is done and the first warehouse load is performed.
What I think is a really important part of enablement though is someone walking the customer through their own data in the out of the box subject areas. This is a watershed moment in the project as within the first weeks the customers can see their own data surfaced through BI Applications. If they are then given an introduction to all of the subject areas that they have purchased with a description of each one with some example analytics using the customers’ own data, then this is helps to re-enforce their understanding in the capabilities of the product. Now, this can do done prior to too much configuration being done and can actually assist the users when doing configuration and witnessing the changes that their decisions make. I firmly believe this helps to cement engagement with the project.
(9) Performance Guide
For whichever version is being implemented there is an Oracle guide that provides recommendations for increasing performance. It certainly is reassuring if you have some affirmation that that’s all been checked and advice on memory management, indexes, etc taken into account. The indexes on E-Business certainly help throughput for incremental runs!
That’s pretty much a whistle-stop tour of some of the items that I think are important for the customer to know and be involved with (if they want to of course). It’s not everything and I’d be happy to elaborate on some other items if you’d care to contact me, but if you are striving for either complete or a degree of “self-sufficiency” then I hope that it’s given you some food for thought.