esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Hirsch <hirsch.d...@gmail.com>
Subject Re: ESME Process Integration
Date Wed, 06 Jan 2010 05:02:51 GMT
@Martin: your use cases make sense.

I like the use cases that simplify the interaction with ERP systems
that users have (for example, #1 or #3). Now, some might say that such
interaction is also possible via other means. There are widgets
(MicroApps, etc.) that perform similar functions but these are usually
restricted to one task and one individual.  If you have a widget on
your desk tracking the developments of a certain opportunity, there is
no social aspect at all. It represents your view on that object. If
you want to talk to someone else about that customer, you have to move
to another platform.  You also can't find others who have knowledge
about that customer.

On Wed, Jan 6, 2010 at 4:10 AM, Lang, Martin <martin.lang@sap.com> wrote:
> I had been following the Twitter discussion last Monday and feel inspired by the eloquent
and eMail Michael wrote below.
> Other than that I am fairly new to ESME as well as this dev list (few weeks give or take)
and have been listening, reading and watching for the most part so far. While I have read
quite a bit and watched some of the YouTube Videos on ESME, I am not really sure whether I
can already contribute something new but I felt I'll try.
>
> Michael was asking below for specific examples of ESME scenarios with enterprise systems.
Again I don't know whether some of this was discussed before and possibly dismissed for whatever
reason, but I could imagine some scenarios that I would consider very useful and practical.
> Here are three ideas:
>
> (1) Time Management
> Consultant sends messages like: "Tuesday 9hours on project xzy" to an ERP based central
account, that interprets the message (e.g. with akibot or BusinessObjects Textanalysis components)
and posts respective entries in the respective ERP time recording system. Obviously the syntax
of the potential message would allow for certain variations, mentioning specific dates or
date ranges, specific tasks or task categories to make things flexible enough. The ERP system
or the "bot" in between would send back confirmation messages or clarifying questions, if
the message is not complete.
>
> (2) Proactive 360° Customer information sharing
> In my world discussions about tools that provide comprehensive overviews for Sales People
or Consulting managers have come up many times. Certain tools were built but nothing so far
really provided all information that's valuable for a Sales Person, a Consulting Manager,
Account Exec etc. Examples are:
> - Open Opportunities
> - Quotes and their status, approval status etc.
> - Contracts and many aspects around contracts, e.g. status, imminent expiration, burn
or fill rates, margin leakage etc.
> - Invoices issued
> - Overdue invoices
> - Invoice Disputes
> - Support Tickets in general or escalated support tickets in particular
> - Skills required (and possible not yet found) for a Consulting Contract
> - List could go on and on
>
> Objects and the information behind these objects would typically reside in ERP, CRM or
similar systems and while the processes to create many of these objects is typically A-B-C
and fairly straight forward and mostly repeatable, what's more unstructured is who's interested
in this information or for whom it would be very valuable to know about these things. Yes
ERP/CRM systems like SAPs provide functionality to e.g. maintain certain partner roles or
business partner functions and if maintained correctly the people maintained in such roles
can be informed somewhat automatically through e.g. an eMail but in reality it seems that
in a larger Sales and/or Consulting organization it's close to impossible to keep accurate
track of who is interested in what.
> Wouldn't it be easier if Sales People, Consulting folks or whoever customer facing or
in the backoffice supporting field organizations could just "follow" these objects and all
or some of their attributes? The ERP, CRM etc. systems involved would "chat" about all significant
events that happen and whoever is interested can follow these things, or once he receives
them forward them to other folks or take certain actions on them (even like forwarding an
invoice dispute (as an example) to 12sprints an open a discussion on impact and potential
resolutions)
> From my perspective this might actually overall be less effort and more promising than
continuing the path to try to built 360° view UIs, that read and display certain information
in a single screen, as these tools seem to be never complete and the business is changing
to fast, so that the UI and logic underneath can never keep up with what's needed.
> A "chatter" (just using the term don't mean SFDC's) like interface might be less effort,
as it's all messages based and any new objects would just need to be connected to the API
to start chattering as well.

This is an excellent point. The cost of making new objects "chatty" is
relatively low. This is what I also discovered in my work with Apache
OFBiz. Once the basic techincal framework is established, the cost of
adding functionality to a new object is low. Since the ABAP connector
for ESME already exists, I'm assuming the same could be said for SAP
"objects".

> On the client side, no adjustments would be required even if additional components start
to chat, and obviously multiple clients would be available for the potential users in the
field or wherever, mobile, web, AIR, WDA. etc.
>
> (3) Talking ERP/CRM
> Not 100% sure about this one (and essentially it's like (1), but driving it further).
I find the ideas of bots still very appealing because of the simplicity of a natural conversation.
Also with the newest voice recognition possibilities it's conceivable that we might not even
have to type things anymore at some point. E.g. I recently added " de2en@bot.talk.google.com"
to my Google Talk account and when I type in a sentence in German, it answers me right away
and gives me the translation in English. How about I could do similar things with me ERP system
and with that bring the learning curve down to practically 0.
> I would follow, e.g. an ERP based bot and send him a message (or DM) saying "my recent
trips" and it would give me a trip overview with reimbursement status etc. of my last few
trips.

Instead of a DM, you might have your own private pool.

> Or I could say: "Send PO 45000000012 to xy@z.com" and if I am authorized to issue such
an action (the ERP system could easily validate that) it would be executed. "Run report abc
today 8PM and send result to user123" would be another example etc.
>

You just need one example ESME bot based in any development language
and application code to send this information to a back-end and you
can rapidly create a multi-faceted integration scenario.

> Does this make sense? Or not really? Again am fairly new to this discussion...
> All the best
> Martin
>
>
> -----Original Message-----
> From: Bechauf, Michael [mailto:michael.bechauf@sap.com]
> Sent: Monday, January 04, 2010 20:17
> To: esme-dev@incubator.apache.org
> Subject: ESME Process Integration
>
> 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 "integraton" 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
>

Mime
View raw message