Business Process
An interesting debate behind the scenes at Wikipedia about the nature of the Business Process [article, discussion] involving Keith Swenson (Fujitsu and WfMC), Kai Simon (Gartner) and myself.
Kai had contributed a definition of Business Process to Wikipedia: "A business process is a set of linked activities that create value by transforming an input into a more valuable output."
Keith objected that this definition assumed an "information system" view of the world, and was not necessarily valid for office work. How do activities such as document approval or answering the telephone fit into this definition? What happens if two people approve a document for different purposes?
Document approval and answering the telephone are presumably useful to the business - otherwise why would the business employ people to perform them? Perhaps they create value in some way - an approved document is worth more than an unapproved document; an answered telephone more than an unanswered telephone.
But Keith is correct to point out the potential complexities of this way of viewing business process. If there are n people who may approve a document, then there are potentially 2-to-the-power-n approval states of the document. (In this case it might be easier to regard the approval instead as a separate entity.) And once the document has been approved (by manager A), does a second act of approval (by manager B) confer any additional value?
Understanding the business process as a chain of value-adding activities is a popular and useful view, often attributed to Michael Porter and not only found in IT. But this view (modelling perspective) has some limitations, and it is certainly not the only way of understanding the business process. It is particularly problematic with management processes, such as command and control or strategic planning, whose value depends on some indirect calculation.
For developing service-oriented architectures and systems, it is often useful to think of the business process more abstractly in terms of events and capabilities, rather than a particular value chain. Even within IT this view provides a useful alternative to the value-chain perspective, and allows us to analyse the requirements for management systems (including business intelligence) as well as transaction systems.
Kai had contributed a definition of Business Process to Wikipedia: "A business process is a set of linked activities that create value by transforming an input into a more valuable output."
Keith objected that this definition assumed an "information system" view of the world, and was not necessarily valid for office work. How do activities such as document approval or answering the telephone fit into this definition? What happens if two people approve a document for different purposes?
Document approval and answering the telephone are presumably useful to the business - otherwise why would the business employ people to perform them? Perhaps they create value in some way - an approved document is worth more than an unapproved document; an answered telephone more than an unanswered telephone.
But Keith is correct to point out the potential complexities of this way of viewing business process. If there are n people who may approve a document, then there are potentially 2-to-the-power-n approval states of the document. (In this case it might be easier to regard the approval instead as a separate entity.) And once the document has been approved (by manager A), does a second act of approval (by manager B) confer any additional value?
Understanding the business process as a chain of value-adding activities is a popular and useful view, often attributed to Michael Porter and not only found in IT. But this view (modelling perspective) has some limitations, and it is certainly not the only way of understanding the business process. It is particularly problematic with management processes, such as command and control or strategic planning, whose value depends on some indirect calculation.
For developing service-oriented architectures and systems, it is often useful to think of the business process more abstractly in terms of events and capabilities, rather than a particular value chain. Even within IT this view provides a useful alternative to the value-chain perspective, and allows us to analyse the requirements for management systems (including business intelligence) as well as transaction systems.
