The Agile SAP Enterprise and Regulatory Compliance
How can you be more nimble? Are you in an agile enterprise?
With global competitors who are not subject to the same rigorous requirements as American or European countries and smaller / privately owned competitors it is more important than ever to find ways for the enterprise to be agile.
The very nature of regulatory schemes makes agility difficult. Most businesses restricted by regulatory environments often find these areas of the enterprise “off-limits” to the type of process improvements, streamlining, cost reductions, and simplifying that are required to stay competitive in a global environment.
Regulatory compliance and their difficult to navigate requirement structures make the creation of an agile enterprise very difficult. After doing several projects for U.S. companies subject to Sarbanes-Oxley (SOX) compliance and pharmaceutical companies heavily regulated through 21 CFR Part 11 (Validated environments) I’ve found highly regulated environments need to be nimble in our modern global environment.
How Aggressive “Regulatory Overhead” Infects the Whole SAP Enterprise
I’ve 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 systems. These compliance systems never follow the famous “7 habits” for success. I have yet to see a compliance system designed from the beginning with the end in mind –, most compliance systems seem to create a numbing frustration that chokes productivity across all processes.
Regulatory overhead routinely translates into learned behavior that causes a productivity slowdown and lack of enthusiasm even in the processes not subject to compliance. People become so frustrated dealing with unnecessary regulatory overhead, or “red tape,” that it poisons all facets of productivity.
How do you Improve Approval Processes in an SAP Regulated Environment?
SAP, like other ERP applications, can help the enterprise through the integration it provides. To leverage your SAP investment it is important to be able to add new functionality or enhancements improving or automating existing functionality. However in highly regulated environments after your ERP or SAP go-live the regulatory restrictions can be painful, time consuming, and frustrating. For regulated industries the validation and approval processes can be killers to productivity–, they stifle your ability to respond to changing market conditions.
Your internal compliance requirements may be slowly choking your business with overly rigorous controls that really aren’t supported by a genuine regulatory requirement. Or worse still, the exponential growth of “controls” may mean that the people who are leading the effort do not actually understand the real regulatory requirements. There has got to be some measure of balance between the required controls and the ability to make changes.
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 certain critical steps are accomplished before being able to continue. Anyone who has been there knows the problems with being forced 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 choking any possible efficiency.
And 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 and configuration reviews and formal approvals with signoffs before something can be moved to the QA environment, more of an ad hoc approach could be used. For compliance purposes there might be a first review and only a project manager’s approval needed to move it to QA. From there, informal testing performed and any incremental coding or configuration changes are made, and then before the final testing, the final, formalized, fully approved review and approvals are performed. What this does is remove the numerous review cycle times from the earlier development process and ensures the necessary quality, documentation, and compliance exists before the changes are moved into production.
Recent SAP Project with FDA 21 CFR 11 Validation Requirements
Recently I had a project on a company subject to U.S. FDA regulatory requirements. Their regulatory model was very thorough, well-planned, and well thought out. It was actually a work of art and was internally called a “V” model to cover their validation requirements. This model had a few small areas that if they were to be adjusted would still be compliant and would offer tremendous improvements in change processing cycle times. Several of their approval gates were on their Development system rather than later in the process.
A few adjustments to gates and gate timing of some of their process model would dramatically improve change cycle times and reduce the overall amount of effort. For example there was too much validation control in the Development environment that might have been better if some of the review gates were moved to the quality assurance system. This would have required fewer review cycles and fewer “early” gates in the process. It would accelerate the process and allow for several more parallel activities to take place making the process more efficient. This approach of moving some of the gates to the QA environment would allow for more incremental adjustment and change, as well as unofficial testing without as much of the administrative overhead.
Where Some SAP FDA Regulatory Validation Problems Occur
Too often in any regulated environment there are several types of issues:
1) Problem: A lack of understanding of the compliance requirements 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. Do a little online research and get a better understanding of the requirements.
2) Problem: Compliance triggers defined at unnecessary control points such as having controls on a Development sandbox (this is a misunderstanding of compliance requirements).
Solution: Move any “serial gates” (those processes that stop all other activities until they are completed) to as late in the process as possible.
3) Problem: Compliance processes with too many serial process streams or “gates” where everything must stop completely until the gate is successfully navigated (in an FDA validated environment there will always be a need for some “gates”).
Solution: To the extent possible, combine the number and frequency of serial gates to reduce the overall number of “hard” compliance points. However, use some thought here and be sure that where it makes sense, at logical breakpoints, where an item may not have to go all the way back to the beginning of the process that you also break up any of the gates. One huge gate with numerous controls and reviews may not be productive either. Think of it like this, if the gate can be used to efficiently find and resolve an issue earlier in the process, where it is easier to correct then that might be a good use.
4) Problem: Auditors or systems administrators who do not have sufficient understanding of SAP security capabilities and are too quick to declare risks at a transactional level without understanding how those transactions can be controlled. Arbitrarily finding “segregation of duties” (SOD) problems and conflicts.
Solution: Be sure your system administrator and system security personnel have enough exposure and experience with SAP to 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. So in an invoice process you may wish break up overlapping responsibilities by document type. Another thing I have seen is the silliness of defining “conflicts” where the entire dollar amount involved was not sufficient enough to be materially significant. 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. 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.
Solution: 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: Validation empire builders who are internal political players (which is beyond the scope of this article).
Solution: This one is for senior management to tackle. Dealing with corporate politics is beyond the scope of this post.
SAP Compliance with Sarbanes-Oxley (SOX), FDA Part 21, and Others
Getting business benefit
Regulated companies do have significant potential for improvement in the area of streamlining and improving the compliance processes and procedures.
I would challenge some of the highly regulated companies to do cost studies on their compliance requirements to see how much overhead they add or how much of an impediment they are to making needed changes. We’ll call these impediments to change “regulatory overhead.” This regulatory overhead applies almost equally to even the very smallest and least significant of changes.
The failure to take advantage of even small incremental changes can have serious negative consequences over time. Because of the regulatory overhead many small or incremental changes will never be implemented because of the painful, expensive and time consuming validation requirements.
Standing alone these small changes are generally not that significant. However, stacked together across dozens or even hundreds of these changes, multiplied across an entire enterprise, the cost and automation can represent orders of magnitude improvements . These changes have direct impacts on efficiencies and cycle-time improvement for both supply chain and financial processing.
Think about it, all those changes, multiplied across the number of times that small task is carried out, multiplied by the hundreds, and in some cases even thousands of people impacted by the processes they affect. It doesn’t take long for small improvements to add up to major differences and efficiencies across large organizations. As for larger changes, reducing compliance cycle time saves costs related to this regulatory overhead.
SAP and Sarbanes-Oxley or “SOX” Compliance Stupidity with Segregation of Duties
One of my pet peeves are some of the supposed “SOX prohibited” system transactions. Sometimes there is no way to describe it except stupid. How an auditor might demand that some simple display transaction is a “conflict” often baffles me. With the exception of HR data and some limited financial information there is little risk for display access to other information. I still have not found an auditor who can answer how some of these ridiculous requirements can lead to or cause “material misstatements.”
A story from the trenches
Recently I was at a small subsidiary of a very large company. When I say small, I mean the parent company gross revenue was 30 times the size of the small subsidiary. Like most small companies, they were lean on staffing and different individuals often performed more than one task or function. They failed to meet the parent company “segregation of duties” requirements but during the SAP implementation the parent Sarbanes-Oxley requirements were imposed on the small company. The attendant increased staffing requirements coupled with the ridiculous bureaucratic overhead bordered on insane. At the very least it was a comedy of errors.
This company has several U.S. and European Plants, each with their own bank accounts, and between them there were 3 or 4 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 plants, the overall financial impact to the parent company, and to their quarterly report would have been little more than a rounding error.
When I dared to ask the parent company’s compliance staff what the threshold for a “material misstatement” was for the small subsidiary I got blank stares of shock from the auditors. It was as if I were speaking a foreign language under water. 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 3% to the gross revenue of the parent, forcing a 20% increase in staffing just to comply with “separation of duties” requirements is patently absurd. The measure of regulatory requirements imposed on them by the audit requirements were the height of plain stupidity.
If the regulatory overhead equals or exceeds the cost of the risk, this should be carefully evaluated. Sadly this is common in many companies subject to various regulatory compliance schemes.
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 needless audits. It’s great for auditors to point at anything you do, no matter how trivial, menial, or inconsequential and scream that it is an audit problem–, even when there is no real financial or regulatory significance. And even those things that have some direct financial significance may be so small as to be a worthless waste of time. Fix the audit process and stop the compliance processes from choking you to death.
Start with the end in mind. Define what compliance really means in your company and then determine how that compliance will be measured. We’ll call those activities or efforts that directly support measuring compliance (or the deliverables that are needed) as those items that support “compliance value.” If something you do in your compliance efforts do not have a specific purpose that supports a clearly defined compliance requirement then it is not only 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 it takes to ensure compliance. From there work backward to determine the appropriate processes. Without that up front determination of how you will define what compliance is, and how compliance will be measured, you have nothing to measure value added steps against. In an environment without clear understanding of how you define and measure compliance, it becomes an expanding balloon that grows while choking everything in its path.
1) Work with the auditors to map compliance requirements to the specific statutory provisions or regulatory requirements that are affected. 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 some generally accepted governing body or publication that provides guidance. Don’t just make something 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.
After you assess, or re-assess your processes to eliminate steps that do not directly add “compliance value,” take a look at the remaining process to see how it 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. 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, far-flung enterprises. If test processes are sufficiently automated by using SAP CATT, eCATT, Mercury, or other automated test tools there is no legitimate reason a full regression test cycle should not be able to be resolved in a few days, even in validated environments.
In the area of defining automated regression testing it is important to understand that in highly regulated environments this can be a “mini-project” 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?
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–, and then only when going into a production system. Regulatory requirements rarely extend to most segments of a development system yet it is shocking to me how many companies implement stringent controls even in a sandbox.
If you must extend validation requirements to a development environment, it is likely less expensive and more productive to invest in the hardware and application(s) to set up a separated stand-alone SAP system that you can copy your production system to. All advance development efforts and work should be done there and only after there is some comfort level that it will work and is correct, duplicate the effort in the “compliance” development environment.
If there are needs for “gate” processes before going into your production system, attempt to define some parallel processing that will allow some or all processing to continue. To the extent possible don’t allow “gate” processes to stop progress.
Develop “staged” or graduated levels of compliance requirements based on the process of moving from a development stage, to a testing stage, and then preparation for moving into a productive system. The less restrictive these processes are until they get to the stage of preparation for moving into a productive system the more efficient they will be. For example, if testing shows that things work but additional efficiency or automation improvements might be made, the ability to go back and add additional enhancements should not be so prohibitive as to create significant obstacles to improvement. The amount of compliance “pain” or regulatory overhead imposed at earlier stages in the processes will have a direct relationship to the ability to make useful changes as the process is worked through.
Early process stages should be the least restrictive and the least intensive to 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. The less restrictive the early stages are the more investigation and development can be performed. The development environment should meet this requirement.
For a quality or testing environment provide a separate, completely non-validated test environment that is a periodic copy of the validated test client. Then move system changes into there, test run through test scripts or test scenarios in an informal manner, evaluate for improvements or enhancements, then make adjustments and move them to the testing environment for re-testing. Once satisfied that the results are what you expect, then begin the testing in the formal validated QA environment. This non-validated test environment is refreshed with copies of the validated test environment from time to time.
Conclusion on Regulatory and Compliance in SAP or Other IT Projects
This article only scratches the surface but as you can see there are many possibilities for reasonable improvement that will 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 designed to build empires or which do not directly support clearly defined compliance requirements are an impediment to the agile and competitive enterpri
