Click the following link for a good presentation, on prospects for Aerospace Industry in this region, from the recently concluded 2009 Asia Pacific Aviation Technology CEO Summit:
Mar 10, 2009
Business Intelligence in Best-in-class companies...
[Source: Ann All's Blog]
In a recent blog on cloud computing, I wrote that asking folks to define an emerging technology is one way of gauging its popularity. In general, the squishier the definition, the hotter it is.
Another popularity gauge is how many (roughly equivalent) terms are used to describe it. A good example is operational business intelligence, aka pervasive BI, transactional BI, real-time BI and near real-time BI.
A thorough Intelligent Enterprise article discussing Aberdeen Research findings on the BI practices of best-in-class companies deals with the multiple term issue early on. The article notes:
No matter what flavor or definition is used, at the heart of the matter, organizations are beginning to focus their attention on leveraging existing data to enable and optimize daily, hourly, minute-to-minute, or even up-to-the-second actions.
Best-in-class companies are streamlining their decision-making processes, which is the overriding goal of operational BI. Indeed, Aberdeen says such companies experience decreases in both the time that elapses between business activity and the delivery of information to decision-makers and the time between business activity and actual decisions or other resulting actions.
According to Aberdeen, other key characteristics of these best-in-class companies include improvements in customer satisfaction and customer retention and improvements in data access and availability for end users.
Best-in-class companies differentiate themselves from more "ordinary" peers with their ability to master five practices: process, organization, knowledge managment, performance management and technology. As I read through the in-depth explanations of these areas, it occurred to me that a number of them had been featured in my blogs, in my interviews with experts and elsewhere on IT Business Edge.
For example, in the process category, Aberdeen notes that best-in-class companies are more inclined to automate their data processing and analysis activities. Charles Nicholls, the CEO of SeeWhy Software, in October made a similar point during my interview with him. Drawing a parallel between BI and aviation, he said:
When I get onto the plane, I feel very good that there are two pilots who know what they are doing. However, they are not actually flying the plane. They do the takeoff and they do the landing, but everything else in between is done by the autopilot. The autopilot is making very gentle corrections in course and speed, and it flies the airplane much more accurately than the pilot can. It's completely objective, and doesn't get confused, and that kind of thing.
Nicholls told me that companies are increasingly choosing to separate their data from data logic. He said:
So analytics can trigger business process management systems and trigger the process for retaining customers, or retaining stock, or those kinds of things. Therefore the nature of what we call BI -- for the sake of a label -- is changing. It's not just about producing reports, but about creating these kinds of autopilot systems.
Automation can affect decision-making in a dramatic way by eliminating the reporting process entirely, said Nicholls. In his example, a service representative might be immediately notified via e-mail or other means if a customer halted an online application for a mortgage, triggering an outbound call to that customer. Nicholls said:
This particular case doesn't involve a report or a dashboard. ... This is an example of how you can build BI into your daily processes. If you think about displaying information daily, a dashboard is just an electronic version of a report. If you think about an operational process, it may not be that relevant to have that dashboard, because then you are relying on a person to look at it. It doesn't give you the big performance lift.
In the knowledge management area, Aberdeen points out that best-in-class companies are ahead of their peers in providing training and other resources to BI end users. Often, this includes the establishment of a BI center of excellence or competency center.
I blogged about the importance of user involvement in BI initiatives in June and asked BI expert Lyndsay Wise, principal of WiseAnalytics, about it in an interview earlier this month. She told me that a lack of user training can derail a BI initiative because users won't adopt BI if they don't feel comfortable with it.
For super users and IT, I think they may think (BI is) more intuitive than it actually is. With BI search and different areas in which BI is starting to become more intuitive, by developing interfaces that look and feel the same way a person might surf on the Internet, hopefully in the future it won't be as much of an issue.
Since usability is still an issue for many -- if not most -- companies, Wise recommends getting business users more directly involved in BI initiatives. She said:
More super users within the business so that not only are end users not always going back to IT, but also those issues of whether something will work or how well it will work are determined by the business. Once the business adopts BI and likes it, they'll see other uses for it and want to use it more.
In a recent blog on cloud computing, I wrote that asking folks to define an emerging technology is one way of gauging its popularity. In general, the squishier the definition, the hotter it is.
Another popularity gauge is how many (roughly equivalent) terms are used to describe it. A good example is operational business intelligence, aka pervasive BI, transactional BI, real-time BI and near real-time BI.
A thorough Intelligent Enterprise article discussing Aberdeen Research findings on the BI practices of best-in-class companies deals with the multiple term issue early on. The article notes:
No matter what flavor or definition is used, at the heart of the matter, organizations are beginning to focus their attention on leveraging existing data to enable and optimize daily, hourly, minute-to-minute, or even up-to-the-second actions.
Best-in-class companies are streamlining their decision-making processes, which is the overriding goal of operational BI. Indeed, Aberdeen says such companies experience decreases in both the time that elapses between business activity and the delivery of information to decision-makers and the time between business activity and actual decisions or other resulting actions.
According to Aberdeen, other key characteristics of these best-in-class companies include improvements in customer satisfaction and customer retention and improvements in data access and availability for end users.
Best-in-class companies differentiate themselves from more "ordinary" peers with their ability to master five practices: process, organization, knowledge managment, performance management and technology. As I read through the in-depth explanations of these areas, it occurred to me that a number of them had been featured in my blogs, in my interviews with experts and elsewhere on IT Business Edge.
For example, in the process category, Aberdeen notes that best-in-class companies are more inclined to automate their data processing and analysis activities. Charles Nicholls, the CEO of SeeWhy Software, in October made a similar point during my interview with him. Drawing a parallel between BI and aviation, he said:
When I get onto the plane, I feel very good that there are two pilots who know what they are doing. However, they are not actually flying the plane. They do the takeoff and they do the landing, but everything else in between is done by the autopilot. The autopilot is making very gentle corrections in course and speed, and it flies the airplane much more accurately than the pilot can. It's completely objective, and doesn't get confused, and that kind of thing.
Nicholls told me that companies are increasingly choosing to separate their data from data logic. He said:
So analytics can trigger business process management systems and trigger the process for retaining customers, or retaining stock, or those kinds of things. Therefore the nature of what we call BI -- for the sake of a label -- is changing. It's not just about producing reports, but about creating these kinds of autopilot systems.
Automation can affect decision-making in a dramatic way by eliminating the reporting process entirely, said Nicholls. In his example, a service representative might be immediately notified via e-mail or other means if a customer halted an online application for a mortgage, triggering an outbound call to that customer. Nicholls said:
This particular case doesn't involve a report or a dashboard. ... This is an example of how you can build BI into your daily processes. If you think about displaying information daily, a dashboard is just an electronic version of a report. If you think about an operational process, it may not be that relevant to have that dashboard, because then you are relying on a person to look at it. It doesn't give you the big performance lift.
In the knowledge management area, Aberdeen points out that best-in-class companies are ahead of their peers in providing training and other resources to BI end users. Often, this includes the establishment of a BI center of excellence or competency center.
I blogged about the importance of user involvement in BI initiatives in June and asked BI expert Lyndsay Wise, principal of WiseAnalytics, about it in an interview earlier this month. She told me that a lack of user training can derail a BI initiative because users won't adopt BI if they don't feel comfortable with it.
For super users and IT, I think they may think (BI is) more intuitive than it actually is. With BI search and different areas in which BI is starting to become more intuitive, by developing interfaces that look and feel the same way a person might surf on the Internet, hopefully in the future it won't be as much of an issue.
Since usability is still an issue for many -- if not most -- companies, Wise recommends getting business users more directly involved in BI initiatives. She said:
More super users within the business so that not only are end users not always going back to IT, but also those issues of whether something will work or how well it will work are determined by the business. Once the business adopts BI and likes it, they'll see other uses for it and want to use it more.
Mar 4, 2009
Cost Optimization Framework...
[Source - Express Computer]
Gartner recommends that IT and business leaders use a cost optimization framework as a template when evaluating cost optimization initiatives.
Gartner’s Four Levels of Cost Optimization framework is based on the four discrete levels at which IT organizations can help their enterprises optimize business costs. The two lower levels—IT procurement and cost savings within IT—are focused on the reduction of cost within IT, while the two upper levels—joint business and IT cost savings, and enabling innovation and business restructuring—involve IT and the business teaming up to reduce operating costs.
“Whether it’s due to an efficiency play, response to competitive action, meeting the needs of a powerful customer or dealing with an economic downturn, a sudden, renewed focus on IT costs can sometimes lead to ill-considered management responses,” said Barbara Gomolski, Managing Vice President at Gartner. “However, experienced IT leaders know that cost-cutting campaigns seldom leave the organization positioned well for IT-innovation-enabled and new-value-creation-based expansion.”
Where appropriate, each level of this framework explores cost optimization issues by technology, domain, technology role, supporting facts and quantifications, estimates of savings and risk, and, in some instances, vertical industry. The broad definitions of the four discrete levels are given below (listed from lowest to highest):
- IT procurement: True partnerships with IT vendors mean that each party benefits in the good times and makes joint sacrifices in times of economic uncertainty. Each year, IT organizations spend billions of dollars for hardware, software, IT services and telecommunications services. The manner in which IT organizations approach procurement issues will affect how much they can reduce spending to meet business goals.
- Cost savings within IT: A priority for many IT organizations will be to identify opportunities to reduce baseline IT costs, not just move them to another budget center. Where IT organizations focus is where they will be successful with cost savings.
- Joint business and IT cost savings: Consider that the average IT budget is roughly 3% of revenue, while total operating expenses are 80% to 90% of revenue. If the enterprise is looking to reduce costs in 2009, IT managers should try to join IT with the business to reduce costs in business operating expenses.
- Enabling innovation and business restructuring: As economic uncertainty passes, cost optimization will refocus on efforts to implement long-term process improvement and enable business structuring and innovation.
Gartner recommends that the framework is used as an organizing structure in which to track cost optimization programs as well as communicating the impact of cost optimization to the business.
Mapping out cost optimization efforts to the framework can help to determine whether an organization’s overall initiative is out of balance (all cuts coming from cost savings in IT, for example) or whether an organization has mixed IT costs with an appropriate amount of optimization techniques (such as innovation and business restructuring) that can prepare an organization for a return to growth.
“As the immediate needs of the business change in relationship to the macroeconomic climate, more optimization focus will be transferred to the higher levels of the framework, reflecting efforts to enable a return to growth,” said Kurt Potter, Research Director at Gartner. “As organizations focus on the higher-level cost optimization areas, they will recognize and communicate higher levels of business benefit, aside from cost-cutting.”
Organizations should differentiate between cost optimization and cost-cutting.
“IT cost savings often result from optimization, but IT cost savings are not a given when optimizing business processes,” said Mark Raskino, Vice President and Gartner fellow. “In other words, optimizing the business may require spending more on IT in order to meet the service-level expectations of business and IT in the future.”
Arbitrary cost-cutting often delays optimization, because investments that would normally yield better results in the long-term are delayed. These are the challenges that IT and business leaders are facing in the current period of economic uncertainty.
Feb 27, 2009
Instinct or Analytics?
[Source: Ann All's Blog]
Way back in 2007, I wrote about the tension between sophisticated analytics and human judgment. No matter what data tells people -- and it can tell us a lot -- many of us are uncomfortable relying strictly on data when making decisions. Sometimes our guts simply tell us to go a different way.
So it's perhaps not that surprising that a recent Accenture survey found that 40 percent of companies base important business decisions largely on judgment rather than analytics. In many cases, of course, it's not so much that companies think human judgment trumps the data, it's because of data shortcomings. Sixty-one percent of respondents cited a lack of good data, for example, while 60 percent mentioned absence of historical data.
The quality of data can't be discounted, said Ian Ayres, author of "Super Crunchers: Why Thinking-by-Numbers is the
Yet the Accenture survey also seemed to indicate that, in some cases, companies simply preferred to rely on their guts. The experts contributing their opinions in the TDWI piece said that data and human judgment aren't an either/or proposition. Said Neil Raden, author of "Smart (Enough) Systems":
... I don't think you can separate gut from analytics, because all analytics can do is inform your decision and at some point you have to apply your gut to the analytics.
Perhaps the realization that human experience and opinion can complement data helps explain the growing popularity of prediction markets, a decision-making tool I wrote about a few months ago. Bo Cowgill, a quantitative marketing manager at Google, told me such markets bring in more diverse opinions, which makes decisions more reliable. Google typically has two dozen internal prediction markets running at a given time. He said:
With more traditional methods, you rely on a single analyst, or maybe a team of them, crunching numbers. They are typically not going to be as exposed to as much information as the crowd.
Ayres said humans are less effective in making more complicated decisions. Their success rate tends to fall as the number of underlying factors involved in a decision grows. Yet that's exactly when prediction markets can be helpful, believe Cowgill and others, because they bring in opinions and knowledge sets that might not otherwise be considered.
The counter view: When making decisions, humans often assign too much weight to certain factors or include irrelevant factors. In our interview, Ayres offered the example of a loan officer who focuses on an applicant's race. Said Ayres: Give me any individualized loan approach and let me run a race with it; the statistical approach is going to make better lending decisions. Discretionary systems tended to make loans to their friends other than to qualified candidates.
Feb 23, 2009
Adopting "Lean" Methods to ERP Implementation
[By Rebecca Gill, Vice President, Technology Group International - published in Manufacturing.Net]
Although most people tend to think of manufacturing when hearing the term "lean," the primary principles of lean easily lend themselves to successful adoptions of ERP (enterprise resource planning) systems. The basic principles of lean manufacturing focus on process flow, optimization, waste elimination, problem solving, and continuous improvements. Without question, these same principles guide the most successful ERP implementations. Learning how to translate the concepts of lean manufacturing over to ERP implementation and usage can help turn a potential project failure into fast ROI dollars.ERP Equals Process Flow
Lean concepts start with a steady flow of employees, tasks, and associated goods. This uncluttered and continual process flow is paramount for the success of any lean implementation. This same concept is an integral part of the selection, implementation, and ongoing usage of an ERP system.
Instead of picturing the seamless movement of physical goods within the manufacturing process, envision the effortless movement of data within an ERP system. As with lean manufacturing, a lean ERP system facilitates the ease of movement of information from one task to another, from one employee to another.
Proper Configuration Equals Optimization
This effortless process flow comes not by chance. Regardless of an ERP package’s reputation, functionality, or cost - the package will only provide an optimal flow if the selection process was well planned, the right system selected, and the proper implementation methodology followed.
Lean experts agree on the importance of optimization. It is a key and critical element for any lean Sensei’. Within the world of ERP selection and implementations, optimization is achieved through a balance of an organization’s requirements, the software’s functionality, and the configuration of data and process flow within the system to equally tie the system’s abilities to those of the company’s needs. But this optimization does not come at installation or even at the initial go-live of the package. It is achieved through a combination of out of the box functionality, some number of custom modifications or configurations, and extended user training.
Integration Equals Waste Elimination
By definition, an ERP system equates to integration. The enterprise wide adoption of a package, purchased to manage the overall requirements of an organization, dictate that an elimination of multiple systems will occur and that a streamlined process flow will be adopted. This, in itself, leads to an integration of resources, employees, and tasks. And by a natural course of events, this integration leads to an elimination of waste.
An ERP system offers a multitude of opportunities for waste elimination. Virtually any ERP adoption offers reductions in data entry time and user errors, increases access to information, as well as substantially increases overall employee output and performance. For those truly focused on the concept of value stream mapping and waste elimination, the benefits of an ERP implementation can increase substantially.
Testing And Training Equals Problem Solving
A good test plan will take a lackluster or even disastrous implementation and help turn it into a positive experience for the majority of participants. A solid test plan equates to proactive problem solving through early resolution. It helps to push problem detection and management into the implementation stage of the project, helps resolve issues in a timelier manner, and causes little to no disruption to the project’s internal or external stakeholders.
But an adequate test plan cannot solve impending issues alone. Ask any software developer about what is one of their biggest complaints about a customer’s implementation strategy or ongoing system usage and the answer will be training. Every software package has users who under utilize system functionality due to limited user training. Limited or insufficient training force many well intentioned implementation teams to quickly fall into status quo mode shortly after their initial go-live.
A solid, well executed test plan and well trained users create a seamless transition for all of those involved, because in the end, these two project elements will make or break any system implementation.
Ongoing Benchmarking & Evaluation Equals Continuous Improvements
An ERP system and its ongoing usage is an evolution. Successful adoption and solid return on investment does not come overnight. It is a long-term project and an ongoing process. It involves a solid selection plan, quality testing, intensive user training, and active participation by all levels within the organization. Most important, however, is a periodic and thorough self-evaluation which provides a means of reassessment throughout the system’s entire lifecycle.
Obtaining the full benefits of an ERP system, regardless of the ERP system at hand, requires an unending pursuit of continuous improvement. It requires a review of initial goals and milestones, an objective evaluation of the current state and a specific plan to close out any existing process or functional gaps. This gap analysis should occur shortly after go-live, a year after go-live, and any time a new software release or major corporate structural change occurs.
Typical Self Evaluation Questions
Executing continuous improvement practices does not require an army of employees. A quick self evaluation can occur in answering some basic, yet fairly comprehensive questions.
1. Do the users feel confident with the existing system?
2. Do the users have knowledge of the organization’s operational flow and how their responsibilities fit within this flow?
3. Do the users routinely manage off-line systems (typically spreadsheets or other small database applications) to either do their jobs or to maintain information they need to function in their job?
4. Do the users have enough solid information to make educated and timely business decisions?
5. Is there an ever growing number of user complaints regarding their ability to do their jobs in an efficient and timely manner?
6. Does the system help users confidently meet the needs of other internal (employees) or external (customers, partners, etc.) stakeholders?
7. Has the existing software’s latest release been reviewed? Can these new functional improvements better the operations and output of the organization?
2. Do the users have knowledge of the organization’s operational flow and how their responsibilities fit within this flow?
3. Do the users routinely manage off-line systems (typically spreadsheets or other small database applications) to either do their jobs or to maintain information they need to function in their job?
4. Do the users have enough solid information to make educated and timely business decisions?
5. Is there an ever growing number of user complaints regarding their ability to do their jobs in an efficient and timely manner?
6. Does the system help users confidently meet the needs of other internal (employees) or external (customers, partners, etc.) stakeholders?
7. Has the existing software’s latest release been reviewed? Can these new functional improvements better the operations and output of the organization?
If you find yourself answering no to many of these questions, your organization can certainly benefit from a review of your current system. These newly discovered gaps can be addressed via a number of different short-term or long-term projects. Resolution can be as simple as performing additional user training or having your software vendor perform an onsite benchmarking workshop. Or in some cases, resolution may require more in depth action such as the initiation of a thorough evaluation of a new software package.
Regardless of the resulting gaps and associated corrective action, ongoing self evaluation and continuous improvement efforts are necessary for efficient and profitable operations. Just as adopting lean methods on the manufacturing plant floor is an ongoing pursuit of perfection and a never ending process of improvement, so is adopting lean within the world of ERP.
Feb 20, 2009
Managing In the Face of Imposed Models...
By Mark Mullaly, PMP
ITIL. COBIT. ISO 9000. Sarbanes-Oxley. Even PMBOK.
Processes and models come in many flavors, shapes and sizes. Whether they advocate better quality management, better project management, better corporate governance or better audit-ability and control, their fundamental motivation--at least theoretically--is to, well, make things better. Models don’t start out with the underlying intent of making things worse. That would be unproductive, irrational and entirely unhelpful. The principle is that the model provides a better way of managing than whatever came before.
Except when they don’t…
Something very curious has happened in the implementation of countless models that have been implemented under the guise of “making management better”. In many instances, the result has been far from an improvement. The reality is that many implementations have made things worse.
Ironic? Certainly. Unhelpful? Unquestionably. But why? What is it that organizations are doing that takes a well-intentioned, well-meaning and purportedly well-crafted model and turns it into something that is considered bureaucratic, ill-guided and--in a couple of noteworthy instances--downright evil? And what can we do differently that will enable positive results, rather than haunted cries of “not again”?!?
An organization I recently consulted with voiced an all-too-familiar refrain. In updating their IT processes, methodologies and guidelines, they were aligning with the principles of the COBIT model. The COBIT framework was developed by the IT Governance Institute, a self-described “research think tank” that was established in 1998 to support the improvement of IT governance. While the purpose is to define what an effective, architecturally driven means of managing IT that supports the enterprise is, the emphasis of COBIT is on controls, not processes. In other words, it doesn’t define how activities and initiatives should be done, but instead what controls should be in place to ensure that functions are being performed correctly.
The result, for this organization, was the creation of “a ridiculous and overwhelming layer of bureaucracy,” in the words of one of its executives. There was an enormous feeling that “the inmates are running the asylum.” It’s worth noting that the stated intent underlying the implementation in this organization was not the imposition of bureaucracy, or the creation of an overwhelming and unworkable structure. In fact, the purpose was quite opposite--to try to create a workable and effective structure that supported the stated goals of making the IT function better support the overall needs of the organization.
Once the decision was made to adopt COBIT, however, the resulting activities quickly descended into the creation of a vast amount of rigor, oversight and bureaucracy that went far beyond where anyone in the organization expected or valued. Despite the lack of expectation or perceived value, however, the organization still proceeded down the path it had set for itself. Why didn’t it adjust its course, or even stop? How did this take on a life of its own? And how can future organizations learn a lesson from this experience and not do the same thing next time?
When looking at how industry standard models and frameworks are adopted, there are a number of traps that organizations allow themselves to fall into, which collectively can lead to the same slippery slope that the organization described above found itself on:
Because it’s the right thing to do. As noted, no one implements a model for the sake of it, or simply for the sake of creating bureaucracy. The models that exist do so for a reason. Creating visibility and momentum around this model or that, however, requires marketing and selling. Books are written, conferences staged and consultants bray that organizations that fail to adopt this model or that are at best misguided and at worse “doomed to fail”.
Sadly, in this, I am not exaggerating. A survey of the advocacy approaches behind any number of models and frameworks, from ISO 9000 to agile, reveal a level of rhetoric that is breathtaking in their audacity and downright apocalyptic in the consequences of not adopting it. Sadly, the rhetoric frequently gets confused with reality, and we begin to believe the stories we tell ourselves. What is valued and appropriate gets drowned beneath the sweeping claims of what is imperative and essential.
We’re just dealing with growing pains. Once an organization has made the choice to adopt this model or that framework, the implementation necessarily requires effort. Adoption and use requires that much more work. The literature on change management and implementation quite rightly points out the productivity impacts that can be encountered when adopting a change. When faced with the pains of adoption, however, legitimate concerns about the relevance and appropriateness of an approach risk dismissal as just growing pains. Rather than objectively asking whether the expressed concerns are legitimate, those raising concerns run the risk of being perceived as naysayers and “not on board”.
The technical imperative trumps the organizational need. Models are theoretically adopted to deliver business value. The implementation of any improvement initiative is frequently tied to a promise of improved business results that is in fact sold to the business. Like the organization described earlier, however, once agreement or adoption takes place, the actual adoption and implementation tends to be driven more by technical rather than business imperatives. The business oversight is assumed to be the decision to proceed in the first place, and the proper level of business scrutiny over what is implemented tends not to occur. The phenomenon of “inmates running the asylum” is far more appropriately the technical side implementing what they think is right, without a regular and necessary check-in with the business side of the organization as to whether or not it makes sense.
All of it, and as rigorously as possible. Models provide choices and alternatives. A careful reading of the introduction to the PMBOK, for example, reveals that there isn’t an expectation that every aspect is relevant for all projects. Appropriate and intelligent adaptation and application is essential. Sadly, when implementing a defined model, especially one that has been adopted as a best practice, the presumption is that everything it offers is good, appropriate and valuable. Rather than evaluating trade-offs and choosing what to implement, and how it should be implemented, the default position is that if the model says we should do it, then we should do it. Consequences in terms of the costs of adoption and the diminishing returns of benefits get dismissed in favor of rigorous adherence. After all, if this is what a “best” practice looks like, then any compromise runs the risk of becoming merely good, mediocre or even bad.
Adapting would “undermine the spirit and intent” of the model. Closely related to the presumption that the full model represents the best of all possible implementations is a related assumption: If adaptation were appropriate, the model would already be adapted. Again, the presumption is that because the model is the way it is, its integrity must be preserved. Adaptation is compromise. Compromise is assumed to be sub-optimal. Intelligent application of the model, in the eyes of the true believer, is heresy.
The result of these trends are implementations that are complete, universal and uncompromising in their adherence to what is viewed as “right”, unfortunately losing sight of what is fitting and practical. Models are just that--they are representations of reality. They are not reality, nor are they replacements for reality. They are suggestions of approaches that must be intelligently and reasonably considered by organizations in order to identify what is logical and appropriate, given the culture, context and management style of the organizations adopting them.
What this means is that the project managers and teams that implement models need to take a deep breath before proceeding to really think through what the results will mean for the organization. Often, the kickoff of an improvement effort is participation in a workshop, training course or boot camp to familiarize the team with the model and its purpose. It is at these events where the implementation can take on its sheen of ideology.
After all, the workshops are led by articulate, impassioned and well-meaning advocates for the approach being explored. They believe in what they are teaching and the value the model offers, and they have a host of horror stories to share regarding failures and consequences of incomplete or inappropriate adoption, or of not starting down this past in the first place. While education is fine, the second activity must be a sober reflection of what the implementation will mean for the organization. What fits, and what doesn’t? What makes sense in the context of the organization, and what won’t work? The fundamental question to be asked is how the principles of the model can be adopted and adapted, not how an ideologically pure and perfect version of the model can be shoehorned in and made to fit.
More importantly, organizational oversight is crucial. The executive agreement to adopt and proceed with an implementation requires a level of understanding of what the organization is signing on to when it chooses to proceed. This means that executives need to familiarize themselves with the principles and purposes of the models being considered. More importantly, they need to understand how these principles suit the context of the organization they lead. And most importantly, they need to provide the ongoing oversight of what is proposed to be actually implemented, constantly asking whether what is proposed makes sense, is relevant and will ultimately deliver value.
Models and frameworks abound in today’s marketplace. As organizations take stock of how they are performing, and seek improvement opportunities in the face of an uncertain marketplace, these models become tempting means of short-circuiting and accelerating the real work of improvement. Certainly, models like ITIL and COBIT have a place as a repository of practices and experiences that organizations can consider.
They are not blueprints for improvement, however, nor are they processes that can be adopted wholesale. They are representative principles of what can work. It is up to any organization considering them, however, to figure out what they can do to make them work in their context and environment. As has been said many times before: caveat emptor, let the buyer beware.
ITIL. COBIT. ISO 9000. Sarbanes-Oxley. Even PMBOK.
Processes and models come in many flavors, shapes and sizes. Whether they advocate better quality management, better project management, better corporate governance or better audit-ability and control, their fundamental motivation--at least theoretically--is to, well, make things better. Models don’t start out with the underlying intent of making things worse. That would be unproductive, irrational and entirely unhelpful. The principle is that the model provides a better way of managing than whatever came before.
Except when they don’t…
Something very curious has happened in the implementation of countless models that have been implemented under the guise of “making management better”. In many instances, the result has been far from an improvement. The reality is that many implementations have made things worse.
Ironic? Certainly. Unhelpful? Unquestionably. But why? What is it that organizations are doing that takes a well-intentioned, well-meaning and purportedly well-crafted model and turns it into something that is considered bureaucratic, ill-guided and--in a couple of noteworthy instances--downright evil? And what can we do differently that will enable positive results, rather than haunted cries of “not again”?!?
An organization I recently consulted with voiced an all-too-familiar refrain. In updating their IT processes, methodologies and guidelines, they were aligning with the principles of the COBIT model. The COBIT framework was developed by the IT Governance Institute, a self-described “research think tank” that was established in 1998 to support the improvement of IT governance. While the purpose is to define what an effective, architecturally driven means of managing IT that supports the enterprise is, the emphasis of COBIT is on controls, not processes. In other words, it doesn’t define how activities and initiatives should be done, but instead what controls should be in place to ensure that functions are being performed correctly.
The result, for this organization, was the creation of “a ridiculous and overwhelming layer of bureaucracy,” in the words of one of its executives. There was an enormous feeling that “the inmates are running the asylum.” It’s worth noting that the stated intent underlying the implementation in this organization was not the imposition of bureaucracy, or the creation of an overwhelming and unworkable structure. In fact, the purpose was quite opposite--to try to create a workable and effective structure that supported the stated goals of making the IT function better support the overall needs of the organization.
Once the decision was made to adopt COBIT, however, the resulting activities quickly descended into the creation of a vast amount of rigor, oversight and bureaucracy that went far beyond where anyone in the organization expected or valued. Despite the lack of expectation or perceived value, however, the organization still proceeded down the path it had set for itself. Why didn’t it adjust its course, or even stop? How did this take on a life of its own? And how can future organizations learn a lesson from this experience and not do the same thing next time?
When looking at how industry standard models and frameworks are adopted, there are a number of traps that organizations allow themselves to fall into, which collectively can lead to the same slippery slope that the organization described above found itself on:
Because it’s the right thing to do. As noted, no one implements a model for the sake of it, or simply for the sake of creating bureaucracy. The models that exist do so for a reason. Creating visibility and momentum around this model or that, however, requires marketing and selling. Books are written, conferences staged and consultants bray that organizations that fail to adopt this model or that are at best misguided and at worse “doomed to fail”.
Sadly, in this, I am not exaggerating. A survey of the advocacy approaches behind any number of models and frameworks, from ISO 9000 to agile, reveal a level of rhetoric that is breathtaking in their audacity and downright apocalyptic in the consequences of not adopting it. Sadly, the rhetoric frequently gets confused with reality, and we begin to believe the stories we tell ourselves. What is valued and appropriate gets drowned beneath the sweeping claims of what is imperative and essential.
We’re just dealing with growing pains. Once an organization has made the choice to adopt this model or that framework, the implementation necessarily requires effort. Adoption and use requires that much more work. The literature on change management and implementation quite rightly points out the productivity impacts that can be encountered when adopting a change. When faced with the pains of adoption, however, legitimate concerns about the relevance and appropriateness of an approach risk dismissal as just growing pains. Rather than objectively asking whether the expressed concerns are legitimate, those raising concerns run the risk of being perceived as naysayers and “not on board”.
The technical imperative trumps the organizational need. Models are theoretically adopted to deliver business value. The implementation of any improvement initiative is frequently tied to a promise of improved business results that is in fact sold to the business. Like the organization described earlier, however, once agreement or adoption takes place, the actual adoption and implementation tends to be driven more by technical rather than business imperatives. The business oversight is assumed to be the decision to proceed in the first place, and the proper level of business scrutiny over what is implemented tends not to occur. The phenomenon of “inmates running the asylum” is far more appropriately the technical side implementing what they think is right, without a regular and necessary check-in with the business side of the organization as to whether or not it makes sense.
All of it, and as rigorously as possible. Models provide choices and alternatives. A careful reading of the introduction to the PMBOK, for example, reveals that there isn’t an expectation that every aspect is relevant for all projects. Appropriate and intelligent adaptation and application is essential. Sadly, when implementing a defined model, especially one that has been adopted as a best practice, the presumption is that everything it offers is good, appropriate and valuable. Rather than evaluating trade-offs and choosing what to implement, and how it should be implemented, the default position is that if the model says we should do it, then we should do it. Consequences in terms of the costs of adoption and the diminishing returns of benefits get dismissed in favor of rigorous adherence. After all, if this is what a “best” practice looks like, then any compromise runs the risk of becoming merely good, mediocre or even bad.
Adapting would “undermine the spirit and intent” of the model. Closely related to the presumption that the full model represents the best of all possible implementations is a related assumption: If adaptation were appropriate, the model would already be adapted. Again, the presumption is that because the model is the way it is, its integrity must be preserved. Adaptation is compromise. Compromise is assumed to be sub-optimal. Intelligent application of the model, in the eyes of the true believer, is heresy.
The result of these trends are implementations that are complete, universal and uncompromising in their adherence to what is viewed as “right”, unfortunately losing sight of what is fitting and practical. Models are just that--they are representations of reality. They are not reality, nor are they replacements for reality. They are suggestions of approaches that must be intelligently and reasonably considered by organizations in order to identify what is logical and appropriate, given the culture, context and management style of the organizations adopting them.
What this means is that the project managers and teams that implement models need to take a deep breath before proceeding to really think through what the results will mean for the organization. Often, the kickoff of an improvement effort is participation in a workshop, training course or boot camp to familiarize the team with the model and its purpose. It is at these events where the implementation can take on its sheen of ideology.
After all, the workshops are led by articulate, impassioned and well-meaning advocates for the approach being explored. They believe in what they are teaching and the value the model offers, and they have a host of horror stories to share regarding failures and consequences of incomplete or inappropriate adoption, or of not starting down this past in the first place. While education is fine, the second activity must be a sober reflection of what the implementation will mean for the organization. What fits, and what doesn’t? What makes sense in the context of the organization, and what won’t work? The fundamental question to be asked is how the principles of the model can be adopted and adapted, not how an ideologically pure and perfect version of the model can be shoehorned in and made to fit.
More importantly, organizational oversight is crucial. The executive agreement to adopt and proceed with an implementation requires a level of understanding of what the organization is signing on to when it chooses to proceed. This means that executives need to familiarize themselves with the principles and purposes of the models being considered. More importantly, they need to understand how these principles suit the context of the organization they lead. And most importantly, they need to provide the ongoing oversight of what is proposed to be actually implemented, constantly asking whether what is proposed makes sense, is relevant and will ultimately deliver value.
Models and frameworks abound in today’s marketplace. As organizations take stock of how they are performing, and seek improvement opportunities in the face of an uncertain marketplace, these models become tempting means of short-circuiting and accelerating the real work of improvement. Certainly, models like ITIL and COBIT have a place as a repository of practices and experiences that organizations can consider.
They are not blueprints for improvement, however, nor are they processes that can be adopted wholesale. They are representative principles of what can work. It is up to any organization considering them, however, to figure out what they can do to make them work in their context and environment. As has been said many times before: caveat emptor, let the buyer beware.
Feb 16, 2009
Overcoming Resistance to Change...
Author: Ahmet Oturgan, Director of Marketing and Sales, IAS [We could use these excellent Tips to advise our clients appropriately on managing Change]
Starting an ERP implementation in your organization may very well be a venture of the highest risk level attempted in the history of your company, as ERP implementations also signify a period of change and transformation for the organization. The undertaking will affect corporate processes, established practices, and organizational structures; in short, the entire culture of the organization will somehow be touched upon. And tampering with company cultures always carry inherent risks.
On the other hand, intense competition forces us to undergo change. In the rapidly changing world of business, change for the better and managing change are now the critical maxims to live by for achieving success, and indeed, for survival. In such a context, an ERP implementation project is really another name for change, one that should be embraced as an excellent opportunity for implementing cultural transformation and for turning your organization into an enterprise that is professionally managed.
However, research shows resistance to change as a threat that you may experience when transforming this opportunity into success for your organization. Analyses of several failed ERP implementation projects show that, general resistance to any type of change and specific end-user resistance to the ERP implementation efforts, are some of the most significant roadblocks that are encountered in the road to success. In summary, successfully managing change and taking the measures to overcome end-user resistance, lead the list for critical success factors relating to ERP implementations projects.
So then, what are some of the appropriate actions that we can undertake to overcome the end-user resistance that poses such a significant threat to our ERP implementation project?
- First and foremost, if you feel that your organization does not need change, and furthermore, if you are happy with your organization's current status and are apprehensive about disrupting it, it is best that you shelve the ERP implementation for now, until you really feel the need for change. Much as it would be a marketing mistake to launch a new product at a time when the consumer is not ready or exhibits no need for such a product, so would embarking on an ERP implementation project be a serious fault, especially when upper management for the organization and the core project team do not display an enthusiastic attitude towards the implementation, possibly jeopardizing project success.
- In an ERP implementation project, you should consider the project team as the sales team, the end-user as the consumer, and the ERP implementation as the product. Once we accept this compelling analogy, we can employ marketing methods, which is an advanced discipline devised to overcome the buyer's (in this case, the end-user's) resistance. In short, for a successful ERP deployment, you need to market the implementation project in the best possible manner to its consumers, who happen to be your end-users.
- To avoid comments of the type "This system does not meet my requirements; I would not have picked this software" half-way into the implementation, you should include your project team and end-users into the product selection process and should obtain their buy-in as well, as secure their active participation.
- You should compose your project team of highly motivated individuals with good communication skills, who possess positive outlooks, and who are disciplined and dedicated.
- Upper management and the project team should maintain their motivation throughout the implementation process, and even at times of crises, should set a positive example for the end-users by sustaining their motivation and their belief in the implementation. (Imagine a ferry in the midst of severe weather and the effects it will have on the passengers observing the captain and the crew running about the ship in panic!)
In summary, throughout your implementation project you will have a need for project champions and heroes who will be there during turbulent times, and a strong defensive team who knows what it is doing. The best possible composition for your team is an upper management and a project team, in that order, who are composed of project champions who do not easily lose their motivation in times of difficulty. - You should prevent, at all cost, all ill-intended criticisms, and especially sarcastic remarks, aimed at the implementation project. Most of the time, simple advice and guidance will do the job; when necessary, you should take disciplinary action. At the same time, you should keep in mind that exemplary conduct and a resolute attitude displayed by the upper management and your project team will be the most effective support you will have.
- In ERP implementations, change may come in different flavors. Change will sometimes take place in the organization itself or in its business processes, and at other times, change may be necessary for the ERP system itself. Especially during the early starting stages of your project, modifications to the ERP system and the software may need to be implemented where necessary, to overcome end-user resistance. Such adaptations and customizations, when successfully realized, will help establish end-user trust in both the project team and the software vendor. It will lessen the feelings of uneaseness and apprehension relating to change that are being experienced by the end-users, by enforcing their sense of control over the change that is being introduced.
On the other hand, finding a balance between making modifications to the ERP system versus altering the way your company does business, will have a significant effect on the success of your project. For such customizations stemming from user requests, carrying out sound requirements analyses as well as deciding on what is truly necessary and what is not, are responsibilities that rest with your upper management and your project team. - Resistance may not always explicitly manifest itself. At times, becoming aware of resistance may be difficult. Sometimes a seeming display of acceptance will actually hide a passive resistance. For example, a group of your users may signal no problems with the system, while in practice they may opt to use alternative applications instead of utilizing the system itself, or generate external processes to achieve their objectives. Upper management and your project team should be as diligent on passive resistance as they are on open resistance, and should take precautions to recognize and resolve passive resistance.
- Upper management (the sponsor for the implementation project), should tackle all individual issues of resistance that are relayed to them by the project manager, and should absolutely not postpone problem resolution, or display indifference towards issues of resistance.
- The transition to live production use is a singularly risky and critical period with respect to the trust associated with the system and the software. Therefore, the quality of the support that is provided to the end-users, as well as responses to possible problems that may arise during this period, is of critical importance. To prevent issues of trust and resistance which may later become chronic occurrences, it is imperative that this period be managed with careful attention from you.
- Indeed, it is not change itself that people are afraid of, but the fear that change will adversely affect them. Fundamentally, people are in favour of change that is positive. We are generally confronted with resistance in the form of a defensive reaction mechanism against the adverse aspects of change. Trust should be established by removing the negative perceptions that may be perpetuated.
- Most of the time, the real risks are much smaller than the perceived risks. That is, it is not all that important whether change itself is positive or not. What is important is how that change is perceived by people. For example, if a user is under the impression that he or she may lose his or her job as a result of the implementation project, it will result in resistance because of the risks it harbors for that user, however positive the results of that change may actually be. As such, you will need to become aware of ill-conceived perceptions about your ERP implementation project, and take the necessary precautions to disseminate accurate information instead.
- In direct contradiction to the above scenario, an overly trusting environment may also cause a roadblock for change. As human beings, we all have a need for security and a sense of control over our immediate environment, as well as for a feeling of certainty. When these needs are fully or exceedingly met, we can be unwelcoming towards change. Therefore, in certain situations, the final resort for "coercing" your team to accept change may really be to somewhat disrupt the atmosphere of trust and certainty, and to cause a tremor of sorts in the organization's foundation.
The literature on the topic of ERP systems is still evolving. Therefore, one cannot point out a results-oriented methodology for use in overcoming possible resistance during project implementations. However, I believe the bullet items I have compiled above, based on actual success stories we have experienced at our own customer implementation projects, as well as input from various reference materials, will hopefully be of guidance to organizations embarking on new ERP implementations.
Feb 9, 2009
State of Affairs in Helicopter MRO Industry...
The following Article by By Paul Seidenman & David J. Spanovich published recently in Aviation Week, provides a good analysis of Current Status of Helicopter MRO Industry:
The once-high-flying civil helicopter market is having its wings clipped by the global financial crisis, as operators cut back flying hours and more rotor craft hit the resale market. For those who service and repair helicopters, that means having to make some adjustments in their business planning, as demand for MRO declines along with flight hours.
To get an idea of the potential impact of the current global economy on the helicopter MRO industry, it is necessary to look at some numbers. In the summer of 2007, consulting firm AeroStrategy released a global helicopter MRO market study that predicted $5.4 billion in spending for 2008. Hal Chrisman, a principal of the firm, explained that the study looked at airframe work, engine and component overhaul and repair, and modifications, and took into account all civil helicopters, including those specially modified for military or paramilitary use. Excluded were those purpose-built for military roles.
"Prior to the global financial crisis, we projected a 3% increase in the international helicopter MRO market for 2009, putting it at $5.6 billion," said Chrisman. "But given today's economy, we are now estimating anywhere between a 5% and 10% decline in helicopter MRO sales for 2009, compared with our 2008 projections." Driving this trend, said Chrisman, is utilization. "There is no question that, even before the global economic meltdown occurred, high fuel prices began to impact at least some segments of the helicopter operating sector.
"In fact, we talked to some [operators] who told us that helicopter utilization in industries other than EMS (emergency medical services) and oil and gas exploration has dropped as much as 15-20%." Airframe, engine and dynamic component repair, he pointed out, are the segments of the helicopter MRO market that are driven mostly by flight hours, or what Chrisman referred to as "utilization." In fact, dynamic components, those which are directly involved with transferring power from the engine to the rotors, make up the largest segment, 48%, of the helicopter component repair and servicing market, with avionics the next largest segment at 12%. Hydraulics, he said, was in third place at 10%.
Chrisman added that all components make up 40% of the total helicopter MRO business, with airframe, engine and modifications making up 30%, 22% and 8% of the MRO market, respectively.Modifications are not driven by utilization. "Most modifications are discretionary and include green completions, painting, interior work, and avionics upgrades, which in some cases can be regulatory driven," he said. "A big piece of the modification market is involved with completions." Danny Maldonado, SVP, customer support services for Ft. Worth-based Bell Helicopter Textron, reported that helicopter utilization began to decline in the fourth quarter of 2008. He predicted that this could lead to "what will likely be a slight decline in demand for maintenance services" in 2009.
"Many helicopter operations run by municipal governments are facing budget cuts, and with much lower energy prices, many oil and gas producers believe that initiating new exploration projects is not worth it now," said Maldonado. "Very possibly, EMS will also be impacted, especially if some operators are more community, as opposed to insurance-funded."
Although cutbacks in mining and energy exploration will curtail some helicopter operations, John MacDougall, president of Vancouver-based Vector Aerospace Helicopter Services, a major North American helicopter MRO firm, believes that there are a few bright spots.
"There will be some reductions in utility flying, especially in the forestry and mining sectors, but we believe that paramilitary operations, such as border patrol and law enforcement, will remain strong," he said. "We also see continued strength with EMS and electronic news gathering."
For many operators, the near-term trend may involve a shift from new aircraft acquisitions to continued usage of older models, according to MacDougall. "A lot of operators are postponing plans to acquire new aircraft due to the non-availability of credit, in some cases, as well as their own uncertainty about future work," he said. "Commercial firms and some military agencies, as examples, will hold onto and modernize their existing fleets, with upgrades such as modern glass cockpits."
An increase in the demand for system upgrades of older helicopters has, in fact, been noted by Tina Cannon, general manager of Phoenix Heliparts at Falcon Field in Mesa, Ariz. "We are taking advantage of our focus on the MD helicopter family, which is once again emerging as a major force in the market," said Cannon. "That will strengthen our position as an MRO company, because more MD helicopter operators are choosing to refurbish and upgrade their aircraft, as opposed to buying something new. For example, a number of MD 500-E operators have chosen to re-engine their aircraft with the Rolls-Royce 250-C20R, which has better high altitude performance than the original Rolls-Royce 250-C20B engine. "Phoenix Heliparts, said Cannon, currently is doing about 80% of its MRO work for international civil and military operators. So far, she said, business has been steady.
"We did not witness a slowdown in our MRO business in 2008, due to the fact that many of our international customers are military operators," she said. "Also, a lot of our civil operators outside the U.S., especially those based in Europe, are sending airframe maintenance to us in order to take advantage of the favorable exchange rate on the U.S. dollar versus the euro."
Basically, the company's international business has offset the softer domestic helicopter MRO market. But while Phoenix Heliparts may have seen growth last year, there was about a 10% drop in the volume of worldwide helicopter MRO activity, specifically engine removal and repair, from 2007, according to Clarke Mouncher, the global Rolls-Royce 250 program director for BBA Aviation Engine Repair and Overhaul in Portsmouth, U.K. This, he said, is directly related to the downturn in helicopter utilization.
"Declining utilization has been the most pronounced among corporate operators, and others whose helicopter use is discretionary, especially when some other form of transportation is available," Mouncher said. "Into 2009, we will probably see the same level of flight activity that we saw in 2008, but it will involve missions other than discretionary flying, such as oil and gas support, and EMS. Those missions will stay pretty constant, since there will still be a need for emergency medical flights and a requirement to move people on and off oil and gas drilling rigs."
The result of the cutbacks, explained Mouncher, is that in some cases, helicopters are being parked at the end of their engine overhaul intervals.
However, he added, there are still opportunities to provide "part-life"modules and engine exchanges, even as full overhauls drop off. "Operators are saving money by exchanging engine components that have come to the end of their overhaul cycle, or complete engines that have not been fully overhauled, but are still serviceable," he said. "In fact, we have seen a significant increase in demand for part-life engines and components, especially in Europe, the Middle East and Africa. On the Rolls-Royce 250, this is very practical, because the engines are highly modular." In tandem with this, Mouncher said some operators are holding back on repairs of spare parts as a cost-savings measure.
"Before, they would have removed the components [from] the aircraft that needed repair and sent them, immediately, into an MRO shop. Now, they are holding the inventory rather than having it repaired immediately. That trend is not only a result of the global economy, but the exchange rate on the U.S. dollar, which is not as favorable as it was early last year against the euro and British pound. In the world helicopter MRO industry, repair services are normally priced in U.S. dollars, and with the strengthening dollar, some repairs are as much as 25% more costly on the same components than they would have been a year ago."
Doug Kult, director of helicopter sales for engine and avionics OEM Honeywell, noted that today, helicopter operators are trying to defer maintenance events as long as possible, because it is one of the ways they can save cash. MRO companies, he explained, are trying to help by looking for ways to extend component maintenance cycle times. For example, Kult said that due to customer requests, the hot section inspection interval for the Honeywell LTS101 engine, which powers the Bell 222, and Eurocopter BK117 and AS350 models, will be increased to 2,400 hours, from the current 1,800 hours.
"We have actually gotten more requests for a program of this kind as the economy has deteriorated. While the maintenance for this engine is already on-condition, we will be helping the operators that much more by increasing the hot section interval times." That inspection interval, explained Kult, is expected to be approved by FAA in the fourth quarter of 2009. The agency already has signed off on the testing plan for the extension, which Honeywell expects to initiate during the first quarter of this year.
As cash-strapped operators seek further ways to save on repairs, one question that arises is this: Are more of them at least looking again at PMA? The short answer is that the jury is still out. "There is definitely more of a demand for PMA parts in the U.S. than there has been in Europe," said BBA Aviation's Mouncher. "At least with the Rolls-Royce 250 engine family, that has remained pretty consistent, and I do not see a change in that, at least for awhile."
Interestingly enough, that observation was borne out by Phoenix Heliparts' Cannon, whose company does a lot of international work. "Particularly on the Rolls-Royce 250 engines, I am getting more requests for quotes from customers to include PMA," she said.
Bell Helicopter Textron's Maldonado said that there always will be an interest in PMA, although he is not seeing any great increase in demand. "If operators' budgets start getting cut, more of them will look at PMA for non-flight critical parts. But, right now, we are not seeing a strong interest in the demand for PMA, since many operators will want to stay with OEM parts, at least during the warranty periods."
Still, he pointed out one helicopter MRO trend is toward more turnkey, fixed price maintenance plans. "Given today's economy, more people are turning to MRO vendors to provide turnkey maintenance solutions at a predictable [fixed] cost," he said. "That not only helps those who have to stay within annual budget constraints, such as a local government funded operations, but also operators bidding contracts to energy and mining companies."
Maldonado also predicted that more operators will focus on keeping their current fleets flying, rather than looking at replacements. "At least for now, more operators will conclude that it's cheaper to keep their older aircraft in service and maintain them, than to go out and buy something new."
Closely related to that is a growing potential MRO market for the large inventory of helicopters currently on the used market. "If you look back to 2007, anybody looking for a used helicopter found that the market for anything decent was tight. Frankly, you couldn't find one," said AeroStrategy's Chrisman. "But now, our sources have told us that of the 22,000 civil helicopters in service worldwide, nearly 50-100 aircraft per week are going onto the resale market."
According to Mark Clancy, president of Minneapolis-based HelicopterBuyer, a dealer and broker in turbine powered helicopters, as of mid-December 2008, there were some 650-670 turbine powered helicopters for sale on the global used market. "If you include those units available for sale, but not being actively marketed, that increases by another 25-33%, giving you a total of nearly 900," he explained. "That number is approximately 80% greater than it was at the start of the 2008, and represents a 134% increase in the number of used helicopters being marketed between December 2005 and December 2008. In fact, over the past six months [June-December 2008], we have seen more resale helicopters on the market than was the case over the past two years."
Clancy attributes the rise in used aircraft numbers partially to the banking and financial services crisis and the uncertainty in the markets, which unfolded last year. "People were still able to get financing for new helicopters, but for the most part, the banks were no longer willing to finance a used aircraft purchase," he said. "The first signs of problems really began with the corporate market, where there was a buildup in the number of pre-owned Sikorsky S-76s available last spring and early summer.
It's a very popular corporate model that tends to be used by large corporate owners. Other sectors started slowing as fuel prices soared last summer, which started to affect demand. Since then, there has been an overall increase in used helicopters for sale across the sector board."
The helicopter MRO companies, he said, will stand to benefit if efforts being made to shore up the financial sector once again make money available for the purchase of used helicopters. "We believe that by the spring, and into the summer, there will be some increase in the purchase of used helicopters, as operator contracts are issued or renewed and more sources of funding become available," said Clancy.
He also noted that for the time being, the MRO industry still has about a three to six month backlog of work on new helicopters as buyers send in "green" aircraft for initial completion work. "And, as funding for used aircraft becomes more available, people will find that they can get some very good helicopter deals, and will look to the MRO shops to do the repair, refurbishment and reconfiguration work."
Along this line, he predicted that there will be "significant growth" in leasing of both new and pre-owned helicopters. "There will probably be more leasing over the next 12-18 months than there has been over the past 18 months, as some buyers will prefer to lease rather than to own additional assets. As the helicopters move from one lessee to another over the next few years, the leasing companies will have to update and possibly reconfigure the helicopters for their next customer mission profile, and that translates into repairs, refurbishments, and component and engine work."
At the same time, as more people consider buying used aircraft, the MRO shops will sense opportunities to market their services, as Clancy pointed out. "At the height of the market, the lead times for new helicopters out of the factory was anywhere between two and five years. When you start seeing new model lead times drop to less than 12 months, it will eventually translate into a slowing down of new completion work at MRO shops that specialize in those specific new model completions," he said. "Those shops likely will more aggressively promote themselves to the owners of used equipment, over a wider array of makes and models, for refurbishments and upgrades."
Feb 3, 2009
Paradigm Shift in Aircraft & Operation Maintenance...
Click on the following link for a very good presentation titled “Enabling Technologies and Challenges for the Future Global Maintenance System” by Arnd Schirrmann, EADS Innovation Works, focusing on Operational Needs and Health Monitoring & Management (HMM) Technologies driving the Paradigm shift (some of these ideas could be applied to Application Maintenance too?):
Subscribe to:
Posts (Atom)