esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Anne Kathrine Petter√łe <>
Subject Re: ESME Process Integration
Date Thu, 07 Jan 2010 12:15:37 GMT
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 <>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:
>> Just a few practical things from my side (to everyone):
>> Right now I am first and foremost busy with two things, namely getting our
>> new UI up and running and getting our first release out the door. Without a
>> release there will never be an ERP integration if you see my point? I would
>> at least much rather spend my evenings coding than reading and answering
>> emails right now. And I could need whatever little help I can get.
>> Don't want to offend anyone here by saying I don't appreciate the
>> discussions, just let's not forget it would be great to finally write Apache
>> ESME release 1.0 on our next board report :-)
>> ..only 32 Jira tasks to go..
>> Last 2 cents for tonight, a twitter comparison.
>> One of the things I always liked about twitter was that it was the users
>> who defined the service.
>> Look at how hashtags, @-replies, RT (old format), the API-client usage etc.
>> came about, not one was a feature Twitter had initially thought of. Maybe we
>> don't have to define everything up front either? Once we have a product we
>> can ship and a few use cases as examples for what *can* be done with ESME,
>> who knows where it might end up? I know that when I talk to my colleagues
>> about it they often have very different ideas than I do for instance.
>> /Anne
>> On 6. jan. 2010, at 18.56, Ethan Jewett wrote:
>>> Micheal,
>>> I think it's a difficult request you are making, because ESME is a
>>> type of communication mechanism that has never before been integrated
>>> into an ERP. We need your help figuring this out! :-) The key will be
>>> to find use-cases that are suited to the format: Transitory,
>>> contextual messages
>>> Because of the new-ness of the area, there are going to be a lot of
>>> idea flying around about how best to integrate. Some of those ideas
>>> will prove to truly add value to an ERP system and most of them won't.
>>> The fact that you don't see a single idea as adding value does not
>>> mean that there are not ways to add value, and it certainly doesn't
>>> mean that ESME is irrelevant.
>>> Perhaps we can look at existing SAP business processes and start to
>>> understand when it can best fit in.
>>> Personally, I'm also not very motivated by the "tweeting ERP system"
>>> use case, though I do think it has more potential than you give it
>>> credit for. Let's say that we hook up all of our ERP-like systems to
>>> ESME and have them send messages whenever a transaction happens
>>> involving a customer, and they tag the message with the customer ID.
>>> Now a new sales rep becomes responsible for customer XYZ. How do they
>>> find out what is happening with that customer? If you've ESME-enabled
>>> all your transactional systems, then they just subscribe to that
>>> customer's tag, and automatically see everything that is going on,
>>> with links back to the relevant transactions and reports. So, I think
>>> messaging like this can add value in that context
>>> (discoverability/dashboards).
>>> However, I think the more compelling use-case is similar to the one
>>> Sig is working on with Thingamy. Basically, contextual messaging
>>> around a specific business-process step.
>>> Let's give an example: Perhaps a financial analyst is executing a
>>> period close process in a consolidation system (which happens to be
>>> integrated into ESME). The analyst comes across a discrepancy - the
>>> numbers don't match what they should be. Standard operating procedure
>>> in a lot of organizations (come on, admit it :-) is to try to figure
>>> out what the problem is for a while, not figure it out, then put in a
>>> plug entry to make the number right. Eventually the plug entry becomes
>>> part of the "business process", which is now less of a "business
>>> process" and more of a "financial close process" because the finances
>>> are no longer as connected to how the business works.
>>> In an ESME-enabled system, the analyst would send a message listing
>>> the account, the amount, the relevant legal entity and profit center,
>>> and a brief description of the issue. 75% of the time, no one will
>>> respond, and the analyst will book the plug just like always. 25% of
>>> the time, the controller in the Brazilian entity will see the message
>>> and say, "Hmmm, we made a local accounting process change last month
>>> that affected that account. The number looks very similar. I wonder if
>>> that could have something to do with it." One thing leads to another
>>> and eventually the process is permanently fixed and is closer to the
>>> business. In the long run, this better correlation between financial
>>> process and actual business events will lead to a ... dare I say it
>>> ... better run business. :-)
>>> That is the type of contextual, discoverable messaging that adds
>>> value. You can't really model that process because the whole point is
>>> that it is plugging a broken process in a dynamic and unpredictable
>>> way. You can't do this with email or a workflow because you don't know
>>> who the message should go to. That's the type of scenario when
>>> communication systems like ESME and Twitter add value.
>>> Hopefully that's helpful,
>>> Ethan
>>> On Wed, Jan 6, 2010 at 11:08 AM, Bechauf, Michael
>>> <> wrote:
>>>> I can't help but wonder if ESME is like a hammer trying to find an ERP
>>>> nail to drive in.
>>>> If I need to do something, and get notified, there is something that is
>>>> called an "inbox" on every mobile device. Why would I go into an ESME
>>>> client to check what I have to do, given that Twitter does not even have
>>>> the notion of an "unread" indicator ?
>>>> The whole idea of Twitter is transient information, where connections
>>>> are established and collaborations are started by conversations I become
>>>> aware of, or that I discover by following threads. It's ok if I don't
>>>> see a message. On the contrary, Twitter shouldn't be used like an inbox,
>>>> and few people do (I happen to do so, because I have relatively few
>>>> people I follow, and I want to catch up on what they say. Try that with
>>>> 1000+ people you follow ...).
>>>> Sure, there are plenty of things that are technically possible, like
>>>> having a natural language parser for creating POs or time entry, but is
>>>> that natural to anybody ? It would be for me. If I do time entry, I go
>>>> to a URL in my browser and do so right there.
>>>> If there are use cases, they need to be related to transient
>>>> information, not things to do. Publishing ERP events "just for
>>>> information" like what Dick suggested may be interesting, but I'm still
>>>> missing the specific use case. Am I really interested when a PO is
>>>> created, particularly when there is little context other than a PO
>>>> number that can be provided ?
>>>> So, it's gotta be something more natural; perhaps in service management
>>>> where service technicians in the field communicate with each other to
>>>> resolve a problem, but also get notified if a new problem arises within
>>>> a specific domain or location. I'm not a service management expert, but
>>>> that's something that I could personally imagine, and that is related to
>>>> ERP. Or what about PLM, where product designers interact with each other
>>>> to discuss an engineering problem, and where the ERP system could also
>>>> feed in new documents that are checked in, with a short description of
>>>> what these documents are about. If I don't miss the message, no big
>>>> deal, but if I happen to see it, and the content of the document
>>>> interest me or pertain to the problem I am trying to solve right now, it
>>>> could be helpful.
>>>> Best,
>>>> Michael
>>>> -----Original Message-----
>>>> From: Markus Kohler []
>>>> Sent: Wednesday, Jan 06, 2010 3:11 AM
>>>> To:
>>>> Subject: Re: ESME Process Integration
>>>> Hi all,
>>>> Very good discussion here.
>>>> I would like to add a few points.
>>>> What are the key factors that made twitter successful and how can these
>>>> key
>>>> factors be useful in ERP scenarios?
>>>> There are certainly a few factors, but I think one reason for twitters
>>>> success is that by limiting the message size to the famous 140
>>>> characters, *it
>>>> works very well on mobile devices *such as the Iphone and even less
>>>> capable
>>>> smartphones.
>>>> With twitter one can use some spare time (waiting for the bus for
>>>> example)
>>>> to do do something useful, for example check the latest news, chatting
>>>> with
>>>> friends, etc.
>>>> In ERP applications there are certain simple tasks, such as as the
>>>> approval
>>>> for a leave request that can easily be done on a phone, but there are
>>>> other
>>>> tasks that are just to complex from the UI side to be done on a phone.
>>>> I believe that simple tasks could be done from within ESME using a
>>>> widget
>>>> approach or natural language processing, whereas for more complex tasks
>>>> the
>>>> ESME message would just contain a link.
>>>> Coming back to the leave request, the system could send a message to the
>>>> approver which would include a widget that would show the time frame and
>>>> the possibility to approve or  reject, by just clicking a button (and
>>>> optionally enter a message).
>>>> Alternatively one could use some syntax or natural language processing
>>>> for
>>>> approving. This could be as simple as sending a replay with a message
>>>> "Approved".
>>>> In short I think twitter's short message approach could be extended by
>>>> small
>>>> widgets/microapps that a rendered inline within ESME.
>>>> I fear that with a pure syntax based approach usability could be an
>>>> issue.
>>>> What would be at least needed is that the message caries some
>>>> information
>>>> that allows the user to get some help about the syntax used.
>>>> In addition ESME could be embedded within existing ERP
>>>> applications similar to what SAP All-In-One has done for their demo.
>>>> This
>>>> could mean that a standalone ESME would not be necessary. But IMHO that
>>>> goes
>>>> somewhat against the spirit of a twitter like application, that also
>>>> fosters
>>>> collaboration by making messages available to unknown consumers.
>>>> Regards,
>>>> Markus
>>>> "The best way to predict the future is to invent it" -- Alan Kay
>>>> On Tue, Jan 5, 2010 at 5:46 AM, Richard Hirsch
>>>> <>wrote:
>>>>> Comments inline
>>>>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
>>>>> <> wrote:
>>>>>> In an effort to hopefully once and for all settle the question of
>>>> what
>>>>> type of integration with 3rd party application systems ESME would be
>>>> best
>>>>> suited for I want to capture the essence of a Twitter conversation
>>>> that
>>>>> happened today. Basically, it was started by @dahowlett in reference
>>>> to
>>>>> Thingamy. Dennis said that "#esme's true power is the NetWeaver
>>>> integration
>>>>> so @sig's work has significance". I have not seen the Thingamy/ESME
>>>> work,
>>>>> but I felt compelled to again bring up an old question: What can
>>>>> micro-blogging utilities like ESME really do to make ERP systems
>>>> "better" ?
>>>>> For me, this was not a technical integration question, but rather a
>>>>> fundamental question that can easily be applied to SFDC Chatter as
>>>> well.
>>>>>> The way I look at ERP systems is that a business process is broken
>>>> up
>>>>> into multiple steps that can each be executed with a specific
>>>> transaction.
>>>>> Most of these transactions can also be executed through some remote
>>>>> invocation interface (WS*, RFC or whatever) which would apparently be
>>>> used
>>>>> by ESME. People with specific roles using the ERP system would enter
>>>> those
>>>>> transactions, either triggered by an outside event (Goods Receipt,
>>>> Create
>>>>> Sales Order, Shipment) or prompted through some workflow in the
>>>> system. In a
>>>>> way, the system is designed and implemented so that it's clear when
>>>> who has
>>>>> to do what. The level of success of an ERP implementation depends on
>>>> the
>>>>> degree of automation that can be accomplished.
>>>>> <dlh>
>>>>> I think the question here is whether such "pure" processes actually
>>>>> exist or whether they are rather the exception to the rule. I think
>>>>> that there is more likely to be some sort of a hybrid process whether
>>>>> the foundation is a ERP-type process but certain iterations contain
>>>>> steps (usually collaborative in nature) that take place outside this
>>>>> model. Of course, you could try and capture such steps in the ERP
>>>>> model itself but then the model would be in a constant state of
>>>>> change.  The question is how do you expand the definition of the
>>>>> process to include such steps. Process rigidity in this case isn't
>>>>> helpful.
>>>>> </dlh>
>>>>>> Typically, ERP systems work best with what Sig lovingly calls
>>>> "Easily
>>>>> Repeatable Processes". An event happens, an appropriate transaction is
>>>>> executed, the ERP systems determines specific follow-up action that
>>>> either
>>>>> need to be executed manually by a person or a follow-up business
>>>> process is
>>>>> triggered automatically. Even in the case of customer support, where
>>>> Twitter
>>>>> is said to have some enterprise-level success, the CRM system will
>>>> make sure
>>>>> that a customer support specialist will give a customer a callback,
>>>> and if
>>>>> that hasn't happened within a certain time period, a different
>>>> customer
>>>>> service agent would be found. Essentially, it is all about
>>>> predictability.
>>>>>> Obviously, predictability only works as long as the real world works
>>>> in
>>>>> synchronisity with the inner workings of the ERP system. In many cases
>>>> it is
>>>>> not; that's when people pick up phones or maybe use some internal
>>>>> micro-blogging utility. Somebody will say, "Hey, I've got this
>>>> customer who
>>>>> presents me with this issue, anybody out there who can help ?".
>>>>>> However, what kind of "integration" is required to make this happen
>>>> ? The
>>>>> demos that were shown at Demo Jam essentially published an event with
>>>> a text
>>>>> on ESME, but isn't in reality just somebody typing in a question ?
>>>> Would
>>>>> ESME really trigger a business process through some remote invocation
>>>>> interface, like creating a PO, or would the ESME user, once a question
>>>> was
>>>>> satisfactorily answered by their network, rather turn to their ERP
>>>> screen
>>>>> and enter whatever they have learned ?
>>>>> <dlh>
>>>>> I think we are talking about two distinct but related use cases.  The
>>>>> demos at Demo Jam should ERP systems joining microblogging
>>>>> conversations. These conversations were "not", however, placed in a
>>>>> process context. What Sig is doing is placing the messages in a
>>>>> process context. I'm performing a task and I can see the messages that
>>>>> relate to that task. In Sig's use case, machine-originating messages
>>>>> might not make sense primarily because there are no "machines/systems"
>>>>> involved in the task.
>>>>> </dlh>
>>>>>> So, essentially what I'm saying is that I don't think an ESME
>>>> integration
>>>>> with ERP will be of significant value. ESME as a standalone tool may
>>>> very
>>>>> well be, but then what is its sweet spot compared to Twitter or
>>>> compared to
>>>>> commercial tools for enterprise-level deployment that are already on
>>>> the
>>>>> market ?
>>>>> <dlh>
>>>>> I think the ERP integration might focus more on the ERP systems
>>>>> posting their status messages to the microblogging systems. This
>>>>> information would first of all mean less work for human users. Instead
>>>>> of a knowledge worker informing his team members that a new sales
>>>>> opportunity has been created, the ERP system could do this. This
>>>>> machine-created message could also be sent via an email but this would
>>>>> be counter-productive. The true value would the mixture of human-based
>>>>> and machine-based messages creating a more comprehensive information
>>>>> context. Via ESME's actions which act as filters and the fact that
>>>>> users decide which machines / users to follow, the efficiency in
>>>>> processing the information increases.  You could then make this
>>>>> information available to ERP users in context.  If you are working on
>>>>> an opportunity then you might see messages regarding the customer in
>>>>> question. The real challenge will be the identification of the context
>>>>> and the tagging of messages so that they are associated with a
>>>>> particular context.
>>>>> </dlh>
>>>>>> The Thingamy thing caught my attention because the way I understand
>>>> it,
>>>>> what Sig has developed is precisely for those "Barely Repeatable
>>>> Processes",
>>>>> meaning things that can't be executed like A-B-C, but where the
>>>> activities
>>>>> of people need to be coordinated in a unpredictable way in order to
>>>> resolve
>>>>> a specific situation. So, when exceptions become the norm, an ERP
>>>> system is
>>>>> not really well suited, and an BRP system - however this is going to
>>>> look
>>>>> like - will take over. Intuitively, for these kind of things ESME will
>>>> be
>>>>> better suited, and from what I was able to follow on the list, an ESME
>>>>> conversation is actually associated with the specific context of that
>>>> BRP.
>>>>> That makes sense to me.
>>>>>> I read Sig's latest blog where he compared 12sprints and Chatter
>>>> with
>>>>> "Sending email through Word" which sounds a little grandiose to me. I
>>>> don't
>>>>> know Chatter yet, but 12sprints seemed like it could show the future
>>>> of
>>>>> applications, where decisions need to be made in an unpredictable way
>>>> with a
>>>>> set of people, and how a system would support that. This could also be
>>>>> augmented with business intelligence and of course also
>>>> micro-blogging. But
>>>>> in this case, the system is designed to work with Barely Repeatable
>>>>> Processes, and associating the conversation in ESME with the BRP
>>>> context or
>>>>> 12sprint task could lead to interesting applications.
>>>>>> But that's all very different than trying to kind of artificially
>>>>> integrate ESME with a system that assumes that the world works like
>>>> A-B-C.
>>>>> What I believe is for ESME to *really* work efficiently, is to design
>>>>> application systems that deal better with unpredictable situations,
>>>> and then
>>>>> make best use of ESME capabilties, instead of trying to superimpose
>>>> ESME on
>>>>> the A-B-C world of today's ERP. Yes, it's technically possible, but
>>>> whether
>>>>> it makes sense is a different story.
>>>>>> All that I'm trying to establish is what needs to be built for the
>>>> ESME
>>>>> engine in order to really be useful and different, and on the other
>>>> side
>>>>> understand how application systems should look like that better deal
>>>> with
>>>>> the unpredictable processes where ESME shines. I briefly looked at the
>>>>> Chatter announcement, and SFDC was also mentioning better integration
>>>> with
>>>>> application data or business intelligence, but I wasn't able to read
>>>> more
>>>>> from it.
>>>>>> Anyway, hope this is helpful, and we can start a discussion from
>>>> I
>>>>> know you had some use case discussions already, but I really could not
>>>> find
>>>>> any specific examples.
>>>>>> Best,
>>>>>> Michael

View raw message