Business process management/Sharing - infrastructure cost models

From Wikiversity
Jump to navigation Jump to search

Summary[edit]

The position of a BPMS tool in the infrastructure stack is such that it will span departmental systems and cross the boundaries of system silos. Both the users that interact with the BPMS tool and the integrations invoked by the defined processes give rise to the possibility of sharing a BPMS tool across the program. If the infrastructure has the capacity for the load imposed by the executing processes then the costs can be distributed to those teams that use it.

Cost Model
Description
Advantages
Disadvantages
Flat Fee Projects pay a fixed fee, usually a portion of the infrastructure costs, to participate in the shared infrastructure environment.
  • Works well with similarly sized projects.
  • Can quickly cover the cost of infrastructure if enough projects join.
  • Small projects pay a penalty if they share with larger projects.
Transaction Fee Projects pay based on usage. The unit of usage is typically a transaction, and that can be defined differently. For example, some organizations charge by hardware (CPU) operations. Others charge by business transactions.
  • Allocates cost based on the size of the project.
  • Provides data for sizing hardware requirements if opportunities are deemed to be of a size similar to existing projects.
  • Usually requires initial upfront costs to pay for the infrastructure until projects begin producing chargeable transactions.

There are occasions when sharing parts of the physical infrastructure may not make sense. Isolation of more sensitive process applications might require different environments for the BPMS tools. However, the sharing of software licensing costs, shared staff to support the environments, and even physical data centers might still make sense. The above cost models can still apply and be defined for such use cases.


Applies to[edit]

Engine.gif
Charter for the BPM Engine
Investment.gif
Charter for BPM Investment