The past two decades have seen many technological advances, including new governance, risk, and compliance (GRC) capabilities to address corporate security concerns, such as unauthorized access to data and financial fraud — concerns that take on added importance for the growing number of global businesses.
An SAP customer since 1999, Eli Lilly and Company — a corporation that has been manufacturing human pharmaceuticals and animal health products for more than 140 years — has steadily expanded its single SAP instance into a larger footprint as it has brought worldwide affiliates onto the platform. In 2010, to help secure its global IT landscape, Lilly began a four-phased global services delivery (GSD) project with the goal of implementing financials, supply chain, and human resources systems. Today, essentially all of Lilly’s global business runs on SAP ERP 6.0 and 17 other SAP systems, including SAP GRC solutions to support security and standardization.
“One of the important parts of the GSD project was not only implementing SAP software as a backbone, but also moving to four regional shared service centers located in Ireland, Malaysia, Mexico, and Indiana,” says Mike Burnham, Director of the Finance Business Process Knowledge Center at Lilly. “The project involved pulling business processes out of the affiliates and regionalizing them in the shared service centers at Lilly.”
Creating shared service centers was only the beginning of Lilly’s path toward achieving standardization throughout the company, however — Lilly decided to also add functionality from SAP Process Control to its GRC implementation to enable process automation.
Continuing the Standardization Journey
Standardizing and automating processes were the main motivators for Lilly to enhance its GRC landscape. Following SAP’s security model, Lilly had been keeping up with the software updates for SAP Access Control, SAP Identity Management, and SAP Global Trade Services throughout the years. In 2013, while planning an upgrade of these applications to version 10.0, Lilly decided to also implement SAP Process Control. “We chose SAP Process Control for two core purposes,” says Emily Swaim Damson, Security and Controls Consultant for the Finance Business Process Knowledge Center at Lilly. “One was to be the repository for our control matrix, which is where we store the information for the Sarbanes-Oxley (SOX), segregation of duties (SoD), and operational controls that we use to manage the business — and the other was to automate those controls.”
Sometimes viewed as the most crucial controls, SOX controls ensure the accuracy and security of data reported within the financial statement, while SoD controls prevent employees from performing fraudulent activity and ensure that business processes are completed correctly. With SAP Process Control, Lilly wanted to improve the way these controls were managed.
Previously, the financial control organization used individual spreadsheets to identify the controls that were applicable for different sites and to manage the control structure regionally. The master control matrix was essentially a massive workbook — based on data from the various regional spreadsheets — with color coding to manage changes to the file over the course of a year.
It was time consuming to identify which controls were in place at any given moment in time. “Part of the driver to go toward SAP Process Control was that we wanted a real-time control repository that had date effectiveness and could more accurately reflect what the controls were for particular dates,” Swaim Damson says. “We wanted any changes to immediately show up on the control matrix at that point in time — versus having to go into a spreadsheet and make sure everyone understands that green means a control is effective as of one date, while blue means some other date.” Moving away from its spreadsheet-heavy model and automating those activities became a pressing matter for Lilly.
When controls were executed manually, we were not only hoping people were doing it on a timely basis, but more importantly, that they were performing them correctly.
— Mike Burnham, Director of the Finance Business Process Knowledge Center, Eli Lilly and Company
The Path to Automated Controls
After returning from an SAPinsider conference where she discovered the benefits of SAP Process Control, Swaim Damson — and others from the Finance Business Process Knowledge Center team — developed a business case for implementing the application at Lilly. Because the project would involve many manual technical activity to create the data sources and the business rules in the application, a lot of foresight and planning was required. “We looked at the time it would take to do the manual control maintenance, and we also looked at the benefits of automating it and the time we would save from the automation,” she says. “Then we networked that information through Lilly, got approval for the project, and began the implementation process in August 2013.”
The project took about six months in total, with help from an implementation partner for the first several months. Due to the concurrent scheduling of an SAP Access Control upgrade, however, the SAP Process Control project was put on hold for some time — eventually going live in July 2014, after the SAP Access Control upgrade concluded. The setback did not negatively affect the outcome, and the project was viewed as a success. “It was a good implementation plan from a process control perspective,” says Burnham. “The extra project time actually allowed us to develop more business rules to automate controls. Waiting to go live the following year did not hurt us in the long run at all.”
The bulk of the implementation work involved building all the data sources and business rules in SAP Process Control to perform the control automation. First, a data source is developed to identify specific data to pull from an SAP system to look for exceptions. Then a business rule evaluates that information and determines if any issues exist. “We created business rules to evaluate certain SAP tables on a daily basis to look for exception data — for example, to check if any changes were made to the table in the last day,” says Swaim Damson. “We built a data source and a rule to look just for that problem situation, and scheduled it to run every day to see if anything happened that someone needed to be alerted of.”
If SAP Process Control finds that certain flagged criteria are met, it automatically creates an issue and notifies the appropriate control owner directly in the system and also by email. If there is no exception, then it takes no action other than documenting the fact that it looked at the information. When control owners do receive alerts to look into a problem, they then have to document in the application an explanation of the exception before they can close the issue. This documentation is the information that auditors will reference to understand the exceptions when auditing the controls.
Today, the application users total around 200 control owners who receive the exceptions or issues. There are also a number of process owners who access the application — people who have an organizational responsibility to manage a particular process for the business. For example, there is a process owner for the company’s procure-to-pay process. Process owners aren’t involved in the day-to-day resolution of the control issues, but can see the number of issues identified by the system. Control owners are the individuals who receive SAP Process Control notifications of exceptions around this control. “An example in our purchase-to-pay area is a control in place for master data updates. There is a table in SAP ERP that stores information containing employee names and the values they are allowed to approve. Each employee is granted a unique authority to spend when it comes to purchase orders and invoices,” explains Swaim Damson. “A global data steward is tasked with updating this table once a year to reflect organizational or exchange rate changes, and SAP Process Control performs automated checks to monitor if anyone updates that table beyond that once-a-year time frame. The automated business rule detects when the table has been updated and sends an alert of any change to the control owner. The process owner has oversight through standard reports of the number of issues detected over the year and can ask the appropriate questions if there are changes.”
Another automated control Lilly uses relates to the order-to-cash process. This control applies to all the different global sales affiliates and ensures that at month end, when it’s time to close the books, all billing documents have been booked to accounting to ensure accurate financials. This example demonstrates how, in standardizing and automating a process, Lilly has improved the efficiency and performance of this control globally. “Previously, the sales sites would run a standard SAP report individually to ensure there were no items to be addressed. If there were no billing documents to book, they would sign a blank report and file that away,” says Swaim Damson. “The power of SAP Process Control is that it automates the running of that report so analysts no longer have to worry about doing it. If there are no issues, the tool automatically documents that, and the analyst can keep moving through the rest of the month-end activities. If there are problems, then it sends a notification to the control owner.”
The application also contains functionality that can be built into business rules called “business rule parameters,” which decrease development and maintenance efforts. This involves using a defined field in a rule as a variable when the value of the field may change depending on location. Using a business rule parameter for the order-to-cash control, for example, means no hardcoding of individual rules to apply unique company codes for each affiliate’s distinct sales organization. “Instead, we can write one rule and then have a variable that holds the appropriate value for each of the individual legal entities,” says Swaim Damson. “From a testing perspective alone, going from maintaining 70 rules to maintaining just one is a huge time saver.”
These processes are just two examples of how the performance of controls is now automated at Lilly. Other examples of how the business uses SAP Process Control include creating rules to ensure no one changes the system configuration to allow revenue to be recorded for sample or free-of-charge orders; no one edits existing billing documents after posting; or that no one can approve a journal voucher that he or she originally initiated. There are many other controls that need to be checked every day or every month, and Lilly is using SAP Process Control as the engine to perform that work, which otherwise someone would have to do manually.
We wanted a real-time control repository that had date effectiveness and could more accurately reflect what the controls were for particular dates.
— Emily Swaim Damson, Security and Controls Consultant for the Finance Business Process Knowledge Center, Eli Lilly and Company
Monitoring Capabilities and Results
The native integration capabilities of the application allow it to connect with any SAP system. Currently, Lilly is using it to perform standard security-related and IT checks and to monitor not just its SAP ERP system but 17 different SAP systems — such as SAP Advanced Planning and Optimization, SAP Business Warehouse, and SAP Supplier Relationship Management. “Right now, however, we are only using SAP Process Control to monitor and evaluate some controls in our financial, HR, and security areas of business,” says Swaim Damson. “We do not have anything yet in production that’s looking specifically at manufacturing or supply chain data.”
As SAP Process Control monitors all of Lilly’s SAP systems for problems, it also looks at its own tables and monitors itself to identify any automation that does not complete successfully. “We built a rule that tells the system to run a check on itself daily,” explains Swaim Damson. “It provides feedback each day alerting us that the system is still running and completing its jobs as scheduled — or if there’s a problem we need to look at.”
As part of this control check, the application will send an alert if a data source or a business rule has changed — changes that could affect testing or auditing of the control if the changes remain unnoticed. “If something changes that we hadn’t intended, that could lead to a problem,” says Swaim Damson. “We built a rule to monitor all its key control data and job scheduling data to ensure we know about any changes right away, so we can address them immediately and avoid any potential audit issues down the road.”
The testing of controls has improved significantly since the implementation of SAP Process Control. Before, there were several controls being executed at 70 different sites around the world with variability in terms of how different affiliates performed controls due to interpretation, language, and other factors. According to Swaim Damson, standardizing the global execution of its controls has been extremely beneficial to the business. “Now, we can standardize how these controls are performed globally by how we write the business rules, and they are applicable to every site in the same manner,” she says. “Everyone performs the controls in the same way, seeing the same sorts of results — if there are results — and then having to work with those. That standardization has been a huge benefit for us.”
The monitoring results from SAP Process Control are delivered to users — with foundational data that is geographically and functionally specific — via dashboards, which give business owners global visibility into control performance. “Dashboards are very important to help measure and analyze the general health of our overall control framework,” says Burnham. “SAP Process Control not only provides a control repository, but also allows us to develop the business rules necessary to perform the control execution — and having this all in one automated tool really helps us out on our side.”