Wednesday, August 14, 2013

Why Do Need An Engineering Change Process?

One primary objective for introducing changes to the existing processes with the transition to the PLM environment will be to ensure consistency, discipline and control on the flow of data from Design to Manufacturing. This data flow, under Change Management control, will authorize manufacturing logistical actions. Automotive, Manufacturing, High Tech and Aerospace industries have widely adopted Engineering Change Management processes. Engineering Changes (EC’s) define parts release, revision and obsolescence which drives parts planning, acquisitions and dispositions. Knowing the EC level will help us isolate technical problems to dates and levels to minimize costs of identifying and fixing problems in the field. We know who has what, when it was built, and what is in each and every machine that is built. EC’s will provide a clear and precise historical record on all product programs, down to the individual part numbers.

Engineering Changes are the vehicle for releasing the product (item/BOM). An engineering change will establish or modify the basic records (part identification, content, usage) and reference the technical data, such as prints, drawings or CAD/CAM data. The release of technical data and records information should be concurrent. Usually, groups of parts to be designed and released at the same time are grouped into ECs.

The bill of material is a dynamic document, reflecting the dynamic nature of products. Products change and evolve, getting better. Changes to the bill-of-material can be a controversial topic. The problem with engineering changes is really several problems disguised as one. For a start, the basic problem is the volume of changes. One or two changes a year wouldn't amount to any problem at all. Dozens, or even hundreds, of engineering changes a month adds up to a nightmare when neither justified, nor
managed properly. Finally, bill-of-material changes, when handled incorrectly, tend to generate a lot of problems, which are usually blamed on something else.

Engineering changes are, as a rule, tough to control and hard to communicate to everyone who needs to know. Many companies do not have the tools for planning and scheduling in place, so it doesn't matter how the bill-of-material changes are made. Perhaps the biggest reason people are against using an EC to control a product/part release is a lack of understanding about the impact those changes can have on the business. It's not always obvious that the visible problems on the shop floor are a direct result of mismanaging engineering changes. Here are just a few of the problems that can result from poorly managed changes:

1. Excess obsolete inventory: This happens all the time. There is inventory left over after the part has been obsolete. If changes are poorly managed, it is not unusual to see obsolete parts reordered.

2. Assembly, packaging or finishing shortages: You can't build it if you don't have the parts. Shortages often occur because we run out of one component before the new component was ready or had been delivered. When the bill-of-material is not current, the wrong material is scheduled.

3. Inefficient Production: When engineering changes are not properly managed, theproblem often doesn't surface until the last minute. Final Assembly discovers it is using Revision D. The latest engineering design is Revision E. The parts must be reworked or produced to the latest revision with zero lead time.

4. Missed delivery dates to customers: Only items on the bill-of-material can be scheduled. When the bill is not updated with the latest engineering changes, the wrong materials are scheduled and produced. The problem is usually discovered in the final stages of production, and that's too late.

5. Poor product quality: When the bill is not properly maintained, the latest product improvements from Product Engineering are not communicated to the factory floor. 

6. Lack of configuration control: Product liability is a big issue facing industry. Failure to provide good control over the configuration of your product is the quickest road to failure.

7. Erroneous product costing: When the bill-of-material is not maintained properly, the product costs do not reflect what it actually costs to make the product.

The net result is that mismanaged bill-of-material changes result in major financial losses, and many companies don't even realize it. Time and time again, people who routinely handle their companies bills do not realize the cost implications in poorly managed changes. They don't monitor change costs, and, consequently, top management isn't aware that a problem even exists.


Conclusion
Competing in today's global market means getting new, innovative products to the market before the competition. By using the formal system and having an efficient product change management process which starts in the early stages of engineering, all of the documentation necessary to get into production can be justified, tested and released to manufacturing in a seamless fashion. 

Friday, June 14, 2013

Product Compliance - an organization growth enabler

A few weeks back, I had a discussion with a client about Product Compliance. It was a very interesting as some of them saw compliance as a necessary evil, which was complete opposite to my perspective.

Organizations today are facing a constant challenge to keep up with ever changing product regulation.  Every year, quarter brings increased global product compliance laws, which requires increased spending by companies to mitigate the high risk of being non-compliant and to keep up with constantly changing laws. 

Companies can see this as a necessary evil or as an opportunity to growth enabler. Those that see as necessary evil take a project-based approach, while forward thinking companies take a holistic approach and take a process-oriented approach.  Organization need to view product compliance as a growth enabler.

The risk of being non-compliant increases as the product progress across different product stages.



Forward looking organization follows a simple guideline:
·       Enable compliance in early product stage, putting less pressure in the downstream stage
·     Design for “Social Compliance” which includes stakeholders like NGO, people, government as will play an important role in acceptance of a product
·    Take a proactive process based approach so the products are prepared upfront for any legislative changes
·     Educate and collaborate with suppliers early in the process putting less pressure on suppliers which allows companies to get the compliance date in-time
·        Electronically manage compliance data is well designed system

Product compliance does address risk, but with vision also provides growth opportunity for organizations as it prevents expensive product recall & product delays thus increasing revenue and profit.  Compliance is a living process, and not a point in time – but an ever-evolving process to meet compliance. 

Thursday, June 6, 2013

Insight - Who do we hire for a Business Transformation?


You realized that there is a need for Business Transformation in your organization. And now, you are looking for consulting services to help you sail through the long journey you are about to take. Well, you look out for choices in the market and there is a variety available to pick:
1.    Independent Consultants - bringing breadth and depth of industry experience
2.    Small Consulting firms - talking niche skills
3.    System Integrators - generally providing technical capabilities
4.    Consulting houses - helping in strategy direction

It would be really hard to classify any other variety outside the 4 types mentioned above. And you would get your needs met either by mix or going with a single choice, depending on your preference. The extended consulting provided by product/package vendors is limited in nature and hence does not make broader differentiation to this subject.  For Business Transformations programs, the subject goes beyond aspects of capabilities rather principles. “TCQIVcomes into play wherein  T is for Time, C is for Cost, Q is for Quality, I is for Impact and final one V which is for Value realized either in tangible or intangible terms.
So, looking from outsiders view on TCQIV based on what we have heard and seen with clients, in 20 years, for large transformation programs, it represents an interesting picture as shown below.



"Independent Consultant & Small Consulting companies makes client's life simple"

Well, there are soft sides to business decisions as well which influence TCQIV principles. After all, business decision makers are humans too and they look for humanitarian aspects as well to make a successful transformation journey and they could vary from organization to organization. However over the years of experience, we have seen some of them to be looked in more critically than some of others. And no matter what one says about choice of hiring, these aspects have played a significant role in the making of  the final decisions. At times, even some businesses give soft aspects a higher weightage than others purely due to the fact that business acumen and technical knowledge can be learnt however softer aspects of organization are built over a period of time and are the foundation pillars of success.





"Large Consulting firms and System Integrator's focus on selling their 'partner / framework' service to client" 
 
Moreover, the risk-taking appetite and financial stability, at times, does not favor independent and small consulting firms. However they negate it by demonstrating high ethics, integrity and innovation. And because they are more open to co-create with client, financial risk or IP based revenue sharing models generally make things easier with independent and small consulting firms. 

 
SI (System Integrator) and big consulting  firms on the other hand seek revenue generation opportunities by selling their services. They are biased predominantly due to the partnerships they have which at times have averted clients moving away from co-creation opportunities with them as they result in more complex collaboration than co-creation. 
 
 

What is the right strategy to hire? 

Business transformation needs a mature decision and budget distribution across phases of the program. Experience has shown that it is best to have an ‘unbiased’ view for strategy, vision, roadmap and vendor evaluation followed by a collaborated model with an SI for execution phases. Independent consultants generally do not carry any partnership representations and hence are more unbiased as compared to others however they should bring in industry leadership in their approach. Independent consultants  and small consulting firms are more flexible and innovative and can think beyond the box and can help in defining strategies. SI and large consulting firms have partnership tags and hence they influence decisions for strategy, software evaluation and vendor selections. Their biggest strength is in execution.


Though how much one tries to make a business transformation look simpler, it is always full of perplex and complex situations which are unique to client business and hence no single entity is the right solution. Right mix of talents and partners is the direction one should take to make a business transformation journey successful.

 

Friday, May 24, 2013

Does Training Guarantee Successful System Adoption?


Recently, I was conducting an assessment for a PLM business transformation program. I was surprised to learn that key KPI’s were not met after PLM implementation. One of complaints from the end users was that the PLM system did not deliver the required functions and features that they had seen as part of package selection and design phase. This was a shocker, as these same users that defined system requirements and part of design and were given detail system training a part of the go-live. I did some research and learnt that it was NOT true and found it to be a system adoption issue. The users were not using a function or feature as designed.

Organizations often forget that training is 40-50% of the adoption process. Training is one of the components of Change Management. Training is a part of the Terminal Behavior Capability Development process which includes pre-course, knowledge transfer, post-implementation skill development, remediation, and maintenance. Users need support and guidance after the initial go-live training.
 



 
To ensure successful system adoption, organizations need to:   
  • Develop an Adoption Strategy
  • Provide necessary skills and tools
  • Assign a trusted subject matter expert group for end-users
  • Define the support structure for end-users. Setup two-way communication between the project team and end-users
  • Defined Rewards and Consequences
  • Set Clear Expectations. Focus on the end-users and business context to drive widespread adoption. Review what functions and features the end-users use to complete their day-to-day tasks.
The Bottom Line: A well-defined adoption plan with clear expectations, skills, and tools provides a high probability of system adoption.
Note: As for my client, I did setup focus groups to give system tips and help users understand how the functions and features behave.  After these focus groups were held, the users did feel that the PLM system delivered the required functions and features. I also held lunch and learn sessions which also helped.

Saturday, May 11, 2013

PLM Package Selection

Implementing any off the shelf PLM package solution needs be tied to a long term business strategy. The role of PLM in enterprise strategies can be decrease product development time, decrease product cost, increase product revenue and introduce innovative products.

There are two typical approaches for implementing a PLM package:
·         Big Bang Approach
·         Phased Approach

The Big Bang Approach requires large number budget and have project timelines. Organization today prefer phased approach as they build on small successes there by getting continuous commitments from stake holder and key business users.
Guiding Principles for successful implementation:

·         Define Program Scope - Get a sign-off so that scope creeps can be avoided. Make sure the program deliverables and deliverable owners have been clearly documents. Map the program to the business stratergy and defined measurable matrix.

·         Establish Project Governance Structure - Define upfront with clearly defined responsibilities & Expectations. Executive support is a must.

·        Secure required resource - Before the implementation begins make sure that your organization has the time and financial and personnel resources necessary to support it during the acclimation period.  It is also important that your team contains the appropriate "balance" of technical and functional experts and is experienced in the implementation of the considered product.  If required, hire external help for the implementation

·         Define To-Be Business process - Involve key stake holders and functional users during the process design session. Because the implementation PLM product may significantly impact the business functions of an organization, it is imperative to involve the user community in the process design from the outset.  In addition to the technical issues, understanding the business issues will lower the risks associated with the implementation.  A stable operating environment coupled with functional users willing to accept a new way of doing business will also minimize implementation obstacles. 

·         Examine the Product & Process "gap"— The PLM package has not been specifically designed to meet your organization's unique requirements, there will be a gap between the business processes and product functions / featured to support your existing processes and systems. It is imperative that you understand this gap well before the implementation begins and ensure your organization can accept this gap without degrading performance. Make sure the options for gaps are evaluated before deciding to customization. Avoid excess customization as it forfeits the advantage of using PLM solution

·         Understand the PLM Package - Visit another organization that has implemented the PLM package during PLM vendor selection process. Early in the process, obtain a comprehensive understanding of the functionality of the PLM package.  If possible, obtain hands-on experience with the system.  Consider prototyping or piloting the package in your environment..

·         Validate performance and scalability - Ensure that the product's capabilities support the needs of your organization. Confirm that the PLM package has previously supported the number of users and geographic locations your organization will require.

·         PLM Package Adoptions:  Adoption is the final step to the package evaluation. Other than keeping financial aspects into picture the most important factor is “organization change management”. If this is not properly defined and taken care of, the whole adoption could prove harmful. While adoption strategy is defined in phases, it is important to note the change management along with that phase. Historical records have shown failure to PLM projects due to lack or poor change management in adoption strategy.
PLM is not a technology implementation, but business transformation journey that reloves around product and product development process.