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 <[email protected]>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 > > <[email protected]> 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:[email protected]] > >> Sent: Wednesday, Jan 06, 2010 3:11 AM > >> To: [email protected] > >> 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 > >> <[email protected]>wrote: > >> > >>> Comments inline > >>> > >>> On Tue, Jan 5, 2010 at 2:16 AM, Bechauf, Michael > >>> <[email protected]> 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 > >>>> > >>> > >> > >
