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.

Retiring applications

A frequently-neglected part of the plan for implementation of a new application is the retirement of the one that is being replaced.

However, there is good reason to do that work at the same time as your new project, as there are risks and costs related to keeping an old system running after it is no longer actively used.

Why decommission

The most obvious concern with maintaining applications that are no longer used is the cost of licensing and support agreements. There are also less obvious costs. For example, you may be running certain hardware or operating systems for the sole purpose of maintaining the legacy applications. You may also pay consultants with legacy expertise to maintain that legacy hardware and software. Perhaps it is no longer feasible to apply some types of security to older systems.

Here is an approach to consider and tailor to your own application and organization.

Business ownership

Although managed by IT, there must be a business owner who will participate in retirement planning and approve any decisions that are relevant to the business.

Contracts

Unless the application being retired is fully home-grown, you likely have some contracts in place. For example, application licenses for users and administrators, and support agreements. The infrastructure or security support may also be covered by service contracts. Review all of the relevant contracts and determine what your rights and responsibilities are. E.g. if users are not maintaining any data, but are read-only, do you still have to pay? What is the notice period, and when is the deadline to give notice? Are your responsibilities truly clear in the contract, or do you need a lawyer to review it?

Continuing access to the data

Depending on the business use of the application, it may be necessary to keep the data for some period of time. Start by identifying the data that is kept in the system. Is it general ledger, purchase orders, energy usage? Also identify whether the application is the system of record for that data. If the application is just for reporting or transmitting, and the system of record is somewhere else, it may much easier to eliminate the application’s data set.

If the application is the system of record, map the data sets in the system to the corporate data retention policy. This policy will have been developed in alignment with compliance, legal, and regulatory requirements. Then, discuss with the business owner what their business needs are for ongoing access to the data. This may be different from the corporate data retention policy.

While you’re having that discussion with the business, find out what kind of access to the data is going to be needed. Do they still need to use the application to view the data, or will it be enough to be able to query the database?

Also ask the business owner how many users should have continuing access to the application. Perhaps you can reduce the number of users to just a few, either right away, or after a year or so.

If the application being retired is on some technology that you no longer use for any other applications, it may be tempting to copy the database to a technology that you support as a standard. However, this may not provide what the business needs. If the data structure is complex, you may no longer have an employee with the experience to query that structure and get the right answer. In addition, if there is a need to re-generate reports or documents, it may not be feasible to do so without the application.

Operations

Perhaps based on either the retention policy, or the business needs, you have learned that the application is still needed for inquiry and reporting for several years. There still may be steps you can take to reduce the effort of operating the application.

For example, since the data isn’t changing, it may not be necessary to do daily backups or manage high availability. Perhaps the business would now be fine with a monthly backup, so you have fresh media. Maybe the business would agree with a longer recovery in the event of failure.

It’s also likely that you could eliminate the development and testing environments for the retiring application.

Security and controls

You can also examine the security and controls for the retiring application. For example, discuss with the business whether they still require two-factor authentication.

It’s also a good time to discuss whether the controls for the application and its supporting infrastructure should be tested any more as part of the audit. Some of the testing may no longer be needed, which could reduce the effort of internal or external auditors.

Other considerations

If you are generally moving applications to the cloud, or no longer wish to support the particular technology platform of the retiring application in your data centre, you may consider options to have someone else manage it for you. There are usually vendors who would agree to host the hardware and application in their own data centre. Note that this approach requires considerable planning, and you should engage the potential vendor early to discuss requirements.

Conclusion

When you implement a new system, planning for the retirement of the old one should be planned at the same time. It should be possible to manage costs and risks by appropriate planning and execution.

This article provided some high-level guidance on retirement planning to get you started. You can use it as a framework, and customize it to your own organization’s needs

The changing role of the technology team in ERP implementations (part 3)

In two previous articles, I described several areas where the role of the technology team in ERP implementations has changed in the last ten to twenty years.  Here is part 3, the final installment.

Single sign on

This capability makes life much easier for the end user. Although it is easier to implement than it used to be, it still requires set up, testing, and support by the technology team.

 

Disaster recovery

In a cloud environment, you won’t be managing databases and servers any more. The scenario where your entire data centre collapsed and you lost all your systems at once will change to multiple application-based or vendor-based scenarios. You need to re-think what disaster recovery planning and testing should cover. You also need to verify that participation in disaster recovery planning and testing exists in your contracts with cloud vendors.

IT controls

If you’ve been outsourcing some of your IT functions already, you’re familiar with this. Although your organization is responsible to ensure IT controls are operating effectively, many of those controls will now be implemented and operated by your cloud vendors. Relevant IT controls will need to be reviewed internally and with the vendors to identify if any controls need to be re-designed, and how they will be tested. Selection of your ERP system and negotiation of the contract needs to consider IT controls and associated Service Organization Control (SOC) reporting requirements.

Application support model

With ERP in the cloud, the internal support team no longer needs to be heavily weighted toward database analysis, operating system, and hardware experience. Instead, the team’s focus will be on the business process, how the application supports the business process, and reporting and data governance. This is a significant shift in mindset and skills for many IT support managers and staff.

If the existing ERP is supported by manual processes, your business users will certainly want to automate more when the new ERP is implemented. E.g. on-line workflow to replace email approvals. As a result, the number of ERP users you support is likely to be higher than it is today.

Vendor management

Given the number of areas where your IT organization now relies on vendors (ERP, integration, disaster recovery, IT controls), it is evident that a key responsibility and skill set in your operational support model is vendor management. This may be an area in which your team requires bolstering if you have not been outsourcing or using cloud very much to date.

Conclusion

Technology is so ingrained in business processes today that there’s no such thing as a fully manual business process any more.  Having the business define the new processes and handing off requirements to the technology team is not a workable process. Business analysts have to participate fully in the business process workshops, identifying requirements along the way for everything from mobile device needs to interface and data conversion requirements.

In addition, your technology team for the ERP project, whether internally available or contracted, needs to support a wide variety of requirements that didn’t often exist two decades ago: mobile technology, browsers, firewalls, single sign on. In addition, the approaches to disaster recovery, IT controls, and application support likely need to change.

As you can see from this article and the previous two, the role of the technology team in ERP implementations has changed significantly. So, if you are implementing ERP soon, and it’s been ten or twenty years since you did so, you should anticipate and plan for all or most of these differences.

The changing role of the technology team in ERP implementations (part 2)

In a previous article, I described several areas where the role of the technology team in ERP implementations has changed in the last ten to twenty years.  Here is part 2.

Importance of data

ERP and other application implementers have historically considered focus on People, Process, and Technology as the foundation for success. In the last several years, it has become apparent that Data is a fourth and equally important element.

Data, including its definition, conversion, integration, and governance have become critical to the success of the implementation and the ongoing usability of the ERP system. Although the data is owned by the business, they generally require support from the technology team in supporting data governance and enforcement of data standards.

Downstream systems

Due to changes in master data or the business meaning of data when you implement a new ERP, combined with the integrations, you may have many changes to data in applications you connect to/from.

One of the causes will be data re-numbering. For example, if you change significant master data such as customer number, vendor number, or part number, you will likely have a business requirement to update existing data in other systems besides the ERP.

In addition, when implementing ERP, the business may take the opportunity to change the meaning of the data. For example, the existing ERP may have Acme Toronto, Acme Vancouver, and Acme Calgary all set up as separate vendors. In the new ERP, the business may choose to eliminate these three vendors and instead create a vendor called Acme Canada with three sites in Toronto, Vancouver, and Calgary. You can see that this would have an impact on the way that integrations to/from other applications are designed; and the potential for changes to existing data in those systems.

Data cleansing

Data often requires cleansing in order to accommodate a new ERP. In addition to correction of issues with existing data, the business may want to develop data for the ERP that exists only in spreadsheets today. The technology team is often called upon to support data assessment and may also need to provide tools and processes to support data creation and standardization. 

Workflow

Workflow can enforce controls and retain documentation of approvals, and is built into modern ERPs. In a cloud environment, the notification emails will be crossing multiple corporate firewalls. Similarly, if you are using your ERP host or another external party to provide integrated services such as invoice scanning, there will be technology-enabled processes crossing internal and external environments. Your technology team will need to be involved in the security design and implementation.

Customizations

If your existing ERP system is customized, you know what a challenge it is to keep up with upgrades, as modifications need to be re-established with each upgrade. With cloud ERP, it is easier to push back on the business when they want to customize, as cloud lends itself to adherence to the vendor’s standard offerings. However, where there is a real business need, you may need to develop the customization outside of the ERP, leading to another system and interface to manage, and the necessity of supporting business questions on differences between the two systems.

System cutover

Along with the transition of business functions to the new application and processes, there will be a number of technical steps involved as well. Cutover tasks may include turning off/on interfaces and scheduled jobs, and providing updated charts of accounts and other master data (e.g. customer numbers) to other systems and business partners. It is also common to prevent data updates in legacy applications by modifying user roles when the new ERP goes live.

Stay tuned

There is more to cover on the changing role of the technology team in ERP implementation. Watch for part 3.

The changing role of the technology team in ERP implementations (part 1)

Companies change their Enterprise Resource Planning (ERP) systems infrequently, only every ten to twenty years. If your ERP no longer meets your business needs and you are thinking of its replacement, here is a summary of how your technology team will be involved in ways that may not have applied the last time around.

The technology team has always had a role in the selection of the ERP, evaluating the vendor’s technology solution and direction. The technology team also set up the on-premise system, extracted and transformed data for loading to the new ERP, and trained a support team.  Depending on how long ago the ERP was implemented, and the company’s industry, they may have built some interfaces.  

It’s tempting to think that the world of cloud solutions is easier for the technology team during the ERP implementation project. It isn’t so. Here are some of the changes to think about when you are scoping and planning your new ERP implementation project.

Mobile technology

ERPs now have mobile features, such as approvals on mobile phones, and reporting on tablets. In the implementation project, you’ll have to test operability with all of the device types and operating systems that you support. You also may need to support multiple browsers to handle your new ERP at the same time as any remaining legacy systems. You may also have concerns about security if mobile devices are lost, or need to figure out how to implement dual factor authentication for these.

Integration

Integration between systems used to be a nice-to-have. Now integration is a must-have. The business relies on automated interfaces to communicate with customers, vendors, banks, and business partners.

Interfaces to/from the existing ERP may have been built over time with a variety of tools and approaches. When implementing a new ERP, you will need to re-develop all of those that connect with the ERP. If you plan to select a new integration tool or define a new approach, this is the time to do it. As a result, you need to factor in time, money, and expertise for selection, purchase, and training your team on the new toolset.

With some of your applications, and possibly also your integration tool, in the cloud, the development, testing, and promotion to production of the integrations requires access to multiple environments in a variety of public and private cloud environments. The external parties with whom you exchange data may also have cloud applications. Engaging the internal and external parties and their cloud providers and working with all of them to achieve a common go-live date is a significant coordination effort.

Reporting

ERP is an important source of data for company reporting. With implementation of a new ERP, the data model of that source data is changing, which will require you to re-build data feeds to your reporting platform. The standard reports in the new ERP will also be different from the existing one. As a result, this is a good time to re-evaluate reporting requirements and perhaps replace that application or the mechanism by which it receives its data. As with integration tool replacement, this requires selection, purchasing, and training staff.

Business-managed systems

Cloud has made it easy for the business to implement solutions that IT is not aware of. Many of these applications will be affected by the ERP implementation (integration, data changes, process impact). Although it is the responsibility of the business to identify these situations, they will need support from the technology team to assess impacts and identify how to integrate these solutions into their new processes.

Stay tuned

There is more to cover on the changing role of the technology team in ERP implementation. Watch for part 2 

Project risk case study: Scarce resource management

Technology projects are heavily dependent on expert resources from the IT team and the business. Managing people whose work is critical to the success of the project is essential and managing their time can be challenging.

This case study is a situation where a business expert was proving to be unable to deliver to the timeline.

Case study

The project was development of custom reports. When engaging resources for the work, the project manager did the usual things to ensure availability of the resource: for example, arranged for dedicated team members, and obtained commitments from their managers that they would be free to concentrate on the project. For those who were not vendors, the project manager arranged for the individuals’ jobs to be filled by other workers so the project team could concentrate on the project work.

The situation

The development work proceeded but there were challenges and issues along the way (perhaps a case study for another time).  Due to the development issues, there were quite a large number of problems found in the testing phase. 

However, just as problematic, it was taking a very long time for the business expert doing the testing to identify the issues on the reports, and to re-test as defects were corrected.  As time went on, it became clear that the tester was a significant bottleneck in the process.

The project manager discussed the pace with the tester, who confirmed that he was concentrating on the testing tasks, and had not been pulled away to work on other non-project work. The tester claimed that it was just a temporary delay due to learning curve on what needed to be done, and that he would have no problem catching up.

Unfortunately, the tester’s prediction of increasing speed did not come true. The testing continued to take much longer than planned.  In addition, the tester claimed, and his manager agreed, that no one but himself was qualified to examine the reports and determine whether they were right or wrong.

Evaluation of the problem

The project manager decided to see for herself what was causing the delay, so she arranged to sit in the tester’s office while he worked. She did some other work, but by sitting close by was able to observe the tester’s process.

What she observed was that there were many time-consuming steps to complete the tester’s work.  He printed the legacy report; then printed the new report. Then, he went through every line and checked every heading, description, and number for accuracy.  Then, when he found a difference between the legacy and new report, he had to determine whether the difference was acceptable. If it was not acceptable, he had to log the defect in the tracking software.

The project manager realized that much of the work could actually be done by others. The only part of the work that the business expert tester really had to do for himself was to evaluate whether a difference was acceptable or not.

New approach

The project manager arranged to add two junior staff to the project. They were assigned to print the legacy and new reports, compare every heading, description, and number, and mark differences with highlighters and tape flags for review. 

The business expert was now able to focus on the one thing that no one but himself could do. He focused on evaluation of the differences between the legacy and new reports, and decided whether the difference was acceptable or a defect.

The project manager also arranged for someone else to log the defects for the tester, so he could concentrate on just the evaluation.

Conclusion

The project manager’s observation was essential to resolving the work bottleneck. Each report was taking two to four hours to test, but the portion that only the business expert could do was really only fifteen to thirty minutes.

By re-allocating much of the work to other resources, the business expert was freed up to complete the evaluation for many more reports.

Although their participation is critical to a project’s success, business experts can become a bottleneck on a project. In order to ensure the proper participation of the expert while also eliminating the bottleneck, it was necessary for the project manager to evaluate the work and break it down into its component parts. Then many of the steps could be completed by others, freeing up the expert to focus on the task for which he had the expertise.

Introduction to IT Project Risk

While working on a variety of IT projects, I’ve seen several project charters and risk registers. Over time, I’ve noticed that not all project managers have a solid grasp of how to identify and mitigate project risk. So, here’s an introduction to the subject.

These aren’t project risks

Perhaps it seems an odd place to start, but the most common problem I see is that many risks identified aren’t really risks.  So, what is not a project risk?

An issue is not a project risk.  An issue is something that is already a problem for the project. E.g. a risk item that states: Vendor is late delivering components. Since the vendor is already late, or you already know the delivery is going to be late, this is an issue, not a risk. A risk is something that could happen, but hasn’t happened yet.

An outcome is not a project risk. E.g. a risk item that states: The project might not go live on time. This statement is an outcome of one or more events that could happen, for which the outcome is that there could be an impact on the project timeline. A risk is the thing that might cause the project to go late or cost more, etc.

Also, a vaguely-defined concern isn’t a risk. Risks aren’t really properly identified if they are not specific. E.g. a risk item that states: Testing is a risk. This statement is too vague, as it doesn’t say what specifically about testing is a risk and why it is being identified.

These aren’t mitigation plans

In addition to incorrectly identified risks, I often see vague mitigation plans. E.g. Manage dependencies and milestones. E.g. Leverage vendor’s experience. These mitigation plans are too vague to be actionable.

What are we worried about? What will we do about it?

Every book on project management has a risk definition along the lines of “Project risk is an uncertain event or condition that, if it occurs, has a positive or negative effect on one or more project objectives such as scope, schedule, cost, and quality.” (PMBOK, Fifth Edition). Following that, there’s a definition of risk mitigation, such as: “Risk mitigation is a risk response strategy whereby the project team acts to reduce the probability of occurrence or impact of a risk.” (PMBOK, Fifth Edition)

Although accurate, these definitions can be simplified to aid understanding. The easiest way to identify risks is to ask yourself and others: What exactly are we worried about and why are we worried about it?

Then, once the worry and rationale are very clearly defined, the mitigation plan is based on:  What very specific actions are we going to take regarding that worry?

An example

Do you have reason to believe the vendor might deliver late – before it happens? For example, maybe the vendor has recently made a lot more sales than usual and you’ve had late deliveries when you’ve bought from other fast-growing vendors. If so, you can record the risk very clearly: Vendor has gained significant market share in the last three months. Based on our experience with other vendors, this market gain can have an impact on manufacturing capacity, which may result in late delivery.

If you want to avoid this event, think about what options you have to avoid your project being derailed by late delivery. For example, if the contract isn’t signed yet, can you build in a penalty clause, or pay a premium for on-time? Can you spend extra effort on vetting your requirements to ensure your own project doesn’t cause any impact on the vendor? Do you have access to other equipment you could use temporarily if the delivery is late? Does that strategy lead you define an additional risk and mitigation plan? Ask others for ideas on how they’ve managed this kind of risk before and how successful the strategy was for them. Be specific in your mitigation plan: go beyond platitudes such as good project management.

Do you have other worries?

Anything that causes you a specific concern is a candidate to be included as a risk.  Risks are as varied as the projects on which they arise. Here are a few examples I’ve seen: (1) Servers are being moved from a company-run to an external data centre during the same time period that our project needs to test connectivity for several interfaces. Testing connections to the old data centre will need to be repeated for the new data centre, with potential for delay to our project’s timeline. (2) Although the on-site project manager assigned by a major vendor has great leadership skills, he’s not particularly rigorous about scheduling and tracking against the schedule. Since he is managing a large team and a tight delivery timeline, we are concerned that we won’t have adequate visibility to progress or lack thereof. (3) Previous upgrades to this application have failed due to lack of understanding of the integration points.

Notice that all of these risks are very specific, and they provide a rationale for why the risk has been identified.

Schedule and follow up

Assign a responsible person and due date for every mitigation action item. If you aren’t able to assign a person and due date, the mitigation step probably isn’t defined clearly enough. Track these mitigation steps to make sure that they actually get accomplished.

Conclusion

Understanding of IT project risks and mitigation plans can be improved by simplifying the definitions to: (a) What you are worried about exactly and why; and (b) what you will do about it.

It is important to be very specific and provide the rationale for the risks. The mitigation plan needs to be detailed enough that each task in it can be assigned to a person and on a specific date.