Hi Skip Is the solution you are working on tapping into the existing database? If that is correct, it appears to be the way to go. Java is entirely different to Java script, what's more entire programs such as Open Office Org, Compiere and many more are written in Java, I feel a small module that concentrates on area that is obviously missing in OFBiz at present written in Java is not a concern. The concern is not making available an intrinsic function that most ERP operations incorporate is something to be concerned about.
I have just been browsing previous threads on CRM and it seems the demand is high. If your solution is able to integrate with the current dbase framework well, I feel this would be the next natural progression to OFBiz's evolution. Keep up your good work, and hopefully you will receive the support your efforts deserve. Cheers Phil > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > Sent: Thursday, 4 October 2007 2:54 PM > To: [email protected] > Subject: RE: CRM - Customer Relationship Management facilities in OFBiz > > Johathon > > Hmmm, you've almost got me convinced to give this up. So convinced in > fact > that I am gonna forward this email on to my current customer and get his > reaction. It's well thought out and you obviously spent a great deal of > time thinking about it and I thank you for it lavishly. > > Still, I have these arguments in favor to offer: > > 1. Backoffice personell are expensive. Even saving them 10 minutes > (that's > 10 seconds a transaction or less) a day translates to $3000 a year even > for > the lower paid ones, and this is per-person. I have timed myself using > the > Ofbiz "Order Entry" screen to enter a two item sale and the desktop Java > based order entry application I am currently finishing. The results? It > takes 20 seconds less on simple orders (Finalize with defaults) and 45 > seconds less with complicated ones using the Java app. And, all my code is > using the stock Ofbiz services to do the real work so it's fairly simple > to > write. The difference in time is because I can change the control having > the input focus intelligently and I don't have to wait for brower repaints > between atomic operations. A fast operator can go as fast as they can > type. > I know I can achieve the same effect with ajax, but if I have to write > these > apps from scratch anyway, why not take advantage of the extra horsepower > and > compiled Java? By the way, the nearly finished Java app is surprisingly > small. With Ofbiz code doing the grunt work, I can spend my time making > the > GUI fast, easy, and smart. > > 2. "Also, the move forward is to "dumb down" the client terminals (cheap > to > deploy, scalable)." I would partially disagree with this although it is > repeated a lot. This was certainly true a couple of years ago, but > lately, > we are heading back in the other direction. Witness the move to Ajax > backed > Javascript as an example. It takes almost no time to code a GUI with > Netbeans. No such tools currently exist (that I know of) for Ajax backed > apps. Also. go look at the sales stats for Dell and HP and you will see > that the majority of their sales are to business and it shows no signs of > slowing (although it is not increasing as fast as it was a few years ago). > > 3. "Even if the client terminals just happen to be blazing fast enough > for > graphics-intensive work...". Graphics-intensive capability is more a > factor > of the video card than the CPU. EVERY desktop I see with an A/R or A/P > person in the chair is capable of running Ofbiz, Word and Excel at the > same > time. On my test box, I have Ofbiz running with Netbeans, Visual Studio, > Gaim, and Outlook and it's no smoker and joker. > > 4. "In production, servers aren't hit all the time. There are peak > periods, > and there are lull periods." If the brains are on the user's desktop, > there > are no lull or peaks at any time (and no associated aggravation). Their > work is never interrupted or slowed (assuming the database server is not > overloaded.) > > > 5. "Those folks writing the "offloading algorithms" won't know how > fast/slow my computer is." Gads Jonathon, I couldnt agree more. I get > aggravated daily waiting for Javascript intensive web pages to download. > However, I am not running javascript, but blazingly fast compiled Java. > If > the user's machine doesnt have the guts, I wouldn't install Ofbiz on it. > They can use a browser to access the same funcionality. > > > Hmmm, now I've almost convinced myself to carry on. :) > > Cheers > > Skip > > > -----Original Message----- > From: Jonathon -- Improov [mailto:[EMAIL PROTECTED] > Sent: Wednesday, October 03, 2007 7:43 PM > To: [email protected] > Subject: Re: CRM - Customer Relationship Management facilities in OFBiz > > > > You might be surprised by how expensive such a solution would be to > > create/maintain/deploy and how little it will help on server resources. > > I have many clients wanting to move away from that distributed (client > codes) model to the > centralized (server codes) model. Yes, it is proving to be expensive. > Kinda > "tried and tested" to > be expensive, actually. > > "Create/maintain/deploy" are all human activities. Will be inordinately > expensive to create > artificial intelligence to do all that. In general (with our current > state-of-the-art of AI), it > is cheaper to simply upgrade the server hardware. Yes, computer hardware > speed improvement may be > slowing down now (used to be doubling every 1.5 years?). But there will > surely be something new > coming up (quantum computers, multi-state logic units, etc), unless we're > suddenly hit by an > epidemic that halves human intelligence every 1.5 years. (Or I infect all > you guys with my stupidity). > > Also, the move forward is to "dumb down" the client terminals (cheap to > deploy, scalable). Even if > the client terminals just happen to be blazing fast enough for > graphics-intensive work, perhaps > those terminals' users' job scope is to do graphics-intensive work on a > regular basis? Putting a > part of OFBiz into those machines will compromise the efficiency of their > graphics-intensive work. > > As for "You might be surprised", I'm ALWAYS surprised when it comes to > doing > optimization work! > Optimization needs are very hard to calculate and predict by hand. Rather > than spend weeks using > complex maths and theories to predict (presume, rather) bottle-necks, it's > easier to spend a > couple of hours to do an actual measurement of computation speeds. > > > You might also be surprised by how capable servers are of handling > > concurrent load, how different performance tends to be in a development > > versus production environment, and for certain things how easy it is to > > tune them once the slowest stuff has been identified. > > In production, servers aren't hit all the time. There are peak periods, > and > there are lull > periods. To handle such cases, clustering and load-balancing is the usual > practice. The diff > between clustering servers and using smart client terminals, both being > distributed models, is > this... it's easier to monitor and tune a few servers than to do so for > hundreds of client terminals. > > Also, consider how irritating javascript is getting to be, those that try > to > offload huge amounts > of servers' workloads into our personal computers. Those folks writing the > "offloading algorithms" > won't know how fast/slow my computer is, and could render my computer > completely useless by > overloading it. > > But before going into clustering, it is often adequate to spot the > bottle-necks in a single > server, and optimize just those areas. That'll help the OFBiz framework > and > help the OFBiz > community too. > > For all the optimization smarts we have, I must say that I had > over-optimized before in my career. > In business, over-optimizing a system isn't "passing with flying colors", > but actually translates > into a loss. While it is great to "push the envelope", it'll help in > thesis > writing more than in > business. Study the bottle-necks in production settings, and fix just > those. > > Still, please feel free to over-optimize the OFBiz framework! That's a > different scenario. Huge ROI. > > Jonathon > > David E Jones wrote: > > > > You might be surprised by how expensive such a solution would be to > > create/maintain/deploy and how little it will help on server resources. > > You might also be surprised by how capable servers are of handling > > concurrent load, how different performance tends to be in a development > > versus production environment, and for certain things how easy it is to > > tune them once the slowest stuff has been identified. > > > > -David > > > > > > On Oct 3, 2007, at 1:05 PM, [EMAIL PROTECTED] wrote: > > > >> David > >> > >> This issue here to me asset utilization. In a typical mid-sized > company, > >> there are dozens or hundreds of desktop computers that their user use > >> to do > >> their daily work. If the user is using a browser to access logic on > >> one of > >> Ofbiz servers, the desktop is under-utilized. By tying in a desktop > >> application to Ofbiz (i.e. running an entity engine on the desktop > >> tied to > >> the same database as the main ofbiz servers and running xml setups > >> identical > >> to the servers), that workload is performed on the users desktop and > >> not on > >> the main ofbiz servers thereby freeing the server for functionality > that > >> REQUIRES browser based access. > >> > >> This does not in any way supplant Ofbiz, it enhances it by > >> distributing the > >> workload and giving the clerical user a better amd more responsive > >> experience. > >> > >> As some examples, my recent testing of the sales order functionality > >> shows > >> that it takes ~ 200 msecs to complete the "userLogin" service or 120 > >> msecs > >> to complete "calculateProductPrice" (these numbers are from the ofbiz > log > >> file on a fairly fast machine with lots of debug output). If this is > all > >> done on the main ofbiz servers about 5 of the former and 10 of the > >> later can > >> be done simultaneously to maintain a reasonable lag time. If the load > is > >> spread out among say 8 desktops and 2 browser accesses, everyone has a > >> really good experience. > >> > >> The only drawback to this all is that if the server configuration > >> changes, > >> the desktops must be patched as well. In practice, that is not a big > >> issue. > >> > >> So, it makes great sense to me to write desktop applications for common > >> backoffice functions. > >> > >> I am currently working on a suite of such applications, hence my > >> interest in > >> BJs SWT based CRM. > >> > >> Skip > >> > >> -----Original Message----- > >> From: David E Jones [mailto:[EMAIL PROTECTED] > >> Sent: Wednesday, October 03, 2007 11:12 AM > >> To: [email protected] > >> Subject: Re: CRM - Customer Relationship Management facilities in OFBiz > >> > >> > >> > >> I'm not sure where this thread is leading or how it's related to > >> OFBiz... > >> > >> In any case, there is CRM functionality in OFBiz. The first step > >> would be defining in a little more detail what you mean by "CRM" > >> since that means very different things in different companies. OFBiz > >> does offer a single view into customer interactions including web > >> site visits, phone/email/in-person/etc communications, requests, > >> quotes, orders, shipments, invoices, payments, balance accounts, > >> projects, calendar events, and many other things. You can also > >> classify parties for marketing and sales, and do things like > >> marketing campaigns including reference codes via email, snail mail, > >> whatever. > >> > >> If you're looking for simple desktop contact management something > >> like ACT or even salesforce.com would be better. If you're looking > >> for enterprise CRM (especially a business or industry specific > >> incarnation of such) then OFBiz a great basis for the effort. > >> > >> -David > >> > >> > >> On Oct 3, 2007, at 11:07 AM, [EMAIL PROTECTED] wrote: > >> > >>> I'd like to see the SWT code as it is. To heck with translating it > >>> to use > >>> web based widgets. > >>> > >>> I gotta set up a web site soon to hold code like this. > >>> > >>> Skip > >>> > >>> > >>> -----Original Message----- > >>> From: BJ Freeman [mailto:[EMAIL PROTECTED] > >>> Sent: Wednesday, October 03, 2007 3:06 AM > >>> To: [email protected] > >>> Subject: Re: CRM - Customer Relationship Management facilities in > >>> OFBiz > >>> > >>> > >>> basically yes. > >>> the tool i used added some classes to better manage things. > >>> http://www.elance.com/p/? > >>> q=eolproviderprofile&view_person=BJFreeman&catid=10 > >>> 182#tab=1 > >>> click on Java CRM > >>> > >>> [EMAIL PROTECTED] sent the following on 10/2/2007 8:55 PM: > >>>> BJ > >>>> > >>>> SWT as in Eclipse SWT? > >>>> > >>>> Skip > >>>> > >>>> -----Original Message----- > >>>> From: BJ Freeman [mailto:[EMAIL PROTECTED] > >>>> Sent: Tuesday, October 02, 2007 8:26 PM > >>>> To: [email protected] > >>>> Subject: Re: CRM - Customer Relationship Management facilities in > >>>> OFBiz > >>>> > >>>> > >>>> there at least two efforts going that i know of. > >>>> the data model pretty much has all that you need. > >>>> Si's implementation does not totally integrate with the current data > >>>> storage. it is built on ofbiz but is supported under opentaps. > >>>> Mine is something I am bringing over from Java SWT and SQL db. > >>>> Once I figure out how to show the UI I want in widgets I will release > >>>> it. Currently for my clients I use a java sWT that connects to ofbiz. > >>>> It is built entirely within the current ofbiz datamodel. > >>>> as soon as I get some irons of the fire will focus on it more > >>>> > >>>> > >>>> > >>>> Philip Laing sent the following on 10/2/2007 7:36 PM: > >>>>> Thanks for your input relating my previous questions, I am > >>>>> interested in > >>>>> implementing some sort of Helpdesk/CRM system and I am interested > >>>>> in what > >>>>> facilities OFBiz already has > >>>>> > >>>>> Thanks > >>>>> Phil > >>>>> > >>>>> > >>>>> > >>>>> > >>>> > >>>> > >>>> > >>>> > >>> > >> > >> > >
