TUG Buzz! for Wednesday February 26, 2020

IN THIS ISSUE:

1. Set Legacy Applications to Read-only - article by Debbie Gallagher
2. Sneak Preview of March MoM - AI, with speaker: Marija Mijalkovic (IBM)
3. Stay Connected - Confirm your subscription to TUG Buzz

[article] Set Legacy Applications to Read-only

When preparing to go live with a new application, the set up and testing of access to the new application is necessarily part of the work. What is also needed is to prepare a plan for how you will change the legacy application(s) being replaced to read-only.

It's a common enough statement… let's make the old system read-only so users can look things up for a while. But why and how to do that?

The first, most immediate reason to keep the application read-only is to allow users to inquire and run reports so they can validate the data converted to the new system. The next user of the read-only access will be the auditors, either internal or external or both. Whether they log on directly or ask the business to run reports of the data converted, read access will be needed to support the audit.

Over the longer term, the business may require ongoing access to the legacy system for a variety of reasons, which will vary depending on the kind of application it is. For example, regulatory audits, addressing disputes with suppliers or customers.

Businesses generally change the legacy applications to read-only (instead of just continuing with update access) because no matter how much training and communication is provided, if there are more than a few users, someone in the organization will continue to make entries in the old system unless it is specifically prevented.

Start with the requirements
The starting point is to identify requirements for the access changes.  Someone on the project team or in the business will be developing a cutover plan, defining the steps for opening up the new application. Planning for the changes to legacy access needs to be aligned with the cutover plan. For example, if the last Accounts Payable close date will be March 20, the date to stop approving supplier invoices is likely also March 20. 

Where's the read-only switch?
The next step is to identify how to set the specific functions to read-only in the legacy application.  There's generally no read-only switch, and you have to figure out how to do it for your specific application. You'll need to work with the subject matter expert for each legacy application.

Every application will be different and some will be easier than others.  The easiest is when there's a read-only role already established and every user can be re-assigned to that role on the specified date.  Another simple method is to leverage existing application settings that support standard business processes. For example, accounting applications often have a setting to prevent posting to closed months, so if all months are closed, no one can post accounting entries.

Sometimes, especially with ERP systems, users will need their Accounts Receivable, Accounts Payable, Fixed Assets, and General Ledger access changed to read-only on different dates.  In addition, there may be a few corporate accounting folks who need to retain their access for a few weeks longer than divisional accountants.  These kinds of situations often require changes to existing roles, or creation of new roles in the legacy application. If there are a lot of users or roles for which access changes are going to be made, it may be necessary to run script updates instead of changing them manually one-by-one.

Some systems don't really have the kind of flexible roles that exist in ERP systems.  In these cases, making access read-only may require setting an end date on an entity, changing to a different license type, or modifying workflows.

It is common to keep a very few users with admin access so they can continue to add or remove users as needed in the future.

Testing access changes
The amount of testing you need to do will depend on what approach is taken. New roles, script updates, or other approaches will require more testing than assignment of users to existing roles.  Document the testing approach, results, and approvals, and save them for audit.

Controls/approvals
Identify and document approvals needed for execution of the plan. If the plan is approved, are there further sign-offs as each step is executed, or is approval of the plan enough to proceed with all of the steps?

Process for exceptions
What will the process be once changes to read-only are done and there is a business need to continue to execute? For example, if all of the invoice approval workflows have been turned off, and there are invoices that really must be processed. Identify in advance how that situation will be accommodated, and who will approve that change when it is requested.

Service desk
Remember to advise the service desk and user provisioning team of the access changes being made. Provide them with a script for what to tell users who missed the training and didn't read the emails, or who forgot the deadline. You don't want the support team granting update rights to users who are not supposed to have it any more.  

Document the execution
Document any access changes needed for audit, and identify where they are to be stored. Create the documents as you execute the steps, and file them as you go. 

Conclusion
When you implement a new system, it is likely that you need to change access in the legacy system to read-only. This article provided some high-level guidance to get you started. You can modify it to suit your own project's needs.

Copyright 2019 - Debbie Gallagher

Debbie Gallagher is a project manager and business analyst. She can be reached by email at gallagher.debbie@gmail.com. Previous project management articles are archived at http://debbiespmtales.blogspot.ca.

Back To Top

March Meeting of Members

Date: Wednesday March 18, 2020

LOCATION:
Sandman Signature Mississauga Hotel
5400 Dixie Road
Mississauga

** FREE Parking **

Topic:  Artificial Intelligence

Speaker:  Marija Mijalkovic

Marija is IBM's PowerAI expert for North America. She knows AI well and can explain to our members how Toronto is an important hub in the AI community. She is also familiar with IBM i, having been to been to Rochester many times attending the Large Users Group meetings.

Back To Top

Stay Connected with TUG

The Toronto Users Group is committed to providing you with communications that are timely, relevant, and insightful. Canada's Anti-Spam Legislation (CAS) requires that we receive your permission to continue sending you emails.

You may have already given us your consent. If you haven't done so yet, or if you're not sure, please click on the following link to indicate that you would like to continue receiving electronic communications from TUG.

Should you change your mind, you can unsubscribe at any time, by clicking on "manage your subscription" at the bottom of our messages.

Back To Top

Browse our
Articles & Downloads archives
Browse our
TUG Buzz! archives

Browse our
eZine archives