Note: This blog post was first published on www.plm-blog.com
Every time you introduce a PLM system, you need to think about what kind of IT infrastructure you really need in the organization? Simply installing the PLM system and making changes after the fact in this productive environment is a very bad idea. And in some regulated industries like the medical device industry, it is not even allowed.
This setup of different environments is not only needed once during the initial introduction. Each PLM system manufacturer delivers new major releases of its software at intervals and sometimes it is necessary to install service packs or hotfixes. And then, of course, there are the most common changes due to user requests, either developed by their own implementation team or made externally by a service provider.
Therefore, when choosing a PLM system, it is worth taking a critical look at these technical and more operational use cases. However, my experience shows that unfortunately not enough attention is paid to it and many are surprised by the cost of operating the PLM system. A PLM system is never really "done" and changes to this system are a common task. And if they follow an agile project management approach, this transfer and change between environments is common daily task.
But which environments need such a PLM implementation now?
The development environment:
As the name suggests, this is the environment in which each developer works and programs separately. Of course, this includes first tests. After these have been successfully completed, the changes to the source code and configuration of the PLM system are transferred to the integration environment.
The integration environment:
In this environment all changes of the individual developers are integrated and can be tested against each other for the first time. Since these integration tests happen every day in an agile environment, a look in the direction of a test automation is worthwhile. In particular, authorizations depending on the roles / group membership and lifecycle status can be tested very well and automated with a reasonable effort for the programming of the test cases. Another important consideration is when and how the shared state of the integration environment is fed back into each development environment. This ensures that all developers programme against the identical configuration.
The test and validation environment:
This environment helps future users to test the implementation of their needs. If you work with external service providers, this environment can also be divided into two instances again. On the one hand, the test environment at your service provider as the last quality assurance instance before handing over a new configuration to the customer. And on the other hand, there is their test environment for performing their user testing and in regulated industries like the medical device industry for performing system validation.
Another special form can still be a "simulated productive environment". Here is not only a small excerpt of your data (documents, CAD models, drawings, ...) available, but a complete copy of your productive data. In this environment, you can then test the performance of your new features under real-world conditions to identify performance issues.
The productive environment
After a successful user test and, if necessary, a validation, your system changes can then be transferred to your production environment.
The training environment
New users of the PLM system must be trained in the application of this. It does not matter whether this happens in classroom training or with new approaches like e-learning. A dedicated environment with generic training identities supports this necessary training.
You can see that a whole series of dedicated environments are needed to ultimately run a productive entity securely, in the best possible quality. This brings me back to my initial problem. You often make changes to the configuration of your PLM system from one environment to another, and the effort involved is a significant part of the cost of ownership. Let's take a closer look at the nature of the data that needs to be transferred here. So far, I have always used only this rather abstract term "configuration" for it.
1) Changes to the PLM system for mapping user requirements
This is common daily task for your PLM administrators and system managers. Such a PLM system is never finished. That is why there are always a number of user requests that need to be implemented. I would like to divide the data, which will be changed, a little bit more:
* Administrative data such as User and associated rights or report templates (e.g., for KPIs based on the PLM data)
* Configuration data, such as new or changed business objects, extensions of the data model, attributes, electronic workflows, roles and permissions, ...
* Extensions and adjustments through individual programming
* PLM data, such as Documents, Parts, Requirements, Specifications, ...
Depending on the application, this data must be easily, quickly and completely transferred to another environment. It is not always the case that all data must always be transferred completely. A nice example of this are users. I hardly believe that the generic users from your development environments should find themselves in their productive environment. That would be rather strange, especially if the productive users are actually fed from an AD or LDAP. But this may be different when updating the training system. There, it would be helpful to be able to automatically transfer generic users and not have to "click" them by hand.
2) New major releases of your PLM system manufacturer
Each PLM system manufacturer continues to issue new releases of its software at regular intervals. Of course, you want to benefit from these new features, so it's important to understand how these new PLM system versions can be brought into their environments. Here, not only the configuration of your system changes, but also the entire basis on which its configuration is based. You need to have a thorough understanding of the strategies and tools your PLM system manufacturer offers to help upgrade your system. For example:
- How do you handle the adjustments you make to the system when you import a new software release?
- What happens to your data? You may even need to migrate data to the new environment because the data model changes
A good idea is to listen in to the appropriate user communities and share experiences with other users.
3) Hotfixes and service packs of your PLM system
Error-free software does not exist, and thus even the most careful quality assurance makes it slip into the software releases. This can not be prevented with reasonable effort. How does the manufacturer of your system react to these errors? When does he deliver hotfixes and service packs? And they need to look at how to get these hotfixes and service packs into their environments. This resembles the challenges that you have to overcome in new major releases.
And last but not least, some manufacturers still have to consider that they need to buy licenses. But how generous is the regulation for the more generic users for your development, integration, and validation environments?
This brings me to the end of this rather technical article. I hope you found the article useful. If you have any comments, please contact me at firstname.lastname@example.org