Skip to Content
InformationInformation
  • Article
  • Open Access

13 October 2026

15 Pages

Dependency Restructuring: How Technological Enactment Changes Organizational Requirement Relations

Energee3 S.r.L., 42121 Reggio Emilia, Italy

Abstract

Digital technologies can change organizational work without changing the dependencies through which work is coordinated. This article examines the cases in which those dependencies do change. The analysis separates changes in activities from changes in dependencies and from the coordination needed to manage them. Its main contribution is a bounded meso-level framework that treats dependency restructuring as an independently observable change between technological enactment and subsequent coordination requirements. The framework specifies observable forms of dependency change and derives two conditional propositions. Individual dependency relations may be created, eliminated, or redirected to a different provider; previously separate sets of dependencies may also become connected. The first proposition concerns situations in which local autonomy increases while reliance on a shared technological or external capability also increases. The second concerns situations in which different technologies produce similar coordination requirements because they generate similar dependency configurations under similar organizational conditions. Two evidence-based illustrations—enterprise cloud migration and artificial intelligence integration in organizational workflows—show how the approach can be applied without treating the cases as tests of the theory. The article also provides an empirical identification procedure for distinguishing activity change, dependency change, and coordination response.

1. Introduction

Digital technologies can change organizations in several ways. They can accelerate an existing exchange, automate an activity, alter the sequence of a process, move work across an organizational boundary, or change the division of labor between people and technological systems. These changes are often discussed as digital transformation, process redesign, automation, integration, or technological enactment. This article addresses a narrower question: when the arrangement of activities changes, do the requirement relations connecting those activities change as well [1,2,3]?
A change in the technology used to coordinate work is not necessarily a change in the dependency being coordinated [4,5,6]. Suppose two activities remain in a producer-consumer relationship, but paper transmission is replaced by electronic transmission. The coordination mechanism changes, but the underlying requirement relation may remain the same. By contrast, if a shared information system makes the producer’s recurrent transfer unnecessary, the direct relation may disappear, the requirement may be redirected toward a technological capability, and new dependencies on shared data, infrastructure, governance, or providers may emerge. In that case, the dependency configuration itself has changed.
Technology adoption and activity change alone may not explain why organizations face different coordination problems [7,8]. Comparable technologies can be enacted differently and produce different dependency configurations. Conversely, different technologies can produce similar configurations and, under comparable organizational conditions, similar coordination requirements. The proposed mechanism matters only when the observed change in dependencies explains something that a technology category or activity change alone does not.
Several established literatures address different parts of this problem. Coordination theory treats dependencies among activities as the basis of coordination problems and examines alternative mechanisms for managing them [4,5]. Organization design research shows that interdependence can arise endogenously through task, goal, and knowledge structures [9]. Research on information technology and organizational change also rejects simple technological determinism and emphasizes the role of organizational structures, human agency, and enactment in shaping outcomes [7,8]. Process redesign research represents activity relationships directly and examines how redesign operations alter them [10], while mirroring and modularity research examines how technical and organizational interdependencies can be structured or reduced [11,12]. Broader digital-transformation research places such relational changes within wider processes of structural and organizational change [1,2]. Recent work further examines coordination in digital platforms [13], human–AI divisions of labor and interdependent AI adoption [3,14], technology-enabled coordination affordances [6], and the reconfiguration of interdependence in digital ecosystems [15].
These studies already establish that dependencies can change, that technology can affect interdependence, and that process redesign can alter relations among activities. The unresolved issue is more specific: How can a change from one organizational dependency configuration to another be identified, and when does that change help explain new coordination requirements? Addressing this question requires keeping activity change, dependency change, and coordination response analytically separate.
The relevant object is not the technology in isolation but the pattern of relations among the activities, people, technological components, and external providers that together make organizational performance possible. Dependency restructuring focuses on changes in that relational pattern. A local technological intervention can therefore remain local if the surrounding requirement relations are unchanged, or it can become a system-level organizational change when requirements are redistributed across multiple activities or concentrated on shared internal or external capabilities. This distinction clarifies when a technological change has consequences for the wider organizational system without assuming that every technological change is systemic.
The research question is as follows: How does organizational enactment of technological capabilities change the requirement relations among activities, and under what conditions do those changes alter coordination requirements? The article first locates dependency restructuring within the relevant literature, then defines the mechanism and the observable forms of dependency change, and finally develops two conditional propositions together with a procedure for comparing configurations before and after technological enactment.
The scope is limited to changes in organizational requirement relations. Digital technology can also affect identity, power, legitimacy, learning, culture, strategy, and value creation through other mechanisms. Dependency restructuring applies only when technological enactment changes what organizational activities require from one another or from technological and interorganizational providers.

2. Literature Review and Theoretical Positioning

Coordination theory treats dependencies among activities as the source of coordination problems and distinguishes those dependencies from the mechanisms used to manage them [4,5]. Organization-design research likewise treats interdependence as a central design problem and examines different forms of interdependence among tasks and organizational actors, together with the information-processing demands they create [9,16,17]. These approaches establish that dependency and interdependence are not new objects of analysis; the question for the present article is more narrowly how a dependency configuration can be observed to change after technological enactment.
Business Process Management (BPM) and process redesign research provide a second adjacent perspective. BPM represents activities, events, flows, performers, and process structures and supports the analysis and redesign of business processes [10,18]. Recent BPM research also represents activity dependencies that go beyond execution order and traces structural consequences of redesign operations across related activities [19,20]; a systematic review of digitally enabled process redesign maps technological capabilities to redesign heuristics [21]. Research at the intersection of BPM and digital innovation further shows that emerging technologies can reshape BPM itself, extending it from more traditional approaches toward more exploratory forms of process management [22]. In the terminology used here, an activity may therefore correspond to a process activity or task, while its performer may be represented as a process resource. A requirement relation is not, however, equivalent to a control-flow or other BPM activity-dependence relation: it records a substantive input, resource, output, state, or capability required by an activity and the locus that supplies it. This distinction allows a process or resource-assignment change to occur without assuming that the underlying requirement relation has changed.
Architectural approaches provide a third point of comparison. Modularity and mirroring research examines how technical and organizational interdependencies can be reorganized [11,12], while Design Structure Matrix methods represent system elements and their interactions across product, organizational, and process architectures [23]. These approaches show that dependency structures can already be represented and, in some settings, redesigned. Dependency restructuring therefore does not claim novelty for dependency mapping itself; its narrower purpose is to identify a before-and-after change in what activities require and in the loci from which those requirements are supplied.
Finally, research on technology and organization rejects a deterministic link between a technological capability and a single organizational outcome [7,8]. A practice-lens account of technological enactment similarly emphasizes that technologies acquire organizational consequences through situated use [24]. Recent research on IT-enabled organizational transformation develops this point at the level of organizational change: structured reviews identify process redesign as a recurrent level of transformation, while process models distinguish IT-enabled organizational transformation from broader digital transformation [25,26]. Recent theory also links the task-and-transfer structure of technologies to feasible organization designs [27]. The present framework is complementary but different in explanatory direction: it begins with organizational enactment and asks whether the realized activity change is accompanied by an independently observable change in requirement relations before any subsequent coordination response is inferred. This is the specific gap addressed by the dependency-restructuring framework.

3. Materials and Methods: Conceptual Development

3.1. Conceptual Development Method

This is a conceptual article. It develops the argument by clarifying concepts and relationships rather than by testing hypotheses with new empirical data or conducting a systematic literature review. Following Jaakkola [28], the development procedure is made explicit so that the role of dependency restructuring can be assessed against related explanations. During manuscript preparation, ChatGPT (OpenAI, GPT-5.6 Sol) (OpenAI) was used to support drafting, language editing, structural revision, and the structured literature completeness check. For the latter, the tool assisted in formulating and refining the Scopus search strings, deduplicating the bibliographic records, screening titles and abstracts against the predefined criteria, and assessing candidate contributions according to their potential effect on the framework. AI-assisted screening outputs were used as analytical support, while the sources incorporated into the manuscript and the resulting theoretical interpretations were reviewed by the author, who retains full responsibility for the analysis and conclusions.
The conceptual development proceeds by separating activities, dependencies, and coordination requirements; examining theoretical domains according to which parts of this explanandum they already address; formulating the remaining relational problem as dependency restructuring; and deriving propositions, boundary conditions, and an empirical identification procedure. The literature comparison is therefore problem-driven rather than systematic. The review considers coordination and interdependence, process and activity redesign, modularity and mirroring, technological enactment and affordances, and broader digital transformation because these domains address different components or boundaries of the explanandum.
After the framework and its theoretical positioning had been developed, a structured completeness check was conducted in Scopus to reduce the risk that the problem-driven selection had omitted recent or directly competing work. The check was designed to identify contributions capable of rendering the proposed distinction redundant, narrowing or modifying its theoretical positioning, affecting its boundary conditions, or altering its empirical identification. It was not used to retrospectively derive the framework and is not presented as a systematic literature review. Operational details are reported in Supplementary File S1.

3.2. Terms and Unit of Analysis

The basic unit of analysis is the activity, not the job title or organizational unit of the person who performs it. An activity may require an input, resource, output, state, or capability supplied by another activity, a technological system, or an external provider. This paper calls that requirement a requirement relation. The full set of such relations at a given time is the dependency configuration. Coordination requirements are the communication, synchronization, control, accountability, governance, or cross-boundary arrangements needed to manage those dependencies. When configurations are compared over time, activities must be described at the same level of detail; otherwise, an apparent change in dependencies may simply reflect a different description of the work. The activity must also be kept distinct from its performer. Moving an activity from a person to a technological system changes who or what performs it, but it changes the dependency configuration only if what the activity requires also changes. For compactness in the formal passages below, A_t denotes the activity configuration, D_t the dependency configuration, and C_t the associated coordination requirements at time t.

4. Conceptual Results: The Dependency-Restructuring Framework

Table 1 places dependency restructuring alongside related concepts and shows which part of the problem each study already addresses.
Table 1. Positioning dependency restructuring against adjacent constructs.
Changing dependencies is not a new idea. Coordination theory and the MIT Process Handbook already use dependencies to analyze and redesign organizational processes [29,30]. Andree, Bano, and Weske [10] show explicitly how process redesign can change relationships among activities. Modularity research examines how interdependence can be reduced or reorganized [11], while Colfer and Baldwin [12] relate technical dependencies to organizational ties. Other studies examine interdependence between technologies [31], technology-enabled coordination [6], coordination in digital platforms [13], human–AI divisions of labor [3], interdependent decisions in AI adoption [14], and changing interdependence in digital ecosystems [15]. Baldwin [27] further links task-and-transfer structures of technologies to organization design. Dependency restructuring therefore does not claim that changing dependencies is new. Its narrower task is to identify what changes in the substantive requirements among organizational activities occur after technological enactment and in the loci that supply those requirements, while keeping that change separate from the preceding activity change and the coordination response that follows.

4.1. Definition and Dynamic Mechanism

4.1.1. Definition

Dependency restructuring (DR) is a change in the requirements that connect organizational activities after a technology is enacted. To identify it, the same activities are compared before and after the change. Dependency restructuring is present when at least one activity no longer requires something it previously required, begins to require something new, or obtains the same requirement from a different source. It is therefore different from technology adoption, digitization, automation, process redesign, or a change in the method used to coordinate an unchanged dependency.

4.1.2. Mechanism

A technological capability can make new ways of organizing activities possible, but it does not determine which one an organization will adopt. The realized arrangement depends on factors such as governance, architecture, sourcing, regulation, skills, data, interoperability, and the availability of alternatives. If enactment changes the activity configuration, the dependencies among activities may also change. If those dependencies change, the organization may then face different coordination requirements. Using the notation introduced above, T denotes the technological capability, and E its organizational enactment; the mechanism is summarized in Figure 1:
(T, E) → ΔA → ΔD → ΔC
Figure 1. Dependency-restructuring mechanism. Each arrow represents a conditional transition; dependency restructuring is identified at the ΔD step, and boundary conditions can affect both transitions and consequences.
In BPM terms, ΔA may include changes in process activities or tasks and in the performers or resources assigned to them, whereas ΔD denotes changes in substantive requirement relations rather than changes in sequence or control flow alone.
None of these transitions is automatic. Technology may alter activities without altering their dependencies, and a changed dependency configuration may be managed differently in different organizational settings. The analysis therefore treats dependency change as a possible link between technological enactment and later coordination change, not as a fixed sequence of outcomes.
Three distinctions are essential. An activity can change performer, medium, or speed while retaining the same dependencies. A dependency can change without dictating a single coordination response. And a new way of coordinating an existing dependency does not mean that the dependency itself has changed. Observing these changes separately is necessary if dependency restructuring is to have explanatory value.
Dependency restructuring is present only when at least one requirement changes: it appears or disappears, its substantive content changes, or it is obtained from a different source. Changes in speed, communication medium, interface, or performer do not count unless they also alter a requirement. The dependency change must therefore be identified independently of the coordination outcome it is later used to explain.

4.2. Observable Forms of Dependency Change

At the level of a single requirement relation, three changes are possible: creation, elimination, and redirection. Creation means that a new requirement appears. Elimination means that a previous requirement disappears. Redirection means that the same requirement remains but is obtained from a different source.These forms are summarized in Table 2.
Table 2. Elementary operators and configuration-level transformations of dependency change.
A fourth change, coupling, concerns the overall configuration rather than a single relation: previously separate sets of dependencies become connected so that changes in one affect activities in the other.
Redirection is treated separately even though it could be described formally as one relation disappearing and another appearing. The reason is practical: the substantive requirement remains the same, while only its source changes. That difference matters in cases such as outsourcing, cloud sourcing, platform dependence, and human–AI reallocation, where a requirement moves across an organizational or technological boundary.
Creation, elimination, redirection, and coupling are descriptive categories for identifying change. The theoretical claim lies in the conditional sequence connecting technological enactment, activity reconfiguration, dependency change, and coordination requirements.

Scope of the Three Elementary Changes

The three elementary categories are complete only for the way requirement relations are represented in this paper. When the same activities are compared at the same level of detail, a requirement can be absent before and present after the change (creation), present before and absent after it (elimination), or present at both times. If it is present at both times but comes from a different source, it is redirected. A change in the substantive requirement itself can be represented as the elimination of one relation and the creation of another. Coupling is treated separately because it describes a change in the overall configuration rather than in a single relation. The purpose is to provide a small set of observable changes, not a complete classification of organizational change.

4.3. Theoretical Propositions and Boundary Conditions

The two propositions concern different consequences of the mechanism. Proposition 1 follows from the redirection or elimination of a local dependency toward a shared capability, whose criticality, concentration, and substitutability shape the result. Proposition 2 concerns the relationship between dependency configuration and coordination requirements while allowing relevant organizational conditions to affect that relationship.

4.3.1. Local Autonomy and System-Level Dependence

Removing a local dependency does not necessarily reduce dependence in the wider activity system. A worker may rely less on a specialist but more on shared software. A business unit may rely less on internal IT provisioning but more on an external provider. An integrated information environment may remove bilateral requests while making many activities depend on the same data and infrastructure.
Proposition 1.
When digital enactment eliminates or redirects locally mediated dependencies toward shared capabilities that are highly critical, concentrated, and difficult to substitute, local autonomy can increase while system-level dependence increases.
Removing a local relation reduces direct reliance on another local actor or unit. Local autonomy can therefore increase. If many activities are redirected toward the same shared capability, however, continued performance becomes more dependent on that common source. The effect should be strongest when the capability is critical, when many activities rely on it, and when substitutes are scarce. It should weaken when the capability is noncritical, dependence is dispersed, alternatives are readily available, or workable local fallbacks remain.

4.3.2. Technological Similarity and Configurational Equivalence

Proposition 2.
Under comparable relevant organizational conditions, organizations using similar technologies should face different coordination requirements when enactment produces dependency configurations that differ on properties relevant to coordination. Conversely, different technologies may lead to similar coordination requirements when they produce comparable dependency configurations under comparable organizational conditions.
This proposition is deliberately conditional because coordination requirements depend on more than dependency structure alone. Governance, regulation, routines, power, and the available coordination mechanisms can all affect the response. Comparisons should therefore focus on dependency properties relevant to the coordination problem and on organizational settings similar enough to make the comparison meaningful. Relevant properties may include the locus of critical requirements, concentration on common providers, substitutability, cross-boundary dependence, and coupling among previously separate activities. These properties and the criteria for judging similarity should be specified before the comparison. The proposition is weakened if comparable configurations under comparable organizational conditions repeatedly produce very different coordination requirements.

4.3.3. Boundary Conditions

Three conditions are required. The technology must make an alternative activity configuration feasible; organizational enactment must actually change the distribution or coupling of activities rather than merely improve the inherited arrangement; and that activity change must alter at least one requirement relation. Regulation, accountability, professional jurisdiction, power, legacy architecture, governance, sourcing arrangements, skills, data quality, interoperability, and organizational knowledge can affect each condition.
Properties such as criticality, substitutability, concentration, strength, temporal sensitivity, and failure propagation do not determine whether restructuring has occurred. They help determine how consequential a given restructuring will be. This distinction separates identification of the mechanism from assessment of its effects.

5. Analytical Illustrations

The following cases are evidence-anchored illustrations, not tests of the theory. They show how a researcher could reconstruct dependency configurations before and after enactment and distinguish technology adoption from relational change. Because the source studies were not designed to test dependency restructuring, the tables include only relations supported by the reported evidence; the dependency interpretation is supplied by the present analysis.

5.1. Enterprise Cloud Migration: Local Simplification and Relocated Dependence

Cloud sourcing changes the locus through which organizations obtain computing capabilities and requires corresponding sourcing and governance choices [32]. Khajeh-Hosseini, Greenwood, and Sommerville [33] studied the prospective migration of an enterprise IT system in the oil-and-gas sector from an in-house data center to Amazon EC2. Their stakeholder analysis found potential infrastructure cost savings and a possible reduction in support calls, while also emphasizing organization-wide risks and warning against local optimization at the expense of enterprise performance.
This makes the case useful for Proposition 1: the same migration that can remove locally mediated infrastructure and support requirements can redirect critical requirements toward an external cloud locus. The source establishes the before/after sourcing change and its organizational implications; the DR reconstruction below specifies what would have to be mapped relationally to test whether local simplification coexists with greater external dependence. The corresponding D0-to-D1 reconstruction is reported in Table 3.
Table 3. Dependency restructuring in enterprise cloud migration.
The before-and-after comparison adds a relational question to the label ‘cloud adoption’: which requirements disappear, which move elsewhere, and whether dependence becomes concentrated in a different locus. Testing Proposition 1 would require measuring whether simplified local relations are replaced by greater reliance on an external capability that is critical, concentrated, or difficult to substitute. The case does not establish increased system-level dependence; it shows how that claim could be tested.

5.2. AI Integration in Organizational Workflows: Task Reallocation Does Not Identify Dependency Change

Human–AI collaboration can be treated as an organization design problem because technological participation changes possible divisions of labor between people and algorithms [3]. Oliveira, Carvalho, and Faria [34] report a qualitative case of AI integration in a leading European road-infrastructure company. Repetitive and analytical tasks shifted toward AI-supported execution, while employees moved toward more strategic activities. The study also reports human supervision, parameter adjustment, training and data-feeding activities, new AI-related skills, and internal relocation rather than direct dismissal. These observations help separate activity change from dependency change: AI assistance shows that work has been reconfigured, but dependency restructuring is present only where the existence or source of a substantive requirement also changes. Table 4 reconstructs those relations.
Table 4. Dependency restructuring in AI-integrated organizational workflows.
The labels ‘AI automation’ and ‘AI augmentation’ do not identify which dependencies have changed. That requires asking which requirements disappear, which move to an AI-supported locus, and which new oversight, data, maintenance, or capability relations arise. A longitudinal study could map these relations before and after enactment and then examine whether the resulting dependency configuration helps explain changes in communication, control, accountability, synchronization, or governance. The illustration shows how the construct can be applied; the source study itself did not test dependency restructuring.

5.3. What the Two Cases Illustrate

The two cases highlight different uses of the mechanism. Cloud migration illustrates the relocation of dependence across an organizational boundary, while AI integration shows why task reallocation alone is insufficient evidence of dependency restructuring. Together they also motivate the comparative hypotheses developed above: similar technologies may produce different coordination problems when their dependency configurations differ, whereas different technologies may produce similar problems when dependency configurations and relevant organizational conditions are comparable. These propositions remain to be tested. Table 5 compares the two analytical illustrations.
Table 5. Comparison of the two analytical illustrations.

6. Empirical Identification and Research Agenda

This section translates the conceptual framework into an empirical identification procedure for distinguishing ΔD analytically from ΔA and ΔC in longitudinal or comparative research. Dependency restructuring can be examined with longitudinal or comparative designs. The key requirement is to map activities and dependencies before and after technological enactment rather than infer dependency change from the presence of a new technology. One possible procedure follows.
  • Define the organizational objective and select a stable level of activity decomposition.
  • Map the relevant activity configuration A0 before the focal technological enactment.
  • Identify substantive requirements r among activities and the loci that supply them; reconstruct D0.
  • Document the technological capability T and how it is organizationally enacted E rather than treating adoption as enactment.
  • Reconstruct A1 and determine whether activity distribution, performer, locus, or coupling changed.
  • Reconstruct D1 at the same analytical granularity.
  • Classify ΔD through creation, elimination, redirection, and configuration-level coupling.
  • Measure changes in coordination requirements C, including communication, synchronization, control, accountability, governance, and cross-boundary coordination.
  • Measure theoretically relevant dependency properties such as criticality, concentration, substitutability, strength, temporal sensitivity, and failure propagation.
  • Test whether observed coordination consequences are better explained by realized dependency configuration than by technology category alone.
Longitudinal designs are especially appropriate because dependency restructuring is defined as change over time. Comparative studies can instead examine organizations using similar technologies but enacting them differently, or different technologies that create similar dependency patterns. Network representations may help when activities can be treated as nodes and requirements as links, but they are not required.

7. Discussion

7.1. Theoretical Contribution and Implications

The theoretical contribution lies in separating activity change, dependency change, and coordination response so that the middle step can be examined directly. Existing research explains many elements of this process; the question is whether an independently observed change in what activities require adds explanatory value for the coordination requirements that follow.
The system contribution is to distinguish a change in system elements from a change in the relations that connect them. A new technology may alter who performs an activity, how fast it is performed, or the medium through which information moves while leaving the requirement structure intact. When enactment changes that structure, however, the organizational system faces a different coordination problem. This relational view also explains why a gain in local autonomy can coexist with greater system-level dependence: fewer local exchanges may be accompanied by stronger reliance on a shared platform, infrastructure, data resource, or external provider. System-level dependence is therefore a property of the resulting configuration, not a direct property of the technology itself.
That claim can be evaluated empirically only if the three changes are observed separately. Researchers must compare activities before and after enactment, compare dependencies over the same interval, and observe coordination requirements without defining one change from another. If coordination change is explained equally well without the observed dependency change, or if another framework already accounts for the same transition, dependency restructuring adds little.
A second implication concerns local autonomy. Digital technologies can remove visible interpersonal dependencies while concentrating activity on shared technological or interorganizational capabilities. Proposition 1 identifies the conditions under which this divergence is expected: high criticality and concentration, together with low substitutability, make greater system-level dependence more likely even as local mediation declines.
The argument is also falsifiable in several ways. Activity changes may leave dependencies unchanged; observed dependency changes may fail to explain differences in coordination requirements; greater local autonomy may not increase system-level dependence even when a new shared capability is critical, concentrated, and difficult to replace; and comparable dependency configurations may repeatedly produce different coordination requirements under similar organizational conditions. Any of these results would require revising the mechanism or its boundary conditions.

7.2. Managerial Implications

For managers, a dependency perspective adds one question to conventional technology evaluation: after an activity is automated, integrated, accelerated, or outsourced, what new requirements have appeared and where have existing ones moved? This directs attention to dependencies that disappear, dependencies redirected to another provider or system, and critical requirements that become concentrated. The question is particularly relevant when local simplification creates greater reliance on a shared system, a small group of providers, or a common data architecture.

7.3. Scope and Limitations

The argument has a limited scope. It does not explain every organizational consequence of technology or assume that dependency change is always the main mechanism. The two illustrations demonstrate application, not prevalence or causal validation. The literature comparison is problem-driven rather than systematic. Dependency properties such as criticality and substitutability still need operational measures, and the degree of similarity required when configurations are compared will depend on the research question. Power, identity, legitimacy, institutional change, learning, and culture may interact with dependency configuration but are not explained by it.

7.4. Future Research

The main methodological challenge is independent observation of dependency change. A study must identify dependencies before and after enactment without inferring them from the coordination outcome to be explained, and it must describe activities at a consistent level of detail. Future work should test whether different researchers can map the same requirement relations consistently, compare dependency restructuring with competing explanations, and revise the mechanism where another explanation accounts for the observed change more directly.

8. Conclusions

Digital technologies can alter activities without altering the dependencies through which those activities are coordinated. They can also alter dependencies without determining a single organizational response. Dependency restructuring concerns this intermediate change: what activities require one another or technological and external providers after technological enactment.
The analysis separates activity change, dependency change, and coordination response. Individual requirements may be created, eliminated, or redirected, while previously separate sets of dependencies may become connected. From this structure follow two conditional implications: less local mediation can coexist with greater reliance on a shared capability, and similar dependency configurations can generate similar coordination requirements when relevant organizational conditions are also comparable.
At the system level, the framework identifies when a technological change alters the relational architecture of organizational work rather than only one of its components. The organizational boundary can include technological and interorganizational providers when activities depend on them, allowing local and system-level consequences to be examined within the same representation.
The resulting empirical question is direct: after a technological capability is enacted, have the requirements among activities changed, and does that observed change help explain the coordination requirements that follow? If not, dependency restructuring should not be invoked. If so, the concept offers a way to reconstruct the relational change without inferring it from adoption, automation, or digitalization alone.

Supplementary Materials

The following supporting information can be downloaded at https://www.mdpi.com/article/10.3390/info17101015/s1, File S1: The Scopus search strategy, counts, deduplication procedure, and screening and assessment rules.

Funding

This research received no external funding.

Institutional Review Board Statement

Not applicable.

Data Availability Statement

No new data were created or analyzed in this study. Data sharing is not applicable to this article.

Acknowledgments

During the preparation of this manuscript, the author used ChatGPT (OpenAI, GPT-5.6 Sol) (OpenAI) to support drafting, language editing, structural revision, source checking, and all the phases of the structured literature completeness check. The author reviewed the sources incorporated into the manuscript and the AI-assisted material used in the analysis and text, edited the manuscript accordingly, and takes full responsibility for the content of this publication.

Conflicts of Interest

The author is affiliated with Energee3. Energee3 provided no specific funding for this research and had no role in the conceptualization, preparation, analysis, interpretation, or decision to submit the manuscript. The author declares no other conflicts of interest.

References

  1. Vial, G. Understanding digital transformation: A review and a research agenda. J. Strateg. Inf. Syst. 2019, 28, 118–144. [Google Scholar] [CrossRef] [Scilit]
  2. Hanelt, A.; Bohnsack, R.; Marz, D.; Antunes Marante, C. A systematic review of the literature on digital transformation: Insights and implications for strategy and organizational change. J. Manag. Stud. 2021, 58, 1159–1197. [Google Scholar] [CrossRef] [Scilit]
  3. Puranam, P. Human–AI collaborative decision-making as an organization design problem. J. Organ. Des. 2021, 10, 75–80. [Google Scholar] [CrossRef] [Scilit]
  4. Malone, T.W.; Crowston, K. The interdisciplinary study of coordination. ACM Comput. Surv. 1994, 26, 87–119. [Google Scholar] [CrossRef] [Scilit]
  5. Crowston, K. A coordination theory approach to organizational process design. Organ. Sci. 1997, 8, 157–175. [Google Scholar] [CrossRef] [Scilit]
  6. Claggett, J.L.; Karahanna, E. Understanding the role of technology in coordination through affordance configurations. J. Manag. Inf. Syst. 2025, 42, 599–632. [Google Scholar] [CrossRef] [Scilit]
  7. Markus, M.L.; Robey, D. Information technology and organizational change: Causal structure in theory and research. Manag. Sci. 1988, 34, 583–598. [Google Scholar] [CrossRef] [Scilit]
  8. Leonardi, P.M. When flexible routines meet flexible technologies: Affordance, constraint, and the imbrication of human and material agencies. MIS Q. 2011, 35, 147–167. [Google Scholar] [CrossRef] [Scilit]
  9. Raveendran, M.; Silvestri, L.; Gulati, R. The role of interdependence in the micro-foundations of organization design: Task, goal, and knowledge interdependence. Acad. Manag. Ann. 2020, 14, 828–868. [Google Scholar] [CrossRef] [Scilit]
  10. Andree, K.; Bano, D.; Weske, M. A closer look at activity relationships to improve business process redesign. Softw. Syst. Model. 2025, 24, 69–86. [Google Scholar] [CrossRef] [Scilit]
  11. Schilling, M.A. Toward a general modular systems theory and its application to interfirm product modularity. Acad. Manag. Rev. 2000, 25, 312–334. [Google Scholar] [CrossRef] [Scilit]
  12. Colfer, L.J.; Baldwin, C.Y. The mirroring hypothesis: Theory, evidence, and exceptions. Ind. Corp. Change 2016, 25, 709–738. [Google Scholar] [CrossRef] [Scilit]
  13. Leong, C.; Lin, S.; Tan, F.; Yu, J. Coordination in a digital platform organization. Inf. Syst. Res. 2024, 35, 363–393. [Google Scholar] [CrossRef] [Scilit]
  14. Agrawal, A.; Gans, J.S.; Goldfarb, A. Artificial intelligence adoption and system-wide change. J. Econ. Manag. Strategy 2024, 33, 327–337. [Google Scholar] [CrossRef] [Scilit]
  15. Gomes, L.A.d.V.; Flechas Chaparro, X.A.; Silva, L.E.N.; Maniçoba, R.F.; Farago, F.E. Ecosystem orchestration work in the digital transformation of ecosystems. R D Manag. 2026, 56, 363–384. [Google Scholar] [CrossRef] [Scilit]
  16. Puranam, P.; Raveendran, M.; Knudsen, T. Organization design: The epistemic interdependence perspective. Acad. Manag. Rev. 2012, 37, 419–440. [Google Scholar] [CrossRef] [Scilit]
  17. Galbraith, J.R. Organization design: An information processing view. Interfaces 1974, 4, 28–36. [Google Scholar] [CrossRef] [Scilit]
  18. Dumas, M.; La Rosa, M.; Mendling, J.; Reijers, H.A. Fundamentals of Business Process Management, 2nd ed.; Springer: Cham, Switzerland, 2018. [Google Scholar] [CrossRef] [Scilit]
  19. Adamo, G.; Di Francescomarino, C.; Ghidini, C.; Maggi, F.M. Beyond arrows in process models: A user study on activity dependences and their rationales. Inf. Syst. 2021, 100, 101762. [Google Scholar] [CrossRef] [Scilit]
  20. Andree, K.; Deigner, F.; Stupp, F.; Kuzmin, I.; Pufahl, L. Automatic support in process redesign: Structural impact analysis of change operations. In Research Challenges in Information Science—20th International Conference, RCIS 2026, Proceedings; Polacsek, T., Ruiz, M., Ralyté, J., Ravat, F., Eds.; Springer: Cham, Switzerland, 2026; pp. 71–88. [Google Scholar] [CrossRef] [Scilit]
  21. Milani, F.; Kubrak, K.; Nava, J. Strategic redesign of business processes in the digital age: A framework. Data Knowl. Eng. 2024, 154, 102367. [Google Scholar] [CrossRef] [Scilit]
  22. Ahmad, T.; Van Looy, A. Business Process Management and Digital Innovations: A Systematic Literature Review. Sustainability 2020, 12, 6827. [Google Scholar] [CrossRef] [Scilit]
  23. Eppinger, S.D.; Browning, T.R. Design Structure Matrix Methods and Applications; MIT Press: Cambridge, MA, USA, 2012. [Google Scholar] [CrossRef] [Scilit]
  24. Orlikowski, W.J. Using technology and constituting structures: A practice lens for studying technology in organizations. Organ. Sci. 2000, 11, 404–428. [Google Scholar] [CrossRef] [Scilit]
  25. Vom Brocke, J.; Schmid, A.M.; Simons, A.; Safrudin, N. IT-enabled organizational transformation: A structured literature review. Bus. Process Manag. J. 2021, 27, 204–229. [Google Scholar] [CrossRef] [Scilit]
  26. Wessel, L.; Baiyere, A.; Ologeanu-Taddei, R.; Cha, J.; Jensen, T.B. Unpacking the Difference Between Digital Transformation and IT-Enabled Organizational Transformation. J. Assoc. Inf. Syst. 2021, 22, 102–129. [Google Scholar] [CrossRef] [Scilit]
  27. Baldwin, C.Y. A theory of technology and organizations. Strateg. Organ. 2026, 24, 388–418. [Google Scholar] [CrossRef] [Scilit]
  28. Jaakkola, E. Designing conceptual articles: Four approaches. AMS Rev. 2020, 10, 18–26. [Google Scholar] [CrossRef] [Scilit]
  29. Crowston, K.; Osborn, C.S. A coordination theory approach to process description and redesign. In Organizing Business Knowledge: The MIT Process Handbook; Malone, T.W., Crowston, K., Herman, G.A., Eds.; MIT Press: Cambridge, MA, USA, 2003; pp. 335–370. [Google Scholar]
  30. Malone, T.W.; Crowston, K.; Lee, J.; Pentland, B.; Dellarocas, C.; Wyner, G.; Quimby, J.; Osborn, C.S.; Bernstein, A.; Herman, G.; et al. Tools for inventing organizations: Toward a handbook of organizational processes. Manag. Sci. 1999, 45, 425–443. [Google Scholar] [CrossRef] [Scilit]
  31. Bailey, D.E.; Leonardi, P.M.; Chong, J. Minding the gaps: Understanding technology interdependence and coordination in knowledge work. Organ. Sci. 2010, 21, 713–730. [Google Scholar] [CrossRef] [Scilit]
  32. Schneider, S.; Sunyaev, A. Determinant factors of cloud-sourcing decisions: Reflecting on the IT outsourcing literature in the era of cloud computing. J. Inf. Technol. 2016, 31, 1–31. [Google Scholar] [CrossRef] [Scilit]
  33. Khajeh-Hosseini, A.; Greenwood, D.; Sommerville, I. Cloud migration: A case study of migrating an enterprise IT system to IaaS. In 2010 IEEE 3rd International Conference on Cloud Computing; IEEE: Piscataway, NJ, USA, 2010; pp. 450–457. [Google Scholar] [CrossRef] [Scilit]
  34. Oliveira, P.; Carvalho, J.M.S.; Faria, S. AI integration in organisational workflows: A case study on job reconfiguration, efficiency, and workforce adaptation. Information 2025, 16, 764. [Google Scholar] [CrossRef] [Scilit]
Disclaimer/Publisher’s Note: The statements, opinions and data contained in all publications are solely those of the individual author(s) and contributor(s) and not of MDPI and/or the editor(s). MDPI and/or the editor(s) disclaim responsibility for any injury to people or property resulting from any ideas, methods, instructions or products referred to in the content.

Article Metrics

Citations

Article Access Statistics

Multiple requests from the same IP address are counted as one view.