Where Does "Technology" End and "Process" Begin?

Published on: Sun Sep 01 2024 by Ivar Strand

Defining the Boundaries: Where Does “Technology” End and “Process” Begin?

In financial management and program oversight, we have long operated with a clear distinction between “process” and “technology.” A process was seen as the sequence of human actions and decisions, while technology was the tool used to support those actions. This mental model, once useful, is now an obstacle to effective analysis.

The fundamental idea for modern governance is this: the technology is now the process. The rules, controls, and workflows that define how an organization functions are no longer just supported by software; they are instantiated in it. To ask where the process ends and the technology begins is to ask the wrong question.

An Outdated Dichotomy

The traditional model was born from a physical world. A procurement process, for example, consisted of tangible steps: a person completes a paper form, another person provides a signature, and a third files it in a cabinet. The technology—a typewriter or a calculator—was a discrete tool applied at specific points. The locus of the process, and its control, was clearly human.

That model does not describe our current reality. In a modern Enterprise Resource Planning (or ERP) system, the procurement process is the software’s coded workflow. The budget checks, the approval hierarchies, and the compliance flags are not actions performed by people using a tool. They are automated functions executed by the system itself. The process logic and the system logic have merged.

A New Vocabulary for a New Reality

To analyze and manage this integrated reality, we must adopt a more precise vocabulary. Continuing to speak of process and technology as separate entities leads to flawed assumptions and misplaced oversight. The shift in thinking is best illustrated by a shift in language.

• Old Question: “Can you walk me through the expense approval process?”

  • This question implies a sequence of human actions.

• New Question: “Can we review the configuration of the expense approval workflow in the system, including all automated rules and exception handlers?”

  • This question targets the codified process itself.

• Old Statement: “We have an internal control for flagging duplicate invoices.”

  • This statement is ambiguous about implementation.

• New Statement: “The payment module has an algorithm designed to flag duplicate invoices. We need to test the parameters of that algorithm.”

  • This statement is specific, testable, and acknowledges the technical nature of the control.

This updated vocabulary is not semantic. It is a necessary tool for focusing inquiry on where the actual execution and risk now reside.

The Practical Implications of Systems Thinking

Adopting this perspective has significant practical consequences. It changes how we approach procurement, implementation, and assurance. When we accept that the software is the process, we can no longer treat it as an impenetrable “black box.”

Our due diligence must evolve from reviewing user manuals to interrogating system architecture. Our risk assessments must map not just human workflows, but data flows and algorithmic logic. Our audits must include not just transactional sampling, but system configuration analysis.

Ultimately, the goal of any financial or programmatic control framework is to ensure integrity at the point of decision. By recognizing that this point has moved from a manager’s desk to a line of code, we can direct our oversight to where it will have the most meaningful effect. To monitor the process, we must monitor the system.