Digital Transformation Planning: Start With One Process

現在のパスを描画します。

関係する人やシステムを通じてタスクを追跡します。ハンドオフ、繰り返しのデータ入力、および例外を記録します。関係者に地図を確認するよう依頼します。今日のプロセスの説明を共有することは、チームがどの変更が重要で、どの依存関係を尊重する必要があるかを判断するのに役立ちます。

問題を優先ツールから分離します。

プラットフォームを選択する前に、ワークフローがサポートする必要がある結果について説明します。問題が統合の欠如、責任の不明確さ、古いインターフェース、またはそれらの組み合わせであるかどうかを検討してください。要件と制約が理解されるまで、オプションを開いたままにしておきます。

明確な境界を持つ最初のフェーズを選択してください。

最初のフェーズで何が変更され、その外側に何が残るかを定義します。含まれるユーザー、システム、データに同意します。変更されたワークフローをどのようにレビューするか、依存関係の準備ができていない場合はどうなるかを計画します。これにより、プロジェクトに実質的な決定点が与えられます。

所有権と移行を含めます。

改訂されたワークフローを使用、承認、保守する担当者について話し合います。文書と必要なトレーニングを範囲に含めます。テクノロジーの変化には、それを取り巻く組織にとって実行可能な移行が必要です。

Define a first phase with a visible boundary

Choose a process with an identifiable trigger, outcome and owner. Observe a real sequence of work and record where staff wait, clarify information or copy details between tools. Include exceptions, since the normal path alone may hide the decisions that create difficulty.

Describe a first phase in terms of request types, users, systems and locations. Agree what remains outside it and how the new process interacts with existing work. Test the proposed flow with the people who submit, review and support requests. Use their feedback to refine the scope before deciding on a wider programme or a particular platform.

A first-phase transformation canvas

Use this canvas to explain the change to both business and technical reviewers. Each statement should be specific enough for someone to challenge it.

• Current process: trigger, outcome, users and systems involved in the work.
• Problem: observed friction and the evidence available to describe it.
• First-phase boundary: included request types, teams and explicit exclusions.
• Dependencies: policy decisions, data quality, permissions and connected systems.
• Acceptance: representative tasks and exceptions the changed workflow must handle.
• Transition: training, support, ownership and a decision point before expansion.

Separate workflow change from tool replacement

Moving a form into software does not resolve an unclear approval rule. Decide which decisions belong to policy owners and which require implementation. Otherwise the new tool may preserve the same ambiguity in a different interface.

Avoid making the first phase depend on every proposed improvement. Record future ideas without silently including them in the commitment. Review the pilot’s limits before describing its results as representative of the entire organization.

How do we choose the first process?

Look for a meaningful problem with an available owner, accessible evidence and a boundary the team can test. Do not choose only the most visible idea. A smaller process may be a better starting point when its dependencies and review responsibilities are clear.

ILLUSTRATIVE PLANNING EXAMPLE

Example: digitizing purchase approvals

Follow a purchase request from submission to approval and receipt. Note where staff re-enter details, wait for an approver or resolve missing information. Choose one request type for the first phase. Agree how rejected and urgent requests are handled before drawing a new screen or selecting a platform.

Use a process map and a scoped first-phase brief to compare options. Keep wider departments and request types visible as later decisions rather than implied commitments.

FURTHER READING

Official resources to explore

Explore the related official guidance below. The templates and examples are practical starting points to adapt to your own project.

• GOV.UK Service Manual: how discovery works