One of the criteria when selecting a PLM platform (or any other software platform) is often how flexible it is and what kind of customizations that can be made.
First of all one should think of whether the strategy should be to keep to the Out Of The Box (OOTB) solution as much as possible or if your processes are so unique that they give the company such a competitive advantage that it would be dangerous to go with OOTB.
First of all one should think of whether the strategy should be to keep to the Out Of The Box (OOTB) solution as much as possible or if your processes are so unique that they give the company such a competitive advantage that it would be dangerous to go with OOTB.
Of course if you ask the software vendors, the answer will be somewhere along the lines of: “The processes implemented are industry best practices, and we strongly recommend you to follow them. However the platform is highly customizable should you choose to implement special processes”
Such an answer actually gives more questions than answers.
First of all: What industry’s best practices? Keep in mind that most PLM platforms at least originates from aerospace or automotive industry, so make sure core processes are applicable in your industry as well.
Secondly: What is meant by customization? Does it mean additions or changes to the source code of the platform, or does the platform come with tools to easily add modifications or additions to the data model and GUI (Graphical User Interface) of the platform? If the latter is the case, how do you add business logic and behavior to the added data model and GUI?
The answers to such questions have a huge impact on Total Cost of Ownership (TCO) of the platform itself
After spending a lot of years both as solution architect and programmer in PLM projects in multiple industries I’ve learned that there are a lot of different shades of grey hidden in both scenarios.
If customization means additions or changes to source code, that is not necessarily bad provided that a clear and well documented Application Programming Interface (API) exist, and that your organization either have extensive knowledge and experience in the programming language, or have access to a trustworthy and reliable third party who can make the changes.
It then becomes an analysis of:
On the other hand if customization means that some kind of framework or tool exist in order to easily change or add to the data model and GUI you would instinctively assume that this would be preferable.
From a technical point of view I would agree, BUT there are some dangerous pitfalls.
When additions are easy from a technical standpoint it also becomes easy to implement changes without doing the proper analysis work beforehand. The technical implementation cost might be low, but what about the consequences of putting the modifications in production from a business process view? Again how does the modifications impact upgradeability of the platform in the future, and does the modifications impact the rest of the platform?
In both scenarios, pure programming or easy customization, the same questions should be asked and the consequences of the answers should be analyzed before making a decision.
Some points to ponder
Bjorn Fidjeland
The image used in this post is by Bowie15 and purchased at dreamstime.com
Such an answer actually gives more questions than answers.
First of all: What industry’s best practices? Keep in mind that most PLM platforms at least originates from aerospace or automotive industry, so make sure core processes are applicable in your industry as well.
Secondly: What is meant by customization? Does it mean additions or changes to the source code of the platform, or does the platform come with tools to easily add modifications or additions to the data model and GUI (Graphical User Interface) of the platform? If the latter is the case, how do you add business logic and behavior to the added data model and GUI?
The answers to such questions have a huge impact on Total Cost of Ownership (TCO) of the platform itself
After spending a lot of years both as solution architect and programmer in PLM projects in multiple industries I’ve learned that there are a lot of different shades of grey hidden in both scenarios.
If customization means additions or changes to source code, that is not necessarily bad provided that a clear and well documented Application Programming Interface (API) exist, and that your organization either have extensive knowledge and experience in the programming language, or have access to a trustworthy and reliable third party who can make the changes.
It then becomes an analysis of:
- How much do we have to implement to meet our goals
- How will the modifications impact the rest of the solution
- How will the modifications impact the upgradeability of the platform
On the other hand if customization means that some kind of framework or tool exist in order to easily change or add to the data model and GUI you would instinctively assume that this would be preferable.
From a technical point of view I would agree, BUT there are some dangerous pitfalls.
When additions are easy from a technical standpoint it also becomes easy to implement changes without doing the proper analysis work beforehand. The technical implementation cost might be low, but what about the consequences of putting the modifications in production from a business process view? Again how does the modifications impact upgradeability of the platform in the future, and does the modifications impact the rest of the platform?
In both scenarios, pure programming or easy customization, the same questions should be asked and the consequences of the answers should be analyzed before making a decision.
Some points to ponder
Bjorn Fidjeland
The image used in this post is by Bowie15 and purchased at dreamstime.com
RSS Feed
