创建一个变更管理流程-部分1
让我来猜想一下，你的收件箱一定已经塞满了用户要求你更改Salesforce功能的请求。你的桌子上也可能同样布满了相同内容的便签。更有可能的是，你的笔记本里也同样写满了用户各种各样的请求。
一团乱，根本没有优先级。或者根本不知道从何开始！
变更管理对很多人(包括我自己)是一个非常抽象的概念。我花了几年时间充实我的大脑去明白变更管理对我意味着什么，以及如何管理变更。今天，我将解释为什么你需要一个变更管理过程，以及我是如何管理我所在组织的变更管理请求的。
什么是变更管理
因为这是一个比较抽象的概念，让我们来了解下变更管理的概念。MindTools定义变更管理为：
“…一个系统化的方法以确保变更能够彻底并顺利的实施，而通过变化将得到持久的好处。重点是关注对整体的影响，特别是作为个人和团队如何从现状过渡到新的状态。”
根据这个定义，很容易了解到变更管理绝不是一个待办事项清单或一组规则，恰恰相反，它是一种方法，旨在帮助用户拥抱变更的实施。
根据公司的规模，变更管理可以采取许多不同的形式,大公司可能会需要遵守很多的流程，而规模较小的公司可能只是关注最终的结果。
关键是不需要将它复杂化。
反对声音
好吧，在这一点上可能会有一些反对意见。在我们进入更多的细节之前先解决这个问题，因为这是这样一个重要的话题，我不想让你认为你不能这么做变更管理。
我只有一个人，我没有时间
我一直是一个人在管理公司的系统，很难兼顾抛到我这的一切请求。很多事情你想做，但就是没有时间。我明白，但我敢说你今天花时间来解决这些问题正是解决你总是没有时间的问题。
你当前的流程不是可持续的。是时候升级你的流程，让自己变的更轻松些了。
我没有变更管理的经验
这是一个很容解决的理由，我将向您展示如何建立一个变更管理过程，你可以在此基础上调整和修改以适合你的情况。你可将它视为一个基础,一个起点。
好了我们已经解决了这些异议，开始进入正题吧！
创建一个需求表单
首先，我们需要在Salesforce中创建一个表单来捕获来自用户的请求。这个表单将取代便签和电子邮件，让你成为更有条理，办事效率更高的管理员。
在标准Cases对象下利用新的记录类型和页面布局创建这个表单是一个好方法。当然也可以创建一个新的自定义对象跟踪这些请求。两种方法都可以——只是确定哪个更适合用户和组织。
包含的字段
这个需求表单里将包含一些基本的字段。除了这些标准字段，你可能希望创建一些新的自定义字段。浏览一下这些你一直在工作的需求，看看是否有任何缺失的信息，如果有，添加新的字段来捕获这些信息。
下面是我们在需求表单里使用到的字段：
- ReadyTalk Team – 一个下拉列表包含公司内部所有的用户团队. 这可以帮助我们跟踪各个团队的需求数量，用来了解需求的类型和数量
- Request Type – 一个下拉列表对需求进行分类。值包含Workflow / Validation Rules, Email Template Creation / Modification and Reports & Dashboard 以及 others.
- Status – 这个下拉列表帮助我和我的团队来区分进来的需求的优先级。
- Subject – 需求的简单概述。把它添加到报表和列表视图中做快速的信息参考。
- Request Details –文本框，要求用户添加的所有细节的要求。
还有几个额外的字段，你可以看到下面的截图。
Admin Request Details Page
一旦在需求中添加好这些字段，你可能还需要一些专门供你使用的字段。我们发现有几项我们希望或需要跟踪，这些字段包括:
- Salesforce Case Number – 如果我们需要开一个Case去解决用户的请求， 我们希望可以追踪哪个Case和用户的请求关联。
- Date Completed –当Status标识为完成时，我们使用一个工作流规则自动更新这个字段。它会帮助我们做一些一般性的时间周期报告。
- Administrator Notes –这是一个输入备注的地方。通常，我用这个字段来记录从Chatter或email发来的一些附加或重要的需求
- Time Spent –一些数字类型的字段，可以用来评估我们大概在此需求上花费的时间。使用这个字段来得到我们在不同部门不同类型需求上所花费的时间。
- Resolution –我们把解决方案输入到这里。当Case标记为完成后此字段的信息将会自动通过邮件发送到需求请求者那里
这是第二部分的关于Admin Details部分字段的截图：
Admin Request Detail Page Continued
记住，这些字段只是建议。最终还是要创建适合你的业务和你支持流程的字段。
建立工作流和Validation Rules
现在的表单已经建立，考虑在创建新记录时添加一些工作流和验证规则。
下面是一些例子:
- 记录创建通知——当创建一个新的需求请求是发送电子邮件或Chatter消息给管理员。
- 通知需求请求者需求已经解决——当请求被标记为完成，发送电子邮件给需求提出者，请求关闭此Case。邮件中包含解决方案细节。
- 使用工作流规则更新完成日期。
- 当需求优先级为重要时，创建一个验证规则优先级时需要填写一个业务案例。
- 某些请求类型中需使用一个验证规则来要求用户填写需要新字段的原因。
部署，培训，实施
通知用户已经有了新的需求提交流程，需要将所有的请求都通过表单来提交。这中间可能有些曲折，但一旦你强迫用户进入新的流程，他们终将一贯于创建表单。
在过去的几个月的时间里我们对用户的要求不是很严格，在某些情况下,我们替用户创建表单。但是我们慢慢让他们抛弃原来的习惯，现在要求所有的需求请求都要通过Salesforce提交。事实上现在在会议上用户已经开始问我们如何来提交请求了。
使用Chatter去沟通
Chatter是一个很好的沟通工具。它代了替电子邮件，你和用户可以使用Chatter询问问题，并将更新信息发布在Chatter feed上。这对我们的公司有很大的帮助，因为所有的谈话都集中在一个区域，每个人都可以看到与自己直接相关的信息。
你对本文介绍的流程有何想法？你有其他的好的建议么？如果有的话请给我留言吧。