Enterprise 2.0: it's not about people it's about process. Part 1

The conventional Enterprise 2.0 wisdom is that people matter over process.
Written by Dennis Howlett, Contributor

The conventional Enterprise 2.0 wisdom is that people matter over process. It is about value coming from the social relationships between people that govern our approach to applications going into the next decade as a way of delivering the next wave of value to the business. While the amplified concepts surrounding E2.0 emphasize unstructured data, emergent behaviors, crowdsourcing and information discovery, they say nothing about how all of this 'stuff' is supposed to fit into the existing IT landscape. It appears as an afterthought. It's a dangerous way to think.

From 30,000 feet we have two basic flavors of E2.0: that which faces outwards as an adjunct to existing sales and marketing activities. Today we see that morphing into the idea of Social CRM. The second can broadly be corralled into the general idea of business collaboration. At that same 30,000 feet, both have merit as standalone concepts. Both can deliver at least some value. However they quickly break down once we start to examine them in the context of the existing applications landscape and the business hierarchies that are both supporting and supportive of what we call enterprise IT.

The other day I pointed to the classic problem of turf wars and process gaps which are a common feature in the conduct of business and which serve to cut across processes involving people. They cannot be ignored because they always impact the business, often with enormous consequences as evidenced in the Nigerian Pants Bomber story.

E2.0 mavens have tried to side step this problem broadly arguing either that hierarchies will disintegrate from the bottom up or that business requires a fundamental redesign around the social. That can be true in knowledge based businesses but I'd be hard pressed to see those ideas taking root in large scale manufacturing or process industries. Both notions ignore the problem of managing process which is where all the business action takes place and from which monetary value flows via the transactions those processes generate. Think about it. Does the fact I Tweeted something or that I annotated a wiki post deemed as valuable create monetary value on the balance sheet? Of course not. It's what happens when that non-monetary value is converted to real money that it becomes recognizable as having business value. And for that we need processes.

In what we might call the 'old world,' automating processes allows us to become more efficient or, with a bit more automation and tweaking, more effective. Whether that's been achieved is not wholly relevant to this discussion even though it is frequently debated. Whether we can function without IT is an altogether different story and that means at least a partial acceptance of what we have. It's either that or blow up the whole SAP/Oracle/IBM etc edifice. That alternative is what seems to be in the minds of at least some E2.0 mavens although I can find no support for that position from business.

Brian Sommer has argued that the current crop of established applications are largely ill suited to the fast paced world in which we live. He correctly points out the technical limitations of much enterprise software. Key to his argument is that at least some software companies have figured a way around the problem. In other words it may not be necessary to throw out the concepts of ERP etc but supplant them with other ways to crack the process change nut.

In the alternative, Phil Wainewright argues something quite different:

I believe we’re at a breakthrough point precisely because technology has matured to the point that it’s flexible enough to be adapted to what the people who use it are trying to achieve — to empower them to refine the automation and processes that help them fulfil their roles as effectively as possible. We no longer have to ask people to change their processes to fit in with the demands of punch card runs or application stovepipes or implementation and upgrade cycles. We now have information technology that’s sophisticated enough to fit in with how human beings work and behave, and that’s why people-centric IT is a defining theme for the new decade, requiring information technologists to develop new skills and ways of working that deliver results the people demand.

Despite Phil's lacking of concrete proofs, it's an extremely seductive argument until, once again, you realize that Phil is sidestepping the process problem in the context of what we have at our disposal. Sure, we desperately need better UX, certainly the consumer world has much to teach but in isolation they cannot achieve much that you would recognize as business value. Even with the most sophisticated SOA deployments, you still have the problem of working within often rigid process environments. What to do?

If we step back a moment and look at the problems E2.0 is seeking to solve you can argue (at least from the collaboration perspective and possibly the outward facing sales/marketing angle) that they are trying to meaningfully surface information that adds value somewhere in the process chain and which ultimately can be turned into money. Right now that broadly doesn't happen except through manual application and even then in a chaotic way. Somewhat self defeating. That neatly brings me to an email SAP's Michael Bechauf penned to the ESME Apache incubator group. The essence of what he is asking is as follows:

What can micro-blogging utilities like ESME really do to make ERP systems "better" ? For me, this was not a technical integration question, but rather a fundamental question...

The way I look at ERP systems is that a business process is broken up into multiple steps that can each be executed with a specific transaction. Most of these transactions can also be executed through some remote invocation interface (WS*, RFC or whatever) which would apparently be used by ESME. People with specific roles using the ERP system would enter those transactions, either triggered by an outside event (Goods Receipt, Create Sales Order, Shipment) or prompted through some workflow in the system. In a way, the system is designed and implemented so that it's clear when who has to do what. The level of success of an ERP implementation depends on the degree of automation that can be accomplished.

Typically, ERP systems work best with what Sig lovingly calls "Easily Repeatable Processes". An event happens, an appropriate transaction is executed, the ERP systems determines specific follow-up action that either need to be executed manually by a person or a follow-up business process is triggered automatically. Even in the case of customer support, where Twitter is said to have some enterprise-level success, the CRM system will make sure that a customer support specialist will give a customer a callback, and if that hasn't happened within a certain time period, a different customer service agent would be found. Essentially, it is all about predictability.

Obviously, predictability only works as long as the real world works in synchronisity with the inner workings of the ERP system. In many cases it is not; that's when people pick up phones or maybe use some internal micro-blogging utility. Somebody will say, "Hey, I've got this customer who presents me with this issue, anybody out there who can help ?".

However, what kind of "integration" is required to make this happen ? The demos that were shown at Demo Jam essentially published an event with a text on ESME, but isn't that in reality just somebody typing in a question ? Would ESME really trigger a business process through some remote invocation interface, like creating a PO, or would the ESME user, once a question was satisfactorily answered by their network, rather turn to their ERP screen and enter whatever they have learned ?

So, essentially what I'm saying is that I don't think an ESME integration with ERP will be of significant value. ESME as a standalone tool may very well be, but then what is its sweet spot compared to Twitter or compared to commercial tools for enterprise-level deployment that are already on the market ?

Let's break this down as in many ways it goes to the heart of the issues surrounding E2.0 as applied to the existing IT landscape. I should at this point say that Michael's question is one I've seen asked in similar fashion by representatives of other large ERP players so let's not assume for one minute that what I'm referencing represents the ramblings of one individual. This is a big issue.

In the ideal IT ERP landscape automated processes deliver the optimal result. In the real world that's rarely the case. Or rather it is rarely so in specific application areas. If you think about it what's to go wrong with financials? Not much. HR admin? Not so much. CRM? Yep - all sorts of things. SCM? Plenty. Parse that to say industry specific order to cash processes (as an example) and there are potentially multiple points of failure, even though the aggregated process steps should deliver more value than trying to traverse many applications.

The ESME DemoJam use case was meant to describe a relatively simple scenario where a person was operating a process that broke down. In the demonstrated use case it works as a people based discovery mechanism for problem resolution that would otherwise get shoveled into an email trail. I'd therefore argue that in time saved, ESME demonstrated value which could be costed back to the process issue. I'd also add that because ESME was integrated to what was a NetWeaver process, the savings were greater than going out to a non-integrated service. Taking an integrated process view, microblogging tools can deliver value. Expand that to blogs/wikis and you can make a reasonable case for E2.0 technologies helping in the case of broken processes which are readily fixed. Yes it has a social component but that is not the main point. It's about the ability to leverage the network while in process.

So - given we have ERP which may be capable of varying levels of automation but which is often inflexible and/or liable to breakdown then what are we to do? How can we optimize processes, continue to reap benefit from ERP and yet manage improvement in a fast track process world while at the same time leveraging E2.0 data? That's the subject of the next post.

Editorial standards