How to keep up with the need to update and patch?

Are you patching to fix a problem or just putting on new patches that Lawson releases?

I think most folks patch to fix an issue that has been identified by the user community. They are not proactively patching just to stay current.

Yes, if it's not broken or becoming un-supported, we don't patch/update. I forgot to mention we also have the new contract module, and it seems to have patches almost weekly.

The users get the weekly CTP list and request the ones they feel they need.

But it's also all the different modules we have and each one has it's own Product updtates, and they are only support for so long, so we try to stay just one release back.

And then there's Websphere, we have 14 instances on 14 different Servers (PROD, TEST and DEV), most need a new Fix Pack, LBI is having issues, so we need to go to a newer version...it just seems endless...

Rory, who decided to give the CTP list to the users? Maybe it's too late to go back but I would think that list would be a bit overwhelming and even frightening to users (even super users). Only IT gets that list here and we review it and test out CTPs that seem important to us but normally we do not apply a CTP or any patch unless the users report an issue or we need to roll out new functionality. I've had CTPs break other functionality so I tend to be cautious when putting them in and try to stay pretty far behind their current versions. You are very brave!

The list only goes to each department lead, who has been on the project from day 1. Each CTP is loaded to 1 of 4 TEST PDL's and not until approved by all Leads does it go to PROD.

The bigger issue is all the 'Products' and their versions, and for many issues that comes up, GSC recommends we get on a newer version or patch of something.

We've had issues with Sourcing, and GSC recommeds we move to 9.0.2.x, and then we find that requires Websphere 7.0, and JAVA sdk 1.6 and 4 App CTP's and......

I agree. I tend to believe Lawson is moving too fast. I no sooner patch something then have to patch it again because it broke something else. Obvious things too like negative signs missing in portal. Yeah right, why does a financial system need negative signs? We don't have the staff we once had in this economy so we have no choice but to slow things way down and test everything to avoid major problems in production. But slowing things down has a cost too. We are constantly at odds with Lawson because we are behind and they want us to just apply updates to fix things.

I have no practical solution. The two are at odds. Fast moving poorly tested software updates and decommision strategies do not fit into the real world.

 

 

Exactly right on target! We have a long-standing process that will run a full up system and process test on the part of all areas that use Lawson.  CTP's are only reviewed when an issue by a user cannot be resolved locally - and then the CTP(s) that may or may not fix the issue is fully tested prior to implementation. 

We also have the same issue with Lawson on the continued support for what they term 'legacy' programs - when in reality, their original concept of no db changes unless it is a version change - went out of the window years ago.  Now, we will see db changes on the occasional CTP - and definitely on the MSPs that are fielded.  Add IBM to that mix and we have job security!

 

What does everyone do with WebSphere fix packs? We're at 6.1.0.19 and the latest Windows version is 6.1.0.27.

Interesting topic that I think we all have to deal with. Sharing the patch list with general users could be quite overwhelming. I find that the majority of the patches have nothing to do with features we use. (Canada or a state we do not do business in...) We do CTP's as needed to fix issues, year-end patches annually, ESP/MSP's every other year, and full upgrade reviews every 3 years. We just started doing this because we were getting tired of the upgrade/patch treadmill. We have quite a few self-service customizations so we have to plan ahead before installing environment patches. Seems to be working for us.

My biggest concern lately is that the ESP/MSP's patches and upgrades for the HR/Payroll/Benefits system have not really offered any new features - in fact, most of the changes have been decommissions ... The enhancements seem to only be offered if you want to buy new products like smart office, smart notes, absence management, process flow integrator, etc.

We only review and test the WAS if and when needed.  Recently, we had some issues with the 6.1.0.23 - and went up to 6.1.0.27 in order to work around the problem.  So far, it is quite stable for 3k users.  At this point, we are also looking at 7.x.x on our upgrade area (64 bit) - and it appears to be fairly stable so far.

 

 

Does anyone have a really outstanding Change Management process? We manually track changed programs (custom) and fully document the changes in the PD; however, on occasion, we may have multiple changes that are required due to either local or national requirements - and end up with more than 1 programmer working on the effort. When it goes into testing, the delay may end up causing issues with a quarterly CTP, etc. Just looking for ideas! Thanks!

What we have recently implemented is to patch as needed. Once a CTP is identified by our users as one that is needed, we will run the patch preview on the fix, this provides the programs that are updated. Even though a program may compile 800 programs it may only change the code on 20 actual forms. We compile that list and send it to the appropriate users to test, sign off, and then we move to PROD. We have a formal change control process for every change that is documented in our IT ticket solution.

The ESP's and MSP's are scheduled as needed. We try to keep within the stated support level of two back from current. We have a monthly downtime window to install any CTP's, MSP's, ESP's or Self Service application changes.

This has made the patch applications much smoother, in the past we in IT would install a CTP to fix an AP issue and it would break RSS or some other program. We were loosing credibility with our users so we moved to this process and it has made a world of difference. It puts more work on our group up front.

We follow a very similar process at Allina and it works well. We are also going to build a new environment where every CTP will be applied. This environment will be test only with no plans of migrating said CTP's to production.

The idea is to have a place where we can test issues using our current data to determine if Lawson already has an existing fix for a problem. That way, we won't have to apply that CTP that gets us current in the event that Lawson cannot replicate. We will know right away if they have a fix. If we find that the issue is fixed we can run a diff against what we have in prod. We should than be able to identify the CTP that will fix. We will have our choice of applying either the oldest or newest CTP that would fix the problem. I'm not sure which we will choose. There are pros and cons to each.

We've done exactly that over the past period of time since Lawson got rid of the paper chase! We rebuild a product line (copy of production) for our development group and build a separate CTP product line at the same time on our development machine (same environment - different pl) and only use LID to perform our initial review. If that works, then we bring it into development, followed by an install into test if the programs are not failing on DEV and DEV - Portal. If it touches existing custom programs, our development folks run a diff for changes and/or re-incorporate changes for local use. The major problem arises when there are multiple CTPs (year end AP and HR/PR) or upgrade related actions.

We are in the initial stages of building a new environment that we could keep in line with PROD. Once completed it will have period updates of data, and will be the last test before a move to PROD.