Iterative Development of a Process-Oriented Approach for the Selection of Platform-Based Digital Services

Digital platforms are generally software-based artefacts that connect different stakeholders and facilitate interaction between them [4]. A basic distinction can be made between two types of digital platforms. On the one hand, there are the digital transaction platforms that primarily facilitate matchmaking and transactions, such as Amazon or Uber [5]. Providers and consumers can thus use the platform to exchange goods (Amazon) or services (Uber) for money. On the other hand, there are so-called digital innovation platforms that focus on the development of new services by providing interfaces from the platform operator through which extensions to the platform, such as apps (Apple iOS) or browser extensions (Firefox), can be created [4, 5].

These two types are an expression of different perspectives on digital platforms, which are expressed in an economic perspective for transaction platforms and in an engineering or innovative perspective for innovation platforms [6, 7]. Whereas the first focusses on the mediation between two market sides [8], the latter concentrate on the development of the platform to offer innovative new services [5]. In this context, the term platform core is used, which provides basic functionalities such as user management but also the tools that enable extension by third parties (for example APIs or other interfaces) [9]. An extended platform is created in which newly developed modules are provided by so-called complementarians [10].

Abstracted from the perspectives, digital platforms consequently consist of a platform core that provides the basic functionality and becomes an extended platform through complementary services. They are embedded in a (digital) eco-system that includes both platform components and the various stakeholders from the platform owner to the complementor to the customer [10]. The result is that digital platforms bring many actors together and enable an easy exchange of resources (e.g. digital representations of offers) across large distances.

For the development itself, two main streams can be distinguished: user-centred according to Draper and Norman and benefit-centred according to Constantine and Lockwood. While the focus of the former approach is on the user and the fulfilment of his or her needs, the latter concentrates on the improvement of the tools to systemically support the tasks to be carried out [11‐13].

The aforementioned design paradigms consider the complete scope from the first ideas to the development of the software. The use case described here must be distinguished from this, which combines both models, but also only extends to the step of selecting functional elements.

Considering the development of digital services as a system and software engineering task with a focus on requirements elicitation and management, RE for short, according to ISO/IEC/IEEE 29.148:2018, an iterative three-stage process with subsequent work steps can be assumed [14]:

The first step is to identify the stakeholders with connections to the system over its life cycle, whereby according to the standard, requirements from the management level should also be considered in addition to pure user and developer requirements. The requirements can consist of needs, expectations and wishes. The next stage is the transfer to an implementation-independent model of the future system, which describes it and the degree of fulfilment of the requirements. In the last stage, the system functions would be identified and assigned to the elements of the system architecture, and interfaces and system boundaries would be defined.

The other standards for software development that follow on from this will not be discussed in detail. They describe the relationship between RE, software development and formal vocabulary, but also methods for quality metrics or evaluation of tools for RE [15].

Methods for determining the knowledge of the stakeholders depend on the object of determination but also on the existing sources of requirements. Since this is a new development, document- and system-based methods will not be discussed further. Nevertheless, business process analysis as a document-based method should not remain unmentioned at this point. Suitable investigation techniques according to Rupp are, for example, questioning, observation or creativity techniques [16]. In the case of the former, surveys and interviews are the most important. A method for the next step of deriving requirements would be requirements analysis as a multi-stage process as well as testing techniques for the requirements, such as reviews, test cases, prototypes, and analysis models. In parallel, documentation and management should take place [16].

In order to record and document both the user and utility requirements resulting from the everyday scope of work, the aim was to be able to do this as intuitively and easily understandable as possible. The focus here was on the defined aspects of utility and usability.

Since the requirements were recorded at the level of business processes and their activities, with a focus on the development of the model, this is the “design model” use case. According to Van der Aalst, this has a strong correlation with the choice of process modelling language [17]. The objective of modelling at the conceptual level is linked to essential criteria in the selection decision. These include ease of reading and interpretation, ease of learning and a wide range of application, so that after a comparison based on comparative studies, the decision was made in favor of BPMN 2.0 [18].

As already described, the method developed aims to derive meaningful services of a digital platform in a process-based manner. Accordingly, the existing processes of the potential user groups of the platform, which must be adequately recorded and modelled, form the basis of the process model. The aim here is to obtain as detailed a picture as possible of the processes to be modelled in the institutions by means of process interviews. BPMN 2.0 has proven to be a suitable modelling language. These activity-oriented business process models (BPM) with the responsibilities structured in Swimlanes serve as a starting point to document the current effort or the possible need for utility in the respective institution. The process recording in the institutions is conducted in semi-structured interviews, which is a proven method in qualitative research. The questions are not rigidly prescribed, so that the dialogue between the interview partners is as free as possible, which is supported by an interview guideline with prepared questions structured according to topics (e.g., introduction, process initiation, challenges in the process, conclusion). On the one hand, this interview guideline serves as an orientation aid and for structuring the interviews. On the other hand, it also ensures the comparability of the interviews conducted. It is important that the questions are always formulated as openly as possible to stimulate free explanations of the processes and circumstances. Nevertheless, it is recommended to prepare so-called specifications, especially for the very specific questions about the process, which provide approaches for targeted follow-up questions and accordingly help the interviewer to further specify the initial answers. While recording the process, individual and double interviews should preferably be conducted to prevent interviewees from withholding information that they do not share with (larger groups of) third parties, such as superiors or colleagues. This goes hand in hand with the fact that persons with similar responsibilities and positions should always be interviewed across institutions to ensure comparability of process views. Similarly, all interviews should be conducted by the same member of the project team to increase comparability between the interviews conducted. To be able to adequately create the individual BPMs afterwards, we recommend that the interviews are first recorded acoustically and then transcribed.

In the next step, the process models created in the first process step are to be aggregated into a generic BPM in order to combine the various individual processes and thus form activity clusters that are suitable for possible implementation as individual function modules within a platform. By means of expert workshops consisting of process experts and experienced process analysts, a generic BPM can be derived that generalises the individually recorded processes of the individual user groups to simplify the prevailing process diversity. At this point it should be pointed out that this aggregation step is of course accompanied by a certain loss of information from the individual process models of the individual institutions. Nevertheless, this aggregation requires the definition of framework conditions to be observed in order to systematically design this process step. For this purpose, it is conceivable, among other things, to limit the number of activity clusters resulting from the aggregation of the process models in order to reduce the complexity of the aggregated BPM to a reasonable level. Furthermore, we recommend using the lanes as a criterion for the aggregation of activities and accordingly not merging activities across lane and thus role or department boundaries, so that existing process interfaces remain intact. Taking such essential boundary conditions into account, two alternative procedures are available in principle in the course of process aggregation. On the one hand, all captured process models as well as the activities they contain can flow equally into the generic BPM. On the other hand, it is also possible to prioritise the information that enters the process aggregation, for example, to focus on more frequently occurring process paths or to trivialise infrequent activities.

The previous steps describe an empirical actual state of activities and events of a synthesised existing process. In the following, we want to start from this modelled state and assume that an alternative “better” target process can be found, which is more useful on the one hand and is made possible using digital services on the other. Manual processes should be simplified and substituted by digital sub-processes.

The planned transformations should be cost-benefit efficient. For the improvement of total costs and total benefits, we want to make each activity, each event and each decision assessable in one step. We aim to formulate selective evaluation criteria to estimate the respective benefits at different levels. For example, we would assign attributes such as “temporal -”, “monetary -”, “crisis resilient –”, “emotional benefit” etc. to each activity. In addition to different benefit values of each element of BPM, we also estimate different cost values. Costs can be of various kinds. For target activities to be evaluated, implementation, establishment and operating costs are incurred, among others.

Costs and benefit values do not necessarily have to stand in relation to each other individually. In the next steps, they are used to evaluate potential transformations in terms of whether the overall cost-benefit ratio would increase. To determine this, we propose simulations using a complex benefit function that integrates all cost and benefit attributes in a weighted way. In the simulation, BPM instances are processed, for which additional measured or estimated knowledge about flow distributions is needed.

From a scientific point of view, we find it interesting to investigate the methodology of determining suitable benefit attributes and the joint calculation in a complex benefit function regarding the user experience. The result is an extended and assessable BPM.

In the next step, various alternative processes and sub-processes are to be developed and discussed with the help of the previously developed evaluation methods.

New substituted activities proposed by experts need to be estimated in terms of their costs and benefits in the same way as existing activities. It should be noted that the transformation into an improved process is associated with one-off costs. These costs include both the one-off potential development costs of the digital services and the overcoming costs that all the entities involved must incur to accept the change and establish it in the long term. As an example, a potential actor of a platform has to actively decide to give up his usual processes and get motivated to learn new procedures, etc. These costs should be considered in the analysis. If necessary, it may even be necessary to model intermediate transformations, because it is only through these that the new target process appears achievable. All in all, a set of new imaginable target processes should be modelled, which are more useful, more accepted, and not more cost-intensive over a defined period.

Our focus is on categorising all variations of individual functionally definable sub-processes individually and in combination. The resulting set of different potential overall processes can then be ranked using the proposed evaluation. We finally select the best-rated, most useful, and feasible alternative process including the new sub-processes.

The last step in the process model describes the derivation of the requirements of the target process in the context of a focus group. According to Rupp, this can also be seen as a review of the requirements [16]. This workshop takes place with both developers and stakeholders – the future users. The users should have the same role and sector affiliation as in the process interviews, since they were identified as relevant stakeholders at the beginning. In the focus groups, it will be examined whether the classified process works with the future role distributions on the one hand, and on the other hand, which building blocks could be considered for a possible implementation. This functional selection of possible services could then be the starting point for further development and keep the effort low for all those involved.