Case Study: How to Efficiently Manage New Product Development Project Attributes Nat Workman PLM Technical Lead [email protected] http://www.mercuryplm.com About Mercury Marine • World’s Leading Marine Propulsion Manufacturer • Mercury Marine is a division of Brunswick Corporation (BC:NYSE) • BC is Forbes “Best Managed Consumer Durable Goods Mfg” (Feb/06) About Mercury PLM Services • Management on-boarding, business process development, implementation facilitation • PLM solution architecture, configuration, support • Process-focused training materials, end-user training facilitation • Clients include aerospace, consumer goods, and heavy equipment manufacturing Our goal is to guide and help clients ‘look beyond their current horizon’ by focusing on creating consistent business processes that drive innovation and sustainable growth through technology enablers. Topic Overview • History • Business Need • Solution Development • Business Involvement • Application Overview • Questions History • Large engine development programs operated from massive Excel spreadsheets—hundreds of columns, thousands of rows. • Manual BOM item/structure reconciliation • Full-time employee(s) just to maintain Business Need • In 2006 the business requested a cross-functional team review the problem of managing attributes associated with large engine development programs • Pillar Requirements: • BOM structure automatically managed from PDM • Cross-functional attribute participation (many hands make for lighter work) • Simplified highest-level metrics • Cost, weight roll-ups • Editable by all users simultaneously worldwide • Attribute security managed by group Solution Version 1.0 • In mid 2007 the initial deployment of the ‘EBOM Pilot’ was deployed to end users • Solution based on Teamcenter Engineering 9.1.3.5 • Contained 50 attributes in POM schema • Attributes managed in tabbed form with security by group • Deployed on a non-production (Pilot) server Solution Version 1.0 Trouble In Paradise • Application ran extremely slow • Constantly managing reference issues • Sync issues from production to Pilot server • Business wanted more attributes—making system even slower, extremely labor intensive to update • Reporting driven from Cold Fusion, requiring additional skillset to maintain New Approach • Version 1.0 met Pillar requirements, but slow performance made it unusable to end-users • Pilot server solution supported a VERY high-profile new product development program • Business still maintained spreadsheet because of performance issues • Took a clean slate approach late November 2008 New Approach Concept: 1. Pull attributes from disparate sources and present them in a common interface 2. Master planning/transient attributes separately 3. Leverage Tc BOM management functionality Project Project Plan Project Milestone and Critical Dates (Future Development) Current Functionality TcEng TcCommunity ERP Product Structure Planning/Transient Attributes ERP Mastered Item, Item Revision Teamcenter Mastered Item, Item Revision, and BOM Attributes Reporting/Common View New Approach • Enabled by Large Assembly Management Methodology • Common BOM Level 2 and Level 3 across similar product categories New Approach • Engineering Bill of Material Management • Pro/E Design>Teamcenter PSE>TcCommunity • Requires designers to save updates into Teamcenter so changes flow into TcCommunity Pro Engineer Teamcenter PSE Teamcenter Community Solution Version 2.0 • New Name—Mercury Parts Planning Application (PPA) • Launched May 2008 • More than 70,000 data or structure changes • Audit trail records attribute and bill structure updates • Displayed on application home page • Over 200 Cross-Functional Users across numerous locations • More than 200 item-specific, transactional, and planning attributes Application Benefits • Web-based application with spreadsheet-style interface for ease of use / learn • One application to view attributes mastered in multiple sources • Master planning (transient) attributes in TcCommunity where flexibility is greatest • Engineering structure and attributes mastered in Teamcenter allows for design changes to be automatically managed • Reporting provided as Views, dashboards, and extracts • Attributes associated with projects as needed • Ability to manage attributes through development by phase Application Role PPA is a… • Planning tool • Reporting / Viewing application • Attribute repository PPA is NOT a… • Bill management tool • Communications device • Bill comparison application Attribute Board • Attribute board owns the process and application • Cross-functional team consists of one critical user from each functional area • Made decisions for entire program • Board active in all prototype review sessions • Participated in final User Acceptance Tests (UAT)—final sign-off for production • Served in training sessions for functional areas • Excellent change communication agents Attribute Board RACI Attribute Board (Y/N) Req. Sign Off Program Management Director R N Y Engineering Director R N Y Manufacturing Lead R Y Y Procurement Project Manager R Y N Cost Accounting R Y Y Engineering Lead R Y Y Engineering Manager R Y Y Engineering Director C N Y Engineering Director C N Y Engineering Director C N Y Quality Lead R Y Y BOM Group R Y Y PPA Project Lead A Y N Role Application Development Process • Process First—Gather Business Requirements • Work through conflicting team priorities / needs. • Use priority matrices to manage requirements and establish development phases. • Obtain requirement approval from stakeholders to proceed. • Development Methodology—Iterative / Engaging • Establish time estimation and project plan for current phase. • Present phase development plan to Attribute Board for approval Use Rapid Application Development (RAD) methodology. • Iterative, time-boxed, quick team decisions, frequent reviews. • UAT event participation required by Attribute Board to sign-off deployment before Go-Live. • Training and Support • Provide End-User Training before Go-Live. Requirements Gathering • Attribute Board ranked attributes based upon Business Needs to assess requirement importance. • Attributes with strikethrough were eliminated by team before development began—Remained in document for historical or reference purposes. Requirements Gathering • Attribute Board ranked attributes based upon Priority Criteria. • Requirements pushed or pulled into development phase based upon criteria. • Development estimate for Nice-to-Have requirements promoted some earlier in development sequence. Program Management • RAD development approach • Fast Pace—RAD requires team commitment to attend weekly prototype and decision reviews. • Weekly development schedules/completion windows • Strict adherence to decisions, session attendees empowered to make decisions Program Management • Communication Key to Successful Adoption • Town Hall meetings with end-user community • Teamcenter Community used to manage project information • Updates to design engineering and other cross-functional staffs Team Communication Aides Program Management Thank You! Siemens PLM Connection 2010 Dallas, TX June 28 - July 1