esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <>
Subject Re: ESME Process Integration
Date Tue, 05 Jan 2010 04:46:44 GMT
Comments inline

On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
<> wrote:
> 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.
I think the question here is whether such "pure" processes actually
exist or whether they are rather the exception to the rule. I think
that there is more likely to be some sort of a hybrid process whether
the foundation is a ERP-type process but certain iterations contain
steps (usually collaborative in nature) that take place outside this
model. Of course, you could try and capture such steps in the ERP
model itself but then the model would be in a constant state of
change.  The question is how do you expand the definition of the
process to include such steps. Process rigidity in this case isn't

> 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
> 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 ?
I think we are talking about two distinct but related use cases.  The
demos at Demo Jam should ERP systems joining microblogging
conversations. These conversations were "not", however, placed in a
process context. What Sig is doing is placing the messages in a
process context. I'm performing a task and I can see the messages that
relate to that task. In Sig's use case, machine-originating messages
might not make sense primarily because there are no "machines/systems"
involved in the task.

> 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 ?
I think the ERP integration might focus more on the ERP systems
posting their status messages to the microblogging systems. This
information would first of all mean less work for human users. Instead
of a knowledge worker informing his team members that a new sales
opportunity has been created, the ERP system could do this. This
machine-created message could also be sent via an email but this would
be counter-productive. The true value would the mixture of human-based
and machine-based messages creating a more comprehensive information
context. Via ESME's actions which act as filters and the fact that
users decide which machines / users to follow, the efficiency in
processing the information increases.  You could then make this
information available to ERP users in context.  If you are working on
an opportunity then you might see messages regarding the customer in
question. The real challenge will be the identification of the context
and the tagging of messages so that they are associated with a
particular context.
> 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
> 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

View raw message