DfSS implementation
Six Sigma – iSixSigma › Forums › Old Forums › General › DfSS implementation
- This topic has 13 replies, 4 voices, and was last updated 13 years, 4 months ago by
Mike Carnell.
-
AuthorPosts
-
October 29, 2008 at 4:04 am #51215
MBBinWIParticipant@MBBinWIInclude @MBBinWI in your post and this person will
be notified via email.For those implementing DfSS – I have found in several companies that there are multiple functional groups that “own” different parts of DfSS. Inbound marketing owns the VOC part (customer segmentation through horizontal slice of HoQ1), Systems engineering has the concept development aspect (vertical slice of HoQ1 through Pugh and creation of top-level design scorecard), design & manufacturing engineering the detailed optimization for robustness, reliability engineering the reliability specific aspects, and quality/operations the process validation and control plans. Because some of these functions don’t see great value in their participation in other parts of the overall process, it is difficult to get them engaged in an end-to-end program of training (nor, quite frankly do I see it as necessary).
Query: Have other organizations segmented up their DfSS deployment so that the appropriate skill-set training is provided directly to the functional groups that most directly relate to those tools? Have you approached certification from those specific skill-set areas (GB in VOC for example)?
“Wave” training for DfSS seems problematic and wasteful. DfSS projects tend to be much more expansive in scope and longer in duration and trying to pace a training program around an actual project implementation has not worked effectively for us.
Any comments would be appreciated.0October 29, 2008 at 6:31 pm #177183
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.MBBinWI,There are lots of opinions around the DFSS type deployments. The Guys at Statistical Design Institute (SDI) are going to be hard to beat in terms of hands on experience. The founders have around 20 years of experience and regardless of what some claim I don’t know anyone who has more than this.If you give them a call and speak with George or Jesse they can probably give you some great advice in just a matter of minutes.Just my opinion.
0October 29, 2008 at 8:37 pm #177194
Gary ConeParticipant@garyaconeInclude @garyacone in your post and this person will
be notified via email.Agreed on SDI. Tom Cheek is a class act as well even if he does sound
like a Texan.0October 29, 2008 at 9:20 pm #177196
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.Gary,Tom is a class act. He was sort of stepping back from the business for a while the last time we spoke. Tom and George are both from the old TI work at SSRI with Motorola. Jesse is newer but with mentors like Tom and George the learning curve is significantly shorter.Happy to see you posting.Regards
0April 9, 2009 at 7:36 pm #183262
MBBinWIParticipant@MBBinWIInclude @MBBinWI in your post and this person will
be notified via email.Mike: I was mostly asking to gin up some discussion. I’m a highly seasoned (if I have to say so myself) DfSS expert. Seems like this board is mostly “cruised” by DMAIC types, so wanted to get some good DfSS issues going. Unfortunately, it devolved into name calling and nothing really useful came about.
Gary Cone preceded me at my (now) former employer. I haven’t had the personal pleasure of his acquaintance, only his reputation.0April 9, 2009 at 7:39 pm #183263
MBBinWIParticipant@MBBinWIInclude @MBBinWI in your post and this person will
be notified via email.Gary: I was mostly asking to gin up some discussion. I’m a highly seasoned (if I have to say so myself) DfSS expert. Seems like this board is mostly “cruised” by DMAIC types, so wanted to get some good DfSS issues going. Unfortunately, it devolved into name calling and nothing really useful came about.
RA has basically killed off the CI group. 2 MBB’s left, and they’ll soon be gone as well.
I’ve had conversations with Tom a few years ago, and met him at a conference somewhere. Seemed like a very knowledgeable fellow.0April 9, 2009 at 10:01 pm #183270
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.MBBinWI,
Just a quick impression of what you described sounds to me like functional silos. I have never seen much good come out of an organization like that unfortunately most design groups I have been around are structured like that.
I have seen a few design team approached so that the silo is around the product and/or the customer. That seems to generate some better designs but I think people struggle with the idea of being part of a product/customer team rather than part of a department.
I did a very short period of time that seemed like an eternity at Compaq Computer (pre HP). I was in Servers so I can’t speak for the rest of the organization but the relationship between the marketing and the design guys was amazing. The design guys were very clued up and ran with data and the engineering guys trusted them. It was a very nice thing to see.
The issue I see with DFSS is that people seem to think that they can launch this product using DFSS and not others. If you are going to DFSS it needs to be the way you do business not waking up in the morning and deciding if you are going to work as Ying or Yang.
Just my opinion.0April 10, 2009 at 1:45 am #183281
MBBinWIParticipant@MBBinWIInclude @MBBinWI in your post and this person will
be notified via email.Mike: What I have found is that for most product development organizations there are different functions that participate on the multi-function team. The marketing guys really have no interest in robustness or reliability (other than that the product is – both), and the engineers really don’t get into VOC data gathering, although they live and die on it being done well. So, it seems better to ensure that the various functional participants at least are doing a more effective job at their primary role. It is necessary to describe the entire process to the team members, so they know how they fit in the overall process, but they only need extensive tool training in those elements where they directly lead the effort.
Just my humble opinion.0April 10, 2009 at 1:48 am #183282
MBBinWIParticipant@MBBinWIInclude @MBBinWI in your post and this person will
be notified via email.And I’m not sure that I understand your final paragraph. Can you elaborate, please? Thanks.
0April 11, 2009 at 11:42 am #183309Have sent the concerned slides ……..
0April 13, 2009 at 6:01 pm #183355
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.MBBinWI,
I am not sure how you got your impression about the marketing guys and the engineering guys. Maybe I spent to much time in automotive and aircraft engines but everybody seemed real interested in robustness and reliability (that would include the government guys for things like bomb fuses). I don’t know how the engineering guys have a clue what to design to if they aren’t working from the VOC.
There was a book out called “The Power of Alighnment” by George Labovitz (I don’t know if it is still available). It differentiated between vertical alignment (the one everyone always talks about) and horizontal alignment, where you align processes with customers. It might be worth your time to take a look. It has a tendancy to shift peoples focus from internal to internal and external.
Just my opinion.0April 13, 2009 at 6:04 pm #183356
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.MBBinWI,
I don’t see how anyone can successfully decide to launch a certain product using a DFSS program and another product not using it. If you try to run a place like that the message is mixed and lacks commitment. DFSS is not a tool. It isn’t like trying to decide if you want to use a t-test. If you understand the logic of it and believe it then you commit to it and that is the process for new product development.
Just my opinion.0April 13, 2009 at 8:10 pm #183365
MBBinWIParticipant@MBBinWIInclude @MBBinWI in your post and this person will
be notified via email.Mike: I believe that your confusion comes from looking at all product development projects being “equal.” In my experience, going on 20 years, few projects are truly “new.” In reality, I have found that nearly 2/3 are just fixing things (cost reduction or reliability improvement), and even the 1/3 that are “new” rarely have more than 10-15% that hasn’t already been done. Thus, when fixing problems, a DMAIC approach is appropriate. That doesn’t mean that a phase-gate product development approach isn’t appropriate, it is. BUT, if the emphasis of the project is cost reduction, then I wouldn’t expect to redo VOC, rather I would expect that the existing VOC be reused (and depending on how long since it was gathered, perhaps validated).
Yes, every prod dev project should aim at six sigma (or whatever level of sigma is appropriate for your organization), it’s just what approach you take. If you’re fixing problems, use the problem fixing approach (DMAIC), if creating something new, use that approach (DMADV or whatever flavor of DfSS you prefer).0April 13, 2009 at 9:37 pm #183369
Mike CarnellParticipant@Mike-CarnellInclude @Mike-Carnell in your post and this person will
be notified via email.MBBin WI,
I don’t think we are going to get very far with this. I must have missed the part where I said they were all equal. There is nothing equal between the GE 90 engine, a server and thin film ignition, to name a few.
With the rate of change being what it is, depending on technology, and products having 18 month product life cycles there is probably more of a down side to missing the VOC and putting yourself out of the market for 18 months than spending the time to make sure it is right. I see that as the old timers I run into that like to tell me how many times they have fixed something in the past so there is no reason to do a problem statement.
In terms of it being done before I don’t see why that has anything to do with it. There are basic design flaws in most things that are built today. How many times have you seen legacy tolerancing that doesn’t have a thing to do with reality?
You suggest we only use DFSS when creating something new and the paragraph before you say we only have about 1/3 that is new and in reality only 10-15% of that is new. Do I understand your position correctly; there is no real use for DFSS?0 -
AuthorPosts
The forum ‘General’ is closed to new topics and replies.