Phân hệ PM Study
  • Tình huốngTình huống thực chiến
  • Kịch bảnRa quyết định tình huống
  • Biểu mẫuKho biểu mẫu tải về
  • Thẻ ghi nhớHọc thuật ngữ PMP
  • Công cụMáy tính EVM, PERT, dự phòng
  • Hỏi đápHỏi đáp & thảo luận
  • Thử tháchMỗi ngày một câu hỏi PMP
  • Lý thuyếtBài học PMBOK 8 & ECO 2026
  • Luyện thiThi thử & ôn tập PMP
  • Bài viếtThư viện bài viết PMP
PM Study
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đáp
6 chuyên mụcXem tất cả bài viết →
  • Quản lý các bên liên quanTình huống về kỳ vọng, giao tiếp và gắn kết stakeholder.
  • Lãnh đạo & đội nhómXây dựng, dẫn dắt và giải quyết xung đột trong đội dự án.
  • Kế hoạch & tiến độLập kế hoạch, ước lượng, nén tiến độ và kiểm soát baseline.
  • Rủi ro & thay đổiNhận diện, ứng phó rủi ro và kiểm soát thay đổi phạm vi.
  • Agile & HybridLựa chọn và vận hành cách tiếp cận Agile, Predictive, Hybrid.
  • Luyện thi PMPChiến lược ôn tập và mẹo xử lý câu hỏi tình huống PMP.
Công cụBài viết
Trang chủLý thuyếtTình huốngLuyện thiBiểu mẫuHỏi đápChuyên mụcCông cụBài viết
/
PM Study

Học quản lý dự án và ôn thi PMP bằng tiếng Việt: lý thuyết PMBOK® Guide 8, tình huống thực tế và đề luyện thi theo ECO 2026.

Chuyên mục

  • Quản lý các bên liên quan
  • Lãnh đạo & đội nhóm
  • Kế hoạch & tiến độ
  • Rủi ro & thay đổi
  • Agile & Hybrid
  • Luyện thi PMP

Tài nguyên

  • Project Management Institute (PMI)
  • PMP Exam Content Outline
  • The Scrum Guide
  • PMI Vietnam Chapter

PM Study

  • Tất cả bài viết
  • Bài viết nổi bật
© 2026 PM StudyPMP® và PMBOK® là nhãn hiệu đã đăng ký của Project Management Institute.Phiên bản 1.12.1
  1. /Tình huống
  2. /Quản lý Phạm vi
  3. /USCIS ELIS (Mỹ): sau 11 năm chuyển đổi số, hệ th…
Quản lý Phạm vi

USCIS ELIS (Mỹ): sau 11 năm chuyển đổi số, hệ thống hồ sơ nhập cư điện tử mới xử lý trực tuyến 2 trên khoảng 90 loại đơn

Từ năm 2005, Sở Di trú và Nhập tịch Mỹ (USCIS) tìm cách chuyển quy trình giấy sang hệ thống điện tử. Hệ thống ELIS ra mắt 5/2012, nhưng đến 2016 mới cho nộp trực tuyến 2 trên khoảng 90 loại đơn, dưới 10% khối lượng công việc. Chi phí ước tính tăng khoảng 1 tỷ USD, lịch lùi hơn 4 năm. Bài học về sản phẩm khả dụng tối thiểu và sự tham gia của người dùng.

HP
Nguyễn Thu Hà, PMP
15/04/2026
4 phút đọc 0 lượt xem
USCIS ELIS (Mỹ): sau 11 năm chuyển đổi số, hệ thống hồ sơ nhập cư điện tử mới xử lý trực tuyến 2 trên khoảng 90 loại đơn
Bình luận0

Bối cảnh thực tế

USCIS xử lý hàng triệu hồ sơ xin quyền lợi nhập cư mỗi năm — thẻ thường trú, nhập tịch, giấy phép lao động… — phần lớn trên giấy. Từ 2005–2006, cơ quan này khởi động Chương trình Chuyển đổi (Transformation Program) nhằm nộp hồ sơ, xét duyệt và quản lý hồ sơ điện tử. Hệ thống trung tâm là ELIS (Electronic Immigration System), ra mắt tháng 5/2012.

Theo báo cáo của Tổng Thanh tra DHS (3/2016, được Nextgov tường thuật):

  • Chỉ 2 trên khoảng 90 loại quyền lợi nhập cư cho nộp trực tuyến, chiếm dưới 10% khối lượng công việc.
  • Chỉ khoảng 2.215 trên 19.000 nhân viên và nhà thầu có tài khoản ELIS; người dùng mô tả hệ thống khó dùng, thiếu chức năng thiết yếu và có vấn đề hiệu năng.
  • USCIS ước tính cần thêm 3 năm và khoảng 1 tỷ USD để tự động hoá đầy đủ; đây là lần rà soát thứ sáu của Tổng Thanh tra về chương trình trong 11 năm.

Theo GAO-17-486T (16/3/2017): đường cơ sở 4/2015 ước tính tới 3,1 tỷ USD và triển khai đầy đủ trước 3/2019 — tăng khoảng 1 tỷ USD và trễ hơn 4 năm so với đường cơ sở 7/2011. Chương trình áp dụng không nhất quán các thực hành về phát triển phần mềm, kiểm thử và giám sát nhà thầu; có phần mềm được triển khai khi chưa kiểm thử đầy đủ, gây lỗi trên môi trường thật.

Phân tích nguyên nhân theo chuẩn PMP

  • Phát hành sớm nhưng phần phát hành chưa đủ giá trị

    Sản phẩm khả dụng tối thiểu (minimum viable product) phải đủ để người dùng thật làm xong một công việc trọn vẹn. Một hệ thống xử lý 2/90 loại đơn buộc nhân viên vẫn dùng giấy cho phần lớn công việc, nên chi phí vận hành song song tiếp tục, trong khi lợi ích chuyển đổi chưa đến.

  • Người dùng nội bộ không được tham gia thực chất

    Tổng Thanh tra kết luận cách tiếp cận chưa bảo đảm sự tham gia của bên liên quan. Phạm vi một hệ thống xét duyệt phải được xác nhận bởi chính người xét duyệt; khi phần lớn nhân viên không có tài khoản, vòng phản hồi để làm rõ phạm vi gần như không tồn tại.

  • Định nghĩa hoàn thành không bao gồm kiểm thử đầy đủ

Triển khai phần mềm chưa kiểm thử đầy đủ cho thấy định nghĩa hoàn thành (definition of done) yếu. Trong Agile, một hạng mục chỉ được coi là xong khi đã đạt tiêu chí chấp nhận và tiêu chuẩn chất lượng chung; nếu không, "tốc độ" chỉ là ảo giác và nợ kỹ thuật dồn lại.

  • Thiếu chỉ số đo kết quả

    Thiếu chỉ số hiệu suất (performance metrics) khiến không ai trả lời được hệ thống đã cải thiện thời gian xử lý hay không. Theo lĩnh vực hiệu suất Đo lường (Measurement) của PMBOK 7, chỉ số phải đo kết quả, không chỉ đầu ra.

  • Lẽ ra PM nên làm gì

    1. 1

      Bước 1: Chọn lát cắt phạm vi theo khối lượng và giá trị

      Ưu tiên các loại đơn có khối lượng lớn và quy trình ổn định để mỗi lần phát hành giảm rõ rệt khối lượng giấy.

    2. 2

      Bước 2: Định nghĩa "khả dụng" cùng người xét duyệt

      Một loại đơn chỉ được tính là đã chuyển đổi khi đạt các điều kiện:

      • Xử lý trọn vẹn

        Người xét duyệt hoàn tất hồ sơ từ đầu đến cuối trên hệ thống mà không cần quay lại giấy.

      • Đã kiểm thử đầy đủ

        Mọi bản phát hành qua kiểm thử hồi quy và kiểm thử chấp nhận với người dùng trước khi lên môi trường thật.

      • Chỉ số kết quả

        Thời gian xử lý trung bình và tỷ lệ lỗi được đo trước và sau chuyển đổi.

    3. 3

      Bước 3: Mở rộng người dùng theo lộ trình có hỗ trợ

      Lên kế hoạch đào tạo, hỗ trợ kỹ thuật tại chỗ và kênh phản hồi cho từng văn phòng trước khi kích hoạt tài khoản.

    4. 4

      Bước 4: Giám sát nhà thầu bằng kết quả

      Hợp đồng gắn với chỉ số chất lượng và kết quả nghiệp vụ, không chỉ số lượng tính năng giao.

    PM Takeaway (Bài học rút ra)

    Phát hành sớm chỉ có giá trị khi phần phát hành giúp người dùng làm xong việc thật. Hãy đo phạm vi đã giao bằng tỷ lệ công việc thực sự chuyển sang hệ thống mới, chứ không bằng số tính năng hay số lần phát hành.

    Nguồn tham khảo

    • GAO-17-486T — Immigration Benefits System: Significant Risks in USCIS's Efforts to Develop its Adjudication and Case Management System
    • Nextgov (03/2016) — DHS OIG slams USCIS on immigration IT
    #Quản lý phạm vi#Sản phẩm khả dụng tối thiểu#Sự tham gia của người dùng#Kiểm thử#gao

    Nguồn: GAO-17-486T — Immigration Benefits System: Significant Risks in USCIS's Efforts to Develop its Adjudication and Case Management System ↗ (mở trong thẻ mới)

    Trắc nghiệm tình huống PMP

    Câu 1/1
    Nhóm Agile của bạn đã phát hành hệ thống xử lý hồ sơ mới được 18 tháng, tốc độ (velocity) ổn định, nhưng người xét duyệt vẫn xử lý hơn 90% hồ sơ trên giấy và phàn nàn hệ thống thiếu chức năng. Bước tiếp theo phù hợp nhất là gì?

    Bạn chọn phương án nào?

    Nếu là PM chương trình ELIS năm 2016 — hệ thống mới xử lý dưới 10% khối lượng, còn quy trình giấy vẫn tốn kém — bạn chọn hướng nào?

    Tình huống này hữu ích với bạn?

    Bình luận0

    Bình luận (0)

    Đăng nhập để tham gia thảo luận.

    Tình huống cùng lĩnh vực

    Quản lý Phạm vi

    Duke Nukem Forever: 14 năm phát triển khi phạm vi là một mục tiêu di động và không ai định nghĩa "xong"

    Công bố năm 1997 với kỳ vọng ra mắt cuối 1998, tựa game Duke Nukem Forever chuyển động cơ đồ hoạ nhiều lần, khởi động lại và chỉ phát hành tháng 6/2011 sau khi Gearbox tiếp quản. Phân tích dưới góc nhìn quản lý phạm vi: khi chủ dự án tự quyết mọi thay đổi, không có đường cơ sở và không có tiêu chí hoàn thành.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận14/10/2026
    Quản lý Phạm vi

    FBI Sentinel (2006–2012): yêu cầu sáu năm tuổi, tạm dừng nhà thầu và cuộc đặt lại phạm vi theo hướng agile

    Sau thất bại của Virtual Case File, FBI giao Lockheed Martin xây hệ thống hồ sơ điện tử Sentinel theo bốn giai đoạn. Đến 2010, mới xong hai giai đoạn, thanh tra Bộ Tư pháp cảnh báo yêu cầu đã cũ và kế hoạch mới chưa được văn bản hoá. FBI dừng nhà thầu, tự phát triển theo agile với phạm vi thu hẹp và hệ thống được dùng toàn cơ quan từ 7/2012. Bài học về xếp hạng lại yêu cầu khi đã tiêu hao phần lớn ngân sách.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận12/10/2026
    Quản lý Phạm vi

    Phoenix/Firefox (2002–2004): cắt gọt phạm vi của một bộ ứng dụng cồng kềnh để làm ra trình duyệt gọn nhẹ

    Một nhóm nhỏ trong cộng đồng Mozilla cho rằng áp lực thương mại và việc tính năng chồng chất đã làm Mozilla Suite phình to. Họ làm một trình duyệt độc lập, tối giản (Phoenix, sau đổi tên Firefox), ra bản 1.0 ngày 9/11/2004 và đạt 60 triệu lượt tải trong chín tháng. Ví dụ thành công của việc dám loại bỏ.

    0 lượt thích 0 lượt đánh giá hữu ích 0 bình luận04/10/2026

    Nội dung

    Bối cảnh thực tếPhân tích nguyên nhân theo chuẩn PMPLẽ ra PM nên làm gìPM Takeaway (Bài học rút ra)Nguồn tham khảoTrắc nghiệmBình chọn
    Quảng cáoBộ đề thi thử PMP (mẫu)