Blueriq's implementation method consists of four iterative phases
- Discover
- Design
- Model
- Use
and two continuous phases
- Continuous control
- Continuous improvement
Throughout the entire implementation of a solution, from discover to use, the customer (and the customer's customer) are at the center.
Each phase has a specific goal, a list of mandatory and optional artifacts and a list of milestones. For more information on the Blueriq implementation method, please contact info@blueriq.com.
Target operating model
Within the design phase, one of the most important artifacts is the target operating model (in Dutch: bedrijfsfunctiemodel). Shown below is an abstract version of such a target operating model.
A target operating model is a model that describes the situation that is intended to achieve by means of the application(s) that are part of the entire solution. Some might use the term SOLL for this, with its counterpart IST for the current situation. The target operating model allows to scope, since it is not necessary to only describe elements of the solution that is desired now, but also include elements that are wanted or desired, but are left out of scope for the next release of the solution. Scoping is done using different colors, elements in pink are in scope of the intended solution, elements in grey are not.
The target operating model contains 7 groups:
- Roles
This part of the target operating model contains the roles that play a part in the solution, such as the case handler, the citizen or customer, investigators etc. - Channels
This part consists of the channels on which the solution will run, such as a computer, tablet or phone but also the channels that provide incoming and outgoing communication in general, such as mail. - Control
Here all types of controlling applications and modules are depicted. Most of the time this will be reporting or business activity monitoring, but also the links to law and legislation. - Primary functions
This part of the target operating model is the most important one and contains all primary functions of the solution. These functions are cases and can also be grouped, for instance by product. Examples are a permit request case, a benefit payment case etc. - Knowledge functions
Main decisions, calculations or classifications can be identified separately from the cases they are used in. They are the main decisions of the solutions and have their own ownership and life cycle. Examples are the eligibility for a permit, the amount and duration of a certain benefit etc. - Secondary functions
Next to the primary functions, functions can be distinguished that play an essential role in the solution, but are not part of the primary enterprise process. In many situations, appeal and object cases are considered secondary functions, but sometimes these are primary as well. Another example of a secondary function is a reporting case, containing information of more than one related case. - Information
Of course the cases in the primary and secondary functions section consist of information, but there is also a lot of information that is not stored within the case, but in a register that is part of the solution or even outside of the solution.
Cases and registers
Bla bla
See also
More information on how to design dynamic processes in Blueriq can be found here: Designing dynamic processes.
How aggregates are used to model cases can be found here: Designing cases using aggregates.
Everything about persistency management and aggregates can be found here: Persistency Management guide.
A visualization of most concepts discussed in this article can be found here: Blueriq visuals.
Overview
Content Tools