ERP公司的项目实施提成制度设计.doc.doc

ERP公司的项目实施提成制度设计ERP公司的项目实施提成制度设计--02原则既然谈到项目实施提成制度的设计，先得谈谈制度设计的原则，否则你的制度好不好，如何鉴别或判断，就成了一团乱码。 我认为好的项目实施提成制度设计可以从个人感受和组织绩效两个角度去评价，我的评价办法也很简单，就两条。 从个人感受的角度，好的制度应该是： 1、简明，可预期 从组织绩效的角度，好的制度应该是： 2、匹配，与组织的结构，人员的能力，产品线特点以及市场经营目标匹配 先谈谈简明，可预期该怎样理解。 在ERP类复杂项目实施里，管理者有很强的动机去搞清楚一个事情，就是每个项目到底是赚了还是亏的，否则将来公司资源将来往哪个方向投就是问题。 那么项目实施过程中需要调动营销配合，需要实施费用，也需要公司开发团队配合，那么一个项目实施的提成是不是应该扣除营销成本？是不是应该扣除开发费用？ 还有即使在项目实施过程中，是不是应该考虑项目金额，项目难度，项目周期，项目质量来管理实施人员，鼓励他们多快好省地完成项目？ 这些都需要量化，不量化就没有办法做科学评估，进而建立有效的绩效管理体系。这话很熟悉，对吧？国外的人力资源顾问都是这么讲的。 不过这样的结果极端的情况就给秋叶遇到了，为了搞清楚项目的成本，就必须详细合算工作量，这样项目的实施提成计算变成了如下公式： 项目实施提成=（合同额-营销费用-开发费用）*项目难度系数*项目提成 其中项目难度系数有34个变量参考评估，以给予合理的工作量计算。 天啊，这个公式出来后，估计麦肯锡的人力资源顾问也得来请教我们的量化细则，很好很强大，很牛很科学，就是有一个问题。 什么问题？ 一个实施经理在接到100万的项目实施，他自己算不清楚自己到底能提成多少钱了，即使这次算清楚也没用，下次项目开发成本和营销成本是多少，都是动态的，全乱了。 假如一个人对自己的未来收入没有预期，他的实施积极性必然存在问题，就这么简单，所以我说好的设计应该简明，让实施人员自己算算就清楚，否则就容易出问题。 秋叶个人的观点是，对很多公司，对于影响项目成功因素特别多的复杂项目（未必项目金额大），采取简单的一刀切模式也许更好，反正一刀切可能短期内个别项目不公平，长期看，还是一刀切好一些。 再从组织角度谈谈提成制度，我们很多人想找我要个制度模板，然后参考，这种想法是很有害的，每个公司情况不同，对制度设计应该有区别，才能最大发挥激励作用，让员工在制度设计下能动性和公司经营目标最大程度相符。 举几个小例子， 假如你的公司规模很大管理层次复杂，又或者效率很高转向非常快； 假如你的公司鼓励做价高单少大项目，又或者做价低量大的小项目； 假如你的公司人员能力够又稳定性高，又或者新手多又跳槽人很多； 假如你的公司产品实施多年口碑不错，又或者新产品实施问题多多； 这些边界条件不同，你能套别人的制度吗？ 也许用友金蝶现在的制度你拿来都没有用，不过他们当初创业，或走上一定规模时期制度更适合你现在的情况。 没有权变思维的意识，到处找灵丹妙药的人，估计也管不好你的提成制度。 从这点上讲，秋叶个人观点是： 没有一劳永逸的提成制度设计，你的制度总要和你企业现在的情况进行评估，选择当下最匹配的制度。 ERP公司的项目实施提成制度设计--03分类上一篇谈到组织不同，对实施制度设计有很大影响，那么如何了解自己的组织在什么区间，是个难题，因为要考虑的因素太多。 秋叶这里做一个简单粗浅的划分决策分析模型，也希望有见识的朋友将来提供更好的决策分析工具来完善。 秋叶建立一个矩阵框架，横坐标是公司的人员能力，从弱到强，纵坐标是公司的规模，从小到大，如下图： ? ? 这个划分模型是秋叶针对市场公司类型一个粗的分类，未必是最精细和科学，但也反映了一些特点，先说说秋叶心目中每种类型的代表，还是用图说话简单： ? 这里要解释下秋叶如何界定高风险，瓶颈区和安全区的。 创业小团队风险大不用解释，刚接到大项目是机遇也是挑战，很容易“过能死”，但为什么拥有标准化流程和产品的大公司我认为他也是高风险性呢？ 秋叶认为这类公司逐步变成为渠道所左右，丧失了对客户个性化需求的快速响应能力，在软件这个行业，不创新不重视客户，也就进入了危险区。 这类公司要么走向行业大客户捆绑个性化服务之路，例如EDS的外包模式，要么走向IBM这样的行业领导型咨询服务模式，才能和巨大的客户结成利益共同体，抗拒商业生态链突变式危机。 而小公司一旦能做起来，接更多同类的单不是问题，但很辛苦，利润也微薄，所以他们关注能不能做大，往上上一个台阶，例如能接更大的单子，赚更多的现金流。 而做到一定产品成熟度的公司，就关心能否复制现在的产品和实施模式，也是很痛苦。 外包的公司，入行容易，做大规模的时候遇到的问题也是一样，大行业客户已经有伙伴了，小行业客户对生存不是问题，但要发展