Wednesday, February 11, 2015

How to Implement ERP in Less Than 30 Days

In order to protect my current employer, the new software company and myself from any embarrassment, I will be keeping this blog somewhat anonymous - at least for the time being.

First...A little about me:

I have been an IT Professional for nearly 20 years. For the past 17 years, I have worked pretty much exclusively as a BSA (Business Systems Analyst) and an Implementation Consultant with a fairly popular ERP software based overseas. I have a strong background in PI (Process Improvement), PM (Project Management), IT, Inventory Control as well as Manufacturing.

In summary, I am far from a novice when it comes to implementing an ERP system.

From the Beginning:

I have worked for my employer for about 18 months. I was called in to finish implementing their current ERP program. They previously decided they didn't have the money to pay the consulting company they purchased the software from, to correctly implement the software. A year passed, and they hired me to come in and help get the system up and running correctly. It is a new division of a 25 year old company. After several interviews, in depth discussions about company expectations and manufacturing philosophies, I decided this would be a great opportunity to rest my career for the next 15-20 years.

Just a few months after I started at the new company, the President told me about a great opportunity that was presented to him. We had an opportunity to employ the current plant manager from one of our bigger competitors. I was very excited to be able to add someone to  our team that has 30 years of experience in this industry.

From day one after the new plant manager started, she complained about our ERP system. Seems that she was used to using the same ERP system for most of her tenure at her previous company. She pressed on for almost a year about 'her' system. On 1/22/15, we saw a demo of the software she used at her previous company.

The owner at my current place of employment decided immediately that he liked the software and wanted to buy it.

On Feb 3rd, I was informed they were purchasing the new software. I was informed on Feb 10th that we would have a Kick Off meeting on Feb 12th to begin implementing the software. I was also informed that it would be implemented on Mar 9th.

After talking to a long time friend that I have worked with for many years, he asked me to write a blog of the coming implementation. He was amused at the idea of a 30 day implementation (as am I).

Good, bad, or indifferent....I  will be posting the events, challenges, successes and failures of the implementation over the coming days. My hope is that other professionals will learn something from the next 30 days of my life. If it is a success, other implementors can learn something about expediting the implementation process. If it is a failure, hopefully overly ambitious management will find this and realize the value of planning a project of this magnitude. Either way, I will be here with the goal of a successful implementation - and documenting the entire process along the way.

It is probably fair to note that our division will be the first (guinea pig) implementation out of many for the entire company. The remaining divisions will start implementing the same software over the course of the year. I believe 4 other divisions will be moving from their existing software to the new software.

2/11/2015 (T-26)

I was notified today that the software for all divisions will be loaded onto two servers (a database server and an application server) at our HQ's location. We currently do not have any adequate VPN connection between our location and the HQ location. Our remote facility #1 is currently set up with VPN connection to our facility (since we are currently hosting the application servers for the currently installed ERP System). It was rumored that our 2 new servers should be installed at HQ on or about 2-25-15 (T-12 for those paying attention to the countdown).


2/12/2015 (T-25) Kick Off Meeting

As is typical in most implementations, most of the department heads were pulled into the conference room this afternoon for the 'Kick Off Meeting'. What was different about this kick off meeting was that this was the first exposure to the software for most of the department heads. Most of the attendees of the meeting are still yet to see any part of the software. Only one of the department heads or actual current ERP users were involved in the pre-sale evaluation of the new software.

The general overview of the implementation timeline took about an hour. There were very few questions or comments. The few that were presented quickly turned into off topic conversations.

The masses dispersed and left a few critical participants of the implementation team to begin sorting out the details.There were 12 main sections of the plan outlined, with a few miscellaneous subsections. I was quickly calculating the number of work days, consulting days, hours and events facing us.

We currently have 16 working days, 9 consulting days (the lead consultant/project manager is available 3 days per week to work with us), 12 outlined sections, data conversions of most existing data, server setup, vpn setup, discovery, training, GL account restructuring and countless questions needing answered. Assuming that a day is defined as 8 hours, that is 72 consulting hours to complete all of these tasks.

The Outlined Sections are as follows:
  • Sales Order Entry
  • Scheduling
  • Engineering (BOM Entry)
  • Production Release
  • Production Tracking
  • Labor Tracking 
  • Quality Tracking – Rework and Inspection doumentation
  • Material Planning 
  • Job Completion 
  • Shipping and Invoicing
  • Accounting
    • GL Structure
    • GL Integration
    • GL Entries
    • Financial Reports
    • AP
    • AR
    • Cost Accounting
  • Post Delivery Support
    • Warranty
    •  Service
    •  After Market Part Sales


There was some minor restructuring of the outline that resulted in 10 main sections instead of 12. Not significant, but it does help simplify the math. 72 hours divided by 10 outlined sections results in approximately 7.2 hours dedicated to each core process of our 'Phase I' of the ERP Implementation. In order to keep the math simple, we will leave out tasks such as data conversion, server setup, vpn setup, data validation, testing, conference room pilots....We will just assume that we have the discovery phase (the time in which the consultant helps identify our current requirements, processes, workflow...) and training. We are also going to make the assumption that our company currently has all of the processes and procedures well documented and enforced throughout the company.

A schedule is born: In short, we are dedicating 1/2 day of discovery to 8 of the above core processes (two of them are going to be handled through training by the two production managers that are already familiar with the new software (they also came from our competitor)). 1/2 day of training is scheduled for the same 8 core processes. 1 day is scheduled for the Conference Room Pilot. If you are not keeping up so far, that is approximately 4 hours of training time for core processes such as the multiple accounting tasks.

Several main concerns about switching the software were broached (remember that all divisions of the company are going to eventually switch to the new software, and we are standardizing as much as possible):

  1. General Ledger Chart of Accounts - The CFO will be responsible for releasing a new corporate structure for Chart of Accounts by 2/20/15. We will create a 'mapping' from our existing chart of accounts to the new structure.
  2. Inventory Stock Codes - There was discussion about revamping all of our existing part numbers using a new part numbering methodology. This would essentially render all existing Engineering Models and Bills of Materials useless. This would also affect all existing customer's that reference already published stock codes.It was decided to postpone the restructuring until after Phase I was complete.
  3. Manufacturing Philosophies - Will our BOM contain a fully structure BOM or only reference Raw Material Requirements? Will we create manufacturing jobs for the 150+ manufactured parts required to build our end product? How will routings be structured? How will we integrate to our fabrication nesting software? All of these questions were tabled and would be discussed at a future date.
  4. Customer Accounts and Vendor Accounts - Should we reconcile customers and vendors with all divisions before our go live? Is it possible to do? What are the limitations? The account numbers are numeric fields. Other divisions currently use AlphaNumeric structures for their account numbers. Will changing account numbers affect existing customers or vendors? No decision was made on making changes.
The remainder of the discussion focused on data conversion. The consultant is going to provide 'data templates' to be populated from our existing data. I will create some scripts to export the data for testing. He will be responsible for importing the data into the new system. The plan is to run these scripts before the Conference Room Pilot and conduct testing to make sure it is acceptable. The Conference Room Pilot is scheduled for 3/5/2014 - leaving one day between the CRP and the 'Go Live' date. The scripts will be run again before 'go live' to have the most current transactional data in the new system.

Although there are many different uses of the term 'Conference Room Pilot', there are three commonly accepted principles:

  1. A CRP is commonly used to identify how well the software fits the business needs and identify gaps.
  2. There is an expectation that changes will be required before acceptance of the solution.
  3. CRP's should be performed early in the process, throughout the process and well before the Go Live' date to allow adequate time to identify and fix shortcomings.
If we are all willing to accept the concept of a CRP as being a tool to identify potential shortcomings or gaps in the software, then it should be deemed unacceptable to perform the CRP with little to no time to react to the findings.

As of now, the next stage of the implementation is for the lead consultant to provide the data templates for me to begin populating data. I have committed to being present during all of the company's interactions with the consultant -so that I better understand the system and proposed changes.

The servers are scheduled to be in place, with the new ERP programs loaded on 2/27/15. That is 5 working days before the 'Go Live' date. I am scheduled to meet with our HQ's technical department on 2/24/15 about the VPN. How long does it take to get dedicated trunks to set up an adequate VPN? Will we have a redundant connection set up in case of failure by our current ISP?  Will we be stuck running off our existing and inadequate coaxial connection for a while? Will it be adequate for 'go live'? How can we possibly test the throughput and react with the CRP 1 working day  before we go live?

There is one other troubling question...who decides on a mid month 'go live' date?

2/13/2015 (T-24) Friday The 13th

Not much to report on today. The 'training schedule' was made available to all department managers today. Personnel was assigned to each session. A few didn't make sense, but that is not a surprise at this point.

I sent an email to the lead consultant today asking if computers should be set up in the conference room for testing and exposure to the software. The response I receive was that it was not necessary since our servers would not be set up until 2-27-15. There will not be a database set up for testing until that time. Users may have 5 working days before 'go live' to expose themselves to the software.

I did read a great article about successes and failures of ERP implementations. Although it was focused around SAP implementations, I think it still stands true. It is something management should read before considering any system.

"CRITICAL IMPLEMENTATION CONCERNS
Even in a single site, implementing ERP means "Early Retirement Probably." An ERP package is so complex and vast that it takes several years and millions of dollars to roll it out. It also requires many far-flung outposts of a company to follow exactly the same business processes. In fact, implementing any integrated ERP solution is not as much a technological exercise but an "organizational revolution." Extensive preparation before implementation is the key to success. Implementations carried out without patience and careful planning will turn out to be corporate root canals, not competitive advantage. "

I know the article speaks of millions of dollars and several years. That stands true for SAP, but isn't necessarily true for mid market ERP software packages.

2/16/2015 (T-21)

21 Calendar days until the go live date...and no activity. Nothings is scheduled until tomorrow. The consultant may, or may not be working on anything. I can't think of anything here that anyone could possibly be doing to prepare for the go live.

2/17/2015 (T-20) Engineering and Sales

Engineering is one of the biggest hurdles at our facility. Engineers don't have enough time to design our products before production begins building. The schedule often changes based on material availability and customer demands. Engineering will be working on an item they think is starting next week, only to find out that their current design has been pushed out for three months, pending customer financing. Customer specifications are not always well defined or signed off on. Changes during production are rarely communicated to Engineering. Partial designs are often released by engineering. What system can accurately run MRP with inadequate BOMs?

We have a simple approach at helping purchasing identify long lead time items by creating Advanced Bill of Materials. This started off consisting of long lead time items. It has emerged into being a list of purchased parts. This ABOM is tied to the BOM for the finished product, then eventually has to be merged as each of the partial releases from engineering is structured in the BOM in the system.

This is a complex problem for any system. It took me months to create procedures, customizations and training to get the data correctly into our current system. We ended up going with a third party program that integrates our ERP system and CAD software. The third party still spent several weeks customizing their well established software, to accommodate our requirements.

The lead consultant and I spoke at length about how this is being handled and how he can handle it in the new system. He is going to write an import program to emulate what we are currently doing (to some degree). He committed to having that done by the end of the week.

Sales- I was only present for a small portion of the sales discovery. The new software handles sales orders much differently than I am used to. They developed their system based on our competitor's way of allocating materials through BOMs directly to the sales order, rather than to a stock code's BOM then to a job. I understand the concept, it is just a different approach.

I had to leave the Sales Discovery early to head to HQ to discuss setting up the VPN. We decided on a hardware device on each side of the VPN. We discussed speed and redundancy. HQ has both on their end. We need to address both concerns at our facility. Our ground is currently frozen solid. I don't see having new fiber installed in the next 20 days.

2/18/2015 (T-19) Accounting and HR

Mostly general discovery about AP, AR, Cost Accounting, GL Transactions. How much time can I spend on the details? I haven't seen much difference in the way many systems handle this: Debits, credits, assets, liabilities,zzzz... Everything was very similar to the way we currently handle transactions. The new system uses some different terminology to define integration. There was not much alteration, customization or setup changes required.

There was some concern about having the same vendor at multiple locations. We all have different accounts with the vendors, different pricing and sometimes different remittance information. Similar concerns were waged concerning customers. We were assured there should be no issues with this as our other companies come online.

HR was a little more interesting. We are currently using an average wage and overhead for employees time in WIP. We will be switching to actual wages and a different overhead calculation. Doesn't sound much like an HR function, but they will be responsible for maintaining wages in the new ERP software, as well as in the Payroll system. The new system has a loosely defined HR module. HR will be responsible for maintaining shifts in the new system. Our shifts aren't clearly defined, but time rounding and incidents will be created based on these shifts. It is a little confusing trying to tie an employee to a shift that potentially changes daily - based on production requirements. There are a couple of hundred employees in our facility and a couple thousand throughout the organization.

On top of HR trying to maintain shifts, wages, points, approvals...they are also going to be responsible for maintaining employee's work centers and supervisors. Our employees often change production lines, supervisors and work centers. Some float around like pollen in the summer.

One positive - I have been requesting that our engineers post the time they spend designing products, to the jobs they are working on. The competitor doesn't do that, so the request was rejected. In the new system, they are finally going to agree with my request to begin tracking design time, since it will be tied to payroll.

2/19/2015 (T-18) Quality and Production

The morning started off with one of the production managers that is already familiar with the software (he too came from the competitor). Most of the discussion was about how it was done at the competitor's place of business. He wants to see things the same way it was used in his past life. Not significant changes to our current processes. Work Centers would all be renamed to what he is used to instead of the simplistic way we currently have it set up. Production supervisors will be expected to take on more responsibility for updating 'product status' in the new system. They have fought tooth and nail to avoid managing any data in the current system. That will be unacceptable in the new system, but was understandable in the past (in management's eyes...not mine)

A big concern is that employees currently do not clock in on correct jobs or correct work centers. How can we make them start doing this in the new system? This has caused significant issues tracking labor values in WIP and finished goods. The solution is to directly tie the shop floor employee's time to payroll. We changed to a new payroll system the first of the year. Now they are going to change the way employees and supervisors report time, again, to HR. They expect this to take place the week after go live, since go live is in the middle of a pay period. HQ doesn't support us doing this since we just changed systems (that was not a smooth transition at all). We did receive all of the interface requirements from the payroll company. No deadline designated yet to have the interface created.

Quality Control (inspection) was the topic of conversation in the afternoon. Many systems were created for our competitor. None exactly match our processes. We have specific forms and checkoff sheets being used.  It was decided to try to electronically create many of those documents in the new system, and link them to the existing rework process in the new software. Other documents will just be scanned and linked for the time being. No real decisions made concerning which would be in the system before go live.

We discussed how the scanned documents and finished good pictures would be 'linked' in the new system. This created a little panic from me. The new system 'imports' the documents onto the applications server, rather than linking them to the live files. Concerns:

  1. Drive space- I am not sure what was communicated to HQ when they ordered the servers. Do they have adequate drive space for all companies to link all docs and pics within the system? That will end up being a substantial amount of TB to backup. I am not sure an adequate disaster recovery plan was discussed given this new data.
  2. Pipeline- What happens when we start pushing multiple 5 mb files across the VPN? Is that going to slow processing? What is the load time to pull up one of these images that is supposed to be more convenient?
  3. Importing Live Documents? What happens when a live file is updated on our side? Will the user remember to re-import that document through the ERP Software? Do we have outdated documents in the new system and different versions onsite? The thought scares me a little. I have worked with document management in the past. I would never have imagined handling it this way.


2/20/2015 (T-17) No Consultant Onsite

I was able to order some additional hardware today which is required for the new system. I caught up on some of my other job duties. No discussions, emails, homework or anything else related to the implementation.

I was asked to spend time researching issues with our existing system. They wanted me to investigate why someone entered incorrect data into the system and come up with a solution to fix the issues and retrain the person who entered it incorrectly. Seems like a futile task at this point.

2/23/2015 (T-14) 

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'.

2/23/2015 - (T-13) First Successful Login/VPN Hardware Installed 

I was able to use the software VPN today to connect to the new ERP System. After several attempts of logging in, and eventually locking myself out, I finally contacted the Lead Consultant. He reset my account, and let me know that I was not authorized to log into the 'Test Database'. He had only set me up to connect to the 'Production Database'. He reset my login account, and I was able to finally connect to the new system and poke around for a bit. Have you ever noticed how much more intuitive a software package looks when someone else is using it?

Our hardware device came in today to set up the VPN between our building and HQ. HQ's tech guy was onsite at our place today to install and configure it. After 4 hours of attempting to set it up, he let me know he had to leave for a meeting. He emailed me at the end of the day to let me know he believed he had everything configured, but needed a change to our firewall to allow connection. I will make the requested changes in the morning and see if it allows traffic to flow through.

I spoke to the lead consultant just before receiving the email from the HQ Tech Guy. He wanted to walk back through the BOM import program I thought was completed over the weekend. It appeared he was doing some final testing on his side, and wanted to make sure his assumptions were correct. There were some required changes do to the structure of our engineering design release process. He assured me he would have this critical piece completed by the time he comes back in ---Friday (today is Tuesday).

I received an email from our Project Manager with another update to the training schedule today. Department training was moved around to allow me to have a few hours of administrative training Friday morning. We will begin setting up users and roles (permissions) on Friday.

I received a bit of a comic relief at the end of the day. As I was leaving the office, I was giving an update to the plant manager. I let her know that I talked to one of the key guys at our remote facility #1 and he didn't know we were implementing the new software - or they were expected to go live with the new system on May 1. I suggested to the plant manager that the 'key guy' be invited to connect to our training sessions via the web next week to get some exposure to the software (he can't be here in person due to personal obligations). She let me know that the plant manager and engineering manager of remote #1 were invited to be onsite the week of 3/9 (go live week) to see the software in action. I rolled my eyes a bit and asked if she really thought that was a good idea (well planned go live days are hectic enough). She almost jumped out of her chair  saying how excited she was to have them here to see the new software going live on 3/9.

Note---My apologies to all for the delay in posting the last week. I am trying to balance having some sort of life, with the extra work imposed on me and find time to be as objective as possible in this blog.

I do want to reiterate my position during this implementation. I am there to support the implementation in any way I can, without affecting the outcome of the implementation. I am not the project manager, I am not responsible for the success or failure of going live on 3/9. I will be Johnny on the Spot if someone needs something from me: data exports, admin, hardware, documentation, troubleshooting...I am trying to be objective and not interfere with planning, timelines or methodology. I am trying to learn as much as I can about the software, different approaches to implementation and process improvement and generally support the plan as best as possible. I am honestly concerned at the short and long term implications of a poor project plan and implementation timeline. That in no way affects what I do or how quickly I do it. I will do everything within my power to support making the go live date. My biases are based on my experience. I don't think I am being pessimistic, I believe I am realistic in my approach. Feel free to reread my post on 2/13 to better understand my real concerns for the longevity of the company.

2/25/15 (T-12) 

Very little activity today.

The tech guy from HQ was working on the VPN again today. Can't seem to get it running.

I spoke to our ISP today about upgrading our internet service to fiber. He is sending someone out for a site survey. He suspects it will take up to two months to upgrade our internet service.

The lead consultant called with more questions about the BOM import program.

I spent time exporting several of the transaction files today, along with some of the master tables we hadn't discussed. All sent off to the lead consultant. I can only hope he is converting some of them into the new system.


2/26/15 (T-11) VPN...Where Art Though?

Given today's title, you have probably guessed our VPN isn't running yet. HQ's tech guy thinks it is on our end, but we can's seem to get it figured out. I can get around it by running a routing command through CMD on my computer. I guess I can add that to the domain policy until they get it figured out.

A few more questions about the BOM import program. The file our CAD software exports creates a few issues for the import. There is a little inconsistency.

I got two new computers set up today that will be used for training starting tomorrow. Tested some new Windows 8 Tablets today that I plan on deploying to our Quality group after the go live. They move around between the buildings quite often, inspecting production. Having the tablets should make it a little easier for them to document their findings.

The project manager finally released some notes today with tasks that are assigned. The list is fairly incomplete. There are a number of responsibilities that don't seem to be assigned yet.

There were some questions about the data that was provided to the lead consultant. The plant manager asked why I wasn't reviewing the data, looking for incorrect records before dumping  into the new system. I explained to her that it was an initial data dump, to get data into the new system...there is no possible way I could review 3 years of data in such a short time. In my experience, inconsistent  data is generally addressed during training and CRPs. A plan is normally put together to address or clean up data before the final file conversion. She was insistent that I was incorrect and should be reviewing all data before passing it on. The lead consultant jumped into the conversation and let the plant manager know that my understandings were correct. With such a limited time frame to complete  the implementation, there isn't much time to verify all of the data. If it was incorrect in the old system, and couldn't be cleaned up, it will probably be converted that way.

HQ's CFO sent a preliminary GL structure today. He will not have final approval until next Tuesday - two days before the CRP. That doesn't leave much time to map our existing GL to the new structure.

Training starts tomorrow morning. We have an hour with the lead consultant to begin setting up users and roles before we start the BOM training. They have only allocated 2 1/2 hours for training on one of the most important tasks in the system. Knowing that we have struggled with getting accurate BOMs in the old system, I would have expected more concentration on this obvious shortcoming.

I was struggling the last two days to keep up on everything on my plate. Our engineering server went down yesterday. A major portion of yesterday and today was spent getting it back online. Whatever changes HQ's tech guy made to our network for the VPN messed up our DHCP. When trying to setup the new computers and touchpads, I had a hell of a time getting them to join our network. It took a while to figure out that DHCP was coming through the tunnel, and assigning addresses not on our network. Hopefully this is fixed in the morning.

I am not sure what has been done on the lead consultants end. Hopefully, some of the file conversions are in for tomorrow's training.

2/27/2105 (T-10) First Day of Training

The day started off as kind of a mess. Something happened with the VPN setup that caused our internal IP addresses to get mixed up. Any computers that shut down yesterday, have an IP address that isn't on our network. The two new computers I set up for training, our RF Scanners and a couple other computers cannot connect to the network.

We were scheduled to start admin training first thing this morning but getting the network fixed was a higher priority. Our controller took my slot to start GL Integration setup instead.

We moved to the bigger conference room this morning. There was a 20 minute conversation about coffee. Evidently, nobody in the building with the bigger conference room drinks coffee. Several people in our meeting wanted coffee. Why not waste valuable time talking about getting coffee today, and how we would get coffee on Monday.

Our engineering department's training was scheduled for today. The entire department came down to learn how to setup new stock codes and structure Bills of Materials in the new system. The custom program to import BOMs into the system is nearly done. There are a few tweaks to the import program are required after reviewing how it works.

The actual training was a little awkward. We kept getting interrupted trying to get a GoToMeeting setup with remote facility #1. The phone connection would drop, and we would have to stop what we were doing to fix the connection. We spent 2 1/2 hours watching the lead consultant go through the screens and demonstrate about half of what is currently used in our current system. Everyone was released to go work on the two training computers plus the plant manager's laptop.

After about 20 minutes, we realized that nobody knew navigation in the system at all. Simple things like finding and saving records weren't even covered during the training. I addressed this with the lead consultant and he was apologetic. He thought the system was more intuitive than it was to anyone that hadn't used it yet.

After lunch, purchasing came in for their training. The consultant took my advice and broke for hands on training after every small session of training. He was sure to cover navigation with the buyers. We went over simple items like setting up vendors and manual purchase order entry. It seemed to go pretty well for the time allotted. Let's hope they don't forget what they learned by go live date.

After purchasing was done with their training, the lead consultant and I had a brief discussion about file conversions. He wanted to make sure that he had all of the required files. There were a few of them left off the list, and he had questions about the files that were already sent to him. We reviewed a few of the files together to define fields in question.

The fax, email and barcode software were received. There was discussion about how to set it up. Since it is being hosted on HQ's servers, should they be supplying an outgoing fax number and line? Which outgoing email server should be used? How are we to map the zebra printers across the VPN to print correctly? Those are items we will work on next week.

3/1/2015 (T-8) Sunday - Fun Day

I started to get emails at about 8 o'clock last night from the lead consultant about some of the files in the initial data dump. I responded to him that I was busy at dinner with some friends, and would have to review with him the next day.

The plant manager sent me a text message desperately wanting to get into the new system from her laptop. I set it up for her to connect through the VPN on Friday. It took about an hour to troubleshoot. Ended up that she just needed to reboot her computer. I see some future issues with troubleshooting this connection methodology.

I set up some cross reference files for the lead consultant to make it easier for him during the file conversions. He seemed content with the new data exported. There were a few more questions about how to identify things from our current system that he needs in the new system. Funny thing is that it was data I have been requesting to have populated in our current system over the past year. I could not provide a complete data set for him, since it wasn't a priority to provide that data for me in the past. The plant manager will (now) make sure that data is populated - since it is a priority to get the new system running.

3/2/2015 (T-7) Finally...Some Help!

I had been looking for some help with IT for about 8 months. I finally got approval about 2 months ago to hire someone. The first guy that we offered the job to, rejected the offer immediately and stated he wasn't interested. We had to start the interview process over again. We finally found someone that seems like he can do a great job, with some additional training. He was offered the job over two weeks ago and accepted right away. We had to wait for him to serve out his final two weeks at his current employment, before he could start with us. Today is the day he starts. Just in time as far as I am concerned. With all of these computers needing set up on the new system and 2 weeks of me trying to sit in all all of the new system's meetings, IT has been falling behind.

We didn't get started with training until 8:45 this morning. We started with AP. The training went fairly well since one of the ladies doing AP was in the PO training this past Friday.She created a few purchase orders while the lead consultant did some setups. The POs were receipted and training pursued on invoice posting. There was a breakout session which allowed the ladies to practicing posting invoices. It was pretty straight forward. One of the things that made the training fairly easy was the fact that the new system has what they call Workbenches. Most of the tasks are tabbed on the same screen. You can go from a Customer tab, to a 'GRN' (Goods Received Note (unvouchered receipts)) tab, to an invoice posting tab (or post an invoice from the GRN tab), and also a custom links tab (you can setup links in the same window to any other programs the user might need). It is a cool concept to make navigation a little easier.

After invoice posting, we went into AP Checks. Very typical processes for posting checks. There were a few concerns about the way checks were voided if they didn't print correctly. The users also wanted to see a running total of all checks they released for payment - without having to run a payment report or trial check run. The screen will be modified and programming done to add this functionality.

AR invoicing and payment posting training took about an hour and a half and ran through lunch. A few more requests for modifications to accommodate our current processes.  It seems that the lead consultant just can't say no. He might be losing sight of the fact that we are now less that 7 calendar days until go live.

We broke for about an hour to allow the lead consultant to get some more system setups and modifications completed for the next session. Nobody though it was important to let me know that they were resuming training. I got the new IT guy setup on his computer and walked him around to introduce him to some employees in the office. I went back to the conference room to see when they were going to start the next round of training. It had already begun.

Production supervisor training was underway. The new software has an easy interface to graphically show where a product is in the production process. It requires the supervisors to log in and update when production started for the 'Parent Job' as well as when it is completed. It color codes the milestone operation for the job (which is setup in a cross tab type screen) to allow a quick visual of the status of all of production, based on which production line you want to view.

We then went through time tracking in the system. Basically, how an employee logs into jobs to post labor. The user has to enter their employee number, production line, work center and the specific job they are working on. It is similar to the system we are currently using. We then reviewed the supervisor's responsibility to audit and approve their employee's times. One issue we have had with our current system is that the plant manager thought it took too much time for the supervisors to approve employee's times, since they were inaccurate logging into correct jobs and operations. Now, it seems that she has made it a priority to instill that discipline into employees. Not sure why it wasn't a priority before. It is funny how that works. She now expects the supervisors to have all time 100% accurate and the production line updated before the morning production meeting - every single day.

Somehow, we fit in 2 hours of training for HR to maintain employee records. We are switching to 'actual rates' for employees in the new system, rather than a standard rate (which we currently use). HR will be responsible for maintaining the employee wages in the new system, as well as the payroll system. Updating employee records by HR will just be an additional evil required to change the costing method for labor in the new system.

There was some friction  about some functionality that isn't readily available in the new system. There is need to have modifications/additions needed to add that functionality as soon as possible. The lead consultant is showing his exhaustion from working so many hours converting files, setting up the system and making modifications. He is growing a little irritated by criticism and further requests.

One rather large issue with the program is setting up tables for things like terms, reasons, codes...You can't maintain any of those tables from any of the normal user screens. You have to go into a table setup program, and hopefully know the name of the table you are wanting to set up. It is a little archaic, especially when you are new to the system.

I sent a report to the team last week to review current inventory costs and last cost paid (we are using average costing method currently and are switching to standard costs in the new system). There was a brief discussion about some initial analysis that was performed by the cost accountant (project manager for the new system). She is just recommending we transfer the average cost as the standard cost in the new system, even though she has complained that our current costs aren't accurate in our current system. Why would you transfer costs and value your inventory at a cost you don't think is accurate? I suggested using the 'last price paid', which should be as accurate as our current purchasing process.

The VPN still isn't working correctly. I sent out a nastygram to HQ's tech guy and our consulting company to get this fixed immediately. This was a concern for me from the beginning. It was dismissed by the plant manager and HQ VP as being a minor issue that would take an hour to get set up. I can't make any work arounds fix the fact that the VPN is down for any of the terminal users (at least not easily).

It seems that while 'costing out the system', some major details were left out. Since the software is sold by the seat, rather than using concurrent licensing, 1/3 of the users were overlooked during quoting and contract signing. The plant manager had years of experience working with this new system, and knows our processes and users well enough to know who would be using it. The lead consultant was an integral part of quoting the new system to us. How could more than 30% of the cost of licensing be overlooked? I was not involved in the system, or due diligence on costing would have certainly been performed. The only benefit of the licensing structure is that they allow 1 license per named user, and all of the shop floor computers will share 1 license (currently 17 computers). We have added all 7 of the engineers, two HR users, 8 production supervisors and managers and two other users that never used the old system. Although I am not privy to the cost of the system, I cannot imagine that is an inexpensive mistake. There were also 2 add on integration (3rd party) pieces of software that were not initially quoted. Those were purchased last week and installation is due this week (email, fax and barcode printing).

It is 10:30 pm now. I have to quit posting for the day to go and dump 4 more files the consultant sent me today, for Wednesday's training session.

3/3/2015 (T-6) CHA-CHING!!

We purchased licensing for 25 users. We have at least 42 users (at last count). We have 24 user licenses in our current system that are shared between our facility and remote #1. One of the selling points of the new software was that all of the production employees could use one license (since the licenses are sold as 'named users'.

We got off to a late start today. The lead consultant was working on some of the system setups until about 10:30 am. I had asked late last night that we go visit the lady that puts our BOMs into the system to test the BOM import program. She had exported a number of Bills from our CAD software yesterday in anticipation of getting the bills into the new system. It was decided yesterday by the plant.manager that we would not pull over any of the existing BOMs out of the current system because they were deemed too inaccurate. We have been using the same process for over a year to import BOM into the system from CAD. I wonder how the new bills are going to be more accurate than the records that could have been converted.

An attempt was made to import one of our master models that was released by engineering yesterday. The import program blew up. The lead consultant spent about half an hour troubleshooting, then had to stop to head to training the controller on some more tasks.

About an hour and a half was spent attempting to make the controller more comfortable in the new system. It was quality training, concentrating on navigating through the system, knowing how to perform specific tasks and answering process questions.

We returned to the engineering department to check in on the BOM import program. About 30 more minutes were spent troubleshooting. One of the issues was discovered. A potential workaround was given along with direction to try to import some smaller sub-assemblies. She emailed me about 2 hours later letting me know that she was successful in getting 4 small assemblies imported, then it failed on the next several she worked on. She gave up and left work...knowing we couldn't get back to her until tomorrow (maybe).

We spent a great deal of the afternoon training for parts sales, warranty, service and repairs. One of the sales people used the new system in the past. He also came from our competitor. He was requesting to change several of our processes to match the way he was used to working at his previous employment. He indicated how much easier it would be in the new system to do it with the requested changes. Some of them were logical and easy enough to change processes. Some of the requests would require a significant amount of time to implement. Many of the discussions were tabled.

We walked through several different types of transactions...in theory. The system wasn't adequately set up to be able to complete several of the transactions. None of the data had been converted from the current system, so performing queries, looking at reports and basic navigation was severely hindered. Reminiscing about the 'good old days' became a higher priority than further training.

The day was wrapped up with about 15 minutes of administrative training. I finally learned the programs required to set up users, user roles and custom menus. The plant manager indicated that she would help with a majority of that setup, since the admin programs are far from intuitive. You have to know the program names to enter them into the archaic  setup programs.

I was notified that the VPN was working. I tried to set up a new computer to access the software and discovered the port was blocked by the firewall. I was notified it was fixed again. After testing again, discovered we were receiving certificate errors. The new issue is being addressed. We may have to get tech support from Oracle to help fix this issue.

I am pretty sure this was a major concern for me during the kick off meeting, but was dismissed because it should only take an hour to set up a VPN. I am not quite sure when an hour was redefined to be such a long stretch of time. I guess we do still have 6 days before go live, as  well as a work around to bypass our firewall.

3/4/2015 (T-5) Forget Accountability

After grossly underestimating the number of users required for the new system, the decision was made today to consolidate (share) some of the user accounts. That is great except for the fact that two users, using the same account, you lose accountability of who did what.

The BOM import program isn't working. The BOM specialist spent hours preparing the data, only to watch it all disappear. The lead consultant spent some time working on the program, and thought he had it fixed. We found out a few hours later, that the problem is intermittent, and data was lost 2 more times before the end of the day.

The consultant wasn't available until after lunch for any training today. It was decided to put off the Conference Room Pilot until Friday. Most of the afternoon was used to set up miscellaneous tables, users, user roles and permissions.

We had to re-script some of the data files. They didn't come over correctly and caused some issues when running through a couple of the programs.

The decision was made today not to bring over any of the BOMs out of our current system. Almost 4 years of data not converted because of concerns of accuracy. There are over 14,000 manufactured parts in our current system with structure. None of that data will make it into the new system. The plant manager's theory is that if the data is needed, it will be structured at that time.

3/5/2015 (T-4) CHA-CHING!!

A late start again today. One of the lead consultant's other client's had some issues running MRP (just so happens it was our plant manager's old company).

Our controller spent some time with the lead consultant to try to better understand the GL transactions in the new system. She is extremely nervous about the implementation. The goal was to make her more comfortable before the Conference Room Pilot.

I asked the other consultant onsite to create some documents to assist users in navigating through the system. Many of them couldn't perform simple tasks like look ups, saving records, or finding the correct programs to do their jobs. He copied some of the data out of the help files that was barely useful.

There were miscellaneous tasks throughout the rest of the afternoon. I had to step out to begin setting up computers and fixing miscellaneous issues that have been building up.


3/6/2015 (T-3) Data Validation? What's That?

Do you want to know what is scarier than trying to implement an ERP system in less than 30 days? How about doing it without any real validation of the data that was converted?

Today was the Conference Room Pilot. You remember me talking about that a couple of weeks ago. A CRP is generally the time that you run through all of your processes to make sure they work, document what doesn't and review the data to make sure the converted data looks accurate.

What did we do for our CRP?

We had our HR department come into the conference room and add an employee. Then asked them to leave immediately afterward because there was a line of people out in the hallway, waiting to come and perform their transactions.

Inside sales person...enter a sales order for a finished parts...get out!

ABOM guy....create a new part number for the above sales order, then copy the BOM from an existing part. Get Out!

One buyer put in a PO for one of the parts on the above BOM. Get Out!

The warehouse manager receipted the part from the above PO...you get the idea.

AP posted an invoice for the above receipt. There was no time to simulate check writing.

An supervisor simulated an employee logging time against a job. There was a half hour delay since employees were not set up correctly.

AR invoiced the original sales order from above, then simulated a cash receipt.

The controller then went through to see if the transactions hit the GL correctly. There were quite a few adjustments with the integration to try to get them to go to the correct accounts.

I finally got a chance to spend about 20 minutes with one of the consultants (one of the other seasoned consultants was onsite today). He had a little time to teach me some navigation tricks and administrative tasks.

I spent the remainder of the day confirming all of the office computers could connect to the programs through the VPN, then began the final data dump after everyone else was done for the day.



3/7/2015 (T-2) Saturday Clean-up

I was awakened by our BOM specialist. The custom program for importing BOMs into the system crashed on her again today, after spending 3.5 hours manipulating the data. She was livid! After a quick conversation with the lead consultant, I was on my way to the office. He was making this import program a top priority for the day.

There was some tweaking of data for a good part of the day. I sent over trial balances from each of our modules for the lead consultant to review, and confirm accurate totals in the new system.

There were three computers on the shop floor that would not launch the new program. I went back through all of the requirements, unloaded and reconfigured the machines, then reloaded. After 4 times doing the same thing, and working with one of the support guys from the new company...still no luck. I spent the next 4 hours playing with it, and finally figured out that it was a problem with Java. I was able to work around the issue and get them to work.

The BOM specialist stopped by before she left to let me know that she didn't have much success putting in bills today. The plant manager's request on Wednesday was to have all 18 of the BOM (for products currently in production), in the new system by Saturday afternoon. Only 1 BOM was successfully uploaded when I left today.

3/8/2015 (T-1) This Is Gonna Be Easy

So, the day before the much anticipated go live. I spent a couple of hours emailing three different consultants some last minute information. Our label printer is not set up yet for inventory transactions (PO Receipts) - nor is the label itself. The lead consultant asked for a little more information about a couple of files that were being converted.

I spoke to the lead consultant and ask if there was anything else that I could help with. I know he had to tie out the totals from each of the files to ensure all of the data was converted correctly. He indicated that he had it under control. Guess I will just remain on standby for the day.

3/9/2015 (T-0) D-Day

I got to work a couple of hours earlier than normal this morning. I had one more computer to configure to allow employees to 'clock' into  the new system. I finished configuring and went to set it up. After it was set up, I stayed back to see how everything went with the first employees using the new system. At 6:59 am, 80% of the employees were streaming through the door. The start time for these employees is 7:00 am. Many of them complained they did not have time to clock into the new system because it would make them late for work.

I walked around the plant and explained to everyone that there were well defined work instructions for the attendance and labor logging at each of the work stations (this included pictures of screens, arrows and numbered -detailed instructions). How many times today do you think I had to read the instructions to employees and supervisors? All of the questions I was asked, were described in detail in my instructions (still including pictures). I am sure glad I spent an hour of my Saturday writing up instructions nobody would bother to read.

At 7:30, I was informed the AP balances between the two systems was about $5,000 off. No big deal. One of the invoices probably did not come over correctly. There were only about 600 open AP invoices, it should be easy to find the issue.

Then, the controller arrived...

AP was actually about $80,000 off. AR was $110, 000 off. Inventory was $200,000+ off. WIP was yet to be determined. To say she was surprised by the results would be an absolute understatement.

Ok...nobody post any transactions yet.

No need to stress out about it...right?  I downloaded the details from both systems for AP, wrote a quick program to compare the balances between the two, and identified the issue. During the conversion, the lead consultant didn't convert credit notes. No big deal, he still had the data files. It took him about 15 minutes to append the data and fix the AP balances. AP - you can now begin posting invoices.

Somehow, more than half of the people that changed their passwords last week, forgot their passwords. I guess I wasn't doing anything else...let me reset those for you.

Nobody can print now. What the hell? It seems that the new software uses a pop up window from the browser to launch Adobe to print. Pop up blockers are still enabled in the browsers. Not a big deal - it is a quick fix. Now, more and more people can't print. How could that be? That was the new IT guy's only job on Friday - make sure every computer has the shortcut for the new system, update java and change security settings. I had to go change settings on every computer in the place.

Ok, time to work on AR balances and identify differences. It was actually another simple fix. Some of the data wasn't added to the new system during the conversion. Lead consultant added the missing data, now we are only $250 off. Unacceptable! We found the invoice that was in question. Seems that 3 years ago, someone deleted the invoice from our existing (now old) system, but didn't delete the details from the database. Simple fix. Surprised it was never caught before today, but that is beside the point now.

Nobody trained the receiving guy how to use the new system. I guess I am doing nothing else...let me do it. Let me remind you that the theory was to 'train the trainer'. The department managers were all trained, and were expected to train their employees. I am not sure when they would have had time to do that. Each only had 4 hours (at best) of training. They were still responsible for performing their daily tasks, and didn't find time to train their employees.

While I am back there, let me train the lady that does all of the inventory transactions. She now has 5 times the amount of work. We previously had RF scanners for all of the warehouse employees and water spiders. They would transfer or issue their own parts. There is currently no barcode scanning in the new system. The employees are to write down their transactions now, and the inventory transactions will be manually entered by one person.

Inventory was easy to figure out. We had multiple warehouses in our old system, with different costs for several of the parts -in the different warehouses. The consultant just took the last cost in the file for each part, and assigned across the board. Once that was identified, it was fixed rather quickly.

One of the key guys from remote facility #1 showed up to get some exposure to the new system. He will spend a few hours with everyone throughout the week. He got a tour, then had to do some work for his normal job. Somehow, parts of our existing system aren't working correctly. He can't print anything. I will work on that tonight...I wasn't planning on sleeping much tonight anyway.

Labor posting was down the entire day. There were some things missed during set up. The plant manager and the lead consultant were working on this throughout the day. Maybe it will work tomorrow.

Some of the HR data wasn't converted correctly. Employee numbers were swapped somehow during the conversion. Employees couldn't use the attendance module to clock in. HR is reviewing and fixing throughout the day. While I am back there explaining what needs to be done, I might as well train them again. They can't remember how they added an employee on Friday.

The warehouse employees and manager were beside themselves throughout the day. There was a consultant assigned to them, but they were having lots of issues. They could not figure out which transactions to use in the system to perform simple tasks. They were validating their transactions after performing each one, and couldn't find the transactions posting correctly. There were some frazzled and frustrating looks on all of their faces by the time they left.

The controller still had some major concerns at the end of the day. Cashbook was not loaded, GL transactions and balances weren't converted. WIP values still needed to be balanced. I told her she needed to just get out of there and have some wine and relax. It really wasn't doing her any good to sit around the office and stress about stuff she had no control over.

At some point during the past 30 days, someone made the decision that accounting wouldn't be performed in the new system for the first month. I guess this decision was made without the controller's input. She was anticipating (as was I), that everything would be done in the new system on 'D-Day'. Now, she is stuck going between the two systems for the entire month, unless I can work with the lead consultant to get everything set up this week.

Good news!! The BOM specialist was able to get 4 finished product's BOMs into the new system today. It appears that the new program intended to import the bills from our CAD system, is working -for now.

Fortunately, I have been through a few implementations in my career. I knew what to expect by what I saw during the past month. I was removed from the user's stresses, since I didn't fall for the 'everything will be fine' propaganda.

Tomorrow is another day! Hopefully there will be progressive improvements throughout the week. The lead consultant will be out of pocket for the next several weeks. If something major goes wrong after this week, it could be detrimental to the project. Do you remember from the beginning of this blog what the biggest challenges were with our old system? Poor implementation and training, which led to bad data and poor practices to circumvent the system.

3/10/2015 (T+1) How Do I do That Again?

There are quite a few outstanding issues. The lead consultant and the plant manager spent the day in the conference room updating data and fixing programming bugs. I spent the day running from desk to desk answering questions about how to perform transactions in the new system.

Simple warehouse transactions turned out to not be so simple. Transactions either posted more than one time or not at all. Lots of confusion about new programs written for the warehouse as well as some standard inventory transactions not hitting inventory correctly. Warehouse pickers aren't using their scanners anymore as they were in the old system. Using the new pick list program written for us, the warehouse manager was issuing parts that were picked in the old system. Basically, doubling transactions because the system didn't take into account parts that were already issued. Prior WIP transactions were converted, but were not taken into consideration with the new program.

The BOM import program seems to be working fine now. The first few imports were a mess and didn't import correctly. Those are being deleted and reimported after a few days of causing confusion for the warehouse. The BOM specialist can actually put in BOMs 50% faster than she could in the old system.

Routings were somehow lost to allow shop floor employees to log time to open jobs. These were fixed, and crashed again. The consultant is continually working on this as a top priority.

All of the old purchase orders that were put in for outside processing have to be modified to work with the new system. Fortunately, the warehouse had one come in today, and couldn't receipt it correctly. I had one of the consultants walk through the system with me to show me what needed to be done to work correctly. After working with purchasing to modify the purchase order, we went to the warehouse to receipt the PO. The Parts on the PO receipted correctly. I tried to validate that the transferred parts were then issued correctly, and they were not. I had to manually take the components out of inventory manually. The consultant is working on the program to see why it didn't work correctly. No answer on wether or not he got it working correctly. I will try again tomorrow.

Some of the employees still need to run reports out of the old system. Remote facility #1 is still using the old system. Printing isn't working in the old system now. It took a few hours to figure out that the old system uses a different version of java to run the reporting feature, than the new system uses. I was able to figure out a temporary workaround. Fortunately, there are only a few users working on both systems at the same time. This impact is minimal in the entire scope of the projects.

None of the part sales, service sales or warranty information was brought over in the conversion. It was deemed more efficient to manually enter those items by hand.

Permissions seem to be an issue. There  really is no clearly defined way to set permissions in the system, unless you know every program required to perform a transaction. Unfortunately, I am not that familiar with all 900+ screens and programs to identify when each of these will be called. For now, the users are emailing the plant manager and myself every time they get an access denied error. We are dealing with these, one at a time. That affects the menu structures we started off trying to organize. I will have to do clean up on the permissions and roles in the next few months.

One of the guys from remote facility #1 came in to see the new system, and work with users to figure out how they will implement on May 1. It appears they only get 30 days to implement the system at their facility as well. He is a little taken back as to why we are switching systems. They were able to fully utilize the old system and run MRP effectively. I had the opportunity to set them up from scratch about a year and a half ago. They were trained correctly, and entered all of the required information into the old system correctly. The visitor was an integral part of getting the old system in place correctly. He is correctly using the system, and is reluctant as to why he should change systems when the current system works so well for them.

All of the data transfers are still being scrutinized by the controller. Most accounts aren't balancing correctly. We did get AP and AR corrected.

We are going to work on cash book over the next couple of days, then discuss how to get GL information into the new system. Someone made the decision that performing February's month end in the old system, then carry over numbers. The accountant was planning on using the new system from day one, and performing the previous month's closing in the new system. We will work through this process throughout the week to get it straightened out.

WIP hours and issued materials are being audited. The lead consultant made some incorrect assumptions when converting the data. These issues would normally get caught during an adequate CRP. Since ours was rushed and had minimal data loaded, this will probably be ongoing...through the month.

Training is a huge issue. I am still running around trying to help figure out how to perform all of the transactions in the new system. Seems that 4 hours of training per department wasn't enough to adequately instill proper procedures into each of the users.

3/11/2015 (T+2) Training...Training...Training!!!

Inadequate training = incorrect data input. Each of the users are doing their best to do their jobs. Problem is that they are still stumbling through the system, trying to get their jobs done. If it wasn't covered in their 4 hours of training, they are doing their best to figure out how to perform the tasks in the new system. I had quite a bit of exposure to the system, and have years of experience performing all of these types of transactions in different systems. I have been doing my best to help the users navigate through the program correctly. I am working with the consultants to make sure that my assumptions are correct while trying to show the employees. A few of my assumptions have been incorrect, and we have worked through them.

Our shop floor computers are running kind of slow. Doing some testing to figure out why. Employees are taking up to a full minute to record their time, and log out for the day. We have a couple hundred employees and 14 computers for them to use. Imagine being at the end of your shift - wanting to go home - and waiting in line while other employees are slowly logging out for the day. A few of the employees decided they are not waiting to log out, since they are on their own time. They aren't getting paid overtime to log out, so they just go home.

The plant manager and production managers are keeping steady pressure on the floor supervisors to make sure labor is bring recorded properly. This is something that was absent in the old system, which caused inaccurate data to be processed daily.

Many employees did not make the short list to be users in the new system...since we only purchased the 25 licenses, and haven't negotiated more licenses yet. I have had to forward requests to the plant manager to see how she wants them handled. There is no enforcement of the number of licenses being used in the new system, so, I think we are just adding additional users for now. Maybe they will negotiate this later?

GL and Cash Book are still being worked on. Inventory and WIP balances are still being worked on. NOt sure of the ETA of having this completed.

I have had to export additional information for the lead consultant to populate data in the new system. The lead consultant mistakenly converted some of the data from the first data dump. New data was sent, after the CRP, but some of the data was not properly identified. It is an honest, easy mistake, but really slows production when it has to be reimported. It seems that every time the files are updated, something else crashes. It causes some of the master tables being incompletely populated because of additional data.

Employees were not able to report labor correctly again for a few hours. Some changes were made to the system last night, and wiped out details that were loaded yesterday. The lead consultant had to run back through and update much of the WIP data again to get the module working.

Some modifications were made to allow the receiving guy print labels correctly. By default, the program was setup to print one label for each part that was received on a PO. Sometimes, there are 30-40 boxes per receipt, and all of them need to be labeled to identify parts correctly in the warehouse. We hope to have the modification completed tomorrow. The receiver is currently hand writing labels with the part number, description and PO number, just to be able to put parts away.

I have to spend more time testing the outside processing purchase orders. We had more products come in today that fit the role of subcontract or outside processing. After converting the PO and receipting, consigned material was not issued correctly again. Manual inventory transactions were made to compensate for parts not being relieved correctly.

3/12/2015 (T+3) New Issues or Unresolved Issues

The day was filled with issues again. As the users begin doing more of their daily transactions, more issues arise. Some of them were issues for the past 3 days, some are new issues that need to be addressed.

Most users feel overwhelmed because they are behind for the week. Trying to manage their daily tasks in unfamiliar territory has been taking a toll on users' patience. Some tasks that were assigned to users have not been kept up on, since they are already overwhelmed. We are waiting for the weekend to come and give everyone a break. Hopefully after a couple of days off, the users come back more comfortable with the system.

Training and data conversion accuracy is still eating away at moral. This doesn't come as a surprise to those of us that knew what to expect. The only way to deal with these issues is to keep pushing forward and mandating the work is performed as correctly as possible.

Purchasing is still manually managing purchase orders. It was expected that they would be using MRP to order, from day one. Although it was an unrealistic goal, everyone seems to be surprised that it doesn't work that way. With BOMs still being loaded into the system, and engineering still behind on releasing complete designs, expecting to use MRP is absurd.

Inventory control is far from being controlled at this point. The warehouse manager is constantly auditing data from the day before, trying to identify issues. There have been several inventory transactions that didn't flow through the system as expected. We need to get these issues fixed quickly, and start planning on performing a physical inventory to help identify additional inaccurate transactions. I am not looking forward to performing a cycle count! When I started at the company, a physical inventory took 3 or more days to complete. I implemented RF scanning a few months after I arrived, and it brought the process down to just about 1 day. The new system doesn't have a scanning solution, so I am afraid it will be a minimum of 3 days of inventory again.

User permissions are an ongoing issue. Hopefully, after another week or two of users performing all of their tasks in the new system, we will have worked out permission issues. Navigation is still an issue because of the sloppy way we are keeping up with permissions. I have been working with the users to organize their own menus, using the 'Favorites' function in the system. They are setting up their own folders under favorites, then structuring a custom menu to help them find their programs easier.

Our engineers are still keeping excel spreadsheets of Advanced BOMs. They are not making entering the information in the new system a priority. That leaves us in the same predicament we were previously facing. Inaccurate, nonupdated information in the new system, leaves the same results we had in the old system.

The warehouse manager has noticed some BOMs not uploading correctly. She has been trying to 'code' parts in the system, based on point of use in production. She concentrates on purchased parts from her warehouse for coding parts. She sets up 'kits' that warehouse employees pick, just before they are needed in production. Some of the Bills are being loaded as flattened BOMs, rather than multi level boms. Somehow, that is messing up her ability to code the kits correctly, print the pick lists for the warehouse employees, and kit issuing (backflushing) parts correctly as they leave the warehouse and go into WIP.

We are facing similar issues in the new system, as they existing in the old system. Engineering currently cannot get ahead of production with releasing designs and complete BOMs. Jobs are already created in the new system, and Bills aren't being added to the jobs, since BOMs are released after the jobs are created and started.

Accounting balances are still not complete. The controller released numbers for cash book, as well as un-reconciled check information from the bank. This should be updated in the new system today. The controller plans on cutting AP checks tomorrow, but won't do it until the cash is stated correctly. We still have not tackled the GL conversion decisions.

The lead consultant won't be in tomorrow, or for the next 3 weeks. He is involved in another implementation, and will be out of pocket for a while. This is a scary thought based on the amount of work he has had to perform every day to fix issues. I think he is working a minimum of 12 hours per day trying to keep up. With him being unavailable for a few weeks, I am not sure that unresolved and new issues are going to be addressed in a timely fashion. That is going to result in people circumventing the system and entering incorrect data...just to get their jobs done. Based on the background I provided at the beginning of this blog, that puts us in the same predicament we were faced with over a year and a half ago.

I will do my best to begin documenting procedures and transactions in the new system. I will start with the most troubled users, to try to create some training and procedural documents. Hopefully, by having documentation, it will help answer user  questions and help with data accuracy. It will take a couple of weeks to document a few of the more critical operations. I wish we would have had more time before go live. I would have created these documents for reference before the users hit the levels of frustration they are currently facing.

We have several more modules to implement. I am not sure if a plan was put into place for implementing these modules. I am not sure if the plant manager knows enough about these additional tasks to start implementing, or if we have to wait for the lead consultant to return. One of the issues with waiting on the lead consultant is that remote facility #1 is currently scheduled to go live on 5/1. With the lead consultant being out for 3 weeks, and remote facility #1 supposed to go live 28 days later, does that leave any time to address current support and future module implementation?

3-4 months after remote facility #1, two of the other facilities are supposed to go live. I was told they are waiting to see how our facility is doing on the new system, before they make the decision of going live. Their implementations are going to be more involved than ours. Our facility has only been around for 4 years. The other plants have been active for more than 20 years. There is still talk of consolidating our part numbers, vendor accounts and customer accounts. That means retraining at our facility, converting more of our data to match the new consolidated master records and establishing new procedures. That also means much larger record sets to be converted for the other facilities.

The slow shop floor programs are still undergoing testing. We haven't identified why the screens are taking so long to repopulate after entering data. I hope to have those issues identified tomorrow and hopefully fixed over the weekend.

I will be spending the majority of my day tomorrow working with the part sales/warranty department. None of the pricing rules have been set up in the new system yet. Entering orders, jobs and purchase orders have proven to be difficult for the one user managing the department. Training for these tasks was minimal, since most of the training time was spent discussing potential improvements and theories by the outside sales rep. I may have to try to figure out how to set up the pricing rules tomorrow, since the lead consultant is out.

My biggest issue with the new system is still navigation. I know this will get better with time. I am sure I will become more familiar with the programs, and find what I need. The problem is that I have been trying to figure this all out as we go, which creates a fairly slow pace while I try to find the programs, establish a procedure and test my assumptions before deploying. It is difficult transitioning from a system I used for almost 20 years, to one I have only seen for the past 30 days. Testing theories in the old system was very timely, since I knew where everything was, and could create custom reports directly from the database. I don't have access to the database to track transactions or create custom reports. All of these types of transactions have to flow through the consultants. We are also limited by the fact that only one consultant for the new system seems to know all of the transactions and data well. There is one other consultant that can perform many of the same tasks, but not nearly as efficiently as the lead consultant.

As of now, I would say that the core modules (Sales Orders, Purchase Orders, Inventory and WIP) are (at best) 70% implemented. Bills of materials are minimally implemented at this time, since we didn't convert bills from the old system. Accounting is possibly 20% implemented - only because GL integration and chart of accounts seem to be set up. Seeing as we are still trying to tie out balances, cash book isn't loaded, GL balances haven't been converted and no GL entries have been  made, 20% seems reasonable.

We still have to set up quality control modules, MRP, part sales and warranty, return to vendor, job processing, verify inventory transactions, set up cycle counts, set up ABC analysis, establish rules for raw materials, test the fax/email system, update standard costs (we carried over our average costs from the old system and just called them our new standard costs), train on using the CRM module, and start the documentation process.

I am not sure how to rate the overall success of the 30 day implementation. I am not sure what is in store for our company in the coming weeks without the lead consultant being onsite. I do know that the plant manager has convinced the owner of the company how well the software is working. I am not sure I agree that it is working well based on all of the information I have posted in this blog. I do know that there is potential in using the new software to run the company. I am also sure that if the same efforts were put into the old system, we would have reached our goals much faster than we can in the new system.

So, now there are some personal decisions for me to make. Am I willing to stick around and become an expert on the new software or go with what is familiar to me - and find a different job where the old software is being utilized? Is my current employment going to keep me onsite trying to finish implementing the new system completely? Will I work as a corporate expert of the new system over time? Will my current employer keep me around after remote facility #1 gets all of their data converted?

I will continue this blog as needed. I am planning on weekly updates, rather than daily updates. I have tried to be as fair as I could be while recording the events of this implementation. I am sure that my bias and personal opinions have shown at times during this implementation. It has been somewhat difficult for me to sit back and just support the implementation. I have always taken a much more active role during software implementations. There were quite a few things that could have been done better, but I am not sure if they could have been done better with such a short timeline. There have been lots of proposed changes. There are quite a few tasks  yet to be completed.

I at least hope that the information provided in this blog offers valuable information for the readers. I have personally learned from the last 30 days. As I said from the beginning, this was not my project to succeed nor fail at...I was only there to support the lead consultant and plant manager to the best of my ability. I am sure I held up my end of the bargain. I hope that at some point, we are able to reach the company's goals and better manage finances, production, inventory and purchasing. I hope that such rash decisions on an aggressive implementation does not negatively affect the company.