Right From the Start: Considering Compliance Issues Throughout the IT Lifecycle

Computerworld - While much of the work to comply with the Sarbanes-Oxley Act has been focused on adding controls to business processes and systems related to financial reporting, some companies are beginning to tap application life-cycle management tools to address Sarbanes-Oxley compliance as part of the application development process.
These companies are using tools to automate development and documentation processes. That documentation can then be audited to detail who has accessed code and what changes have been made. It can also be used to track what testing and quality assurance have been done when building applications or changing existing ones that fall under the act's scope. Some companies are finding that these compliance efforts are yielding additional rewards, like reducing costly rework by automating the change management aspects of programming.
Israel-based Teva Pharmaceutical Industries Ltd., which generates 91% of its revenue from sales in the U.S. and Europe, has replaced its paper-based application development workflow with change management and code-change tools from MKS Inc. over the past year. In addition to helping Teva meet regulatory requirements, the tools have allowed the company to attach electronic signatures to software change requests as required by the U.S. Food and Drug Administration. Teva has also been able to virtually eliminate its rework requests by using the tools to verify that changes are meeting business user requests, says Tom Loane, vice president and CIO of Teva North America.
Teva's old paper-based process for requesting development work centered around a seven-page form that had to circulate among employees in the U.S. and Israel to get four required sign-offs -- from the user requesting the change, the programmer, the tester and the quality assurance employee -- for the 1,000 software changes the company makes annually. Teva is replacing that process with MKS Integrity Manager, which prescribes the process and manages the workflow associated with code changes. The tool creates a document trail that records all activity, from the time a request for a change is made to when the code is moved into production. A workflow engine sends e-mail notifications to team members when work is requested, performed or completed, or when requirements have changed. Because Teva has combined Integrity Manager with MKS's Source Integrity software configuration management tool, programmers can check out the source code needed for the change request. All the changes are also recorded and compared against the details in the request for the change. As a result, Teva can "freeze" an activity during the development process to see what changes were made before or after that point.
"We're controlling things seven time zones away, [and] this rolls out a clean pattern of what the heck happened in any situation," Loane says. "It is not hard to prove what you did."
But automating the process had its challenges. First, Teva tried to replicate the paper process in the tool, which Loane says amounted to "automating a bad process and making it worse." Then the company took several months to devise a new process that treated all development as change, including new development and changes to existing systems, he says. In addition, the company began using the MKS tools to provide authorization for user access that required approval from a manager.
Since it ironed out those problems, Teva has been through two successful audits for Sarbanes-Oxley compliance, Loane says. In addition, the tool has helped to boost the quality of overall application development because the company added a step in the process to query the requester of the change about his satisfaction with that change.
"It is a neat check to make sure we are really listening to what people are saying," Loane says. "We haven't gotten any requests for rework after the fact. Everyone knows we are going to ask the user if they got what they asked for, [and] it tends to improve the quality overall."
ADM Investor Services Inc. last year expanded its use of Alexsys Corp.'s team management tools. Instead of just tracking help desk problems, it's now used throughout ADM's development process as part of Sarbanes-Oxley compliance, says Sam Helmich, vice president of technology at the Chicago-based futures trading company.
The subsidiary of Archer Daniels Midland Co. reconfigured the system so that as employees put in requests for programming projects, those requests are automatically sent to be approved by managers and reviewed by business analysts. They are then sent to the developers and testers who perform the work, he says. Before going to production, the original requester can review proposed changes to see if they meet the business need, Helmich says. The system also documents installation instructions and can allow the installer to acknowledge that such instructions were followed, he adds.

Tracking Changes
The Robert Mondavi Corp. is using TeamTrack process and issue management software from Serena Software Inc. to help support regulatory compliance, based on the advice of auditors who saw the tool being used to track and prioritize application change requests, says Brian Shelden, director of IT at the Oakville, Calif.-based winemaker.
Mondavi has also begun using TeamTrack to track changes made to applications, from the request for a change all the way to production, Shelden says. For example, the tools are used to document when changes are made in response to calls to a help desk or to track product price variations from state to state, he adds.
"[Sarbanes-Oxley] requires us to document where the request was coming from, who requested change, what review process that went through, who was involved in approving those changes and what changes where made to ERP applications," Shelden says. "TeamTrack allowed us to have an audit trail of that process."
John Hagerty, an analyst at AMR Research Inc. in Boston, says most companies working to comply with Sarbanes-Oxley have yet to use software to document application development processes. Most, he says, are still using manual processes for change management because they have not seen tangible advantages in using IT for compliance.
Making changes to applications "can change or invalidate the controls that have been put in place to run the business," Hagerty says. "Or, companies will make a change and forget to change the documentation when they should be making the changes to the written documentation and then making changes to the system."