将临时报告添加到应用程序中值得吗?


16

我们有一个收集大量数据并生成报告的应用程序。第一次迭代是一个很好的Crystal Reports集成。在Crystal Report设计器中创建报告,然后将RPT文件导入到应用程序中。这很好用,但是用户需要应用程序来运行报告,而且用户无法创建报告。我们添加了过滤器,排序器和分组,以便可自定义RPT文件,但它们无法从头开始创建一个。

第二种互动是使用SSRS,SSAS和Microsoft的报表生成器工具的基于Web的解决方案。这需要一些数据库工作,还需要一些工作才能从OLTP架构启动并运行多维数据集,但是最后,创建汇总报告要容易得多。但是,我们仍然必须使用报告构建器工具创建报告,然后发布然后发布,等等。我们还添加了过滤器,排序器和分组器以使其“可自定义”。

在这两个场景中,随着时间的推移,我们大约有30至50个开箱即用的报告。

现在,有一些有关添加临时报告的讨论,以便用户可以从头开始创建报告。现在,我们的数据模型非常复杂,需要具备良好的工作知识才能理解它。至少要做到这一点,需要大量的工作才能将数据模型转换为“更可报告”且更易于理解的模式。我认为我们的应用程序不适合临时报告(不值得付出努力)。

有没有人在提供临时报告方面取得任何成功?您使用了什么工具集?它对您的应用程序的成功有影响吗?

Answers:


13

临时报告存在一些危险。

  1. 在由此产生的组合爆炸中,报告趋于泛滥。

  2. 这样创建的任何报告都有一定的内置合法性,因为它是打印的报告,因此该信息必须有效。

  3. 您可能会认为,以这种方式提供报告会减轻您为人们提供新报告提供支持的负担,但实际上却增加了负担。

  4. 这不仅仅是要给人们提供报告功能。它还与文档管理有关:此类文档的保留和销毁政策是什么?归档和存储要求是什么?

出于所有这些原因,我认为,如果提供了自定义报告工具,则必须限制其范围。精心构造,以免产生过多,未经证实和不受支持的文物;并以明确概述可以动态生成哪些报告以及必须正式定义和生成哪些报告的策略为后盾。

在某些情况下,向现有报告中添加精心选择的自定义项(例如,少量的用户可配置参数)可以减少对自定义报告工具的需求。还要注意,如果这是关于对OLAP数据库进行研究,则与在普通事务系统上进行报告相比,需要更大的报告灵活性。


2
+1用于仔细限制结构和范围。它很容易过关并创建一个怪物。
GrandmasterB

最近我的办公室里开始讨论这个话题,我有很多相同的感觉,但是很难证实。我想您不知道有什么地方可以对此主题进行深入的处理吗?例如,良好的报告定义和/或保留策略会是什么样?
2011年

@Aaronaught:您从保存记录的法律要求开始,然后再从那里开始。例如,在大多数(理智的)组织中,都有保留电子邮件的政策,因为如果您将它们保留的时间太长或不够长,则公司可能会承担法律责任。与担保和税收等相关的记录非常明确;其他记录,不是很多。
罗伯特·哈维,

与增加负担而不是减轻负担有关的那部分呢?例如,您如何向CTO或CEO解释/辩解呢?
亚伦诺特,2011年

@Aaronaught:您可能已经知道,临时报告工具不是灵丹妙药。它们确实在过程上提供了一定程度的简化,但是无法从集合和联接(即SQL)方面进行思考的人似乎也很难将计算机用于处理较平凡的事情。因此,您的支持工作仅从编写自定义报告(可产生可重复利用的公司资产)转变为帮助新手编写自己的客户报告(全部为一次性工作)。
罗伯特·哈维

7

我见过很多昂贵的失败。我在这台风车上有多年的业务合作伙伴。他们的困难是他们坚持要求“非技术”人员能够创建报告。我们建立了许多解决方案,使人们能够学习和使用不同程度的成功。就像您一样,我们从参数化罐头报告开始。

然后,我们提供了一种保存参数集并将其与不同的“格式”模板关联的方法,从本质上讲,您可以混合并匹配您的罐头报告并将其发布给其他人。实际上,这是我们做过的最有效的事情,因为它大约需要两个星期的开发时间(在基本的参数化罐头报告系统之上),并且他们成功使用了多年。这是一个非常简单的用户界面,但是仍然有些用户无法真正构建自己的报告,他们只是无法确定其标准。但是,由于任何人都可以创建报告并将其共享给其他人,因此他们可以让同事做出报告,而不必去某个MIS团队排队。

但是,我们一直在努力改善它,浪费了数十万美元。Crystal Decisions有一个非常漂亮的工具包,可作为Crystal Reports企业产品的附加组件。这是版本9或10。它早已被更名,由Business Objects重命名,但我想它仍然有一个版本。这是非常昂贵的,它为您提供了一个用于构建几乎任何报告格式的完整的Web设计器。它还有一个示例应用程序,它更像是一个向导,可引导您完成修改现有报告的过程。我们已经成功实现了“保存并共享参数化模板”的想法,因此,随着它的发展,它吸引了我们。长话短说,我们并没有真正兑现。我认为该工具还可以,但是我们试图做的只是太混乱和错误而无法使用。

在所有这些时间里,企业必须保留一组MIS开发人员,他们负责很多临时报告。他们从我们的工作中获得的最好成绩是罐装报告的灵活性,该罐装报告最好的情况是,只要存在另一个有些相似的现有报告,它就可以更快地开发新的罐装报告。如果您想以某种方式集成新的数据源,请不要使用它。多数情况下,MIS为他们所做的就是以草率但非常迅速地推向市场的方式集成越来越多的数据源。

最终,他们开始大量使用Business Objects-BI工具的桌面版本。这使您可以将本地数据与在线元数据目录中找到的数据集成在一起。因此,您既可以为大众和量化指标做实际的生产工作,管理人员也可以继续研究他们研究导致的不同数据集。这种技能变得更加罕见,这肯定不是任何人都可以拿来做的事情。他们仍然能够吸引比有效雇佣MIS专用人员更多的人。MIS人员的减少从未减少过。

我对这个普遍问题的印象是,您必须愿意为使用该工具的人们大力投资于技能开发,并且您必须接受的是,并不是所有的员工都会去到那里。而且,如果他们不能花几个星期来学习BI平台,他们将永远无法充分利用您提供给他们的任何工具。某些人,无论出于何种原因,似乎从未获得过诸如外部联接之类的基本思想。大量的问题集将永远无法使用任何工具来解决,因为它们还不足以从概念上理解他们真正想让计算机去做的事情。这并不是说他们“不能”学习到这些,只是他们中的很多人永远都不会。


5

我们目前正面临这种情况。目前,我们正在使用Excel和Power Pivot来运行临时报告界面,而不是临时报告界面。我们将其与Excel工具栏集成在一起,并允许用户将数据直接导入并使用此工具生成报告。我们发现许多此类临时报告在特定时间需要回答某个特定问题的地方。

在这一点上,它工作得很好,需要事先进行一些培训和手持,但是财务部门正在使用它,因此他们当然最擅长excel。

顺便说一句,如果您想谈论一些实施细节,请告诉我。


+1,在许多方面,办公室是最终的报告平台
Wyatt Barnett

2

在我正在管理的项目的类似情况下,我们为客户提供了一个添加了OLAP解决方案的数据仓库。为了降低成本,我们选择PostgreSQL作为DWH数据库,并选择Pentaho Enterprise作为BI / OLAP分析工具-我们选择付费版本是因为OLAP工具更加用户友好。

就像您所说的那样,您需要进行分析以设计出适合用户需求的数据模型。从需求到部署,我们花了三个月的时间,最初需要修复一些小故障,但最终客户对结果非常满意。用户现在可以创建自己的分析,有时还可以将其用作报告(将其导出为PDF)。还有一项功能可以创建足够简单的临时报告,但至少就目前而言,分析工具已足以满足他们的需求。


2

随着客户趋向于定制,数据集成和临时报告,您所拥有的公司的业务范围和规模越来越广。它会降低成本。

大多数公司不鼓励自定义,因此他们为此服务收取高额费用。程序员往往认为这些事情是不必要的,但是当您可以节省时间并使数百名用户更容易使用时,节省下来的钱就加起来了。

为了进行报告,这提供了收取额外培训费用的机会。临时报告可能需要支付额外费用。

作为开发人员,您的工作将越来越艰巨。我曾经工作过的大多数使用第三方软件的地方都具有自定义报告功能。对于某些人来说这很容易,因为它们具有简单的数据结构。较大/较复杂的企业需要自定义报告,因为这是他们经营业务的方式。如果他们想做和其他人一样的事情,就不会雇用我。我不得不在SO上提出一些DevExpress Reporting问题。

取决于是否需要销售和营销。不是“临时报告会很酷”,而是“我会购买您的软件,因为它具有临时报告。” 您只需要让每个人都知道所需的技术投资即可。


2

我的解决方案是让您的应用程序生成一些基本的电子表格,并让用户使用Access直到他们看到自己想要的东西为止。

一种更复杂的方法是编写一个访问/ vbscript程序来“刷新”基础数据,以便允许用户在那里重复使用自定义项。


1

这些年来,我已经做过几次。如您所说,对于依赖某些域知识的数据库,它可能会变得非常棘手。因此,我(或我所在的团队)在不使用报告工具的情况下开发了它们。坦率地说,他们很难与他们合作,试图将所有必要的逻辑纳入其中。您最终会在他们的帮助下竭尽全力。

用户非常喜欢能够发表自己的报告,因此,如果您有时间开发这样的系统,那绝对值得。


1

简短的答案是可以的。

我在90年代中期为一家公司工作,该公司开发的软件完全可以满足他们的要求。我们在制药行业拥有良好的市场,在该市场上,临床试验意味着大量的查询和报告-如此之多,以至于剔除IS中间人是有意义的。

该公司被另一个公司吞并,而另一个公司又不知道或不在乎如何处理该产品。

尽管如此,(智能的)商业智能世界仍然部分依赖于允许最终用户定义或至少优化对数据系统的查询的能力。有一些工具可以使用户稍微容易一些。Business Objects(现在是SAP的一部分)在该领域占主导地位。然后他们买了水晶。然后SAP买了它们。他们当前在该领域提供的产品是SAP Crystal Interactive Analysis。

这是一项巨大的工作-这些工具通常需要大量的工作来设置元数据以及所有这些工作。这实际上是您的用户是否真的需要这个的问题-投资回报率是多少?


1

我为具有临时和固定报告要求的政府IT系统工作,此外,用户还需要一种临时报告解决方案,该解决方案感觉“已嵌入”现有应用程序中,提供钻取功能以查看报告输出背后的记录信息,并提供完整的信息。访问查询数据库。目标报告产品通常只是网页或MS Excel。安全性希望报告能够与现有的JEE安全控件集成。

在找不到市场上现有的解决方案之后,我们最终推出了我们使用了几年的自定义报告工具。但是,由于它的设计目的不在于扩展适度的联接,过滤和排序用例,因此维护成本高昂,需要增加负担。

我们遇到的一些问题与其他人提到的类似:

  • 用户无法理解数据模型-特别是,用户经常通过该工具创建交叉联接产品,并被输出所迷惑。
  • 即使许多数据具有空间属性,也无法在地图上显示结果。
  • 无法添加书签并返回到临时报告选择(这是原始工具设计的缺陷)。

我们目前正在评估Pull Reports,以确定它是否可以解决这些问题。我们喜欢临时界面如何为用户提供简化的数据模型外观以及表和列的文本描述。用户的过滤器选择与报告输出一起嵌入的事实减少了对结果将被错误解释的担忧。

关于所有这些是否都是“值得”的:在我们的案例中,临时报告比让技术人员管理大量罐装报告便宜且易于管理。但是,这个问题有点儿争议,因为固定报告(包括我们内部的报告工具和拉式报告)通常建立在临时报告工具的查询/报告引擎之上。意思是,固定报告只是具有预配置设置的临时报告。

By using our site, you acknowledge that you have read and understand our Cookie Policy and Privacy Policy.
Licensed under cc by-sa 3.0 with attribution required.