第二章:客户关系管理集合与事件--事件 Event workflow in ERP5 编写:OSOE项目. 现在我们来介绍如何运用ERP系统的CRM模块来管理组织内外的沟通。 注意:本章节我们会继续使用VIFIB来介绍ERP5的“集合”和“事件”模块功能。因此当您实践 您的ERP5实例的时候,请用您配置ERP5的公司替换VIFIB。 纲要 • ERP5的CRM系统 • 事件类型 • 事件性质 • 一个发送人/多个接收人 • 跟踪交流事项 • 发出事件流程 • 接收事件流程 • 如何运用工作列表 ERP5的CRM系统 CRM system in ERP5: Person communication 由于交流人数的增加,不留记录的通讯工具的增加,以及在集成系统中跟踪交流的难度增 大(像邮件存储在个人邮箱,传真存储在特别的地方等),追踪交流信息的复杂性阻碍我 们从经验中获得学习,以及分享重要联系人的信息。这就造就了CRM系统。 CRM表示客户关系管理。这些ERP系统被用于记录您与客户的交流信息。今天,CRM的许多概 念被扩展。基于“事件”与“集合”的概念,我们可以运用CRM来记录您与供应商,员工以及媒 体的关系(例如供应商关系管理--SRM)。因此在ERP5中,CRM系统包含了事件,活动,会 议,销售机会以及客户支持请求,它们被应用管理我们的组织于所有联系人之间的交流。 现在我们就已“事件”的特征开始介绍ERP5的CRM流程。 例子:事件“SlapOS ongoing!” Events example: SlapOS Beta Developer Program 现在就先来看一个VIFIB事件的例子,然后我们将解释事件的详细流程。 现在VIFIB有一个营销活动“Beta Developer Program”,旨在通过招聘软件开发员来提高 SlapOS(一个由VIFIB开发的新的开源云)的知名度。VIFIB社区经理Cédric De Saint Martin将这项招聘信息以电子邮件的方式发送给他的联系人,他们是可能对该活动感兴趣 的并且有意向成为SlapOS未来开发员的编程员。当这些联系人收到邮件后,他们就会通过 邮件方式回复该VIFIB经理,而这些发送于接收邮件就将存储在CRM系统中以供将来检索使 用。 事件标题是“SlapOS ongoing!”,事件发送人是Cédric de Saint Martin (VIFIB 的 SlapOS社区经理),事件接收人是Cédric的14为联系人,包含了软件开发员,公司经理, 学校教授等等。事件内容如图所示。 事件类别 Event types ERP5的CRM系统使用所谓的“事件”概念。事件是存储在电脑中的发生在两个以上联系人之间 的交流记录。 本例中,每一封有一人发给另一人的邮件就是一个事件。 每项交流在CRM系统中都有记录。我们通常将事件分为一下类别:当您访问一位客户或接受 客户来访时,您可以使用访问;但您希望为与客户的交流添加引用时,您可以使用笔记; 当您与某人有电话联系,您可以使用电话来讲您的谈话概况记录下来;许多CRM系统提供通 过邮件信息由系统中心直接发送邮件的功能,您还可以向系统录入您接收的邮件;当您接 收许多信件或传真,您可以将其扫描并通过信件和传真存入CRM系统;站内信息是站内员工 间发送的短信息,例如ERP5的用户VIFIB员工之间通过ERP5站内信息发送短消息:网站信息 专门用于记录组织外人员在您的公开网站(例如erp5.com)上发布的信息。 基于您自己的业务或许需要配置更多种类的交流事件。 本例中,事件种类是“邮件信息”。 事件性质 Event nature 除了不同种类,事件还拥有不同性质。 事件性质是通过其目的划分的:投诉,公告,广告,信息,查询,垃圾邮件等。我们必须 根据事件性质对其分类:一个投诉事件和一个广告事件是完全不同的。 基于您的业务范围,CRM系统用户需要为事件选择分类类别。 本例中VIFIB经理要发送的邮件信息的事件类型是一个“信息”。 一个发送人/多个接收人 Events: one sender multiple receivers 一个事件代表了一项资源(信息,查询等)的运动,它将由一个发送人那里到达一个或多 个接收人。在ERP5中,我们不仅已事件内容来区分事件,还以它们的发送人来区分事件。 一个事件通常只有一个发送人,但却可以有无数个接收人。由两个发送人发出的事件是两 个不同事件,而有同一个发送人发给许多接收人的事件则是一个单独事件。 本例中,有VIFIB经理发送的事件是一个单独事件,因为该事件只有一个发送人,但是对此 事件的回复就是多个不同事件,即使回复信息可能相同。 接收和发出事件 Incoming and outgoing event 由于事件都有一个发送人和接收人,因此我们就知道事件的方向。 我们需要区分接收事件和发出事件:接收事件由组织外人员发送给组织内部的;发出事件 是由组织内部人员发送给外部人员的。 这项分类非常重要,因为您处理发出事件和接收事件的方式和流程是不同的。 本例中,由VIFIB经理发送的邮件信息是一个发出事件,而来自其联系人的对该邮件的回复 是接收事件。 跟踪交流事项:发起事件 Keep track of interactions by 'Event Origin' 连接事件可以通过“发起事件”以及跟进集合进行,这样您就可以轻松跟踪您的组织与外部 联系人的所有交流事项。 首先,通过“发起事件”功能,即使复杂的交流事项也可以被清晰列出。 一个单一事件发生在两个联系人之间,但它可以根据发送人和接收人的需求使用不同的事 件类型(如左图所示)。 但是,复杂事件(如右图所示)可以涉及许多联系人,他们是组织内外成员,使用不同的 通讯工具。这种情况下,如果我们列出与一个人相关的事件,我们只能得到部分交流信息 。 如图所示,该表格记录了所有发生在VIFIB员工及客户关于一个新的产品发盘之间的讨论。 事件N°1是客户进行回复并创建事件N°2的原因,因此我们可以说事件N°1是事件N°2的发起 事件。 因此,通过使用“发起事件”可以正确并精确地表现事件之间的关系。 跟进集合 Keep track of interactions by 'Follow Up' a ticket 其次,一个事件也可以“跟进”一个集合,集合被ERP5用于收集所有主题相关的事件。我们 将在下一节介绍中看到。 回到我们的例子,正如您在图中所见,这个事件是一个接收事件,它是由一个收到VIFIB经 理邮件的联系人回复的邮件。再该事件页面中,它显示了发起事件(“SlapOS Ongoing!”) 以及该事件跟进的集合(“Beta Developer Program”)。因此这两个功能帮助我们将负责 交流事项以清晰的方式呈现出来。 发出事件流程 Outgoing Event workflow 上图显示ERP5发出事件的流程。 基于您的任务指派,您可以对发出事件进行一项或多项操作。 标准操作有四个步骤: 首先,从发出事件的发送人文件中草拟建立该事件,此时事件状态是“草拟”; 其次,计划该事件(即“要求审阅”),状态变为“已计划”; 然后,经理确认该事件(公司经理或者该事件操作的负责人),状态变为“已确认”; 最后,您就可以发送该事件,状态变为“已发送”。 如果事件已被编辑,正等待发送,您可以在事件建立后“草拟”或“已计划”状态下直接发送 。您也可以在该过程中删除或取消事件。 根据该事件工作流程的引导,您可以管理三人小公司直至大型的客户服务中心。 本例中,事件发送人Cédric de Saint Martin(社区经理)以发出的邮件信息事件的方式 从他的人文件中建立了新的事件。草拟事件内容之后,他设置该事件为“已计划”,因此负 责所有事件运行的VIFIB公司经理Smets先生就可以在“我的菜单”中“待审阅的已计划事件” 中查看事件。当经理认可了该事件内容,他就可以确认该事件。当Cédric看到事件状态从“ 草拟”变为“已确认”,他就知道他的事件已被批准并可以发送了。当他将邮件发送给事件接 收人--他的联系人之后,该事件“SlapOS Ongoing!”的状态就会由“已确认”变为“已发送”, 从而发出事件程序就结束了。 工作列表 Outgoing events worklist 工作流程的概念帮助人们理解处理事件的完整步骤。但这是抽象的。为了切实而有效地应 用工作流程,我们使用工作列表。 工作列表(请见ERP5页面左上方的“我的菜单”,如图所示)是一个显示所有事件状态的列 表。完整的发出事件工作列表是一个标准流程列表:从草拟,已计划,已确认直至已发送 (如图红线部分所示)。您对事件每进行一次修改,该工作列表就会自动更新。有了这个 列表,每个员工就可以轻松进入任何状态的事件。如果是事件的操作人或接收人,他们就 会获悉每天需要处理的事件。 举个客户服务中心的例子。每天,客服中心的经理都会审阅“已计划”事件并“确认”它们。 事件操作人就可以看见等待发送的“已确认”事件。一旦他们处理完“已确认”事件列表,他 们就完成了一天的工作。 本例中,负责事件运行的VIFIB公司经理每天都要查看“我的菜单”中有没有“已计划”事件需 要审阅和确认。现在他看到了由VIFIB的社区经理Cédric创建的事件,于是他审阅后将它设 置为“已确认”;当Cédric查看“我的菜单”发现他创建的“已计划”事件已经移至“已确认”事 件列表,就知道该事件已被经理批准,他于是将其发送,该事件便进入“已发送”事件列表 。 因此工作列表将工作流程精确清晰地呈现,从而促进了大家的工作。 接收事件流程 Incoming Event workflow 如图示第二部分所示,接收事件有不同流程:它们可以被手动创建(例如,您可以将一个 来自客户的支持请求或回复邮件内容以新建接收事件的方式输入系统),或者由系统自动 创建(例如,一个事件可以通过“声明已接收”的操作在使用相同ERP5系统的两个部门之间 传递。如果该事件起初是由部门A创建的发出事件,即,部门A是发送人,那么当部门B声明 接收该事件后,它就成为一个新建的接收事件,即,部门B是接收人)。 标准的接收事件流程有三步骤: 首先,从接收事件发送人的人文件草拟建立该事件,此时事件状态是“草拟”; 其次,您可以声明事件已接收;您也可以定义事件接收人(如果您需要指派另一组织成员 来处理该事件,而非由您--事件初始接收人来处理),状态变为“已接收”; 然后,事件接收人创建跟进集合以记录将发生所有与该发起事件相关的事件,该事件就会 被自动交付;您也可以在接收事件之后手动交付事件操作。这两种操作之后事件的状态变 为“已交付”。 如果一个由另一部门发出的事件被“声明已接收”而自动成为新建的接收事件,它的状态就 是“已接收”。然后该事件的处理流程就从上一步“创建跟进集合”/“交付事件”开始。 接收事件的最后状态“已交付”就告知所有组织成员该事件已经被接收人“认领”并会对其负 责。 本例中,发送邮件信息事件之后,VIFIB的社区经理Cédric收到一个联系人的回复。于是他 就基于该回复的内容创建了一个新的接收事件。接着该事件就可能被以两种方式处理:或 者由事件接收人Cédric直接处理(例如,回复发送人),或者Cédric将该事件通过改变“事 件接收人”的方式指派给另一组织成员,并建立一个跟进集合以便将来跟进该事件的处理过 程。 工作列表 Incoming events worklist 同发出事件同理,工作列表简化了工作并为每人的任务提供了清晰视图。 本例中,VIFIB的社区经理Cédric发送邮件给他的联系人后,就要他的工作列表(“我的菜 单”)中有没有“待交付的接收事件”,因为它们可能是客户支持部门员工收到客户对其邮件 回复后建立的接收事件需要他来处理。于是他就可以点击列表进入该事件直接处理,从而 节省时间提高工作效率。