Alignment of BPR and IT Solution Approach

Business Process Reengineering does not always Require Software
Darron Passlow
Business is a process involving humans. BPR is also a process involving humans and humans reactions.
Why do we need a software package to help handle processes? Some processes, particularly those involving human (reactions) are multi-variable problems that are not easily modelled (by software) - so drop the idea and get in an do your BPR the old fashion way. My thoughts anyway.

Need to Consider the Applicability Of COTS and the Divisions on Applications they Introduce
Adonis
Various tools which enter in the BPM domain may be divided in engineering tools and/or execution tools.
Executing business process software is more complex than business process software used for mapping. A tool by itself alters the way to change and sometimes we use multiple tools for the same processes and change, what is costly.
An additional parameter is the change of technology which may not follow the business change.
Generic tools remain trivial while specialized or sophisticate tools may hide enormous problems.

Business Process Reenginering Does not Always Require Software
funke tijani
@Darron Passlow: thank you for your contribution. Unfortunately or shall I say fortunately, BPR does requires IT !
The originators of BPR (Champy et al.) all advised using IT to enable any changes made through BPR. BPR really is about re-engineering business processes and IT helps to automate some human activities.
Whilst I know there are some processes that can not be modelled by software, a majority of business processes are automated by IT for effectiveness and efficiency.

Business Process Reengineering
CK Park
@funke tijani: funke, I am actually OCM practitional and familiar with Champy, Hammer, Demming etc. I would think both you and Darren are right, but it can be dangerous to assume you must have IT involved.
Remember, there are business processes that do not involve IT such as (when a customer walks in the door, looks at the price tag and walks out).
Darren is correct on the importance of human beings.
IT works in most cases, but most projects fail not because of IT, but because of people issues. I have actually led many ERP projects where everybody focused on the IT and ignored people aspect of it, resulting in cost overruns and project delays. That is why the BPR is under the change management domain, you must manage change.

BPR and IT Systems - COTS or Otherwise
Debashish Bhattacharyya
The primary requirement is the process; and the software follows process. If the processes are not aligned to the business objectives, the application software definitely will not.
Having worked with SAP and IFS applications, I have seen that as long as the BPR gets executed and implemented, taking care of the cultural change and ownership issues, implementing ERP is not a problem.
Custom development comes with its own challenges, not the least of which is the long development and stabilisation life cycle. I would therefore advise a COTS rather than custom development.

Business Process Engineering
Darron Passlow
All, the big challenge in BPR is understanding what you are trying to achieve (the goals).
Then deciding on the best process that will fit the "culture".
Then deciding whether you need it to help you achieve your goals.
COTS always before "custom" builds.
So remember to always consider the need for the process change first, and then the people involved.

Business Process Reengineering and COTS - Which One First?
Debashish Bhattacharyya
For any implementation - BPR / ERP / any enterprise application, understanding the objective is the key - always.
The rationale for BPR before COTS / custom build is that unless the business process is aligned with the organisation / functional objective, the implementation of any application will not provide any major benefit to the organisation.