Selecting a GRC software

The selection of an enterprise software is usually a complex undertaking. On the one hand, every company already has individual framework conditions and specific processes for service provision, which should be optimally supported by the new tool. On the other hand, there is a multitude of products with different philosophies and focal points, the effects of which are initially difficult for an outsider to grasp. In the selection process these two sides have to be brought together. The customer's representatives have to pre-select, understand and evaluate the products that come into question in principle with regard to their suitability. And the product suppliers must understand the customer's requirements in order to offer meaningful solutions.

In practice, the procedure described below is often used, which is divided into three phases here. This model can be applied to different types of enterprise software, whether it is a risk management application or a complete ERP system. However, if the scope or complexity of the software to be introduced and the processes to be implemented is greater, individual steps may have to be run through in more detail or several times than with simpler software.

In the public sector, certain procedures are also prescribed, so that the approach can be fundamentally different.

Clarify current status, problems and motivation, e.g.

• Changes in the organization or in the processes of the company or agency
• Specifications of the group or superordinate institutions
• new or changed legal requirements

Describe approach to solution

• Restructuring of processes and tool support
• Which processes should be addressed?
• Which parts of the organization and which roles should work with them?

Benefits for the organization

• What benefit would the solution bring to the organization?
• Which processes would be executed faster or with fewer errors?
• Are costs minimized?
• Are risks minimized, e.g. by replacing old software?
• Will it meet legal requirements or customer requirements?
• What opportunities would arise for marketing and sales?

Supporting:

• What are best practices in this area? (norms, industry standards)
• Is it possible to draw on experience within your own organization?
• Are there experiences in friendly organizations?
• Experience reports, information from conferences
• What are current trends?
• Does such a tool already exist in other areas and could it be used?

Clarify basic willingness and ability to carry out such a project

• Where in the organization would the responsibility for such a tool lie? Can it be introduced decentrally, if necessary, or is the responsibility centralized?
• Is a budget available or planned?

Clarify goals and scope

• What belongs in the project?
• What explicitly does not belong to the project?

Result: The project is sufficiently outlined and coordinated with the participants

Perform initial market screening

The first market survey is about getting to know current trends and currents as well as general capabilities of tools. The goal here is not yet to create as complete a list as possible of providers and products. Rather, the aim is to build up basic knowledge so that the subsequent steps can be processed reasonably.

• What are current trends in this environment?
• What possibilities do marketable tools offer?

Result: You know some providers and products as well as their approaches and approaches.

Define target state

At the target state you develop an idea of how your organization and processes should function in the future. If you really only need a new tool and you want to continue the processes as before, you can save yourself this step. Usually, however, there is always room for improvement and, due to the constantly changing conditions in today's world, there is also a need for adaptation - now is a good opportunity to do this.

• Overview of the planned processes
• Involved organizational units and roles
• Role of the tool
• Interfaces
• Quantity Structures

Implementation projects often run into difficulties because they are torpedoed at a very late stage by other organizational units claiming that they were not included in the conception and that the software does not fit their actual working methods. For this reason, make sure that all relevant units are intensively involved and regularly give their commitment to system implementation.

Result: The future way of working is roughly defined and coordinated with all parties involved.

Putting together a rough concept

• Description of the project
• General conditions
• Goals and Scope
• Current status and problems
• Approach
• Target state
• Benefits
• Time frame

Here too, make sure that you coordinate with all relevant organizational units.

Result: There is a rough concept for tool introduction and use. It is written in such a way that tool providers can get a comprehensive picture of your current situation and the goals you want to achieve.

Create project plan

• Phases and deadlines
• Resources for tool selection
• Resources for tool implementation
• external support, e.g. consulting, project management
• Estimated expenses
• Estimated internal costs
• Estimated external costs (SW license/maintenance or SaaS fees, services)
• Risks

Result: There is a first version of a project plan with ideas about deadlines, efforts, costs and risks. The document is intended for internal use, so that the vendors initially do not receive any information about your " thresholds".

Review

All work results should be checked by a third party not directly involved in the creation. Criteria are among others: Logical connections, plausibility, consistency and completeness

Result: Examined and, if necessary, revised documents that make a continuation of the project appear reasonable.

Create a decision template and submit it for approval

In this step, the project should be confirmed according to the organization's specifications and the required capacities and funds should be approved.

In addition to the formal route, it can be useful to involve the decision-makers at an early stage through unofficial channels and to win them over to the project. In addition to the benefits for the organization, the associated prospect of achieving personal career goals and special recognition can increase the willingness to approve the project. So it often depends on which of the already existing aspects are stressed in which context 🙂

Result: Approval for implementation, budget and resource commitments.

In order to find the most suitable software for your organization, you need to know exactly what your needs are and what the general conditions are. Since the processes in companies and public authorities are usually complex and can involve different internal and external organizational units, the collection and structuring of requirements can quickly become a complex matter. However, it is worth the effort and care required to avoid unpleasant and above all expensive surprises at a later date. It would be fatal if an important requirement was only recognized after the software was acquired and this requirement could not be met by the new software.

Define software requirements

• What are the use cases in the application?

• IT requirements or operational requirements

• Specifics of the organization, the processes

The requirements should be explained in a meaningful way so that the providers have a good understanding. The explanation can also help internally to understand certain things.

Create criteria catalog

The criteria catalog is a structured representation of the requirements for the software, to be filled out by the providers. It can be used to query the degree of fulfillment and link it to evaluation figures, so that at the end there is a number for each product that expresses the degree of compliance with the criteria and makes the offers comparable. However, this figure should be viewed with appropriate caution, as the questions often offer room for interpretation and can be understood differently by the providers. In addition, the products usually have different strengths and weaknesses, so the formal suitability for a task may differ from the actual suitability. Such differences can usually only be found out in a practical test.

• Often as spreadsheet, possibly online in a special application

• All requirements should be clearly identifiable by an ID
• Classification into mandatory and optional criteria
• Degrees of fulfillment, e.g. "in standard", "by configuration", "by customizing", etc.
• Providers should always have the opportunity to comment. An application may have a completely different concept for a requirement and it should be possible to describe this circumstance.

Result: A structured catalog with concrete requirements for the software. The document is designed in such a way that it can be filled out by the vendors and that allows a comparable evaluation of the various products with regard to the fulfilment of the criteria.

Update rough concept and project plan.

In this phase you will have gained important insights into your processes and your needs. This is normal and this is good, so you should update the rough concept and project plan in the relevant points.

Result: The documents are up-to-date.

Review

Also the results of this phase should be reviewed by a third party not directly involved. Especially the catalog of criteria can become extensive and should nevertheless be consistent, since it goes to the vendors and is the basis for further evaluation. Special attention should be paid to this.

Result: Checked and possibly revised documents.

Approval

Create a longlist

• Include vendors that are expected to meet the requirements
• Basis: market analysis, analysts

Planning the process

The following steps should be planned carefully, as appointments must be coordinated with both internal staff and multiple vendors.

Please plan fairly towards the vendors. Although they are service providers, there are also people working there who would like to go on vacation with their families or celebrate Christmas. Therefore, avoid situations where, for example, a tender is sent to the providers shortly before Christmas to expect the offers to be returned on January 2nd.

Obtain information from product vendors

• Cover letter
• Description of the process according to the planning
• Expected results
• Rough concept
• Service description
• Catalog of requirements
• Rough project plan

Evaluate responses from providers

Evaluate the answers and criteria catalogs sent in by the offerers according to the evaluation scheme and bring the vendors and/or products into an order of precedence.

Vendor presentations

Invite the suppliers in question to a presentation. This should be taken into account in the planning:

Conduct presentations and evaluate vendors

Create shortlist

After the presentations, an interim evaluation is prepared for each provider, taking into account the results from the criteria catalog and the presentation. From this a ranking is provided and only the leading n offerers come a round further.

The ranking should be discussed with the internal participants despite the actually "objective" score. Because by at first unhappily selected weightings and by insights won in the procedure, results could formally arise, which are not goal-prominent. If the organization has the freedom to deviate from the agreed procedure, this possibility should at least be discussed when there are good reasons. On the other hand, this should not be used to bring forward a special tool that is purely guided by interests but which only insufficiently meets the requirements.

Testimonials

Speak with the references named by the provider and get an impression. With good discussion conduct the referring party should be encouraged to speak very openly, also about weaknesses of the system and/or in the project execution. For this reason such a reference discussion should always take place without the vendor.

Proof of concept (PoC)

• Define and describe use cases that are to be demonstrated, taking into account specifics in your organization that the tool must be able to cover.
• Schedule appointments
• Set a realistic and feasible agenda

Test version

A test version of the product is used to get a hands-on impression of the tool:

• What is the general impression and operation?
• Are the logical structures and the concepts of the software understandable?
• How easy is the handling? How often do you have to click for a task? Are important control elements immediately findable?
• How is the mass input? How easily can 100 new data sets be created?
• How easy is the software to configure or customize?

Test systems, on which the prospective customer can test alone are viewed critically by some vendors. The possibilities of today's software systems are often extensive and first you need to learn the underlying concepts and operating models before you can use a system meaningfully. The fear of some vendors is that in a "quick" test without training the software will not be understood by the testers and therefore be judged as unsuitable. Nevertheless the software should be tested hands-on. Even if one will not understand every detail of the individual system, the comparison over all products will provide important insights that should not be missed.

Narrow further down the vendors

• Evaluate results from the proof of concept and the test
• Based on this, reduce the considered vendors to the two or three best

Negotiations

• License metrics of the vendors, modules
• Support levels and conditions
• Project effort for the introduction

Final offer presentations

Here the vendor should deal with the last open critical topics, bring in suggestions for their solution and make a "best and final offer"

Decision template for the introduction of the tool and approval

Contract conclusion