Re: Definition of business process

[LITTRE Jacques <jacques.littre@swift.com>]

Hi Bob,

You will find in the § below my interpretation of what is usually meant by "Business Process" and business modeling as understood in
business analysis activities (an activity part of software engineering in general). This definition is a bit more abstract that the
ones which have been given so far but all what has been said in the other related mails are good examples (instances) of business
prcesses in general. That's why I will not give additional examples here.

<A business process can be a set of consecutive and/or simultaneous operations that contributes to the achievement or realisation of
a business objective or of a well defined business activity.
The operations can be manual as well as automated or semi-automated and involved none, one or more actors/parties. A business
process can be global (coarse) or specific (fine-grained). Coarse business processes may usually be decomposed into one or more
sub-processes (or finer-grained processes).>

Business modeling is one of the most important activity of Business Analysis. Business modeling is mainly about understanding a
business and defining the business domain (also called the "business problem domain") and the business context. Understanding the
business is namely done by identifying the Business Processes i.e. what is this business all about. The result of this, the business
models, are only an abstraction of the "real-world". The reason to go through business modelling is usually for business
reengineering or business improvement. The objective is, instead of starting from an existing implementation of a business process
to see how to improve it (bottom up appraoch), is first to understand what are the tasks to be achieved and the relationships with
the other processes (i.e. a top down approach) an then to (re-)define a (usually better) way to implement it.

Now, one of the best way used in business analyis to describe a business process is the "use case" which include usually a
description of actors, the activities /courses of events involved in the process.

Some good references in this area are the "Catalysis" method by Desmond d'Souza and Alan Wills or "Applying UML and Patterns" by
Craig Larman.

Hope it helps understanding.
Best regards
Jacques

Bob Haugen wrote:

> Christian Huemer wrote:
> >i'm sure that you
> >are not refering to content (here dain is right, we cannot
> >predict the future), but to which extend is it necessary to
> >consider business processes in the modelling phase.
>
> That is part of my question, although I understood that
> ebXML decided in Orlando to get deeper into business
> process modeling, thus the new name of the Business
> Process Methodology group, which is now just Business
> Process.
>
> >so why is (2) not enough? why do i prefer to include the internal operations
> >as defined in (3), when the focus is on inter-organisational operations.
> >my opinion is that the data interchanged between organisations heavily
> >depends on the internal processes. take the following example from
> >an order: the seller will determine whether the ordered goods are available
> >or not. if not the following conditions might hold: not an offered product
> >by the seller, out of stock ... if not deliverable, the seller might offer
> >a substitute, a later delivery date ...
> >=> the described process is internal to the seller. but accoring to this
> >business process the reply message will look differently (will include
> >different semantics). therefore, i think it is necessary to include internal
> >business processes to that extend as they influence the interchange.
>
> It is difficult to know where to stop (and where to focus),
> which was really the basis of my question.
>
> Also, the internal processes are very different for example
> for a) purchases of capital goods which might have a long
> and involved approval process and many documents
> floating back and forth between buyer and seller;
> or b) purchases of office supplies which just might mean
> cutting a PO, receiving a shipment, getting an invoice,
> and paying once a month;
> or c) manufacturing components which want to minimize
> paper work and do not use orders or invoices, but
> work off the end item production schedule and
> dependent demands or electronic Kanbans
> and maybe evaluated receipts settlements.
>
> So I think if I was making the decision I would
> not model processes at all, because the word
> is too overloaded.
>
> I would model activities in a lightweight way.
> There are basically only two kinds of economic activities:
> transformations where inputs are transformed into outputs,
> and exchanges where one resource is exchanged for another
> between two or more economic agents.
>
> I would probably start with exchanges.
> A basic exchange is very simple, and is the core of
> each of the above scenarios.
> I would leave the administrative documents and processes
> which vary so much for add-ons:  that is, purchase orders,
> requisitions, invoices, approvals, etc etc.
> That does not mean they are not important,
> but you cannot assume that everyone wants
> to use purchase orders any more, so they are
> better off as optional accessories.
>
> Anyway, that is just to make clear where I
> am coming from.  But I am a mere mailing list
> and conference call participant, and do not
> really set the policies, so I was trying to get
> some feedback about what the policies were
> as well as what other people thought.
>
> Thanks for your feedback,
> Bob Haugen
> Logistical Software LLC
begin:vcard 
n:Littre;Jacques
tel;fax:+32-2-655.45.52
tel;work:+32-2-655.43.35
x-mozilla-html:FALSE
org:S.W.I.F.T.;Standards Automation
adr:;;;;;;
version:2.1
email;internet:jacques.littre@swift.com
title:Lead Analyst
x-mozilla-cpt:;1
fn:Jacques Littré
end:vcard