中国式的报表与商业智能?
来源:互联网 发布:硅藻陶瓷滤芯效果 知乎 编辑:程序博客网 时间:2024/03/29 17:28
曾几何时,报表左上角的小斜线早已成为判别报表制作能力的标准之一,以小斜线为代表的,则是各种格式古怪,但数据却未必复杂的所谓中国式报表。在繁杂纷呈的中国特色之下,成熟的报表软件纷纷落马,几十种国产报表工具陆续从小作坊中出现,其成功者已经大行其道,直至今天仍然有人打算陆续炮制,增加这个数量。我一直在想,报表需要的到底是什么?是哪些勾勒的线线框框,还是需要呈现的数据?放在信息系统之中,却被复杂表样框死的报表,与纸质的报表相比到底有什么更大的用途?难道仅仅是省纸,并且归档之后易查找、不易丢失?框死的表样是否断绝了以报表信息化转换作为起点,陆续挖掘信息化给报表应用带来的其它价值?当然,我们一般说,这不是用户所要的,用户需要的只是出几张报表。
近期因为项目原因,需要了解合并报表,就了解了相关会计准则,也看了看各种合并报表软件,可惜可供深入了解合并报表软件的资料极少。但从论坛、顾问等途径,却看到了许多自己不认可的观点。其中之一就是,表并和帐并的问题。有人认为Hyperion、SAP等以往来帐套辅助的帐套合并方式,不满足合并报表的制作——会计准则规定了合并报表是从个别报表出发,而不是从帐套。我则认为,既然从个别报表经过抵消调整可以完成合并,为什么他们要采取帐并得方式?显然,他们不仅仅是为了产生那四张报表及一堆附注。再看看会计准则,字面上讲的是个别报表、合并报表等,而实质上则是为了消除内部交易等对集团财务状况及其变动的影响。我不懂财会,但我想在帐务的层面处理好往来与合并,出几张合并报表和些许附注应该不困难吧。果真如此的话,我们是否应该想想合并之后,帐并/表并的方式分别给集团带来什么额外的价值。当然,我们仍然会说,这不是用户所要的,用户需要的只是出几张合并财务报表。
再回头看看自己这么多年所从事的商业智能领域,如果您有心但却没有太多时间的话,我建议您只去SAP/BO实验室看看,看看人家在鼓捣些什么。而我们所做的呢,则不外乎是仓库、查询、报表、门户等等吧,最多再加上“新”舶来品KPI、DashBoard、ScoreCard等,鹦鹉学舌、老旧肤浅;我们有些人甚至倡导商业智能就是他们的报表系统。而对于巨头们陆续提倡的搜索集成、分析型主数据管理、协同决策、业务分析等,我们冷静的认为这些只是他们的又一次忽悠。我们还是会说,这不是用户所要的,用户需要的只是堆砌在Web里的表格和图形。
我们这样做,原因不外乎有以下几点:谋求自己业务的生存空间;自己捡的总是别人的剩饭,忽悠不来新东西;国内管理信息化参差不齐,土问题还需土办法。至于更深层的原因及评判,我没资格多说,感兴趣的话可以揣摩一下这篇文章《商业智能:中外差距到底有多大?》(麦炳),除去某些字面的细节外,其中的观点我很是赞成,比如管理思想的差异,比如我们只是结果导向,而不重视过程改进和绩效优化等。
最后,特别声明一下:本人并不崇洋迷外;同时本人也是某几家山寨版BI的始作俑者之一。本文纯属自我鞭策,以求进步。
- 中国式的报表与商业智能?
- 商业智能BI和报表的区别?
- 商业智能中的报表制作.
- BI-商业智能与 BA-商业分析 的区别
- 商业智能的技术与实践
- 商业智能的历史与现在
- 中国式报表
- 部分商业智能及报表工具一览
- 商业智能三步走:报表 分析 挖掘
- 用友BQ商业智能平台报表功能
- BIRT--商业智能和报表工具,从零开始
- 商业智能的新发展
- QLIKVIEW的商业智能
- 商业智能的基本概念
- 中国式数据分析报表的5宗罪
- 数据挖掘与商业智能
- 稻谷商业智能与数据仓库
- 让智能与商业联姻
- SRM 438
- 跨团队的持续集成: 几个基本矛盾
- 什么是云计算?
- 经典面试问题回答思路
- 【Java.Concurrency】多线程的代价 & Why Threads Are A Bad Idea (for most purposes)
- 中国式的报表与商业智能?
- 2009-07-05
- Java项目的打包与发行
- IE与Firefox在JavaScript上的7个不同句法
- 对邪恶八进制老大冰血封情的流产采访
- require(),include(),require_once()和include_once()的区别
- StarUML: 插件加载失败的解决方法
- 一个好玩的现象
- 向前——向前——向前