Introduction
The company is one of the largest utility companies, providing power, heat and gas. When they contacted me for the first time it was actually for a quite technical reason. They asked me how to create and update SAP NetWeaver BI master data via BI-IP (BI Integrated Planning) within their existing NetWeaver BI 7.0 system. I showed them an approach using Visual Composer and ABAP function modules which I have been applying at other projects.
Continuing this discussion we developed a prototype for a maintenance planning process based on this quite new technology. Especially the easy to use UI as well as Visual Composer's capability of combining BI queries with transactional business logic encouraged the company to turn this prototype into a real application.
Within the following lines I wrote down the scope of the project and my lessons learned.
Challenges and opportunities
The companies maintenance planning process is a yearly repeated operational planning process which happens before the official overall cost planning process. From April to September the maintenance group plans its estimated costs for maintaining the companies five power plants. For the upcoming year the costs are adjusted to cost elements whereas they are aggregated for the additional next four years.
The process itself is initiated by the technical controlling department. After process start the maintenance group - all technicians who try to avoid "unnecessary" administration work - creates maintenance tasks, assigns them to maintenance projects and provides the key figures. Finally the data's returned to technical controlling, consolidtated and entered into the existing SAP BW/BPS based planning tool.
Before this project the company used Microsoft Excel to build the workflow on. As the size of the Excel workbook was 50 MB+ as well as the data quality wasn't ok this process proved to be very time consuming. The result were high process costs as well as low transparency due to missing reporting functionality.
For me this is a quite typical situation. Planning processes of any kind frequently reach over department level thus involve different people with different roles. The consequence is that the different group of people uses their preferred tool to do their job resulting again in so called system and media breaks.
Objectives of this project
The prime goals of the project were the following:
- Reduce costs of maintenance planning process for power plants
- Provide up-to-date information on actual and planned data of maintenance costs
- Ensure maximum user acceptance of application
- Minimize operating costs
- Ensure future security on investment by implementing first services for Enterprise SOA
In regards to functionality the application should ensure the following:
- High data quality via three step data approval workflow and up to data status tracking
- Comprehensive reporting functionality: planning history, status tracking, plan/actual comparison, individual pdf document "project report" based on various BI documents, characteristics and key figures
- Support of multiple planning versions, comprehensive commenting functionality, seamless integration into the BW/BPS planning tool and reassigning/copying of projects as well as tasks
- Seamless integration in to the specific power plant maintenance hierarchy
In order to archive these goals we developed a solution which eliminated the use of Microsoft Excel. Instead, a new web based front end was built to collect the planning data as well as to create new master data directly by the end users. At the end the planning process could be shortened and unnecessary work for the technical controlling department could be minimized.
Implementation highlights
The project began with an in-depth business and technical concept of the application. It was key to me to include the controlling and maintenance teams from begin on. Respective workshops took place end of 2007.
The result was a detailed business document which contained a verbal description of all use cases, the UIs which we had to implement as well as the content of the reports. Based on this business document we created a specific software design document for SOA-based application development. This is a document which precisely describes which UIs call which enterprise services, which enterprise services are based on technical services and so on.
This document was really important for me as it helped me organize my mixed team based on BI, ABAP and Visual composer cracks. In February 2008 we actually began developing the solution. We decided to use following architecture:
As you can see the heart of the solution is SAP NW BI 7.0. It generally speaking stores of all of our business objects we create/read/update/delete in the process. Most of the business objects are stored as BI characteristics in order to be available for BI reporting, whereas the planning data which is entered by the maintenance people is kept as key figures. Some of the characteristics are individual to this application whereas others belong to the corporate planning application. This makes sure that we get an integrated corporate reporting.
Now I'd like to emphasize an important point: Instead of using BI-IP we used Visual Composer with self developed enterprise services to write the planning key figures. The reason is that the end users expected very ease to use web front ends which incorporated change of key figures and characteristics. Additionally the enterprise service needs to cover additional business logic such as security checks. The possible flexibility gain of BI-IP was to performance expensive for us, so we decided to write delta packages into a transactional cube. On top of the planning cube we made a multicube which is only used for reporting purposes.
To meet the requirement of generating a highly customized PDF document we developed a set of Enterprise services which renders a Sap Script form into a PDF document. Adobe interactive forms have been under evaluation, but due to potential license costs we didn't use them.
The implementation of the application took approx. two months, followed by extensive technical tests. Finally the application was tested by the end users, approved and went into production at April 1st 2008.
Since then the application has continuously been extended.
Benefits
First of all the major goal to streamline the process itself by eliminating Microsoft Excel has been met. The process costs could be reduced significantly.
Additionally ad-hoc reporting empowers the company to increase transparency about their maintenance plan and actual costs. This helps control the development of the costs.
The feedback from the end users was very positive. Some of them even like it more than Excel! This is confirmed by very low training and support costs. It took just 45 mins to train the end users.
At the end I applied with this project for the SAP Enterprise SOA reference case. I'm pleased that it has been officially accepted.
Lessons Learned
This project was very exciting, but tough though. Visual Composer is a great tool and SOA certainly helps reduce implementation costs, but we faced some challenges I'd like to share with you.
I personally see following points as positive:
- SAP Portal, Visual Composer and Enterprise SOA efficiently help provide the end users exactly these front ends they expect at this time to support the process
- UI Composition with Visual Composer is very quick, but requires detailed specification with the end users. Don't just go and create!
- Having a solid software architecture runtime performance with Visual Composer is ok, except initializing time of Adobe flash based Visual Composer iViews. Our VC UIs are deployed using Flex 1 as WebDynpro HTML runtime doesn't support BI queries and flex 2 doesn't run stable enough. I strongly recommend using VC CE 7.1 with WebDynpro HTML runtime. Experiences from other projects show 20%-30% less development time and compile and runtime high performance. Additionally you get rid of the flex initialization time.
- Although we used a combination of different technologies (ABAP, Java, Portal, Visual Composer and BI) robustness of the solution in production environment is ok. No major break-downs.
- No major change requests driven by the end users after going into production. This is certainly due to the detailed business and technical specification. I'm still not happy with the available documentation tools though
Following bullets need some level of improvement:
- Understanding technical architecture of the Visual Composer server is key in daily live. Sometimes you get deployment errors you never have heard before and only find little information about it. It's essential to understand how the process flow of your VC model is at runtime, too. You may get surprising results just because you forgot to specify the right "event guard condition".
- Without using CTS+ consistently transporting Visual Composer, portal, ABAP and BI objects is a mass. It's a huge manual work.
- Version control is not really available. In order to be able to always deploy a certain version of our application I was heavily looking for NetWeaver support. I didn't find something. So we helped us by copying the development objects and putting them into the right name space or adding the version into the object name
- BI Hierarchies in VC are tough to develop in order to get good end user experience. There're several how-to guides at SDN but at the end runtime performance was to slow. So we helped us by simulation the hierarchies using several tables - one for each node level. VC CE 7.1 Ehp 1 allows seamlessly embedded Web Dynpro Java UIs. I'm looking forward to use those to build the hierarchy tree, surrounded by the VC UI components. I expect better usability then.
So, that's all for now. I hope I could help you with some interesting information and would be happy to answer to your questions.
1 Comment
