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