Streamline Ecosystem Activity Modelling with RegDefy's Capability and Process Management
In order to explain the details of the ecosystem’s operation to investors, participants, employees, and regulators you need to articulate exactly what each organisation is going to do and how they are going to do it. This is managed in the activity layer of the Ecosystem Digital Twin and in the Capability and Process management dimensions of RegDefy.
Capabilities & Processes
An organisation’s capabilities are what the organisation can see or do. For example, in a regulated ecosystem one of the organisations should be able to “Manage Incidents”. As you can see a capability is phrased as a verb. An organisation has a capability usually because of those items in the implementation layer, namely: Systems, Data, Interfaces, and non-technical Assets as well as the people to operate them. Flipping it round one can think of groups of Implementation layer items come together to give an organisation a capability. This concept is useful when mapping to Important Business Services (IBS) for Operational Resilience compliance.
Processes on the other hand are the specific ways activities are performed by an organisation. As an example, most regulated organisations should have an “Incident Management Process”. In contrast to capabilities processes are phrased as nouns. This distinction helps when the wording may be very similar. If capabilities are the what, in general terms, an organisation can do, then a process defines the how, who and when of the activity. A process has a defined (and hopefully testable) outcome; it defines steps and tasks along with conditions (think flowchart); and it uses input artefacts and creates output artefacts.
The RegDefy static model manages the Capability and Process catalogues for the ecosystem. The former are mapped to other dimensions showing how the organisation delivers the capability. The latter are broken into steps, assigned to teams with “happy path” sequence diagrams or flow charts depending on the level of elaboration required.
Some processes will be scheduled in runbooks and may require evidence to be collected along the way. This is managed by RegDefy’s dynamic model. As an example, making sure the start and end of day processes happen; recording who performed each step; and outputs are stored correctly can be very useful in the event that something goes wrong.
Capabilities and Processes Challenges
When to define Capabilities and Processes
The benefit of capabilities is that they tend to be more durable than processes i.e. an organisation’s capabilities change slowly over time. As such they are a useful broad brush at the start of an ecosystem’s construction. Unfortunately, regulators like the detail around exactly how an organisation is going to achieve a specific outcome – to the extent that at one client one particular regulator physically visited the team performing the Incident Management process to watch them run an incident. On the other hand, as Processes are more fragile, there is a cost to managing the activities of an organisation at the process level for a long period of time.
So, the right strategy is to start in Capabilities and then migrate to Processes at the right time. Picking the right time is more of an art than a science but RegDefy has some techniques to make the transition easier.
Firstly, you can define an ecosystem in terms of Capabilities all the way through to mapping them to how Products and Services are delivered to customers (aka the Value Stream). This means you can define Processes using a just in time approach.
Secondly, when you do need to define Processes you can vary the “Definition of Done” depending on the process. For some (e.g. the Background check process for all new employees) you can capture the name, the outcome, and who is accountable. For others (e.g. the End of Day process) you can define triggers, steps, and exceptional flows. RegDefy also allows you to keep track of which process needs which treatment. In either level of detail the process can be mapped to clauses in a policy or regulation to ensure the compliance story is solid.
Cross Ecosystem
As most DLT projects involve multiple organisations, so you find that many processes (especially those requiring a more fulsome treatment) will be cross party for example the on boarding process. For these it is essential that there is a commons language and process model. Where process steps are allocated to teams there needs to be a common people model as well. At the very least the ecosystem needs to have a standard people model that can then be mapped by the individual organisations.
Capabilities can also be cross party. In some ways that is the point of a DLT: multiple organisations executing a protocol allows the ecosystem to do something (e.g. validation of blocks). Again, a common language and understanding how the capabilities are delivered is essential.
RegDefy’s multi organisational model allows the ecosystem to meet both of these challenges. If used by the ecosystem’s governance function, standards can be set across both catalogues and the people model. In the case of processes it becomes very clear who is expected to do what and who owns what. This ownership at the team (rather than organisational) level is very useful in getting to federated and transparent accountability.
Continuous Improvement and Change Control
If there is one thing that we are sure about Processes is that, over time, they will change. Embedding a proper Systems Thinking culture means using feedback loops for continuous improvement as we learn lessons from operating the ecosystem. However, this needs to be done in a controlled manner as these processes may have been approved in some way by external parties. In short, the process catalogue should ideally be under change control.
Initially RegDefy can be used without Change Control enabled such that change can be rapid and unencumbered. However, after a point in time which maybe a regulatory submission (e.g. Gate 2 on the Bank of England’s Digital Securities Sandbox), RegDefy can keep any of the 11 dimensions under change control. RegDefy manages the current and future versions of the operating model with the “Now” or “As Is” version being the one that is currently executing. Changes can be fully modelled in a “Soon” or “To Be” version without affecting current operations.
This new version can be made live either optimistically (notification after the event) or pessimistically (approval before the event). Both mechanisms can provide a historical record of changes to the model.
RegDefy's mission is to accelerate the path to regulatory recognition and business viability for innovative, decentralised finance (DeFi) startups.
By providing a comprehensive and streamlined compliance tool and methodology, RegDefy empowers startups to efficiently navigate complex regulatory environments, minimise time to market, and focus on their core objectives.
Want to know more?
RegDefy’s integrated approach to managing the activity layer makes it a significantly easier exercise. Over time RegDefy has been designed to work closely with how an ecosystem grows and changes meaning that it fits in with your journey.
