Talk:Business process re-engineering

Older topics

This article is incredibly kind to Hammer and Champy. BPR has to be one of the all time shortest management fads, it was consultant driven and has had high failure rates which led to general burnout of the fad within five years (Buchanan, D. 2000, An Eager and Enduring Embrace: The Ongoing Rediscovery of Teamworking as a Management Idea' in S. Proctor and F. Mueller (eds) Teamworking). Hammer's confession that "He and the other leaders of the $4.7 billion re-engineering industry forgot about people" exemplifies the non existant intellectual foundations of BPR.

Furthermore much of what it says, like so many management fads, is nothing new. The goals of Customer Friendly and Effectiveness are just marketing ideas repackaged to sell books. That a company should aim to be efficient is hardly a revelation either. Finally BPR's roots in Scientific Management are hardly laudable The dehumanising aspects of Taylor's work are well recorded and distasteful.

Essentially this article is biased in favour of an set of ideas that many organisational theorists consider flawed and that are more representative of consultant puff rather than any contribution to mankinds understanding of business and organisations.

Oliver Sawers, Cambridge, UK 30 April 2006

Efficiency: How efficient is the company that is manufacturing the product before introducing it to the market to maximize costs? This is one of the key categories that I believe is more important than any others. If a manufacturing company can master the skill of being efficient then they can automatically be more customer friendly and effective. Efficiency is not just about being efficient at the production floor level but the management level also has to be efficient. An example of only the production floor being efficient and not the management level would be the Japanese manufacturing companies. Now they are going through turmoil to repair their problems.

Merging articles

I noted that the content of Business process design is minimal and that it is more or less a synonym of BPR (or at least so closely-related a cousin that the two topics are very similiar). But before I just went ahead and merged, them, I thought it would be good to see if anyone thinks there's a good reason to keep them as separate articles. What do you think? Fairsing 18:57, 1 June 2006 (UTC)

Don't think so; Business Process Design is a Software development thing, not an Industrial Engineering thing

Hi, thanks for your comment. Can you provide a citation that BPD is a software development term? As it's defined in the current stub, it is defined as a synonym for BPR, and categorized as a Business Model, not a Software Development Process. Thanks. Fairsing 02:20, 6 June 2006 (UTC)

BPR's something different from BPD. It has own literature and tools. See Champy books for more information. --217.219.164.6 23:38, 26 October 2006 (UTC)

Business process design is far different from business process re-engineering.Business process re-design is same as BPR.So, it doesn't make any sense in merging the BPD and BPR.

I completely agree that Reengineering is really talking about Business Process Reengineering. Both are dealing with a subject which is generally attributed to Michael Hammer in the 90's. Wikipedia would benefit by having a single page. Goflow6206 17:23, 28 January 2007 (UTC)Goflow6206

Hmmmmm, design vs reengineering, business process reengineering vs reengineering. I agree that all three articles would be better merged, but I think "design" is more general than "reengineering". A design can be for a new business process as well as an existing business process. Business process engineering seems to apply only to existing business processes. The page should be named "business process design", with business process reengineering directed to it. Once reengineering is merged with it, "reengineering" should be directed to engineering or a disambiguation page. Oicumayberight 07:39, 2 February 2007 (UTC)

I agree to direct "reengineering" to a disambiguation page that could contain at least three links: Business Process Reengineering, Software Reengineering, Reengineering as in mechanical engineering. However, business process design and bp reengineering should not be merged, since the former is generally related to software design and the latter to an organizational change concept. Kai A. Simon 15:02, 6 March 2007 (UTC)

Though it is right that article on re-eingineering suits this topic i.e. business process re-engineering, but the two topics are not same. A wrong article has been posted at Re-engineering. Re-engineering is a much broader terms that encompasses manufacturing, software and business process re-engineering

I agree strongly that 'reengineering' should be directed to a disambiguation page that offers Business Process Reengineering as an important and concrete term, as well as any other reengineering related terms. When does the decision stop getting talked about and get made? (just curious actually) and how does it physically take place? (Maybe I share this question with lots of wikipedians, or maybe i'm newer than most. thanks.) --Pointblankstare (talk) 22:14, 19 December 2007 (UTC)

Re-engineering the article?

I am prepared to rewrite the BPR article, if you are interested. Subsequently, we might discuss the fine-tuning.
Note: I am not registered with the English Wikipedia yet, but you can find more information about me here. --194.120.17.193 14:05, 20 November 2006 (UTC)

Being back with real identity. I have re(written) a considerable portion. Please provide feedback. I also suggest to

• merge the article with the BP Redesign article. A short note on the (admittedly minor) conceptual differences can be added.
• remove the success story section and the Problems section and to join them into a short general pro and con discussion.
• remove the Key Target section, since those are mainly covered by the definition.

Kai a simon 17:24, 20 November 2006 (UTC)

Wikification

This might happen as part of re-engineering (above) but this page is also in desperate need of wikification (particularl adding internal wiki links) so I've added the tag Madmedea 12:10, 2 January 2007 (UTC)

Major edit?

Please note that this is a follow-up of the topic Re-engineering the article? from above.

I am considering a major edit, but would like to put it up for discussion first:

• Rewrite Key Target and/or merge it into the Methodology section.
• Delete Successes, since success is highly subjective. Also, the sources included in the text are not in the reference list.
• Delete Problems, or rewrite and rename to Critique, but then to include a balanced discussion of pros and cons.
• Rewrite Future. The references to TQM and Six Sigma are a part of a contemporary discussion and the reference to BPM is highly subjective.

Kai A. Simon 12:55, 25 January 2007 (UTC)

Diagram missing information

The diagram shows steps labeled "non-value added tasks" being removed from a process. Without knowing what those steps are, it's hard to say if those tasks do or don't add value to that process. To a BPR skeptic, it looks like carelessness rather than efficiency. Maybe more needs to be said about the steps that have been removed from the process in the caption of the diagram. Oicumayberight 17:54, 28 April 2007 (UTC)

Since I created the diagram, I might also be the one replying to your comment: This high-level picture is meant to explain the basic concept. If you look at the methodology steps to its left, you will see a step 3.2 Uncover pathologies in existing processes. This is where you identify improvement potentials, such as removing tasks from a process that are no longer required. Let me use the clinical development process as an example. If you collect the clinical data from study centers by means of EDC (Electronic Data Capture), i.e. the data is entered directly into a web-based system instead of being written down on paper and then transcribed into a clinical database, you can remove the work step data transcription, since it no longer adds value to the process. Of course, you cannot always know if there any activities that can be obliterated, but this is, as mentioned above, part of the process analysis. Kai A. Simon 19:56, 28 April 2007 (UTC)

I was speaking for speculators who may read too much into just the diagram or glance at it. Maybe it's a case of too much information for the example instead of a case of missing information that I mentioned above. Maybe the diagram should have more generic examples like "step 1, 2, 3" or "Department A, B, C" instead of "Discover, Pre-Clinical Research, ect". Then there would be no reason for people like myself to speculate on how important the tasks are or if they can afford to be removed. Oicumayberight 20:23, 28 April 2007 (UTC)

Oh, I see, you may be right. :-) This diagram was a standard slide from one of my presentations. When I find the time, I will change it into a more generic diagram and replace it, even though I don't think it is a major problem, because the tasks as such are not labeled. And, let me assure that you will always find a task to obliterate. —The preceding unsigned comment was added by Kai a simon (talk • contribs) 23:22, 28 April 2007 (UTC).

REBUS

it's REBUS APPROACH the same thing? http://www.citeulike.org/user/wigelius/article/1526778 --151.53.234.136 14:36, 25 October 2007 (UTC)

The WP article describes the phenomenon BPR as such, whereas as the article behind the above link describes a research approach used to analyze BPR projects. Kai A. Simon 20:58, 25 October 2007 (UTC)

Suggest to move Section: BPR - a rebirth of scientific management?

In my opinion, the first 70-90% of what is written in this section should be summarized. The section should start off with, (i can't remember the exact terminology) "This section is a stub of a longer article", and be referenced to either Taylor and/or Scientific Management.

It gives too much background and historial information that is so off the point from BPR it gets the reader a bit lost. I read it twice just to figure out if i was i was actually reading something that was still very directly pertinent to BPR. I felt I should leave it to discussion and further suggestions / opinions. Thanks. --Pointblankstare (talk) 22:27, 19 December 2007 (UTC)

Of course, the section would also fit into a discussion of Taylorism or Scientific Management. So would any other discussion of an organizational concept that relates to these topics. However, to understand my reason for putting it here, you need to consider the criticism against BPR that was brought forward around 12-15 years ago, when the concept was on top of the hype cycle. Back then, there was a strong opinion that BPR is merely more than a revival of Taylorism under a new label.

BTW, the section is not a part of another article and after having looked at the Scientific Managment article I am not sure, whether it would naturally fit in there.

Cheers, Kai A. Simon (talk) 01:37, 31 December 2007 (UTC)