One of the first things you will need to do before developing your Oracle Business Intelligence (OBIEE) application is … identify who will use it. You need to identify who will be using the application – what business areas they belong to, what groups they belong to, what are the various functions or roles within those groups, and eventually, who are the actual people. After identifying the various roles (groups of users typically associated with a business process or function), then you can identify their needs. Starting any development before knowing who will be using the system could result in a lot of wasted time and effort or a sub-optimal system. The grouping of information on dashboards, the available functionality and security will be driven by these roles and their respective needs.
After identifying the various functions or roles that users posses, then it is important to understand how each role performs their job functions. You need to understand what information they need and in what order, how it’s used, and the level of detail required at various stages. With this information, you will determine the dashboards, dashboard pages and their order, the information on each dashboard page and its precedence and level of detail, and what detailed information is needed via drill down. Basically, you will be creating the analytic workflows for the identified roles and the various processes, functions and tasks that they perform.
When performing the above exercise, please be as discrete as possible. For example, even if someone doubles as an AP/AR Analyst, you should still analyze and plan for 2 separate roles – AP Analyst and AR Analyst – because those are 2 separate functions. Later, the individual or group can be granted permissions to both roles. From a security standpoint in general, you will create the necessary OBIEE application roles to support your business roles. And then assign security based on these roles.
In general, always keep the focus on the users, what they need to accomplish, and the most efficient ways to help them perform their job. When you build the OBI system to meet those needs and usage scenarios, it will result in higher and faster user adoption. This will take time, so do not rush the process. Get detailed information about all the steps in their workflow upfront, document it, and then build around it. However, on the other hand, you do not have to document to perfection upfront, you can take a more agile approach of developing based on fairly good user profiles to give users working prototypes, and then adjusting as new information and feedback is received from the users.
Good luck identifying your users and their needs as you get your OBIEE project rolling. And remember, it’s all about the users!
