I can't help but wonder if ESME is like a hammer trying to find an ERP
nail to drive in.
If I need to do something, and get notified, there is something that is
called an "inbox" on every mobile device. Why would I go into an ESME
client to check what I have to do, given that Twitter does not even have
the notion of an "unread" indicator ?
The whole idea of Twitter is transient information, where connections
are established and collaborations are started by conversations I become
aware of, or that I discover by following threads. It's ok if I don't
see a message. On the contrary, Twitter shouldn't be used like an inbox,
and few people do (I happen to do so, because I have relatively few
people I follow, and I want to catch up on what they say. Try that with
1000+ people you follow ...).
Sure, there are plenty of things that are technically possible, like
having a natural language parser for creating POs or time entry, but is
that natural to anybody ? It would be for me. If I do time entry, I go
to a URL in my browser and do so right there.
If there are use cases, they need to be related to transient
information, not things to do. Publishing ERP events "just for
information" like what Dick suggested may be interesting, but I'm still
missing the specific use case. Am I really interested when a PO is
created, particularly when there is little context other than a PO
number that can be provided ?
So, it's gotta be something more natural; perhaps in service management
where service technicians in the field communicate with each other to
resolve a problem, but also get notified if a new problem arises within
a specific domain or location. I'm not a service management expert, but
that's something that I could personally imagine, and that is related to
ERP. Or what about PLM, where product designers interact with each other
to discuss an engineering problem, and where the ERP system could also
feed in new documents that are checked in, with a short description of
what these documents are about. If I don't miss the message, no big
deal, but if I happen to see it, and the content of the document
interest me or pertain to the problem I am trying to solve right now, it
could be helpful.
Best,
Michael
-----Original Message-----
From: Markus Kohler [mailto:[email protected]]
Sent: Wednesday, Jan 06, 2010 3:11 AM
To: [email protected]
Subject: Re: ESME Process Integration
Hi all,
Very good discussion here.
I would like to add a few points.
What are the key factors that made twitter successful and how can these
key
factors be useful in ERP scenarios?
There are certainly a few factors, but I think one reason for twitters
success is that by limiting the message size to the famous 140
characters, *it
works very well on mobile devices *such as the Iphone and even less
capable
smartphones.
With twitter one can use some spare time (waiting for the bus for
example)
to do do something useful, for example check the latest news, chatting
with
friends, etc.
In ERP applications there are certain simple tasks, such as as the
approval
for a leave request that can easily be done on a phone, but there are
other
tasks that are just to complex from the UI side to be done on a phone.
I believe that simple tasks could be done from within ESME using a
widget
approach or natural language processing, whereas for more complex tasks
the
ESME message would just contain a link.
Coming back to the leave request, the system could send a message to the
approver which would include a widget that would show the time frame and
the possibility to approve or reject, by just clicking a button (and
optionally enter a message).
Alternatively one could use some syntax or natural language processing
for
approving. This could be as simple as sending a replay with a message
"Approved".
In short I think twitter's short message approach could be extended by
small
widgets/microapps that a rendered inline within ESME.
I fear that with a pure syntax based approach usability could be an
issue.
What would be at least needed is that the message caries some
information
that allows the user to get some help about the syntax used.
In addition ESME could be embedded within existing ERP
applications similar to what SAP All-In-One has done for their demo.
This
could mean that a standalone ESME would not be necessary. But IMHO that
goes
somewhat against the spirit of a twitter like application, that also
fosters
collaboration by making messages available to unknown consumers.
Regards,
Markus
"The best way to predict the future is to invent it" -- Alan Kay
On Tue, Jan 5, 2010 at 5:46 AM, Richard Hirsch
<[email protected]>wrote:
Comments inline
On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
<[email protected]> 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.
<dlh>
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
helpful.
</dlh>
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 ?
<dlh>
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.
</dlh>
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 ?
<dlh>
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.
</dlh>
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
