|
||||||
|
In a recent blog I wrote about Deviations and Concessions, temporary changes that allow you – when necessary and under control – to not do things the way you normally do them. But what happens when the change is permanent; how do you manage change? This is a well-established part of quality management and you may be quite familiar with Change Requests or ECRs (Engineering Change Requests) and Change Orders or ECOs (Engineering Change Orders) or sometimes ECNs i.e. Notes. So, rather than go through the basics, I thought it might be useful to look at some of the issues and subtleties. What system do you need? Quality Management Systems invariably have a change control facility built-in, as do Product Lifecycle Management systems (e.g. Agile) and many MRP or ERP systems. There are also many stand-alone systems available. For organisations that mainly produce documentation, an integrated document control system such as SharePoint or CogniDox (or others) could provide the required version and change control. For companies that produce software, configuration and version management is crucial and they will probably want to use an established tool, from an open-source system such as CVS or Subversion up to an enterprise-level application such as IBM’s Rational ClearCase. However, for many hardware-producing companies, if they don’t already have an integrated system for change control they don’t necessarily need to make a large investment; it can be provided via a simple paper or e-forms based system or a DIY database. How many forms? Many organisations that take a DIY approach use separate documents or templates or e-forms, etc, for ECRs and ECOs (or ECNs), the former being used to request a change and the latter to implement it. However, some organisations use one single form or template to request a change, assess it (see below), approve and implement it. You can also use the same process to release products or documents for the first time rather than to change them. What are the consequences? All ECRs / ECOs / ECNs should define what needs to change and why. However, for me a key part of change control – and one that is often missed – is to assess the consequences of making the change before you commit to it. What are the costs, including re-work or scrappage? What effect will it have on timescales? What risks will it introduce? Will it invalidate any approvals or require re-testing? Will customer, sales or marketing documentation need to be changed? Will customers need to be advised (does it affect compatibility with other products)? Will test systems need to be changed? Will production systems need to be changed? Will you need to swap-out sales or production product samples? Any actions resulting from these consequences will need to be properly managed if the change is implemented. You will want to make sure these questions are asked and the results and actions agreed by all the ECR / ECO signatories who must cover all the relevant parts of the business and must agree that the change is worthwhile after taking into account all these consequences… Who signs it, and why? How often do you see these things being signed without the person actually reading the document? Are people signing to say they are merely aware of the document’s existence or to say they take full responsibility for everything contained within, including costs and consequences? Here’s a thought – if you are designing a template or form that has sign-off boxes, write down exactly what each signatory should check and sign for. Make it explicit, then it can becomes a meaningful process rather than tokenism. (Then use internal audits to verify they are doing it right!) How do you know the change has been made? You make be able to implement the change immediately or you may have to wait until a certain time, or after a certain number of units has been produced, or at a certain product serial number. Your system should allow this cut-in point to be specified; you should ‘close the loop’ and make sure that the implementing of the change is recorded as proof that it was done correctly. How do you keep track of what has changed? You may have very few changes in what you do and may not need anything other than a record of the changes having been made. Lucky you! However, for many companies the changes accumulate and become complex to administer, especially if using third parties and especially for low volume, high mix products. How do you know what changes were applied to product XX, serial number ABC12345? How do you know what changes the system shipped to Customer YY on 08/04/2009 had applied to it? Can you identify all the products shipped with Change ZZZ applied to them? There are two main ways of answering these questions. The first requires a detective job in which you cross-check build records, change control cut-in dates, serial numbers, etc, etc, and work out what changes applied to any given item. It can be painful and slow, but it’s the way that many companies do it. The second is to fully manage product configuration; you keep a record of what changes / deviations / concessions / etc, and often what specific subassemblies or parts, are applied to every single product. This is more difficult to do, requiring more comprehensive systems or databases, but gives better traceability and is a must-do for high integrity / high safety systems; only you can decide if it is worthwhile for your business. I hope this has given a few useful pointers as to how Change Control can best meet your requirements. For many organisations it doesn’t need to be complex, but to be meaningful and effective it has to go beyond mere tokenism; you should be actively managing change, not merely watching it wander, out of control, past the window! If quality is doing “exactly what it says on the tin” (courtesy of Ronseal), what happens if you really don’t want to? What happens if you knowingly choose to do something else? Presumably that isn’t allowed? Well, yes it is. Quality management shouldn’t be a straightjacket. Of course, if you’re dealing with safety-critical applications or other high security, high safety, high risk or cost areas there are many restrictions and must-do activities – some aspects of quality aren’t up for negotiation – but sometimes it is highly appropriate to deliberately not follow the normal processes or standards. However, you should do this in a controlled way rather than just allowing anarchy. The way to do this is called a ‘Deviation’ or a ‘Concession’. The two are slightly different in that a deviation is before the event – you choose to do something not in the normal way or to the normal specification – whereas a concession is an acceptance of something that is already not to the normal specification. One way of thinking of it is ‘the supplier deviates and the customer grants a concession’. But this subtlety is often lost and, for many people, not worth worrying about; the key principle is that if you choose not to follow your normal path, do so in a managed, measured way. So a common technique is to have a deviation (or concession) form, or electronic template, or database or other system that records what you are doing in a different way to normal, why, authorised by whom, and – most importantly – for how long… because a key characteristic is that deviations (I’ll stop adding “and concessions”, take that as read) are temporary. They are made to expire after a certain time period, or after a certain number of units are made or cycles of activity are complete, or after a predictable set of circumstances are met. Deviations are controlled, measured and time-limited changes. If you want to make permanent alterations you use change control; I’ll talk about that another time. Typically, a deviation note contains:
If you are designing your own system, the ability to add attachments is hugely valuable. You would also be wise to add the ability to automatically flag up the expiry of deviations, i.e. have the system send a message or email to the user when its expiry date is approaching. Of course, you may already have a change control or Product Lifecycle Management system that has deviations and/or concessions built in but, if not, you don’t need to go out and buy an expensive integrated system, you really can do it yourself using Excel or Word or Access or any other simple document or database technique. Finally, if you are introducing this facility into your processes, make sure it isn’t abused or over-used. Deviations should be the exceptions not the norm. Check they really are temporary and they really are time-expiring automatically and things then revert to normal. Check that expiry times are not excessive. Check that they are being signed off at the appropriate level and are being properly stored so that, if problems subsequently arise, you can back-track and understand what was done when and why. It’s great to see a real home-grown high-tech success story in the UK. Cambridge Broadband Networks, a company I know well, is just such a success. They’ve recently celebrated their tenth anniversary and are growing very quickly at the moment, in fact they are one of the top 50 technology hardware and equipment sector companies as recognised in the Department for Business Innovation and Skills 2009 R&D Scoreboard, and were in the Sunday Times Tech Track 100 in 2009 and a finalist in Growing Business magazine’s Fast Growth Business of Year Awards 2010. Cambridge Broadband Networks design and manufacture next-generation microwave communications products that provide broadband data and voice for mobile phone backhaul (3G, HSPA and 4G/LTE) and access. They sell to emerging markets in the Far East, Middle East and Africa as well as in Europe, and their highly innovative ‘Point to Multipoint’ architecture is, in many applications, more technologically advanced, much more future-proof and far more cost-effective than any of the competing solutions. The company is recruiting hard and is currently looking for product managers, hardware and software engineers, customer support engineers, business development people, test engineers, and other roles, mostly UK based but with a few overseas roles too. I promised the good folks at Cambridge Broadband that I’d mention their search on this blog site. If you’re interested, have experience in wireless comms, and are local to the Cambridge (UK) area, they have an open recruitment evening on Wednesday 11 Aug, 5-7pm to discuss the opportunities; even if you aren’t local you can find more details on their website: http://www.cbnl.com/about/vacancies.html No, I’m not talking about lipstick and blusher despite the tongue-in-cheek introduction. Cosmetic Inspection refers to the quality of the surfaces of products or equipment, especially those surfaces that are visible to the customer. Nothing is perfect; no material is entirely defect-free (especially if you look hard enough), so what scratches or blemishes or discolouration or badly-formed edges are acceptable to your company and its customers? What defects are unacceptable? How do you decide? This is somewhat of a minefield for the Quality Inspector and the supplier alike, because you are trying to quantify and form a go / no-go decision on something that is highly subjective. So how do you decide what cosmetic quality is acceptable versus unacceptable? I suggest that you write, then evolve and continuously improve, a Cosmetic Inspection Specification or Standard. Now, I can’t simply write one for you here and now because (a) I haven’t got the space and (b) I don’t know what products you produce for what markets. What I can do is to give some guidelines about the things that you should think about putting in this document to make it as useful – and as consistently applicable – as possible. Materials You will have different requirements for self-coloured plastics as opposed to clear plastic windows or sheet or cast metal. Plated surfaces can have discolouration and can show underlying flaws, paint can have blemishes, runs, different textures and embedded specks. Different materials and surface finishes can show defects in different ways so it’s unlikely that one simple rule will suffice; be prepared to have different sections of the specification for different materials. Surfaces Although no-one likes defects anywhere, surfaces that face the user are usually more critical than bottoms or back panels. You can categorise your surfaces and allow more blemishes on the less important faces whilst imposing higher standards on front panels or display windows or anything frequently seen by the user. For many types of surface it is common to permit certain specified minor defects so long as the integrity of the coating isn’t breached, e.g. so that you don’t let moisture in which could lead to corrosion. Time, distance and lighting Given enough time, light and a magnifying glass you’d be astonished what defects you can find, but that’s hardly a fair test. Will your customers apply the same techniques? (If they will, you should too.) It is usual to have a standard inspection distance – perhaps 1 metre, specified lighting of a certain luminous intensity, and a time limit (such as 10 seconds) for finding the blemishes; these can all vary depending on the products, surfaces and materials involved. Size Which is worse, a deep, short scratch or a very fine long one, a patch of noticeably different texture on a surface or a fine scratch across it? You will want to quantify what is acceptable and what is not acceptable; how many defects of what size will you permit? Defect density and orientation Very fine marks parallel to a panel edge (often caused by tooling) are often less objectionable than scratches at random angles; a group of small scratches concentrated in a limited area can be more noticeable than a few very fine hairline defects distributed over a large panel. You will need to specify what is acceptable for your products, surfaces and customers. Colour and Texture These are some of the most difficult parameters to get right because colour and texture often interact and can be greatly affected by lighting conditions. Getting dissimilar materials to match in colour, or plastics to match with metals, can reduce even the best engineers to tears; often the answer is not to try – deliberately use different textures or colours for the different materials, although sometimes you have no choice and detailed specifications and samples… and tenacity… are required. Burrs, dents and manufacturing marks Will you allow weld or solder marks to show? Glue seepage? Dents where spot welding has been done? What about the finish of edges, how much trimming or burrs or grinding marks will you let show and will you allow any sharp edges to be present even on normally hidden surfaces? What about sink marks, or flow or ejector marks, or voids? What marking or burring of screw or bolt heads, or the surfaces they mate up against, will you allow? At what point will you decide there have been lapses in workmanship and the defect is unacceptable? Alignment What misalignment will you allow between panels or other mating surfaces? What gaps? How straight must labels be, and will you allow any bubbles under them or curling, overlaps or smudges? Examples and photographs In the end, you can follow all these guidelines in great detail and write a really thorough, objective, detailed specification but still end up with ambiguous results. Why not take a leaf out of well-established standards such as the electronics workmanship standard IPC-A-610 and include photographs of what is acceptable and unacceptable to clarify your requirements? ‘Golden samples’ i.e. reference parts that are used to define exactly what you require, can also form a useful part of your standard. How you define cosmetic defect acceptability depends on your products, your markets and your customers. But, if you haven’t got a written specification already, wouldn’t it be useful to have an agreed cosmetic standard to work to? Of course it will have to change over time, and sometimes you will have to concess or deviate from it, but at least you and your suppliers and customers can all be ‘singing from the same hymn sheet’ and that has to be a good place to start. Ignore some of the more disparaging descriptions of what ‘M.T.B.F.’ means; it actually stands for Mean Time Between Failures (or, for products that can’t be repaired, the term Mean Time To Failure is often used instead). It’s the inverse of the annual failure rate if the failure rate is constant. And it isn’t quite what you might think. What is the MTBF of an 25 year old human being? 70 years? 80? No, it’s actually over 800 years which highlights the difference between lifetime and MTBF. Take a large population of, say, 500,000 over a year, and seeing how many ‘failed’ (died) that year – e.g. 600 – so the failure rate is 600 per 500,000 ‘people-years’, i.e. 0.12% per year and the MTBF is the inverse of that which is 830 years. An individual won’t last that long, they will wear out long before then (unless they are Doctor Who), but for the population as a whole, in that ‘high reliability’ portion of their lifespan, it holds true – in a typical year you will only have to ‘replace’ 600 of them. So why measure MTBF? “If you can’t measure it you can’t manage it” – knowing your MTBF allows you to benchmark yourself against competitors and can be a marketing asset; many customers expect you to know and disclose your figures. It also allows you improve the weak spots in your product range, and is useful feedback for the design process. There are two main methods for calculating MTBF: MTBF Prediction is a mathematical model of reliability, based on accumulating the individual MTBFs for the product’s constituent parts and subassemblies, gleaned from manufacturers data or libraries of standard figures and mathematically combining them into an overall figure. MIL-HDBK-217 (MIL-STD-217) was one of the first methods and is still very well known although other schemes have since come into common usage such as Telcordia’s SR-332, BT’s HRD5, and others; there are software tools available, from free to megabucks, that help you make the calculations. These theoretical methods are supposedly based on empirical evidence but have a number of flaws, primarily that (a) the individual parts never actually have the MTBFs you expect of them, and (b) combining them mathematically ignores many of the real-world effects that dominate the MTBF of the whole product. I once designed a large audio mixing desk whose predicted MTBF according to MIL-STD-217 was less than 8 minutes; I’m glad to say that, in practice, it was a great deal longer than that! MTBF Measurement sounds simple in principle; count how many failures you have in a given period of product usage and some easy maths gives you the MTBF. The Devil is in the detail, though – doing statistically meaningful averages over large volumes and long periods is easy, but what about small populations, and what if you need answers quickly rather than waiting for several years? In practice you have to make some assumptions, the main one being that your failure rate is constant. Now this may not be true; if we take the classic bathtub reliability curve you may have a long drawn-out leading edge with a high level of infant mortality, or you may have a long trailing edge where products start to fail prematurely after relatively little life in the field, but both of these are problems that you would need to do something about urgently. The norm is to have a fairly long period of constant reliability – bumping along the bottom of the bathtub – and in this zone the failure rate over a short period can be extrapolated to the rate that would be achieved over a much longer period… as long as it is within the published lifetime of the product (the MTBF of an 80 year old human is not 830 years!). So take the date that you shipped a unit to a customer, add a little time for the customer to put it into service, then open up a ‘sampling window’ in time of, say, 6 months to look for any failures. If the failure rate is constant then the annual failure rate is twice the number of failures in the 6 month window. If the units are used 24/7 the MTBF in years equals the number of units built divided by the annual failure rate (back to 500,000 25 year old humans, divided by 600 failures, equals 830 years MTBF). Periodic use, say 8 hours a day, would require the MTBF to be scaled down accordingly (because it has clocked up fewer operating hours per failure, hence a lower MTBF). Don’t be too harsh on yourself, by the way; you wouldn’t normally expect to count units returned as faulty but that turned out to be No Fault Found, or units damaged by the customer or in transit, or units that were prototypes and not expected to have the performance and longevity of production units, or units that had not been properly serviced or maintained or had reached their published end of life, so you can normally exclude these from the calculations. And how do you define a failure – does the malfunction of a single dashboard bulb in a car mean the whole vehicle has failed? You will want to have a sensible, defensible criteria for “fail”. Now, I plead guilty to dramatically simplifying the subject; what about Mean Time To Repair, what about non-linear failure rates, what about the difference between constant failure rate and constant failure density, what about adding normalising or scaling factors to match different environments? All valid questions and, I’m sorry to say, beyond the scope of this short blog. However, the key message is that you can calculate MTBF quite easily with a little patience and a simple spreadsheet, and it’s a very useful figure to have. No, it isn’t a Madonna song or anything written by New Order for the England football team! In order to go somewhere that you want to be you need to know where you are now, otherwise how do you know in which direction to travel? A key element of many Quality Management Systems – for example, ISO 9001 – is the idea of self-assessment, often called ‘internal audit’. This differentiates itself from the external audit where an expert body such as BSI or LRQA or others comes in and assesses you against an official Standard. The internal audit is done by members of an organisation for its own benefit and is seen as more frequent, less formal, and hugely beneficial in that it helps both the auditor and auditee equally – everyone learns something. Although some purists insist on acting in loco Assessment and Certification body, making the internal audit indistinguishable from its external cousin, I have always taken a more flexible, friendly and interactive approach to get the best out of the process. (Not to imply that external auditors can’t be friendly too, of course!). As an internal auditor (whether a member of the organisation’s staff or not) I think you are there not only to assess whether the Standard or the processes are being implemented as it ‘says on the tin’, but also to help the auditee understand the system and to improve the processes or procedures where they fall short of what is required, preferably before they lead to problems in products or services or other areas. It allows people to express their concerns and views about how work is done in the organisation, and it helps you to identify best practice. In other words, this is a key mechanism for ensuring Continuous Improvement. To start the internal audit you need to agree its scope, i.e. what specific areas of the business and what processes or systems are you covering. You will want to examine documentation or computer records, perhaps looking for specifications, diagrams, standards, procedures, records of processes or tests being done, checklists, analysis, Corrective Action records, and so on. You will certainly want to ask questions of the auditee and please make these open questions (what, why, how, etc) not closed or leading ones (“do you follow the process?”). Look at the way that information flows and processes interact. How do people know when to start a process or a procedure? How do they know what to do? What are the steps they take and how do they know when and how to take them? Where are the records of them completing their actions; can they find documents and records easily? How do they know they have done the actions correctly and what happens when they have finished? Does everyone always use the processes they have described or are things sometimes done in a different way? How could the processes or procedures or systems work better or be easier to use? It is important to de-personalise the process and make it objective rather than subjective wherever possible; look for specific evidence of something being done or not done. Use the auditor’s favourite phrase “show me…” to search for objective evidence not merely opinion, although for an internal audit both are important. Make sure you write down the details of documents or facts presented to you, then what else that led you to, then in turn what that led to, and so on, as a record of what you saw (‘audit trails’). Your audit report can be very short – mine are rarely more than two pages and usually only one – and cover who was audited by whom and when, the scope and the standard being assessed against, the audit trail i.e. reference number and name of any documents, files or other material that you looked at, and a summary of what you found including Non-Conformances (i.e. not doing ‘what it says on the tin’), agreed Corrective Actions, or areas where you both think that improvements might be appropriate. By the way, the words ‘agree’ and ‘both’ are critical here, the findings should be fully and willingly agreed to by all parties as it’s your joint work rather than an examiner’s report! If you see areas that do need improvement the Corrective Actions (or maybe Preventive ones) should also have the buy-in of the people who are affected and responsible for that area of business as well as the auditee. Most of all, just to re-iterate, the Internal Audit is not a test. It is a way of helping the organisation and the people in it improve their ways of working and should be seen as a constructive and collaborative act not an assessment; it should contain no element of blame. In other words, it’s about seeking improvement not criticism. Internal Auditor Training How could the processes or procedures or systems work better?
Another preventive technique I recently promised to blog about was risk review and analysis. This is an approach used to reduce or manage risk; we aren’t necessarily trying to achieve zero risk (if there’s no risk at all you often get little benefit) although in areas such as safety or security a zero-tolerance approach to risk is necessary. The risk review can be used in general business management – strategy development, marketing or sales initiatives, new product or service offerings, and so on – through to product development projects that have risk review sessions as part of their project management process. Special, rigorous instances of risk review are used in areas such as Health and Safety management. I have found the best way to run risk reviews and risk management is as a group activity, i.e. in a workshop meeting, partly to get key people’s buy-in, partly to enhance creativity – bouncing ideas off each other and gaining different perspectives (one person on their own will always miss something) – partly because you will need volunteers, and partly because peer pressure can save you having to continually nag people to do their actions! I suggest that ‘risk review groups’ meet regularly, e.g. every month. You may only need one group for the whole business, or you may choose to have project or function-specific groups as this can often be a better way of delegating authority and responsibility to those who can really make things happen. The tool at the heart of the process is the risk register, which is a simple matrix or table. Each row in the table describes a different risk that has been identified. The columns are typically: 1. A reference number (so you can easily refer to that specific risk) 2. Description of the risk 3. Date the risk was first identified (and sometimes the name of the person who first identified the risk) 4. Type of risk, e.g. Technical, Project, Business, Health & Safety; alternatively, this could be changed to what or who is at risk 5. Probability of the risk occurring (e.g. L = <10%, M = 10-30%, H = 30-50%, VH = >50%) 6. Impact on the business or project, etc, if the risk did occur (e.g. L = <1 week delay or £10k, M = <1 month delay or £50k, H = < 3 month delay or £100k, VH = > 3 month delay or £100k) 7. Person who is responsible for managing the risk (this is where you need your volunteers) 8. Mitigating actions that are to be taken, i.e. actions that will eliminate or reduce the risk or its impact 9. Status or progress of each mitigating action 10. You may also find it useful to add an owner, or person/s responsible, against each mitigating action. Some people also combine 4, 5, and 6 into an overall Risk Severity rating. At the first risk review meeting in any particular area you work out, using structured creativity techniques such as brainstorming, what risks may possibly affect you, then agree on their type, probability and impact. For each of them, especially the medium/high impact, medium/high probability ones, you again use structured creativity techniques to decide what mitigating actions could be taken then choose the most suitable ones to implement. You may want to apply a hierarchy to the actions; e.g. you may prefer an action that eliminates the risk over one that simply reduces it, which in turn you may prefer over one that merely reports the risk if it occurs. All High Risk / High Probability risk areas should be formally reviewed at each subsequent risk review group meeting, although for practical reasons it may not be worth reviewing all areas at every meeting. However, the responsible person must monitor his/her risks and warn Management immediately of any increase in the probability or impact of that risk, or of other related concerns. Any new risks should also be identified at each meeting. The risk review matrix or table is usually reported upwards to senior management or, if this provides too much detail, simple Key Performance Indications can be derived. A particularly useful measure is to show whether risks are reducing over time, as the mitigation actions start to kick in, or whether they are growing; a simple red / yellow / green traffic light colour code can be effective in drawing attention to risks that have suddenly worsened or don’t seem to be under control. It is important for risk review and management to be a proactive process; that’s why it’s a preventive technique rather than a corrective one. The mitigating actions in the table should be seen a starting point rather than the only action ever required; the person responsible for managing each risk should continuously monitor their risk area and take further actions to reduce the probability or impact of the risk and report it to the risk review group. I think you’ll find his approach to be simple, easily understood and effective. The management of risk in this way helps you to become more in control of your own destiny rather than continually responding to events as a knee-jerk reaction! Poka Yoke (“poh-ka yoh-kay”), translated as mistake-proofing, was developed by Toyota manufacturing engineer Shigeo Shingo in the 1960s. (Its original name, ‘fool-proofing’ was changed because some people were offended by its implications.) It’s another preventive technique that I recently promised to explain in more detail. Poka Yoke is a simple but effective approach to reducing errors and defects in any business or manufacturing process by removing the opportunity to make the mistake in the first place; it eliminates the need for particular concentration or skill or memory to get the process right. Often several different Poka Yoke techniques are used at the same time on the same process or assembly, each preventing a different potential error so that the process is robust and virtually impossible to get wrong. Having said that, some people also use it for early detection of errors by making them immediately obvious, although I’m not keen on that interpretation, I prefer to keep it purely for preventing the problem occurring in the first place. Poka Yokes usually involve devices like fixtures, jigs, mechanical interlocks or switches, and warning mechanisms that prevent people from making mistakes even if they want to! They automatically stop machines or mechanisms, prevent components being assembled the wrong way round, guard the users against hazards or warn them if something starts to go wrong. Yes, they could involve sophisticated computer vision systems, sensors and lots of software but more often than not they use something like a peg fitted to a block of plastic or a mechanical part that is asymmetrical so it only fits in its hole one way round. The most effective Poka Yokes are usually very cheap and very simple. How to develop Poka Yokes The great thing about this technique is that anyone can do it; once you have the right mindset it’s something that a bit of common sense, some creative thinking or brainstorming, and a little experimentation can deliver. The first action is to look at what can go wrong, because – as per Murphy’s Law – anything that can go wrong will go wrong. What sort of mistakes can and should be prevented? Could the wrong number of parts could be used, or the wrong type of parts (e.g. too few screws of the wrong length), could you forget to apply thread-locking compound or miss out the adhesive from an assembly operation? Could you use incorrect machine settings, or make measurement or calibration errors? Could you work to the wrong assembly documentation, or miss a key stage of the assembly, or fit the wrong connectors or cables together or fit them in the wrong orientation? Do you have examples of where things have already gone wrong? You could have a brainstorm or any other structured creativity session about what errors might possibly occur, however far-fetched. Try using ‘reversals’ – rather than looking at how to assemble it right, look at how you could assemble the item incorrectly if your life depended on doing so. Then come up with the simplest possible mechanism, or technique, or tool, or jig that would eliminate each error at source. If you can’t possibly stop an error, as a second-best how can you show that it has occurred as quickly and obviously as possible? Then test the mechanisms or techniques or jigs to see which combination works best, then put them in place and train your staff in their use. Examples Good Poka Yokes include things like ‘keyed’ plugs and sockets that prevent the wrong connectors being fitted together or fitted the wrong way round, or asymmetrical hole patterns in matching plates so they can only be screwed together the right way round, or cut-outs in Printed Circuit boards that only allow them to be fitted the correct way into an enclosure. The bevelled edge on a mobile phone SIM card is a good example, as it stops you inserting it the wrong way round, as is a guard over a button that stops it being pressed by accident. As another example you may decide to pack exactly the right number of nuts and bolts for a given assembly in a container that travels with each assembly; if you have any left over at the end, or if you run out, you can easily see this and look into what has gone wrong – this can save you from leaving fixings off the assembly or from the ‘loose screw problem’ – spare fixings rattling round loose inside the unit because they were dropped in there. Do a Poka Yoke on your Poka Yoke Never underestimate the capacity of some folks to get things wrong! People can be ingenious. Although colour coding has its place, don’t over-depend on it as a significant proportion of the population is colour-blind. If you’re designing mechanical interlocks remember that people are stubborn and may force things even when you think it’s obvious they shouldn’t be fitted that way round. Safety interlocks can be defeated – try to defeat yours and see it it’s possible. Do a Failure Mode and Effects Analysis on your design – what would have to go wrong to render the Poka Yoke ineffective? And when you’ve implemented them, review the effectiveness of your Poka Yokes; keep an eye on them and make sure they are delivering the results you expect after a period of time. Is Poka Yoke difficult? Frankly, no; as with many Japanese quality techniques it’s mainly applied common sense but the trick is to actually apply it in a structured, planned way and make it stick. Mistakes will be made – people are only human – so find ways of preventing those mistakes leading to defects in your products or services. Educate your colleagues, set up some Poka Yoke sessions, get some quick wins under your belt and show how everyone can help reduce costs and reduce waste through the application of good, sound, common sense Poka Yoke techniques. Then keep doing it! I worked in one of the large Cambridge-based technology consultancies for many years and was privileged to have clients from small, inexperienced start-ups to large, established mature enterprises. Sometimes we developed products from scratch but sometimes we were brought in late in the day to sort out a client’s project that had gone wrong. One of the key tools that we used was the formal design review. We used it during complete product developments – it was an integral part of our ISO 9001 processes and we were trained how to do it – but it was of even greater benefit when we were parachuted in to rescue a project. I have used the same technique with clients ever since. However clever the designers, however sophisticated the design, this approach finds bugs. Peer-reviewing new designs before you commit a lot of time and money can be hugely beneficial in preventing problems further downstream… if done properly. Process Your people will naturally be capable of finding design weaknesses if given the opportunity, environment and culture that encourages them to do so, even if – especially if – they aren’t personally involved in that part of the design. The review is done by a selected group by peers (colleagues) from different disciplines; electronic engineers, mechanical engineers, system architects, manufacturing people, software experts, etc, under the chairmanship of an experienced reviewer not the designer/s themselves. The timing of the review is usually set by project management but is typically at a point in the project where a significant commitment of time, money or risk is about to be made e.g. release of design details into prototype manufacturing. For a complex design the requirements specification, functional specification and the design documentation should be circulated in advance so the attendees can spend time understanding it and assessing it for themselves. The design review meeting then reviews and challenges these findings. For a simple design, or an iteration, the findings can usually be derived on-the-fly during the meeting itself. In both instances the meeting decides on the relative importance of the findings and identifies the actions that needs to be taken. These are documented in a meeting note or minutes, and the actions are progressed to a conclusion through project or line management. Check List
To help guide the review, give it structure, and avoid omitting key questions, I have always found it beneficial to use a detailed checklist. This is added to over time so that it becomes a ‘superset’ of all possible questions. Many will be not applicable for any given circumstance so can be omitted, but it’s a way to avoid leaving anything out; it captures best practice for your products and industry. There isn’t room here to reproduce a generic checklist – in any case it should be bespoke to you and your business – but, for illustration, I would expect an electronic or electro-mechanical checklist to cover:
Specifications, risks, safety-critical areas, design fail-safes, use of unproven technologies or new design techniques. Schematic design: Gate and bus loading, I/O loading and protection, devices within Safe Operating Areas, production tolerancing, PSU monitoring / watchdogs, high current or voltage designs, spare IC pins (especially inputs), timing and synchronisation. Software / firmware design and prototyping, BITE, software to test hardware at different stages, GUI design, interoperability and standards compliance. ASIC design, timing analysis, hardware and/or software simulation. Industrial Design, mechanical design, tolerancing, tooling, robustness or life testing, mechanism optimisation, stress testing, HALT / HASS, pressure relief, fluid handling… I suggest that you draw up a checklist specific to your own products and technologies, then evolve the list over time on the basis of experience and as a Corrective Action if you find that design shortcomings have slipped through its safety net. In any case, it isn’t the list itself that’s important, it’s the things that going through the list – and asking questions of each other in a constructive way – brings up. And, as a bonus, it’s a very effective way of addressing ISO 9001 Section 7.3.4. They don’t like it… Instinctively, some design engineers don’t like this process. If not done well they can feel like they are under unfair pressure or criticism. I had one engineer say to me recently “it was a waste of time, most questions were irrelevant, it took too long”. “Sorry to hear that”, I replied, “so you didn’t find anything that could be improved?” “Oh yes, we spotted some things we definitely needed to change…” QED! The fix for their reluctance? Make it constructive not critical, make it relevant, show how effective it can be as a design safety-net, and make them part of developing the process so they are passing on their experience and knowledge to others. By finding and fixing the design shortcomings and risks at this stage you can prevent hugely expensive field failures or product recalls; I suspect that, given their recent experience, Toyota wish they had done better design reviews…
Windsurfing4CancerResearch, Grafham Water 2 May 2010
Gosh that was hard… After a month of lovely warm, dry weather, the day of the Sunrise Sunset event dawned with the thermometer well under 10 degrees C, heavy rain and blustery winds. Lovely! Although only 15 of us were participating at Grafham, there were over 200 windsurfers across the UK all trying to raise money for the cancer charity. Everyone had their own goals; mine were 50 miles if the weather was grotty or 100 if it was great. I think we can safely say it fell into the grotty category… We knew that however fast we went in a straight line the corners would slow us down; we had to do long straight runs. There was a big national dinghy sailing event at Grafham – 300 teenagers in little ‘Topper’ boats – so the windsurfers’ strategy was to get out early and clock up as many miles as we could before the lake got boat-logged and we were stuck in a corner. We took to the water at 9am with the dinghies due out at 10.30. Within a few minutes I found the first problem. Yes, I could get up a decent speed but as soon as I hit the corner it all went pear-shaped. I could turn the board OK but when I grabbed the mast or boom on the other side I couldn’t grip it – my hands were too cold, so the sail just pulled itself out of my hands and I went for a little swim.
The wind was very up and down. Sometimes it would go from a hardly-moving-at-all-5mph to a rip-the-sail-out-of-your-hands-30mph in just a second or two… or the reverse. Very difficult conditions as I could never settle on the board, I was continually moving around trying to get some control. The driving rain was stinging my face and hands so it was difficult to see as I had my eyes half shut! Two and a half hours gone, wind dropping, time to come in and change to a larger board and sail; this might help to reduce my swimming time as it will give me longer to persuade my hands to work. Well, it was a good theory… The wind decided to get back up again with a vengeance. OK, so I’m covered in mud but at least I’ve got the kit back. Limp across to the beach for a very necessary break. Pasta and soup although I couldn’t finish it. Too cold; starting to shiver continuously, even after diving – wetsuit-clad – into a hot shower. Not a good sign! So I had a long break and that was probably a bad idea as it was all downhill from then on; longer breaks, shorter time on the water. I was completely shattered; I’d go out feeling OK but within 5 minutes I was falling off repeatedly and didn’t have the energy to get going properly. I know what the marathon runners mean by ‘hitting the wall’. You get into a vicious cycle of making a silly mistake, falling off, struggling to get going, making more mistakes, falling off again, etc.
I could only manage about half an hour without a break or I risked not being able to get back into the beach at all. I couldn’t stand the ignominy of being rescued! I hadn’t so much ‘hit the wall’ as run into it headlong and had it collapse down all over me! But gradually, in little slow chunks, I ate into the 50 mile target. The dinghies had, by now, abandoned racing as the weather was much too v I don’t think I could have gone another hundred yards, but I made it. Some windsurfers did less, some did more, but given the conditions, the cold, the numbness of the hands, the swimming, the exhaustion, the lack of fitness despite hours in the gym, I thought that 50 was OK for an unfit old git of 55 with little windsurfing ability! Total distance covered = 51.2 miles Top speed recorded = 28mph, although my average speed was clearly a lot lower than that!
Calories burnt over 8 hours = 4600 (although I really can’t recommend it as a viable diet). Maximum heart rate = 162. Average heart rate, over the whole 8 hours = 122. But, most importantly, money raised for cancer research = £250 (and about £15,000 in total by everyone participating in the event across the country).
|
ABOUT ME
I've worked in industry as a consultant, manager and business trouble-shooter for most of my career.
After spending 14 years in a multi-national consulting organisation and 10 years working in telecomms design and manufacturing start-ups, I set up the Cambridge-based (UK) consultancy Primilis (http://www.primilis.com) in 2006. |
|||||
|
Copyright © 2010 Quality and Product Insights - All Rights Reserved |
||||||
