ESME Process Integration

["Bechauf, Michael" <mi...@sap.com>]

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 "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 ? 

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

Re: ESME Process Integration

[Anne Kathrine Petterøe <yo...@gmail.com>]

I don't really have anything to add to this, Dick summed it up nicely (as always).
:-)


On 5. jan. 2010, at 05.46, Richard Hirsch wrote:

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

Re: ESME Process Integration

[Anne Kathrine Petterøe <yo...@gmail.com>]

LOL
I just *really* want to get our first release out the door :-)


On 7. jan. 2010, at 09.13, Markus Kohler wrote:

> Hi all,
> looks like Anne is really living the agile development ideas. I really like
> that approach :-)
> 
> Markus
> 
> "The best way to predict the future is to invent it" -- Alan Kay
> 
> 
> On Thu, Jan 7, 2010 at 1:55 AM, Anne Kathrine Petterøe <yo...@gmail.com>wrote:
> 
>> 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:
>> http://blogs.zdnet.com/Howlett/?p=1631)
>> 
>> 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
>>> <mi...@sap.com> 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 [mailto:markus.kohler@gmail.com]
>>>> Sent: Wednesday, Jan 06, 2010 3:11 AM
>>>> To: esme-dev@incubator.apache.org
>>>> 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
>>>> <hi...@gmail.com>wrote:
>>>> 
>>>>> Comments inline
>>>>> 
>>>>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
>>>>> <mi...@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
>>>>>> 
>>>>> 
>>>> 
>> 
>> 

Re: ESME Process Integration

[Markus Kohler <ma...@gmail.com>]

Hi all,
looks like Anne is really living the agile development ideas. I really like
that approach :-)

Markus

"The best way to predict the future is to invent it" -- Alan Kay


On Thu, Jan 7, 2010 at 1:55 AM, Anne Kathrine Petterøe <yo...@gmail.com>wrote:

> 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:
> http://blogs.zdnet.com/Howlett/?p=1631)
>
> 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
> > <mi...@sap.com> 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 [mailto:markus.kohler@gmail.com]
> >> Sent: Wednesday, Jan 06, 2010 3:11 AM
> >> To: esme-dev@incubator.apache.org
> >> 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
> >> <hi...@gmail.com>wrote:
> >>
> >>> Comments inline
> >>>
> >>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
> >>> <mi...@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
> >>>>
> >>>
> >>
>
>

Re: ESME Process Integration

[Martin Böhringer <ma...@wirtschaft.tu-chemnitz.de>]

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
Martin


Zitat von Anne Kathrine Petterøe <yo...@gmail.com>:

> 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: http://blogs.zdnet.com/Howlett/?p=1631)
>
> 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
>> <mi...@sap.com> 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 [mailto:markus.kohler@gmail.com]
>>> Sent: Wednesday, Jan 06, 2010 3:11 AM
>>> To: esme-dev@incubator.apache.org
>>> 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
>>> <hi...@gmail.com>wrote:
>>>
>>>> Comments inline
>>>>
>>>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
>>>> <mi...@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
>>>>>
>>>>
>>>
>
>
>

Re: ESME Process Integration

[Anne Kathrine Petterøe <yo...@gmail.com>]

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: http://blogs.zdnet.com/Howlett/?p=1631)

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
> <mi...@sap.com> 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 [mailto:markus.kohler@gmail.com]
>> Sent: Wednesday, Jan 06, 2010 3:11 AM
>> To: esme-dev@incubator.apache.org
>> 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
>> <hi...@gmail.com>wrote:
>> 
>>> Comments inline
>>> 
>>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
>>> <mi...@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
>>>> 
>>> 
>> 

Re: ESME Process Integration

[Ethan Jewett <es...@gmail.com>]

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
<mi...@sap.com> 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 [mailto:markus.kohler@gmail.com]
> Sent: Wednesday, Jan 06, 2010 3:11 AM
> To: esme-dev@incubator.apache.org
> 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
> <hi...@gmail.com>wrote:
>
>> Comments inline
>>
>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
>> <mi...@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
>> >
>>
>

RE: ESME Process Integration

["Bechauf, Michael" <mi...@sap.com>]

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:markus.kohler@gmail.com] 
Sent: Wednesday, Jan 06, 2010 3:11 AM
To: esme-dev@incubator.apache.org
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
<hi...@gmail.com>wrote:

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

Re: ESME Process Integration

[Markus Kohler <ma...@gmail.com>]

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 <hi...@gmail.com>wrote:

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

Re: ESME Process Integration

[Richard Hirsch <hi...@gmail.com>]

Comments inline

On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
<mi...@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
>

Re: ESME Process Integration

[Richard Hirsch <hi...@gmail.com>]

@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 <ma...@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
>

RE: ESME Process Integration

["Lang, Martin" <ma...@sap.com>]

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.
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.
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.

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