LawsonGuru Blog

One of the realities of ERP is that organizations often feel they need to customize to meet their requirements. Customization is a tough choice to make and there really is no good answer. In this article, we’ll examine some of the reasons for customization of your Lawson S3 Applications, why to avoid it, and how to mitigate the risks if you do customize.

Reasons for Customizing

Core competencies. Certainly a valid argument, with an interesting dichotomy. One of the primary reasons an organization implements ERP software is to force them adhere to best practices in their industry. The twist, though, is that if every organization implements the same software, with the same best practices and processes, then there really is nothing that differentiates one organization from another one. This then results in a valid argument for customizing to support and embolden your unique core competencies. Here’s an interesting article on this: http://www.microsoft.com/midsizebusiness/businessvalue/when-and-why-you-should-customize-ERP-software.mspx.

However, one trap which almost every organization falls into is that of customizing—under the false pretense of core competency—when in fact what they are doing is customizing to make their ERP to look and work just like the system it is replacing.

Your other front/back-office systems require it. You likely have other systems which interact with Lawson, and which require data or processes which Lawson doesn’t provide. Luckily, Lawson’s integrated processes will likely replace a number of your current inter-system interfaces. For example, there is no longer a reason to interface timecards to payroll, payroll to Accounts Payable, etc. as these interfaces are included as part of the integration inherent in Lawson. Further, some interfaces are no longer required, because the associated business process is changing in conjunction with the Lawson implementation. Obviously, not all interfaces can be eliminated. So, a strategy is required for developing and deploying the necessary interfaces.

You want additional fields and/or different field sizes. I hear this one a lot, where a client absolutely needs longer address fields, or needs to store additional data related to a master record or transaction. For the most part, Lawson does address the need for additional data elements with Attributes, but they aren’t perfect.

Regulatory requirements. If your ERP is not meeting regulatory requirements, then it’s not a reason to customize—it’s probably time to select a new ERP.

Arguments against Customizing

It comes as no surprise; the primary reason for not customizing is that you lock yourself into a particular version of the ERP software. It is often difficult to isolate and extricate your customizations in order to upgrade. While it’s recommended that you not make superfluous customizations, some customizations are indeed justified. However, installation of a future service pack or patch set (CTP) can become a major event if you have customized your code.

Within the scope of this article, it’s important to distinguish between what I refer to as a customization and a modification. I developed this diagram to help explain that you can often “customize” Lawson with Design Studio and/or User Exits with little or no future impact. However, cloning a program, or even worse, weaving your customizations into the base code should not be undertaken without understanding the business/financial risks that result and weighing the risk against the rewards.

Consider the extreme example of modifying AP20 to meet your unique business requirements. What you are making is a modification to the base Lawson-delivered product. This can have significant impact on your ability to maintain and upgrade Lawson. If your customization also includes modifying the standard Lawson tables, each time you install an MSP you will need to use the Manual installation process–you can no longer use the Automated process.  You also have to be prepared that this change may be undone if any CTP changes the base table (e.g., APVENMAST) and requires a dbreorg.  You would need to intervene before the dbreorg and reapply your table modification. Same applies to version upgrades, like the 8.x -> 9.x Applications upgrade many of you are now undertaking.

Have you ever looked “under the covers” into a Lawson program? Any program can touch any table. While there is some encapsulation and modularity for convenience sake, it’s nowhere close to what it would look like in an object-oriented language. In other words, it’s an ugly world inside that code, and you are going to need some seriously talent developers to correctly implement customizations.

Mitigating the Risk of Customizations
Now, if you really do need to customize, here are some techniques you can use to lessen your future pain:

– Use Shadow tables. If you absolutely must make a table change to accommodate additional fields or longer field sizes (e.g. “longer addresses”), here’s a way you can do it less intrusively (i.e. reducing the risk of getting clobbered by an MSP/CTP).  Create some subordinate tables which are related/joined to the primary tables (e.g., APVENMAST/APVENADDR). Then use some Design Studio form modifications to allow for entry into the longer address tables. Depending on why you’re changing the addresses, you can then create custom reports or clone the various programs (AP155, AP160, etc.) on which you want to present/report the longer addresses.  Using this method will avoid a lot of pain and agony in the future.

– Custom Libraries. Take advantage of Lawson’s common library features (i.e. “pdlib” and “wslib”) and use them to isolate your customized code into your own set of library files and avoid repeating it within a customization.

– Ancillary Tools. Utilize Design Studio and ProcessFlow to accomplish things you might envision requiring a modification.

– Learn the art of retrofitting. Retrofitting your customizations to cloned Lawson programs can be cumbersome and tedious—“ugly grunt work” that simply must be done. Make sure you carefully document your customizations. Make sure you have isolated your customizations to make them easier to apply. Always copy a base Lawson program, and make your customizations to that version, rather than to the base Lawson program. This applies to customized program libraries as well. Read http://www.lawsonguru.com/itemlink.aspx?itemId=144 for some retrofitting guidelines.

– User Exits. Implementing custom logic with User Exits has an added benefit: User Exits, since they are part of the business logic, are invoked regardless of how the form is used: LID, Portal, Excel Add-Ins uploads, ProcessFlow, AGS calls, etc. By contrast, a Design Studio edit would only be applied via Portal. Unfortunately, User Exits only exist for on-line forms, not batch programs.