Economic policy: those who look farther down the road know when it’s time to slow down
by Franco Bruni, Professor of Monetary Theory and Policy, Università Bocconi
The international economic crisis is largely due to myopic behavior and lack of foresight. We have been shortsighted about looking into our past: we forgot about past crises and we extrapolated only from the boom years of the recent past. And we have been shortsighted looking into the future, riding booms and bubbles as if they could have gone on for ever. We have valuated risk taking into account exceedingly short time horizons.
Among the most important measures to help avoid a repetition of the crisis are recipes which steer us toward a long-run approach rather than short-termism. There is a growing sense that the main task of macroeconomic policy is no longer to help navigate the economy from recession to recovery in the shortest possible time, but to stabilize long-run performance, by moderating the upswings and mitigating the downswings of the business cycle.
The central idea is to properly coordinate fiscal and monetary policies. Monetary policy is well known in its tools and effects, but its anticyclical stance must be made more timely and rigorous. The crisis was born out of the excessive monetary expansion on interest rates and credit, through which, not only in the US, boom years and the accompanying speculative bubbles were financed. When the time came to pull the brake on monetary policy, the accelerator was pushed instead.
The other form of policy is new and its instruments and objectives are yet to be precisely defined. It’s called macro-prudential policy and is about measuring and containing the level of risk across the whole financial systems. In addition to transparent and integrated statistical monitoring, with international policy collaboration and standardization of oversight all over the world, macro-prudential policy calls for anticyclical policy moves regarding certain regulated parameters. Some already exist, like the minimum capital requirements of banks, others need to either be invented or globally diffused, like a ceiling on the degree of leveraging in financial institutions.
These are parameters that need to become restrictive when the credit cycle is on the up and vice versa. The existing regulation of financial risks tends to do the opposite; it’s too permissive when thigs go well and belatedly too prudent when things to bad and the risk of insolvency mounts. Macro-prudential policy is about preventing wild cycles in credit.
Both the EU and US are moving in this direction. But there is unfortunately hesitation. Some fear giving too much power to central banks. But it should be evident than only central banks are able to intervene timely and in a coordinated fashion with policies of cyclical stabilization. In order for central banks to do well their job, their independence from political and market pressures is crucial. It’s not easy to spoil the party when the economy booms, and impose prudence and foresightedness to effervescent markets!
The approach oriented to stability across the cycle of money, credit and financial risk has been long preached by the Bank of International Settlements in Basel, a prestigious but not much-heeded international agency. Its annual report, published this summer, reminds us how shortsightedness has always historically been at the root of international financial crises.
Giannis Giataganas
IT related
Thursday 8 October 2009
Monday 5 October 2009
The State of Business Process Reengineering: A Search for Success Factors
Total Quality Management
Vol. 16, No. 1, 121–133, January 2005
DAVID PAPER & RUEY-DANG CHANG
BISE Department, Utah State University, Logan, USA, Department of Business Management,
National Sun Yat-Sen University, Taiwan, Republic of China
In the early 1990s, business process reengineering (BPR) came blazing onto the business scene as the saviour of under-performing organizations. Early advocates of BPR (e.g.Harrington, 1991; Davenport, 1993; Hammer & Champy, 1993) touted it as the next revolution in obtaining breakthrough performance via process improvement and process change. However, BPR has failed to live up to expectations in many organizations (Davenport,1993; Hammer & Champy, 1993; Kotter, 1995; Bergey et al., 1999). Some of the reasons include adoption of a flawed BPR strategy, inappropriate use of consultants, a workforce tied to old technologies, failure to invest in training, a legacy system out of control, IT architecture misaligned with BPR objectives, an inflexible management team, and a lack of long-term commitment (Bergey et al., 1999). As one can see from this list, it seems obvious that many organizations failed to realize the scope and resource requirements of BPR.
Clark et al. (1997) offered a five-component star model featuring people skills, structure, reward systems, processes, and change-ready IT capabilities. The components ‘structure’ and ‘reward systems’ fall into the ‘environment’ category developed by Paper (1998a). The component ‘strategy’ falls into the ‘vision’ category developed by Paper (2001). Paper (1999) extended the model to include IT capabilities. Paper et al. (2001) further extended the model to include vision that weaves the other components together with a ‘top-down’ imperative. Since the component ‘process’ is what organizations are attempting to change to improve performance (Broadbent et al., 1999; Davenport & Stoddard, 1994; Harkness et al., 1996; Kettinger et al., 1997; Nissen, 1998; Paper, 1999), we felt that it should not be a part of our theoretical lens.
Methodology Success Factors
Methodology provides a guiding blueprint for successful transformation. Methodology
success factors include appropriate guiding principles, buy-in, direction, continuous monitoring, graphical process map, and customer support. Transformation cannot be accomplished in the absence of fundamental guiding principles(Hammer & Champy, 1993; Tapscott & Caston, 1993). Existence of such principles allows people to challenge existing assumptions, recognize resistance to change, and establish
project buy-in (Kettinger et al., 1997). Also of critical importance is direction from top management (Paper&Dickinson, 1997),which is essential to identifying information-technology
opportunities, informing stakeholders, setting performance goals, and identifying BPR
opportunities. Direction can be formalized in the form of a process model (Harrington,1991; Davenport, 1993; Paper & Dickinson, 1997). A process model provides a graphical representation of the targeted processes and a starting point for measurement-driven inference(Nissen, 1998). We now articulate methodology success factors:
A customized BPR methodology (process map) facilitates business and contingency
planning for process transformation (Kettinger et al., 1997). It also provides a ‘stepby-step’ map of activities and resource-allocation requirements (Paper & Dickinson, 1997). Hence, a detailed methodology for addressing change must be devised and customized by management prior to undergoing change.
A process map, however, only maps tasks and activity requirements. It fails to provide high-level support and direction. Management is thereby responsible for budgeting along mapped activities, directing (redirecting) process workers, and exhibiting visible support. A map is just a blueprint. Management must lead change.
The process map must be based on sound business principles and be appropriate for each business. That is, it should be customized. As such, an organization’s map
should incorporate business-specific principles and undergo continuous refinement
based on current and ongoing business needs.
A BPR methodology is not a ‘turn-key’ program and should not be purchased as such. Each organization has its own special needs, environment, and business culture.
The process map should be represented as a graphical blueprint that depicts what needs to take place at each phase of a project so that everyone involved understands his or her role in the transformation (Paper, 1999). A graphical map makes it much easier for everyone to ‘see’ the phases and conditions necessary for success.
The customer should be the focus of any change event. Hence, the process map should reflect this focus. That is, customer demand should ‘pull’ the change plan.
The BPR methodology (process map) acts as a rallying point to keep people engaged
and to help management continuously monitor the transformation as it unfolds. Buy-in
of course is critical as management at all levels and people involved in change along
the process path need to understand and believe in its potential for success. Top management and project leaders must offer direction, as it is very easy for transformation projects to glide off track. Finally, customer support must be part of the change plan as they are the reason for transformation in the first place. An organization would not need to change if customers were already delighted. Given the cross-functional and radical nature of process redesign, a lot is learned by process workers (Paper & Dickinson, 1997). Further, new knowledge is created by those involved (El Sawy & Bowles, 1997). However, the organization can lose this valuable
knowledge through attrition if an effort is not made to capture the knowledge on an
organizational basis. As a result, the BPR methodology must move to a higher order of
analysis to formalize the way in which the ‘process’ learns during the redesign process. Thus, interactions between people, management, and the environment are necessary to enact a process map.
Giannis Giataganas
IT related
Vol. 16, No. 1, 121–133, January 2005
DAVID PAPER & RUEY-DANG CHANG
BISE Department, Utah State University, Logan, USA, Department of Business Management,
National Sun Yat-Sen University, Taiwan, Republic of China
In the early 1990s, business process reengineering (BPR) came blazing onto the business scene as the saviour of under-performing organizations. Early advocates of BPR (e.g.Harrington, 1991; Davenport, 1993; Hammer & Champy, 1993) touted it as the next revolution in obtaining breakthrough performance via process improvement and process change. However, BPR has failed to live up to expectations in many organizations (Davenport,1993; Hammer & Champy, 1993; Kotter, 1995; Bergey et al., 1999). Some of the reasons include adoption of a flawed BPR strategy, inappropriate use of consultants, a workforce tied to old technologies, failure to invest in training, a legacy system out of control, IT architecture misaligned with BPR objectives, an inflexible management team, and a lack of long-term commitment (Bergey et al., 1999). As one can see from this list, it seems obvious that many organizations failed to realize the scope and resource requirements of BPR.
Clark et al. (1997) offered a five-component star model featuring people skills, structure, reward systems, processes, and change-ready IT capabilities. The components ‘structure’ and ‘reward systems’ fall into the ‘environment’ category developed by Paper (1998a). The component ‘strategy’ falls into the ‘vision’ category developed by Paper (2001). Paper (1999) extended the model to include IT capabilities. Paper et al. (2001) further extended the model to include vision that weaves the other components together with a ‘top-down’ imperative. Since the component ‘process’ is what organizations are attempting to change to improve performance (Broadbent et al., 1999; Davenport & Stoddard, 1994; Harkness et al., 1996; Kettinger et al., 1997; Nissen, 1998; Paper, 1999), we felt that it should not be a part of our theoretical lens.
Methodology Success Factors
Methodology provides a guiding blueprint for successful transformation. Methodology
success factors include appropriate guiding principles, buy-in, direction, continuous monitoring, graphical process map, and customer support. Transformation cannot be accomplished in the absence of fundamental guiding principles(Hammer & Champy, 1993; Tapscott & Caston, 1993). Existence of such principles allows people to challenge existing assumptions, recognize resistance to change, and establish
project buy-in (Kettinger et al., 1997). Also of critical importance is direction from top management (Paper&Dickinson, 1997),which is essential to identifying information-technology
opportunities, informing stakeholders, setting performance goals, and identifying BPR
opportunities. Direction can be formalized in the form of a process model (Harrington,1991; Davenport, 1993; Paper & Dickinson, 1997). A process model provides a graphical representation of the targeted processes and a starting point for measurement-driven inference(Nissen, 1998). We now articulate methodology success factors:
A customized BPR methodology (process map) facilitates business and contingency
planning for process transformation (Kettinger et al., 1997). It also provides a ‘stepby-step’ map of activities and resource-allocation requirements (Paper & Dickinson, 1997). Hence, a detailed methodology for addressing change must be devised and customized by management prior to undergoing change.
A process map, however, only maps tasks and activity requirements. It fails to provide high-level support and direction. Management is thereby responsible for budgeting along mapped activities, directing (redirecting) process workers, and exhibiting visible support. A map is just a blueprint. Management must lead change.
The process map must be based on sound business principles and be appropriate for each business. That is, it should be customized. As such, an organization’s map
should incorporate business-specific principles and undergo continuous refinement
based on current and ongoing business needs.
A BPR methodology is not a ‘turn-key’ program and should not be purchased as such. Each organization has its own special needs, environment, and business culture.
The process map should be represented as a graphical blueprint that depicts what needs to take place at each phase of a project so that everyone involved understands his or her role in the transformation (Paper, 1999). A graphical map makes it much easier for everyone to ‘see’ the phases and conditions necessary for success.
The customer should be the focus of any change event. Hence, the process map should reflect this focus. That is, customer demand should ‘pull’ the change plan.
The BPR methodology (process map) acts as a rallying point to keep people engaged
and to help management continuously monitor the transformation as it unfolds. Buy-in
of course is critical as management at all levels and people involved in change along
the process path need to understand and believe in its potential for success. Top management and project leaders must offer direction, as it is very easy for transformation projects to glide off track. Finally, customer support must be part of the change plan as they are the reason for transformation in the first place. An organization would not need to change if customers were already delighted. Given the cross-functional and radical nature of process redesign, a lot is learned by process workers (Paper & Dickinson, 1997). Further, new knowledge is created by those involved (El Sawy & Bowles, 1997). However, the organization can lose this valuable
knowledge through attrition if an effort is not made to capture the knowledge on an
organizational basis. As a result, the BPR methodology must move to a higher order of
analysis to formalize the way in which the ‘process’ learns during the redesign process. Thus, interactions between people, management, and the environment are necessary to enact a process map.
Giannis Giataganas
IT related
Friday 2 October 2009
ERP delays give CFOs a headache
But what's causing them and how can businesses keep these giant projects on track?
By Tim Ferguson
Published: 25 September 2009 10:01 BST
Cost over-runs on the largest ERP implementation projects can reach tens of thousands of pounds per month - so what are the classic stumbling blocks that delay the roll out of these gigantic projects.
The late completion of ERP projects can create problems in terms of additional cost, delayed savings and potential loss of revenue, meaning the CFO has a real interest in reducing these delays. According to research commissioned by ecommerce technology maker GXS, 84 per cent of businesses it surveyed had experienced ERP roll-out delays due to integration issues with suppliers and partners.
The research also found that when the biggest ERP deployments are delayed this can waste as much as $45,000 per day - more than $1m per month.
Tony Lock, programme director at Freeform Dynamics told silicon.com: "There are certainly delays in ERP projects but that, I think, is not specific to ERP projects, it's rather a symptom of IT projects in general. There are very few major projects that go off perfectly on time with few challenges along the route."
One big issue is that ERP implementations significantly change business processes - meaning people have new responsibilities and are working in new areas - something Lock said also has political connotations that can be tricky to resolve.
Christian Hestermann, research director for ERP at Gartner, said that many ERP projects suffer from delays as they involve a large number of different people within the business and "a lot of distributed responsibility".
He added: "Normally it does not only have to do with technology. It's more things like poor planning, unclear responsibilities, people pointing at each other. These implementations look like a technology project but it's much a business and people kind of thing."
To minimise the potential for problems, Hestermann said these projects need management buy-in and good planning. They also need to have clearly defined objectives and processes in order to reach the right conclusion.
Freeform Dynamics' Lock added there aren't actually that many people with the necessary experience around big ERP projects, so it's hard to find the right people and even if you do, their services come at a cost.
"Changing technology is difficult, changing processes is more difficult, changing people is the hardest task of all," he said.
Another problematic area is the scope of the ERP project. The GXS research found that 34 per cent of data in ERP systems originates from outside the enterprise - for example from customers and suppliers - adding further to the complexity.
Lock said: "ERP by its very nature tries to embrace quite a wide swathe of the infrastructure so the actual technical integration aspects of it can be quite challenging in and of themselves."
Angela Eager, senior analyst at the Ovum Butler Group, added: "The complexity of the system in terms of scale (functionality, users, instances, physical and virtual locations), and integration to other systems are also significant factors."
Eager said the scope of this kind of project isn't often "set in stone" so is subject to change during implementation. The need to be flexible therefore means completing projects in a set timeframe is often difficult.
Despite these concerns, Lock feels the issues affecting ERP rollouts are increasingly becoming well understood.
He said: "I don't think that the delays are getting worse. I think that we are getting more experience with big ERP projects and we are beginning to learn not to reinvent the wheel each time but to take the best practice that's already been established and exploit that."
Ovum Butler Group's Eager added there is a trend away from "big bang" implementations which "virtually guarantee delays" to more incremental approaches which make ERP implementations more manageable and likely to be delivered on time. She said many businesses she works with have found this approach more successful.
Giannis Giataganas
IT related
By Tim Ferguson
Published: 25 September 2009 10:01 BST
Cost over-runs on the largest ERP implementation projects can reach tens of thousands of pounds per month - so what are the classic stumbling blocks that delay the roll out of these gigantic projects.
The late completion of ERP projects can create problems in terms of additional cost, delayed savings and potential loss of revenue, meaning the CFO has a real interest in reducing these delays. According to research commissioned by ecommerce technology maker GXS, 84 per cent of businesses it surveyed had experienced ERP roll-out delays due to integration issues with suppliers and partners.
The research also found that when the biggest ERP deployments are delayed this can waste as much as $45,000 per day - more than $1m per month.
Tony Lock, programme director at Freeform Dynamics told silicon.com: "There are certainly delays in ERP projects but that, I think, is not specific to ERP projects, it's rather a symptom of IT projects in general. There are very few major projects that go off perfectly on time with few challenges along the route."
One big issue is that ERP implementations significantly change business processes - meaning people have new responsibilities and are working in new areas - something Lock said also has political connotations that can be tricky to resolve.
Christian Hestermann, research director for ERP at Gartner, said that many ERP projects suffer from delays as they involve a large number of different people within the business and "a lot of distributed responsibility".
He added: "Normally it does not only have to do with technology. It's more things like poor planning, unclear responsibilities, people pointing at each other. These implementations look like a technology project but it's much a business and people kind of thing."
To minimise the potential for problems, Hestermann said these projects need management buy-in and good planning. They also need to have clearly defined objectives and processes in order to reach the right conclusion.
Freeform Dynamics' Lock added there aren't actually that many people with the necessary experience around big ERP projects, so it's hard to find the right people and even if you do, their services come at a cost.
"Changing technology is difficult, changing processes is more difficult, changing people is the hardest task of all," he said.
Another problematic area is the scope of the ERP project. The GXS research found that 34 per cent of data in ERP systems originates from outside the enterprise - for example from customers and suppliers - adding further to the complexity.
Lock said: "ERP by its very nature tries to embrace quite a wide swathe of the infrastructure so the actual technical integration aspects of it can be quite challenging in and of themselves."
Angela Eager, senior analyst at the Ovum Butler Group, added: "The complexity of the system in terms of scale (functionality, users, instances, physical and virtual locations), and integration to other systems are also significant factors."
Eager said the scope of this kind of project isn't often "set in stone" so is subject to change during implementation. The need to be flexible therefore means completing projects in a set timeframe is often difficult.
Despite these concerns, Lock feels the issues affecting ERP rollouts are increasingly becoming well understood.
He said: "I don't think that the delays are getting worse. I think that we are getting more experience with big ERP projects and we are beginning to learn not to reinvent the wheel each time but to take the best practice that's already been established and exploit that."
Ovum Butler Group's Eager added there is a trend away from "big bang" implementations which "virtually guarantee delays" to more incremental approaches which make ERP implementations more manageable and likely to be delivered on time. She said many businesses she works with have found this approach more successful.
Giannis Giataganas
IT related
Subscribe to:
Posts (Atom)