LinkedIn: Answers: Does implementing a Software within an organization impede continuous Process Optimization?

<question>
Does implementing a Software within an organization impede continuous Process Optimization?
- Time-Frame for Implementation (say for ERP) - at least 1.5 years
- Time-Frame for maturity and stabilization - 2-3 years
i.e. - even after 3.5 years the organization is still stuck at current state.

Considerations for changing the process -

- Cost of Change (customization cost)
- Consideration of impact on other modules
- Dependence on external third-party

Thus 3.5 years at current state followed by uncertainty and additional dependencies. So that brings me back to my question - Does implementing a software impede continuous Process Optimization?
</question>

My answer is “NOT NECESSARY” – if you architect your BPM system (a set of tools and practices to handle business processes as enterprise-wide important artefacts) for optimal agility (required level of agility may change over the time).

Of course, such architecture should define a set of principles, recommendations, examples, etc. for “implementing software” within your organisation. Examples of such principle are: “avoid dispersion of the business logic” (e.g. not embed it into ERP), “explicit is better than implicit” (e.g. keep your business processes in BPMN, but not code them in Java), etc.

In my experience, a properly architected BPM system (with explicitly and formally defined executable business process) will help you to
a) provide tools for better decision making– real models and real performance data can be used by popular process improvement disciplines as Lean and Six Sigma.
b) guarantee that your business system is capable to implement changes with required pace.

Some practical examples were presented this summer at the conference "Architecture World 08" in Bangalore, India (see below).

Thanks,
AS

Links:
http://www.improving-bpm-systems.com/pubs/AS-AW08-keynote.pdf