SAP

Individual Process Quality aspects in SAP ERP (HCM )- Part 3

2011-12-25T22:18:59Z

Test Procedures:

A specific problem when maintaining data for time management is caused by intended or unintended changes that reach too far back into the past. This can be restricted by limiting retroactive accounting relevance. There are often situations where it should be possible to make corrections that extend one or two years into the past, but not every time representative should have the authorization to make such corrections. This can be reflected using Info type 0130(Test Procedures). You can also use it outside of time management, but this is an area where it is frequently used. To configure this in customizing , go to PM->PA-> Tools-> Authorization Management-> Test Procedures. ]]> You can also use it outside of time management, but this is an area where it is frequently used. To configure this in customizing , go to PM->PA-> Tools-> Authorization Management-> Test Procedures. You can define one or more test procedures here. You can assign a number of info types and subtypes to each test procedure .For each test procedure defined this way(number of info types or subtypes), you can now define the point in the past to which data can be changed retroactively. Users who have maintenance authorization for the corresponding subtype of IT130 can also maintain the corresponding data in past .

Automating Tests:

Depending on the company, very complicated rules can underline the time evaluation process. It is also very difficult to configure customization via schemas and rules. This makes testing very important and particularly difficult. A serious problem is created by the fact that when a particular rule is changed or a specific error is corrected - although the directly affected areas are tested- There are often unexpected consequences in completely different areas.This problem can be resolved by automating the test. There are tools available on the market that compares the results of copied personnel numbers with those of the original in the productive system. In many projects, it has proved worthwhile to setup successive, comprehensive test datasets, that are tested automatically at every change. To do this we need a program that stores reference results for all test cases.Everytime a change is made, the program can determine where the new results differ from the reference results. This kind of program is called test workbench .

Setup of an Internal Control System :

An essential pre-requisite is the clear definition of processes, including their documentation beyond system boundaries . Some aspects that are outside the system and should be observed within the framework of an Internal Control System:

Ø Simplification of process

Ø Clear definition and communication of process

Ø Checklists

Ø Responsibilities

Ø Leeway of exceptions

Ø Use of tools outside SAP HCM

Ø Traceability/ auditability

It is recommended to create a main document based on the goals in which all the important elements of the internal control system is documented

v Which processes are contained ?

v How much they be described and where can you find the documentation?

v How does the IT system support the quality of the processes?

v How are the system changes made and documented?

v How much test procedures be described ?

v How are tests and other test-relevant facts documented in a revision-proof form?

v Which checks are implemented periodically?

Note : If an Internal Control system is not adapted to the actual requirements continuously, the employees are bound to work around it.

Always keep the following two principles in mind :

ü The system compliance must be possible with the available capacity. The intelligent use of system, checklists, etc. facilitates the employee's work.

ü The system must be maintainable. Definitions that are too specific require permanent adjustments .

Maintaining Quality in SAP Projects- Part 2

2011-12-11T18:49:30Z

Cross -Process Quality aspects in SAP ERP (HCM ).

Quality in and of itself is a critical success factor for HCM Projects and any ERP projects. It should, however, be based on a clear concept and not simply be implemented for its own sake. Projects can also be needlessly stifled in the name in quality.

Structured Procedure: There are many process models for implementing standard software products. Quality problems arise for the following three reasons:

ü The selected process model is not used because it entails to great a workload.

ü The selected process model is not used because it cannot be applied to the actual situation

ü The process model focuses on implementation and requires clear and sensible definition of the requirement.

An "Off-the -rack" process model can only server as a rough guide. One of the first tasks of a project team is to create a project-specific model from a general process model. The team must not only consider company -specific factors, but also the special characteristics of SAP ERP(HCM). It is not enough for a technically oriented process to stipulate the definition of the most important structures. For a HCM project, the team must define the company and employee structure and use of the Organizational management.

A clear definition of requirements that clearly describes the planned processes is indispensable for Quality. The planned processes are, after all, the means for measuring the success and therefore the quality of Project .

]]> The following points should be clearly documented in some form:

ü What services should the SAP ERP (HCM) system support?

ü How are individual processes reflected in the most important variants?

ü Which exceptions should you be aware of?

ü What technical and organizational interfaces are provided?

These points should be supplemented with a detailed description of the data and

interfaces that can be refined over the course of project .

Documentation and Customizing:

Because the SAP ERP HCM system is constantly changing, the changes in customizing and programming are not only driven by real process improvements, but also by work agreements, wage agreements, and regulatory changes. Another measure of the ERP dynamics is the number of support packages delivered by SAP. It is strongly recommended to have a clean structure and ongoing cleanup of customizing entries and report variants . Also, an easy to go documentation is very important for ongoing maintenance. It is always important to document frequent small changes as quickly as possible. However , you should not be tempted of simply repeating the contents of the customizing table in the documentation. Instead, you should concentrate on following :

ü Reasons for doing the certain settings

ü Reference to laws, work agreements , process descriptions, or other documentation

ü Naming conventions

ü Modifiers or groupings (Specially in SAP HCM)

Clear and Transparent customizing :

Clear Customizing in both the implementation and maintenance phases represents a significant contribution to QA. During implementation, clear conventions are very important, especially when structuring tables that contain many entries. In SAP HCM system it applies when defining wage types or time types, for example. Also, the relationships between the different customizing tables are often extremely complicated and multilayered. Before you make your settings in customizing entries settings , you should graphically display the dependencies for the area of work in and create a configuration design with easy to sue naming conventions. Every time a subsequent change is made to the settings, you will be rewarded for the initial time invested. Many of the settings in HCM are subject to extreme changes, so you should make sure that customizing entries that are no longer required are time restricted. Unfortunately, some table entries cannot be time restricted, because they are not stored with start and end dates. These includes, (Employee Groups/ Subgroups; Personnel Areas/ Subareas).While most users may not see this as a problem, but eventually it will become a problem after several years of production system operation . In customizing, there is a way to improve input help for end users and to indicate obsolete entries. If you add "ZZ" to the beginning of the text description, then the corresponding settings can be recognized immediately. Because most input help programs sort the entries by text, rather than by the key, these obsolete entries will appear at the end of the list(Note that in other input help programs, there is still the option to sort the entries by text, rather than by key, these obsolete programs will appear at the end of the list.

Test Concept:

Tests in SAP ERP (HCM) system often focus on the correct calculation in the areas of time management, remuneration statements, Payroll , and the company pension / benefits plans .While these areas requires heaviest testing, it is important not to forget the tests for more dialog -oriented processes and evaluations. To test dialog applications, CATT processes can be used.

HCM is characterized by strong relationships between individual components and changes to planned results over time. Fr this reason, it is particularly important to document the test cases in a structured way and to setup a lasting test dataset. Setting up test data can be time -consuming and laborious. You have to take into account very different configurations and many exceptions. It is , however, possible to reduce the workload involved in setting up test data .

ü Personnel data(HR master, including payroll etc) can be copied if you use the right programs . This can be done within a system and across systems. Cross -system copying can be used to copy new configurations from the production system to test systems on a regular basis, to keep the test dataset up to date.

ü Objects in personnel planning and development is generally copied on a 1:1 basis from the production system, it is possible to copy the data without a special tool. Instead, you can use ALE functionality to copy Org Mgmt, from prod to test system .

ü Anonymity is probably the most critical factor when copying test data from a production system. Usually, for data security reasons, it is not possible to use original data in test system . Some companies deal with this problem by setting up the test environment within the quality system in which the use of original data is not critical, however the quality system would have to be subject to the same access authorization restrictions that apply to production system.

The following points list criteria that may have relevant when choosing a copy tool :

Ø Is cross system also possible?

Ø Is data security guaranteed during cross -system copying?

Ø Is there an anonymization option?

Ø Is it possible to adapt the range of data to be copied and the anonymization process to your company specific requirements?

Ø Apart from the HR master data, which data can also be copied?

Ø Can several people be copied in one run?What is the selection process and how long is runtime ?

Ø Pricing , including maintenance(Mostly applicable for new releases)

Ø Is there a log that allows tracking of copy options ?

Authorization Concept:

In SAP HCM, the authorization concept check is often seen as particularly critical. This is due to the sensitivity of HR data and the importance that employee representatives. Furthermore, the authorization concept of SAP ERP (HCM) is extremely complicated. In a strongly decentralized implementation of the system, creating, implementing and testing of authorizations are often extremely labor intensive tasks. It is much more important to include authorizations concept from the very beginning of the HCM project. It will reduce the workload at later stages of the project.

Decentralized Use of the System :

SAP ERP HCM is increasingly decentralized(i.e., implemented outside of HR department).This is the best way to support the HR processes while not being limited only to HR department processes.

The decentralized development can, however create some quality problems. Aside from the special requirements for the authorization concept, it is important to bear the following points in mind .

ü For medium sized companies, definition of quality process is implicit, as long as there are limited no of system users. With decentralized implementation, user numbers quickly shoot up to large numbers , which means that process changes can no longer be made at will. Process must be clearly defined .

ü Complexity of the applications must be kept at a much lower level than for users in the HR department. This can be done by efficiently using specific interfaces that can complicate the process for ex : MDT, ESS/MSS, Time manager workplace etc

ü To make processes more efficient and secure, process automation is specially useful when many users outside the HR department are involved. You can use workflows or generation of emails by custom ABAP development.

Auditing Tools:

Basically the auditing tools allows you

ü To define rules about what situations are considered an exception, which leads to a warning message or an error

ü To identify all exceptions with a reporting tool that allows you to deal with each exception(Ex approving or correcting a data ). The tool will keep a track record of each exception and the way it was dealt with, so that the auditor can access the whole process.

Maintaining Quality in SAP Projects

2011-11-27T23:23:12Z

Quality in Software Projects

Implementation projects for IT systems are often subject to extreme time and budget constraints. Even if the initial project planning is realistic, pressure can arise from the following factors :

ü Late or drawn out project start;

ü Use of capacity elsewhere (especially if the workload for ongoing everyday tasks has been underestimated);

ü Changes in the project team members during the project execution;

ü Constantly changing requirements during the project execution stage.

]]> When projects are under pressure to meet a deadline or stay within a specific budget, quality is often neglected to save resources . This is a short term approach, however, it may help to keep deadlines when running projects with short runtimes, but at a price for a much poorer quality .

Typical Quality problems can be divided into four main categories:

ü Incorrect Definition of requirements

The first project phase is used to generate system requirements. Due to communication problems or the inclusion of the wrong group of people, the planned processes are often misunderstood . Just as frequently, individual processes or process variants are completely overlooked. In both cases, these mistakes may only come to light during the end user training

Or even during the production support operations stage.

ü Incorrect Mapping of Requirements

This is the classic "quality problem" that often the users define as a "program error" leading to incorrect system behavior. Along with a clear concept and a well-defined project team, structured tests are indispensable .

ü Incorrect use of System

System providers and consultants (even the internal business users) are often all too eager to call these problems "user errors" thereby removing them from their area of responsibility - even though the users are not completely without responsibility in the situation. Change management in its broadest sense (including user specific training) and optimal system support (ex: via plausibility checks) can, however reduce the user errors during the implementation

ü The Maintenance Trap

Quality problems that occur only some time post the production support starts can also be tracked back to implementation. Missing documentation or badly structured customizing or program could not that makes the maintenance more the difficult.

Architecture Plan for SAP Netweaver based Solution

2011-11-10T05:07:14Z

Architecture for any IT based solution is a most important factor for aligning IT with business expectation. This also facilitates a transparent and manageable roadmap for most adaptable and efficient system landscape. An effective architectural design of a solution helps business to fulfill their target in an open, scalable and easy to handle infrastructure. This blog will focus on approach of an architecture design for SAP Netweaver based solution.

]]> Before starting an architecture design, first make a decision about the platform on which the solution will be built. As this blog is considering SAP Netweaver based solution as an example, the solution in discussion will be built on SAP Netweaver platform. First step is to consider Basic Architecture of the decided platform for the solution. It means the basic architecture of Netweaver based solution is briefed in a refrigerator-type diagram as shown below:

Once basic architecture is defined, we need to go through the use cases for the solution. Based on the use cases, the decision has to be made on component of Netweaver stack to be used for solution design. For example, use case says develop a User Interface which will be used to display analytical reports based of user's input data. Based on this use case, solution needs at least Portal, Business Intelligence (BI) and J2EE application server. This is the minimum component required to fulfill the use case requirement. So this is the second step for defining architecture for a solution and is called minimum infrastructure based on solution concept.
The third step is to finalizing different components required to implement this solution and is called minimum infrastructure with respect to SAP product. Different phases involved with solution implementation are Blueprint, Build, Execute and lifecycle management. In this step, SAP product has to be outlined for different phases of solution implementation. For example, to build portal based application, we need Netweaver Development Infrastructure to manage coding other than portal application server. Other different products might require are CTS+ for transport, NWA for administration and others.
Once all products decided for solution implementation, the last and final step is detailed solution deployment infrastructure. This step can be achieved by applying different architectural/deployment principles applicable for the selected products and recommended best practices for those products. Based on this step, an architect can revisit the decision made in previous step to give more effective design.

Below content showcases the points discussed above:

Base Architecture(Solution IT platform)
Minimum Infrastructure (Based on use case concept): Influenced by Solution Use Cases
Minimum Infrastructure (Based on SAP product)
Detailed Solution Deployment Infrastructure: Influenced by Architectural Principles, Deployment Principles and Best Practices.

Mobile Business Intelligence - Part 2

2011-11-09T20:41:29Z

In the first part of this blog, we discussed key elements of Mobile BI, options for delivering BI content on mobile devices and business scenarios best suited for mobile usage. Now let's talk about specifics from SAP in this area. I will cover various technology options from SAP, their use cases, device support and some future enhancements from SAP.

]]> Mobile BI is not new at SAP. Business Warehouse 3.0 offered what was known as BEx Mobile Intelligence. It facilitated rendering BEx Web Reports, developed using Web Application Designer (WAD), on PDA's and WAP-enabled phones. It had device recognition and rendering capability which meant that you could create one single template and use it on multiple devices.

The product was meant for early generation PDA's and WAP phones, and did not really come up to newer feature-rich and highly capable "Smart Phones". BEx Mobile Intelligence has not seen any new upgrades or enhancements in a long time. One of the reasons could be SAP's acquisition of BusinessObjects (BO) and its strategic decision to make BO as the primary Business Intelligence offering. If you are looking to start your Mobile Business Intelligence now, you should not consider BEx Mobile Intelligence as a strategic tool (it could be used a quick-win tactical solution though).

So what are the Mobility options on BusinessObjects toolset? At a high-level there are two; BO Mobile and BO Explorer Mobile. Both these serve different purposes. BO Mobile is meant to deliver targeted BI content to users based on their roles, whereas BO Explorer Mobile allows users to use search and exploration feature of Business Explorer via mobile devices. In other words, BO Mobile allows users to access predefined purpose-built BI applications from their mobile devices and BO Explorer provides them Google-like search feature to analyze data using auto-generated data visualizations on mobile.

BO Mobile enables accessing Web Intelligence (WebI) and Crystal reports content on Mobile through a device-specific client application (or "app"). It allows users to connect to BusinessObjects servers in the corporate network through mobile and render the reports that are already published on the server for that user/role. Although the reports have to be predefined, neither the data is not static nor are the reports "broadcast" to users. BO Mobile allows users to access the content on-demand (or "pull") and interact with it. Some of the key features it provides are document refresh, changing filter values (prompts), drill-downs, navigation to other hyperlinks defined on the report, invoking device-specific actions such as phone call, SMS text or Email, and sending document link via email, etc. It also allows users to receive alerts when a document is refreshed on the server or an exception condition is met. Users can also download report on the local device and access offline.

BO Mobile is supported on Windows Mobile, Nokia and BlackBerry Smart Phones. In June this year, SAP also released an app that allows accessing WebI reports on iPad. For iPad support though, you need BO 4.0 SP2 or BO XI 3.1 SP4 on the server side. Also, currently iPad only renders WebI reports (no Crystal) and some features like drilldown are not supported. But I must say that the visualizations on iPad look gorgeous!

Now let's talk about BO Explorer Mobile. This product extends the core search-and-exploration capability of BO Explorer to mobile devices. As we discussed earlier, the use case is completely different from BO Mobile. Here the objective is not to render pre-defined BI content, but to allow users to perform ad-hoc analysis. Visualizations are automatically generated by the system, similar to BO Explorer on desktop. However some backend work in terms of defining InfoSpaces etc. is still needed. You would need BO Explorer installed and configured on top of your BusinessObjects environment, and for a superior performance an accelerated (in-memory) version is recommended.

Currently the BO Explorer Mobile is available for iPad and iPhone as a downloadable app from Apple AppStore.

Both the above products do not address one key ask of many organizations and users - Xcelsius Dashboards. So how does one access Dashboards on the mobile? Well, there is one option. As most of you would know, Xcelsius Dashboards are rendered using Adobe Flash running in device browsers. So, technically, any device that can run Adobe Flash can render Xcelsius Dashboards. Users using Android devices (Smart Phones or tablets) or BlackBerry PlayBook can simply access Xcelsius Dashboards through their device browsers. As discussed in the first part, this is an example of RIA rendering. Only condition is that your BO Enterprise server should be accessible via Internet/VPN and device should support Flash. However as we all know, within tablet space, iPad is the big elephant, and since iOS devices do not support Adobe Flash, currently iPad and iPhone cannot run Xcelsius Dashboards. L

So as you might agree, SAP provides quite a lot of options and features to mobile enable your Business Intelligence. But I think there are some key elements still missing -

1. BO Mobile support on iPhone (currently only iPad is supported)

2. Drilldown functionality on iPad/iPhone

3. Ability for users to customize charts/reports and save views

4. BO Mobile and BO Explorer Mobile support for Android devices

5. Xcelsius on iPad/iPhone

As per SAP, many of them would get addressed in the newer releases that are in "pipeline". (Disclaimer: product directions are subject to change)

Device support - Support for iPhone, Android devices and BlackBerry Playbook

Feature enhancements - Drilldown on iPad/iPhone

Explorer Augmented - Will integrate location awareness, device camera and map visualization in BO Explorer Mobile

Exploration Views - An extension on BO Explorer Mobile allowing users to customize and share different visualizations.

Unified Mobility Platform - An integrated platform for Business Process Mobility and BI Mobility. Currently both exist as independent product stacks (Sybase and BO Mobile) and technologies.

Well, that concludes this 2-part blog. In Part-1, we discussed generic aspects of Mobile BI, and in this part technology options from SAP. Hope you found them useful. Do write-in your comments/views/suggestions...

ARRIVED: SAP Business Intelligence 4.0- PART II

2011-11-08T11:25:26Z

Continuing from my blog on BI 4.0 strategic direction on the reporting platform http://www.infosysblogs.com/sap/2011/10/arrived_sap_business_intellige.html, I would now like to focus on the strategic direction being taken around data integration or Information Management (IM).

· Finding your place

When we talk about Information/Data Management we usually talk about 3-4 broad areas:

]]> · Data Integration

· Data Quality

· Metadata management/master data management

SAP is addressing the above through its offerings around Business Objects -Data Services (DS) and Business Objects -Information Steward (IS). While Business Objects -Data Services combines the ETL from its legacy BO- Data Integrator (DI) and Data Quality (DQ) ,which in turn was acquired by Business Objects after its purchase of First Logic in early 2006. This combination of BO-DI and BO-DQ had anyway happened in the version 3.x. However Version 4.0 takes things further in terms of enhancing and automating the data quality checks [Checking the authenticity of postal codes of China] is a case in point and creating a homogeneous offering of the ETL and data cleansing capabilities.

On the other hand the functionality that Information Steward brings to the table is a full suite of data profiling, rules builder as well as metadata management capabilities. Version 4.0 provides a nice integrated interface of all these sub application in an easy to use navigation.

While all these functionalities are needed for building a best in class data management solution I as an IT practitioner would prefer to see the data profiling and rules builder to be closely working with my data quality platform. In a typical data enrichment process I would approach it in the order of Data Profiling à Rules Package Builder à Data Quality/Cleansing. To do that I would rather have all these functionality integrated together on a single platform.

At the same time I can possibly see the direction that SAP is taking with regards to the positioning of BO-DS and BO-IS would be for two different set of people in the enterprise. While BO-DS would remain positioned for the IT department, BO-IS given its highly interactive interface is for the business analyst's use. Here SAP is towing the copybook line whereby it is said that business knows data better than IT and there cannot be two ways of looking at it!

· The Power of NOW

A lot has been said and debated on the need and ability to deliver analytics on a real time basis. SAP's offering with Events Insight tries to address this space. It can raise alerts on a 'near' real time basis. Using Sybase Complex Event Processing (CEP) capabilities it is able to match patterns and recognize occurrences. The use of this tool, I think can largely lie in the area of Business Activity Monitoring as well. However the added capability that Events Insight provides its ability to integrate with BI analytics engines like dashboards and reports. I see logistics organizations being able to make good usage of its capabilities.

Regression testing automation in SAP: How to make it a success - Part - II

2011-11-07T03:41:39Z

by Madhup Mukund Paturkar

In last blog we discussed about why regression testing should be automated. Also we discussed about the contents & important of Process Mapping and Test cases. In this blog we will look at the approach to automation project and tools provided by SAP.

Approach to test automation project:
The approach to SAP automation will also depend on many other non technical issues few examples are business process readiness, test case readiness and budget and time constraints.

]]>

Above figure shows simple execution model for the automation project. Ideal way to do automation project can be with upgrade or any rollout where regression testing is being done manually. But before you start the automation project, it is expected that Process Maps are ready. Test case preparation and test data creation for the process along with automation can be achieved as a parallel process to any big project or upgrade. This gives saving of effort in terms of test data and test case creation. The same test cases and test data can be used in automation as well it helps to do the regression testing during big project or upgrade. To keep the momentum it is expected that you finish the automation project along with the regression testing of the already running project. Automation will always be lagging functional test data creation.

Operating model shows the tools used and data flow. It is expected that senior functional consultant to create detail business process flows. Based on the analysis of the flows functional consultant can create the test cases as explained in first blog. The variation of test data for a unique t code needs to be captured in test case. Automation team will need details of the flow and test data for the flow as well as test case. Test automation team needs a close co-ordination with functional team to understand the flow and variations. SAP experienced test automation consultant in this particular model is added advantage.

Tools required in test automation:
In order to run the entire project efficiently, you need tools like SAP TAO, HP QC, QTP and Solution Manager. ARIS is a tool provided by Software AG Company which has a very strong integration with Solution Manager. Process can be mapped in Solution Manager or ARIS-Solution Manager together. ARIS gives a very good front end for end users to understand the process and further enhance it. Purely from automation point of view ARIS is not mandatory.

Solution Manager has direct link with QC to create the requirements. Actual automation is done with help of SAP TAO and QTP. SAP TAO helps a lot in generating the components from SAP. Details about these tools are generally available on web.

Mobile Business Intelligence - Part 1

2011-11-04T06:26:31Z

With significant new advancements in mobile technology and devices capabilities, coupled with growing importance of Business Intelligence (BI) within organizations, it is no surprise that Mobile BI is gaining so much attention. In the first part of this 2-part blog, I will discuss key elements of Mobile BI, options for delivering BI content on mobile devices and business scenarios best suited for mobile usage. In the next part, I will cover Mobile BI technology from SAP BusinessObjects perspective.

]]> Let's first start by defining what Mobile BI is. In my view, a Mobile BI is an interactive BI application catering to a specific business scenario and tailored for mobile usage and devices.

First and foremost, it is an interactive application that allows users to "play" with it by way of slicing, dicing, filtering, etc. It is not a simple static web page or PDF that is broadcast to users' mobile through emails.

Mobile BI is not just another frontend. Mobile BI application needs to be designed keeping in mind the business scenario that it will be catering to. Not all scenarios are suited for a mobile use, and mobility option should not be "enabled" for all BI applications.

Another side of the above coin is that BI applications need to be tailored for mobile usage. A report designed for desktop or web usage might work as-is on a mobile device. However for optimum usage on a mobile device, a Mobile BI application needs to be tweaked/customized considering various factors such as screen size, amount of data to be passed over the air, device capabilities and features, etc.

Lastly, the device support. Each device type has different features, capabilities and limitations. Typically you would not be able to create a BI application that will work the same way on all devices, unless it is a static HTML or PDF. So you would need to tailor your application for the most commonly used devices by the users of your application.

From a device type perspective, Mobile BI is targeted towards the Smart-phones and Tablets. Although BI on Smart-phones has been around for quite some time, it is the emergence of Tablets that has created whole new opportunities for Mobile BI. Many analysts feel that a tablet is the right device for delivering BI content on mobile given its screen size, processing power and interactive touch capabilities.

Let's discuss the ways in which BI content can be delivered on mobile devices. There are primarily 3 options and each has its pros and cons. But the choice really boils down to how much customizing/maintenance effort you are willing to spend vs. the user experience expected.

1. Delivering BI Content on Device browsers - This has the least amount of customizing effort and will work similarly on most devices. But on the flip side, user experience is quite basic and does not take into account device capabilities.

2. Delivering BI Content through Rich Internet Applications (RIA) e.g. Adobe Flash - Here too customizing effort is not significant and it will work similarly on most devices. Also it provides great interactivity as compared to a plain browser. However it does not leverage device features and moreover not all devices support all RIA. For example, Apple iOS does not support Adobe Flash!

3. Delivering BI Content on device specific applications - This provides the best user experience leveraging device features and capabilities. However, applications need to be customized for each device type leading to higher customizing and maintenance effort.

I earlier mentioned that not all business scenarios are best suited for mobile usage. So where would Mobile BI make most sense?

• Providing on-demand access to BI for people on the move E.g. Field sales/service staff

• Mobile BI applications for people without regular access to traditional BI E.g. Shop floor managers, Retail store managers

• BI applications where data is updated frequently E.g. Inventory, Health & Safety incidents

• Integrated workflow and BI applications E.g. Approval for temporary credit limit increase for customer based on customer analytics

So we discussed key elements of Mobile BI, options for delivering BI content on mobile devices and business scenarios best suited for mobile usage. In the next part, I will cover Mobile BI technology from SAP BusinessObjects perspective.

Hope you found it useful. Do write-in your comments/views/suggestions...

Regression testing automation in SAP: How to make it a success - Part - I

2011-11-03T06:14:19Z

by Madhup Mukund Paturkar

Regression testing, Integration Testing and Unit Testing, all form important part of any SAP project. Testing is necessary but never sufficient. Testing becomes more complex in global-local object development scenario with multiple SAP clients across the geographies. In such scenario any rollout or a complex enhancement should ensure that regression testing is sufficient so that it does not affect normal operations.

]]> This entire activity needs effort and costs dollar every time you do it. Question which I would like to address is, can we avoid it? If yes, how to go about it and with which SAP tools? In this two blog series I would like to take you through some of the basic readiness checks in order to start the automation project so that you can achieve maximum efficiency during the project and SAP tools with methodology.

Here I am focusing on automation of regression testing. Never-the-less, automation can be extended to other type of testing as well.

Process mapping:
To do the automation, basic requirement is to have business process documented in the same sequence as it happens in production environment. The scope of process should include all manual activities, automated jobs, interfaces (inbound / outbound) and all legacy system related activities. To limit the scope till regression testing you need to identify and document all processes which you would like to include as part of regression testing or else entire process mapping in itself will be a big project.

Process should have a documentation of SAP T code, program or interface being used. Also it should clearly indentify the SAP fields which are passed from one step to another in order to completely execute the process. This is very important from automation point of view.

Test cases for SAP Component:
Process mapping will give you entire repository of SAP T code, programs and interfaces used as a part of regression testing. The test cases have to be prepared for each of these SAP components in the way they are used in a process. For example ME21n may be used in multiple type of procurement process. The test case should be unique for a t code / program / interface irrespective of multiple usages in processes. So ME21n test case should document as many variations of procurement process. The test case should clearly identify the process / processes in which the component is used.

Content of Test case:
Normally the test cases are prepared from the point of view functional or technical usability. In case of automation the nature of test case will differ a little. The test case should contain following important points:

1) Steps to execute a particular t code / program / interface

a. If a t code / program / interface are used in more than one way then test case should include all such possible variation. The possible variation can be concluded from the usage of the object in various processes. Extrapolate the ME21n example.

b. Success message for each t code / program / interface should be clearly identified with screen shot.

2) Data for the execution of t code / program / interface

a. If a t code / program / interface need more than one type data then all such data requirements should be documented. The possible variation can be concluded from the usage of the object in various processes. Extrapolate the ME21n example.

b. The data should be captured in such a way that the same data can be used when the t code / program / interface is used in the process.

c. If the data is received from the previous step or has to be used in next steps then it has to be identified explicitly.

In next blog we will look at the approach to automation project and tools provided by SAP.

Utilities can address Electric Vehicle Challenges with SAP Solutions

2011-11-01T13:28:58Z

Electric Vehicle adoption is becoming a reality worldwide and it is growing at an accelerated pace. Automobile manufacturers across the globe are focusing on developing electric vehicles for mass consumption. The developed nations specifically are seeing this growth which is fueled by numerous factors like:

]]>

Electric vehicles are becoming more and more affordable. Coupled with innovative buying campaigns, it is driving purchasing

Lower cost of ownership of electric vehicles since these are not dependent of traditional fuels and simpler mechanical technology translates into lesser maintenance and failures

Increasing cost of fossil fuels since most nations are dependent on imports for such fuels and hence often consumers are opting for their small vehicle as an electric vehicle

Environmental concerns caused by use of traditional vehicles with some nations having high taxation on these

Rebates and concessions offered by governments in use of electric vehicles either directly or indirectly

While all this growth of electric vehicles is good for the economy, good for the environment and of course translates into additional revenue stream for automobile manufacturers, electric utilities are really concerned on how they can address the impact to their business, planning and supply of electricity by this increasing use of electric vehicles.

Charging an Electric Vehicle consumes and demands significant electricity when compared to the overall household consumption and average demand in a billing period. Hence increase in use of electric vehicle creates additional consumption and demand requirements. Some of the challenges that electric utilities are facing with the use of electric vehicles are:

Utilities are unable to plan additional consumption or demand from use of Electric vehicles because utilities have no knowledge of number of such vehicles in a particular geography and at what time of the day these will be charged

Spikes in electricity demand can result due to concurrent charging patterns, sometimes leading to neighborhood blackouts

Meeting unplanned demand will require increase in financial, operational, field and planning resources

New services have to be introduced like public charging outlets and may have to be tied back to billing systems

Extra meters with line infrastructure and field personal may have be deployed to install dedicated meters in garage / parking areas

Standard household rates may not be valid for Electric Vehicles charging. Higher or different rates for Electric Vehicles may be required by some utilities or regulations

Changes may be required in bill print to show separate consumption for Electric Vehicles charging from regular household use

While the above are significant challenges posed by growing use of electric vehicles, there are possible solutions for utilities that are running SAP or planning to implement SAP based solutions.

Identifying additional demand and consumption requirements due to Electric vehicle use is important. Utilities can reach out to customers to understand their interest in Electric Vehicles and whether they are planning to purchase an electric vehicle in near future. The earlier the customers notify the utility, the more effective demand planning would be possible. This solution can be achieved in SAP in multiple ways:

This communication can be created as a campaign in SAP Customer Relationship Management with a preselected target group. Based on the response the campaign effectiveness can be analyzed and reported. Further campaigns can then be modified accordingly.
Bill Inserts via SAP Print Workbench or SAP certified products like StreamServe can help reach out to customers to gauge their interest in Electric Vehicles
With SAP UCES, customer feedback can be recorded when the customer logs into the online portal

Utilities can tie up with Electric Vehicle dealers/sellers in their geography to notify the utility on sale of Electric Vehicles per geography. Using SAP, an Idoc based integration can be achieved with the Electric Vehicles dealer/Seller sending out a message with details of customer who has purchased the vehicle and his address . The same customer's details can be updated with relevant information in the SAP Master Data if it is also the utility's end customer.

Some utilities may want to have differential rates and tariff for Electric Vehicle charging. Using SAP's IS-Utilities Billing module will allow to setup differential tariff for such cases. SAP IS-Utilities Work Management and Device Management modules will allow a separate meter installation and dedicated meter reading management. Utilities may recover the costs involved in additional meter installation from the customer. This cost can be integrated into the regular periodic bill by using SAP's Sales and Distribution Module and IS-Utilities Invoicing.

Customer awareness campaigns can be executed to educate customers on charging their Electric Vehicles at off-peak hours. This can again be achieved using SAP CRM Campaign Management, Bill Inserts via SAP Print Workbench or StreamServe and SAP UCES.

Electric Vehicles can also be integrated into the Smart Grid. With this integration, utilities will have the ability to remotely disconnect Electric Vehicle charging to reduce peak load on the local distribution infrastructure. This solution can be achieved with SAP IS-Utilities AMI integration pack of AMI where remote disconnection services are provided.

Increasing outlets for public charging of electric vehicles will allow utilities to closely track and monitor growth and usage of electric vehicles in a geography. With SAP's Enterprise Asset Management modules, utilities can perform the entire blueprint to construction to maintenance of such charging outlets.

A customer using a charging outlet can input his Customer or Account Number prior to charging. With SAP Mobility solutions these charging outlets can be integrated to SAP IS-Utilities Device Management modules to capture consumption and the same can be billed and included in the periodic bill of that customer.

SAP Print Workbench and StreamServe can be used to enhance customer bill print by showing separate consumption and billing line items for electric vehicle usage.

SAP BI can be used to generate business reporting for electric vehicles. Some of relevant reports can provide insights into revenue by EV consumption, penetration of Electric Vehicles, forecast in growth of Electric Vehicles, Charging station utilization etc.

While Electric Vehicle challenges will continue to grow, with SAP based solutions, utilities should be able to address these challenges in a more effective and organized way and for a much longer term without having to incur significant significantly or bringing in 3rd party solutions.

ARRIVED: SAP Business Intelligence 4.0 -PART I

2011-10-26T06:13:58Z

SAP's Business Intelligence product platform reached a critical milestone last month when the much awaited SAP BI 4.0 was made for General Availability (GA) on September 16^th. Although the event was a bit muted and probably lost in the din and hype on HANA, it was definitely a corner stone in SAP's journey to transform its Business Intelligence bouquet. In this blog I would like to talk about the strategic direction that SAP is taking with this new platform both in terms of Business Intelligence (BI) and Information Management (IM). While in this blog I will provide my view points on the shape that BI is taking, I will be talking about aspects of IM in the subsequent blog.

]]> · Fitting the square peg in the round hole

With SAP's acquisition of Business Objects (BO), the BO flagship WebI had become the de facto 'cure all' pill for whatever BEx analyzer lacked, especially with regards to interactivity and powerful navigation . Many SAP BW Customers, under lack of guidance thought that WebI was a one to one replacement for the existing OLAP analysis tools of SAP BW and ran into multiple challenges with respect to mapping capabilities (especially hierarchies) and poor performance. The simple fact of the matter was that WebI was never an OLAP analysis tool and the attempt to force fit it for doing it and trying to leverage its interactivity was a misplaced option.

SAP BI with its release 4.0 has taken a step forward to provide the cure all pills with BO Analysis, Office and OLAP (Web) versions. This platform, especially the OLAP edition is the best of both world bringing in the native BICS connectivity to the BW OLAP cubes and also the much needed interactivity. WebI with version 4.0 has also been enhanced to inherit some of the OLAP properties, especially the hierarchical representations, which I personally believe was probably not necessary when BO Analysis Web would serve the same purpose anyway. At the same SAP has been very categorical in mentioning that the positioning of WebI does not change and it continues to remain an interactive ad-hoc analysis tool and in no way going to transform itself to become an alternative OLAP analysis tool. I think this messaging and reiteration was very important and reassuring to the large constituency of the traditional non OLAP users of WebI.

· United we stand

The above adage may not be literally true with SAP's BI bouquet but definitely working in isolation with the disparate products for various analytical purposes was bit of a bother. Bringing them all on a 'common launch pad' with close look and feel is definitely going a step in the right direction.

However the bigger success in my view has been achieved with the ability to unify the metadata management capability of WebI , Xcelsius etc. using the Common Semantic Layer (CSL) and powering it with the BO-Data Federator engine. I am yet to see this in action but hope that this will address the issue of unifying the tools and also the make meta data access, free of performance bottlenecks (even without HANA that is J!).

Of course the capability to integrate data from multiple heterogeneous data source remains another milestone in the CSL offering.

· Off with the middleman

Weren't the MDX layer and the SAP Integration kits the guys we all wanted to see go? Those of us who would have possibly worked with the SAP BW integration with BO XI 3.x would understand the aspects design and the tuning that had to be done keeping the MDX layer in mind. BI 4.0 sees them all out of the window with a native BICS integration with the erstwhile BEx queries or via the new common semantic layer to the DSO/cubes etc. Your investments on building those BEx queries stay protected making this a 'disruptive change in a non disruptive manner' as mentioned by SAP

With BI 4.0, SAP has certainly taken a step ahead to clean up the product suite, create an unambiguous messaging on the product positioning and offered a strong product suite in the market place.

Mobility at Infosys

2011-10-20T11:46:09Z

By Suresh Santhana

The ability to stay connected at all times and the ability to process data faster than ever has made Mobility and HANA the hottest topics in this year's Sapphire. At Infosys we leverage SAP's newest technologies to provide the best in class mobile solutions for our customers. At Sapphire Madrid we will showcase our Mobility capabilities and some of the smart apps like mBrochure, Guided Sales that we have built on devices like iPAD and smart phones.

]]> In a recent paper titled Mobilizing SAP Enterprise Applications at the following link in our Thought Leadership website we have examined this mobility phenomenon and those crucial parameters that need to be considered while choosing a platform or middleware to implement a mobile solution. This perspective attempts to address the benefits of enterprise mobility and how the combined approach to SAP and Sybase Unwired Platform addresses organizational needs in the present and for the future.

Infosys is a Diamond level sponsor at SAPPHIRE NOW, Madrid. Our sophisticated solutions for business analytics, SAP HANA™ and our advanced solutions for mobility empower clients to respond faster to their customer needs, thanks to crucial insights and accelerated business processes. We look forward to see you at SAPPHIRE NOW on November 9-10, 2011.

Opportunity Maintenance- A point of view: Part 2

2011-09-26T08:28:00Z

In continuation to what we were talking on Opportunity Management (OM) in Part 1, following picture graphically shows how the OM is planned:

]]> In the illustrated picture there is a breakdown of a machine which is expected to take 4 days to restore it back. This has resulted in the stoppage of the production area. The primary focus would be on to restore the machine as quickly as possible and restore the machine back to its original condition.
However there are work orders which are falling within those 4 days + 3weeks window of time which needs to be executed and subsequently these will also stop the process. Other work orders which does not necessitate production stoppages and falling in this window can also be clubbed maximize the utilization of OM window.

Challenges for opportunity Maintenance
Following are challenges envisaged for opportunity maintenance,
1. No clear idea on how long the machines under breakdown will be restored - Many times it takes considerable time to identify the root cause of the issue hence no accurate duration of machine down time can be predicated. This will impact others getting the benefit of Opportunity window.
2. The software does not support pulling the maintenance work orders based on Opportunity selection criteria like duration, location and priority wise
3. Unavailability of Resource - since the focus will be on breakdown rather than planned maintenance in such situations.
4. Non availability of spares
5. Non Availability of external service / delay in getting internal approvals for external service
6. Sometimes the machine which was under breakdown might be restored earlier than anticipated creating pressure situation on planned maintenance works.

Conclusion and Recommendations
While this is an opportunity to carry out planned works during such window , but it requires enormous coordination and accurate planning and more important it requires Management support to make use of opportunity windows.

Opportunity Maintenance- A point of view: Part 1

2011-09-17T11:53:12Z

By Gopal Krishna

Opportunity Maintenance (OM) is the term we are using to describe an opportunity window of maintenance for the machines by virtue of breakdown with another machine(s). In this article let us discuss about the event for opportunity window, how maintenance tasks can be identified and execute within this time frame and finally look at the challenges posed for doing opportunity maintenance.

]]> Detailed Analysis
For an opportunity maintenance window to occur there must have been failure / unscheduled stoppage of a machine which has resulted in partial or full stoppage of a process area.

How fast and accurate your planner can pull the list of maintenance work lists for the opportunity window? This is very crucial step in maximizing the utilization of this window? Following are the list of activities envisaged for such an opportunity
• Identify the duration of the breakdown; alternatively plan for the opportunity time
• Pull list of maintenance work(s) meeting the opportunity time window
• Prioritize the work lists
• Determine the no of hours required; find out the available capacity
• Material availability check; plan for material issue from stores
• Decide if required to go for external service in case the demand capacity is more
• This may involve pre scheduling some work orders planned in within near future time (1-2 weeks)
• Execute and complete the work / report the work orders completed.

Scheduling Principle for Opportunity Maintenance
The core objective of the opportunity maintenance is to complete as much maintenance work as possible within the opportunity window, however the principal theory behind OM would be to execute only such works which are falling in the OM window which would otherwise require scheduled stoppage of the specific area. One would need to be experienced enough to decide on how much of future maintenance work can be bring forward in time?

In our next blog, we will discuss, with graphical representation, how OM is planned, challenges faced in OM and our recommendations.

SAP Best Practices Approach - Part 2

2011-09-06T09:22:42Z

by Siddharth Tavargeri and Abhishek Tare

In the previous blog we discussed about what are SAP Best Practices, why do we need SAP Best Practices and various approaches to use SAP Best Practices. In this part, we will discuss the approaches in details with pros and cons of each of them.

]]> Approach A: Deploy a rapid prototype to preview and understand SAP applications and processes

In this approach, all the scenarios for the Best Practice will be installed on an SAP instance and this will act as a prototype environment. The prototype environment will be used to:

· Determine the scope of the requirements

· Select the relevant scenarios

· Refer Best Practices master data

· Train the project team

· Study the processes

Once the prototype scope is identified, it is frozen and only the selected scenarios in scope will be installed on the Development instance using the Building Block approach.

Pros:

1. Rapid Prototype deployment will help the customer evaluate how the Best Practices will work in the live system before making a commitment

2. Prototype will have all the preconfigured scenarios and implementation content thus enabling the business process owners, analysts, SMEs and users to evaluate their relevance

3. Rapid prototype will enable us to expand the scope further to other process areas in the organization during realization phase

Cons:

1. Prototype development and deployment before realization calls for additional effort as Best Practice scenarios need to be installed in a sandbox environment for prototype and then on the development environment for realization

2. An additional step will need to be accommodated in the implementation roadmap and may result in a minor extension to the overall timeline and added cost

3. A certain amount of discipline will need to be enforced on the user community's desire to extend the scope of the prototype to other scenarios

Approach B: Use Best Practice as a reference system to accelerate blueprinting and solution scope definition

In this approach, all the scenarios available for the Best Practice will be installed on a sandbox environment, which will act as a reference system. This reference environment will provide comprehensive details about how the various scenarios mapped by SAP as part of Best Practices. They will act as a reference during blueprinting and realization phase. Configurations / documentation available will be referred while doing blueprinting / realization by the implementation partner. No Best Practices will be installed on Development and subsequent environments.

Pros:

1. Since this will serve as a reference system, the scenarios from the Best Practices can be emulated during actual blueprinting / realization phase

2. Only the applicable scenarios from the best practices can be picked and chosen for implementation, avoiding an overkill

3. Best Practice scenarios / configurations can be duplicated and then tweaked to accommodate customer specific Business Requirements

Cons:

1. SAP Best Practices need to be installed on a sandbox initially so as to make them available for evaluation, leading to additional cost of hardware and installation.

2. Best Practices will not be directly used in solution definition however they will serve as a reference system

Approach C: Use Best Practice as a starting point for implementation project; 30 - 70% of business needs are met, and the rest can be flexibly added during the project

In this approach, blueprint phase will start with Best Practices installation. Implementation partner, in consultation with business process owners will try to align most of the customer business processes to the processes defined in SAP Best Practices. Wherever there is no alignment possible, the preconfigured scenarios will be re-configured to address the customer business requirements.

Pros:

1. Considerable decrease in implementation timeframe and costs, as most of the business requirements will be covered by the Best Practices

2. Most of the delivered content in Best practices, like documentation, configurations etc can be utilized significantly reducing the cost and efforts.

Cons:

1. Customer Business needs to align its processes to the SAP Best practices offering little flexibility to save cost and time

2. In cases where is a misalignment, this approach may involve Business process Reengineering to align processes to Best Practices resulting in additional change management exercise. Works best in cases where the setup is new and business processes are yet to be defined

3. If misalignment is big huge efforts are involved in realignment, not to mention the wasted initial configuration effort, which may not be used,

Approach D: Use Best Practice for accelerated rollout of SAP to subsidiaries in different regions or industries from the parent company

This approach is relevant in the case where the subsidiaries have more or less identical business processes, so that it is possible to have an accelerated roll-out in different regions using the available SAP Best Practices. This approach will not be relevant in the case where there is Global Solution definition which will be implemented across all its subsidiaries.

Pros:

1. Considerable decrease in rollouts timeframe as most of the business requirements will be covered by the Best Practices itself

2. Most of the readymade content in form of documentation, configurations etc can be utilized

Cons:

1. Subsidiaries need to have more or less similar type of business processes

2. This type of situation is highly improbable in case of customers where the subsidiaries belong to different countries and have different set to statutory / business / legal requirements