Tuesday, April 17, 2007

The Myth of the "Out-of-the-Box" Assessment

When most of my clients talk about assessments, they relate past horror stories about consultants who couldn’t live up to more than the first three letters of either word. When I asked what went wrong, the most typical responses were either the consultant didn’t tell the client anything he didn’t already know or wasn’t able to truly target the client’s real business problems.

I see the root of the issue in the type of consultant often used to perform assessments. Many Business Analysts are consultants who are really good at capturing user-provided requirements and putting them into volumes of documentation for an eventual system implementation. The consultants who can go into a business and truly act as trusted advisors to the client tend to be few and far between.

One thing to look out for is any consultant who touts standardized assessment methodologies, use cases, etc. After having been involved in at least 20 different assessments myself, I’ve learned there are many different incarnations of assessments and there is no single approach that fits the needs of all business organizations. Assessments might be as diverse as one-week readiness report cards, detailed financial ROI analysis, vendor evaluations, technical road maps, etc.

At the end of the assessment, success can be gauged by the following:

  • Has the problem been quantified in terms of impacts to the business and value of a solution?
  • Has consensus been reached on what success looks like?
  • Have the gaps between the end goal and current situation been identified?
  • Is there a blueprint and road map that can be executed upon realistically in terms of cost and organizational dependencies?

All else said, assessments are invaluable in ensuring subsequent investments are made wisely. Too many clients make the mistake of skipping assessments because of past bad experiences.

Tuesday, March 20, 2007

BPM and Revenue Assurance: The Curse of Cross-Organizational Solutions?

Over the past several months, I’ve been helping my company establish a BPM Practice. One of my last practice startups was in Revenue Assurance, so I made sure to take into account both the factors that made it so successful as well as the complexities I encountered. After compiling my lists, I realized the complexities for BPM were very similar to those of Revenue Assurance. I attributed the majority of these to a single root cause, namely that both solutions required cross-organizational decision-making and collaboration within the client to sell and deliver successfully.

Ask yourself these questions:
  • Who owns it and who is empowered to make the purchase decisions? When was the last time you met a VP of Revenue Assurance or VP of BPM?
  • Is the value proposition of the solution enough to deliver into a single organization or is the ROI dependent on realizing value across multiple organizations with multiple people involved across these organizations?
  • How then is collaboration across the organizations to be facilitated? BPM pundits have come up with this great concept of “BPM Governance”, although it seems to me that no two groups define it the same way.
The intention of this posting is not to discourage the pursuit of either Revenue Assurance or BPM solutions. On the contrary, by recognizing these obstacles from the start, you’ll hopefully come up with the right strategies for navigating around them. Our Revenue Assurance Practice ended up being a very successful endeavor and we’re on the right track to do the same with BPM.

Wednesday, February 21, 2007

What User-Centric Data Reconciliation Does and Does not Do to Provide Business Value

In an effort to further refine the value proposition of User-Centric Data Reconciliation, below is a list of what it does and does not do:

What User-Centric Data Reconciliation Does:
  • Reduces intensive manual efforts to find data
  • Provides visibility to disparate data in a correlated, centralized way so that the “big picture” doesn’t have to be assembled piecemeal and manually
  • Offers a substitute to creating structured queries or views
  • Provides a single user interface for access to the underlying data sources
  • Produces side-by-side data for "stare and compare" reconciliation to manage discrepancies without the complexity of building or buying a reconciliation engine
What User-Centric Data Reconciliation Does Not Do:
  • Capture complex business rules for clarifying the relationships between discrepant data
  • Perform complex calculations on data subsets, such as summing up aggregated fields, etc.
  • Automate the reconciliation of data across multiple sources
  • Implement a workflow for prioritizing and resolving data discrepancies

Monday, February 12, 2007

The Value Proposition For User-Centric vs. Audit-Based Data Reconciliation

After my last post, I was asked to put the concept of user-centric data reconciliation into a real context that would better indicate its benefits. This post should enforce the following value proposition.

User-centric data reconciliation solutions…
  • Can be implemented in a fraction of the time and cost of audit-based solutions
  • Do not require the formation of a separate team of people to build or work through data discrepancy issues
  • Can be more easily tailored to user needs
  • Should be greater in the value delivered than that of audit-based solutions
Below are two different scenarios using as an example, the identification of revenue assurance issues related to customers being under-billed for their telecommunication services.

Scenario 1: Audit-based Data Reconciliation
  • Analyze how customer, service and billing data are structured in switches and billing systems
  • Capture business rules for what constitutes under-billing situations
  • Define transformation rules for consolidating the different data into a single database
  • Write code to automate the comparison of switch and bill data to identify the discrepancies and present them to the client
  • The client allocates a team of people to research each “switch-to-bill” discrepancy
Depending on how many discrepancies are identified (often in the thousands), the entire process could take six months or more

Scenario 2: User-centric Data Reconciliation
  • Analyze only the metadata behind the same data sources
  • Instead of explicitly defining business and data transformation rules, an information access product such as Endeca can be used to discover the relationships automatically through embedded natural language processing, semantic analysis and statistical inference
  • The data is automatically indexed and presented to users in real-time
  • Guided navigation through entities, terms and clusters can be used to identify the same “switch-to-bill” discrepancies
  • The results are iteratively tuned by user-provided feedback
This second scenario takes the effort away from auditors and code developers and puts it in the hands of those best qualified to fix the billing discrepancies as part of their normal job responsibilities.

Monday, January 22, 2007

A User-Centric Approach to Revenue Assurance

A couple years ago, Revenue Assurance was the hottest thing. Carriers understandably jumped on any opportunity to seemingly recover millions of dollars in unbilled revenue. The problem was the vendors selling Revenue Assurance solutions either did not realize or neglected to inform the carriers that, while their tools certainly facilitate the identification of Revenue Assurance issues, it’s really up to the carrier to resolve the issues. RA tools are great at identifying billing discrepancies, prioritizing them and recommending resolution workflow. What they don’t do is the necessary final research into their validity and system updates that fix the issues. Unless the carriers invest the time and resources to do this, their RA successes will be dubious. I posit that this is perhaps why RA hasn’t been the sure thing revenue builder it was once thought to be.

If the problem is that carriers don’t have the time and resources, what can be done to address this? What about an RA solution that is ad-hoc and user-driven rather than a back office audit of thousands of discrepancies? Instead of treating RA as effectively an ETL “bashing” of millions of rows of data from multiple systems at once, why not take the Business Intelligence approach of providing users with visibility into a consolidated picture of the underlying data sources, errors and all? That way, the identification and correction of discrepancies can be integrated into the core processes of the users who know the data best and rely on it to be accurate in the first place. You could even take this a step further and incorporate SOA so that the interfaces used to view this consolidated data can be leveraged by not only users but systems across the entire enterprise that need access to shared data and perhaps have the resources to fix the problem, one discrepancy at a time.

Tuesday, January 16, 2007

Network Neutrality: Dick's Last Resort?

On January 11th, I attended the Denver Telecom Professionals Putting Network Neutrality In Perspective conference. The highlight was the keynote presentation from Dick Notebaert, CEO of Qwest Communications. Regardless of what side of the argument one is on, Dick’s passion and clear articulation of the issues might have been enough to sway people to his side.

Dick’s three main arguments against net neutrality were:

• There is no problem from which to derive a solution around Network Neutrality
• Telcos must be given a chance to make a return on their capital investment
• Telcos are not in the business of making service worse, they are in the business of improving it

The most interesting part of his presentation was what the concept of neutrality might mean in terms of automobiles, iPods and football. While these were a bit of stretch, his exaggeration served its purpose of making the point that differentiation is crucial in order to be successful.

Tuesday, January 9, 2007

BPM: Did Someone Forget About the Data?

All the buzz these days is about Business Process Management (BPM). Here we have yet another 3-letter acronym for a concept that goes back many years for modeling, automating and monitoring processes to improve operational efficiencies. The twist now is packages which allow you to manage processes independent of the underlying technology “plumbing”. The vendors of these tools would like you to think all the failures of the past can be summed up in these technology complexities (remember EAI?). While certainly decoupling processes from technology makes it easier for business users to participate, it doesn’t tell the whole story. Without accurate data, operational processes will always be “garbage in, garbage out”. Ask the same business users what their biggest process headaches are and I’ll think you’ll be surprised.

I recently led a data architecture assessment for a telecommunications service provider that has made several acquisitions over the last few years. Understandably, this provider is worried about having a consistent set of processes to follow for ordering and delivering service. They have implemented business process management solutions in the past that have met with varying results.

The results of the data assessment gave a clear indication that two of the largest issues this service provider faced were having too many sources of record for the same type of data (e.g. Customer, Location) as well as not having the proper controls in place to reconcile or consolidate the data. The consequence to process management was not figuring out how to better model, automate or monitor. Rather, the consequence was was where to go to look for the data and make sure it was accurate in the first place!

BPM has a tremendous value in modeling, automating and monitoring operational business process. When taken together with effective data and information management, you will have a better chance of actually reaping the benefits of it.