Business Process Reengineering
Business Process ReengineeringThe BPR Bible is... ReengineeringTheCorporation: A Manifesto for Business Revolution, by Michael Hammer, James Champy (Contributor)
And read the sequel as well, BeyondReengineering? (ISBN 0887308805 )
Comes from IBM. (Historically, people have thought that IBM knew something important about software development in the corporate environment. ;-)
Side note: IvarJacobson wrote a book called "The Object Advantage: Business Process Reengineering With Object Technology" ISBN 0201422891 . I have not read it, but, as best I recall from what someone explained to me, Jacobson makes the case for using UseCases for BPR. It had something to do with UseCases representing a process that adds value for the customer/user. I don't mean to confuse, but I hope it helps understand what is a process, as opposed to a task.
The book is quite rigorous, but you can get a feel for the power of the idea by using object modelling techniques rather than the conventional procedural 'workflow' ones. Using that approach you identify how people need to work as teams (possibly virtual teams) to look after your 'assets' (products, customers, suppliers, resources, etc.). You could think of these as use cases. This approach has been successfully used within a very large UK company and has proved very successful - people actually use and maintain the process descriptions because they are people-oriented. -- MikeHowells
The fundamental idea is that if you automate the current manual practice, all you'll get is a fast ineffective practice.
What you need to do instead is to redesign or "reengineer" the customer's business process, to be more sensible, effective, efficient, focused on results of value to their customer, etc... before you ever try to build an automated system.
Without BPR, you run the risk of automating bad business practices, and thereby "locking them in" -- making them nearly impossible to fix ever in the future.
Isn't this a bit arrogant? Sure, there are often current practices that are less than perfect in any business, but who is the BPR consultant to say that the business must redesign its practices before any software can be started?
Over at XpIsResultOfApplyingBusinessProcessReengToSwEngProcess, we've gotten an interesting statement. That XP and BPR are really instances of the same idea, applied to slightly different concepts.
Fine. Could somebody explain what BPR is? What is the fundamental text, who believes it (academics? business people? some unholy conglomeration of the two?), what are the perceived benefits, etcetera.
Bonus points for addressing the following sorts of questions: If I believe the claim of XpIsResultOfApplyingBusinessProcessReengToSwEngProcess, how should I change my actions?
I'd buy into that, in that BPR is for redesigning our customer's business process, and XP (and all other development methodologies for that matter) are about redesigning our development "business process" -- the techniques we use to develop the software itself. I don't think it changes your actions, as the fact that we talk about development methodologies at all means that we're already doing BPR -- on ourselves. -- JeffGrigg
I've changed my actions by ordering the book. BPR is a buzzword in a lot of America's industrial companies, and many of them are actually trying to do serious rethinking of their processes. My mission, should I choose to accept it, is to "sell" XP into the corporate environment, and the hook to something they know about and (somewhat) believe in, may be valuable. I'm also hoping to get some ideas to feed back into the XP process itself. --RonJeffries
EditText of this page
(last edited May 21, 2004)
or FindPage with title or text search