Business Process Mapping Before Software Changes

قم بالتعرف على مثال فعلي.

اتبع طلب الممثل من البداية إلى النهاية مع الأشخاص الذين يتعاملون معه. سجل القرارات وعمليات التسليم والمعلومات المستخدمة في كل نقطة. قم بتضمين الخطوات غير الرسمية التي قد لا تظهر في الإجراء المكتوب. غالبًا ما يشرحون سبب احتياج التغيير المقترح إلى أكثر من مجرد واجهة جديدة.

فصل الأعراض عن الأسباب.

اسأل عن سبب حدوث التأخير أو الإجراء المتكرر. قد يتضمن ذلك معلومات مفقودة أو ملكية غير واضحة أو موافقة مطلوبة. قم بتمييز هذه الشروط عن قيود الأداة قبل تحديد ما تريد تغييره. وإلا فإن النظام الجديد يمكن أن يعيد إنتاج نفس المشكلة مع شاشة مختلفة.

تعريف التحسين الأول المحدود.

اختر جزءًا من سير العمل بمالك واضح ونتيجة يمكن ملاحظتها. اتفق على كيفية مراجعتها مقابل العملية الحالية. قم بتسجيل ما يبقى خارج المرحلة الأولى حتى يفهم أصحاب المصلحة الحدود ويمكنهم تخطيط التبعيات حولها.

Build and verify the current-state map

Define the start and finish of the process, then ask people doing the work to walk through a representative case. Record actions, decisions, handoffs and the information needed at each stage. Include the systems involved and places where staff maintain a separate spreadsheet or message thread.

Walk through exceptions such as incomplete information, rejection, delay and an absent approver. Mark uncertain steps rather than filling gaps with an idealized sequence. Ask participants to verify the map and note differences between teams or locations. Only then sketch a proposed change. Keep the current and proposed versions separate so reviewers can see which rules are being preserved, removed or introduced.

A process-mapping worksheet

A simple table can be enough before creating a diagram. Use the diagram to communicate the verified sequence, not to hide unresolved decisions.

• Boundary: triggering event, completed outcome and process owner.
• Step: action, responsible role and the information received or produced.
• Decision: rule used, authority to decide and possible next paths.
• Handoff: receiving role or system and how acceptance is confirmed.
• Exception: missing information, delay, rejection or another route requiring attention.
• Improvement note: observed difficulty, evidence and whether it needs policy or technical action.

Do not draw only the official procedure

The written process and everyday practice can differ. Record both and ask why workarounds exist before proposing their removal. A workaround may compensate for missing access, an unclear rule or a system limitation.

Avoid treating every observed delay as a software defect. Some decisions depend on authority, policy or external information. Assign the right owner to investigate. Keep proposed changes distinct from current facts so a new diagram is not mistaken for an already agreed operating procedure.

How detailed should the process map be?

Include enough detail to understand the problem and its dependencies. Start with the end-to-end sequence, then expand the steps connected to the proposed change. Excessive detail can obscure decisions, while a map containing only department names may hide the handoffs that matter.

ILLUSTRATIVE PLANNING EXAMPLE

Example: mapping an expense claim

Follow a claim from submission through approval and reimbursement. Include a missing receipt, a rejected claim and an absent approver. Ask people doing the work to verify the sequence and identify where information is copied between systems. Mark uncertain steps for investigation rather than drawing an idealized process.

Use the verified map to define a focused improvement. Preserve the distinction between a policy decision and a software feature needed to support it.

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