The Business Process Re-engineering (BPR) Syndrome
It was not a long ago when Business Process Re-engineering (BPR) was a buzzword in the industry and still resonates with many of its practitioners. Process improvement through re-engineering received unprecedented attention as the source of competitive advantage. Organizations went into an overdrive to redesign business processes to seek radical improvements in efficiency and effectiveness. 
Solutions such as ERP, CRM and SCM became common enablers for companies across business segments. Certification of process performance, meeting various standards such as ISO became necessary ingredients of companies’ profiles. Similarly, demonstration of process capability and maturity by means of assessments at various levels of CMM, PCMM and CMMi started defining company’s capability to deliver. And then there was Six Sigma, ISMS and solutions emanating from the theory of constraint management.  Soon these enterprise solutions, quality certifications, demonstration capability and maturity of processes through tools such as CMM and Sigma became a norm and most organizations either had these recognitions or similar in-house systems to convince customers that they could deliver. These companies however could not retain the competitive edge because every other company also flashed these recognitions and similar process re-engineering achievements. Though there were perceivable advantages, these, in a lot of ways, became part of legacy for organizations and often at the cost of agility and flexibility.

The Problem of Legacy (Technologies)

Interestingly, alongside process re-engineering, over the last couple of decades, organizations have also invested heavily in Information & Communication Technology (ICT) infrastructure. The decades of incremental improvements, which were actually aimed at achieving efficiencies have also proved an impediment in the progress as they have led to:
  • Disparate applications from multiple vendors
  • Multiple platforms
  • Layers of data and application redundancy (unwanted)
  • Mixture of packaged and legacy apps
  • Messaging-based integrated apps
  • Poor performance & usability of integrated apps and thus poor usage by users
Today, this infrastructure has high level of inefficiencies due to the challenges of integration and interoperability.  Managing such an infrastructure itself is a huge cost for organizations. Companies can’t take the risk of replacing these systems due to high switching costs, even if most CIOs/CTOs may wish to have one single platform (with open source apps) with optimal redundancy and maximum efficiency which will ultimately lead to a substantially low cost of maintenance.
The problem has become extremely complex due to the fact that most organizations are now using inorganic means to grow further.  Inorganic growth will surely help in short term to meet financial expectations of the stakeholders but will become a bigger cost in long run due to problems related to integration of business culture and technology.
The problem of legacy is not just for non-IT companies, it is equally immense for leading software and web companies like Google, Yahoo! and AOL. Convergence of web is happening but larger players in internet space today have a mixed portfolio of websites (organic inorganic) which pose a challenge as to integrate and provide a seamless interface to the user.  Any such effort will always have a compromised usability and users would not mind switching to better options.

The Answer is Business Technology Re-engineering (BTR)

It is now an established fact that competitive advantage in the knowledge economy comes from innovation, agility and adaptability.  Processes over the years were automated using multiple products from different proprietary technology vendors such as MS, IBM and the likes. Today integrating them for a seamless process with high reliability and control has become an extremely difficult proposition and some expert concur that it may not be possible at all. Legacy has become a burden which may make some players cease to exist in the coming decade as their technology will end up restricting their competitiveness.
So what happens to the idea of becoming agile and adapt to fast changing markets? 
Technology has seen some major improvements in the last decade, especially due to cloud computing, Web 2.0, Telecom and Open source revolution.  Today, it is possible to build a single platform from scratch that can meet all the needs of an enterprise and at almost quarter of the cost that went into the development of silo apps. The challenge, however, is the high switching cost and resistance to change (strong reluctance to change a system that has apparently been working fine).
The challenges notwithstanding, to create a real competitive edge in the new economy, we need Business Technology Re-engineering (BTR) to create most efficient, scalable and flexible architecture for an enterprise that provides the required agility to an enterprise.  BTR, in simple terms, is to re-think your enterprise ICT infrastructure (Software and Hardware) and architecture from scratch. 
Key Objectives
  • Get agility and power to evolve ICT systems
  • Reduce total cost of ownership of ICT
  • Increase business impact of ICT and thus returns
Approach to BTR
  1. Assess your ICT infrastructure on the basis of criticality, cost, value and engagement
  2. Compare Total Cost of Ownership (TCO) over 3-5 years
  3. Define a transition roadmap, grab low hanging fruits first

A few useful guidelines when considering BTR

While assessing existing IT assets and thinking of alternate approaches, do consider the following:
  • Forget what worked best in the past. Find out what is the best way to do something today, and then look at reusing existing apps and components. Don’t re-invent the wheel, but do redesign it.
  • Try to move from silo based automation and integration to seamless enabling of processes.
  • Reduce no of application participants and provide SPOA(Single Point of Access), avoid too much integration by moving to enterprise platforms.
  • Don’t integrate apps at the cost of usability and flexibility to modify it later.
  • Focus on data reuse, try to migrate so that redundancy can be optimized, and use web services and semantic models.
  • If needed, replace the entire presentation layer (usability is the key) and separate it from the logic across all apps.
  • Think open source and consider change as a continuous process.
  • Switching cost may be high, but it will be only be a one-time expenditure and will always be lower than the cost of loosing competitiveness and struggling with issues of legacy systems that don’t talk to each other and create inefficiencies.

Assess your current IT infrastructure

You need to closely assess your entire enterprise IT stack including various hardware and software assets, assess the following for all assets:
  • Average Annual Cost (TCO: Direct + Indirect)
  • Value Addition (Benefits/Returns)
  • Criticality for Operations
  • User Engagement (Usage, Performance)
  • Other Info: Year of Purchase, Licensing Type, License: Maintenance + other costs ratio etc.



Compare TCO

When comparing TCO, do a detailed analysis; take all cost heads into consideration and a time period of 3-5 years. Do an objective comparison, prefer a higher percentage of required functionality out of box, do give weightage to additional capabilities that you may use in future etc.
Cost heads to consider must include:
  • Direct License
  • Additional License of dependant infrastructure
  • Hardwareclip_image014
  • Hosting & Networking
  • Maintenance & Support
  • Customization
  • Training
  • Professional Services (like consulting)
  • Deployment & Rollout time (take opportunity cost of late rollout)

Define a transition roadmap

Based on the assessment, strategic priorities and known constraints you must define a phased plan to completely reengineer your enterprise IT infrastructure.
The transition roadmap must help in meeting the twin objectives of reducing cost and increasing impact on business. Table 1 provides a sample analysis to prioritize for BTR.

Conclusion

BTR doesn’t mean that you should replace all systems. The aim is to make your stack leaner, interoperable and reduce TCO. When you assess your enterprise IT stack and architecture, you must evaluate each asset and take a call if it makes sense to Replace, Retire or Retain it and if to be retained then what are the integration needs and the best approach to integrate.
Today, everything conventional is challenged, so try and not apply conventional wisdom, rather think from scratch and innovate.