Many venture folks assume that granular processes relating to the definition and start of an ERP implementation, also suggests that any marginalization's and/or assurances associated with enterprise risk management will also be resolved once a system has been spun up.
Unfortunately, while this claim may appear to be a reasonable premise, in reality this is largely untrue.
Risk management relates to; the identification, analysis, assessment, control, and dodging minimization, or elimination of unacceptable (business) risks. An institute 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 constitution, 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, dodging and mitigation of bad things before the whole thing blows up your face.
Any solid technical requirement involves various senior management levels and their scale 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 quandary 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, a 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 resolute, but who is best qualified to pull the trigger. This is where management prioritization applies as a part of an overall risk management plan.
Here, it is assumed that an accomplishment 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 state. Again, this effort is focused on administrivia, i.e. what is the 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 transform is executed. This means that if need be this final snapshot can buy some operational time if something goes awry.
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, all through 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 the lot has been checked and rechecked, everyone understands what is about to happen, and what, who, and how the group proposes to resolve its ERP problem should one appear.