Hey All,
We are getting ready to undergo a needs analysis for an MRP + ERP to upgrade our system and I was curious what people are using out there are what their experiences have been with the products. I would also like to hear about your experiences regarding the implementation. We are thinking about going with the MRP first then getting an ERP system that intregrates with the system due to cost/bandwidth issues plus the fact that the MRP system is a higher need right now.
Thanks,
Mark
What you are proposing is not uncommon but does have unique challenges to consider. Two important items to keep in mind are eventual integration between MRP and Finance, and Finance needs from MRP. Both are important, and should require financial involvement now even if manufacturing goes forward on their own.
Integration will be (is?) critical – and your statement indicates this is desirable. Given this you will need to do at least a cursory review of your financial system options related to the manufacturing system and the available integration with these systems. On the open market integration can mean anything from moving a few bits of data back and forth by spreadsheet load to full end to end ERP. A written definition for what integration means (for example: one version of truth, platform compatibility for consolidated reporting, robust auditable integration points) will be important. Considering the value of integration is also important (for example: audit transparency, information velocity and accuracy, personnel efficiency) would also help you understand if the perceived cost benefit trade-off really exists given the extra work required to make separate system function in your organization.
Financial requirements in the MRP system are also critical – and are often ignored when people make the decision to have these functional groups proceed separately. MRP would usually include sales operations support (sales orders, shipments, possibly invoices and credit
Bob Scarborough / Tensoft, Inc.
Mark
Bob's note has some good points of wisdom. Here are a few upfront pointers that I see as very important before you get tactical:
1. Does your company have people who know how to define their functional/ business requirements for a software selection package? If Yes, can they be released from significant day duties to work on this project? If not, hire someone who has the experience. Hire them as an employee, or engage a consultant, but avoid the temptation to "do this myself, it must be easy" if in fact it's new to you or your colleagues. It's a project, so it must be managed as a project, not as "another task that gets attention now and then."
2. Pay attention to understanding what you need in future. Don't define requirements only in terms of what you do today; e.g. you may be domestic now, but could you be in other countries soon and need foreign language capability (e.g. multi language names for products?). An ounce of selection is worth a pound of implementation is what I say to clients.
Regards
Len Green
TSI
www.transforming.com
Hello Len,
I think my original post may have added some confusion. I should have mentioned the needs analysis was going to be with a consultant. Here are my answers:
1. No. We know we would need an outsider with the experience and bandwidth to do this. We understand this isn't something we can whip up overnight. The problem we have had is trying to find a consultant or someone with these skills who can manage such a project. A lot of our processes are poorly documented if they exist and there are processes that will need to be built from the ground up. Knowing this a consultant would be ideal since hiring someone full-time would
2. I am looking at it for what we need in the future. We are going to need multi-national/multi-language/multi-location abilities eventually and I do not rule out the possibly of an IPO.
