There are both interests and inhibitions to either promote implementation of ERP to their organization, or stay away from it as long and far as possible. There are horrow stories on the subject regarding work loads, operations severely compromised and prices shooting over - unfortunately also backed up by statistics. More than half of the projects go considerable over budjet or fail on some critical aspect, or both.
However, there is the ever increasing amount of those projects that succeed. One could say that the general attitude towards ERP is positive regarding the final goal, but most see the project as difficult, expensive and risky, so they postpone the decision as far as possible. Maybe unnecessarily, because there has been improvement lately in the ERP systems themselves, them being more stable and accessible nowadays, but also with the methods of implementation moving toward more practical and concrete approaches.
It is also much easier and economical to "get onboard ERP" while the operation is still relatively simple. And then grow together with the ERP. As opposed to first grow for years, while letting all the flowers bloom in the organization, and then trying to align everything to a common process. Surely it works that way as well, but be prepared to either slightly more resistance from people, or be prepared to modify the ERP a bit more..
There is hardly any precise treshold to determine exactly when ERP would be a smart move, but at least one might give it some thaught when these conditions apply:
1) the turnover goes over one million €
2) there are more people than "officefull", so either several departments or people are located in several places ,
3) the number of orders per day goes to three digits
If the operation is complex, either geographically, including foreign offices or sites, subcontracting, manufacturing, any oversees operations or such, the pressure for ERP is psobably harder and you may need it already in the start..
Below is a imaginary use case, where a small web shop gradually bumps into all kind of difficulties, where ERP might have helped. In the end there is list of features that a typical ERP could have managed.
The operation starts IT-wise as a combo of webshop and cloud (Saas) based book keeping. Not integrated, as your particular book keeping system does not have a direct ready-made integration. But they still work loosely together so that one simply runs a stock valuation report from webshop and updates the value in the book keeping as a lump sum per month. Not too much work! Purchase related invoices are booked to book keeping system, no link to webshop. Customer sales can be reported to book keeping based on the payments reported and paid by the payment provider, once per week. That's it, those are the main transactions, and everything runs smoothly. There is maybe a slight problem, as the book keeping system cannot show the profit per product, because you only record lump sums of weekly payments - it is missing the product dimension. And report from webshop, while they have the profit on product level, are missing the commission, so profit looks just a bit too good. Unless you compensate with some excel based custom report where you apply some formulas to reduce the commissions. Also the indirect purchasing costs, such as customs, freight, insurance and such are missing from the stock value and booked as direct cost, because there is no practical way to link them to stock value. So these costs get allocated evenly as operation costs, instead of being linked to only those products that actually required them. But that is not severe enough inaccuracy to start doing it in any more complex way, like in ERP.
The reporting of stock valuation is nice and easy: webshop has two nice fields for each product: the stock quantity and unit-cost. One just multiplies and sums and there you have it, and it is actually fully automatic based on webshop standard report. However, there is glitch! Sometimes, in order to serve customers quickly and avoid stock-outs, goods are purchased as air-freight and not the normal cheaper by-truck method. When this happens, the purchasing cost is higher, and as instructed by the book keeper, one should maintain the average price in the unit-cost field. Which takes a calculator to count, and is prone to typos, and annoying as hell! So after a while our enterpreneur finds a nice extra app to fix it. One just types in the purchase orders with the quantities and prices, and upon recieving them all the stock values are automatically calculated. It gives also an extra bonus: users can see when the stock is going to increase, in case you are running out, so that gives them nice extra information and reduces the emails asking the same. So the only annoying thing is the fact, that when purchasing one needs to 1) first actually purchase it using the vendors system, 2) doing the same thing in the web shop app and 3) entering the purchase as invoice to book keeping system, though this last step you don't need to do line-by-line, lump some is ok. Domestic vendors are bit easier (in Finland) as most of them send eInvoice directly to book keeping. .
Then suddenly sales is boosted, and you hit the treshold for reporting and paying the VAT with local VAT% (this happens around 10k€ in most European countries, but of course the limit is country specific). So the sales reporting must be more accurate, the payment providers lump sums cannot be used any more. And payment provider does not exactly know the reporting country so they can't do the split. (They only know the address in the credit card, but they do not know if the goods were actually delivered there, as delivery and invoicing country are not necessarily same). So then the sales must be actually reported from webshop system after all, but the figures must be adjusted so that the commissions are separately calculated. It is all a lot of fuzz and extra work, but the book keeper does this every month. With some extra costs and extra delays and hardly ever with mistakes. But there is no obvious way to do it in any other way, neither, that the enterpreneur would know of.
Next obstacle are some more technical devices, which you need to sell with warranty, because otherwise the customer goes to competitor. As they sell nicely, you every now and then also get a reclaim and return. So you need to check your reports if that customer is still eligible to for warranty or not. And though you can simply send the defects to the importer or to the manufactures, there are actually some so simple fixes that you prefer to do them yourself, to save time. Especially when the failure happens after warranty and you wouldn't get any free service anyways. This is nice and profitable business, but there is again an annying side effect. The spare parts used for repairs are actually also for sale in the web shop, so you must always adjust the stock balances so that stocks are accurate. And then the book keeper says that one cannot simply adjust the stock as-if it was physical inventory count difference, the usage must be reported as usage for repairs. Which is another problem, as web shop only understands sales transactions, and this is not sales. So then a special excel sheet is launched to track these internal usage cases, which the book keeper then involves in his manual monthly calculations to get it correct. And it basically works, though sometimes the people forgot to update either the excel or stock quantity or both, so one just has to execute the physical inventory a bit more often for these materials. This extra work and confusion make the repair business kind of troublesome, though it would basically be a good business .
At some point it is discovered that some products would sell much better if only the customers could touch and feel them before buying. Also it would reduce the returns for these products a lot, which is another irritating topic. So then there is the idea to open the warehouse for direct sales occasionally, just every now and then, to promote and directly sell goods. But then a practicality arises: how do we sell and collect the money, as hardly anyone uses cash any more. So the same web shop is used to book and sell the goods, which basically works but is bit slow, and totally separate payment terminal is leased to get the payments. POS systems would be available, and the fees they charge are not impossible, but integrating the stocks between their system and current web shop is simply not supoorted.
Then, after the export seems to do pretty well, there arises new idea: we should have a parallel web shop optimized for our best selling country. It is not just about translating the product descriptions: the whole web page content, including layouts and other content, should be adjusted. So again there is an obstacle: it is pretty hard to align the stock balances between the web shops. This is partially solved by launching a separate warehouse in Central Europe, so that original web shop manages the original warehouse, and the new one the outsourced warehouse. But this is not optimal for some of the slow moving products, it is simply not feasible to have double stocks. So then the new web shop will use drop shipping feature so that the original web shop serves as a provider, and this solves it. But now the sales is booked double, and book keeper has to eliminate the double sales in finance system, but hey, he is used to fixing the books every month, so just another little task for period end for him. No trouble! Though out of respect for him, the drop shipping scenario will be used only for the expensive slow movers, other are managed using separate stocks. Again, there is a funny feeling that there might be a better way to set this up...
Okay, so much for imaginary story. But maybe above serves as a taster of what kind of issues one might face trying to run things with web shop / book keeping combo only. When opportunities arise in business, like new markets or product groups, it feels really impossible to start developing IT systems at the same time, as all time goes to the new business topics. It might occur that it could be a nice idea to somehow have options for new IT features. So when need arises, you simple activate the option, and go on with the business case. This may start to sound like you should have an ERP system in the background actually well in advance, so when you grow, you just leverage it and go full speed ahead .
Odoo includes following features, just to name a few:
- stock management with stock valuation, e.g. using moving average. And serial and lot numbers for selected products, as needed. And management of indirect purhchasing costs like customs, freight etc.
- option to integrate to several platforms, like WooCommerce, Shopify, Magento, or even Amazon marketplace. There can be several in parallel, even several of same type (two shopify stores). Linked with one or several warehouses.
- option to integrate to book keeping systems, like ProCountor or Netvisor, in case one wants to continue using them and not the Odoo own book keeping module, which is yet another option
- warranty management with preset warranty period, tracked per serial numbers (with custom module, ask for more details if interested)
- repair management, supporting both warranty and separate repairs, integrated with stock keeping and invoicing and serial number based tracking
- purchase order management, integrated to stock management (automatic replenishment proposals), including automatic stock value update upon reciept, integrated to finance and also integrated to vendor systems e.g. by email. Essentially entering each order just once
- automating the purchasing process based on stock balances, minimum/maximum quantity rules, forecasted reqirements etc. so that purchasing can be based on automated proposals
- support for multiple warehouses, multiple companies, several countries, transfers between stocks, pickups of sales from shops, inter-company transactions, etc
- POS module, supporting bar-code based product recognition in the desk, integration to payment tarminals, receipts, integration to cash registers, regular customer programs etc. .
- and more than 1000 different functionalities / modules, thay you can activate as needed. They are all part of common integrated product, built as compatible with each other (unlike some web shop plugins that usually work nicely with the core but not always with each other, at least not each version of each other).
- etc...
