Resurfacing after a long winter & The Danger of Double Data

Sakura!

It's been a while. I've been busy, and kind of in a odd state of in-between for the last 6 months. Not quite hibernation, not quite torpor, but definitely off-line and focused on other things. But it's spring! And it's time to poke my head out and look around, see what's going on out there in the Big Bad World. 

OK, the world isn't that big and bad, that's true. I've been enjoying my time in aerospace - lots to learn, lots of thinking and Fun with MATH, and lots of open-minded and smart people with whom to work. Heck, I think I've done more mathematical analyses in the last six months than I had in the last six YEARS.

And the nerd in me loves it. 

Aluminum corrosion? Check...

Heat treatment of alloys? Absolutely...

All three classes of anodizing? Why not...

Torque-this-and-torque-that? Definitely...

Any ANSI-ASME-MIL-BAC-BSS spec you can think of? Sounds like fun...

And so goes the day in aerospace. Never a dull moment. I appreciate that my co-workers trust my use of math as well as common sense to help the team solve challenging problems. They all find it amusing (and probably disturbing) that I actually enjoy reading all these specs and regulations.

One of the things I wrote earlier this year was something to help manage all the revisions of all the specifications - internal and external - and all the revisions of programs for machining and inspecting for our aerospace parts. I called it a Control Plan - and I'd really only ever written one for electronic assemblies before. My co-workers had never heard of one. It was a good way to track process revisions without a part revision. Since we didn't own the vast majority of the specs, it seemed a good thing to try for this situation.

My boss, when looking this thing over and seeing how it could solve some of our configuration management problems, asked me a simple question: "how much of this is double data?"

What? Come again?

"Yeah, if some thing changes say... here" (points at single line on control plan) "how do we know what to change? where else does this info live? what if we miss updating one data set?"

Hm. That's a really good question. It got me thinking about how many times we create duplicate data sets - particularly in quality and operations - sometimes to help one group with one specific task. Like translating a complicated assembly drawing into a operation-by-operation SOP. We want to do the translation to make it easier for those doing assembly to be successful - heck they don't need to read the whole riveting specification right? So we should just give them the info they need, when and where they need it right? How often with that spec change anyways? 

Most times, I think we'd agree it's worth the effort to do that translation work. But there are definitely advantages to asking yourself the Double Data question before you get too far down the road. What can you eliminate or consolidate? What actually needs to be translated, transcribed or re-written? If you have data in your ERP system, for example, can you provide it real-time on a screen, instead of a daily report that is out of date as soon as its printed?

No one wants to be in the middle of oh, say, their AS9100 certification audit to find out they missed updating something that had been duplicated... 

... not that I'd know anything about that... :-)

AMac

PS: Thanks to all who pestered, er, asked me to write again. I appreciate the encouragement. A