I'd like to add my thanks for sharing this Nick, it's really great feedback and a good case study too.
-David On Mar 2, 2010, at 11:50 AM, Nick Rosser wrote: > I'll group together a number of q&a in one general response: > > is it a common thing to have a Microsoft-IIS/6.0 in > front of Tomcat rather than Apache? > NICK: dunno, this was dictated by the client > > Is the site behavior pretty good with a larger set of products? Now I > can only see arround 140 products there. > NICK: the back-end ERP is much more active, processing 5000 orders per day; > 140 products on the web site reflects a subset of their product line. ERP is > performing well, with ~100 customer service users. > > How many developers did it take? > NICK: 3 for the ERP system (lots of customization; close to 1 year by the > time we were fully live); 1-2 for the eCommerce site (approx 6 months) > > What was their skill set? > NICK: Senior J2EE, experienced in the delivery of web based business > software > > I'd be interested in knowing more about specific requirements for beginner > documentation and/or training. If you have time, could you post some more > information about this? > NICK: tough question. I think we generally struggled with implementation > concepts that we knew would be challenging. How do you properly extend > existing entities? What's the best practice for services etc? And the > classic struggle of not fully understanding what OFBiz does ootb and coding > around it, only to find out that a simple tweak / configuration would have > worked (or was close). This may simply be a nature of the sheer size of > OFBiz and generally not appreciating all the features, we are much better at > looking for stuff before we code it. This gets back to a lack of knowledge > available, particularly outside of simple issues, that we would have > appreciated greatly during our implementation. > > Nick > > > -----Original Message----- > From: Florin Popa [mailto:[email protected]] > Sent: Tuesday, March 02, 2010 10:38 AM > To: [email protected] > Subject: Re: Salmon LLC: OFBiz eCommerce Site Goes Live > > Hello all, > > One question please: is it a common thing to have a Microsoft-IIS/6.0 in > front of Tomcat rather than Apache? > > Is the site behavior pretty good with a larger set of products? Now I > can only see arround 140 products there. > > thanks, > Florin >> Great post Nick - and thanks for being one of those vendors who is giving > back to the community - especially with this level of detail. We enjoyed > working with you and are stoked to see that thru your hard work and patience > with the community you were able to achieve the level of internal adoption > that many people strive for, but are unsuccessful. The points you lay out > here are great for everyone to hear - and I think really hit the nail on the > head as far as the difficulty of less technical, and even less resourced > companies face. >> >> That being said, I believe that there are commercial entities in the OFBiz > world with the right processes, enough firepower (read resources) and > expertise to ensure success in your project. This may not have been the > case when you first started, but I think that has changed. >> >> This does not mean that any one entity has to run the entire project - > like say a JBoss or a MySQL - but there is really not much difference in > paying for MySQL support services than paying the high tiered support > offerings with OFBiz. You just have to choose the right group and find the > right individuals to help you along - and my personal opinion is that they > are out there. >> >> Sorry to digress - now, back to your original point, there are a ton of > things that the community can improve upon that you mentioned below. Can > you put these together up on the Wiki, much like we've discussed in other > threads, so that we can begin to track our progress? I'd like to see the > documentation angle continue to get worked thru (technical and end-user) - > possibly moving some of the documentation that I know that people are > creating internally - out to a place where everyone can appreciate it > without having to pay additional money. >> >> We need to come together to make this happen - and it will only get there > if all of the corporate entities out there begin to or continue to support > the community by donating a ton of time into documentation, mailing list > responses, enhanced applications. Thanks again Nick - this is great stuff. >> >> Cheers, >> Ruppert >> -- >> Tim Ruppert >> HotWax Media >> http://www.hotwaxmedia.com >> >> o:801.649.6594 >> f:801.649.6595 >> >> On Mar 2, 2010, at 7:08 AM, Nick Rosser wrote: >> >> >>> All, >>> >>> >>> >>> Just a note to let you know that we recently released an eCommerce site. >>> Check out www.purityproducts.com. >>> >>> >>> >>> Launched a couple of weeks ago, to very little fanfare, this is a > complete >>> replacement of an existing site, with no upgrades to the UI or basic >>> eCommerce structure. A straight conversion to OFBiz as a platform change > to >>> allow for future changes, enhancements and growth. >>> >>> >>> >>> This is on the back of a very successful ERP release last year for the > same >>> customer, our first OFBiz implementation. Challenging, to say the least, > but >>> very successful in terms of laying the same platform for the back-end >>> processes, with a specific focus on a very intense and customized CSR > layer. >>> >>> >>> >>> >>> Of interest to some, particularly given recent posts about > community-driven >>> OFBiz and various discussions about the lack of process and documentation > I >>> thought I'd share our experience of using OFBiz during the last 2 years. >>> First a little background on Salmon LLC that I think is relevant: >>> >>> >>> >>> Our background: >>> >>> >>> >>> * we have released open-source framework software in the past >>> >>> * we have developed many custom J2EE solutions >>> >>> * we have adopted other ERP solutions prior to OFBiz (Compiere / >>> Adempiere - before bailing because it was not really open-source) >>> >>> * we have adopted other packaged solutions in other business areas >>> >>> * we're a technical company, with business savvy >>> >>> * we can figure stuff out >>> >>> >>> >>> OFBiz, the good: >>> >>> >>> >>> * nice architecture, we were generally impressed with the service >>> based approach >>> >>> * the services work. For us, OFBiz is a starting point, the > services >>> are available and they work! >>> >>> * the community support is amazing; the commitment of everyone >>> monitoring this thread and providing responses is commendable >>> >>> >>> >>> OFBiz, the not so good: >>> >>> >>> >>> * UI ootb: not the best. BUT, we understand the objective > (framework) >>> and we understand the ERP domain to realize that OFBiz is a starting > point; >>> and a pretty good one >>> >>> * architecture: next level of concepts was harder to grasp, as you > dig >>> more into the code the more confusing it can get; the lack of good coding >>> standards can make it very confusing as to what exactly is the best > practice >>> (particularly when looking at "older" code) >>> >>> * the devil is in the details, and there are a lot of them; be >>> prepared to make mistakes, having to figure stuff out for yourself, lots > of >>> trial and error >>> >>> * community support: when it gets a little tricky it's much more >>> difficult to explain the issue and get a good community response. > Perfectly >>> understandable but this is where the risk comes into play . we spent >>> countless hours on some very tricky payment processing issues (credit, > card, >>> returns, refunds) and inventory processing >>> >>> * what a pity that the documentation cannot encapsulate all the >>> knowledge from the user-group. Yes, I know we can search through email >>> postings. Yes, I know that the documentation is improving. But there are >>> still problems in this area, perhaps I can share one specific example: >>> >>> >>> >>> One specific example: >>> >>> >>> >>> * Product A is put with product B in order to offer product C >>> >>> * Product A and B may (or may not) have inventory associated >>> >>> * When assembled into C, this can also carry inventory >>> >>> * When the item is returned, it may be put back into inventory as >>> product C, OR may be disassembled into products A and B >>> >>> * Fairly straight forward and not uncommon, and I'm sure that OFBiz >>> can handle this but we couldn't find ANY document that would clearly > explain >>> product configuration and it's impact on other areas of the ERP solution >>> >>> * I remember being amazed that a thorough product configuration > guide >>> was not available that would explain all the product attributes and a > high >>> level description of the impact throughout OFBiz. What's more important > is >>> that if you guess wrong then you can cause all sorts of problems >>> >>> * BTW: since this was a while ago I did review the current >>> documentation, the only item I saw that described setting up a product > was >>> the "Business Setup Guide (for users)", the content for Product Setup is >>> pasted below. The best looking resource is I understand that there may be >>> more documentation available that is more appropriate . BUT, if I'm new > to >>> OFBiz and cannot find something decent after a few minutes then I'll move > on >>> very quickly >>> >>> >>> >>> So, where are we now? Well, I think we can safely say that we are OFBiz >>> adopters, it took much sweat and tears to get to where we are now but I >>> consider my team to be well versed, near expert, with ERP and eCommerce >>> implementations using OFBiz. I'm very comfortable offering this service > to >>> our clients, and very comfortable with our ability to deliver scalable > ERP >>> and eCommerce solutions. >>> >>> >>> >>> HOWEVER, our first implementation was very stressful. And in hindsight, > very >>> risky. Remember that ERP solutions are "bet your business" propositions . > we >>> cannot make mistakes. If we do, we jeopardize our business and the > business >>> of our clients. In our first implementation we are processing 5000 orders >>> per day. For the first 3-4 weeks of go-live the background jobs were > taking >>> more than 24 hours to run (build orders from a recurring order list, > process >>> orders for fulfillment, manage incoming inventory, process credit card >>> transactions, PLUS any new orders for that day). Saturdays and Sundays > were >>> used to make-up the time while we figured out solutions! As you can > imagine >>> we had a very stressful time working with our client, tuning our > processes >>> and working with our client to keep OFBiz as the ERP solution. I'm happy > to >>> report that everything is perfectly fine now, but this is not the way we >>> like to do business. >>> >>> >>> >>> I consider my team to be extremely committed, technically excellent and >>> business savvy. I wonder how small companies or small integrators adopt >>> OFBiz without these resources? >>> >>> >>> >>> Conclusion: >>> >>> >>> >>> * As I re-read my comments and gather my thoughts it basically > boils >>> down to documentation >>> >>> * We did not have the luxury of being able to hire a certified > "guru" >>> to help out (we did have David Jones spend a week with us initially and > used >>> a couple of committers for specific tasks) but there is generally no >>> "corporate" option to ensure success >>> >>> * Best practices / coding techniques etc are exposed because of the >>> open-source nature of OFBiz; it's probably better written than other >>> proprietary software; this is not an essential issue >>> >>> * So everything hinges on community support. Lots of it is required >>> for early adopters and we see these postings every day. For folks that > have >>> moved into more complex areas (like we were 12 months ago), the community >>> support is not enough-the issues are too complex >>> >>> * As an open-source project, without formal corporate backing, the > key >>> is documentation, not just technical. And I suspect that we need more > than >>> Oracle and SAP because of the community nature of the project >>> >>> >>> >>> Nick Rosser >>> >>> Salmon LLC >>> >>> >>> >>> >>> >>> >>> Product Setup >>> >>> >>> Congratulations, you are finally to the point where you can start setting > up >>> products.... >>> >>> To create a Product follow a process similar to those described for other >>> things, like Categories. >>> >>> 1. Go to the main page of the Catalog Manager and click on the "Create >>> New Product" link. >>> 2. If you fill in an ID it will make sure that ID is valid, and if so >>> it will use that one. If you specify no ID it will generate one. >>> 3. Set an Internal Name that makes it easy for you to recognize the >>> product. This name will be shown in the admin tools, but not to the >>> customer. >>> 4. Note that if you are using the UPS or USPS or other online rate >>> estimation utilities then you must have values in the "Weight" and > "Weight >>> Uom Id" fields. >>> 5. Submit the form to create the product. >>> >>> Add Content to the New Product >>> >>> 1. Click on the "Content" tab/button for the product you just created. >>> Here you can setup text and images for your product. >>> 2. You will see some forms at the top for administering managed content >>> (ie from the Content Manager) with the product. For more advanced product >>> related content needs use this, but for more common and simple needs, > this >>> can be more difficult to administer and slower at run time. >>> 3. Near the bottom of the page is a section labeled "Override Simple >>> Fields". Here you will typically want to specify a Product Name, Product >>> Description, and Long Description. If you have images to associate with > the >>> product, you can specify their locations here, or upload them. Note that >>> there are default locations for the images (can be quickly set by > clicking >>> on the "[.jpg]" or "[.gif]" buttons). We recommend using these locations, >>> but of course you can put your images anywhere. These can be an absolute >>> URL, or will be relative to the current server address, or the content > URL >>> prefix if one is specified in the url.properties file. >>> >>> Add Prices to the Product >>> >>> 1. Product pricing in OFBiz is very flexible. There are two main >>> aspects to it: Prices and Price Rules. This is independent of promotions, >>> which are applied after the price calculation is done. >>> 2. For basic operation you should have at least one type of price setup >>> for each product: the Default Price. This is the price that is used when > no >>> rules apply. >>> 3. To add a Default Price go to the Prices tab for the Product, and use >>> the form at the bottom of the page. >>> >>> 1. The Product Price Type Id should be "Default Price", the Currency >>> Uom Id should be whatever currency the price is in, and the Product Store >>> Group Id can be left as Not Applicable, unless you are setting up > multiple >>> groups of stores that have different pricing. >>> 2. The From Date can be now or in the future, if you want the price to >>> take effect in the future. The Thru Date is optional, but can be used to >>> specify that this particular price expires at a certain date and time. > Note >>> that if there are multiple prices of the same type, etc that are active > at >>> once, it will use the one with the most recent From Date. This is useful >>> when you want a temporary price to override the normal "Default" price of >>> the product. >>> >>> 4. If you are using price rules or may do so in the future you may also >>> want to enter information such as the List Price and the Average Cost > which >>> are often used in the price calculations. >>> 5. Note that if a Minimum Price is set the price will never be less >>> than that. So, even if the Default Price is to 2.00 and the Minimum Price > is >>> set to 3.00, then 3.00 will be used as the calculated price. The Maximum >>> Price setting works the same way as the ceiling for the price. >>> >>> Make sure to put each product in a browse category, and in the All > Products >>> category so that it can be searched for, viewed, and purchased in your >>> catalog. >>> >>> Expert Recommendation: These are the basics, but there is a lot more >>> information about products that you can, or may need to, setup. We > recommend >>> reviewing the more detailed documentation or engaging the services of an >>> experienced consulting to help you through this. >>> >>> Advanced Catalog Setup: Features, Promotions, Price Rules, Keyword >>> Thesaurus, Features for special functionality or parametric search, >>> Moderated (or unmoderated) Product Reviews, Configurable and Manufactured >>> Products, Virtual and Variant Products, Inventory/Facility/Location >>> settings, and so on >>> >>> See the end-user documentation space for details on how to set these > things >>> up and what they mean. Also see this for more advanced options for > Products, >>> Categories, and so on. >>> >>> >>> >>> >>> >>> >> >> > > >
