How can you be more nimble? Are you in an agile enterprise?
The very nature of regulatory compliance makes creating an agile enterprise difficult. Often, regulatory compliance acts as a tax on the enterprise. Most businesses with highly regulatory environments struggle to process the improvements, streamlining, cost reductions, and simplifications that they need to stay competitive in a global environment.
After doing several projects for U.S. companies subject to Sarbanes-Oxley (SOX) compliance, and pharmaceutical companies heavily regulated through FDA including 21 CFR Part 11 (Validated environments), I have witnessed the dark side of compliance. Through this experience, I have also learned of ways for highly-regulated environments to become nimble in our modern global environment.
SAP Compliance with Sarbanes-Oxley (SOX), FDA Part 21, and Others
SAP can help the enterprise through the integration it provides. To leverage your SAP investment, you need to be able to add new functionality or enhancements. This way, you can improve or automate existing functionality.
However, in highly regulated environments, the regulatory restrictions after your ERP or SAP go-live can be time consuming and frustrating. For instance, the validation and approval processes can destroy productivity, as they stifle your ability to respond to changing market conditions. Even so, you cannot avoid them. Just like a tax on the enterprise, they are a part of the cost of doing business.
Your internal compliance requirements may be slowly choking your business with overly rigorous controls–and some requirements may not even be necessary. Or worse still, the exponential growth of controls prevents you from enhancing important processes and functions to improve the business and operations. When this happens, marketplace agility, innovation, and flexibility all suffer. You need to balance between the required controls and the ability to make changes.
Gaining business benefit
The regulatory tax on the enterprise prevents many small or incremental improvements because of the painful, expensive, and time-consuming compliance process requirements. However, if you fail to take advantage of even small incremental changes in today’s competitive environment, you can face serious negative consequences over time.
Standing alone, these small changes are generally not that significant. However, dozens or even hundreds of these changes, multiplied across an entire enterprise, build up. Additionally, each small task is carried out by hundreds, and even thousands of people. It doesn’t take long for small improvements to add up to major differences and efficiencies across large organizations. All of these changes have direct impacts on efficiencies and cycle-time improvement for the supply chain, financial processing, and marketplace responsiveness.
As for larger changes, reducing compliance cycle time more visibly saves costs and improves agility. However, the regulatory tax of formal approvals, reviews, verifications, validations, regression tests, and all of the other compliance requirements can deter companies from enacting even these changes.
How Aggressive Regulatory Overhead Can Infect the Whole Enterprise
The regulatory tax routinely translates into learned behavior, which causes a productivity slowdown and lack of enthusiasm across the enterprise. People become so frustrated dealing with what they perceive as unnecessary regulatory overhead, or “red tape,” that it poisons all facets of productivity.
Personally, I have seen little consistency in compliance schemes on several heavily-regulated SAP projects. The only constant is the painfully inefficient, frustrating, and obstructive design of compliance processes. These compliance processes fail to follow the famous “7 habits” for success.
Compliance Gates That Affect Your SAP Project Time and Budget
Too often, compliance processes rely on many serial processes or gates. These serial processes have built-in stops to ensure that the project team accomplishes certain critical steps before continuing. This forces the team to stop, and then wait for days, or in some cases even weeks, before the gated procedure is completed.
Worse still, while the intent is to place these gates or checkpoints into the processes at critical points, they often end up throughout approval processes, which further chokes efficiency. In worst-case scenarios, the most demanding controls are placed early in the process stream, making even the thought of initiating improvements distressing.
Rather than having fully-documented code, configuration reviews, and formal approvals with sign-offs before moving to the QA environment, you should consider an ad hoc approach. For compliance purposes, the team may complete a first review and only require a manager’s approval before moving to QA. From there, formal or informal testing is performed, and any incremental coding or configuration changes are made. The team should receive a final, formalized, fully approved review before the final testing. This process removes the numerous review cycle times from the earlier development process, ensuring the necessary quality, documentation, and compliance before moving the changes into production.
The earlier in the process you move regulatory controls, the more painful, slow, and disruptive these taxes on the enterprise become. Because of this, you should move regulatory requirements, approvals, validations, and all other “taxes” on the enterprise as late into the process as possible. Validations and regulatory requirements should only come into play once testing, bug fixes, and error corrections solidify the solution. Otherwise, constant reviews, approvals, and management overhead for each error stall the normal evolution of ERP solution delivery.
SAP Project with FDA 21 CFR 11 Validation Requirements
An SAP project subject to FDA regulations that I worked with stands out — their regulatory model was very thorough, well-planned, and well thought out. It served as a “V” model to cover their validation requirements. Even so, a few small areas in this model could be adjusted and still be compliant, offering tremendous improvements in processing cycle times. Several of their validation approval gates were during the development phase, rather than later in the process after testing defects and solution gaps had been closed. If the review gates were moved far later in the process, the company would dramatically improve change cycle times, reduce the number of review cycles, reduce the overall amount of effort.
The company could then accelerate the process and conduct parallel activities to improve efficiency. This approach of moving some of the gates to the QA/Validation environment would allow for more incremental adjustment and change, as well as unofficial testing without as much of the administrative overhead.
Successful SAP project delivery, in a reasonable timeframe and budget, requires building and then maintaining momentum. Adding compliance requirements too early destroys that momentum and in turn undermines timelines and budgets.
Serial, Parallel, and Gate Processing in IT Project Compliance
As much as practicable, avoid gate processes. When developing compliance processes, the only genuine gate process should be a high-risk validation process or high-risk direct financial impact segregation of duties process. Even then, the gate process should only be for going into a production system. Regulatory requirements rarely extend to most segments of a development system, yet many companies implement stringent controls even in a sandbox.
Before going into your production system, attempt to define some parallel processing when you need gate processes. In other words, avoid allowing gate processes to stop progress. Early process stages should be the least restrictive and the least intensive. This way, you can encourage the type of early testing, checking of assumptions, setup, verification of processes, prototyping, and checking of concepts that are critical for well-developed processes. Remember: The less restrictive the early stages are, the more investigation and development can be performed.
Based on how you move from a development stage, to a testing stage, to preparation for moving into a productive system, develop graduated levels of compliance requirements. The less restrictive these initial processes are, the more efficient they will be. For example, if a project passes testing but you may want to add additional efficiency or automation improvements later, you should be able to go back without significant obstacles. The amount of compliance pain or regulatory overhead imposed at earlier stages in the processes will have a direct relationship on how easily you can make useful changes later on.
For a quality or testing environment, provide a separate, non-validated test environment that is a periodic copy of the validated test client. Then, move system changes into the copy, test run through test scripts or test scenarios in an informal manner, evaluate for improvements or enhancements, make adjustments, and move those adjustments to the testing environment for re-testing. Once you are satisfied with the results, begin the testing in the formal QA environment.
SAP and Sarbanes-Oxley or “SOX” Compliance
One of my pet peeves is some of the supposed SOX-prohibited system transactions. In these scenarios, an auditor might even demand that a simple display transaction is a conflict. With the exception of HR data and some limited financial information, display access to other information poses little risk. Personally, I still have not found an auditor who can answer how some of these requirements can lead to or cause material misstatements.
Previously, I was at a small subsidiary of a very large company. When I say small, I mean the parent company gross revenue was almost a hundred times the size of the small subsidiary. Like most small companies, they were lean on staffing, and individuals often performed more than one task or function. As a result, they failed to meet the parent company’s “segregation of duties” requirements.
During the SAP implementation, the parent’s Sarbanes-Oxley requirements were imposed on the small company. The increased staffing requirements, coupled with the ridiculous bureaucratic overhead, were unrealistic expectations for the subsidiary to reach.
This company has several U.S. and European plants, each with their own bank accounts, and between them there were three or four separate banking institutions involved. In a worst-case scenario, if someone could figure out how to pilfer an entire month’s gross receipts from one of the bank accounts, the overall financial impact to the parent company and their quarterly report would have been little more than a “rounding error.”
When I dared ask the parent company’s compliance staff what the threshold for a material misstatement was for the small subsidiary, the auditors responded with blank stares of shock.
To this day, I wonder if they even knew the regulations or actual compliance requirements they were supposed to be auditing. After all, when the subsidiary contributes a whole 1% to the gross revenue of the parent, forcing a 20% increase in staffing just to comply with the separation of duties requirements is patently absurd. Keep in mind, the subsidiary only had about 45-60 days of revenue in the bank at any time throughout the year. Even if everything were embezzled, that 1% really amounts to about a sixth of 1% of actual financial exposure.
If the regulatory overhead equals or exceeds the cost of the risk, it may not be a worthwhile investment. Unfortunately, many companies that are subject to various regulatory compliance schemes fail to consider actual risk.
Where to Begin with Regulatory and Compliance Programs
As you may have guessed, my all-time-favorite Sarbanes-Oxley compliance item is the never-defined material misstatement. This is the catchall excuse for choking a company in audits that lack regulatory or financial significance. And even the audits that have some direct financial significance may be so small as to be a waste of time.
Start with the end in mind. Define what compliance really means in your company, and then determine how that compliance will be measured. We can refer to those activities or efforts that directly support measuring compliance (or the deliverables that are needed) as items that support compliance value. If something you do in your compliance efforts does not support a clearly-defined compliance requirement, then not is it a waste of time, it is an artificially-imposed impediment to efficiency and competition.
In other words, define the actual compliance requirements up front, and then determine the criteria needed to ensure compliance. From there, work backwards to determine the appropriate processes. Without that upfront determination of what compliance is, and how compliance will be measured, you have nothing to measure value added steps against.
Below are the following steps to defining compliance requirements:
1) Work with the auditors to map compliance requirements to their corresponding statutory provisions or regulatory requirements. If an auditor will not map specific requirements to statutory or other written regulatory requirements (such as CFR’s or “Codes of Federal Regulation”), then it may be time to find a new auditor.
2) Define clear, specific, and objectively measurable criteria for each of those compliance requirements, and if the regulatory provision is not clear enough to define such criteria, find a generally accepted governing body or publication that provides guidance. Don’t make definitions up because an auditor says you have to.
3) Define what material misstatement means in terms of financial liability amounts. If necessary, to avoid shareholder liability and in the interests of proper disclosure, publish the new compliance schema in a quarterly statement explaining the new compliance paradigm, the potential risks, and how the streamlined process will improve business operations.
4) For Life Science related companies, you need to understand, evaluate, and map risks at the execution level of the transaction as subject to GxP regulations. In conjunction with this, that same risk thinking should be applied to the approval and control processes. In some cases, while well intended, heavily-gated processes may slow critical changes that reduce GxP-related risks.
After you assess, or re-assess, your processes to eliminate steps that do not directly add “compliance value,” take a look at the remaining processes to see how they can be improved or streamlined.
Regulatory and Compliance Process Improvement Options to Consider
In all highly-regulated companies, one of the biggest compliance time killers is regression testing. To avoid inefficiency, determine the actual testing requirements, and then find ways to streamline and automate those processes. A full regression test process should not take weeks, even in very large enterprises. If SAP CATT, eCATT, Mercury, or other automated test tools sufficiently automate test processes, a full regression test cycle should be able to be resolved in a few days–even in validated environments.
In the area of defining automated regression testing, this can be a “mini-project” in highly-regulated environments, taking significant one-time efforts to implement.
Take a hard look at serial processes — especially those gate processes that must be completed before any further activity can be done — and see if they are adding any “compliance value.” If they are not directly related to achieving compliance deliverables, then why are they in the process chain?
Where Some SAP FDA Regulatory Validation Problems Occur
In any regulated environment, you can run into several types of issues:
1) Problem: The project team lacks understanding of the compliance requirements, and SAP-provided tools that support compliance, within the organization responsible for compliance.
Solution: On any new project, or before any major undertaking, ensure that the entire project team reads and reviews the relevant regulations and compliance requirements. In other words, get the actual language of the regulations, and ensure that every team member reads them before the project begins. To better understand the requirements, do some online research.
2) Problem: Compliance triggers are defined at unnecessary control points (such as having controls on a development system).
Solution: Move any serial gates to as far right (or as late in the process) as possible.
3) Problem: Compliance processes have too many serial process streams or “gates” that require everything to stop completely until the gate is successfully navigated (in an FDA-validated environment, there will always be a need for some of these serial “gates”).
Solution: As much as possible, reduce the frequency of serial gates by combining them. This way, you can reduce the overall number of “hard” compliance points. However, be sure that, at logical breakpoints where an item may not have to go all the way back to the beginning of the process, you also break up any of the gates. One large gate with numerous controls and reviews may not be productive either. Finally, avoid compliance requirements early in the process, when problems are more likely to be found and resolved.
4) Problem: Auditors or systems administrators do not have sufficient understanding of SAP security capabilities. They are too quick to declare risks at a transactional level without understanding how those transactions can be controlled. They often arbitrarily find “segregation of duties” (SOD) problems and conflicts.
Solution: Be sure your system administrator and system security personnel have enough exposure and experience with SAP. This way, they can help any compliance officials understand the ability to control security at a more detailed level than the transaction level. For example, SAP allows you to use security to control document types. For example, in an invoice process you may wish break up overlapping responsibilities by document type.
Another issue I have seen is defining “conflicts” where the entire dollar amount involved was not sufficient enough to be materially significant. In this scenario, insist that material misstatement thresholds are defined and published. A deviation from SOD requirements can easily be justified if the compliance cost is prohibitively high (e.g. hiring a new employee) and the activity is subject to thresholds so low that it does not make any business sense to separate the duties.
5) Problem: Auditors and consulting companies often have little or no background with SAP and its published control points for various types of compliance.
Solution: Often, vendor-published GxP (Good “x” Practices) or SOD (Segregation of Duties) documentation, such as SAP’s, provides a critical basis for understanding and challenging improper or unnecessary compliance requirements. The vendor documentation frequently serves as reasonable due diligence for most regulatory agency compliance requirements. At a minimum, vendor documentation serves to also distribute the risk, so that a vendor such as SAP who provides paid support will address any compliance deficiency in the software that arises.
6) Problem: The process has too many serial gates, or gates with little direct impact on regulatory requirements.
Solution: Virtually all regulatory environments end up being reasonably well documented. Once the approval and gating processes are defined, do a final review to assess and challenge approvals and serial gates. Start asking yourself whether there is an easier or less restrictive way to meet the requirement.
Conclusion on Regulatory and Compliance in SAP or Other IT Projects
Due to the vast number of regulatory requirements and scenarios, this article only scratches the surface. As you can see, however, many process improvements can help you to become agile and more competitive. Compliance processes should not become a stranglehold for your enterprise. A little work, and a careful review and evaluation of what the actual compliance requirements are, can go a long way toward understanding whether your compliance processes make sense.
Compliance is important, but in today’s globally competitive environment and fast-paced world, activities that do not directly support clearly defined compliance requirements are an impediment to the agile and competitive enterprise.
Your competition are looking for ways to take your market share. Don’t help them by unnecessarily restricting your innovation and competitive abilities!
