GRC advisor Webinar - Part 2
We have launched our GRC Advisor webinar series to strengthen and build on our existing, successful cooperation with consultancies. Both sides complement each other and profit immensely from extremely valuable, vast experience. This post will briefly summarize the key messages in Part 2 of our GRC Advisor webinar series by exploring both common obstacles and pitfalls as well as possible solutions.
Most companies start with the tool selection before the business projects have been completed. As a result, the processes and procedures continue to change while the requirement list is still being put together. This is normal in our opinion. The project team, however, should be meticulous in storing the different versions. Any changes should be obvious – for internal colleagues as well as external parties including vendors such as avedos.
Another important point is to bring very different requirement descriptions from various contributors into uniform structures with comparable levels of detail. Here it makes sense to describe a few examples from the individual categories in the requirement list so that all contributors know what is expected from them and their input can flow into a clear, standardized list.
We would be happy to provide feedback on the typical categorizations and requirements in today's market during the early stages of this process. Since working though these requirements and making tender bids is part of our daily business, we have a good overview of the changes taking place. Today, for example, requirements for artificial intelligence (AI) and machine learning are commonplace in calls for bids. A few years back, however, there were rarely an issue.
Another example is how the software is operated – either purchased licenses managed by the IT department or a cloud version hosted by avedos.
Call for bids:
Any vendor that receives a bid invitation needs to know as soon as possible if any changes or delays in the timelines should occur. In addition to adjusting our own resource planning, it is important to discuss what the changes to the timeline mean for the implementation and go-live date. Our experience has shown that calls for bids and selection deadlines are often delayed, but the go-live date remains the same. Accordingly, it makes sense to evaluate when a decision has to be made so that the go live date is not jeopardized.
Many times, a final check and review also takes place before the decision is made. Here we are happy to assist our clients with important rules as well as constructive arguments and insights that have helped many other clients. One discussion that often arises, for example, is whether to purchase specialized software or develop the GRC software in house. We would be glad to support you with our wealth of experience in this regard.
Evaluation and selection:
The offer presentation plays a crucial role in evaluating and selecting a vendor. What is important here is to ensure that the vendors are comparable by defining a very clear and detailed use case. We also recommend briefing the participants prior to the actual offer presentation in order to focus on the key criteria for making the decision. It is also essential for us to know the main focus so that we can tailor our presentation accordingly. If desired, we would be happy to help work out the agenda. We have conducted many offer presentations and know in which directions the discussion can head. It helps to keep these points in mind at the very beginning to avoid surprises at a later time.
The figure above summarizes the reasons why precise and detailed requirements are so critical for our work. For starters, they allow us to draft a customized offer and address all key points in our offer presentation. We always customize our demos based on the client’s own story. Any mockups or screenshots showing examples or listing the actual fields help us explain the mandatory requirements.
Calculating the scope of services is the most important point on the agenda. This is often a decisive factor that is heavily weighted in the scoring models. We work through the requirements in detail in order to learn as much about the approach, workflow, touchpoints, interfaces, dependencies, etc. as possible. Our calculations are based on this information and address key decisions – for example, if the requirements can be configured within the standard software functionality or custom coding is required.
Example: GRC integration focusing on links between individual processes
A client requested an offer for deploying risk2value as the leading platform for all GRC-related topics within the company. Our focus at the beginning of the project was enterprise risk management, followed by the internal control system and later information security and data protection. The risks and actions that are recorded in the ERM are directly tied to information security, where their relevancy is categorized and a brief business impact analysis is defined. The ICS also is linked to the ERM. The effects of the controls are mapped as the process risks, which are consolidated into corporate risks and the respective mitigating effects are tallied into the risk evaluation. In the coming months, the client intends to add internal audits and compliance to the software. We will keep you updated on the latest developments.