如果企业决定把它的业务流行迁移到云端的话,在那之前有几件事一定要先完成。
首先,云BPM并没有什么魔力。它只是提升了业务流程的效率。如果它们只是微不足道的,那它们在云中也并不会发挥什么大的价值。
其次,云改进了处理数据的质量。如果他们在本地存在错误、遗漏或重复,那么他们在云中也将一样。
再者,流程实际上不能哪里都放,它们还是要置于组织触手可及的地方,要面向于员工,以及相关的合作者,并且有他们的参与。然而,所支持软件可能会运行其它的服务器上,而不一定是公司自己的,这样潜在的影响也不会波及太大。
这就说明业务流程仍然是企业自己的责任,这与是否卸载云提供商的执行引擎没有关系。尽管如此,还有一些可做和不可做的事情,以此来入简化这一过渡。
下面是开始迁移业务流程的的一些注意:
1.要花费时间和精力来学习并改进目标业务流程,在把它们放入云端之前。无论如何,企业将来肯定要研究特定资源和目标厂商的性能,所以为什么不同时也使流程运行的更好呢?
2.不要只是因为可能就迁移流程。要了解哪个流程需要更多的关注——考虑技术的时效性、劳动力的扩展和减少、成本控制等,使之成为关注的重点。
3.要花费时间和精力清理数据(流程规则、用户目录),在迁移之前。这一行为将在公司把数据迁移到另一个本地系统之前,所以为什么不在迁移向云之前行动?
4.不要一次性迁移所有,也不要迁移所有东西。
5.要对迁移的流程进行测试在使用之前,从而确保运行维目标理解这一需求,同埋还要确保已经满足或超出了最初的需求。另外,使用不必要的或虚拟数据,以防出错。
6.不要只是假设新的云BPM系统会比本地个的系统更好地与现有的解决方案工作。对于交互和重叠部署地,业务流程有一个不好的地方,所以要确保集成和交互相关的问题都已经解决了。
7.要与用户沟通,无论是在迁移之前,之时还是之后。这应该是很常见的做法,与任何公司进行技术变更工作时。可以更舒服地使用新的接口和流程,企业将更尽全力满足目标要求。
8.不要忘记设定一些成功的衡量标准,在开始之前;并收集一些指标,在迁移进行时。如系统性能、流程完成时间、错误率和财务回报这些东西都一样的,而且只有在成本和利益可衡量时,才知道迁移是否有价值。最后,对比结果和预定目标。
虽然列出这些注意事项,但需要企业自己衡量是只遵循这些技巧。运气好的话,公司部分或全部登上云这艘船;同时在做了一些应该做的事情后,也了解了云BPM没有什么神奇的。
我们一直都在努力坚持原创.......请不要一声不吭,就悄悄拿走。
我原创,你原创,我们的内容世界才会更加精彩!
【所有原创内容版权均属TechTarget,欢迎大家转发分享。但未经授权,严禁任何媒体(平面媒体、网络媒体、自媒体等)以及微信公众号复制、转载、摘编或以其他方式进行使用。】
微信公众号
TechTarget
官方微博
TechTarget中国
相关推荐
-
AWS PaaS来也:炎黄盈动为业务流程管理带来无限价值
随着容器、微服务等技术的使用,企业的应用程序也变得越来越趋于组件化;同时,为了这串连起这些组件,开发人员却需要 […]
-
Red Hat披露更加架构驱动的BPM模型愿景
Red Hat的一个更加结构化的BPM设计方案有望搭设应用开发界与业务流程管理的桥梁,让企业架构师、开发者和业务侧的人更快速更容易地实时新的业务流程。
-
SOA治理模型核心:人
治理在IT领域非常关键,但是很多时候企业的做法往往太过单向,企业SOA治理模型往往忽视了所有部分当中最关键的组件:人。
-
地理位置与移动BPM:一种自然的延伸
你是不是把地理位置当作自己移动BPM战略的自然延伸?Steve Weissman探讨了地理位置对业务流程的价值。