现在很多企业从中获得的收益已经可以得到很好的证实。例如，在一份来自Gartner的最新研究报告中显示：在成功的桌面日程安排软件项目中有78％的企业获得的内部报酬率高于15％，而有一些企业的这个数据达到了100％甚至是360％。这份研究还发现在业务流程管理越来越重视相关人员的参与，而不仅仅是系统与系统的整合。此外，企业除了可以获得财务上的回报，他们还一直称赞桌面日程安排软件可以减少错误，改进服务水平与增加业务流程透明度的能力。因此，Gartner预测桌面日程安排软件的热度还会持续上升，并且会成为企业提升管理的投资首选，桌面日程安排软件能够给企业带来竞争优势。

            业务流程在组织中比比皆是。一些流程已经界定得十分详细和明确。例如，贷款流程是人手众多的财务部门的核心职责，因此，有关如何处理贷款流程的详细资料也就自然为大家所熟知。与此相对应的另外一个方面，企业中的大多数流程仍然没有被很好的说明定义或者记录下来。这种情况是企业业务经过多年的发展，人们为了应对情况而做出即时决定所造成的结果。如果成功了，这些程序就会运用到相似的情形中去，多年之后就成为了公认的流程标准。如果没有成功，就会将尝试其它的方法，直到找到有用的流程。结果造成流程的反复进化，几乎就是达尔文进化论的翻版。由于这些实际情况，实施桌面日程安排软件常常面临很多的挑战--不仅要理解现有的流程，同时还要在运用桌面日程安排软件技术实现了自动化后保证流程的灵活性，使流程能够不断做出变化和调整。

            企业要想取得桌面日程安排软件的成功，业务人员与IT专家必须组建一个团队来共同作战。业务人员是业务流程的使用者，他们了解流程的目的与运作方式。一旦实际情况需要，他们就会采取行动调整现有的流程。IT部门提供了企业流程自动化运作的技术和基础设施。他们知道如何管理数据，以及整合与系统运作的要求。

            企业需要发掘IT基础设施、业务流与业务需求这样的一个组合，然后把它们转换成业务流程图，这样才能实现企业业务流程的自动化运作。这一个过程需要团队的努力工作，流程需要不断做出调整以适应变化是实施桌面日程安排软件项目面临的最大挑战。德勤（DelphiGroup）最新的研究报告指出：通常，主要的工作集中在发掘阶段，也就是需求分析，流程模型的开发与制定业务规则这样的一个整体努力。从平均水平来看，这些活动（流程与规则分析结合需求定义）大约耗费整个桌面日程安排软件项目时间的40％，然而，实际上人们常常发现这个阶段花费了整个项目时间的50％到60％甚至更多。

            为了充分发掘流程，IT人员与业务人员的代表必须进行合作一起定义流程图。流程图应当真实的反映业务流程的流向与导致遵从不同路径的业务条件或规则。流程图与支持性文件一起详细描述流程的细节。某些流程定义的工作与传统的应用程序开发相类似，包括：

            .数据记录的需求；

            .确定流程执行中可能需要完成的所有任务；

            .确定运用那个现存的系统（来获取信息，传送信息或者使整个步骤自动化）；

            .选择如何通过电子表格/用户界面从用户那里收集信息。

            其它的一些细节则是业务流程独有的（与IT无关的）：

            .什么条件确定了工作流程必须按哪些步骤进行；

            .流程中的每一步工作应当由谁来完成；

            .如何来处理那些改变工作流向的例外事件。

            详细的流程图本身也会带来问题，这一点是于流程图的图画性质本身所决定的。虽然在最初的时候，图画形式的流程能够大大推动我们对流程的理解，但是随着流程复杂性程度的增加，它所能增进理解的价值也在不断减少。即使能够画出最好的流程图，对于不是绘图专家的人来讲，要理解图画流程（理解图画后面的详细内容）的困难仍然是非常大的。图画形式的流程图不仅没有提高流程的清晰度与可理解性，反而还加大了理解的难度与迷惑程度。此外，我们还要注意到流程图与模型实际上是永不能被真正完成的，因为变总是化无时无刻地在发生。

            随着企业业务流程的持续变化，企业的IT部门会感受到越来越大的压力，因为他们不得不千方百计地去理解、领会和贯彻流程的要求。但是，我们要知道这些要求的关键部分往往都存在于流程拥有者的头脑中，他们根据业务环境的需要进行运用和调整。在企业的IT部门看来，定义与把流程的规则和流向形式化是必须的，不存在商量余地的。但从业务的角度来看，要做到这点是几乎不可能的事。

            为了解决这些挑战，各种方法与技术层出不穷。其中有一些促进了业务部门与IT部门工作的协调性，有一些使解决方案程序中的代码得以减少从而简化了变化，也有一些重新定义了什么是桌面日程安排软件项目的理想团队结构，还有一些从完全不同的角度对这些问题进行了探讨。在作者的下一篇文章，将会进行更加详细的探讨来如何解决这些流程分析的难题。