When the phone rang at three in the night (or was it already morning*, long days at work incapacitates the brain for sure!) Bernard said to himself, 'Oh God, not again'. The ring tone ('alarm' would be a better term!) was distinctive, slowly rising in pitch from a sweet whisper to an ear piercing shrilling - it was the support phone crying to be attended to. Bernard reached out for the phone and he was right, it was the IT helpdesk calling. 'Hello, this is Bernard from PeopleSoft support team. May I know who is on line?'
'Hi Bernard, this is Anand from IT Helpdesk. We have received around eight incidents in the last one hour saying that employees are not able to apply for leave. When they try to click on the forecast button, they are getting the error message 17000,483. As this is preventing a large number of employees from applying leave, David has authorised this to be a Priority 2 ticket. Could you take a look? I will call back in 30 minutes for an update'.
'Ok. Sure Anand. Please pass on the incident numbers to me with the exact error details reported by the employees'.
Bernard analyzed all the reported incidents and noticed that in all cases employees were trying to apply retroactive leaves. He knew that there were no issues with the retro setup in Absence Management and was perplexed about this issue. As he had the error number, he quickly logged into Oracle metalink to gather more details about the error. 'There you go, another product bug fixed in a future bundle!', Bernard sighed. This was not the first time that such an issue had come up, they had not applied bundles for the last one year and a number of critical issues were finally nailed down to being part of one or the other bundle. It was not that the project manager was complacent on the need to apply bundles, but the cost and effort concerns always reigned in. The story goes on that Bernard was able to downgrade the severity of the ticket and later got the DBA to apply the specific fix for this issue. This incident went in as yet another entry into the 'business case' for a bundle upgrade. Last heard, the customer realised that it is better for them to upgrade to the latest version of the product, rather than apply close to 20 outstanding bundles!
Couple of weeks back, there was a very interesting discussion on ITToolbox regarding the best practices on applying bundles and maintenance packs. Even though staying current on bundles and patches is the ideal scenario, practical considerations make it a very difficult state to be in. For shops that have a small PeopleSoft team, supporting multiple applications and in times of stringent HR IT spending, spending effort and money to stay current on bundles is not always a top choice. Organizations would rather spend on new projects with tangible business impact.
But a careful analysis of the bundle fixes will show that a number of critical issues are often fixed in these releases, so completely ignoring bundles and adopting the strategy of 'don't fix it if it's not broken' can turn out to be counter-productive.
Thus, I would advocate a middle path of proactive analysis and selective application. The steps in this approach is illustrated below:
1. Proactively analyse bundles for fixes that are relevant to the customer as soon as they are released. This first step is very important because it will immediately bring to light potential issues in the system that have either been not identified or have been identified but not resolved. This activity of proactive bundle analysis for relevant fixes will surely help the customer pre-empt some of the issues before they arise and is thus a very powerful support tool.
2. Try to replicate the relevant bugs in the customer's environment. This is to confirm that the issue as reported by the bug exists in the customer's environment also. A number of times I have found that this kind of an analysis brings forth issues which were never identified in the system and has helped to fix them before they arose.
3. Rank the fixes in terms of business impact. It's a no-brainer that bugs with maximum impact has to be taken on priority and fixed and this process should help to come out with the priority list.
4. Debate the possibility of a work around vs. applying the fix. There could be certain scenarios where the effort of applying a fix provided by Oracle is very high and a customized work around could be put in place with lesser effort. This can typically happen in environments where certain parts of the application has been heavily customized and high degree of retrofitting is required to apply a fix provided by Oracle. In these cases, a decision has to be made whether it is better to put in a customized work around or the Oracle provided fix.
5. The final step in the process would be to extract the specific fixes from the bundle release and selectively apply them in the customer's environment.
I believe that the above is a very effective strategy that can be adopted effectively by PeopleSoft support projects. While the cost of applying entire bundles can be very high, the cost of not being aware of the bugs fixed by bundles and waking up to critical system issues can be equally damaging (especially when it affects time and pay. I know of organizations that have lost thousands of dollars in terms of payroll overpayments due to bugs in Time and Labor/Absence Management!). This process of proactive bundle analysis has to be an integral part of every PeopleSoft support process, to the extent that I would advocate measuring the compliance to this activity.
*At the heights of it's colonial powers, Britain was referred to as the 'Empire on which the sun never sets'. This would be an accurate reference to the Indian IT companies of the current era. With work and support being provided round the clock, the sun indeed doesn't set for these companies.
No comments:
Post a Comment