All 38 entries tagged Mbe

On knowledge management and the pma

Well this kbam pma has dragged on a bit (suppose to finish weeks ago) but I have myself to blame for spending too much time procrastinating. For the sake of kbam blogging marks, let me talk a bit about a small realisation about how to apply KM to AM. In my previous blog post I said something about "thinking about knowledge on a higher level" but now I think about it there is little value in that idea because it doesn't help with answering the question whatsoever.

An important aspect, I think, is to recognise the difference between "information" and "knowledge". As Nonaka (a guru on knowledge management) stated "information is indifferent to human values, context free, without intentions or commitment." whereas "knowledge is grounded in values, experience, and purposeful action." Well, that is just a wordy way of saying information is "dead" whereas knowledge is "living". Not sure if this metaphor makes more sense or not. The idea, according to me, is that without humans to 'use' or 'interpret' information, information is just information. On it own, information does not lead to better decisions, better actions, or better business performance. Knowledge, on the other hand, needs humans to 'interpret' and 'be understood' based on one's own perception and analytical abilities. In this sense, knowledge is subjective which often exists in a tacit form, like a skilled craftman knows how to make beautiful porcelain but cannot explain how. When such tacit knowing is externalised (distributed, made public, turned into worker's manual), knowledge becomes information in the eyes of others. Unlike knowledge, information in an explicit form is easy to circulate. An English dictionary, for example, exists only as information to an unlearned person unless (he) can use it to solve a translation problem. If he succeeds, information is turned into knowledge. 

So, what is the point of this information/knowledge garbage? What are you getting at you may say. Well, aspiring businesses that have approached KM by installing expensive IT, automated computer systems may be thinking "Yes, We have a knowledge management system, I mean we spent all these money on these technologiee havn't we?" Actually what they have gained is merely an 'information processing' technology. It may help them to collect and distribute key information about customers or suppliers in an unprecedented rate. But when information is not 'sinking' in i.e. not being utilised in a way that helps them to make better decisions, they quickly despair and claim KM is just 'air' and move on to the next initiative. 

Why wouldn't it work? It seems more is needed, but what? Nonaka thinks KM should have three ingredient, working together; the knowledge asset, the Ba, and the SECI process. The knowledge asset is the people, or the infrastures such as IT system. SECI process is a process describing the conversion of knowledge between explicit to tacit forms. But to me, the key ingredient is the Ba which in Nonaka's words is the "platform for the concentration of knowledge assets." We can draw parallels between the concept of Ba and the idea of "creating a learning environment" in organisational learning. 

When thinking about application of KM, it is easy to think "what is difficult about that? Just put in a computer IT sytem and that will solve all your worries. I mean, after all, that is what big companies are doing!" Yes, on a surface level, we see company buyig technologies and naturally we want to imitate their success and the quickest way is just to have whatever they have. Unfortunately, as said before, explicit things such as information can be bought easily with money. Knowledge on the other hand must be fostered and created from within the organisation. Knowledge, unlike information, can not be bought.

: 19 Apr 2009 21:48 |  Tags: Kbam Mbe |  Comments (2) |  Close comments |  Report a problem

initiating kbam pma

I have chosen resource utilisation for my KBAM pma. At first answering the question was rather puzzling because I could not see how resource planning, i.e. inventory levels, capacity planning could relate to the idea of knowledge, i.e. how to facilitate sharing of information etc., that seem to dominate literatures on KM and organisational learning. 

After spending some time reading up about inventory management, and some common problems that goes on in scheduling production, managing customers, and raw material orders, I begin to see it is necessary to view knowledge in a more broader sense: as the ¡§thing¡¨ that is necessary to run a business and this may be key information, the way of organising work etc

So in a way resource utilisation tools (or methods or techniques) such as MRP, MRPII, JIT, DRP are, I suppose, knowledge management tools in its own right, designed to help people interpret and make decision based on raw data such as inventory level, delivery time etc.

If above premise are accepted, then the systems mentioned above seem like the formal KM tools- ie what people can see explicitly and followed religiously. However, there is also another level of knowledge not visible from these formal tools, called informal knowledge, which are often the often tried & tested ¡§methods¡¨ or ¡§ways of doing things around here¡¨ .

Sometimes informal and formal knowledge are incompatible with each other, such as when data generated from computer is completely ignored by workers who would rather rely on talking to people or own experience to make own decisions, thereby rendering the formal system essentially worthless. Interestingly, Landvater 1997 explains this by saying whether formal, informal adopted by organisation, it is the one that provide the necessary information to people that reigns all. The abandonment of computer system is due to the fact it doesn¡¦t give the information people wanted, therefore an informal system appears. 

To apply KM to resource planning then, seem to take the questions of resources to a higher level. Instead of asking ¡§what information do I need to make my ordering decision¡¨, we may be asking ¡§what system will best suited to solve this problem?¡¨, and this question would then depend on ¡§what sort of knowledge does this decision requires?¡¨ 

The point I am trying to make here, I suppose, is that KM is about maximising the benefits of formal/informal systems of information transfer to deliver your organisational objectives. This would depend on the organisational structure, cultures, and type of operations that are carried out. Thinking along this line of thought brings KM literatures closer asset management. 

: 14 Apr 2009 15:18 |  Tags: Kbam Mbe |  Comments (1) |  Close comments |  Report a problem

Sustainable Energy – Without hot air

Global warming problem is HUGE, our need for energy is HUGE, but how do we balance one huge with another huge? Essentially this is the point David MacKay try to tackle in his book "Sustainable energy- without the hot air" and I must say he paints a rather grim future regarding our ability to meet energy demand using renewable energy. Considering we hear news about icebergs breaking, or bizzare weathers happening around the world, it seem like a pretty important issue but everyone seem to either hold a skeptical view toward climate change, or are too busy to think about it seriously. And even though many politicians claim to be getting "serious" about combating climate change, because of Mackay's book, to me, it seem like goal of replacing fossil fuel with renewables is unlikely to be achieved in near or distant future... the implication is both unimaginable and unthinkable...

One of his main conclusion is whichever method(s) we use to replace fossil fuel (wind farm, hydro, plant, tidal, or solar but not nuclear because it's not renewable), it all require country sized space to be physically practical. For example, build wind farms twice the size of Wales, solar panels the size of Germany + in desert places, grow plants twice the size of Britain and so on. In another word, he is saying it is practically+ physically not workable (unless we can turn most of land space into energy production)  that we will meet our energy demands from renewable source. More importantly, this conclusion is drawn based on physical considerations only. Other considerations like the economic consideration of cost or political consideration like "you can build it anywhere except for my backyard" will shift any renewable solution from improbable, to impossible.

Nice thing about Mackay's book is that unlike many climate change debates we hear. His argument is based on numbers which tells you without dispute (except for how the numbers are derived) whether we have reason to be concerned. The following passage illustrates the motivtion for his book

"This heated debate is fundamentally about numbers. How much energy
could each source deliver, at what economic and social cost, and with
what risks? But actual numbers are rarely mentioned. In public debates,
people just say "Nuclear is a money pit" or "We have a huge amount of
wave and wind." The trouble with this sort of language is that it's not
sufficient to know that something is huge: we need to know how the one
"huge" compares with another "huge"? namely our huge energy consumption.
To make this comparison, we need numbers, not adjectives." (Mackay 2008, p3)

David MacKay's book Sustainable energy - without the hot air is freely available from his website http://www.withouthotair.com, or it can be purchased from amazon.co.uk. You can also listen to his light hearted talk to understand his ideas (talk (mp3) here  (25mb) + ppt(pdf) here (27mb)). Oh ! and it is really fun to listen because he is a really funny man :P

: 10 Apr 2009 21:42 |  Tags: Energy Mbe |  Comments (1) |  Close comments |  Report a problem

Six Sigma and Service industry

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.

: 31 Mar 2009 23:37 |  Tags: Mbe Piuss |  Comments (3) |  Close comments |  Report a problem

Understanding system

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.

: 24 Mar 2009 18:42 |  Tags: Mbe Rdd |  Comments (0) |  Close comments |  Report a problem

fault tree analysis

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

1. water valve mechanism fails
2. 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).

: 23 Mar 2009 17:16 |  Tags: Mbe Rdd |  Comments (0) |  Close comments |  Report a problem

System engineering/ System thinking – difficult to grasp

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

1. It's been around for ages
2. Mirrors the system thinking principles from Peter Senge, but has a more engineering focus
3. 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.

: 20 Mar 2009 19:39 |  Tags: Mbe Peuss |  Comments (3) |  Close comments |  Report a problem

Know your audience – KBAM presentation

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

1. Experience and knowledge about what make the executives tick (probably money $$$)
2. 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.

: 14 Mar 2009 06:15 |  Tags: Kbam Mbe |  Comments (2) |  Close comments |  Report a problem

One more on Leadership– creating common grounds

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.

: 12 Mar 2009 06:11 |  Tags: Le Mbe |  Comments (1) |  Close comments |  Report a problem

Experimental Planning – in the context of Taguchi

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.

: 12 Mar 2009 05:11 |  Tags: Mbe Piuss |  Comments (1) |  Close comments |  Report a problem