THE GREENING OF THE IT SECTOR:
Problems and Solutions in Managing Environmental Compliance

by Tom Butler and Damien McGovern, The Cutter Edge, Vol 21, No 2

IT manufacturing organizations face both regulatory and competitive pressures to adopt ‘green’ strategies for manufacturing their products. While the European Union (EU) and its member states are leading the regulatory charge, others are following hot on their heels, each with its own regulatory take on what is, and is not, acceptable to put into products [5]. Keeping track of a mountain of legal instruments, regulatory information, and associated compliance imperatives is proving a daunting task for organizations trading in the global marketplace [3,7]. Growing societal concerns about the environmental impacts of IT products are also exercising the minds of corporate executives, as customers are switching to ‘greener’ IT products, not only on the basis of what is in them, but also in terms of their energy and carbon footprints, whether in relation to their manufacture or use. Thus ‘going green’ has become not only a responsibility for environmental sustainability [14], but also a competitive and regulatory imperative for IT organizations [1,3].

It is one thing to proclaim that products are green — and quite another to offer proof of it to regulators and end users. One way of doing this would be to provide evidence of compliance with regulatory policies and imperatives, but this is easier said than done [1,11]. For example, governance, risk, and compliance (GRC) officers and product design engineers would need to know what those regulations are, what they apply to, and what the implications of compliance imperatives are for products, present and future. As with other information-related problems, high-tech firms are adopting software applications to inform their decision making. In this article, we describe the growing number of environmental mandates that are driving organizations to adopt such solutions to manage environment-based regulatory compliance and risk. We then present the overall design and underlying features and functions of an ideal environmental compliance management system (ECMS) based on our experiences in the area and our analyses of solutions currently in the marketplace. We hope that this will help business and IT professionals make an informed selection of an ECMS in order to transform their firms into green organizations.

The Greening of the Regulatory Environment
Recent EU regulations, such as the Restriction of Hazardous Substances (RoHS) directive, the Waste Electrical and Electronic Equipment (WEEE) directive, and the Registration, Evaluation, and Authorisation of Chemicals (REACH) directive, have enormous implications for IT manufacturers operating globally [4,9,12]. The WEEE and RoHS directives, which the EU introduced in 2002, have resulted in highly complex legislation in the EU’s 27 member states as the directives were implemented into legislation in the following years. Consequently, neither WEEE nor RoHS lends itself to easy comprehension, application, and integration into an organization’s research, development, manufacturing, and logistics processes [15]. If this were not enough to worry GRC executives, the EU’s proposed Eco-Design for Energy-using Products (EuP) directive — which regulates and mandates disclosure of energy consumption for all electric and electronic goods, including IT products — was introduced in 2005.

In June 2007, the task of maintaining compliance became even more onerous for the IT manufacturing industry and related sectors as the new REACH directive came into force. This new law requires organizations to specify the possible dangers of combinations of chemicals present in their products not only on disposal, but also while in use [4]. This is a daunting prospect given that there were over 100,000 untested chemicals on the market prior to 1981, safety details on 99 percent of which are described as ‘sketchy’ by the EU. Significantly, only the 2,700 or so new chemicals introduced since 1981 were subject to rigorous testing under previous legislation, while REACH now encompasses all substances put on the market. The EU estimates that more than 1,500 substances will be on its restricted list of ‘substances of very high concern’ (SVHC) by mid-2008 [6]. As IT manufacturers are classified as ‘downstream users’ (including original equipment manufacturers, or OEMs) and covered under REACH, they will be legally obligated to demonstrate compliance and ensure that their products, and the substances they contain, are safe to put onto the market.

While the EU’s environmental laws have received much attention, others are no less stringent. The US Environmental Protection Agency (EPA) has issued a raft of legislation covering all hazardous substances across the whole range of manufacturing sectors, while Japan also has highly demanding laws [9,10]. Over the last two years, Korea, Australia, Canada, and US states such as California have introduced legislation similar to the RoHS and WEEE directives, while in China, a law known as the China RoHS, or the ‘Administration on the Control of Pollution Caused by Electronic Information Products’ directive, came into force in March 2007. Interestingly, China WEEE followed in its wake.

The need to address compliance legislation in different geographical locations poses a challenge to global manufacturing organizations, and determining the applicable regulation for a given geographical area is complicated by uncertainty about which products are covered by, or exempt from, different sets of seemingly conflicting regulations [10]. Thus, regulatory pressures are presenting IT manufacturing firms with serious difficulties in terms of compliance, as shorter product lifecycles and longer product lines have increased the use of materials that are deemed hazardous to the environment and, ultimately, to human health [1,3]. Our ongoing research suggests that there are in excess of 1,324 environmental regulations that global IT manufacturers need to consider, and we expect this number of increase significantly.

Counting the Costs of Compliance and Non-compliance
Regulatory compliance can be an expensive proposition for companies worldwide. Meeting the requirements of the US Sarbanes-Oxley Act (SOX) cost large US firms over $5 billion in 2004, with $1 billion of this being spent on IT [16]. The costs of meeting EU and environmental regulations globally will dwarf this figure. For example, the European Commission estimates that the cost of being in compliance with its new REACH legislation will be upwards of £5.2 billion ($7 billion) [6]. Independent research also reports that the cost of compliance with RoHS and WEEE is approximately 2-3 percent of the cost of goods sold, a not insubstantial amount given the size of the IT sector [17].

However, while the costs of ensuring compliance are considerable, the costs of not being in compliance are even higher, as companies run the risks of exclusion from key markets, stopped shipments, and product recalls, with a corresponding loss of revenue and potentially disastrous consequences for brand image and/or corporate reputation [1,3,7]. In the case of a serious breach of compliance regulations, firms may also face hefty fines and/or criminal prosecutions [3]. In the EU, for example, Finland imposes a maximum fine of approximately £850,000 for being in violation of RoHS, with all business activities suspended indefinitely; Germany has a relatively small fine of approximately £50,000, with a recall of all products; while Ireland may levy fines up to £15,000,000, can impose prison terms of up to 10 years, and will ask for a recall of violating products [15]. Being in violation of RoHS (and now REACH) in one EU member state also generates problems in the other 26, with cumulative fines, product recalls, and prison time in several jurisdictions for offending organizations and their executives. Therein lies the headache for GRC executives, CIOs, and IT executives who need to select IT-based solutions to manage product compliance and minimize risk.

Enterprise GRC Solutions . . . Well, Almost!
The spread of regulatory controls across all business and industry sectors has given rise to an integrated set of GRC activities across the enterprise whose functions are to ensure corporate governance, risk management, and regulatory compliance. It is clear that SOX provided a focal point for software vendors to integrate existing compliance and risk platforms (e.g., those serving the pharmaceutical industry and the life sciences in general) with emerging corporate governance solutions. This led to enterprise GRC systems for use across all industry sectors [13] and ECMSs [8], which are targeted at the life science industries.

CIOs and IT executives in high-tech firms could be forgiven for assuming that such ‘enterprise systems’ would help them manage compliance and risk with regard to environmental regulations on a global basis. In reality, environment-based compliance and risk management in the electrical and electronic industries, including the high-tech sector, is the poor relation of corporate GRC initiatives. A recent report by an analyst firm evaluated the top 15 enterprise GRC vendors out of a total of 114 providers [13]. Only once in this extensive report was there any reference to environmental compliance, and this was only in passing. A closer examination of the top six vendors — BWise, AXENTIS, MetricStream, OpenPages, Paisley, and QUMAS (Oracle and SAP declined to participate) — revealed that they were not covering environment regulations in their product offerings. AXENTIS, for example, focuses on SOX, information privacy, ethics and integrity, legal and regulatory issues, and IT GRC in its enterprise system, while QUMAS offers much the same in the financial and life sciences sectors. Perhaps it will require an Enron-like event to galvanize senior executives to take seriously their companies’ obligations to comply with the various flavors of WEEE, RoHS, EuP, and REACH — and for vendors to address these regulations in their GRC products.

While concrete information on Oracle’s GRC activities is hard to come by, SAP presently has a comprehensive suite of environment-based solutions; namely, SAP Environmental, Health, & Safety (SAP EH&S); SAP xApp Emissions Management (SAP xEM) compliance management; SAP Compliance for Products (CfP); and SAP REACH solution. Oracle’s recent acquisition of Agile Inc. is a signal that it is serious about competing in the environment space, as Agile’s Product Governance and Compliance solution is said to help organizations manage product, substance, and material compliance against standards and regulatory requirements. But SAP and Oracle aside, what, you may ask, is the state of play in the high-tech sector in terms of IT support for product compliance with environmental regulations on a global basis?

From Ad Hoc ‘Solutions’ to True Compliance
A recent study by industry analyst Jim Brown has revealed that nearly 80% of high-tech manufacturing companies lacked a cohesive IT infrastructure to track, audit, and/or manage product compliance. Most companies rely on a variety of solutions that are not properly integrated and do not provide the information needed to meet environmental regulations [3]. Throughout 2006 and 2007, Damien spoke with executives in more than 50 global organizations across a range of industry sectors while conducting market research on the use of IT to manage environmental compliance. His findings concur with Brown’s. Organizations admitted to using a variety of ad hoc internal solutions based on, for example, Excel spreadsheets, rudimentary database systems, and point solutions from external vendors. GRC executives in these organizations acknowledged that their ad hoc solutions were unable to manage environmental compliance product by product, component by component, across all policy/regulatory areas. Yet some of the same organizations appeared to possess relatively sophisticated GRC strategies and solutions aimed at financial and IT compliance.

In assessing how high-tech manufacturers are addressing the problem of product compliance, industry expert German Avila argues that a compliance management solution needs to be able to account for rapidly changing environmental regulations across multiple markets and geographies. Furthermore, such systems also need to possess material compliance analysis capabilities, in addition to features that help decision makers reduce the cost of compliance [1]. The implication here is that, as of 2006 (when Avila made this argument), vendor-based solutions that met these criteria were thin on the ground. That is not the case in 2008, as there appear to be a menu of available ECMS options (albeit relatively smaller in number than in the enterprise GRC category). CIOs and IT executives will be instrumental in choosing the most suitable solution to help their organizations comply with environmental regulations globally, while offering tangible evidence to customers that their products are indeed green. In the following section, we will discuss the functions and features of an effective ECMS.

Toward an Integrated ECMS
Just as enterprise GRC systems evolved from vendors’ previous offerings (e.g., QUMAS and its document management solution), ECMSs emerged from product lifecycle management (PLM) systems (e.g., EMARS from Synapsis Technology, Inc., and Product Governance and Compliance from Agile Inc.), enterprise resource planning (ERP) systems (e.g., CfP from SAP AG and TechniData AG), or supply chain management (SCM) systems (e.g., E2open, Inc.’s, Eco-Compliance solution). While these types of ECMSs grew out of a product-to- compliance perspective, in drafting this article we conducted a comparative analysis of current solutions and discovered that the Compliance-to-Product solution (C2P) from Compliance & Risks Ltd. was the only ECMS to have been designed and developed from a regulatory compliance perspective.

Depending on vendor architecture, the solutions offered by the above vendors can be deployed as:

• Standalone applications (off-the-shelf packages that are configured or customized).
• Hosted solutions (e.g., compliance-as-a-service; for examples, see [2]).
• Either of the above, integrated with existing PLM/ERP systems.

By examining the features and functions of environmental compliance solutions currently on the market, we can arrive at a comprehensive set of characteristics that an ideal ECMS should possess in order to support key environment-based, product-related GRC processes. First of all, an ECMS should have a well-designed, extensible database to capture: (a) regulations and relevant product/subassembly/parts/materials data, and (b) all data generated during the compliance process, including supplier compliance declarations, organizational and product compliance documentation and reports, instant messages, e-mail threads, external legal reports, and so on. The database would need to store RoHS-related documentation and compliance reports for four years and REACH reports for 10 years, as there are regulatory requirements to do so. In addition, the system would need to be integrated with the organization’s document management system in order to upload all relevant reports and documents. All of this is necessary to help organizations meet due diligence obligations and perform liability management. While the database is the core of the system, our analysis of the various ECMS offerings currently available (from vendors such as SAP AG, TechniData AG, E2open, Synapsis Technology, etc.) indicates that an ideal integrated ECMS should have a sophisticated set of functions and features that support the following key compliance and risk management processes:

• External compliance requirements-gathering process.
• Supply chain compliance process.
• Compliance management process.
• Knowledge sharing processes.

External Compliance Requirements-Gathering Process
The nub of the problem facing GRC officers and product stewards is that they and their firms often do not have the necessary legal knowledge and capabilities to interpret, evaluate, capture, and store all relevant compliance-related information. Similar issues arise in relation to evaluating the compliance status of sub components and materials from suppliers. These activities are usually outsourced to legal experts, who respond with voluminous reports that do little to lift the burden on GRC staff. On the other hand, in-house compliance requirements gathering demands strong legal competencies by GRC officers, as their focus must be on the jurisdiction, instrument type, and legal basis for compliance imperatives. The scope of this process encapsulates all of the business territories in which a company operates, in addition to juridico-political territories, future regional implementation areas, and so on.

Identifying, managing, and tracking compliance imperatives is complicated by the fact that ‘parent’ legislation (e.g., an EU Directive to member states) often gives birth to different regulatory ‘child’ legislation. That is to say, the resulting compliance imperative inherits the general characteristics of a directive but may differ in the scope or detail of its application in particular member states. For example, the EU’s WEEE and RoHS directives provided the basic framework and baseline for legislation in the 27 EU member states, but the regulatory instruments drafted in each country differ slightly (see [9] for examples), creating a compliance management nightmare for high-tech manufacturers doing business in the EU. So, for instance, while the EU RoHS lists just six hazardous substances, Norway RoHS lists 18.

This complexity stands in stark contrast to the type of support provided by the majority of ECMSs, in which users create static ‘lists’ of compliance requirements rather than the multidimensional data structures needed to model compliance imperatives and requirements. (Note, too, that such structures need to be updated in real time, a capability most ECMSs currently lack.) In contrast, the ideal system will enable legal experts and GRC officers to collaborate in capturing all global regulatory imperatives and to represent them not as one-dimensional lists, but as complex data structures that can be easily navigated and mapped onto products, subassemblies, parts, materials, and substances. In order to support this GRC process, an ECMS should include:

• Database representations of regulatory and legal compliance data, including all related legal requirements, related organizations, geographical areas impacted, material and substance exceptions, and exemption impacts.
• Features that help users enter and present the meaning of legal terms and definitions in order to facilitate their analysis and understanding.
• A smart links feature that would illustrate the relationship between regulations and requirements and their impact on a product or activity.

Supply Chain Compliance Process
This ECMS process focuses on capturing all compliance-related details on materials used in product subassemblies, component parts, and so on. Thus, a typical system should support the upstream electronic transfer and processing of all materials composition declaration (MCD) documents from suppliers. When the organization is itself a supplier, the ECMS should produce MCD documents for customers. Also important is the capture of compliance declarations for all supplier products, materials, and substances. The scale and complexity of this sub-process cannot be underestimated, as there are many thousands of materials, subassemblies, and so forth, that IT manufacturing organizations source from suppliers. Of course, the data collected in declarations needs to be scaled with the actual quantities of materials supplied: thus, data from the bills of materials (BOMs) needs to be integrated so that the ECMS can calculate the exact amounts of controlled materials being put into products.

In order to execute electronic data transfer from suppliers, the ideal ECMS would need to integrate with an organization’s SCM system or, in the absence of such a system, would need to support a range of data transfer standards for direct data transfer. For example, the industry-wide IPC-1752 data standard provides an XML schema for data transfer, while RosettaNet (a standards organization that promotes collaborative B2B commerce) also has XML schemas for PIP 2A15 (Request) and PIP 2A13 (Declaration) data exchange. There is, in addition, a new international standard based on the JIG (Joint Industry Group) and IPC 1752, which may need to be supported. Finally, it is also clear that legacy standards, such as Excel, must be accounted for.

In situations where data exchange standards do not yet exist, or are incomplete for the purpose at hand, a proprietary standard may be used, such as SAP’s CfP Data Exchange Format CfPXML. Proprietary standards may be deployed easily to suppliers using Web services, provided the ECMS or SCM system supports them. In the case of data transfer from the BOM, the ECMS needs to transfer data from the company’s ERP system. If the ECMS vendor is not the ERP vendor, then integration, typically via XML, will be required.

Compliance Management Process
GRC executives and other users need full visibility into the status of a company’s compliance activities. In most scenarios, manufacturing organizations will set down product specifications, including materials and so on, to be used in sub-components at the R&D/product design stage. Once the product details are entered into the ECMS, these may be matched against all known regulatory compliance imperatives in the system to determine compliance or noncompliance. However, IT manufacturers may dynamically change product subassemblies in line with customer requirements (e.g., Dell’s mass customization) or by procuring from different suppliers at different times. Thus, during production, a product’s compliance profile may change from that of the original design. As a result, the ECMS may need to be integrated with, and gather data from, the production module of the adopting organization’s ERP system. Once the compliance status of a product that is put on the market is ascertained, disclosure must take place. If the ECMS is to accomplish this electronically, it must support appropriate document/data exchange formats, such as the IUCLID (International Uniform Chemical Information Database) XML schema for REACH and so on.

The most important feature of an ECMS would be its ability to show GRC professionals and related users the impact of regulations on products, subassemblies, parts, materials, and substances in real time. This means that once a regulatory requirement changes or a new one emerges, and it is entered into the system, the status of all related products should change, down to constituent materials and on to parts provided by suppliers. The system should make these changes visible to all users (e.g., through the use of flags).

Analysis features would also be important, in order to analyze compliance imperatives and requirements impacts on products, subassemblies, parts, materials, and substances. Such features should also encompass facilities to map supplier data against compliance requirements, so as to identify noncompliant parts, materials, or substances.

Most enterprise GRC systems and ECMSs feature a personal dashboard. A dashboard for an ECMS should, at base, display compliance issues, searches, bookmarks, reminders, alerts, action plans or to-do lists, and instant messages in order to facilitate individual decision making. The dashboard should also be part of the application’s workflow capabilities and support access to the following features:

• An issue management feature to help GRC professionals, product design engineers, and SCM staff collaboratively evaluate, escalate, and address product/materials compliance issues.
• A risk ratings feature to display a product’s risk status for each compliance issue.
• The ability to allow GRC managers to delegate and monitor issues and responsibilities to relevant staff.
• An action plan feature, so that GRC staff can associate milestones with, and manage, tasks for each issue.
• An exception or alarm feature to remind users of, and help them track, the status of assigned areas of responsibility.
• The ability to create custom reports according to the company’s issues and products.
• The ability to show multiple views so that users can navigate between summary views and more detailed information

Knowledge-Sharing Processes
A full-featured ECMS must also offer knowledge-sharing capabilities and tools. The purpose of these features would be to provide an additional dimension to enhance the understandings of GRC officers, design engineers, and other relevant stakeholders in order to facilitate compliance-related decision making. Some of these features might appear on, or be accessible from, the dashboard. Such capabilities could include:

• The ability to capture discussion threads — both instant messaging or e-mail threads — between users on any topic.
• The facility to create contexts (i.e., background information) for classifying and reporting the evolving impact of compliance issues on products and so forth.
• A history of all changes to regulatory imperatives and requirements, regulatory updates, and associated changes to the design and makeup of products, subassemblies, parts, materials, and substances. This would also encompass audit trails of supplier declarations for liability management and due diligence reporting purposes.
• Automatic e-mail and/or instant messaging notification of any changes in the regulatory status of products, subassemblies, parts, materials, and substances. The ECMS should also highlight the relevant areas covered and trigger alerts to dashboards.

As with all knowledge-sharing tools, the ECMS should possess an attachment feature to provide links to, or attach directly, related documents (legal interpretations or advice, industry journal articles, reports, etc.) that describe in-depth compliance imperatives, requirements, issues, impacts, or data on products, subassemblies, parts, materials, and substances. Of importance here is the ability to attach independent laboratory analysis reports with supplier MCDs for validation of content and accuracy. Finally, sophisticated search features are required to allow users to run queries and produce reports based on specific parameters.

Conclusions
High-tech organizations require sophisticated IT-enabled solutions to manage the complexity of the global regulatory environment; however, selecting and adopting an ECMS is no easy task for GRC and IT executives. Organizational preferences will determine whether the chosen application is to be a stand-alone, off-the-shelf software package or a hosted solution (i.e., compliance-as-a-service). Issues such as total cost of ownership and return on investment will inform such decisions, as will an IT group’s wish to adhere to corporate standards. For example, an organization running SAP might, on the recommendation of IT executives, wish to adopt its ECMS suite — namely, SAP EH&S, j, CfP, and REACH solutions. Conversely, given SAP’s reputation for being overly complex and hard to use, GRC officers may prefer an ECMS that focuses on core compliance processes.

Whatever ECMS solution is chosen, it must address one of the major challenges facing GRC officers; that is, the need to understand, from the outset, the jurisdiction, instrument type, and legal basis for compliance imperatives and their impact on a company’s products. To enable this understanding, the ECMS will need to contain all relevant compliance data from diverse regulatory sources. Vendor and application support for addressing this problem is, we argue, a prerequisite for selecting a particular offering. If this data is not forthcoming, then no matter how sophisticated or well integrated an ECMS is, it may suffer from the ‘garbage in - garbage out’ problem, with adverse consequences for the adopting organization. To put it another way, adopting an ECMS that does not come preloaded with regulatory data would be like giving a child an electronic toy without including the batteries.

In conclusion, we hope we have shed some light on the challenges organizations face in trying to comply with the burgeoning number of environmental regulations. We also hope we’ve illustrated how the features and functions of an ‘ideal’ ECMS could solve compliance problems for IT manufacturers, thereby enabling — and certifying — their green transformation.

REFERENCES
1. Avila, German. ‘Product Development for RoHS and WEEE Compliance.’ Printed Circuit Design & Fab, 1 May 2006, pp. 28-31.

2. Brodkin, Jon. ‘Hosted Software Manages Environmental Compliance.’ Network World, 1 August 2007.

3. Brown, Jim. The Product Compliance Benchmark Report: Protecting the Environment, Protecting Profits. The Aberdeen Group, September 2006.

4. Bush, Steve. ‘EU’s REACH Directive Will Hit Electronics Firms.’ Electronicsweekly.com, 28 February 2007.

5. Drahos, Peter, and John Braithwaite. ‘The Globalisation of Regulation.’ Journal of Political Philosophy, Vol. 9, No. 1, March 2001, pp. 103-128.

6. European Commission. ‘The New EU Chemicals Legislation — REACH,’ updated 23 February 2007 (http://ec.europa.eu/ enterprise/reach/overview_en.htm).

7. Goosey, Martin. ‘Implementation of the RoHS Directive and Compliance Implications for the PCB Sector.’ Circuit Design, Vol. 33, No. 1, 2007, pp. 47-50.

8. Hayward, Ken. ‘Enterprise Compliance Management Systems (ECMS): Choosing the Right System and the Real Costs Involved.’ Pharma IT Journal, Vol. 1, No. 2, April 2007, pp. 2-5.

9. Hristev, Iliyana. ‘RoHS and WEEE in the EU and US.’ European Environmental Law Review, March 2006, pp. 62-74.

10. Kellow, Aynsley, and Anthony R. Zito. ‘Steering Through Complexity: EU Environmental Regulation in the International Context.’ Political Studies, Vol. 50, No. 1, March 2002, pp. 43-60.

11. Kerrigan, Shawn, and Kincho H. Law. ‘Logic-Based Regulation Compliance-Assistance.’ Proceedings of the 9th International Conference on Artificial Intelligence and Law (ICAIL 2003), ACM Press, 2003, pp. 126-135.

12. Kubin, Richard. ‘Eco-Compliance: Implementing Material Declarations to Support RoHS and WEEE Compliance.’ E2open Inc., 2007 (www.e2open.com/resources/download.php?title= E2open:__Eco-compliance_White_Paper&id=8).

13. McClean, Chris, and Michael Rasmussen. The Forrester Wave: Enterprise Governance, Risk, and Compliance Platforms, Q4 2007. Forrester, 21 December 2007.

14. Murugesan, San. ‘Going Green with IT: Your Responsibility Toward Environmental Sustainability.’ Cutter Consortium Business-IT Strategies Executive Report, Vol. 10, No. 8, August 2007.

15. Pecht, Michael et al. ‘The Impact of Lead-Free Legislation Exemptions on the Electronics Industry.’ IEEE Transactions on Electronics Packaging Manufacturing, Vol. 27, No. 4, October 2004, pp. 221-232.

16. Smith, Heather A., and James D. McKeen. ‘Developments in Practice XXI: IT in the New World of Corporate Governance Reforms.’ Communications of the Association for Information Systems, Vol. 17, No. 32, May 2006, pp. 1-33.

17. Spiegel, Rob. ‘Cost of Compliance — 2 to 3 Percent of Cost of Goods.’ Led-Free Zone Blog, Design News, 6 September 2005.

Tom Butler is a Senior Lecturer in business information systems at University College Cork, Ireland. A former IT professional, Dr. Butler worked for 27 years in the telecommunications sector. His research focuses on investigating the origins of firm-level IT capabilities and the design, development, and implementation of information systems. Beginning in 2003, Dr. Butler was lead researcher and project manager on two major action research-based initiatives on the design, development, and deployment of IT-enabled knowledge management systems for the UN Population Fund Agency and the Irish government. He has been conducting research into the design of compliance knowledge management systems since 2005. His work has been published in the Information Systems Journal, the Journal of Strategic Information Systems, the Journal of Information Technology, and in the proceedings of major international conferences such as ICIS, ECIS, and IFIP 8.2 and 8.6. Dr. Butler can be reached at tbutler@afis.ucc.ie; http://afis.ucc.ie/tbutler.

Damien McGovern is founder and CEO of Compliance and Risks Ltd. (C&R). Mr. McGovern qualified as a lawyer and spent a considerable portion of his career working for Deloitte & Touche in Europe. It was in this capacity that he identified the need for a dedicated compliance knowledge management system (CKMS). Consequently, he began to draft a blueprint for his C2P (Compliance-to-Product) application in 2001. His CKMS concept has been tested and validated by C&R’s clients and is now fully operational in several sites. C&R has its headquarters in Cork, Ireland, while its software development team is located in Northern California and in Ireland. C&R’s team of governance, risk, and compliance (GRC) domain experts includes lawyers in Ireland, the UK, Europe, and the US. Mr. McGovern can be reached at Compliance and Risks Ltd., National Software Centre, Mahon, Cork, Ireland; d.mcgovern@complianceandrisks.com.

<back to news and articles