All entries for March 2009
March 31, 2009
I was talking to dad today and the topic of what I have learnt over the past 5 months came up. I told him business improvement is a underlying theme throughout most of our modules. In particular, I bring up Six Sigma telling him how I am doing a dissertation on it. Then I was surprised when he said he heard about it while citing the success GE had with it. But he didn't know exactly what it is except that it is being used in many large corporations.
Then I went into a bit of effort explaining (poorly) the bell shaped curve and the DMAIC methodologies . And he suddenly throw a question at me "So how will it help my company?". I was a bit taken aback because I wasn't expecting it. So I fumbled a few words like "Well, your company is a importer of milk powder, and your main customer are pharmacies... but six sigma is more suitable to manufacturing... but it may be able to help with the admin side of the business...". It was easy to see I was totally unprepared for his question.
Later that night, I spent some time reading an article on application of six sigma in Seagate UK (PC hardrive manufactuer) and it made the following comment
"Thus, the case findings, consistent with the literature, conclude that six sigma lacks evidence of success when applied outside the mass manufacturing environment" (McAdam & Lafferty 2004; p546)
So it had me wondering how useful Six Sigma is outside the manufacturing industry. I remember during the PIUSS module, the question of "Six Sigma in Service" came up several times, and the general idea at the time was "Yes! Six Sigma can work in non-manufacturing (service) industry too". But now I am less convinced and would like to see some evidence of that statement somewhere.
McAdam, R. and Lafferty, B. (2004). A Multilevel case study critique of six sigma: statistical control or strategic change? International Journal of Operation & Production Management. Vol24. (5). p530-549.
March 24, 2009
Again another interesting day for RDD. Today we studied Markov model, reliability Block diagram RBD, and Petri net
I feel even with the simple examples we used in class today, we can begin to feel the power of these tools in helping us to unravel and understand the working of a complex system
reliability block diagram , markov model and Petri net seem to be an extension of the Fault tree analysis from yesterday but focusing on the series of intermediate events that happens between an operating system and a failed system. This is represented by the RBD. Markov model represent the system as different states and add statistical probability to system being in each state as well as the transition between different states. And lastly the Petri net tells us about the sequence of event leading to a systemic failure.
Today's session fit well well with the CBE especially in Deming's first theory of profound knowledge - appreciation for the system. Until now the system idea has been a rather fuzzy concept, we know it's important and very influencial but we don't fully understand how to change or improve it. Studing this RDD module put the concept of system in a better perspective. It allows use to see why an big event is usually a working consequence of many other smaller sub events (or subsystems). Vice versa, how smaller seemingly insignificant and discrete decisions can lead to a much bigger often unintended consequence. Although we study this in an enginering context, it isn't difficult to see how it can be applied to other scenarios or disciplines. Most importantly, it at least give us some idea about how to go about modifying the system for business improvement.
March 23, 2009
Today's Robust design development RDD class was more than what I expected initially, considering yesterday I was contemplating dropping the module bcause I didnt think I was gonna find the material useful
But today we learnt how to do a fault tree analysis FTA. the FTA in principle is very similar to the Failure mode crtical analysis FMEA. Both helps us to understand a complex system by breaking it down into smaller more manageable componenets. For example , to understand how a water tank leakage could happen we would need to know what specific parts of the water tank (i.e. overflow pipe) could fail. And we get from the high level system down to low level part by continously asking questions like "what could go wrong with this?", or "why would this happen?" and drilling down to the lowest level failure mode until some event or failure mode requires no further explanation.
What I like particularly about the FTA is the addition of formal logics into the analysis. On a basic level we would need to think about for a certain event to happen, what needs to happen before it as pre-requiste, then we connect different levels events with the "AND" / "OR" symbols. For example, for the water tank to overfill, two events can happen simutaneouslt or individually
- water valve mechanism fails
- overflow pipe fails
If any one of the two event happen at one time , water will not overflow because the other back up mechanism will prevent water overflow. However when both event happen at the same time (denote by "AND" symbol), the higher level event (water overflow) will happen.
The most powerful bit with this analysis comes when the laws of logics is applied to the tree. We can discover the minimum "cut set" which is the minimum necessary event that has to happen before the high level event occurs. For example it may be contaminant in the water which leads to blockage of overflow pipe AND jamming the water valve. This information allows us to take rather specific and rational actions (as opposed to trial and error approach) to prevent the occurence of a particular event. Moreoever, combined probabality of all low level event in minimum "cut set" allows us to determine the probablity of occurence of a higher level event.
So how is FMECA different from FTA? In my opinion it seems FTA is a more powerful technique because it allows us to pin point exactly areas of design weakness whereas FMECA will tell us all the areas of potential failures. And the prioritisation of improvement effort in FMECA is based on a subjective judgement of importance (to safety) and criticality whereas FTA is based on rigorous logical analysis. In practice though, both are applied at the same time. Very often FMECA is carried out first to provide input data (i.e. what could go wrong) to the FTA. In addition, FMECA gives an additional consideration for importance to safety which tell us where the most critical area (may not be most common failure mode).
March 20, 2009
Just a short one today (yes I promise :p)
After spending sometime today, and yesterday trying to understand 'system engineering' (SE), I am afraid I have produced little result. Some of the sources I used are
- System Engineering Management (1991) Benhamin S. Blanchard
- System Engineering Method (1967) Harold Chestnut
- System Enginering from Wikipedia
Some initial readings suggests
- It's been around for ages
- Mirrors the system thinking principles from Peter Senge, but has a more engineering focus
- Employs some very similar tools and procedures to DFSS like QFD, optimisation, simulation
This kind of makes me wonder how different is system engineering from DFSS. Both appear to address the issue of design in the early stages, but one seem to focus on the product design (DFSS) whereas the other focus on the whole system (SE) i.e.how the whole company/organisation operates.
Part of my problem in understanding system engineering concept I believe may be my lack of background knowledge /experience in engineering type work. I find it interesting that the subject is not usually taught in undergraduate level (Wikipedia) simply because undergrad students do not have the background knowledge to appreciate the 'power' or 'application' of system engineering. This is precisely my problem as I flick through the pages, many ideas are 'high level' talks about being holistic , interdisciplinary, customer focus etc , complicated by complex process flow charts of how processes in a systems should look like.
I guess I shouldn't confuse myself with too much details. Perhaps I should think about system thinking from its conceptual viewpoint, compare that to DFSS or concurrent engineering, and see what are the similarities and differences.
March 14, 2009
Note: This entry is not specific to any person or team from MBE
Today's presentation was interesting for a few reasons. First Paul went into a lot of effort to make this 'class presentation' as 'real-life' as possible. Everything from the room layout, assign board of director, company background information added realism. Second, every team responded to this which is apparent from the heightened sense of seriousness, dress code, keeping to time, highly selective on the material presented.
How have we performed overall?
- As a class presentation? Quite well I think.
- As a real consultant presentation? We will get a 'D' at most, for participation
Why such low grade? Well, mostly because our presentation lacked 'persuasion' which is the feeling that we must start now and have some initial steps to work with. No feeling of urgency or practicality was conveyed by many teams, instead we had a lot of 'nice to have' reasons to implement KM or AM. Well, guess what! business executives ain't going to invest in big projects simply because it is 'nice to have'.
"Are you mad? How can you say that? We suggested many real solutions to Waveriders!". Yes, you did, teams tried several ways to be 'real', some made up problems they claimed exists within WR. Some try to match their chosen AM systems to WR's EU expansion strategy and claim it is 'useful' or 'nice' to have this system in place. But I doubt any of the board members was actually thinking "Oh my goodness, look at our company! It's broken, we must do something fast to fix it!". Rather, they were probably more like "Okay... I know these benefits, tell me something I don't know, like where do I start, what is the pay back period, give me something concrete numbers here..."
One thing I learnt from this presentation, and the process of creating it, is the importance of looking at the problem/issue as realistically as possible. Paul can do everything to make this realistic, but at the end of the day it is still up to us - the presenters to think realistic as well. The reason I say this is I noticed many teams (myself included) fell in the trap of doing things the same old way- focus on what the tools are and why they are important - pretty much straight out of any books on KM or AM.
What our KM team (francisco aykut and smily) did excellently (in my opinion) was to forget about the WHAT, the WHY but focus only on the HOW. Why is that? Because the directors probably are not very interested in hearing about WHAT is Knowledge Management or Facility Management because they probably know it more that we do. They are probably not interested in the 'theoretical' benefits either unless we can back them up with real cases (as Paul repeated pointed out from many teams). But to do this wold require
- Experience and knowledge about what make the executives tick (probably money $$$)
- A holistic understanding of the topic in order to apply KM/AM theories into practice.
One possible way to get closer to this goal would be to carry out research on HOW people actually implement it in practice, any real cases, why they have succeeded or failed. So if we get asked "How do you know this works?", we can confidently say " X Inc. implemented this Y years ago, it cost them Z dollars and they started making profit from it after U years".
To be fair, this was problematic from a lot of us because we are not used to this type of presentation. We are used to the 'theory' type of presentation where we learn what is A and why is A important, lectures, books, seminars all follow this format. But to a non-academic business executive, what is more important is how do we do it, how much does it cost, is the benefit immediate, does cost outweigh benefit? Things that depend on situation given, and require substantial industrial experience knowledge in order to say it with confidence.
It is possible had Paul worded the topic differently, we would have come up with a better approach. But I think he left it quite open ended to avoid putting too much constraint on our material and style. Nevertheless, with some deeper thinking, we could have arrived there as well.
This experience illustrate something about any public speaking we already knew but always forget to practice. "Know your audience". What do they really want to know? What are their interest? and most important WHY would they sit there fore 20 min listen to me. If we can think about that deeply before we prepare any presentation, we will bump our presentation quality up several notches.
March 12, 2009
I was reading an interview (here) of the founder of Acer Inc, a Taiwanese computer technology manufacturer, Stan Shi . In this he discussed the qualities of leadership he possess and this spurred some thoughts in my mind. Some of the things he said were
"I (lead) through the use of (people) organisation, not me personally driving (progress, change). Of course I utilise my persuasion skills, but my persuasion comes from understanding the psychology, thoughts of everybody, and combine them together. This is what I called "Meeting the expectation of the group".
"For example, when we first started, every young people wanted to make a difference, do something meaningful. At that time we tried to drive the second industrial revolution because we didn't have the opportunity to take part in the first one. So I said to my team. If we understand this, but still don't do it properly, we will carry the blames of history. I used this to motivate them, so they understood this is the right path to follow. I used this to activated what is on everyone's mind, (by finding their common grounds).
From this I wish to talk about leading in a group environment from my experience. Sometimes it is difficult to achieve what Mr. Shih refer to as finding the common grounds . Often individuals or leaders themselves focus on their argument/persuasion skills but forget to pay attention to what the group is saying or want. It is easy to argue with people on things we don't agree with. We find flaws in other people's logic and try to criticise it. It's almost a human nature and we do it intuitively. But at the same time, I do not mean leader should accept every suggestion made by group members. Of course there has to be crtical thinking on why a particular idea is useful or not. But before we rush to judge or criticise it, why not take a moment to listen what other group members have to say about it. Often initial ideas proposed by any one person will be unrefined and contain many flaws. But before we rush to criticise and treat it as unworthy, why not use the group mechanism to further discuss and refine the idea so that it becomes stronger.
This is why I believe a leader should not be a debater, but a listener. Before he/she had a chance to listen to everyone's views he/she should not rush to shut people down. Instead he should listen to all the voices and seek to reconcile the opposing views so that everyone can reach a common ground.
I remember when I did my undergraduate research project. I often rushed to carry out the experiments without thorough considerations beforehand. The end result is I realise there is a flaw in my experimental design, and make my result difficult to interpret or impossible to draw a valid conclusion. The consequence is plenty of re-do's and re-work which were both time consuming and expensive.
Today (Wednesday) I continued working on Taguchi experiment. I find the initial phase of research and experimental planning to be very time consuming. I needed to consider many aspects of experiment (selecting arrarys, control factors, assigning factors) all before I even start folding the planes. This is to ensure I do not make costly mistakes later on in the conducting experiment. This is the same idea as DFSS, where we want to make all the changes as early as possible to prevent costly changes later on. One book I frequently refer to for this PMA is Taguchi - Hands on approach (Peace 1997) is quite useful in this respect because it takes me through a step by step process, emphasising pitfalls and common mistakes, ensure all necessary precautions are taken to avoid making mistakes.
But the truth is even if I gave my best shot at paying careful attention to the experimental design, there always seems to some slip-ups somewhere in your experiment which you realise much later. For example, after I determined my design variable, and started folding planes. I forget to consider the effect of combinantorial (?) layout of orthorgonal arrays, which means some of the control factors are mutually incompatible with each other. Specifically, I couldnt have planes with a 6 inch wing span AND a 1.5 inch high wing tip both at the same time (due to paper size constraint)! This means I had two planes that turned out to be impossible to build according to my design specifications. It's too late to change things now because that would take too much effort. I will simply point that out in my pma reflection.
I guess the important lesson to take away from this, is the importance of spending time and effort on the initial experimental planning. Making sure you have considered everything that can go wrong in your experiment and take steps to mitigate the effects in case they happen. In most PMA's this is not so important because we can easily make changes to our essays on the computer. But for the project, especially if it involve surveys or experiment. It is handy to study books on experimental designs , many of which are mentioned in the REME module.
March 09, 2009
An interesting discussion came up in today's seminar about reward and recognition. It seems that the idea that 'recognition' could be a better motivational tool than financial 'reward' is hard to accept by many people. They would ask "How can I expect to receive only a pat on the back after making a huge contribution to my company?". Well, my answer is " No you should expect more!". But not more money, then what?
One of the biggest problem with financial reward is that it is never enough. This idea has popped up many times during MBE classes. You give a child one piece of cake for good behavior, the next time he is going to come back and ask you for two, the next for three and so on ... Does this mean he is behaving well because he is a good kid and listen to his parent? or is he doing so to receive the cake from you? . One immediate concern is the diminished return, the more cake the child receives the less he would desire it. So giving cakes becomes less effective the more you gave. "Give him candy instead", you might say. Well, the same problem persist and you are just changing from one form of reward to another. This is exactly the problem with reward based performance management,companies comes up with ever more inventive creative bonus schemes... 5 day holiday in Hawaii, membership in a prestigious golf club... you focus worker's attention on the reward itself but not on the purpose of rewarding which is the fact that they are doing a good job for you.
But imagine this, what if one day you exhaust all your creative reward ideas. Or worse, what if one day you run out of money, and you turn to your employee and say "Sorry mate, we are in a rut and I have nothing more to give you, but can you stay in the company? for old times sake?". Would it be a surprise if your employee, after telling you he's been head-hunted by a competitor firm, wave you 'Sa-yo-nara' and leave your office while leaving a 5 dollar note on your desk?
Imagine another scenario. Suppose you are an average worker. Your boss pays your by the going market rate, no more, no less. But your boss also care about his employees personally. I mean, he cares about your day, your worries in the family, or even goes to the trouble to talk to your about your future, and how you can make progress in your personal and life goals. One day a headhunter comes along , give you this 15% extra base pay and ask you to jump ship. Then you think... " Okay I know nothing about this new company, even though the pay is good, but how about the people? are they friendly? is my contribution going to be appreciated by others? most importantly am I going to be happy there?". You keep thinking and then you realise "But I am happy here! Why should I risk a good job, caring boss and my happiness for a 15% raise? I mean I will only put those extra money in the bank and earn interest" .
Marslow's hierachy of human needs tell us human goes through incremental levels physilogical, safety, love, esteem, and self actualisation needs.... I am guessing in certain countries where basic supplies and resources are extremely deficient ... it might be the physiological/safety needs of food and shelter (satisfied by forms of financial reward) may have larger impact than higher level needs such as respect by colleague, love and caring, pursuit of life goals etc. Nevertheless, in a truly excellent organisation, we want to make sure every worker's needs is cared for. Every individual, poor or not, will eventually grow out of the need to satify its physiological need and seek to fulfil esteem and self actualisation goals. It is important that managers recognise this and is prepared to offer support for these higher level needs when the time comes.
I know all of this sound too "ideal" or "in a perfect world this is what happens". But I know this from experience. In my previous job I often hear about my colleagues talk about a manager that used to run the place. They would tell me "Yeah... he was a good boss, I mean he really cared about us". Although at the time I joined this manager had already left the company, I could often feel his influence on the people he left behind.
So much work to do- PIUSS pma, KBAM mini project, KBAM seminar preparation, ... ... ... keep fightin~
March 08, 2009
Today I came across reading a book on Lean production "The Machine that changed the world" James P. Womack, Daniel T. Jones and Daniel Roos; 1990; Macmillan. I got this book initially to read about supply chain management but realised this is actually a book about Lean production of Toyota.
I recommend this book because
- I believe it is one of the first texts on lean, according to the book the authors coined the term lean
- It is easy to read. It begins with a history of automobile manufacturing from craft production to mass production which has ills and inefficiencies that eventually give rise to Japan's lean production. The clear logical flow allow you to see why lean become important. What I find most useful is it clearly contrast the management philosophies between the West and Japan
Mass Production Lean Production Produce everything in mass leads to inventories Produce only what is needed, aim for zero inventory Kanban system Market style relationship with supply chain Seek long term relationship with suppliers Clear separation of design with production Provide suppliers only with performance specs, but allow supplier to come up with product specs Tolerance mentality toward defect, defect is seen as 'inherent' and cannot be eliminated '5 why's' problem solving system (similar to root cause analysis). root cause of defect is eliminated and will never happen again Firefighting or 'fix it' mentality toward problems Kaizen gradual improvements invovling small teams and devote time to reflect and solve problems
One of the amazing idea I find is
In Western style assembly line, management promote maximum throughput and allow no stoppage in assembly line. So line managers have no incentive to fix minor problems because his ass is on the line if assembly stops. This result in small problems snow-balling into big problem in end product, and within production process.
Lean production devolve responsibility down to floor worker, any worker is free to stop assembly line if a problem is discovered, and group of workers will work on solving problem together.
Not surprisingly, when each worker is free to halt the process, the assembly proces actually almost never stops because the process defects has been eliminated. Whereas to impose non-stop assembly always end up stopping the assembly because of various small problems during production. And the end product often has many defect which needs to be checked and fixed, incurring significant cost on repair and quality checks.
- Detailed description of lean and how it relate to production, supply chain, customer and so on. Page 55-57 describes lean principles in assembly line which resembles six sigma (teamwork, quality circle, root cause)
Verdict: Even though I have only spent a couple hours reading this book, I can already grasp the keys ideas about lean (compare this to some books you read for hours but still have no idea what the topic is about?). This text is filled with rich examples from Toyota company and is very easy to read. I'd recommend this to people studying lean for PIUSS or for their project, if they havnt already come across it.
March 07, 2009
After some more testing today incorporating some design changes, I have isolated factors influencing flight performance
- Wing span
- Wing angle
- Head weight
- Folding wing tip
- Fold wing trailing edge
- Cut out plane head
Especially the ones in bold made significant impact on performance. Once this is realised, I spent sometime with my next door neightbour discussing why this is so (who by the way showed me how to fold his 'ultimate paper plane' ; see picture below) .We finally agreed that
- Head weight helps to keep plane head down (lower pitch angle) during flight (too much pitch angle create stalling).
- Folding wing tip helps focus airflow above the wing surface. This in turn increases 'above' wing speed and hence lower 'above' wing air pressure according to Bernoulli's principle
- Folding wing trailing edge up increase climb, whereas fold down makes plane dive. Folding one up and the other one down makes plane turn corners.
Ideally to keep plane aflot, the plane should not climb too much so that stalling occurs. Equally, it should not dive. So to keep plane 'leveled' , different adjustment to the head weight and folding trailing edge is needed. I think this could be a potential source of 'interaction' in Taguchi experiment. Another observation I got from my neighbour's design is plane can go through a series of climb-dive fly patterns to stay in air longer, I have yet to figure out how this happens.
I think these discoveries are good, I feel I finally discovered some significant control factors. Now I need to proceed into my next stage- experimental design, and finding a way to measure time, and find a big space to carry out my experiment.
I have spoke to sport centre and I think I can use the basket ball courst in the moring (730am) during the week. But I still someone to do measuring time for me. I understand everyone will be busy this week with KBAM and PIUSS , is anyone able to help ??
First prototype - Cut plane head; folded wingtip and folded wing trailing edge; paperclip added to head (not visible)
Ray's Flying Champion - My neighbour's ultimate flying champion. According to him this one can fly for ages and ages. It's a very different design with much bigger wing aspect ratio. The head is folded several times to make plan head 'heavy'. Wingtip is 'rolled' instead of folded. Strangely this one has a habit of flying in circles and go through several 'climb dive' patterns.