esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <markus.koh...@gmail.com>
Subject Re: ESME Process Integration
Date Wed, 06 Jan 2010 11:11:14 GMT
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 <hirsch.dick@gmail.com>wrote:

> Comments inline
>
> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
> <michael.bechauf@sap.com> 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
> >
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message