Features of an ERP System
Features of an ERP system - James Meredith - Medium
Part 2 of what makes an ERP systemIn the last section we examined what an ERP system may be used for, and why you might want one. This section digs a bit deeper into what features an ERP is likely to have.A database of master recordsThis is the base information that a system needs to function, and consists of a a series of records of the company data. This data probably already exists in the company somewhere, in a binder or a spreadsheet (or perhaps in certain peoples heads), and it makes a lot of sense to transfer all of this into the ERP and keep it as the single source of the truth. Let us take an example. In order to buy, stock and sell a product you need certain information. Firstly you will need to give it an ID to know it by, known as the Stock Keeping Unit or “sku” (pronounced skew). You will need to know what supplier it comes from, the Manufacturers Part Number (MPN) to reference on your orders so the supplier knows what to send you, the buying price from that supplier (one of several, perhaps with quantity breaks), and minimum order quantities. You may need to know the physical dimensions and weight of the product for the shipper. If it is coming internationally you may need customs codes (HS codes, CN codes). To stock the product you will need to know what locations it is allowed in, does it have a sell by date, will it have a serial number you need to track, and what cost will be assigned to it in the stock valuation. To sell the item you will also need a description of the product, perhaps several descriptions for your website, shelf labels, or product catalogue, perhaps in several languages. You will also need a selling price, probably several selling prices if you sell to the trade and end-users and in different geographies. You will need to know if the item attracts sales tax, and at what rates. You might need to categorise it in several ways, the section it sits in your catalogue or on your website or on eBay, or perhaps a ranking about how important it is not to run out of the item. Real product records may run to hundreds of fields. The best systems may allow you to store datasheets, or images along with the relevant product. There are specialised Product Information Management Systems (PIMS) that can handle this, but since you also need this data in your ERP a good implementation might be able to replace this need.As an aside if you do have a PIMS system I suggest that it is integrated with your ERP and that the ERP is the master. It is infuriating for users to have to update data in multiple placesOther master data records may be Suppliers, Customers, Prospects, Bills of Materials, Prices and many others to come. As you can see, losing track of these, or losing them altogether is going to be a problemA database of transactional recordsTransactional records are those that relate to moving one of the master data records. Some common examples are Purchase Orders, Sales orders, Invoice etc. There are likely to be important reasons for both compliance and customer service reasons that it will be pretty serious if any of these got lost. It might disappoint an important customer or get you a fine from a tax authority!It is likely that every line of every sales order and every line of every invoice is going to create a new row in this database. This will soon run into the millions even in an SME.A database of balancesIt may sound like this is simply a matter of adding things up from the transactional records. However it is very useful if you can find out your stock balance without having to sum everything you ever bought and sold. It is useful to know what a customer owes you without having to sum everything they every bought minus everything they every paid (while they are on the phone!). Keeping the balances in sync with the transactions is a non trivial problem which many systems in the wild have not managed to solve.A User interfaceThere will need to be some kind of user interface where users can create, update or perhaps delete records. They will need to be able to enter sales or purchase orders and accounting journals. They will also need to be able to view the output of complex processes like MRP and make decisions based upon it. There also needs to be a way for administrators to configure things. This was typically available in a ‘client’ system installed on a PC, but may now be delivered as a web page.The accounts system is basically a specialised way of summing up transactional records and displaying them in a standardised way.Some users may have specialised User interfaces like Point of Sale equipment or Warehouse Management System handheld terminals. These may be a part of the ERP itself or an add on system. This is an area where I think some fresh thinking is required, which I will cover off in a later episode.Business LogicThis is the smart part of the system. This says what happens when someone enters a transaction. A simplistic example is that once a customer orders some goods, you may want to credit reference them, you may want to tell the warehouse to ship, you may want to tell the purchasing people to reorder.Reporting and analyticsIt is common to need to view and work with data outside of the ERP, in Excel for instance. For this you will need a way to query the data out of the database and export it. For instance you may need to query all of the product records that are in a certain category to send the descriptions to someone who is writing the paper catalogue. Perhaps you want to see all of the sales orders for a certain product, for instance, to see who is buying it and compare them with who is not.Further to that you may want to run much more complex queries on the database to analyse transactions, this might need a much more complex reporting tool or a direct query interface to the database using Structured Query Language (SQL).Going a step further there is analytics. This might be to undertake complex analytics of sales performance, or production efficiency. You might want dashboards of KPI’s or interactive reports where you can drill-down by customer, product, territory etc. This may well be handled by a dedicated reporting system integrated to the ERP.You may even want to perform machine learning on your data to see what insights you can discern about your customers.An API, EDI and import export functionalityThere will be a day when you need to create or mass change a lot of products. The data may have been given to you by the supplier as a csv file, perhaps. You are going to want ways to import that into your system.You may need to book deliveries from your courier company, and print off their labels. It is a drag to have to type them into their software by hand, so you will want an integration. Maybe you have a website, and you want the transactions entering into the ERP so you can ship them. Perhaps you have a major customer that can send you sales orders electronically. I would be nice if you could have those enter themselves into the system.Allowing this to happen requires a suite of integration tools, an API, an EDI system and imports/exports system. They are often undervalued when people are speccing a system. These systems are often not very good, probably for the same reason. They are however critical to the future expansion and flexibility of your system and you should give it a high priority.CustomisationEvery ERP vendor offers a level of customisation. This is where you could spend a lot of money with little to sow for it. It is my strong opinion that your ERP should do 95% of what you need out of the box, or you a falling into one of two traps. The first one is thinking that your business is so unique that the way the rest of the world is doing it wont work for you. You need to work in the way the ERP works, and consider that this might in fact be great business advice. Maybe doing things the way the rest of the world does is better. The second trap is that you may be looking at the wrong system for you, or even the wrong partner.The degree of customisation varies from some ‘workflow’ type tools (when this happens do that) all the way to full programming environments.In the next articles we will dive into each of these areas and look at how they work. We are then going to look at how you might choose a system, followed by how you might design and build one.This post is part of a series about ERP systems. To make sure you catch the full story please sign up to my mailing list