Skip to Content

I recently invested some time to review some research provided by ServiceXRG. They published an extensive document on ‘Applying Remote Support Technology for Maximum Impact’. After reviewing this information I took a look into how it can apply to the supportability offering for the the SAP BusinessObjects products.

Achieving Success

In order to achieve success with remote supportability you need to be able to solve the right problems in the right situations. It is imperative that you have realistic expectations about how to be successful with remote supportability tools and applications. This is not always defined in lower operating costs, it could be increased satisfaction or even faster resolution times. Sometimes in order to determine the niche for remote supportability tools, consider the following questions:

 

  • What issues are trying to be resolved?
  • What kind of results are expected?
  • How will the remote supportability tools be successful?

 

How to utilize Remote Supportability

 

Within Primary Support there are many excellent opportunities to leverage remote supportability tools. Until recently it has been unavailable for anyone who supports or maintains an SAP BusinessObjects product stack. Still, there are just as many situations where this technology may not be the right tool. Think of remote supportability as an application framework upon which many distinct support applications can be built. A onesizefitsall approach to remote supportability will not result in the best return on investment. This can be demonstrated by the offering of Solution Manager for large SAP ecosystems and the remote support component for a smaller subset or a single enterprise application. To be successful we must demand that it be applied at the right time, by the right individual, to solve the right problem. When considering how and when to apply the remote supportability tools, consider how you can benefit by using them. In some instances, the successful use of the remote supportability tools could result in a longer issue duration, but then results in a more satisfied administrator. In some others, remote supportability helps reduce down time by minimizing the time and effort required to diagnose and resolve an issue.

 

When to utilize Remote Supportability

 

I don’t believe there is a right or wrong time to use the remote supportability tools being offered for SAP BusinessObjects as long as it delivers a recognized benefit to the business. Customers can leverage the remote supportability applications for very difficult issues, the average, or even for the simple issues. One of the largest factors to consider in order to determine how and when to apply these tools lies in what the expected benefits are by leveraging them. The image here provides some guidance on targeting different applications available for SAP BusinessObjects based on the complexity of issues involved and expected benefits.

 

 

Remote Debugging

 

 Impact of Remote Debugging Impact*
Cost of initial analysis time Increase
Cost of diagnosing issue Decrease
Overall time cost for analysis Decrease
Likelihood to occur again Decrease
Effectiveness of solution Increase
Satisfaction with process Increase

More than 80% of the issues encountered can be resolved without a remote debugging effort. Costs can be high when attempting to identify, diagnosis and resolve the cause of an issue. The efficiency with which we handle these issues depends upon the ability to quickly and accurately determine what is wrong and what can be done about it. Most issues will follow the diagnostic process conducted via telephone. In such situations, the engineer provides guidance to help diagnose the issue. As the complexity of issues rise, it’s critical that the engineer lead and possibly travel onsite. Remote debugging technology offers the most costeffective means to leverage and engineer or developers skills by allowing them to diagnose issues as if they were actually onsite. They have the benefit of “being there” without leaving their desk

 

 

*Compared to a comparable case that did not use remote debugging

 

Remote Support Component

 

 Remote Support Component  Impact*
Cost of initial analysis time Increase
Cost for diagnosing issue Decrease
Overall time cost for analysis Decrease
Likelihood to occur again Decrease
Self-service success rate Increase
Satisfaction with process Increase

Many SAP BusinessObjects administrators are increasingly willing to help themselves when they have an issue, but they don’t necessarily have the tools and resources to take full advantage. Companies invest a lot of money in the creation or acquisition of the system monitoring and analysis tools for their administrators, but these applications cannot be as effective as the remote support component due to its tight integration with SAP BusinessObjects. In many cases the lack of success with these other tools has less to do with the administrator and more to do with the integration of the system monitoring and analysis application with the software being monitored. Before companies can expect administrators to assume a greater role in selfsupport, they really need to provide the remote support component as a basis for administrators.

 

 

*Compared to a comparable case that did not use remote support component

 

SAProuter

 

 Impact of SAProuter Impact*
Cost of initial analysis time Increase
Cost of diagnosing issue Decrease
Overall time cost for analysis Decrease
Likelihood to occur again Decrease
Effectiveness of solution Increase
Likelihood to occur again Decrease

When issues cannot be resolved using the knowledge and skills available to the engineer, more in depth investigation may be warranted. When an issue requires advanced diagnostics, SAProuter can significantly enhance the engineers ability to establish the underlying circumstances and help facilitate faster time to resolution. Establishing a secure connection between the engineer and the administrator enables the engineer to run diagnostic utilities, review log files, verify systems settings and evaluate the environment in which the issue occurs. The engineer may even be able to duplicate the reported situation while directly connected to the administrators environment. Not all issues are resolved at first contact, while the diagnostic session may reveal the cause of the issue and present an opportunity to resolve the issue, many situations may require additional investigation. In these situations, SAProuter or remote debugging will provide sufficient support for further investigation.

 

*Compared to a comparable case that did not use SAProuter

 

Line Opener Program

 Impact of the Line Opener Program Impact*
Cost of initial analysis time Increase
Cost of diagnosing the issue Decrease
Overall time cost for analysis Decrease
Likelihood to occur again Decrease
Effectiveness of solution Increase
Satisfaction with process Increase

Historically when an issue is encountered that cannot be solved by the administrator they would call technical support and an engineer would walk them through the steps to identify and resolve the issue. This method has many restrictions, some of them have been discussed already but another is that the administrator must be present and working with the engineer to resolve the issue. In today’s global economy that may be difficult to align time zones in order to find the highest level of expertise for the individual product area. With the Line Opener Program (LOP) which enables SAP to open service connections to the SAP BusinessObjects systems independently this can become a thing of the past. If an engineer requires access to one of the systems, an opening request will be created. Opening requests can only be sent to systems which administrators give the permission for independent opening. Administrators can specify when a connection is available, to what system it can be connected, and what type of connection is allowed.

 

*Compared to a comparable case that did not use line opener program

 

Realizing the Full Potential of Remote Supportability

 

Remote supportability fundamentally changes traditional support delivery because it allows both the engineer and the administrator to see and experience the same actions. With the traditional support delivery model, an engineer attempts to decipher what may be causing an issue based on the description of the administrator requesting help. While it’s remarkable that engineers can be as effective as they are without seeing what the administrator is experiencing, there’s potential for significant improvement. Remote supportability can immediately address potential miscommunication that may occur between engineers and administrators during a support interaction. Successful remote support applications extend beyond high complexity issues and can help novice administrators with a wide variety of simple issues. As issues become more complex, the ability for an engineer to see what is happening becomes more important. Trying different approaches to diagnose and resolve administrators issues is possible with these tools. The potential for savings become more significant the more we use remote supportability. Remote supportability can be the “killer application” when applied to solve the right problems.

To report this post you need to login first.

Be the first to leave a comment

You must be Logged on to comment or reply to a post.

Leave a Reply