A couple of days ago I wrote about an instance of XBRL’s leaping over the market chasm to see use in a no-nonsense, pragmatic, “early majority” application. This isn’t just idle marketing chatter. The question of where XBRL stands along the technology adoption curve is one that any organization or company thinking about using XBRL needs to be asking. Just how mature is this technology? How big a bet can you put on it? And if you do make a bet, what steps do you need to take to hedge it?
Just in case some readers are not familiar with Geoff Moore’s work in the area of how technologies get adopted, here is a picture of what we are talking about.
The gist of Moore’s argument is that the movement from Early Adopters to the mainstream market is discontinuous. The things that attract Early Adopters to a technology are not the same things that matter to the primary market. This isn’t just a small problem. Many promising technologies never make it across the chasm. They get hyped in the technology press and by the people who are excited because the technologies are elegant or innovative–but many of these technologies fall into the chasm and never get to the point where they make a difference in the daily operations of most companies.
Working on both sides of the chasm to effect a crossing is a tricky problem. You need Early Adopters to get a new technology started. Early Adopters are the organizations, and the people within them, who see a chance to use a new technology to build an entirely new market or to gain sudden, overwhelming competitive advantage. They are visionaries. They invest in the new technology when no one else will because they hope to change the rules of the game. Early Adopters are willing to take big risks in order to get a shot at big returns. Without Early Adopters, new technologies would never get out of the lab.
Early Majority buyers have a very different view of risk. They are managers, not visionaries, and are interested in new technologies when the technologies are the only way to reach key objectives. Early Majority buyers are not wholly risk averse, but they do need the reassurance that comes from seeing a variety of vendors offering a technology. They have no interest in being the first and only company out on a technology frontier. They also need to see a clear, near term business case before they invest in a new technology. As I noted in my article a couple of days ago, the adoption of XBRL for banking call reports is a good example of a pragmatic, early majority application. Risks can be controlled, there will be a substantial, certain payoff from Call Report Modernization, and XBRL is clearly the best way to do the job.
Not surprisingly, movement across the chasm does not happen all at once. Even as the first, highly focused applications move across the chasm, there continues to be a lot of visionary Early Adopter activity over on the left side. That is certainly true of XBRL today.
This business of being on both sides of the chasm can work out fine so long as everyone knows what side they are operating on. But you run into trouble when a buyer on the right side of the chasm, from the Early Majority, ends up with a solution that belongs somewhere over on the left side, in the world of the Early Adopters.
Last week’s XBRL conference in Washington presented an example of just such a straddling of the chasm. Barry Ward, Vice President and Head of Financial Reporting at ING Insurance Americas, U.S. Financial Services, described an XBRL initiative–a “proof of concept” effort–that his company undertook over the past year. ING sought to streamline internal reporting, eliminate rekeying of data, improve audit trails, enhance understanding of financial results within the company, and automate the creation of the many state reports that the company must produce. (Each state regulates the insurance business in its own way, with its own reporting requirements.) Ward noted that mere external reporting was NOT of interest as a stand-alone effort at ING since this would not improve efficiency, but would instead actually add another step to the reporting process. Internal use of XBRL, on the other hand, looked as if it could save money.
The U.S. unit of ING was upgrading its accounting software, and the vendor (left unnamed by Mr. Ward–later identified as a major ERP vendor) claimed to offer XBRL support as part of the general ledger program. This appeared to present an opportunity for ING to see if it could use XBRL to reduce financial reporting costs while improving the quality and utility of the reports.
Unfortunately, the project did not go well. One problem was that the general ledger vendor had not fully implemented XBRL, but had, instead, just hard-coded a set of XBRL tags into the system. So, there was no easy way for ING to update the system to make use of more recent work on the XBRL-GL taxonomy or to extend it to address the unique problems faced by the insurance industry.
On top of this problem, there was no XBRL presentation component built into the system, undercutting the whole purpose of the effort, which was to enable more flexible reporting. And then there were problems with things such as getting the system to deal with data from more than a single year.
Ward also noted that ING discovered that its financial reporting structure was more complicated than what the vendors’ XBRL system could deal with. This was partly, once again, a limitation of what Ward characterized as “first generation” software tools, but was also an indication that ING needed to spend more time on up front analysis and design than had been expected.
In Mr. Ward’s words, the end result of all this was that the XBRL proof of concept project was “put on hold for further evaluation of the approach.”
This was a painful story, though an interesting and important one. Just as interesting was the response from the XBRL experts in the audience. They were particularly critical of ING’s reliance on its general ledger software vendor for the solution. In different ways, the XBRL experts said that there ARE firms that could help ING address the problems it wants to solve. What ING should have done, in their view, was work with the much smaller companies specializing in XBRL, rather than with its mainstream accounting system vendor.
This story and reaction took me back 20 years, to when some early SGML implementations were hard coded to a particular DTD and when the only really capable SGML vendors were the little, specialist companies. Then, as now, there were stores of failed projects, first generation software, and too much complexity.
Looking back on those SGML stories, it is clear to me now that the problem was NOT one of immature software or poor planning, but of a mismatch between buyer expectations and the state of that early market. On the vendor side (I was among them), we were releasing new products every six months–sometimes more often than that–and moving ahead quickly. Most of our resources were going into development, so there was no 24/7, worldwide customer support. Customers with problems got on the phone with a developer and we released new code that fixed the problem, and probably added a few new features while we were at it. We were the “go to” companies if you wanted the most flexible, cutting edge SGML solutions–much like the companies that the XBRL experts were recommending to ING. We owned the market on the left side of the chasm.
But some of the companies and government agencies wanting to use SGML came to the market with very different expectations. They were accustomed to software products with worldwide 24/7 support, that were thoroughly tested and stable before commercial release. They were accustomed to systems supported by service organizations, where training was available, where new releases came regularly, with predictable results. They were trying to buy the kinds of systems that you find only on the right side of the chasm.
ING’s hopes and plans, matched against the response from the XBRL audience last week, shows this same kind of straddle over the chasm. ING is a worldwide company, running 24/7, wanting a system to handle its most critical information. Why should it be surprising that ING sought to work with its principal software vendor, who offers worldwide support and professional services? How could ING reconcile the size and critical importance of its accounting problems with the capabilities of a 25 person XBRL firm?
ING’s problem — and XBRL’s problem — is that ING was wanting to build an Early Majority application with what is still primarily an Early Adopter’s technology.
Which is why the FDIC’s Call Report Modernization project is such an important example. It is an early bridge across the chasm that should be able to work because the problem can be constrained and because the need to change processes and software among users can be minimized. It is the kind of XBRL project that can be put to real use right now, generating real returns.
When you are looking at your own XBRL project, ask yourself whether it is more like the Call Modernization project–nicely constrained–or whether is is more the kind of broader, more mature project that ING hoped to undertake. If it is the latter, be careful. You should probably think in terms of a pilot project–something where the focus is more on learning, rather than operational outcomes.
One last thought — technology matures rapidly, particularly when it has as much energy and investment behind it as XBRL does. The constraints on this market that apply today could be very different in six months. This is precisely why it is important to pay such careful attention to what is happening on either side of the chasm and to what is moving across it.
