Customization or Configuration
Customization has a number of important implications beyond the cost of employing application programmers to carry it out. Consider batch manufacturing and lot traceability functionality created using a supplier’s application programming environment. Given the complexity of the potential manufacturing workflows, it is possible that the application as developed will not meet the needs of an organization. If that is the case, there are two options: develop the functionality from scratch or modify the existing code to do what it was not originally designed to do. The first option will likely re-create large amounts of existing functionality and will be wasteful and time-consuming. Modifying the standard code would therefore seem more appealing. However, what are the consequences if the supplier issues an upgrade to the system that adds new functionality, fixes known errors, or supports technological changes? At best, the customized code will need to be reworked to support the changes (if that is possible); otherwise the customized code will need to be left as is, risking system obsolescence. Similarly, if the needs of the user change, the code will again need to be reworked, likely by the supplier’s programmers. Not only are there costs associated with this, but any changes in the application code may require that the LIMS be revalidated.
True configuration allows the supplier and users to create screens and workflows that meet their specific needs without having to write or modify any computer code. The standard objects are simply manipulated to produce the desired configuration. This is held within the database and is unaffected by upgrades made by the supplier, as these will only modify the underlying technology layer of the product and functioning of the standard classes and objects. Users can also create completely new functionality if required. New database tables can be created to store specific data, and generic classes and objects allow the data to be managed, manipulated, and seamlessly integrated throughout the system. Changes can be made by the supplier or user as needed.
Most importantly, because the underlying code is unchanged, software revalidation may not be necessary.
How can you tell if your system is, or is going to be, customized? Here are some key indicators:
- Does the supplier refer to its technical consultants as programmers?
- Does the supplier say its configuration tool is similar to C, C#, Visual Basic, or some other programming language?
- When you ask if you can do the configuration yourself, is the answer “Yes, if you have someone who understands computer programming”?
- When you ask for standard functionality to be changed, does the supplier talk about “programming in” the modification?
- When standard functionality is changed, is the original program copied, renamed, and then worked on to prevent future upgrades from overwriting your changes?
- Are upgrades to your system time-consuming and expensive, requiring rework of your changes?
- Is your LIMS outdated? Are workflows not fully supported because your specific functionality cannot be upgraded?
- When new functionality is created for your system, does the supplier start with a blank program file and start writing computer code?
If the answer to one or more of these questions is “yes,” then your system has been customized.
Choosing a system that supports true configuration, which is a great deal more than just turning switches and flags on and off, will help ensure long-term supportability of your system, protect your investment, and ensure that the LIMS can evolve as needs change.