<?xml version="1.0" encoding="UTF-8"?>
<TEI xml:space="preserve" xmlns="http://www.tei-c.org/ns/1.0" 
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" 
xsi:schemaLocation="http://www.tei-c.org/ns/1.0 https://raw.githubusercontent.com/kermitt2/grobid/master/grobid-home/schemas/xsd/Grobid.xsd"
 xmlns:xlink="http://www.w3.org/1999/xlink">
	<teiHeader xml:lang="en">
		<fileDesc>
			<titleStmt>
				<title level="a" type="main">Defining mechanisms for having a socio-technical system aligned</title>
			</titleStmt>
			<publicationStmt>
				<publisher/>
				<availability status="unknown"><licence/></availability>
			</publicationStmt>
			<sourceDesc>
				<biblStruct>
					<analytic>
						<author role="corresp">
							<persName><forename type="first">Ilia</forename><surname>Bider</surname></persName>
							<email>ilia@dsv.su.se</email>
							<affiliation key="aff0">
								<orgName type="institution">Stockholm University</orgName>
								<address>
									<addrLine>Borgarfjordsgatan 12</addrLine>
									<postCode>164 55</postCode>
									<settlement>Kista, Stockholm</settlement>
									<country key="SE">Sweden</country>
								</address>
							</affiliation>
							<affiliation key="aff1">
								<orgName type="institution">University of Tartu</orgName>
								<address>
									<addrLine>Ülikooli 18</addrLine>
									<postCode>50090</postCode>
									<settlement>Tartu</settlement>
									<country key="EE">Estonia</country>
								</address>
							</affiliation>
						</author>
						<title level="a" type="main">Defining mechanisms for having a socio-technical system aligned</title>
					</analytic>
					<monogr>
						<idno type="ISSN">1613-0073</idno>
					</monogr>
					<idno type="MD5">031FBF9A66791E596582528179FBBDDD</idno>
				</biblStruct>
			</sourceDesc>
		</fileDesc>
		<encodingDesc>
			<appInfo>
				<application version="0.7.2" ident="GROBID" when="2025-04-23T17:45+0000">
					<desc>GROBID - A machine learning software for extracting information from scholarly documents</desc>
					<ref target="https://github.com/kermitt2/grobid"/>
				</application>
			</appInfo>
		</encodingDesc>
		<profileDesc>
			<textClass>
				<keywords>
					<term>socio-technical</term>
					<term>alignment</term>
					<term>Fractal Enterprise Model</term>
					<term>FEM 1</term>
				</keywords>
			</textClass>
			<abstract>
<div xmlns="http://www.tei-c.org/ns/1.0"><p>A socio-technical system consists of several components that should be aligned in order for the system to function properly. As the environment in which the system functions constantly changes, alignment cannot be achieved once and continues to exist. There should be alignment mechanisms that ensure the alignment continues to exist. The paper introduces the idea of how to depict mechanisms for alignment that can be used for both (a) checking whether the alignment mechanisms exist and (b) introducing them if none exists for a particular type of alignment. Definitions need to be somewhat formal so that the presence of mechanisms can be discovered. This paper uses a special enterprise modeling technique called Fractal Enterprise Model (FEM) to clarify the idea and give some examples. However, this does not mean that other enterprise modeling techniques could not be used for the purpose.</p></div>
			</abstract>
		</profileDesc>
	</teiHeader>
	<text xml:lang="en">
		<body>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="1.">Introduction</head><p>The classical work <ref type="bibr" target="#b0">[1]</ref> introduces a Socio-Technical Matrix (STM) presented in Fig. <ref type="figure" target="#fig_0">1</ref>. According to this matrix, a Socio-Technical System (STS) can be presented as consisting of two parts: Social and Technical. Each part, in turn, can be further divided; the Social part consists of People and (social) Structure, while the Technical part consists of Tasks and Technology. The arrows in Fig. <ref type="figure" target="#fig_0">1</ref> show that all parts should be synchronized/aligned. STM gives a very rough picture of the structure of the STS, but in this work, we are only interested in the idea that, independently of how the system is divided into parts, there should be alignment between them. We consider an organization as an autopoietic system <ref type="bibr" target="#b1">[2,</ref><ref type="bibr" target="#b2">3,</ref><ref type="bibr" target="#b3">4]</ref>, which constantly rebuilds itself based on the elements taken from the environment. As the environment constantly changes, the new elements acquired from it differ from the ones they substitute. This can lead to alignment between internal parts becomes broken and needs to be restored. This happens, for example, when new technology is employed that radically differs from the previous one, or a new generation of workers is employed that has a different education and a different set of values.</p><p>An organization can also choose to adopt a different way of organizing work, e.g., adopting an agile methodology. The change in organizational principles and technology can be forced by changes in the environment outside the organization and cannot be connected to the need to substitute old technology. It might be needed, for example, to preserve a competitive advantage.</p><p>Our focus is on what mechanisms could be employed to preserve the alignment. More specifically, we are interested in keeping alignment when no major changes are completed, such as installing new equipment that requires changing the existing business processes and retraining the workers. As major, we consider changes that require a special project to be completed. However, a project, due to limitations on time and resources, cannot achieve total alignment. For example, training cannot cover all possible uses of the new technology. Thus, mechanisms should exist to restore and preserve alignment even after major changes are made in the internal environment. These mechanisms also need to take care of changes in the organization's staff when some workers leave, and new workers are hired, slight changes in the customer base or in the products and services provided, etc. Our long-term goal is to create a repository of alignment mechanisms expressed more or less formally. The idea is to use an enterprise modeling language for the purpose. This will ensure some formality of description. To fully exploit such a repository, an organization will need to have/build an enterprise model depicted in the same language. In this case, depicted alignment mechanisms could be used as patterns to search the model to see whether these mechanisms already exist in the organization. If some mechanism does not exist but makes sense, it could be incorporated into the to-be model of the organization and implemented.</p><p>The goal of this paper is to demonstrate how the alignment mechanisms can be formally defined. For this purpose, we will use Fractal Enterprise Model (FEM) <ref type="bibr" target="#b4">[5,</ref><ref type="bibr" target="#b5">6,</ref><ref type="bibr" target="#b6">7]</ref>. There are several reasons why we have chosen this specific modeling technique. Firstly, this is our own invention, and we have enough experience in creating FEMs. Secondly, we believe that FEM has enough expressive power to depict alignment mechanisms, which need to be tested in practice. Thirdly, it does not matter which modeling technique we start with when testing the idea. If the technique shows not to be good for the purpose, it could be changed at certain phase of development.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Tasks Technology Structure</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>People</head></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Social Technical</head><p>The rest of the paper is structured in the following way. In Section 2, we give some background information that concerns examples we are about to explore. Section 3 introduces FEM and presents the idea of how an STS can be depicted using this modeling technique. Section 3 gives two examples of alignment mechanisms and how they can be depicted using FEM. Section 4 summarizes the results achieved and draws plans for the future.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="2.">Tacit Knowledge</head><p>Examples used in this paper concern alignment between the people's tacit knowledge and other elements of the organization, e.g., IT systems. This section presents some basic material related to tacit knowledge and how it is managed in organizations.</p><p>The term tacit knowledge was introduced by Michael Polanyi to differentiate internal knowledge from explicit or codified knowledge in books, manuals, papers, etc. Moreover, he believed that actual knowledge was always personal and tacit <ref type="bibr" target="#b7">[8]</ref>, while explicit knowledge was used for transferring tacit knowledge. Now, the term tacit knowledge is central to the Knowledge Management (KM) discipline, which deals with the usage and management of knowledge in both tacit and explicit forms. One of the important achievements in KM is the SECI model of Nonaka <ref type="bibr" target="#b8">[9]</ref>, which explains how knowledge is created in organizations, where SECI stays for Socialization -Externalization -Combination -Internalization, see Fig. <ref type="figure" target="#fig_0">1</ref>.</p><p>In Fg.1, socialization refers to changing the knowledge while it remains in the tacit form without converting it to the explicit form; externalization refers to transforming the knowledge from the tacit to the explicit form; combination refers to transforming knowledge in its explicit form; internalization refers to transforming knowledge from the explicit to the tacit form. In this paper, we will give examples of three of SECI's transformations, leaving socialization outside our consideration. </p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="3.">Components of STS from FEM perspective</head><p>In this paper, we consider STSs that are arranged around a repetitive business activity, such as a business process or delivering a business service. In Fig. <ref type="figure">3</ref>, we present an example of the socio-technical components of such a system that need to be aligned with each other. The model designed using the FEM technique presents the process/service as an oval and assets that are needed to repeatedly run the process as rectangles connected to the oval with arrows. An arrow with a solid line means that the asset is used in the process, and an arrow with a dashed line shows that the process changes the asset. The label on an arrow points to the asset's role in the process or how the process changes the asset.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Figure 3: Components of STS depicted in a FEM</head><p>Besides the assets that have a physical representation, Fig. <ref type="figure">3</ref> shows tacit assets that have a dash-dotted border; they represent the knowledge and skills of the internal participants (Workforce) that are used for repeatedly running the process. These assets are connected to the workforce asset by asymmetric association (blue arrow) with the label Reside within. We differentiate two types of tacit assets: Procedural and Factual. The procedural asset is about how to run the process, what activities to complete, how to use equipment, etc. The factual asset is the knowledge that is needed when completing particular activities.</p><p>The procedural knowledge is used in a process as EXT (EXecutable Template), i.e., this asset controls how the process is driven. The factual knowledge is used as technical &amp; informational infrastructure. Besides these two tacit assets, there are other assets in Fig. <ref type="figure">3</ref> that fill the same roles. Manuals and references contain procedural and factual information in the form of text, pictures, and videos, which can be used by the workforce when running the process. Another asset often used in processes is IT systems that help run the process; such systems can include elements of control, e.g., when a workflow system is used. Besides arrows that show how tacit assets are used in the process, Fig. <ref type="figure">3</ref> has arrows that show that tacit assets are changed by the process. These arrows that have three labels -Acquire, Maintain, and Retire -show that the tacit assets are being changed during the process runs. They reflect the fact of getting experience while participating in the process.</p><p>As seen in Fig. <ref type="figure">3</ref>, two types of assets fulfill the role of EXT and Tech &amp; Info infrastructure: tacit and explicit (tangible). These two types of assets need to be aligned for the process to run smoothly and effectively. This can be done by changing tacit assets or changing physical assets. Examples of how such alignment could be achieved are presented in the next section.</p><p>Besides elements of the STS system, Fig. <ref type="figure">3</ref> has several elements that illustrate that this system is an autopoietic system. These elements are highlighted by having a thicker border. They present supporting processes that aim to have the system assets in "working" order. They acquire new elements for assets, maintain assets in working conditions, and remove elements that can no longer serve the process. Depending on the type of assets, the latter can mean retirement or firing some staff members, phasing out old IT systems, etc. These processes are connected to the pools -cloud shapes, which are elements of the organization's environment. The pools are connected to the processes by dashed blue arrows with a rounded start. The arrow shows that the process can draw elements from the pool to convert them to the elements of the respective assets. This corresponds to production+bounding as defined by <ref type="bibr" target="#b2">[3]</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.">Examples of the alignment mechanisms</head><p>In this section, we present two examples of alignment mechanisms that are aimed at alignment between the tacit knowledge of process participants and tangible assets, such as IT systems and manuals. The first example concerns IT support, which is mostly directed at changing the tacit procedural knowledge of the process participants so that they can properly use IT systems in the process. This corresponds to Internalization in Fig. <ref type="figure" target="#fig_1">2</ref>. The second example concerns changing tangible assets, like IT systems, manuals, reference books, etc., so that they incorporate the experience of the process participants obtained while they were engaged in the process. This corresponds to Externalization + Combination in Fig. <ref type="figure" target="#fig_1">2</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.1.">IT support</head><p>In this section, we consider a mechanism that ensures alignment between tacit procedural knowledge that belongs to the workforce and IT systems and manuals. The FEM model of this mechanism is represented in Fig. <ref type="figure">4</ref>. The upper part of the model is a reduced version of Fig. <ref type="figure">3</ref>; it has only procedural tacit knowledge and only manuals that concern IT systems. The lower part represents an alignment mechanism whose elements are highlighted using a sicker border. The mechanism has two additional processes that are responsible for maintaining alignment: (1) IT support for end-users and (2) IT system maintenance. The first one is responsible for changing the tacit procedural knowledge if this can bring about alignment, and the second one is responsible for changing IT systems and their manuals in order to bring about alignment. These two processes are interconnected. If the alignment is not possible to achieve by changing the tacit knowledge, the IT support creates an issue, which the maintenance should resolve.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Figure 4: FEM for IT support mechanism</head><p>The primary objective of IT support for end-users is to change the tacit knowledge of the internal participants. As this asset is tacit, it cannot be changed without the owners of this tacit knowledge participating in the process. Therefore, there are two assets (groups of people) that participate in the IT support process as Workforce. Achieving the above objective corresponds to Internalization in Fig. <ref type="figure" target="#fig_1">2</ref>.</p><p>If the problem that internal participants have cannot be solved by instructing them how to use the systems, a new issue is created in the asset Issues for developers to solve. This asset serves as an EXT for IT system maintenance. The arrow from Issues to Maintenance has an additional label -Stock, which means that a process run consumes one or several elements from the Issues asset. This behavior is different from the behavior of other assets that are used in many runs of a process to which they are connected. The Stock label also changes the visualization of an arrow, which gets two extra lines at the tail of the arrow, see Fig. <ref type="figure">4</ref>.</p><p>In case of an issue is created, the process IT support for end users externalizes the tacit knowledge of the participants that there is a gap between their needs and what the systems provide. The process IT systems maintenance removes the gap, which corresponds to Combination in Fig. <ref type="figure" target="#fig_1">2</ref>.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="4.2.">Periodical review</head><p>The primary goal of the periodical review mechanism is to adjust tangible/physical assets, such as manuals and IT systems, to the way participants in the process actually work. For this, an explication of the participants' tacit knowledge is required. The FEM for periodical review is presented in Fig. <ref type="figure" target="#fig_3">5</ref>  This can be done in the form of facilitating workshops, interviews, surveys, etc. The intermediate results can be depicted in diagrams, e.g., process diagrams. The ultimate result of this process is a list of changes that should be made to physical assets. These are implemented by another process -Change implementation. The first process corresponds to Externalization + partial Combination (the list of what should be changed). The second process completes the Combination by providing the participants with better tools for their process.</p></div>
<div xmlns="http://www.tei-c.org/ns/1.0"><head n="5.">Conclusion</head><p>The research question that we deal with in this paper is, "How can the alignment between the components of the STS be maintained?" To answer the question, we suggest cataloging mechanisms that help maintain the alignment. To be of use, the mechanisms should be de-fined (semi)formally in a way that allows (a) either to find out that a mechanism is already present in an organization or (b) to introduce it, in case it is not present but needed. The paper suggests depicting alignment mechanisms using an enterprise modeling language. To make the suggestion more concrete and practical, we use a special enterprise modeling technique -Fractal Enterprise Model -to present two examples of mechanisms for alignment between components of STS.</p><p>As far as the two examples are concerned, it looks like FEM is quite suitable for the task of depicting alignment mechanisms. However, this statement needs more substantial evidence. The latter can be obtained by finding and depicting other alignment mechanisms that are used in practice. This constitutes our nearest goal for the future.</p></div><figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_0"><head>Figure 1 :</head><label>1</label><figDesc>Figure 1: Socio-technical matrix adapted from [1]</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_1"><head>Fig. 2 .</head><label>2</label><figDesc>Fig.2. Knowledge management in organizations adapted from<ref type="bibr" target="#b8">[9]</ref> </figDesc><graphic coords="3,195.95,443.27,220.30,115.20" type="bitmap" /></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_2"><head></head><label></label><figDesc>. The upper part of it repeats the model from Fig 3. The lower part consists of two additional processes: Periodic review and Change implementation.</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0" xml:id="fig_3"><head>Figure 5 :</head><label>5</label><figDesc>Figure 5: FEM for the periodic review mechanism</figDesc></figure>
<figure xmlns="http://www.tei-c.org/ns/1.0"><head></head><label></label><figDesc></figDesc><graphic coords="4,111.05,129.40,383.75,297.30" type="bitmap" /></figure>
		</body>
		<back>

			<div type="acknowledgement">
<div xmlns="http://www.tei-c.org/ns/1.0"><head>Acknowledgments</head><p>The work of the author was partly supported by the Estonian Research Council (grant PRG1226). The author is also thankful to the reviewers whose comments have helped to improve the text.</p></div>
			</div>

			<div type="references">

				<listBibl>

<biblStruct xml:id="b0">
	<analytic>
		<title level="a" type="main">MIS problems and failures: A socio-technical perspective</title>
		<author>
			<persName><forename type="first">R</forename><forename type="middle">P</forename><surname>Bostrom</surname></persName>
		</author>
		<author>
			<persName><forename type="first">J</forename><surname>Heinen</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">MIS Quarterly</title>
		<imprint>
			<biblScope unit="volume">1</biblScope>
			<biblScope unit="issue">3</biblScope>
			<biblScope unit="page" from="17" to="32" />
			<date type="published" when="1977">1977</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b1">
	<analytic>
		<title level="a" type="main">The autopoiesis of social systems</title>
		<author>
			<persName><forename type="first">N</forename><surname>Luhmann</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Sociocybernetic paradoxes</title>
				<editor>
			<persName><forename type="first">F</forename><surname>Geyer</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">J</forename><surname>Van Der Zouwen</surname></persName>
		</editor>
		<meeting><address><addrLine>London</addrLine></address></meeting>
		<imprint>
			<publisher>Sage</publisher>
			<date type="published" when="1986">1986</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b2">
	<analytic>
		<title level="a" type="main">On Social Nature of Autopoietic System</title>
		<author>
			<persName><forename type="first">Milan</forename><surname>Zeleny</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Evolution, Order and Complexity</title>
				<editor>
			<persName><forename type="first">Kenneth</forename><surname>Boulding</surname></persName>
		</editor>
		<editor>
			<persName><forename type="first">Elias</forename><surname>Khalil</surname></persName>
		</editor>
		<imprint>
			<publisher>Taylor &amp; Francis Group</publisher>
			<date type="published" when="1996">1996</date>
			<biblScope unit="page" from="122" to="145" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b3">
	<analytic>
		<title level="a" type="main">Using Enterprise Models to Explain and Discuss Autopoiesis and Homeostasis in Socio-technical Systems</title>
		<author>
			<persName><forename type="first">I</forename><surname>Bider</surname></persName>
		</author>
		<author>
			<persName><forename type="first">G</forename><surname>Regev</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><surname>Perjons</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">CSIMQ</title>
		<imprint>
			<biblScope unit="volume">22</biblScope>
			<biblScope unit="page" from="21" to="38" />
			<date type="published" when="2020">2020</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b4">
	<analytic>
		<title level="a" type="main">A fractal enterprise model and its application for business development</title>
		<author>
			<persName><forename type="first">I</forename><surname>Bider</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><surname>Perjons</surname></persName>
		</author>
		<author>
			<persName><forename type="first">M</forename><surname>Elias</surname></persName>
		</author>
		<author>
			<persName><forename type="first">P</forename><surname>Johannesson</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">SoSyM</title>
		<imprint>
			<biblScope unit="volume">16</biblScope>
			<biblScope unit="issue">3</biblScope>
			<biblScope unit="page" from="663" to="689" />
			<date type="published" when="2017">2017</date>
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b5">
	<analytic>
		<title level="a" type="main">Tool Support for Fractal Enterprise Modeling</title>
		<author>
			<persName><forename type="first">I</forename><surname>Bider</surname></persName>
		</author>
		<author>
			<persName><forename type="first">E</forename><surname>Perjons</surname></persName>
		</author>
		<author>
			<persName><forename type="first">V</forename><surname>Klyukina</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="m">Domain-Specific Conceptual Modeling</title>
				<imprint>
			<publisher>Springer</publisher>
			<date type="published" when="2022">2022</date>
			<biblScope unit="page" from="205" to="229" />
		</imprint>
	</monogr>
</biblStruct>

<biblStruct xml:id="b6">
	<monogr>
		<author>
			<persName><surname>Fractalmodel</surname></persName>
		</author>
		<ptr target="https://www.fractalmodel.org/" />
		<title level="m">Fractal Enterprise Model</title>
				<imprint/>
	</monogr>
</biblStruct>

<biblStruct xml:id="b7">
	<monogr>
		<author>
			<persName><forename type="first">M</forename><forename type="middle">S</forename><surname>Polanyi</surname></persName>
		</author>
		<title level="m">Knowing and Being</title>
				<meeting><address><addrLine>Chicago</addrLine></address></meeting>
		<imprint>
			<date type="published" when="1969">1969</date>
		</imprint>
		<respStmt>
			<orgName>University of Chicago</orgName>
		</respStmt>
	</monogr>
</biblStruct>

<biblStruct xml:id="b8">
	<analytic>
		<title level="a" type="main">A dynamic theory of organizational knowledge creation</title>
		<author>
			<persName><forename type="first">I</forename><surname>Nonaka</surname></persName>
		</author>
	</analytic>
	<monogr>
		<title level="j">Organ. Sci</title>
		<imprint>
			<biblScope unit="volume">5</biblScope>
			<biblScope unit="issue">1</biblScope>
			<biblScope unit="page" from="14" to="37" />
			<date type="published" when="1994">1994</date>
		</imprint>
	</monogr>
</biblStruct>

				</listBibl>
			</div>
		</back>
	</text>
</TEI>
