Selling an ERP to the boss.
August 16, 2006 11:20 PM Subscribe
How do I convince the boss that we need to deploy an Enterprise Resource Planning (ERP) project.
We're less than a quarter old. We are starting up during the traditional slow sales season around here, giving us the opportunity to work out the bugs before sales go ballistic. I think our point-of-sales system and backend support sucks rabbit shit through straws, and our half-dozen staff unilaterally agree.
I think this is exactly the best time to start deploying an ERP like Compiere or Opentaps. I'm capable and willing to run the project. I think we can work out a creative financing solution to the professional-level payment I'd expect for such work. I could become CIO and be paid in shares, f'rinstance.
I have complete faith the business is going to thrive. I think an ERP would make it thrive phenomenally. And would provide us the tool to replicate our success in the next town...
We're less than a quarter old. We are starting up during the traditional slow sales season around here, giving us the opportunity to work out the bugs before sales go ballistic. I think our point-of-sales system and backend support sucks rabbit shit through straws, and our half-dozen staff unilaterally agree.
I think this is exactly the best time to start deploying an ERP like Compiere or Opentaps. I'm capable and willing to run the project. I think we can work out a creative financing solution to the professional-level payment I'd expect for such work. I could become CIO and be paid in shares, f'rinstance.
I have complete faith the business is going to thrive. I think an ERP would make it thrive phenomenally. And would provide us the tool to replicate our success in the next town...
You convince him by by teasing out the true cost of sales with your current system, comparing that with a conservative estimate of your proposed replacement, and deriving an attractive payback time.
Case studies of other users are helpful, and it's good to have the support of the other staff, but if it cannot be shown to be cheaper in the medium term, it will not fly. "Sucks rabbit shit through straws" is not nearly as damning as "causes us to spend 25 cents more per transaction and loses 2 out of 100 customers rather than 1".
If you can't make it look good, then your instincts are wrong.
Also, you want to show how you can easily roll back in the event of failure. If I were your boss my worst nightmare would be you deploying in the slow season and discovering that it does not scale during the busy season. I would also have a gantt chart to hand that shows how you will prevent having the project run late and be faced with deploying in the busy season.
Itemise the current flaws concretely ("takes 3 minutes to key in an order") and show how the proposed replacement addresses each flaw.
posted by i_am_joe's_spleen at 12:22 AM on August 17, 2006
Case studies of other users are helpful, and it's good to have the support of the other staff, but if it cannot be shown to be cheaper in the medium term, it will not fly. "Sucks rabbit shit through straws" is not nearly as damning as "causes us to spend 25 cents more per transaction and loses 2 out of 100 customers rather than 1".
If you can't make it look good, then your instincts are wrong.
Also, you want to show how you can easily roll back in the event of failure. If I were your boss my worst nightmare would be you deploying in the slow season and discovering that it does not scale during the busy season. I would also have a gantt chart to hand that shows how you will prevent having the project run late and be faced with deploying in the busy season.
Itemise the current flaws concretely ("takes 3 minutes to key in an order") and show how the proposed replacement addresses each flaw.
posted by i_am_joe's_spleen at 12:22 AM on August 17, 2006
As a slight derail but hopefully still on topic ERP applications are a pain in the ass. My work as well as friends that work at places with ERP applications have trouble with them. Two reasons.
1) The ERP application selected for their business does not best suit their business needs.
2) The people using it have inadequite training.
1) can be solved if before you buy it, you thoroughly research it. But they are so complicated that I wouldn't advise doing it on your own. Hire a consultant that works with different ERP applications (not one that just shills one or two) that can evaluate your business and decide which one works best for you.
2) Requires that training costs be taken into account. Companies like to think they can learn it themselves and save a bundle. This rarely happens, because its too damn complex and they lose money with how poorly the system ends up being run. My company, for example, does inventory in excel spreadsheets because no one knows how to do it in our ERP application. So be sure that training is included in any costs relating to it.
posted by [insert clever name here] at 1:11 AM on August 17, 2006
1) The ERP application selected for their business does not best suit their business needs.
2) The people using it have inadequite training.
1) can be solved if before you buy it, you thoroughly research it. But they are so complicated that I wouldn't advise doing it on your own. Hire a consultant that works with different ERP applications (not one that just shills one or two) that can evaluate your business and decide which one works best for you.
2) Requires that training costs be taken into account. Companies like to think they can learn it themselves and save a bundle. This rarely happens, because its too damn complex and they lose money with how poorly the system ends up being run. My company, for example, does inventory in excel spreadsheets because no one knows how to do it in our ERP application. So be sure that training is included in any costs relating to it.
posted by [insert clever name here] at 1:11 AM on August 17, 2006
devilsbrigade is right -- for smaller businesses Open Source software that is more complicated to install than Open Office is not going to work unless someone inside the business knows how to install and work with it! The expense to hire out for someone to sit there and tinker with it is not justifiable, IMHO.
However, as the business grows, it will make more sense, since *hopefully* your company will eventually have a full IT department, at which point, *hopefully* you hired someone competent enough in computers to be able to handle the job.
What are you missing in a PoS that makes it suck for 6 people? You might want to look at that question first. I just can't see any reason such a small company NEEDS ERP software.
posted by shepd at 6:52 AM on August 17, 2006
However, as the business grows, it will make more sense, since *hopefully* your company will eventually have a full IT department, at which point, *hopefully* you hired someone competent enough in computers to be able to handle the job.
What are you missing in a PoS that makes it suck for 6 people? You might want to look at that question first. I just can't see any reason such a small company NEEDS ERP software.
posted by shepd at 6:52 AM on August 17, 2006
quick answer from an IT business systems analyst: um, you have not supplied enough info to answer the question, but the way to convince the boss is nothing to do with niftiness, but pure & simple cost-benefit analysis. does the proposed system reduce costs or increase profits enough to cover the cost of designing, configuring, implementing & supporting it? that is pretty much the only question worth asking here.
and as shepd said, why ERP with such a tiny company? i just don't understand the business need. (um, when i think ERP i think SAP, so yeh, big bucks)
posted by UbuRoivas at 7:24 AM on August 17, 2006
and as shepd said, why ERP with such a tiny company? i just don't understand the business need. (um, when i think ERP i think SAP, so yeh, big bucks)
posted by UbuRoivas at 7:24 AM on August 17, 2006
afterthought: ERP's strengths, IMHO, are in supply chain mgt and/or production mgt. your business case would probably need to focus on cost savings in either of those areas, eg improved inventory control (just-in-time inventory, for example). see if there is any good info on www.gantthead.com - it's a project mgr site, but can have some decent tips on business cases, justifying ROI etc for projects like these, i think...?
posted by UbuRoivas at 7:49 AM on August 17, 2006
posted by UbuRoivas at 7:49 AM on August 17, 2006
FYI for fff: Your links above are borked, although they contain the URL strings you wanted to link. Preview is your friend.
25 year veteran of the ERP wars here, including J.D. Edwards/Peoplesoft, Oracle, SAP and various amalgamated and customized sales/inventory management applications, on everything from DEC minis, to System 36/38/AS400/iSeries, to Unix boxen. I've installed 3 ERP systems from scratch as the project lead/MIS manager and fixed 2 other badly broken implementations, in companies as small as 30 system users. And I've done consulting in the ERP industry for years, and been an ERP user group officer. So, I've seen the implementation issues from just about all sides, if that's any value to you.
A true ERP system installation takes a fair amount of setup, even if your business is a plain vanilla operation, and most of the cost recovery of an ERP system is going to come from improved inventory turns, better purchasing, and the ability to drive manufacturing processes more efficiently. If your operation is purely that of a small retailer, most ERP systems are going to have many modules that have little bearing on your problems, and which will not only contribute nothing to your business, but will be a drag on your implementation as you shut off interfaces to system modules and revamp selection screens to prevent silly operational results. So, for small companies with straightforward business operations, the lack of business needs for advanced planning functionality, and the setup issues are usually significant drawbacks. I personally worked for several years on a vastly simplified version of J.D. Edwards called Genesis, which was targeted to small enterprise customers, through a sophisticated setup automation function, which pulled the usual 2,500 business process questions/set up points in a standard JDE implementation down to about 450 questions, which then automated the account and processing function setup. I can tell you that none of the first 25 customers that bought the package commercially could even answer the stripped down install questionnaire, as there just wasn't that level of sophistication in businesses of under 50 people.
Moreover, the better ERP systems are closely tied to, or include, full accounting system functionality, as a means of capturing and manipulating cost and item data. So, implementing a full ERP system will call for significant input from your accounting people (can't possibly be done without them actually), who are legally responsible for maintaining financial reporting through the process (particularly if there are multiple investors, or bank financing involved). Accounting professionals are likely to be extremely skeptical of open source accounting packages, simply because there may be significant liability issues to them for software errors over which they have no contractual control. So, the accountants are usually another big stumbling block to ERP systems implementation.
One way of getting a feel for the practicality of trying this, that will help tremendously in selling this to your boss (if you possibly can) is to find a vendor with successful customers of your exact size and similar business (retail products, apparently) and then do some live site or at least telephone interviews with them regarding their business case development, implementation issues, and results. You may find that coming up with 5 good cases for 6 person companies that are successfully running ERP systems in similar businesses is tough, and that should tell you something.
I'll disagree a bit with some of the advice given upthread, that ERP implementations are always cost driven. In fact, many (if not most) aren't, as all the commercial ERP vendors well know. A business can have internal systems that are so bad, or so inadequate to the tasks going forward, as to make the installation of an ERP system that promises "they'll never outgrow it" seem like an ideal management solution. But in my experience, such projects undertaken as process improvement, remediation, or management revamping templates have higher than average rates of failure, frequently taking the business they are meant to improve into insolvency. You have to plan ruthlessly for the survival of the business in worst case circumstances when you do ERP for non-financial reasons, to avoid going out of business doing it. Trust me, I've seen it happen (but thank $DEITY I wasn't the one driving those boats!).
posted by paulsc at 11:33 AM on August 17, 2006 [2 favorites]
25 year veteran of the ERP wars here, including J.D. Edwards/Peoplesoft, Oracle, SAP and various amalgamated and customized sales/inventory management applications, on everything from DEC minis, to System 36/38/AS400/iSeries, to Unix boxen. I've installed 3 ERP systems from scratch as the project lead/MIS manager and fixed 2 other badly broken implementations, in companies as small as 30 system users. And I've done consulting in the ERP industry for years, and been an ERP user group officer. So, I've seen the implementation issues from just about all sides, if that's any value to you.
A true ERP system installation takes a fair amount of setup, even if your business is a plain vanilla operation, and most of the cost recovery of an ERP system is going to come from improved inventory turns, better purchasing, and the ability to drive manufacturing processes more efficiently. If your operation is purely that of a small retailer, most ERP systems are going to have many modules that have little bearing on your problems, and which will not only contribute nothing to your business, but will be a drag on your implementation as you shut off interfaces to system modules and revamp selection screens to prevent silly operational results. So, for small companies with straightforward business operations, the lack of business needs for advanced planning functionality, and the setup issues are usually significant drawbacks. I personally worked for several years on a vastly simplified version of J.D. Edwards called Genesis, which was targeted to small enterprise customers, through a sophisticated setup automation function, which pulled the usual 2,500 business process questions/set up points in a standard JDE implementation down to about 450 questions, which then automated the account and processing function setup. I can tell you that none of the first 25 customers that bought the package commercially could even answer the stripped down install questionnaire, as there just wasn't that level of sophistication in businesses of under 50 people.
Moreover, the better ERP systems are closely tied to, or include, full accounting system functionality, as a means of capturing and manipulating cost and item data. So, implementing a full ERP system will call for significant input from your accounting people (can't possibly be done without them actually), who are legally responsible for maintaining financial reporting through the process (particularly if there are multiple investors, or bank financing involved). Accounting professionals are likely to be extremely skeptical of open source accounting packages, simply because there may be significant liability issues to them for software errors over which they have no contractual control. So, the accountants are usually another big stumbling block to ERP systems implementation.
One way of getting a feel for the practicality of trying this, that will help tremendously in selling this to your boss (if you possibly can) is to find a vendor with successful customers of your exact size and similar business (retail products, apparently) and then do some live site or at least telephone interviews with them regarding their business case development, implementation issues, and results. You may find that coming up with 5 good cases for 6 person companies that are successfully running ERP systems in similar businesses is tough, and that should tell you something.
I'll disagree a bit with some of the advice given upthread, that ERP implementations are always cost driven. In fact, many (if not most) aren't, as all the commercial ERP vendors well know. A business can have internal systems that are so bad, or so inadequate to the tasks going forward, as to make the installation of an ERP system that promises "they'll never outgrow it" seem like an ideal management solution. But in my experience, such projects undertaken as process improvement, remediation, or management revamping templates have higher than average rates of failure, frequently taking the business they are meant to improve into insolvency. You have to plan ruthlessly for the survival of the business in worst case circumstances when you do ERP for non-financial reasons, to avoid going out of business doing it. Trust me, I've seen it happen (but thank $DEITY I wasn't the one driving those boats!).
posted by paulsc at 11:33 AM on August 17, 2006 [2 favorites]
Response by poster: My goodness.
I shall have to rethink my goals.
I basically want to (a) make sure customer orders are tracked and progressed through the supply chain without error and with provision for some automation (ie. telling the sales guys to give their customer a call if the order seems to be taking too long); (b) make it possible for the sales guys to access everything they'd ever want, by giving them wiki or other cms capabability; (c) integrate with calendaring, email, web, and getting things done management tools.
Which I thought looked like the kind of thing the open source ERPs were providing.
That, or maybe I need to write some software. This doesn't strike me as the sort of product that shouldn't already exist in fine form.
Workflow management, too, with integration with POS, too...
posted by five fresh fish at 11:08 PM on August 17, 2006
I shall have to rethink my goals.
I basically want to (a) make sure customer orders are tracked and progressed through the supply chain without error and with provision for some automation (ie. telling the sales guys to give their customer a call if the order seems to be taking too long); (b) make it possible for the sales guys to access everything they'd ever want, by giving them wiki or other cms capabability; (c) integrate with calendaring, email, web, and getting things done management tools.
Which I thought looked like the kind of thing the open source ERPs were providing.
That, or maybe I need to write some software. This doesn't strike me as the sort of product that shouldn't already exist in fine form.
Workflow management, too, with integration with POS, too...
posted by five fresh fish at 11:08 PM on August 17, 2006
"... I basically want to (a) make sure customer orders are tracked and progressed through the supply chain without error and with provision for some automation (ie. telling the sales guys to give their customer a call if the order seems to be taking too long); (b) make it possible for the sales guys to access everything they'd ever want, by giving them wiki or other cms capability; (c) integrate with calendaring, email, web, and getting things done management tools. ..."
It sounds like you want the Customer Relationship Management or even Sales Force Automation functions of the packages you linked. Whether or not you need ERP functions underneath them depends largely on your idea of stock commitment to orders. If you are selling inventory for immediate delivery from stock at time of order, then visibility through the supply chain is crucial, as stock commitment is a key condition of the order. This is true of enterprises selling serialized inventory items, and lot controlled or perishable items. Placement of an order in these kinds of businesses is contingent on delivery of specific items at a specific delivery point for an agreed price, and failure to deliver as specified invalidates the order.
OTOH, if you are selling nickel plated widgets on future delivery dates, you may not need real time stock commitment, or you may even find that offering such becomes a disincentive to selling, as customers will not place orders for stock that cannot be instantly allocated online for delivery, and instead, they will break uncommitted quantities to new requests for quotation.
This is just a minor example of how terms logic can influence an implementation decision. In the first case, you absolutely need inventory management and sales order processing linked to CRM to have any chance of meeting customer expectations. In the second example, not only is it not in your customer's general expectations to do business only on actual stock commitment, but your customer may even behave negatively if you provide too much information about your stock and replenishment position; in that case CRM functions should not be linked to inventory control or sales order processing, beyond visibility into sales order processing status.
None of this, of course, takes into account any of your dissatisfactions with your current POS system, which may still be inadequate to your needs, or incorrectly implemented. Nor am I trying to make CRM a bigger issue than it need be for the functionality you've outlined. If it is clear already that your current system is hosed, maybe replacing it now with something of more general design is in your immediate interests. But 3 months into a startup is pretty soon to be declaring your internal systems a disaster, and it doesn't bode well for tackling potentially more complicated packages while trying to grow and operate a startup business.
posted by paulsc at 4:12 AM on August 18, 2006
It sounds like you want the Customer Relationship Management or even Sales Force Automation functions of the packages you linked. Whether or not you need ERP functions underneath them depends largely on your idea of stock commitment to orders. If you are selling inventory for immediate delivery from stock at time of order, then visibility through the supply chain is crucial, as stock commitment is a key condition of the order. This is true of enterprises selling serialized inventory items, and lot controlled or perishable items. Placement of an order in these kinds of businesses is contingent on delivery of specific items at a specific delivery point for an agreed price, and failure to deliver as specified invalidates the order.
OTOH, if you are selling nickel plated widgets on future delivery dates, you may not need real time stock commitment, or you may even find that offering such becomes a disincentive to selling, as customers will not place orders for stock that cannot be instantly allocated online for delivery, and instead, they will break uncommitted quantities to new requests for quotation.
This is just a minor example of how terms logic can influence an implementation decision. In the first case, you absolutely need inventory management and sales order processing linked to CRM to have any chance of meeting customer expectations. In the second example, not only is it not in your customer's general expectations to do business only on actual stock commitment, but your customer may even behave negatively if you provide too much information about your stock and replenishment position; in that case CRM functions should not be linked to inventory control or sales order processing, beyond visibility into sales order processing status.
None of this, of course, takes into account any of your dissatisfactions with your current POS system, which may still be inadequate to your needs, or incorrectly implemented. Nor am I trying to make CRM a bigger issue than it need be for the functionality you've outlined. If it is clear already that your current system is hosed, maybe replacing it now with something of more general design is in your immediate interests. But 3 months into a startup is pretty soon to be declaring your internal systems a disaster, and it doesn't bode well for tackling potentially more complicated packages while trying to grow and operate a startup business.
posted by paulsc at 4:12 AM on August 18, 2006
Response by poster: Most of our sales are custom-ordered, with four to six weeks delivery time. Custom fabrics, finishes, components, etc. Indeed,we're trying to avoid selling off the floor, and avoid stocking endless product in the warehouse.
Perhaps I need a set of keywords with which to search for solutions. "CRM" I know; I hadn't heard of "Sales Force Automation."
posted by five fresh fish at 8:39 AM on August 18, 2006
Perhaps I need a set of keywords with which to search for solutions. "CRM" I know; I hadn't heard of "Sales Force Automation."
posted by five fresh fish at 8:39 AM on August 18, 2006
This thread is closed to new comments.
My first instinct is to say that a first quarter company shouldn't be trying to use an opensource ERP system without professional support. Opensource can be a major sinkhole for small companies that see it as the cheap way to get something done... & sometimes that works well, & sometimes it breaks horribly. In the first quarter, its probably not going to be worth the risk to most managers.
posted by devilsbrigade at 11:43 PM on August 16, 2006