大家好-寻找用户体验。
我们正在实施一个新的ERP(在我们的案例中是Oracle Fusion)。这是一项需要数年时间才能完成的全球实施。在实现的第一阶段,只涉及美国,我们使用Concur Test实例配置和测试来自我们的HR系统和Fusion的集成。这些集成包括员工成本中心和地点列表,以及项目会计列表和其他。
我们正在考虑向前推进到没有测试实例的未来实现。这些实现也将主要通过集成影响Concur。
你们有人试过吗?我担心如果在生产环境中进行集成测试将是不够的。例如,需要将测试员工放在“测试组”中,而不是他们本来的员工组中。下一个实现将覆盖8个国家,仅这一个示例听起来比使用Test实例要困难得多,而且可能会令人困惑。
然而,也许我并没有看到所有的可能性,所以你分享的任何建议或经验都会很感激。谢谢你,
嗨KayPellack,
首先,我假设你是在专业平台和标准平台上。在这两种情况下,您都应该使用Concur检查您的选项。
根据您的公司结构,您将有不同的选择。
Rlipsey64非常适合软件开发的测试环境。
话虽如此,Concur却没有正常情况下提供一个测试环境。您将与测试员工一起建立一个测试组(不要使用真正的员工),并构建您的测试环境:测试组在您的生产站点中。通常,实现开始使用TEST实体,然后使用PROD实现移动到PROD。/rollout。但是客户可以购买TEST环境,除非Concur将其作为销售的一部分提供。
现在你有特殊的情况:多个县。(请咨询您的同意)。我的理解是每个国家都有一个测试组。您将为每个县配置费用的所有方面(策略、费用类型、工作流、审计规则等),包括拥有所有自然员工组数据的测试组员工,然后是用户验收测试和签收。
然后,最后一步是将TEST县移动到生产用户,并更新新县所需的生产策略、费用类型、工作流和审计规则。
PROD场景中的“TEST”看起来确实“比使用TEST实例困难得多,而且可能会令人困惑”,但实际上需要的工作更少。这里存在的一个主要因素是所有国家的ERP是相同的,所以整合的结构与国家要求的方差是相等的。
根据经验,这将是第二阶段的推出,可能需要在您的合同中添加一个MOD来支持Concur Implementation。再次使用Concur进行检查。
马克
马克