Stowe Boyd picks up where Ben Metcalfe left off in Web 2.0 doesn’t work in the mothership, but… essentially recommending that Web 2.0 is best introduced in the Enterprise “in a satellite operation at arms length from the rest of your operation”

While this is often the easy solution, I think a case can be made for the seamless mashup of process- and workflow-centric enterprise applications and the more creative, unstructured, collaborative tools like wikis.  Case in point is JotSpot’s integration with Salesforce.com based on the Appexhange. Granted their target is not the largest of enterprises, but another example I heard of at SAP’s annual conference is the SAP Help Desk wiki by  Socialtext targeting the entire SAP ecosystem.  In any case, I agree that spontaneous, project-focused use is how wikis will become adopted in the Enterprise, but at the same time I believe they should be a logical extension of any Enterprise system – SAP, Salesforce.com are starting to recognize, and I think the day when we’ll have both top-down (enterprise sale as part of the large package) and bottom-up (departmental initiative) penetration is not that far.

But then Stowe goes one step further, and this is where the trouble starts:

“…the larger question — whether the enterprise would be more agile, more adaptive, and more of a survivor is it could somehow break away from the need for slow-to-change applications that span the needs of many departments, beholden to many but satisfying none — has not really been addressed by Ben or the others I am interviewing on the on ramp to CTC 2006….
My gut says yes. Enterprises would be better off if their IT departments could move to small, low cost, web-based apps that satisfy local needs — a project group, one campus in Denver, the marketing department in Japan — without having to subordinate local needs to corporate controls. The benefits of enterprise standardization are measured in the IT budget, but the true costs are distributed thoughout the enterprise: less collaboration in the research team leads to slower innovation, a less-thatn-intuitive UI for the sale staff in France leads to lowered sale numbers, and a heavyweight finance solution that slows down invoicing costs serious bank in collection time.”

Oh, boy. When we’re talking about large multinational corporations, as Stowe does in his example, the primary benefit of standardization and integration is NOT measured in the IT budget. The key benefit is competitiveness, simply being able to conduct business.  Here’s a case study from my “previous life” when I was implementing SAP systems in exactly these types of companies: The Client, a major test and measurement equipment manufacturer had no real-time visibility of their available-to-promise inventory throughout their own plants accross the US and several countries in Asia and Europe.  It typically took them 3 weeks to be able to promise a delivery date to customers. Needless to stay they started to lose business. After the SAP implementation customers could receive the promised delivery date in real-time. For this company the implementation of the standard system was not an option, or driven by IT savings, it was the only way to stay in business.

As a matter of fact, prior to standardizing on SAP the individual plants operated exactly according to Stowe’s ideal model: each doing whatever they wanted, picking their own systems that simply did not talk to each other.

Web 2.0, collaboration is great, it has it’s place in the Enterprise, but so do those “ugly complex” transactional systems.  Don’t try to run your supply chain on a wiki

Update , more than three years later: Would You Manage CRM with a Wiki?

Tags: web2.0, enterprise, sap, sapphire06, erp, crm, salesforce.com, jotspot, socialtext, supplychain, standardization, integration, systemintegration, zoliblog