incubator-esme-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Markus Kohler <markus.koh...@gmail.com>
Subject Re: ESME Process Integration
Date Thu, 07 Jan 2010 08:13:44 GMT
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 <yojibee@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
> > <michael.bechauf@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
> >> <hirsch.dick@gmail.com>wrote:
> >>
> >>> Comments inline
> >>>
> >>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael
> >>> <michael.bechauf@sap.com> wrote:
> >>>> In an effort to hopefully once and for all settle the question of
> >> what
> >>> type of integration with 3rd party application systems ESME would be
> >> best
> >>> suited for I want to capture the essence of a Twitter conversation
> >> that
> >>> happened today. Basically, it was started by @dahowlett in reference
> >> to
> >>> Thingamy. Dennis said that "#esme's true power is the NetWeaver
> >> integration
> >>> so @sig's work has significance". I have not seen the Thingamy/ESME
> >> work,
> >>> but I felt compelled to again bring up an old question: What can
> >>> micro-blogging utilities like ESME really do to make ERP systems
> >> "better" ?
> >>> For me, this was not a technical integration question, but rather a
> >>> fundamental question that can easily be applied to SFDC Chatter as
> >> well.
> >>>>
> >>>> The way I look at ERP systems is that a business process is broken
> >> up
> >>> into multiple steps that can each be executed with a specific
> >> transaction.
> >>> Most of these transactions can also be executed through some remote
> >>> invocation interface (WS*, RFC or whatever) which would apparently be
> >> used
> >>> by ESME. People with specific roles using the ERP system would enter
> >> those
> >>> transactions, either triggered by an outside event (Goods Receipt,
> >> Create
> >>> Sales Order, Shipment) or prompted through some workflow in the
> >> system. In a
> >>> way, the system is designed and implemented so that it's clear when
> >> who has
> >>> to do what. The level of success of an ERP implementation depends on
> >> the
> >>> degree of automation that can be accomplished.
> >>>>
> >>> <dlh>
> >>> I think the question here is whether such "pure" processes actually
> >>> exist or whether they are rather the exception to the rule. I think
> >>> that there is more likely to be some sort of a hybrid process whether
> >>> the foundation is a ERP-type process but certain iterations contain
> >>> steps (usually collaborative in nature) that take place outside this
> >>> model. Of course, you could try and capture such steps in the ERP
> >>> model itself but then the model would be in a constant state of
> >>> change.  The question is how do you expand the definition of the
> >>> process to include such steps. Process rigidity in this case isn't
> >>> helpful.
> >>> </dlh>
> >>>
> >>>> Typically, ERP systems work best with what Sig lovingly calls
> >> "Easily
> >>> Repeatable Processes". An event happens, an appropriate transaction is
> >>> executed, the ERP systems determines specific follow-up action that
> >> either
> >>> need to be executed manually by a person or a follow-up business
> >> process is
> >>> triggered automatically. Even in the case of customer support, where
> >> Twitter
> >>> is said to have some enterprise-level success, the CRM system will
> >> make sure
> >>> that a customer support specialist will give a customer a callback,
> >> and if
> >>> that hasn't happened within a certain time period, a different
> >> customer
> >>> service agent would be found. Essentially, it is all about
> >> predictability.
> >>>>
> >>>> Obviously, predictability only works as long as the real world works
> >> in
> >>> synchronisity with the inner workings of the ERP system. In many cases
> >> it is
> >>> not; that's when people pick up phones or maybe use some internal
> >>> micro-blogging utility. Somebody will say, "Hey, I've got this
> >> customer who
> >>> presents me with this issue, anybody out there who can help ?".
> >>>>
> >>>> However, what kind of "integration" is required to make this happen
> >> ? The
> >>> demos that were shown at Demo Jam essentially published an event with
> >> a text
> >>> on ESME, but isn't in reality just somebody typing in a question ?
> >> Would
> >>> ESME really trigger a business process through some remote invocation
> >>> interface, like creating a PO, or would the ESME user, once a question
> >> was
> >>> satisfactorily answered by their network, rather turn to their ERP
> >> screen
> >>> and enter whatever they have learned ?
> >>>>
> >>> <dlh>
> >>> I think we are talking about two distinct but related use cases.  The
> >>> demos at Demo Jam should ERP systems joining microblogging
> >>> conversations. These conversations were "not", however, placed in a
> >>> process context. What Sig is doing is placing the messages in a
> >>> process context. I'm performing a task and I can see the messages that
> >>> relate to that task. In Sig's use case, machine-originating messages
> >>> might not make sense primarily because there are no "machines/systems"
> >>> involved in the task.
> >>> </dlh>
> >>>
> >>>> So, essentially what I'm saying is that I don't think an ESME
> >> integration
> >>> with ERP will be of significant value. ESME as a standalone tool may
> >> very
> >>> well be, but then what is its sweet spot compared to Twitter or
> >> compared to
> >>> commercial tools for enterprise-level deployment that are already on
> >> the
> >>> market ?
> >>> <dlh>
> >>> I think the ERP integration might focus more on the ERP systems
> >>> posting their status messages to the microblogging systems. This
> >>> information would first of all mean less work for human users. Instead
> >>> of a knowledge worker informing his team members that a new sales
> >>> opportunity has been created, the ERP system could do this. This
> >>> machine-created message could also be sent via an email but this would
> >>> be counter-productive. The true value would the mixture of human-based
> >>> and machine-based messages creating a more comprehensive information
> >>> context. Via ESME's actions which act as filters and the fact that
> >>> users decide which machines / users to follow, the efficiency in
> >>> processing the information increases.  You could then make this
> >>> information available to ERP users in context.  If you are working on
> >>> an opportunity then you might see messages regarding the customer in
> >>> question. The real challenge will be the identification of the context
> >>> and the tagging of messages so that they are associated with a
> >>> particular context.
> >>> </dlh>
> >>>>
> >>>> The Thingamy thing caught my attention because the way I understand
> >> it,
> >>> what Sig has developed is precisely for those "Barely Repeatable
> >> Processes",
> >>> meaning things that can't be executed like A-B-C, but where the
> >> activities
> >>> of people need to be coordinated in a unpredictable way in order to
> >> resolve
> >>> a specific situation. So, when exceptions become the norm, an ERP
> >> system is
> >>> not really well suited, and an BRP system - however this is going to
> >> look
> >>> like - will take over. Intuitively, for these kind of things ESME will
> >> be
> >>> better suited, and from what I was able to follow on the list, an ESME
> >>> conversation is actually associated with the specific context of that
> >> BRP.
> >>> That makes sense to me.
> >>>>
> >>>> I read Sig's latest blog where he compared 12sprints and Chatter
> >> with
> >>> "Sending email through Word" which sounds a little grandiose to me. I
> >> don't
> >>> know Chatter yet, but 12sprints seemed like it could show the future
> >> of
> >>> applications, where decisions need to be made in an unpredictable way
> >> with a
> >>> set of people, and how a system would support that. This could also be
> >>> augmented with business intelligence and of course also
> >> micro-blogging. But
> >>> in this case, the system is designed to work with Barely Repeatable
> >>> Processes, and associating the conversation in ESME with the BRP
> >> context or
> >>> 12sprint task could lead to interesting applications.
> >>>>
> >>>> But that's all very different than trying to kind of artificially
> >>> integrate ESME with a system that assumes that the world works like
> >> A-B-C.
> >>> What I believe is for ESME to *really* work efficiently, is to design
> >>> application systems that deal better with unpredictable situations,
> >> and then
> >>> make best use of ESME capabilties, instead of trying to superimpose
> >> ESME on
> >>> the A-B-C world of today's ERP. Yes, it's technically possible, but
> >> whether
> >>> it makes sense is a different story.
> >>>>
> >>>> All that I'm trying to establish is what needs to be built for the
> >> ESME
> >>> engine in order to really be useful and different, and on the other
> >> side
> >>> understand how application systems should look like that better deal
> >> with
> >>> the unpredictable processes where ESME shines. I briefly looked at the
> >>> Chatter announcement, and SFDC was also mentioning better integration
> >> with
> >>> application data or business intelligence, but I wasn't able to read
> >> more
> >>> from it.
> >>>>
> >>>> Anyway, hope this is helpful, and we can start a discussion from it.
> >> I
> >>> know you had some use case discussions already, but I really could not
> >> find
> >>> any specific examples.
> >>>>
> >>>> Best,
> >>>> Michael
> >>>>
> >>>
> >>
>
>

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