结束了痛苦的日子 结束, 神话, 系统, 经历, BaaN

FLEX_ERP.Jerry

结束了痛苦的日子BaaN的实施结束了。
这段时间过的很辛苦。我们用两个月的时间创造了一个神话，但在这个神话背后却着实隐藏着很多艰辛。
我没有经历过系统实施，仅有的一次类似经历还是当时IFS系统的更新升级。老实说当听到Global关于常州Site要更换BaaN系统的消息时我很忐忑，因为心里没有底，但又十分想做好它，那时的感受记忆犹新。好几个夜晚都在失眠。不过终究还是熬过来了，这个过程很兴奋。有痛苦，有无奈，但更多的还是快乐和欣慰。
实施结束后的这段时间，我们忙于优化之前制定的流程，同时开始编写相关实施文档以供备案。在这里，我急切地想分享自己这两三个月来的经历和感受，虽然写的不好，但同样希望这篇文字能够带给大家一些启示。同时也欢迎朋友们随时指教。

一．四月七号
三月中旬，我们接到通知，Corporate将派驻在马来西亚的FLEX BaaN专家前来常州支持我们的实施工作。刚开始我们对此没有任何关注，只是照常做着手里的事，等待着这位专家的到来。
基本上在四月七号之前公司的一切都在照旧，所有流程均围绕着IFS系统开展，我们的日常工作也仍然是给予IFS足够的支持。
时间过的很快，尽管我们有所期待。转眼四月七号临近，这位远在马来西亚的专家很快便会来到常州指导我们的工作，我们有打听过，看样子他是个经验老道的角色。七号那天他如期来到常州，在经过一番介绍后我们得知，他叫SK，是此次实施的项目经理。黑黑的皮肤，矮胖的身子，但给人的第一印象不是他那与众不同的外表，而是一种和蔼可亲的感觉（这一点果然在往后的日子得到了印证）。
我们为他安排了一个VIP ROOM，并安排了那几天的工作内容。根据他的要求，我们定义了各部门的Key User，并向他们发出了邮件通知，告知他们未来系统实施当中他们的角色和将要参与的工作。
SK刚来到常州并没有闲着，而是马上展开对常州工厂各项流程的调研。他先是和我们IT部的经理做了交流，了解了现有系统的运行状况和模式，然后和我们做了一些细节上的了解。
SK是个一丝不苟的人。在所有工作开始前他花了一天的时间了解情况，并制定了接下来两周的工作计划表，从计划表中看，本周的第一项工作就是确认现有流程，理清系统流程和实际流程的对应情况。
Please review following activity for next 2 weeks for Logistic (Sales/Purchase/Warehouse):
Date            Time             Activity                                   Personnel
14 April       10-12am        Kick-Off meeting                    All Key Users + IT
14 April       1pm - 5pm     Warehouse requirements         Warehousing Key User
15 April       9-12 am        Sales Control requirements      Sales Key User
16 April       9-12 am        Sales Control requirements      Sales Key User
17 April       9-12 am        Purchase Control Req               Purchase Key User
18 April       9-12 am        Purchase Control Req               Purchase Key User

21-24                             to be confirmed
当我们收到他的计划表时也就意味着实施工作展开在即。我们很期待，但同时也有些不知所措。


二．流程调研
根据SK的计划表，我们认真安排了相关User的参与工作，在这之前我们定义了此次实施工作的Key User的角色和相关职责，明确了他们在实施工作中应当起到的作用。按照我们的打算，IT将就系统的各个环节进行分割，落实到相关Key User头上，并着重对他们进行培训和指导，未来的End User的培训将依靠他们进行，IT将不参与End User的直接培训工作。
在伟创力，站在IT的角度，有一点是值得肯定的，那就是我们的Key User对系统十分熟悉。无论是MRP的运算还是基本的Operation他们都有自己的理解和方法。所以，当我们确定完Key User之后，我们的工作也就减轻了很多。
总的来讲，调研是一件很不容易的事情，我们要做的是明确公司现有流程，并基于BaaN系统给予改善建议。要完全达到我们的目标很难，因为就Mechanical的情况来看，很多Site的ERP系统运行都很乱，其矛盾点主要集中在Logistic一块。所以，像我们公司这么典型的情况更是难上加难。我们之前为IFS设计了很多流程，运行的时间也较长，很多积累下来的历史问题通常都无法找到根本的方法去解决，而这些问题也同样出现在BaaN里面，像Common Part，MPQ物料等等，都是顽疾。
尽管时间过去两三个月了，但我清晰地记得当时我们在讨论现有流程时的激烈场景。我们与相关的经理做了交流，听取了他们关于流程的建议和看法，大部分时间都是他们在Challenge我们，压力很大，不过很过瘾（实在找不到比这个词更合适的了）。那两个星期我的脑细胞估计死了一大半，我们总是在不停的提问或被提问，脑子里总是在想该怎么回答或怎样回答会更好。问题如山一般堆积，能解决的基本上也不会是最好的方案，因为我坚信，任何一个由专家给出的方案都不会是一个最好的方案。
经过了两周的调研，我们整理出了流程文档，在User的确认下Release了所有需要移至BaaN系统的流程。


三．系统培训
调研一结束，SK就着手编写了培训文档，用于接下来的培训工作。
Logistic/Manufacturing training below:

8 May 08                     Warehouse Operation            Warehouse
                                    - Warehouse Order Type and Series
                                    - Item Warehouse Data and Defaults
                                    - Warehouses and Locations
                                    - Adjustment
                                    - Transfer
                                    - Counting
                                    - Warehouse Reporting

9 May 08 morning         Sales Order                          Program
9 May 08 Afternoon     Sales Shipment                     Warehouse
                                    - Customer Pricing, Item Sales Information & Defaults
                                    - Sales Order Type and Series
                                    - New BP (Customer)
                                    - NPI
                                    - Sales Order Entry
                                    - Sales Order Shipment
                                    - Back Order handling
                                    - S/O Cancellation
                                    - Customer Return and receiving
                                    - Order Blocking (Credit Limit / Term)

12 May 08 morning        Purchase Order                   Buyer
12 May 08 Afternoon    Purchase Receiving            Warehouse
                                    - Item Purchase Data & Defaults, AVL, ISI, AML, Receiving Tolerance
                                    - Supplier Pricing and Global Pricing
                                    - Purchase Order Type and Series
                                    - New BP (Supplier)
                                    - NPI
                                    - Normal P/O creation
                                    - MRO P/O creation
                                    - P/O from MRP

9 May 08 Afternoon    - Planning
12 May 08       - Purchase, Planning, Finance
13 May 08         - Production, Finance, Agile (for NPI, ED, DCC)
14 May 08 - Production, Finance, Agile (for NPI, ED, DCC)
15 May 08       - Agile (for NPI, ED, DCC)
16 May 08           - Agile (for NPI, ED, DCC)
培训的日程安排很满，起初我们感到压力很大，因为我们的工作不仅仅在于协助SK完成实施，还要保证现行系统的运行。我们整个ERP Team只有两个人，我负责Manufacturing&Purchasing一块，另一位同事则负责Fiance&Sales一块。基本上前期的培训我都没去听，因为每天有太多的事要做，Daily的Support已经让我忙的够呛，再加上需要全身心投入的实施，我真可谓是分身乏术。
不过还好，培训的工作完全由SK来负责，我们除了需要被培训以外就是帮他安排好辅助工作。不过实际上在培训期间我们便开始了一些基础数据的导入工作。其中最大最麻烦的一项工作便是Item的导入。
由于总部对BaaN系统有一套十分完整的控制制度，我们在认真研读之后根据总部提供的手册的要求给Item重新定义了编码规则，并通知了NPI对这些Item进行重新编码。这确实是一项大工程，当时由我来负责这项工作的实施，我们给NPI定下了交工的日期，当时他们的抵触情绪很大，对此我们很能理解，在经过多次会议讨论后我们定下了双方都可以接受的条款，一是所有Item的命名规则均按照总部要求进行，二是所有Item Code必须在6月15日前完成并导入系统。当时我们的系统中预测有两到三万个料号，按照项目来分虽然工作量在一定程度上得到了分摊，但对每个NPI工程师来说都是一项艰巨的任务。因为之前我们对在IFS中的part做过不少更改，也提出过不少要求，基本上我们同NPI工程师的交往是很紧密的，所有此次工作他们虽然有抵触情绪但还是能够较好的理解我们的意图。
就这样，第一项子工程启动。同时培训继续进行。实施发展到这一步一切还均在我们的掌控之内，但往后的事情却让着实让我们措手不及。


四．基础数据的准备
任何系统的更新或是替换都涉及到一个基础命题，就是如何保证数据的导入是安全并且可靠的。基础数据的导入是一项需要非常谨慎的工作，我们必须尽最大可能保证数据的真实性，可靠性，准确性和安全性。其中，我所涉及到的基础数据的导入包括：Item Date, BOM, Routing, BP-Supplier, AML, AVL, User Date, etc. 在这些基础数据中最大的工程就是BOM了，我们本身有一套敏捷系统，通过该系统可以很轻松地完成Item Data的导入工作，但前提是必须做出准确无误的Template来。在培训处于白热化状态时，我Review了一下NPI的进度，一个消息让我非常吃惊。时间是2008-06-10，我们的工程师居然只完成了不到10%！这让我们一度陷入困境，因为按照进度，15必须BOM就必须导入系统，如果不能按时完成所有其他的子项目都要延期。当得知进度如此之慢后我非常气愤，立即发出了会议邀请，通知所有工程师开会讨论解决方案。在会议上我反复强调了此项工作的重要性，从交谈中我了解到，他们之所以这样慢是因为一来各自手头上还有很多项目要做，二来没有充分意识到系统上线的重要性。尽管管理层对此非常重视，但处于operation层面上的人如果没有重视起来这个项目同样走不下去。
为了能够迅速让他们作出反映，弥补时间上的漏洞，我同时向他们的经理发送了会议邀请，在他们经理的帮助下所有工程师开始投身与此项工作，因为时间所剩不多，我强烈要求他们加班赶工，虽然抵触声音很大，但这也是不得已而为之的方法。就在这剩下的五天里我们日夜跟着他们转，定时发布进度表，随时更正他们所建数据的错误之处。另外，我们在通知他们需要开展此项工作之时就明确告诉他们要准备好一份详细的的新旧系统编号对应表，因为这将是我们日后其他工作的依据，非常之重要。在经过几天的赶工之后进度明显加快，截至13号总进度已达到80%，但错误同样不少，主要集中在Item Code编号不对，Item类型对，格式不对等粗心问题上，还有一些则是BOM本身就建错了，导致部分BOM返工的问题。
不管怎样，BOM的工作在容许的时间内交工了，尽管错误不少，尽管之前我们的工程师没有认真对待这件事情，我还是很感激他们，毕竟我们共同拼搏了好几个夜晚，但辛苦是值得的。对于这一点，我坚信。

五．CRP(Conference Room Pilot)测试
经过基础数据的准备和培训工作的完成，我们开始了下一个环节的工作，就是CRP测试，因为时间的关系，我们将SOP(Standard Operation Procedure)的工作纳入到了CRP测试当中，将其整合起来。

	Simulation Scenarios	Pre-requisites	Remarks/Comments	Start Date	Completion Date
1	Master Data Process			04-Jun-08	04-Jun-08
1.1	Create Items & Master
*	Create 1 FG Item, Sub assemblies, Purchase components in Agile and push to Baan	Item groups and default data in Baan defined	Agile Integration	04-Jun-08	04-Jun-08
	Review Item Sales Data			04-Jun-08	04-Jun-08
	Review Item Purchase Data			04-Jun-08	04-Jun-08
	Review Item Ordering Data			04-Jun-08	04-Jun-08
	Review Item Plan Data			04-Jun-08	04-Jun-08
	Review Item Production Data			04-Jun-08	04-Jun-08
	Review Item Warehousing Data			04-Jun-08	04-Jun-08
	Create 1 Cost item(outsourcing)			04-Jun-08	04-Jun-08
	Maintain Itemcode by Itemcode Systems			04-Jun-08	04-Jun-08
	Maintain Item supplier Information			04-Jun-08	04-Jun-08
	Maintain Approved Manufacturer in AML			04-Jun-08	04-Jun-08
	Maintain Suppliers by Approved Manufacturer			04-Jun-08	04-Jun-08
	Create SMI item			04-Jun-08	04-Jun-08
	Create FSP Supplier			04-Jun-08	04-Jun-08
1.2	Maintain BOM
	Use of BOM Unit			04-Jun-08	04-Jun-08
	Create BOM for FG Item in Agile and push to Baan			04-Jun-08	04-Jun-08
	Create BOM for Sub assemblies in Agile and push to Baan			04-Jun-08	04-Jun-08
	Print Multi-level BOM Report			04-Jun-08	04-Jun-08
2	Planning Process			04-Jun-08	04-Jun-08
2.1	Master Plan(Simulation and generation basd on AML)
	Simulate master plan for plan item(to be given)			04-Jun-08	04-Jun-08
	Simulate Orders			04-Jun-08	04-Jun-08
	Simulate within time fence			04-Jun-08	04-Jun-08
	Verify planned production/PO’s  created			04-Jun-08	04-Jun-08
	Review Master Schedule Output			04-Jun-08	04-Jun-08
	Planned Orders			04-Jun-08	04-Jun-08
	Generate AML by Planned PO LINES			04-Jun-08	04-Jun-08
	Generate AML			04-Jun-08	04-Jun-08
2.2	Review and Change Planned Orders
	Review orders to make changes as needed			04-Jun-08	04-Jun-08
	Double click on highlighted line to open			04-Jun-08	04-Jun-08
	Planned Orders			04-Jun-08	04-Jun-08
	Verify/Change Destination Warehouse			04-Jun-08	04-Jun-08
	Verify/Change Order details to change Quantity			04-Jun-08	04-Jun-08
	Open Order Status Window			04-Jun-08	04-Jun-08
	Change from Planned to Confirmed			04-Jun-08	04-Jun-08
2.3	Transfer Planned Production Orders
	Review Master Schedule Output			04-Jun-08	04-Jun-08
	Transfer Plan/Order			04-Jun-08	04-Jun-08
	Check Production orders			04-Jun-08	04-Jun-08
2.4	Transfer Planned Purchase Order
	Review Planned Purchase Orders			04-Jun-08	04-Jun-08
	Select Order Type and print			04-Jun-08	04-Jun-08
	Select Planned Order Detailed			04-Jun-08	04-Jun-08
	Transfer Planned Purchase Orders			04-Jun-08	04-Jun-08
	Send Demand Forcast to Supplier
3	Purchase Process			04-Jun-08	04-Jun-08
3.1	Normal Purchase Orders
	Raise 3 normal orders for purchase parts, maintain 1 Purchase order with 2 delivery dates		fxcom0102m000(Legal Company Data For Documents)-Purchase Order Footer	04-Jun-08	04-Jun-08
	Maintain AML line wise		AML data to be maintained line wise	04-Jun-08	04-Jun-08
	Change Price for 1 Purchase order after receipt is maintained		Item price defaults	04-Jun-08	04-Jun-08
	Maintain Partial Receipts for 1 orders		Back orders created automatically	04-Jun-08	04-Jun-08
	Cancel backorder for 1 order			04-Jun-08	04-Jun-08
3.2	Purchase Cost Orders
	Raise 1 cost orders and maintain receipts.(warehousing receipts)		No inventory	04-Jun-08	04-Jun-08
3.3	Purchase Return Orders
	Raise 1  purchase return orders (give the original ordr reference)			04-Jun-08	04-Jun-0

这个是我们安排的6月4日的CRP测试表，由于当时一些数据还未导入系统，但为了能够让Key User早日熟悉系统，我们采取了同步的方式让他们进行测试，确定需求。所有的测试均在测试库中进行，为了模拟正是环境，我们将待导入的部分数据导入到测试库用于User操作。
CRP测试的难点在于我们需要将日程的业务操作涵盖进测试系统，这对于Key User来说非常重要，他必须清除知道自己日程的业务将在哪些Session里完成，并因此会产生哪些结果，会影响到什么等等。之前我提到过我们期望将SOP纳入到CRP测试中来一同完成，这也说明了我们的Key User对系统的标准操作还不是很熟悉，所以要一下子进入业务操作测试确实存在很多问题。不过好在我们User很关心自己所要面对的模块，在规定的测试时间以外他们也会自觉进行练习，这也给了我们更多的时间布置更重要的事。
测试完全按照模拟环境进行。我们给定了一些假设情况，要求User按照这些情况给予解决方案并在系统中进行相应的操作。首先是让PA在系统中下了张销售订单，然后根据BOM让采购和计划分别开具了采购订单和生产订单，订单分别OK后安排仓库完成了收料操作和发料以及下线操作。每一环都是紧密相扣的。
当然，CRP测试中的重点还是在于指导Planner进行MRP运算。这是重头戏，除了要求计划清楚该怎样运算MRP以外我们还要求计划给出详细的Planning Requirement，以及哪些地方需要定制，哪些地方需要改善等等。
整个CRP测试我们分成了两部分，第一阶段是Key User进行，第二阶段让Key User指导End User进行。测试结束由我们指导Key User编写操作文档。

六．盘点＋数据导入＋MRP RUN
系统上线前的最后一个大工程――全厂盘点。
我们公司的盘点不是难题，因为我们有训练有速的盘点团队，整个盘点花费了不到两天的时间，加上后期数据的整理，我们有效的控制了上线的效率。在数据准备妥当之后，系统中的Inventory因此成功地导入了系统。接下来我们要做的就是计算差异。这是Finance一块的内容，在这里我就不多说了。
根据要求，我们在完成库存导入之后便进行了一次MRP运算，结果可想而知。100%准确是不可能的，我们之所以要运行这次MRP，一是为了让接下来的生产变得有序，另一方面则是为了看看整个系统上线的结果究竟如何。

2008-07-03	1) Planners load new MPS in BaaN 2) Baan Run MRP
2008-06-30	1) Plan to release BaaN at 08:30AM. 2) Planners manual creat outsourcing work order in BaaN based on counting data.
2008-06-29(Weekend)	PI in process(Plan to finish data entry in IFS and BaaN before 24:00PM)
2008-06-28(Weekend)	PI in process(plan to get all counting data before 15:00PM)
2008-06-27	1) Buyers start cancel or close all received PO and manual creat purchase order in BaaN system,negotiate with suppliers for PO transferring. 2) Planners start manual creat work order in BaaN 3) IFS system transaction freeze at noon 12:00AM,PI start. 4) Shop floor return all materials to warehouse before 17:00PM.

七．上线
正是宣布系统上线之前我们还做了不少工作，其中最主要的工作就是培训加操作支持。我们为了让系统里的流程更加完善，展开了详尽的培训工作，而这一个阶段的培训完全依靠我们完成。虽然前期的培训我们没有参与，但我们在平时花了相当多的时间研究系统，对它的结构，特性和操作原理进行了一系列分析，并赶在User之前掌握了系统的方方面面，即使做不到十足的了解但对于日常的支持可以说是绰绰有余了。
上线期间的培训我们花了很多功夫，因为有些流程已经在运作了，有些东西看似已经定了型，我们要做的是纠正现行操作中不正确的地方，并发布相应的规定，要求并明确指出User该怎样做才是正确的。每天我们都会根据系统里的数据拉出相应的报表，分析这些数据以查找出问题出在哪，由谁导致，有些问题说来说去还是人的问题，系统是死家伙，操作者如果不能按照要求进行会给我们的工作带来很多不必要的麻烦。

八．系统支持
刚上线的系统急需一支强有力的队伍给予支持，因为之前IFS系统升级时我们曾组建过一支Tiger Team来给予Backup，现在这支队伍又到了该上场的时候了，只不过此次的队员都是公司的Manager，当然除了我们两个以外。
我们始终坚信自己的支持是有效的，但问题在于同一个错误应该允许它重复几次？！我们的User反复犯着同样的错误着实让我们感到难受，为此我们只能借助于系统来实现我们强制性的要求，因为制度不是我们IT应该考虑的。

就这样，我们在高压下度过了近三个月。痛苦？欣慰？紧张？激动？真的是五味杂成。接下来还有很多事情要做，至于结果，还是不要想的好。
九．流程优化
现在正在做的···

花了些时间写了这篇不知道是什么的什么，见笑了。
最后要感谢那些在实施过程中帮助过我们的朋友，SK，Raymond, Tiven, Aaron, Jargon```

pest0005

1，兄弟，你这篇文章表明，向项目经理的路上迈出了重要一步。相信从SK身上学习了不少东西（ERP项目迁移方法论）

2，从BOM建立的过程，相信兄台明白沟通以及配合的重要。相信伟创力在这块水平在国内来讲还是不错的。
从我的经验来说，沟通和协调就是一切。
尤其是技术层面已经掌握了以后，往往项目成功的成败就在于组织结构，沟通效率。

3，期待你的大作，关于BaaN和IFS比较分析！

城市孤星

这是ERP100上较长一段时间里看到的一篇很现实的、关于实施顾问现场工作的文章，ERP的实施确实是痛苦和快乐并存的一项工作，不是任何一个普通的实施人员可以能全盘做得好的，但是在整个实施的过程中，扎实的基础，良好的沟通，文档的写作都是考验一个实施顾问的功底的时候，期待LZ能更上一层楼，并能多分享。
同时也很乐意能和LZ交个朋友，本人QQ是：418505403，谢谢！