iSixSigma

DfSS implementation

Six Sigma – iSixSigma Forums Old Forums General DfSS implementation

Viewing 14 posts - 1 through 14 (of 14 total)
  • Author
    Posts
  • #51215

    MBBinWI
    Participant

    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.

    0
    #177183

    Mike Carnell
    Participant

    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.

    0
    #177194

    Gary Cone
    Participant

    Agreed on SDI. Tom Cheek is a class act as well even if he does sound
    like a Texan.

    0
    #177196

    Mike Carnell
    Participant

    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

    0
    #183262

    MBBinWI
    Participant

    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.

    0
    #183263

    MBBinWI
    Participant

    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.

    0
    #183270

    Mike Carnell
    Participant

    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.

    0
    #183281

    MBBinWI
    Participant

    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.

    0
    #183282

    MBBinWI
    Participant

    And I’m not sure that I understand your final paragraph.  Can you elaborate, please?  Thanks.

    0
    #183309

    Trainer
    Member

    Have sent the concerned slides ……..

    0
    #183355

    Mike Carnell
    Participant

    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.

    0
    #183356

    Mike Carnell
    Participant

    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.

    0
    #183365

    MBBinWI
    Participant

    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).

    0
    #183369

    Mike Carnell
    Participant

    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
Viewing 14 posts - 1 through 14 (of 14 total)

The forum ‘General’ is closed to new topics and replies.