Make enterprise BI more responsive to change analytics
The world is evolving swiftly. What was true yesterday may change today. The tremendous rate of business change demands development processes that keep pace. Agile is a methodology that can help match the pace of change. Therefore, it is not surprising that a recent analyst study showed that over 76% of CIOs are expected to adopt Agile methods[ The Gartner Scenario for IT Service Providers : IT Services in a Digital Future]. Given the trend, can Agile in SAP BI be far behind? Which brings up a natural question: When is Agile best for SAP BI deployment? We suggest three ideal scenarios: New Report Development Changes in existing report by making a copy of it SAP BusinessObjects Web Intelligence (BO Webi)/ Visualization/ Dashboard reports Traditionally, projects in SAP BI have used the Waterfall method. This has led to increasing failure and user dissatisfaction. Reason: Collecting requirements, developing a data model, identifying and uploading data, developing BI objects and rolling out a finished product takes time and the process is unable to adjust to rapidly changing context and user needs. This is why the First Time Right metric for BI has been low. BI projects have had time and cost over runs because they require a couple of iterations before they can become acceptable. Agile, on the other hand, follows an iterative and evolutionary approach, building incrementally in 4 week cycles or sprints by breaking down projects into disparate modules/ functionalities. This means project scope can be modified during development, resulting in a better end product. Three scenarios for Agile The advantages of Agile are clear. Development is adaptive and aligned to current business needs, providing a faster route to real value while eliminating waste (in terms of time, effort and budgets). In a majority of the instances, Agile methodology also means smaller development teams (read: easier to assemble, easier to manage). But, there are limitations too. Two critical issues need to be recognized. First, Agile is unsuitable for complex development that requires integration with multiple systems; and second, it can present frustratingly technical challenges with the need to reload large data volumes. A recent analyst study showed that over 76% of CIOs are expected to adopt Agile methods For the first two scenarios, either existing data models should be used or a new data model can be used so that data load does not impact existing models/reports. While using existing data model, minimal changes can be made in the data model (example: Navigational attribute enablement which does not require data reload). For the third scenario, build efforts can be comparatively higher than Business Explorer (BEx) reports. SAP BO reports are mostly new for business user and difficult to visualize. This is where Agile methods can step in and help business with visualizing representations and other features while minimizing rebuild efforts. Where not to use Agile Agile methodology is not suitable for technical projects (patching/ upgrade) where new business functionality/ reports are not added. It is also not suitable for complex development that needs integration with multiple source system where changes are required in the source system. Neither is it suitable when changes are called for in the existing data model and which require reload of data/re initialization of delta. Such changes have a business impact as existing reports become unavailable during data reloads. 2
Getting the methodology right The key is to get the SAP BI deployment methodology right. Here is a suggested approach (see Figure 1 for details): Perform an assessment during Scoping and Planning about utilizing Agile based on the defined scenarios Use the BAU approach to allow Agile delivery of the BI Reports into production landscape, using iterative BI cycles to refine requirements (iterations should be finite depending on report complexity simple, medium or high) All reports to follow BAU rigour such as regression and performance impact analysis with Unit, Informal and Formal Tests before moving into production Reports in production are not directly available to business user, hence they can only be run by the project team along with business users to validate it. The business verifies the report from an accuracy, look, feel and performance perspective prior to entry into Formal test (see Figure 1). The BI documentation and change control are kept open during the iteration. Documentation is completed before entry into Formal test. Formal testing for the reports, as part of a release, will align with the formal test phase for the release. Mitigate risk build success Some risk mitigation measures are strongly recommended. Ensure that testing as part of the change process is comprehensively followed (including regression and performance testing). No business users should be able to run the report the report should be accessible only to the project team. The actual report should be run in a controlled manner during periods of low business activity with a time out setting that prevents long running reports from adversely impacting production. Functionality and configuration can be added, not replaced or deleted. This is meant to prevents unintended regressive impact. And finally, report iterations should be capped based on simple, medium or high complexity of the reports being developed. These should be agreed upon with the business team as part of the planning exercise.following these simple guidelines, an iterative Agile methodology can be used to ensure business and IT work together towards a common goal. The outcome is bound to be business-aligned SAP BI at reduced cost and with improved reliability. yes iterative BI cycle scoping & planning assessment for agile overall design Report Design no Review With buisness Build business sign off Transport to Prod Test alignment to release when part of a project/rollout detail design build & unit test informal test formal test UAT cutover to prod Figure 1 SAP Bi Deployment Methdology-Suggested Approach I The Gartner Scenario for IT Service Providers : IT Services in a Digital Future 3
About the author Sangita Kumari SAP Architect/Consultant Sangita Kumari A well-rounded SAP Architect/Consultant with experience in creating BI/BW/HANA solutions for a range of industries such as Retail, Manufacturing, Energy and Utilities, Healthcare and Life Science; Managed technology and people for both Start-ups and Fortune 500 companies. Responsible for all aspects of software-based product s life cycle from concept to delivery. 4
Wipro Limited Doddakannelli, Sarjapur Road, Bangalore-560 035, India Tel: +91 (80) 2844 0011 Fax: +91 (80) 2844 0256 wipro.com Wipro Limited (NYSE: WIT, BSE: 507685, NSE: WIPRO) is a leading global information technology, consulting and business process services company. We harness the power of cognitive computing, hyper-automation, robotics, cloud, analytics and emerging technologies to help our clients adapt to the digital world and make them successful. A company recognized globally for its comprehensive portfolio of services, strong commitment to sustainability and good corporate citizenship, we have a dedicated workforce of over 170,000, serving clients across six continents. Together, we discover ideas and connect the dots to build a better and a bold new future. For more information, please write to us at info@wipro.com IND/BRD/JUL 2017-JUN 2018