INNOVATE. INTEGRATE. TRANSFORM.

Business Solutions with SAP

ERP Consultants: Is the Promise of Knowledge Transfer just part of the Sales Pitch?

February 10th, 2010 by

CEO CIO CFO AlignmentMost ERP projects are filled with promises of software knowledge transfer from the consultants to the client. Yet once a project is over, in many cases, the client is clueless when it comes to making software configuration changes, and may even struggle with performing basic transactions in the system. So what gives?

In spite of all the lip service given to knowledge transfer, the problem is there never was a real strategy to make it more than just a dream. Secondly, when push comes to shove this once important concept of learning suddenly becomes something we worry about later (and of course, it never happens). This is similar to consultants building a spaceship to get you to Mars with the understanding we will not plan the return trip until after you get there. In other words, there are business consequences for assuming software knowledge will somehow automatically cross-pollinate. Some of them include the following:

1. Paying consultants to do project task that the client could (and should) be doing. Without a certain level of software knowledge, it will be difficult for the client to fulfill even the most basic project responsibilities. Beyond that, what incentives do consultants have to transfer knowledge? Like I have said before, the less you know the more money they make!

2. Fostering resistance to change. When it comes to change management, many times we are our own worst enemy. It is not hard to imagine why employees refuse to buy into something they do not understand (no matter how great it sounds). When consultants are running the project (because the client team hasn’t learned a thing), understandably many employees will view the project as a ticking time bomb (and try to get as far away from it as humanly possible).

3. Software quality will suffer (and this is not just a perception). Lack of software knowledge limits the ability of the client team to become proactive in the design of new business processes and software. In this case, unless the consultant is superman (and they never are) it is a given something very important will slip through the cracks. On the other hand, a client that has a decent understanding of the system can at least ask the right questions or spot things that maybe wrong with the software.

4. Paying consultants to camp out for years after the initial go-live. After all, someone must hold the hands of untrained users and make simple software configuration changes required by the business. A similar issue exists with regard to the clients ability to implement new releases without an army of consultants.

5. The software remains static while the business needs change. The reasons: a) no one internally is aware of what the software is capable of doing; b) no one internally understands how to make the changes, c) the alternative of hiring consultants cost too much. In the end, this all boils down to a failure to leverage your software investment. In the meantime, users are told to live with the software and “work-around” the functionality issues.

6. As employees change jobs, leave the organization and new ones are hired, consistency in user procedures and knowledge of the system slowly erodes. This is inevitable considering no one can explain the big picture or the original software design intent. Therefore, new users are not trained correctly or simply do the best they can (we are now back to sub-optimization).

7. Modifications are made to the software to support needs that are already addressed by the software (right out of the box or with a few configuration changes).

8. After several years of struggling with the software, the organization finally hires an employee from the outside with the expertise to provide needed support. Unfortunately, if this was done prior to implementation, they could have saved themselves a lot of money and grief.

9. Outsource the application support with the hope that the problem goes away. Don’t kid yourself, if no one internally can make sense of user requests (from a software design and set-up standpoint) or, better yet, actually make configuration changes, outsourcing may cost more than you think (service or change orders).

Knowledge transfer is not a one-time event, but a project management “thread” that runs throughout the project cycle. It requires a strategy and attention to execution. In other words, the consultants and the internal team must be managed with the objective of knowledge transfer in mind. The following is a list of items to consider in any knowledge transfer strategy.

1. Select application consultants that have implemented their assigned modules on at least three other projects (with at least one in a similar industry, scope and degree of complexity). Otherwise, there may not be much knowledge to transfer. Also, they will spend most of their time trying to figure out the software(at your expense).

2. Select application consultants with good oral and written communication skills. Understanding software is one thing; but if the consultant does not communicate very well this is a real issue that undermines the goal of knowledge transfer. In addition, a consultant that simply does not say much may also be a consultant that does not know much.

3. Understand that rapid deployment or fixed price consulting engagements can work against you. These type of projects may (or may not) result in a faster or cheaper implementation; but they are definitely more consultant and date driven. This means the client may not have the chance, and the consultant may not have the time for knowledge transfer.

4. Put together an internal project team that has the desire and ability to learn the software. The core skill set includes understanding your business processes, business systems analysis skills (process oriented, logical thinker, problem solver), willing to roll-up their shelves and dig into the software. Like I always say, if you do not have employees with the right skills, get them. You will need them longer than you think.

5. Establish clear expectations with the team and consultants that knowledge transfer is a key priority, a shared responsibility and progress will be measured. For example, add a “knowledge transfer status” segment to the agenda of project team meetings and executive steering team meetings. Schedule one-on-one discussions with each team member and consultant to discuss specific issues and develop get well plans.

6. Do the “formal” project team training (but do not reinvent the training wheel). This training is normally conducted after the software is acquired but before the design phase. When done correctly, classroom style training for the project team is of considerable value since it lays a solid foundation for continued learning. However, when poorly planned or executed, it is a waste of time.

As general rule, for many reasons I prefer courses offered by the software vendor (not those delivered by the consultants you might have working on your project). First, vendor training programs are developed by those with expertise in both formal teaching methods and the software. These courses are also time tested; in other words your team will probably not be the first to take them. They are typically conducted by a professional trainer (who has done the exact same class many times before) with a pre-defined training agenda, lesson plan, data and supporting materials. This usually means a more comprehensive coverage of the software capabilities, consistency, smoother delivery, a software perspective other than that of your consultants, and access to up-to-date training materials.

On the other hand, when consultants deliver the lesson plan and training there is a greater risk that the opposite will be true (narrow scope, poor quality, etc). This is not necessarily an issue of bad consultants. The need to reinvent the training wheel is typically the reason for problems with this approach. Secondly, do not under-estimate the time required by the consultant just to prepare for a class. This is one reason why training delivered by consultants may end up costing much more than vendor training. Finally, many consultants are overly accomodating and are willing to customize the training beyond what is reasonable or advisable. Classes may be customized to the extent it is no longer really training, but instead a premature design or testing session. Remember, the goal at this stage is to learn the software capabilities and basic transaction processing, not test or determine how it will be used. The truth is no one at this point has enough information to design or test anything.

7. Plan courses to maximize learning for the dollars spent. When scheduling classes first take only the basic courses required for each module. After the team has have worked with the software for a while (with the assistance of your consultants), take the advanced functionality (if you need to). With this approach, the student has a chance to absorb and reinforce what was learned during initial training and, as a result, should be better prepared to take the advanced topics and probably will have more specific questions.

Finally, do not send a cast of thousands to project team training (the idea is the project team will train others). The key people to attend the courses for a given module include the module team lead, the power user (functional analyst), the internal consultant (if you have one), and the IT developer (supporting the module). Recognize it may be appropriate for a few others to attend such as the dept. manager (not formally on the team), power users from other highly integrated modules, etc. However, as a general rule, training only those on the project team is the best use of time and the training budget. That is why they call it “project team training”!

8. Take the software configuration classes. When offered, these courses get into the parameters; switches and setting that makes the software do what it does. The point is, most classes focus on end-user transaction processing, but the software configuration classes get into what is behind the curtain (but are not about writing programs). These classes are very important because if the goal is to wean yourself from consultants this will not be possible unless the team eventually understands how to maintain the software set-up. The list of attendees for these type of classes is shorter and includes the module team lead, power user and IT support.

9. Set-up a playground software environment. When the team returns from training, there must be an environment immediately available for them to reinforce learning and do some self-help follow-up testing. Taking advantage of the playground should not be optional but mandatory for the team.

10. Develop a realistic (yet aggressive), schedule to transition consultants into support roles. When developing internal software expertise, typically at first the consultant has primary responsibility for initial software set-up and other application activities (based on client input). However, as the internal team gets up to speed and confidence grows, there must be a plan to transition primary application responsibilities from the consultants to the client module team. At this point and thereafter, the consultants play coaching and support roles. This transition should occur as soon as it is realistic to do so and targeted for specific project milestones / dates. Depending on the client team, it is not unheard of to start this transition after the design phase or after the software is configured(construction phase). At the very latest, the internal team should take primary responsibility once formal testing begins.

11. Make sure the internal team (client team) is available for knowledge transfer. It is difficult for any consultant to educate a client that fails to show up for meetings.

12. Insist that consultants give homework assignments to the project team. The assignments should require the team to work with the software on their own with some meaningful expected outcomes (reviewed by the consultant). Most people learn by doing, struggling a bit and making a few mistakes. In fact it is good to have the client work on assignments when the consultants are not around. If the team does not have these type of experiences on their own, the consultant will become a crutch and an excuse for not doing anything.

13. Require the internal team (not consultants) to perform software demonstrations, design reviews, and management presentations. This is not about throwing your team to the wolves. However, if you expect nothing from the team that is exactly what you will get. These activities should be part of any implementation methodology and must start early and occur often. When the internal team knows they will eventually take the lead for these activities, it drives the perceived need to learn, gets them moving out of their comfort zones, expedites the process and is a good gauge of learning progress. These type of activities also helps the team build confidence in their own abilities.

14. Take advantage of all learning resources available for your specific ERP system. This involves some self-help (a very necessary part of learning) and includes web communities, memberships, and white papers (obtained from the consultants or software vendor). These type of white papers (not to be confused with marketing “white papers”)are very useful since they explain the step-by-step details of setting up the software to perform certain functions.

15. The client team should create most of the project documentation relating to software usage and set-up. Examples are work procedures, end user training materials and system documentation that include screen shots and explanations. The premise is if the client is required to do documentation (with the quality reviewed by the consultants), the client will learn many things in the process.

16. The client team is expected to train all end-users prior to go-live. Again, if you are to train many people you will probably feel the need to learn the software. Keep in mind, consultants play training support roles. (what is required to transfer knowledge to the end-user is a different topic).

17. Put the client team on the frontline of post go-live support. There is no better incentive to learn the software then knowing you will field the real world questions and issues once the rubber meets the road.

~~~~~~~~~~~~~~~~~~~

Reposted completely, and with permission from my friend and author Steve Phillips who runs a Blog entitled Street Smart ERP – Visit his site for great insight and commentary.

The original post can be seen here:

http://it.toolbox.com/blogs/street-smart-erp/erp-consultants-is-the-promise-of-knowledge-transfer-just-part-of-the-sales-pitch-36252


Related Posts:

The Agile SAP Enterprise and Regulatory Compliance

February 21st, 2008 by

Speed, Agility, Technology, Advanced SolutionsHow can you be more nimble? Are you in an agile enterprise?

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.

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.

How Aggressive “Regulatory Overhead” Infects the Whole SAP Enterprise

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.

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.

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 aren’t supported by a genuine regulatory requirement. Or worse still, the exponential growth of “controls” often means that important processes and functions are not enhanced to improve the business and operations.  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 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 processing cycle times.  Several of their validation 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, and SAP provided tools which 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. 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.

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  of these serial “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 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 enterprise.

Related Posts: