incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Martin Böhringer <>
Subject Re: ESME Process Integration
Date Thu, 07 Jan 2010 03:32:35 GMT
Aloha ;)

Let me just throw in an outsider's view on the ESME/SAP discussion. I  
totally agree with Anne:

> Maybe we don't have to define everything up front either?

Off course it might not be a brillant idea to use microblogging for  
well-structured processes which can be defined before they occure.  
This is the business of SAP for decades. My point of view as a  
researcher in Enterprise Information Systems is that the whole point  
of microblogging is providing an infrastructure for ad hoc processes.  
That is all the stuff that happens but is not supported by ERP  
systems. So we talk about synergy, not about substituting anything.

I think, SAP has a great chance here to leverage ESME as  
community-driven but "SAP-friendly" tool to get on the top of this  
discussion. This clearly is the future of Information Systems.

There is only limited potential in optimizing prozesses (which have  
been optimized with IT for 20 years). The potential lies in processes  
which are not supported by process-oriented systems yet.

Regards from HICSS Information Systems conference at Hawaii

Zitat von Anne Kathrine Petterøe <>:

> Michael,
> Rather than ESME being the hammer trying to find an ERP nail to  
> drive in, I wonder if you do ;-)
> If anyone you (and Dick) probably knows ERP best, so please keep the  
> ideas coming.
> We should probably hold off this discussion until Dennis has  
> published his series of blog posts though, he will most likely give  
> us something to chew on. (For those of you who don't know which post  
> we are referring to:
> Just a few practical things from my side (to everyone):
> Right now I am first and foremost busy with two things, namely  
> getting our new UI up and running and getting our first release out  
> the door. Without a release there will never be an ERP integration  
> if you see my point? I would at least much rather spend my evenings  
> coding than reading and answering emails right now. And I could need  
> whatever little help I can get.
> Don't want to offend anyone here by saying I don't appreciate the  
> discussions, just let's not forget it would be great to finally  
> write Apache ESME release 1.0 on our next board report :-)
> ..only 32 Jira tasks to go..
> Last 2 cents for tonight, a twitter comparison.
> One of the things I always liked about twitter was that it was the  
> users who defined the service.
> Look at how hashtags, @-replies, RT (old format), the API-client  
> usage etc. came about, not one was a feature Twitter had initially  
> thought of. Maybe we don't have to define everything up front  
> either? Once we have a product we can ship and a few use cases as  
> examples for what *can* be done with ESME, who knows where it might  
> end up? I know that when I talk to my colleagues about it they often  
> have very different ideas than I do for instance.
> /Anne
> On 6. jan. 2010, at 18.56, Ethan Jewett wrote:
>> Micheal,
>> I think it's a difficult request you are making, because ESME is a
>> type of communication mechanism that has never before been integrated
>> into an ERP. We need your help figuring this out! :-) The key will be
>> to find use-cases that are suited to the format: Transitory,
>> contextual messages
>> Because of the new-ness of the area, there are going to be a lot of
>> idea flying around about how best to integrate. Some of those ideas
>> will prove to truly add value to an ERP system and most of them won't.
>> The fact that you don't see a single idea as adding value does not
>> mean that there are not ways to add value, and it certainly doesn't
>> mean that ESME is irrelevant.
>> Perhaps we can look at existing SAP business processes and start to
>> understand when it can best fit in.
>> Personally, I'm also not very motivated by the "tweeting ERP system"
>> use case, though I do think it has more potential than you give it
>> credit for. Let's say that we hook up all of our ERP-like systems to
>> ESME and have them send messages whenever a transaction happens
>> involving a customer, and they tag the message with the customer ID.
>> Now a new sales rep becomes responsible for customer XYZ. How do they
>> find out what is happening with that customer? If you've ESME-enabled
>> all your transactional systems, then they just subscribe to that
>> customer's tag, and automatically see everything that is going on,
>> with links back to the relevant transactions and reports. So, I think
>> messaging like this can add value in that context
>> (discoverability/dashboards).
>> However, I think the more compelling use-case is similar to the one
>> Sig is working on with Thingamy. Basically, contextual messaging
>> around a specific business-process step.
>> Let's give an example: Perhaps a financial analyst is executing a
>> period close process in a consolidation system (which happens to be
>> integrated into ESME). The analyst comes across a discrepancy - the
>> numbers don't match what they should be. Standard operating procedure
>> in a lot of organizations (come on, admit it :-) is to try to figure
>> out what the problem is for a while, not figure it out, then put in a
>> plug entry to make the number right. Eventually the plug entry becomes
>> part of the "business process", which is now less of a "business
>> process" and more of a "financial close process" because the finances
>> are no longer as connected to how the business works.
>> In an ESME-enabled system, the analyst would send a message listing
>> the account, the amount, the relevant legal entity and profit center,
>> and a brief description of the issue. 75% of the time, no one will
>> respond, and the analyst will book the plug just like always. 25% of
>> the time, the controller in the Brazilian entity will see the message
>> and say, "Hmmm, we made a local accounting process change last month
>> that affected that account. The number looks very similar. I wonder if
>> that could have something to do with it." One thing leads to another
>> and eventually the process is permanently fixed and is closer to the
>> business. In the long run, this better correlation between financial
>> process and actual business events will lead to a ... dare I say it
>> ... better run business. :-)
>> That is the type of contextual, discoverable messaging that adds
>> value. You can't really model that process because the whole point is
>> that it is plugging a broken process in a dynamic and unpredictable
>> way. You can't do this with email or a workflow because you don't know
>> who the message should go to. That's the type of scenario when
>> communication systems like ESME and Twitter add value.
>> Hopefully that's helpful,
>> Ethan
>> On Wed, Jan 6, 2010 at 11:08 AM, Bechauf, Michael
>> <> wrote:
>>> 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 []
>>> Sent: Wednesday, Jan 06, 2010 3:11 AM
>>> To:
>>> 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
>>> <>wrote:
>>>> 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.
>>>> <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

View raw message