【IT专家网独家】大部分大型的IT厂商都有着投资于高风险但收益不确定的IT项目的专断权。但对于那些小规模和中间市场的公司而言，较小的预算额度通常会成为投机项目不可逾越的障碍。
那是因为无论公司规模的大小，项目融资的规则都是一样的。想要切实地评估任何项目的可行性，我们必须能够比较项目的预期成本和为企业带来的预期价值。对大部分的IT项目来说，投资的未来价值是很容易通过开支的节省、所获得的效益，或者现有资源的再利用被估算出来。 然后运用简单的预估方法来计算出潜在的投资回报率，从而决定是否要采取行动。这是一个经过实践论证的方法，CFO应该能够理解。在小型企业中，如果你押错了宝，你将会失去更多。
我曾经接到过一个验证高风险高收益的商业智能(BI)项目的任务。 传统的项目计划和投资回报率的衡量方式对于这次的BI项目都不适用，因为计算不确定收益的价值就如同毫无目标的去掘金一样困难。 我们知道这个项目是有价值的;我们对我们所追求的东西有一个粗略的概念，但是我们知道的到底有多少，它的价值到底有多高，只有等投资完成后才会揭晓。
因此，尽管我不认为那个BI项目是一项鸡肋型的IT投资，但是在CFO眼中还是将它划拨到了高风险的范畴里。不管如何，我都必须得去验证一下这个项目。 我是中西部地区一家大型医疗实践公司的技术负责人(由于在非医疗领域的限制原因，请恕我不便透露公司的名字)。我通过手下380名人员(包括45名医师)来监控分布于17个地点的技术应用。我们曾经面临的关键管理问题之一是作为一家大型企业如何去充分地将所有实践标准化，从而获取相同的效益。
至今为止，如何解决这个问题对我们来说依然棘手，但是这是我们唯一改善我们财务状况的方法。保险公司和联邦政府通过医疗保险制度和医疗补助制度来购买我们的服务。 不像其它与我们规模相当的同行，我们不与任何的医院或大学有从属联系。 我们依靠医师网络来扩张我们的病患资料库，这些医师会将他们的病患信息传递给我们。 也正因为如此，我们才需要花费最小的代价去做到更多。今年大部分的战略工作计划都有赖于绩效衡量。但是实践却限制了获取有效度量的工具。我们需要BI来更好的处理我们的业务量。 以下是进行该项目的方法：
先从小处入手
为了让这个BI项目更合乎财务效益，我们将它分割成了几个子项目，每个子项目之间都紧密相连(即一个子项目的成功是另一个开始的基础)。 其中每一个步骤所产生的价值会被运用到下一个步骤中去。 如果规划和执行恰当的话，那么最终的结果将会是一个低风险、高收益的项目。 由于该项目中的任何一步无法提供价值都会导致项目的中断，因此CFO也被我们说服了。
我们被批准进行该项目的原因如同互联网先锋David Reed所总结的那样(通常被称为Reed定律)，网络的价值不在于它的容量，而在于网络之上所产生的交易。 如果企业无法采取有可行性的行动，那么这个系统所披露的信息就没有价值，你就不该去建立它。 Reed关于网络价值的定律是我们进行需求分析时的关键。 我们识别出了我们能够以低成本提供积极价值的第一个区域 – 使用现有的工具。 对于我们来说，这意味着依靠现有的微软SQL和IBM Universe平台，并且利用Access，Excel和基本网页服务来创建客户端的视图。 随着BI的成长，我们又加入了免费版本的微软Office Sharepoint Server (MOSS)，并且计划利用这个项目为企业所节省下来的资金添置MOSS企业版的功能。
我们的初始步骤之一是关注病患的候诊时间。 由于我们的实践带有紧急的性质，因此医生办公室里经常会坐满病患，这就导致了等待时间的延长。 从历史经验来看，这好像是无法避免的。 今年管理层要求我们优先开发出一套关于问题和建议处理方式的报告卡。
通过与临床经理的合作，我们开始从病患图表系统中的一些简单数据探索入手。 由于病患在就医过程中会不断移动，他或她的位置就会被医疗人员录入到这个系统中以确保病患在就诊前后都得到了恰当的检查。 这些事件的时间戳和位置都会被记录下来作为合规用途，但是我们没有报表来分析这些数据。
因此我们使用BI工具来看看这些数据到底说明了什么。 对每一个病患来说，我们在流程中的每一个阶段都有一个开始和结束的时间，这些时间可以被计算到一个统计模型中。 我们可以从中了解到一个病患要在候诊室和诊疗室里等待多久才能见到医生，等待多久才能见到医务助理，等待多久才开始接受检查。 当我们把这些数据与医师、就诊类型和位置做出比较后，我们终于了解到我们所采用的计划模板时病患等候时间的一个关键部件，而我们的模型没有留出足够的空间来处理紧急状况所带来的额外流量。
该项分析为我们提供了一个改善病患接待能力的路标。 我们开始重新培训我们的电话调度员安排看急诊和专科门诊之间病患的数量，以确保预约的病患可以按时就诊。
依靠早期的成功
然后我们比较了想要获取其它有价值的成效所需付出的成本和带来的收益。 在这个阶段，我们最主要的目的是寻找重新利用解决方案的机会。 比方说，我们曾利用IT帮助台绩效的数据设计了一个简洁的工作流程来简化这个功能。 现在我们重新展开这个工作流程引擎来创建一个半自动的员工机载应用，一个时间表解决方案，一个员工技能知识库，一个电子表格库和一个报表库。 这些成为了BI后续阶段的基石，使得模块方式得以展开。 尽管有许多工具可以完成这个功能，但是微软的Sharepoint对我们来讲最适用。
由于每一个阶段是否能够顺利展开都有赖于前一个阶段的成败，因此我们的计划就必须保持足够的灵活性来适应不断变化的目标和项目本身的发展。 比方说，在展开帮助台工作流程解决方案的期间，我们就发现了我们可以为帮助台提供自动的呼叫量报表。 从中我们得出了在其它呼叫中心运用相同的报表可以为呼叫中心经理和病患候诊时间提供更高的价值结论。
