“缺少对内部员工的观念推广/沟通”很可能导致立意良好的BPM项目偏离初衷。以部署平衡记分卡(BSC)为例：BSC的精神是先拟定企业策略目标，再由上往下展开与核对各部门的业务事项是否与企业策略目标相符，为避免它的业务工作内容被归类为不重要，开始有某些部门员工提出抗议、甚至拒不配合;有些BSC主导单位为消除上述阻力，改成由下往上推：由各部门同仁自行列出部门目标，并以该部门目标往上拼出处级目标、事业群目标甚至是企业目标。

　　该做法虽能降低部门抗拒BSC，但企业目标也因此被灌水到数十个之谱、或者是变得抽象到可以包容万物，更重要的是，由下而上拼出企业目标的做法与BSC的本意完全不符。

　　对BPM项目目标认识不深必陷入左右为难的窘境。缺乏明确目标的结果往往与父子骑驴的状况一致，到底要为方便使用而简化窗体，还是得为了搜集详细的分析数据设计出正规窗体?要着重管理还是效率?要严谨防呆还是弹性容错?

　　BPM的重点是流程(Process)的管理(Management)，既然要管理就会被管、被监控，自由放任度不比从前，换句话说，使用者可能会找各种真实或被包装过的理由，拒绝使用系统。

　　其次，持续性的流程精炼(ProcessRefine)也是BPM的核心精神。企业应先掌握1个观念：不能自满于旧有流程，也没有所谓完美流程。这意味着，无论使用者想一切照旧完全不变更，或者是因求好心切反导致流程发散等，都是不对的观念。

　　另外，鉴于家家都有本难念的经，因此，本文不予评论“政治因素”亦是导致BPM窒碍难行一事。

　　至于有近三成受访者认为“项目范畴失控”会阻碍BPM项目一点，我想任何一类型的项目都会遇到该问题。为避免范围失控，得以明确的项目目标为筛子，理清与取舍所有事项的轻重缓急;若是不知取舍，如前面的BSC例子，为避免得罪人而将所有人的意见都予以考虑的“万全”做法，最后多导致失控。

　　而“缺乏制度与配套措施导致使用率偏低”一点，我想，流程的“管理”常会使原本不用被管或管不到的事项得被摊在阳光下，在这样的状况下，即便没有私人因素，光是作业或操作习惯的改变，便能让许多人不愿意配合。这就跟早餐习惯吃烧饼油条的人，虽知汉堡三明治也很营养可口，但因习惯与口味等因素，多不愿意尝试。

　　同样的道理，当高级主管表态不签纸本只认电子窗体、不走流程就不算绩效、走电子流程者可提早领款或优先定库存等配套措施出现，即可强迫或引诱使用者使用BPM系统;至于哪些措施比较有效?视公司高层能挺到什么程度与企业文化而定。

　　“业务案例不足”与“低估将业务流程转换成系统化流程信息的工夫”其实都与“低估了流程与组织的复杂度”相关，这边不多费篇幅。

　　“因为设计或实作不当导致使用者接受度低”多半是因为需求访谈不够详尽。如需求访谈时未访谈其它地区的相关业务负责人，需求确认后又未对这些负责人进行差异说明，未参与需求访谈的业务人员自然会觉得BPM系统是设计或实部署不当的产品。

　　总的来说，在考虑业务流程的变异性与地域差异后，BPM往往比标准化程度较高的OA流程来得复杂许多，鉴于此，若负责部署BPM的单位是以部署OA系统的经验在部署BPM系统，那在统合跨组织、跨部门的意见时，必会吃到不少非预期的苦头。

　　这也意味着，若企业能找到一个熟悉业务流程且与决策者互动关系不错的关键使用者担任“流程需求负责人”，势必有助于BPM项目的推动，若让技术单位的人以闭门造车的方式建构系统，顺利推导BPM系统将难上许多;因为大部份技术人员的专长是与系统而非人沟通，因此，单独由其负责推动强调与人沟通互动的BPM项目，确实有其困难性。

免责声明：本网站（http://www.ciotimes.com/）内容主要来自原创、合作媒体供稿和第三方投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。
本网站刊载的所有内容（包括但不仅限文字、图片、LOGO、音频、视频、软件、程序等）版权归原作者所有。任何单位或个人认为本网站中的内容可能涉嫌侵犯其知识产权或存在不实内容时，请及时通知本站，予以删除。