I use an action research approach to present my projects, devoted to analyzing and describing processes in large sized companies. The cycle of interactions between theory and practice, proposed by action research, is described by means of the Checkland model and its elements. I shortly present the methodologies exploited in the projects, their main characteristics and results. In particular the different taxonomies and notations used during the process analysis are described. The topics of map sharing among different functions, formal/informal use of notation, meaning of the graphical symbols (for instance arrows) are posed as reflection and research themes.
In this paper, as suggested by E. Mumford [
In particular, as described in [
In Section 2 I briefly describe this approach, using the framework proposed in [
Section 3 summarizes the methodological framework that drive my practice: the
development of management systems in accordance with ISO 9001: 2015 “Quality
Management Systems - Requirements” [
The experiences, described in Section 4, are the real world situations. They are a cluster of projects. Some projects have been running from several years others started recently. All of them are in large sized companies. Among the features of the projects, in this paper the focus is on the taxonomies and the notations used to develop process analysis. Examples are presented and the main results of the projects are shortly summarized.
Section 5 and 6 present the key points of an action research approach: the reflection on my projects and the proposal of research themes. The reflections confirm the effectiveness of maps in supporting a socio-technical design and open two questions related to the informal-formal use of notations and of the meaning of graphical symbols, in particular of arrows. Accordingly research themes are proposed: the definition of a multifocal mapping toolset for the socio-technical design, the analysis of the meaning of the notations from the social and the technical perspective and the exploration of new mapping approaches. 2
As stated by E. Mumford ‘The story of socio-technical design is closely allied with
action research’ [
I shortly summarize my methodological toolkit, described in [
ISO Management Systems. The criteria that drive my practitioner activities are based on the business models proposed by ISO standards on management systems, including the analysis of context and risks.
Process Analysis. Since 2000, the Standard ISO 9001 on Quality Management
System has prescribed a process approach. I must therefore use process analysis for
“understanding and managing interrelated processes as a system” [
Socio-technical Design. In the socio-technical Design I have identified several
similarities with the concerns of my practitioner activities: the idea that “technical
structure and work roles are both part of an inclusive system” [
Ethnographic Approach. The ethnographic approach, described in [
Mapping. My activities are backed up by several types of graphical tools: maps are always used to perform field observation of large sized companies. The maps are useful for exploring, for describing and defining relationships (organizational charts and processes), and for tracking and modifying behavior.
Among these topics, in the experiences presented in this paper I applied: Process Analysis, Socio-technical design and Mapping. 4
Process Analysis is a key requirement of ISO 9001:2015, exploited in all my projects
as part of the development of a quality management system. ISO defines a process as
a ‘set of interrelated or interacting activities that use inputs to deliver an intended
result. Whether the intended result of a process is called output, product or service
depends on the context of the reference’ [
The cluster of experiences I present is in four large sized companies. I do not describe a specific case, but a synthesis of all these experiences is proposed, focusing on mapping and notation. 4.1
The large sized companies I worked with share several common features that are
described in [
The main and common features of the described projects are listed in the following.
• The objective of all these projects is producing a set of maps that describe, at least,
the processes that manage the customer relationships from offer and order
management to delivering and customer servicing. The description of these core
processes could be enlarged, if possible, to other processes, for instance measurement
and monitoring, human resources management, continuous improvement, etc..
• As described in [
During the projects the processes have to be suitably identified and classified and then a key point was how to define and to describe the processes, focusing on the topics related to taxonomies and maps.
To define the processes I deal with several scenarios. In some cases I worked with a roughly structured list of process names, just generic descriptions, such as production, customer order handling, delivery, etc. considering also taxonomies of other functional areas. For instance the controlling function defines customer order handling as ‘order to cash’ and the supplier order handling as ‘purchase to pay’.
In other cases I had to analyze more structured taxonomies, as described in the
following.
• The list of processes required by Railway ISO/TS 22163:2017 ‘Railway
Applications-Quality management system’ [
To describe the processes, the inventory of the map toolkit includes descriptive
tools and graphical tools. Some of them are sketched in Figure 2 and described in the
following.
• Tables where the column define process (name and description), input, output or,
in a more structured way, SIPOC (Supplier, Input, Process, Output, Customer)
descriptions. SIPOC is proposed by Six- sigma management approach [
These maps could be linked to process owners, documents, KPIs, Risk analysis, etc. and could change: for instance if the business model changes the process ownership could change with the model. I present a synthesis of the process mapping I developed in the cluster of experiences.
As described before, to develop a quality management system, I have to map, at least, the processes that manage the customer relationships from offer and order management to delivering and customer servicing. These processes are linked with the ISO requirement ‘8. Operation’ that describes the ‘Customer related processes’.
If I have non constraints in using the notation (for instance Turtle Chart), I prefer using, in an informal way, the IDEF0 notation and producing high level maps as in figure 3. These maps are a result of my practice and of my contractual commitment. They are part of the documented information that describes the quality management system and I use them, for instance, as a guideline when performing ISO 9001 internal audit. The focus of this map is how customer requirements are deployed in the operational processes.
Applying a socio-technical design, I define this kind of map through meetings and interviews with the owners of the processes. For instance I meet the Sales Manager to describe the customer service, the Production Manager to describe the production planning, the Process Engineer to describe the production, and so on. In this way I define the ‘set of interrelated or interacting activities’ and I could describe every box of the map, in more detail. I exemplify this approach considering my experience in mapping the processes of Customer Service and Order Handling.
During the meetings on ‘Customer service’, the Sales Manager presented a set of maps that describe the processes of the Sales Department and, among them, a map on ‘Customer order handling’ as in figure 4. The processes are described focusing on the relationships with the customer and mapped with the cooperation of the IT ERP System Manager, using a BPMN. The flows have been referenced in the procedures prepared by the IT department for training of employees on the new ERP. The same flows, probably, have been used to develop the ERP, but I have not had the opportunity to meet the development team and/or to analyze their maps.
During the same meetings I discovered that the same process of ‘Customer Order handling’ was described, by the Administration and Controlling Function as ‘Order handling’, using a ‘free’ notation as in figure 5. In this case, the process is described focusing on financial topics, such as credit check. The Information Systems were involved as ‘recording tools’ (repositories, forms, data base). These process descriptions are usually on the basis of the internal audit of the controlling functions.
Then the same process of (Customer) Order Handling is described focusing on operation for the quality management system, on customer and ERP for Sales and IT and on shareholders for Controlling. The same process is described with three different notations. 4.5
The projects confirmed my belief that the analysis of the processes with a social
approach is a useful way for involvement, empowerment and change of behavior. I
described these positive results in [
The maps supported all the projects steps, acting as an effective way of communication and becoming one of the main deliverables of the projects: the framework that supports the Integrated System Management.
As means of communication they have been initially used by the project team without stressing a rigorous use of the notation. But as deliverables of the project, required as documented information of the management system, the choice and meaning of the notation became a key point of discussion in the team. In the presented experiences, only one organization describes all the processes with the same notation (BPMN).
The relationships with the other functions that exploit process analysis had
different results. For instance, in some projects, the gap with Controlling functions was
reduced sharing common maps to describe processes related to customer and supplier
management. The weak point was still in defining link with the technical side, i.e. the
IT functions and their approach in business process analysis, even if the project teams
deal with the same processes and share the same notation. In [
I present, as described in section 2, some points of reflection, related to Process Analysis, Socio-technical Design and Mapping, that rose up during my projects. 5.1
The recent projects reinforced my hypothesis that ‘maps could be conceived as
windows for viewing the world and as artefacts to modify the world’ [
The enlarged inventory of taxonomies and notations confirms the role of maps to communicate. Most of the company presentations I analyzed in the projects are based on maps. Inside the organizations, even the color and the shape of symbols could be a reference. 5.2
For communication even a naïve graph is effective. But if want to move in a more structured direction the trend is from informal to formal interpretation of taxonomies and graphical symbols.
I exemplify, using APQC taxonomy that describes these main categories of Operating processes.
1.0 Develop Vision and Strategy 2.0 Develop and Manage Products and Services 3.0 Market and Sell Products and Services 4.0 Deliver Physical Products 5.0 Deliver Services 6.0 Manage Customer Service
In all these categories part of the processes could be performed using Information Systems. For instance in ‘3.0 Market and Sell Products and Services’ the activities of ‘3.5.4 Manage Sales Order’ –‘3.5.4.5 Enter orders into systems’ are usually supported by an ERP. But ‘2.0 Develop and Manage Products and Services’ is usually performed with several different information systems (including social media) or without them.
In my projects the business process maps connected these layers considering the information systems as tools or data repositories. Probably, the same business processes had been described, from a different point of view, to develop the information systems. In some experiences the BPMN was used to describe the same processes from the two perspective but the process maps, as far as I know, had no relationships.
In any case, my efforts continue to be in connecting these different ‘point of view’ and these different layers of the organizations, for instance including IT function in meeting and interview. 5.3
In mapping the processes, moving towards a better definition of graphical symbols, I often reflected on their meaning. • Boxes, and more generally polygon, mostly always describe an activity, including as a particular type of activity, the choice. • Different symbols (box or text) describe the ownership of processes and activities. • Arrows describe different types of relationships: ─ informal relationship with sequence and interactions, suggesting a goal to reach ─ main relationship with input/output (SIPOC and IDEF0) and secondary with time ─ main relationship with time (BPMN) and secondary with input/output Then, with different meanings, arrows are linked to time direction (before/after) and to entities.
Furthermore, during my projects, I often argued why processes are usually represented through boxes and arrows and why in the ‘network era’ this ‘deterministic’ approach is still prevalent. 6
Considering the reflections previously described, I pose these research themes, presently without any structured findings. 6.1
The process analysis could be developed in different functional areas of the organizations. In my experiences, these areas often describe the process with similar notations but without sharing any type of information. In a socio-technical perspective, a multifocal approach (researcher, practitioner and organization) have to explore the possibility of a common background, with different layers for a socio-technical design, sharing methodological tools and developing a mapping toolset, moving from a less formal to a more formal use of notation. 6.2
In a recent paper on business process models [
Then the question ‘Is there anything beyond arrows?’ posed in the title, suggests me the answer ‘…so many things beyond arrows’ or, better, so many meanings of the arrows.
Let’s consider for instance the historical dependence, where ‘one can perform an
activity on an artefact only if this artefact exists and is available’. The paper [
I consider as an example of the historical dependence, the supply chain process of delivering a product that requires the sequence: handling the customer order, producing or buying the product and delivering. This dependence could be monitored if all the events are tracked on the same medium, for instance an ERP. The complexity in describing this dependence increases if the media are several or none, for instance if the data for managing customer relationships are on a file system and the activities of driving a truck are not recorded.
If the use of process maps could be a bridge between the social and the technical side, researchers and practitioners have to focus on the notations that support them, considering structured approaches but also modifying their mindset and exploring other graphical tools.