Multi-channel provisioning of public services - Department of ...

Conclusion and further work
FW4
How is it possible to implement process logging, using the occurrence of events,
to maintain process state for interactive processes in a multi-actor service
network?
Considering FW3, editing of interactive process models suggests that a provided service
is based on a process template where all aspects of the progression of the service are
necessarily not known when the service is instantiated. The process template can be
empty so that the service process is created progressively, the process template is not
accurate and needs to be customised to the actual service instance, or the process
template requires that information based on context or timely knowledge is added at
run-time. It is also possible that the process template is changed. This can be based on
changes in service primitives used in its construction, or through modifications of
process flow. In both the case of updating a process template or instance, interfaces,
interactions, and constraints has to be established. Revising existing service primitives
will also require propagation throughout the system.
Considering FW4, process logging is related to updating process state and to catch
events within a heterogeneous collaboration environment. This can be related to logging
changes to the process instance based on changes in the local information system, and
further distributing those changes so that they are made available for the relevant
process actors. It is expected that the approach to be used will depend on the process or
task in combination with the type of task and the environment in which the task is
performed. Possible approaches can be based on process mining techniques, or active
reporting by the process actors.
8.2.3 Validation of artefact agility
Business agility is discussed in P9 and is central to the requirements covering the
transformation capabilities of the design artefact (Chapter 6.3). The consequence of a
satisfactory solution to these requirements suggests not only that the design artefact
should be capable of supporting any public service with a predefined flexibility, but also
that it further should be able to support unpredictable changes in the service. In this, it
would not be sufficient to construct a scenario for a given public service in order to
demonstrate the design artefact, but it would also be necessary to construct scenarios for
how a service could transform and how the artefact would handle transformations. This
could be done through classifying existing public services with respect to where
flexibility is needed. In addition to the predefined flexibility and flexibility for
unpredictable changes, aspects related to an administrative reorganisation of how a
service is provided in Chapter 6.3 (e.g.: relocating of a citizen) are also considered to be
within the scope. Constructing scenarios would further not only demonstrate the
benefits for the isolated public agency and the citizen, but also demonstrate the network
effect through a global availability of a working e-service infrastructure. Using
narratives as storyboards or role-plays could help bring the artefact description to a level
where it could be demonstrated to various audiences for feedback, and simulations or
scenario descriptions could be elaborated to a level where Delphi studies or the use of
focus groups are made possible. The following research questions for further work are
defined:
90