Embed Size (px)
Citation preview
SIGSOFT 2008 Marburg 1
For what Purpose and by which Means Should we
Describe Organizational Processes?
Organizational Process For what Purpose? By which Means?
Thorsten Spitta, University of Bielefeld / GermanyJuliane Kaup, General Electric Inc., Jenbach / Austria
SIGSOFT 2008 Marburg 2
Organizational Process● Process?
the flow of a thing over time– Flow?
things change their states over steps● State?
– physical– artificial– mental / "psychological"
SIGSOFT 2008 Marburg 3
Org. Process ...– Thing?
● active ● passive
● Actor?– humans– machines
● Resource?– material– money– data– humans
hierarchical and cyclic relationships
--> actor--> resource
SIGSOFT 2008 Marburg 4
Org. Process ...
What kind of organizational process?● Business Process● Routine Process
SIGSOFT 2008 Marburg 5
Org. Process ...
Examples1. New order of four cruise liners for 2.4 Bill. $.
The process:Gaining new orders of very large investments
2. Next year's agreement of a food producer with Wal Marts.The process:Negotiating delivery conditions with a mighty customer
3. Order entry of a large bookseller via internet.The process:Highly standardized flow of data, material and money - repeatedly performed every day
SIGSOFT 2008 Marburg 6
Org. Process ...
Conclusion➢ Case 1 and 2 are business processes, 3 is not ➢ Real business processes are not standardizable,
they are management, concerning the organization's business
➢ Case 3 is a routine process.It is well standardizable and should be standardized.
Be careful with notions of consultants!
SIGSOFT 2008 Marburg 7
For what Purpose?
Assumptions 1. We never model organizational processes
for their own sake.2. We always do it for decision purposes.3. Often we need a decision base for the
automatization of processes or parts of them.
Our main purpose is the introduction or construction of information systems
SIGSOFT 2008 Marburg 8
Purpose ...
Example– decision: IT steering committee of Schering AG /
Berlin on a new payroll system– time: 1986– users: 26,000 once a month– processes, analysed and drawn: 172– processes, to-be: 23 (8 batch
15 dialogue entry points)– documentation: 480 printed pages
SIGSOFT 2008 Marburg 9
Purpose ...
ConclusionWe should look at the efficiency of our methods,
because real projects grow to large dimensions.
SIGSOFT 2008 Marburg 10
Purpose ...
Phases of information system's introduction1. Organizational overview 2. Detailed view
Assumptions ➢ In the understanding phase rigor in detail is
counterproductive – it hampers communication➢ Methods should support both phases without brake➢ In the constructive phase rigor must be possible
- understanding & communication
- construction & implementation
SIGSOFT 2008 Marburg 11
Which Means?● "Means" at first are methods ● Tools must be based on well defined methods● Tools are the last link in the chain
Well defined?Ontologies seem to be a broadly accepted
foundation for methods
SIGSOFT 2008 Marburg 12
Means ...
The BWW ontology (Bunge-Weber-Wand) [Weber&Wand 1990] – based on general systems theory– central construct: thing (object?)
● properties● visible as states ● lawful or not● causing events, leading to lawful state transitions into stable states
SIGSOFT 2008 Marburg 13
Means ...
Ontology ...– a system is a well defined (lawful !)
collection of things,● having stable states● some of them interacting with the environment
– the environment's things can cause unstable states in a system
The BWW ontology seems to be appropriate
SIGSOFT 2008 Marburg 14
Means ...
system
thing
thing
thingthing thing
environment
transiton laws
a simple system view
SIGSOFT 2008 Marburg 15
Means ...
BWW ontology organizational pendantsystem organization
subsystem organizational unitthing resource
human actormachine (material or artificial actor)
property attribute of data typestate value of attributetransition resource flowlaw business rulehistory sequence of attribute's valuesevent result of an actor's action
environment actors, each behaving as an indivisible thing
SIGSOFT 2008 Marburg 16
– ARIS– UML
– System View?
Both frameworks have grammaticaldeficiencies against the BWW ontology
Means ... / Frameworks
→ EPC → Activity Diagram (AD)
→ ??
SIGSOFT 2008 Marburg 17
Means ... / UMLUML
object(thing)
action(of a thing)
control flow(signals, data)
Extension
data
money
material
actor
object flows
SIGSOFT 2008 Marburg 18
Means ... / UMLrefinement UML 2
activity
action
action
activity
action
action
refinement System
thing
action
action
thing
action
action
SIGSOFT 2008 Marburg 19
A system view
Procurement
money
Enterprise
Production
Sales
Finance
data
material & work
customersupplier
administration & banks
SIGSOFT 2008 Marburg 20
A System refinement
Material Picking for
Production Order
Shipping
ProductionBilling
GoodsReceipt
OrderProcessing
Quotation
Inquiry
[material ordered ]
[Entire Order Processed ]
Warehouse Service
[duplicate]
A B
External Internal[Customer Contact]
[Direct CustomerContact]
A
B
[Bill paid] [Bill paid ]<<actor>>Finance
ProductStaging
<<actor>>C
ustomers
<<actor>>Suppliers{joinspec =
((A and B) xor B)}
{joinspec = ((A and B) xor A)and all material available}
[final sales order ]
[material purchased]
[duplicate]
Sales
SIGSOFT 2008 Marburg 21
All refinements (9)● Sales
– inquiry– quotation– order processing– goods receipt– material picking– production– product staging– shipping– billing
The case was the danish sales Co. of a large german enterprise – implementing SAP's SD (sales & delivery)
SIGSOFT 2008 Marburg 22
A further refinementInternal Sales
Retrieve delivery note
[Billing process terminated]
ArchiveDelivery Note
Batch:Printing/Transfering
Confirm
Enter additional data
<<actor>>Finance
[Product shipped]
<<actor>>Customer
Billing
Bill(duplicate)
Bill
<<actor>>ShippingProcess
Delivery note(duplicate)
Delivery note
SIGSOFT 2008 Marburg 23
Conclusions➢ we model routine processes, not business
processes➢ we model processes for communication, but we
should try to bridge the semantic gap between overview and construction
➢ a system view seems to be essential for bridging this gap, a suited framework is necessary.
Let's work on UML
