Main Title: A Method for the Sustainable Documentation of Operations Processes in Parcel Distribution Centers

There is often no common understanding on operational processes in logistics companies as they are not properly documented. Hence, people execute the same process differently and training is conducted by experienced operators on an ad-hoc basis. Furthermore, continuous process improvement is hampered as neither the ideal process nor current issues in as-is processes are visible. A major reason for the missing documentation is the complexity of existing business process modelling languages. Modelling experts are required for initially describing the processes and also for updating the models after process changes. Furthermore, operations people are usually not used to read complex process models in EPCs or BPMN diagrams. In order to overcome these limitations, a domain-specific modelling language which facilitates maintaining up-to-date process models has been designed with a large logistics company in Germany. The paper at hand briefly describes this language and illustrates the method on how to apply it in operations environments.


Introduction
Transparency on processes in an enterprise is a mandatory prerequisite for understanding and (continuously) improving business processes. Transparency can be achieved by having a descriptive documentation that helps stakeholders with achieving their respective objective. One objective is having the processes documented in a way that it fosters a common understanding on the processes. Pointing at a part of a picture and inducing a common understanding what the discussion is about (and excluding irrelevant topics at the same time) is still an underestimated effect during meetings. The picture serves for setting the scene and guiding through the presentation or discussion. Although this is a rather simple (and obvious) benefit, adequate business process models conduce to achieving further objectives. Typical examples are (just to mention a few) 1 : -Training of new employees workers or temporary workers based on common diagrams -Quality assurance: Business process documentation for ISO 9001 certification (cf. [4]) -Continuous improvement: Diagrams depicting processes are used in common methodologies for continuous business process improvement (cf. [5]) There is a plethora of business process modelling techniques, tools and methodologies available today. Although they are supposed to help in modelling business processes, they still fail in many of today's environments as people struggle with (semi-)formal business process modelling languages as well as applying methodologies in order to achieve a given goal. Reasons are manifold.
Effort: Domain experts are very seldom familiar with common business process modeling languages [6]. Dedicated know-how is still required for applying modelling tools and methodologies. This usually leads to starting business process modelling initiatives with domain experts and modelling professionals (plus project managers and facilitators) tasked with conducting process workshops for creating as-is or to-be business process models. Facilitation of such workshops is challenging as domain experts tend to be very detailed when it comes to talking about their daily business. In fact, they tend to focus on all the exceptions they have to solve every day in operational business. Strong guidance is needed for getting reasonable result out of the workshop and not getting lost in (exceptional) details.
Focus: Business process models should serve a given purpose (or several of them) but not all initiatives succeed in fulfilling it as the results are often not easy to comprehend. This can partially result from domain experts getting too detailed as explained above. Furthermore, modelling experts tend to use modeling language and tool features even though they are not necessary for achieving the objective. A common rule should be that -nice to have‖ is not required for the first version. Modelling professionals can also overwhelm by using highly elaborated modelling language features but which are hard to understand by domain experts. Especially in the operations part of a logistics company, people are very hands on and not used to elegant modelling techniques. Even those participating in the modelling initiative later on struggle with explaining the results to other domain experts 2 . Nevertheless, finding the right balance between level of detail and an appropriate level of simplicity is still very challenging.
Sustainability: The authors observe very often that existing business process models are not maintained at all after performing the initial effort -even though the process itself changed. Uncertainty about the correctness of a model can be even worse than having no model as validating the model requires significant effort (including getting aware of the inaccuracy). Business process modelling is not the core of logistics operations people and, furthermore, the value of process documents is not at hand, partially because of the reasons give above.
Against this background, the paper at hands describes an approach supporting business process modelling in operations of a large logistics company. The core product of this company is international parcel distribution with facilities in several countries globally. The approach bases on a domain-specific business process modelling language for the domain of parcel distribution centers of the logistics company: Parcel Distribution CenterModeling Language (PDC-ML)It aims at fostering having a sustainable documentation of business processes by following these requirements: a) Models are easy to understand by operations people and without any modelling-specific training. b) The modelling method is applicable in an operations environment using available tools. c) Models can be maintained continuously by people working in a parcel distribution center.
The remainder of the paper is structured as follows: The domain-specific business process modelling language is presented in section 2 and its application further demonstrated using a case study in section 3. Section 4 provides an overview on the state of the art of domain specific modelling as well as its application in business process modelling. The paper closes with a summary and an outlook on future research in section 5.

1
Parcel Distribution Center Modelling Language

Requirements on the language
The PDC-ML is created to offer operations people an easy way for process modeling and understanding. This requirement is achieved by the following criteria: 1. Usage of domain-specific terms: The language should use concepts and terms that are common to practitioners of the respective domain. 2. Adoption of established symbols: The graphical modeling language should use symbols that reflect the corresponding concept of the domain. 3. Definition of required attributes: Each concept of the application domain has certain properties. These can be pre-defined by the modelling language and, therefore, already indicates which kind of (detailed) information should be provided by the modeler in order to describe the real world object properly. 4. Restriction to valid connections: General purpose modelling languages usually offer generic relationships between objects (e.g. associations in UML) that can be used for describing any kind of relationship. However, there are no mechanisms that would prevent modelers from linking objects incorrectly to each other. Domain-specific modelling languages rather focus on restricting relationships to semantically correct aspects. 5. Strict focus on value add: The PDC-ML should focus on the value-adding part of the process and prevent people from getting lost in detailed discussions about which exception can occur and how to solve them.
The PDC-ML is supposed to use domain-specific terms and expressive symbols the employees are already used to know as proposed by Frank (cf. [7,8]). Predefined attributes and limited connection variations ensure that the process models contain the required information without high complexity (cf. [9,10]). Through focusing on the value adding process part, the so called -happy path‖, the PDC-ML supports sustainable process documentation. A similar approach is followed by Sharp and McDermott (cf. [11]) or Hammer and Champy (cf. [12]). If necessary a separate exception handling is possible and desired as well. These criteria have been defined together with the corporate process management organization. They differ from other approaches of domain specific languages which propagate a generalized view to multiple perception channels [13].

Language overview
The PDC-ML possesses four different components: The process, the process steps, the activities and the events. Each of them fulfills specific functions and features corresponding characteristics.The process symbol poses as a kind of heading and gives a short process overview ( Figure 1, red symbols on top). The process -Sales order handling‖ has a defined result (-Sales order processed‖), which shall create an additional value for the company. Without identifiable additional value the process and its documentation are possibly not necessary. The process is initiated by one or more triggers (-Sales order received‖). They mark the origin of the process.With PDC-ML the processes are divided in consecutive process steps (from -Receiving‖ to -Manifesting‖) as shown using grey symbols in Figure 1. These steps convey a general idea of the process and are read from the left to the right. Each process step consists of one or more activities.  Figure 1: Example detailed process step -Sales order handling-(simplified) Activities represent single operations which are executed during the process flow (yellow symbols in Figure 1). They are assigned to their superior process step (-Sorting‖) and arranged top down (Only exception: Parallel activities are arranged next to each other). These activities can be differentiated in five PDC-specific activity types. They describe what shall be done or what is happening in this step. The activities (-Create bag label‖) can trigger events (out event: -Bag created‖) or are triggered by them (trigger event: -Bag is full‖). In this case the event is linked to the corresponding activity.
Events can be time-dependent (timestamp event, e.g. -Bag created‖) or mark a specific incident (incident event, e.g. -Scan error‖). The incident event documents the exceptions occurring aside the happy path. They are solved apart from the value adding process through incident solutions.

Exception handling
The separation of happy path and incident solution shall ascertain on the one hand that the possible exception handlings do not become inherent process parts. On the other hand the focus on the value adding part helps to keep the thread in process modeling workshops. The exceptions occurring during the modeling workshop are marked directly in the process through incident events and can be discussed later on easily. If every problem and its solutions would be discussed immediately, the workshops would mostly take too much time. In addition the separate solution discussion enables the operations people to take a closer look on each relevant problem and work out one or more possible solutions. This can be done at the end of the workshop with all participants or in a separate meeting with only the people concerned. The developed solutions are documented in standardized problem-solution-processes which are linked to the primary operations process through the marked incident events.

Language definition
(Graphical) modelling language are typically specified by their syntax and semantics. The syntax definition can be further devided into the description of elements as well as rules for combining the elements(abstract systax) and the visual representation of the language (concrete systax,cf. [14]). The abstract syntax of the PDC-ML is given in following meta-models while the concrete sytax has already been shown in figures 1 to 3 in the previous section. A more detailed language specification can be found in [15].  Figure 2 shows the language elements forming the core of the language. Each process has a trigger and a result and is composed of several process steps. Each step consists of several activities. An activity can be triggered by an event but can also raise events during or after execution. Activities are, furthermore, specified by a business object that it works on as well as required resources and human actors (i.e. role).

Figure 3: Meta-model for activities
In order to simplify modelling for operations people and also standardising the models, there are five domainspecific kinds of activities as given by Figure 3. They have been perceived as sufficient by involved logistics people so far. A Create Activity adds value by creating an output based on given input. Physical Movement Activity addresses the core of logistics, moving objects to a destination. Activities for quality assurance are represented by a Verify Activity, which can also describe the testing method and expectation on properties of the outcome. Tracking is one of the core activities in a logistics company, as this allows for managing the logistics chain and making the transportation status visible to the customer. Parcels need to byidentified by an Identify Activity in order to achieve this. Sort Activity is required for sorting parcels inbound or outbound.

Applying the PDC-ML
The ideal set-up for applying the PDC-ML is a workshop with the people involved in performing the process. Workshops are well-suited in case of lacking knowledge about the process (cf. [6]). It needs to be prepared so that that it can be run efficiently by focusing the work on the desired outcome. The result itself needs to be made available to all stakeholders and a clear ownership has to be defined so that the process can be adjusted in case of changes.

Preparing the workshop
The workshop preparation aims at ensuring that the process in scope will be documented properly and all relevant stakeholders are involved (cf. [16]). The following aspects need to be considered: a) Objective of the process model and targeted user group b) Scope of the process to be modelled c) Participants of the workshop d) Facilitation and documentation e) Workshop tools and documents

Objective
The objective of the process model to be created during the workshop needs to be clear to all participants. This includes the purpose the models will be used for as well as the typical user that will read or update it. Models will be interpreted by humans rather than computer systems, as the focus of the PDC-ML is on defining a common understanding of the process by all involved participants. The language does not include specific concepts for control flow, consequently, PDC-ML models cannot be used for implementing a workflow-based IT system, for example, or allow for simulation or formal analysis. Nevertheless, the models can be used as a starting point for later implementation-specific process models. Scenarios to be covered by the PDC-ML are still manifold, even if the level of detail is rather high. The models can be used for transparency (e.g. defining a common understanding, documenting processes for external people or improving the process within a process optimization initiative). The process model needs to cover any aspects that are required by the objective in scope, for example: showing the value-add to externals, indicating process inefficiencies for a process optimization or covering the whole process as understood by the participants. These examples are not mutually exclusive but rather indicate which concepts are more relevant than others for a given scenario.

Scope
The scope definition aims at focusing the discussion during the workshop on the relevant process. The scope should encompass a process with a specific result as well as defined triggers for starting the process. This will be the starting point for the process definition workshop. The scope should also take into consideration the limited time available for the workshop execution. Hence, the scope should not be too large as it will take a long time for modelling but it should also not be too small as the models are not considered to be very detailed. Some rules of thumb are:  Processing time by up to 5 people within 5 to 40 minutes  Various manual steps by operations people (less than 30)  Mix of automated and manual steps  Process can be supervised by one person Examples for typical scope definition are handling parcels for export, organization of transports between distribution centers, import customs clearance for commercial shipments, last mile delivery or handling a specific customer service request. These examples represent scenarios in which the method has been applied already, but there might still be further application areas.

Participants
The workshop should be attended by people involved in executing the process. They will provide the desired input and will help in identifying inefficiencies in the process flow (cf. [6]). It is also suggested to have the process owner in the workshop. Operations people tend to thinking about the as-is while the process owner also has an understanding what the process is supposed to do. In fact, these kinds of workshops sometimes also lead to interesting insights for the process owner. An external person not knowing the process can optionally be invited to the workshop. This kind of participant can check whether the model will also be understood by others or even challenge parts of the process. Process experts are often affected by the process as they know them and external input can offer an additional, open-minded perspective.

Facilitator
The facilitator plays a crucial role in the workshop and takes care for the following aspects during the workshop:  Making sure that the workshop is finished on time by guiding the participants through the process of creating the process model  Ensuring that every participant's input is recognized and incorporated into the final result: Participants should recognize that the result is a common achievement rather than being pushed by individuals.  Helping participants on focusing on as-is or to-be: People usually switch between them which makes it hard to achieve the representation of either the process as it is now or how it should be. A mix of both is usually of no avail.
The facilitator can be supported by one of the participants with documenting the result. Please, note that a dedicated modelling or tool expert is not required explicitly. The facilitator rather needs support with placing and labelling the process symbols as provided by the PDC-ML. Support will also be needed when creating the final documentation of the workshop.

Documenter
The documenter is in charge of documenting the workshop results, sharing them with any stakeholder as well as keeping them up-to-date. He will be selected amongst the workshop participants or can be decided upon by the owner of the process in scope. It is important that the documenter is also involved in the process so that he can get aware of changes that require updates of the process documentation.

Sponsor
The sponsor is usually a person from the (top) management ensuring that all participants understood the relevance of the initiative. He (or she) plays a crucial role for the initiative even though he is not directly participating. It's his obligation to communicate the initiative to the whole organization and ensuring that all participants get feedback from their line managers or team leads as well. The sponsor will also be involved in solving problems that cannot be handled by the participants of the workshop.

Tools
The design of the PDC-ML is based on using paper-based material for the workshop. Process and activity symbols are prepared as cards that can be labelled and attached onto a whiteboard (e.g. sticky notes). This allows all stakeholders to actively participate in creating the process model. Changes can also be made easily by anybody in the room. A software-tool is not recommended during the workshop as this will only enable one person to apply changes. However, a tool (MS Visio or a dedicated modelling tool) can be used afterwards for the final documentation.

Executing the workshop
The facilitator will be in the lead for coordinating the discussion but not directly provide business contents. The workshop itself will thereby follow the following steps: 1) Introduction and managing expectations 2) Aligning the process scope including trigger and result 3) Identifying major process steps as a value-added chain 4) Detailing process steps 5) Wrap-up the workshop Although listed a sequence, the facilitator can decide to return to a previous step in case of adjustments need to be made.

Introduction
Even though the objective is already communicated while inviting to the workshop, it needs to be clearly communicated in the beginning of the workshop so that everybody has a common understanding of the purpose of his or her participation. Open communication is one of the success factors for a process initiative (cf. [17]). The facilitator should also ask the people in the room for their own expectation as well as potential concerns. This will help addressing them early during the process definition. Potential concerns can be incorporated into the process definition in the same way as any feedback is appreciated properly 3 . This step can be supported by sticky notes. The participants write the expectations or concerns on them individually and then present them to the group by sticking them onto a wall.Thoise should be addressed throughout the worshop but the participants also need to understand and commit to the relevance of the iniative (cf. [19]).

Process scoping
The process overview only consists of the process (represented by a symbol with its name) as well as the result and the trigger. This approach is based on the methodology provided by Sharp and McDermott (cf. [11], pp. 32). The facilitator can already prepare a draft up front, but the overview needs to be agreed upon by all participants. Even though it might make some time for discussing and agreeing on the scope, it will support the further process definition.
-Result: Each process should have a result that provides value to the corporation. Hence, it does not only state the immediate outcome of the process (e.g. parcels are sorted into mail bags) but also the value. For example: Having parcels sorted in mail bags simplifies handling during transportation and enables dispatching for delivery in the destination parcel distribution center. -Trigger: The trigger represents one or more events that initiate the execution of the process. Both, trigger and result are defining the boundaries of the process and help in explaining it in a nutshell. The example in Figure 4 will be read as: -When we have received shipments (i.e. pallets with parcels from the receiving department) we sort the parcels into mail bags so that they can be transported into the respective destination countries.‖ -Process: The team should agree on a concise description of the process in order to make sure that everybody has the same understanding. If this description is the result of the common work of the team, they will rather accept it (compared to being provided by some external party) and even establish some emotional relationship with the result.

Sort parcels into mail bags
Bags sorted by country There are pre-defined cardboard symbols available that can be used for the scoping. Participants can write on them and attach them to the wall. This supports having the process documentation as a common result but something the facilitator or a dedicated process modeler was creating. It is the process of the participating domain experts.

Process steps
Defining process steps together with the team has the following two purposes: a) It fosters a common understanding amongst everybody involved and can, therefore, also be seen as part of the process scoping. b) The steps will provide the structure for the following workshop phase.
The process steps should comply with the description evolved during the process scoping. Otherwise, the description needs to be adjusted accordingly. Placing the steps from left to right should provide a summary of the process (i.e. how is the value add being achieved) as given in the example provided in Figure 5. The shipments received are usually a consolidation of many parcels on a pallet or in a container. Each parcel needs to be taken out of the container, processed and put into the bag for the respective destination country.

Detailed process steps
The PDC-ML provides a Process Detail Diagram for documenting the process flow as presented in section 2. The example provided in Figure 6 describes the detailed activities for the Build outbound consol process step from the sorting process in Figure 5. Each mail bag has a unique identifier that needs to be scanned so that the required documents can be generated later on. Before, the bag needs to be closed and weighed. Its identifier and weight as well as the number of parcels are printed on a bag tag that is printed together with a manifest listing the contents. Figure 6: Detailed process step "Build outbound consol" (photo from workshop) A good starting point for the detailed process diagram is collecting activities together with the participants. Events and control flow can be added in due course and there is no specific order to be followed. The facilitator needs to make sure that the input from anybody is appreciated and incorporated properly. However, the group should not get lost in detailed discussions but rather focus on getting the complete picture done.
Exception events can be used here as a means for conducting the discussion. Domain experts tend to go into very details and frequent issues as this is what they experience on a daily basis. This can lead to lengthy discussions and bears the risk of running out of time. The workshop should focus on the -happy path‖, i.e. the value adding processes. Issues in operations and how they can be solved can be discussed later after finalizing the happy path. Any exceptional event in the process can be represented by the exception event symbol so that it is located properly in the process. It, therefore, also serves as a bookmark so that it can be addressed later4 as proposed in section 2.3.

Wrap-up
Wrapping up the workshop basically consists of recap the result and making sure that all relevant aspects are covered. Any parked topic should be addressed explicitly and checked whether it has been incorporated into the process as required. All participants should now agree on the result or raise final concerns. Depending on the severity of the concern, the documentation needs to be adjusted together with all participants. Some best practices for the wrap-up: -The sponsor should be present so that he also accepts the result and, therefore, increases the value of the documentation. -The presentation should not be done by the facilitator but one of the domain experts from the parcel distribution center. -One of the participants should be asked to take pictures of the result. They are the basis for the final documentation of the process. 4 The principle behind this is similar to the facilitation tool of a parking lot which collects any topic that cannot be discussed extensively in a meeting.
At the end of the workshop, the facilitator should check whether the expectation of each participant has been met and any concern has been solved.

Ensuring sustainability
The results of the workshop should be documented and shared within the organization. Ideally, there will be one dedicated persons that takes over responsibility for maintaining publishing the results. This can be the done be the process owner or any person playing a role in the process. Another option would be having a dedicated person for managing process documentation in a parcel distribution center. He or she just needs to have access to common channels for distributing documentation and also needs to be involved in process changes.
There are also no specific requirements on how to document the results. The process maps should reflect what has been agreed during the workshop and it is recommended to use the same symbols. Potential media are (to list only a few):  Photo: A photo of the maps that have been developed during the workshop are a simple form of documentation. They do not require significant effort and provide some kind of authenticity. However, it is not easy to update a process map on a photo, so that an additional documentation might be considered.  Original process map: The process map as a result of the workshop can be kept as it is. It is also authentic and changes can be applied later on. The authors experienced process maps in meeting rooms for more than a year. Although everybody can go to the room and inspect the result, it is hard to share via any electronic channel. A photo can be taken after each change and shared electronically.  Graphic format: The person in charge of maintaining the documentation can draw the process using any drawing software available. An electronic copy of the documentation can be shared easily with others and also be updated. However, the documenter needs to be in charge of keeping the master document. Hence, any change needs to be reported to him so that it can be incorporated and shared with others.

Distributing the process documentation
The process documentation needs to be distributed in the organization so that everybody is aware of the results. This can be done by using existing channels but it can also be spread using informal ways. Examples for formal channels are:  Operations manuals: Some organizations already maintain descriptions of operational processes in so called operations manuals (aka. work instructions).  ISO:9001 documentation: Process maps can also be incorporated into documentation that is required for ISO:9001 certification and published together with them.  Training material: Existing training material needs to be aligned with the process maps from the process definition workshop.
Using any formal channel also requires aligning the publishing process with the owner of the existing documentation. Best practice: The role of the documenter is assigned to the person already maintaining the existing documents. This also fosters the documents being rather complementary than redundant. If the result of the process workshop deviated from existing documentation (i.e. there is a conflict) the exiting documentation needs to be adjusted accordingly. In worst case, the workshop needs to be re-iterated if the result is not compatible with requirements for existing documentation. However, the participants (especially the documenter) should be aware of those and make sure that the result matches the existing documentation requirements.
There are also a couple of rather informal ways for distributing process maps. They are not formally established in the organization and, therefore, offer some more flexibility. Examples are:  Leaving the result in the meeting room in the same way as it has been created on the wall by using the card box symbols. People will recognize it and it might gain some attention because of the card box style.  Process posters: The authors usually documented the process electronically and shared printed posters with the participants and other stakeholders. Some of the posters can still be found in respective offices after months. The impact of the workshop can also be determined by the frequency of using those posters.
 Laminated work instructions as hand-outs: Hand-outs can be created from the same file as the poster but laminated so that they can be used in an operations environment. By simply laminating it in plastic film already increases the perceived value of the process map.
Furthermore, any kind of channel can be used for distributing the results, like for example team meetings, other workshops or any jour fix. Although, people should not be annoyed by repeatedly being confronted with the documentation, it is important that people are aware of it and incorporate workshop result in their daily work.

Maintaining changes
Business processes in an organization are usually subject to frequent changes. As-is processes, for example, need to be adjusted in case of changes in the process' context (e.g. changes in customer expectations or legal requirements). Also to-be processes are not immune to changes as prerequisites can be altered between the process definition workshop and the implementation of the process. Those changes need to be reflected in the process maps and they, in turn, need to be republished. Hence, publishing the process documentation is not a single task after the workshop but rather a continuous obligation.
The real difficulty is not incorporating the changes but rather getting aware of them. If the documenter is working in administration (i.e. physically and mentally distant from the real process), he might not get aware of deviations in the process flow. Therefore, the documenter should be a person who is involved in the process' execution (for example as a team leader) or somebody who will be formally informed about adaption of an existing process (like a quality manager).
After getting aware of the change, the documenter should check its impact on the documentation and discuss this with relevant people. Relevant people are usually the workshop participants but can also be further stakeholders like a process owner or the distribution center's management. If there is a consensus in the change, the documenter updates the process maps accordingly and shares the results with the same relevant people for double-checking. If the approve the new version of the process map, it can be published again.

Related work
Currently there are many different process modeling methods and languages existing. One of them is the in Germany most popular method ARIS with its process modeling language EPC [20]. It includes many language concepts for any purpose, including automation. To create a process model with EPC a dedicated tool is required. Another general purpose modeling language is Business Process Modelling and Notation (BPMN, cf. [21]), which has become an international process modeling standard. It includes detailed language concepts with respect to workflow management and orchestration. With its extensive notation it is well suited for process execution as well [21]. Multi-perspective Enterprise Modelling (MEMO, cf. [22]) is a further example for a general purpose business process modeling language. All of them offer detailed concepts even enabling process execution. But they have rather no emphasis on supporting domain experts with respect to documenting logistics processes. Therefore they are not very useful in the context given here.
Significant research has been done on the development of domain-specific languages. There are a couple of guidelines available (cf. [23] or [24]) as well as concrete language examples [25]. However, their focus is rather on the formal specification of a language, verification and code-generation. In contrast to this, PDC-ML is more focussing on supporting modelling novices so that they can easily create a process model as mentiond by Frank [7]. One domain-specific language with a very similar approach to this is the PICTURE method [26]. This graphical language describes a simple control flow with domain-specific activity types. But the PICTURE method only concentrates on administrative processes and not logistics. For this reason it is also not useful for the described purpose. Another figurative domain-specific language is MEMO-ITML [27] which is created to describe IT management processes and not logistics either. For this reason the existing domain-specific languages deal with many different domains as administration, IT management or medical processes [28], but none of them is suitable for the requested logistic processes. In addition none of the languages given above focuses on the happy path with exception handling as a dedicated language feature.The bottom line is that there is no dedicated domain-specific language for parcel logistics available.
Other known logistics models as the SCOR model [29], the Supply Chain Operation Reference model, are not practicable either. Indeed it reuses artefacts documenting logistic processes but rather Supply Chain processes for manufacturing and not for parcel distribution.
As a domain-specific language is tailored to the contexts and the needs of the participants, a standard method cannot be applied. Classical business process management methods rather address modeling experts or professionals by providing generic guidance (cf. [6], [30]). These methods are further complemented by (formal) validation approaches that aim at ensuring model quality in a larger context by also standardising the vocabulary used in process models (for example in [6], [31] or [32]). Even though a standardised language can support further operationalisation of business process models, formal restrictions often discourage business stakeholders. As they need to accept and confirm the correctness of the models, they should use the termionology established in the business context. The approach presented here rather puts emphasis on involving and engaging people by eliminating barriers form modelling processes. It, therefore, incorporates typical techniques from Change Management as presented in [19] or [17].

Conclusions
The paper at hand presents a domain-specific language for modeling processes in parcel distribution centers as well as the corresponding methodology. The language has been defined by a global logistics company and been used in several process definition workshops. Not only providing the language but also supporting process workshops have been perceived as valuable by logistics experts.
Nevertheless, the method is still subject to further evaluation. So far, it was only applied in a single parcel logistics company but testing it in a broader audience might improve the quality of the approach. The authors, therefore, strive at distribution the approach to further companies. Although the language has been designed for processes in parcel distribution centers, it might also be applicable to other areas. Further research is required for adapting the approach to additional areas.