Loading

Check out the Training Zen Webinar

How should one design and build Kronos interfaces?

Kronos Interface Design Strategy

Download the New Kronos Interface Design Strategy White Paper Now!

Subscribe to this Blog

Your email:

About Bryan

Resume Pic of Bryan deSilvaMusician & Yin Style Bagua practitioner. Over twenty years of software implementations and upgrades, project management, systems and applications development experience with a current focus on ADP eTime & Kronos Timekeeper/HR systems implementation. 

Now on Technorati!

Add to Technorati Favorites

The "Kronos Guy" Blog

Current Articles | RSS Feed RSS Feed

The Kronos & PeopleSoft & every other software Change Control Guide

  | Share on Twitter Twitter | Submit to Digg digg it |  Add to delicious  delicious |  Submit to StumbleUpon StumbleUpon |  Share on LinkedIn LinkedIn |  Share On Technorati Technorati | Submit to Reddit reddit 

Upgrading complicated software, such as Kronos and PeopleSoft can be a challenge at best. Typically, this process takes up to six months with many hours of testing, design and development. There are several key elements that every organization needs in order to effectively maintain change control: standardization of customizations, updated documention, standardized testing requirements. Maintaining these requirements helps improve the quality of an upgrade and improved SOX and SAS-70 requirements.

The primary issue with change control is keeping track of customizations vs. delivered code. It is not uncommon for clients of large scale ERP solutions to make changes or customizations to support the uniqueness of their organizations. Keep track of stuffThere are several approaches to keep track of the customization without the use of speciaized software. The first approach is to develop a unique naming standard for custom vs. delivered code, for example, prefixing a unique client identifier with the name of the delivered program.  One example is the delivered program PROG01, customized to C_PROG01. The benefit to this approach is during the upgrade process, the program is easily identified as a delivered program that was customized. Custom programs, written from scratch to support a client need  would have a unique identifier associated with them, such as PAYPROG01 - a totally custom payroll program. Online objects would have similar constraints associated with them. For example, field names such as C_FIELD_NAME would be identified as a totally custom data object, easily identifiable as a custom object. Records, pages, components and other  objects would use the same approach to maintain their integrity.

Once the custom changes are created it becomes imperative to store them separate from non-customized objects. Creating custom object libraries is important to totally keep client written objects separate. This will facilitate the complex upgrade process by total segregation of source, easily identifying the modules that need changed and allowing developers to focus on business critical needs. Customizations can be easily tracked and modified and enhanced where needed. Delivered code is protected during the development process.

The final benefit of using this approach is to focus on a key component of an upgrade - testing. The overall of mantra of an upgrade is to have minimal impact to the end-user, except where new software needs dictate. Search for that Kronos problemTherefore, by segregating source code from delivered to custom allows the testing team to focus on business critical objectives. Custom objects can be easily isolated for a test plan and regression and impact testing can be much more streamlined with objects separated. The overall mantra should be test, test and retest. With the overall impact to focus on testing, a much better product will be realized.

Finally, IT governance has been a challenge in the development arena. Sign-offs, proof of testing and proof of user acceptance are critical for auditors. By effectively controlling the customizations through simple naming standards, it becomes easier for auditors to verify what changes need to be reviewed for Sarbanes-Oxley and SAS-70 requirements. Segregating the objects allows the audit team to identify customizations, verify the test plan and focus on implementing the processes more effectively.

In conclusion, change control is a concept that needs to be practiced to support any upgrade process.  With the complicated number of objects typically associated with large scale ERP solutions, by using an effective naming standard, the testing and development effort can be reduced to business critical processes.

------------------------------------

Jeff Hill PMP, CPP is our newest guest blogger. He's a Senior Consultant for a large PeopleSoft consulting firm responsible for project management and functional implementation of large-scale HRMS & Payroll solutions. He has spent 20 years working with both ERP and MRP solutions for manufacturing, retail and defense industries. IOW, he's a serious PeopleSoft, Payroll, HR guy about whom you can find more on his LinkedIn profile

Comments

I have gotten good knowlege from ths site. But now I have a request. Does any have a simple step by step instructions on how to configure a new work rule by duplicating an existing payrule in 6.0? For example Rest Between Shifts.
Posted @ Tuesday, February 16, 2010 11:01 AM by Rakesh Nair
I'm glad you like the site Rakesh. However I'd like to suggest asking setup questions on Kronos-Fans. Are you a member? It's free peer to peer support at http://tech.groups.yahoo.com/group/kronos-fans/
Posted @ Tuesday, February 16, 2010 2:25 PM by Bryan deSilva
Post Comment
Name
 *
Email
 *
Website (optional)
Comment
 *

Allowed tags: <a> link, <b> bold, <i> italics