Advertisements

LawsonGuru Blog

Thought-Provoking Commentary for the Lawson Software Community

Customization: Risk vs. Reward


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.

image

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.

Advertisements

6 responses to “Customization: Risk vs. Reward

  1. MTFF October 19, 2008 at 7:54 pm

    To customize or not customize?

    The “usual” justification to customize a COTS package has been “core competencies”, or “we do things differently, which is what makes us better”.

    Before I continue, let me say this first. I personally have benefited from business requirements to customize software, i.e. I have a job. With that said, I am an OPPONENT of customizing COTS. I have 3 of reasons.

    1. Arguments for customizing “we do things differently, which makes us better” are flawed. Professional Photographer and an amateur photographer, both have a Nikon D90 camera, yet, the pictures they take, will come out drastically different. It’s not the “tool”, its how you use it. Software is a tool for us to run our business. I am a firm believer of using the right tool for the right job, with that said, one can argue the COTS is not the right “tool”; therefore, we need to make the tool better. Which leads me to my second reason?

    2. Does anyone know how to measure the benefits of customization? I mean no holds barred, detailed analysis; including the cost of tech staff needed to maintain the code, fix it when there are problems, then, compare that cost to the benefits gained. I am willing to bet, NO ONE. Usually, this is a self-cheating exercise, because the cost/benefit analysis is done by the same people that approved / implemented the project. Unlike golf, which the players are required to be honest and keep their own scores………….

    To have a true competitive advantage over your competitors, you can use the SAME tool better than them by hiring the right people. We see this example everyday in the work place. A task that takes the “right’ person 5 minutes, takes someone else 15.

    3. The best method to keep / retain competitive advantage is to build your own software. By the time you spend the resources on the COTS, you may well have build your own. This also eliminates one other source of waste, un-used modules. I am wiling to bet, the COTS were sold as a “package”, and there are un-used components you paid for.

    Customizing COTS, is the same as taking steroids. What is the ongoing cost to the body? It’s better to exercise and build lasting strength by developing your employees or build your own software.

  2. Phil Simon November 1, 2008 at 11:40 am

    Far be it from me to argue with a guy who uses golf analogies (like I do), but I take a bit of issue with this:

    3. The best method to keep / retain competitive advantage is to build your own software.

    Maybe, maybe not. If the internal resources can’t handle the mod’s, then you’re left scrambling. One Lawson client has so many internal experts that they regularly tweak the code but I would never recommend that unless IT could handle it.

  3. Alex Ladjimi December 1, 2008 at 9:51 am

    I have a very strong feelings with this issue and they are very basic.

    1.) If the product is working properly, ……….

    2.) Look and see if a change in shop methodology is not a more appropriate answer than altering code.

    I always try to explain to my clients that jumping on the code and making changes may not be the answer.

  4. MTFF December 11, 2008 at 11:29 am

    Another reason to avoid custom coding is Technical Debt!

  5. Pingback: Should You Customize Open Source ERP? — Open Source Strategies, Inc.

  6. Joson June 1, 2015 at 5:45 am

    Its all depend upon what it is being used for. If its for a standard business process like trading, procure to product, manufacturing to selling, inventory management, etc. its better to go with the standard software product. You will get best products in the market which was made taking inputs from different people and industry and different working environments. Your business will get benefit from others experience. If you start building your own, you will loose those benefits. Secondly, its very expensive to make your own product and making it run for you. Technology keep changing in every 6 months, if you make your own product, you will loose even that option. For custom-made products, its difficult to change the platform also.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

%d bloggers like this: