The Buzz - April 2008

What is Application Problem Resolution?

Application problems are unexpected behaviors in software applications. Problems can occur in development, in testing, or after the application has been deployed to a production environment or customer site. Problems can be caused by software defects, but they don't necessarily have to be. Problems can be due to improper configuration, an infrastructure malfunction, or even user error.

The steps that IT organizations and software vendors take to determine the root cause of an error constitute the problem resolution process. Steps in a typical problem resolution process include:

·  The problem is discovered by end users, IT operations, testers, or developers, depending largely on the environment in which it occurs.

·  Information about the problem is documented and passed along to the parties responsible for high-level diagnostics and assignment of responsibility. 

·  Alternately, the party that discovered the problem is able to resolve it. For example, IT operations may discover and repair the hardware malfunction responsible for a production problem.

·  If the problem appears to be because of a software defect, it may be passed to development. In this case, developers will review the information they've been provided and attempt to recreate the problem, diagnose the root cause, and address the underlying issue.

·  If developers are unable to recreate the problem, they will have to gather more information.

·  The changes that developers make are passed along to the environment in which the problem was discovered, whether test, production, or a customer site, for deployment. 

The problem resolution process involves a large number of stakeholders scattered across the enterprise, all of whom are interested in different domains, familiar with different vocabularies, and accustomed to different tools. This inherently makes the problem resolution process prone to inefficiency, as each handoff between roles represents an opportunity for miscommunication or insufficient communication. When this happens, the result is a bottleneck in the process. 

For most shops, problem resolution is highly inefficient. Developers dedicate nearly a third of their time to problem resolution, with much of that time spent investigating and attempting to recreate problems rather than actually implementing a fix. And testers spend hours documenting each problem they encounter, in addition to time spent communicating with developers about problems and testing their fixes. 

The result is that problems take too long to resolve (see Figure 1). On average, application problems take more than six days to resolve, and 11% of problems take more than 10 days. The criticality of problem resolution depends almost entirely on the nature of the problem and the nature of the application in which it occurs. There are few problems and few applications for which six days is an acceptable amount of time to leave a problem unaddressed. 

Here are some recommendations to improve the problem resolution process:

·  Determine the true efficiency - and cost - of your problem resolution process.  Gather your own data from your bug tracking, test management, and service desk applications. Alternatively, field a survey to developers and testers within your shop.

·  Decide what to tackle first and what returns to expect. It may be that in your organization there are particular parts of the problem resolution process that are especially inefficient.

·  Consider improving the problem resolution process bit by bit. Use an incremental approach. First focus on improving a single part of the problem resolution process, for example, the part that one role plays in it.

·  Use improvements in problem resolution to drive better apps-ops relationships.

Problem resolution is one of several disciplines that spans applications and operations; when problem resolution is dysfunctional, the apps-ops relationship usually is, too. Use improvements in your problem resolution process as the launching pad for a larger initiative to improve communication and collaboration across these two silos of the IT organization, or even across development, testing, and operations.

**********************

The Five Inviolable Rules for Successful CRM
 
Want to have successful CRM? Here are the five basic rules to ensure that yours is a winning implementation:

Rule #1. Successful CRM always helps the sales rep to sell. A CRM system must be more than just a way to make fancy reports for top management. The system should make it easier for sales reps - not top management - to find the information they need to get their job done.

Rule #2. Successful CRM always motivates the team to sell more. Consider how your CRM solution will fit into your organization as a whole. Before you try to get everyone to use it, consider what value it will add to the sales reps' day-to-day activities.  If it makes their job easier, they'll be motivated to use the system, and use it to sell more.

Rule #3. Successful CRM always reflects your actual selling needs. Don't buy or upgrade a CRM capability because you heard it was a good idea. The best way to implement or upgrade a CRM system is to think through the issues, gradually introduce usage requirements, and then, when the system comes up, hold regular training sessions.

Rule #4. Successful CRM never requires coercion to achieve compliance. Sales reps will only want to use a CRM system if it saves them time and helps them make more money. If the sales teams can't easily see what's in it for them, then the CRM initiative will fail.

Rule #5. Successful CRM always simplifies; it never complicates. With CRM, the goal is to manage the complex business of selling by making it simpler. Think of CRM like an automobile. When you turn the key in your new car, you do not care that there are umpteen silicon chips controlling every aspect of your car's handling and performance. You just care that it starts and gets you where you are going. A well-implemented CRM system makes sales processes simple and hides complexity. Building in simplicity, though expensive, will in the long run cost less than simply applying a quick fix and hoping for the best. When done right, your investment in simplicity will be recovered many times over.

****************************

The Real Reasons Why ERP Systems Fail by Bernie Goldband 

The implementation and maintenance of large-scale enterprise resource planning (ERP) software can require a million-dollar, if not multimillion-dollar, investment. Yet many companies invest in an ERP system without adhering to the same disciplines applied to other areas of their business.

Essential steps such as risk assessment, benefit analysis, performance objectives and cash flows are typically discarded. In their place, expenditures are made based on naïve assumptions that the computer will magically transform a company into a paragon of efficiency. This misguided approach sets up a sequence of events that often leads to a failure of objectives. The resulting conclusion is that the ERP software was a bad investment decision.

Frequently, company management will conclude that the software doesn't work or it is too complex to implement in their unique environment. Management further compounds the failure by claiming that the wrong ERP system was chosen, and if they had the "right" software package they could recapture their initiative and achieve their original objectives.

Yet, my experience is that the software itself is rarely the source of failure. In fact, selecting the presumed "right" software package will most likely result in a second failure - this one even more costly than the first. Blaming or changing your ERP system is simply a way to divert attention from the execution mistakes made as a result of human - rather than technology - error.

To rescue a failing ERP project, start by taking corrective action. Before throwing out your current system (or worse, letting it spin into oblivion), evaluate what steps were followed (or not followed) to bring you to your present situation. Make sure you understand why the system is failing. And be prepared to do whatever it takes to reverse the current course of action.

There are times when the software is really not appropriate for a particular environment. Even then, the reason for failure is not the software. Rather, it is the lack of due diligence by the company before buying it. While software mismatch does occur, as this article points out, those instances are not as common as business managers believe.

Companies regularly use ERP systems to improve competitive advantages; raise customer service levels; increase productivity and plant utilization; and reduce inventories. With the right implementation strategy, yours can too!