Saturday, September 15, 2018

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.


Friday, September 14, 2018

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.