Mọi data warehouse và sáng kiến kinh doanh thông minh đều có rủi ro. Học cách xác định chúng ngay từ đầu và chọn biện pháp khắc phục hoặc kỹ thuật giảm thiểu tối ưu để giải quyết từng rủi ro.

Điều cần thiết là xác định những rủi ro tiềm ẩn trong mọi dự án và giải quyết những rủi ro đó trước khi chúng trở thành vấn đề lớn. Rủi ro vốn có trong bất kỳ dự án nào nhưng rủi ro liên quan đến dự án data warehouse dường như lớn hơn các dự án khác và có nhiều loại rủi ro khác nhau trong những nỗ lực lớn hơn này. Tuy nhiên, mỗi rủi ro đều có ít nhất một biện pháp khắc phục hoặc kỹ thuật giảm thiểu đã được chứng minh để có thể giải quyết thành công.

Không có nhiệm vụ hoặc mục tiêu

Cả sứ mệnh và mục tiêu của data warehouse đều chưa được xác định. Đây là một con thuyền không có bánh lái. Không rõ data warehouse sẽ đi đâu hoặc vấn đề kinh doanh nào mà nó phải giải quyết.

Để tránh tình trạng này, hãy kiểm tra các biện pháp khắc phục sau:

Xác định Nhà tài trợ data warehouse 

Nhà tài trợ – thường là về phía doanh nghiệp – là người có lợi ích lớn trong sự thành công của data warehouse. Đó có thể là một trưởng bộ phận rất cần thông tin mà data warehouse sẽ cung cấp. Đôi khi, một giám đốc điều hành CNTT, người phù hợp với yêu cầu kinh doanh quan trọng , có cổ phần nghề nghiệp trong sự thành công của data warehouse.

Xác định sứ mệnh và mục tiêu trước tiên 

Nhấn mạnh hoặc khuyến nghị mạnh mẽ rằng sứ mệnh và mục tiêu phải được xác định trước bất kỳ hoạt động nghiêm túc nào trong dự án. Đây là một vấn đề của những gì đến trước. Ban quản lý có thể xem việc xác định sứ mệnh và mục tiêu là một hoạt động không góp phần thúc đẩy dự án tiến triển. Bây giờ là lúc đưa ra những ví dụ về những dự án đã thất bại hoặc bị trì hoãn vì hướng đi của chúng không rõ ràng. Đừng bắt đầu dự án mà không có nhiệm vụ và mục tiêu rõ ràng, đồng thời xác định phạm vi DW .

Phát triển một bộ nhiệm vụ và mục tiêu mẫu 

Cách nhanh nhất để xây dựng và được phê duyệt cho một bộ nhiệm vụ và mục tiêu là phát triển một bộ nhiệm vụ mẫu và trình bày bộ nhiệm vụ này với Ban Cố vấn CNTT và Ban Cố vấn Kinh doanh và yêu cầu họ cho ý kiến và sự chấp thuận. 

Triệu tập một ủy ban 

Tập hợp một nhóm nhỏ những người có mối quan tâm sâu sắc đến data warehouse và mục đích của nó. Điều này sẽ mất nhiều thời gian hơn một chút so với cách tiếp cận trước đó nhưng sẽ nhận được nhiều hỗ trợ hơn từ tổ chức. Danh sách các nhiệm vụ và mục tiêu vẫn cần được sự chấp thuận của các ban Cố vấn Kinh doanh và CNTT. Lựa chọn cẩn thận các thành viên của ủy ban. Sẽ có một số người có ảnh hưởng quan trọng và những người ra quyết định, những người sẽ không có thời gian cho ủy ban, nhưng hãy đảm bảo sao chép chúng trên bản nháp và thu hút ý kiến ​​đóng góp của họ.

Nhiệm vụ và mục tiêu của data warehouse không liên quan tới mục tiêu của doanh nghiệp

Tài liệu hóa các mục tiêu doanh nghiệp rõ ràng 

Những mục tiêu này có thể được tìm thấy trong thư của Chủ tịch Hội đồng quản trị gửi cho các cổ đông. Nó cũng có thể được tìm thấy trong tuyên bố sứ mệnh, tuyên bố tầm nhìn của tổ chức và trong các tài liệu phác thảo định hướng chiến lược. Một số ví dụ:

• Dịch vụ khách hàng xuất sắc
• Sản phẩm chất lượng vượt trội
• Nhà cung cấp chi phí thấp
• Giao hàng nhanh nhất thị trường

Tài liệu hóa các mục tiêu doanh nghiệp ngầm định  

Nếu không có các mục tiêu doanh nghiệp rõ ràng, có thể có các mục tiêu ngầm định hoặc giả định mà hầu hết mọi người trong doanh nghiệp đều tán thành. Chúng phải được ghi lại và ánh xạ tới các mục tiêu của data warehouse.

Nếu data warehouse không hỗ trợ các mục tiêu của doanh nghiệp – Nếu các mục tiêu của doanh nghiệp tồn tại nhưng data warehouse không hỗ trợ chúng, hãy suy nghĩ lại về các mục tiêu của nhóm với data warehouse và xem xét các ứng dụng data warehouse hỗ trợ các mục tiêu chiến lược của doanh nghiệp.

Chất lượng của dữ liệu nguồn không được biết đến

Trong hầu hết các tổ chức, chất lượng của dữ liệu hoạt động hoặc là không xác định hoặc được đánh giá quá cao. Các tổ chức thường thậm chí không biết cách đánh giá chất lượng của hệ thống nguồn của họ. Nỗ lực liên quan đến việc chuyển đổi và làm sạch dữ liệu nguồn có thể là đáng kể. Không biết về chất lượng dữ liệu nguồn, không thể ước tính nỗ lực và thời gian để làm sạch dữ liệu.

Công cụ lập hồ sơ chất lượng dữ liệu 

Sử dụng công cụ đánh giá chất lượng để xác định trạng thái hiện tại của dữ liệu nguồn (tốt, kém, xấu, xấu). Xác định dữ liệu hoạt động có vấn đề về chất lượng cho một người nào đó cấp cao trong tổ chức, có thể là cho CIO, nhưng chắc chắn là cho giám đốc điều hành kinh doanh sở hữu dữ liệu.

Xác định tác động của dữ liệu bẩn đối với độ tin cậy của việc ra quyết định, xác định chi phí để làm sạch, xác định lợi ích của việc làm sạch, ưu tiên nỗ lực làm sạch và thương lượng thời gian, nỗ lực, chi phí và phạm vi với người dùng và chủ sở hữu dữ liệu .

Triển khai dữ liệu sạch nhất trước tiên 

Thường có nhiều tệp và cơ sở dữ liệu có thể được sử dụng cho dữ liệu nguồn. Chọn nguồn sạch nhất. data warehouse luôn được triển khai theo từng giai đoạn, là những sản phẩm phân phối kín đáo được cung cấp cho người dùng. Các giai đoạn khác nhau sẽ sử dụng dữ liệu nguồn khác nhau. Cố gắng cấu trúc các giai đoạn để giai đoạn đầu tiên có thể sử dụng dữ liệu nguồn sạch nhất.

Siêu dữ liệu phản ánh chất lượng  

Các chỉ số chất lượng có thể được lưu trữ trong kho lưu trữ siêu dữ liệu . Chọn chỉ định một trong bốn danh mục cho từng thành phần dữ liệu: “Nguyên sơ”, “Có vấn đề”, “Dơ bẩn” và “Không được đánh giá”.

Kỹ năng không có sẵn

Rất hiếm khi ban đầu nhóm có đúng số người vào đúng vai trò với các kỹ năng phù hợp và họ luôn sẵn sàng vào đúng thời điểm. Để giảm thiểu rủi ro liên quan đến tình trạng thiếu kỹ năng, hãy chọn một số hoặc tất cả các phương pháp sau:

Xác định trách nhiệm 

Xác định trách nhiệm chức năng của Quản trị viên dữ liệu, Quản trị viên cơ sở dữ liệu, Nhà phát triển ứng dụng, cả nhà phát triển Back End ETL và nhà phát triển Business Intelligence, Người quản lý dữ liệu và bất kỳ vai trò bắt buộc nào khác.

Xây dựng kế hoạch dự án 

Bằng cách xác định các nguồn lực cần thiết và thời điểm cần thiết trong kế hoạch dự án, Người quản lý dự án DW (PM) sẽ có thể xác định nhu cầu về đúng người với các kỹ năng phù hợp. Không có một kế hoạch như vậy, người quản lý dự án không có gì để hỗ trợ các yêu cầu của mình.

Xác định tài nguyên ứng viên

Liệt kê tất cả các nhân viên ứng viên đang được xem xét cho nhóm data warehouse và đánh giá mức độ kỹ năng của họ. Nếu tổ chức thiếu kỹ năng, hãy xem xét bổ sung đội ngũ với các nhà thầu và chuyên gia tư vấn cho đến khi có thể sắp xếp đào tạo phù hợp.

Thuyết phục quản lý 

Ban quản lý thường sẽ yêu cầu vận hành với một nhóm không đạt tiêu chuẩn – không đủ nguồn lực và kỹ năng. Thuyết phục ban quản lý về sự cần thiết phải có những người có kỹ năng trong nhóm data warehouse. Ngoài ra, hãy thuyết phục ban quản lý về sự cần thiết phải có những người này đủ tâm huyết với dự án. Ban quản lý có thể mong muốn sử dụng một người cam kết 100% cho một dự án khác. Điều này sẽ không làm việc. 

Sử dụng tài liệu từ các cuộc thảo luận với các tài liệu tham khảo bên ngoài nơi họ giải thích cần bao nhiêu người có kinh nghiệm và được đào tạo để triển khai data warehouse của họ. Dựa trên quy mô và độ phức tạp của dự án, ngoại suy và cung cấp cho ban quản lý yêu cầu nguồn lực thực tế.

Nếu ban quản lý không hỗ trợ các nguồn lực toàn thời gian, hãy thuê một nhà tư vấn đắt tiền (ban quản lý không lắng nghe các nhà tư vấn chi phí thấp) và yêu cầu họ trình bày hoặc viết một đề xuất về nguồn lực.

Ngân sách không đủ

Thường rất khó để biết trước một data warehouse sẽ có giá bao nhiêu. Ngân sách data warehouse thường bị đánh giá thấp.

Nghiên cứu 

Biên soạn các ấn phẩm, bài thuyết trình và báo cáo tư vấn trong ngành cho biết chi phí của một data warehouse trung bình điển hình thông thường là bao nhiêu. Hãy cảnh giác với những người đưa ra số liệu cho các tập con nỗ lực đã chọn, những số liệu không tính đến phần mềm hoặc phần cứng mà họ đã có sẵn hoặc những số liệu không bao gồm chi phí được giao cho một số bộ phận khác.

Ước tính chi phí

Phân loại từng khoản chi phí cho dự án của bạn. Không độn số nhưng cũng đừng coi thường nếu chi phí thật sẽ khiến quản lý tê liệt.

Suy nghĩ nhỏ hơn 

Nếu chi phí quá cao, hãy xem xét một dự án nhỏ hơn hoặc một dự án không yêu cầu một số hạng mục đắt tiền (RDBMS mới, công cụ ưa thích hoặc phần cứng mới chính)

Thiếu phần mềm hỗ trợ

Trong nhiều trường hợp, phần mềm hỗ trợ (ETL, làm sạch, công cụ BI, RDBMS, v.v.) không được chọn hoặc cài đặt không kịp thời.

Đánh giá lợi ích của phần mềm 

Hiểu lợi ích của phần mềm đối với dự án. Nếu nó không mang lại lợi ích cho dự án cụ thể này, thì việc biện minh chỉ có thể được thực hiện nếu các dự án lớn tiếp theo sẽ được hưởng lợi đáng kể từ việc sử dụng nó. Tuy nhiên, nếu nó không mang lại lợi ích cho dự án, đừng lãng phí thời gian và năng lượng để biện minh cho phần mềm.

Chi phí không sử dụng phần mềm

Định lượng chi phí không sử dụng phần mềm. Những chi phí này nên bao gồm nỗ lực bổ sung để viết mã hoặc tạo quy trình vận hành, chi phí liên tục để duy trì mã, chi phí triển khai bị trì hoãn, rủi ro gia tăng và khả năng giảm chất lượng của sản phẩm.

Chọn đại gia

Chỉ xác định phần mềm có thể đóng góp lớn. Tránh đề xuất một phần mềm thú vị, có lợi thế hàng đầu và giúp cải thiện sơ yếu lý lịch, nhưng không đóng góp đáng kể vào thành công của dự án.

Dữ liệu nguồn không hiểu

Hầu hết các tổ chức không có tài liệu hiểu biết về dữ liệu nguồn. Kiến thức có thể nằm trong đầu của ai đó hoặc được ghi lại trên máy tính xách tay của anh ta nhưng thông tin này thường không có sẵn cho phần còn lại của tổ chức.

Dữ liệu nguồn kiểm kê và mô hình 

Nếu dữ liệu nguồn không được kiểm kê cũng như không được mô hình hóa, có thể là do người dùng và ban quản lý CNTT không nhận ra tầm quan trọng của các hoạt động này. Bất kỳ khuyến nghị như vậy có thể được coi là trì hoãn dự án.

Trên thực tế, nỗ lực lập mô hình và kiểm kê siêu dữ liệu là lâu dài và tốn nhiều công sức. Nếu ban quản lý chưa nhận ra lợi ích của họ, thì dự án data warehouse cũng khó có thể hỗ trợ điều đó. Điều nguy hiểm ở đây là, trong khi các hệ thống độc lập có thể tồn tại mà không cần loại phân tích và tài liệu này, thì các hệ thống tích hợp lại không thể.

Đừng cố lập mô hình toàn bộ tổ chức mà hãy phân tích và lập mô hình các phần tử dữ liệu được nhắm mục tiêu cho data warehouse như một phần của dự án DW/BI. Tích hợp không thể xảy ra trừ khi các mối quan hệ dữ liệu được biết và thực sự có thể được xây dựng từ dữ liệu nguồn và nếu siêu dữ liệu kinh doanh và kỹ thuật đã được ghi lại và có thể được quản lý theo các phương pháp hay nhất.

Kỹ thuật đảo ngược 

Nếu có một công cụ mô hình hóa có khả năng kỹ thuật đảo ngược (khả năng lấy các định nghĩa cơ sở dữ liệu (DDL), nắm bắt chúng trong kho lưu trữ công cụ và tạo ra các mô hình thô), thì kỹ thuật đảo ngược này có thể là ít tốn kém nhất và được chấp nhận nhiều nhất điểm khởi đầu. Thật không may, nhiều cơ sở dữ liệu hiện có chứa nội dung khó hiểu và quy trình kỹ thuật đảo ngược sẽ cần nỗ lực đáng kể để làm cho tài liệu trên các cơ sở dữ liệu đó trở nên hữu ích.

Nhà tài trợ yếu

Để dự án thành công, nó cần một nhà tài trợ người dùng mạnh mẽ, có vị trí tốt , người đưa ra các quyết định hợp lý.

Thu hút những gì tốt nhất 

Nghiên cứu. Lập danh sách các nhà tài trợ và đặt những nhà tài trợ mạnh nhất lên đầu danh sách. Nghiên cứu các yêu cầu hỗ trợ quyết định của họ và xác định vấn đề nào có thể được data warehouse phục vụ tốt. Mời ứng viên hàng đầu đi ăn trưa, trình bày kết quả nghiên cứu cho người dùng đó và cố gắng bán cho họ những lợi ích của data warehouse. Giải thích cho họ những lợi ích của sáng kiến ​​và hệ thống DW/BI, phác thảo những gì họ và bộ phận của họ cần, đồng thời yêu cầu họ tài trợ.

Thu hút người giỏi thứ hai 

Nếu ứng viên hàng đầu không dễ chịu, hãy mời người thứ hai trong danh sách. Nếu người giỏi thứ hai không sẵn lòng, hãy dừng lại và làm việc khác. Trên thực tế, sẽ không hiệu quả nếu bạn đi quá sâu vào danh sách, vì những ứng viên hàng đầu là những người có tầm nhìn và quyền hạn nhất để hoàn thành một mục tiêu lớn.

Người dùng không thoải mái với công nghệ

Sẽ luôn có những người dùng, dựa trên kinh nghiệm và sự sẵn lòng của họ, sẵn sàng thử một cái gì đó mới. Tuy nhiên, sẽ có những người dùng khác có thể miễn cưỡng sử dụng công nghệ mới.

Mở rộng Hỗ trợ Người dùng 

Nếu người dùng không thoải mái với công nghệ, hãy dành nhiều tiền hơn cho Hỗ trợ Người dùng, vì các ứng dụng mới sẽ yêu cầu tương tác bổ sung với cộng đồng này. Hỗ trợ người dùng thành thạo là một cách tiếp cận khác.

Điều chỉnh kỳ vọng 

Người dùng ít thoải mái hơn sẽ tạo ra ít truy vấn hơn. Dự đoán về khối lượng truy vấn có thể cho rằng người dùng cảm thấy thoải mái hơn với hệ thống. Dành thêm thời gian để đạt được khối lượng truy vấn dự kiến. Cho phép nhiều thời gian hơn để người dùng hài lòng với hệ thống và có thể sử dụng hệ thống một cách hiệu quả. Điều chỉnh lại kỳ vọng và kỳ vọng của nhà tài trợ.

Đào tạo 

Làm chậm quá trình đào tạo để không làm học sinh sợ hãi. Hãy chắc chắn rằng các sinh viên thành công trong hội thảo của họ. Cung cấp người cố vấn trong quá trình đào tạo .

Truy vấn và báo cáo được xác định trước  

Phát triển một tập hợp toàn diện hơn các truy vấn và báo cáo được xác định trước và truyền đạt tính khả dụng của chúng tới cộng đồng người dùng. Chủ động thêm các truy vấn và báo cáo được xác định trước vào thư viện.

Giao diện người dùng thân thiện 

Chọn một công cụ BI cực kỳ thân thiện với người dùng. Chọn “ấm và mờ” thay vì “sức mạnh và chức năng”. Không quan trọng về các tính năng tuyệt vời của công cụ nếu người dùng ngại sử dụng nó. Công cụ lý tưởng vừa dễ học vừa dễ sử dụng.

Phần kết luận

Mọi data warehouse và sáng kiến ​​kinh doanh thông minh đều có rủi ro và mọi rủi ro đều có ít nhất một biện pháp khắc phục đã được chứng minh. Không để rủi ro vượt qua cơ hội cung cấp thành công data warehouse, tìm kiếm biện pháp khắc phục hoặc giảm thiểu tối ưu.