While there is an abundance of white papers on “How to Select an Enterprise Resource Planning System,” most articles tend to focus on functionality requirements, technology issues and total cost of ownership. Though it’s obviously important to verify that the product features, platform and price of a system meet the requirements of your organization, it is extremely important to understand that functionality is the only thing that a demo can provide. There are other elements that are impossible to ascertain from a demo or in discussion with the ERP vendor.
Due diligence on the less tangible elements of a vendor’s total solution – such as software quality, ease of implementation and responsiveness of customer support – can only be accomplished by asking other companies that have used or are using the ERP systems being evaluated. Not performing the same level of due diligence in checking references that was performed in examining product functionality invites critical shortcomings to remain hidden until well into the implementation process. By then it may be too late to change.
In short, reference checking is the only source of truth in the ERP selection process for these other key elements that are often overlooked in ERP selection process. Not performing solid due diligence on these items will greatly increase the risk of a bad decision.
Top 5 Critical Factors
When checking references it’s important to ask the right questions. Product functionality questions are mostly resolved during the software demonstration process, so the objective of checking references is to measure the elements of a vendor’s total solution that cannot be reliably validated by the vendor through presentations and software demonstration. The Top 5 are:
Quality of the ERP software
Quality of the vendor’s customer support organization
Time, pain and cost of implementation and data migration
Scalability of the ERP software
ERP vendor’s commitment to your success
Quality of the ERP Software
Obviously, high quality software is an essential requirement in an ERP system. The frequency and severity of software bugs is a critical issue that can impact a company on many levels, from the consistency of financial reporting to the reliability of serial number and lot tracking. Software quality is an issue that cannot be resolved during the sales cycle in a demo or sales presentation. A sales engineer won’t provide a true representation of a system’s quality if they are having problems with a particular release or new product. Product specialists carefully script their demos to work around known issues so they do not come into play.
It’s especially important to gauge the quality of ERP systems that are new to the market or promote the fact that they are built on the latest technology platform. Sales reps will maintain that having the latest technology is a key advantage over a competitor’s more established system, but in many instances new software systems and products developed on emerging technology are unproven and lack market support and real world validation.
Usability is a quality issue that most vendors will claim, but is hard to validate without sitting down and using the software for an extended period of time in a real-world environment. One person’s definition of “user-friendly” can vary wildly from another’s based on the level of experience and simple preferences. If the system has bugs or shortcomings that require “work-arounds,” users will be tasked with performing multiple steps to achieve a routine outcome and will quickly become frustrated with the software.
Investigate the genealogy of the software. Who authored it? How many owners or name changes has it undergone? Was the product developed by the vendor or acquired through a merger or buyout? If the vendor is a reseller, do they have a position of strength with the software developer if needed? Gauging the quality level of a software system is an important consideration, and is an issue that can only be resolved outside the controlled sales environment. Talking to and asking questions of a good cross-section of individuals who are already using the system at their companies will be a good indication of the quality level of a system.
Questions to ask:
Is the product reliable? Does it do what it is supposed to do?
Does the system lock up frequently?
How many bugs are in the system?
Are there any work-arounds that you have to perform and how long have they been known issues?
How many software products does this vendor sell and support – are they focused on ERP?
If the vendor acquired the software:
When did the acquisition occur?
How many other platforms does the vendor sell/support?
If multiple platforms are being sold it may result in customer support and/or development dilution. In addition, you’ll need to fully understand if you will be forced to migrate to a higher level platform as you reach your growth objectives.
I will continue the detailed discussion on the four remaining elements on my next post.
To increase your odds of having a successful CRM deployment, in order to reap the benefits of the CRM system, the three critical success factors are:
Executive support and overview during both the implementation and post go-live
Record and Maintain Data that is accurate and timely
Clear process rules, consistently followed by the sales team
If ANY of these three elements above are not present, at time of CRM launch, you should defer the CRM deployment. Given their criticality, let’s take a closer look at each of these success factors.
Without the executive oversight and support, the company will be fighting an uphill battle with little chance of success, because sales reps will most likely resist using the CRM system for a variety of reasons including:
Input into CRM means less selling time
Some sales reps will lose their ability to “play it very close to the vest”. This will reduce their chances for them to feed their egos by being viewed as heroes, because their ability to close deals that were not forecasted will be greatly diminished
Sales Reps will have little desire be learn the value of a, properly deployed, CRM is to the company and to themselves. If this vision is not embraced by the sales team, CRM will be viewed as nothing more than bureaucracy that management decreed to control the sales team
Data Integrity
One of the most common and frustrating problems encountered with CRM systems is the lack of data integrity. Data integrity issues that typically appear are a) multiple instances of the same company appearing in the database, b) data entered with minimal context or timely content, and 3) data not being maintained.
Multiple instances of the same company occur, because a formal agreed upon a naming convention is not in force. For instance, without a formal agreement, four different accounts (Acme Products, Acme Products, Inc., Acme Products, Inc and Acme Products, Incorporated) might be created for the same company. The system will treat each account as separate and distinct accounts. Sales rep notes, attachments and even account contacts could be scattered across the four accounts. Think of the CRM has an obedient soldier; it will do exactly as instructed. It doesn’t know or even care the four accounts are really the same company. It doesn’t matter to CRM, because you told it, right up front, these accounts are separate and distinct. It is following your instructions perfectly. Good job, Soldier!
If the information is scattered across different accounts, the likelihood a sales rep or management will make an inaccurate assessment of a prospect increases, because they didn’t know important information was recorded in Acme Products instead of Acme Products, Inc. This will probably result in ineffective plans and actions had all the notes been recorded in the one true account.
Just as important, a flawed assessment of the prospect will likely be reached if notes are not recorded accurately with proper appropriate detail or not entered in a timely manner. If a culture of data integrity does not exist, the data will be become stale over time and information that was once accurate, can no longer be relied upon. Data integrity issues will cause users to resist using the system and by definition, the benefits derived from the CRM will be severely diminished.
Clear Process Rules
Management’s ability to interpret the entire sales pipeline, is driven by two variables; the prospects’ location in the sales cycle and the probability an opportunity’s estimated final quote amount to become revenue. The communication of the meaning of these two variable and subsequent enforcement of the application of categorizing the prospect’s location in the pipeline and the manner in which the probability percent is determined, is the only way the sales pipeline will be accurately assessed, across the management team.
As an example, during the CRM implementation process, the company will need to define its sales cycle into steps/stages; i.e. how many steps, in the sales cycle, will there be before the account reaches the opportunity stage? These steps determine the categorization of an account; i.e. at which step, in the sales cycle is the prospect?
The opportunity stage is typically the stage where the total dollar amount of the opportunity, is a variable to forecast revenue. If the likelihood of winning the deal is small, it is up to management to decide if the low probability warrants the account to be categorized as an opportunity. There is no single right answer. It all depends how detailed management wants to monitor and review the account as it marches down the sales cycle path. However, consideration must be taken to account that additional steps in the sales cycle equates to more time the sales rep will have to change the stage and the more categories management will have to review. At some point, too many steps in the sales cycle becomes counterproductive and frustration for the sales rep; less time to sell due to maintaining the accuracy of the stage.
Strict enforcement of the categorization rules are required, else different sales reps will use their own set of rules to determine a prospect’s location in the sales cycle. Different ways to categorize prospects will immediately reduce the assessment accuracy of the pipeline.
Summary
There are many benefits of having a successful CRM system deployed, but unless close attention is paid to the three key success factors, it will likely result being an expensive failure with consequences for those leading the project.
An old axiom in sales is that it is much easier to keep an existing customer than it is to acquire a new customer. From a top level perspective, an installed base customer has value for so many reasons that losing a customer to a competitor should never be taken lightly. The value that an existing customer can deliver include 1) repeat sales, 2) increased sales as a result of their growth, 3) references for prospects to contact, 4) upsell opportunities, 5) cross sell and 6) and sell to other parts of a large company.
In the SaaS environment, where the monthly revenue is the lifeblood of the company, the value of keeping a customer is one of the key determining factors in the valuation of a company. Not only will high churn, by its very existence, limit the revenue growth potential, it is a strong indicator for overall customer satisfaction. Not paying close attention to your installed base will ultimately result in disastrous consequences.
Elements to Review
Contacts: Relationships are made with people and not with companies.
By staying close to your contacts, understand and help them alleviate or eliminate their pain-points, recognize their accomplishments, and help them when they need assistance, a trust and a bond will be created.
I highly recommend that you connect with your key contacts on LinkedIn. This is a great tool that can help you stay in touch with your network:
Congratulate them if they receive a promotion
Wish them best of luck if they are switching companies
This might be a future sales opportunity to land a new customer
LinkedIn is also a great way to review employees at a customer. If you see an employee that you do not know that perhaps you should, give them a call and introduce yourself
Use the Task functionality in the CRM to remind you to give each customer a call or visit at the time interval you deem most appropriate. There is no right or wrong answer as a particular customer or contact might require more contact than others at any particular time. The key is the CRM application is a great tool to facilitate this activity
Customer Support Tickets:
A sales person should know any customer support issue that has been escalated or if a constant stream of calls to customer support are occurring. While the customer support organization is best qualified to manage the issues, a well-informed sales person is in a much better position to interact with a customer that is dissatisfied vs being blindsided by the issue when they visit or call the customer. If the latter occurs, it will be a painful lesson learned a bit too late.
Purchase History: While an ERP system does keep track of what a customer has purchased, having this information in a separate system is valuable for a few reasons including providing a tool for the sales people that is all inclusive so they do not have to access, learn, navigate and obtain licenses for the ERP system. This information is one of the key benefits of having your CRM system integrated with your ERP system. Otherwise, this information will likely lose its accuracy very quickly.
This information allows the sales team to better understand and help their customers to leverage their system to a greater degree. For instance, if the customer is telling the sales person that they need to accomplish a specific task, they might already have that capability available, but they are not aware of it. The customer’s issue is now converted from a product satisfaction issue to a training issue.
By using a CRM, integrated with your ERP, the salesperson has complete access to what the customer does not purchased; perhaps the latest model, an accessory add-on, or a newly released feature
Track installed base sales opportunities
CRMs are just as effective as managing your new customer sales pipeline as they are managing opportunities emanating from your installed base. All notes, stages, forecast amount, date and probability are all important things to review and manage.
Another good practice is to attach any and all quotes provided to the customer in case the opportunity is deferred to a future time. Having the prior quote readily available is obviously very valuable.
One final closing comment; if your sales representatives are not keeping detailed notes regarding your existing customers all their knowledge will walk out the door if the sales person was to leave the company. The company will have a much better chance to maintain or improve the relationships with their customer during such a transition if all relevant notes, contacts and quotes are in the CRM system.
What is Backflushing?
From a functional perspective, backflushing automates the issuing of material to the manufacturing floor upon the completion of the production process, which the ERP system defines as the point when the manufactured part is transacted into Finished Goods.
From a backflushing evangelist’s perspective, Backflushing is a way to significantly increase manufacturing efficiencies by eliminating manufacturing Work Orders and its associated task of issuing material to the Work Order.
How does Backflushing Work?
The actual backflushing process is really quite simple and contains a few basic steps:
MANUFACTURING LOGISTICS
Employees use the materials it needs to manufacture the quantity of the Part ID for a particular manufacturing schedule
Scrap is tracked
When the Part ID is ready to be transferred to another Inventory location (e.g., Finished Goods) the following information is entered into the ERP system:
Part ID manufactured
Quantity manufactured
Scrap incurred
ERP SYSTEM CALCULATIONS and AUTOMATED ENTRIES
The ERP system will reduce the amount of raw materials and/or any sub-assemblies for the:
Increase the inventory in Finished Goods for the quantity of the part that was manufactured
One can certainly make an argument that any one of the above examples where the prevention of an error, cost avoidance, and/or process improvement could very easily pay for the cost of an alerts module all by itself.
Follow-up Analysis and the Importance of Cycle Counting
By definition, if the BOM is accurate and all scrap is recorded, the only material manufacturing variance should be for any scrap recorded over/under the yield in the BOM. The only way to verify the accuracy of the backflush process is to establish and follow an efficient and regular cycle count program. If the cycle counts result in significant material quantity variances, then either the BOM is not accurate or scrap is not being recorded properly and corrective action must be taken immediately.
Keys to Success
To have a successful backflush process there are a few important things to ensure:
The BOM must be extremely accurate in terms of quantities, expected yield and structure (raw materials vs. sub-assemblies) and contain few if any variable components
Scrap for the production run are recorded on a timely basis
Production cycles are relatively quick
A strong cycle counting program is up and running
Tossing and turning at night is never fun, especially when the cause is concern over work related issues. There is an abundance of literature in medical journals regarding the negative impact on one’s health due stress or to a lack of sleep. Clearly, there would be a lot of demand for a product that could alleviate or even eliminate the stress and let you sleep at night. Even better if the cost of the product was reasonable and it actually allowed you to recoup your investment many times over.
I am sure you have heard the old axiom “if it sounds too good to be true, it usually is”. Well, in this case, I would say this doesn’t apply or at the very least it is worth your time to evaluate the product. What I am talking about is an alert system for your business, based on a set of self-defined rules waiting for an event to happen. The below are some examples of errors that could be prevented or actions that can occur with a proactive automated watch dog protecting your cash and profits while improving processes:
Shipping a customer order to European address with a US power cord
Notifying your sales people that one of their accounts just went on credit hold or is within 15% of their credit limit
A critical part in inventory just went below its safety stock level
An e-mail to your customers attaching the invoice for orders that shipped today
An e-mail to your buyer that notifies them about a new Engineering Change Order that will obsolete an inventory item and remind them as the cut-over date approaches
One can certainly make an argument that any one of the above examples where the prevention of an error, cost avoidance, and/or process improvement could very easily pay for the cost of an alerts module all by itself.
Another great example comes from one of our longtime customers. The owner was reviewing his records and was going back a few years to find something. By happenstance, he noticed that an invoice for a product shipment was sent that included a line item that had $0 for its list price. He couldn’t go back to the customer as the event was a few years in the past. This error literally cost him thousands of dollars. Right then and there he decided he didn’t want to even think about this happening again so “in order to sleep at night” he decided to purchase our alerts module.
The bottom line is the number of ways an alert system can help you and your business is almost limited by your imagination and creativity. How about a daily email alert that is sent at 6:00 every evening displaying the day’s bookings, shipments and cash collections amounts by customer?
A separate blog provides an overview regarding the five critical success factors needed to have a successful ERP implementation being:
Executive sponsorship/committee and support
Select a project manager
Cross functional team assigned
Training for all users
Test prior to “go-live”
The number one critical success factor is listed first for a reason. Without the CEO’s or COO’s full support of the project, the probability of success is dramatically decreased. A culture of Accountability with Consequences must be created combined with direct communication from the Company Executives. If the ERP implementation team and the rest of the company does not feel nor understand the sense of urgency and criticality of having a successful ERP launch, full participation from all business functions will not happen for the following five reasons:
Resistance to change
It is a well-known fact that people resist change at the work place (and in life) for numerous reasons including a) fear of the unknown, b) job insecurity and c) if they don’t understand the reasons for as well as the benefits to be derived by the change. Without the proper executive sponsorship, the wall representing resistance to change will be an entrenched obstacle.
Insufficient Communication
Two way communication with the Executive Sponsor is crucial in order to a) keep morale high even when a particular battle appears lost, b) provide strategic guidance and tactical direction to ensure that everyone is on the same page c) keep accountability high throughout the project, and d) inform the rest of the company of the progress being made as well as showing continued executive support and of the project.
Prioritization
Undoubtedly, along the way, there will be challenges for the company that appear that will test the company’s resolve of keeping the project on track keep it from getting derailed by all urgent matters that surface. All the company employees, managers will need to know that the Executive Sponsor is available to “make the call” and therefore have clear direction on task priorities in both the short and long term.
Performance Reviews
In most instances, an ERP system was obtained because the company is growing rapidly or needs to get the operations under control. Either way, employees are feeling stretched and stressed just trying to “hold down the fort”. Without Accountability with Consequences, employees will remain focused on getting their day-to-day jobs done at the expense of the ERP implementation as that is what they will be measured on come performance review time.
Measurement Yields Improvement
The old business adage of what gets measured improves is very relevant in this instance. Just knowing executives care and communication with executives will result in better results.
About the Author
Bob Swedroe is President and CEO of Expandable Software, Inc., a leader in manufacturing software development since 1983. Bob has held executive management positions at both start-ups and Fortune 500 companies including XO Communications, Silicon Graphics and Concentric Networks.
About Expandable Software, Inc.
Expandable Software, Inc. develops, markets and supports and enterprise resource planning (ERP) software suite designed to help fast-growing manufacturing companies maximize business performance.
Expandable’s fully integrated enterprise solution achieves a low total cost of ownership by delivering long-term deployment of a single system implementation.
With its unique model of direct sales and support, Expandable minimizes implementation costs and assures expert ongoing customer support.
Let’s face it; ERP evaluations, if done correctly, are extremely time consuming and often quite tedious. Hopefully, you have narrowed your ERP vendor list to a manageable few before you engage in a full blown demo with your extended team. Experience has taught me the time required for an overview demo is typically one hour. However, to complete a robust ERP demo is typically going to take a minimum of 4 hours and can, depending on the particular situation, easily take another 2-3 hours. Given this, I recommend that your full demo schedule should be limited to no more than the three ERP systems that made your shortlist.
Given the time commitment and importance of having a solid demo, clearly communicating your objectives for the demo to the vendor and the company’s attendees, in order for you and your team to be focused and can evaluate each finalist consistently. While there may be other objectives to consider, the final list really needs to include all the below items.
There is an adage regarding the three most important things to consider for successful real estate investing and opening a retail store or restaurant being location, location, and location. If the location is wrong, then the rest doesn’t matter. For ERP systems the three most important things for an ERP system selection are functionality, functionality and functionality. If the system cannot demo your required functionality in a manner that will work for your company, then the vendor needs to be eliminated from further consideration.
Therefore, the number one objective for any ERP demo is to determine if the functionality that you require to run your business exists can be demonstrated.
Functionality matching your ERP requirements: There are many things you cannot determine from a demo, including the quality of the application, the quality of the vendor’s customer support organization, and the scalability of the ERP system. However, you can clearly determine if the functionality that you require exists. All you have to do is ask to see it. The remaining objectives of the demo are all about understanding as much as you can about the company that will be supporting you during and after the go-live event. In some cases, it will be the ERP system company itself. Alternatively if might be an ERP system reseller that will be providing supporting. While the benefits of having direct support from the ERP system company itself are important, that topic is for another discussion as the remaining two objectives for the demo are almost the same.
Understanding your business: Does the ERP system company understand your specific business requirements, business model and your industry? Can they provide insights into your known issues as well as insights into issues with which you are not even aware that you have or will encounter in the near future? In essence, the ERP system vendor should know enough about your business to provide a very relevant demo and act as a catalyst for thought provoking discussions. If the ERP system company doesn’t “get it” when they are in the sales cycle trying to win your business, how likely are they to spend the effort after they win your business? Without understanding your business, they will have a tough time fully grasping the issues that you &/or your industry encounter. This will severely limit their ability to be an effective business partner and recommend best practices. In addition, if the industry knowledge is lacking, the likelihood their R&D product roadmap covering features and functionality important to your company and your industry will be greatly reduced. If you are considering using a reseller, the one difference to consider is that if the reseller does not understand your business well enough, will they be strong enough advocates to the ERP system company to champion roadmap features and functionality that are important to you?
Problem Solving/Listening: During the demo it is important to try to see evidence that a problem solving culture exists in the ERP company presenting. Are they really listening and are willing and able to discuss unique functionality or processes that are, will or might become problematic in the near future? Can they provide answers during the demo or even after the demo (once they have had a chance to discuss the issue more back at the office)? Do they quickly respond to all follow-up questions? The discovery objective is to try to determine if the ERP company has the DNA to make your problems their problems; i.e.be a strong business partners that won’t disappear once the sale is made. This objective should be followed up by reference checking for validation, but first-hand evidence might be a good indicator as well.
Wouldn’t it be nice if there was one managerial style that you can use for your staff as well as your supervisor? Well, there is; it is called flexibility or adapting to the particular person for a particular assignment.
There is a widely accepted theory based on a learning process model that has four stages (along with my very simplistic definition for each stage) that is listed below:
Unconsciously Incompetent (Stage 1): Do not know what you do not know
Consciously Incompetent (Stage 2): Know what you don’t know
Consciously Competent (Stage 3): Know how do it, but you have to think about it
Unconsciously Competent (Stage 4): Know how to do it without thinking about it and can see a few steps ahead
While these stages are very interesting, the real value is around using these stages to adjust one’s managerial style for each individual on your staff and which Stage they are in while working on their current assignment(s). For instance, if you had a newly hired employee that had minimal or no relevant experience in the area required for their current tasks (Stage 1 of the learning cycle), the best managerial approach would always be directive with minimal coaching. In essence, since the employee does not know what they don’t know regarding the assignment or with the company’s appropriate policies and procedures, it will be necessary to tell the employee what to do, how to do it, why they are doing it, and why they are doing it this particular way. This approach will facilitate the job to be completed correctly, on time, and teach the employee to enable their progression to Stage 2 for this task.
On the other side of the spectrum, let’s assume the employee assigned to the task has been with the company for a long period of time as well as having previously completed the same assignment numerous times; i.e. in Stage 4 of the learning cycle. In this instance, the managerial approach applied has to be completely different if you want to avoid undesirable outcomes least of which are being labeled a micro-manager and running the risk of completely demoralizing the employee as they easily can reach a conclusion that you don’t trust them to do the job by themselves.
Given the two extreme examples above, always consider the particular situation before deciding which managerial approach to use whether it is Directive (Stage 1), Coaching (Stage 2), Supporting (Stage 3) or Delegation (Stage 4). This thought process should be used for each assignment, because an employee might be in Stage 4 for one assignment, but in Stage 2 for a different assignment. The ability to be flexible and adjust your managerial style for each specific situation will make you a more effective manager and your staff’s productivity and morale will be the beneficiary.
On another level, you should use the same approach to manage your supervisor, if you feel they are “playing in your sandbox” too often. If you had a discussion with your manager on this subject, they might be willing to take a step back and change their approach. If however, they continue to micro-manage you, I suggest asking your manager why they don’t trust you to do the job as you believe that you are in Stage 3 or 4 of the learning cycle. If the answer is not satisfactory, then you most likely have a manager who only has a single managerial approach called micro-managing. In this instance you have to decide whether to “tough it out” until you change managers, try to find another position in the company or at a different company.
Wikipedia: http://en.wikipedia.org/wiki/Four_stages_of_competence Purchasing: By providing the ERP system with approved ECOs and new product design BOMs, the Purchasing department will be in position to modify their inventory purchases to account for the change in the BOM. In fact, the ERP system itself should be able to provide a purchasing employee with a warning if they are entering a purchase order for an inventory part that has a ECO that has been approved. These two examples serve to highlight the power and the importance of solid integrations between applications where the information in one of the applications is important to users of another application.
While there is no hard and fast rule on what is acceptable or required, most companies categorize their inventory into three classifications; 1) “A” items which typically represent 15-20% of the quantity and 75-80% of the total inventory value, 2) “B” items which usually comprise 15-25% and 10-20% of the quantity and value respectively and 3) “C” items comprising the balance and therefore having about 65-70% of the quantity, but only around 5% of the value.
This inventory value distribution is used primarily for inventory control purposes. Inventory control can include various forms including how tightly a particular inventory item is secured and the accuracy of purchase quantities and cycle counting. In essence, the main purpose is to focus a company’s inventory control on mainly the “A” items, less so on the “B’ items and even less on the “C” items. For example, a company may decide to cycle count their “A” inventory once a week or once a month, the “B” inventory once a quarter or twice a year and the “C” items once a year. Similarly, the “A” inventory items will get the most review and analysis of the purchasing recommendation provided by the MRP.
The benefit of focus is the reason why most companies do categorize their inventory in this manner. Without this tool manufacturing, purchasing and finance personnel will end up spending an inappropriate amount of time reviewing purchases and cycle counts on parts that do not warrant such attention.
The “D” category (which I chose to define it for this blog) mentioned in the title is a bit of a misnomer as it really is not a category, because it represents items of such little value they should be expensed upon receipt; i.e. not classified as inventory for financial reporting purposes. A good example of such “inventory” would be any inexpensive nuts, bolts or washers. Obviously, for “D” parts there would be no need to cycle count nor spend a lot of time analyzing the inventory as the decision was already made by management to expense it.
With the above as context, a reasonable question that finance and manufacturing should ask is should we reclassify some of our existing “C” inventory to a more appropriate expense item. By definition, there will be a one-time charge to the P&L when the existing inventory is expensed, but the charge should be immaterial given the low-value of the parts being reclassified.
Bottom-line: at a minimum, a once a year review of all your inventory items should be done so that all parts are classified appropriately in order maintain the appropriate level of management and control of the inventory. This review should also include analyzing “C” items to determine if certain items should be expensed upon receipt.
Executive sponsorship, committee and support
Select a project manager
Cross functional team assigned
Training for all users
Test prior to “Go-Live”
Executive Sponsor
Without the CEO’s or COO’s full support of the project, the probability of success is dramatically decreased. A culture of accountability with consequences must be created combined with direct communication from the Company Executives. If the ERP implementation team and the rest of the company does not feel nor understand the sense of urgency and criticality of having a successful ERP launch, full participation from all business functions will not happen.
Project Lead
The project lead should be a person with broad knowledge of the company’s business, processes, have the ability to articulate the ERP solution vision, have respect of the executive sponsor/committee and the personality strength to work with and ability to communicate effectively across functional lines, the implementation team, and the Executive sponsor/committee. The project lead needs to be a strong communicator and have the ability to eliminate the resistance to change which will arise. The ability to communicate, coach and act decisively cannot be emphasized enough.
The project lead should be a key operational stakeholder. From my experience the project lead typically comes from the manufacturing, finance, or IT organization. I strongly recommend an IT employee not lead the project for a few reasons including the greater likelihood the project will be viewed as a corporate IT project (which it is not), even the best IT employees do not understand the working requirement nuances of manufacturing and finance well enough, and it places the accountability on a support function as opposed to the people who will be responsible for the project’s success.
Cross Functional Teams
Core Team: It is imperative that an adequate number of key personnel from all impacted functions be assigned to the core implementation project team led by the Project Lead. These core team members will be relied upon to make/communicate critical workflow decisions, obtain input at the appropriate time, and communicate decisions and status to the functional working team (discussed below).
Functional Working Team: Best practices have a separate working team for each function, led by the function’s Core Team member. The Core Team member’s responsibility to:
Be the project manager for the function
Uncover any “gotchas” that need to be addressed prior to the ERP system go-live event
Communicate appropriate issues raised by the functional working team to the Core team
Drive tasks and open issues to closure
Ensure adequate resources are being assigned to the project within the function
Motivator and cheerleader for the functional working team members and across the function company wide.
Training
Lack of proper training is one of the biggest reasons for failed deployments. Inevitably, users will be frustrated by their decreased productivity, inaccurate information and reports, and will ultimately blame the software for being too difficult to use.
The old British proverb penny-wise and pound-foolish is a perfect description for companies that invest a great of time and money to obtain an ERP system, but decide to save some money at the end by skimping on training. A few of the obvious benefits that will increase the probability of having a successful deployment by orders of magnitude, which proper training provides are:
Educate users how to use the system in their functional area. This will accelerate the learning curve on the proper and optimum way to use the system which leads to increase productivity
Provide users knowledge so they understand the impact of any errors they make on other users and the company
Reduce the level of frustration and angst in learning the new system
Without proper training, the chances of having a smooth and successful launch will be greatly reduced. In addition, improper use of the system will rapidly spread throughout the company has new employees will be instructed on improper use.
Test Prior to Go-Live
Testing should occur during the period between training and system Go-Live. Sufficient testing serves many purposes including making sure the users know how to use the system properly, the work flow processes that are going to be implemented are efficient, and the results are accurate.
If an issue is surfaced during the testing period, then more training is required, a work flow process needs to be modified; which may require additional training or perhaps a system setting or configuration needs to be modified.
About the Author
Bob Swedroe is President and CEO of Expandable Software, Inc., a leader in manufacturing software development since 1983. Bob has held executive management positions at both start-ups and Fortune 500 companies including XO Communications, Silicon Graphics and Concentric Networks.
About Expandable Software, Inc.
Expandable Software, Inc. develops, markets and supports and enterprise resource planning (ERP) software suite designed to help fast-growing manufacturing companies maximize business performance.
Expandable’s fully integrated enterprise solution achieves a low total cost of ownership by delivering long-term deployment of a single system implementation.
With its unique model of direct sales and support, Expandable minimizes implementation costs and assures expert ongoing customer support.