[ Date Index ] [ Thread Index ] [ <= Previous by date / thread ] [ Next by date / thread => ]
Thanks Tom I didn't assume that you were getting at me at all. I think under most circumstances you are absolutely correct. Hopefully I'll be able to get to a meet at some point and we can chat it over, but I'll summarise the workflow I am involved in. Basically, when a shop floor operator thinks he has a problem, he will initiate a problem solving exercise by gathering some data on a paper chart, calculating from the data the way the process should be operating, and then using excursions from the normal operation as triggers to initiate problem solving exercises. If he doesn't find any excursions he would normally drop the charting or reduce the frequency of sampling and move on to charting something else. This whole exercise could take as little as one day before he/she moves on to something else. All of the above steps will be individual to the specific problem although based on general principles. There is no way to determine in advance the type or structure of data required, or where it is to be collected. The only electronic method of doing this would be for the operator to use a spreadsheet but that would be too limited in many cases as it is difficult to add freehand sketches etc (bearing in mind that this is an operator led process) I know that there are companies who collect all the data that they can imagine might be useful, but they will still miss 90% of the information that's important. The other problem with the centralised data collection approach is that it takes the information and the problem solving away from the shop floor - the result of which is that problems are only identified when it is too late to trace the root cause. The use of R, gGobbi, Mondrian etc really comes in when the operators get stuck, and I would then use some of the data (possibly 20 to 100 data points) they have collected to look for clues as to what is going on. My main tool for that would be Exploratory Data Analysis using Interactive Graphics (Mondrian for categorical data and gGobbi for numeric) I don't in principle have an attachment to any particular file format, but gGobbi and Mondrian use character delimited, so I would need to export as CSV or tab delimited anyway. At the moment I do that from OOo, but it could be from SQLite I guess - the main thing is that the design and implementation should be as quick as typing directly into a spreadsheet. Also there is no structure in the data which would require it to be anything but flat file. I guess there is a big difference between a generic situation where you know in advance what data you want to collect and will be collecting it for a long time, and a specific situation where you won't know what you want to collect in advance, or where you want to collect it, and will probably only need it for a day or so. To apply electronic data collection to the specific problem solving situation you would need to perform systems analysis, design build and test a database, design build and test code to enter and pre-process the data, install networking and hardware, all of it different for each problem, with a time-scale of say 10 minutes from identification that there is a problem to be solved - and usually at 3 a.m. All of this so the operator can take the data from the screen and chart it on paper manually so he can make notes on the chart for the maintenance guy to take with him when he crawls into a confined space wearing breathing apparatus to look at a hydraulic valve which might be the problem. (I exaggerate but you get the idea!) I do genuinely appreciate all the help and ideas though. Phil On Mon, 2010-11-22 at 11:04 +0000, tom wrote: > On 22/11/10 10:34, Philip Whateley wrote: > > On Mon, 2010-11-22 at 07:48 +0000, tom wrote: > > > >> On 21/11/10 22:49, Tom Brough wrote: > >> ..... > >> > >>> Having said all that it would be really nice to see a good csv / xml > >>> editor in open source. Ah if only my programming skills were 100% > >>> better than they are now :-( > >>> > >>> Tom. > >>> > >>> > >>> > >> If people would adopt a data centric approach - managing the data they > >> are really concerned with and not spreading it around piecemeal in > >> 'documents' then there would be no need for a good csv/xml editor. > >> As you wrote in the parent post it is really sad, really really sad that > >> we even have to contemplate doing these things. > >> Tom te tom te tom > >> > >> > > Well - in general terms I think you are right, but in this specific > > instance, most of the data is collected on paper for very good reasons. > > > > -The original charts are and should be owned by shop floor problem > > solvers, who do not have access to computers because the environment is > > hot, humid, and full of stray high EMF interference. > > -The charts are used for problem solving on the shop floor, and need to > > be available to be carried from potential problem to potential problem. > > -Operators also need to make notes on the charts, often in the form of > > freehand sketches, schematics etc. > > -The charts need to be posted in a form where they are always visible > > and accessible. > > > > My role is in training the operators and setting up the charts in the > > first place. The main reason for getting the data into R/Mondrian/gGobbi > > etc. is so I can perform additional analysis. > > > > I'm afraid that one of the first pieces of advice I give when called in > > to see why a company is not making improvements as a result of spending > > several hundred thousand pounds on shiny new computer equipment, is that > > they need to get away from a data-centric approach and focus on problem > > solving by doing the work on paper. > > > > Working on paper also means that the problem can often be solved in less > > than 5 minutes, instead of the months it would take to perform systems > > analysis, requirements definition, capital justification, tender for > > hardware, tender for software etc. etc. etc. to solve a single problem > > which will often be a different problem when the (by now) obsolete > > system is in place. > > > > I'm sure that there are many instances where your "moan" is justified, > > but in this instance the people responsible for managing the data need > > to be the operators, not the organisation. So managing the data they are > > concerned with actually means spreading it around piecemeal. > > > > Phil > > > > > > > Sorry - I didn't intend to have a go at you. I interpreted what you said > earlier as that you were getting paper data taken from someone elses > computer system. > However back to the data - at no time should it go near csv - you should > be able to put it straight into a database from paper as bland table > data which can then be transformed directly (or indirectly) into the > format you need and then sucked into R (or anything else) at will. > There should be no significant capital requirements for looking > at/entering data - just bad management of the same. > If a pen can work on a bit of paper in the environment then a cheap > terminal can be used. > OK I dont know quite what environment and what your requirements are but > just because some con artist has sold them a useless IT solution (MS?) > doesn't mean that an IT solution is not possible. > I've worked in companies where 25 simple wyse terminals have been > replaced with 25 case hardened windows machines and a lot of money > pissed up the wall because - like your last para they mistakenly assumed > that the organisation is not responsible for the data. It is - its just > a question of where you put up bureaucratic barriers: you can analyse > the data because you don't have to jump through ill placed hoops - > neither should the operators. > You presumably get them to provide you with data in a way which is > mutually convenient - that always a good thing to do and is often a lot > easier than you'd think. > Tom te tom te tom > -- The Mailing List for the Devon & Cornwall LUG http://mailman.dclug.org.uk/listinfo/list FAQ: http://www.dcglug.org.uk/listfaq