Datamation content and product recommendations are editorially independent. We may make money when you click on links to our partners. Learn More.
The IT community is witnessing a proliferation of applications and document templates all offering salvation regarding regulatory compliance. While tools can help, they cannot provide a total solution. Organizations must factor in people and process requirements to develop and/or purchase the appropriate technology. This article will focus on process requirements.
Information technology is a multiplier of processes. Through judicious application, IT can make good processes better. On the other hand, a haphazard application of IT can also make things worse. Many IT people are familiar with the benefits of understanding a process before they automate it. Essentially, they document the status quo and then work with stakeholders to identify a desired state and the means to arrive at it.
In contrast, IT should not simply implement technology and tell the organization, “Here is the new system. It will make your lives better.” That type of “technology push” risks misunderstanding requirements and invites a misapplication of IT with unpredictable outcomes.
Building on this, compliance requirements must be recognized as another input to process design. Whether the process is for the business, external customers, or internal to IT, the need to identify, understand and synthesize all the requirements to come up with a valid optimum solution for the overall organization still exists.
It is this systemic approach that matters. No one area, not even IT, should be optimized at the expense of the overall entity. An overemphasis on optimizing one area can be detrimental because what benefits one area may harm others disproportionately to the gain. To use an extreme illustration, shutting off all user and network access to a key financial system would minimize some security risks, but at a ridiculous cost to the business because the system is needed to operate. The view that the organization is a system of component parts moving toward a common goal is very much needed.
Confusing IT Controls and Business Goals
If controls are implemented to the extent that the business cannot function, then the point has been missed. It is the purpose of controls to create a reasonable expectation of predictable outcomes. This means that the need to manage risks must be tempered by the need for the organization to achieve its goal. Likewise, the needs and objectives of any component part (IT, marketing, finance, manufacturing, etc.) must properly align with the goal of the entity. Public companies exist to maximize their returns to shareholders, but they must also strive to do this in a predictable and sustainable manner.
When IT is implementing controls at the process or application levels, it must be cognizant of the need to deal with acceptable levels of risk. Their goal should not be to eliminate risks, but to reduce the risks to organizational objectives to levels that are deemed acceptable to management. This isn’t always an easy concept for IT to grasp. Many times, perhaps due to the binary nature of computing, they want all or nothing, and this usually isn’t cost-effective.
To optimize the system, and organization as a whole, the identified controls must be factored into the design of processes and applications. These controls must be reviewed by stakeholders to ensure that they are as efficient as possible and represent the appropriate trade-off between business needs and risk mitigation.
The need for compliance cannot be an afterthought layered on top of existing systems comprised of processes, people and technology. Instead, new systems must evolve to properly reflect the control requirements. Far from being a one-time event, these systems must be routinely scrutinized both by practitioners and by audit to ensure that they reflect the needs of the business — in terms of supporting goals while mitigating risks — and are as efficient as possible.
For a good comparison, look at the impacts of the U.S. automakers’ decision to bolt emission control systems on top of existing engine designs in the 1980s. The end result was a loss of power and fuel efficiency plus increased complexity. Over time, they revised their engine designs such that emissions controls were integrated into the design of the new engine systems.They regained, and even exceeded, the previous levels of fuel efficiency and horsepower while managing complexity. IT and business processes are the same way. The initial push for compliance resulted in many gross inefficiencies. Now, organizations must go back and enhance, or outright replace, those processes.
The goal of business is to make money — not to be compliant. The need to be compliant while making money creates a dynamic that must be recognized and appropriately factored in because the level of regulatory complexity is likely to only rise over time. Furthermore, multinationals will be striving to deal with often conflicting compliance requirements from multiple countries as the level of global regulation increases.
In summary, regulation will be a fact of life for businesses moving forward. Internal compliance initiatives must constantly trade off the need to balance risks with the needs of the business to achieve a proper balance. To make the best of it, businesses must approach compliance and process design systemically to properly integrate requirements and develop true solutions.
