The Evolution of Software Systems for Internal Controls (by Rino Belloni & Ercole Belloni)

The evolution of management software has led to the birth of ERP systems (Enterprise Resource Planning) as a response to the need to facilitate interaction of the many applications created to automate operational activities. ERP is a software system made up of several vertical modules, where each one designed for the automation of a specific business process. The advantage of the aggregation is to allow a   greater ease of sharing the managed information.

In the absence of an integrated solution, following the acquisition of a new software in the system infrastructure, it was also necessary to implement the interface with existing applications, in order to make its own information available and to obtain the availability from the others. In this situation, the problem is that as the information structure of one application changes, each interconnected one needs to adapt the interfaces. The complexity of this software architecture grows exponentially with the increase of interconnected applications, making its management very expensive (Figure 1).

The need for integration of software applications has triggered the development of sharing tools over time, in terms of data structures (ETL, DWH), functionality (BPM) and reporting (OLAP, BI). Nevertheless, the proliferation of actors and technologies of these instruments has determined an even greater degree of complexity. In fact, the emergence of ERP solutions is the direct consequence of this technological evolution, whose result was to bring under one system different applications (modules), having interactions already developed within the system, which also includes additional tools that facilitate them.

However, the use of integration tools still finds a lot of space, since the adoption of ERP systems is onerous and therefore limited, without covering all management areas. Anyhow, the main reason must be found in the growing need to exploit company information with analytical and control objectives. These requirements are widespread in almost every business activity at every operational level, but especially in the decision-making processes that often need to exploit management information coming from multiple areas.

Figure 2

The evolution of management software leads to the integration of the majority of operational controls. Many decision-making processes are also supported by specific software, satisfying further control needs. As depicted in Figure 2, if we hypothesise to increase the implementation of every control requirement in the management systems, the base of the pyramid would expand to the top. This scenario is difficult to realise because of the excessive complexity in the resulting system, which would contravene the need to keep management activities separate from control activities.

By shifting focus to the informative needs in the upper part of the pyramid, thus making an accurate transposition of software evolution from the management field to the control world, it is clear that the availability of all organizational information is not just an advantage, but a primary necessity. It is unthinkable to be able to analyse an organizational resource without having knowledge of all the information that concerns it, regardless of the contexts and therefore of the systems in which it is managed.

Figure 3

As for the management system, the history of the corporate control world was born with isolated initiatives, transformed into more or less technological  developments (often with office automation tools) and with scarce or non-existent interactions with other control and management activities. Especially in this case, the increasing complexity of analysis has demanded the construction of forms of dialogue between the different adopted solutions, requiring considerable efforts to develop sharing functions.  This creates an extremely complex system, similar to the non-integrated management solution described previously (Figure 1).

Now imagine a solution for the internal controls that follows the development process of ERP systems, where every need is addressed by a specific module (Audit, Compliance, Risk Management, ...), realized with the same technology and the same IT framework. This kind of system (GRC) is far less complex, since, if well designed, it leads to a considerable reduction in the complexity of interactions with a linear growth as the number of systems increases, as shown in Figure 3.

The situation previously described is an important step forward in the implementation of control systems, but it is possible to go further. While management systems are composed by separate modules, addressing different areas that are more or less correlated between them, it is not the same for control systems.

Control needs have become increasingly important over time, requiring continuous evolution and different approaches. It is easy to think about the transformation of control activities from mere investigation, to the evolution of the audit process, up to the use of the "Audit Universe" for analysis needs. Then, if we consider Risk Management activities and the more recent ones of Compliance and Supervisory Body functions (considering also higher-level departments and top management), the first objective is always to provide access in a shared system. Each of these control functions, while carrying out its activities, provides its expertise to the overall evaluation, gaining indisputable advantages from the knowledge of the evaluations of individual actors who operate in other fields.

Therefore, it is not optimal to conceive a control system as an integration of different modules that exchange information; certainly, it is better to organize it as a single system that offers tools to manage all information shared, in which every actor contributes to his own and can consult those of others.

Many elements on which control activities are focused are easily identifiable, but they must be structured appropriately: starting from the ones for the specific control area (Audit Universe, Risks Catalog, External Regulations, Crime Categories), proceeding with the unique organizational ones (Business Units, Employees, Organizational Chart, Processes Catalog, Roles, Safeguards), up to considering the information structures to be taken from the management field (Accounting Plans, Balance Sheet Items, Cost Centers, Products, Stakeholders) with eventual details of the operating data that may support the assessments.

The first elements are exclusively related to the proper control function, which independently establishes the information and the methodological evaluation schemes in its competence area. The second ones describe the organization; they need a periodical information update to be collected in the proprietary systems and they constitute the elements to which all the results of the control activities are going to be reported. The last elements are those that support the evaluation activities, owned by the management systems and they should be already structured and available in the first level corporate DWHs.

With such a well-organized information system, it is easy to set up the specific operating environment for each control function. The first step is defining which elements, among those available, are going to be taken into consideration and which are the correlations to be used (the organizational ones are predefined).

For example, if we want to try the basic approach of a control scheme oriented to the implementation of D.lgs. 231/2001 (Supervisory Body), the elements  selectable within the mosaic are: Employees, Business Units and Processes, taking advantage of the existing relationships (Figure 4). Crimes are organized into categories and individual schemes, as described in detail in the decree, and they are managed by the methodologist when facing any normative change. The expert then proceeds in correlating the organizational elements with the crime ones, describing effectively in which activities, described in the processes catalog, every single type of crime can be potentially committed. For this purpose, it is necessary that there is a specific software feature, while another managerial functionality must allow the determination of the sensitivity level through the compilation of a scheme that follows the official methodology. The scheme must be set up to meet current needs, but it should be modifiable for future ones. Business units and employees are involved in the process through the easy identification of organizational relationships and occasionally (important changes) and periodically (information and evaluation campaigns) called to contribute to survey and evaluation activities.

Following the example just described, it is possible to organize similarly every other model: to correlate the prerequisites of an external regulation with the  processes to evaluate the coverage of the existing organizational safeguards; to record the processes risks and verify the adequacy of controls; to certify assets of the accounting plans by evaluating controls and systems that support the related accounting processes. If each control model is implemented in the same system, using the same software tools and a common information structure, it should be easy to understand that every processing need is immediately available.

The coordination function has the task to guarantee the alignment of common information, represented in all the historical evolutions, and it is responsible for carrying out the analysis and the overall assessments (ICS Assessment), while every single function acts within its internal control sphere.

The complexity of such a well-organized system will always remain constant and it will be independent of the number of control models implemented (Figure 5).