CIO日记

作者：    来源：《CIO通讯》

欢迎访问e展厅 展厅 1 企业资源计划ERP展厅 企业资源计划ERP, 供应链管理SCM, 客户关系管理CRM... 6月20日 天气：晴 今天，新的一轮培训开始了，经过一段时间的休整之后，学员们的精神面貌明显比以前更加饱满了，点名前的那声“好”的问候语也比以前更加洪亮了，信心和自豪都写在他们脸上，看到这样的情景，我这个项目经理自然也乐开了花。 上午安排的是销售管理系统的培训，除了种子选手之外，我还特地邀请了销售部经理和物流科长一起来助阵今天的培训，效果明显有很大改善，主要表现在流程描述和问题讨论方面比以前更加深入，气氛也更加活跃。在后续的系统教育训练中，项目组仍然会引用这种方式，逐步把受训人员向中层干部扩展渗透。周五的生产系统管理培训，我准备让生产企划部的主要骨干都来参加，还准备让生产车间的部分负责人也来听听，这样对项目组和顾问尽快掌握公司生产管理流程加快项目实施步伐有着重要的推动作用，同时也有助于我们的种子选手更好地结合公司的现状去理解去熟悉我们的系统。 在今天的培训中，顾问和学员们都提出了不少问题，我们非常需要这样的学习氛围，在讨论中加深理解，在争论中解决问题。昨天日记中我提到的销售预测问题，今天顾问和学员们也拿出来讨论了，我想要强调一点的是，ERP的生产计划其实都是动态的，是不断在滚动运行的，因此学员们以后考虑系统问题时，一定要跟着系统动起来，不可以出现这样的情况：生产计划一直在动，而你却停留在原地。我举个比较通俗的例子来说明以加深理解：6月20日拉配仓库库存拉头10000个，现在A订单需要拉头6000个，6月25日交货，B订单需要拉头8000个，也是6月25日交货，如果是以静止的方式去判断，6月25日交货的拉头数量不够，但系统其实不是这样的，因为这期间（20日到25日）拉头生产仍然是在滚动进行的，系统会把这几天的拉头计划排产数量自动计算并叠加到库存数量中。 对于销售预测数据，情况也是类似的，预测合计数据总是在滚动叠加修正的，系统支持针对整个销售系统一体的销售预测数据管理，也支持针对业务员单个的销售预测数据管理，前者是统一管理的，业务员之间的预测量是可以分享的；而后者是针对单体的，各业务员的销售预测数据都实行额度管控的，彼此之间的数据分享是有限制的，看我们如何来取舍。销售预测数据的产品是可以通过工单安排生产的，因此预测数据的准确度是非常重要的。尤其是我们业务员对客户单方面作出的销售预测数据更是如此，因为如果出现大的偏离，预测失误所带来的损失客户是不可能替我们承担的。当然，我们也可以通过预测数据转工单生产时进行判断取舍来降低预测失误风险，生产那些通用件的，比如白胚、拉头之类的，而不安排生产那些专用件。 上午我们还谈到了客户的信用度问题，这应该比较好理解，但有一点要注意，对于销退的订单，要及时给予结账，否则会冲消该客户的信用额度。对于系统中客户的信用等级评定，我们还必须做好检验项目和检验比率的设置工作。提到客户管理系统（CRM），我还想多说几句，它涉及到销售队伍和销售机会的管理、市场活动的组织和评价、客户服务请求和订单处理、以及通过商业智能发现客户不同贡献率等各个方面的数字化任务，这些恰恰是ERP软件功能十分薄弱的地方。这种系统的要求更偏于适应如何从外部不同渠道获得信息、如何与外部的系统实现“实时”对接，而ERP系统的设计则更强调内部各个应用的数据集成和实时对接。客户关系管理（CRM）在我们的信息化中长期规划里已经考虑到了，它是作为我们ERP系统的一个补充。 产品编码问题是今天我们争论最为激烈的问题，学员们都清楚，我们和上海公司之间，应该实现产品编码的统一，这样做的好处谁都清楚，项目组在去年就已经提出了三个统一原则，其中就包含了编码统一，现在我们也仍然坚持这个原则，关键是如何统一和何时统一的问题了。由于公司和上海公司情况有所不同，实施进度也有先后，实施范围也有差异，导致了上海公司目前的编码方案不完整，和我们系统可能不匹配（因为他们没有拉头生产），而且他们系统比较简单，生产管理只到生产企划部这一环节，我们不同，产品比他们多而全，生产比他们广而深，项目组目前正在酝酿一个替代方案，一个比上海既优化而又完整的实施方案，当然也包括了产品编码方案，因为上海的编码方案有可能在上拉头生产线时就会出现致命的技术问题了。 不仅如此，项目组实际上还考虑得更远，计划把股份公司的整个ERP技术中心建在这里，之所以这么考虑，是因为很快我们就有这样的需求了，把ERP中心数据库服务器和二次开发的技术力量设在这里，一来我们有这样的硬件设施和技术力量，二来我们的广东、天津、成都公司以后的ERP实施就相当方便，可以统一连接到总部的服务器，在我们的ERP系统上增加站点，并由总部派出专业培训人员到各公司进行ERP实施的辅导培训，这样不但可以大大节省三公司的ERP实施成本，同时也可以大大缩短三公司的ERP实施时间，我们何乐而不为呢！ 对于上述的设想，项目组正在从技术角度上对方案的可行性进行论证，一旦可行，也将为上海公司的ERP后续实施提供一种后备方案，以降低上海公司ERP实施的风险，这样一来，将在总部设立ERP编码中心，负责整个股份公司的产品编码工作，并把产品编码录入ERP中心服务器中，供各分公司共享使用。 6月21日 天气：晴 根据项目计划，今天我们安排了有神州数码实施顾问参加的料件编码第一次讨论会，在前面的日记里我不断提到了料件编码，并称它是项目组首先要面对的第一个难关，这主要是因为我们公司的产品复杂，可以说是千变万化，编码规则的确定有一定难度，编码工作量也相当巨大，而且产品编码还必须结合产品结构表（BOM）的设计，这和人的身份证号码编号还不太一样，在下面篇幅里我会详细说明的，以帮助大家理解料件编码和BOM表设计这两个专业技术名词的真正含义。 公司的产品编码工作不是现在才开始提出来的，其实在研发部、拉配部都存在有一定数量的产品编码，但由于编码原则过于简陋，而且编码的产品范围窄，使用的部门少，缺少统一标准，不适应ERP系统对产品编码的要求；为了配合ERP项目实施，公司在去年下半年成立了由品质环境本部主导的产品编码委员会，在成品、半成品和拉配产品编码方面做了大量工作，也取得了许多宝贵经验。项目组这次的料件编码工作，是想在充分吸收了去年编码委员会所取得的精华的基础上，结合ERP系统的具体要求和产品结构表（BOM）的设计情况，并考虑实际工作的可操作性，制定出一套既简洁又完整的料件编码方案。 今天的编码讨论会收获还是蛮大的，各方面的专家代表基本都到齐了，特别是两个重量级人物的参加：营销系统总经理助理和品质环境本部的部长，他们为这次料件编码工作提出了许多极有见地的建议，这些建议使得原来一些看起来比较复杂的东西顿时变得简单了，他们俩是我们这次ERP编码小组的顾问。在接下去的几天里，项目组将继续集中力量，和顾问一起讨论制定一套行之有效的料件编码方案来。 6月26日（下周二），双方项目小组将联合召开ERP项目实施总结会议，向公司ERP领导小组汇报项目实施的具体进展情况、面临的问题和需要的资源，这样的项目总结会议每月1次，基本就定在每月的26日（如遇周末顺延）。为了做好和上海公司的产品编码统一工作，下周我准备和顾问一起去趟上海，和上海公司一起协商料件编码、BOM表设计等一些技术性较强的问题，同时了解上海公司系统上线前的工作准备情况。 附录例子：料件编码原则说明（条装） 上面是目前项目组考虑推荐的条装产品编码结构表，可以看出，它是由码装和拉头两部分组成，其中码装8位，这里我们把条装两个重要的属性（颜色、长度）单列出来了，颜色占4位，长度也是4位（具体需要的位数可以调整的），为了减少条装产品的编码位数，拉头部分我们是采用流水号，它由头粒、拉片和中间件三部分组成，占7位，有一千万种组合方式，我想用它来表示拉头三个组成部分已经是足够了。拉头其它属性，比如说上下止等，我们把它放在后两位流水码中。 按照上述条装编码规则，业务员在接单时，必须输入码装、颜色、长度、拉头主属性（头粒、拉片、中间件）和拉头其它属性，系统将根据这些输入属性对产品进行自动编码，并在料件编码库中自动查找相匹配的码装，通过码装编码找到其BOM表进行展开，生成对应工单，安排生产。 拉头部分比较复杂，在系统中维护了一张由头粒、拉片和中间件这三部分组成的拉头编码表，同时也维护着和这张编码表相对应的拉头产品结构表（BOM），除此之外，在业务员按上述条装编码规则输入订单自动生成拉头流水码时，系统还必须自动生成该流水码和对应拉头编码的映射表。这样，订单便可以通过这张映射表，找到对应的拉头编码，然后通过拉头编码，找到其对应的拉头产品结构表（BOM），生成工单，安排生产。 上面的例子感觉还是有点不太好理解，可能我也没有表达得很清楚，大家看了以后如有疑问，可以来找我或者找项目组的其它人员，也许面对面的解释会更为清楚。(end)

文章内容仅供参考 (投稿) (如果您是本文作者，请点击此处) (12/8/2008)