Kieth: I agree that there are MORE complex ones. Railroads are another.
BUT if we can set a baseline on a simple one the QUESTIONS raised by a complex one, should be easier to answer. I worked for Trilogy, which built the 'build your own' web model. (Good or bad...??) They handled the 'complexity' problem when making choices by making everything PACKAGES..(you are used to that for automobiles)... Railroads have multi-layered rates, depending on a LARGE number of variables...Not just the PRESENCE of variables, but the ABSENCE of variables... Anyway...start small, build a model for small, see if it works for complex...eh? John --- Keith Harrison-Broninski <[EMAIL PROTECTED]> wrote: > The model Raja describes works for some businesses - > the classic > exemplar being Dell. But this is actually a special > case, miniscule in > percentage terms if you look at the business world > overall. Most > businesses "building to order" have sales processes > that are far more > complex. There is a travel agent example described > in Appendix B of the > report of the Process Modelling Group from June > 2005: > > http://www.bptrends.com/deliver_file.cfm?fileType=publication&fileName=09%2D05%20TB%20Proc%20Modelling%20Group%20Workshop%20Eindhoven%20June%202005%E2%80%A6%2Epdf > > or if the link above breaks due to word-wrap: > > http://tinyurl.com/83huc > > that illustrates the complexity typical of most > real-world sales > processes. To quote: > > > [This process description] takes the Travel Agency > closer to real life > > - but still not close enough. It does not deal > with information > > provision to the Customer, exception situations, > the interaction > > between different bookings, successive refinement > of bookings, payment > > options/problems, and so on. All these issues and > more are a normal > > part of such processes - even when mechanized, say > by a Web site. > > > > Moreover, if we consider a human Travel Agent, the > process becomes > > even more complex, since we are then in the domain > of "human-driven > > processes", where the activities may go off in > unforeseen directions. > > Consider a very normal situation: an agent who > books business trips on > > behalf of a large company. All sorts of > additional process issues > > arise, since if the agent wishes to prove their > value and retain the > > company's business, they must effectively embed > themselves into the > > internal business processes of the company > concerned, taking note of > > considerations which differ from trip to trip and > even making > > proactive suggestions based on their knowledge of > the company's > > working practices. > > To handle such processes properly, you need a lot > more than a set of > services. This is /not/ purely an IT problem, > unfortunately - it would > be much simpler to solve if it were. > > -- > > All the best > Keith > > http://keith.harrison-broninski.info > > John Hirsch wrote: > > >Raja: > > Perfect sense... > > > > SO: From a business standpoint, to START, a > >customer and a sales rep. At this point the SALES > REP > >interacts with the system, the CUSTOMER interacts > with > >the Sales Rep...(leaving out the old internet at > this > >point, eh?)...The Sales Rep interacts as the > Starting > >Actor. As the Sales Rep interacts with the system > >(and customer), OTHER Actors, such as The > >Manufacturing System The Delivery System, et al.. > > > >If I'm on the right track we will continue... > > > >IF I am anticipating correctly, we could eventually > >build an internet Interface (for use by the > customer) > >to REPLACE the sales rep and invoke all of those > >functions as services....IF we build them as > services, > >now.. > > > > > >Later, > >And Thanks > >John > >--- Raja Mohan <[EMAIL PROTECTED]> wrote: > > > > > >>Hi John, > >>I suggest we will take a process that goes across > >>many functions such as Planning, Order > >>Management,Supply and delivery etc. > >>1. I propose to have a business process ORDER > >>ENTRYfor an assemble to order manufacturing and > >>sales system. > >>2. sales rep receives the order for an assemble to > >>order item (Computer). Sales rep calls the service > >>orderentry from a order management application > >>3. The item computer need to be configured from > >>various optional features available for computer > >>(Such as Memory,disk space and minotor size). The > >>sales rep must call the list of features and > options > >>available for computer from a configurator product > >>which stored these data. > >>3. After selecting the features the sales rep > needs > >>to know the promising date for which he calls ATP > >>from planning application to determine the > possible > >>delivery date. > >>4. Sales rep calls the pricing to determine the > >>price of the selected computer based on the > settings > >>defined in the pricing data. > >>5. Once the customer is happy with the price and > >>date of delivery the sales rep books order which > >>calls for updating the sales order data in order > >>management as well as the on order data in > Inventory > >>master. > >>This may not be a best example of what really > >>happens because there are many other things that > >>happen at the time of order entry. But we can use > >>this as a starting point. > >>Do I make sense? > >>regards, > >>Raja Mohan > >> > __________________________________ Yahoo! Mail - PC Magazine Editors' Choice 2005 http://mail.yahoo.com ------------------------ Yahoo! Groups Sponsor --------------------~--> Get Bzzzy! (real tools to help you find a job). Welcome to the Sweet Life. http://us.click.yahoo.com/A77XvD/vlQLAA/TtwFAA/NhFolB/TM --------------------------------------------------------------------~-> Yahoo! Groups Links <*> To visit your group on the web, go to: http://groups.yahoo.com/group/service-orientated-architecture/ <*> To unsubscribe from this group, send an email to: [EMAIL PROTECTED] <*> Your use of Yahoo! Groups is subject to: http://docs.yahoo.com/info/terms/
