On finding things

originally posted on one of my several now defunct blogs, called On Engineering on 24th Jan 2012

At the very beginning of this blog, one of the questions I asked myself was - what do I do all day? Between cups of tea or coffee, lunch and hometime, I mean.

(an aside; had I not settled down for a cup of coffee and a natter with a colleague recently, I wouldn’t have heard of silane coating systems, nor he of critical entanglement in polymers, so coffee breaks do have their uses).

It’s a tricky question to answer, in reality. We have where I work a form of time tracking database where we record the hours that we spend on particular projects. I can’t extract my own time from each pot, though, so I’d be working on overall team trends, which would only loosely represent my own. Suffice to say I’m not that interested in setting up my own private tracker; for now we’ll say that I am pulled in so many different directions, it’s difficult to focus on any one activity for any length of quality time. One task that takes up an inordinate amount of time, one that I want to discuss here, is finding things.

Others would refer to it as research, but sticking to the simpler term of “finding” better reflects what I am usually doing. Our labs have produced thousands of reports in the last years. Many are for repetitive tests for series production control or “requalification”, lots are investigations into manufacturing or quality issues. Many are validation reports that prove to a customer that we can deliver to an overly complex and largely unchallenging specification. We even have some that are reports on new developments (gasp!). At present, all that good data contained within those reports is effectively fossilised in the hardening goo of Microsoft Word.

How do we detect patterns? Generally, we don’t. How do we find the totality of relevant test reports over the years for a given product? I won’t say that we can’t, but it’s harder than just tapping a query into a Desktop Search. We can search and filter through our test database, but that’s clunky, too (searching across several years? Forget about it).

So the eternal problem remains eternal - how do we develop the relevant knowledge so that we can design better systems? That’s one of the key challenges I think we face.

A small example: recently I had to answer some questions from a colleague in Korea regarding a hose connection. Simple, on the face of it. The connection requires a particular tube endform profile to ease insertion into the hose and to promote the fairly crucial function of sealing. Unfortunately, the drawing he was referring to was created in 2003 and I had no idea where the design principles that led to that particular drawing came from.

I searched and found… another copy of his drawing, but not much else. So, it came down to the oldest of information transfer systems; colleagues. The colleague who created that endform drawing all those years ago still works in my department and ask him I did - but could he remember for the life of him how he arrived at those particular dimensions? No. What and where are our tools? Here’s a possible search pattern:

  1. Desktop search for anything containing that part number (emails, report, lists, etc) or description

  2. Search for reports containing that part number or description

  3. Search for reports containing similar parts of a similar description

  4. Search for relevant specifications

  5. Ask colleagues

If nothing interesting is dredged up by that lot, then it’s a case of redesigning from scratch. How do we do that?

  1. Use Design of Experiments principles to get parts made at various diameters and angles and tested

  2. Request some Finite Element Analysis on the joint to ensure that nothing’s going to give too soon.

  3. Get some fluid dynamics studies done on it to ensure that I’m not overly constricting the joint

  4. … umm, file a report somewhere (go back to 1.)

The answer here would then be to link the report to the drawing somehow, either simply by placing the report number somewhere on the drawing, or by placing the link somewhere in the CAD model, or as an additional link or document next to the print on our SharePoint system.

Yes, we use SharePoint. It’s clunky and has some great functionality holes at the moment (we’re still on version 2007), which means that people don’t like to use it. However this, or a dedicated PLM system, is the way forward in terms of linking everything up.

Curation of data is also important. Labelling, Keywording, making more searchable. It’s a dull and dry task to start or to perform retrospectively (company librarians required), but if it can become second nature to document control, it could help.

Generally, putting data to use to obtain information, knowledge and even wisdom is becoming ever more important: Big Data is Big Business, as HP proved by stumping up $11.7 bn for Autonomy corp. In theory, using an Autonomy search would be better than hit and hope: hitting the Windows Desktop Search button and hoping that you’ve entered the right keywords, both in the search and in the document (and praying that the report was written in English by somebody who could spell). But I’ve only experienced Desktop Search and I don’t expect to see such enlightened methods used where I work.

Another tack is social. I am a follower of blog, Confused of Calcutta, run by J.P. Rangaswami who now works for Salesforce.com. He is a true social enterprise and open market evangelist who loves the ways of communication available to us with Facebook, Google+ and their more enterprise-tuned cousins, Chatter and Yammer (an unfortunate name that sounds like the German for “to complain”). The idea behind these tools in the work place is an interesting one. Using my example above, I could write on my wall: “Wondering why this here endform pilot angle is 32° and the other 38° and whether or not it matters in the slightest”. The post will be seen by all of my followers and - the theory goes - one of them may know the answer, or know where to find it. Social beats email because the author of the question does not need to think about who a mail would need to be addressed to, who should be “carbon copied” on it and does not need to run the risk of either missing people out or annoying disinterested parties. Social beats email because the act of “liking” or responding to a post broadcasts that action to the connections of the person responding, potentially creating a snowball of knowledge.

However, we all know the downside of our social networks - signal to noise. How can we ensure that the right people even read our question and hold it in their active mental buffers for long enough to action in amongst all the other questions, observations and general banter going on around them? This is where filtering comes in - but filter incorrectly and you’ll miss the occasional important missives in the storm.

So, right now, I don’t know. In so many ways. If you’ve used Chatter, Yammer or tools like Autonomy, I’d love to hear from you. Has it transformed the way you work, the way you search, the way you engineer?

In the meantime, I’d best get back to what we engineers do best, which is to… Umm, where did I file that job description?

Sebastian Abbott @doublebdoublet