Embed Size (px)
Citation preview
ARTICLE IN PRESS
0925-5273/$ - se
doi:10.1016/j.ijp
�CorrespondiE-mail addre
Int. J. Production Economics 113 (2008) 914–927
www.elsevier.com/locate/ijpe
Integrating the global enterprise using Six Sigma: Businessprocess reengineering at General Electric Wind Energy
Sanjay Goela,�, Vicki Chenb
aSchool of Business, BA 310b,University at Albany, SUNY 1400 Washington Avenue, Albany, NY 12222, USAbGeneral Electric Energy, 1 River Road, Schenectady, NY 12345, USA
Received 1 September 2006; accepted 1 December 2007
Available online 23 December 2007
Abstract
This paper describes the risks involved in business process reengineering (BPR) when a large enterprise company
acquires small fast-growing companies to power its own growth engine. Integration of business processes across disparate
organizations with different cultures requires careful planning and involves process automation, globalization, system
selection, downsizing, and information security. It is important to streamline and automate processes in order to improve
efficiency and reduce operating cycle times. Ideally, during reengineering, processes should be built from scratch based on
evolving business needs, changing market conditions, as well as innovations in technology. Business realities, however,
often force organizations into redesigning peripheral business processes while keeping the core process intact. This helps
avoid disruption of organizational operations and allows for more flexible time constraints during implementation. Several
compromises must be made during this redesign. This paper presents a framework for BPR using a structured analytic
approach to make business decisions. The paper discusses the case of BPR at General Electric Energy’s Wind Division to
integrate business operations across its globally dispersed acquisitions. The effort involved defining metrics for redesign,
identifying alternate tools and processes, and evaluating the alternatives through those metrics employing Six Sigma
methodology. The goal of this work is to demonstrate our approach that abstract best practices for process integration
across global engineering corporations developed over time at General Electric.
r 2007 Elsevier B.V. All rights reserved.
Keywords: Security; Risk analysis; Information assurance; Business process reengineering (BPR); Six Sigma; General Electric
1. Introduction
Large corporations often make strategic acquisi-tions of startup or small high-growth companies inorder to achieve higher growth rates. Following suchacquisitions, disparate processes across the business,e.g., finance, engineering, marketing, and humanresources need to coalesce into a streamlined mono-
e front matter r 2007 Elsevier B.V. All rights reserved
e.2007.12.002
ng author. Tel.: +1 518 442 4925.
ss: [email protected] (S. Goel).
lithic process. The objective of business processreengineering (BPR) is not only to improve costand performance, but also to meld organizationalcultures and impose parental controls on theacquired business. Mergers offer a tremendousopportunity to improve efficiency and reduce oper-ating costs through consolidation of activities,streamlining of operations, and integration of busi-ness processes. Barriers to successful integrationinclude divergent organizational cultures, poor com-munication, incompatible processes, and language
.
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927 915
problems. If BPR is not properly performed,resulting integration can disrupt operations, impedeproductivity, hurt employee morale, and stiflegrowth. Unanticipated organizational changes canthreaten the very success of the integration effort(Orlikowski and Hofman, 1996). Careful planningand analysis is essential for a smooth, uninterruptedtransition to the new business processes. This paperdiscusses the conundrum that organizations face intemporarily disrupting current activities and hurtingshort-term profits versus rebuilding for futuregrowth.
Unless BPR is performed in a systematic andrationale manner, it is just as easy to createpermanent damage to reliability, profitability, andefficiency in the organization. Based on the experi-ence at General Electric (GE) through severalsuch endeavors a set of best practices has emerged.The following stepwise approach is typically carriedout in such integration efforts. The first step is tocreate a road map for process integration and toidentify all the issues and business requirementsinvolved in the current process. The second stepis to determine the root cause of the issues thatwere identified, understand their business impact,and identify alternate options. Based on theidentified solutions a cost–benefit analysis is per-formed for the different options. Based on theanalysis, a comprehensive process is defined andtools are selected, process risks are analyzed, andcontrols are introduced. Significant due diligenceand effort are required, however, this initial effortpays huge dividends by preventing subsequentproblems in the redesigned process. Process reengi-neering efforts in the recent past have relied ontechnological advancements to automate businessprocesses and improve performance (Venkatraman,1994; Brynjolfsson and Lorin, 1996). Therefore,it is understandable that particular attention shouldbe paid in ensuring information systems functionproperly while maintaining (or improving) thebasic infrastructure. In attempting to improveoperational efficiency the risks associated withexposure of critical data in information systemsused to model business processes should not beignored. On the one hand, process automationincreases productivity; on the other hand, it expo-ses the organization to threats from maliciousinsiders, competitors, and hackers. In certaincircumstances, the tools and processes that shaveoff cost and time expose the company to seriousliability.
A company engaged in BPR after an acquisitionaims to ensure continuity, reduction of costs,improvement of productivity, and synchronizationof business operations. To achieve these objectives,companies perform extensive cost–benefit analysesboth for process refinement and tool selection.However, due to additional upfront costs andcomplexity, information security issues are seldomincorporated in these analyses and are usuallyrelegated to information technology implementa-tion once the BPR decisions are complete. While webelieve that there is great benefit in incorporatingsecurity considerations early on during the BPRprocess, the consequent complexity that inevitablyensues may be too high given that the literature haslittle to offer in terms of best practices ormethodologies for handling such security issues.
The paper analyzes a BPR effort at GE Energy’sWind Division to elucidate the challenges associatedwith including information security considerationsin the BPR process and the compromises that weremade. While we were not able to incorporate formalinformation security risk analysis in the BPRprocess, information security was included as ahigh-level metric in the decision-making for toolselection.
BPR is a complex organizational–technical pro-cess and close observation of the dynamics involvedin the entire process as well as evaluation oftechnical decisions was required. In conjunctionwith performance metrics data collection, an em-pirical action research methodology was employedfor this work. One of the authors led the BPR effortfor the division and overtly engaged in the interac-tions among consultants, staff, managers, and ITexperts. Action research has been established asa legitimate research approach in informationsystems literature (Baskerville and Pries-Heje,1999; Baskerville and Wood-Harper, 1996, 1998).
The paper follows the reengineering effort fromconception to completion and provides an in-depthview of the process. First, the business case andanalysis of process reengineering in relation to thegoals, vision, and metrics of the organization wherea detailed structured approach based on Six Sigmamethodology (Mikel and Schroeder, 2000; Pandeet al., 2000) are described. Subsequently, businessdecisions made in selecting tools based on cost–be-nefit analyses are discussed. Tool selection decisionsare discussed in context of technical, organizational,and political constraints. This paper makes severalkey contributions to the literature and offers a more
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927916
detailed structured approach than currently exists.It presents a case study that highlights the difficultyglobal organizations have in BPR. In the Internetage, BPR and information security are inseparable.The issue of incorporating information security inBPR is also briefly discussed though a detailedsecurity risk analysis is beyond the scope of thispaper. The paper is organized as follows: Section 2presents our methodology; Section 3 describes thereengineering methodology; Section 4 discusses thecase study; Section 5 presents discussions; andSection 6 presents our conclusions.
2. Literature review
The literature in the area of BPR is very diversewith significant work in the practitioner literature.A brief review of the literature is provided here withspecific focus on the security aspect. The concept ofBPR first emerged in early 1990s with the works ofDavenport and Short (1990), Hammer (1990, 1996),Harrington (1991), and Hammer and Champy(1993), Davenport (1993), Johansson et al. (1993),Klein (1993), Dixon et al., 1994, Manganelli andKlein (1994), and Ovans (1995). All offer differentdefinitions of BPR. The most commonly useddefinition comes from Hammer and Champy(1993), who define reengineering as the redesign ofbusiness processes to dramatically improve perfor-mance in terms of cost, quality, service, and speed.Researchers, including Hales and Savoie (1994),Irani et al. (1997), Farmer (1993), and De Bruynand Gelders (1997), have extolled the virtues ofBPR. The success of BPR has been widelypublicized, while the more serious failures havenot. Caron et al. (1994) report a 50% failure rate,Murphy (1994) a 70% failure rate. Holland andKumar (1995) report that 60–80% of such effortsare unsuccessful, while Hammer (1996) and Cham-py (1995) claim that 70% of companies obtain nobenefit. One explanation for this is that seriouslytroubled companies often consider BPR to be thesolution to all their woes (Fitzgerald and Murphy,1996). In such cases, however, the problems run fardeeper than what can be fixed by reengineeringalone. Davenport (1994) suggests that in order tomaximize the benefits, reengineering should beintegrated with total quality management.
Effective BPR involves understanding existingprocess defects, identifying sources of inefficiency,and redefining processes to increase efficiency ordecrease errors. In the past, reengineering focused
on automating existing manual processes whileleaving the process flow intact, resulting in smallincremental gains in productivity (Fitzgerald andMurphy, 1996; Davenport and Stoddard, 1994). Tofurther improve performance and cost, radicalchanges to tactical and operational processes andthe procedures, policies, structures and infrastruc-ture that support them are required (Giaglis et al.,2000). According to Hammer (1990), using agrounds-up approach incorporating best practicesand leveraging new technologies allows for max-imum flexibility in process redesign. It is not feasibleto reengineer processes from scratch since existingoperations must continue during the reengineeringprocess and the data information security must bemaintained during all phases of the transition (Gosset al., 1993). Instead, greater efficiency and securitycan be achieved through other means, including:automating the process (or part of it), usinginformation technology; improving existing toolsor acquiring new ones; and simplifying controls inexisting processes. Hall et al. (1993) describes howshort-term narrow focus process improvements canlead to long-term profits. Guimaraes et al. (1997)presents critical success factors for BPR andoutlines issues that should be addressed duringimplementation. A crucial element is gatheringintelligence from available sources, e.g., processowners, consultants, IT security, and the literature.This helps designers understand current processesand make informed choices in selection of tools andprocedures. Ultimately, the success of such effortslies not only in careful technical analysis, but also inensuring that the employees directly affected em-brace the reengineered process.
To successfully implement reengineering projects,companies need to follow a systematic approach(Andrews and Stalick, 1992). Although there is noset formula (Caron et al., 1994), several differentapproaches have been proposed. Evans (1993) usesa bridging metaphor to describe a broad frameworkfor BPR projects. He proposes a four-stage process:(1) defining vision; (2) outlining the current businessprocess; (3) creating a plan for the redefined process;and (4) implementing the plan. This seems feasiblebut provides little insight into how the new processshould be designed. Fitzgerald and Murphy (1996)outline a six-step process with interactive feedbackloops. Their approach includes selecting a processand establishing a process team. Though slightlybetter, it still offers little refinement in the area ofprocess reengineering and did not address the issues
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927 917
concerning information security. It is extremelyimportant not only to have a clear vision and goalsbut also to have crisp, quantifiable metrics (Croweet al., 2002) so that the progress of the reengineeringeffort can be measured.
Reengineering the public sector has also beenwidely discussed (Corbin, 1993; Davenport, 1994;Kettl, 1993; Miller, 1994; Moe, 1994; Malhotra,1998; Thong et al., 2000) and several US govern-ment agencies, however, have taken a lead infostering public sector reengineering efforts (GAO,1997). The US Department of Defense (DoD, 2004)has defined a process for strategic and businessplanning, especially as it pertains to BPR. Theyhave developed tools and techniques that can beused to define, analyze, develop, and implementstrategic organizational and business plans. Theyfollow a structured methodical approach similar tothe approach presented here but they do notconduct statistical analysis nor do they incorporateinformation security risks. Instead they createchecklists for facilitating specific reengineeringmissions, such as, environmental liabilities recogni-tion (DoD, 2006). Despite the availability ofmethodologies in the literature there is considerablerisk in reengineering projects. Several frameworksas well as best practices for business processredesign are presented in the literature, notablyJablonski and Bussler (1996), Berio and Vernadat(2001), Seidmann and Sundararajan (1997a), andMansar and Reijers (2005). They are howeverpresented at a conceptual level. In this work, wepresent a case study that actually defines the metricsand employs a metrics-driven methodology basedon Six Sigma that manages reengineering risks indecision-making at each step. Case studies such asthis one can help other organizations understandthe subtle nuances of this process.
Process Redesign
Define Vision
Create Process Metrics
Analyze Process
Redefine Process
Process Controls
Tool Selec
Identify To
Create Tool
Analyze T
Select To
Revision C
Fig. 1. Process reeng
3. Reengineering methodology
Decision makers may find it difficult to chooseamongst the various alternatives when integratingbusiness processes from different organizations.They often have to contend with sparse andinaccurate data that emanates from the variousorganizations, all of whom have a stake in promot-ing their tools and processes. A rational riskanalysis is seldom used to evaluate the merits ofprocess integration and return on investment lagsbehind expectations in the majority of cases. This, inlarge part, is due to inadequate recognition of theinterdependence among technology, practice, andstrategy. Researchers Crowston and Malone (1988)and Barua et al. (1995) have recognized the criticalrole that interdependence plays in affecting out-come. Milgrom and Roberts (1988) describe howpoorly understood interactions among the compo-nents of a system can prevent successful implemen-tation of a complex business process. To ensuresuccessful implementation, a rational analysis of therisks involved in process integration must beconducted in order to ensure current survivabilityas well as future gains in productivity. Themethodology presented in this paper presents astructured approach to facilitate the decision-mak-ing process (see Fig. 1). In step one, metrics aredefined and the process is analyzed and refined. Instep two, different tools are identified and analyzed.
3.1. Process redesign
Process redesign involved mapping the existingprocesses and then streamlining the processes tooptimize operational efficiency. This redesign wasdone using the Six Sigma approach, which is a rigo-rous data-driven approach that utilizes statistical
tion
ols
Metrics
ools
ols
ontrol
Security Analysis
Define Security Goals
Value Assets
Identify Vulnerabilities
Determine Threats
Select Controls
ineering steps.
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927918
analysis to measure and improve organizationalprocesses. This approach has been institutionalizedthroughout the company to manage process andproduct quality. By definition, Six Sigma quality isachieved when process errors are reduced to lessthan 3.4 per one million opportunities. An error isan instance when a process metric falls outside thenormal range of specification. The basic philosophyof Six Sigma is that: ‘‘if you can measure it, you canimprove it’’. This approach entails creation ofquantitative metrics for processes, which itself canlead to ambiguities in the computation of qualitymetrics. Six Sigma toolkit includes several tools thatassist users in managing risks and making decisions,including (1) design for Six Sigma (DFSS); and‘‘define’’, ‘‘measure’’, ‘‘analyze’’, ‘‘improve’’, and‘‘control’’ (DMAIC). Both of these tools areimplemented using a spreadsheet that is called the‘‘Pugh matrix’’. Pugh matrices are particularlyuseful for integration of multiple processes as wellas selection of tools and technologies. The processRedesign includes the following five steps: (1)
Table 1
Definition/
planning
Measurement Analysis Process desig
Business
requirement and
problems
Detailed project plan Benchmark
solutions
analysis
Project summ
Mission/scope
identify key
success factors
Process map Process design
analysis
Identify key
project succe
Build a team Customer
requirements
High-level
systems
integration
needs
Define busin
policy and o
changes
Multi-generation
plan
Critical to quality
measurement
Performance
targets
Vendor selec
(if required)
Define cost and
benefit
Data baseline Data quality Outline spec
requirements
Project plan Infrastructure
assessment—
hardware and
network
Detailed fit and
gap software
analysis
Risk related
new process
Communication
plan
Security assessment Root cause
analysis
New process
map
Legal
requirements
Secure funding Cost/benefit
analysis
Training pla
Risk
assessment—
security risk
Security
measurement
Security risk
analysis
Security fact
for success
Review/approve Review/approve Review/approve Review/appr
creating metrics; (2) weighing metrics; (3) identify-ing the baseline; (4) rating different options; and (5)selecting processes. During the consolidation phase,the best process chosen for each step is used toconstruct the final integrated process. In case of aconflict, e.g., processes from two divisions have thesame quality metric; rationalization is based onsecondary factors such as cost and culture.
DFSS facilitates gathering of specifications fromstakeholders and assists in evaluating differentoptions for creating the new process. DMAIC isused to measure the behavior of existing processes,and to improve, monitor and control them to ensureefficiency. Using Six Sigma methodology, the BPRis a multi-step process, as shown in Table 1. In theDefinition/Planning phase, the purpose and scope ofthe project are defined and background informationis obtained. A problem statement, goal statement,constraints, assumptions, and project plan areoutlined; a high-level process map and list of criticalto quality factors (CTQs) is also generated. In theMeasurement phase, process metrics are defined and
n System design Building, testing
and verification
Control
ary Hardware, software
prep, and
construction
Detailed training
plan
Launch pilot/beta
release
to
ss
New infrastructure
assessment
Coding Transition
application to
production
ess
rg.
Design issues and
strategies
Build
infrastructure
Transition
application to
business owners
tion Architecture design System integration
test
Train end users
ific Overall software
test strategy
Rollout plan Establish and
implement control
procedures
to User interface Implement
business policy
and org. changes
Production launch
Define support
strategy
User acceptance
test
Identify and
resolve post
production issues
n Application/help
manual
Vendor service
agreement
Verify key success
factors
ors Resolve legal
requirements/
security weaknesses
Test interfaces and
conversions
On-line
documentation
ove Review/approve Review/approve Review/approve
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927 919
baseline analysis is conducted to define projectgoals. In this phase, the problem statement isfurther refined and root cause analysis is used toidentify potentially defective areas. In the Analysis
phase, statistical methods and tools are used tofurther analyze root causes of defects; the processitself is analyzed in order to identify inconsistenciesor problem areas. We have incorporated securityrisk analysis as a part of this step. The improvementphase consists of: (1) process design; (2) system
design; (3) building, testing, and verification. Thisphase focuses on remedying the problems and isusually technologically intensive. Once improve-ments are made, the process needs to be controlledto ensure that problems do not recur; hence, theControl phase, which involves monitoring on acontinuous basis. By combining risk analysis withSix Sigma methodology, the reengineered businessprocess can be measured, analyzed, and improved;at the same time, security risks can be analyzed andcontrolled.
3.2. Selection of tools
Once a comprehensive reengineering process hasbeen defined, intricate details of the solution can bedeveloped, such as choosing the right tools, analyz-ing process risks and introducing controls. BPRefforts often fail because of poor tool selection andinadequate risk analysis. Tools are often toosimplistic; they neither capture the dynamics of thebusiness process nor are they able to adequatelyrepresent organizational knowledge. Sometimes,they are so complex that they prevent domainknowledge and intuitive judgment from being usedto solve business problems. A complex tool may actlike a black box, preventing users either fromrecognizing limitations when the tool is used outof context or from identifying errors propagatingdownstream from an inadvertent mistake. Businessprocesses are constantly evolving due to changingtechnology and legislation. Most traditional auto-mation tools are best suited to automation of staticprocesses with fixed inputs, outputs, and rules.Static business processes, however, hinder innova-tion and sometimes lead to a competitive disadvan-tage. In addition, a majority of BPR efforts focus oncost, speed, and logistics without considering hu-man behavioral factors. Behavioral modeling re-veals how business processes operate (Hansen,1994) and is, thus, essential for identifying propertools. Lastly, security and integrity of data should
be primary considerations in tool selection; thesemust not be treated as mere implementation details.
The tool selection process demands carefulplanning, clear specification of business require-ments, and a precise definition of tool metrics. Oncebusiness requirements have been identified, afeasibility study should be conducted to ensure thatthe tools selected meet functionality requirements.Once a short list of tools has been created, each oneshould be analyzed and ranked using the toolselection metrics. The metrics for tool selectionshould include change management challenges,business reengineering alternatives, usability con-siderations, security considerations, and mainte-nance needs. If several different types of tools arebeing considered, their compatibility must beexamined prior to selection. In such cases, theaggregate value of the entire group should beranked against that of other such groups. A SixSigma approach—Pugh matrix can also be used inthe tool selection process (see Fig. 2). Once the righttool has been selected, the final step is to analyzerisks associated with the tool and initiate revisioncontrols.
4. Case study
The research presented in this paper is based on acase study at GE Energy, which acquired severalnew wind turbine businesses and attempted tointegrate business processes across different divi-sions. Power generation is an extremely competitivefield, but GE considers it a core business in which itwould like to maintain its leadership position. It,too, is a cyclical business and GE is looking fornovel ways to maintain growth. Alternate sources ofenergy, particularly wind energy, provide one suchopportunity. In 1973, the oil crisis prompted the USgovernment to seriously consider investing in windenergy and solar power; large tax breaks were givento windmill farms and to corporations, which inturn, made significant progress in this field. Declin-ing government interest and investment has scaredoff many would-be investors. The current energycrisis, however, has rejuvenated worldwide interestin wind energy. In the past 15 years, the wind energyindustry has grown by 25–30% per year (GE Wind,2007). In Denmark, wind energy accounts for 20%of available electricity; in Germany it accounts for5.9%. The US federal government’s recent exten-sion of the Renewable Energy Production TaxCredit (PTC) provides a strong impetus for invest-
ARTICLE IN PRESS
List CriticalBusiness
Requirements
ListExisting Tools
AnalyzeFunctionality &
Architecture
Gap Analysis forTools (Capabilityvs. Requirement)
Rank Tools Basedon Requirements -Pugh Matrix (PM)
Identify Technical &Cultural Problems in
Selecting Tools
Populate PMfurther based on
Gap Analysis
Selected two highScored tools
AnalyzeImplementation
Cost (As-Is)
Compute Cost forTool Upgrade to
meet requirements
Cost BenefitAnalysis for Final
Tool Selection
Business SecurityRisk Analysis
Identify Experts to Evaluate Different
Tools
Create Roadmapfor Tool
Integration
Fig. 2. Six Sigma-based approach to tool selection.
S. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927920
ment in wind energy. While wind energy currentlyamounts to less than 1% of US electric production,the goal is to increase that figure to 6% by the year2020.
It acquired its wind power business from Enron in2002. Enron had two separate divisions in Califor-nia and Germany, to which it added acquisitions inUS, China, and Spain. Enron had failed to integrateits tools and processes. In addition, the Californiadivision maintained one set of tools and processesand the German division another. GE also had itsown tools and processes prior to its acquisition ofEnron’s wind power business. Consequently, GEwas saddled with three separate, uncoordinated setsof tools and processes. As a result, the threedivisions had to communicate manually, whichproved to be inefficient and expensive due todata integrity issues. To improve efficiency andreduce costs, it was decided to reengineer the windenergy business process and integrate processesand tools.
4.1. Process redesign
After making these acquisitions, GE Energy’sWind Division continued to operate functionally asa holding company for multiple, autonomous units.Issues such as inaccurate or incomplete bills of
materials (BOMs), delays in shipment, and poorquality forced it to reevaluate its business model andopt for a more synergistic model with an integratedbusiness process across all divisions. Developmentof a BOM generation process was the first processtargeted for reengineering. This subsection presentsan analysis of the BOM process using data forturbines manufactured during the 2003–2004 pro-duction run. Problems encountered in the originalprocess, the reengineering approach, and the rede-signed process are discussed. A statistical compar-ison of the original and reengineered processes isalso presented.
4.1.1. The BOM problem
BOM is a critical component of the product lifecycle; it lists the subassemblies, intermediate parts,and raw materials that go into a parent assembly.Manufacturing activities that originate in BOMinclude material resource planning, inventory con-trol, and production scheduling. Any problem inBOM can cascade down through subsequentprocesses and cause cost overruns and delays inshipment. Since the margins on wind turbines arethin, rework often results in a loss. In the 2003–2004production run, the requisition team at GE Windworked on designs that had delay-causing problemsin their BOMs. More than 150 Engineering Change
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927 921
Requests (ECR) were generated during this period.Since each ECR affects multiple subassemblies,errors were propagated through several processes,resulting in inventory overages and parts shortages.The order to remittance cycle was ultimatelyaffected, causing delays, premium delivery freightcharges, and damages for breach of contract. Therefined BOM process shown in Fig. 3 is a nine-stepprocess. Potential problems associated with eachstep, e.g., information integrity, communication,and notification failures, are indicated in theProblems box (below).
Commercialoperations providesthe go ahead to out
order requirement tothe GMS for theidentified project
High levelconfiguration is
manually extractedfrom CMS to theGMSL (monthly
update)
GMS obtain deliveryschedule fromCommercialoperations
GMS uploads highlevel configurationmatrix to Support
Central
Production planner manually extractsthe GMS high-level configuration from supply central and checks for
any special requirement. Also obtainsproduction start and end dates and
dispatches to MRP
MRP creates thevariant only for inside
(Nacelle), hub andconverter and sends itto production planner
Production entersstart and end date
and enters thevariant of BOM into
DF/GSB
Execute the processin DF/GSB to
create work order
P5
P3
P7
P9
Monthly QMIMeeting
Review the next 12months outlook
based on COOL andGMSL
P1
Fig. 3. Current business process and
4.1.2. Root cause analysis
In order to reengineer the process more data werecollected; 14 key BOM problems identified in the2003–2004 production run are listed below. Solu-tions to each of these problems follow (in italics).
(1)
P6
P4
P8
P2
infor
No primary BOM owner in the Americas(Need to define owner).
(2)
Insufficient tools within system (Need tocreate/select better tools).(3)
Supply chain sometimes drives configuration;use of old material (Need correct BOM).Problems:P1– Lost opportunity if problems notanticipated during this reviewP2– Manual communication between CMSand GMSLP3– Without proper review, commercialoperator approves ordering the material usingInaccurate & Incomplete BOM definitionP4/P5– High level configuration anddelivery schedules are updates from theproject manager database for projects thathave gone through a release meeting.Information handoff directly from sales toproject manager with out any involvementfrom engineeringP6/P7-Product planner and MRPcommunicate back and forth for theinformation without engineering inputP8/P9- Customer order information sent toMRP database and create work order. At thistime, manufacturer has already startedbuilding the turbine and errors go unnoticedand unresolved leading to poor quality ofproduct to customer.
Abbreviations:QMI – Quick Market IntelligenceCOOL-Commercial Operator ListGMSL-Global Master Schedule listCMS - Customer management SystemGMS – Global Master ScheduleMRP - Material Resource PlannerBOM – Bill of MaterialPPB – Production Policy BoardC&CE – Cost cycle estimateDF – US MRP systemGSB – German MRP system
mation integrity defects.
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927922
(4)
Items are not interchangeable with regard tofit, form and function (Need to correct BOM).(5)
High number of inactive BOMs (Need toidentify and fix problems).(6)
BOMs are not defined for global market in newproduct introduction (NPI) (NPI team needs tobe involved).
(7) ECR process does not entail creation/valida-tion of new BOM after change is approved(Need proper review process).
(8)
No closed loop second party review of BOMprior to release on live side (Engineering andmanufacturing need to work as a team).
(9) No good baseline BOM; errors migrate intonew configurations (Need to build standard
BOM).
(10) Process of new component introduction poorlydefined (Need NPI to define the new compo-
nent).
(11) Flat BOM makes errors hard to spot (Need todevelop a clear hierarchical model).
(12) BOM entry in system is highly manual (Need tostart automation efforts).
(13) BOM definitions are not part of NPI scope(Administrative change required to add this towork scope of NPI).
(14)
NPI process does not entail creation of GlobalBOM as part of NPI tollgates (Need to definetollgates).
The histogram of defects in Fig. 4 shows thefrequency of each of the 14 causes listed above. Thesolid line shows the cumulative percentage count;here we see that cause numbers 1, 2, 9, 11, and 12account for 70% of all defects. The most significantproblem, i.e., that BOM lacked a primary owner,
Pareto of BOM
242 236213
158
11593
7
0.18
0.35
0.50
0.620.70
0.770.84
0.
0
50
100
150
200
250
300
1Cause,
Freq
uenc
y
2 9 11 12 13 6 8
92
Fig. 4. US problem Pare
had a frequency of 242. The second most importantproblem, i.e., inadequate tools, had a frequency of236. The third most important problem, i.e.,absence of good baseline BOMs, had a frequencyof 213. It is relatively easy to address the firstproblem by refining the process and assigning anowner to each BOM. The second problem is thehardest and most expensive since it typicallyrequires reengineering tools. The third problemstems from lack of NPI involvement in constructingthe non-standard BOM but can be remediedthrough process refinement. A management teamwas convened to address this issue; the team agreedto assign specific managers to different BOMs (andsub-BOMs). A team of core engineering staff met toaddress the issue of tool reengineering; their findingsare discussed in Section 3.2. To address the issue ofa ‘‘Flat BOM’’, each owner has to understand theBOM structure, create a proper hierarchy andensure accuracy. The fifth most important error,i.e., manual input, is a tool-related issue and will bediscussed in the section on Section 4.2. Theremaining problems are related to the processesand tools used in the creation of BOMs. Systemswere old and inefficient but the company chose touse existing tools to minimize process disruptionand reduce training costs.
An analysis of the tools and processes related toBOM sheds light on several serious problems; someexisted before acquisition by GE while others aroseas a result of the merger. These issues, together withroot causes, business impacts, and potential solu-tions, are identified in Table 2. Resolution wasessential prior to global integration of businessprocesses. The resolution effort was divided intothree phases. Phase I focused on centralizing the
Defects
7 72
3625
8 4 0
890.95 0.97 0.99 1.00 1.00
x
0
0.2
0.4
0.6
0.8
1
1.2
Cum
mul
ativ
e C
ount
, %
14 4 10 7 3 5
1.00
to of BOM defects.
ARTICLE IN PRESS
Table 2
Issues/problems Root cause Business impact Solution
Pre-integration problems
No unique process in each site No process to follow Manf. and sourcing will order the wrong
material/delay turbine delivery
Fix process
No PLM system Legacy system No unique data storage Build product life
cycle central (PLM)
Tool cannot meet requirements Tool too old Too many manual processes Generate new tools
Too many manual processes,
human errors
No tool available Data integrity, no control New control and
review security issues
Integration issues
Multiple processes and tools No standardization among
multiple sites
No communication between each sites/
cost/errors
Develop common
tool and process
Unable to link CAD data to
product definition in BOM
Multiple systems and too many
manual processes
Technology must maintain separate data
bases for product definition and CAD
data
Develop common
tool and process
Unable to accurately relate
valid customer orders to a
unit’s quoting limit
Tool not available in either
new or old systems
Comm. Ops, sales, ARE teams unable to
associate specific customer orders with a
particular unit type or configuration
Implement a proper
tool to support this
function
Unable to link F&O config to a
customer’s BOM
Not available in old/new
systems
ARE, Mfg teams unable to analyze
impact of F&O changes to orders in
pipeline
Find tool support this
function
Cannot link a serialized unit to
an ECO, assembled BOM,
work order and re-assigned
assay BOM
Tool not available in either
new or old systems
ARE, Mfg teams unable to analyze
impact of ECO, EFN, WO and others to
orders and fleet units as well as capture
As-built configurations by pad number
Implement a proper
tool to support this
function
S. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927 923
manufacturing and reengineering process in the US.Phase II focused on European processes and toolsissues. Phase III focused on the creation of a singletool and process across all divisions. The last phaserequired fundamental tool issues to be resolved,communication across divisions to be seamless, andprocesses to be consolidated across the US, Europe,and Asia. In addition, security concerns needed tobe incorporated into the BPR efforts.
4.2. Tool selection
To improve business processes it is often neces-sary to reengineer tools along with the processes.While GE wanted to integrate tools and synergizebusiness processes across all power generationdivisions, the existing tools were not powerfulenough to meet the process requirements of theWind Division. It thus decided to create a new toolcalled PLM/PDM1 that would be compatible withthe reengineered process. Using Six Sigma metho-dology, existing tools were compared in order todetermine which suite of tools would work best.
1PLM/PDM is a combination of two processes: product
lifecycle management and product data management.
These tools are shown in Table 3; and a Pugh matrixwas used to rank potential solutions. It wasgenerally anticipated that different divisions wouldbe reluctant to provide objective opinions in orderto protect their own turf and avoid having to retrainemployees in the new technology. The wrongdecision, however, would have made matters worseby raising costs without adding commensuratebenefits. A team consisting of developers, users,and managers was quickly formed in order to selecttools. The team was led by the InformationTechnology group and was named the GlobalProducts Company (GPC). Their main goal wasto migrate the energy division to a common tool setthat would integrate best practices into the businessprocess. The group decided to use an existing powergeneration tool suite, (the Newton Suite) as thebaseline for comparison.
The 10 key criteria used for the Pugh matrixcomparison are as follows: integration, functional-ity, stability, scalability, manageability (administra-tion), enterprise change management, economy(cost of ownership and licenses), capacity perfor-mance, architecture, and security. Pugh matrixresults showed that the not yet fully developedPLM/PDM system rated highest, followed by the
ARTICLE IN PRESS
Table 3
Subject Newton Suite Wind EU/Asians tools/
system
Wind US tools/
system
PLM/PDM
Reporting system Control Point Summary NA NA NA
Resource management GEW, Times, TIM Manual Manual Primavera
Product configuration
management
Window sticker, Pegasus,
AutoBoM
XLS file XLS file PLM/PDM (Product Central)
BOM control eBOM GSB DataFlow Engineering Central
Change control eBOM, DCI ECR ECR Engineering Central
Document management DART ERDB ERDB Engineering Central, Document
Central
Service tool eService NA NA NA
CommOpp tool CMS NA NA NA
Table 4
Business impact/
risk of Newton
suite
implementation
PLM/PDM team/
users
Newton Suite teams/
users
Process Process integration
with Newton process
None
Funding Reprioritize funding
and place
development on hold
Reprioritize funding;
re-evaluations
required for all tool
sets
Business impact Customer fulfillment
impacted during
bubble (2000 new
units wind orders),
impossible to migrate
users to Newton
overnight
None
Leadership Negative impact on
leadership credibility
and reputation
Need help to form
core teams to bring
the new users on
board
Cost $3M+ loss in PLM/
PDM spending
Reprioritize funding
dollars
Technology Move into worked
but old/new mixed
tools
No changes
S. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927924
Newton Suite, the acquiring department’s Europeantool (GSB is a manufacturing tool), and finally, theacquiring department’s US system (Dataflow is aUS manufacturing tool). PLM/PDM ranked high-est because it is a web-based tool in which modernsecurity functions are embedded. The Newton Suiteranked second because it embodies several tools andis well accepted in the business. In the NewtonSuite, manufacturing and resource managementtools are based on the IBM mainframe, whileconfiguration tools are web-based. The latter helpedthe Newton Suite rank second. The GSB andDataFlow systems have several weaknesses. Firstthey are limited to manufacturing functions only.Second, their software must be loaded onto localmachines and servers to be used. Third, GSB andDataflow do not have Enterprise Change Manage-ment role and finally they lack information securityfunctions. In summary, these are old tools andtechnologies that do not compare favorably with themore modern alternatives. Newton Suite and PLM/PDM, thus, became the common tool solution. Wenext present a step-by-step analytical evaluation ofthese tools. Some of the values were extracted fromthe Pugh matrix. It is clearly more expensive andmore time consuming to implement PLM/PDMthan the Newton Suite. Tables 4 and 5 present theseresults from the perspective of the technical teams.
Thirteen of the 16 teams reporting to the Vice-President of the energy division currently use theNewton Suite; this amounts to some 3000 activeusers. The PLM/PDM system is not yet fullydeveloped, thus, there are no active users, only betausers. The risk of moving 3000 active users to theunknown system was simply too high and it wouldbe impossible to switch all of them to the new toolovernight (see business impact and risk analysis in
Tables 4 and 5). The Decision-Making team spent aconsiderable amount of time evaluating the cost ofboth short- and long-term moves to the PLM/PDMsystem. Financial considerations forced the com-pany to give up the PLM/PDM system even thoughit embodies more modern technology.
The Information Management and Technologyteam summarized other reasons for not moving tothe PLM/PDM system. First, there is no technicallycompelling reason to move 3000 engineers away
ARTICLE IN PRESS
Table 5
Business impact/
risk of (PLM/
PDM)
implementation
PLM/PDM team/
users
Newton suite teams/
users
Process Need to integrate into
one process
Need to learn new
process
Funding Reprioritize funding;
re-evaluations
required for all tool
sets
Move all funding to
PLM/PDM
implementation
Training Need PLM/PDM
training due to tool
still under-
development
3000+ users need to
be moved to new
system; training
required
Cost Reprioritize PLM/
MGSP integration,
$3M will not have
been wasted
Fund migration of
3000+ users cost plus
tool ownership and
licenses cost
Technology Graduate move away
from GSB & dataflow
Move out of IBM
main frame use
S. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927 925
from current process automation tools to the PLM/PDM system since the latter is based on the sameplatform, i.e., MatrixOne. Second, there is nofinancial benefit to justify migration to PLM/PDMsince GE’s engineering and related functional needsdo not fit within the constraints of the configura-tion. PLM/PDM requires extensive customizationto meet current and future functional requirements.Moreover, GE’s common PLM suite (eBOM PLMsystem) scores higher in the Pugh matrix than thePLM/PDM. Pre-existing architecture and technol-ogy standards and 3 years’ worth of applicationdevelopment causes eBOM to score higher than thePLM/PDM. Without specific, quantifiable andcompelling reasons, the eBOM–MatrixOne centralwas preferred. Thus, it was decided that usersshould remain in the current common PLMproduction environment.
During the tool selection process security wasfactored at a very high level, since the complexity ofthe problem would have made decision-makingvirtually impossible. During the tool selectionprocess responders were asked three questions:Does risk analysis match the company’s securitypolicy? Does it require authentication across multi-ple applications? Does it have role-based access toapplication functionality? This however is insuffi-cient for ensuring security of the system. Informa-tion security risk analysis must answer many otherquestions and must involve other stakeholders,
including information creators, information users,and information technology support groups. Secur-ity risk analysis should examine the entirety of thebusiness process, data access, data integration, userbehavior, and communication. To this end, adetailed risk analysis of the refined process wasperformed to identify the necessary controls in theredesigned process.
5. Discussions and future directions
Companies engage in reengineering of theirbusiness processes for several reasons, such as,improving efficiency, increasing productivity, andreducing time to market. However, reengineeringoften results in huge short-term costs that need to beamortized over several years through increasedfuture revenues resulting from the reengineering.Even though at the top level primary decisions arerelated to selection of tools and design of process,success in reengineering is often tied to suchintangible factors as formation of balanced teams,due diligence in selection of tools, periodic verifica-tion, and validation of work practices, and mostimportantly, definition of quantifiable metrics. Inaddition, adequate resources should be available tocommensurate with the effort. The approach pre-sented in this paper reflects the Six Sigma philoso-phy used at GE. Projects are divided into multiplesegments with clear quantifiable metrics for eachsegment. Such reengineering efforts are especiallydifficult in global organizations due not only totechnical inconsistencies in processes and specifica-tions, but also to legal and cultural issues.
Decision makers typically focus on parameterswith a direct payoff, such as cost and productivity,reflecting their own performance metrics. Theystruggle to evaluate non-tangible factors that donot have a direct payoff or have a high degree ofuncertainty such as employee morale or companyimage (Tomasko, 1993; Beugre, 1998; Seidmannand Sundararajan, 1997b).
The problem is especially insidious since man-agers often feel uncomfortable with informationtechnology and they have traditionally treated it asa tool designed merely to reduce their workload. Inthe current business environment, information is themost important differentiator that provides acompetitive edge. Proprietary engineering informa-tion regarding technology and business practicesforms the company’s core competence. Engineeringcompetence derives from years of expertise in
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927926
aircraft engine manufacturing and power generationand must be protected to maintain a competitiveedge.
The paper presents a case study of BPR at GEEnergy Wind Division after the acquisition of manyglobal businesses. Automation of storage andprocessing of information, poses several challengesto decision makers, such as, minimizing disruptionof activities, ensuring synergy among operationsaround the globe, reducing costs, protecting pro-prietary information, as well as ensuring legalcompliance. Integration is harder in a globallydistributed organization, due to different culturalvalues, disparate information systems, and differ-ences in legal environment. In addition, distributedorganizations engender higher risks of securityvulnerability.
Most organizations operate in a reactive modeand only address security problems as they areuncovered. It is quite evident that security should beintegrated in the business processes during theredesign rather than as a patchwork of controls tofix security problems after incidents. However, it isnot always feasible to incorporate detailed securityanalysis during initial decision-making due to thecomplexity involved. Consequently, security is usedas a high-level metric during BPR and controls aredecided during implementation. In subsequentwork, we intend to show a detailed security analysisof the redesigned process.
6. Conclusions
This case study describes the process of businessprocess reengineering. The study shows how largeglobal corporations with multiple sites can accom-plish reengineering efficiently through a structuredmethodical approach. For successful reengineeringefforts due diligence is necessary to prevent futureproblems. The overall objective of reengineering isto define the business process and select appropriatetools such that the process requirements are satisfiedand cost and productivity goals met. Corporationsroutinely engage in BPR where a large number ofsuch endeavors fail often due to a variety of reasonsincluding lack of due diligence.
The study highlights the reengineering processbased on a repertoire of Six Sigma tools that areused at General Electric. These tools employstatistical analysis to track the quality and perfor-mance of individual components of a process,product or service. The tools described here are
not black boxes that provide a solution but ratherinformation aggregation tools that improve trans-parency and provide decision makers with acomprehensive view of information that they canemploy during the redesign process.
Reengineering of business processes across dis-parate globally distributed subsidiaries is a difficultprocess that if done carefully can pay largedividends or can be catastrophic if done poorly.This case study will provide users with a structuredapproach to reengineering in context of globalacquisitions of large engineering firms. This canprovide valuable insight for organizations that haveembarked on a similar endeavor to make globalacquisitions and integrate them in their businesses.
References
Andrews, D., Stalick, S., 1992. Business reengineering. American
Program 5 (5), 10–19.
Barua, A., Sophie Lee, S., Whinston, A., 1995. The Calculus of
Reengineering. Department of Management Science, Uni-
versity of Texas, Austin.
Baskerville, R., Pries-Heje, J., 1999. Grounded action research: A
method for understanding IT in practice. Accounting,
Management and Information Technologies 9 (1), 1–23.
Baskerville, R.L., Wood-Harper, A.T., 1996. A critical pers-
pective on action research as a method for information
systems research. Journal of Information Technology 11,
235–246.
Baskerville, R.L., Wood-Harper, A.T., 1998. Diversity in
information systems action research methods. European
Journal of Information Systems 7, 90–107.
Beugre, C.D., 1998. Implementing business process reengineer-
ing: The role of organizational justice. The Journal of Applied
Behavioral Science 34 (3), 347–360.
Berio, G., Vernadat, F., 2001. Enterprise modeling with
CIMOSA: Functional and organizational aspects. Production
Planning and Control 12 (2), 128–136.
Brynjolfsson, E., Lorin, H., 1996. Paradox lost? Firm-level
evidence of the returns to information systems spending.
Management Science 42 (4), 541–558.
Caron, J., Jarvenpaa, S., Stoddard, D., 1994. Business reengi-
neering at CIGNA corporation: Experiences and lessons
learned from the first five years. MIS Quarterly 18 (3),
233–250.
Champy, J.A., 1995. Reengineering Management: The Mandate
for New Leadership. Harper-Business, New York.
Corbin, L., 1993. Reengineering: The next management revolu-
tion. Government Executive 25 (9), 26–32.
Crowe, T.J., Fong, P.M., Bauman, T.A., Zayas-Castro, J.L.,
2002. Quantitative risk level estimation of business process
reengineering efforts. Business Process Management Journal
8 (5), 490–511.
Crowston, K., Malone, T., 1988. Information technology and
work organization. In: Helander, M. (Ed.), Handbook
of Human–Computer Interaction. Elsevier, Amsterdam,
pp. 1051–1069.
ARTICLE IN PRESSS. Goel, V. Chen / Int. J. Production Economics 113 (2008) 914–927 927
Davenport, T.H., 1993. Need radical innovation and continuous
improvement? Integrate process reengineering and TQM.
Planning Review 22 (3).
Davenport, T.H., 1994. Managing in the new world of process.
Public Productivity and Management Review 18 (2), 133–147.
Davenport, T.H., Short, J., 1990. The new industrial engineering:
Information technology and business process redesign. Sloan
Management Review, Summer 11 (27).
Davenport, T.H., Stoddard, D.B., 1994. Rengineering: Business
change of mythic proportions? MIS Quarterly 18 (2),
121–127.
De Bruyn, B., Gelders, L., 1997. From TQM to BPR: Two case
studies in personnel administration. International Journal of
Production Economics 50 (2–3), 169–181.
Dixon, J.R., Arnold, P., Heineke, J., Kim, J.S., Mulligan, P.,
1994. Business process reengineering: Improving in new
strategic directions. California Management Review 36 (4),
93–108.
DoD, 2004. Planning for Business Process Reengineering. The
Electronic College of Process Innovation.
DoD, 2006. DoD business process reengineering: Environment
liabilities recognition, valuation, reporting requirements
document.
Evans, K., 1993. Reengineering and cybernetics. American
Programmer 6 (11), 10–16.
Farmer, J.R., 1993. Reengineering the factory. Production and
Inventory Management Journal 34 (1), 38–42.
Fitzgerald, B., Murphy, C., 1996. Business process reengineering:
Putting theory into practice. INFOR 34 (1), 3–13.
GAO, 1997. Business Process Reengineering Assessment Guide
/http://www.gao.gov/special.pubs/bprag/ai10115.pdfS.
GE Wind Website, 2007. /http://www.windengery.orgS.
Giaglis, G.M., Irani, Z., Hlupic, V., 2000. Managing information
and operations. Brunel University.
Goss, T., Pascale, R., Athos, A., 1993. The reinvention roller
coaster: Risking the present for a powerful future. Harvard
Business Review 71 (6), 97–108.
Guimaraes, T., Yoon, Y., Clevenson, A., 1997. Empirically
testing ES success factors in business process reengineering.
International Journal of Production Economics 50 (2–3),
245–259.
Hales, H.L., Savoie, B.J., 1994. Building a foundation for
successful business process reengineering. Industrial Engineer-
ing 26 (9), 17–20.
Hall, G., Rosenthal, J.J., Wade, J.J., 1993. How to make
reengineering really work. Harvard Business Review 71 (6),
119–131.
Hammer, M., 1990. Reengineering work: Don’t auto-
mate, obliterate. Harvard Business Review July–August,
104–112.
Hammer, M., 1996. Beyond reengineering: How the process-
centered organization is changing our work and our lives.
Harper Collins, New York.
Hammer, M., Champy, J., 1993. Reengineering the corporation:
A manifesto for business revolution. HarperCollins Publish-
ers Inc, New York.
Hansen, G.A., 1994. Tools for business-process reengineering.
IEEE Software 11 (5), 131–134.
Harrington, H., 1991. Business Process Improvement. McGraw-
Hill, New York.
Holland, D., Kumar, S., 1995. Getting past the obstacles to
successful reengineering. Business Horizons, 79–85.
Irani, Z., Sharp, J.M., Race, P., 1997. A case experience of new
product introduction within a once traditional subcontract
manufacturing environment. Production and Inventory Man-
agement Journal 38 (2), 47–51.
Jablonski, S., Bussler, C., 1996. Workflow Management: Model-
ing Concepts, Architecture and Implementation. Interna-
tional Thomson Computer Press, London.
Johansson, H., McHugh, P., Pendlebury, J.A., Wheeler, W.,
1993. Business Process Reengineering: Breakpoint Strategies
for Market Dominance. Wiley, West Sussex.
Kettl, D.F., 1993. Toward new governance: Making process a
priority. The LaFollette Policy Report 5 (2), 1–2, 18–19.
Klein, M.M., 1993. IEs fill facilitator role in benchmarking
operations to improve performance. Industrial Engineering 25
(9), 40–43.
Malhotra, Y., 1998. Business process redesign: An overview.
IEEE Engineering Management Review 26 (3).
Manganelli, R.L., Klein, M.M., 1994. The Re-engineering
Handbook: A Step-by-step Guide to Business Transforma-
tion. AMACOM, New York.
Mansar, S.L., Reijers, H.A., 2005. Best practices in business
process redesign: Validation of a redesign framework.
Computers in Industry 56, 457–471.
Mikel, H., Schroeder, R., 2000. Six sigma—The breakthrough
management strategy revolutionizing the world’s top corpora-
tions. Doubleday, New York.
Milgrom, P., Roberts, J., 1988. Communication and inventories
as substitutes in organizing production. Scandanavian Jour-
nal of Economics 90 (3), 275–289.
Miller, B., 1994. Reengineering government. Government Tech-
nology 7 (5), 1, 46–47.
Moe, R.C., 1994. The ‘Reinventing Government’ exercise:
Misinterpreting the problem, misjudging the consequences.
Public Administration Review 54 (2), 111–222.
Murphy, E., 1994. Cultural values, workplace, democracy and
organizational change. In: Coulson-Thomas, C. (Ed.), Busi-
ness Process Reengineering: Myth and Reality. Kogan Page,
London.
Orlikowski, W., Hofman, D., 1996. An improvisational model of
change management: The case of groupware technologies.
Sloan Management Review.
Ovans, A., 1995. Should you take the re-engineering risk?
Datamation 41 (17), 38–42.
Pande, P.S., Neuman, R.P., Cavenaugh, R.R., 2000. The Six
Sigma Way: How GE, Motorola, and Other top Companies
are Honing their Performance. McGraw-Hill, New York.
Seidmann, A., Sundararajan, A., 1997a. The effects of task and
information symmetry on business process redesign. Interna-
tional Journal of Production Economics 50 (2–3), 117–128.
Seidmann, A., Sundararajan, A., 1997b. Competing in informa-
tion intensive services: Analyzing the impact of task
consolidation and employee empowerment. Journal of
Management Information Systems 4 (2), 33–56.
Thong, J.Y.L., Yap, C.S., Seah, K.L., 2000. Business process
reengineering in the public sector: The case of the housing
development board in Singapore. Journal of Management
Information Systems 17 (1), 245–270.
Tomasko, M.R., 1993. Rethinking the Corporation: The
Architecture of Change. AMA, New York.
Venkatraman, N., 1994. IT-enabled business transformation:
From automation to business scope redefinition. Sloan
Management Review 35 (2), 73–87.
