this probably sound off the wall, but i think a good starting point for all businesses is a Business plan. I adopted this as my primary model for creating other Business processes, based on the type of business.
David E Jones sent the following on 6/15/2009 4:20 AM: > > As I mentioned in the email below I've been working on the lightweight > version of this analysis and design process, the one I propose to use > for the UBPL effort. > > It is now available here (link at the bottom of the page): > > http://www.dejc.com/home/HEMP.html > > Comments and feedback are welcome on this! I imagine this "HEMP light" > document and the ones that follow will go through a goodly number of > revisions. :) > > -David > > > On Jun 11, 2009, at 4:03 AM, David E Jones wrote: > >> >> The last major priority that I pushed on was clean ups and >> enhancements to the framework. While there are still some big >> improvements coming along (new authorization approach and more >> AJAX/etc stuff come to mind), I think we've made huge progress on that >> and the framework is significantly cleaner and far more helpful when >> writing business applications. >> >> I've mentioned this a little bit and started putting some seed >> material together, and the next high level priority that I'd like to >> work on (and work with others on!) is to add collaboration on >> requirements and designs to our existing excellent collaboration on >> implementation. >> >> What I mean by that is instead of collaborating mostly through the >> code and lower level artifacts I'd like to work with others on higher >> level artifacts including requirements (organized by process from an >> end-user organization perspective) and designs based on those >> requirements, and then use those designs to improve OFBiz. The most >> important improvement that should result from this is that we have >> applications that are designed to support various business activities >> and that better meet the needs of various types of end-users. These >> may be improvements to the existing base "applications", and many will >> work best as "specialpurpose" applications that are based on the base >> applications and that more directly address the needs of certain users. >> >> There are some exciting possibilities for this. One of them that seems >> interesting to lots of people right now is to create an application >> that OFBiz itself will use. Once that happens we can make sure it >> works well for other open source projects (both in and out of the ASF) >> and make using it a no-brainer choice that will not only help the >> world of open source in general, but also be perhaps the best form of >> marketing that OFBiz could ask for as an open source project with no >> real marketing budget. >> >> There are many other types of organizations we could target, and what >> I've started working on to help us collaborate on requirements >> acknowledges this. Some of these organization types will share >> business activities and can share requirements, designs, and >> implementations. Others will have some pretty unique requirements. For >> example there are many things that an open source project does that >> service providers also do (such as manage tasks and issues), but also >> many things that each does that the other does not (open source >> projects don't typically invoice for work done, collect against >> receivables, etc). >> >> One other important aspect of this is documentation. A few people have >> written on the mailing lists and to me personally about this recently. >> My opinion is that this collaboration on requirements will be the >> single most important effort to prepare for a successful documentation >> effort. The requirements themselves (and overlap information with OOTB >> apps and links to designs that are implemented) have some value as >> implicit documentation, and more importantly provide a foundation and >> structure that is consistent with what end-users are looking for and >> will help organize a large volume of information. IMO that is one of >> the biggest problems with documentation efforts to date: it is not >> consistently organized, and it is very tough in general to organize it. >> >> Anyway, here is the main page for what I'm calling the "Universal >> Business Process Library": >> >> http://docs.ofbiz.org/display/OFBREQDES/Universal+Business+Process+Library+Index >> >> >> The name is based on the concept of the "Universal Data Model" that we >> got from "The Data Model Resource Book, Revised Edition, Volumes 1 and >> 2" (and the new Volume 3 is pretty interesting too). The trick is that >> there doesn't seem to be such a thing in existence, at least not in a >> form that is useful to OFBiz. There are lots of standards and other >> efforts that have some great seed material for this, like the UBL and >> OAGIS standards which document information flow between organizations >> at many different points during business processes, but have a focus >> on what is external to an organization instead of one that is >> internal, which is much of what OFBiz provides. >> >> For those who want to get involved, there is a quick introduction to >> UBPL here: >> >> http://docs.ofbiz.org/display/OFBREQDES/UBPL+Introduction >> >> To help people get a quick understanding of the artifacts (documents) >> and process I have in mind for doing these requirements, overlap >> analysis, designs, etc I'm working on a shorter version of the "HEMP" >> book that I've slowly been assembling for the last few years (and more >> formally in the last 1.5 years). I'll send out information on that ASAP. >> >> The most mature high level story for a particular type of organization >> is the "Story of Online Retail Company" which you can find here: >> >> http://docs.ofbiz.org/display/OFBREQDES/Story+of+Online+Retail+Company >> >> That high level story has links to the more detailed stories, many of >> which can be shared with other types of organizations and so they are >> organized separately under the "General Business Process Stories" >> section of the UBPL Index page. >> >> >> =============================== >> >> Sorry for the long email! I know I've also written something similar >> to this before, and there is a reason I'm writing about it again! I'll >> be presenting about this at OSCON in July, and probably also at >> ApacheCon in November, but there is another reason. >> >> Another benefit to this pattern is that if used for projects that >> involve customization of OFBiz it will significantly increase chances >> of success in terms of overall efficiency and also effective >> applicability to the end-user organization. >> >> Helping others do just that is what I have chosen for the next step of >> my career. To pursue that direction I have recently resigned from >> Hotwax Media and returned to being an Independent Consultant. My hope >> is that by doing this I can work with more of you and do so in a way >> that best meets your needs. For more information see my recent blog >> post on the topic (at http://osofbiz.blogspot.com/) and my new web >> site (at http://www.dejc.com/). >> >> My vision for the future is to solve the biggest problem that OFBiz >> has right now (applicability to end-user organizations) and the >> biggest problem most service providers have (successfully tailoring >> OFBiz to the needs of their clients)... which also happens to be the >> biggest opportunity for service providers too. >> >> I look forward to collaborating a lot more with a lot more of you! >> >> -David >> >> > > -- BJ Freeman http://www.businessesnetwork.com/automation http://bjfreeman.elance.com http://www.linkedin.com/profile?viewProfile=&key=1237480&locale=en_US&trk=tab_pro Systems Integrator.
