All entries for March 2006

March 28, 2006

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.

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.

March 16, 2006

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

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.

March 14, 2006

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.

March 13, 2006

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.

March 2006

Mo Tu We Th Fr Sa Su
Feb |  Today  |
      1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31      

Search this blog

Galleries

Most recent comments

  • You may want to look at the information on QFD Online. They have quite a bit of QFD tips, tutorials,… by Grover on this entry
  • I should like to discuss with you the introduction to the module. I thought that we had done this in… by Paul Roberts on this entry

Blog archive

Loading…
Not signed in
Sign in

Powered by BlogBuilder
© MMXIX