SOP doanh nghiệp

SOP doanh nghiệp trên ShopDunk được định vị như một Page giải pháp cho doanh nghiệp cần SOP ngắn, dùng được và kiểm soát phiên bản. Bản chất của chủ đề này là thiết kế cách công việc chạy end-to-end với trigger, input, owner, decision, SLA, control và output rõ ràng. Vì vậy nội dung tập trung vào cách triển khai, dữ liệu, quyền quyết định, KPI và tiêu chí lựa chọn, thay vì lặp lại một danh sách tính năng.

Để đánh giá đúng, nên lấy một tình huống thật rồi đi xuyên từ trigger đến output. Cách này thường phát hiện điểm nghẽn tốt hơn một cuộc họp chỉ dựa trên mô tả.

Nếu cần đặt bài toán trong bức tranh rộng hơn, có thể xem Quy trình vận hành. Trang hiện tại chỉ giữ một intent chính cho SOP doanh nghiệp để tránh trộn với các Page sibling.

Research cho từ khóa này tập trung vào SERP Việt Nam, PAA/related, các nguồn cập nhật 2026 và nhóm entity: BPM, BPMN, SOP, RACI, process owner, SLA, control, exception. Các claim có tính pháp lý hoặc thay đổi theo thời gian được tách khỏi phần framework quản trị để tránh biến khuyến nghị vận hành thực tế thành một kết luận pháp lý tuyệt đối.

Từ nhu cầu đến mô hình vận hành cho SOP doanh nghiệp

Cách hiểu thực dụng nhất: SOP doanh nghiệp phải tạo ra một chuỗi công việc có đầu vào, owner, quyết định, evidence và deliverable rõ. Nếu một bước quan trọng vẫn phụ thuộc vào việc nhắn riêng cho người có kinh nghiệm, năng lực đó chưa thực sự được hệ thống hóa.

Hai entity cần khóa sớm là SOP template và work instruction. Cần định nghĩa chúng bằng ngôn ngữ nghiệp vụ, rule dữ liệu và ví dụ thật. Cùng một nhãn nhưng khác cách hiểu giữa các phòng ban sẽ tạo sai lệch ở workflow và báo cáo.

Một lỗi nhỏ lặp hàng nghìn lần có thể tốn kém hơn một lỗi lớn hiếm gặp; cần đo cả tần suất và impact.

5 điểm nghẽn thường gặp khi triển khai sop doanh nghiệp

1. Sop template chưa có owner hoặc quy tắc thống nhất

Điểm khó thường không nằm ở việc thiếu công cụ. Điểm nghẽn nằm ở cách tổ chức định nghĩa data, quyền quyết định và trách nhiệm khi có ngoại lệ. Với SOP doanh nghiệp, cần chỉ ra pain này xuất hiện ở giao dịch, nhóm người dùng và bước bàn giao nào. Một mô tả kiểu “luồng vận hành chưa tối ưu” không đủ để xếp ưu tiên.

Thay vì hỏi chung ‘đang vướng gì’, hãy chọn 3–10 giao dịch và đi xuyên từng bước. Ghi queue time, rework, owner và loại ngoại lệ để thấy điểm nghẽn có chi phí lớn nhất.

2. Dữ liệu phục vụ sop doanh nghiệp nằm ở nhiều công cụ và khó đối soát

Để đánh giá đúng, nên lấy một tình huống thật rồi đi xuyên từ trigger đến output. Cách này thường phát hiện điểm nghẽn tốt hơn một cuộc họp chỉ dựa trên mô tả. Với SOP doanh nghiệp, cần chỉ ra pain này xuất hiện ở giao dịch, nhóm người dùng và bước bàn giao nào. Một mô tả kiểu “luồng vận hành chưa tối ưu” không đủ để xếp ưu tiên.

Nếu spreadsheet vẫn là công cụ chính sau triển khai, adoption chưa đạt; cần review fit và data flow.

3. Work instruction được xử lý theo kinh nghiệm cá nhân thay vì tiêu chí

Các hệ thống cơ chế quản trị thất bại nhiều khi không phải vì thiếu tính năng, mà vì cùng một khái niệm được các phòng ban hiểu và ghi nhận theo nhiều cách khác nhau. Với SOP doanh nghiệp, cần chỉ ra pain này xuất hiện ở giao dịch, nhóm người dùng và bước bàn giao nào. Một mô tả kiểu “luồng vận hành chưa tối ưu” không đủ để xếp ưu tiên.

Deliverable nên trở thành công cụ làm việc, không phải tài liệu lưu kho.

4. Ngoại lệ phát sinh nhưng không được ghi nhận thành backlog/root cause

Một hệ thống mới không tự giải quyết được SOP doanh nghiệp nếu business rule và quyền xử lý vẫn mơ hồ. Phải khóa governance trước khi tự động hóa.

Một output tốt phải đủ rõ để người không tham gia dự án vẫn có thể sử dụng.

5. Báo cáo có số liệu nhưng chưa nối trực tiếp với quyết định quản trị

Đánh giá SOP doanh nghiệp nên dựa trên dữ liệu vận hành thật: case, log, queue time và exception. Không nên chỉ dựa trên nhận định của một nhóm.

Một cách audit thực dụng là sample transaction: theo dấu từ trigger tới output, đo thao tác thủ công và nơi phải hỏi lại. Sau đó mới quyết định vấn đề thuộc rule, quy trình, dữ liệu hay năng lực.

Entity và semantic coverage cần có trong Page này

Để Page SOP doanh nghiệp có chiều sâu semantic, entity không được nhắc như từ đồng nghĩa rời rạc. Mỗi entity phải có quan hệ: tạo ra data nào, thuộc luồng vận hành nào, ai sở hữu và tác động đến KPI nào.

Cụm từ liên quan được giữ theo ngữ cảnh thay vì nhồi từ khóa: BPM, BPMN, SOP, RACI, process owner, SLA, control, exception, workflow, automation, cycle time, SOP template. Mục tiêu là bao phủ chủ đề và quan hệ giữa các khái niệm, không phải lặp lại một cụm chính ở mọi đoạn.

Đầu ra một dự án sop doanh nghiệp nên bàn giao

Đầu ra 1: Bản đồ hiện trạng và baseline cho sop doanh nghiệp

Nên nghiệm thu đầu ra bằng khả năng sử dụng, không chỉ bằng việc tài liệu đã được chuyển giao. SOP doanh nghiệp cần một version chính thức, owner bảo trì và tiêu chí xác nhận rõ.

Một mong muốn phụ không mặc nhiên tạo ra giá trị để thêm trường data hoặc một bước duyệt.

Đầu ra 2: Mô hình mục tiêu với sop template và work instruction được định nghĩa rõ

Trước khi đánh dấu hoàn thành, hãy chốt ai sở hữu đầu ra, phiên bản nào có hiệu lực và bằng chứng nghiệm thu là gì. Với SOP doanh nghiệp, năng lực vận hành mới là đích cuối.

Tài liệu bàn giao cần có owner bảo trì để không lệch khỏi cách vận hành thực tế.

Đầu ra 3: Ma trận vai trò, quyền quyết định và escalation

Kết quả này phải đi vào hoạt động thực tế: có owner, version, ngày áp dụng và chuẩn kiểm tra. Nếu chỉ dừng ở tài liệu, dự án SOP doanh nghiệp vẫn còn một khoảng trống triển khai.

Nếu sau go-live vẫn tồn tại Excel song song, cần tìm nguyên nhân về fit, dữ liệu hoặc thao tác trước khi quy vấn đề cho ý thức tuân thủ.

Đầu ra 4: Data dictionary/source-of-truth và rule đối soát

Deliverable này chỉ nên nghiệm thu khi có owner, phiên bản áp dụng và tiêu chí hoàn thành. Với SOP doanh nghiệp, trạng thái ‘đã gửi tài liệu’ chưa chứng minh luồng làm việc đã vận hành được.

Kết quả bàn giao nên được kiểm bằng use case sau go-live thay vì số trang tài liệu.

Đầu ra 5: Quy trình triển khai/pilot/uat theo scenario thật

Một kết quả bàn giao chỉ thực sự hoàn tất khi người chịu trách nhiệm, version và chuẩn nghiệm thu đều rõ. Trong SOP doanh nghiệp, cần phân biệt bàn giao tài liệu với khả năng dùng nó trong công việc thật.

Nên bắt đầu bằng mô hình đủ vận hành thực tế rồi mới tăng phạm vi khi data cho thấy cần thiết.

Đầu ra 6: Dashboard kpi, backlog và nhịp governance sau go-live

Hạng mục này cần owner và điều kiện nghiệm thu cụ thể trước khi đóng. Đối với SOP doanh nghiệp, file tài liệu không phải evidence đủ nếu user chưa thể thực hiện đúng scenario.

Đầu ra chỉ có ý nghĩa khi đội vận hành dùng được sau khi dự án kết thúc.

Quy trình triển khai sop doanh nghiệp theo 7 bước

Bước 1: Khóa mục tiêu, phạm vi, sponsor và baseline

Trước khi khóa phương án, bước này phải giảm phần chưa được kiểm chứng. Quyết định quan trọng cần được ghi lại kèm lý do và người bước duyệt.

Bằng chứng tốt phải cho phép người khác tái hiện logic mà không cần hỏi người lập ban đầu.

Bước 2: Đi walkthrough bằng case/giao dịch thực tế

UAT nên đi theo scenario end-to-end thay vì tick từng màn hình. Happy path cho thấy luồng cơ bản; ngoại lệ mới kiểm được độ bền của thiết kế.

Nếu dữ liệu nền còn nhiễu, hãy tách fact khỏi assumption và dùng proxy có chú thích trong giai đoạn đầu.

Bước 3: Phân loại pain theo impact × frequency × risk

Khi review SOP doanh nghiệp, hãy kiểm điểm này bằng evidence từ vận hành thật thay vì giữ nó như một nguyên tắc chung không có owner.

Target chỉ nên được chốt sau khi baseline đủ dùng; nếu chưa, cần công khai sai số và cách hiệu chỉnh.

Bước 4: Thiết kế target model cho sop template và work instruction

Không nên dùng ngày trên kế hoạch thay cho exit criteria. Điều kiện đủ của bước hiện tại phải được kiểm trước khi mở bước tiếp theo.

Nếu baseline chưa đủ tin cậy, hãy đánh dấu assumption và cách thu thêm dữ liệu; đừng biến ước lượng tạm thành KPI chính thức.

Bước 5: Pilot/uat với happy path và ngoại lệ

Nên cho một case chạy từ trigger tới output, kèm cả exception, thay vì test các form rời rạc.

Khi số liệu hiện trạng còn thiếu, nên ghi rõ giới hạn nguồn và thời điểm đo lại trước khi khóa target.

Bước 6: Go-live kèm training, support và control

Issue tác động đến dữ liệu, quyền hoặc kiến trúc phải có impact analysis và approval phù hợp trước khi triển khai.

Mỗi kết luận quan trọng cần một evidence cụ thể: sample transaction, log hệ thống, baseline, decision record hoặc hồ sơ phê duyệt.

Bước 7: Review value/adoption rồi mới mở rộng

Kịch bản xuyên suốt phản ánh vận hành thật tốt hơn kiểm từng màn hình; cần có cả happy path và trường hợp dữ liệu lỗi.

Evidence có chất lượng cần giúp reviewer lần lại cách đi đến kết luận mà không phụ thuộc trí nhớ của tác giả.

Một dependency thường gặp của chủ đề này nằm ở Tư vấn quy trình vận hành. Nếu hai miền dùng chung customer/master data hoặc cùng tạo ra một quyết định, nên thiết kế integration và ownership ngay từ đầu.

Tiêu chí chọn giải pháp hoặc nhà cung cấp cho sop doanh nghiệp

1. Fit với use case ưu tiên

Đừng chấm điểm theo số lượng chức năng. Hãy cho một case của SOP doanh nghiệp chạy xuyên hệ thống và ghi lại cách nền tảng xử lý happy path, exception cùng integration.

2. Khả năng tích hợp và dữ liệu

Một cách đánh giá tốt là đặt cùng một scenario cho tất cả nhà cung cấp. Với SOP doanh nghiệp, so sánh phải dựa trên kết quả xử lý, thao tác người dùng và giới hạn giải pháp.

3. Governance, phân quyền và audit trail

Nên xác minh tiêu chí này bằng dữ liệu mẫu và use case cụ thể. Khi demo SOP doanh nghiệp, yêu cầu nhà cung cấp nói rõ assumption, giới hạn và chi phí của phần không phải standard.

4. Trải nghiệm/adoption của người dùng

Hãy kiểm tiêu chí này bằng một scenario nghiệp vụ có expected result, thay vì đếm feature. Với SOP doanh nghiệp, vendor cần tách rõ phần standard, cấu hình, tùy biến và integration.

5. Năng lực triển khai và hỗ trợ

Nên yêu cầu demo tiêu chí này trên use case thật. Trong SOP doanh nghiệp, một slide tính năng không đủ chứng minh khả năng xử lý dữ liệu, quyền và ngoại lệ.

6. Tco, khả năng mở rộng và lock-in

Tiêu chí này chỉ có giá trị khi có evidence từ kịch bản end-to-end. Khi đánh giá SOP doanh nghiệp, cần biết bước nào là chuẩn, bước nào phải cấu hình và phần nào phát sinh custom.

KPI cho sop doanh nghiệp: đo outcome, process và adoption

KPI phải có định nghĩa, owner, nguồn data, baseline, target, kỳ đo và hành động khi vượt ngưỡng. Nếu hai bộ phận tự tính cùng một KPI bằng công thức khác nhau, dashboard sẽ tạo tranh luận thay vì tạo quyết định.

Không nên tối ưu một KPI đơn lẻ. Ví dụ tốc độ xử lý tốt hơn nhưng lỗi hoặc reopen tăng thì SOP doanh nghiệp chưa tạo hiệu quả tổng thể. Dashboard nên giúp người quản lý quyết định nơi cần can thiệp, không chỉ mô tả quá khứ.

Rủi ro và sai lầm dễ làm sop doanh nghiệp thất bại

Rủi ro 1: Document hóa quy trình thừa

Rủi ro này cần một owner, mức ảnh hưởng và control tương ứng trong RAID log. Nếu workaround của SOP doanh nghiệp lặp qua nhiều chu kỳ, nên mở root-cause action thay vì tiếp tục xử lý từng case.

Scope nên tăng theo dependency và value, không theo số tính năng có sẵn trong sản phẩm.

Rủi ro 2: Số hóa trước khi tối ưu

Nên ghi rủi ro vào backlog/RAID cùng người chịu trách nhiệm và hạn xử lý. Với SOP doanh nghiệp, một giải pháp tạm tồn tại quá lâu thường cho thấy thiết kế hoặc dữ liệu nguồn chưa được sửa đúng chỗ.

Khi vận hành SOP doanh nghiệp, cần có escalation rõ cho điểm này nếu nó vượt thẩm quyền của process owner hoặc key user.

Rủi ro 3: Không có process owner

Đừng để rủi ro chỉ nằm trong biên bản họp. Dự án SOP doanh nghiệp cần xác định owner, preventive/detective control và điều kiện escalation cho điểm này.

Điểm này nên được kiểm lại sau pilot của SOP doanh nghiệp; dữ liệu adoption và issue thực tế sẽ cho biết có cần thay đổi thiết kế hay không.

Rủi ro 4: Ngoại lệ đi ngoài hệ thống

Điểm rủi ro này cần được theo dõi như một item có impact và action cụ thể. Nếu cùng lỗi của SOP doanh nghiệp xuất hiện lại, action phải chuyển sang nguyên nhân gốc.

Điểm này nên được kiểm lại sau pilot của SOP doanh nghiệp; dữ liệu adoption và issue thực tế sẽ cho biết có cần thay đổi thiết kế hay không. Ở lần review này, ưu tiên kiểm BPM và owner dữ liệu liên quan.

Rủi ro 5: Sop dài nhưng không dùng

RAID log nên ghi rõ rủi ro, bằng chứng, owner và quyết định xử lý. Trong SOP doanh nghiệp, việc sửa lặp đi lặp lại một symptom là dấu hiệu cần review process hoặc data model.

Với SOP doanh nghiệp, hãy lưu rationale của điểm này để người tiếp quản sau dự án hiểu vì sao rule hoặc control được thiết kế như vậy.

Kiến trúc dữ liệu và tích hợp

Ranh giới giữa các hệ thống là phần bắt buộc của một Page giải pháp sâu. Source system tạo data; system of record giữ bản ghi chuẩn; downstream system tiêu thụ trạng thái hoặc báo biểu. Nếu ba vai trò này bị trộn, tổ chức dễ có nhiều ‘bản đúng’ cho cùng một đối tượng.

workflow/BPM

Khi nối với workflow/BPM, cần xác định object trao đổi, chiều data, tần suất, key mapping, xử lý lỗi và owner. Với SOP doanh nghiệp, integration không nên được nghiệm thu chỉ bằng việc ‘đã kết nối’; phải kiểm tra completeness, duplicate và khả năng reconcile.

ERP

Khi nối với ERP, cần xác định object trao đổi, chiều data, tần suất, key mapping, xử lý lỗi và owner. Với SOP doanh nghiệp, integration không nên được nghiệm thu chỉ bằng việc ‘đã kết nối’; phải kiểm tra completeness, duplicate và khả năng reconcile.

CRM

Khi nối với CRM, cần xác định object trao đổi, chiều data, tần suất, key mapping, xử lý lỗi và owner. Với SOP doanh nghiệp, integration không nên được nghiệm thu chỉ bằng việc ‘đã kết nối’; phải kiểm tra completeness, duplicate và khả năng reconcile.

DMS

Khi nối với DMS, cần xác định object trao đổi, chiều data, tần suất, key mapping, xử lý lỗi và owner. Với SOP doanh nghiệp, integration không nên được nghiệm thu chỉ bằng việc ‘đã kết nối’; phải kiểm tra completeness, duplicate và khả năng reconcile.

BI

Khi nối với BI, cần xác định object trao đổi, chiều data, tần suất, key mapping, xử lý lỗi và owner. Với SOP doanh nghiệp, integration không nên được nghiệm thu chỉ bằng việc ‘đã kết nối’; phải kiểm tra completeness, duplicate và khả năng reconcile.

Ở lớp kiến trúc, ERP là một miền liên quan cần được nối theo đúng source-of-truth và quyền data. Internal link này phục vụ hành trình ra quyết định, không dùng để mở rộng sang một intent khác trong cùng Page.

Ở lớp kiến trúc, Chuyển đổi số là một miền liên quan cần được nối theo đúng source-of-truth và quyền data. Internal link này phục vụ hành trình ra quyết định, không dùng để mở rộng sang một intent khác trong cùng Page.

TCO, roadmap 30–60–90 ngày và điều kiện mở rộng

TCO của SOP doanh nghiệp gồm effort nội bộ, tư vấn/thực thi, license hoặc phí dịch vụ, data migration, integration, training, change management, support và cải tiến. So sánh phương án phải dùng cùng scope và cùng kỳ thời gian.

Mỗi giai đoạn phải có exit criteria; chỉ chuyển bước khi điều kiện hiện tại đạt, nếu không dependency và issue sẽ bị dồn sang pha sau.

4 góc nhìn chuyên sâu giúp Page này khác nội dung tổng hợp trên SERP

1. SOP khác policy và process map

Để đánh giá đúng, nên lấy một tình huống thật rồi đi xuyên từ trigger đến output. Cách này thường phát hiện điểm nghẽn tốt hơn một cuộc họp chỉ dựa trên mô tả. Khi áp dụng vào SOP doanh nghiệp, câu hỏi cần đặt là: quyết định nào thay đổi, data nào chứng minh và control nào giữ kết quả ổn định sau khi dự án kết thúc.

Information gain ở đây nằm ở việc nối sop khác policy và process map với implementation. Thay vì dừng ở định nghĩa, doanh nghiệp cần biến nó thành rule, owner, scenario kiểm thử và KPI. Đây là phần thường bị thiếu ở các bài chỉ tối ưu cho truy vấn thông tin.

2. Viết theo người thực hiện chứ không theo người phê duyệt

Điểm khó thường không nằm ở việc thiếu công cụ. Điểm nghẽn nằm ở cách tổ chức định nghĩa data, quyền quyết định và trách nhiệm khi có ngoại lệ. Khi áp dụng vào SOP doanh nghiệp, câu hỏi cần đặt là: quyết định nào thay đổi, data nào chứng minh và control nào giữ kết quả ổn định sau khi dự án kết thúc.

Information gain ở đây nằm ở việc nối viết theo người thực hiện chứ không theo người phê duyệt với implementation. Thay vì dừng ở định nghĩa, doanh nghiệp cần biến nó thành rule, owner, scenario kiểm thử và KPI. Đây là phần thường bị thiếu ở các bài chỉ tối ưu cho truy vấn thông tin.

3. Quản lý phiên bản và ngày hiệu lực

Một hệ thống mới không tự giải quyết được SOP doanh nghiệp nếu business rule và quyền xử lý vẫn mơ hồ. Phải khóa governance trước khi tự động hóa. Ở lần review này, ưu tiên kiểm BPM và owner dữ liệu liên quan.

Information gain ở đây nằm ở việc nối quản lý phiên bản và ngày hiệu lực với implementation. Thay vì dừng ở định nghĩa, doanh nghiệp cần biến nó thành rule, owner, scenario kiểm thử và KPI. Đây là phần thường bị thiếu ở các bài chỉ tối ưu cho truy vấn thông tin.

4. Đo SOP bằng first-time-right

Với SOP doanh nghiệp, tool chỉ là một lớp. Process, data và ownership mới quyết định kết quả có bền hay không.

Information gain ở đây nằm ở việc nối đo sop bằng first-time-right với implementation. Thay vì dừng ở định nghĩa, doanh nghiệp cần biến nó thành rule, owner, scenario kiểm thử và KPI. Đây là phần thường bị thiếu ở các bài chỉ tối ưu cho truy vấn thông tin.

Nguồn nghiên cứu và nguyên tắc fact-check

Trước khi viết, từ khóa được khảo sát SERP và nguồn tham chiếu riêng. Nguồn dưới đây dùng để đối chiếu khung khái niệm, xu hướng thị trường hoặc pháp lý. Không dùng số liệu marketing của một nhà cung cấp như evidence mặc định cho mọi tổ chức.

• MISA AMIS – Quản trị vận hành doanh nghiệp
• 1C Việt Nam – Quy trình vận hành
• Cogover – Xây dựng quy trình vận hành
• Lạc Việt – Quy trình vận hành doanh nghiệp
• Base Workflow – Quản lý và tự động hóa quy trình
• HBR – Tự động hóa doanh nghiệp
• Intech Group – SOP

Câu hỏi thường gặp

SOP doanh nghiệp phù hợp với doanh nghiệp ở giai đoạn nào?

Không có ngưỡng nhân sự cố định. Nên nhìn độ phức tạp: volume, số đơn vị, số ngoại lệ, mức phụ thuộc cá nhân và rủi ro. Khi cách làm hiện tại cản trở scale hoặc cơ chế kiểm soát, tổ chức nên chuẩn hóa sop tổ chức.

Nên bắt đầu sop doanh nghiệp từ quy trình hay phần mềm?

Bắt đầu từ outcome và use case. Không cần đóng băng mọi chi tiết trước khi chọn công cụ, nhưng phải biết phần nào là rule bắt buộc, phần nào có thể fit-to-standard và phần nào cần kết nối hệ thống.

Sop template cần được định nghĩa như thế nào?

Sop template cần có định nghĩa nghiệp vụ, owner, source-of-truth và ví dụ hợp lệ/không hợp lệ. Nếu chỉ có tên trường dữ liệu mà không có rule, báo cáo rất dễ sai.

Làm sao đo hiệu quả sau khi triển khai sop doanh nghiệp?

Dùng KPI có baseline và source rõ. Với sop tổ chức, nên kết hợp outcome, tốc độ, chất lượng, adoption và risk thay vì chọn một thước đo duy nhất.

Khi nào nên thuê ngoài hoặc dùng đơn vị tư vấn cho sop doanh nghiệp?

Nên cân nhắc thuê ngoài/tư vấn khi thiếu năng lực chuyên môn, cần thực thi nhanh, có nhiều dependency hoặc cần một bên độc lập thiết kế governance. Dù thuê ngoài, tổ chức vẫn phải giữ owner và quyền bước duyệt.

Doanh nghiệp cần chuẩn bị dữ liệu gì trước workshop?

Chuẩn bị process map hiện tại, sample giao dịch, issue list, KPI/báo biểu, data dictionary nếu có, danh sách hệ thống và các ràng buộc. Với sop tổ chức, 5–10 case thật thường hữu ích hơn một tài liệu mô tả dài.

Bắt đầu từ bài toán thực tế

Nếu tổ chức đang đánh giá SOP doanh nghiệp, hãy bắt đầu bằng đích cần đạt kinh doanh, quy mô áp dụng, luồng vận hành hiện tại, hệ thống đang dùng, 3–5 ngoại lệ điển hình và KPI muốn cải thiện. Từ đó mới xác định nên ưu tiên tư vấn, phần mềm, dịch vụ vận hành thực tế hay một lộ trình kết hợp.

Các miền liên quan để nối kiến trúc: Giải pháp doanh nghiệp.