Product Lifecycle Management (PLM) vendors promise their systems to be so great, they can be used by organizations from the get-go, revolutionizing how they define and manage their product data. However, that is the case only for those organizations who are willing to adapt their own internal standards and procedures for the sake of pre-implemented best practices within PLM systems. All others must rely on configuration and customization. What is the difference between them and how to make sure they don’t end up being (risk, downside, weakness?) in the future? Read on to find out.
OOTB, or “out-of-the-box”, is the set of functionalities available to users immediately after installing a system. In case of a PLM system, OOTB means a group of pre-defined elements, such as:
These are, especially in the case of larger and more mature PLM systems, such as PTC Windchill, created based on certain industrial standards and best practices. They were defined jointly by their creators and some of the brightest minds from worlds’ best universities, but also actual customers, through many years of system usage and hands-on experience. Some things which initially were considered custom in the system have gradually made their way into the core product, becoming “OOTB”.
Most software vendors boast their software as being ready to handle any challenge for any company “out-of-the-box”, but very few are true to their word. Think: an office software suite, including a word processor, spreadsheet editor, presentation editor, etc. These will work similar regardless of who made them (OK, there may be some slight differences in the User Interface (UI) or the kinds of animations you can use, but the general “feeling” is the same).
In case of PLM, however, there is no “one size fits all” solution. It is very unlikely an OOTB (or “vanilla”) system can be utilized effectively within “just any” organization. Especially larger and/or older companies have their developed working methods, which have proven to be effective and should not be changed to fit the system – rather the system should be changed to fit these methods. What data and meta-data we consider important and decide to store in a PLM system also changes from organization to organization, as do roles and access control rules assigned to them. These and many more things usually need to be changed in a “vanilla” PLM system before it becomes truly usable to an organization, and this is where configuration and customization come into play.
Although these two terms sound similarly, they are in fact significantly different in meaning. Let us start by defining what these two are – in as simple terms as possible.
Configuration (in a PLM system) covers all the changes you can do to a product from the User Interface perspective. PLM vendors usually include configuration tools, allowing you to change the system behavior to a limited degree. This includes such things as:
Some people also include potential modification of system property values (in case of Windchill: changing the open-text values inside .property files) as configuration, but for the sake of clarity let’s not include this into this category at this point.
In other words, configuration is a system modification that does not require access, modification, implementation, etc. of the system’s source code[1]. For this reason, many people also consider ability to configure the software (and thus configuration itself) to be an integral part of OOTB functionality.
Configurations are generally supported between system versions, so if you upgrade your PLM system, you usually don’t have to worry about upgrading configuration to fit a newer version.
[1] Yes, configuration can usually be exported from a system (for the purpose of importing it to another instance) and then it does take the form of XML or other files which may contain code, but you don’t have to actually “touch” that code: open a text editor and write anything. You just “export” it and “import”, without actually looking inside those files.
Customization, on the other hand, is everything above and beyond configuration. Customization is any system change which requires modification or extension of the system’s source code (i.e. implementation, development), because the desired result cannot be achieved through configuration only. In most cases, customization examples include:
Although this does not exhaust the list of possible customizations. Through my years of working as a Windchill developer, there’s much I’ve seen people do with the system in terms of introducing new/custom features… and there’s even more of what I haven’t seen so far…
Software systems, PLM included, usually have their own lifecycle and get upgraded by their vendors from time to time. PTC Windchill is no exception here, with a roadmap detailed for a few years ahead. When upgrading your system to a newer version, you should never assume that your customization will work properly. System vendors introduce upgrades, changes and so on to their core products, which may render some customizations unnecessary, but also some portions of them can address pieces of code which no longer exists (or functions as it did earlier) in the core product – which can wreak all kinds of havoc on your PLM system. Each system upgrade with customization present should consider effort needed to verify the customization’s compatibility with the new version and (if necessary) its upgrade. For comparison, an upgrade of a “vanilla” system can sometimes be completed within hours. If complex and extensive customizations are present, it can be months, or even years (yes, I’ve seen such cases).
As you can see, the main difference between configuration and customization is that the first can usually be achieved via system UI, while the latter requires programmers to code new/changed functionality. Unfortunately, it’s not as simple as that.
Configuration, even if exported into a set of files (for the purpose of deploying in another system) is usually relatively easy to manage: Simply track the list of changes you did and never manually modify exported files[2].
Customization, as with most things programming, can be (and usually is) much more complex and should be managed appropriately. Otherwise, deploying it will result in a system full of bugs and errors, or even not starting at all (!), rendering it unusable and thus a big waste of money and effort.
[2] This would be the case in an ideal world. In the real world you do sometimes have to modify configuration files, which are usually XML. Still, by doing so you are not affecting the code of the core application.
No system or solution could possibly be designed to ideally serve all customers across all industrial verticals. In many cases customization will indeed be inevitable. Even as common a case as feeding information from your PLM to your ERP system upon “Release to Manufacturing” will require customization in the form of a system integration.
As a PLM system customer, you should not be required to know all the ins and outs of PTC Windchill, Siemens Teamcenter or anything else out there. Trying to learn all the intricacies and important bits may take years, which your organization may not have.
Therefore, you should rely on two things:
A partner should be your best asset when implementing a PLM system within your organization. Through years of working with other customers, such a partner should have gained deep understanding of tools he is working with and can not only tell you whether a system can act as you want it to, but also potentially advise on whether it’s actually a good idea to abandon its functionality and develop your own.
Software Development and System Operations, often referred to as DevOps, can be quite a complex topic – also for Product Lifecycle Management systems. If I went into details here, this would turn into an entire article on DevOps best practices for PLM, so I will cut it down to necessary details here:
I can pretty much bet that if a system uses customization, it also has configuration. In that case configuration, once exported from the development system, should also be managed as part of the process above – this will ensure an entire system deployment is coherent and smooth, and any and all issues are detected and resolved at an early phase.
Obviously, the process above is simplified… significantly. Even so (or maybe because of that), some organizations decide not to follow it and take high risk when developing PLM customizations. From what I’ve seen, this always ends in a disaster[3], so if you want to avoid being part of that disaster, please make sure your PLM service provider applies proper DevOps techniques before it’s too late.
[3] Yes, always. Sooner or later, but always.
After reading what you’ve read so far you may think you want to steer clear of customizations of any kind: they are often complex, risky and costly. That is largely true: what can be achieved using an OOTB product with some (even much) configuration, should be done that way. After all, most PLM vendors try to incorporate as much flexibility into their products and solutions as possible, so you don’t have to customize.
However, please keep in mind that even the best PLM system will not have all the features working exactly how you’d like them to, and thus will require some modifications. If a PLM salesperson ever tries to convince you that his PLM product will fit your (and every other business) perfectly from the moment you install it, show him the door.
Yes, there is. I’ve seen projects with over a dozen thousand custom classes, varying from a few dozen to many thousand lines of code. It was manageable, but barely. Managing dependencies between various packages slowly became a nightmare and tracking an issue to a change in requirement and piece of code developed by a particular person was almost impossible. Testing and debugging the solution required weeks, if not months, before every release.
Then came the system upgrades, which changed the core code of the system which was customized…
(Needless to say, any hopes of upgrading that system before severely decustomizing it were abandoned.)
Nowadays, vendors release new system versions more frequently than ever. Just like with physical products, for software Product Lifecycles also shortened to a point where some versions are fully supported for only a few months. Customers must now decide whether they want to use the latest features (and upgrade frequently) or install a long-term support (LTS) version. Of course, the more frequent the upgrades, the more time needs to be spent on ensuring that configuration and (especially) customization continue to work as expected.
Not all is lost, though, if you indeed need to heavily modify your PLM system. There is a way to manage and maintain even extensive and complex customizations: DevOps. This concept, if implemented properly, greatly simplifies many processes and helps maintain high quality of a solution even if significant modifications are introduced. It does not solve all challenges, but it helps. A lot.
Yes and no. Let me explain:
If you decide to purchase your PLM system as a SaaS (Software as a Service) offering, then the vendor of the system takes care of all the back-end work: setting up servers, installing and maintaining the system, performing upgrade, etc. However – you as a customer rarely (if at all) are going to get access to the actual operating system (OS) on which the PLM application is running. Since you don’t have access to the OS, you won’t be able to deploy your custom classes / code. You will have to rely on a SaaS provider for any change deployment. Some providers require lengthy and cumbersome processes to deploy even the smallest change, so select your partner carefully and ask them about their deployment procedure.
This second approach requires significantly more effort, not to mention deep knowledge of cloud solutions, especially if you want to achieve a satisfying level of automation. Luckily, this is where you can rely on your PLM partner to help you out. See for yourself how you can achieve SaaS-level automation (or more!) and peace of mind while leveraging the public Cloud to host your Windchill system, based on a real-life example from the automotive industry:
Although it might be easy to say that you should avoid customization at all cost, in the PLM world there is no “one size fits all.” While some organizations may indeed benefit from using an OOTB PLM system, it’s hard to expect many of them to let go of their principles and working methods – things that made these companies so great in the first place. While it is true that you should aim at minimizing customization, even large ones can be managed efficiently if a proper process is applied. Ultimately deciding whether to go with configuration or customization (or even a particular PLM product) should be an informed decision based on your organization’s true needs and requirements – in best case supported by the breadth of knowledge and experience of a trusted partner, who can later execute on the plan. Contact us!
Explore the importance of eco-design for businesses and the environment. Learn how eco-design principles, from material reduction to recyclability, enhance sustainability, reduce costs, and support regulatory compliance, offering a competitive edge in today’s market.
Optimizing automotive production processes and managing complex supply chains present several challenges in the automotive industry. As the automobile industry advances, particularly with digital twin technology, automakers are seeking more efficient and agile manufacturing solutions to remain competitive in a fast-changing market. The historical evolution of motor vehicles has significantly impacted the automotive industry, especially […]
Sustainable product design encompasses a systematic approach that considers environmental and economic aspects throughout a product’s life cycle. Sustainability and environmental impact have become a fourth key performance indicator (KPI) in product development, joining the traditional metrics of time, cost, and quality. Environmental impacts Adopting a design for sustainability framework positions companies at the forefront […]
Uncertain about Scope 3 emissions and the CSRD? This article delves deep, unpacking the importance of sustainable product lifecycles and how ecoPLM empowers businesses to excel in sustainability reporting. Discover how technology is key to transparency and environmental responsibility, taking your business beyond compliance and into a sustainable future.
Design for lifecycle sustainability is not just a concept but a necessity in today's environmentally conscious world. By adopting practices aligned with the EcoDesign Directive, utilizing Digital Product Passports, and employing technologies like CCS, industries can significantly reduce their environmental impact. With the support of GreenPLM toolbox, businesses can seamlessly integrate these practices into their operations, paving the way for a sustainable and profitable future.
Delve into the world of Modular Design and Product Lifecycle Management (PLM) where Variant Management emerges as a game-changer. Discover how embracing modularity and variant flexibility can lead to enhanced product customization, improved efficiency, and a competitive edge in the market. Unravel the benefits and strategies for implementing successful variant management in your PLM processes, and stay ahead in the dynamic world of product development. Join us in exploring how to revolutionize your approach to product design and management!
Information from various systems within a business is comparable to clues in a criminal case. Every single trace conceals information. Some of them drop out due to a lack of documentation.
Product Lifecycle Management (PLM) is by no means a new concept, in fact it has been around since humans started producing things. However, PLM has a different meaning nowadays.
In February 2020, we described how to upgrade Windchill to version 11 step by step. Over a year has passed since that time and a new major version of Windchill – 12 – was released. Today we will show you how to perform an upgrade from Windchill 11 to Windchill 12. Are you ready for Windchill uprade?
Product lifecycle management has never been more relevant than it is now, in an ever-changing world. Today, it is no longer enough to have a great idea or even good execution. What is needed now is full control over the product - from concept, through design and production, to service and disposal.
Most modern manufacturing companies use PLM systems to document and manage product data. PLM systems support many important operations in a company: first of all – administration of CAD files, documents, and data related to change management. All these functions are permanently updated with new requirements. A small error that occurs in one area can negatively affect whole processes.
The new opportunities associated with Industry 4.0 require companies to adapt to the new environment. In this article, we take a closer look at the current situation in the automotive industry, discuss the challenges it faces and the opportunities offered by digital transformation.
Migrating data to a PLM system is often a very complex undertaking, where business environment and ways in which data is being operated on play a key role. A Migration – what is it, what approaches are the most common and what challenges lay ahead of each one? These and more questions are answered in this article.
Process of the product development consists of many steps that are often very complicated, time consuming and not well defined. It is common that companies are struggling to track the progress of the development and keep the documentation up to date. The main challenge that I would like to focus on is the continuous need to improve the product. Because we do not live in the perfect world the changes are unavoidable – whether it is just small fragment of the design that needs to be updated, the part you have been using so far is no longer available or you have to make sure that the product meets the requirements of the new markets.
Windchill is PTC’s flagship Product Lifecycle Management software, which has its latest version this year - WNC12. The long-announced premiere, scheduled for 2020, was questioned due to the COVID-19 pandemic. But PTC did not disappoint – on 9th June, at the fair in Boston, it announced the release of the latest version of its product lifecycle management (PLM) software. Windchill, which is considered a model example of an Enterprise Class System, has gained new functionalities. What is the potential of the latest, twelfth version of this program? We decided to analyze it for you.
With Cloud technologies developing rapidly in recent years, so came the thought of using the Cloud for hosting various systems in it, from computationally demanding, through mission critical and more. Product Lifecycle Management (PLM) systems were no different and a large number of both PLM vendors and customers attempted to leverage benefits the Cloud brings to gain that competitive edge world’s best manufacturers always strive for.
Computer Aided Design (CAD) techniques have been inseparable from the very dynamic development of industry for many years and their role is growing with every decade. What started as fairly simple systems that functioned basically as virtual drawing boards, has developed over time into packages of advanced IT tools. Although initially they could only be used by select research institutes and the largest and most developed corporations, CAD systems have gradually gained popularity, acquired new functionalities and became easier to use. However, the real revolution took place in the era of fast Internet and Industry 4.0, when CAD systems have dynamically transformed into sophisticated tools integrated with PDM and PLM systems. In addition to the ability to develop a complete 3D representation of a product in a virtual environment, they support virtually all other activities related to the broadly understood design, construction, digital prototyping and preparation of data for other stages of the product life cycle.
The manufacturing sector is changing faster than ever. The increasing multifaceted nature of processes is associated with maintaining operational efficiency and high quality. The need for transparency and efficiency of operations is increasing and product innovations need to be implemented more and more quickly. Effective planning is the key to the business success of the organisation. In the Industry 4.0 era, IT technologies dedicated to product lifecycle management (PLM) have become even more helpful.
Still running a Windchill PLM system version 10.0, 10.1 or 10.2? There are several reasons why you should consider upgrading to version 11.1 (or newer).
ALM is an abbreviation of Application Lifecycle Management. As the name shows, the concept was supposed to be used mainly by developers during the process of creating programs. Currently, ALM is widely used in different business fields, where it helps manage a variety of projects. This continuous process of software development can be divided into […]
Once upon a time.. Far far away, over a hills and forests… Wait.. Wait.. Wait.. This is not another long fairytale about princesses, castles and dragons without merit or concrete, measurable value. This is a story about pursuing targets and passions. This is a story about people’s ideas and the way they evolve […]
After four year of contract, Transition Technologies PSC just finished realization of five different projects for huge Brazilian aviation concern. Many hours of hard working… During all of this time our specialist have pended almost 27 000 working hours on the best solutions in PLM, including applications like: PTC Windchill and PTC Integrity Lifecycle […]
Let’s get in touch
Contact us