Việc thêm báo cáo Ad Hoc vào một ứng dụng có đáng để nỗ lực không?


16

Chúng tôi có một ứng dụng thu thập rất nhiều dữ liệu và đã báo cáo về nó. Lặp lại đầu tiên là một tích hợp Crystal Báo cáo hoạt động độc đáo. Tạo báo cáo trong trình thiết kế Báo cáo Pha lê và sau đó nhập tệp RPT vào ứng dụng. Điều này hoạt động tốt nhưng người dùng cần ứng dụng để chạy báo cáo và người dùng cũng không thể tạo báo cáo. Chúng tôi đã thêm các bộ lọc, bộ sắp xếp và nhóm để tệp RPT có thể tùy chỉnh, nhưng chúng không thể tạo từ đầu.

Tương tác thứ hai là một giải pháp dựa trên web sử dụng SSRS, SSAS và công cụ xây dựng báo cáo từ Microsoft. Điều này đòi hỏi một số công việc cơ sở dữ liệu và một số công việc để có được các khối và chạy từ lược đồ OLTP, nhưng cuối cùng, việc tạo báo cáo cuộn lên dễ dàng hơn nhiều. Tuy nhiên, chúng tôi vẫn phải tạo các báo cáo bằng công cụ xây dựng báo cáo, xuất bản rồi ra ngoài, v.v. Chúng tôi cũng đã thêm các bộ lọc, bộ sắp xếp và nhóm để làm cho nó "có thể tùy chỉnh".

Trong cả hai kịch bản này, chúng tôi có khoảng 30 đến 50 trong số các báo cáo được tạo theo thời gian.

Bây giờ có một số cuộc thảo luận về việc thêm các báo cáo ad hoc để người dùng có thể tạo một báo cáo từ đầu một cách nhanh chóng. Bây giờ mô hình dữ liệu của chúng tôi rất phức tạp và đòi hỏi kiến ​​thức làm việc tốt về nó để hiểu ý nghĩa của nó. Để làm điều này ở mức tối thiểu sẽ cần một lượng công việc tốt để đưa mô hình dữ liệu vào một lược đồ "dễ báo cáo hơn" và dễ hiểu hơn. Tôi không nghĩ rằng ứng dụng của chúng tôi phù hợp cho báo cáo đột xuất (không đáng nỗ lực).

Có ai có bất kỳ thành công với việc cung cấp báo cáo ad hoc? Bạn đã sử dụng bộ công cụ nào? Nó có ảnh hưởng đến sự thành công của ứng dụng của bạn không?

Câu trả lời:


13

Có một số nguy hiểm với báo cáo đột xuất.

  1. Các báo cáo có xu hướng sinh sôi nảy nở trong vụ nổ tổ hợp.

  2. bất kỳ báo cáo nào được tạo ra đều có một số tính hợp pháp tích hợp bởi vì, đó là một báo cáo được in, vì vậy thông tin phải hợp lệ.

  3. Bạn có thể nghĩ rằng việc cung cấp các báo cáo theo cách này giúp giảm gánh nặng của bạn trong việc hỗ trợ mọi người với các báo cáo mới, nhưng thực tế nó làm tăng nó.

  4. Nó không chỉ là về việc cung cấp cho mọi người một khả năng báo cáo. Đó cũng là về quản lý tài liệu: chính sách lưu giữ và hủy đối với các tài liệu đó là gì? Các yêu cầu nộp và lưu trữ là gì?

Vì tất cả những lý do này, tôi tin rằng, nếu một công cụ báo cáo tùy chỉnh được cung cấp, nó phải bị giới hạn về phạm vi; cấu trúc cẩn thận để không tạo ra các cổ vật quá mức, không có căn cứ và không được hỗ trợ; và được hỗ trợ bởi một chính sách phác thảo rõ ràng loại báo cáo nào có thể được tạo động và những báo cáo nào phải được xác định và sản xuất chính thức.

Trong một số trường hợp, việc thêm tùy chỉnh được chọn cẩn thận vào các báo cáo hiện có (chẳng hạn như một số lượng nhỏ các tham số có thể định cấu hình người dùng) có thể làm giảm nhu cầu về một công cụ báo cáo tùy chỉnh. Cũng lưu ý rằng, nếu đây là về việc thực hiện nghiên cứu đối với cơ sở dữ liệu OLAP, thì cần linh hoạt báo cáo hơn so với khi bạn báo cáo trên một hệ thống giao dịch thông thường.


2
+1 để cẩn thận giới hạn cấu trúc và phạm vi. Nó dễ dàng để đi quá mức và tạo ra một con quái vật.
GrandmasterB

Cuộc thảo luận này đã được đưa ra tại văn phòng của tôi gần đây và tôi có rất nhiều cảm xúc tương tự, nhưng chúng rất khó để chứng minh. Tôi không cho rằng bạn biết bất cứ nơi nào để có được một điều trị sâu sắc về chủ đề này? Ví dụ, định nghĩa báo cáo tốt và / hoặc chính sách lưu giữ sẽ như thế nào?
Aaronaught

@Aaronaught: Bạn bắt đầu với các nhiệm vụ pháp lý để lưu trữ hồ sơ và làm việc theo cách của bạn từ đó. Ví dụ, trong hầu hết các tổ chức (lành mạnh), có chính sách lưu giữ email, bởi vì nếu bạn giữ chúng quá lâu hoặc không đủ lâu, công ty có thể phải chịu trách nhiệm pháp lý. Các hồ sơ liên quan đến những thứ như bảo hành và thuế được cắt giảm rất rõ ràng; các loại hồ sơ khác, không quá nhiều.
Robert Harvey

Điều gì về phần tăng gánh nặng trái ngược với việc giảm bớt - bạn sẽ giải thích / biện minh điều đó như thế nào với CTO hay CEO?
Aaronaught

@Aaronaught: Như bạn có thể đã tìm ra, các công cụ báo cáo đặc biệt không phải là viên đạn bạc; họ cung cấp một số mức độ đơn giản hóa trong quá trình, nhưng những người không thể nghĩ về các tập hợp và tham gia (ví dụ SQL) dường như cũng gặp khó khăn khi sử dụng máy tính của họ cho những thứ trần tục hơn. Vì vậy, nỗ lực hỗ trợ của bạn chỉ đơn giản là chuyển từ viết báo cáo tùy chỉnh (sản xuất tài sản của công ty có thể được sử dụng nhiều lần) sang giúp người mới viết báo cáo khách hàng của riêng họ (tất cả đều là nỗ lực một lần).
Robert Harvey

7

Tôi đã thấy rất nhiều thất bại đắt giá. Tôi đã có một đối tác kinh doanh nghiêng tại cối xay gió này trong nhiều năm. Khó khăn của họ là sự khăng khăng của họ rằng những người "phi kỹ thuật" có thể tạo báo cáo. Chúng tôi đã xây dựng một số giải pháp mà mọi người có thể học hỏi và sử dụng ở nhiều mức độ thành công khác nhau. Giống như bạn, chúng tôi đã bắt đầu với các báo cáo đóng hộp được tham số hóa.

Sau đó, chúng tôi đã thực hiện một cách để lưu các bộ tham số và liên kết chúng với các mẫu "định dạng" khác nhau, về cơ bản cho phép bạn trộn và khớp các báo cáo đóng hộp của mình và xuất bản chúng cho người khác. Đó thực sự là điều hiệu quả nhất mà chúng tôi từng xem xét đó là khoảng hai tuần thời gian phát triển (trên cùng là một hệ thống báo cáo đóng hộp tham số cơ bản) và họ đã sử dụng nó với một số thành công trong nhiều năm. Đó là một giao diện người dùng rất đơn giản, nhưng vẫn có một số người dùng không thể thực sự xây dựng báo cáo của riêng họ, họ chỉ không thể tìm ra tiêu chí của họ là gì. Nhưng vì bất cứ ai cũng có thể xây dựng báo cáo và chia sẻ nó cho người khác, họ có thể nhờ đồng nghiệp lập báo cáo thay vì phải đến một nhóm MIS nào đó và xếp hàng.

Chúng tôi tiếp tục cố gắng cải thiện nó và lãng phí hàng trăm ngàn đô la. Crystal Decutions có một bộ công cụ khá lạ mắt như là một tiện ích bổ sung cho sản phẩm doanh nghiệp báo cáo pha lê của họ. Đây là phiên bản 9 hoặc 10. Nó đã được đổi tên từ lâu, được đổi tên thành Business Object nhưng tôi tưởng tượng vẫn còn một phiên bản của nó. Nó khá tốn kém và nó đã cho bạn một nhà thiết kế web hoàn chỉnh để xây dựng khá nhiều định dạng báo cáo. Nó cũng có một ứng dụng mẫu giống như một thuật sĩ hướng dẫn bạn sửa đổi một báo cáo hiện có. Chúng tôi đã thành công với ý tưởng "lưu và chia sẻ mẫu tham số hóa" vì vậy điều này đã hấp dẫn chúng tôi khi nó tiến thêm một bước. Câu chuyện dài quá ngắn, chúng tôi đã không thực sự cung cấp về nó. Tôi nghĩ rằng công cụ này là ổn, nhưng những gì chúng tôi đã cố gắng làm là quá bối rối và sai để làm việc.

Tất cả thời gian này, doanh nghiệp phải giữ một đội ngũ các nhà phát triển MIS, người đã làm rất nhiều báo cáo đột xuất của họ. Điều tốt nhất họ từng rút ra từ công cụ của chúng tôi là báo cáo đóng hộp linh hoạt hơn một chút, trường hợp tốt nhất giúp phát triển báo cáo đóng hộp nhanh hơn với điều kiện là có một báo cáo khác có phần tương tự. Nếu bạn muốn bằng cách nào đó tích hợp một nguồn dữ liệu mới, hãy quên nó đi. Và chủ yếu, đó là những gì MIS đã làm cho họ được tích hợp ngày càng nhiều nguồn dữ liệu theo kiểu cẩu thả nhưng rất nhanh để tiếp thị.

Cuối cùng, họ bắt đầu sử dụng Business Object - phiên bản máy tính để bàn của công cụ BI. Điều này cho phép bạn tích hợp dữ liệu cục bộ với dữ liệu mà bạn đã tìm thấy trong danh mục siêu dữ liệu trực tuyến. Vì vậy, bạn có thể làm cả hai công cụ sản xuất thực sự cho số đông và người thuê và người quản lý có thể tiếp tục nghiền nát các bộ dữ liệu khác nhau mà nghiên cứu của họ đưa họ tới. Bộ kỹ năng thậm chí còn hiếm hơn, nó chắc chắn không phải là thứ mà bất cứ ai cũng có thể nhận và làm. Tuy nhiên, họ vẫn có thể có được nhiều người sử dụng nó một cách hiệu quả hơn họ có thể đủ khả năng để thuê như những người MIS tận tâm. Nhân viên MIS không bao giờ được giảm nhiều mặc dù, đó là nói.

Ấn tượng riêng của tôi về vấn đề chung này là bạn phải sẵn sàng đầu tư đáng kể vào phát triển kỹ năng cho những người mà bạn tưởng tượng bằng cách sử dụng công cụ này và bạn phải chấp nhận rằng không phải tất cả nhân viên của bạn sẽ đến đó. Và nếu họ không thể dành vài tuần để học một nền tảng BI, họ sẽ không bao giờ có thể tận dụng tối đa bất kỳ công cụ nào mà bạn cung cấp cho họ. Một số người, vì bất kỳ lý do gì, dường như không bao giờ có được những ý tưởng cơ bản như tham gia bên ngoài. Các lớp lớn các bộ vấn đề sẽ không bao giờ nằm ​​trong tầm tay của họ để giải quyết bằng bất kỳ công cụ nào vì chúng không đủ hiểu để hiểu ở cấp độ khái niệm những gì chúng thực sự đang cố gắng yêu cầu máy tính làm. Điều đó không có nghĩa là họ "không thể" học được điều đó, chỉ là rất nhiều người trong số họ sẽ không bao giờ muốn.


5

Chúng tôi đang phải đối mặt với tình trạng này hiện nay. Tại thời điểm này thay vì giao diện báo cáo đột xuất, chúng tôi đang chạy thử nghiệm bằng cách sử dụng Excel và Power Pivot. Chúng tôi đã tích hợp nó với thanh công cụ Excel và cho phép người dùng nhập dữ liệu trực tiếp vào và tạo báo cáo bằng cách này. Chúng tôi thấy rằng nhiều trong số các báo cáo đặc biệt này, trong đó một trong những nơi cần thiết vào một thời điểm cụ thể để trả lời một câu hỏi cụ thể.

Tại thời điểm này, nó đang hoạt động tốt, một chút đào tạo và nắm tay được yêu cầu lên phía trước nhưng nó đang được sử dụng bởi bộ phận tài chính để họ tất nhiên thoải mái nhất trong excel.

Nhân tiện, nếu bạn muốn nói về một số chi tiết thực hiện hãy cho tôi biết.


+1, văn phòng theo nhiều cách là nền tảng báo cáo cuối cùng
Wyatt Barnett

2

Trong một kịch bản tương tự trong một dự án tôi đang quản lý, chúng tôi đã đề nghị khách hàng thêm một kho dữ liệu với giải pháp OLAP ở trên cùng. Để giảm chi phí, chúng tôi đã chọn PostgreSQL làm cơ sở dữ liệu DWH và Pentaho Enterprise làm công cụ phân tích BI / OLAP - chúng tôi đã chọn phiên bản trả phí vì công cụ OLAP thân thiện với người dùng hơn nhiều.

Chính xác như bạn đã nói, bạn cần thực hiện phân tích của mình để thiết kế một mô hình dữ liệu phù hợp với nhu cầu của người dùng. Chúng tôi mất ba tháng thời gian từ yêu cầu đến triển khai, và lúc đầu có một số trục trặc để khắc phục, nhưng cuối cùng khách hàng rất hài lòng với kết quả. Người dùng hiện tạo phân tích của riêng họ và đôi khi sử dụng chúng làm báo cáo (xuất chúng sang PDF). Ngoài ra còn có một tính năng cho phép tạo các báo cáo đặc biệt đủ đơn giản, nhưng ít nhất cho đến nay, công cụ phân tích là quá đủ cho nhu cầu của họ.


2

Tên miền và quy mô của các công ty bạn có càng rộng khi khách hàng có xu hướng nghiêng về các tùy chỉnh, tích hợp dữ liệu và báo cáo đột xuất. Nó sẽ đi xuống chi phí.

Hầu hết các công ty không khuyến khích các tùy chỉnh để họ tính phí cao cho dịch vụ này. Các lập trình viên có xu hướng xem những điều này là không cần thiết, nhưng khi bạn có thể tiết kiệm thời gian và giúp dễ dàng hơn cho vài trăm người dùng, tiền tiết kiệm sẽ tăng lên.

Đối với báo cáo, điều này tạo ra một cơ hội để tính phí cho đào tạo bổ sung. Báo cáo đột xuất có thể có một khoản phí bổ sung.

Công việc của bạn là nhà phát triển sẽ khó khăn hơn. Hầu hết các nơi tôi từng làm việc có phần mềm bên thứ 3 đều có báo cáo tùy chỉnh. Thật dễ dàng cho một số người vì họ có cấu trúc dữ liệu đơn giản. Những cái lớn hơn / phức tạp hơn cần báo cáo tùy chỉnh vì đó là cách họ điều hành doanh nghiệp của mình. Nếu họ muốn làm những việc giống như mọi người khác, họ sẽ không thuê tôi. Tôi đã phải đặt một vài câu hỏi về Báo cáo DevExpress trên SO.

Tùy thuộc vào việc bán hàng và tiếp thị để xem có nhu cầu hay không. Không phải "báo cáo ad hoc sẽ rất tuyệt", mà là "Tôi sẽ mua phần mềm của bạn bởi vì nó có báo cáo ad hoc." Bạn chỉ cần làm cho tất cả mọi người nhận thức được đầu tư kỹ thuật cần thiết.


2

Giải pháp của tôi là để ứng dụng của bạn tạo một số bảng tính cơ bản và cho phép người dùng chơi với Access cho đến khi họ thấy những gì họ muốn.

Một cách tiếp cận tinh vi hơn sẽ là viết chương trình truy cập / vbscript để "làm mới" dữ liệu cơ sở để cho phép người dùng sử dụng lại các tùy chỉnh ở đó.


1

Tôi đã thực hiện một vài năm qua. Như bạn đã nói, với các cơ sở dữ liệu dựa trên kiến ​​thức tên miền nhất định, nó có thể trở nên rất khó khăn. Vì vậy, tôi (hoặc nhóm tôi đã tham gia) đã phát triển chúng mà không cần sử dụng công cụ báo cáo. Họ đã thực sự gặp quá nhiều rắc rối để làm việc cùng, cố gắng đưa tất cả logic cần thiết vào chúng. Bạn cuối cùng chiến đấu với họ nhiều như họ giúp đỡ.

Người dùng thực sự thích có thể tạo báo cáo của riêng họ, vì vậy tôi nói rằng nó hoàn toàn xứng đáng nếu bạn có thời gian để phát triển một hệ thống như vậy.


1

Câu trả lời ngắn gọn là nó có thể.

Tôi đã làm việc cho một công ty vào giữa những năm 90 xây dựng phần mềm đúng như những gì họ yêu cầu. Chúng tôi đã có một thị trường tốt trong ngành dược phẩm, nơi các thử nghiệm lâm sàng có nghĩa là có rất nhiều truy vấn và báo cáo - đến mức cắt đứt những người trung gian của IS có ý nghĩa.

Công ty đó đã bị nuốt bởi một công ty khác, đến lượt họ bị nuốt bởi một công ty khác không biết hoặc không quan tâm phải làm gì với sản phẩm.

Tuy nhiên, thế giới (Oxymoronic) của Business Intelligence phụ thuộc một phần vào việc cho phép người dùng cuối khả năng xác định hoặc ít nhất là tinh chỉnh các truy vấn đối với các hệ thống dữ liệu. Có những công cụ hiện có để làm cho điều này dễ dàng hơn cho người dùng. Đối tượng kinh doanh (hiện là một phần của SAP) là vua trong lĩnh vực này. Sau đó, họ đã mua Crystal. Sau đó, SAP đã mua chúng. Cung cấp hiện tại của họ trong lĩnh vực này là Phân tích tương tác SAP Crystal.

Đó là một nỗ lực lớn - các công cụ thường đòi hỏi rất nhiều công việc để thiết lập siêu dữ liệu của bạn và tất cả những thứ đó. Đây thực sự là một câu hỏi về việc người dùng của bạn THỰC SỰ cần điều này - ROI sẽ là gì?


1

Tôi làm việc cho một hệ thống CNTT của chính phủ có các yêu cầu báo cáo đóng hộp và quảng cáo Ngoài ra, người dùng muốn có một giải pháp báo cáo đột xuất có cảm giác "được nhúng" trong các ứng dụng hiện có, cung cấp khả năng xem thông tin hồ sơ đằng sau đầu ra báo cáo và cung cấp đầy đủ truy cập vào cơ sở dữ liệu. Các sản phẩm báo cáo được nhắm mục tiêu thường chỉ là một trang web hoặc MS Excel. Bảo mật muốn các báo cáo được tích hợp với các kiểm soát bảo mật JEE hiện có.

Sau khi không tìm được giải pháp hiện có trên thị trường, cuối cùng chúng tôi đã tung ra công cụ báo cáo ad hoc mà chúng tôi đã sử dụng trong vài năm. Tuy nhiên, rất tốn kém để duy trì và một con gấu để tăng cường vì nó không được thiết kế để vượt ra ngoài các trường hợp sử dụng, bộ lọc và sắp xếp khiêm tốn.

Một số vấn đề chúng tôi đã có những vấn đề tương tự được đề cập bởi những người khác:

  • Người dùng không có khả năng hiểu datamodel - đặc biệt, người dùng thường xuyên tạo các sản phẩm tham gia chéo thông qua công cụ và bị nhầm lẫn bởi đầu ra.
  • Không có khả năng hiển thị kết quả trên bản đồ mặc dù phần lớn dữ liệu có thuộc tính không gian.
  • Không có khả năng đánh dấu và quay lại các lựa chọn báo cáo ad hoc (đây là một lỗ hổng trong thiết kế công cụ ban đầu).

Chúng tôi hiện đang đánh giá Báo cáo Kéo để xác định xem nó có thể giải quyết các vấn đề này không. Chúng tôi thích cách giao diện ad hoc cung cấp cho người dùng một hình ảnh đơn giản về mô hình dữ liệu cùng với các mô tả văn bản của các bảng và cột. Thực tế là các lựa chọn bộ lọc của người dùng được nhúng với đầu ra báo cáo làm giảm mối lo ngại rằng kết quả sẽ được giải thích không chính xác.

Về việc liệu tất cả những điều này có "đáng giá" hay không: trong trường hợp của chúng tôi, báo cáo đột xuất đã rẻ hơn và dễ quản lý hơn so với việc nhân viên kỹ thuật quản lý việc phổ biến các báo cáo đóng hộp. Tuy nhiên, câu hỏi hơi khó hiểu vì các báo cáo đóng hộp - cả với công cụ báo cáo nội bộ của chúng tôi và với Báo cáo Kéo - thường được xây dựng dựa trên công cụ truy vấn / báo cáo của công cụ báo cáo ad hoc. Có nghĩa, các báo cáo đóng hộp chỉ là các báo cáo đột xuất với các cài đặt được cấu hình sẵn.

Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.