12 lý do thất bại trong Analytics và Business Intelligence
Số 9 có thể làm bạn ngạc nhiên
Trong phân tích và kinh doanh thông minh, có rất nhiều thứ có thể xảy ra sai sót. Sau tất cả, chúng tôi đang tìm kiếm phiên bản duy nhất của sự thật. Cho dù đó là một báo cáo hay một dự án - để dữ liệu và kết quả xuất hiện nhất quán, có thể kiểm chứng, chính xác và quan trọng nhất là được người dùng cuối chấp nhận - thì có rất nhiều liên kết đến chuỗi phải đúng. Thực hành Tích hợp liên tục, được phát minh bởi các nhà phát triển phần mềm và được cộng đồng phân tích và trí tuệ kinh doanh mượn, là một nỗ lực để phát hiện sớm các lỗi hoặc sai sót.
Tuy nhiên, sai lầm vẫn len lỏi vào sản phẩm cuối cùng. Tại sao nó sai? Đây là một số lời xin lỗi lý do tại sao bảng điều khiển sai hoặc dự án không thành công.
- Nó sẽ nhanh hơn. Vâng, điều này có lẽ đúng. Đó là một vấn đề của sự đánh đổi. Bạn thích cái nào hơn? Bạn muốn nó nhanh hay bạn muốn nó được thực hiện đúng?
Thành thật mà nói, đôi khi chúng ta bị đặt vào vị trí đó. Tôi cần nó trước thứ sáu. Tôi cần nó hôm nay. Không, tôi cần nó ngày hôm qua. Ông chủ không hỏi sẽ mất bao lâu. Anh ta nói với chúng tôi đã phải làm điều đó trong bao lâu. Vì đó là lúc Sales cần. Vì đó là lúc khách hàng muốn. - Nó sẽ đủ tốt. Sự hoàn hảo là điều không thể và bên cạnh sự hoàn hảo là kẻ thù của điều tốt. Các phát minh của radar cảnh báo sớm cuộc không kích đã đề xuất một "sự sùng bái của những người không hoàn hảo". Triết lý của ông ấy là “Luôn cố gắng mang đến cho quân đội những điều tốt nhất thứ ba vì điều tốt nhất là không thể và điều tốt nhất thứ hai luôn là quá muộn”. Chúng tôi sẽ để lại sự sùng bái của những người không hoàn hảo cho quân đội. Tôi nghĩ rằng điểm của sự tiến bộ nhanh nhẹn, gia tăng hướng tới kết quả cuối cùng đã bị bỏ sót ở đây. Trong phương pháp Agile, có khái niệm về Sản phẩm khả thi tối thiểu (MVP). Từ khóa ở đây là khả thi. Nó không chết khi đến và nó không xong. Những gì bạn có là một con đường trên hành trình đến đích thành công.
- Nó sẽ rẻ hơn. Không hẳn vậy. Về lâu dài thì không. Nó luôn luôn tốn nhiều chi phí hơn để sửa chữa nó sau này. Sẽ rẻ hơn nếu làm ngay lần đầu tiên.
Đối với mỗi bước bị loại bỏ khỏi mã hóa ban đầu, chi phí sẽ cao hơn một bậc. Lý do này liên quan đến điều đầu tiên, tốc độ giao hàng. Ba cạnh của tam giác quản lý dự án là phạm vi, chi phí và thời hạn. Bạn không thể thay đổi một cái mà không ảnh hưởng đến những cái khác. Nguyên tắc tương tự cũng được áp dụng ở đây: chọn hai. Tốt. Nhanh. Rẻ. https://www.pyragraph.com/2013/05/good-fast-cheap-you-can-only-pick-two/ - Nó chỉ là một POC. Nó không giống như chúng ta sẽ đưa Proof of Concept này vào sản xuất, phải không? Điều này là về việc thiết lập các kỳ vọng một cách thích hợp. POC thường có thời hạn với một tập hợp các mục tiêu hoặc trường hợp sử dụng cụ thể để đánh giá ứng dụng hoặc môi trường. Những trường hợp sử dụng đó đại diện cho những điều quan trọng cần phải có hoặc những mẫu chung. Vì vậy, đánh giá POC, theo định nghĩa, là một phần của miếng bánh lớn hơn mà chúng ta có thể đưa ra các quyết định tiếp theo. Nó là ít khi Không bao giờ là một ý tưởng hay khi đưa POC vào sản xuất, cho dù đó là phần mềm hay phần cứng.
- Nó chỉ là tạm thời.
Nếu kết quả sai, nó hoạt động kém, hoặc nó chỉ đơn giản là xấu xí, nó sẽ không được đưa vào sản xuất. Ngay cả khi đây là đầu ra tạm thời, nó cần phải có sẵn. Người dùng cuối và các bên liên quan sẽ không chấp nhận điều này. Tuy nhiên, báo trước là có thể chấp nhận được nếu đây là những kỳ vọng đã được đặt ra như một phần của quá trình. "Các con số là đúng, nhưng chúng tôi muốn phản hồi của bạn về màu sắc trong trang tổng quan." Tuy nhiên, điều này không nên được sản xuất; nó phải ở trong một môi trường thấp hơn. Thông thường, "nó chỉ là tạm thời" trở thành mục đích tốt của một vấn đề vĩnh viễn. - Đây là cách duy nhất tôi biết. Đôi khi có nhiều hơn một câu trả lời đúng. Và, đôi khi có nhiều hơn một con đường để đi đến đích. Đôi khi chúng ta mang theo những thói quen cũ của mình. Họ chết khó. Sử dụng điều này như một thời điểm học tập. Học đúng cách. Hãy dành thời gian. Yêu cầu giúp đỡ.
- Đây là cách chúng tôi luôn làm. Cái này khó sửa và khó tranh cãi. Cần có quản lý thay đổi tổ chức thực sự để thay đổi các quy trình và những người thực hiện chúng. Thông thường, một dự án mới, phần mềm mới, nâng cấp hoặc di chuyển, sẽ bộc lộ các vấn đề tiềm ẩn lâu nay. Đã đến lúc phải thay đổi.
- Rất tiếc, Tôi đã làm lại.
Tôi là một người làm đồ gỗ và chúng tôi có một phương châm vì rất nhiều sai lầm mắc phải: đo hai lần và cắt một lần. Tôi biết câu cách ngôn này. Tôi lặp lại điều đó với chính mình. Nhưng, tôi xấu hổ khi phải nói rằng, vẫn có những lúc bảng của tôi xuất hiện quá ngắn. Đây có phải là sự bất cẩn? Có lẽ. Tuy nhiên, thường xuyên hơn không, nó chỉ là một cái gì đó nhanh chóng và dễ dàng. Tôi không thực sự cần một kế hoạch. Nhưng, bạn biết không? Nếu tôi dành thời gian để vạch ra một kế hoạch, rất có thể các con số đã được tính toán. Đoạn quá ngắn có thể đã nằm trên giấy và một cục tẩy sẽ sửa nó. Điều này cũng đúng với phân tích và trí tuệ kinh doanh, một kế hoạch - ngay cả đối với một cái gì đó nhanh chóng và dễ dàng - có thể giảm những loại sai lầm này. - Phiền nhiễu. Nhìn mà không thấy. Sự mù quáng không chủ ý. Bạn có thể đã thấy video nơi bạn được giao một nhiệm vụ phải làm, chẳng hạn như đếm số lần chuyền bóng rổ của một đội. Trong khi bạn đang bị phân tâm khi thực hiện nhiệm vụ đơn giản đó, [SPOILER ALERT] bạn không nhận thấy con khỉ đột đi dạo trên mặt trăng. Tôi biết điều gì sẽ xảy ra và tôi vẫn sẽ phải làm một nhân chứng khủng khiếp nếu một tội ác đã được thực hiện. Điều tương tự cũng xảy ra trong việc phát triển các báo cáo. Các yêu cầu đòi hỏi sự liên kết pixel hoàn hảo, biểu trưng phải được cập nhật, tuyên bố từ chối trách nhiệm pháp lý phải được bao gồm. Đừng để điều đó làm bạn phân tâm khỏi việc đảm bảo các phép tính được xác thực.
- Bạn dự định.
Hoặc, mong đợi. Ít nhất, nó luôn là một lựa chọn. Thomas Edison đã nói nổi tiếng “Tôi không thất bại. Tôi vừa tìm một vạn cách mà không hiệu quả ”. Triết lý của anh ấy là với mỗi thất bại, anh ấy sẽ tiến gần hơn một bước tới thành công. Theo một nghĩa nào đó, anh ta đã lên kế hoạch thất bại. Anh ấy đã loại trừ các khả năng. Anh ta chỉ dùng đến thử và sai khi cạn kiệt lý thuyết. Tôi không có hơn một nghìn bằng sáng chế mang tên mình như Edison, nhưng tôi nghĩ chúng ta có thể có những cách tiếp cận tốt hơn để phát triển các phân tích hoặc báo cáo. (Đơn xin cấp bằng sáng chế của Thomas Edison cho đèn điện sợi đốt năm 1882.) - Sự ngu ngốc. Đừng phủ nhận nó. Điều này tồn tại. Sự ngu ngốc nằm ở đâu đó giữa “Bạn dự định” và “Rất tiếc”. Loại thất bại hoành tráng này là loại đồng hồ-này-giữ-tôi-bia, Giải thưởng Darwin. Vì vậy, có thể, đôi khi có liên quan đến rượu. May mắn thay, trong nghề của chúng tôi, theo như tôi biết, một bảng điều khiển say rượu chưa bao giờ giết ai. Nhưng, nếu tất cả đều giống bạn, nếu bạn làm việc trong một nhà máy điện hạt nhân, hãy thực hiện phân tích của bạn một cách tỉnh táo.
- Thành công không quan trọng.
Diễn viên đóng thế huyền thoại Evil Knievel được trả tiền khi thực hiện các pha nguy hiểm bất chấp tử thần. Thành công hay thất bại - dù anh ta đã hạ cánh hay không - anh ta vẫn nhận được một tấm séc. Mục tiêu của anh ta là sống sót. Trừ khi bạn được bồi thường khi bị gãy xương - Knievel đã có Kỷ lục Guiness Thế giới về số người bị gãy xương nhiều nhất trong đời - thì thành công mới là điều quan trọng.
