Many enterprise folks assume that granular processes relating to the definition and launch of an ERP implementation, also suggests that any marginalizations and/or assurances associated with enterprise ‘risk management’ will also be resolved once a system has been spun up.
Unfortunately, while this assertion may appear to be a reasonable premise, in reality this is largely untrue.
There are significant differences between dealing with ‘risk management’ at a technical level, versus ‘risks’ related to how a technology may or may not pose a threat to the enterprise at-large.
To establish a better understanding of what I’m talking about, here’s the formal definition of ‘risk management’, and how it typically apples from an administrative perspective.
According to the Online Business Dictionary:
“‘Risk management’ relates to; “the identification, analysis, assessment, control, and avoidance, minimization, or elimination of unacceptable (business) risks. An organization may use risk assumptions, risk avoidance, risk retention, risk transfer, risk marginalization, risk validation and/or any other strategies (or combination of strategies) in order to create proper management of future events.”
Note that while the definition may be generally assumed to be applicable to a complex technical structure; subsumed within a larger enterprise business structure, the classical definition has little to do with technology at all.
It is instead primarily applied in terms of administrative considerations and decision-making driven by potentially negative impacts of future events, or in more coarse terms, ‘avoidance and mitigation of bad things before the whole thing blows up your face.’
Consequently, as requirements go, when one is developing and implementing an enterprise ERP solution, there are really two discrete task-sets involved. The first is focused on the system itself, while the second is based on enterprise-wide risk management scenarios and potential business impacts, followed by any consequent resolutions.
While we don’t have enough space to get into the details of a proper administrative ‘risk management’ analysis for an ERP round, here are at least three major areas that should find themselves in any comprehensive document.
1. Management prioritization
Any solid technical requirement involves various senior management levels and their degree of importance when defining, selecting, integrating and launching of an enterprise ERP platform.
However, let’s assume that all of those elements are established, and everything is going along swimmingly, until something goes wrong. It could be as simple as a corrupt database that fails to migrate accurately, or a highly-complex problem triggered by a malformed set of initial technical specs.
Either way, the whole costly thing is lying on the beach like a beached whale, waiting for someone to come along and save the day. Meanwhile, business must be conducted, transactions must be executed, revenue must be booked and payroll must be met; so what do you do?
In this case, the first thing is not necessarily ‘how’ the particular issue must be resolved, but ‘who’ is best qualified to pull the trigger. This is where management prioritization applies as a part of an overall risk management plan.
Similar to emergency call trees, any ERP risk management analysis should include a complete list of managers that are both acquainted with the business impacts associated with a potential failure, along with senior, priority-based individuals, who are immediately available to reach out and drive the herd in the right direction, or call the cavalry as necessary.
Once again, this is not a technical effort but an administrative one, focused on keeping enterprise operations afloat, while a technical team works the problem down in the weeds.
2. Compliance assurance review
Here, it is assumed that an implementation is complete and the ERP system is ready to go live.
However, before anyone actually pushes the button, the implementation committee ‘must’ execute a management compliance review driven by the businesses current situation. Again, this effort is focused on administrivia, i.e. what is current state of the enterprise’s overall GAAP position, how many external dollars are in the sales pipe etc.
The goal is to ensure that the company understands its business situation before a major change is executed. This means that if need be this final snapshot can buy some operational time if something goes awry.
3. Final approval and sign-off
This element is sort of a sign-off of a group of sign-offs, but it’s still worthwhile from what I refer to as a ‘one for all’ perspective.
Granted, during the system’s requirements phase, various management sign-offs should have been part of each task progression. But this last ‘one and go’ sign-off represents an assumption that everything has been checked and rechecked, everyone understands what is about to happen, and what, who, and how the company proposes to resolve its ERP problem should one appear.
