2/22/2015 (T-14) Purchasing/Warranty

2/22/2015 (T-14) Purchasing/Warranty

After a relaxing weekend, I was asked to come in and meet a little early today to set up a user account for myself and discuss some of the system architecture. This was cut short by our project manager coming into the meeting early to announce some new information she received on the GL structure that was supposed to be provided this past Friday. She let us know there was a meeting with HQ at 3:00 today to discuss further. I received an email with 10 file conversion layouts from the Lead Consultant. I made a joke that I did tell him not to send them to me on Sunday night, and say in the meeting on Monday that he was waiting on me to export the data. He figured it was safer to give them to me on Monday.

Purchasing discovery- Two of the purchasers were present to discuss current happenings, and potential improvements to their current workflow.  Normal purchasing questions and discussions for the most part. There were a few instances that were discussed concerning outside processing (subcontract, consignment, value added service - many different names). Essentially, this is where you send a part out to a vendor; they add some value (painting, welding, assembly, machining, printing...); you receive the part(s) back in under a different part number.  The lead consultant discussed how it is handled in the new ERP software. Surprisingly, it was very, very similar to the way we are currently handling it. Our purchasing department was very disappointed that there was not a more magical way to handle this somewhat cumbersome process. They have argued with me for months about how to accurately perform the tasks. They don't like having multiple steps in the process. The new ERP software does consolidate the process a little more than I can in the current software, by eliminating the need to create a work order to relieve components and receipt the finished part. They were still disappointed and a bit confused by the process.

Purchasing was informed that all vendor numbers would be changing to consolidate vendors between the companies. Someone from HQ will be responsible in the future for setting up new vendors. There is concern that the process of setting up a new vendor will not be efficient when a PO has to be cut quickly.

A common question among buyers in automatic PO numbering or manual numbering. Every buyer wants to be on the phone at lunch or in the car, call a vendor and give them a purchase order over the phone. Most companies (especially companies intending to run MRP) would mandate a purchase order be cut as soon as the buyer enters an agreement with the supplier. The new software takes a novel approach by allowing automatic numbering, but also allowing 'reserving' PO numbers by a buyer. I am not sure I like giving the buyers that ability, but it is available (not my decision to make).

There was quite a bit of discussion about the receiving process, and current deficiencies in our vendor management. Since there was nobody present from the warehouse to have an educated discussion about why things aren't received in a timely manner (no packing slips, wrong part numbers, packing slips referring to closed purchase orders), receiving was blamed for everything.

RTV (Return to Vendor) processes were discussed. We currently don't have that module for our existing ERP system ( Management decided not to purchase it). Anything shown to fill the existing hole would seem substantial compared to a manual system.

Everyone went to a local Italian Deli for lunch. I opted out since I had some personal business to attend to. I tried to export some of the data that was sent to me this morning. I then realized the lead consultant forgot to attach the templates. Oh well, I didn't have any plans this evening.

Part Sales and Warranty discovery started around 1:00 pm. There is one guy currently responsible for both activities. He isn't able to keep up, and was hoping the new system will aid him in being more efficient. The meeting got off track pretty quickly, talking about potential future improvements to the warranty tracking system. I was able to refocus everyone and discuss what is currently available in the new system. Again, it seems substantial, since management opted not to purchase the RMA module for our existing system. In comparison to what I know is available in our current system, it was very similar. There were a few features that are industry specific. They weren't specific enough, which is why the conversation kept getting off track.

Part sales was a fairly typical discussion. The processes are almost exactly the same as what is currently being done.

Our 3:00 meeting with HQ was more discovery than expected. We expected to have a new GL structure and new account numbers presented to us. The VP wanted to better understand what was available and what was recommended before making any decisions. This was tasked to them last week, to be completed by last Friday. The lead consultant let them know that we needed the new structure by next Thursday (the day of the CRP). This was one of the rare moments I have interjected any comments about timelines. If our accountants are to have time to map the new account numbers to our existing account numbers, and allow us to have enough time to convert the data, we need more than 5 minutes. HQ is now tasked with having that data by next Tuesday.

Discussions continued about merging vendors, customers and part numbers. Half an hour was spent discussing how it could be done and when. The decision was to table the discussion until more companies began the implementation process. We will remap those items then, and convert the data we are using, to match the new numbers.

I spent 4 hours this evening converting data our of our existing system into the format requested by the lead consultant. Mostly master tables. There were a few transaction tables we will try to get into the test system. Hopefully, we can evaluate the quality of the conversion during testing next week. I still don't think the CRP will offer us enough time to adequately evaluate the quality of data before 'go live'.