In an effort to hopefully once and for all settle the question of what type of 
integration with 3rd party application systems ESME would be best suited for I 
want to capture the essence of a Twitter conversation that happened today. 
Basically, it was started by @dahowlett in reference to Thingamy. Dennis said 
that "#esme's true power is the NetWeaver integration so @sig's work has 
significance". I have not seen the Thingamy/ESME work, but I felt compelled to 
again bring up an old question: 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 that can easily be 
applied to SFDC Chatter as well.

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 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 ? 

The Thingamy thing caught my attention because the way I understand it, what 
Sig has developed is precisely for those "Barely Repeatable Processes", meaning 
things that can't be executed like A-B-C, but where the activities of people 
need to be coordinated in a unpredictable way in order to resolve a specific 
situation. So, when exceptions become the norm, an ERP system is not really 
well suited, and an BRP system - however this is going to look like - will take 
over. Intuitively, for these kind of things ESME will be better suited, and 
from what I was able to follow on the list, an ESME conversation is actually 
associated with the specific context of that BRP. That makes sense to me. 

I read Sig's latest blog where he compared 12sprints and Chatter with "Sending 
email through Word" which sounds a little grandiose to me. I don't know Chatter 
yet, but 12sprints seemed like it could show the future of applications, where 
decisions need to be made in an unpredictable way with a set of people, and how 
a system would support that. This could also be augmented with business 
intelligence and of course also micro-blogging. But in this case, the system is 
designed to work with Barely Repeatable Processes, and associating the 
conversation in ESME with the BRP context or 12sprint task could lead to 
interesting applications. 

But that's all very different than trying to kind of artificially integrate 
ESME with a system that assumes that the world works like A-B-C. What I believe 
is for ESME to *really* work efficiently, is to design application systems that 
deal better with unpredictable situations, and then make best use of ESME 
capabilties, instead of trying to superimpose ESME on the A-B-C world of 
today's ERP. Yes, it's technically possible, but whether it makes sense is a 
different story.

All that I'm trying to establish is what needs to be built for the ESME engine 
in order to really be useful and different, and on the other side understand 
how application systems should look like that better deal with the 
unpredictable processes where ESME shines. I briefly looked at the Chatter 
announcement, and SFDC was also mentioning better integration with application 
data or business intelligence, but I wasn't able to read more from it. 

Anyway, hope this is helpful, and we can start a discussion from it. I know you 
had some use case discussions already, but I really could not find any specific 
examples. 

Best,
Michael

Reply via email to