Windchill is a PTC PLM product, which is highly flexible and configurable application. 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.

How System is called :
1. OOTB

2. Configured

3. Customized

OOTB : Often termed as Out-of-the-box, i.e 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:

• Standard user interface, with browsing and searching capabilities

• Data model (object types, their attributes/parameters)

• Lifecycles

• Workflows

• Object templates (including Product templates, complete with role and security definition)

These are created based on some industry standards and established best practices. well defined by Creator ,PTC .

In case of any 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 is needed to achieve desired process and business goals.

Configuration :
Any changes you can do the product from UI perspective, ex: Defining new Model , User defnied attribute creation , Defining rules, Access Control , Defining business speccific Processes , creating new UX etc .

Configuration is a system modification that does not require access, modification, implementation, etc. of the system’s source code. This is also considered as the ability to configure the software (and thus configuration itself) to be an integral part of OOTB functionality. Configurations are usually supported between system Versions and not impacted by system Upgrade and Updated. They can be exported from System ( as XML or any supported format) and imported again to new or upgraded system .

Customization :

Sometimes the required business process needs specific changes to the OOTB Code and can't be achieved by Configuration . Here i calls for a system change which requires modification or extension of the system’s source code (i.e. implementation, development). Some exapmles:

• Listeners (triggers that fire a certain action/system behavior when a given event happens, for example auto-publishing on Change Notice completion, etc.)

• New user actions and wizards

• Workflows (some cases) – Windchill allows you to write code, so when you want to do some custom processing while running your workflow, you can

• System integrations – I’m sorry to say, but almost all system integrations for PLM are custom

• Some cases of advanced business reporting

• Various implementations of additional business rules

and list is never ending . However, the thumbrule is to first establish the business usecase with OOTB --> if not attained , configure ---> if not supported, go for Customization .

Unlike Configurations, Customization needs special attention and effort evaluation for checking compatibility while migration/upgrade .

How should I manage customizations?

Software Development and System Operations, DevOps, can be quite a complex topic – also for Product Lifecycle Management systems.

• Use a version control system for your source code (ideally Git or equivalent)

• Use a system like JIRA , ADO or PTC Windchill RV&S (former Integrity, as an Application Lifecycle Management [ALM] system) to track development progress, tasks, issues, user stories, sprints, etc.

• Tightly integrate the two above so that no one can change anything in the repository if he’s not working on a specific ticket.

• Use automated tests for any custom code (at minimum unit tests).

• Use automated environment creation (if possible – greatly simplifies and decreases effort and time) and build deployment tools like Jenkins.

• Tightly integrate automation tools with tests, source code and the ALM system.

• Use multiple validation environments (for example: programmers code in a Dev system, testers test on a Test system, final user acceptance testing is done on a QA system – and finally, nothing is changed on production, unless part of an official release schedule, tracked, managed and validated)

In that case configuration, once exported from the development system, should also be managed as part of the process above – ing Customizatthis will ensure an entire system deployment is coherent and smooth, and any and all issues are detected and resolved at an early phase.

Managing customization:

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. System upgrades, changes the core code of the system which was customized .

Vendors are releasing new system versions frequently tahn ever. However, this is typically a call from Business, what is suitable for them . These decisions should be relying on ,

• What are existing issues in current implementation

• Demanding market needs an improvement is system which is no longer be supported

• Vendor's support model for there existing PLM in business.

• Upgrading or moving, will add add up any revenue growth for longterm company goals .

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.