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