How Can IT Help Competitiveness These Bleak Days? - Part 2

Part 1 of this blog series introduced the SAP-sponsored expert panel discussion that explored reasons to maintain IT investments even during difficult economic times. The Harvard Business Review (HBR) article by Andrew McAfee and Erik Brynjolfsson entitled “Investing in the IT That Makes a Competitive Difference" was the main supplement and starting point of the discussion.

As I mentioned in Part 1, in a nutshell, the panel logically (and not surprisingly) argued that enterprises should use IT tools to innovate and create differentiation, especially during a difficult economy.  Moreover, a long-term SAP analyst relationship contact privately solicited my opinion on the extent to which these esteemed academics understand our industry.

According to the “you asked for it” motto, here is the continuation of my thoughts that was parlayed into a blog post to be shared with our readers too.

Going further, I found it interesting that the study never referenced the Y2K (or Year 2000 bug) over-hyped phenomenon as a possible explanation as to the increase in IT spending from 1994 to 2005 (referenced in Part 1). I particularly noticed this quote:
"According to one estimate, spending on these platforms (ERP systems) already accounted for 75% of all US corporate IT investment in 2001."

Hmm, if the emphasis of IT has long been on the rise in corporate America, why has there been so much consolidation in the software industry from way back when? Shouldn’t there still be a proliferation of software companies instead of a reduction then?

A friend and an occasional featured contributor to TEC’s newsletter even teased me by pointing this out:
“TEC should be able to easily verify the professors' contentions. Has the evaluation of enterprise resource planning (ERP) software increased from 2002 (i.e., from the launch of TEC's very first online evaluation center) to present day? If the professors are right, TEC should be rolling in dough.”

Well, as it is a privately held company, I am not at liberty to divulge much of TEC’s business and financial situation. It suffices for me to say that we are not necessarily “rolling in dough” per se, but we’ve been doing fine since 2002. Folks from all walks of life and corners of the world do seem to continue to evaluate all sorts of software applications and solutions in our evaluation centers.

Thou Shalt Not Forget About Talent

In any case, credit should also be given to the authors for the assertion that we should focus more on the human resource (HR) management side (i.e., to cultivate "knowledge workers") versus the process and software side of the house. Some nitpickers might say that even that’s no longer news since almost about everyone started jumping on the talent (and human capital) management-related business advantage bandwagon a few years ago.

We have been hearing for some time how chief information officers (CIOs) and IT managers cannot easily find the skilled workers they need to make modern systems work efficiently and effectively. While this applies especially to legacy skills, the emerging cloud computing, service oriented architecture (SOA), composed applications, mashups, and whatnot era demand a significantly new skills mix.

But not all existing IT staff will transition easily to this new world, and the critical issue for most companies will be managing skills transitions (retraining or outsourcing IT staff). This might be particularly true during the period of downsizing and as the focus shifts from managing assets to business processes.

New School of Thought

What was possibly the most valuable finding in the report (and the panel discussion), beside the three-step “Build-Innovate-Propagate” strategy (mentioned in Part 1), was that:
 “…successful IT-enabled business process improvements like the showcased ones generally have a number of important characteristics:

  • They cover a wide span. -- The new ways of working apply across a very large swath of a company -- in this case, all stores, factories, and delivery teams;

  • They produce results immediately. – As soon as the new enterprise system goes live, so do the process changes it enables;

  • They are precise. -- Rather than general guidelines, suggesting highly scripted instructions for business activities (furniture order taking and delivery);

  • They are consistent. -- Executed the same way everywhere, every time. Every furniture store uses the same method to quote lead times, and deliveries are closed out the same way day after day;

  • They make monitoring easy. – Activities and events can be observed and tracked in real time, providing unprecedented opportunities for testing and feedback; and

  • They build in enforceability. -- The designers of a new process that’s embedded in IT can have great confidence that it will be executed as intended. It is often simply impossible to execute the process the old way, and even when backsliding is possible it can be recognized and addressed. The furniture company could easily use the data collected during the delivery process to determine if all teams were calling in properly.”

It is indeed difficult and completely pointless to debate the above findings and recommendations. What might be interesting, though, to note is that many of the above prescriptions mesh well with on-demand software as a service (SaaS) delivery.

This brings me to another of my recent reads (a provocative book rather in this case), which claims that the conventional business consulting process and (costly and never-ending) mega software initiatives model is on its way out. It is about to be superceded by a radical new consulting approach that revolves around delivering fast results (for projects broken in smaller and more easily digested chunks) and fostering client self-sufficiency, where SaaS and cloud computing often come in handy.

In their book entitled “Iterate or Die: Agile Consulting for 21st Century Business Success," authors Eric Berridge and Michael Kirven, co-founders of Bluewolf, reveal the fallacies of conventional business consulting and introduce Agile Consulting, a bold consulting policy pledge built around the so-called “Bluewolf Laws of Consulting Economics.”

Bluewolf is possibly the world's largest provider of consulting services for Cloud Computing, Free and Open Source Software (FOSS), and SaaS solutions. With eight years of SaaS experience and more than 1,200 customers, the firm is defining a new style of consulting based on the novel Agile Consulting model that guarantees success and delivers on the promises of Cloud Computing. Bluewolf clients include Dow Jones, ADP, General Electric (GE), and Fox Interactive Media.

The Agile Consulting model has the following three major tenets:

  1. Focus on success criteria instead of functionality;

  2. Focus on client self-sufficiency; and

  3. Focus on change management.

In the book, the authors also share the abovementioned "Bluewolf Laws of Consulting Economics:"

  • A successful business process trumps cool technology;

  • Every project must start with a specific success plan;

  • There is no return on investment (ROI) from business software without widespread user adoption; and

  • Expect (continual) change.

Now, many of these premises are in tune with those of the two Harvard professors, and given SAP’s sponsorship of the panel debate, it would be refreshing to see SAP (and its powerful Big 3 or Big 4 consulting partners like Accenture or Deloitte) preach agile consulting, incremental (iterative) project delivery, and customer self-sufficiency (i.e., the risk of the client not needing you) from now on.

However, I am still skeptical about such a quick change of these giants’ tried-and-true business model (and of their hearts and largely indelible mindsets). Ironically, even the moderator of the SAP-sponsored panel discussion, Bruce Richardson, the Chief Research Officer of AMR Research, has a recent blog post about SaaS advantages for both users and vendors.

The recent appointment of John Wookey to head up SAP’s on-demand business is certainly interesting and promising. Wookey has a formidable reputation but is coming to a company that hasn’t thus far had much idea about what to do and how to go about the on-demand world. We have all heard about SAP’s less than stellar launch of the SAP Business ByDesign offering, and not much significant has happened since according to Brian Sommer’s more recent blog post.

On the other hand, Wookey’s focus within SAP will be on large enterprises’ on-demand offering, which is not exactly the province of SAP Business ByDesign (but rather within Business Objects' OnDemand offerings). It is way too early to predict his likely influence within SAP, but if his work doesn’t contribute to major new sales in the near term, we might not hear much about him again. In the meantime, Josh Greenbaum puts a few stakes in the ground on Wokkey's behalf, with which I tend to concur in principle.

What’s all the FOSS About?

Additionally, although not explicitly stated in the HBR report, there has been the phenomenon of companies, particularly the bigger ones with real IT budgets, taking a harder look at FOSS enterprise applications these days. The occurrence is quite real, and is no doubt accelerated by the downturn, since in a tough economy, cutting cost is surely a key agenda item in all meetings. Some participants in corporate board meetings might suggest the use of either free software or some software that allows end-users to easily tailor it to what they want and need, instead of hiring costly consultants to do that.

I would agree with Dana Blankenhorn's recent blog post that touts now as the best time to start a FOSS company, although it's still important (perhaps especially in the open source market) to have a unique selling proposition for the FOSS vendor. I am not sure that all the companies that pop up around various Apache modules, for example, can claim differentiation per se.

I'll take it a step further by arguing that the likes of xTuple, Compiere, or Openbravo  have done exactly what the HBR authors preached in the study.  For example, xTuple has invested in baseline horizontal technology (i.e., open source tools such as Postgres, Linux, and of course running its own manufacturing-oriented OpenMFG ERP system) and has innovated in process of building, maintaining, and delivering own differentiated products and services to certain market segments (often with the wholehearted help and participation of customers).

SOA What, As a Conclusion?

At the end of the day, I hope I (and my unnamed colleagues/friends) will not come across as being conceited but perhaps rather jaded and cynical for picking apart the great and generally informative HBR article. Perhaps I am disillusioned by an IT industry that keeps re-inventing technologies like SOA in order to make new sales.

Incidentally, I haven't heard much explicit talk about SOA in the article and during the panel discussion. Why? Perhaps because, to implement a SOA foundation in earnest a company would have to at least re-write, expose as Web services (if not completely gut out) the existing legacy IT assets to realize the subsequent agility benefits? Not to mention painstaking testing and ongoing management of these loosely coupled technologies ever after.

According to the professors’ three-step strategy (i.e., Deploy, Innovate & Propagate) from Part 1, and their case study findings (implicitly though), companies should be jumping at the opportunity to deploy SOA for flexibility and nimbleness (i.e., innovate and differentiate) reasons. That means running the business on a modern SOA platform that’s built to change and not on a client/server one that was more build to last and architecturally peaked before the advent of the Internet for business.

Today, the world's markets are so interconnected and it is the Internet (or the Web) that underpins all communication and most collaboration. Therefore, it is essential for any business that is looking to deploy a consistent and innovative platform to choose an architecture that was designed with the Web in mind (i.e., SOA) as opposed to one with the Web as an afterthought (i.e., client/server).

But there are at least two sides to SOA. For example, Ciber offers a non-technical description of SOA as follows:
“The objective of SOA is to allow businesses to extend the functionality and life of their existing IT assets, reduce architectural complexity, decrease duplication of services and data, and increase business flexibility and agility in responding to market changes. SOA is a way of molding IT technology around the needs of the business, instead of molding the business around IT.”

The first part of this definition might go along with the “Build” step and is similar to what many extended-ERP platform providers are doing: stitching together existing assets through a lower cost common middleware platform. This is laudable, especially in this economy.

However, the second part of the definition that refers more to the “Innovate” step, i.e., of molding software to the business and enabling flexibility and agility, simply are not considered by these quasi-SOA platforms. That is because the core enterprise systems and components that these platforms incorporate are themselves not necessarily SOA-based.

But then again, the HBR article findings and case studies came from the pre-2005 era, far away from the current credit crunch, recession, and the current negative market sentiments towards major system overhauls. Make no mistake, a SOA foundation enables agility, immediate results, etc., but getting to a SOA foundation from outdated infrastructures would be yet another mega-project that is not likely to get a green light in this economic climate.

Perhaps this SOA enthusiasm should be curbed a little in today’s cost-conscious markets? But on the other hand, many (including the expert panel participants, surveys, and bloggers mentioned in Part 1) will say that bad times are the best for most nimble companies to either leapfrog competitors or increase their leads even more.

Therefore, dear readers, what are your comments, opinions suggestions, experiences, and so on in this regard? Do you (and how) plan to use software to leapfrog competitors in the foreseeable future?
comments powered by Disqus