Target Vision, Transformation Principles, and the Operating Model

1. From diagnosis to a target state

After understanding gaps, we should not jump directly to a technology project. We first need a target state describing how value, service, process, data, capabilities, and decisions should work when the situation improves. A good vision is specific enough to guide choices but does not prematurely lock the organization into one product or vendor. Example: “A unified digital service channel with an assisted path for those who need it, trusted one-time data capture, clear exception responsibilities, and regular measurement of completion, quality, and adoption.”

Transformation principles help teams make consistent choices when many options appear. Teaching examples include: simplify before automating; capture data once and reuse it responsibly; provide an assisted path rather than assuming equal digital ability; make accountability and decision rights clear; measure benefits and adoption, not only delivery; reduce unnecessary duplication; and test at limited scale before expanding when uncertainty is high. These are instructional design principles, not verbatim rules from an external standard.

The operating model translates the vision into an executable way of working. In this diploma we use six connected layers: process; roles and structure; skills and capabilities; data; platforms and integration; and governance and measurement. Technology can be excellent, but if data definitions remain inconsistent, or nobody knows who approves rule changes or handles exceptions, the target model will not work as designed.

Professional governance frameworks treat technology use as an enterprise responsibility rather than a matter for the IT department alone. ISO/IEC 38500 provides principles for governance of current and future use of IT, while COBIT emphasizes governance and management of enterprise information and technology with components including processes, organizational structures, policies, information flows, culture, skills, and infrastructure. We use this idea here to reinforce that a target state needs responsibilities, decisions, and standards, not only technology architecture.

A useful practical form is “from → to → why → how we know.” Example: “From three channels using different definitions of active customer, to one agreed definition and shared data source, so service and reporting decisions become comparable; progress will be indicated by fewer report discrepancies and a higher share of records flowing without manual reconciliation.” This format also exposes what still needs a decision.