Failure Mode and Effects Analysis

 

Any business in the manufacturing industry would know that anything can happen in the development stages of the product. And while you can certainly learn from each of these failures and improve the process the next time around, doing so would entail a lot of time and money.
A widely-used procedure in operations management utilised to identify and analyse potential reliability problems while still in the early stages of production is the Failure Mode and Effects Analysis (FMEA).

FMEAs help us focus on and understand the impact of possible process or product risks.

The FMEA method for quality is based largely on the traditional practice of achieving product reliability through comprehensive testing and using techniques such as probabilistic reliability modelling. To give us a better understanding of the process, let’s break it down to its two basic components ? the failure mode and the effects analysis.

Failure mode is defined as the means by which something may fail. It essentially answers the question “What could go wrong?” Failure modes are the potential flaws in a process or product that could have an impact on the end user – the customer.

Effects analysis, on the other hand, is the process by which the consequences of these failures are studied.

With the two aspects taken together, the FMEA can help:

  • Discover the possible risks that can come with a product or process;
  • Plan out courses of action to counter these risks, particularly, those with the highest potential impact; and
  • Monitor the action plan results, with emphasis on how risk was reduced.

Find out more about our Quality Assurance services in the following pages:

Check our similar posts

Which Services to Share?

It often makes sense to pool resources. Farmers have been doing so for decades by collectively owning expensive combine harvesters. France, Germany, the United Kingdom and Spain have successfully pooled their manufacturing power to take on Boeing with their Airbus. But does this mean that shared services are right in every situation?

The Main Reasons for Sharing

The primary argument is economies of scale. If the Airbus partners each made 25% of the engines their production lines would be shorter and they would collectively need more technicians and tools. The second line of reasoning is that shared processes are more efficient, because there are greater opportunities for standardisation.

Is This the Same as Outsourcing?

Definitely not! If France, Germany, the United Kingdom and Spain has decided to form a collective airline and asked Boeing to build their fleet of aircraft, then they would have outsourced airplane manufacture and lost a strategic industry. This is where the bigger picture comes into play.

The Downside of Sharing

Centralising activities can cause havoc with workflow, and implode decentralised structures that have evolved over time. The Airbus technology called for creative ways to move aircraft fuselages around. In the case of farmers, they had to learn to be patient and accept that they would not always harvest at the optimum time.

Things Best Not Shared

Core business is what brings in the money, and this should be tailor-made to its market. It is also what keeps the company afloat and therefore best kept on board. The core business of the French, German, United Kingdom and Spanish civilian aircraft industry is transporting passengers. This is why they are able to share an aircraft supply chain that spun off into a commercial success story.

Things Best Shared

It follows that activities that are neither core nor place bound – and can therefore happen anywhere ? are the best targets for sharing. Anything processed on a computer can be processed on a remote computer. This is why automated accounting, stock control and human resources are the perfect services to share.

So Case Closed Then?

No, not quite. ?Technology has yet to overtake our humanity, our desire to feel part of the process and our need to feel valued. When an employee, supplier or customer has a problem with our administration it’s just not good enough to abdicate and say ?Oh, you have to speak to Dublin, they do it there?.

Call centres are a good example of abdication from stakeholder care. To an extent, these have ?confiscated? the right of customers to speak to speak directly to their providers. This has cost businesses more customers that they may wish to measure. Sharing services is not about relinquishing the duty to remain in touch. It is simply a more efficient way of managing routine matters.

Scrumming Down to Complete Projects

Everybody knows about rugby union scrums. For our purposes, perhaps it is best to view them as mini projects where the goal is to get the ball back to the fly-half no matter what the opposition does. Some scrums are set pieces where players follow planned manoeuvres. Loose / rolling scrums develop on the fly where the team responds as best according to the situation. If that sounds to you like software project management then read on, because there are more similarities?.

Isn’t Scrum Project Management the Same as Agile?

No it’s not, because Scrum is disinterested in customer liaison or project planning, although the team members may be happy to receive the accolades following success. In the same way that rugby players let somebody else decide the rules and arrange the fixtures, a software Scrum team just wants the action.

Scrum does however align closely ? dare I say interchangeably with Agile?s sprints. Stripping it of all the other stages frees the observer up to analyse it more closely in the context of a rough and tumble project, where every morning can begin with a backlog of revised requirements to back fit.

The 3 Main Phases of a Scrum

A Scrum is a single day in the life of a project, building onto what went before and setting the stage for what will happen the following day. The desired output is a block of component software that can be tested separately and inserted later. Scrumming is also a useful technique for managing any project that can be broken into discreet phases. The construction industry is a good example.

Phase 1 – Define the Backlog. A Scrum Team?s day begins with a 15 minute planning meeting where team members agree individual to-do lists called ?backlogs?.

Phase 2 – Sprint Towards the Goal. The team separates to allow each member to complete their individual lines of code. Little or no discussion is needed as this stage.

Phase 3 – Review Meeting. At the end of each working day, the team reconvenes to walk down what has been achieved, and check the interconnected functionality.

The 3 Main Phases of a Scrum ? Conclusions and Thoughts

Scrum is a great way to liberate a competent project team from unnecessary constraints that liberate creativity. The question you need to ask yourself as manager is, are you comfortable enough to watch proceedings from the side lines without rushing onto the field to grab the ball.

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK
Transformation to a process based organisation

Today’s global marketplace rewards nimble organisations that learn and reinvent themselves faster than their competition. Employees at all levels of these organisations see themselves as members of teams responsible for specific business processes, with performance measures tied to the success of the enterprise. As team members, they are “owners” of the process (or processes) to which they are assigned. They are responsible for both the day to day functioning of their process(s), and also for continuously seeking sustainable process improvements.

Transforming a traditionally designed “top down control” enterprise to a process-based organisation built around empowered teams actively engaged in business process re-engineering (BPR) has proven more difficult than many corporate leaders have expected. Poorly planned transformation efforts have resulted in both serious impacts to the bottom line, and even more serious damage to the organisation’s fabric of trust and confidence in leadership.

Tomislav Hernaus, in a publication titled “Generic Process Transformation Model: Transition to Process-based Organisation” has presented an overview of existing approaches to organisational transformation. From the sources reviewed, Heraus has synthesised a set of steps that collectively represent a framework for planning a successful organisational change effort. Key elements identified by Hernaus include:

Strategic Analysis:

The essential first step in any transformation effort must be development of a clear and practical vision of a future organisation that will be able to profitably compete under anticipated market conditions. That vision must be expected to flex and adjust as understanding of future market conditions change, but it must always be stated in terms that all organisational members can understand.

Identifying Core Business Processes:

With the strategic vision for the organisation in mind, the next step is to define the core business processes necessary for the future organisation to function. These processes may exist across the legacy organisation’s organisational structures.

Designing around Core Processes:

The next step is development of a schematic representation of the “end state” company, organised around the Core Business Processes defined in the previous step.

Transitional Organisational Forms/ Developing Support Systems:

In his transformation model, Hernaus recognises that information management systems designed for the legacy organisation may not be able to meet the needs of the process management teams in the new organisation. Interim management structures (that can function with currently available IT system outputs) may be required to allow IT professionals time to redesign the organisation’s information management system to be flexible enough to meet changing team needs.

Creating Awareness, Understanding, and Acceptance of the Process-based Organisation:

Starting immediately after the completion of the Strategic Analysis process described above, management must devote sufficient resources to assure that all organisation members, especially key managers, have a full understanding of how a process-based organisation functions. In addition, data based process management skills need to be provided to future process team members. It is not enough to schedule communication and training activities, and check them off the list as they are completed. It is critical that management set behavioural criteria for communication and training efforts that allow objective evaluation of the results of these efforts. Management must commit to continuing essential communication and training efforts until success criteria are achieved. During this effort, it may be determined that some members of the organisation are unlikely to ever accept the new roles they will be required to assume in a process-based organization. Replacement of these individuals should be seen as both an organisational necessity and a kindness to the employees affected.

Implementation of Process Teams:

After the completion of required training AND the completion of required IT system changes, process teams can be formally rolled out in a planned sequence. Providing new teams with part time support by qualified facilitators during the firsts weeks after start-up can pay valuable long term dividends.

Team Skill Development and Continuous Process Improvement:

Providing resources for on-going skill development and for providing timely and meaningful recognition of process team successes are two keys for success in a process-based organisation. Qualified individuals with responsibility for providing training and recognition must be clearly identified and provided with sufficient budgetary resources.

The Hernaus model for transformation to a process based organisation is both well thought out and clear. His paper provides an ample resource of references for further study.

Contact Us

  • (+353)(0)1-443-3807 – IRL
  • (+44)(0)20-7193-9751 – UK

Ready to work with Denizon?

Contact Us Today