Dears, Many organizations struggle to provide master data for traditional business intelligence (BI) information, such as dimensional

hierarchies and performance measures. While performance measures are not technically considered master data, they should be consistent and governed like master data. The traditional BI platform from products such as Oracle's Business Intelligence Enterprise Edition enable IT to control dimensional hierarchies and performance measures, but only for that (BI platform) vendor's reporting and analysis tools, and always downstream of operational systems. Increasingly, organizations will need to enable more business user control and accommodate rapidly changing requirements (such as alternate hierarchies and what if analysis). In addition, organizations will need master data portability where any application, not just the reporting and analytical tools, can access the master data for dimensional hierarchies and performance measures. A nascent market is developing for dimensional hierarchies, with products such as Oracle Hyperion Data Relationship Management (DRM), IBM Cognos Business Viewpoint, Microsoft's Master Data Management Services, Profisee's Maestro, and Kalido Master Data Management. These tools are not widely deployed, and most IT leaders are unaware of their functionality. In an effort to learn about the experiences of early adopters, A leading Reach firm interviewed four customers using Oracle Hyperion DRM Product: Customer 1 is an electronic design automation firm. Customer 2 is a financial services company.

 Customer 3 is an energy services company. Customer 4 is a data storage company. They have asked the following eight questions to each of these four anonymous customers. Their answers are provided below. 1. For what business problem is DRM meant to address? Customer 1. The original business problem we wanted to address was that we needed a central place to maintain a hierarchy, but in such way that we could distribute the maintenance over various places in the world (i.e., close to the source) so that people could only maintain their part of a hierarchy and with a set of business rules applied that would make sure people adhered to a set of corporate policies underlying that hierarchy. Customer 2. DRM was purchased several years ago to solve the business problem of inconsistent organizational hierarchies across business units. Numerous "alternate" hierarchies were maintained in each business unit using whatever tool (e.g., Excel, Access, etc.) they knew best. This led to many errors in their "alternate" hierarchies and many inconsistencies in their reporting to upper level management. Customer 3. Creating a single source of truth with respect to master data used in our internal and external financial reports. Customer 4. [Our] primary business problem is productivity loss due to resolving data discrepancies and inaccuracies in reporting, caused by misaligned, and multiple hierarchy inconsistencies throughout the enterprise. Organizations face many valid reasons why different business

entities need different dimensional or hierarchical organization of master data. In cases where no such support is provided by the tools, business units revert back to organizing hierarchies in silos using Excel, Access and so on. Providing the ability to govern the definition of hierarchies can bring the right balance between centralized control and business enablement. 2. How well does DRM resolve this business problem? Customer 1. Very well. The initial deployment was for our sales hierarchy and we were able to distribute maintenance, while it enforces all rules of channel management. We have since extended it to many other hierarchies. Customer 2. DRM solves this particular business problem extremely well. All business units have been very happy with the consistent organizational hierarchies and consistent reporting. Customer 3. DRM along with our business processes has enabled us to be very successful. Customer 4. DRM provides a foundation for an enterprise, business driven, single source of truth for hierarchies and reference data with effective management capabilities including change management, control and audit, and data governance. While Oracle DRM has been an enabling technology to provide consistent organizational hierarchies, driving this consistency requires putting in place governance practices and organizational functions to deal with the ongoing life cycle and governance of the various hierarchies across the business. The governance and organizational structures for managing hierarchies and dimensions are very similar to those used in master data management for core entities. It requires strong business involvement from the various stakeholders to define and maintain the hierarchies.

3. Has DRM been applied to other business problems? Customer 1. Most of our deployment deals with maintaining hierarchies, but we have in some cases extended the reach. We found, for example, that one hierarchy was a good basis for financial approvals (purchasing etc.), so we ended up not just maintaining the hierarchy itself but also all the approving positions for various purposes for each node so that we can send the hierarchy with all approvers for each level/node to the purchasing system as an approval hierarchy. Customer 2. DRM has been used to solve various business problems. For example, the Legal Entity hierarchy was maintained manually and turnaround on the maintenance was several days. With DRM, turnaround is immediate. Also, the chart of accounts hierarchy was manually maintained in an Access database. With DRM, chart of account maintenance is ongoing DRM has also taken off in other various ways. Business units get very creative in their requests and we get very creative in helping the business units meet their ever changing hierarchy needs. Customer 3 Sure. For creating derived and alternate hierarchies for our EPM [enterprise performance management] applications that are not available in the source system. In addition, we were able run some analytics on the master data as well. Customer 4. DRM has been used to manage change of business master data across enterprise applications while consolidating and rationalizing structures across source systems. In addition, proliferation of corporate hierarchies are addressed by synchronizing alternative business views and providing alternative hierarchies to meet reporting objectives. One of the common challenges organization face is the need to

manage and govern the changes in hierarchies. The main requirements that drive change management on hierarchies are: Slowly changing dimensions: the hierarchy definition evolves over time and organizations need to have a hierarchy management system that allows them to adapt the definition over time and also to version it. Versioning becomes essential when trying to compare analysis over dimensions at different dates. Diverse teams have diverse hierarchy definitions to meet their various reporting needs. What-if analysis and scenario planning also require the ability to create multiple hierarchies. 4. Which hierarchies are managed by DRM? For example, cost centers, sales territories. Customer 1. Cost center hierarchies, functional area hierarchy, sales hierarchy, sales territory hierarchy, work location, management organization, product hierarchy, financial approvals, chart of accounts, various mappings that create relationships between accounts, cost centers, sales channels and product lines. Customer 2. Accounts, organization, legal entity, currency and product. We also keep all other Essbase dimensions (scenario, calendar, year, etc.) in DRM as hierarchies for consistency of dimensions going into Essbase. Customer 3. Profit centers (Geo based and BU [business unit] based), cost centers, accounts, customers, products, company, legal entities and other ancillary hierarchies. Customer 4. Currently nine hierarchies are managed in DRM including: accounts, currency, external geography, fiscal calendar,

product, scenario, product revenue classification group and category, and sales districts for professional services. We will be implementing hierarchies in DRM for cost center this year. 5. Can you describe how users interact with DRM to manage hierarchies? Customer 1. Users just browsing a hierarchy are using the Web viewer portion of DRM, which we expose in the BI portal. There are a couple of possible interactions for people editing a hierarchy. In most cases users use the DRM client to enter new nodes or modify existing ones, for example a cost center or an account manager, in a hierarchy. Once they are done, they can publish the updated hierarchy and this should trigger updates in various downstream systems, typically within minutes. For some hierarchies, nodes are automatically imported from another system and become available for mapping in DRM, in some cases by inserting them in a node that contains all new members to be mapped. Customer 2. Users have access to manage their own alternate hierarchies in DRM. They also have access to manage various required user-defined attributes on all hierarchies. Customer 3. The source for the hierarchies are SAP. We extract it from SAP and load into DRM on a monthly basis. Only the DRM team and a few select super users have read access to DRM at this point. Customer 4. Business users interact with DRM for the ongoing maintenance of the hierarchies and reference data. The business is actively involved with enriching the hierarchies and reference data in DRM. The business manages access control to the user base and controls security, as well as all aspects of data integrity DRM. Hierarchy definition requires business expertise. The client answers

above demonstrate that business users typically own the responsibility of maintaining or creating hierarchies. Business users administering hierarchies for their business area act as data stewards in master data management (MDM) or data quality improvement projects. This further enforces the governance and organization principles used in MDM to support hierarchy definition. 6. Do you seek to master hierarchy data in downstream systems ( i.e., business intelligence) or upstream systems (business applications)? Customer 1. We do both. All hierarchies go into the data warehouse and some of our OLAP [online analytical processing] cubes. Some also are fed back to transaction systems (SAP, several Web applications, planning/forecasting apps). Customer 2. We feed only downstream BI applications. Customer 3. At this point only the downstream systems. Customer 4. We have DRM master of hierarchy data for both upstream and downstream applications. 7. Who is the primary business sponsor of DRM? Customer 1. Mainly finance, mostly because finance is tasked with maintaining many of the corporate hierarchies. Customer 2. Primary business sponsor is financial planning and analysis group. Customer 3. Finance and accounting organization (financial reporting systems group). Customer 4. The primary business sponsor of DRM is a finance BI

senior manager within corporate financial planning and analysis. 8. Is DRM used to manage performance measures as well dimensional hierarchies? Customer 1. We currently only use DRM to create or edit dimensional hierarchies. Customer 2. We do not use DRM to manage performance measures. Customer 3. We maintain custom performance measures and align with hierarchies managed in DRM. Customer 4. Currently, we are not using DRM to manage performance measures. We use DRM for standard dimension hierarchies with single parent-child relationship. Miles Organizations need to include governing dimensional hierarchies as part of their master data management initiative. This becomes more important as the need for multiple hierarchies increases. Part of the MDM strategy needs to reconcile the single, static hierarchy provided by most business applications with the multiple and often ungoverned hierarchies manifesting themselves in numerous downstream OLAP cubes. Look to leverage these types of tools for downstream and upstream applications. Try to position them as a change management solution in your organization that builds consistency between operational and analytical systems by maintaining relationship maps among the most complex web of data relationships. Moreover, leaders of MDM initiatives can enable a wide variety of data managed as hierarchies. The customer references highlighted above are a testament to the neutrality of tools like DRM to facilitate

hierarchies from multiple data management subject areas. Although all the business sponsors mentioned above were associated with the finance department, that doesn't mean the scope of the project needs to be limited to just finance. Notice how most of the references above included hierarchies such as cost centers, chart of accounts and fiscal calendars; but they also included customers, products, legal entities, sale channels and so on. Unfortunately, based on the customer experiences outlined above, it doesn't appear that organizations have extended the idea of analytical MDM to include governing performance measures. While there is a clear need to ensure organizations have a consistent and reliable set of performance measures available to all business applications, there doesn't appear to be a technical solution to this problem yet. Customers indicated this could be possible with DRM, but it isn't a clear application of DRM and not something they were considering in the near term. This means most performance measures will continue to be defined within the BI platform semantic layer and performance management applications for the near future.

Business Objects vs Hyperion

The first difference between Hyperion and Business Objects comes out while checking the sale ranks. As BO has managed to dominate almost the whole market, Hyperion is thought to be a leader only on financial perspective. Detailed ranks (by IDC, Gartner and Forrester) consider Business Objects as a straight leader, placing Hyperion on fifth

position (just a place better than Oracle - 6th), and - believing analysts' prognosis - keeping such a high place is for Hyperion a matter of days. Even more, it's being predicted that Hyperion has no future - Oracle Corporation invests much stronger in Oracle BI Enterprise Edition advancement and improvement, therefore Hyperion has been almost left itself. That questions how long more is Hyperion going to be sold and - as a consequence - how long its customers are going to be supported. Independently on that, every new day makes Hyperion technology more outdated and reduces upgrades possibility. On the other hand, SAP Business Objects platform lives its bests, being delivered as a full spectrum tool for enterprise management support. BO is thought to be widely open (to different operating systems, applications, databases, but also middleware), broad (meeting all the needs of modern business intelligence), and, finally, integrated (with all the tools included in a single platform - Business Objects XI). Oracle specialists make extremely different forecasts. They state that the time of independent business intelligence and performance management is counted, therefore its largest vendors - including Business Objects - are going to be out or acquired. In fact, quick end of Business Objects shouldn't be expected as long as BO is one of the vendors that reach fastest growths. Then, business intelligence, as well as performance management, demands quick information spread across the whole enterprise to support efficient and timely decisions making. Thereupon, the system of information management must be consolidated to let every user see the same data at the same time. The only one supplier - Oracle - saves from a lot of troubles. Yes, indeed. Exclusive supplier saves not only from troubles, but also from a few quite interesting possibilities. Along that come losses of negotiating power - "If they're alone, they do not have anyone to compete with so who cares about the user who's got no alternatives?". During a two-year time (2005-2007) Oracle acquired about thirty companies and, after that, all of them have been left themselves. Oracle advertises Hyperion as a leader in enterprise performance management (EPM) and business performance management (BPM). The things aren't as obvious, though. Hyperion really is a market leader, but only while focusing on the office of finance.

Strengths and weaknesses

How does Business Objects answer Hyperion's weaknesses? First, that should be mentioned, is the market leadership belonging to Business Objects - BO's market share is about 40% more than SAS' - second largest vendor (and, off-handedly, about 180% more than 5th Hyperion). Unlikely Hyperion, Business Objects is fully focused on business intelligence. Oracle's product is rather concentrated about planning, budgeting, and consolidating, not the BI itself, treating it rather as a tool supporting reaching further goals. Finally, Business Objects seems to be a tool closest to meet completely different needs - a single business intelligence platform ensures trouble-free cooperation of different styles users, basing on a constant access to the best quality data.

Business Objects is still not fully satisfied with its position, therefore sales strategy has been slightly modified:

positioning the BO "end to end" technology - emphasizing the benefits of single, integrated platform positioning user oriented solution - less IT engaging accelerates data finding, and as a consequence - decision making steering customers to relational data warehousing instead of OLAP - relational DW facilitates openness and flexibility expanding EIM and EPM functionality emphasizing lower costs

Business Objects holds a first place in business intelligence market. Not accidentally.

BO praises for user friendly interface and breadth of functionality. Unlikely Hyperion, which interface lacks functionality, basing on obsolete metatopics concept that provides limited capabilities BO is known for its usability and ease of use that effectively support answering even the most complex business questions. Unlike Hyperion, BO doesn't demand diving into complicated structures and diversified data locations BO provides a single platform. That has a significant influence on data timeliness and trustworthiness BO is focused straight on BI, unlike Hyperion, which focuses mainly on financial applications

Some solutions offered by Hyperion seem a bit out-dated or impractical, but maybe they're somehow motivated, too:

Data Storage solution provided by Hyperion surprises not only its users - while deploying simultaneously Hyperion Planning and Hyperion Financial Management, the most difficult task is to make them cooperate. But that's still not the end. Both Hyperion Planning and Hyperion Financial Management for storing metadata use the same relational database management system, so their cooperation should be easy. But it is not. The thing is that HP and HFM store metadata in different formats. Why is that? Hard to tell, whether that was a matter of internal politics, or rather a technology requirement. Hyperion's planning functionality is also significantly limited, due to its Essbase dependency. Although HP obtains a lot of Essbase's profits, Essbase cannot function as a core database, so that working on different dimensionality is strongly complicated. Furthermore, some capabilities - such as calculation logic - are applied at server, what neutralizes their offline usability. Also the Hyperion product strategies are hard to understand. Hyperion Planning was a most preferably chosen product (due to planning market growth much faster than consolidation market), but it resulted in less Essbase sale - an example of internal competition.

Hyperion solutions lack for management reporting consistency - multiplied tools are used simultaneously. Production Reporting, Interactive Reporting, and Financial Reporting use different architectures. Efforts put into making them work together result in increased total costs of ownership. Hyperion users complain also about data management - without original data strategy, Hyperion relies on different partners what almost disables consolidation. Finally, driver based modeling is possible via separate product - Profitability Management.

All in all, both Business Objects and Hyperion have their followers that probably cannot be convinced by any comparison. After all, it should be remembered, that every judgement depends on the judge.

Business Intelligence Interview Questions

I have got these queries from someone and I would like to share my views. I dont claim my answers to be correct and hence wherever you dont agree, please let me know and share your views. If you have any questions or comments, please post them. Question:How you generally Approach to ur Analytics Project? Answer: Any project should start from defining the scope of the project and the approach should be not to deviate from the scope. Then the project should be functionally divided into smaller modules generally done by project managers alongwith technical and functional leads. The functional leads then decide on majorly three things: 1. According to the defined scope of the project they start gathering requirements while interacting with the clients. 2. They had a discussion with the technical leads and try to reach a solution. 3. Technical leads decides what schemas to create and what requirements are going to fulfill by that schema. Technical leads discuss all this with the developers and try to close requirements. Simultaneously testing and deployment is planned in a phased manner. Question: How we are going to decide which schema we are going to implement in the data warehouse? Answer: One way is what is mentioned in Question above. If you ask me to blindly create schemas for the warehouse without knowing any requirements, I will simply first divide the schemas on the basis of functional areas of an Organisation which are similar to the modules in an ERP like sales, finance, purchase, inventory, production, HR etc. I will broadly describe the expected analysis an organisation would like to do in every module. I think this way you would be able to complete at least 40-50 % of the requirements. To move ahead, study the data and business and you can create few more schemas.

Question: What are the Challenges You Faced while making of Reports? Answer: Making of an report has never been a difficult task. But problem comes when users are reluctant to adopt a new system. I have experienced that if you are not able to create the report in exactly the way they used to see, they will keep asking for the changes. Your approach should be to first show them what they want to see and then add more information in the report. Question: What you will do when your Report is not Fetching Right Data? Answer: this is the biggest problem in report creation and verification. There could be two reasons for report not fetching the right data. 1. Mostly clients do not have correct data in their database and on top of that to correct the results they make some changes at the report level to bring the desired result which you may not e aware of while creating the reports. Clients try to match the data with their existing reports and you never get the correct results. you try to discover the things and at later stage come to know of all these problems and you are held responsible for this delay. Hence always consult the SPOC(Single Point of Contact) and try to understand the logic they have used to generate their reports. 2. If the database values are correct, there there could be a problem with the joins and relations in the schema. You need to discover that analysing and digging deep into the matter. There are more questions which I will try to answer later. The questions are very specific to OBIEE and I dont have much experience in that. Hence you may not agree to my answers, but wherever please post a comment and let me know too. Question: How analytics Process Your Request When you Create your Requests. Answer: If the Question means how does Oracle BI Analytics Server processes the user requests, the answer is- Oracle BI server converts the logical SQL submitted by the client into optimised physical SQL which is then sent to the backend database. Also in between it performs various tasks like converting the user operations like user selections to form a logical SQL, checking and verifying credentials, breaking the request into threads(as Oracle BI is a multi threaded server), processes the requests, manages the cached results, again converting the results received from the database into user presentable form etc.

Question: From where u Get the Logical Query of your Request? Answer: The logical SQL generated by the server can be viewed in BI Answers. If I have not understood the question, Please raise your voice.

Question: Major Challenges You Faced While Creating the RPD?????? Answer: Every now and then there are problems with the database connections but the problem while creating the repository RPD files comes with complex schemas made on OLTP systems consisting of lot of joins and checking the results. Th type of join made need to be checked. By default it is inner join but sometimes the requirement demands other types of joins. There are lot of problems with the date formats also. Question: What are Global Filter and how thery differ From Column Filter? Answer: Column filter- simply a filter applied on a column which we can use to restrict our column values while pulling the data or in charts to see the related content. Global filter- Not sure. I understand this filter will have impact on across the application but I really dont understand where and how it can be user. I heard of global variables but not global filters. How to make the Delivery Profilers Work?

When we are Use SA System how Does SA Server understand that It needs to use it For Getting the User Profile information?

Where to Configure the Scheduler? Answer: I am not sure if Iam correct but we configure the OBIEE schedular in database.

Question: How to hide Certain Columns From a User? Answer: Application access level security- Do not add the column in the report, Do not add the column in the presentation layer.

Question:How can we Enable Drills in a Given Column Data? Answer: To enable Drill down for a column, it should be included in the hirarchy in OBIEE. Hyperion IR has a drill anywhere feature where dont have to define and can drill to any available column.

Question: Is Drill Down Possible without the attribute being a Part of a Hierarchical Dimension? Answer: No Question: How do u Conditional Format.? Answer: while creating a chat in BI Answers, you can define the conditions and can apply colour formatting.

Question: What is Guided Navigation? Answer: I think it is just the arrangement of hyperlinks to guide the user to navigate between the reports to do the analysis. How is Webcat File Deployed Across Environment?

Question: How the users Created Differs From RPD/Answers/Dashboards Level????? Answer: RPD users can do administrator tasks like adding new data source, create hirarchies, change column names where as Answers users may create new charts, edit those charts and Dashboard users may only view and analyse the dashboard or can edit dashboard by adding/removing charts objects. Question: Online/Offline Mode how it Impact in Dev and Delpoyment???? Answer: Online Mode- You can make changes in the RPD file and push in changes which will be immediately visible to the users who are already connected. This feature we may use in production environment. Offline mode- can be useful in test or development environment.