PHẦN BỐN

Tòa nhà và
Hệ thống quản lý

Chương 13 Chương 15
Xây dựng hệ thống thông tin Quản lý Hệ thống Toàn cầu

Chương 14
Quản lý dự án

PHẦN THỨ TƯ chỉ ra cách sử dụng kiến thức thu được trong các chương trước để phân tích và thiết kế các

giải pháp hệ thống thông tin cho các vấn đề kinh doanh. Phần này trả lời những câu hỏi như sau: Làm thế

nào để tôi có thể phát triển một giải pháp cho một vấn đề hệ thống thông tin nhằm mang lại lợi ích kinh

doanh chân chính? Làm thế nào để công ty có thể điều chỉnh những thay đổi do giải pháp hệ thống mới

đưa ra? Có những cách tiếp cận thay thế nào để xây dựng các giải pháp hệ thống?
 13
CHƯƠNG

Xây dựng hệ thống thông tin

Mục tiêu học tập

Sau khi đọc chương này, bạn sẽ có thể trả lời những câu hỏi sau:
13-1 Làm thế nào để xây dựng các hệ thống mới tạo ra sự thay đổi tổ chức?

13-2 Các hoạt động cốt lõi trong quá trình phát triển hệ thống là gì?
13-3 Các phương pháp luận chính để lập mô hình và thiết kế là gì
hệ thống?

13-4 Các phương pháp thay thế để xây dựng hệ thống thông tin là gì?

13-5 Những cách tiếp cận mới để xây dựng hệ thống trong kỷ nguyên công ty kỹ thuật số là gì?

MyLab MIS™
Thăm nom mymislab.com cho mô phỏng, hướng dẫn và các bài toán cuối chương.

CÁC TRƯỜNG HỢP CHƯƠNG

Angostura xây dựng hệ thống bán hàng di động

Fujitsu chọn giải pháp SaaS để đơn giản hóa quy trình bán hàng,
phát triển ứng dụng di động: Có gì khác biệt
Công thức của ConAgra cho một hệ thống nguồn nhân lực tốt hơn

CÁC TRƯỜNG HỢP VIDEO

IBM: Quản lý Quy trình Kinh doanh trong Môi trường SaaS IBM
Giúp Thành phố Madrid với Phần mềm BPM Thời gian thực
Video hướng dẫn:
Quản lý quy trình kinh doanh BPM Quản lý quy trình làm
việc của khách hàng được trực quan hóa

514
 Angostura xây dựng hệ thống bán hàng di động

NS ở Laventille, Trinidad, là một trong những nhà sản xuất rượu rum hàng đầu của Caribe
ouse
và dẫn đầu of
thịAngostura (cònvềđược
trường thế giới gọi
bitters là Angostura
được Limited),
sử dụng trong có trụ
nhiều loại
tura có 330 nhân viên toàn thời gian và doanh thu hàng năm khoảng 100 triệu đô
sở chính
cocktail. Angos-

la.
Angostura vẫn đảm nhận việc phân phối nội địa các sản phẩm của mình ở
Trinidad và Tobago, với đội ngũ 16 đại diện bán hàng nhận đơn đặt hàng tại hiện
trường. Mặc dù sự sắp xếp này hoạt động tốt trong quá khứ, nhưng quá trình này
rất thủ công, tẻ nhạt, tốn thời gian và đôi khi tạo ra các đơn đặt hàng không chính
xác.
Mỗi ngày, 16 đại diện bán hàng trong lĩnh
vực này phải sao chép các đơn đặt hàng ra
giấy và trở lại văn phòng để giao các đơn đặt
hàng cho đại diện dịch vụ khách hàng, người
này sau đó sẽ nhập thủ công dữ liệu đơn đặt
hàng vào kế hoạch nguồn lực doanh nghiệp
SAP của Angostura (ERP ) hệ thống. Bởi vì đơn
đặt hàng được viết tay, thông tin có thể được
đọc và nhập không chính xác, có thể dẫn đến
việc gửi nhầm hàng cho khách hàng. Những
đơn đặt hàng không chính xác như vậy thường
bị trả lại, tạo ra nhiều thủ tục giấy tờ hơn và chi
phí cao hơn. Angostura cũng sử dụng các quy
trình thủ công để báo cáo và theo dõi các hóa
đơn và thông tin tài khoản phải thu, điều này
có thể tạo thêm sự chậm trễ và sai sót.

Các đại diện bán hàng cũng đang làm việc

với dữ liệu về tình trạng sẵn có của sản phẩm- © TristanBM / Fotolia

ity đó có thể đã lỗi thời. Nếu các đại diện bán hàng vắng mặt tại văn phòng, họ sẽ
không thể biết liệu đơn đặt hàng có thực sự được hoàn thành hay không. Họ sẽ phải
gọi đến kho hàng của Angostura để tìm hiểu xem liệu đơn hàng có khả thi hay không.

Vào năm 2012, ban lãnh đạo của Angostura quyết định rằng quy trình bán
hàng cần được sắp xếp hợp lý và hiệu quả hơn và nên sử dụng công nghệ di
động. Công ty đã xác định một tập hợp các yêu cầu thông tin chi tiết cho quy trình
bán hàng được cải thiện và đã dành hơn một năm để đánh giá các giải pháp hệ
thống từ năm nhà cung cấp thiết bị di động. Một yêu cầu quan trọng là ứng dụng
phải có thể tự động cập nhật tính khả dụng của các sản phẩm đã mua từ kho
tổng thể của công ty và tích hợp

515
516 Phần bốn Xây dựng và Quản lý Hệ thống

với hệ thống ERP SAP back-end của công ty. Một yêu cầu khác là hệ thống di động
có thể hoạt động ngoại tuyến để đại diện bán hàng vẫn có thể nhập đơn đặt hàng
trên thiết bị di động ngay cả khi không có kết nối trực tuyến. Sau khi trực tuyến,
thiết bị có thể gửi đơn đặt hàng qua hệ thống ERP.

Nhà cung cấp được chọn là nhà cung cấp có thể phát triển tốt nhất ứng dụng di động
theo các thông số kỹ thuật của công ty và nằm trong ngân sách do ban quản lý thiết lập. Vào
năm 2013, Angostura đã hợp tác với các nhà tư vấn IDS Scheer và itCampus để phát triển
một giải pháp bán hàng di động chạy trên Apple iPad. Giải pháp bao gồm cơ sở dữ liệu khách
hàng ngoại tuyến, danh mục sản phẩm, giá cụ thể của khách hàng, mục nhập đơn đặt hàng,
xem trước đơn đặt hàng và tích hợp với máy in Bluetooth. Nó nhanh chóng được tạo ra bằng
cách sử dụng công nghệ SAP NetWeaver Gateway để kết nối các thiết bị và nền tảng khác
nhau với phần mềm SAP. Một ứng dụng thử nghiệm đã sẵn sàng để thử nghiệm vào tháng 6
năm đó và toàn bộ ứng dụng đã hoạt động vào tháng 1 năm 2014.

Mỗi người trong số 16 đại diện bán hàng của Angostura được cấp một chiếc iPad
không chỉ bao gồm ứng dụng đặt hàng mà còn các ứng dụng di động khác để giúp quá
trình bán hàng hiệu quả hơn, chẳng hạn như email, Google Maps, trình tải lên video và
tài liệu PDF để hiển thị dòng sản phẩm Angostura. Ứng dụng bán hàng tích hợp với hệ
thống ERP của công ty, cung cấp cho các đại diện bán hàng thông tin cập nhật về tình
trạng sẵn có của sản phẩm trong kho.
Với Ứng dụng bán hàng trên thiết bị di động Angostura, đơn hàng có thể được
tạo trong vòng chưa đầy 30 giây, tùy thuộc vào kích thước của đơn hàng, giúp quá
trình đặt hàng nhanh hơn gấp hai lần. Tiết kiệm 20 phần trăm thời gian cho mỗi
nhân viên bán hàng vì các đại diện bán hàng hiện có khả năng gửi đơn đặt hàng
khi họ đặt chúng thay vì đợi cho đến khi họ trở lại văn phòng. Lượng thời gian mà
đại diện dịch vụ khách hàng thường dành cho việc nhập dữ liệu — vốn là đáng kể
— đã giảm 75%, giải phóng thời gian cho các nhiệm vụ hữu ích hơn. Các đơn đặt
hàng bị trả lại đã được giảm 30%.

Nguồn: Natalie Miller, “Công ty lâu đời với xu hướng bán hàng hiện đại,” SAP Insider Profiles,
tháng 1 năm 2016; www.angostura.com, truy cập ngày 10 tháng 2 năm 2016; và IDS Scheer
Consulting Group, “Giải pháp Bán hàng Di động SAP dựa trên iPad của Angostura,” 2014.

MỘT và xây dựngKinh nghiệm

hệ thống của
thông ngostura
tin mới. minh
Xây dựng mộthọa một số
hệ thống mớibước cầnthoại
cho điện thiếtdiđể
kế đơn hàng bán hàng, bao gồm việc phân tích các vấn đề của tổ chức với các hệ
thiết
động

thống hiện có, đánh giá các yêu cầu về thông tin, lựa chọn công nghệ phù hợp và
thiết kế lại các quy trình và công việc kinh doanh. Ban lãnh đạo phải giám sát nỗ
lực xây dựng hệ thống và đánh giá lợi ích và chi phí. Các yêu cầu thông tin đã được
đưa vào thiết kế của hệ thống mới, thể hiện một quá trình thay đổi tổ chức theo kế
hoạch.
Trường hợp mở chương kêu gọi sự chú ý đến những điểm quan trọng được nêu ra
bởi trường hợp này và chương này. Khả năng xử lý các đơn đặt hàng của Angostura bị
cản trở bởi các quy trình thủ công lỗi thời và không hiệu quả, làm tăng chi phí, làm
chậm công việc và hạn chế khả năng phục vụ khách hàng của công ty.
Giải pháp là thiết kế lại quy trình đặt hàng bán hàng để sử dụng thiết bị di động
và phần mềm, đồng thời cho phép nhập đơn hàng qua iPad và truyền tới hệ thống
ERP back-end của công ty. Các yêu cầu về thông tin của Angostura đã được đưa
vào thiết kế hệ thống. Giải pháp không chỉ bao gồm
 Chương 13 Xây dựng hệ thống thông tin 517

Việc kinh doanh

Thách thức

• Quy trình thủ công không hiệu quả

• Chọn hệ thống
dung dịch Ban quản lý
• Giám sát dự án

• Thiết kế lại bán hàng

quá trình đặt hàng
Thông tin Việc kinh doanh
• Thiết kế lại công việc Tổ chức Hệ thống Các giải pháp
• Thay đổi công ty
văn hóa
• Tiết kiệm thời gian
Hệ thống đặt hàng bán hàng di động
• Cải thiện dịch vụ
• Chuyển đơn đặt hàng qua thiết bị • Giảm chi phí
di động
• SAP ERP • Cập nhật hàng tồn kho và đơn đặt hàng trực

• SAP NetWeaver tuyến trong thời gian thực

Công nghệ • Hoạt động ngoại tuyến và trực tuyến
Phần mềm Gateway
• iPad

ứng dụng công nghệ mới nhưng thay đổi văn hóa doanh nghiệp, quy trình kinh doanh,
chức năng công việc. Hoạt động bán hàng của Angostura đã trở nên hiệu quả và tiết
kiệm chi phí hơn rất nhiều.
Dưới đây là một số câu hỏi cần suy nghĩ: Ứng dụng bán hàng trên thiết bị di động của Angostura đã
đáp ứng các yêu cầu thông tin của nó như thế nào? Ứng dụng bán hàng trên thiết bị di động của
Angostura có giải pháp hiệu quả như thế nào? Tại sao? Hệ thống mới đã thay đổi bao nhiêu phần trăm
cách Angostura điều hành kinh doanh?

13-1 Làm thế nào để xây dựng các hệ thống mới tạo ra
thay đổi tổ chức?
Xây dựng một hệ thống thông tin mới là một loại thay đổi tổ chức có kế hoạch. Sự
ra đời của một hệ thống thông tin mới liên quan đến nhiều thứ hơn là phần cứng
và phần mềm mới. Nó cũng bao gồm những thay đổi về công việc, kỹ năng, quản lý
và tổ chức. Khi chúng tôi thiết kế một hệ thống thông tin mới, chúng tôi đang thiết
kế lại tổ chức. Người xây dựng hệ thống phải hiểu cách một hệ thống sẽ ảnh
hưởng đến các quá trình kinh doanh cụ thể và toàn bộ tổ chức.

Phát triển hệ thống và thay đổi tổ chức

Công nghệ thông tin có thể thúc đẩy các mức độ thay đổi tổ chức khác nhau, từ
mức độ gia tăng đến mức độ sâu rộng. Hình 13.1 cho thấy bốn loại thay đổi cơ cấu
tổ chức được hỗ trợ bởi công nghệ thông tin: (1) tự động hóa, (2) hợp lý hóa, (3)
thiết kế lại quy trình kinh doanh và (4) thay đổi mô hình. Mỗi thứ đều mang những
rủi ro và phần thưởng khác nhau.
Hình thức thay đổi tổ chức hỗ trợ CNTT phổ biến nhất là tự động hóa.
Các ứng dụng đầu tiên của công nghệ thông tin liên quan đến việc hỗ trợ nhân viên
thực hiện nhiệm vụ của họ một cách hiệu quả và hiệu quả hơn. Tính toán phiếu lương
và sổ đăng ký trả lương, cho phép giao dịch viên ngân hàng truy cập ngay vào hồ sơ
tiền gửi của khách hàng và phát triển mạng lưới đặt chỗ trên toàn quốc cho các đại lý vé
máy bay là tất cả những ví dụ về tự động hóa ban đầu.
518 Phần bốn Xây dựng và Quản lý Hệ thống

HÌNH 13.1 RỦI RO VÀ PHẦN THƯỞNG ĐỔI HÀNG TỔ CHỨC

Các hình thức thay đổi tổ chức phổ biến nhất là tự động hóa và hợp lý hóa. Các chiến lược tương đối chậm và
thay đổi chậm này mang lại lợi nhuận khiêm tốn nhưng ít rủi ro. Thay đổi nhanh hơn và toàn diện hơn — chẳng
hạn như thay đổi mô hình và thiết kế lại — mang lại phần thưởng cao nhưng mang lại cơ hội thất bại đáng kể.

Một hình thức thay đổi tổ chức sâu hơn — một hình thức diễn ra nhanh chóng
từ quá trình tự động hóa ban đầu — là hợp lý hoá các thủ tục. Tự động hóa
thường xuyên bộc lộ những điểm nghẽn mới trong sản xuất và làm cho việc sắp
xếp các thủ tục và cấu trúc hiện có trở nên cồng kềnh một cách khó khăn. Hợp lý
hóa các thủ tục là việc hợp lý hóa các thủ tục hoạt động tiêu chuẩn. Ví dụ, hệ thống
đặt hàng di động mới của Angostura hiệu quả không chỉ vì nó sử dụng công nghệ
máy tính mà còn vì công ty đã đơn giản hóa các quy trình kinh doanh cho chức
năng này. Cần ít bước thủ công hơn.
Hợp lý hóa các thủ tục thường được tìm thấy trong các chương trình thực hiện một loạt
các cải tiến chất lượng liên tục trong sản phẩm, dịch vụ và hoạt động, chẳng hạn như quản lý
chất lượng toàn diện (TQM) và sáu sigma. Quản lý chất lượng toàn diện (TQM) làm cho việc
đạt được chất lượng tự nó trở thành mục đích và là trách nhiệm của tất cả mọi người và các
chức năng trong một tổ chức. TQM bắt nguồn từ các khái niệm được phát triển bởi các
chuyên gia chất lượng của Mỹ như W. Edwards Deming và Joseph Juran, nhưng nó đã được
phổ biến bởi người Nhật.Sáu Sigma là một thước đo chất lượng cụ thể, đại diện cho 3,4
khuyết tật trên một triệu cơ hội. Hầu hết các công ty không thể đạt được mức chất lượng này
nhưng sử dụng sáu sigma làm mục tiêu để thúc đẩy các chương trình cải tiến chất lượng liên
tục.
Một loại thay đổi tổ chức mạnh mẽ hơn là thiết kế lại quy trình kinh doanh,
trong đó các quy trình kinh doanh được phân tích, đơn giản hóa và thiết kế lại.
Thiết kế lại quy trình kinh doanh tổ chức lại quy trình làm việc, kết hợp các bước để
cắt giảm lãng phí và loại bỏ các nhiệm vụ lặp đi lặp lại, tốn nhiều giấy tờ. (Đôi khi
thiết kế mới cũng loại bỏ công việc.) Nó tham vọng hơn nhiều so với việc hợp lý hóa
các thủ tục, đòi hỏi một tầm nhìn mới về cách tổ chức quy trình.
 Chương 13 Xây dựng hệ thống thông tin 519

Ví dụ được trích dẫn một cách đáng kinh ngạc về việc thiết kế lại quy trình kinh
doanh là quy trình xử lý không cần hóa đơn của Công ty FordMotor, đã làm giảm
75% số người đứng đầu trong tổ chức Các khoản phải trả của Ford tại Bắc Mỹ gồm
500 người. Nhân viên kế toán khoản phải trả đã từng dành phần lớn thời gian để
giải quyết những sai lệch giữa đơn đặt hàng, chứng từ nhận và hóa đơn. Ford đã
thiết kế lại quy trình thanh toán các tài khoản của mình để bộ phận mua hàng
nhập đơn đặt hàng vào cơ sở dữ liệu trực tuyến để bộ phận tiếp nhận có thể kiểm
tra khi các mặt hàng đã đặt hàng đến nơi. Nếu hàng hóa nhận được khớp với đơn
mua hàng, hệ thống sẽ tự động tạo ra một bảng kiểm tra khoản phải trả để gửi
cho nhà cung cấp. Không cần nhà cung cấp gửi hóa đơn.
Hợp lý hóa các thủ tục và thiết kế lại các quy trình kinh doanh được giới hạn trong các bộ
phận cụ thể của doanh nghiệp. Hệ thống thông tin mới cuối cùng có thể ảnh hưởng đến
thiết kế của toàn bộ tổ chức bằng cách biến đổi cách thức tổ chức thực hiện hoạt động kinh
doanh hoặc thậm chí bản chất của hoạt động kinh doanh. Ví dụ, công ty vận tải và vận tải
đường dài Schneider National đã sử dụng hệ thống thông tin mới để thay đổi mô hình kinh
doanh của mình. Schneider đã tạo ra một doanh nghiệp mới quản lý hậu cần cho các công ty
khác. Hình thức thay đổi kinh doanh triệt để hơn này được gọi làchuyển đổi mô hình. Một
sự thay đổi mô hình liên quan đến việc xem xét lại bản chất của doanh nghiệp và bản chất
của tổ chức.
Thay đổi mô hình và thiết kế lại quy trình kinh doanh thường thất bại vì sự thay đổi
tổ chức rộng rãi rất khó để sắp xếp (xem Chương 14). Vậy tại sao nhiều tập đoàn lại dự
tính đến sự thay đổi triệt để như vậy? Vì phần thưởng cao như nhau (xem Hình 13.1).
Trong nhiều trường hợp, các công ty đang tìm kiếm sự thay đổi mô hình và theo đuổi
các chiến lược tái cấu trúc đã đạt được mức tăng đáng kinh ngạc, mức độ lớn trong lợi
tức đầu tư (hoặc năng suất) của họ. Một số câu chuyện thành công và một số câu
chuyện thất bại, được bao gồm trong suốt cuốn sách này.

Thiết kế lại Quy trình Kinh doanh

Giống như Angostura, được mô tả trong trường hợp mở đầu chương, nhiều doanh
nghiệp ngày nay đang cố gắng sử dụng công nghệ thông tin để cải thiện quy trình kinh
doanh của họ. Một số hệ thống này đòi hỏi sự thay đổi quy trình gia tăng, nhưng những
hệ thống khác yêu cầu thiết kế lại các quy trình kinh doanh sâu rộng hơn. Để đối phó
với những thay đổi này, các tổ chức đang chuyển sang quản lý quy trình kinh doanh.
Quản lý quy trình kinh doanh (BPM) cung cấp nhiều công cụ và phương pháp luận để
phân tích các quy trình hiện có, thiết kế các quy trình mới và tối ưu hóa các quy trình đó.
BPM không bao giờ được kết luận vì cải tiến quy trình đòi hỏi phải thay đổi liên tục. Các
công ty thực hành quản lý quy trình kinh doanh trải qua các bước sau:

1. Xác định các quy trình thay đổi: Một trong những quyết định chiến lược quan trọng nhất mà
một công ty có thể đưa ra không phải là quyết định sử dụng máy tính như thế nào để cải thiện
quy trình kinh doanh mà là hiểu những quy trình kinh doanh cần cải tiến. Khi các hệ thống
được sử dụng để củng cố mô hình kinh doanh hoặc các quy trình kinh doanh sai, doanh
nghiệp có thể trở nên hiệu quả hơn trong việc làm những việc không nên làm. Kết quả là, công
ty trở nên dễ bị tổn thương trước các đối thủ cạnh tranh, những người có thể đã phát hiện ra
mô hình kinh doanh phù hợp. Thời gian và chi phí đáng kể cũng có thể được dành để cải thiện
các quy trình kinh doanh có ít tác động đến hiệu suất và doanh thu tổng thể của công ty. Các
nhà quản lý cần xác định quy trình kinh doanh nào là quan trọng nhất và việc cải thiện các quy
trình này sẽ giúp ích như thế nào cho hiệu quả kinh doanh.

2. Phân tích các quy trình hiện có: Các quy trình kinh doanh hiện tại cần được mô hình hóa và
lập thành văn bản, lưu ý các yếu tố đầu vào, đầu ra, nguồn lực và trình tự của các hoạt động.
Nhóm thiết kế quy trình xác định các bước thừa, nhiệm vụ tốn nhiều giấy, tắc nghẽn và các
yếu tố kém hiệu quả khác.
520 Phần bốn Xây dựng và Quản lý Hệ thống

Hình 13.2 minh họa quy trình “nguyên trạng” để mua một cuốn sách từ một cửa
hàng sách thực. Hãy xem xét điều gì sẽ xảy ra khi khách hàng ghé thăm một cửa
hàng sách thực và tìm kiếm một cuốn sách trên kệ của họ. Nếu người đó tìm thấy
cuốn sách, người đó sẽ mang nó đến quầy thanh toán và thanh toán qua thẻ tín
dụng, tiền mặt hoặc séc. Nếu khách hàng không tìm được sách thì phải nhờ nhân
viên nhà sách lục soát các kệ sách hoặc kiểm tra hồ sơ hàng tồn kho của nhà sách
xem còn hàng hay không. Nếu nhân viên bán hàng tìm thấy cuốn sách, khách hàng
mua nó và rời đi. Nếu sách không có sẵn tại địa phương, nhân viên bán hàng hỏi về
việc đặt hàng cho khách hàng từ kho của hiệu sách hoặc từ nhà phân phối hoặc
nhà xuất bản sách. Khi sách đã đặt đến nhà sách, một nhân viên của nhà sách sẽ
gọi điện cho khách hàng thông báo thông tin này. Khách hàng sẽ phải đến hiệu
sách một lần nữa để chọn sách và thanh toán. Nếu nhà sách không thể đặt sách
cho khách hàng, khách hàng sẽ phải thử một nhà sách khác. Bạn có thể thấy rằng
quy trình này có nhiều bước và có thể yêu cầu khách hàng thực hiện nhiều chuyến
đi đến hiệu sách.
3. Thiết kế quy trình mới: Sau khi quy trình hiện có được lập bản đồ và đo lường về thời
gian và chi phí, nhóm thiết kế quy trình sẽ cố gắng cải thiện quy trình bằng cách thiết kế
một quy trình mới. Một quy trình “sắp xảy ra” mới được sắp xếp hợp lý sẽ được lập
thành văn bản và mô hình hóa để so sánh với quy trình cũ.

Hình 13.3 minh họa quy trình mua sách có thể được thiết kế lại như thế nào
bằng cách tận dụng lợi thế của Internet. Khách hàng truy cập vào một cửa hàng
sách trực tuyến qua Internet từ máy tính của họ. Anh ấy hoặc cô ấy tìm kiếm danh
mục trực tuyến của hiệu sách để tìm cuốn sách mà anh ấy hoặc cô ấy muốn. Nếu
sách có sẵn, khách hàng đặt sách trực tuyến, cung cấp thông tin thẻ tín dụng và địa
chỉ giao hàng, sách sẽ được chuyển đến tận nhà của khách hàng. Nếu nhà sách
trực tuyến không có sách, khách hàng chọn nhà sách trực tuyến khác và tìm kiếm
lại sách. Quy trình này có ít bước hơn nhiều so với quy trình đó

HÌNH 13.2 QUY TRÌNH KINH DOANH NHƯ THẾ NÀO ĐỂ MUA SÁCH TỪ CỬA HÀNG SÁCH VẬT LÝ

Việc mua sách từ một cửa hàng sách thực đòi hỏi nhiều bước phải được thực hiện bởi cả người bán và khách hàng.
 Chương 13 Xây dựng hệ thống thông tin 521

HÌNH 13.3 QUY TRÌNH ĐỔI MỚI ĐỂ MUA SÁCH TRỰC TUYẾN

Sử dụng công nghệ Internet giúp bạn có thể thiết kế lại quy trình mua sách sao cho yêu cầu ít bước hơn và tiêu
thụ ít tài nguyên hơn.

để mua sách trong một cửa hàng sách thực, khách hàng cần ít nỗ lực hơn nhiều và
cần ít nhân viên bán hàng hơn cho dịch vụ khách hàng. Do đó, quy trình mới hiệu
quả hơn và tiết kiệm thời gian hơn nhiều.
Thiết kế quy trình mới cần được chứng minh bằng cách cho thấy nó giảm thời
gian và chi phí như thế nào hoặc nâng cao giá trị và dịch vụ khách hàng. Đầu tiên,
ban quản lý đo lường thời gian và chi phí của quy trình hiện có như một cơ sở.
Trong ví dụ của chúng tôi, thời gian cần thiết để mua sách từ một cửa hàng sách
thực có thể dao động từ 15 phút (nếu khách hàng tìm thấy ngay thứ họ muốn) đến
30 phút nếu sách còn trong kho nhưng phải có nhân viên bán hàng tìm. Nếu sách
phải được đặt hàng từ một nguồn khác, quá trình này có thể mất một hoặc hai
tuần và khách hàng sẽ phải đi một chuyến khác đến hiệu sách. Nếu khách hàng
sống ở xa hiệu sách, thời gian di chuyển đến hiệu sách sẽ phải được tính vào. Nhà
sách sẽ phải trả chi phí duy trì một cửa hàng thực và giữ sách trong kho, cho nhân
viên bán hàng tại chỗ,

Quy trình mới để mua sách trực tuyến có thể chỉ mất vài phút, mặc dù khách
hàng có thể phải đợi vài ngày hoặc một tuần để được giao sách và sẽ phải trả phí
vận chuyển. Nhưng khách hàng tiết kiệm thời gian và tiền bạc do không phải đi
đến nhà sách hoặc ghé thăm thêm để chọn sách. Chi phí của người bán sách thấp
hơn vì họ không phải trả tiền cho một vị trí cửa hàng thực hoặc cho hàng tồn kho
tại địa phương.
4. Thực hiện quy trình mới: Một khi quy trình mới đã được mô hình hóa và phân tích
kỹ lưỡng, nó phải được chuyển thành một tập hợp các thủ tục và quy tắc làm việc
mới. Các hệ thống thông tin mới hoặc các cải tiến đối với các hệ thống hiện có có thể
phải được thực hiện để hỗ trợ quá trình được thiết kế lại. Quy trình mới và các hệ
thống hỗ trợ được triển khai vào tổ chức kinh doanh. Khi doanh nghiệp bắt đầu sử
dụng quy trình này, các vấn đề sẽ được phát hiện và giải quyết. Nhân viên làm việc
với quy trình có thể đề xuất các cải tiến.
5. Đo lường liên tục: Khi một quy trình đã được thực hiện và tối ưu hóa, quy trình đó
cần phải được đo lường liên tục. Tại sao? Các quy trình có thể xấu đi theo thời gian
khi nhân viên quay lại với các phương pháp cũ hoặc chúng có thể mất hiệu quả
nếu doanh nghiệp có những thay đổi khác.

Mặc dù nhiều cải tiến quy trình kinh doanh đang tăng dần và liên tục, nhưng vẫn
có những trường hợp cần phải có sự thay đổi triệt để hơn. Ví dụ của chúng tôi về
một cửa hàng sách thực thiết kế lại quy trình mua sách để có thể thực hiện trực
tuyến là một ví dụ về kiểu thay đổi căn bản, sâu rộng này.
522 Phần bốn Xây dựng và Quản lý Hệ thống

Khi được thực hiện đúng cách, việc thiết kế lại quy trình kinh doanh sẽ tạo ra những lợi ích đáng kể
về năng suất và hiệu quả và thậm chí có thể thay đổi cách thức hoạt động của doanh nghiệp.
Trong một số trường hợp, nó thúc đẩy một “sự thay đổi mô hình” làm thay đổi bản chất của chính
doanh nghiệp.
Điều này thực sự đã xảy ra trong lĩnh vực bán lẻ sách khi Amazon thách thức các hiệu
sách vật lý truyền thống bằng mô hình bán lẻ trực tuyến của mình. Amazon đã gia tăng
áp lực lên các hiệu sách khi phát hành máy đọc sách điện tử Kindle. Ở trong
Năm 2015, 84 triệu người đã tải xuống sách điện tử và tạo ra doanh thu hơn 4 tỷ USD,
chiếm khoảng 25% tổng thị trường sách. Bằng cách suy nghĩ lại toàn diện về cách một
cuốn sách có thể được xuất bản, mua và bán, Amazon và các hiệu sách trực tuyến khác
đã đạt được những hiệu quả đáng kể, giảm chi phí và một cách kinh doanh hoàn toàn
mới.
BPM đặt ra những thách thức. Các giám đốc điều hành báo cáo rằng rào cản lớn nhất để
thay đổi quy trình kinh doanh thành công là văn hóa tổ chức. Nhân viên không thích những
thói quen quen thuộc và thường cố gắng chống lại sự thay đổi. Điều này đặc biệt đúng với
các dự án mà những thay đổi về tổ chức là rất tham vọng và có tầm ảnh hưởng sâu rộng.
Quản lý thay đổi không đơn giản cũng không trực quan và các công ty cam kết cải tiến quy
trình sâu rộng cần có chiến lược quản lý thay đổi tốt (xem Chương 14).

Công cụ quản lý quy trình kinh doanh

Hơn 100 công ty phần mềm cung cấp các công cụ cho các khía cạnh khác nhau của BPM, bao
gồm IBM, Oracle và TIBCO. Các công cụ này giúp doanh nghiệp xác định và lập hồ sơ các quy
trình yêu cầu cải tiến, tạo mô hình các quy trình cải tiến, nắm bắt và thực thi các quy tắc kinh
doanh để thực hiện các quy trình cũng như tích hợp các hệ thống hiện có để hỗ trợ các quy
trình mới hoặc được thiết kế lại. Các công cụ phần mềm BPM cũng cung cấp các phân tích để
xác minh rằng hiệu suất quy trình đã được cải thiện và để đo lường tác động của các thay đổi
quy trình đối với các chỉ số hoạt động kinh doanh chính.
Một số công cụ BPM ghi lại và giám sát các quy trình kinh doanh để giúp các công ty
xác định sự kém hiệu quả bằng cách sử dụng phần mềm để kết nối với từng hệ thống
mà công ty sử dụng cho một quy trình cụ thể để xác định các điểm sự cố. Một loại công
cụ khác tự động hóa một số phần của quy trình kinh doanh và thực thi các quy tắc kinh
doanh để nhân viên thực hiện quy trình đó một cách nhất quán và hiệu quả hơn.
Ví dụ: Công ty Bảo hiểm Quốc gia Mỹ, công ty cung cấp bảo hiểm nhân thọ, bảo hiểm
y tế, bảo hiểm tài sản và các dịch vụ đầu tư, đã sử dụng phần mềm Pega BPMworkflow
để hợp lý hóa các quy trình dịch vụ khách hàng trên bốn nhóm kinh doanh. Phần mềm
đã xây dựng các quy tắc để hướng dẫn các đại diện dịch vụ khách hàng thông qua một
chế độ xem thông tin của khách hàng được duy trì trong nhiều hệ thống. Bằng cách loại
bỏ sự cần thiết phải kết hợp nhiều ứng dụng đồng thời để xử lý các yêu cầu của khách
hàng và đại lý, quy trình được cải tiến đã tăng công suất khối lượng công việc của đại
diện dịch vụ khách hàng lên 192 phần trăm.
Loại công cụ thứ ba giúp các doanh nghiệp tích hợp các hệ thống hiện có của họ để
hỗ trợ cải tiến quy trình. Chúng tự động quản lý các quy trình trong toàn doanh nghiệp,
trích xuất dữ liệu từ nhiều nguồn và cơ sở dữ liệu khác nhau, đồng thời tạo ra các giao
dịch trong nhiều hệ thống có liên quan.

13-2 Các hoạt động cốt lõi trong hệ thống là gì

quá trình phát triển?
Hệ thống thông tin mới là sự phát triển vượt bậc của một quá trình giải quyết vấn đề của tổ
chức. Một hệ thống thông tin mới được xây dựng như một giải pháp cho một số loại vấn đề
hoặc tập hợp các vấn đề mà tổ chức nhận thấy rằng nó đang phải đối mặt. Vấn đề
 Chương 13 Xây dựng hệ thống thông tin 523

có thể là một trong đó các nhà quản lý và nhân viên nhận ra rằng tổ chức đang
hoạt động không tốt như mong đợi hoặc rằng tổ chức nên tận dụng các cơ hội mới
để thực hiện thành công hơn.
Các hoạt động đi vào sản xuất một giải pháp hệ thống thông tin cho một vấn đề
hoặc cơ hội của tổ chức được gọi là phát triển hệ thống. Phát triển hệ thống là
một dạng vấn đề có cấu trúc được giải quyết bằng các hoạt động riêng biệt. Các
hoạt động này bao gồm phân tích hệ thống, thiết kế hệ thống, lập trình, thử
nghiệm, chuyển đổi và sản xuất và bảo trì.
Hình 13.4 minh họa quá trình phát triển hệ thống. Các hoạt động phát triển hệ
thống được mô tả thường diễn ra theo thứ tự tuần tự. Nhưng một số hoạt động có
thể cần được lặp lại hoặc một số hoạt động có thể diễn ra đồng thời tùy thuộc vào
cách tiếp cận xây dựng hệ thống đang được sử dụng (xem Phần 13-4).

Phân tích hệ thống

Phân tích hệ thống là phân tích một vấn đề mà một công ty cố gắng giải quyết
bằng hệ thống thông tin. Nó bao gồm việc xác định vấn đề, xác định nguyên nhân
của nó, xác định giải pháp và xác định các yêu cầu thông tin phải được đáp ứng bởi
một giải pháp hệ thống.
Nhà phân tích hệ thống tạo ra một bản đồ đường đi của tổ chức và hệ thống hiện có, xác
định chủ sở hữu và người dùng chính của dữ liệu cùng với phần cứng và phần mềm hiện có.
Sau đó, nhà phân tích hệ thống sẽ trình bày chi tiết các vấn đề của hệ thống hiện có. Bằng
cách kiểm tra các tài liệu, giấy tờ làm việc và thủ tục, quan sát hoạt động của hệ thống và
phỏng vấn những người sử dụng chính của hệ thống, nhà phân tích có thể xác định các khu
vực vấn đề và mục tiêu mà một giải pháp sẽ đạt được. Thông thường, giải pháp yêu cầu xây
dựng một hệ thống thông tin mới hoặc cải tiến một hệ thống thông tin hiện có.

Phân tích hệ thống cũng bao gồm một nghiên cứu khả thi để xác định xem giải
pháp đó có khả thi hoặc có thể đạt được từ quan điểm tài chính, kỹ thuật và tổ chức
hay không. Nghiên cứu khả thi xác định liệu hệ thống được đề xuất có được mong
đợi là một khoản đầu tư tốt hay không, liệu công nghệ có cần thiết cho

HÌNH 13.4 QUÁ TRÌNH PHÁT TRIỂN HỆ THỐNG

Xây dựng một hệ thống có thể được chia thành sáu hoạt động cốt lõi.
524 Phần bốn Xây dựng và Quản lý Hệ thống

hệ thống sẵn có và có thể được xử lý bởi các chuyên gia hệ thống thông tin của
công ty và liệu tổ chức có thể xử lý các thay đổi do hệ thống đưa ra hay không.

Thông thường, quá trình phân tích hệ thống xác định một số giải pháp thay thế
mà tổ chức có thể theo đuổi và đánh giá tính khả thi của mỗi giải pháp. Một báo
cáo đề xuất hệ thống bằng văn bản mô tả chi phí và lợi ích cũng như những ưu
điểm và nhược điểm của từng phương án. Ban giám đốc phụ thuộc vào việc xác
định kết hợp chi phí, lợi ích, tính năng kỹ thuật và tác động của tổ chức đại diện cho
phương án thay thế mong muốn nhất.

Yêu cầu thiết lập thông tin

Có lẽ nhiệm vụ thách thức nhất của nhà phân tích hệ thống là xác định các yêu cầu
thông tin cụ thể phải được đáp ứng bởi giải pháp hệ thống đã chọn. Ở cấp độ cơ
bản nhất,yêu cầu thông tin của một hệ thống mới liên quan đến việc xác định ai
cần thông tin gì, ở đâu, khi nào và như thế nào. Phân tích yêu cầu xác định một
cách cẩn thận các mục tiêu của hệ thống mới hoặc đã sửa đổi và phát triển một mô
tả chi tiết về các chức năng mà hệ thống mới phải thực hiện. Phân tích yêu cầu bị
lỗi là nguyên nhân hàng đầu gây ra lỗi hệ thống và chi phí phát triển hệ thống cao
(xem Chương 14). Một hệ thống được thiết kế theo bộ yêu cầu sai sẽ phải bị loại bỏ
vì hoạt động kém hoặc sẽ cần phải trải qua những sửa đổi lớn. Phần 13-3 mô tả các
cách tiếp cận thay thế để đưa ra các yêu cầu giúp giảm thiểu vấn đề này.

Một số vấn đề không yêu cầu giải pháp hệ thống thông tin mà thay vào đó cần
có sự điều chỉnh trong quản lý, đào tạo bổ sung hoặc cải tiến các quy trình tổ chức
hiện có. Nếu sự cố liên quan đến thông tin, vẫn có thể cần phân tích hệ thống để
chẩn đoán sự cố và đưa ra giải pháp thích hợp.

Thiết kế hệ thống
Phân tích hệ thống mô tả những gì một hệ thống phải làm để đáp ứng các yêu cầu thông tin,
và thiết kế hệ thống cho biết hệ thống sẽ thực hiện mục tiêu này như thế nào. Thiết kế của
một hệ thống thông tin là kế hoạch hoặc mô hình tổng thể cho hệ thống đó. Giống như bản
thiết kế của một tòa nhà hoặc ngôi nhà, nó bao gồm tất cả các thông số kỹ thuật cung cấp
cho hệ thống hình thức và cấu trúc của nó.
Người thiết kế hệ thống nêu chi tiết các thông số kỹ thuật của hệ thống sẽ cung cấp
các chức năng được xác định trong quá trình phân tích hệ thống. Các thông số kỹ thuật
này phải đề cập đến tất cả các thành phần quản lý, tổ chức và công nghệ của giải pháp
hệ thống. Bảng 13.1 liệt kê các loại thông số kỹ thuật sẽ được tạo ra trong quá trình
thiết kế hệ thống.
Giống như nhà ở hoặc tòa nhà, hệ thống thông tin có thể có nhiều thiết kế khả thi.
Mỗi thiết kế thể hiện sự pha trộn độc đáo giữa các thành phần kỹ thuật và tổ chức. Điều
làm cho một thiết kế vượt trội so với những thiết kế khác là tính dễ dàng và hiệu quả
mà nó đáp ứng các yêu cầu của người dùng trong một loạt các hạn chế về kỹ thuật, tổ
chức, tài chính và thời gian cụ thể.

Vai trò của người dùng cuối

Yêu cầu thông tin người dùng thúc đẩy toàn bộ nỗ lực xây dựng hệ thống. Người dùng phải
có đủ quyền kiểm soát đối với quá trình thiết kế để đảm bảo rằng hệ thống phản ánh các ưu
tiên kinh doanh và nhu cầu thông tin của họ, chứ không phải các thành kiến của nhân viên
kỹ thuật. Làm việc trên thiết kế làm tăng sự hiểu biết và chấp nhận của người dùng đối với hệ
thống. Như chúng tôi mô tả trong Chương 14, không đủ sự tham gia của người dùng
 Chương 13 Xây dựng hệ thống thông tin 525

BẢNG 13.1 THÔNG SỐ KỸ THUẬT THIẾT KẾ HỆ THỐNG

ĐẦU RA CHẾ BIẾN TÀI LIỆU

Vừa phải Tính toán Tài liệu vận hành Tài
Nội dung Mô-đun chương trình liệu hệ thống
Thời gian Báo cáo bắt buộc Tài liệu người dùng

ĐẦU VÀO Thời gian của kết quả đầu ra CHUYỂN ĐỔI
Nguồn gốc CÁC THỦ TỤC HƯỚNG DẪN Quy tắc chuyển đổi dữ liệu

lưu lượng Những hoạt động Phương pháp thử nghiệm

Nhập dư liệu Ai thực hiện chúng Chiến lược chuyển đổi

GIAO DIỆN NGƯỜI DÙNG Khi nào TẬP HUẤN

Sự đơn giản Làm sao Kỹ thuật đào tạo

Hiệu quả Ở đâu Các mô-đun đào tạo

Hợp lý ĐIỀU KHIỂN THAY ĐỔI TỔ CHỨC

Nhận xét Điều khiển đầu vào (ký tự, giới hạn, tính hợp lý) Thiết kế lại nhiệm vụ

Lỗi Điều khiển xử lý (tính nhất quán, số lượng bản Thiết kế công việc

THIẾT KẾ CƠ SỞ DỮ LIỆU ghi) Điều khiển đầu ra (tổng, mẫu đầu ra) Điều Thiết kế quy trình

Mô hình dữ liệu logic khiển thủ tục (mật khẩu, dạng đặc biệt) Thiết kế cơ cấu tổ chức
Yêu cầu về khối lượng và tốc độ Tổ BẢO VỆ Mối quan hệ báo cáo
chức và thiết kế tệp Ghi lại các Kiểm soát truy cập

thông số kỹ thuật Kế hoạch thảm họa

Các đường mòn kiểm tra

trong nỗ lực thiết kế là một nguyên nhân chính gây ra lỗi hệ thống. Tuy nhiên, một số hệ thống
yêu cầu sự tham gia của người dùng trong thiết kế nhiều hơn những hệ thống khác và Phần 13-4
cho thấy cách các phương pháp phát triển hệ thống thay thế giải quyết vấn đề tham gia của người
dùng.

Hoàn thiện Quy trình Phát triển Hệ thống

Các bước còn lại trong quá trình phát triển hệ thống chuyển các thông số kỹ thuật
của giải pháp được thiết lập trong quá trình phân tích và thiết kế hệ thống thành
một hệ thống thông tin hoạt động đầy đủ. Các bước kết thúc này bao gồm lập
trình, thử nghiệm, chuyển đổi, sản xuất và bảo trì.

Lập trình
Trong thời gian lập trình giai đoạn, các thông số kỹ thuật của hệ thống đã được
chuẩn bị trong giai đoạn thiết kế được dịch sang mã chương trình phần mềm.
Ngày nay, nhiều tổ chức không còn tự lập trình cho các hệ thống mới nữa. Thay
vào đó, họ mua phần mềm đáp ứng các yêu cầu cho một hệ thống mới từ các
nguồn bên ngoài như gói phần mềm từ nhà cung cấp phần mềm thương mại, dịch
vụ phần mềm từ nhà cung cấp dịch vụ phần mềm hoặc các công ty gia công phát
triển phần mềm ứng dụng tùy chỉnh cho khách hàng của họ (xem Phần 13 -4).

Thử nghiệm
Hết sức và kỹ lưỡng thử nghiệm phải được tiến hành để xác định chắc chắn liệu hệ thống có
tạo ra kết quả phù hợp hay không. Thử nghiệm trả lời câu hỏi "Liệu hệ thống có tạo ra kết
quả mong muốn trong các điều kiện đã biết không?" Như Chương 5 đã lưu ý, một số công ty
đang bắt đầu sử dụng các dịch vụ điện toán đám mây cho công việc này.
526 Phần bốn Xây dựng và Quản lý Hệ thống

Khoảng thời gian cần thiết để trả lời câu hỏi này theo truyền thống đã được đánh giá
thấp trong lập kế hoạch dự án hệ thống (xem Chương 14). Kiểm tra tốn nhiều thời gian:
Dữ liệu kiểm tra phải được chuẩn bị cẩn thận, xem xét kết quả và thực hiện các chỉnh
sửa trong hệ thống. Trong một số trường hợp, các bộ phận của hệ thống có thể phải
được thiết kế lại. Rủi ro do đánh bóng qua bước này là rất lớn.
Kiểm thử một hệ thống thông tin có thể được chia thành ba loại hoạt động: kiểm
thử đơn vị, kiểm thử hệ thống và kiểm thử chấp nhận. Kiểm tra đơn vị,
hoặc thử nghiệm chương trình, bao gồm thử nghiệm từng chương trình riêng biệt trong hệ
thống. Người ta tin rằng mục đích của thử nghiệm như vậy là để đảm bảo rằng các chương
trình không có lỗi, nhưng mục tiêu này trên thực tế là không thể. Thay vào đó, kiểm thử nên
được xem như một phương tiện định vị lỗi trong chương trình, tập trung vào việc tìm mọi
cách khiến chương trình bị lỗi. Khi chúng được xác định chính xác, các vấn đề có thể được
khắc phục.
Thử nghiệm hệ thống kiểm tra hoạt động của toàn bộ hệ thống thông tin. Nó cố
gắng xác định xem liệu các mô-đun rời rạc có hoạt động cùng nhau theo kế hoạch hay
không và liệu có tồn tại sự khác biệt giữa cách hệ thống thực sự hoạt động và cách nó
được hình thành hay không. Trong số các lĩnh vực được kiểm tra là thời gian hoạt động,
khả năng lưu trữ tệp và xử lý tải cao nhất, khả năng khôi phục và khởi động lại cũng
như các quy trình thủ công.
Kiểm tra chấp nhận cung cấp chứng nhận cuối cùng rằng hệ thống đã sẵn sàng để
sử dụng trong cài đặt sản xuất. Các bài kiểm tra hệ thống được người dùng đánh giá và
ban quản lý xem xét. Khi tất cả các bên hài lòng rằng hệ thống mới đáp ứng các tiêu
chuẩn của họ, hệ thống được chính thức chấp nhận để lắp đặt.
Nhóm phát triển hệ thống làm việc với người dùng để đưa ra một kế hoạch kiểm tra có hệ
thống. Cáckế hoạch kiểm tra bao gồm tất cả các bước chuẩn bị cho loạt thử nghiệm mà
chúng tôi vừa mô tả.
Hình 13.5 cho thấy một ví dụ về kế hoạch thử nghiệm. Tình trạng chung đang được
kiểm tra là một sự thay đổi kỷ lục. Tài liệu bao gồm một loạt các màn hình kế hoạch thử
nghiệm được duy trì trên cơ sở dữ liệu (có lẽ là cơ sở dữ liệu PC) phù hợp nhất với loại
ứng dụng này.

HÌNH 13.5 KẾ HOẠCH KIỂM TRA MẪU ĐỂ KIỂM TRA THAY ĐỔI BẢN GHI

Khi xây dựng một kế hoạch thử nghiệm, bắt buộc phải bao gồm các điều kiện khác nhau được thử nghiệm, các yêu
cầu đối với từng điều kiện được thử nghiệm và kết quả mong đợi. Kế hoạch kiểm tra yêu cầu đầu vào của cả người
dùng cuối và các chuyên gia hệ thống thông tin.
 Chương 13 Xây dựng hệ thống thông tin 527

Chuyển đổi
Chuyển đổi là quá trình thay đổi từ hệ thống cũ sang hệ thống mới. Bốn chiến lược
chuyển đổi chính có thể được sử dụng: chiến lược song song, chiến lược chuyển đổi
trực tiếp, chiến lược nghiên cứu thử nghiệm và chiến lược tiếp cận theo từng giai đoạn.

Trong một chiến lược song song, cả hệ thống cũ và hệ thống thay thế tiềm năng
được chạy cùng nhau trong một thời gian cho đến khi mọi người yên tâm rằng hệ
thống mới hoạt động chính xác. Đây là cách tiếp cận chuyển đổi an toàn nhất bởi vì,
trong trường hợp có lỗi hoặc gián đoạn xử lý, hệ thống cũ vẫn có thể được sử dụng làm
bản sao lưu. Tuy nhiên, cách làm này rất tốn kém và có thể cần thêm nhân viên hoặc
nguồn lực để chạy hệ thống bổ sung.
Các chiến lược cắt bỏ trực tiếp thay thế hoàn toàn hệ thống cũ bằng hệ thống
mới vào một ngày đã định. Đó là một cách tiếp cận rất rủi ro có thể tốn kém hơn so
với việc chạy hai hệ thống song song nếu phát hiện ra các vấn đề nghiêm trọng với
hệ thống mới. Không có hệ thống nào khác để quay trở lại. Sự sai lệch, gián đoạn
và chi phí sửa chữa có thể rất lớn.
Các chiến lược nghiên cứu thí điểm chỉ giới thiệu hệ thống mới cho một khu vực
giới hạn của tổ chức, chẳng hạn như một bộ phận hoặc đơn vị điều hành. Khi phiên bản
thử nghiệm này hoàn tất và hoạt động trơn tru, nó sẽ được cài đặt trong toàn bộ phần
còn lại của tổ chức, đồng thời hoặc theo từng giai đoạn.
Các chiến lược tiếp cận theo từng giai đoạn giới thiệu hệ thống mới theo từng giai
đoạn, theo chức năng hoặc theo đơn vị tổ chức. Ví dụ, nếu hệ thống được giới thiệu theo
chức năng, một hệ thống trả lương mới có thể bắt đầu với những người lao động theo giờ
được trả lương hàng tuần, sau đó sáu tháng bằng cách thêm những người làm công ăn
lương (được trả lương hàng tháng) vào hệ thống. Nếu hệ thống được giới thiệu bởi đơn vị tổ
chức, trụ sở công ty có thể được chuyển đổi đầu tiên, tiếp theo là các đơn vị vận hành bên
ngoài bốn tháng sau.
Chuyển từ hệ thống cũ sang hệ thống mới yêu cầu người dùng cuối phải được
đào tạo để sử dụng hệ thống mới. Chi tiếttài liệu hiển thị cách hệ thống hoạt động
từ cả quan điểm kỹ thuật và người dùng cuối được hoàn thiện trong thời gian
chuyển đổi để sử dụng trong đào tạo và hoạt động hàng ngày. Thiếu tài liệu và đào
tạo thích hợp góp phần dẫn đến lỗi hệ thống, vì vậy phần này của quá trình phát
triển hệ thống là rất quan trọng.

Sản xuất và Bảo trì

Sau khi hệ thống mới được cài đặt và quá trình chuyển đổi hoàn tất, hệ thống được
cho là sản xuất. Trong giai đoạn này, hệ thống sẽ được cả người dùng và chuyên
gia kỹ thuật xem xét để xác định xem hệ thống đã đáp ứng các mục tiêu ban đầu
của nó tốt như thế nào và quyết định xem có bất kỳ bản sửa đổi hoặc chỉnh sửa
nào theo thứ tự hay không. Trong một số trường hợp, mộtkiểm toán sau thực
hiện tài liệu được chuẩn bị. Sau khi hệ thống đã được tinh chỉnh, nó phải được bảo
trì trong quá trình sản xuất để sửa lỗi, đáp ứng yêu cầu hoặc nâng cao hiệu quả xử
lý. Các thay đổi về phần cứng, phần mềm, tài liệu hoặc quy trình đối với hệ thống
sản xuất để sửa lỗi, đáp ứng các yêu cầu mới hoặc cải thiện hiệu quả xử lý được coi
làbảo trì.
Khoảng 20 phần trăm thời gian dành cho bảo trì được sử dụng để gỡ lỗi hoặc
khắc phục các sự cố sản xuất khẩn cấp. 20 phần trăm khác quan tâm đến những
thay đổi trong dữ liệu, tệp, báo cáo, phần cứng hoặc phần mềm hệ thống. Nhưng
60% của tất cả các công việc bảo trì bao gồm cải tiến người dùng, cải thiện tài liệu
và mã hóa các thành phần hệ thống để có hiệu quả xử lý cao hơn. Khối lượng công
việc trong loại vấn đề bảo trì thứ ba có thể được giảm thiểu đáng kể thông qua các
hoạt động phân tích và thiết kế hệ thống tốt hơn. Bảng 13.2 tóm tắt các hoạt động
phát triển hệ thống.
528 phần bốn Xây dựng và Quản lý Hệ thống

BẢNG 13.2 PHÁT TRIỂN HỆ THỐNG

HOẠT ĐỘNG CỐT LÕI SỰ MIÊU TẢ

Phân tích hệ thống Xác định (các) vấn đề

Chỉ định các giải pháp

Thiết lập các yêu cầu thông tin

Thiết kế hệ thống Tạo thông số kỹ thuật thiết kế

Lập trình Dịch các thông số kỹ thuật thiết kế thành mã chương trình

Thử nghiệm Thực hiện kiểm tra đơn vị

Thực hiện kiểm thử hệ thống

Thực hiện kiểm thử chấp nhận

Chuyển đổi Lập kế hoạch chuyển đổi

Chuẩn bị tài liệu

Đào tạo người dùng và nhân viên kỹ thuật

Sản xuất và Vận hành hệ thống

bảo trì Đánh giá hệ thống
Sửa đổi hệ thống

13-3 Các phương pháp luận chính là gì

mô hình hóa và thiết kế hệ thống?
Có các phương pháp luận thay thế để mô hình hóa và thiết kế hệ thống. Các phương
pháp luận có cấu trúc và phát triển hướng đối tượng là những điểm nổi bật nhất.

Phương pháp luận có cấu trúc

Các phương pháp luận có cấu trúc đã được sử dụng để lập tài liệu, phân tích và thiết kế
hệ thống thông tin trong nhiều thập kỷ. Có cấu trúc đề cập đến thực tế là các kỹ thuật
được thực hiện từng bước, với mỗi bước được xây dựng dựa trên bước trước đó. Các
phương pháp luận có cấu trúc là từ trên xuống, phát triển từ cấp độ cao nhất, trừu
tượng nhất đến cấp độ chi tiết thấp nhất — từ tổng quát đến cụ thể.
Các phương pháp phát triển có cấu trúc là hướng theo quy trình, tập trung chủ yếu vào
việc mô hình hóa các quy trình hoặc các hành động nắm bắt, lưu trữ, thao tác và phân phối
dữ liệu dưới dạng luồng dữ liệu thông qua một hệ thống. Các phương pháp này tách biệt dữ
liệu khỏi các quy trình. Một quy trình lập trình riêng biệt phải được viết mỗi khi ai đó muốn
thực hiện một hành động trên một phần dữ liệu cụ thể. Các thủ tục hoạt động dựa trên dữ
liệu mà chương trình chuyển cho chúng.
Công cụ chính để biểu diễn các quy trình thành phần của hệ thống và luồng dữ
liệu giữa chúng là sơ đồ luồng dữ liệu (DFD). Sơ đồ luồng dữ liệu cung cấp một
mô hình đồ họa logic về luồng thông tin, phân chia hệ thống thành các mô-đun
hiển thị các mức độ chi tiết có thể quản lý được. Nó chỉ định một cách chặt chẽ các
quy trình hoặc biến đổi xảy ra trong mỗi mô-đun và các giao diện tồn tại giữa
chúng.
Hình 13.6 cho thấy một sơ đồ luồng dữ liệu đơn giản cho hệ thống đăng ký khóa
học đại học qua thư. Các hộp tròn đại diện cho các quá trình, mô tả sự chuyển đổi
của dữ liệu. Hộp vuông đại diện cho một thực thể bên ngoài, là người khởi tạo
hoặc người nhận thông tin nằm bên ngoài ranh giới của hệ thống đang được mô
hình hóa. Các hình chữ nhật mở đại diện cho các kho dữ liệu,
 Chương 13 Xây dựng hệ thống thông tin 529

HÌNH 13.6 SƠ ĐỒ LƯU LƯỢNG DỮ LIỆU CHO TRƯỜNG ĐẠI HỌC MAIL-IN
HỆ THỐNG ĐĂNG KÝ

Hệ thống có ba quy trình: Xác minh tính khả dụng (1.0), Ghi danh sinh viên (2.0) và Xác nhận đăng ký
(3.0). Tên và nội dung của mỗi luồng dữ liệu xuất hiện bên cạnh mỗi mũi tên. Có một thực thể bên
ngoài trong hệ thống này: sinh viên. Có hai kho dữ liệu: tệp tổng thể sinh viên và tệp khóa học.

là kiểm kê dữ liệu thủ công hoặc tự động. Các mũi tên đại diện cho các luồng dữ
liệu, hiển thị chuyển động giữa các quy trình, thực thể bên ngoài và kho dữ liệu.
Chúng chứa các gói dữ liệu với tên hoặc nội dung của từng luồng dữ liệu được liệt
kê bên cạnh mũi tên.
Sơ đồ luồng dữ liệu này cho thấy rằng sinh viên gửi phiếu đăng ký với tên của
họ, số nhận dạng của họ và số của các khóa học họ muốn tham gia. Trong quy
trình 1.0, hệ thống xác minh rằng mỗi khóa học được chọn vẫn đang mở bằng cách
tham chiếu tệp khóa học của trường đại học. Tệp phân biệt các khóa học đang mở
với những khóa học đã bị hủy hoặc lấp đầy. Quy trình 1.0 sau đó xác định lựa chọn
nào của học sinh có thể được chấp nhận hoặc bị từ chối. Quy trình 2.0 ghi danh
sinh viên vào các khóa học mà họ đã được chấp nhận. Nó cập nhật tệp khóa học
của trường đại học với tên và số nhận dạng của sinh viên và tính toán lại quy mô
lớp học. Nếu đã đạt đến số lượng đăng ký tối đa, số khóa học được gắn cờ là đã
đóng. Quy trình 2. 0 cũng cập nhật hồ sơ sinh viên thạc sĩ của trường đại học với
thông tin về sinh viên mới hoặc thay đổi địa chỉ. Quy trình 3.0 sau đó sẽ gửi cho
mỗi sinh viên đăng ký thư xác nhận danh sách các khóa học mà họ đã đăng ký và
lưu ý các lựa chọn khóa học không thể hoàn thành.

Các sơ đồ có thể được sử dụng để mô tả các quy trình cấp cao hơn cũng như các chi
tiết cấp thấp hơn. Thông qua sơ đồ luồng dữ liệu được cấp, một quy trình phức tạp có
thể được chia nhỏ thành các cấp chi tiết liên tiếp. Toàn bộ hệ thống có thể được chia
thành các hệ thống con với sơ đồ luồng dữ liệu mức cao. Đến lượt mình, mỗi hệ thống
con có thể được chia thành các hệ thống con bổ sung với sơ đồ luồng dữ liệu cấp hai, và
các hệ thống con cấp thấp hơn có thể được chia nhỏ lại cho đến khi đạt đến mức chi tiết
thấp nhất.
Một công cụ khác để phân tích có cấu trúc là từ điển dữ liệu, chứa thông tin về
các phần dữ liệu riêng lẻ và các nhóm dữ liệu trong một hệ thống (xem Chương 6).
Từ điển dữ liệu xác định nội dung của luồng dữ liệu
530 Phần bốn Xây dựng và Quản lý Hệ thống

và lưu trữ dữ liệu để những người xây dựng hệ thống hiểu chính xác chúng chứa
những phần dữ liệu nào. Quy trình kỹ thuật mô tả sự chuyển đổi xảy ra trong
mức thấp nhất của sơ đồ luồng dữ liệu. Chúng thể hiện logic cho mỗi quá trình.

Trong phương pháp luận có cấu trúc, thiết kế phần mềm được mô hình hóa bằng cách sử dụng
các biểu đồ cấu trúc phân cấp. Cácbiểu đồ cấu trúc là biểu đồ từ trên xuống, hiển thị từng cấp độ
thiết kế, mối quan hệ của nó với các cấp độ khác và vị trí của nó trong cấu trúc thiết kế tổng thể.
Đầu tiên, thiết kế xem xét chức năng chính của một chương trình hoặc hệ thống, sau đó chia chức
năng này thành các chức năng con và phân tách từng chức năng con cho đến khi đạt đến mức chi
tiết thấp nhất. Hình 13.7 cho thấy một biểu đồ cấu trúc cấp cao cho một hệ thống trả lương. Nếu
một thiết kế có quá nhiều cấp độ để phù hợp với một biểu đồ cấu trúc, nó có thể được chia nhỏ
hơn nữa trên các biểu đồ cấu trúc chi tiết hơn. Biểu đồ cấu trúc có thể ghi lại một chương trình,
một hệ thống (một tập hợp các chương trình) hoặc một phần của một chương trình.

Phát triển hướng đối tượng

Các phương pháp có cấu trúc rất hữu ích cho việc mô hình hóa các quy trình nhưng không
xử lý tốt việc mô hình hóa dữ liệu. Họ cũng coi dữ liệu và quy trình như các thực thể tách biệt
một cách hợp lý, trong khi trong thế giới thực sự tách biệt như vậy có vẻ không tự nhiên. Các
quy ước mô hình hóa khác nhau được sử dụng để phân tích (sơ đồ luồng dữ liệu) và thiết kế
(biểu đồ cấu trúc).
Phát triển hướng đối tượng giải quyết những vấn đề này. Phát triển hướng đối tượng
sử dụngsự vật là đơn vị cơ bản của phân tích và thiết kế hệ thống. Một đối tượng kết hợp dữ
liệu và các quy trình cụ thể hoạt động trên dữ liệu đó. Dữ liệu được đóng gói trong một đối
tượng chỉ có thể được truy cập và sửa đổi bởi các phép toán hoặc phương thức được liên kết
với đối tượng đó. Thay vì truyền dữ liệu cho các thủ tục, các chương trình sẽ gửi một thông
báo cho một đối tượng để thực hiện một hoạt động đã được nhúng trong đó. Hệ thống được
mô hình hóa như một tập hợp các đối tượng và các mối quan hệ giữa chúng. Bởi vì logic xử lý
nằm trong các đối tượng chứ không phải trong các chương trình phần mềm riêng biệt, các
đối tượng phải cộng tác với nhau để làm cho hệ thống hoạt động.

Mô hình hướng đối tượng dựa trên các khái niệm về lớp học và di sản.
Các đối tượng thuộc một lớp nhất định, hoặc phạm trù chung của các đối tượng tương
tự, có các tính năng của lớp đó. Đến lượt mình, các lớp đối tượng có thể kế thừa tất cả
cấu trúc và hành vi của một lớp tổng quát hơn và sau đó thêm các biến và hành vi duy
nhất cho từng đối tượng. Các lớp đối tượng mới được tạo bằng cách chọn một

HÌNH 13.7 BIỂU ĐỒ CẤU TRÚC CẤP CAO CHO HỆ THỐNG THANH TOÁN

Biểu đồ cấu trúc này cho thấy mức độ thiết kế cao nhất hoặc trừu tượng nhất của hệ thống tính lương, cung cấp cái nhìn tổng quan về toàn
bộ hệ thống.
 Chương 13 Xây dựng hệ thống thông tin 531

lớp hiện có và chỉ định cách lớp mới khác với lớp hiện có thay vì bắt đầu lại từ đầu
mỗi lần.
Chúng ta có thể thấy lớp và kế thừa hoạt động như thế nào trong Hình 13.8,
minh họa mối quan hệ giữa các lớp liên quan đến nhân viên và cách họ được trả
lương. Nhân viên là tổ tiên chung, hoặc lớp cha, cho ba lớp còn lại. Được trả lương,
Theo giờ và Tạm thời là các cấp bậc phụ của Nhân viên. Tên lớp nằm trong ngăn
trên cùng, các thuộc tính cho mỗi lớp nằm ở phần giữa của mỗi hộp và danh sách
các thao tác nằm ở phần dưới cùng của mỗi hộp. Các tính năng được chia sẻ bởi tất
cả nhân viên (ID, tên, địa chỉ, ngày thuê, vị trí và lương) được lưu trữ trong lớp
nhân viên, trong khi mỗi lớp con lưu trữ các tính năng dành riêng cho loại nhân
viên cụ thể đó. Ví dụ, cụ thể đối với nhân viên làm việc theo giờ là tỷ lệ theo giờ và
tỷ lệ làm thêm giờ của họ.

Phát triển hướng đối tượng lặp đi lặp lại và gia tăng hơn so với phát triển có cấu trúc
truyền thống. Trong quá trình phân tích, người xây dựng hệ thống ghi lại các yêu cầu
chức năng của hệ thống, chỉ rõ các thuộc tính quan trọng nhất của nó và những gì hệ
thống được đề xuất phải làm. Tương tác giữa hệ thống và người dùng được phân tích
để xác định các đối tượng, bao gồm cả dữ liệu và quy trình. Giai đoạn thiết kế hướng
đối tượng mô tả các đối tượng sẽ hoạt động như thế nào và chúng sẽ tương tác với
nhau như thế nào. Các đối tượng tương tự được nhóm lại với nhau để tạo thành một
lớp và các lớp được nhóm thành các cấu trúc phân cấp trong đó một lớp con kế thừa các
thuộc tính và phương thức từ lớp cha của nó.
Hệ thống thông tin được thực hiện bằng cách dịch thiết kế sang mã chương
trình, sử dụng lại các lớp đã có sẵn trong thư viện các đối tượng phần mềm có thể
tái sử dụng và thêm các lớp mới được tạo trong giai đoạn thiết kế hướng đối
tượng. Việc triển khai cũng có thể liên quan đến việc tạo cơ sở dữ liệu hướng đối
tượng. Hệ thống kết quả phải được kiểm tra và đánh giá kỹ lưỡng.

HÌNH 13.8 LỚP HỌC VÀ HẠN CHẾ

Hình này minh họa cách các lớp kế thừa các đặc điểm chung của lớp cha của chúng.
532 Phần bốn Xây dựng và Quản lý Hệ thống

Bởi vì các đối tượng có thể tái sử dụng, phát triển hướng đối tượng có khả năng làm
giảm thời gian và chi phí viết phần mềm vì các tổ chức có thể sử dụng lại các đối tượng
phần mềm đã được tạo làm khối xây dựng cho các ứng dụng khác. Hệ thống mới có thể
được tạo ra bằng cách sử dụng một số đối tượng hiện có, thay đổi những đối tượng
khác và thêm một vài đối tượng mới. Các khuôn khổ hướng đối tượng đã được phát
triển để cung cấp các ứng dụng bán hoàn chỉnh, có thể tái sử dụng mà tổ chức có thể
tùy chỉnh thêm thành các ứng dụng đã hoàn thiện.

Kỹ thuật phần mềm có sự hỗ trợ của máy tính

Kỹ thuật phần mềm hỗ trợ máy tính (CASE)—Đôi khi được gọi kỹ thuật hệ thống vi tính—
Cung cấp các công cụ phần mềm để tự động hóa các phương pháp luận mà chúng tôi vừa
mô tả nhằm giảm số lượng công việc lặp đi lặp lại mà nhà phát triển cần thực hiện. Các công
cụ CASE cũng tạo điều kiện thuận lợi cho việc tạo tài liệu rõ ràng và phối hợp các nỗ lực phát
triển nhóm. Các thành viên trong nhóm có thể chia sẻ công việc của họ một cách dễ dàng
bằng cách truy cập các tệp của nhau để xem xét hoặc sửa đổi những gì đã được thực hiện.
Lợi ích năng suất khiêm tốn cũng có thể đạt được nếu các công cụ được sử dụng đúng cách.

Các công cụ CASE cung cấp các phương tiện đồ họa tự động để tạo biểu đồ và sơ
đồ, trình tạo màn hình và báo cáo, từ điển dữ liệu, phương tiện báo cáo mở rộng,
công cụ phân tích và kiểm tra, trình tạo mã và trình tạo tài liệu. Nói chung, các
công cụ CASE cố gắng tăng năng suất và chất lượng bằng cách:
• Thực thi phương pháp luận phát triển tiêu chuẩn và kỷ luật thiết kế
• Cải thiện giao tiếp giữa người dùng và các chuyên gia kỹ thuật
• Tổ chức và tương quan các thành phần thiết kế và cung cấp quyền truy cập nhanh chóng vào
chúng bằng cách sử dụng kho thiết kế

• Tự động hóa các phần phân tích và thiết kế tẻ nhạt và dễ xảy ra lỗi
• Tự động tạo mã và thử nghiệm cũng như kiểm soát triển khai

Các công cụ CASE chứa các tính năng để xác nhận các sơ đồ và thông số kỹ thuật thiết kế.
Do đó, các công cụ CASE hỗ trợ thiết kế lặp lại bằng cách tự động hóa các bản sửa đổi và thay
đổi và cung cấp các phương tiện tạo mẫu. Kho lưu trữ thông tin CASE lưu trữ tất cả thông tin
được xác định bởi các nhà phân tích trong quá trình dự án. Kho lưu trữ bao gồm sơ đồ luồng
dữ liệu, biểu đồ cấu trúc, sơ đồ mối quan hệ thực thể, định nghĩa dữ liệu, thông số kỹ thuật
quy trình, định dạng màn hình và báo cáo, ghi chú và nhận xét cũng như kết quả kiểm tra.

Để được sử dụng một cách hiệu quả, các công cụ CASE đòi hỏi tính kỷ luật của tổ
chức. Mọi thành viên của một dự án phát triển phải tuân thủ một bộ tiêu chuẩn và quy
ước đặt tên chung cũng như phương pháp luận phát triển. Các công cụ CASE tốt nhất
thực thi các phương pháp và tiêu chuẩn chung, có thể không khuyến khích việc sử dụng
chúng trong các tình huống thiếu kỷ luật của tổ chức.

13-4 Các phương pháp thay thế để xây dựng là gì

hệ thông thông tin?
Các hệ thống khác nhau về quy mô và độ phức tạp về công nghệ cũng như về các
vấn đề tổ chức mà chúng phải giải quyết. Một số phương pháp xây dựng hệ thống
đã được phát triển để đối phó với những khác biệt này. Phần này mô tả các phương
pháp thay thế này: vòng đời của hệ thống truyền thống, tạo mẫu, gói phần mềm
ứng dụng, phát triển người dùng cuối và thuê ngoài.
 Chương 13 Xây dựng hệ thống thông tin 533

Vòng đời của hệ thống truyền thống

Các vòng đời hệ thống là phương pháp lâu đời nhất để xây dựng hệ thống thông tin.
Phương pháp luận vòng đời là một cách tiếp cận theo từng giai đoạn để xây dựng một hệ
thống, chia sự phát triển hệ thống thành các giai đoạn chính thức, như được minh họa trong
Hình 13.9. Các chuyên gia phát triển hệ thống có các ý kiến khác nhau về cách phân vùng
các giai đoạn xây dựng hệ thống, nhưng chúng gần như tương ứng với các giai đoạn phát
triển hệ thống mà chúng tôi vừa mô tả.
Phương pháp luận vòng đời của hệ thống duy trì sự phân công lao động chính thức
giữa người dùng cuối và các chuyên gia hệ thống thông tin. Các chuyên gia kỹ thuật,
chẳng hạn như nhà phân tích hệ thống và lập trình viên, chịu trách nhiệm về phần lớn
công việc phân tích, thiết kế và triển khai hệ thống; người dùng cuối bị giới hạn trong
việc cung cấp các yêu cầu thông tin và xem xét công việc của nhân viên kỹ thuật. Vòng
đời cũng nhấn mạnh đến các thông số kỹ thuật chính thức và thủ tục giấy tờ, vì vậy
nhiều tài liệu được tạo ra trong quá trình của một dự án hệ thống.

Vòng đời của hệ thống vẫn được sử dụng để xây dựng các hệ thống phức tạp
lớn đòi hỏi phân tích các yêu cầu chính thức và nghiêm ngặt, các thông số kỹ thuật
được xác định trước và các kiểm soát chặt chẽ đối với quá trình xây dựng hệ thống.
Tuy nhiên, cách tiếp cận vòng đời của hệ thống có thể tốn kém, mất thời gian và
không linh hoạt. Mặc dù người xây dựng hệ thống có thể qua lại giữa các giai đoạn
trong vòng đời, vòng đời của hệ thống chủ yếu là cách tiếp cận “thác nước” trong
đó các nhiệm vụ trong một giai đoạn được hoàn thành trước khi công việc cho giai
đoạn tiếp theo bắt đầu. Các hoạt động có thể được lặp lại, nhưng khối lượng tài
liệu mới phải được tạo ra và các bước được thực hiện lại nếu các yêu cầu và thông
số kỹ thuật cần được sửa đổi. Điều này khuyến khích việc đóng băng các thông số
kỹ thuật tương đối sớm trong quá trình phát triển. Cách tiếp cận vòng đời cũng
không phù hợp với nhiều hệ thống máy tính để bàn nhỏ,

HÌNH 13,9 CHU KỲ SỐNG PHÁT TRIỂN CỦA CÁC HỆ THỐNG TRUYỀN THỐNG

Vòng đời phát triển hệ thống phân chia sự phát triển hệ thống thành các giai đoạn chính thức, với mỗi giai đoạn yêu cầu
hoàn thành trước khi giai đoạn tiếp theo có thể bắt đầu.
534 Phần bốn Xây dựng và Quản lý Hệ thống

Tạo mẫu
Tạo mẫu bao gồm việc xây dựng một hệ thống thử nghiệm nhanh chóng và không tốn kém
để người dùng cuối đánh giá. Bằng cách tương tác với nguyên mẫu, người dùng có thể hiểu
rõ hơn về các yêu cầu thông tin của họ. Nguyên mẫu được người dùng xác nhận có thể được
sử dụng làm mẫu để tạo ra hệ thống cuối cùng.
Các nguyên mẫu là một phiên bản làm việc của một hệ thống thông tin hoặc một phần
của hệ thống, nhưng nó chỉ là một mô hình sơ bộ. Sau khi hoạt động, nguyên mẫu sẽ được
hoàn thiện thêm cho đến khi nó phù hợp chính xác với yêu cầu của người dùng. Khi thiết kế
đã được hoàn thiện, nguyên mẫu có thể được chuyển đổi sang hệ thống sản xuất đã được
đánh bóng.
Quá trình xây dựng một thiết kế sơ bộ, dùng thử, tinh chỉnh và thử lại được gọi
là lặp đi lặp lại quá trình phát triển hệ thống bởi vì các bước cần thiết để xây dựng
một hệ thống có thể được lặp đi lặp lại nhiều lần. Prototyping lặp đi lặp lại rõ ràng
hơn so với vòng đời thông thường và nó tích cực thúc đẩy các thay đổi thiết kế hệ
thống. Người ta nói rằng việc tạo mẫu thay thế việc làm lại ngoài kế hoạch bằng
việc lặp lại theo kế hoạch, với mỗi phiên bản phản ánh chính xác hơn yêu cầu của
người dùng.

Các bước trong tạo mẫu

Hình 13.10 mô tả một mô hình bốn bước của quá trình tạo mẫu, bao gồm những
điều sau:

Bước 1: Xác định các yêu cầu cơ bản của người dùng. Nhà thiết kế hệ thống (thường là
chuyên gia hệ thống thông tin) chỉ làm việc với người dùng đủ lâu để nắm bắt
nhu cầu thông tin cơ bản của người dùng.

HÌNH 13.10 QUÁ TRÌNH TIẾN HÓA

Quá trình phát triển một nguyên mẫu có thể được chia thành bốn bước. Bởi vì một nguyên mẫu có thể được phát triển
nhanh chóng và không tốn kém, các nhà xây dựng hệ thống có thể trải qua một số lần lặp lại, lặp lại các bước 3 và 4, để
tinh chỉnh và cải tiến nguyên mẫu trước khi đến với nguyên mẫu hoạt động cuối cùng.
 Chương 13 Xây dựng hệ thống thông tin 535

Bước 2: Phát triển một nguyên mẫu ban đầu. Nhà thiết kế hệ thống tạo ra một
nhanh chóng tạo nguyên mẫu, sử dụng các công cụ để tạo phần mềm nhanh chóng.

Bước 3: Sử dụng nguyên mẫu. Người dùng được khuyến khích làm việc với hệ thống để
xác định mức độ đáp ứng của nguyên mẫu và đưa ra các đề xuất để cải
tiến nguyên mẫu.
Bước 4: Chỉnh sửa và nâng cao nguyên mẫu. Người xây dựng hệ thống ghi chú tất cả các thay đổi
người dùng yêu cầu và tinh chỉnh nguyên mẫu cho phù hợp. Sau khi nguyên
mẫu đã được sửa đổi, chu trình quay trở lại Bước 3. Bước 3 và 4 được lặp lại
cho đến khi người dùng hài lòng.

Khi không cần lặp lại nữa, nguyên mẫu đã được phê duyệt sau đó sẽ trở thành
nguyên mẫu hoạt động cung cấp các thông số kỹ thuật cuối cùng cho ứng dụng.
Đôi khi nguyên mẫu được sử dụng làm phiên bản sản xuất của hệ thống.

Ưu điểm và nhược điểm của tạo mẫu

Tạo mẫu hữu ích nhất khi có một số không chắc chắn về các yêu cầu hoặc giải pháp
thiết kế và thường được sử dụng để thiết kế hệ thống thông tin
giao diện người dùng cuối (phần của hệ thống mà người dùng cuối tương tác, chẳng hạn
như màn hình hiển thị trực tuyến và màn hình nhập dữ liệu, báo cáo hoặc trang web). Bởi vì
tạo mẫu khuyến khích sự tham gia mạnh mẽ của người dùng cuối trong suốt vòng đời phát
triển hệ thống, nên có nhiều khả năng tạo ra các hệ thống đáp ứng các yêu cầu của người
dùng.
Tuy nhiên, tạo mẫu nhanh có thể làm mờ đi các bước thiết yếu trong phát triển hệ
thống. Nếu nguyên mẫu đã hoàn thành hoạt động tốt một cách hợp lý, ban quản lý có
thể không thấy cần thiết phải lập trình lại, thiết kế lại hoặc tài liệu đầy đủ và thử nghiệm
để xây dựng một hệ thống sản xuất hoàn thiện. Một số hệ thống được xây dựng vội vã
này có thể không dễ dàng chứa được lượng lớn dữ liệu hoặc số lượng lớn người dùng
trong môi trường sản xuất.

Phát triển người dùng cuối

Phát triển người dùng cuối cho phép người dùng cuối, với ít hoặc không cần hỗ trợ chính
thức từ các chuyên gia kỹ thuật, tạo ra các hệ thống thông tin đơn giản, giảm thời gian và các
bước cần thiết để tạo ra một ứng dụng hoàn chỉnh. Sử dụng ngôn ngữ truy vấn thân thiện
với người dùng và các công cụ báo cáo, phát triển trang web, đồ họa và phần mềm PC, người
dùng cuối có thể truy cập dữ liệu, tạo báo cáo và tự phát triển các ứng dụng đơn giản mà
không cần sự trợ giúp của các nhà phân tích hoặc lập trình hệ thống chuyên nghiệp. MỘT
ngôn ngữ truy vấn là một công cụ phần mềm cung cấp câu trả lời trực tuyến ngay lập tức
cho các câu hỏi chưa được xác định trước, chẳng hạn như "Ai là đại diện bán hàng có hiệu
suất cao nhất?" Các ngôn ngữ truy vấn thường gắn liền với phần mềm quản lý dữ liệu (xem
Chương 6).
Ví dụ: Yellow Pages (YP), một công ty giải pháp tiếp thị và truyền thông kỹ thuật số
phục vụ 260.000 doanh nghiệp vừa và nhỏ của Canada, đã sử dụng WebFOCUS của
Information Builders để xây dựng một ứng dụng phân tích thân thiện với người dùng
giúp khách hàng đo lường lợi tức trên số tiền quảng cáo của họ và theo dõi thành công
của các chiến dịch của họ. Hệ thống, được gọi là YP Analytics, có trang tổng quan thân
thiện với người dùng để theo dõi các tương tác và đo lường các chỉ số hiệu suất chính
tập trung vào ROI và doanh thu. Người dùng YP Analytics có thể theo dõi các chỉ số
quan trọng như khách truy cập, lượt truy cập, lượt xem trang và tương tác / nhấp chuột
cũng như cuộc gọi, lượt đi bộ tại cửa hàng, địa chỉ liên hệ kỹ thuật số và các chỉ số hiệu
suất khác và họ có thể tùy chỉnh kết quả đầu ra mà họ muốn (Thông tin Người xây
dựng, 2015).
536 Phần bốn Xây dựng và Quản lý Hệ thống

Nhìn chung, các hệ thống do người dùng cuối phát triển có thể được hoàn thiện nhanh
hơn so với các hệ thống được phát triển thông qua vòng đời của hệ thống thông thường.
Việc cho phép người dùng xác định nhu cầu kinh doanh của riêng họ cải thiện việc thu thập
yêu cầu và thường dẫn đến mức độ tham gia và sự hài lòng của người dùng đối với hệ thống
cao hơn. Tuy nhiên, các công cụ phần mềm dành cho người dùng cuối vẫn không thể thay
thế các công cụ thông thường cho một số ứng dụng kinh doanh vì chúng không thể dễ dàng
xử lý số lượng lớn các giao dịch hoặc ứng dụng với các yêu cầu cập nhật và logic thủ tục rộng
rãi.
Tính toán của người dùng cuối cũng gây ra rủi ro cho tổ chức vì nó xảy ra bên ngoài
các cơ chế quản lý và kiểm soát hệ thống thông tin truyền thống. Khi các hệ thống được
tạo ra nhanh chóng mà không có phương pháp phát triển chính thức, việc kiểm tra và
tài liệu có thể không đủ. Kiểm soát dữ liệu có thể bị mất trong các hệ thống bên ngoài
bộ phận hệ thống thông tin truyền thống. Để giúp các tổ chức tối đa hóa lợi ích của việc
phát triển ứng dụng người dùng cuối, ban quản lý nên kiểm soát sự phát triển của các
ứng dụng người dùng cuối bằng cách yêu cầu biện minh chi phí cho các dự án hệ thống
thông tin người dùng cuối và bằng cách thiết lập các tiêu chuẩn phần cứng, phần mềm
và chất lượng cho các ứng dụng do người dùng phát triển.

Gói Phần mềm Ứng dụng, Dịch vụ Phần mềm và Gia

công phần mềm
Chương 5 chỉ ra rằng phần lớn phần mềm ngày nay không được phát triển nội bộ mà
được mua từ các nguồn bên ngoài. Các công ty có thể thuê phần mềm từ một nhà cung
cấp dịch vụ phần mềm trực tuyến, họ có thể mua phần mềm từ một nhà cung cấp
thương mại dưới dạng gói để chạy trong nhà hoặc họ có thể có một ứng dụng tùy chỉnh
do một công ty gia công bên ngoài phát triển.

Gói phần mềm ứng dụng và Dịch vụ phần mềm đám mây
Ngày nay, nhiều hệ thống dựa trên các gói phần mềm ứng dụng thương mại có
sẵn hoặc phần mềm đám mây như một dịch vụ (SaaS). Ví dụ: các công ty có thể
chọn thực hiện lập kế hoạch nguồn lực doanh nghiệp, quản lý chuỗi cung ứng hoặc
phần mềm quản lý nguồn nhân lực nội bộ của Oracle hoặc trả tiền để sử dụng
phần mềm này chạy trên nền tảng Đám mây Oracle. Phần mềm năng suất dành
cho máy tính để bàn của Microsoft Office có cả phiên bản dành cho máy tính để
bàn và đám mây (Office 365). Nhiều ứng dụng phổ biến cho tất cả các tổ chức kinh
doanh — ví dụ: bảng lương, tài khoản phải thu, sổ cái chung hoặc kiểm soát hàng
tồn kho. Đối với các chức năng phổ quát như vậy với các quy trình tiêu chuẩn
không thay đổi nhiều theo thời gian, một hệ thống chung hơn sẽ đáp ứng các yêu
cầu của nhiều tổ chức.
Nếu một gói phần mềm thương mại hoặc dịch vụ phần mềm đám mây có thể
đáp ứng hầu hết các yêu cầu của tổ chức, thì công ty không phải viết phần mềm
của riêng mình (xem Phiên tương tác về tổ chức). Công ty có thể tiết kiệm thời gian
và tiền bạc bằng cách sử dụng các chương trình phần mềm được viết trước, thiết
kế trước, đã được kiểm tra trước từ nhà cung cấp phần mềm. Các nhà cung cấp Gói
và SaaS cung cấp phần lớn bảo trì và hỗ trợ liên tục cho hệ thống, bao gồm các cải
tiến để giữ cho hệ thống phù hợp với các phát triển kinh doanh và kỹ thuật đang
diễn ra. Khi một gói hoặc giải pháp SaaS được theo đuổi, người dùng cuối sẽ chịu
trách nhiệm cung cấp các yêu cầu thông tin nghiệp vụ cho hệ thống và các chuyên
gia hệ thống thông tin sẽ cung cấp các yêu cầu kỹ thuật.

PHẦN TƯƠNG TÁC: CÁC TỔ CHỨC
Fujitsu chọn giải pháp SaaS để đơn giản hóa quy trình bán hàng
Nếu bạn lướt web, phát video trên điện thoại hoặc xem
truyền hình cáp ở Bắc Mỹ, thiết bị của Fujitsu Network
Communications rất có thể giúp bạn kết nối. Fujitsu
Network Communications Inc., có trụ sở tại Richardson,
Texas, cung cấp thiết bị mạng quang học và không dây,
bao gồm máy chủ, sản phẩm lưu trữ, thiết bị máy tính
khách, máy quét, máy in và màn hình. Đây là công ty có
bằng sáng chế hàng đầu trong lĩnh vực mạng quang
học.
Thiết bị mạng Fujitsu cung cấp các giải pháp vận
chuyển quang học cho các hãng viễn thông lớn trên
khắp Bắc Mỹ. Có hơn 450.000 phần tử mạng Fujitsu,
bao gồm các giá đỡ và thẻ chứa phần cứng kết nối,
thiết lập tín hiệu và định tuyến cũng như cung cấp
quản lý. Nhiều sản phẩm của công ty chứa hàng
nghìn bộ phận và vô số tình huống cấu hình. Ví dụ:
một sản phẩm duy nhất có thể được định giá khác
nhau cho 600 khách hàng riêng biệt vì giá được xác
định bởi cấu hình riêng của khách hàng liên quan đến
các trang web mạng, vị trí địa lý và khoảng cách giữa
các trang web. Ngoài ra, mỗi trang web khác nhau
trong một mạng liên quan đến vô số cấu hình thiết
lập liên quan đến cấp nguồn, ghi nhãn và các quy tắc
giao tiếp. Chỉ cần nghĩ rằng quá trình cấu hình, định
giá,
Trong nhiều năm, các đội bán hàng của Fujitsu đã
gặp khó khăn khi xử lý tất cả sự phức tạp này trong quy
trình bán hàng và đặt hàng. Họ phải sử dụng các bảng
tính riêng lẻ để định cấu hình, định giá và báo giá các
giải pháp (CPQ) cho khách hàng của họ. Công ty không
có kho lưu trữ tập trung cho báo giá, hồ sơ chào hàng
hoặc khả năng tích hợp báo giá với quy trình đặt hàng.
Mặc dù Fujitsu đã có một hệ thống ERP để duy trì dữ liệu
tổng thể về giá cả và nguyên vật liệu trên toàn doanh
nghiệp, quy trình CPQ vẫn mất nhiều ngày và dẫn đến
lỗi báo giá và vô số giờ chỉnh sửa và làm lại.
Một giải pháp hệ thống đã được đặt hàng. Dave
Hawkins, Phó Giám đốc Kỹ thuật Bán hàng, Hoạt
động Bán hàng và Quản lý Thương mại của Fujitsu,
và nhóm của ông đã đưa ra yêu cầu đề xuất (RFP)
cho một giải pháp có thể tạo báo giá nhanh chóng và
giảm lỗi báo giá và làm lại. Các yêu cầu quan trọng
nhất là khả năng tập trung và kiểm soát tất cả các
báo giá đang diễn ra, đảm bảo chính xác
Chương 13 Xây dựng hệ thống thông tin 537
định giá và đảm bảo rằng tất cả các bộ phận đang được định cấu
hình đều có sẵn.
Một quá trình lựa chọn nghiêm ngặt đã xác định phần
mềm của FPX là giải pháp báo giá CPQ dịch vụ (SaaS) là sự lựa
chọn tốt nhất. FPX là nhà cung cấp hàng đầu về phần mềm
định cấu hình-báo giá (CPQ) dựa trên đám mây và là đối tác
Nhà cung cấp phần mềm độc lập SAP (ISV) được chứng nhận.
Chỉ có giải pháp FPX mới có khả năng tích hợp với phần mềm
dự báo và quản lý khách hàng tiềm năng phía trước Salesforce
của Fujitsu cũng như với dữ liệu từ hệ thống ERP phía sau của
công ty — và nó chạy trên nền tảng điện toán đám mây.
FPX CPQ tự động định cấu hình tất cả các đơn hàng bán
hàng, ngay cả khi chúng dựa trên các quy tắc kinh doanh cực
kỳ phức tạp. Phần mềm xác nhận tất cả các lựa chọn sản phẩm
và dịch vụ để loại bỏ việc làm lại tốn kém và giúp duy trì tỷ suất
lợi nhuận bằng cách yêu cầu phê duyệt các khoản chiết khấu
vượt quá mức đã được phê duyệt trước.
Đối với Fujitsu, FPX CPQ tự động hóa tất cả các quy tắc và
yêu cầu về giá cả phức tạp của công ty và tích hợp chúng
trong thời gian gần như thực với hệ thống báo giá để các báo
giá và đơn đặt hàng có thể nắm bắt ngay lập tức bất kỳ thay
đổi nào đối với dữ liệu tổng thể về sản phẩm và vật liệu. Việc
tính toán mức giá từng khiến đội bán hàng của Fujitsu mất
nhiều ngày để tính toán giờ chỉ mất vài giây. Và bằng cách tập
trung thông tin này, người ta không cần phải nghiền ngẫm
từng bảng tính để xem việc định giá đang được thực hiện như
thế nào. Khi một thay đổi được thực hiện, nó không còn bị
chôn vùi trong một hoặc một số bảng tính được duy trì bởi các
nhân viên bán hàng riêng lẻ.
FPX CPQ cũng có thể tự động nhận ra các cơ hội
bổ sung dựa trên việc thay đổi vị trí của sản phẩm ở
một vị trí cụ thể. Tính năng này giúp loại bỏ quy trình
thủ công rườm rà trong việc kiểm tra chéo cấu hình
so với danh sách khuyến mại và loại bỏ nhu cầu
nhượng bộ sau bán hàng cho những khách hàng ban
đầu không nhận được tùy chọn chi phí thấp nhất.
Trong vòng sáu tháng kể từ khi thực hiện FPX CPQ,
Fujitsu đã đạt được lợi ích kinh doanh. Một nền tảng
dựa trên đám mây duy nhất cho CPQ đã thay thế
nhiều hệ thống trích dẫn để định cấu hình các nền
tảng mạng đa giá và đa khe. Sai sót về giá đã giảm
80%, do đó làm giảm đáng kể việc làm lại và ghi giảm
(giảm giá trị của một tài sản). Tổng thời gian chu kỳ
(tổng thời gian từ đầu đến cuối của một quy trình)
cũng giảm. Hơn thế nữa,
538 Phần bốn Xây dựng và Quản lý Hệ thống

giúp bạn có thể xem thêm thông tin quan trọng về
bán hàng, dịch vụ và những gì khách hàng đang
yêu cầu.
Mỗi khi có thay đổi, chẳng hạn như giá mới, sản phẩm
mới có sẵn hoặc thay đổi trong mô tả sản phẩm, tất cả
người dùng đều có thể thấy sự thay đổi đó ngay khi truy
cập vào hệ thống và xem báo giá của chúng. Nếu một báo
giá đang trong quá trình tạo, Fujitsu cũng có thể cập nhật
báo giá đó với những thay đổi như vậy. Người dùng cuối có
thể ra ngoài thực địa với khách hàng và cho họ xem các
giải pháp trực quan theo thời gian thực, thực hiện các thay
đổi đối với cấu hình và ngay lập tức có được mức giá chính
xác đến từng phút.
Hệ thống CPQ mới cho phép Fujitsu hợp lý hóa
quy trình bán hàng bằng cách đặt một phần đáng kể
dữ liệu sản phẩm và các quy tắc cấu hình trực tiếp
vào ứng dụng báo giá. Nhóm bán hàng có thể hoạt
động độc lập hơn và tập trung vào việc bán hàng.
Nguồn: Ken Murphy, “Fujitsu Untangle Sales Complexities,” SAP Insider
Profiles, ngày 6 tháng 7 năm 2015; “FPX: Nền tảng ứng dụng duy nhất để quản
lý đa kênh,” cioreview.com, truy cập ngày 20 tháng 2 năm 2016; www.fpx.com,
truy cập ngày 20 tháng 2 năm 2016; và www.fujitsu. com, truy cập ngày 20
tháng 2 năm 2016.

CÂU HỎI NGHIÊN CỨU TÌNH HUỐNG

1. Fujitsu gặp vấn đề gì với các hệ thống hiện có cho
quy trình CPQ? Tác động kinh doanh của những
vấn đề này là gì?
2. Liệt kê và mô tả các yêu cầu thông tin quan trọng
nhất mà bạn mong đợi thấy trong RFP của Fujitsu.
4. Tại sao phần mềm như một dịch vụ lại là một giải pháp thích
hợp cho Fujitsu? Fujitsu có nên xây dựng hệ thống CPQ nội
bộ của riêng mình không?
5. FPX CPQ đã thay đổi bao nhiêu phần trăm cách Fujitsu điều hành hoạt động
kinh doanh của mình?

3. Tại sao giải pháp CPQ FPX được chọn? Đó có phải là một lựa
chọn tốt? Tại sao hoặc tại sao không?

Nếu một tổ chức có các yêu cầu duy nhất mà gói đó không giải quyết, thì nhiều
gói bao gồm các khả năng tùy chỉnh. Tùy biến các tính năng cho phép một gói
phần mềm thương mại hoặc phần mềm dựa trên đám mây được sửa đổi để đáp
ứng các yêu cầu riêng của tổ chức mà không phá hủy tính toàn vẹn của phần mềm.
Nếu yêu cầu nhiều tùy chỉnh, công việc lập trình và tùy chỉnh bổ sung có thể trở
nên tốn kém và tốn thời gian đến mức chúng phủ nhận nhiều ưu điểm của các gói
và dịch vụ phần mềm.
Khi một hệ thống được phát triển bằng cách sử dụng gói phần mềm ứng dụng
hoặc dịch vụ phần mềm đám mây, việc phân tích hệ thống sẽ bao gồm việc đánh
giá chính thức gói phần mềm hoặc dịch vụ mà cả người dùng cuối và các chuyên
gia hệ thống thông tin sẽ tham gia. Tiêu chí đánh giá quan trọng nhất là các chức
năng được cung cấp bởi phần mềm, tính linh hoạt, thân thiện với người dùng, yêu
cầu phần cứng, yêu cầu cơ sở dữ liệu, nỗ lực cài đặt và bảo trì, tài liệu, chất lượng
của nhà cung cấp và chi phí. Quy trình đánh giá gói hoặc dịch vụ phần mềm
thường dựa trênyêu cầu đề xuất (RFP), là danh sách chi tiết các câu hỏi được gửi
đến các nhà cung cấp phần mềm.
Khi phần mềm từ một nguồn bên ngoài được chọn, tổ chức không còn có toàn
quyền kiểm soát quá trình thiết kế hệ thống. Thay vì điều chỉnh các thông số kỹ
thuật thiết kế hệ thống trực tiếp theo yêu cầu của người dùng, nỗ lực thiết kế sẽ
bao gồm việc cố gắng tạo ra các yêu cầu của người dùng để phù hợp với các tính
năng của gói hoặc dịch vụ phần mềm. Nếu các yêu cầu của tổ chức xung đột với
cách hoạt động của gói hoặc dịch vụ phần mềm và không thể tùy chỉnh phần mềm
này, tổ chức sẽ phải thích ứng với gói hoặc dịch vụ phần mềm và thay đổi các thủ
tục của mình.
 Chương 13 Xây dựng hệ thống thông tin 539

Gia công phần mềm

Nếu một công ty không muốn sử dụng các nguồn lực nội bộ của mình để xây dựng
hoặc vận hành hệ thống thông tin, thì công ty có thể thuê ngoài công việc cho một tổ
chức bên ngoài chuyên cung cấp các dịch vụ này. Các nhà cung cấp điện toán đám mây
và phần mềm như một dịch vụ (SaaS), mà chúng tôi đã mô tả trong Chương 5, là một
hình thức thuê ngoài. Các công ty đăng ký sử dụng phần mềm và phần cứng máy tính
do dịch vụ cung cấp làm nền tảng kỹ thuật cho hệ thống của họ. Trong một hình thức
thuê ngoài khác, một công ty có thể thuê một nhà cung cấp bên ngoài để thiết kế và tạo
phần mềm cho hệ thống của mình, nhưng công ty đó sẽ vận hành hệ thống trên máy
tính của chính mình. Nhà cung cấp gia công phần mềm có thể ở trong nước hoặc ở một
quốc gia khác.
Hoạt động gia công phần mềm trong nước chủ yếu được thúc đẩy bởi thực tế là các công
ty gia công phần mềm sở hữu các kỹ năng, nguồn lực và tài sản mà khách hàng của họ
không có. Việc cài đặt một hệ thống quản lý chuỗi cung ứng mới trong một công ty rất lớn có
thể yêu cầu thuê thêm 30 đến 50 người có chuyên môn cụ thể về phần mềm quản lý chuỗi
cung ứng, được cấp phép từ một nhà cung cấp. Thay vì thuê nhân viên mới cố định, hầu hết
trong số họ sẽ cần được đào tạo chuyên sâu về phần mềm mới và sau đó phát hành họ sau
khi hệ thống mới được xây dựng, sẽ có ý nghĩa hơn và thường ít tốn kém hơn, thuê ngoài
công việc này trong 12 tháng giai đoạn = Stage.
Trong trường hợp gia công ra nước ngoài, quyết định dựa trên chi phí nhiều hơn.
Một lập trình viên có tay nghề cao ở Ấn Độ hoặc Nga kiếm được khoảng 10.000 - 30.000
USD mỗi năm so với khoảng 60.000 - 120.000 USD mỗi năm của một lập trình viên
tương đương ở Hoa Kỳ. Internet và công nghệ truyền thông chi phí thấp đã giảm đáng
kể chi phí và khó khăn trong việc điều phối công việc của các nhóm toàn cầu ở các địa
điểm ngoài khơi. Ngoài việc tiết kiệm chi phí, nhiều công ty gia công phần mềm ra nước
ngoài cung cấp các kỹ năng và tài sản công nghệ đẳng cấp thế giới. Lạm phát tiền lương
bên ngoài Hoa Kỳ gần đây đã làm xói mòn một số lợi thế này, và một số công việc đã
chuyển trở lại Hoa Kỳ. Các công ty nói chung không thuê ngoài việc xây dựng ý tưởng,
phân tích hệ thống và thiết kế hệ thống CNTT cho các công ty nước ngoài, mà thường
thuê bên ngoài lập trình, kiểm tra, bảo trì và vận hành hệ thống CNTT hàng ngày.

Có một cơ hội rất lớn là vào một thời điểm nào đó trong sự nghiệp của mình, bạn sẽ
được làm việc với các nhà gia công nước ngoài hoặc các nhóm toàn cầu. Công ty của
bạn có nhiều khả năng được hưởng lợi từ việc thuê ngoài nếu họ dành thời gian để
đánh giá tất cả các rủi ro và đảm bảo rằng việc thuê ngoài phù hợp với các nhu cầu cụ
thể của họ. Bất kỳ công ty nào thuê ngoài các ứng dụng của mình đều phải hiểu rõ về
dự án, bao gồm các yêu cầu, phương pháp thực hiện, lợi ích dự kiến, các thành phần chi
phí và các chỉ số để đo lường hiệu suất.
Nhiều công ty đánh giá thấp chi phí cho việc xác định và đánh giá các nhà cung
cấp dịch vụ công nghệ thông tin, để chuyển đổi sang một nhà cung cấp mới, để cải
tiến các phương pháp phát triển phần mềm nội bộ để phù hợp với các nhà cung
cấp gia công và giám sát các nhà cung cấp để đảm bảo rằng họ đang thực hiện các
nghĩa vụ theo hợp đồng của mình. Các công ty sẽ cần phân bổ nguồn lực để lập hồ
sơ các yêu cầu, gửi RFP, xử lý chi phí đi lại, đàm phán hợp đồng và quản lý dự án.
Các chuyên gia tuyên bố rằng phải mất từ ba tháng đến cả năm để chuyển giao
hoàn toàn công việc cho một đối tác nước ngoài và đảm bảo rằng nhà cung cấp
hiểu kỹ về doanh nghiệp của bạn.
Gia công phần mềm ở nước ngoài phải chịu thêm chi phí để đối phó với những khác
biệt văn hóa làm tiêu hao năng suất và giải quyết các vấn đề về nguồn nhân lực, chẳng
hạn như cho thôi việc hoặc chuyển công tác trong nước. Tất cả những chi phí ẩn này
làm giảm một số lợi ích được mong đợi từ việc thuê ngoài. Các công ty nên đặc biệt
thận trọng khi sử dụng một bên gia công để phát triển hoặc vận hành các ứng dụng
mang lại cho nó một số loại lợi thế cạnh tranh.
540 Phần bốn Xây dựng và Quản lý Hệ thống

HÌNH 13.11 TỔNG CHI PHÍ KHAI THÁC OFFSHORE

TỔNG CHI PHÍ KHAI THÁC OFFSHORE

Chi phí của hợp đồng thuê ngoài € 10.000.000

Chi phí ẩn Trường hợp tốt nhất Thêm vào Trường hợp xấu nhất Thêm vào
Chi phí (€) Chi phí (€)
1. lựa chọn người gửi 0% 20.000 2% 200.000
2. chi phí chuyển giao 2% 200.000 3% 300.000
3. Sa thải & giữ chân 3% 300.000 5% 500.000
4. Mất năng suất / các vấn đề văn hóa 3% 300.000 27% 2.700.000
5. Cải tiến quy trình phát triển 1% 100.000 10% 1.000.000
6. Quản lý hợp đồng 6% 600.000 10% 1.000.000
Tổng chi phí bổ sung 1.520.000 5.700.000

Nổi bật Thêm vào Tổng chi phí (€) Bổ sung

Hợp đồng (€) Chi phí (€) Trị giá

Tổng chi phí thuê ngoài (TCO) trường hợp tốt nhất 10.000.000 1.520.000 11,520,000 15,2%
Tổng chi phí thuê ngoài (TCO) trường hợp xấu nhất 10.000.000 5.700.000 15.700.000 0%
577..0 %

Nếu một công ty chi 10 triệu đô la cho các hợp đồng gia công phần mềm ở nước ngoài, thì công ty đó sẽ thực sự chi

15,2% chi phí phụ trội ngay cả trong trường hợp tốt nhất. Trong trường hợp xấu nhất, khi năng suất lao
động sụt giảm nghiêm trọng cùng với chi phí chuyển đổi và sa thải đặc biệt cao, một công ty có thể phải
trả thêm tới 57% chi phí phụ trội so với khoản chi 10 triệu đô la cho một hợp đồng ra nước ngoài.

General Motors Corporation (GM) đã thuê ngoài 90% các dịch vụ CNTT của mình, bao
gồm cả các trung tâm dữ liệu và phát triển ứng dụng. Công ty gần đây đã quyết định
đưa 90% cơ sở hạ tầng CNTT vào nội bộ, với chỉ 10% được quản lý bởi những người thuê
ngoài. Giảm chi phí là quan trọng, nhưng lý do chính của GM để cắt giảm hoạt động
thuê ngoài là để giành lại quyền kiểm soát hệ thống thông tin của mình, điều mà GM
cho rằng đã ngăn cản công ty phản ứng nhanh với các cơ hội cạnh tranh. Đưa các hệ
thống thông tin vào nội bộ sẽ giúp GM dễ dàng tiêu chuẩn hóa và sắp xếp hợp lý các hệ
thống và trung tâm dữ liệu của mình. Hình 13.11 cho thấy các tình huống tốt nhất và
trường hợp xấu nhất cho tổng chi phí của một dự án thuê ngoài nước ngoài. Nó cho
thấy chi phí ẩn ảnh hưởng như thế nào đến tổng chi phí dự án. Trường hợp tốt nhất
phản ánh ước tính thấp nhất cho chi phí bổ sung, và trường hợp xấu nhất phản ánh ước
tính cao nhất cho các chi phí này. Như bạn có thể thấy, chi phí ẩn làm tăng tổng chi phí
của một dự án thuê ngoài nước ngoài từ 15 đến 57%. Ngay cả với những chi phí phụ
trội này, nhiều công ty sẽ được hưởng lợi từ việc thuê ngoài nước ngoài nếu họ quản lý
tốt công việc.

13-5 Các cách tiếp cận mới để xây dựng hệ thống là gì trong
kỷ nguyên công ty kỹ thuật số?

Trong môi trường công ty kỹ thuật số, các tổ chức cần có khả năng bổ sung, thay đổi và
loại bỏ khả năng công nghệ của mình rất nhanh chóng để đáp ứng các cơ hội mới, bao
gồm cả nhu cầu cung cấp ứng dụng cho nền tảng di động. Các công ty đang bắt đầu sử
dụng các quy trình phát triển ngắn hơn, không chính thức hơn để cung cấp các giải
pháp nhanh chóng. Ngoài việc sử dụng các gói phần mềm và dịch vụ phần mềm trực
tuyến, các doanh nghiệp đang phụ thuộc nhiều hơn vào các kỹ thuật chu kỳ nhanh như
phát triển ứng dụng nhanh, thiết kế ứng dụng chung, phát triển nhanh và các thành
phần phần mềm tiêu chuẩn có thể tái sử dụng có thể được lắp ráp thành một bộ dịch
vụ hoàn chỉnh cho thương mại điện tử và kinh doanh điện tử.
 Chương 13 Xây dựng hệ thống thông tin 541

Phát triển ứng dụng nhanh (RAD), Phát triển

nhanh và DevOps
Các công cụ phần mềm hướng đối tượng, phần mềm có thể tái sử dụng, tạo mẫu và các công
cụ để tự động hóa việc tạo mã chương trình đang giúp các nhà xây dựng hệ thống tạo ra các
hệ thống làm việc nhanh hơn nhiều so với việc họ có thể sử dụng các phương pháp xây dựng
hệ thống và công cụ phần mềm truyền thống. Thời hạnphát triển ứng dụng nhanh chóng
(RAD) được sử dụng để mô tả quá trình tạo ra các hệ thống khả thi trong một khoảng thời
gian rất ngắn với một số tính linh hoạt để thích ứng khi một dự án phát triển. RAD cũng liên
quan đến việc làm việc theo nhóm chặt chẽ giữa người dùng cuối và các chuyên gia hệ thống
thông tin cũng như giữa các nhóm CNTT đang phát triển và vận hành hệ thống. Các hệ
thống đơn giản thường có thể được lắp ráp từ các thành phần xây dựng sẵn. Quá trình
không nhất thiết phải tuần tự và các phần quan trọng của quá trình phát triển có thể xảy ra
đồng thời.
Đôi khi một kỹ thuật được gọi là thiết kế ứng dụng chung (JAD) được sử dụng để đẩy
nhanh quá trình tạo ra các yêu cầu thông tin và phát triển thiết kế hệ thống ban đầu. JAD tập
hợp người dùng cuối và các chuyên gia hệ thống thông tin lại với nhau trong một phiên
tương tác để thảo luận về thiết kế của hệ thống. Được chuẩn bị và tạo điều kiện thích hợp,
các phiên JAD có thể tăng tốc đáng kể giai đoạn thiết kế và thu hút sự tham gia của người
dùng ở mức độ cao.
Phát triển nhanh tập trung vào việc phân phối nhanh chóng phần mềm đang hoạt động
bằng cách chia một dự án lớn thành một loạt các dự án con nhỏ được hoàn thành trong thời
gian ngắn bằng cách sử dụng lặp đi lặp lại và phản hồi liên tục. Mỗi dự án nhỏ được thực
hiện bởi một nhóm như thể nó là một dự án hoàn chỉnh. Việc cải tiến hoặc bổ sung chức
năng mới diễn ra trong lần lặp tiếp theo khi các nhà phát triển làm rõ các yêu cầu. Điều này
giúp giảm thiểu rủi ro tổng thể và cho phép dự án thích ứng với những thay đổi nhanh
chóng hơn. Các phương pháp Agile nhấn mạnh vào giao tiếp mặt đối mặt qua các tài liệu
bằng văn bản, khuyến khích mọi người cộng tác và đưa ra quyết định nhanh chóng và hiệu
quả.

DevOps
DevOps xây dựng dựa trên các nguyên tắc phát triển nhanh như một chiến lược tổ
chức để tạo ra một văn hóa và môi trường thúc đẩy hơn nữa các hoạt động phát
triển nhanh và linh hoạt. DevOps là viết tắt của “phát triển và hoạt động” và nhấn
mạnh sự hợp tác chặt chẽ giữa các nhà phát triển phần mềm, những người tạo ra
các ứng dụng và các nhân viên vận hành CNTT, những người chạy và bảo trì các
ứng dụng. Theo truyền thống, trong một doanh nghiệp lớn, một nhóm phát triển
ứng dụng sẽ chịu trách nhiệm thu thập các yêu cầu nghiệp vụ cho một ứng dụng,
thiết kế ứng dụng và viết và thử nghiệm phần mềm. Nhóm vận hành sẽ chạy và
bảo trì phần mềm sau khi nó được đưa vào sản xuất. Các vấn đề nảy sinh khi nhóm
phát triển không biết về các vấn đề hoạt động khiến phần mềm không hoạt động
như mong đợi, cần thêm thời gian và làm lại để sửa phần mềm.

DevOps cố gắng thay đổi mối quan hệ này bằng cách thúc đẩy giao tiếp và cộng
tác tốt hơn và thường xuyên hơn giữa các nhóm vận hành và phát triển hệ thống
cũng như quy trình làm việc nhanh chóng và ổn định trong toàn bộ vòng đời phát
triển ứng dụng. Với kiểu thay đổi tổ chức này cùng với các kỹ thuật linh hoạt, quy
trình chuẩn hóa và các công cụ kiểm tra và tạo phần mềm tự động mạnh mẽ hơn,
có thể phát hành các ứng dụng đáng tin cậy hơn nhanh chóng và thường xuyên
hơn.
Ví dụ: Ngân hàng Barclays đã áp dụng các phương pháp linh hoạt, bao gồm cả
DevOps, cho nhiều lĩnh vực kinh doanh để tăng tốc độ đổi mới và đối phó với áp lực
cạnh tranh từ những người mới tham gia vào thị trường ngân hàng, bao gồm
542 Phần bốn Xây dựng và Quản lý Hệ thống

các ngân hàng chỉ dành cho thiết bị di động, cũng như Apple và Google, đang tham gia vào
lĩnh vực thanh toán di động. DevOps và các thực hành nhanh đã giúp Barclays giảm thời gian
cần thiết cho việc cập nhật phần mềm cũng như độ phức tạp của mã phần mềm do các nhà
phát triển của nó viết. Barclays chịu trách nhiệm xử lý các khoản thanh toán mỗi ngày tương
đương với 30% tổng sản phẩm quốc nội của Vương quốc Anh và sử dụng các phương pháp
phát triển phần mềm DevOps đảm bảo hệ thống của họ vẫn hoạt động và cạnh tranh
(Donnelly, 2016).

Dịch vụ Web và Phát triển Dựa trên Thành phần

Chúng tôi đã mô tả một số lợi ích của phát triển hướng đối tượng để xây dựng các
hệ thống có thể đáp ứng với môi trường kinh doanh thay đổi nhanh chóng, bao
gồm cả các ứng dụng web. Để đẩy nhanh quá trình tạo phần mềm, các nhóm đối
tượng đã được tập hợp để cung cấp các thành phần phần mềm cho các chức năng
thông thường như giao diện người dùng đồ họa hoặc khả năng đặt hàng trực
tuyến có thể được kết hợp để tạo ra các ứng dụng kinh doanh quy mô lớn. Cách
tiếp cận này để phát triển phần mềm được gọi làphát triển dựa trên thành phần,
và nó cho phép xây dựng một hệ thống bằng cách lắp ráp và tích hợp các thành
phần phần mềm hiện có. Càng ngày, các thành phần phần mềm này càng đến từ
các dịch vụ đám mây. Các doanh nghiệp đang sử dụng phát triển dựa trên thành
phần để tạo các ứng dụng thương mại điện tử của họ bằng cách kết hợp các thành
phần có sẵn trên thị trường cho giỏ hàng, xác thực người dùng, công cụ tìm kiếm
và danh mục với các phần mềm cho các yêu cầu kinh doanh riêng của họ.

Dịch vụ Web và Máy tính Hướng Dịch vụ

Chương 5 giới thiệu dịch vụ web như các thành phần phần mềm được kết hợp lỏng lẻo,
có thể tái sử dụng bằng cách sử dụng Ngôn ngữ đánh dấu mở rộng (XML) và các giao
thức và tiêu chuẩn mở khác cho phép một ứng dụng giao tiếp với ứng dụng khác mà
không cần lập trình tùy chỉnh để chia sẻ dữ liệu và dịch vụ. Ngoài việc hỗ trợ tích hợp
bên trong và bên ngoài hệ thống, các dịch vụ web có thể được sử dụng làm công cụ để
xây dựng các ứng dụng hệ thống thông tin mới hoặc cải tiến các hệ thống hiện có. Bởi
vì các dịch vụ phần mềm này sử dụng một bộ tiêu chuẩn chung, chúng hứa hẹn sẽ ít
tốn kém hơn và ít khó kết hợp với nhau hơn so với các thành phần độc quyền.

Các dịch vụ web có thể tự thực hiện các chức năng nhất định và chúng cũng có
thể tham gia vào các dịch vụ web khác để hoàn thành các giao dịch phức tạp hơn,
chẳng hạn như kiểm tra tín dụng, mua sắm hoặc đặt hàng sản phẩm. Bằng cách
tạo ra các thành phần phần mềm có thể giao tiếp và chia sẻ dữ liệu bất kể hệ điều
hành, ngôn ngữ lập trình hoặc thiết bị khách, dịch vụ web có thể tiết kiệm chi phí
đáng kể trong việc xây dựng hệ thống đồng thời mở ra cơ hội hợp tác mới với các
công ty khác.

Phát triển ứng dụng di động: Thiết kế cho một

thế giới đa màn hình
Ngày nay, nhân viên và khách hàng mong đợi và thậm chí có nhu cầu có thể sử dụng thiết bị
di động mà họ lựa chọn để lấy thông tin hoặc thực hiện giao dịch ở bất kỳ đâu và bất kỳ lúc
nào. Để đáp ứng những nhu cầu này, các công ty sẽ cần phát triển các trang web di động,
ứng dụng dành cho thiết bị di động và ứng dụng gốc cũng như các hệ thống thông tin
truyền thống.
 Chương 13 Xây dựng hệ thống thông tin 543

Khi một tổ chức quyết định phát triển ứng dụng dành cho thiết bị di động, tổ chức phải đưa ra một số
lựa chọn quan trọng, bao gồm cả công nghệ mà tổ chức sẽ sử dụng để triển khai các ứng dụng này (viết
ứng dụng gốc hay ứng dụng web dành cho thiết bị di động) và những việc cần làm đối với một trang web
dành cho thiết bị di động. MỘTtrang web di động là phiên bản của một trang web thông thường được
thu nhỏ về nội dung và điều hướng để dễ dàng truy cập và tìm kiếm trên màn hình di động nhỏ. (Truy
cập trang web của Amazon từ máy tính của bạn và sau đó từ điện thoại thông minh của bạn để xem sự
khác biệt so với một trang web thông thường.)
MỘT ứng dụng web di động là một ứng dụng hỗ trợ Internet với chức năng cụ thể dành
cho thiết bị di động. Người dùng truy cập các ứng dụng web dành cho thiết bị di động thông
qua trình duyệt web trên thiết bị di động của họ. Ứng dụng web chủ yếu nằm trên máy chủ,
được truy cập qua Internet và không cần cài đặt trên thiết bị. Hầu hết các thiết bị có thể lướt
web đều có thể sử dụng cùng một ứng dụng, bất kể thương hiệu của chúng.
MỘT ứng dụng gốc là một ứng dụng độc lập được thiết kế để chạy trên một nền
tảng và thiết bị cụ thể. Ứng dụng gốc được cài đặt trực tiếp trên thiết bị di động. Các
ứng dụng gốc có thể kết nối với Internet để tải xuống và tải lên dữ liệu, đồng thời
chúng cũng có thể hoạt động trên những dữ liệu này ngay cả khi không được kết nối
với Internet. Ví dụ, một ứng dụng đọc sách điện tử như phần mềm Kindle có thể tải
xuống một cuốn sách từ Internet, ngắt kết nối Internet và trình bày cuốn sách để đọc.
Các ứng dụng dành cho thiết bị di động gốc cung cấp hiệu suất nhanh và mức độ tin
cậy cao. Họ cũng có thể tận dụng các khả năng cụ thể của thiết bị di động, chẳng hạn
như camera hoặc các tính năng cảm ứng của nó. Tuy nhiên, các ứng dụng gốc rất tốn
kém để phát triển vì nhiều phiên bản của một ứng dụng phải được lập trình cho các hệ
điều hành và phần cứng di động khác nhau.
Phát triển ứng dụng cho nền tảng di động khá khác với phát triển cho PC và màn hình lớn
hơn nhiều của chúng. Kích thước giảm của thiết bị di động làm cho việc sử dụng ngón tay và
cử chỉ cảm ứng đa điểm dễ dàng hơn nhiều so với nhập và sử dụng bàn phím. Ứng dụng
dành cho thiết bị di động cần được tối ưu hóa cho các tác vụ cụ thể mà chúng phải thực hiện,
chúng không nên cố gắng thực hiện quá nhiều tác vụ và chúng phải được thiết kế để có thể
sử dụng được. Trải nghiệm người dùng tương tác trên thiết bị di động về cơ bản khác với
việc sử dụng máy tính để bàn hoặc máy tính xách tay. Tiết kiệm tài nguyên — băng thông,
không gian màn hình, bộ nhớ, xử lý, nhập dữ liệu và cử chỉ của người dùng — là ưu tiên
hàng đầu.
Khi một trang web đầy đủ được tạo cho máy tính để bàn thu nhỏ lại bằng kích
thước của màn hình điện thoại thông minh, người dùng sẽ khó điều hướng qua
trang web. Người dùng phải liên tục phóng to, thu nhỏ và cuộn để tìm tài liệu có
liên quan. Do đó, các công ty cần thiết kế trang web dành riêng cho giao diện di
động và tạo nhiều trang di động để đáp ứng nhu cầu của điện thoại thông minh,
máy tính bảng và trình duyệt máy tính để bàn. Điều này tương đương với ít nhất ba
trang web có nội dung, bảo trì và chi phí riêng biệt. Hiện tại, các trang web biết bạn
đang sử dụng thiết bị nào vì trình duyệt của bạn sẽ gửi thông tin này đến máy chủ
khi bạn đăng nhập. Dựa trên thông tin này, máy chủ sẽ cung cấp màn hình thích
hợp.
Một giải pháp cho vấn đề có nhiều trang web là sử dụng thiết kế web đáp ứng.
Thiết kế web đáp ứng cho phép các trang web tự động thay đổi bố cục theo độ phân
giải màn hình của khách truy cập, cho dù trên máy tính để bàn, máy tính xách tay, máy
tính bảng hay điện thoại thông minh. Thiết kế đáp ứng sử dụng các công cụ như bố cục
dựa trên lưới linh hoạt, hình ảnh linh hoạt và truy vấn phương tiện để tối ưu hóa thiết
kế cho các bối cảnh xem khác nhau. Điều này giúp loại bỏ nhu cầu về công việc thiết kế
và phát triển riêng biệt cho từng thiết bị mới. HTML5, mà chúng tôi đã giới thiệu trong
Chương 5, cũng được sử dụng để phát triển ứng dụng di động vì nó có thể hỗ trợ các
ứng dụng di động đa nền tảng.
Phiên Tương tác về Công nghệ mô tả cách một số công ty giải quyết những
thách thức trong phát triển di động mà chúng tôi vừa xác định.
544 Phần bốn Xây dựng và Quản lý Hệ thống
PHẦN TƯƠNG TÁC: CÔNG NGHỆ
Phát triển ứng dụng di động: Có gì khác biệt
Hầu như tất cả các doanh nghiệp ngày nay đều muốn triển khai ứng
dụng dành cho thiết bị di động. Các nghiên cứu cho thấy người tiêu
dùng di động nhìn vào điện thoại của họ trung bình 1.500 lần mỗi tuần
và dành 177 phút trên điện thoại mỗi ngày. Với mỗi lần vuốt, chạm và
thu phóng, khách hàng sẽ mong đợi trải nghiệm giống nhau trong tất cả
các giao dịch của họ với doanh nghiệp. Các doanh nghiệp ngày nay biết
rằng họ phải đáp ứng và họ muốn các ứng dụng dành cho thiết bị di
động được phát triển trong một khung thời gian rất ngắn. Điều đó
không dễ dàng như vậy.
Việc phát triển các ứng dụng di động thành công đặt ra
một số thách thức riêng. Trải nghiệm người dùng trên thiết
bị di động về cơ bản khác với trải nghiệm trên PC. Có
những tính năng đặc biệt trên thiết bị di động, chẳng hạn
như dịch vụ dựa trên vị trí cung cấp cho các công ty tiềm
năng tương tác với khách hàng theo những cách mới có ý
nghĩa. Các hãng cần tận dụng được những tính năng đó
đồng thời mang đến trải nghiệm phù hợp với màn hình
nhỏ. Có nhiều nền tảng di động để làm việc, bao gồm iOS,
Android và Windows 10, và một công ty có thể cần một
phiên bản ứng dụng khác để chạy trên mỗi nền tảng này.
Các nhà xây dựng hệ thống cần hiểu cách thức, lý do và vị
trí khách hàng sử dụng thiết bị di động và những trải
nghiệm di động này thay đổi hành vi và tương tác kinh
doanh như thế nào. Bạn không thể chỉ chuyển một trang
web hoặc ứng dụng máy tính để bàn sang điện thoại thông
minh hoặc máy tính bảng.
Alex và Ani đã học được điều này khi phát triển ứng dụng di
động cho nhân viên tại các cửa hàng của mình để giúp khách
hàng lựa chọn và sau đó hoàn tất giao dịch mua hàng. Alex and
Ani, được thành lập vào năm 2004, thiết kế, sản xuất và bán đồ
trang sức chất lượng cao, thân thiện với môi trường ở Hoa Kỳ
bằng kỹ thuật thủ công và luôn tận tâm giúp khách hàng của
mình tìm thấy sự bình yên bên trong và năng lượng tích cực.
Việc để khách hàng ở các cửa hàng Alex và Ani xếp hàng dài
chờ thanh toán đã đi ngược lại triết lý và hình ảnh thương hiệu
của công ty.
Làm việc với Mobiquity, một nhà phát triển các giải pháp
di động doanh nghiệp, Alex và Ani đã tạo ra một giải pháp
thanh toán và điểm bán hàng di động trong đó Alex và
Ani's Bangle Bartender có thể quẹt thẻ tín dụng, quét mã
vạch và in, cho phép khách hàng ký và nhận bản sao biên
lai thẻ tín dụng tại thời điểm mua hàng khi họ đang ở trên
lối đi của cửa hàng. Họ không phải xếp hàng chờ thu ngân.
Ứng dụng di động giúp nhân viên bán hàng của cửa hàng
quan tâm đến khách hàng hơn đồng thời giảm thời gian
thanh toán khi mua hàng. Điều này nâng cao trải nghiệm
của khách hàng tại cửa hàng,
cải thiện nhận thức về thương hiệu và cung cấp dịch vụ
khách hàng tốt hơn, do đó tăng doanh thu bán hàng.
Điểm khởi đầu để phát triển ứng dụng dành cho thiết bị
di động là xác định những khoảnh khắc trên thiết bị di
động (những thời điểm ai đó rút thiết bị di động ra để hoàn
thành công việc) mà ứng dụng dành cho thiết bị di động sẽ
đặc biệt hữu ích. Giám đốc công nghệ của Alex và Ani, Joe
Lezon và người đứng đầu hoạt động bán lẻ Susan Soards
đã vạch ra những khoảnh khắc trên thiết bị di động mà
nhân viên tương tác với khách hàng. Sau đó, họ xác định
bối cảnh — tình huống, sở thích và thái độ của khách hàng
và nhân viên trong những khoảnh khắc di động này. Lezon
và Soards đã xác định những khoảnh khắc trên thiết bị di
động diễn ra ở đâu, thời gian tồn tại của chúng, giai đoạn
của quá trình thanh toán, thông tin nào có sẵn và mong đợi
của khách hàng.
Bước thứ hai là thiết kế tương tác trên thiết bị di động. Các
doanh nhân, nhà thiết kế và nhà phát triển ứng dụng họp lại
với nhau để quyết định cách thu hút khách hàng trong những
khoảnh khắc trên thiết bị di động và những khoảnh khắc nào
mang lại lợi ích cho cả khách hàng và công ty. Một ứng dụng
dành cho thiết bị di động dành cho những khoảnh khắc mang
lại lợi ích cho cả khách hàng và công ty có nhiều khả năng
thành công hơn. Alex và Ani đã có một nhóm nhỏ vẽ các bức
tranh để thiết kế sự tương tác trên thiết bị di động, vạch ra
chính xác cách một nhân viên sẽ sử dụng ứng dụng iPod Touch
và máy in / đầu đọc thẻ tín dụng được liên kết trực tiếp với hệ
thống điểm bán hàng của công ty để thu hút khách hàng. Các
thông số kỹ thuật thiết kế bao gồm bố cục màn hình, chuỗi sự
kiện và các giao dịch cần thiết ở mỗi bước.
Bước thứ ba là thiết kế con người, quy trình và nền tảng
để cung cấp trải nghiệm di động. Một ứng dụng di động
hiệu quả thường yêu cầu thay đổi hệ thống nội bộ của
công ty, chẳng hạn như hệ thống quản lý hàng tồn kho,
khách hàng và đặt chỗ. Những thay đổi như API mới và
điều chỉnh hệ thống để phản hồi nhanh hơn các yêu cầu
chiếm 80% chi phí của hầu hết các dự án di động. (API là
viết tắt của “giao diện chương trình ứng dụng”, một tập
hợp các quy trình, giao thức và công cụ để xây dựng các
ứng dụng phần mềm, chỉ định cách các thành phần phần
mềm sẽ tương tác.) Alex và Ani đã kết nối ứng dụng di
động của họ với hệ thống điểm bán hàng của công ty cũng
như hệ thống với thông tin sản phẩm chi tiết.
Bước thứ tư, cuối cùng là theo dõi hiệu suất và
cải thiện kết quả. Alex và Ani đã phân tích ứng
dụng bán lẻ di động của mình để xác định
 Chương 13 Xây dựng hệ thống thông tin 545

thời gian thanh toán giảm xuống và khách hàng nào
đã hoàn thành giao dịch. Hệ thống di động mới đã
giúp Bangle Bartender có nhiều thời gian hơn để
tiếp xúc với khách hàng, loại bỏ các dòng khách
hàng và giúp tăng doanh số bán hàng trong dịp lễ
lên hơn 300%. Alex và Ani đã có thể tăng số điểm
thanh toán từ 4 lên 10 tại hầu hết 28 cửa hàng ở Mỹ.
Ứng dụng dành cho thiết bị di động không nên được xây
dựng vì lợi ích của thiết bị di động mà để thực sự giúp công ty
trở nên thành công hơn. Ứng dụng dành cho thiết bị di động
phải được kết nối theo cách có ý nghĩa với các hệ thống hỗ trợ
hoạt động kinh doanh. TTX có trụ sở tại Chicago, cung cấp dịch
vụ quản lý toa xe và đường sắt vận chuyển hàng hóa cho ngành
đường sắt, nhận thấy rằng khía cạnh quan trọng nhất của dự
án phát triển ứng dụng di động của họ là có một ý tưởng chắc
chắn về những gì họ đang cố gắng hoàn thành với ứng dụng.
Vào năm 2014, công ty đã phát triển một ứng dụng dành cho
thiết bị di động để cải thiện độ chính xác của việc thanh toán và
tăng năng suất của đội bảo trì tại 50 cửa hàng bảo trì hoạt
động dọc theo các tuyến đường sắt. Ứng dụng mất khoảng sáu
tháng để thiết kế và xây dựng trong nhà.
Mục đích của ứng dụng là cải thiện việc lưu trữ hồ
sơ liên quan đến công việc bảo trì của TTX,
diễn ra trong điều kiện ngoài trời khắc nghiệt, nơi
kết nối bị lốm đốm hoặc không tồn tại và được thực
hiện bởi những nhân viên thường đeo găng tay. Các
đội bảo trì đã sử dụng giấy và bút chì để ghi lại các
ghi chú của họ về việc sửa chữa toa xe lửa. Ứng
dụng dành cho thiết bị di động dựa trên nền tảng
Windows dành cho PC có màn hình cảm ứng. TTX
CIO và Phó chủ tịch Bruce Schinelli và nhóm phát
triển hệ thống của ông nhận ra rằng những gì ứng
dụng cần làm là thay thế bút và giấy và nó phải hoạt
động tốt trong lĩnh vực này. Sự hiểu biết sớm về
cách ứng dụng di động sẽ cung cấp giá trị cho
doanh nghiệp đã thúc đẩy toàn bộ thiết kế và triển
khai hệ thống. Schinelli tin rằng nếu một công ty
đưa ra những giả định sai lầm về mục đích của ứng
dụng di động của mình, họ sẽ phải làm lại rất nhiều.
Đối với TTX,
Nguồn: Mary K. Pratt, “Khi Ứng dụng Di động cho Nhân viên Tăng lên, Các CIO
được Tham gia”, searchCIO.com, truy cập ngày 10 tháng 2 năm 2016; Alex và
Ani, “Alex và Ani mPOS,” www.mobiquity.com, truy cập ngày 22 tháng 2 năm
2016; Linda Tucci, “Phát triển ứng dụng di động dành cho doanh nghiệp:
Không có câu trả lời dễ dàng”, searchCIO.com, truy cập ngày 22 tháng 2 năm
2016; và Brian Solis, “Di động đang ăn mòn thế giới,” Sitecore Corporation,
tháng 2 năm 2016.

CÂU HỎI NGHIÊN CỨU TÌNH HUỐNG

1. Những vấn đề quản lý, tổ chức và công nghệ nào 3. Mô tả quy trình bán hàng của Alex và Ani trước và sau
cần được giải quyết khi xây dựng một ứng dụng khi ứng dụng di động được triển khai như thế nào.
di động?
2. Định nghĩa yêu cầu của người dùng cho các ứng dụng di
động khác với phân tích hệ thống truyền thống như thế
nào?

Tóm tắt đánh giá

13-1 Làm thế nào để xây dựng các hệ thống mới tạo ra sự thay đổi tổ chức?
Xây dựng hệ thống thông tin mới là một hình thức thay đổi tổ chức có kế hoạch. Bốn loại thay
đổi do công nghệ hỗ trợ là (1) tự động hóa, (2) hợp lý hóa các thủ tục, (3) thiết kế lại quy trình kinh
doanh và (4) thay đổi mô hình, với những thay đổi sâu rộng mang lại rủi ro và phần thưởng lớn
nhất. Nhiều tổ chức đang sử dụng quản lý quy trình kinh doanh để thiết kế lại quy trình làm việc và
quy trình kinh doanh với hy vọng đạt được những đột phá đáng kể về năng suất. Quản lý quy trình
kinh doanh cũng hữu ích để thúc đẩy quản lý chất lượng tổng thể (TQM), sáu sigma và các sáng
kiến khác để cải tiến quy trình gia tăng.

13-2 Các hoạt động cốt lõi trong quá trình phát triển hệ thống là gì?
Các hoạt động cốt lõi trong phát triển hệ thống là phân tích hệ thống, thiết kế hệ thống, lập
trình, kiểm tra, chuyển đổi, sản xuất và bảo trì. Phân tích hệ thống là nghiên cứu và phân tích
546 Phần bốn Xây dựng và Quản lý Hệ thống

các vấn đề của các hệ thống hiện có và việc xác định các yêu cầu đối với các giải pháp của chúng. Thiết kế hệ thống
cung cấp các thông số kỹ thuật cho một giải pháp hệ thống thông tin, cho thấy các thành phần kỹ thuật và tổ chức của
nó phù hợp với nhau như thế nào.

13-3 Các phương pháp luận chính để lập mô hình và thiết kế hệ thống là gì?
Hai phương pháp luận chính để mô hình hóa và thiết kế hệ thống thông tin là phương pháp luận có
cấu trúc và phát triển hướng đối tượng. Các phương pháp luận có cấu trúc tập trung vào việc mô hình
hóa các quy trình và dữ liệu một cách riêng biệt. Sơ đồ luồng dữ liệu là công cụ chính để phân tích có cấu
trúc và biểu đồ cấu trúc là công cụ chính để biểu diễn thiết kế phần mềm có cấu trúc. Phát triển hướng
đối tượng mô hình hóa một hệ thống như một tập hợp các đối tượng kết hợp các quy trình và dữ liệu.
Mô hình hướng đối tượng dựa trên các khái niệm về lớp và kế thừa.

13-4 Các phương pháp thay thế để xây dựng hệ thống thông tin là gì?
Phương pháp lâu đời nhất để xây dựng hệ thống là vòng đời của hệ thống, yêu cầu hệ thống thông tin phải
được phát triển trong các giai đoạn chính thức. Các công đoạn phải tiến hành tuần tự và có đầu ra xác định;
mỗi yêu cầu phê duyệt chính thức trước khi giai đoạn tiếp theo có thể bắt đầu. Vòng đời của hệ thống rất hữu
ích cho các dự án lớn cần thông số kỹ thuật chính thức và kiểm soát quản lý chặt chẽ đối với từng giai đoạn xây
dựng hệ thống, nhưng nó rất cứng nhắc và tốn kém.
Tạo mẫu bao gồm việc xây dựng một hệ thống thử nghiệm nhanh chóng và không tốn kém để người
dùng cuối tương tác và đánh giá. Tạo mẫu khuyến khích sự tham gia của người dùng cuối vào việc phát
triển hệ thống và lặp lại thiết kế cho đến khi các thông số kỹ thuật được nắm bắt chính xác. Việc tạo ra
nhanh chóng các nguyên mẫu có thể dẫn đến các hệ thống chưa được kiểm tra hoặc ghi lại hoàn toàn
hoặc không đủ kỹ thuật cho môi trường sản xuất.
Việc sử dụng một gói phần mềm hoặc các dịch vụ phần mềm trực tuyến (SaaS) làm giảm khối lượng
công việc thiết kế, lập trình, kiểm tra, cài đặt và bảo trì cần thiết để xây dựng một hệ thống. Các gói phần
mềm ứng dụng hoặc SaaS rất hữu ích nếu một công ty không có nhân viên hệ thống thông tin nội bộ
hoặc nguồn tài chính để phát triển hệ thống một cách tùy chỉnh. Để đáp ứng các yêu cầu riêng của một
tổ chức, các gói có thể yêu cầu sửa đổi rộng rãi có thể làm tăng đáng kể chi phí phát triển.

Phát triển người dùng cuối là sự phát triển hệ thống thông tin của người dùng cuối, một mình hoặc với sự hỗ trợ tối thiểu
của các chuyên gia hệ thống thông tin. Hệ thống do người dùng cuối phát triển có thể được tạo nhanh chóng và không chính
thức bằng cách sử dụng các công cụ phần mềm thân thiện với người dùng. Tuy nhiên, việc phát triển người dùng cuối có thể
tạo ra các hệ thống thông tin không nhất thiết phải đáp ứng các tiêu chuẩn đảm bảo chất lượng và không dễ dàng kiểm soát
bằng các phương tiện truyền thống.
Thuê ngoài bao gồm việc sử dụng một nhà cung cấp bên ngoài để xây dựng (hoặc vận hành) hệ thống thông tin
của một công ty thay vì nhân viên hệ thống thông tin nội bộ của tổ chức. Thuê ngoài có thể tiết kiệm chi phí phát triển
ứng dụng hoặc cho phép các công ty phát triển ứng dụng mà không cần nhân viên hệ thống thông tin nội bộ. Tuy
nhiên, các công ty có nguy cơ mất quyền kiểm soát hệ thống thông tin của mình và trở nên quá phụ thuộc vào các nhà
cung cấp bên ngoài. Việc thuê ngoài cũng kéo theo những chi phí tiềm ẩn, đặc biệt là khi công việc được gửi ra nước
ngoài.

13-5 Những cách tiếp cận mới để xây dựng hệ thống trong kỷ nguyên công ty kỹ thuật số là gì?
Các công ty đang chuyển sang thiết kế ứng dụng nhanh (RAD), thiết kế ứng dụng chung (JAD), phát
triển nhanh và các thành phần phần mềm có thể tái sử dụng để đẩy nhanh quá trình phát triển hệ
thống. RAD sử dụng phần mềm hướng đối tượng, lập trình trực quan, tạo mẫu và các công cụ để tạo hệ
thống rất nhanh. Phát triển Agile chia một dự án lớn thành một loạt các dự án con nhỏ được hoàn thành
trong thời gian ngắn bằng cách sử dụng lặp đi lặp lại và phản hồi liên tục. Phát triển dựa trên thành
phần xúc tiến việc phát triển ứng dụng bằng cách nhóm các đối tượng thành các bộ thành phần phần
mềm có thể được kết hợp để tạo ra các ứng dụng kinh doanh quy mô lớn. DevOps nhấn mạnh sự hợp
tác chặt chẽ giữa các nhà phát triển phần mềm, những người tạo ra các ứng dụng và các nhân viên vận
hành CNTT, những người chạy và bảo trì các ứng dụng. Các dịch vụ web cung cấp một bộ tiêu chuẩn
chung cho phép các tổ chức liên kết hệ thống của họ bất kể nền tảng công nghệ của họ thông qua kiến
trúc plug-and-play tiêu chuẩn. Việc phát triển ứng dụng di động phải chú ý đến tính đơn giản, khả năng
sử dụng và nhu cầu tối ưu hóa các tác vụ cho màn hình siêu nhỏ.
 Chương 13 Xây dựng hệ thống thông tin 547

Điều khoản quan trọng

Kiểm thử chấp nhận, Chiến lược song song, 527

526 Phát triển Agile, 541 Chiến lược tiếp cận theo giai đoạn, 527
Tự động hóa, 517 Chiến lược nghiên cứu thí điểm, 527
Quản lý quy trình kinh doanh (BPM), 519 Thiết Đánh giá sau khi thực hiện, 527
kế lại quy trình kinh doanh, 518 Đặc điểm quy trình, 530 Sản
Phát triển dựa trên thành phần, 542 Kỹ thuật phần xuất, 527
mềm hỗ trợ máy tính (CASE), 532 Chuyển đổi, 527 Lập trình, 525
Nguyên mẫu, 534
Tùy chỉnh, 538 Nguyên mẫu, 534
Sơ đồ luồng dữ liệu (DFD), 528 Ngôn ngữ truy vấn, 535
DevOps, 541 Phát triển ứng dụng nhanh chóng (RAD),
Chiến lược cắt bỏ trực tiếp, 541 Hợp lý hóa các thủ tục, 518
Tài liệu 527, 527 Yêu cầu đề xuất (RFP), 538 Thiết
Phát triển người dùng cuối, 535 kế web đáp ứng, 543 Six sigma,
Giao diện người dùng cuối, 535 518
Nghiên cứu khả thi, 523 Biểu đồ cấu trúc, 530
Yêu cầu thông tin, 524 Lặp lại, Có cấu trúc, 528
534 Phân tích hệ thống, 523
Thiết kế ứng dụng chung (JAD), Thiết kế hệ thống, 524
541 Bảo trì, 527 Phát triển hệ thống, 523
Ứng dụng web dành cho thiết bị di động, 543 Vòng đời hệ thống, 533 Kiểm
Trang web dành cho thiết bị di động, 543 tra hệ thống, 526
Ứng dụng gốc, 543 Kế hoạch thử nghiệm, 526

Vật thể, 530 Thử nghiệm, 525

Phát triển hướng đối tượng, 530 Gia công Quản lý chất lượng toàn diện (TQM), 518
phần mềm ra nước ngoài, 539 Kiểm tra đơn vị, 526
Sự thay đổi mô hình, 519

Của tôiPhòng thí nghiệm MIS

Để hoàn thành các vấn đề với MyLab MIS, chuyển đến Câu hỏi thảo luận EOC trong MyLab MIS.

Câu hỏi đánh giá

13-1 Làm thế nào để xây dựng các hệ thống mới tạo ra orga-
thay đổi nizational?
• Mô tả từng loại trong số bốn loại thay đổi tổ
chức có thể được thúc đẩy bằng công nghệ
thông tin.
• Xác định quản lý quy trình kinh doanh và mô
tả các bước cần thiết để thực hiện.
13-2 Các hoạt động cốt lõi trong hệ thống là gì
quá trình phát triển?
• Phân biệt giữa phân tích hệ thống và thiết kế
hệ thống. Mô tả các hoạt động cho mỗi.
• Mô tả vai trò của lập trình, chuyển đổi, sản
xuất và bảo trì trong phát triển hệ thống.
13-3 Các phương pháp luận chính cho mod-
eling và thiết kế hệ thống?
• So sánh hướng đối tượng và phương pháp tiếp cận
có cấu trúc truyền thống để mô hình hóa và thiết
kế hệ thống.
• Mô tả kỹ thuật phần mềm có sự hỗ trợ của máy tính và
giải thích mục đích của nó.
13-4 Các phương pháp thay thế để xây dựng thông tin là gì
hệ thống giao phối?

• Xác định các yêu cầu thông tin và giải thích tại
sao chúng khó xác định một cách chính xác.
• Giải thích tại sao giai đoạn kiểm thử của sự phát
triển hệ thống lại quan trọng như vậy. Kể tên
và mô tả ba giai đoạn thử nghiệm của một hệ
thống thông tin.
• Xác định vòng đời của hệ thống truyền thống.
Mô tả ưu nhược điểm của nó đối với việc
xây dựng hệ thống.
• Xác định nguyên mẫu hệ thống thông tin. Mô
tả lợi ích và hạn chế của nó. Liệt kê và mô tả
các bước trong quá trình tạo mẫu.
548 Phần bốn Xây dựng và Quản lý Hệ thống

• Xác định một gói phần mềm ứng dụng. Giải 13-5 Các cách tiếp cận mới để xây dựng hệ thống là gì
thích những thuận lợi và khó khăn của việc trong kỷ nguyên công ty kỹ thuật số?

phát triển hệ thống thông tin dựa trên các
gói phần mềm.
• Xác định sự phát triển của người dùng cuối và mô
tả những ưu điểm và nhược điểm của nó. Kể tên
một số chính sách và thủ tục để quản lý phát
triển người dùng cuối.
• Mô tả những thuận lợi và khó khăn của việc
sử dụng thuê ngoài để xây dựng hệ thống
thông tin.
• Xác định phát triển ứng dụng nhanh (RAD), phát
triển nhanh và DevOps và giải thích cách chúng
có thể tăng tốc độ xây dựng hệ thống.
• Giải thích cách phát triển dựa trên thành phần và
các dịch vụ web giúp các công ty xây dựng và
nâng cao hệ thống thông tin của họ.
• Giải thích các tính năng của phát triển ứng
dụng di động và thiết kế web đáp ứng.

Câu hỏi thảo luận

13-6 Tại sao lựa chọn phát triển hệ thống 13-8 Ưu điểm của web đáp ứng là gì
MyLabMIS tiếp cận một quyết định kinh doanh quan trọng? Ai MyLabMIS thiết kế so với ứng dụng gốc hoặc thiết bị di động
nên tham gia vào quá trình lựa chọn? trang mạng?

13-7 Những lợi ích và rủi ro của nội địa là gì

MyLabMIS outsourcing và outsourcing ra nước ngoài?

Các dự án MIS thực hành

Các dự án trong phần này cung cấp cho bạn kinh nghiệm thực tiễn về phân tích quy trình kinh doanh, thiết kế và xây
dựng hệ thống khách hàng cho việc bán ô tô và phân tích các yêu cầu về thông tin trang web.

Các vấn đề về quyết định quản lý

13-9 Với một khoản phí bổ sung, khách hàng mua từ cửa hàng thiết bị trực tuyến Appliancesdirect.com trong
Ở Anh, chẳng hạn như máy giặt, có thể mua hợp đồng dịch vụ ba năm. Hợp đồng cung cấp dịch vụ sửa chữa
miễn phí và các bộ phận cho thiết bị được chỉ định bằng cách sử dụng nhà cung cấp dịch vụ được ủy quyền. Khi
một người có hợp đồng dịch vụ Appliancesdirect cần sửa chữa một thiết bị, chẳng hạn như máy giặt, họ sẽ gọi
cho bộ phận Sửa chữa & Phụ tùng của công ty để lên lịch hẹn. Bộ phận thực hiện cuộc hẹn và cung cấp cho
người gọi ngày và thời gian gần đúng của cuộc hẹn. Kỹ thuật viên sửa chữa đến trong khung thời gian được chỉ
định và chẩn đoán sự cố. Nếu vấn đề là do một bộ phận bị lỗi, kỹ thuật viên có thể thay thế bộ phận đó nếu anh
ta đang mang bộ phận đó bên mình hoặc yêu cầu bộ phận thay thế. Nếu bộ phận không có trong kho, nó sẽ đặt
hàng một bộ phận và cho khách hàng một khoảng thời gian gần đúng khi bộ phận đó sẽ đến nơi. Phần được
vận chuyển trực tiếp cho khách hàng. Sau khi linh kiện đã đến nơi, khách hàng phải gọi cho Gia Dụng Direct để
hẹn kỹ thuật viên sửa chữa thay thế linh kiện đã đặt hàng lần thứ hai. Quá trình này rất dài. Có thể mất hai tuần
để lên lịch cho chuyến thăm sửa chữa đầu tiên, hai tuần nữa để đặt hàng và nhận bộ phận được yêu cầu, và một
tuần nữa để lên lịch cho chuyến thăm sửa chữa thứ hai sau khi bộ phận đã đặt hàng đã được nhận.

• Lập sơ đồ quy trình hiện có.

• Tác động của quy trình hiện tại đối với hiệu quả hoạt động của Sears và các mối quan hệ với khách hàng là gì?
• Những thay đổi nào có thể được thực hiện để làm cho quá trình này hiệu quả hơn? Làm thế nào hệ thống thông tin có thể
hỗ trợ những thay đổi này? Sơ đồ hóa quá trình cải tiến.

13-10 Ban quản lý tại công ty hóa chất nông nghiệp của bạn không hài lòng với việc lập kế hoạch sản xuất.
Kế hoạch sản xuất được lập bằng cách sử dụng những dự đoán tốt nhất về nhu cầu đối với từng sản phẩm, dựa
trên số lượng từng sản phẩm đã được đặt hàng trong quá khứ. Nếu khách hàng đặt hàng đột xuất hoặc yêu cầu
thay đổi đơn hàng hiện có sau khi đã đặt thì không có cách nào để điều chỉnh kế hoạch sản xuất. Các
 Chương 13 Xây dựng hệ thống thông tin 549

công ty có thể phải thông báo với khách hàng rằng họ không thể lấp đầy đơn đặt hàng của họ hoặc có thể tốn thêm chi phí duy trì hàng tồn kho
bổ sung để ngăn chặn tình trạng hết hàng.
Vào cuối mỗi tháng, các đơn đặt hàng được tổng hợp và nhập thủ công vào hệ thống lập kế hoạch sản xuất
của công ty. Dữ liệu từ hệ thống sản xuất và tồn kho của tháng trước được nhập thủ công vào hệ thống quản lý đơn
đặt hàng của công ty. Các nhà phân tích từ bộ phận bán hàng và bộ phận sản xuất phân tích dữ liệu từ các hệ thống
tương ứng của họ để xác định mục tiêu bán hàng và mục tiêu sản xuất cần đạt được cho tháng tiếp theo. Các ước tính
này thường khác nhau. Sau đó, các nhà phân tích họp lại với nhau tại một cuộc họp lập kế hoạch cấp cao để điều chỉnh
các mục tiêu sản xuất và bán hàng nhằm tính đến các mục tiêu của quản lý cấp cao về thị phần, doanh thu và lợi
nhuận. Kết quả của cuộc họp là một lịch trình tổng thể sản xuất cuối cùng.
Toàn bộ quá trình lập kế hoạch sản xuất mất 17 ngày làm việc để hoàn thành. Chín ngày trong số này
được yêu cầu nhập và xác thực dữ liệu. Những ngày còn lại được dành để phát triển và đối chiếu các mục tiêu
sản xuất và bán hàng và hoàn thành lịch trình tổng thể sản xuất.
• Vẽ sơ đồ quy trình lập kế hoạch sản xuất hiện có.
• Phân tích các vấn đề mà quá trình này tạo ra cho công ty.
• Làm thế nào một hệ thống doanh nghiệp có thể giải quyết những vấn đề này? Nó có thể giảm chi phí bằng những cách nào? Sơ đồ
quy trình lập kế hoạch sản xuất có thể trông như thế nào nếu công ty triển khai phần mềm doanh nghiệp.

Cải thiện việc ra quyết định: Sử dụng phần mềm cơ sở dữ liệu để thiết kế hệ thống khách hàng cho bán hàng tự
động

Kỹ năng phần mềm: Thiết kế cơ sở dữ liệu, truy vấn, báo cáo và biểu mẫu Kỹ năng
kinh doanh: Trưởng nhóm bán hàng và phân tích khách hàng

13-11 Dự án này yêu cầu bạn thực hiện phân tích hệ thống và sau đó thiết kế giải pháp hệ thống bằng cách sử dụng cơ sở dữ liệu
phần mềm.
Đại lý ô tô Burrows chuyên bán các loại xe mới của Toyota ở Sheffield, Anh. Công ty quảng cáo trên các
tờ báo địa phương và được liệt kê là đại lý ủy quyền trên trang web Toyota và các trang web lớn khác dành cho
người mua ô tô. Công ty được hưởng lợi từ danh tiếng truyền miệng tốt ở địa phương và sự công nhận tên tuổi.

Burrows không tin rằng họ có đủ thông tin về khách hàng của mình. Nó không thể dễ dàng xác định những khách
hàng tiềm năng nào đã mua hàng tự động, cũng như không thể xác định những điểm tiếp xúc của khách hàng đã tạo ra số
lượng khách hàng tiềm năng lớn nhất hoặc doanh số bán hàng thực tế để nó có thể tập trung quảng cáo và tiếp thị nhiều hơn
vào các kênh tạo ra nhiều doanh thu nhất. Người mua có đang khám phá Burrows từ các quảng cáo trên báo, từ truyền miệng
hay từ Web không?
Chuẩn bị báo cáo phân tích hệ thống mô tả chi tiết vấn đề của Burrows và giải pháp hệ thống có thể được thực hiện
bằng phần mềm quản lý cơ sở dữ liệu PC. Sau đó sử dụng phần mềm cơ sở dữ liệu để phát triển một giải pháp hệ thống đơn
giản.

Đạt được sự Xuất sắc trong Hoạt động: Phân tích Yêu cầu về Thiết kế Trang web và Thông tin
Kỹ năng phần mềm: Phần mềm trình duyệt web
Kỹ năng kinh doanh: Phân tích yêu cầu thông tin, thiết kế trang web
13-12 Truy cập trang web mà bạn lựa chọn và khám phá nó một cách kỹ lưỡng. Chuẩn bị một báo cáo phân tích các chức năng khác nhau
được cung cấp bởi trang web đó và các yêu cầu thông tin của nó. Báo cáo của bạn nên trả lời những câu hỏi sau: Trang
web thực hiện những chức năng nào? Nó sử dụng dữ liệu gì? Đầu vào, đầu ra và quy trình của nó là gì? Một số thông
số kỹ thuật thiết kế khác của nó là gì? Trang web có liên kết với bất kỳ hệ thống nội bộ hoặc hệ thống của các tổ chức
khác không? Giá trị nào mà trang web này cung cấp cho công ty?
Dự án hợp tác và làm việc theo nhóm
Chuẩn bị thông số kỹ thuật thiết kế trang web

13-13 Với ba hoặc bốn người bạn cùng lớp của bạn, hãy chọn một hệ thống được mô tả trong văn bản này sử dụng web. Xem lại
trang web cho hệ thống bạn chọn. Sử dụng những gì bạn đã học được từ trang web và mô tả trong cuốn sách này để
chuẩn bị một báo cáo mô tả một số thông số kỹ thuật thiết kế cho hệ thống bạn chọn. Nếu có thể, hãy sử dụng Google
Tài liệu và Google Drive hoặc Google Sites để động não, sắp xếp và phát triển bản trình bày kết quả của bạn cho lớp
học.
550 Phần bốn Xây dựng và Quản lý Hệ thống
Công thức của ConAgra cho một hệ thống nguồn nhân lực tốt hơn
NGHIÊN CỨU TÌNH HUỐNG
Bạn có bỏng ngô Chef Boyardee Ravioli hoặc Orville
Redenbacher trong tủ đựng thức ăn của bạn hoặc Lựa chọn
lành mạnh hoặc cốm gà Banquet trong tủ đông của bạn
không? Nếu vậy, bạn là một trong 99 phần trăm hộ gia đình
ở Hoa Kỳ sử dụng các sản phẩm thực phẩm của ConAgra.
ConAgra Foods Inc., có trụ sở chính tại Omaha, Nebraska, là
một trong những công ty thực phẩm lớn nhất Bắc Mỹ, cung
cấp các bữa ăn nhanh chóng, tiện lợi, món ngon và đồ ăn
nhẹ với các thương hiệu như Libbys, Banquet, LaChoy,
Hunts, Healthy Choice và Blue Bonnet. Ba mươi hai thương
hiệu của ConAgra chiếm hơn 100 triệu đô la doanh thu bán
lẻ hàng năm.
ConAgra dựa vào 33.000 nhân viên để đảm bảo rằng các
kệ hàng siêu thị và hàng tạp hóa luôn chứa đầy sản phẩm
của mình và ban lãnh đạo coi nguồn nhân lực là yếu tố cần
thiết cho sự thành công của nó. Giống như nhiều công ty
hướng tới tương lai, ConAgra nhận ra tầm quan trọng của
nguồn nhân lực đối với thành công chung của công ty và
khả năng công ty có đúng người khi theo đuổi chiến lược
kinh doanh của mình. Công nghệ được kỳ vọng sẽ đóng
một vai trò lớn hơn nữa trong tương lai trong việc giúp
công ty tuyển dụng, giữ chân, phát triển và quản lý những
người lao động mà công ty cần.
Cho đến gần đây, ConAgra vẫn chưa có công nghệ phù
hợp để thu được giá trị tối đa từ tài năng và chuyên môn
của các nhân viên làm công ăn lương theo giờ. Nó có một
hệ thống cốt lõi cho các chức năng nguồn nhân lực (HR) cơ
bản, nhưng nó cũng có các hệ thống riêng biệt cho các
chức năng HR như đãi ngộ nhân viên, phát triển, tuyển
dụng, lập kế hoạch kế nhiệm và đánh giá nhân tài. Các hệ
thống này tạo ra thông tin rời rạc và không thể hỗ trợ quan
điểm của toàn công ty về các quy trình của nhân viên hoặc
nguồn nhân lực. Một số hệ thống này dựa trên các sản
phẩm phần mềm kinh doanh thương mại, và một số hệ
thống khác là cây nhà lá vườn. Các hệ thống này hoạt động
tốt nhưng chỉ đến một thời điểm vì chúng không được tích
hợp. Điều đó có nghĩa là dữ liệu từ một hệ thống không thể
được kết hợp dễ dàng với dữ liệu từ một hệ thống khác để
báo cáo và phân tích tài năng sâu sắc hơn hoặc để có được
bức tranh toàn cảnh về nhân viên. Không có hệ thống
trung tâm để lưu trữ và quản lý dữ liệu nên nhân viên nhân
sự thường phải trích xuất thông tin từ nhiều hệ thống và
ghép các báo cáo lại với nhau theo cách thủ công. Công ty
cũng phải trả tiền cho nhiều nhóm hệ thống thông tin để
hỗ trợ các hệ thống này.
Tất cả đã thay đổi vào năm 2013 khi công ty quyết
định loại bỏ hầu hết các hệ thống nhân sự hiện có và
triển khai hệ thống quản lý nhân tài toàn diện được
tích hợp với hệ thống nhân sự cốt lõi tại chỗ. Hệ
thống quản lý nhân tài bao gồm các mô-đun tích hợp
chạy trên nền tảng đám mây. ConAgra gọi dự án xây
dựng hệ thống quản lý nhân tài mới là “My Recipe”.
Mục tiêu chính của My Recipe là lưu trữ và chia sẻ tất cả dữ
liệu lực lượng lao động trong một hệ thống dựa trên đám mây
tích hợp, trung tâm duy nhất. Một biện pháp khác là giảm bớt
sự dư thừa dữ liệu, độ phức tạp và hiệu quả hoạt động bằng
cách tập trung dữ liệu để chúng dường như đến từ một nguồn.
Một phương pháp khác là cung cấp các công cụ và quy trình
thân thiện với người dùng giúp người quản lý và nhân viên dễ
dàng trao đổi ý nghĩa về hiệu suất và sự phát triển nghề
nghiệp. Một yêu cầu khác là khả năng cung cấp ảnh chụp
nhanh về đội ngũ nhân tài hiện tại của ConAgra và cho thấy nó
đang phát triển như thế nào để đáp ứng nhu cầu kinh doanh
trong tương lai. Một hệ thống như vậy được kỳ vọng sẽ thu hút
nhân viên và quản lý tốt hơn, cung cấp nhiều dữ liệu hữu ích
hơn cho nhân viên nhân sự, cải thiện quản lý nhân tài và tăng
năng suất.
Sau quá trình đánh giá nhà cung cấp kỹ lưỡng,
ConAgra thu hẹp tìm kiếm thành ba nhà cung cấp và
sau đó chọn SuccessFactors. SuccessFactors là nhà
cung cấp toàn cầu phần mềm dựa trên đám mây thuộc
sở hữu của SAP để quản lý nguồn nhân lực. Bộ ứng
dụng quản lý nguồn nhân lực của nó có hệ thống quản
lý học tập (LMS), quản lý hiệu suất, phần mềm tuyển
dụng, phần mềm theo dõi ứng viên, lập kế hoạch kế
nhiệm, quản lý nhân tài và phân tích nhân sự cùng với
các công cụ cộng tác và kinh doanh xã hội để giúp các
tổ chức tối đa hóa sự phát triển và hiệu suất của nhân
viên. Ban quản lý tin rằng SuccessFactors vượt trội hơn
vì nó cung cấp giao diện người dùng dễ sử dụng và có
thể tùy chỉnh để hỗ trợ nhân viên và ban quản lý tự
phục vụ bằng cách sử dụng hệ thống. SuccessFactors
cũng được tích hợp với các sản phẩm SAP khác và các
sản phẩm của bên thứ ba.
ConAgra đã triển khai My Recipe trong ba giai đoạn trong
khoảng thời gian 15 tháng. Trong giai đoạn đầu tiên, hoàn
thành vào giữa năm 2013, ConAgra đã nâng cấp giao diện
người dùng tổng thể và triển khai các mô-đun Học tập và Kế
thừa & Phát triển của SuccessFactors. Trong giai đoạn hai,
hoàn thành vào cuối năm 2013, công ty

đã triển khai SAP SuccessFactors Phân tích lực lượng lao
động, Lập kế hoạch lực lượng lao động, Tiếp thị tuyển
dụng và Quản lý tuyển dụng. Trong giai đoạn cuối cùng,
hoàn thành vào giữa năm 2014, ConAgra đã triển khai
mô-đun Phần thưởng của SuccessFactors và bản cập
nhật cho Hiệu suất & Mục tiêu của SuccessFactors, bao
gồm chức năng hiệu chuẩn xếp hạng hiệu suất. (Hiệu
chuẩn là một quá trình để đạt được sự nhất quán hơn
trong cách phân phối xếp hạng đánh giá hiệu suất.) Hệ
thống SuccessFactors mới đã thay thế tám hệ thống
nguồn nhân lực cũ, giảm đáng kể lượng dữ liệu nhân sự
được lưu trữ trong các tệp thủ công và cung cấp các
công cụ mới cho các nhà quản lý và nhân viên lấy thông
tin và báo cáo trực tiếp từ hệ thống của riêng họ.
Nhóm My Recipe đã chọn ngày mục tiêu triển khai
trùng với thời gian trong năm mà các quy trình được
chỉ định thường được thực hiện. Ví dụ: việc triển khai
phần mềm Kế thừa & Phát triển SuccessFactors được
tính vào thời điểm công ty tiến hành đánh giá nhân
tài hàng năm. Việc triển khai hệ thống theo từng giai
đoạn giúp dự án tồn tại và có liên quan, đồng thời
nhân viên có thể dễ dàng hiểu cách một mô-đun
được xây dựng trên mô-đun tiếp theo. Các mốc thời
gian của dự án cũng tạo điều kiện thuận lợi cho việc
áp dụng hệ thống vì người dùng đã được tiếp xúc
ngay từ sớm với bộ phận nhân lực một cửa và ngày
càng quan tâm đến việc thấy hệ thống được hoàn
thiện. Bản ghi nhật ký hệ thống cho thấy người dùng
HR trung bình truy cập vào một số khía cạnh của giải
pháp SuccessFactors khoảng 100 lần mỗi năm. Khi
ConAgra có hệ thống nhân sự phân mảnh,
Sau khi được triển khai đầy đủ, My Recipe giúp ConAgra
có thể nắm bắt, lưu trữ và chia sẻ việc lập kế hoạch kế
nhiệm, đánh giá nhân tài và các dữ liệu khác mà trước đây
không thể truy cập và không thể chia sẻ. Nó trao quyền cho
nhân viên để chủ động theo dõi các nhiệm vụ, hiệu suất, sự
phát triển nghề nghiệp và các cơ hội của riêng họ, và nó
chuẩn hóa các quy trình kinh doanh nhân sự trong suốt
vòng đời của nhân viên. Hệ thống mới giúp nhân viên nhân
sự có thể tập trung vào các vấn đề lập kế hoạch nhân lực
thay vì quản lý nhân viên hàng ngày theo chiến thuật và lưu
trữ hồ sơ. My Recipe cũng loại bỏ tám hệ thống nhân sự kế
thừa và những gánh nặng hành chính liên quan và sự kém
hiệu quả của chúng.
Một trong những cải tiến hệ thống mới là khả năng
liên kết hồ sơ bảng lương của nhân viên (được xử lý
trong hệ thống nhân sự cốt lõi của ConAgra) với một ô
trên màn hình chính của SuccessFactors, cho phép
nhân viên xem trực tiếp hồ sơ bảng lương của họ từ My
Recipe. Các ô màn hình chính khác, có thể dễ dàng
Chương 13 Xây dựng hệ thống thông tin 551
tùy chỉnh, cung cấp quyền truy cập vào dữ liệu hiệu suất
và sự nghiệp của nhân viên theo cách dễ hiểu. Tính dễ
sử dụng còn được thúc đẩy bởi các lời nhắc tích hợp. Ví
dụ: một người quản lý đang xem các mục tiêu của nhân
viên có thể được cảnh báo rằng nhân viên đó có một
cuộc đánh giá nhân tài sắp tới. Bằng cách tập trung dữ
liệu nhân viên và cung cấp dữ liệu dễ dàng hơn, công ty
có thể xem mỗi nhân viên phù hợp với các kế hoạch cá
nhân, nhóm và toàn công ty liên quan đến hiệu suất, kế
thừa và phát triển như thế nào. Nói cách khác, hệ thống
giúp cho nguồn nhân lực có thể hoạt động chiến lược
hơn và điều chỉnh lực lượng lao động của ConAgra chính
xác hơn với các mục tiêu chung của công ty.
Không dễ dàng để phát triển một hệ thống tích hợp
đầy đủ với các quy trình chung của toàn công ty.
ConAgra đã phải dành thời gian đáng kể để xác định và
đánh giá các quy trình hiện có của mình và quyết định
cái nào nên được giữ lại và cái nào cần thay đổi. Các quy
trình phải được ánh xạ với các quy trình kinh doanh
được hỗ trợ bởi phần mềm SuccessFactors. Điều quan
trọng là phải biết từng quy trình của ConAgra sẽ trông
như thế nào khi hệ thống SuccessFactors được triển
khai và hệ thống mới chạy trên đám mây.
Một thách thức khác là xử lý phân tích và báo cáo.
Việc báo cáo rất khó khăn khi hệ thống của ConAgra
bị phân mảnh vì rất khó để tập hợp dữ liệu cần thiết
từ nhiều nguồn khác nhau. Khi công ty nhận ra rằng
hệ thống mới sẽ tạo ra dữ liệu nguồn nhân lực hữu
ích hơn và có thể truy xuất được như thế nào, dự án
đã được chuyển hướng để chú ý hơn đến báo cáo và
phân tích và đảm bảo hệ thống được thiết kế để
cung cấp dữ liệu cần thiết cho mục đích này.
ConAgra đã khai thác chuyên môn của các chuyên gia
tư vấn PricewaterhouseCoopers (PwC) để thực hiện. Họ
có thể nhanh chóng tìm hiểu về nhu cầu của ConAgra và
áp dụng kiến thức đó cùng với kiến thức chuyên môn
của họ vào dự án. Ví dụ, PwC tự làm chuyên gia về cấu
trúc bồi thường của ConAgra và sử dụng kiến thức đó
để cấu hình hệ thống cho phù hợp. Họ cũng mang đến
chuyên môn của mình trong các dự án hệ thống đám
mây.
Hệ thống SuccessFactors mới đã giúp ConAgra được bao
nhiêu? Theo KC Bradley, Giám đốc Quản lý Nhân tài của
ConAgra, SuccessFactors đã giúp đưa nhân sự lên một tầm
cao mới tại công ty của cô. Hệ thống đã giúp tạo điều kiện
thuận lợi cho các cuộc trò chuyện giữa người quản lý và
nhân viên và trang bị cho người quản lý thông tin mà họ có
thể trình bày với cấp quản lý cao hơn về cách mỗi nhân viên
đóng góp vào mục tiêu kinh doanh của tổ chức và ảnh
hưởng đến
552 Phần bốn Xây dựng và Quản lý Hệ thống

dòng dưới cùng. Giờ đây, mọi người đều có thể biết liệu
có đúng người trong toàn bộ tổ chức hay không.
Nguồn: Ken Murphy, “ConAgra Foods Fine-Tunes Recipe for Enhanced HR,”
SAP Insider Profiles, ngày 1 tháng 10 năm 2015; www. conagra.com, truy cập
ngày 21 tháng 2 năm 2016; www.successfactors. com, truy cập ngày 21 tháng
2 năm 2016; và “ConAgra Foods: Nhà lãnh đạo Thực phẩm Tìm ra Công thức
Đúng để Thúc đẩy Quản lý Thay đổi với Giải pháp SuccessFactors,” SAP, 2015.
CÂU HỎI NGHIÊN CỨU TÌNH HUỐNG
13-14 Phân tích các vấn đề của ConAgra với hệ thống cũ của nó-
tems. Yếu tố quản lý, tổ chức và công nghệ
nào chịu trách nhiệm cho những
các vấn đề? Tác động kinh doanh của những
vấn đề này là gì?
13-15 Liệt kê và mô tả thông tin yêu cầu-
ments of My Recipe.
13-16 Các loại phương pháp xây dựng hệ thống và
ConAgra đã sử dụng các công cụ nào để xây dựng hệ thống của mình?
13-17 ConAgra đã thực hiện những bước nào để đảm bảo
Công thức của tôi đã thành công?
13-18 Những lợi ích của hệ thống mới là gì?
Nó đã thay đổi các hoạt động vận hành và ra quyết
định như thế nào tại ConAgra? Giải pháp hệ thống này
thành công như thế nào?

Của tôiPhòng thí nghiệm MIS

Đi tới phần Bài tập của MyLab MIS để hoàn thành các bài tập viết này.

13-19 Mô tả bốn chiến lược chuyển đổi hệ thống.

13-20 Mô tả vai trò của người dùng cuối trong việc phát triển hệ thống bằng cách sử dụng vòng đời hệ thống truyền thống, tạo mẫu,
gói phần mềm ứng dụng và phát triển người dùng cuối.

Chương 13 Tài liệu tham khảo
“5 Xu hướng DevOps Các Doanh nghiệp Nên Áp dụng trong Năm nay.”
Itbusinessedge.com, truy cập ngày 31 tháng 3 năm 2016.
Armstrong, Deborah J. và Bill C. Hardgrove. “Sự hiểu biết
Học theo hướng tư duy: Sự chuyển đổi sang phát triển theo hướng
đối tượng. ” MIS hàng quý 31, số 3 (tháng 9 năm 2007).
Aron, Ravi, Eric K.Clemons và Sashi Reddi. "Đúng rồi
Gia công phần mềm: Hiểu và Quản lý Rủi ro. ” Tạp chí Hệ
thống thông tin quản lý 22, số 1 (Mùa hè 2005).
Ashrafi, Noushin và Hessam Ashrafi. Hệ thống hướng đối tượng
Phân tích và thiết kế. Sông Upper Saddle, NY: Prentice-Hall
(2009).
Baily, Martin N. và Diana Farrell. “Bùng nổ những huyền thoại về
Bán hàng. ” McKinsey hàng quý (Tháng 7 năm 2004).
Benaroch, Michael, Yossi Lichtenstein và Lior Fink. "Hợp đồng
Lựa chọn thiết kế và Cân đối chi phí giao dịch Ex Ante và Ex
Post trong Gia công phần mềm phát triển. ”
MIS hàng quý 40 số 1 (tháng 3 năm 2016).
Bossert, Oliver, Chris Ip và Irina Starikova. “Ngoài Agile:
Tổ chức lại CNTT để cung cấp phần mềm nhanh hơn. ” McKinsey &
Company (2015).
Cao, Lan, Kannan Mohan, Balasubramaniam Ramesh, và
Sumantra Sarkar. “Sự phát triển của quản trị: Đạt được sự
xung kích trong Gia công phần mềm CNTT”.Tạp chí Hệ thống
thông tin quản lý 30, số 3 (mùa đông 2014).
DeMarco, Tom. Phân tích có cấu trúc và Đặc tả hệ thống. Mới mẻ
York: Yourdon Press (1978).
Dibbern, Jess, Jessica Winkler và Armin Heinzl. “Giải thích
Sự khác biệt về Chi phí bổ sung của Khách hàng giữa các Dự án Phần mềm được
ủy quyền cho Ấn Độ. ” MIS hàng quý 32, số 2 (tháng 6 năm 2008).
Donnelly, Caroline. “Barclays Banks on Agile và DevOps để
Giải quyết các Đe doạ Cạnh tranh trong Fintech. ” Máy tính hàng tuần
(Ngày 1 tháng 7 năm 2016).
Edberg, Dana T., Polina Ivanova và William Kuechler.
“Mashup phương pháp luận: Khám phá các quy trình được sử
dụng để bảo trì phần mềm.” Tạp chí Hệ thống thông tin quản
lý 28, số 4 (Xuân 2012).
El Sawy, Omar A. Thiết kế lại Quy trình Doanh nghiệp cho Kinh doanh Điện tử.
McGraw-Hill (2001).
Feeny, David, Mary Lacity và Leslie P. Willcocks. "Lấy
Đo lường của các nhà cung cấp dịch vụ thuê ngoài. ” Đánh giá Quản lý MIT
Sloan 46, số 3 (Mùa xuân 2005).
Gefen, David và Erran Carmel. “Thế giới có thực sự phẳng không? Cái nhìn
tại Offshoring trong Thị trường Lập trình Trực tuyến. ” MIS hàng
quý 32, số 2 (tháng 6 năm 2008).
Goo, Jahyun, Rajive Kishore, HR Rao và Kichan Nam. "Các
Vai trò của Thỏa thuận mức độ dịch vụ trong Quản lý quan hệ của Gia
công phần mềm công nghệ thông tin: Một nghiên cứu thực nghiệm. ”
MIS hàng quý 33, số 1 (tháng 3 năm 2009).
Hahn, Eugene D., Jonathan P. Doh, và Kraiwinee Bunyaratavej.
“Sự phát triển của rủi ro trong dịch vụ hệ thống thông tin:
Tác động của rủi ro ở quê hương, sự học hỏi vững chắc và
động lực cạnh tranh.” MIS hàng quý 33, số 3 (tháng 9
2009).
Hammer, Michael và James Champy. Tái cấu trúc
Tập đoàn. New York: HarperCollins (1993).
Hoehle, Hartmut và Viswanath Venkatesh. “Ứng dụng di động
Khả năng sử dụng: Khái niệm hóa và phát triển công cụ. ”
MIS hàng quý 39, số 2 (tháng 6 năm 2015).
Người xây dựng thông tin. “Những Trang Vàng Sử dụng WebFOCUS để
Chứng minh ROI cho các nhà quảng cáo. ” www.informationbuilders. com,
truy cập ngày 30 tháng 3 năm 2015.
Chương 13 Xây dựng hệ thống thông tin 553
Ivari, Juhani, Rudy Hirscheim và Heinz K. Klein. “Một động
Khung phân loại các phương pháp và cách tiếp cận phát triển
hệ thống thông tin. ” Tạp chí Hệ thống thông tin quản lý 17, số
3 (Mùa đông 2000–2001).
Kendall, Kenneth E. và Julie E. Kendall. Phân tích hệ thống và
Thiết kế (Xuất bản lần thứ 9). Thượng Saddle River, NJ: Prentice Hall
(2014). Kindler, Noah B., Vasantha Krishnakanthan và Ranjit Tinaikar.
“Áp dụng Tinh gọn để Phát triển và Bảo trì Ứng
dụng.” McKinsey Quarterly (tháng 5 năm 2007).
Kotlarsky, Julia, Harry Scarbrough và Ilan Oshri. “Điều phối
Kiến thức chuyên môn xuyên ranh giới trong các dự án gia
công phần mềm nước ngoài: Vai trò của việc mã hóa. ” MIS
hàng quý 38 số 2 (tháng 6 năm 2014).
Levina, Natalia và Jeanne W. Ross. “Từ quan điểm của nhà cung cấp:
Khám phá Đề xuất Giá trị trong Gia công phần mềm Công
nghệ Thông tin. ” MIS hàng quý 27, số 3 (tháng 9 năm 2003).
Majchrzak, Ann, Cynthia M. Beath và Ricardo A. Lim.
“Quản lý các cuộc đối thoại với khách hàng trong quá trình thiết kế hệ thống thông tin để
tạo điều kiện thuận lợi cho việc học tập của khách hàng.” MIS Quarterly 29, số 4 (tháng 12
năm 2005).
Mani, Deepa, Anitesh Barua và Andrew Whinston. "Một
Phân tích Thực nghiệm về Tác động của Thiết kế Khả năng Thông tin
đến Hiệu suất Gia công phần mềm Quy trình Kinh doanh. ” MIS hàng
quý 34, số 1 (tháng 3 năm 2010).
Mani, Deepa và Anitesh Barua. “Tác động của Học tập vững chắc đối với
Tạo giá trị trong mối quan hệ thuê ngoài chiến lược. ”
Tạp chí Hệ thống thông tin quản lý 32 số 1 (2015). Mocker,
Martin, Jeanne Ross và Craig Hopkins. ” Cách USAA
Công việc tích hợp sự kiện đã được kiến trúc của nó cho cuộc sống. ”
Điều hành hàng quý của MIS 14, số 4 (2015).
Nelson, H. James, Deborah J. Armstrong và Kay M. Nelson.
“Các mô hình chuyển đổi: Sự chuyển đổi từ truyền thống
sang phát triển hướng đối tượng.” Tạp chí Hệ thống thông
tin quản lý 25, số 4 (Xuân 2009).
Chào, Stephanie. “Các chi phí tiềm ẩn của việc thuê ngoài nước ngoài,”
Tạp chí CIO (1 tháng 9 năm 2003).
Ozer, Muammer và Doug Vogel. “Mối quan hệ được ngữ cảnh hóa
Giữa Chia sẻ Kiến thức và Hiệu suất trong Phát triển Phần
mềm. ” Tạp chí Hệ thống thông tin quản lý
32, số 2 (2015).
Pollock, Neil và Sampsa Hyysalo. “Việc trở thành người dùng:
Vai trò của Tác nhân Tham chiếu trong việc Định hình Mua lại và
Phát triển Hệ thống Doanh nghiệp Đóng gói. ” MIS hàng quý 38,
số 2 (tháng 6 năm 2014).
Saunders, Adam và Erik Brynjolfsson. “Thông tin có giá trị
Tài sản vô hình liên quan đến công nghệ. ” MIS hàng quý 40 số 1 (tháng
3 năm 2016).
Sircar, Sumit, Sridhar P. Nerur và Radhakanta Mahapatra.
“Cách mạng hay Tiến hóa? So sánh giữa các phương pháp phát
triển hệ thống có cấu trúc và hướng đối tượng. ”MIS hàng quý
25, số 4 (tháng 12 năm 2001).
Su, Ning, Natalia Levina và Jeanne W. Ross. "Cái đuôi dài
Chiến lược cho Gia công phần mềm CNTT. ” Đánh giá Quản lý MIT Sloan
(Mùa đông 2016).
Valacich, Joseph A. và Joey George. Phân tích hệ thống hiện đại và
Thiết kế (Xuất bản lần thứ 7). Thượng Saddle River, NJ: Prentice-Hall
(2014). Yourdon, Edward và LL Constantine.Thiết kế có cấu trúc. Mới mẻ
York: Yourdon Press (1978).
 14
CHƯƠNG

Quản lý dự án
Mục tiêu học tập
Sau khi đọc chương này, bạn sẽ có thể trả lời những câu hỏi sau:
14-1 Các mục tiêu của quản lý dự án là gì và tại sao nó lại cần thiết
trong việc phát triển hệ thống thông tin?

14-2 Những phương pháp nào có thể được sử dụng để lựa chọn và đánh giá thông tin
dự án hệ thống và điều chỉnh chúng phù hợp với mục tiêu kinh doanh của công ty?

14-3 Làm thế nào các doanh nghiệp có thể đánh giá giá trị kinh doanh của hệ thống thông tin?

14-4 Các yếu tố rủi ro chính trong các dự án hệ thống thông tin là gì và
làm thế nào chúng có thể được quản lý?

MyLab MIS™
Thăm nom mymislab.com cho mô phỏng, hướng dẫn và các bài toán cuối chương.

CÁC TRƯỜNG HỢP CHƯƠNG

Intuit tính đến quản lý dự án

Dịch vụ Y tế Quốc gia có thể hoạt động không cần giấy tờ không?

Hilti AG: Kết hợp mọi thứ với Quản lý Dự án Mới

Công cụ

Khởi đầu run rủi cho Healthcare.gov

CÁC TRƯỜNG HỢP VIDEO

Blue Cross Blue Shield: Dự án điện toán thông minh hơn

Những thách thức trong quản lý dự án của NASA

554
 Intuit tính đến quản lý dự án

tôingười tiêu dùng và các chuyên gia kinh doanh như TurboTax, QuickBooks,
Quickenntuit là nhà cungBán
và Mint.com. cấpcác
phần mềmcụvànày
công công
vàcụ quảncấp
cung lý tài chính
dịch vụhàng đầu
khách cho
hàng
tạo ra rất nhiều dữ liệu có giá trị. Intuit không gặp vấn đề gì với việc thu thập và lưu trữ những dữ liệu
như vậy, nhưng nó đã phải đối mặt với những trở ngại trong việc thu thập thông tin chi tiết hữu ích từ
tất cả dữ liệu của nó. Đó là lý do tại sao Intuit khởi chạy dự án Intuit Analytics Cloud (IAC) để biến các hồ
dữ liệu thành các nhóm thông tin.
Trước đây, Intuit có một số nhóm dữ liệu và nhiều silo dữ liệu được duy trì tách
biệt với nhau. Mặc dù có nhiều kết quả tích cực mà việc sắp xếp được tạo ra trong
doanh nghiệp hoặc trong cơ sở hạ tầng cho các sản phẩm riêng lẻ, Intuit đã
không thể sử dụng dữ liệu của mình một cách hiệu quả cho toàn bộ tổ chức hoặc
cho tất cả khách hàng của mình. Ban lãnh đạo muốn có một cách tiếp cận toàn
diện hơn để công ty có thể sử dụng dữ liệu tốt hơn để phục vụ khách hàng và
khách hàng có thể có trải nghiệm tốt hơn từ dữ liệu và hiểu rõ hơn về bản thân
họ.
Dự án IAC khác với cách xử lý các dự án tại Intuit theo hai cách chính: thứ nhất,
Đám mây phân tích của Intuit không được thiết kế cho một mục đích kinh doanh cụ
thể. Thay vào đó, nó được cho là một nền tảng chung (toàn diện) phục vụ toàn bộ
công ty cho các đơn vị kinh doanh sử dụng theo bất kỳ cách nào họ chọn. Thứ hai, IAC
ít cấu trúc hơn cơ sở dữ liệu truyền thống để dữ liệu có thể được sử dụng linh hoạt
hơn. (Trong cơ sở dữ liệu truyền thống, người ta thiết kế và tổ chức cơ sở dữ liệu trước
khi nhập bất kỳ dữ liệu nào.) Một hồ dữ liệu, chẳng hạn như IAC, hoàn toàn ngược lại,
kết xuất dữ liệu vào một kho lưu trữ Hadoop lớn mà không thiết kế trước một mô hình
dữ liệu. Cách tiếp cận này cung cấp các công cụ để mọi người phân tích dữ liệu cùng
với định nghĩa cấp cao về dữ liệu nào tồn tại trong hồ. Mọi người xây dựng các chế độ
xem khác nhau vào dữ liệu khi họ tiến hành.

© Lucadp / Fotolia

555
556 Phần bốn Xây dựng và Quản lý Hệ thống

Dự án Intuit IAC yêu cầu sự hợp tác trong toàn bộ công ty vì nó đã kết hợp tất cả
dữ liệu doanh nghiệp của công ty, dữ liệu sản phẩm và dữ liệu của bên thứ ba vào
một nền tảng duy nhất. Các nhà lãnh đạo dự án IAC đã chuyển một số nhóm chức
năng từ nhóm kỹ thuật dữ liệu sang công việc sản xuất cho dự án.

Nhóm dự án rất nhạy cảm với thời hạn và ngân sách dự án. Một trong những
bước quan trọng là chia nhỏ dự án thành những phần dễ xử lý. Việc tổ chức một
dự án lớn thành những phần “vừa ăn” giúp nó có thể mang lại những kết quả có
thể chứng minh được khi dự án tiến triển. Dự án IAC là một nỗ lực trong nhiều năm
và cách tiếp cận “vụ nổ lớn” không khả thi về mặt hoạt động hoặc chính trị. Việc tạo
ra một loạt các sản phẩm nhỏ hơn thay vì một sản phẩm cuối cùng lớn làm cho dự
án dễ quản lý hơn đối với các nhóm dự án. Ngoài ra, các giám đốc điều hành ủy
quyền chi tiêu của dự án cũng sẽ hài lòng bởi một loạt các kết quả có thể chứng
minh được. Sự thành công của dự án nhỏ hơn “cắn câu” có nghĩa là các nhà lãnh
đạo dự án không phải làm việc vất vả để thuyết phục các nhà lãnh đạo đơn vị kinh
doanh tham gia vào dự án.

Nguồn: www.intuit.com, truy cập ngày 16 tháng 1 năm 2016; Curtis Franklin Jr., “Intuit CIO: Thay đổi cách
các dự án được quản lý,”Tuần thông tin, 17 Tháng Mười Hai 2015; Vindu Goel, “Intuit đã phát triển thành
công máy tính cá nhân và trỗi dậy như một công ty phần mềm đám mây,”Thời báo New York,
10 Tháng Tư 2016; andRobert L. Mitchell, “Tám xu hướng lớn trongBigDataAnalytics,”Computerworld,
23 tháng 10 năm 2014.

O chúng mang
Những thách lại lợi chính
thức ích kinh
màdoanh chân
hệ thống chính.
thông tinCó tỷ ra
đặt lệ là
thất bạibảo
đảm rất cao
giữa các dự
án hệ thống thông tin do các tổ chức đã đánh giá sai giá trị kinh doanh của họ hoặc
do các doanh nghiệp không quản lý được sự thay đổi tổ chức xung quanh việc giới
thiệu công nghệ mới. Các dự án xây dựng hoặc cải tiến hệ thống thông tin đòi hỏi
các kỹ thuật tổ chức và quản lý đặc biệt để làm cho chúng có hiệu quả.

Ban quản lý của Intuit đã nhận ra điều này khi tiến hành dự án Intuit Analytics
Cloud (IAC). Công nghệ mới liên quan đến những thay đổi đối với các quy trình kinh
doanh quan trọng (và sử dụng dữ liệu) cũng như phần mềm mới. Intuit đã thành
công với dự án này bởi vì ban lãnh đạo của nó hiểu rõ rằng quản lý dự án mạnh mẽ
và chú ý đến các vấn đề tổ chức là điều cần thiết để thành công.

Sơ đồ mở chương kêu gọi sự chú ý đến những điểm quan trọng được nêu ra bởi
trường hợp này và chương này. Sự tăng trưởng trong tương lai của Intuit kêu gọi sử
dụng dữ liệu bên trong và bên ngoài chuyên sâu hơn trên toàn công ty. Tổ chức tệp lỗi
thời và các hệ thống kế thừa khiến hoạt động nội bộ không hiệu quả, cản trở công ty
cung cấp dịch vụ cấp cao cho khách hàng mà ban lãnh đạo mong muốn. Ban lãnh đạo
đã tập hợp một cách khôn ngoan một nhóm dự án và thiết lập các kết quả và thời hạn
mong muốn. Họ đã chọn chia dự án rất lớn này thành các phần có thể quản lý được,
mỗi phần có thể phân phối, điều này làm cho dự án dễ quản lý hơn và cũng nhận được
sự hỗ trợ từ ban lãnh đạo cao nhất và từ các đơn vị kinh doanh muốn sử dụng IAC.

Dưới đây là một số câu hỏi cần suy nghĩ: Tại sao dự án này thành công? Tại sao
việc chia nhỏ dự án thành các phần nhỏ hơn lại quan trọng?
 Chương 14 Quản lý dự án 557

Việc kinh doanh

Thách thức

• Dữ liệu và hệ thống bị
• Phạm vi dự án đầu tiên
phân mảnh
• Chỉ định nhóm dự án
• Đặt ngân sách dự án Ban quản lý
• Thiết lập thời hạn và thời
hạn giao hàng

• Trên toàn doanh nghiệp Thông tin Việc kinh doanh

nhóm dữ liệu Tổ chức Hệ thống Các giải pháp
• Kinh doanh nhờ vả
lãnh đạo đơn vị
sự tham gia • Tăng khách hàng
Intuit Analytics Cloud
• Tổng hợp dữ liệu toàn doanh Dịch vụ
nghiệp để báo cáo và phân tích • Tăng hiệu quả
• Hadoop Công nghệ
• Các công cụ phân tích

14-1 Các mục tiêu của quản lý dự án là gì,

và tại sao nó lại rất cần thiết trong việc phát
triển hệ thống thông tin?
Có một tỷ lệ thất bại rất cao trong các dự án hệ thống thông tin. Trong hầu hết mọi
tổ chức, các dự án hệ thống thông tin tốn nhiều thời gian và tiền bạc hơn nhiều so
với dự đoán ban đầu, hoặc hệ thống đã hoàn thiện không hoạt động bình thường.
Khi một hệ thống thông tin không đáp ứng được kỳ vọng hoặc tốn quá nhiều chi
phí để phát triển, các công ty có thể không nhận ra bất kỳ lợi ích nào từ việc đầu tư
hệ thống thông tin của họ và hệ thống có thể không giải quyết được các vấn đề mà
nó đã dự kiến. Việc phát triển một hệ thống mới phải được quản lý và sắp xếp cẩn
thận, và cách một dự án được thực hiện có thể là yếu tố quan trọng nhất ảnh
hưởng đến kết quả của nó. Đó là lý do tại sao điều cần thiết là phải có một số kiến
thức về quản lý các dự án hệ thống thông tin và lý do tại sao chúng thành công hay
thất bại.

Dự án bỏ chạy và sự cố hệ thống
Các dự án được quản lý tồi như thế nào? Trung bình, các dự án của khu vực tư
nhân được đánh giá thấp hơn một nửa về ngân sách và thời gian cần thiết để cung
cấp hệ thống hoàn chỉnh đã hứa trong kế hoạch hệ thống. Nhiều dự án được cung
cấp với chức năng bị thiếu (được hứa hẹn sẽ cung cấp trong các phiên bản sau).
Một nghiên cứu chung của McKinsey và Đại học Oxford cho thấy các dự án phần
mềm lớn trung bình chạy vượt ngân sách 66% và vượt tiến độ 33%; có tới 17% dự
án diễn ra tồi tệ đến mức chúng có thể đe dọa sự tồn tại của công ty
(Chandrasekaran, Gudlavalleti và Kaniyar, 2014). Từ 30 đến 40 phần trăm của tất cả
các dự án phần mềm là các dự án “bỏ chạy” vượt xa kế hoạch ban đầu và dự kiến
ngân sách và không thực hiện được như quy định ban đầu.
Như minh họa trong Hình 14.1, một dự án phát triển hệ thống mà không có sự quản lý
thích hợp rất có thể sẽ phải gánh chịu những hậu quả sau:

• Chi phí vượt quá ngân sách

• Thời gian trượt không mong muốn
558 Phần bốn Xây dựng và Quản lý Hệ thống

HÌNH 14.1 HẬU QUẢ CỦA QUẢN LÝ DỰ ÁN NGHÈO

Nếu không có sự quản lý thích hợp, một dự án phát triển hệ thống sẽ mất nhiều thời gian hơn để hoàn thành và
thường vượt quá ngân sách được phân bổ. Hệ thống thông tin kết quả rất có thể là kém hơn về mặt kỹ thuật và
có thể không chứng minh được bất kỳ lợi ích nào cho tổ chức.

• Hiệu suất kỹ thuật kém hơn mong đợi

• Không đạt được những lợi ích như mong đợi

Các hệ thống được tạo ra bởi các dự án thông tin thất bại thường không được sử dụng theo cách
mà chúng đã dự kiến hoặc hoàn toàn không được sử dụng. Người dùng thường phải phát triển
các hệ thống thủ công song song để làm cho các hệ thống này hoạt động. Theo một báo cáo năm
2015 của 1E, công ty phát triển các giải pháp phần mềm để quản lý và giảm chi phí CNTT, 37% tổng
số phần mềm được cài đặt không được sử dụng, gây lãng phí 30 tỷ đô la chỉ riêng ở Hoa Kỳ (1E,
2016).
Thiết kế thực tế của hệ thống có thể không nắm bắt được các yêu cầu kinh
doanh thiết yếu hoặc cải thiện hiệu suất của tổ chức. Thông tin có thể không được
cung cấp đủ nhanh để hữu ích, có thể ở định dạng không thể tiêu hóa và sử dụng,
hoặc có thể đại diện cho các phần dữ liệu sai.
Cách thức mà người dùng doanh nghiệp phi kỹ thuật phải tương tác với hệ thống có thể
quá phức tạp và không khuyến khích. Hệ thống có thể được thiết kế với giao diện người
dùng kém. Cácgiao diện người dùng là một phần của hệ thống mà người dùng cuối tương
tác. Ví dụ, một biểu mẫu nhập liệu trực tuyến hoặc màn hình nhập dữ liệu có thể được sắp
xếp kém đến mức không ai muốn gửi dữ liệu hoặc yêu cầu thông tin. Kết quả đầu ra của hệ
thống có thể được hiển thị ở định dạng quá khó hiểu.
Trang web có thể không khuyến khích khách truy cập khám phá thêm nếu trang web lộn
xộn và được sắp xếp kém, nếu người dùng không thể dễ dàng tìm thấy thông tin họ đang
tìm kiếm hoặc nếu mất quá nhiều thời gian để truy cập và hiển thị trang web trên máy tính
của người dùng.
Ngoài ra, dữ liệu trong hệ thống có thể có mức độ không chính xác hoặc không nhất quán
cao. Thông tin trong một số lĩnh vực nhất định có thể sai sót hoặc mơ hồ, hoặc có thể không
được tổ chức hợp lý cho các mục đích kinh doanh. Thông tin cần thiết cho một chức năng
kinh doanh cụ thể có thể không truy cập được vì dữ liệu không đầy đủ.

Mục tiêu quản lý dự án

MỘT dự án là một chuỗi các hoạt động liên quan được lên kế hoạch nhằm đạt được
một mục tiêu kinh doanh cụ thể. Các dự án về hệ thống thông tin bao gồm việc phát
triển các hệ thống thông tin mới, cải tiến các hệ thống hiện có hoặc nâng cấp hoặc thay
thế cơ sở hạ tầng công nghệ thông tin (CNTT) của công ty.
Quản lý dự án đề cập đến việc áp dụng kiến thức, kỹ năng, công cụ và kỹ thuật
để đạt được các mục tiêu cụ thể trong giới hạn ngân sách và thời gian quy định.
Các hoạt động quản lý dự án bao gồm lập kế hoạch công việc, đánh giá rủi ro, ước
tính nguồn lực cần thiết để hoàn thành công việc, tổ chức công việc, thu nhận nhân
lực và vật lực, phân công nhiệm vụ, chỉ đạo hoạt động, kiểm soát việc thực hiện dự
án, báo cáo tiến độ và phân tích kết quả. Cũng như trong các lĩnh vực kinh doanh
khác, quản lý dự án hệ thống thông tin phải đối phó với năm biến số chính: phạm
vi, thời gian, chi phí, chất lượng và rủi ro.
 Chương 14 Quản lý dự án 559

Phạm vi xác định công việc được hoặc không được bao gồm trong một dự án. Ví dụ:
phạm vi của một dự án đối với hệ thống xử lý đơn đặt hàng mới có thể bao gồm các mô-
đun mới để nhập đơn đặt hàng và chuyển chúng đến sản xuất và kế toán nhưng không
có bất kỳ thay đổi nào đối với các tài khoản phải thu, sản xuất, phân phối hoặc hệ thống
kiểm soát hàng tồn kho liên quan. Quản lý dự án xác định tất cả các công việc cần thiết
để hoàn thành một dự án thành công và phải đảm bảo rằng phạm vi của dự án không
mở rộng ra ngoài những gì dự định ban đầu.
Thời gian là khoảng thời gian cần thiết để hoàn thành dự án. Quản lý dự án
thường thiết lập khoảng thời gian cần thiết để hoàn thành các thành phần chính
của dự án. Mỗi thành phần này lại được chia nhỏ thành các hoạt động và nhiệm vụ.
Quản lý dự án cố gắng xác định thời gian cần thiết để hoàn thành từng nhiệm vụ
và thiết lập lịch trình hoàn thành công việc.
Trị giá được dựa trên thời gian hoàn thành một dự án nhân với chi phí nhân lực
cần thiết để hoàn thành dự án. Chi phí dự án hệ thống thông tin cũng bao gồm chi
phí phần cứng, phần mềm và không gian làm việc. Quản lý dự án phát triển ngân
sách cho dự án và giám sát các chi phí đang thực hiện của dự án.
Chất lượng là một chỉ số cho biết kết quả cuối cùng của một dự án đáp ứng tốt như
thế nào các mục tiêu do ban quản lý quy định. Chất lượng của các dự án hệ thống
thông tin thường tập trung vào việc cải thiện hiệu suất của tổ chức và việc ra quyết
định. Chất lượng cũng xem xét tính chính xác và kịp thời của thông tin được tạo ra bởi
hệ thống mới và tính dễ sử dụng.
Đặt vào may rủi đề cập đến các vấn đề tiềm ẩn có thể đe dọa sự thành công của
một dự án. Những vấn đề tiềm ẩn này có thể ngăn cản một dự án đạt được các
mục tiêu của nó bằng cách tăng thời gian và chi phí, làm giảm chất lượng đầu ra
của dự án hoặc ngăn dự án hoàn thành. Phần 14.4 mô tả các yếu tố rủi ro quan
trọng nhất đối với hệ thống thông tin.

14-2 Những phương pháp nào có thể được sử dụng để lựa chọn và
đánh giá các dự án hệ thống thông tin và điều chỉnh
chúng phù hợp với mục tiêu kinh doanh của công ty?
Các công ty thường được trình bày với nhiều dự án khác nhau để giải quyết vấn đề
và cải thiện hiệu suất. Có rất nhiều ý tưởng cho các dự án hệ thống hơn là nguồn
lực. Các công ty sẽ cần chọn từ nhóm này những dự án hứa hẹn mang lại lợi ích lớn
nhất cho doanh nghiệp. Rõ ràng, chiến lược kinh doanh tổng thể của công ty sẽ
thúc đẩy việc lựa chọn dự án. Các nhà quản lý nên chọn như thế nào trong số tất cả
các phương án?

Cơ cấu quản lý cho các dự án hệ thống

thông tin
Hình 14.2 cho thấy các yếu tố của cấu trúc quản lý cho các dự án hệ thống thông
tin trong một tập đoàn lớn. Nó giúp đảm bảo rằng các dự án quan trọng nhất được
ưu tiên.
Đỉnh cao của cấu trúc này là nhóm hoạch định chiến lược công ty và ban chỉ đạo
hệ thống thông tin. Nhóm hoạch định chiến lược của công ty chịu trách nhiệm phát
triển kế hoạch chiến lược của công ty, có thể yêu cầu phát triển các hệ thống mới.
Thông thường, nhóm này sẽ phát triển các thước đo khách quan về hoạt động của
công ty (được gọi làcác chỉ số hiệu suất chính, được giới thiệu trong Chương 12) và
chọn hỗ trợ các dự án CNTT có thể tạo ra một
560 Phần Bốn Xây dựng và Quản lý Hệ thống

HÌNH 14.2 KIỂM SOÁT QUẢN LÝ CÁC DỰ ÁN HỆ THỐNG

Mỗi cấp quản lý trong hệ thống phân cấp chịu trách nhiệm về các khía cạnh cụ thể của các dự án hệ
thống và cấu trúc này giúp ưu tiên cho các dự án hệ thống quan trọng nhất đối với tổ chức.

cải thiện một hoặc một số chỉ số hiệu suất chính. Các chỉ số hoạt động này được
xem xét và thảo luận bởi ban giám đốc của công ty.
Ban chỉ đạo hệ thống thông tin là nhóm quản lý cấp cao chịu trách nhiệm phát
triển và vận hành hệ thống. Nó bao gồm các trưởng bộ phận từ cả hai lĩnh vực
người dùng cuối và hệ thống thông tin. Ban chỉ đạo xem xét và phê duyệt kế hoạch
cho các hệ thống ở tất cả các bộ phận, tìm cách điều phối và tích hợp các hệ thống,
và đôi khi tham gia vào việc lựa chọn các dự án hệ thống thông tin cụ thể. Nhóm
này cũng có nhận thức sâu sắc về các chỉ số hoạt động chính do các nhà quản lý
cấp cao hơn và ban giám đốc quyết định.

Nhóm dự án được giám sát bởi một nhóm quản lý dự án bao gồm người quản lý hệ
thống thông tin và người quản lý người dùng cuối chịu trách nhiệm giám sát một số dự
án hệ thống thông tin cụ thể. Nhóm dự án chịu trách nhiệm trực tiếp cho dự án hệ
thống riêng lẻ. Nó bao gồm các nhà phân tích hệ thống, các chuyên gia từ các lĩnh vực
kinh doanh người dùng cuối có liên quan, các lập trình viên ứng dụng và có lẽ là các
chuyên gia cơ sở dữ liệu. Sự kết hợp của các kỹ năng và quy mô của nhóm dự án phụ
thuộc vào bản chất cụ thể của giải pháp hệ thống.

Liên kết các dự án hệ thống với kế hoạch kinh doanh

Để xác định các dự án hệ thống thông tin sẽ mang lại giá trị kinh doanh cao nhất,
các tổ chức cần phát triển kế hoạch hệ thống thông tin
hỗ trợ kế hoạch kinh doanh tổng thể của họ và trong đó các hệ thống chiến lược
được đưa vào kế hoạch cấp cao nhất. Kế hoạch đóng vai trò như một lộ trình chỉ ra
hướng phát triển hệ thống (mục đích của kế hoạch), cơ sở lý luận, tình trạng của
các hệ thống hiện tại, những phát triển mới cần xem xét, chiến lược quản lý, kế
hoạch thực hiện và ngân sách (xem Bảng 14.1 ).
 Chương 14 Quản lý dự án 561

BẢNG 14.1 KẾ HOẠCH HỆ THỐNG THÔNG TIN

1. Mục đích của kế hoạch Tổng quan

về nội dung kế hoạch

Tổ chức kinh doanh hiện tại và tổ chức tương lai Các quy

trình kinh doanh chính

Chiến lược quản lý

2. Cơ sở lý luận về kế hoạch kinh doanh

chiến lược Thực trạng

Tổ chức kinh doanh hiện tại

Thay đổi môi trường
Các mục tiêu chính của kế hoạch kinh doanh Kế

hoạch chiến lược của doanh nghiệp

3. Hệ thống hiện tại

Các hệ thống chính hỗ trợ các chức năng và quy trình kinh doanh

Khả năng cơ sở hạ tầng hiện tại

Phần cứng

Phần mềm

Cơ sở dữ liệu

Viễn thông và Internet Khó khăn

đáp ứng yêu cầu kinh doanh Dự kiến
nhu cầu trong tương lai

4. Những sự phát triển mới

Các dự án hệ thống mới

Mô tả dự án
Lý do kinh doanh
Vai trò của ứng dụng trong chiến

lược Yêu cầu khả năng cơ sở hạ tầng mới

Phần cứng

Phần mềm

Cơ sở dữ liệu

Viễn thông và Internet

5. Chiến lược quản lý
Kế hoạch mua lại

Các mốc và thời gian

Cơ cấu lại tổ chức Tổ
chức lại nội bộ Các
biện pháp quản lý
Các sáng kiến đào tạo chính

Chiến lược nhân sự

6. Kế hoạch thực hiện

Dự kiến khó khăn trong quá trình thực hiện

Báo cáo tiến độ

7. Yêu cầu về ngân sách

Yêu cầu
Tiết kiệm tiềm năng

Tài trợ
Chu kỳ mua lại
562 Phần bốn Xây dựng và Quản lý Hệ thống

Kế hoạch bao gồm một tuyên bố về các mục tiêu của công ty và chỉ rõ cách thức
công nghệ thông tin sẽ hỗ trợ việc đạt được các mục tiêu đó. Báo cáo cho thấy các
mục tiêu chung sẽ đạt được như thế nào bởi các dự án hệ thống cụ thể. Nó xác
định các ngày và mốc mục tiêu cụ thể có thể được sử dụng sau này để đánh giá
tiến độ của kế hoạch về số lượng mục tiêu đã thực sự đạt được trong khung thời
gian được chỉ định trong kế hoạch. Kế hoạch chỉ ra các quyết định quản lý quan
trọng liên quan đến việc mua lại phần cứng; viễn thông; tập trung / phân cấp
quyền hạn, dữ liệu và phần cứng; và yêu cầu thay đổi tổ chức. Các thay đổi về tổ
chức cũng thường được mô tả, bao gồm các yêu cầu về quản lý và đào tạo nhân
viên, nỗ lực tuyển dụng, thay đổi trong quy trình kinh doanh và thay đổi về quyền
hạn, cơ cấu hoặc phương thức quản lý.
Để lập kế hoạch hiệu quả, các công ty sẽ cần phải kiểm kê và lập hồ sơ tất cả các
ứng dụng hệ thống thông tin và các thành phần cơ sở hạ tầng CNTT của họ. Đối với
các dự án trong đó lợi ích liên quan đến việc cải tiến việc ra quyết định, người quản
lý nên cố gắng xác định những cải tiến quyết định sẽ cung cấp giá trị bổ sung lớn
nhất cho công ty. Sau đó, họ nên phát triển một bộ thước đo để định lượng giá trị
của thông tin kịp thời và chính xác hơn về kết quả của quyết định. (Xem Chương 12
để biết thêm chi tiết về chủ đề này.)

Yêu cầu thông tin và các chỉ số

hoạt động chính
Để phát triển một kế hoạch hệ thống thông tin hiệu quả, tổ chức phải hiểu rõ về
các yêu cầu thông tin dài hạn và ngắn hạn của mình. Cách tiếp cận chiến lược đối
với các yêu cầu thông tin, phân tích chiến lược hoặc các yếu tố thành công quan
trọng lập luận rằng các yêu cầu thông tin của tổ chức được xác định bởi một số
lượng nhỏ các chỉ số hiệu suất chính (KPI) của các nhà quản lý. KPI được định hình
bởi ngành, công ty, người quản lý và môi trường rộng lớn hơn. Ví dụ: KPI cho một
công ty ô tô có thể là chi phí sản xuất đơn vị, chi phí lao động, năng suất nhà máy,
tỷ lệ làm lại và lỗi, khảo sát nhận diện thương hiệu của khách hàng, xếp hạng chất
lượng JD Power, xếp hạng mức độ hài lòng trong công việc của nhân viên và chi phí
sức khỏe.

Phân tích danh mục đầu tư

Khi các phân tích chiến lược đã xác định được hướng phát triển chung của hệ
thống, phân tích danh mục đầu tư có thể được sử dụng để đánh giá các dự án hệ
thống thay thế. Phân tích danh mục đầu tư kiểm kê tất cả các dự án và tài sản hệ
thống thông tin của tổ chức, bao gồm cơ sở hạ tầng, hợp đồng thuê ngoài và giấy
phép. Danh mục đầu tư vào hệ thống thông tin này có thể được mô tả là có một hồ
sơ rủi ro và lợi ích nhất định đối với công ty (xem Hình 14.3) tương tự như danh
mục tài chính.
Mỗi dự án hệ thống thông tin đều có rủi ro và lợi ích riêng. (Phần 14-4 mô tả các
yếu tố làm tăng rủi ro của các dự án hệ thống). Mặc dù không có hồ sơ lý tưởng
cho tất cả các doanh nghiệp, các ngành thâm dụng thông tin (ví dụ: tài chính) nên
có một vài dự án rủi ro cao, mang lại lợi ích cao để đảm bảo rằng họ luôn cập nhật
công nghệ. Các doanh nghiệp trong các ngành không sử dụng nhiều thông tin nên
tập trung vào các dự án có lợi ích cao, rủi ro thấp.
 Chương 14 Quản lý dự án 563

HÌNH 14.3 MỘT CỔNG HỆ THỐNG

Các công ty nên xem xét danh mục dự án của họ về lợi ích tiềm năng và rủi ro có thể xảy ra. Một số loại dự án
nên được tránh hoàn toàn và những loại khác được phát triển nhanh chóng. Không có lý tưởng
pha trộn. Các công ty trong các ngành khác nhau có hồ sơ khác nhau.

Tất nhiên, mong muốn nhất là các hệ thống có lợi ích cao và rủi ro thấp. Những điều này
hứa hẹn lợi nhuận sớm và rủi ro thấp. Thứ hai, các hệ thống có lợi ích cao, rủi ro cao cần
được kiểm tra; Nên tránh hoàn toàn các hệ thống có lợi ích thấp, rủi ro cao; và các hệ thống
có lợi ích thấp, rủi ro thấp nên được khảo sát lại để có khả năng xây dựng lại và thay thế
chúng bằng các hệ thống mong muốn hơn có lợi ích cao hơn. Bằng cách sử dụng phân tích
danh mục đầu tư, ban quản lý có thể xác định sự kết hợp tối ưu giữa rủi ro đầu tư và phần
thưởng cho các công ty của họ, cân bằng các dự án có mức thưởng cao hơn rủi ro hơn với
các dự án có phần thưởng thấp hơn an toàn hơn. Các công ty nơi phân tích danh mục đầu tư
phù hợp với chiến lược kinh doanh được nhận thấy có lợi tức vượt trội trên tài sản CNTT của
họ, đầu tư CNTT phù hợp hơn với các mục tiêu kinh doanh và phối hợp đầu tư CNTT trong
toàn tổ chức tốt hơn (Jeffrey và Leliveld, 2004).

Mô hình chấm điểm

MỘT mô hình chấm điểm rất hữu ích cho việc lựa chọn các dự án nơi nhiều tiêu chí phải
được xem xét. Nó gán trọng số cho các tính năng khác nhau của hệ thống và sau đó tính
tổng trọng số. Sử dụng Bảng 14.2, công ty phải quyết định trong số hai hệ thống hoạch định
nguồn lực doanh nghiệp (ERP) thay thế. Cột đầu tiên liệt kê các tiêu chí mà những người ra
quyết định sẽ sử dụng để đánh giá hệ thống. Các tiêu chí này thường là kết quả của các cuộc
thảo luận kéo dài giữa nhóm ra quyết định. Thường thì kết quả quan trọng nhất của một mô
hình tính điểm không phải là điểm số mà là sự thống nhất về các tiêu chí được sử dụng để
đánh giá một hệ thống.
Bảng 14.2 cho thấy rằng công ty đặc biệt này coi trọng nhất các khả năng xử lý
đơn đặt hàng, quản lý hàng tồn kho và lưu kho. Cột thứ hai trong Bảng 14.2 liệt kê
các trọng số mà những người ra quyết định gắn với các tiêu chí quyết định. Cột 3
và 5 hiển thị tỷ lệ phần trăm yêu cầu đối với từng chức năng mà mỗi hệ thống ERP
thay thế có thể cung cấp. Điểm của mỗi nhà cung cấp có thể được tính bằng cách
nhân tỷ lệ phần trăm các yêu cầu được đáp ứng cho mỗi chức năng với trọng số
gắn với chức năng đó. Hệ thống ERP B có tổng điểm cao nhất.
Như với tất cả các kỹ thuật “khách quan”, có nhiều đánh giá định tính liên quan
đến việc sử dụng mô hình cho điểm. Mô hình này yêu cầu các chuyên gia hiểu rõ
các vấn đề và công nghệ. Rất thích hợp để xem xét mô hình tính điểm nhiều lần,
thay đổi tiêu chí và trọng số, để xem mức độ nhạy cảm của kết quả đối với những
thay đổi hợp lý trong tiêu chí. Các mô hình tính điểm được sử dụng phổ biến nhất
để xác nhận, hợp lý hóa và hỗ trợ các quyết định thay vì là trọng tài cuối cùng của
việc lựa chọn hệ thống.
564 Phần bốn Xây dựng và Quản lý Hệ thống

BẢNG 14.2 VÍ DỤ VỀ MÔ HÌNH ĐO ĐIỂM CHO MỘT HỆ THỐNG ERP

HỆ THỐNG ERP HỆ THỐNG ERP HỆ THỐNG ERP HỆ THỐNG ERP
TIÊU CHUẨN TRỌNG LƯỢNG MỘT % MỘT ĐIỂM NS % ĐIỂM B

1.0 Xử lý đơn hàng

1.1 Nhập đơn hàng trực tuyến 4 67 268 73 292

1.2 Định giá trực tuyến 4 81 324 87 348
1.3 Kiểm tra hàng tồn kho 4 72 288 81 324
1.4 Kiểm tra tín dụng khách hàng 3 66 198 59 177
1.5 Lập hóa đơn 4 73 292 82 328
Tổng số đơn hàng đang xử lý 1.370 1.469

2.0 Quản lý hàng tồn kho

2.1 Dự báo sản xuất 3 72 216 76 228

2.2 Lập kế hoạch sản xuất 4 79 316 81 324
2.3 Kiểm soát hàng tồn kho 4 68 272 80 320
2.4 Báo cáo 3 71 213 69 207
Tổng quản lý hàng tồn kho 1,017 1,079

3.0Warehousing

3.1 Nhận 2 71 142 75 150

3.2 Chọn / đóng gói 3 77 231 82 246
3.3 Vận chuyển 4 92 368 89 356
Tổng kho 741 752

Tổng cộng 3.128 3.300

14-3 Làm thế nào các công ty có thể đánh giá giá trị kinh doanh của
hệ thông thông tin?
Ngay cả khi một dự án hệ thống hỗ trợ các mục tiêu chiến lược của một công ty và đáp
ứng các yêu cầu về thông tin của người dùng, nó cần phải là một khoản đầu tư tốt cho
công ty. Giá trị của các hệ thống từ góc độ tài chính chủ yếu xoay quanh vấn đề hoàn
vốn đầu tư. Một khoản đầu tư vào hệ thống thông tin cụ thể có tạo ra đủ lợi nhuận để
bù đắp cho chi phí của nó không?

Chi phí và lợi ích của hệ thống thông tin

Bảng 14.3 liệt kê một số chi phí và lợi ích phổ biến hơn của các hệ thống. Những lợi ích
hiển nhiên có thể được định lượng và chỉ định một giá trị tiền tệ. Lợi ích vô hình,
chẳng hạn như dịch vụ khách hàng hiệu quả hơn hoặc ra quyết định nâng cao, không
thể định lượng ngay lập tức nhưng có thể dẫn đến lợi nhuận có thể định lượng được về
lâu dài. Các hệ thống giao dịch và văn thư thay thế lao động và tiết kiệm không gian
luôn tạo ra nhiều lợi ích hữu hình, có thể đo lường được so với hệ thống thông tin quản
lý, hệ thống hỗ trợ ra quyết định và cộng tác được hỗ trợ bởi máy tính
hệ thống làm việc (xem Chương 2 và 11).
 Chương 14 Quản lý dự án 565

BẢNG 14.3 CHI PHÍ VÀ LỢI ÍCH CỦA HỆ THỐNG THÔNG TIN
CHI PHÍ

Phần cứng

Viễn thông
Phần mềm

Dịch vụ
Nhân viên

LỢI ÍCH TANGIBLE (TIẾT KIỆM CHI PHÍ)

Tăng năng suất

Giảm chi phí hoạt động

Giảm lực lượng lao động

Giảm chi phí máy tính Giảm chi

phí cho nhà cung cấp bên ngoài

Giảm chi phí văn thư và nghiệp vụ

Giảm tốc độ tăng chi phí Giảm chi
phí cơ sở vật chất

LỢI ÍCH LIÊN TỤC

Cải thiện việc sử dụng tài sản Cải

thiện kiểm soát nguồn lực Lập kế

hoạch tổ chức được cải thiện Tăng

tính linh hoạt của tổ chức Thông tin

kịp thời hơn

Thêm thông tin

Tăng cường học hỏi về tổ chức Các

yêu cầu pháp lý đạt được Tăng thiện

chí của nhân viên Tăng mức độ hài

lòng trong công việc

Cải thiện khả năng ra quyết định

Hoạt động được cải thiện

Sự hài lòng của khách hàng cao

hơn Hình ảnh công ty tốt hơn

Chương 5 đã giới thiệu khái niệm tổng chi phí sở hữu (TCO), được thiết kế để xác
định và đo lường các thành phần của chi tiêu công nghệ thông tin ngoài chi phí
ban đầu để mua và cài đặt phần cứng và phần mềm. Tuy nhiên, phân tích TCO chỉ
cung cấp một phần thông tin cần thiết để đánh giá một khoản đầu tư vào công
nghệ thông tin vì nó thường không liên quan đến lợi ích, các loại chi phí như chi phí
phức tạp, các yếu tố “mềm” và chiến lược được thảo luận ở phần sau của phần này.

Lập ngân sách vốn cho hệ thống thông tin

Để xác định lợi ích của một dự án cụ thể, bạn sẽ cần tính toán tất cả các chi phí và
lợi ích của nó. Rõ ràng, một dự án mà chi phí vượt quá lợi ích nên bị từ chối. Nhưng
ngay cả khi lợi ích lớn hơn chi phí, vẫn cần phải phân tích tài chính bổ sung để xác
định xem liệu dự án có mang lại lợi nhuận tốt trên vốn đầu tư của công ty hay
không.Lập ngân sách vốn mô hình là một trong những kỹ thuật được sử dụng để
đo lường giá trị đầu tư vào các dự án đầu tư vốn dài hạn.
566 Phần bốn Xây dựng và Quản lý Hệ thống

Phương pháp lập ngân sách vốn dựa trên các thước đo về dòng tiền vào và ra
khỏi công ty; các dự án vốn tạo ra các dòng tiền đó. Chi phí đầu tư cho các dự án hệ
thống thông tin là một dòng tiền ngay lập tức do chi tiêu cho phần cứng, phần
mềm và lao động. Trong những năm tiếp theo, khoản đầu tư có thể tạo ra dòng
tiền bổ sung sẽ được cân bằng bởi dòng tiền thu được từ khoản đầu tư. Dòng tiền
vào có hình thức tăng doanh số bán nhiều sản phẩm hơn (vì các lý do như sản
phẩm mới, chất lượng cao hơn hoặc tăng thị phần) hoặc giảm chi phí trong sản
xuất và hoạt động. Chênh lệch giữa dòng tiền ra và dòng tiền vào được sử dụng để
tính toán giá trị tài chính của một khoản đầu tư. Khi dòng tiền đã được thiết lập,

Các mô hình lập ngân sách vốn chính để đánh giá các dự án CNTT là phương
pháp hoàn vốn, tỷ suất hoàn vốn đầu tư (ROI), giá trị hiện tại ròng và tỷ suất hoàn
vốn nội bộ (IRR). Bạn có thể tìm hiểu thêm về cách các mô hình lập ngân sách vốn
này được sử dụng để biện minh cho các khoản đầu tư vào hệ thống thông tin trong
các Đường hướng học tập cho chương này.

Hạn chế của các mô hình tài chính

Sự tập trung truyền thống vào các khía cạnh tài chính và kỹ thuật của hệ thống thông
tin có xu hướng bỏ qua các khía cạnh xã hội và tổ chức của hệ thống thông tin có thể
ảnh hưởng đến chi phí và lợi ích thực sự của khoản đầu tư. Các quyết định đầu tư vào
hệ thống thông tin của nhiều công ty không xem xét đầy đủ chi phí từ sự gián đoạn tổ
chức do một hệ thống mới tạo ra, chẳng hạn như chi phí đào tạo người dùng cuối, tác
động mà đường cong học tập của người dùng đối với một hệ thống mới đối với năng
suất hoặc thời gian mà người quản lý cần để giám sát các thay đổi mới liên quan đến hệ
thống. Các lợi ích vô hình như các quyết định kịp thời hơn từ một hệ thống mới hoặc
nâng cao khả năng học hỏi và chuyên môn của nhân viên cũng có thể bị bỏ qua trong
phân tích tài chính truyền thống.

14-4 Các yếu tố rủi ro chính trong

các dự án hệ thống thông tin, và chúng có thể
được quản lý như thế nào?
Chúng tôi đã giới thiệu chủ đề về hệ thống thông tin và đánh giá rủi ro trong Chương 8.
Trong chương này, chúng tôi mô tả các rủi ro cụ thể đối với các dự án hệ thống thông
tin và chỉ ra những gì có thể làm để quản lý chúng một cách hiệu quả.

Các khía cạnh của rủi ro dự án

Các hệ thống khác nhau đáng kể về quy mô, phạm vi, mức độ phức tạp và các
thành phần tổ chức và kỹ thuật. Một số dự án phát triển hệ thống có nhiều khả
năng tạo ra các vấn đề mà chúng tôi đã mô tả trước đó hoặc bị chậm trễ vì chúng
có mức độ rủi ro cao hơn nhiều so với những dự án khác. Mức độ rủi ro của dự án
bị ảnh hưởng bởi quy mô dự án, cấu trúc dự án và mức độ chuyên môn kỹ thuật
của nhân viên hệ thống thông tin và nhóm dự án.
• Quy mô dự án. Dự án càng lớn - như được chỉ ra bởi số tiền chi tiêu, quy mô
của nhân viên thực hiện, thời gian được phân bổ để thực hiện và
 Chương 14 Quản lý dự án 567

số lượng đơn vị tổ chức bị ảnh hưởng — rủi ro càng lớn. Các dự án hệ thống
quy mô rất lớn có tỷ lệ thất bại cao hơn từ 50 đến 75 phần trăm so với các dự
án khác vì các dự án đó rất phức tạp và khó kiểm soát. Sự phức tạp về mặt tổ
chức của hệ thống - số lượng đơn vị và nhóm sử dụng nó và mức độ ảnh
hưởng của nó đối với các quy trình kinh doanh - góp phần vào sự phức tạp
của các dự án hệ thống quy mô lớn cũng giống như các đặc tính kỹ thuật,
chẳng hạn như số dòng mã chương trình, độ dài của dự án và ngân sách.
Ngoài ra, có rất ít kỹ thuật đáng tin cậy để ước tính thời gian và chi phí để
phát triển hệ thống thông tin quy mô lớn.
• Cấu trúc dự án. Một số dự án có cấu trúc cao hơn những dự án khác. Yêu cầu của họ
rất rõ ràng và đơn giản, vì vậy đầu ra và quy trình có thể dễ dàng xác định. Người
dùng biết chính xác họ muốn gì và hệ thống phải làm gì; hầu như không có khả năng
người dùng thay đổi ý định của họ. Những dự án như vậy có rủi ro thấp hơn nhiều so
với những dự án có yêu cầu tương đối không xác định, linh hoạt và liên tục thay đổi;
với kết quả đầu ra không thể sửa chữa dễ dàng vì chúng có thể thay đổi ý tưởng của
người dùng; hoặc với những người dùng không thể đồng ý về những gì họ muốn.

• Trải nghiệm với công nghệ. Rủi ro dự án tăng lên nếu nhóm dự án và nhân
viên hệ thống thông tin thiếu chuyên môn kỹ thuật cần thiết. Nếu nhóm
không quen với phần cứng, phần mềm hệ thống, phần mềm ứng dụng hoặc
hệ quản trị cơ sở dữ liệu được đề xuất cho dự án, rất có thể dự án sẽ gặp sự
cố kỹ thuật hoặc mất nhiều thời gian hơn để hoàn thành do cần phải thành
thạo các kỹ năng mới.

Mặc dù khó khăn của công nghệ là một yếu tố rủi ro trong các dự án hệ thống
thông tin, nhưng các yếu tố khác chủ yếu là về mặt tổ chức, đối phó với sự phức
tạp của các yêu cầu thông tin, phạm vi của dự án và bao nhiêu bộ phận của tổ chức
sẽ bị ảnh hưởng bởi một thông tin mới hệ thống. Phiên Tương tác về Quản lý về
động thái của Dịch vụ Y tế Quốc gia Vương quốc Anh đối với việc lưu trữ hồ sơ
không cần giấy tờ minh họa một dự án có một số rủi ro trong số này.

Quản lý Thay đổi và Khái niệm Thực hiện

Việc giới thiệu hoặc thay đổi hệ thống thông tin có tác động mạnh mẽ đến hành vi
và tổ chức. Những thay đổi trong cách thông tin được xác định, truy cập và sử
dụng để quản lý các nguồn lực của tổ chức thường dẫn đến sự phân bổ quyền hạn
và quyền lực mới. Sự thay đổi tổ chức nội bộ này tạo ra sự phản kháng và chống
đối và có thể dẫn đến sự sụp đổ của một hệ thống tốt khác.

Một tỷ lệ rất lớn các dự án hệ thống thông tin gặp sự cố do quá trình thay đổi tổ
chức xung quanh việc xây dựng hệ thống không được giải quyết đúng cách. Xây
dựng hệ thống thành công đòi hỏi sự cẩn thậnthay đổi cách quản lý.

Khái niệm về việc thực hiện

Để quản lý sự thay đổi tổ chức xung quanh việc giới thiệu một hệ thống thông tin
mới một cách hiệu quả, bạn phải kiểm tra quá trình thực hiện. Thực hiện đề cập
đến tất cả các hoạt động của tổ chức nhằm áp dụng, quản lý và cách mạng hóa
một sự đổi mới, chẳng hạn như một hệ thống thông tin mới. Trong quá trình thực
hiện, nhà phân tích hệ thống làtác nhân thay đổi. Nhà phân tích không chỉ phát
triển các giải pháp kỹ thuật mà còn xác định lại các cấu hình, tương tác, hoạt động
công việc và các mối quan hệ quyền lực của các
568 Phần bốn Xây dựng và Quản lý Hệ thống

PHẦN TƯƠNG TÁC: QUẢN LÝ

Dịch vụ Y tế Quốc gia có thể hoạt động không cần giấy tờ không?
Dịch vụ Y tế Quốc gia (NHS) là hệ thống chăm sóc sức khỏe • Thông tin kỹ thuật số có đầy đủ trên NHS và các dịch vụ chăm sóc
quốc gia được tài trợ công khai của Vương quốc Anh. Được tài xã hội trước tháng 4 năm 2018 trừ khi các cá nhân chọn không
trợ chủ yếu bằng thuế, NHS cung cấp dịch vụ chăm sóc sức tham gia.
khỏe miễn phí hoặc chi phí thấp cho tất cả các cư dân hợp pháp
Các giải pháp không cần giấy tờ có thể giúp giảm các
của Vương quốc Anh. Các dịch vụ của NHS bao gồm bệnh viện,
sai sót trong điều trị / thuốc, thời gian chẩn đoán nhanh
bác sĩ gia đình, bác sĩ chuyên khoa, nha sĩ, nhà hóa học (dược
hơn, thời gian điều trị ngắn hơn, nhiều chẩn đoán hợp tác
sĩ), bác sĩ nhãn khoa và dịch vụ xe cứu thương. Thuốc men cũng
hơn (cho phép nhiều chuyên gia tham gia hơn) và chăm
được trợ cấp. Các chính sách cụ thể khác nhau giữa Anh,
sóc bệnh nhân tổng thể tốt hơn.
Scotland, Wales và Bắc Ireland.
Tuy nhiên, nhiều người làm việc trong NHS và các khu vực tư
Bộ Y tế Vương quốc Anh giám sát NHS. Hồ sơ bệnh nhân
nhân - bao gồm cả những người trong ngành công nghệ - tin rằng
được duy trì bởi các nhà cung cấp dịch vụ chăm sóc sức
một NHS không giấy tờ là không thể đạt được trong khung thời
khỏe, những người phải đảm bảo tính bảo mật của dữ liệu
gian 5 năm. Đây là một mục tiêu cực kỳ tham vọng và các nhà phê
bệnh nhân và tuân thủ các tiêu chuẩn quy định. Giống như
bình đặt câu hỏi rằng điều này sẽ thực sự cải thiện các dịch vụ NHS
các hệ thống chăm sóc sức khỏe khác, chẳng hạn như ở
đến mức nào, liệu nó có xứng đáng với chi phí triển khai các hệ
Hoa Kỳ, hồ sơ bệnh nhân chủ yếu dựa trên giấy tờ. Văn
thống CNTT mới hay không và liệu nó có thể đạt được hay không.
phòng bác sĩ và bệnh viện có các kệ chứa đầy hồ sơ và giấy
tờ dành cho việc lưu trữ hồ sơ bệnh án, khiến thông tin về
Theo SA Mathieson, một nhà phân tích của EHI
bệnh nhân và điều trị rất khó tiếp cận hoặc chia sẻ. Chỉ cần
Intelligence, NHS tiếng Anh được tạo thành từ hàng
kéo các tờ tiền cho bệnh nhân NHS để được khám vào buổi
trăm tổ chức với năng lực CNTT rất khác nhau cũng
sáng đã là một cơn ác mộng.
như hàng nghìn bác sĩ đa khoa độc lập. Tất cả họ sẽ
Vào tháng 1 năm 2013, Bộ trưởng Y tế Jeremy Hunt đã kêu
phải mua phần mềm và phần cứng mới và chuyển
gọi thực hiện NHS không cần giấy tờ vào năm 2018 để tiết kiệm
đổi hồ sơ giấy của họ sang dạng kỹ thuật số. Để làm
hàng tỷ USD, cải thiện dịch vụ và giúp đáp ứng những thách
cho hệ thống mới hiệu quả, họ cũng sẽ phải thay đổi
thức của dân số già. Hunt và nhiều người khác tin rằng bệnh
các thủ tục (quy trình kinh doanh) của mình để tận
nhân nên có hồ sơ kỹ thuật số tương thích để thông tin sức
dụng lợi thế của công nghệ mới. Việc trả lời điện
khỏe của họ có thể theo dõi họ xung quanh hệ thống chăm sóc
thoại của bệnh nhân, khám bệnh và viết đơn thuốc
sức khỏe và xã hội. Cho dù bệnh nhân cần bác sĩ đa khoa (bác sĩ
sẽ cần kết hợp các quy trình truy cập và cập nhật
đa khoa), bệnh viện hay nhà chăm sóc, các chuyên gia liên
bệnh án điện tử; hồ sơ trên giấy sẽ phải được chuyển
quan đến việc điều trị của họ sẽ có thể xem lịch sử của họ chỉ
đổi thành dạng điện tử, rất có thể với các mã được
bằng một nút bấm và chia sẻ thông tin quan trọng. Việc sử
chỉ định cho các lựa chọn điều trị khác nhau và dữ
dụng công nghệ được cải tiến sẽ cho phép các chuyên gia y tế
liệu được cấu trúc để phù hợp với định dạng của hồ
dành nhiều thời gian hơn cho bệnh nhân và giúp bệnh nhân tự
sơ. Thời gian đào tạo của bác sĩ có thể lên đến 20 giờ,
kiểm soát việc chăm sóc của mình, tiết kiệm hơn 4 tỷ bảng Anh.
và các bác sĩ cực kỳ quan tâm đến thời gian. Để hệ
thống bắt đầu và chạy, bản thân các bác sĩ có thể
Hunt đã công bố các mục tiêu sau:
phải nhập một số dữ liệu, làm mất thời gian mà họ
• Giấy giới thiệu không cần giấy tờ: Thay vì gửi thư đến có thể dành cho bệnh nhân của mình. Khi Hoa Kỳ cố
bệnh viện khi giới thiệu bệnh nhân, bác sĩ đa khoa gắng triển khai hồ sơ y tế điện tử trong chăm sóc sức
có thể gửi e-mail. khỏe trên toàn quốc, nhiều bác sĩ đã phàn nàn về
• Liên kết an toàn các hồ sơ điện tử về chăm sóc và sức thời gian và nỗ lực cần thiết để thực hiện những thay
khỏe ở bất cứ nơi nào chúng được lưu giữ, do đó, hồ sơ đổi này. NHS đã trải qua một số kháng cự này.
chăm sóc mà người đó nhận được càng đầy đủ càng tốt.
Hiệp hội các bác sĩ Vương quốc Anh, Hiệp hội Y khoa
• Khả năng của những hồ sơ đó để có thể theo dõi các cá nhân, với Anh (BMA), cho biết có một số thách thức cần phải vượt
sự đồng ý của họ, đến bất kỳ phần nào của NHS hoặc hệ thống qua để làm cho NHS trở nên không cần giấy tờ và hoài
chăm sóc xã hội. nghi về mức độ lợi ích mà hệ thống này có thể mang lại.
• Khả năng của các cá nhân để truy cập trực tuyến vào hồ sơ sức khỏe Theo BMA, những thách thức lớn nhất để làm cho NHS
của chính họ do bác sĩ gia đình của họ giữ trước tháng 3 không có giấy tờ vào năm 2018 là kinh phí, nguồn lực,
Năm 2015. mức độ ưu tiên và sự lựa chọn
 Chương 14 Quản lý dự án 569

hệ thống chăm sóc phụ. Cũng như việc tài trợ phần
cứng và phần mềm đang diễn ra, sẽ cần có đủ nguồn
lực để hỗ trợ đào tạo người dùng và chuyên gia CNTT sử
dụng hệ thống không cần giấy tờ và cung cấp hỗ trợ
CNTT và hỗ trợ quản trị. Mặc dù có thể có một số hiệu
quả, nhưng chỉ riêng công nghệ sẽ không nhất thiết tạo
ra khoản tiết kiệm chi phí rất lớn.
Hiện tại, 40% thời gian của bác sĩ lâm sàng được dành
để chờ đợi thông tin liên quan hoặc đưa ra quyết định dựa
trên thông tin không chính xác hoặc không đáng tin cậy và
số hóa cũng cần giải quyết những vấn đề này.
Ủy ban Tài khoản Công của Hạ viện cảnh báo rằng
việc làm cho NHS không cần giấy tờ đòi hỏi phải đầu
Hệ thống NHS “không theo đúng kế hoạch,” và một
số người nói rằng đó là một “sự lãng phí thời gian
tốn kém”. Michael Cross, biên tập viên tin tức tại
The Law Society Gazette. Dịch vụ y tế có thể đáp ứng
thời hạn đó không? Hay NHS sẽ chỉ kết thúc với ít
giấy hơn so với khi dự án không giấy bắt đầu?
Nguồn: Kat Hall, “Các dự án CNTT của NHS trị giá 5 tỷ bảng Anh với 'Rủi ro thất
bại cao', Cảnh báo HSCIC," Sổ đăng ký, 8 Tháng Mười Hai 2015; Clare

tư thêm đáng kể vào CNTT và chuyển đổi kinh doanh. McDonald, "Điều gì đang cản trở một NHS không giấy tờ?"Máy tính hàng tuần,
Tháng 9 năm 2015; SA Mathieson, “CNTT có thể đóng góp như thế nào vào hiệu quả
Tuy nhiên, Sở Y tế thậm chí đã không dành một ngân của NHS?”Máy tính hàng tuần, Tháng 9 năm 2015; Michael Cross, “NHS đuổi theo
sách cụ thể cho mục đích này. Bộ cho biết họ đang một con hổ không giấy”Raconteur, Ngày 29 tháng 4 năm 2014; Claire Read, “Rào cản

đầu tư 1 tỷ bảng Anh (khoảng 1,5 tỷ đô la) vào dự án
không cần giấy tờ — một nửa từ chính phủ trung
ương và phần còn lại từ ngân sách chăm sóc và y tế
địa phương.
Một báo cáo của Ủy ban Tài khoản Công (PAC) gần đây cho
biết rằng những thay đổi được thực hiện đối với kỹ thuật số
đối với NHS không giấy: Bạn đã sẵn sàng cho việc kiểm tra màn hình của mình chưa?”
HSJ, 14 Tháng Ba 2014; Ben Rossi, "Không cần giấy tờ: Cuộc đụng độ giữa
Nhân viên CNTT và Người đứng đầu Ủy thác NHS,"Thời đại thông tin, 18 Tháng
Hai 2014; Bộ Y tế và Nghị sĩ Rt Hon Jeremy Hunt, “NHS Thách thức không cần
giấy tờ vào năm 2018,” www.gov.uk, truy cập ngày 4 tháng 1 năm 2016; “NHS
không giấy…?”Trung tâm máy tính, Ngày 12 tháng 4 năm 2013.

CÂU HỎI NGHIÊN CỨU TÌNH HUỐNG

1. Tại sao NHS không giấy tờ là một dự án rủi ro? Xác định các yếu 3. Những bước cần thực hiện để làm cho NHS không cần
tố rủi ro chính. giấy tờ thành công hơn?
2. Các vấn đề về quản lý, tổ chức và công nghệ là
NHS không giấy tờ có khả năng
bắt gặp?

các nhóm tổ chức. Nhà phân tích là chất xúc tác cho toàn bộ quá trình thay đổi và chịu
trách nhiệm đảm bảo rằng tất cả các bên liên quan đều chấp nhận những thay đổi do
một hệ thống mới tạo ra. Tác nhân thay đổi giao tiếp với người dùng, làm trung gian
giữa các nhóm lợi ích cạnh tranh và đảm bảo rằng việc điều chỉnh tổ chức đối với những
thay đổi đó đã hoàn tất.

Vai trò của người dùng cuối

Việc triển khai hệ thống thường được hưởng lợi từ sự tham gia của người dùng và hỗ
trợ quản lý ở mức độ cao. Sự tham gia của người dùng vào việc thiết kế và vận hành hệ
thống thông tin có một số kết quả tích cực. Thứ nhất, nếu người dùng tham gia nhiều
vào thiết kế hệ thống, họ có nhiều cơ hội hơn để tạo khuôn mẫu hệ thống theo mức độ
ưu tiên và yêu cầu kinh doanh của họ và nhiều cơ hội hơn để kiểm soát kết quả. Thứ
hai, họ có nhiều khả năng phản ứng tích cực hơn với hệ thống đã hoàn thiện bởi vì họ là
những người tham gia tích cực vào quá trình thay đổi. Việc kết hợp kiến thức và kiến
thức chuyên môn của người dùng dẫn đến các giải pháp tốt hơn.

Mối quan hệ giữa người sử dụng và các chuyên gia hệ thống thông tin theo
truyền thống là một vấn đề đối với các nỗ lực triển khai hệ thống thông tin.
570 Phần Bốn Xây dựng và Quản lý Hệ thống

BẢNG 14.4 GAP GIAO TIẾP CỦA NGƯỜI THIẾT KẾ

QUAN TÂM CỦA NGƯỜI DÙNG QUAN TÂM CỦA NHÀ THIẾT KẾ

Hệ thống có cung cấp thông tin chúng ta cần cho công việc của Hệ thống này sẽ đặt ra những yêu cầu gì trên máy chủ của chúng tôi?

mình không?

Chúng tôi có thể truy cập dữ liệu trên iPhone, BlackBerry, Nhóm của chúng ta sẽ đặt ra những yêu cầu lập
máy tính bảng và PC của mình không? trình nào?

Để nhập dữ liệu vào hệ thống chúng ta cần làm Dữ liệu sẽ được lưu trữ ở đâu? Cách hiệu quả
những thủ tục gì mới? nhất để lưu trữ chúng là gì?

Việc vận hành hệ thống sẽ thay đổi thói quen hàng Chúng ta nên sử dụng công nghệ nào để bảo mật
ngày của nhân viên như thế nào? dữ liệu?

Người dùng và các chuyên gia hệ thống thông tin có xu hướng có nền tảng, mối quan tâm và
mức độ ưu tiên khác nhau. Điều này được gọi làkhoảng cách giao tiếp giữa người dùng và
nhà thiết kế. Những khác biệt này dẫn đến sự trung thành với tổ chức, cách tiếp cận giải
quyết vấn đề và từ vựng khác nhau.
Ví dụ, các chuyên gia hệ thống thông tin thường có kỹ thuật cao hoặc máy móc,
định hướng giải quyết vấn đề. Họ tìm kiếm các giải pháp kỹ thuật thanh lịch và tinh
vi, trong đó hiệu quả phần cứng và phần mềm được tối ưu hóa với chi phí dễ sử
dụng hoặc hiệu quả tổ chức. Người dùng thích các hệ thống có định hướng giải
quyết các vấn đề kinh doanh hoặc hỗ trợ các nhiệm vụ của tổ chức. Thông thường,
định hướng của cả hai nhóm trái ngược nhau đến mức họ dường như nói những
thứ tiếng khác nhau.
Những khác biệt này được minh họa trong Bảng 14.4, mô tả những mối quan tâm
điển hình của người dùng cuối và các chuyên gia kỹ thuật (người thiết kế hệ thống
thông tin) liên quan đến việc phát triển một hệ thống thông tin mới. Các vấn đề về giao
tiếp giữa người dùng cuối và nhà thiết kế là lý do chính khiến các yêu cầu của người
dùng không được đưa vào hệ thống thông tin một cách thích hợp và tại sao người dùng
bị loại khỏi quy trình thực hiện.
Các dự án phát triển hệ thống có nguy cơ thất bại rất cao khi có khoảng cách rõ
rệt giữa người dùng và chuyên gia kỹ thuật và khi các nhóm này tiếp tục theo đuổi
các mục tiêu khác nhau. Trong những điều kiện như vậy, người dùng thường bị
xua đuổi khỏi dự án. Bởi vì họ không thể hiểu những gì các kỹ thuật viên đang nói,
người dùng kết luận rằng toàn bộ dự án tốt nhất là để trong tay của các chuyên gia
thông tin.

Hỗ trợ và cam kết quản lý

Nếu một dự án hệ thống thông tin có sự hỗ trợ và cam kết của ban quản lý ở các
cấp khác nhau, thì dự án đó có nhiều khả năng được cả người sử dụng và nhân
viên dịch vụ thông tin kỹ thuật nhìn nhận một cách tích cực hơn. Cả hai nhóm sẽ tin
rằng sự tham gia của họ vào quá trình phát triển sẽ nhận được sự quan tâm và ưu
tiên ở cấp cao hơn. Họ sẽ được ghi nhận và khen thưởng cho thời gian và công sức
mà họ dành cho việc thực hiện. Sự hỗ trợ của ban quản lý cũng đảm bảo rằng một
dự án hệ thống nhận được đủ kinh phí và nguồn lực để thành công. Hơn nữa, để
được thực thi một cách hiệu quả, tất cả những thay đổi trong thói quen và thủ tục
làm việc cũng như bất kỳ cơ cấu lại tổ chức nào liên quan đến một hệ thống mới
đều phụ thuộc vào sự hỗ trợ của ban lãnh đạo. Nếu một nhà quản lý coi một hệ
thống mới là một ưu tiên, hệ thống sẽ có nhiều khả năng bị cấp dưới của họ đối xử
theo cách đó.
 Chương 14 Quản lý dự án 571

Thay đổi Thách thức về Quản lý đối với Tái cấu trúc
Quy trình Kinh doanh, Ứng dụng Doanh nghiệp, Sáp
nhập và Mua lại
Trước những thách thức về đổi mới và thực hiện, không có gì ngạc nhiên khi nhận
thấy tỷ lệ thất bại rất cao trong các dự án tái cấu trúc quy trình kinh doanh và ứng
dụng doanh nghiệp (BPR), thường yêu cầu thay đổi tổ chức sâu rộng và có thể yêu
cầu thay thế các công nghệ cũ và hệ thống kế thừa bắt nguồn từ nhiều quy trình
kinh doanh có liên quan lẫn nhau. Một số nghiên cứu đã chỉ ra rằng 70% của tất cả
các dự án tái cấu trúc quy trình kinh doanh không mang lại lợi ích như đã hứa.
Tương tự như vậy, một tỷ lệ cao các ứng dụng doanh nghiệp không được triển khai
đầy đủ hoặc không đáp ứng được các mục tiêu của người dùng ngay cả sau ba
năm làm việc.
Nhiều dự án ứng dụng và tái cấu trúc doanh nghiệp đã bị phá hoại do thực hiện kém
và quản lý thay đổi không giải quyết được mối quan tâm của nhân viên về sự thay đổi.
Đối phó với nỗi sợ hãi và lo lắng trong toàn tổ chức, vượt qua sự phản kháng của các
nhà quản lý chủ chốt, và thay đổi chức năng công việc, con đường sự nghiệp và phương
thức tuyển dụng đã đặt ra những mối đe dọa lớn hơn đối với việc tái cấu trúc so với
những khó khăn mà các công ty phải đối mặt trong việc hình dung và thiết kế những
thay đổi đột phá đối với quy trình kinh doanh. Tất cả các ứng dụng doanh nghiệp yêu
cầu sự phối hợp chặt chẽ hơn giữa các nhóm chức năng khác nhau cũng như thay đổi
quy trình kinh doanh sâu rộng (xem Chương 9).
Các dự án liên quan đến mua bán và sáp nhập có tỷ lệ thất bại tương tự. Hoạt động
sáp nhập và mua lại bị ảnh hưởng sâu sắc bởi đặc điểm tổ chức của các công ty nhận
sáp nhập cũng như cơ sở hạ tầng CNTT của họ. Việc kết hợp hệ thống thông tin của hai
công ty khác nhau thường đòi hỏi sự thay đổi tổ chức đáng kể và các dự án hệ thống
phức tạp để quản lý. Nếu việc tích hợp không được quản lý đúng cách, các công ty có
thể xuất hiện với một mớ hỗn độn các hệ thống kế thừa được xây dựng bằng cách tập
hợp các hệ thống của công ty này sang công ty khác. Nếu không tích hợp hệ thống
thành công, các lợi ích dự đoán từ việc sáp nhập sẽ không thể thực hiện được, hoặc tệ
hơn, đơn vị được sáp nhập không thể thực hiện các quy trình kinh doanh của mình một
cách hiệu quả.

Kiểm soát các yếu tố rủi ro

Nhiều phương pháp quản lý dự án, thu thập yêu cầu và lập kế hoạch đã được phát
triển cho các loại vấn đề thực hiện cụ thể. Các chiến lược cũng đã được đưa ra để
đảm bảo rằng người dùng đóng các vai trò thích hợp trong suốt thời gian thực hiện
và để quản lý quá trình thay đổi của tổ chức. Không phải tất cả các khía cạnh của
quá trình thực hiện đều có thể được kiểm soát hoặc lập kế hoạch một cách dễ
dàng. Tuy nhiên, lường trước các vấn đề triển khai tiềm ẩn và áp dụng các chiến
lược khắc phục phù hợp có thể tăng cơ hội thành công cho hệ thống.

Bước đầu tiên trong quản lý rủi ro dự án liên quan đến việc xác định bản chất và mức độ
rủi ro đối mặt với dự án. Sau đó, những người thực hiện có thể xử lý từng dự án bằng các
công cụ và cách tiếp cận quản lý rủi ro phù hợp với mức độ rủi ro của dự án. Không phải tất
cả các rủi ro đều có thể xác định trước, nhưng với việc quản lý dự án khéo léo, hầu hết đều
có. Giao tiếp thường xuyên và văn hóa hợp tác sẽ giúp các nhóm dự án thích nghi với những
vấn đề nảy sinh không lường trước được (Browning và Ramasesh, 2015; Laufer và cộng sự,
2015; McFarlan, 1981).

Quản lý độ phức tạp kỹ thuật

Các dự án với công nghệ phức tạp và đầy thách thức để làm chủ được hưởng lợi từ
các công cụ tích hợp nội bộ. Sự thành công của những dự án như vậy phụ thuộc vào mức độ
572 Phần bốn Xây dựng và Quản lý Hệ thống

sự phức tạp kỹ thuật của chúng có thể được quản lý. Các nhà lãnh đạo dự án cần cả
kinh nghiệm kỹ thuật và hành chính. Họ phải có khả năng lường trước các vấn đề
và phát triển mối quan hệ làm việc suôn sẻ giữa một nhóm chủ yếu là kỹ thuật.
Nhóm phải được đặt dưới sự lãnh đạo của người quản lý có nền tảng kỹ thuật và
quản lý dự án vững chắc, và các thành viên trong nhóm phải có nhiều kinh nghiệm.
Các cuộc họp nhóm nên diễn ra thường xuyên. Các kỹ năng kỹ thuật cần thiết hoặc
chuyên môn không có sẵn trong nội bộ cần được bảo đảm từ bên ngoài tổ chức.

Công cụ lập kế hoạch và kiểm soát chính thức

Các dự án lớn được hưởng lợi từ việc sử dụng hợp lý công cụ lập kế hoạch chính thức và
công cụ kiểm soát chính thức để lập hồ sơ và giám sát các kế hoạch dự án. Hai phương
pháp được sử dụng phổ biến nhất để lập hồ sơ kế hoạch dự án là biểu đồ Gantt và biểu đồ
PERT. MỘTbiểu đồ Gantt liệt kê các hoạt động của dự án và ngày bắt đầu và ngày hoàn
thành tương ứng của chúng. Biểu đồ Gantt thể hiện trực quan thời gian và thời lượng của
các nhiệm vụ khác nhau trong một dự án phát triển cũng như các yêu cầu về nguồn nhân lực
của chúng (xem Hình 14.4). Nó hiển thị mỗi nhiệm vụ dưới dạng một thanh ngang có chiều
dài tỷ lệ với thời gian cần thiết để hoàn thành nó.
Mặc dù biểu đồ Gantt hiển thị thời điểm các hoạt động dự án bắt đầu và kết thúc, chúng không
mô tả sự phụ thuộc của nhiệm vụ, cách một nhiệm vụ bị ảnh hưởng nếu nhiệm vụ khác bị chậm
tiến độ hoặc cách các nhiệm vụ nên được sắp xếp. Đó là nơi màBiểu đồ PERT rất hữu ích.
PERT là viết tắt của “Kỹ thuật Đánh giá và Xem xét Chương trình”, một phương pháp luận
được Hải quân Hoa Kỳ phát triển trong những năm 1950 để quản lý chương trình tên lửa tàu
ngầm Polaris. Biểu đồ PERT mô tả bằng đồ thị các nhiệm vụ của dự án và mối quan hệ qua lại
giữa chúng. Biểu đồ PERT liệt kê các hoạt động cụ thể tạo nên một dự án và các hoạt động
phải được hoàn thành trước khi một hoạt động cụ thể có thể bắt đầu, như minh họa trong
Hình 14.5.
Biểu đồ PERT mô tả một dự án như một sơ đồ mạng bao gồm các nút được đánh
số (hình tròn hoặc hình chữ nhật) đại diện cho các nhiệm vụ của dự án. Mỗi nút
được đánh số và hiển thị nhiệm vụ, thời lượng của nó, ngày bắt đầu và ngày hoàn
thành. Hướng của các mũi tên trên các dòng cho biết trình tự của các nhiệm vụ và
cho biết hoạt động nào phải được hoàn thành trước khi bắt đầu hoạt động khác.
Trong Hình 14.5, các nhiệm vụ trong các nút 2, 3 và 4 không phụ thuộc vào nhau và
có thể được thực hiện đồng thời, nhưng mỗi tác vụ phụ thuộc vào việc hoàn thành
nhiệm vụ đầu tiên. Biểu đồ PERT cho các dự án phức tạp có thể khó giải thích và
các nhà quản lý dự án thường sử dụng cả hai kỹ thuật này.
Các kỹ thuật quản lý dự án này có thể giúp các nhà quản lý xác định các điểm nghẽn
và xác định tác động mà các vấn đề sẽ có đối với thời gian hoàn thành dự án. Họ cũng
có thể giúp các nhà phát triển hệ thống phân chia các dự án thành các phân đoạn nhỏ
hơn, dễ quản lý hơn với kết quả kinh doanh xác định và có thể đo lường được. Các kỹ
thuật kiểm soát tiêu chuẩn có thể lập biểu đồ thành công tiến độ của dự án so với ngân
sách và ngày mục tiêu, do đó có thể phát hiện ra những sai lệch so với kế hoạch.

Tăng sự tham gia của người dùng và vượt qua sự phản kháng của người dùng
Các dự án có cấu trúc tương đối ít và nhiều yêu cầu không xác định phải có sự tham gia
của người dùng đầy đủ ở tất cả các giai đoạn. Người dùng phải được huy động để hỗ
trợ một trong nhiều phương án thiết kế khả thi và luôn cam kết với một thiết kế duy
nhất.Các công cụ tích hợp bên ngoài bao gồm các cách để liên kết công việc của nhóm
thực hiện với người dùng ở tất cả các cấp tổ chức. Ví dụ: người dùng có thể trở thành
thành viên tích cực của nhóm dự án, đảm nhận vai trò lãnh đạo và phụ trách cài đặt và
đào tạo. Nhóm triển khai có thể chứng minh khả năng đáp ứng của mình với người
dùng, nhanh chóng trả lời các câu hỏi, kết hợp phản hồi của người dùng và thể hiện sự
sẵn sàng trợ giúp của họ.
 Chương 14 Quản lý dự án 573

HÌNH 14.4 BIỂU ĐỒ GANTT

2016 2017 2018

KẾ HOẠCH KẾT HỢP HRIS – Nhân sự Da Who Oct NovDec Jan Jan Feb Mar April May Jun Tháng bảy Tháng tám Tháng chín Tháng mười một Tháng mười một Tháng hai Tháng ba

BẢO MẬT QUẢN TRỊ DỮ LIỆU

Đánh giá / thiết lập bảo mật 20 EF TP
QMF Định hướng bảo mật 2 EF JA
Bảo trì bảo mật QMF Mục nhập dữ 35 TP GL
liệu sec. pro fi les Mục nhập dữ liệu 4 EF TP
sec. lượt xem ước tính. Chuyên gia 12 EF TP
bảo mật mục nhập dữ liệu 65 EF TP

TỪ ĐIỂN DỮ LIỆU
Phiên định hướng 1 EF
Thiết kế từ điển dữ liệu 32 EFWV
DD sản. coordn-query 20 GL
DD sản. coordn-live 40 EF GL
Dọn dẹp từ điển dữ liệu 35 EF GL
Bảo trì từ điển dữ liệu. 35 EF GL

THỦ TỤC LẠI

THIẾT KẾ TRƯỚC
Work fl ows (cũ) 10 PK JL
Dữ liệu về bảng lương 31 JL PK
Mô hình HRIS P / R 11 PK JL
Định hướng giao diện P / R. mtg. 6 PK JL
Giao diện P / R coordn. 1 giao diện 15 PK
P / R coordn. 2 Giao diện có lợi (cũ) 8 PK
Giao diện có lợi (mới) Chiến lược 5 JL
truyền thông có lợi 8 JL
3 PK JL
Tác phẩm mới của mẫu 15 PK JL
Posn. nhập dữ liệu 14 WV JL

TÓM TẮT NGUỒN LỰC

Edith Farrell 5.0 EF 2 21 24 24 23 22 22 27 34 5 17 20 19 34 29 26 28 19 14
Woody Vinton 5.0 WV 12 10 14 10 2 4 3
Charles Pierce 5.0 CP 5 11 20 13 9 10 7 6 844444
Ted Leurs 5.0 TL 12 17 17 19 17 14 12 15 1 11 10 11 16 2 1 1 1 1
Toni Cox 5.0 TC 11 12 19 19 21 7 23 30 34 27 25 15 24 21 21 17 17 12 9
Patricia Knopp 5.0 máy tính 25 1 9 16 21 19 21 21 20 17 4 4 5 5 5 2 16 11 13 17 10 3 3 2
Jane Lawton 5.0 JL 754 15 14 12 14 8 5
David Holloway 5.0 DH 16 2
Diane O'Neill 5.0 LÀM 6 14 17 16 13 11 9 4
Joan Albert 5.0 JA 567621 5 5 1
Marie Marcus 5.0 MM 15 7 2 1 1
Don Stevens 5.0 DS 445451
Binh thương 5.0 CASL 343 4 7 9 5 3 2
Kathy Mendez 5.0 KM 1 5 16 20 19 22 19 20 18 20 11 2
Anna Borden 5.0 AB 9 10 16 15 11 12 19 10 7 1
Gail Loring 5.0 GL 3 6 5 9 10 17 18 17 10 13 10 10 7 17
CHƯA ĐƯỢC ĐĂNG KÝ 0,0 NS 9 236 225 230 14 13
Hợp tác 5.0 CO 64234 4 2 4 16 216 178
Binh thương 5.0 CAUL 33 3
TỔNG SỐ NGÀY 49 147 176 196 194 174 193 195 190 181 140 125 358 288 284 237 196 12

Biểu đồ Gantt trong hình này hiển thị nhiệm vụ, ngày làm việc và tên viết tắt của từng người chịu trách nhiệm cũng như ngày bắt đầu và
ngày kết thúc cho mỗi nhiệm vụ. Bản tóm tắt tài nguyên cung cấp cho người quản lý giỏi tổng số ngày công cho mỗi tháng và cho từng
người làm việc trong dự án để quản lý dự án thành công. Dự án được mô tả ở đây là một dự án quản trị dữ liệu.
574 Phần bốn Xây dựng và Quản lý Hệ thống

HÌNH 14.5 BIỂU ĐỒ PERT

Chọn dịch vụ lưu trữ

2 1 ngày

19/1/17 20/1/17

Thiết kế trang web Viết HTML Hoàn thiện mã Thử nghiệm

1 10 ngày 3 20 ngày 5 6 ngày 6 10 ngày

1/8/17 1/18/17 19/1/17 2/7/17 2/8/17 14/2/17 15/2/17 25/2/17

Tạo tác phẩm nghệ thuật

4 10 ngày

19/1/17 1/29/17

Đây là biểu đồ PERT đơn giản hóa để tạo một trang web nhỏ. Nó cho thấy thứ tự của các nhiệm vụ dự án và mối quan hệ của một nhiệm vụ với các nhiệm
vụ trước đó và tiếp theo.

Việc tham gia vào các hoạt động triển khai có thể không đủ để khắc phục vấn đề người
dùng chống lại sự thay đổi của tổ chức. Những người dùng khác nhau có thể bị ảnh hưởng
bởi hệ thống theo những cách khác nhau. Trong khi một số người dùng có thể hoan nghênh
một hệ thống mới vì nó mang lại những thay đổi mà họ cho là có lợi cho họ, những người
khác có thể chống lại những thay đổi này vì họ tin rằng những thay đổi này có hại cho lợi ích
của họ.
Nếu việc sử dụng một hệ thống là tự nguyện, người dùng có thể chọn tránh nó;
nếu việc sử dụng là bắt buộc, sự phản kháng sẽ có dạng như tăng tỷ lệ lỗi, gián
đoạn, doanh thu và thậm chí phá hoại. Do đó, chiến lược thực hiện không chỉ phải
khuyến khích sự tham gia và tham gia của người dùng mà còn phải giải quyết vấn
đề phản thực thi.Phản biện là một chiến lược có chủ ý để ngăn cản việc triển khai
hệ thống thông tin hoặc một sự đổi mới trong một tổ chức.

Các chiến lược để vượt qua sự phản kháng của người dùng bao gồm sự tham gia của
người dùng (để đưa ra cam kết cũng như cải tiến thiết kế), giáo dục và đào tạo người
dùng, các chính sách và sắc lệnh quản lý cũng như các ưu đãi tốt hơn cho những người
dùng hợp tác. Hệ thống mới có thể được làm cho thân thiện hơn với người dùng bằng
cách cải thiện giao diện người dùng cuối. Người dùng sẽ hợp tác hơn nếu các vấn đề về
tổ chức được giải quyết trước khi giới thiệu hệ thống mới. Phiên tương tác về các tổ
chức mô tả một số thách thức khi phát triển các ứng dụng di động.

PHẦN TƯƠNG TÁC: CÔNG NGHỆ
Hilti AG: Kết hợp mọi thứ cùng với các công cụ quản lý dự án mới
Giả sử bạn muốn đào một đường hầm xe lửa thực sự
lớn, dài 57 km và nối các vùng nói tiếng Đức và Ý của
Thụy Sĩ, từ Erstfeld ở phía bắc đến Bodio ở phía nam.
Nó sẽ hầu như không có độ dốc, nghĩa là tàu hỏa có
thể di chuyển qua đường hầm với tốc độ lên đến 250
km một giờ. Các đường ray cần được neo vào một
lớp bê tông, và các ống dẫn cáp được gắn trực tiếp
vào các bức tường của một ngọn núi khổng lồ được
gọi là Saint Gotthard Massif. Chỉ mười km cáp sẽ cần
đến 30.000 lỗ trên núi và năm triệu dây buộc để cố
định đường ray cho sàn nhà. Ồ, và 900.000 dây buộc
cơ khí khác sẽ cần thiết để kết nối các đoạn đường
sắt. Hơn 150 máy khoan búa và 700 pin sẽ cần thiết
để khoan các lỗ cho các ốc vít có độ bền cao cần
thiết. Các thanh ray cần được đặt và bảo đảm trong
phạm vi milimet trên toàn bộ chiều dài. Hai nghìn
sáu trăm nhân viên sẽ tham gia hàng ngày, hầu hết
trong số họ sẽ cần truy cập thông tin và kế hoạch dự
án kịp thời và chính xác. Đây là thách thức của
Đường hầm Gotthard Base, đường hầm đường sắt
dài nhất thế giới và là dự án công trình công cộng
tốn kém nhất của Thụy Sĩ từ trước đến nay. Một giải
pháp là thuê Hilti
TUỔI THƠ.
Công ty Hilti AG được thành lập vào năm 1941, tại
Schaan, Công quốc Liechtenstein, bởi anh em Marint
và Eugen Hilti, nhằm cung cấp linh kiện cho các nhà
sản xuất Đức. Sau năm 1946, công ty chuyển sang
sản xuất ốc vít và dụng cụ cho ngành xây dựng. Ngày
nay, Hilti là một trong những nhà sản xuất ốc vít và
máy khoan búa lớn nhất thế giới và đã mở rộng sang
các sản phẩm mới như thiết bị đo laser, hệ thống tích
hợp dữ liệu xây dựng cho nhà thầu, phần mềm ước
tính yêu cầu dự án và dịch vụ quản lý dự án tùy chỉnh
cho các ngành công nghiệp năng lượng và xây dựng
chuyên nghiệp. Hilti hiện có 26.000 nhân viên tại 20
quốc gia trên sáu lục địa và công ty được tổ chức tư
nhân bởi Hilti Family Trust. Năm 2016, Hilti tạo ra 4,3
tỷ euro và có doanh thu ròng 448 triệu euro.
Giúp khách hàng của mình quản lý các dự án phức tạp,
Hilti tạo ra hơn 200.000 liên hệ với khách hàng mỗi ngày.
Trong quá khứ, nó dựa vào Microsoft Project Professional
cho mỗi dự án của khách hàng, được xây dựng phần lớn
trên bảng tính Excel. Với hàng nghìn bảng tính Excel cho
mỗi dự án và hàng nghìn dự án,
Chương 14 Quản lý dự án 575
kết quả là một quá trình không rõ ràng với ít giao tiếp
giữa các nhà quản lý dự án và nhân viên ngoài việc
không thể theo dõi các nhiệm vụ, nguồn lực, khả năng
và chi phí của nhân viên. Hilti cần một công cụ quản lý
danh mục dự án (PPM) có thể xem xét tất cả các dự án
đang thực hiện cũng như các nhiệm vụ hàng ngày cho
các dự án cụ thể. Nó cũng cần một môi trường truyền
thông tích hợp để những người tham gia dự án chia sẻ
thông tin về dự án cụ thể. Đồng thời, ban lãnh đạo
không muốn đầu tư quá lớn vào cơ sở hạ tầng CNTT
hoặc thực hiện một chương trình đào tạo tốn kém điển
hình cho các giải pháp phần mềm tùy chỉnh.
Để mang lại những khả năng này, Hilti đã sử dụng
Microsoft Project Online, một giải pháp dựa trên đám mây,
để quản lý danh mục dự án cho các nhà quản lý cấp cao và
cung cấp cho nhân viên quyền truy cập vào dữ liệu dự án
cụ thể hàng ngày. Làm việc với một công ty tư vấn, Hilti xác
định các yêu cầu thông tin cho từng bộ phận và tạo các
mẫu dự án tiêu chuẩn phản ánh các hoạt động, nhiệm vụ
và sự kiện quan trọng tiêu chuẩn cũng như các thủ tục bảo
mật quản lý quyền của người dùng và kiểm soát phiên bản.
Các nhiệm vụ được giao cho các cá nhân và mọi nhiệm vụ
đều có danh sách các nguồn lực, ngày hoàn thành và các
yêu cầu về nguồn lực. Với quan điểm danh mục dự án toàn
công ty, các nhà quản lý cấp cao có thể thấy công ty đang
tham gia vào những dự án nào và những nguồn lực nào
được yêu cầu. Khi việc triển khai hoàn thành, Hiliti ước tính
rằng trên 10, 000 nhân viên của nó sẽ sử dụng hệ thống
hàng ngày để theo dõi các dự án cho chính nó và cho khách
hàng của nó. Trong tương lai, nhân viên sẽ sử dụng máy
tính bảng và điện thoại thông minh để truy cập hệ thống.
Project Online được phân phối như một phần của
Microsoft Office 365, cung cấp tất cả các ứng dụng quen
thuộc của Microsoft như email, lịch, cộng tác, phần mềm
cộng tác SharePoint cũng như Word, Excel và
PowerPoint. Giải pháp đám mây có nghĩa là công ty
không phải mở rộng cơ sở hạ tầng CNTT của riêng mình
và nhân viên đã được đào tạo về Office 365. Không cần
nâng cấp hàng tháng đối với các vấn đề phần mềm và
phần cứng, bảo trì hoặc tương thích giữa các công cụ
phần mềm khác nhau. Những lợi ích đối với Hilti bao
gồm khả năng quản lý các dự án phức tạp cho khách
hàng, quản lý danh mục dự án trên toàn công ty, giảm
chi phí liên lạc và đi lại, ra quyết định nhanh hơn nhiều
và cải thiện năng suất. Trong khi đó trong dự án trước
đây
576 Phần bốn Xây dựng và Quản lý Hệ thống

Các thành viên trong nhóm sẽ dành 30 phút để tìm
kiếm thông tin dự án, thời gian đó đã giảm xuống
trung bình 10 phút, tiết kiệm hơn 75 giờ một năm
cho mỗi người tham gia dự án.
Nguồn: “Trimble và Tập đoàn Hilti Cung cấp Giải pháp Tích hợp cho
Chuyên gia Xây dựng,” Bloomberg.com, ngày 10 tháng 11 năm 2016;
“Báo cáo Công ty Hilti 2016,” http://www.hilti-companyreport.com; “Nhà
sản xuất xây dựng sử dụng dịch vụ đám mây để hợp lý hóa việc quản lý
dự án”, Nghiên cứu điển hình của Microsoft, tháng 1
Ngày 13 năm 2015.

CÂU HỎI NGHIÊN CỨU TÌNH HUỐNG

1. Các vấn đề về quản lý, tổ chức và công nghệ
mà Hilti cần giải quyết khi xem xét một cách
tiếp cận mới để quản lý dự án là gì?
2. Tại sao Hilti lại chọn công nghệ Microsoft Project
Online
3. Tại sao Hilti lại muốn tiêu chuẩn hóa quy trình
quản lý dự án trong toàn bộ công ty của mình?
4. Bạn nghĩ bốn lợi ích quan trọng nhất của giải
pháp mà Hilti đã áp dụng là gì?

Thiết kế cho Tổ chức

Vì mục đích của hệ thống mới là cải thiện hiệu suất của tổ chức, các dự án hệ thống
thông tin phải giải quyết rõ ràng các cách thức mà tổ chức sẽ thay đổi khi hệ thống
mới được cài đặt, bao gồm cài đặt các ứng dụng web và di động. Ngoài các thay đổi
về thủ tục, các chuyển đổi trong chức năng công việc, cơ cấu tổ chức, các mối quan
hệ quyền lực và môi trường làm việc cũng cần được lên kế hoạch cẩn thận.

Các khu vực mà người dùng giao tiếp với hệ thống cần được chú ý đặc biệt, nhạy
cảm với các vấn đề về công thái học. Công thái học đề cập đến sự tương tác của
con người và máy móc trong môi trường làm việc. Nó xem xét việc thiết kế các
công việc, các vấn đề sức khỏe và giao diện người dùng cuối của hệ thống thông
tin. Bảng 14.5 liệt kê các khía cạnh tổ chức phải giải quyết khi lập kế hoạch và triển
khai hệ thống thông tin.
Mặc dù các hoạt động phân tích và thiết kế hệ thống được cho là bao gồm phân tích
tác động của tổ chức, nhưng lĩnh vực này theo truyền thống đã bị bỏ qua. Một
phân tích tác động của tổ chức giải thích cách một hệ thống được đề xuất sẽ ảnh
hưởng đến cấu trúc, thái độ, việc ra quyết định và hoạt động của tổ chức. Để tích
hợp thành công hệ thống thông tin với tổ chức, các đánh giá tác động của tổ chức
được ghi chép đầy đủ và kỹ lưỡng phải được quan tâm nhiều hơn trong nỗ lực phát
triển.

Thiết kế Công nghệ Xã hội

Một cách để giải quyết các vấn đề về con người và tổ chức là kết hợp
thiết kế công nghệ xã hội thực hành vào các dự án hệ thống thông tin. Các nhà
thiết kế đặt ra các bộ giải pháp thiết kế kỹ thuật và xã hội riêng biệt. Các kế hoạch
thiết kế xã hội khám phá các cấu trúc nhóm làm việc khác nhau, phân bổ nhiệm vụ
và thiết kế các công việc riêng lẻ. Các giải pháp kỹ thuật đề xuất được so sánh
 Chương 14 Quản lý dự án 577

với các giải pháp xã hội được đề xuất. Giải pháp đáp ứng tốt nhất cả mục tiêu xã
hội và kỹ thuật được lựa chọn cho thiết kế cuối cùng. Kết quả là thiết kế công nghệ
xã hội sẽ tạo ra một hệ thống thông tin kết hợp hiệu quả kỹ thuật với độ nhạy đối
với nhu cầu của tổ chức và con người, dẫn đến sự hài lòng và năng suất công việc
cao hơn.

Công cụ phần mềm quản lý dự án

Các công cụ phần mềm thương mại tự động hóa nhiều khía cạnh của quản lý dự án
tạo điều kiện thuận lợi cho quá trình quản lý dự án. Phần mềm quản lý dự án
thường có các khả năng xác định và sắp xếp các nhiệm vụ, chỉ định nguồn lực cho
các nhiệm vụ, thiết lập ngày bắt đầu và kết thúc cho các nhiệm vụ, theo dõi tiến độ
và tạo điều kiện sửa đổi các nhiệm vụ và tài nguyên. Nhiều người tự động hóa việc
tạo các biểu đồ Gantt và PERT và cung cấp các công cụ giao tiếp, cộng tác và xã hội.

Một số công cụ này là các chương trình lớn phức tạp để quản lý các dự án rất lớn, các
nhóm làm việc phân tán và các chức năng của doanh nghiệp. Những công cụ cao cấp này có
thể quản lý số lượng rất lớn các nhiệm vụ và hoạt động cũng như các mối quan hệ phức tạp.
Công cụ quản lý dự án được sử dụng rộng rãi nhất hiện nay là Microsoft Project, nhưng cũng
có những công cụ chi phí thấp hơn dành cho các dự án nhỏ hơn và doanh nghiệp nhỏ, chẳng
hạn như Zoho Projects và Teamwork Projects, có sẵn trên đám mây cũng như một số phiên
bản của Microsoft Project. Nhiều ứng dụng quản lý dự án hiện nay dựa trên nền tảng đám
mây để cho phép các thành viên trong nhóm dự án truy cập các công cụ quản lý dự án và dữ
liệu của họ ở bất kỳ nơi nào họ đang làm việc. Huddle, Clarizen và Citrix Podio là những ví dụ
khác (Reisinger, 2016).
Trong khi phần mềm quản lý dự án giúp các tổ chức theo dõi các dự án riêng lẻ,
các nguồn lực được phân bổ cho chúng và chi phí của chúng, phần mềm quản lý
danh mục dự án giúp các tổ chức quản lý danh mục đầu tư của các dự án và sự
phụ thuộc giữa chúng. Phần mềm quản lý danh mục dự án giúp người quản lý so
sánh các đề xuất và dự án với ngân sách và mức năng lực nguồn lực để xác định sự
kết hợp và trình tự tối ưu của các dự án nhằm đạt được mục tiêu chiến lược của tổ
chức một cách tốt nhất.

BẢNG 14.5 CÁC YẾU TỐ TỔ CHỨC TRONG QUY HOẠCH HỆ THỐNG VÀ

THỰC HIỆN

Sự tham gia và sự tham gia của nhân viên Thiết

kế công việc

Tiêu chuẩn và giám sát hiệu suất

Công thái học (bao gồm thiết bị, giao diện người dùng và môi
trường làm việc)
Sưc khỏe va sự an toan

Tuân thủ quy định của chính phủ

578 Phần bốn Xây dựng và Quản lý Hệ thống

Tóm tắt đánh giá

14-1 Các mục tiêu của quản lý dự án là gì và tại sao nó lại rất cần thiết trong việc phát triển thông tin
hệ thống?
Quản lý dự án tốt là điều cần thiết để đảm bảo rằng các hệ thống được phân phối đúng thời hạn và
ngân sách cũng như mang lại lợi ích kinh doanh thực sự. Các hoạt động quản lý dự án bao gồm lập kế
hoạch công việc, đánh giá rủi ro, ước tính và thu thập các nguồn lực cần thiết để hoàn thành công việc,
tổ chức công việc, chỉ đạo thực hiện và phân tích kết quả. Quản lý dự án phải đối phó với năm biến chính:
phạm vi, thời gian, chi phí, chất lượng và rủi ro.

14-2 Những phương pháp nào có thể được sử dụng để lựa chọn và đánh giá các dự án hệ thống thông tin và sắp xếp chúng
với mục tiêu kinh doanh của công ty?
Các tổ chức cần một kế hoạch hệ thống thông tin mô tả cách thức công nghệ thông tin hỗ trợ việc đạt
được các mục tiêu kinh doanh của họ và tài liệu hóa tất cả các ứng dụng hệ thống và các thành phần cơ
sở hạ tầng CNTT của họ. Các tập đoàn lớn sẽ có cơ cấu quản lý để đảm bảo các dự án hệ thống quan
trọng nhất được ưu tiên. Các chỉ số hiệu suất chính, phân tích danh mục đầu tư và mô hình cho điểm có
thể được sử dụng để xác định và đánh giá các dự án hệ thống thông tin thay thế.

14-3 Làm thế nào các doanh nghiệp có thể đánh giá giá trị kinh doanh của hệ thống thông tin?
Để xác định xem một dự án hệ thống thông tin có phải là một khoản đầu tư tốt hay không, người ta phải tính toán
chi phí và lợi ích của nó. Lợi ích hữu hình có thể định lượng được và những lợi ích vô hình không thể định lượng ngay
lập tức có thể mang lại những lợi ích định lượng được trong tương lai. Các lợi ích vượt quá chi phí cần được phân tích
bằng cách sử dụng các phương pháp lập ngân sách vốn để đảm bảo một dự án mang lại lợi nhuận tốt trên vốn đầu tư
của công ty.

14-4 Các yếu tố rủi ro chính trong các dự án hệ thống thông tin là gì và chúng có thể được quản lý như thế nào?
Mức độ rủi ro trong một dự án phát triển hệ thống được xác định bởi (1) quy mô dự án, (2) cấu
trúc dự án và (3) kinh nghiệm với công nghệ. Các dự án IS có nhiều khả năng thất bại hơn khi
không có sự tham gia đầy đủ hoặc không thích hợp của người dùng vào quá trình phát triển hệ
thống, thiếu hỗ trợ quản lý và quản lý quá trình thực hiện kém. Có một tỷ lệ thất bại rất cao trong
số các dự án liên quan đến tái cấu trúc quy trình kinh doanh, các ứng dụng doanh nghiệp và sáp
nhập và mua lại vì chúng đòi hỏi sự thay đổi tổ chức rộng rãi.
Thực hiện đề cập đến toàn bộ quá trình thay đổi tổ chức xung quanh việc giới thiệu một hệ
thống thông tin mới. Sự hỗ trợ và tham gia của người dùng cũng như hỗ trợ quản lý và kiểm soát
quá trình thực hiện là rất cần thiết, cũng như các cơ chế để đối phó với mức độ rủi ro trong mỗi dự
án hệ thống mới. Các yếu tố rủi ro của dự án có thể được kiểm soát bằng một cách tiếp cận dự
phòng đối với quản lý dự án. Mức độ rủi ro của mỗi dự án xác định sự kết hợp thích hợp của các
công cụ tích hợp bên ngoài, công cụ tích hợp nội bộ, công cụ lập kế hoạch chính thức và chính thức
các công cụ kiểm soát được áp dụng.

Điều khoản quan trọng

Lập ngân sách vốn, 565 Phân tích tác động của tổ chức, biểu
Thay đổi đại lý, 567 đồ PERT 577, 572
Quản lý thay đổi, 567 Phân tích danh mục đầu tư,
Phản biện, 574 Ergonomics, Dự án 562, 558
577 Quản lý dự án, 558
Các công cụ tích hợp bên ngoài, 572 Quản lý danh mục dự án, 578
Công cụ kiểm soát chính thức, 572 Phạm vi, 559
Công cụ lập kế hoạch chính thức, 572 Mô hình chấm điểm, 563
Biểu đồ Gantt, 572 Thiết kế công nghệ xã hội,
Thực hiện, 567 577 Lợi ích hữu hình, 564
Kế hoạch hệ thống thông tin, Khoảng cách giao tiếp giữa người thiết kế và người dùng, 570
560 Lợi ích vô hình, 564 Giao diện người dùng, 558
Các công cụ tích hợp nội bộ, 571

Của tôiPhòng thí nghiệm MIS
Để hoàn thành các vấn đề với MyLab MIS, chuyển đến Câu hỏi thảo luận EOC trong MyLab MIS.
Câu hỏi đánh giá
14-1 Các mục tiêu của quản lý dự án là gì,
và tại sao nó lại rất cần thiết trong việc phát triển hệ
thống thông tin?
• Mô tả các vấn đề về hệ thống thông tin do
quản lý dự án kém.
• Xác định quản lý dự án. Liệt kê và mô tả các
hoạt động quản lý dự án và các biến được
quản lý dự án giải quyết.
14-2 Những phương pháp nào có thể được sử dụng để lựa chọn và
đánh giá các dự án hệ thống thông tin và điều chỉnh
chúng phù hợp với mục tiêu kinh doanh của công ty?
• Đặt tên và mô tả các nhóm chịu trách nhiệm
quản lý các dự án hệ thống thông tin.
• Mô tả mục đích của một kế hoạch hệ thống
thông tin và liệt kê các danh mục chính trong
kế hoạch.
• Giải thích cách sử dụng các chỉ số hiệu suất
chính, phân tích danh mục đầu tư và mô hình
cho điểm để lựa chọn các dự án hệ thống
thông tin.
14-3 Làm thế nào các công ty có thể đánh giá giá trị kinh doanh của
hệ thông thông tin?
• Liệt kê và mô tả các chi phí và lợi ích chính của
hệ thống thông tin.
• Phân biệt lợi ích hữu hình và lợi ích vô hình.
Câu hỏi thảo luận
14-5 Mức độ ảnh hưởng của quản lý dự án
MyLabMIS sự thành công của một hệ thống thông tin mới?
Chương 14 Quản lý dự án 579
• Xác định ngân sách vốn và liệt kê các mô hình
lập ngân sách vốn chính để đánh giá các dự án
CNTT.
14-4 Các yếu tố rủi ro chính trong thông tin
các dự án hệ thống, và chúng có thể được quản lý như
thế nào?
• Xác định và mô tả từng yếu tố rủi ro chính
trong các dự án hệ thống thông tin.
• Xác định các tác nhân thực hiện và thay đổi và giải
thích tầm quan trọng của chúng đối với quản lý
thay đổi.
• Giải thích tại sao việc lôi kéo sự hỗ trợ của ban
quản lý và người dùng cuối là rất cần thiết
để thực hiện thành công các dự án hệ thống
thông tin.
• Giải thích tại sao lại có tỷ lệ thất bại cao như vậy
đối với các triển khai liên quan đến các ứng
dụng doanh nghiệp, tái cấu trúc quy trình kinh
doanh và sáp nhập và mua lại.
• Xác định và mô tả các chiến lược để kiểm soát
rủi ro dự án.
• Xác định các cân nhắc của tổ chức cần được
giải quyết khi lập kế hoạch và thực hiện dự
án.
• Mô tả vai trò của công thái học, phân tích tác
động của tổ chức và thiết kế công nghệ xã
hội trong việc thiết kế cho tổ chức.
14-6 Người ta nói rằng hầu hết các hệ thống không thành công vì
MyLabMIS người xây dựng hệ thống bỏ qua hành vi của tổ chức
ior vấn đề. Tại sao có thể như vậy?
14-7 Vai trò của người dùng cuối đối với thông tin là gì
MyLabMIS quản lý dự án hệ thống?
580 Phần bốn Xây dựng và Quản lý Hệ thống

Các dự án MIS thực hành

Các dự án trong phần này cung cấp cho bạn kinh nghiệm thực tiễn đánh giá các dự án hệ thống thông tin, sử dụng phần mềm
bảng tính để thực hiện phân tích ngân sách vốn cho các khoản đầu tư vào hệ thống thông tin mới và sử dụng các công cụ web
để phân tích tài chính cho một ngôi nhà mới. Truy cập Thư viện Đa phương tiện của MyLab MIS để truy cập các Dự án MIS
Thực hành của chương này.

Các vấn đề về quyết định quản lý

14-8 Điều tra dân số Hoa Kỳ đã khởi động một dự án CNTT để hỗ trợ những người kiểm tra điều tra dân số của mình trong lĩnh vực này bằng thiết bị cầm tay công nghệ cao

thiết bị sẽ tiết kiệm tiền cho người đóng thuế bằng cách truyền trực tiếp dữ liệu dân số đến trụ sở chính từ những người kiểm tra điều tra dân số
tại hiện trường. Các quan chức điều tra dân số đã ký một hợp đồng trị giá 600 triệu đô la với Tổng công ty Harris vào năm 2006 để xây dựng
500.000 thiết bị nhưng vẫn không chắc họ muốn có những tính năng nào trong thiết bị. Các quan chức điều tra dân số
không nêu rõ quy trình thử nghiệm để đo lường hiệu suất của các thiết bị cầm tay. Khi dự án tiến triển, 400 yêu cầu
thay đổi đối với các yêu cầu của dự án đã được thêm vào. Hai năm và hàng trăm triệu đô la của người nộp thuế sau đó,
các thiết bị cầm tay quá chậm và không đáng tin cậy để được sử dụng cho cuộc điều tra dân số Hoa Kỳ năm 2010. Ban
quản lý Cục điều tra dân số và Tổng công ty Harris có thể làm gì để ngăn chặn kết quả này?
14-9 Caterpillar là nhà sản xuất máy móc di chuyển trên đất hàng đầu thế giới và là nhà cung cấp thiết bị nông nghiệp-
cố vấn. Caterpillar muốn chấm dứt hỗ trợ Hệ thống kinh doanh đại lý (DBS) mà nó cấp phép cho các đại lý của mình để
giúp họ điều hành công việc kinh doanh của mình. Phần mềm trong hệ thống này đang trở nên lỗi thời và quản lý cấp
cao muốn chuyển hỗ trợ cho phiên bản được lưu trữ của phần mềm cho Accenture Consultants để họ có thể tập trung
vào hoạt động kinh doanh cốt lõi của mình. Caterpillar không bao giờ yêu cầu các đại lý của mình sử dụng DBS, nhưng
hệ thống này đã trở thành một tiêu chuẩn thực tế để kinh doanh với công ty. Phần lớn trong số 50 đại lý Cat ở Bắc Mỹ
sử dụng một số phiên bản DBS, cũng như khoảng một nửa trong số 200 đại lý Cat ở phần còn lại của thế giới. Trước khi
Caterpillar chuyển giao sản phẩm cho Accenture, nó nên xem xét những yếu tố và vấn đề gì? Nó nên hỏi những câu hỏi
nào? Các đại lý của nó nên hỏi những câu hỏi nào?

Cải thiện việc ra quyết định: Sử dụng phần mềm bảng tính để lập ngân sách vốn cho
hệ thống CAD mới
Kỹ năng phần mềm: Công thức và chức năng bảng tính Kỹ
năng kinh doanh: Lập ngân sách vốn

14-10 Dự án này cung cấp cho bạn cơ hội sử dụng phần mềm bảng tính để sử dụng ngân sách vốn
các mô hình được thảo luận trong chương này và các Theo dõi Học tập của nó để phân tích lợi tức đầu tư cho một hệ thống
thiết kế có hỗ trợ máy tính (CAD) mới.
Công ty của bạn muốn đầu tư vào một hệ thống thiết kế có sự hỗ trợ của máy tính (CAD) mới yêu cầu mua
phần cứng, phần mềm và công nghệ mạng cũng như chi phí để cài đặt, đào tạo và hỗ trợ. MyLab MIS chứa các bảng
hiển thị từng thành phần chi phí cho hệ thống mới cũng như chi phí bảo trì hàng năm trong khoảng thời gian năm
năm, cùng với một Đường hướng học tập về các mô hình lập ngân sách vốn. Bạn tin rằng hệ thống mới sẽ giảm lượng
lao động cần thiết để tạo ra các thiết kế và thông số kỹ thuật thiết kế, do đó làm tăng dòng tiền hàng năm của công ty
bạn.
• Sử dụng dữ liệu được cung cấp trong các bảng này, tạo một bảng tính toán chi phí và lợi ích của khoản đầu tư trong khoảng
thời gian 5 năm và phân tích khoản đầu tư bằng cách sử dụng bốn mô hình lập ngân sách vốn được trình bày trong
Chương trình Học tập của chương này.
• Khoản đầu tư này có đáng giá không? Tại sao hoặc tại sao không?

Cải thiện việc ra quyết định: Sử dụng các công cụ web để mua và tài trợ một ngôi nhà
Kỹ năng phần mềm: Phần mềm dựa trên Internet Kỹ
năng kinh doanh: Lập kế hoạch tài chính

14-11 Dự án này sẽ phát triển kỹ năng của bạn bằng cách sử dụng phần mềm dựa trên web để tìm kiếm nhà và tính toán
thế chấp tài chính cho ngôi nhà đó.
Bạn muốn mua một ngôi nhà ở Fort Collins, Colorado. Lý tưởng nhất, đó phải là một ngôi nhà dành cho
một gia đình có ít nhất ba phòng ngủ và một phòng tắm có giá từ 170.000 đến 300.000 đô la và được tài trợ bằng
khoản thế chấp lãi suất cố định trong 30 năm. Bạn có thể trả trước 20% giá trị căn nhà. Trước
 Chương 14 Quản lý dự án 581

bạn mua một ngôi nhà, bạn muốn tìm hiểu những ngôi nhà có sẵn trong phạm vi giá của bạn, tìm khoản thế
chấp và xác định số tiền phải trả hàng tháng của bạn. Sử dụng trang Realtor.com để giúp bạn với các tác vụ sau:

• Định vị các ngôi nhà ở Fort Collins, Colorado, đáp ứng các thông số kỹ thuật của bạn.

• Tìm một khoản thế chấp cho 80 phần trăm giá niêm yết của ngôi nhà. So sánh tỷ lệ từ ít nhất ba trang web (sử dụng công
cụ tìm kiếm để tìm các trang khác ngoài Yahoo).
• Sau khi chọn một khoản thế chấp, hãy tính toán chi phí đóng và số tiền phải trả hàng tháng.

Khi bạn hoàn thành, hãy đánh giá toàn bộ quá trình. Ví dụ: đánh giá mức độ dễ sử dụng của trang web và khả
năng tìm kiếm thông tin về nhà ở và các khoản thế chấp, tính chính xác của thông tin bạn tìm thấy và phạm vi
lựa chọn nhà và thế chấp.

Dự án hợp tác và làm việc theo nhóm

Xác định các vấn đề triển khai

Lập một nhóm với ba hoặc bốn học sinh khác. Viết mô tả các vấn đề triển khai mà bạn có thể gặp phải ở một
trong các hệ thống được mô tả trong Phiên tương tác hoặc các trường hợp kết thúc chương trong văn bản này.
Viết phân tích các bước bạn sẽ thực hiện để giải quyết hoặc ngăn chặn những vấn đề này. Nếu có thể, hãy sử
dụng Google Tài liệu và Google Drive hoặc Google Sites để động não, sắp xếp và phát triển bản trình bày kết quả
của bạn cho lớp học.
582 Phần bốn Xây dựng và Quản lý Hệ thống
Khởi đầu run rủi cho Healthcare.gov
NGHIÊN CỨU TÌNH HUỐNG
Đạo luật Bảo vệ Bệnh nhân và Chăm sóc Giá cả phải chăng,
thường được gọi là Obamacare, được coi là trọng tâm trong di
sản của Tổng thống Barack Obama. Cần thiết cho kế hoạch cải
cách chăm sóc sức khỏe của Obama là Chăm sóc sức khỏe
. gov, một trang web trao đổi bảo hiểm y tế hỗ trợ
việc bán các gói bảo hiểm y tế tư nhân cho
Cư dân Hoa Kỳ, hỗ trợ những người đủ điều kiện đăng
ký Medicaid và có thị trường riêng cho các doanh nghiệp
nhỏ.
Trang web cho phép người dùng so sánh giá của các gói bảo
hiểm y tế ở tiểu bang của họ, đăng ký vào một chương trình họ
chọn và tìm hiểu xem liệu họ có đủ điều kiện nhận trợ cấp chăm
sóc sức khỏe của chính phủ hay không. Người dùng trước tiên
phải đăng ký và tạo tài khoản cụ thể của riêng mình, cung cấp
một số thông tin cá nhân, để nhận thông tin chi tiết về các
chương trình chăm sóc sức khỏe có sẵn trong khu vực của họ.
Healthcare.gov được ra mắt vào ngày 1 tháng 10 năm
2013, như đã hứa, nhưng khách truy cập nhanh chóng
gặp phải vô số vấn đề kỹ thuật. Phần mềm gán danh
tính kỹ thuật số cho người đăng ký và đảm bảo rằng họ
chỉ nhìn thấy dữ liệu cá nhân của riêng họ đã bị lấn át.
Khách hàng gặp phải thông báo lỗi khó hiểu và không
thể đăng nhập để tạo tài khoản. Nhiều người dùng nhận
được báo giá không chính xác vì tính năng này sử dụng
giá chỉ dựa trên hai nhóm tuổi. Người ta ước tính rằng
chỉ có 1% người tiêu dùng quan tâm có thể đăng ký
thông qua trang web trong tuần đầu tiên hoạt động và
nhiều đơn đăng ký gửi đến các công ty bảo hiểm chứa
thông tin sai lệch. Hàng nghìn người đăng ký
HealthCare.gov — ít nhất 1/5 khi có vấn đề — đã nhận
được các nhiệm vụ không chính xác cho Medicaid hoặc
cho các chương trình y tế tư nhân. Một số người đã bị từ
chối bảo hiểm một cách sai lầm.
Các công ty bảo hiểm đã nhận được các hồ sơ đăng ký từ
sàn giao dịch liên bang không đầy đủ hoặc không chính xác,
nhiều nhất là một phần mười. Thông tin bao gồm những ai
đang ghi danh và những trợ cấp mà họ có thể nhận được.
Một số công ty bảo hiểm cho biết họ không nhận được các
cuộc điện thoại từ những người tin rằng họ đã đăng ký một
chương trình sức khỏe cụ thể, chỉ để biết rằng công ty
không có hồ sơ về việc đăng ký. Vấn đề tuyển sinh với các
công ty bảo hiểm vẫn còn kéo dài đến tháng 11.
Giám đốc Công nghệ Hoa Kỳ Todd Park tuyên bố trên
Ngày 6 tháng 10, sự cố của Healthcare.gov là do số
lượng người dùng cao bất ngờ. Ở giữa
50.000 và 60.000 đã được mong đợi, nhưng trang
web phải xử lý 250.000 người dùng đồng thời. Hơn 8,1
triệu người đã truy cập Healthcare.gov từ ngày 1 tháng 10 năm
2013 đến ngày 4 tháng 10 năm 2013.
Các quan chức Nhà Trắng sau đó thừa nhận rằng các
vấn đề của Healthcare.gov không chỉ do lưu lượng truy
cập cao mà còn do các vấn đề về thiết kế hệ thống và
phần mềm. Các bài kiểm tra căng thẳng được thực hiện
bởi các nhà thầu một ngày trước ngày ra mắt cho thấy
trang web đã chậm lại đáng kể với chỉ 1.100 người dùng
đồng thời, ít hơn nhiều so với 50.000 đến 60.000 được
dự đoán. Các chuyên gia kỹ thuật phát hiện ra rằng
trang web này có nhiều lỗi phần cứng và phần mềm, lên
tới hơn 600 mục cần được sửa chữa.
Một nguyên nhân chính gây ra những vấn đề này
là do một phần thiết kế của hệ thống yêu cầu người
dùng tạo tài khoản cá nhân trước khi mua bảo hiểm
sức khỏe. Điều này có nghĩa là trước khi người dùng
có thể mua bảo hiểm, họ phải nhập dữ liệu cá nhân
sẽ được trao đổi giữa các hệ thống máy tính riêng
biệt do nhiều nhà cung cấp xây dựng hoặc điều hành,
bao gồm CGI Group, nhà phát triển của
Healthcare.gov; Dịch vụ Phần mềm Chất lượng; và
người kiểm tra tín dụng Experian PLC. Nếu bất kỳ
phần nào của hệ thống web này không hoạt động
bình thường, người dùng sẽ bị chặn tham gia thị
trường trao đổi. Một nút thắt cổ chai đã được tạo ra
khi các hệ thống này tương tác với một thành phần
phần mềm được gọi là Oracle Identity Manager, do
Tập đoàn Oracle cung cấp, được nhúng trong hệ
thống kiểm tra nhận dạng của chính phủ.
Các vấn đề, bao gồm các menu kéo xuống chỉ hoạt
động không liên tục và thời gian chờ đợi quá lâu, vẫn
tồn tại trong tuần thứ ba hoạt động. Trong một số
tuần trong tháng 10, trang web đã giảm 60% thời
gian.
Những gì đã xảy ra với Healthcare.gov là một ví dụ
khác về việc quản lý dự án CNTT đã trở nên tồi tệ,
điều này thường xảy ra với các dự án công nghệ lớn,
đặc biệt là những dự án cho chính phủ liên bang Hoa
Kỳ. Không có lãnh đạo nào giám sát việc triển khai
Healthcare.gov. Trung tâm Dịch vụ Medicare và
Medicaid Hoa Kỳ (CMS) đã điều phối nỗ lực phát triển.
Tuy nhiên, CMS có một cơ cấu quản lý chặt chẽ và
không có đơn vị nào được chỉ định để phụ trách toàn
bộ dự án.
CMS đã chuyển công việc xây dựng và triển khai hệ
thống Healthcare.gov cho một số

các nhà thầu bên ngoài. Giao diện người dùng của trang
web (bao gồm cả giao diện người dùng) được phát triển bởi
Hạt giống phát triển khởi nghiệp. Phần cuối (nơi diễn ra tất
cả các quá trình xử lý nặng nề về dữ liệu tuyển sinh và giao
dịch với các công ty bảo hiểm) được ký hợp đồng với CGI
Federal, một công ty con của Tập đoàn CGI đa quốc gia
Canada, đơn vị đã nhận được 231 triệu USD cho dự án. CGI
sau đó đã ký hợp đồng phụ phần lớn công việc của mình
cho các công ty khác. Điều này là phổ biến trong các dự án
lớn của chính phủ. Các chức năng liên quan đến xác thực
danh tính kỹ thuật số đã được ký hợp đồng với Experian,
công ty dịch vụ thông tin toàn cầu nổi tiếng với chuyên môn
kiểm tra tín dụng của mình.
CMS đặt ra thời hạn cho các nhà thầu, những người
dự kiến sẽ tham gia các cuộc họp để tìm hiểu chi tiết về
các thông số kỹ thuật cho trang web, nhưng các chuyên
gia máy tính đã bỏ qua một số phiên họp đó. Các nhà
thầu cho các phần khác nhau của hệ thống hầu như
không liên lạc với nhau.
Một số chuyên gia CNTT cũng chỉ trích quyết định
của CMS trong việc sử dụng phần mềm cơ sở dữ liệu
của một công ty có tên MarkLogic, nơi xử lý việc quản
lý dữ liệu khác với các hệ thống quản lý cơ sở dữ liệu
chính thống hơn của các công ty như IBM và Oracle.
Công việc diễn ra chậm hơn vì có quá ít người quen
thuộc với MarkLogic và MarkLogic tiếp tục hoạt động
dưới mức mong đợi sau khi trang web
Healthcare.gov được ra mắt.
Trang web đã không được kiểm tra kỹ lưỡng trước khi
hoạt động, vì vậy một số lỗi phần mềm và phần cứng đã
không được phát hiện. Việc thử nghiệm hệ thống của các
công ty bảo hiểm đã được lên kế hoạch vào tháng Bảy
nhưng mãi đến tuần thứ ba của tháng Chín mới bắt đầu.
CMS chịu trách nhiệm kiểm tra người dùng hệ thống trong
những tuần cuối cùng.
Các chuyên gia công nghệ cũng quy lỗi cho các nhà phát
triển của Healthcare.gov vì đã cố gắng phát hành trực tiếp tất
cả các phần của một hệ thống lớn và rất phức tạp cùng một lúc.
Sẽ tốt hơn nếu triển khai dần dần các chức năng hệ thống. CGI
tin rằng một Chăm sóc sức khỏe đầy đủ chức năng
. gov với tất cả những hồi chuông và còi được dự đoán
trước là một mục tiêu phi thực tế. Với thời gian cần thiết để
hoàn thành và kiểm tra phần mềm, không thể bắt đầu trao
đổi đầy đủ chức năng vào ngày 1 tháng 10, nhưng các quan
chức chính phủ khẳng định rằng ngày 1 tháng 10 là không
thể thương lượng và đã trở nên thiếu kiên nhẫn với hình
thức bào chữa của CGI cho việc trễ thời hạn. Chính quyền
Obama tiếp tục sửa đổi các quy định và chính sách cho đến
mùa hè năm 2013, điều đó có nghĩa là các nhà thầu phải đối
phó với các yêu cầu thay đổi.
Hệ thống ghi danh Healthcare.gov rất phức tạp.
Nó kết nối với các mạng máy tính liên bang khác, bao
gồm cả Cơ quan Quản lý An sinh Xã hội
Chương 14 Quản lý dự án 583
(SSA), Sở Thuế vụ (IRS), Các vấn đề Cựu chiến binh
(VA), Văn phòng Quản lý Nhân sự và Quân đoàn Hòa
bình. Nó phải xác minh một lượng đáng kể thông tin
cá nhân, bao gồm cả thu nhập và tình trạng nhập cư.
Các thành phần quan trọng không bao giờ được bảo
mật. Không có đủ quyền truy cập vào trung tâm dữ liệu
để ngăn trang web gặp sự cố. Không có hệ thống dự
phòng cho sự cố trang web được tạo. Sự tương tác giữa
trung tâm dữ liệu nơi lưu trữ thông tin và hệ thống được
cấu hình kém đến mức nó phải được thiết kế lại.
CMS đã có một số cảnh báo từ tháng 3 đến tháng 7
rằng dự án đang đi chệch hướng nhưng không tìm kiếm
sự tham gia sâu của Nhà Trắng hoặc thay đổi cơ cấu
lãnh đạo, theo các quan chức, trợ lý quốc hội và email
trong giai đoạn này. Một báo cáo quản trị lưu ý rằng sự
giám sát quản lý không đầy đủ và sự phối hợp giữa các
nhóm kỹ thuật đã ngăn cản việc ra quyết định theo thời
gian thực và phản ứng hiệu quả để giải quyết các vấn đề
với trang web.
Công ty tư vấn McKinsey & Co. đã trình bày chi tiết về
những rủi ro tiềm ẩn của dự án trong một bài thuyết
trình từ ngày 28 tháng 3 đến ngày 8 tháng 4 với quan
chức CMS hàng đầu, Marilyn Tavenner, với Bộ trưởng Y
tế và Dịch vụ Nhân sinh Kathleen Sebelius, và Giám đốc
Công nghệ Nhà Trắng Todd Park. Báo cáo của McKinsey
đã dự đoán nhiều cạm bẫy của trang web và thúc giục
ban quản trị chỉ định một trưởng dự án duy nhất để hợp
lý hóa việc ra quyết định. Nó cũng nhấn mạnh tầm quan
trọng của sự hỗ trợ của Nhà Trắng đối với CMS để đáp
ứng ngày ra mắt 1/10. Tuy nhiên, theo các tài liệu từ thời
kỳ và các quan chức, sự tham gia tối thiểu của Nhà
Trắng vào các chi tiết của dự án không thay đổi sau báo
cáo của McKinsey.
Nhà Trắng đã tập hợp các chuyên gia từ chính phủ và
ngành công nghiệp, và họ làm việc điên cuồng để sửa chữa
hệ thống. Chính quyền Obama đã chỉ định nhà thầu Quality
Software Services Inc. (QSSI) để điều phối công việc liên
quan đến việc sửa chữa trang web. QSSI đã làm việc trước
đó trên back-end của trang web. Vào tháng 1 năm 2014,
Accenture đã thay thế CGI Group làm nhà thầu chính của
trang web.
Công việc sửa chữa trang web tiếp tục diễn ra
trong suốt tháng 10 và tháng 11 năm 2013, và trang
web dường như hoạt động trơn tru hơn. Đối với đại
đa số người dùng, Healthcare.gov đã hoạt động hơn
90% thời gian. Thời gian phản hồi (thời gian cần thiết
để tải một trang web) đã giảm từ tám giây xuống còn
ít hơn một giây. Tỷ lệ thông báo lỗi ngăn mọi người
sử dụng trang web đã giảm từ 6 phần trăm xuống
0,75 phần trăm, nhưng đến ngày 30 tháng 11, chỉ có
137.000 người đăng ký riêng tư
584 Phần bốn Xây dựng và Quản lý Hệ thống
bảo hiểm y tế, ít hơn nhiều so với dự báo của chính phủ.
Các vấn đề của Healthcare.gov cũng buộc chính quyền
Obama phải trì hoãn một năm việc trao đổi trực tuyến
cho các doanh nghiệp nhỏ.
Reuters báo cáo vào giữa tháng 10 năm 2013 rằng tổng
chi phí xây dựng Healthcare.gov sử dụng các nhà thầu đã
tăng gấp ba lần từ ước tính ban đầu là 93,7 triệu đô la lên
khoảng 292 triệu đô la. Tổng chi phí xây dựng trang web
đạt 500 triệu đô la vào tháng 10 năm 2013. Tính đến tháng
2 năm 2014, chính phủ đã cam kết trả 800 triệu đô la cho
các hợp đồng cho trang web, và toàn bộ số tiền đã chi cho
đến nay vẫn chưa được biết.
Đến đầu năm 2014, Healthcare.gov đã hoạt động tốt
hơn nhiều nhưng không gặp sự cố. Sau đó HealthCare
. gov đã ngừng hoạt động ngay sau nửa đêm ngày 30 tháng 3,
2014, và vẫn không sử dụng được cho đến một ngày sau đó.
Một số trong số hàng trăm nghìn người Mỹ đang cố gắng đăng
ký dịch vụ chăm sóc sức khỏe vào phút cuối cùng của thời gian
ghi danh đã không thể làm như vậy. Tuy nhiên, 8 triệu người đã
đăng ký chăm sóc sức khỏe trong năm đó.
Kathleen Sebelius từ chức Bộ trưởng Y tế và Dịch vụ
Nhân sinh vào ngày 10 tháng 4 năm 2014, và được thay thế
bởi Sylvia Mathews Burwell vào ngày 9 tháng 6 năm đó. Vào
ngày 30 tháng 7 năm 2014, Văn phòng Trách nhiệm Giải
trình của Chính phủ Hoa Kỳ (GAO) đã công bố một nghiên
cứu phi đảng phái cho thấy trang web Healthcare.gov được
phát triển mà không có các hoạt động lập kế hoạch hoặc
giám sát hiệu quả. Những phát hiện này được hỗ trợ bởi
một báo cáo khác do Tổng Thanh tra Bộ Y tế và Dịch vụ
Nhân sinh ban hành vào tháng 1 năm 2015. Cuộc điều tra
của Tổng Thanh tra cho thấy chính phủ liên bang đã không
điều tra đầy đủ quá khứ.
Của tôiPhòng thí nghiệm MIS
Đi tới phần Bài tập của MyLab MIS để hoàn thành các bài tập viết này.
14-15 Xác định và mô tả ba phương pháp giúp các nhà quản lý lựa chọn các dự án hệ thống thông tin.
14-16 So sánh hai loại công cụ lập kế hoạch và kiểm soát chính.
hoạt động của CGI trước khi trao hợp đồng và đã bỏ qua
việc đặt giới hạn cho các hóa đơn của nhà thầu.
Sau màn ra mắt đầy chông gai, HealthCare.gov xuất hiện
vào năm 2015 đã hoạt động trơn tru. Đã có một vài trục trặc kỹ
thuật nhỏ, tồn tại trong thời gian ngắn. Chính quyền Obama đã
có thể tự hào rằng việc đăng ký 11 triệu người vào các kế hoạch
chăm sóc sức khỏe cho năm 2015 đã vượt qua mục tiêu của
tổng thống.
Nguồn: Louise Radnofsky, “Người giám sát kém, Sự ra mắt của trang web
chăm sóc sức khỏe Work Marred,” Tạp chí Phố Wall, 20 Tháng Giêng 2015;
Alex Barinka, “Healthcare.gov Bug Plagues Obamacare Ngay trước thời hạn,”
Bloomberg, 14 Tháng Hai 2015; Amy Nordrum, “Trang web Healthcare.gov
của Obama chưa đủ thân thiện với người tiêu dùng, các chuyên gia nói,”Thời
báo Kinh doanh Quốc tế, 18 Tháng Hai 2015; Spencer E. Ante và Louise
Radnofsky, “Tai ương kỹ thuật mới gây khó khăn cho sức khỏeTạp chí Phố
Wall, 31 Tháng Ba 2014; “HealthCare.gov được cho là hoạt động như thế nào
và không hoạt động như thế nào,”Thời báo New York, 2 Tháng Mười Hai 2013;
Sheryl Gay Stolberg và Michael D. Shear, “Bên trong cuộc chạy đua giải cứu
một địa điểm chăm sóc sức khỏe, và Obama,”Thời báo New York, 30 Tháng
Mười Một 2013; Gautham Nagesh, “Các vấn đề về trang web sức khỏe đã
không được gắn cờ đúng lúc,”Tạp chí Phố Wall, 2 Tháng Mười Hai 2013;
Christopher Weaver và Louise Radnofsky, “Tìm thấy Flaws của Healthcare.gov,
Fixes Eyed,”Tạp chí Phố Wall, Ngày 10 tháng 10 năm 2013, và “Trang web Y tế
Liên bang bị cản trở bởi Thiếu định hướng,” Tạp chí Phố Wall, Ngày 28 tháng
10 năm 2013; và Eric Lipton, Jan Austen, và Sharon LaFraniere, “Căng thẳng và
thất bại trước sự cố trang web về sức khỏe”Thời báo New York, Ngày 22 tháng
11 năm 2013.
CÂU HỎI NGHIÊN CỨU TÌNH HUỐNG
14-12 Tại sao dự án Healthcare.gov lại như vậy
quan trọng?
14-13 Đánh giá các yếu tố rủi ro chính trong dự án này.
14-14 Mô tả các bước lẽ ra phải được thực hiện
để ngăn chặn một kết quả tiêu cực trong dự án này.
 Chương 14 Quản lý dự án 585

Jiang, James J., Jamie YT Chang, Houn-Gee Chen, Eric TG

Chương 14 Tài liệu tham khảo Wang và Gary Klein. “Đạt được các Mục tiêu của Chương
trình CNTT với Quản lý Xung đột Tích hợp.”Tạp chí Hệ
thống thông tin quản lý 31, số 1 (Hè 2014).
Karhade, Prasanna, Michael J. Shaw và Ramanath
Subramanyam. “Các mẫu trong Hệ thống Thông tin Ưu tiên Danh mục
1E. “Chi phí Thực của Phần mềm Không sử dụng.” www.1E.com, đã truy cập
Đầu tư: Bằng chứng từ Sự khởi đầu của Cây Quyết định.”MIS hàng
Ngày 5 tháng 2 năm 2016.
quý 39, số 2 (tháng 6 năm 2015).
Appan, Radha và Glenn J. Browne. “Tác động của nhà phân tích-
Keen, Peter W. “Hệ thống Thông tin và Thay đổi Tổ chức.”
Thông tin sai lệch gây ra về quá trình kích thích yêu cầu. ”
Thông tin liên lạc của ACM 24 (tháng 1 năm 1981).
MIS hàng quý 36, No 1 (tháng 3 năm 2012).
Keil, Mark, H. Jeff Smith, Charalambos L. Iacovou và Ronald L.
Nhân viên ngân hàng, Rajiv. “Ý nghĩa giá trị của các khoản đầu tư tương đối vào
Thompson. “Cạm bẫy của Báo cáo Tình trạng Dự án.”Đánh
Công nghệ thông tin." Khoa Hệ thống Thông tin và
giá Quản lý MIT Sloan 55, số 3 (Xuân 2014).
Trung tâm Nghiên cứu Kinh tế Kỹ thuật số, Đại học
Keil, Mark, Joan Mann và Arun Rai. “Tại sao lại là dự án phần mềm
Texas tại Dallas, ngày 23 tháng 1 năm 2001.
Escalate: Phân tích thực nghiệm và kiểm tra bốn mô hình lý
Barki, Henri, Suzanne Rivard và Jean Talbot. “Một sự tích hợp
thuyết. ” MIS hàng quý 24, số 4 (tháng 12 năm 2000).
Mô hình Dự phòng của Quản lý Rủi ro Dự án Phần mềm. ”
Kim, Hee Woo và Atreyi Kankanhalli. “Người dùng đang điều tra
Tạp chí Hệ thống thông tin quản lý 17, số 4 (Mùa xuân
Khả năng chống lại việc triển khai hệ thống thông tin: Quan
Năm 2001).
điểm thiên vị hiện trạng. ” MIS hàng quý 33, số 3 (tháng 9
Bloch, Michael, Sen Blumberg và Jurgen Laartz. “Cung cấp
2009).
Các Dự án CNTT Quy mô lớn về Thời gian, Ngân sách và Giá trị. ”
Kloppenborg, Timothy J. và Debbie Tesch. “Cách điều hành
McKinsey hàng quý (Tháng 10 năm 2012).
Nhà tài trợ Ảnh hưởng đến Thành công của Dự án. ” MIT Sloan Management
Brock, Jon Tamim Saleh và Sesh Iyer. “Các dự án CNTT Quy mô lớn:
Review (Mùa xuân 2015).
Từ Ác mộng đến Tạo ra Giá trị. ” Tập đoàn Tư vấn Boston (ngày 20 tháng
Kolb, DA và AL Frohman. “Một tổ chức phát triển
5 năm 2015).
Phương pháp tiếp cận Tư vấn. ” Đánh giá quản lý Sloan 12 (Mùa thu
Browning, Tyson, R. và Ranga V. Ramasesh. “Giảm
năm 1970).
Những bất ngờ không mong muốn trong Quản lý Dự án. ” MIT Sloan
Lapointe, Liette và Suzanne Rivard. “Một mô hình đa cấp của
Management Review (Mùa xuân 2015).
Chống lại việc triển khai công nghệ thông tin. ”
Brynjolfsson, Erik và Lorin M. Hitt. “Công nghệ thông tin và
MIS hàng quý 29, số 3 (tháng 9 năm 2005).
Thiết kế tổ chức: Bằng chứng từ Dữ liệu vi mô. ” (Tháng Một
Laudon, Kenneth C. “CIO hãy coi chừng: Hệ thống quy mô rất lớn.”
1998).
Trung tâm Nghiên cứu Hệ thống Thông tin, Trường Kinh
Ditmore, Jim. "Tại sao các dự án CNTT lớn lại thường xuyên thất bại?"Thông tin
doanh Stern thuộc Đại học New York, tài liệu làm việc (1989).
Tuần (Ngày 29 tháng 10 năm 2013).
Laufer, Alexander, Edward J. Hoffman, Jeffrey S.Russell và W.
Dubravka Cecez-Kecmanovic, Karlheinz Kautz và Rebecca
Scott Cameron. "Những gì các nhà quản lý dự án thành công làm."MIT
Abrahall. “Tái cấu trúc sự thành công và thất bại của hệ thống thông tin:
Sloan Management Review (Mùa xuân 2015).
Một viễn cảnh thực hiện.”MIS hàng quý 38, số 2 (tháng 6 năm 2014).
Lee, Jong Seok, Mark Keil và Vijay Kasi. “Hiệu ứng của một
Mục tiêu về ngân sách và lịch trình về việc leo thang dự án phần mềm. ”
Chandrasekaran, Sriram, Sauri Gudlavalleti và Sanjay Kaniyar.
Tạp chí Hệ thống thông tin quản lý 29, số 1 (Mùa hè
“Đạt được thành công trong các dự án phần mềm phức tạp lớn.”
2012).
McKinsey hàng quý (Tháng 7 năm 2014).
Li, Xitong và Madnick, Stuart E. “Hiểu Động lực của việc Triển khai
Clement, Andrew và Peter Van den Besselaar. “Một cuộc hồi tưởng
Kiến trúc Hướng Dịch vụ.” Tạp chí Hệ thống thông tin quản lý
Hãy nhìn vào các Dự án PD. ” Thông tin liên lạc của ACM 36, số 4 (tháng 6
32, số 2 (2015).
năm 1993).
Liang, Huigang, Zeyu Peng, Xue Zeyu, Guo Yajiong và Wang
Delone, William H. và Ephraim R. McLean. “Delone và
Xitong. “Sự khám phá của nhân viên đối với các hệ thống phức
Mô hình thành công của hệ thống thông tin McLean: Bản cập
tạp: Quan điểm tích hợp.”Tạp chí Hệ thống thông tin quản lý
nhật 10 năm. Tạp chí Hệ thống thông tin quản lý 19, số 4 (Mùa
32 số 1 (2015).
xuân năm 2003).
Liang, Huigang, Nilesh Sharaf, Qing Hu và Yajiong Xue.
Flyvbjerg, Bent và Alexander Budzier. “Tại sao dự án CNTT của bạn có thể
“Sự đồng nhất của các hệ thống doanh nghiệp: Ảnh hưởng
Hãy mạo hiểm hơn bạn nghĩ. ” Tạp chí Kinh doanh Harvard
của các áp lực về thể chế và vai trò hòa giải của Ban lãnh đạo
(Tháng 9 năm 2011).
cao nhất.” MIS hàng quý 31, số 1 (tháng 3 năm 2007).
He Jun và William R. King. “Vai trò của việc người dùng tham gia
Mastrogiacomo, Stefano, Stephanie Missonier và Riccardo
Phát triển hệ thống thông tin: Hàm ý từ phân tích tổng
Bể sục. “Nói trước khi quá muộn: Xem xét lại vai trò của trò
hợp. ” Tạp chí Hệ thống thông tin quản lý
chuyện trong quản lý dự án hệ thống thông tin.”
25, số 1 (Mùa hè 2008).
Tạp chí Hệ thống thông tin quản lý 31, số 1 (Mùa hè
Hitt, Lorin, DJ Wu và Xiaoge Zhou. “Đầu tư vào doanh nghiệp
2014).
Hoạch định Nguồn lực: Các Biện pháp Tác động Kinh doanh và
McFarlan, F. Warren. “Phương pháp tiếp cận danh mục đầu tư đối với hệ thống thông tin.”
Năng suất. ” Tạp chí Hệ thống thông tin quản lý 19, số 1 (Mùa
Tạp chí Kinh doanh Harvard (Tháng 9 - tháng 10 năm 1981). Mumford,
hè năm 2002).
Enid và Mary Weir.Hệ thống máy tính trong thiết kế công việc:
Housel, Thomas J., Omar El Sawy, Jianfang Zhong và Waymond
Phương pháp ĐẠO ĐỨC. New York: John Wiley (1979).
Rodgers. “Đo lường Lợi tức trên các Sáng kiến Kinh doanh Điện tử ở
Polites, Greta L. và Elena Karahanna. “Bị trói vào trạng thái
Cấp độ Quy trình: Phương pháp Tiếp cận Giá trị Gia tăng Tri thức.”
Quo: Tác động ức chế của thói quen hệ thống đương nhiệm, chi phí
ICIS (2001).
chuyển đổi và sức ì đối với việc chấp nhận hệ thống mới. ”
Jeffrey, Mark và Ingmar Leliveld. “Các phương pháp hay nhất trong danh mục CNTT
MIS hàng quý 36, số 1 (tháng 3 năm 2012).
Ban quản lý." Đánh giá Quản lý MIT Sloan 45, số 3 (Xuân
Viện Quản lý dự án. Hướng dẫn quản lý dự án
2004).
Cấu trúc cơ thể (Xuất bản lần thứ 5). Quảng trường Newtown,
PA: Viện Quản lý Dự án (2013).
586 Phần bốn Xây dựng và Quản lý Hệ thống
___________ “Chi phí cao nhưng hiệu suất thấp.” (2016).
Ramasubbu, Narayan, Anandhi Bharadwaj và Giri Kumar
Tayi. “Đa dạng Quy trình Phần mềm: Khái niệm, Đo
lường và Phân tích Tác động đến Hiệu suất Dự án.”MIS
hàng quý 39, số 4 (tháng 12 năm 2015).
Reisinger, Don. “10 Công cụ quản lý dự án dựa trên đám mây để
Phục vụ mọi nhu cầu của Công ty. ” eWeek (Ngày 10 tháng 3 năm
2016). Rivard, Suzanne và Liette Lapointe. "Công nghệ thông tin
Phản ứng của người thực hiện đối với sự phản kháng của người dùng: Bản
chất và Ảnh hưởng. ” MIS hàng quý 36, số 3 (tháng 9 năm 2012).
Ross, Jeanne W. và Cynthia M. Beath. “Ngoài Doanh nghiệp
Trường hợp: Cách tiếp cận mới để đầu tư CNTT. ” Đánh giá quản lý
Sloan 43, số 2 (Mùa đông 2002).
Ryan, Sherry D., David A. Harrison và Lawrence L Schkade.
“Quyết định đầu tư vào công nghệ thông tin: Khi nào thì chi
phí và lợi ích trong hệ thống con xã hội quan trọng?” Tạp chí
Hệ thống thông tin quản lý 19, số 2 (Mùa thu 2002).
Schmidt, Roy, Kalle Lyytinen, Mark Keil và Paul Cule.
“Xác định Rủi ro Dự án Phần mềm: Một Nghiên cứu Quốc tế của
Delphi.” Tạp chí Hệ thống thông tin quản lý 17, số 4 (Mùa xuân
năm 2001).
Schwalbe, Kathy. Quản lý dự án công nghệ thông tin (Thứ 8
ed.). Cengage (2016).
Sharma, Rajeev và Philip Yetton. “Các tác động tiềm ẩn của
Đào tạo, Độ phức tạp Kỹ thuật và Sự phụ thuộc lẫn nhau của Nhiệm
vụ vào việc Triển khai Hệ thống Thông tin Thành công. ” MIS hàng
quý 31, số 2 (tháng 6 năm 2007).
Smith, H. Jeff, Mark Keil và Gordon Depledge. “Giữ mẹ như
Dự án bắt đầu được tiến hành. ” Tạp chí Hệ thống thông tin
quản lý 18, số 2 (Mùa thu 2001).
Sting, Fabian J., Christoph H. Loch, và Dirk Stempfhuber.
“Tăng tốc Dự án bằng cách Khuyến khích Trợ giúp.” MIT Sloan
Management Review (Mùa xuân 2015).
Swanson, E. Burton. Triển khai Hệ thống Thông tin.
Homewood, IL: Richard D. Irwin (1988).
Sykes, Tracy Ann. “Các cấu trúc hỗ trợ và tác động của chúng đối với
Kết quả của nhân viên: Nghiên cứu thực địa dọc về việc triển khai
hệ thống doanh nghiệp. ” MIS hàng quý 39, số 2 (tháng 6 năm
2015).
Tornatsky, Louis G., JD Eveland, MG Boylan, WA Hetzner,
EC Johnson, D. Roitman và J. Schneider. Quy trình đổi mới
công nghệ: Ôn tập văn học. Washington, DC: Quỹ Khoa học
Quốc gia (1983).
Vaidyanathan, Ganesh. Quản lý dự án: Quy trình, Công nghệ
va luyện tập. Thượng Saddle River, NJ: Prentice Hall (2013).
Wang, Eric TG, Gary Klein và James J. Jiang. “ERP Misfit:
Quốc gia xuất xứ và các yếu tố tổ chức. ” Tạp chí Hệ thống
thông tin quản lý 23, số 1 (Mùa hè năm 2006).
Westerman, George. "CNTT đến từ sao Kim, không phải CNTT là từ sao Hỏa."tường
Tạp chí Đường phố (Ngày 2 tháng 4 năm 2012).
Xue, Yajion, Huigang Liang và William R. Boulton. "Thông tin
Quản trị Công nghệ trong Quy trình Quyết định Đầu tư
Công nghệ Thông tin: Tác động của Đặc điểm Đầu tư, Môi
trường Bên ngoài và Bối cảnh Nội bộ. ” MIS hàng quý 32, số
1 (tháng 3 năm 2008).
Yin, Robert K. “Lịch sử cuộc đời của những đổi mới: Cách thực hành mới
Trở thành Routized. ” Đánh giá hành chính công (Tháng 1– tháng
2 năm 1981).
Zhu, Kevin và Kenneth L. Kraemer. “Chỉ số Thương mại Điện tử cho
Tổ chức tăng cường mạng: Đánh giá giá trị của thương mại điện tử
đối với hiệu quả hoạt động của doanh nghiệp trong lĩnh vực sản
xuất. ” Nghiên cứu hệ thống thông tin 13, số 3 (tháng 9
Năm 2002).