The Three Most Valuable Lessons Learned, Part 2

In the first article of this three-part installment, we looked at the most valuable lesson learned to date from customer relationship management (CRM) implementations. That is, implementing new technology without changing underlying processes, incentives, skills sets, and reporting structure constitutes a form of corporate insanity: doing things the same way and expecting different results.

This week, we’ll examine the second Most Valuable Lesson Learned: Most Valuable Lesson Learned No. 2

New technology should be acquired only when it is proven to improve business processes (fulfill business requirements) and can be readily integrated into existing architecture without undue customization or configuration.

Now I realize that if this were true, few CRM packages would ever have been purchased in the first place. But maybe that wouldn’t have been such a bad thing.

We’ve all heard the horror stories — CRM packages that were hard to integrate, difficult to maintain, and, in some cases, fundamentally flawed. Sometimes (certainly in the last example), this was due to inherent design and code quality problems.

In many other cases, however, great functionality and potentially valuable improvements in productivity were never achieved due to the haphazard state of integration of the prevailing technical architecture (typified by the use of “spaghetti” code — hard-coded point-to-point integration solutions), an undue amount of customization, a lack of adoption of the package by the user community, or simply poor business planning.

If there’s one prevailing theme running throughout my columns and consulting recommendations over the past few years, it is that a comprehensive set of standards and procedures for software, network, and data architectures can dramatically facilitate deployment, ease integration, and lower development, operational, and maintenance costs — as well as better support current performance and future growth of the business.

I’m the first to acknowledge that this is a lot easier said than done. Changing needs of businesses, a lack of product standards, a rapid pace of product innovation, and an unrelenting pace of mergers and acquisitions have posed considerable challenges to any mid-size to large organization trying to enforce a cohesive set of architectural standards.

Granted, some mistakes were made in setting standards. Some organizations tried to standardize hardware (monopolies are rarely a good idea) or the adoption of a single development platform. Business users found this too restrictive, limiting the development and deployment of required or desired functionality. With recent developments in automated network operational and maintenance tools, availability of broader, tightly integrated functions in packaged applications, and the merging of interoperability standards such as XML and Simple Object Access Protocol (SOAP), such challenges can be more readily met.

Even the long-standing problem of business and IT alignment is beginning to disappear. Years ago, it was a major issue. Some corporations decentralized IT operations, only to find chaos because they never established the right level of enterprise-wide technology standards.

Today, we realize that the issue of alignment is a fallacy. IT and business operations were never meant to be separate organizations. It was a skill mix problem due to a dearth of technically savvy business people. With the integration of these skills, that’s finally changing.

In our next installment, we’ll look at the third and final Most Valuable Lesson Learned from CRM.

Got an opinion on this stuff? Willing to share it? If so, please write me at [email protected]. And stayed tuned for part three.