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
John Hirsch <[EMAIL PROTECTED]> wrote:
John Hirsch <[EMAIL PROTECTED]> wrote:
Keith/Jan
I simply HAVE to jump in here to make an observation:
Kieth: Are you saying that we've come full circle??
The massive PROCESS ORIENTED systems we USED to build
on the mainframes are now 'back in style'? That my
PROCESS ORIENTED skills are now worth something
(again)? My business ANALYSIS skills are now golden
again?
If NOT then what are you talking about?
Can we, as a group, analyze a specific problem and
build some concepts that illustrate what we are
talking about?
If you need suggestions, I have them, I've worked in a
number of different industries and know their BUSINESS
processes fairly well: Mortgages, Railroads, and
Telco's.
Thanks
John Hirsch (with ancient skills)...
--- Keith Harrison-Broninski <[EMAIL PROTECTED]>
wrote:
> Jan Algermissen wrote:
>
> >Keith,
> >
> >what exactly does it mean for an architectural
> style to be 'process
> >based'?
> >
> >
> Here are some quotes from BPM author Martyn Ould
> (slightly paraphrased
> in places for readability):
>
> > The key thing about a paradigm shift is that old
> ways of thinking just
> > won't work in the new world. If your structural
> engineers have only
> > had mud to work with in the past, their ways of
> specifying and
> > designing buildings will be fine for mud buildings
> but they won't make
> > a lot of sense when the steel girder appears on
> the scene. Today's
> > dedicated follower of fashion in information
> system development is
> > likely to be speaking UML and using one of the
> various development
> > approaches based on the UML. [But] we cannot view
> business process
> > management systems as just another sort of
> information system.
> > Information-oriented languages and
> information-oriented methods have
> > evolved around a world of storing, retrieving, and
> updating
> > information, not the dynamic world of process.
> >
> > Simply extending our information-based methods
> simply won't work -
> > they don't have the necessary concepts at their
> heart. We're moving
> > from the Information Age to the Process Age. We
> need purpose-built
> > methods for working with processes to replace our
> methods for working
> > with information. The process-managed enterprise
> demands that the
> > center of automation be shifted from /information
> processing/ to
> > /process processing/. The traditional paradigm
> views organizations as
> > things that work with information, so our systems
> have been about
> > looking after information. In the past we have
> specified our
> > information systems in terms of what data they
> will store and how we
> > can access it and change it and move it around.
> And we have designed
> > our information systems in terms of data
> representations and
> > operations on data.
> >
> > Processes need an architecture and conceptual
> framework of their own,
> > not a data-oriented information systems paradigm.
> While new
> > "service-oriented" architectures and techniques
> for software
> > development offer flexible, loosely-coupled
> approaches to computing,
> > these advances, though good, are aimed at
> technical people who build
> > and manage information systems, e.g., programmers,
> not business
> > analysts who want to build and manage business
> processes. To this end,
> > a modeling framework based on techniques
> compatible with
> > process-oriented architecture is needed to
> supersede
> > information-oriented approaches to process
> modeling and analysis. This
> > shift from the Information Age to the Process Age
> in terms of
> > architecture and methods will serve as the
> cornerstone of BPM, now
> > that the tinkering, tactical deployment phase is
> moving on to
> > strategic enterprise BPM.
> >
> My own approach to POA is couched in terms of Roles
> and Interactions,
> which bear a resemblance to swim lanes that is
> purely superficial. The
> detailed semantics I propose are different to (say)
> the UML and the
> differences are very important! As with any
> architectural approach,
> there are deep issues that must be addressed in
> order to fashion working
> computer systems - with processes, these issues are
> not just IT-related
> but extend into various other domains including not
> only
> business/management theory but also the "soft
> sciences".
>
> HTH? If not, I am always happy to write more on the
> subject.
>
> --
>
> All the best
> Keith
>
> http://keith.harrison-broninski.info
>
>
>
>
> >
> >Jan
> >
> >
> >
> >
>
>________________________________________________________________________
>
> >_______________
> >Jan Algermissen, Consultant & Programmer
>
> >http://jalgermissen.com
> >Tugboat Consulting, 'Applying Web technology to
> enterprise IT'
> >http://www.tugboat.de
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >
> >Yahoo! Groups Links
> >
> >
> >
> >
> >
> >
> >
> >
> >
>
______________________________________________________
Yahoo! for Good
Donate to the Hurricane Katrina relief effort.
http://store.yahoo.com/redcross-donate3/
Yahoo! India Matrimony: Find your partner now.
SPONSORED LINKS
| Service-oriented architecture | Computer monitoring software | Computer and internet software |
| Free computer monitoring software |
YAHOO! GROUPS LINKS
- Visit your group "service-orientated-architecture" on the web.
- To unsubscribe from this group, send an email to:
[EMAIL PROTECTED]
- Your use of Yahoo! Groups is subject to the Yahoo! Terms of Service.
