KBAM study – 2

Found time to work on the PEUSS assignment and later took up the KBAM module sheets. Most of the asset management practices mentioned in the module are practiced in our company and able to appreciate it. The module notes gave insight on why central utility is held alongwith ISD and why contractors are managed by CU in TVSM. Some of the best systems and practices in TVSM like TPM,ISO,OSHAS,....were explained. Not sure how far will others in the group would understand all these things. But felt that there were few repetitions from the area of Finance, which could be accepted due to the relevance. Spent some time on asset management and need to focus on knowledge management in the next few days. Tomorrow morning we (the team) will have a meeting at the learning grid to decide on which areas to focus on.

: 28 Mar 2006 22:00 |  Comments (0) |  Close comments |  Report a problem

KBAM study – 1

Paul presented the objectives and learning outcomes of the module. The module is going to be with an entirely new way of learning, no class room teaching, no lectures, no internal assessment….its only the self drive and quest for learning which is going to push the module learnings. It would be a different experience for us. Hope to experience it. The syndicate exercise – Meetings on meetings…went on well, with Jane the general manager, Me the food and product manager, Vlad the training manager and Gez the front house /reception manager. The team discussed the issues quite smoothly and was very amicable. It could have been better if such a exercise (with minor modifications ) is held during leadership and excellence module…which might be useful to explain the leader's role or during the CRIP process (Catchball process). I did the summing up on learnings of the exercise and went on well. Later we had a team meeting and decided to go through the KBAM material and meet again on Wednesday to decide further course of action.

: 28 Mar 2006 21:53 |  Comments (0) |  Close comments |  Report a problem

RDD Day 4

Team's discussion on rail crash continues….got some clues on how to go about the presentation..,,team decided on categorising the problems based on various systems (train, guard….) and look for tools which might have been used to avoid those incidences. If we do so will we miss the system thinking or wholistic view again. During discussion one among the reason attributed was to the non-compatibility which would have arised at various stages of development (train station design, railway tracks laying, building trains…..). Anyway, I have to look at RBD and its application in this accident. Need to give a try on this. Seminar discussion started with the same few discussion (Gez views on involvement in discussions are acceptable and expected)....came to vague conclusion as we cannot quantify robustness….I differ in this…thats how it would have started for quality….but today we have hundreds of rating systems to do so…If robustness is the future then people will emerge up with quantifying…..Presentations by Graham & Ossie singh gave a feel as if I am sitting in TVSM…..almost all that was stated right from TGR/TGW/top most complaints/approach to the above…everything were similar. During the post discussion the speakers confirmed the teams thoughts during the seminar and they were not sure about the rating ….. comment by ossie singh that reliability and robustness are interchangeable has taken me back…...long tiring day

: 16 Mar 2006 19:50 |  Comments (0) |  Close comments |  Report a problem

RDD Day 3

Reliability enhancement testing was the topic today. As an engineer who has worked in the reliability test lab for few days…. some of the points from Jones were very useful…unexpected failure modes are sign of bad test, test should be designed like a product (which we are yet to start), do not start a test just like that. The Duane test should be very useful in my day to day practices in our company, quite often we talk only in terms of MTBF to substantiate the life improvement but now some statistical evaluation is possible. Test to improve – fix effectiveness…has its roots on expert judgement…still a doubtful tool as this might be misguided due to the views of one person (more people idea might be confusing ). Testing exercise in the afternoon PAPER CLIP brought out the same issues which I have faced in the company….test results are having too much variation due to test differences,tester differences,test equipment,material…..blah blah. The life was predicted using an extreme accelerated testing (actual usage was 5deg while test was at 105deg), our team should have considered the actual usage first and then started the trials. Moreover we did not make any correlation between a customer usage and the test conducted….may be its just a syndicate exercise and this might not be required. But in a real situation this would have be IMPORTANT. Jane's doubt on assuming the the same trend on the other side of the graph ( measured at 105deg but predicting life at 5deg) was very obvious which did not gain the attention required. In the evening disucussion with TKJ on PPMC….hope will have good dreams.

: 16 Mar 2006 19:21 |  Comments (0) |  Close comments |  Report a problem

RDD Day 2

Day on system analysis. Various analysis tools like reliability block diagram, Markov analysis, Petri net diagram were taught during the morning session. Though these tools seem to be entirely different they have the common base or notion of representing complex systems as easily understood funcitonal requirements. A normal process of learning is to understand a technique, use it in a simple example to ensure the understanding and go further. My process of learning today was a bit reverse, through trial and error arrived at the results and then understood how did I do that. More of circuit diagrams with if and elses…confusing at the first moment but later gives a better picture. i am not able to imagine the size such a diagram for a entire system like aircraft…understanding those diagram might be a real problem. If that is the case, how do people make it happen and convince others. Seminar on what is robustness? brought in different dimesnsions from different people. Discussed in groups of two about robustness…our approach was to bring out the attributes of robustness from normal day to day words used like its robust XYZ. The other teams approach was to see robustness from the perspective of various specialist. Towards the end we narrowed down to reliability, safety and input variation ..further discussion to continue tomorrow. PARIS train crash issue heated up in the team … decided to list the various failures which had resulted in the accident and then try to look fo the tools which would have diagnosed the same. Our team came up with an ample number (25) different reasons or failures for that accident. Will have to work out which tool would answer each problem. LOT TO GO. Have to work on PPMC assignment.

: 14 Mar 2006 20:04 |  Comments (0) |  Close comments |  Report a problem

RDD Day 1

The video presentation on Paris rail accident was like watching a movie. Need to go through that video once again to understand the entire chain of events. From the initial observation, the rail network system might have been designed with the assumption that the probability of failure of all safety measures is very less hence the overall system is robust enough. Failure of human factor, technical factor, communication issues, managerial issues, lack of commitment everything contributed to the lack of robustness. Quite a good example, wonder whether all the accidents like this would be happening because of all these factors. Had a lengthy decision with the team members on what could have caused this system brittleness and tried hard to come up with alternatives to avoid this in the future. Still long way to go on this discussion (as the inputs on tools used were not known). The after noon session on fault tree analysis was elaborate and reminded of the earlier experience I had in TVSM, preparing a FTA for engine noise analysis. Though that was a last minute work, very well received by the management and still contining it (I believe…). What ever be the tools and techniques be taught everything required a pre requisite : systems thinking and knowledge about the system. Jones' comment on active and passive components, defining boundaries were quite interesting. But when I did work earlier, everything was taken for granted and expected that the assumptions were understood by all. Binary decision diagram was quite catchy but felt a bit trapped. Took long time to understand. Continuous usage might improve my understanding and identifying application areas.

: 13 Mar 2006 19:13 |  Comments (0) |  Close comments |  Report a problem

23.02.2006

Using scorecards for CTQs was a sensible approach, it could have been better if some rating or R-squared value or some index which denotes CTQ's impact on to the system level,subsystem level and product level performance was added alonwith the scorecard. FMECA started with lecture session and moved on to the practical session. Lot of confusions in the areas of understanding failure mode,effect,cause,part level,system level,functions,requiremets…and usage over a period of time is surely going to solve this problem. I will have to gain on job experience in the company alongwith some experts…..which might give me a better understanding. It was really a ritual in most of our supplier companies to conduct FMEA…that too once in a year only or only when a new product is launched… Paul rightly mentioned it as the lip service.How do we make the lip service provider a real service provider??? There is were I need to contribute. Good. Need to work on the inmodule work.

: 23 Feb 2006 22:08 |  Comments (0) |  Close comments |  Report a problem

22.02.2006

Brief introduction about Jane on DFX followed by the life and reliability distributions lecture ( for me its the nth time), still finding it new, as usual understand at the moment and then later on getting confused. Was able to appreciate and understand the effort put by our company in bath tub curve study and the actions based on that. Afternoon started with eliciting expert judgement by a consultant from Goodrich…its all capturing the knowledge of the experts in relevant areas and using it for product development. It is critical but most of the companies still neglect it and dont visualise the mammoth opportunity loss of not using the expertise. As Vlad was rightly saying the knowledge capture / sharing need to be brought as an obligation of the employees. The seminar on simulation,variation reduction and GD&T was very much useful for a guy like me, who works on the product and not on the production or design side. The few exercises which he gave us tried to keep us on the go. Late in the evening started with the inmodule work and went on till 2200.

: 23 Feb 2006 22:00 |  Comments (0) |  Close comments |  Report a problem

QFD

It was customer's voice all through the day. How to gather, what data would be required, what questions need to be asked, it was real fun in doing it….with some assumptions. Discussion on the Kano model was very useful and helpful, that simple graph being used to explain the customers expectations, needs, excitment, how the data speaks in relevance to that, what need to be understood about the data before analysing the VOC….was not knowing the importance all these days. A good learning. Rest of the day was all through QFD QFD and QFD. Eventhough I had some exposure to QFD I hadnt any formal training, nor used it in onhand. Felt embarassed to say that our company follows QFD but I dont have enough experience in using it…. but thats true. The overall exercise was very useful but it has so happened that most of the data entered based on assumptions without product knowledge. ( but agree that it is important to understand the concept behind it ). Surely I can contribute in a QFD team with the knowledge acquired.

: 21 Feb 2006 21:58 |  Comments (1) |  Close comments |  Report a problem

PEUSS introduction

The module started a bit late after some hussybussy games. Some of the points which were discussed time and again that the 6sigma projects are financially driven,customer and result focussed were fed through the first few mins. But the real difference between SS and DFSS lies in the fact that DFSS focusses not on the process but on designing the process. Felt sorry about the crazy people when Jane told that there were about 10 to 12 semantics for the DFSS steps. Had a risk assessment of my M.Sc project as a part of learning about the risk management, mostly I found it inline with FMEA methodology and Jane was inline with it. The next two sessions were by Peter brooke on capturing customer requirements. Was interesting to know about the interviews, surveys, data gathering, kano model, VOC….Enojyed the session. Next came the overall most disastrous and boring sessionI have ever attended in WMG, the session on Requirements management & Doors by Keith collyer, it was too compressed that he didnt find enought time to explain fully and as he was grazing throught concepts it was harder to follow him continously. Will be happy if people relook at the content of this session and consider the overall time alocated. Followed by the classroom sessions, our team members met to decide on the internal assessment work. I need to go throught DFx from the book DFSS by crevling. Finished going through the superficial introduction given just now and getting ready for sweet dreams.

: 20 Feb 2006 23:19 |  Comments (0) |  Close comments |  Report a problem