“Product Lifecycle Management” (PLM), enables one tomanage all aspects of the product development life cycle, from concept through service and retirement. It’s a structuring project that directly effects company issues. However, the criticality is intensified by a PLM.
The objective of the “TPAM PLM” (Third Party Application Maintenance PLM), is to maintain the application operational, stabilizing it, making it evolve along the needs of its new users or new functionalities. It also has make evolve the COTS (off-the-shelf software package) on which it’s based. And at the same time, taking into consideration the sensitivity of applications that manage critical client data (production of an airplane structure, a motor, a car), and with an important number of users.
The key to success of a “TPAM PLM” resides, at the very start of a PLM project, in the transitioning but not only. The upgradability is essential, and the added value of the TPAM comes from the adaptive part of the project, on the preventive side or for demand. The TPAM being a sensitive subject, these are five rules to follow to be a “good TPAMist”.
Transition: do not minimize it!
For the implementation of tools, infrastructure, or processes (governance, management, indicators) and, of course, for the acquisition of technical and functional knowledge of the application, transition is the key stone of a future TPAM.
A poorly done transition leads systematically to difficulties, and even failures in the operational maintenance of the application.
Perimeters: achieve and anticipate upgradability
The TPAM touches different services with an important part in corrective and management of data or usage incidents, of glitch correction, of interfacing with solution editors COTS PLM (PTC, Dassault, Siemens especially) to implement editor patches at the final customers’.
The upgradable part is key. The functional perimeter and the user perimeter are often led to evolve quite largely. These upgradable applications usually come from the final customers’. Also, the TPAMist must respond the client’s new needs, without forgetting to anticipate and propose solutions to recurrent incidents.
Documentation: do not neglect it!
It’s a prime element to assure the TPAM. It’s a bit like the history of the project is told throughout documentation. The key tool kits of documentation, of requirements and of software configuration, initialized throughout the transition, enable the delivery of all catalogue services proposed in the specifications. It is sometimes (and often) the weakness of projects (according to the quality requirements of the final client): documentation isn’t always up to date and lacks of traceability.
Status of the solution
Three key factors need to be considered: the maturity, the stability and the performances.
The maturity of an application is measured by the number of incidents upon the application, if we are in the targeted usage conditions (number of users and functional parameter notably).
The stability depends on the quantity of upgrades and corrections to do on the application.
The status performances of the PLM performances are also very important. Indeed, the COTS PLM, in order to respond to client’s needs, undertake more or less important customizations (from the specific code to deflect or bypass certain functionalities of the standard and respond to the client). It’s when we can rapidly face application usage problems.
The capacity of a TPAMist to intervene upon any type of problem, technical, functional or linked to performance, resides mostly in its resources, its experience feedbacks and the handling of monitoring tools.
Overall, the more the application is mature, stable and performant, the easier it is to operate the TPAM.