跳转到内容
技术文章
作者头像达米恩·弗万博新体育手机客户端里堡

用于规划的SAP Analytics云:多级工作流

一般考虑

在协作领域,工作流是组织和构建计划过程的一个无可争议的核心方面。

事实上,组织需要将许多利益相关者纳入各个流程,并能够以协调的方式审查、批准或拒绝提交的预算或计划。

最后,当企业用户设计公司范围的流程时,他们可能不知道参与整个活动的所有个人贡献者。例如,企业用户可能沿着区域或业务单元部署任务,即在层次结构的底层部署任务,而没有考虑到本地BU控制器将需要额外的少数用户来提供更多详细信息,以完全完成规划任务。因此,我们将研究接收任务分配的本地业务用户如何最终将该任务转换为流程,从而调用Corporate最初甚至没有意识到的其他贡献者。

组织的多层次规划过程

在上面的例子中,我们考虑的是一个组织,其规划过程由区域和国家驱动。通常,在顶层,目标将以自上而下的方式定义。随后,在一个自下而上的过程中,详细的计划将被提交,然后由下一级经理审查。

为了实现这一过程,下面介绍了两种设计方案。请注意,对于这两个选项,您可以利用日历的向导(菜单通用-任务/流程驱动维度)来生成它们。

用例#1:多级审批流程(从底层实体到顶部节点的逐级验证):沿着流程层次结构部署任务

使用向导,然后选择所有成员(一直到叶子级别),您将在基础级别创建任务,这些任务将上卷到流程中(任务是必须完成的单个操作,而流程是一个任务或任务的集合,甚至是子流程的集合)。

在上图中,将通过通知和Calendar任务邀请国家一级的每个受让人执行其活动。最重要的是,完成他们的活动意味着向下一个级别提交。换句话说,每个国家经理(例如意大利的Berny McGuire)将通过执行他们的活动完成他们的任务,然后提交给区域经理(例如区域=南部的Helen Cheng)。

此外,您可以在每个阶段包括更多的审查人员。例如,公司的首席财务官可能不仅要验证他直接监督的地区数据,还要验证下面每个国家的数据。为了启用这种补充的和可选的验证,部署在基本级别的任务需要添加一个评审轮(这里是“第2轮”)。这将在区域经理完成对各个国家的验证后,在CFO级别触发验证通知。

用例#2:数据收集过程(不需要正式的中间验证)

第二种选择用于预算或报告周期,在这些周期中,不需要立即对提交的数据执行验证。例如,一个商业组织可能要求他们的现场销售员工每周或每月报告数字,但不应该发生验证/拒绝。

在这种情况下,可以使用Calendar向导从上到下生成流程,而不需要定义审阅者。

一般来说,这个选项类似于前面描述的选项,但是不需要验证所提交的数据。它还意味着,在一个进程在国家一级被标记为完成后,它就被锁定,不能更改。

最后,在区域级别,当被指派人员向上一级执行自己的提交时,这在某种程度上代表了对他们在下一级负责的数据的隐式验证。

选项1与选项2的用例

选项1 选项2
描述 多级审批流程 数据收集
用例 在验证发生的地方生成计划过程。基本级别的受让人提交他们的提案,然后由上面的经理(或维度属性中的指定经理)审查。 以结构化和及时的方式生成用于立即收集数据的流程。
主要功能优势 本地触发批准/拒绝迭代 使用的简单性(没有显式的审查,但是通过父流程级别的提交进行隐式审查)

将基本级别的指派人员转换为流程管理人员:将任务转换为流程

仅这一特性就在组织整个组织的复杂计划工作流方面产生了巨大的变化。

事实上,公司级的业务用户可能不知道计划过程中涉及的每个涉众,因此只在最终将接触到的业务用户方面将任务部署到一定深度。因此,通常需要将复杂的计划过程部署到公司所知道的初始社区之外。这就是将任务转换为流程所带来的价值所在:它允许个人受让人(由于要完成任务)反过来将相同的任务部署给任何其他拥有SAP Analytics Cloud用于计划访问的用户。这也是一个很好的解决方案,企业用户可以设计一个核心规划流程,该流程将在整个层次结构中保持一致,而不会牺牲在每个阶段细化和添加更多业务用户的能力。

结论

正如本文所解释的,在组织中部署计划过程有两种不同的方式。他们都追求自己的目标,特别是在收集数据和/或验证每个级别的提交时。最后,除了要求业务用户参与的已定义流程之外,他们还可以将其他涉众涉及到流程中,这在工作流定义中提供了最终的灵活性。

有用的链接

本博客是最佳实践系列的一部分。如果你想发现更多的最佳实践,请查看这些博客:

https://community.sap.com/search/?ct=blog&mt=819703369010316911100650199149950&q=%23best_practices

指定的标签

      第一个留下评论
      你一定是登录评论:评论或回复一篇文章