Accenture Acquisitions: May be a Game Changer in Product Development Services

Last week Accenture announced their intent to acquire PCO Innovation which will be their 2nd acquisition of a Product Development Services company in less than 90 days. Accenture acquired significant capabilities in Siemens Teamcenter with their 1^st acquisition on PRION Group in August 2013. Now, with the recent announcement to acquire of PCO Innovation, it will acquire new clients and have additional capabilities in PTC and Dassault to strengthens its Technology services offering.

Traditionally, the big 5 consulting companies always had a focus on ERP and Supply Chain initiatives, as these tend to be much larger in revenue and are long term compared to Product Development initiatives which are much smaller. The Accenture acquisition signifies that these companies are now looking to grow and build their technology and outsourcing services capabilities for Product Development and become “One Stop Shop” for Discrete Manufacturing, Aerospace, Automotive, DOD, Retail, Medical Devices, Pharma and High Tech.

PRION Group has its headquarters based in Europe while PCO Innovation has its headquarters in North America. This will give Accenture significant additional presence in Europe and North America market and help them to become one of the top 3 Product Development Services companies in the world.

It won’t be surprising if Accenture next acquisition is a CAD/CAM Engineering  Services outsourcing company. Engineering Services is another area for growth for them where traditionally Indian companies have controlled 23% of market share as per Zinnov’s Annual Global R&D Service Provider Ratings 2013.

Last year, PWC acquired PRTM, one of leading management consulting company with significant expertises in Product Development. Kalypso another niche Product Development consulting company based in Ohio-US had setup a technology delivery center in Mexico. Well, it shows that Management consulting companies are looking to capture downstream revenues as well by either setting up delivery capabilities or through acquisition of delivery capabilities, while Technology services companies would try to acquire management consulting capabilities for to move upstream. One example is of Infosys which acquired Lodestone to up its consulting capabilities and thus provide “End-to-End” services to clients.

As we move into 2014, I foresee more acquisitions and mergers in the Product Development space (software and services). And with Accenture, let’s see if the recent acquisition is a “Game Changer” in the Product Development services.

Mobility in PLM: Getting the Definition Right

In continuation of my previous blog and huge demand from folks across to know details on mobility, I decided that it is time to tell the story. Honestly, I was planning to publish this part sometime next week.

A fortnight ago, I was conducting a session on Mobility for Product Lifecycle Management. While I was preparing for the session, I thought of doing a search on the terms which define mobility for PLM. Checked up in Google trends and results are published .

What caught my attention was increase in interest for similar looking terms and change of interest over period of time. Interestingly, PLM Mobile is the term which is getting attention (increase of 35% over time) and the one which I choose ‘PLM Mobility’ seems to have zero records. Well, this did not discourage me as I still could not figure out the right definition behind most searched terms i.e. ‘Mobile PLM’ and ‘PLM Mobile’. Hence, I rest my case here for the term which I think rightly defines what we expect from PLM and Mobility i.e. ‘PLM Mobility’.

To understand PLM Mobility, we first have to start from defining what Enterprise Mobility is and then see how PLM Mobility fits. Yes, this is how we need to start rather than looking directly at PLM level and kill the essence. The reason for that is very simple. PLM is an enterprise level not an IT initiative. Although, how different it may sound to people and some may argue that PLM is an IT function, I must say that they need to take a step back and look at PLM ecosystem. PLM has a business case which is enabled by IT not the other way round.

Further, PLM enables product innovation and adding mobility to it effectively means enabling mobility in product. Now, this is interesting because mobility in product has many dimensions and most of them are based on business and strategic roadmap of an enterprise. So moving from top to bottom, Enterprise Mobility makes sense to be the right starting point to define PLM Mobility - which is at Level 3 as shown in picture below:

Level 1- Enterprise Mobility: To put it in simple terms, it is about converging business process, technology, and people on a mobile device (Tablets & Smartphone) either provided by an enterprise or by BYOD (Bring Your Own Device) policy. BTW, we should not confuse laptops and notebooks as mobile devices. Laptops and notebooks are considered portable device and not mobile devices.

Level 2- Enterprise Product Mobility: is innovating product by extending internal view and capturing external view via mobile device (Tablets & Smartphones). We extend the Product information which is stored in various systems to internal and external collaborating partners in Enterprise Product mobility.

Level 3- Enterprise PLM Mobility: is about developing & managing product’s life cycle via mobile device (Tablets & Smartphones). We extend the data that is stored in current PLM system to mobile devices. Native apps provided by the PLM Vendor can be classified as Enterprise PLM Mobility. These apps have limited use cases and focus on key out of box process approvals and consumption of data. Organizations have not fully adopted these native apps as these out of box use cases do not meet the organizations product development processes.

So I hope with this structure PLM Mobility will find its due credit in organizations who are thinking about it. Well, the business case for PLM Mobility needs to be envisioned because as organizations mature, new thinking has to seep in. 

Let me know what you think!

Product Innovation is getting attention..!!

Last week, I attended my 2^nd Product Innovation Conference (http://us.picongress.com/) in Chicago. This year’s conference focused more on Product Lifecycle Management (PLM) than Product Innovation. Or, I should say it was portrayed as if having PLM is in itself sufficient for Product Innovation. This is of course not true. Product Innovation is about letting innovation come from any aspect of product development, whether it is customer feedback which forces you to think differently, supplier’s new IP driven part which would revolutionize product, design engineers working on completely different – never heard before – design  and feature set or an idea which sparked out during a conversation over coffee with friends. All this have no relation to whatsoever with PLM, except the fact that PLM can help manage, organize and track this information, once stored. The conference did have a few participants talking on Product Innovation. Overall the conference was a huge success with so many insights into Product Development across various industries that made me write about it.

Day 1 - The key note presentation was led by the Commissioner and CIO for City of Chicago, where she talked about collaboration between cities, counties and communities and how they rely on expertise developed by each other when there are limited resources (human and financial). She talked about future of technology and mayor’s vision to use data analytics, mobility and social platforms to take information closer to society. Very impressive indeed!

The presentation by SVP of ETAC AB where he talked about 12 advises on changing status of PLM from mere an IT function to Enterprise PLM. His insight as to why most of PLM projects overrun and are not successful is because PLM is perceived as IT project and not business transformation program and hence a lack of alignment between IT & business.

Pharmaceutical companies shared insights into their product development facts. It was interesting to note the amount of investment needed to bring a new product is over 1 billion and with over 90 % failure rate at stage 3 (which is one of test stages before FDA approval). The best part was the future perspective where medicines will be about personalization, based on our body structure and weight. The rest of Day 1 had sessions spread across industries ranging from process centric, to manufacturing to automotive to pharmaceutical and so on.

Day 2 - The key note presentation by the Director at New Harvest was an eye opener. She talked about cell cultured leather and cultured meat which will change the future about meat and leather. The cultured meat (beef) is created by extracting & harvesting naturally occurring stem cells from living cows and requires only 1% of the land, 4% of water, 50% of the energy than farmed meat.  She also gave an example of a company using plant extract as a substitute for egg for making mayonnaise, which made it vegan. The company instead of marketing at vegan / vegetarian mayonnaise is marketing as cholesterol free mayonnaise as it could target a larger market segment. Amazing!

There were also some new vendors at the conference who participating for the first time. Two of vendors caught my attention; the first was a software vendor on Engineering Knowledge Lifecycle Management which talked about preventing knowledge lost during product development and reusing it next time.  And the second vendor was on PLM Mobility demonstrating some of the apps built for Engineering and Retail, Footwear and Fashion and how they are being acknowledged and demanded by clients.

One thing that was missed at conference was lack of any case studies / presentation about Organization Change Management (OCM). OCM is mostly overlooked on any Product Development business transformation programs.

Well, I was conducting a think tank session on ‘Enterprise Mobility’. We defined “what is mobility” and proposed an initial maturity model. There was consensus that Mobility is not another jargon or fad but reality near term. Stay tuned for more on this.

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. 

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. 

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. “TCQIV” comes 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.

 

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.

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.