八年级多余的报表一大堆.docx
《八年级多余的报表一大堆.docx》由会员分享，可在线阅读，更多相关《八年级多余的报表一大堆.docx（10页珍藏版）》请在冰豆网上搜索。
八年级多余的报表一大堆
⏹掌握NE5000E/80E/40E产品的体系结构
⏹掌握NE5000E/80E/40E的单板构成
⏹掌握NE5000E/80E/40E换板操作
⏹了解NE5000E/80E/40E升级操作
多余的报表一大堆，需要的却找不到，管理者无法快速有效决策。
信息系统开发者事先确定了管理者的信息需求，为何还会这样？
谁在妨碍你及时决策？
罗艳兵宋亮
一家航天公司工程部的新任副总裁注意到他每个月都会自动收到32份系统。
由于报表太多，他很难在有限的时间内确定这些报表的主要目的。
由于他的前任就是这样，所以他不情愿承认他的无能，为此，他有了一个主意。
如果他发现其他人也同样收到了这些报表，他会巧妙地询问这些报表的用途，来确定这些报表的具体含义。
因此，他让助手去调查还有谁会收到这32份报表。
在一个星期之后，助手回来了，副总裁问道：
“还有谁会收到这些报表？
”
“只有我和你，两个人。
”助手回答到。
副总裁非常震惊：
“那么你怎么处理这些报表呢？
”
“我只是把这些报表作为备份，当你的报表不见的时候，我会把它们拿出来。
”
在对这些报表观察了一年之后，副总裁确认其实他只需要其中的4个报表，同时也清楚还有一些重要信息没有获得。
因此，他不再接受不需要的那28个报表，他也开始把主要精力投入到获取必需的数据上。
在第二年，他开始对信息系统部门提供有效信息的无能感到很沮丧，同时信息系统部门也对他不能确认最终的信息需求感到失望。
因为他的需求一直处于不断的膨胀之中，信息系统部门不得不不断地修改系统，既费时间，又浪费金钱。
这样的例子非常普遍，也许昨天还发生在你身边。
对于管理人员来说，最重要的工作是决策。
除了智力因素之外，他们最重要的资源就是信息。
当不能为他们提供及时有用的信息时，会导致商业机会的丧失，或者某些问题不能得到迅速的解决。
从而没有足够的反应时间来进行决策，包括定价，产品介绍，资源配置，对外部竞争和并购进行快速的反应。
不幸的是，大多数信息系统在经历了长时间的设计和实施之后，仍然不能满足管理人员决策的信息需求。
事实上，大部分新的信息系统都需要进一步的修改来部分地满足这些需求，导致了巨大的损失和浪费。
就像你要在一个完工的房屋里面增加一个卫生间和在你设计的时候就增加这个卫生间是一个道理。
而且成本中还会蕴涵着一些管理人员做出错误决策所产生的机会成本。
可以想象，当管理人员取消了一个有不良驾驶记录的少年保险请求的时候，而这个少年是一个大公司总裁的儿子，这层关系经理人员并不知道，那么也许你能猜到之后的故事了。
问题出在哪里呢？
让我们再看一个例子。
一家大银行最近完成了一项价值几百万美元的信息系统项目，这个信息系统能够追踪它的所有客户信息。
在给各部门经理进行演示时，有些经理提出能不能对这个系统进行修改，使这个系统能够提供原来所没有的功能。
换句话说，经理们想要那些在设计阶段的时候，他们没有提出的信息需求。
尽管增加这些需求并不是很难，但也要推迟整个项目超过一年，使总成本翻倍。
最终这个项目被取消掉了，四十万美元的前期投资完全打了水漂，许多信息部门的员工失去了工作。
有了这样的教训以后，大多数系统开发人员开始采用其他的方案－用户授权。
在这种方案中，他们询问经理人员的信息需求，然后要求经理人员签订必要的文件来保证最终接受开发好的系统。
这种方式可以使系统开发人员在最终的时候有理有据，但不能最终解决功能上的问题，因为经理人员不知道自己的信息需求。
然而，一旦他们认识到了系统最终不能满足他们需求的时候，他们就会责问系统分析人员误导了他们。
最大的领导会说：
“你们技术人员应该发挥你们的作用，因为我们缺乏相关的该领域的知识。
”当碰到这种情况的时候，事先签订好的文件也就没有什么用了。
看来导致管理者无法及时获得信息进行决策，做出快速反应的关键还在于确定清楚管理者的信息需求，不幸的是系统开发人员常常会犯四种基本的错误：
●把系统看作是功能性的而不是跨功能性的。
●单独访谈经理而不是一起访谈。
●在访谈的过程中询问错误的问题。
●在详细设计阶段不允许试验和错误发生。
忘记跨功能思考
在确认信息需求的过程中第一个错误就是把信息系统看作是功能性的而不是跨功能性的，导致不能做出更有效的决策。
举例来说，当开发一个新的预算系统，我们也许只是把需要的信息定位在预算部门经理或者员工，而不是所有使用预算信息的员工。
实际上，所有的经理都需要预算信息。
不幸的是，如果由预算部门负责设计的话，系统将很容易只为少数人服务，导致最终的预算系统像一个银行报表。
大部分人使用银行报表，只是在纸上或者是个人电脑上来对帐。
同样，许多经理把他们的部门预算放到一台部门电脑上，只是和从预算部门获取的控制信息相匹配。
在这种情况下，实际大约60％的数据和其他部门生成的报表有关联关系。
举例来说，一个制造厂商的营销副总裁想按销售人员，顾客和产品来对成本和收益进行分类。
但是预算系统只是按照项目帐号来统计分配的成本。
一个项目可能包括不只一个销售人员、顾客和产品。
只有进一步的从销售系统那里进行数据收集，以及使用报表软件才能获得必要的数据。
一些人也许会认为，预算部门应该把业务经理的报表需求和一个新的系统开发结合起来，但是反对者认为这会增加成本。
这种逻辑的漏洞在于成本的增加总是存在的，因为这些业务经理也必须开发他们自己的报表系统，这会导致比一个集成的系统更多的成本。
就像营销的副总裁所说的，“会计部门要求市场部门提供更多的按照审计和控制方式分类的数据，这给我们增加了额外的负担。
我们需要更好分类的数据来帮助我们更有效率地营销产品。
根据预算设计的系统不能满足我们的需求，你听说过一个制造厂商之所以成功是因为它有世界上最好的会计部门吗？
”
为了表明开发跨功能性系统的需要，考虑一个商业流程－客户订单管理。
为了处理订单，销售人员必须决定该轮到满足哪个顾客的需求，并该如何满足。
信用部门必须决定为哪个用户提供信用。
分销部门必须决定存货水平和报告点。
运输部门应该决定商品应该运输给哪个顾客，如何合并订单来共同运输来减少成本，运输路线和运输安排（见表1）。
在开发新系统的时候，应该提供相应的信息来提高这些决策过程。
具体来说，考虑分销中心的决定——哪个客户应该得到适当的库存。
如果分销中心有五个订单，但是库存只能满足三个，这样就必须做出一个资源配置决定。
通常，这种决定采用先进先出的方式来进行，在目前的信息来看，这种方式是最适合和最公平的。
决策中心
活动
决策实例
销售人员
销售
哪些客户订货
卖给顾客什么商品
现有什么商品
信用部门
可接受的帐户管理
允许多少信用额度
哪个用户需要收到过期通知
哪个用户记录需要终止
分销部门
库存管理
需要对哪些商品进行库存
需要多少库存
什么时间重新定购库存
什么时候移走过期的库存
为哪些用户分配合适的库存
运输部门
包装和运输订单
运输哪些产品
哪些订单可以集中运输
选择运送路线来节约成本
表1客户订单管理的决策分析
考虑到以下信息，顾客A不是很频繁定货，也不需要迅速到货，也不会立即支付帐单，带来的利润比较低。
顾客B，是一个大量商品的购买者，最近经常抱怨到货很迟。
他需要迅速的运输，支付也很快，能带来高的利润率，位于一条频繁使用的运输路线上。
在这种情况下，采用先进先出的决策原则会带来灾难性的后果。
为了提高决策的质量，下列的因素应该被考虑：
●每一个顾客对于生意来说有多重要。
●每个顾客需要货物送达的时间要求。
●每个订单的利润率？
●每个顾客的信用记录？
●每个顾客送达的时间表。
●是否有顾客曾经对以前的订单不是很满意？
注意到分销中心决策过程的信息大部分都要从分销中心之外获得。
举例来说，顾客的需要、重要性和利润来自信用部门的销售额，信用记录和运输部门的时间表。
因此，可以得出一个结论，大部分能够提高部门决策质量的信息是从部门之外的地方获得的。
在一个部门内共享信息对于提高生产力非常重要，当学会在不同的部门之间共享信息，部门员工将会做出更有效的决策。
因此，开发一个新的信息系统的底线是要意识到所有的部门都要受到信息的影响，并且对他们的决策需要非常地敏感。
这样就可以开发一个系统能够使整个组织的信息在各部门之间共享。
但是大部分系统开发人员抱怨员工都对自己部门的信息保持私有，而不愿意参与到一个共享信息的信息系统开发过程中来。
认识到信息就是力量，员工却没有兴趣来共享力量。
为了解决这个问题，核心领导层需要使用他们的权力和影响力来实现跨部门的信息系统设计。
喜欢单打独斗
在确定信息需求的时候，通常犯的第二个错误是信息系统设计团队通常单独和经理们交谈，而不是使用小组的方式。
单独会面的形式把压力集中到管理人员那里，会妨碍他正确地回答问题。
这会影响有效信息需求的提出，据此设计的系统就很难满足管理者及时决策的信息需求。
考虑这样的场景，一组陌生人进入你的办公室让你讲10个笑话。
即使你确实知道10个很好的笑话，你也会想不起来，大部分人都会这样。
现在换一种情形，你和你的同事被放到一个房间里共同讲笑话，你和你的同事会讲出80、90甚至100个笑话。
换句话说，每个人都知道很多笑话，但是他们单独讲的时候会想不起来，而当他们在一起讲的时候，情况就大大改善了。
这里蕴涵的道理就是大家共同的智慧在回忆信息的过程中是非常重要的。
当人们被要求讲笑话的时候，他们通常只会讲最近才知道的，很难记得以前讲过的笑话。
同样的，当经理被问及他们需要的信息的时，只记得最近的信息需求，而不是他们所有的信息需求。
因此，这种过程最好以全体的方式进行，这样，他们能够提供更加详细的信息需求。
另外，不同部门通常有不同的开发信息系统的议程。
在表1中所提到的订单处理系统中，每个决策系统可能强调不同的决策设计标准。
销售部门也许认为确保快速和正确的货物运输是订单处理中最重要的一环。
信用部门也许认为确保客户能够全额付款是最重要的部分。
存货管理部门当然对更加便捷地进行库存管理和降低存货成本非常感兴趣了。
运输部门对如何选择最优的运输路线，降低运输成本最感兴趣。
从各部门的角度对整个信息系统进行综合的考虑才会满足各部门的要求。
如果对每个经理单独访问的话，很难得出一个整体的观点和看法。
比如，对信用部门来说，最主要的目标是确保用户付款，理想的情况是所有的客户都全额付款。
在决策中，可能犯两类错误：
1.给予那些未来不会支付的人以信用授权；2.不给那些将来会支付的人以信用授权。
通过跨功能思考以及全体讨论之后，最优的决策是不进行信用记录检查。
这种貌似违反常理的结论是建立在从全体讨论中产生的两个关键理解。
首先，公司把低价商品的目录发给刚开始接触的客户。
那些付款购买的客户会收到价格更加昂贵的产品目录。
那些拒绝付款的客户将不会收到邮件。
在这种方式下，公司不必根据客户的信用记录证明材料就可以决定公司是否应该把这个客户作为优质客户，只要根据公司自己的信息就可以了。
从顾客拒付中发生的损失要远远小于对所有顾客的信用记录进行检查所需要的成本。
换句话说，没有付款的商品成本就是决定哪些用户是优质客户的成本。
这种信息不仅非常准确，而且要比传统的对顾客进行帐户检查成本要低。
如果这种需求没有考虑到销售部门的话，那么这种方法也不会实现。
进而，那些被认为具有较高信用风险的顾客会有比较大的倾向来购买公司的商品。
反过来说，那些信用记录优良的顾客不会从公司的目录中购买商品。
这意味着，公司发出了很多邮件来宣传自己的产品给那些信用记录优良的顾客，但是却很少做成一笔生意。
因此，这只会使公司受到损失，而没有获得必要的收益。
公司最佳的做法是对那些具有较高信用风险的顾客进行重点营销，但开始不卖给他们比较贵的产品，直到最终确认顾客将会对他们购买的产品进行付款。
如果采取单打独斗的访问方式，将很难使信用部门接受对顾客信用记录进行检查并不是必需的这个观点。
所有，当确定信息需求时，所有涉及到的部门应该同时同地共同讨论。
询问错误的问题
在确定信息需求的时候容易犯的第三个错误是通常询问错误的问题：
“从新系统中你需要获得什么信息？
”尽管这是最显而易见的问题，但是它不会对经理人员试图确定他们的信息需求有任何帮助。
经理人员认为，系统开发人员知道他正在做什么。
因此，系统开发人员问这个问题就像医生问病人你需要什么样的治疗一样。
或者一个销售人员把自己作为一个订单的接受者而不是问题的解决者，问：
“你需要什么产品？
”。
因此，病人和顾客很难给出满意的回答。
一个故事说明了这一点，有一个人需要购买一个拖拉机除草机，但是不了解这个产品。
可以认为他就是那个需要解决问题，而不知道具体需求的经理。
当他来到一家代理商那里，购买拖拉机除草机的时候，销售人员问他需要什么。
他说需要一台拖拉机除草机。
之后，他发现自己陷入了麻烦之中，第二个问题是他需要多宽的刀片。
这个问题是他没有准备回答的问题。
当他这样说的时候，他看到那个销售人员在眨着眼睛好像在说，我不想和一个傻瓜打交道。
接着，他被问到需要多大马力的除草机，他回答说，你能提供多大马力的？
“5到18马力的”，同时销售人员的眼睛又开始眨。
接着销售人员又开始问问题，要宽轮胎还是窄轮胎，电子打火还是手动打火？
由于配置的不同，除草机的价格在800美元到2800美元之间他不想买的配置过高，或者过低。
一旦销售人员不知道他具体想买什么的时候，立刻会推销价值2800的那款机器，建议要顶级配置。
他认为这个推销员提供的配置太高了，因此他又到了另外一家代理商。
那里的销售人员不是一个订单的获得者，而是一个问题的解决者。
销售人员没有问需要什么样的配置，而是一些其他启发性的问题：
“你的草坪有多大？
有多深？
然后又问是否想让太太一起使用除草机。
”
在了解到这些信息之后，销售人员来到一个除草机的前面说，这就是你想要的除草机。
他问一共多少钱，销售人员说800美元。
他觉得这款除草机要比2800美元的那款还要好。
他问为什么推荐这一款，销售人员说从他的描述中，觉得这就是他最想要的那款机器。
销售人员做的实际上也很简单，问了一些间接的问题，同时也了解到了他的需求，从来没有具体问过他需要什么。
使用间接问题是一种创造性的问题解决方式。
系统开发人员也需要做同样的事情，管理人员也应该要求他们这样做。
一个和管理人员沟通来确定信息需求的直接有效的方法是基于三种不同的需求/确定方法论（见表2）。
通过把这三种不同的方法论中的问题合成在一起，就可以获得一个可靠的信息需求确定方式。
在进行面谈之前，整个系统的设计目的必须建立起来。
举例来说，以上讨论的订单处理系统的目的是确保快速正确地订单处理和货物运输，维持信用记录的完整性，方便库存管理和确保正确的运输路线和计划。
一旦这些被建立起来，就可以通过一些问题来决定哪些信息需要知道来保证目标实现。
一个信息需求访谈的基本模型可以从框架1中被看到。
面谈方法
信息系统实施
开发者
具体说明问题和结论
商业系统计划（BusinessSystemsPlanning）和经理面谈的部分
IBM
具体说明关键因子
关键成功因子（CSF）
Rockart
具体说明输出的有效性指标和产生输出的过程的效率指标
Ends/MeansAnalysis（E/MAnalysis）
WetherbeandDavis
表2面谈方法，实施和开发者
图1信息需求访谈框架
以商业系统计划（BusinessSystemsPlanning）为例：
●问题/解决方法/信息格式面谈模板
在完成你管理的组织单元目标的时候，你碰到的最大的问题是什么？
举例来说，在订单系统中，不断的库存溢出，有限的库存分配和卡车离开时间安排的问题。
这些问题的好的解决方式是什么？
更好的库存管理应该解决不断发生的存货溢出的问题，其他的问题也可以通过一些方法来解决。
信息怎样在这些问题解决过程中发挥作用？
当存货水平低于预期值的时候，系统会提醒，从而更好地进行库存管理。
同时可以通过一个顾客优先级管理系统来使分销中心更好的分配库存，如果运输部门能够接触到订单信息的话，也可以更好的进行运输计划和线路的调配。
问题
解决方案
信息
经常存货溢出
更好的库存管理
自动提供库存信息
分销中心分配库存不当
让分销中心知道客户的优先级
在系统中进行顾客级别排序
运输部门不能合并一些到达地址比较近的订单
让他们了解所有的订单信息
系统设计时，加入此功能
表3使用问题/解决方案/信息格式的面谈模板
●决策/信息格式面谈模板
什么是你管理工作中主要面临的决策？
需要卖什么东西给他们，多少钱，他们的信用记录如何，什么时候终止他们的信用记录，什么时候分配足够的内存等等。
在信息方面哪些提高能够更好的促进决策？
决策
信息
哪些用户下单，买什么东西？
顾客订单信息，可用的库存
信用记录如何？
多少？
什么时间终止
信用评级，目前的帐户信息，支付记录
需要多少库存？
什么时间补充？
目前的库存，销售趋势，市场预测
怎样配置有限的库存？
订单优先级，客户重要性，客户信用状态，运输时间表
什么时间清空销售缓慢的库存？
销售趋势
已经被预定的库存的目的地
顾客地址
哪些订单能够被一桶运输
运输时间表和等待运输的订单
表4决定/信息格式面谈模板
通过非直接的问题来获得信息需求在实践操作的过程中很简单，同时也很有效。
它很简单是因为它的主要组成要点非常简单，可以让开发人员和管理人员在一个相对比较短的时间内掌握它。
它很有效是因为它是基于人们信息处理的基本理论，并且考虑到了人的优势和局限性。
另外，这种访谈有一种冗余的保证机制。
举例来说，有限库存的分配（见表3）即使不作为问题发现，也会被当作必须要做出的一个决定提出来（见表4）。
这很大程度上提高了访谈的可靠性。
通过这种访谈形式，可以得出订单处理系统信息需求的概念模型。
举例来说，在表3中的第一项是存货溢出，低于预定值，可以看作是系统的一个报表头；第二项是库存的自动重新定购，可以看作是系统的一个功能。
忽视试验和排错
在确定信息需求的过程中，第四个容易犯的错误是管理者不被允许通过试验和排错的方式确定和重新定义他们的概念需求，转化为具体的信息需求。
如具体的系统界面或系统产生的报表。
试验和排错的方法是确定具体信息需求的一部分。
通过使用原型或模型设计方法可以把具体信息需求集成到系统设计过程。
一个原型的模型可以从图2中看出：
图2原型设计模型
不幸的是，系统分析师并没有把这种试验和排错的过程集成到系统设计过程中。
同时令人沮丧的是，他们因为管理部门强加给他们的预算的压力而对系统原型并不是非常重视。
管理人员不应该在最初的系统概念建立之后就让系统开发人员消失。
管理人员应该在被访谈之后的几天里再对系统原型进行观察和使用。
这个原型系统能够在几个星期之后，逐渐成为最终的系统设计。
一旦管理者接受这个原型，建立这个系统的一个时间表和预算就要出来了，尽管系统必须经过时间逐渐完善。
最初正确的系统将只会通过轻微的修改就会完善起来，对系统的逐渐修改更加容易得到控制。
这样反而节省了时间和成本。
随着商业节奏的加快，原来需要几周才能做出的决策现在必须在几天，几个小时或者几分钟的时间内做出。
因此，管理者需要迅速的接触到信息，而不能等待几周或者几个月的时间，当整个信息系统完善之后。
管理者和信息系统设计者需要协同工作来考虑和决定信息需求，并对遇到的困难进行讨论。
升级会员 