We are testing the ERP system. Part 2
The second part, perhaps, will begin with the answers to some questions on the last part . Some readers accused me of being unsystematic, saying that here, they say, it is not clear what they are doing here, some kind of VAT in the forms looks. No, to think about higher matters. You see, I have these lofty theories and matters ... I’ve been implementing for 10 years now, and I want to, sooner or later, any introduction become a simple and formalized process. No one has a question when it is necessary to take and set up a network, because it is simply taken and set up, and it is clear to everyone exactly how this should be done. Here and in the implementation of ERP need to strive for the same.
We have a new version every month. She undergoes hard testing before being delivered to customers. This is such an instruction on 6 pages. And the version does not come out until everything is type-top. The tester hardly thinks, just tests according to the instructions and that's it. Punctures, of course, happen, but not often, and even then minor ones. After each puncture, the testing card is finalized. This testing, which I am talking about here, should also be carried out on the same principle. There are a number of simple, small, but vital tests. Just do them and look at the result. Passed testing successfully, it means you can continue the conversation about the introduction, development of TK and higher matters. Not tested - goodbye. Everything!
And God forbid you, to think that the testing about which I am writing is some kind of standard. This is just my option. But try to find another.
')
Let me remind you, we look, as in higher mathematics, necessary, but not sufficient functionality. For whom what is sufficient, everyone will finish it himself.
In the previous part, we stopped at the shipments. However, it dealt with the so-called deliveries to the warehouse, when you simply bring the goods and thus replenish the warehouse stock. These are non-targeted purchases. And there are target. This is when a client comes to you, pays money for what you don’t have, and you deliver this “something” to it. This is called “delivery by order”, a very fashionable (and indeed really necessary) functionality. The main problem is that the customer who ordered the goods from you does not receive any guarantee. He pays you money, you buy and deliver to the warehouse. After that, another manager easily sells this product to another customer. Pretty often this is happening. When you have ten people, you have a chance to agree with each other what to ask before you sell, when you are thirty - there is no longer a chance. The task of this functionality is to provide the client with a 100% guarantee of receiving the goods if he has made an order (and even more so has made an advance payment).
There is another nuance. The customer has ordered 20 items from you. You will buy one item in 2 days, and the second for 20. Question: how will the purchasing manager understand when to start the purchase process for each item?
It is tested simply. We issue an order to the client (or an invoice, no matter how it is arranged in the system). Then we form an application for purchase. Again, a little nuance. We write out two names, one of which is in stock, and the second one should be brought “to order”. The first is reserved, and the second is sent to the purchase. Slowly and slowly ask to show how to send the second item to the purchase (I'm not talking about a more difficult case when this second item has 1 item in stock, and 2 more items need to be purchased). We go further. Where will the purchasing manager see that this particular item needs to be purchased? Ask to show this place. What commodity items fall into this place? All or only those goods, orders for which are prepaid (or received a good guide to the purchase without payment)?
Then we carry out the purchase and take the purchased goods to the warehouse. And now attention! We go to our order (or invoice) and see if the goods are reserved in stock. Not? Well, then we quote the “screen reader” the following phrase: “What the hell ... do you compost my brains?”. Automatic reservation of goods at the end of the procurement process - this is the essence of the supply "on request". No reservation - no functionality.
Once when testing, I was proud to say that the system supports the MRP standard. Here is how it looked in practice:
They showed me a form for planning, where the purchasing manager supposedly sees in one place what he should buy. What was my surprise when I discovered that the planning form includes goods for which customers are simply billed. Those. you simply invoice the client, and the purchasing manager automatically sees this for the purchase. The fact that an invoice can easily be unpaid is not taken into account. The goods will be purchased, brought to the warehouse, but the client will not take it, because change his mind even to pay the bill. Direct path to warehouse overstocking. This is the MRP, you know.
So, when testing a product, get rid of all these terms and simply test the functionality. How it is called is not important.
Experiment to start with storekeepers. Get two warehouses. Ask to divide access storekeepers in warehouses. Well, this is an abnormal situation where every storekeeper can easily ship goods from any warehouse, and not just from his own. Otherwise, what's the point in liability? Go to the program under this storekeeper and make sure that he can perform operations only at his warehouse.
In reality, the storekeeper’s functions are extremely simple. He must take the goods to his warehouse and ship it. Everything. But here, unfortunately, there are nuances. How and where does the storekeeper find out what exactly he should ship or take to his warehouse? Let them show you this place. At this place, at a minimum, it should be clear what to accept, from whom, from which document, how much (well, and some other necessary information).
Address storage. I can not say that this is really necessary functionality, but they will accuse me that it is not ERP, since there is no address storage (fashionable thing). This can be useful in several cases:
1. A very, very large warehouse.
2. A great desire not to depend on the storekeepers and on their knowledge of where they lie.
3. A huge number of items and small goods.
4. High discipline of these storekeepers.
If at least one condition is not met, there are concerns that you will not be able to implement address storage. In my practice, managed once. Draconian discipline was the guys.
From the point of view of the functional, there is nothing complicated. There is a warehouse, here are its storage sites, but what products can be put on each storage location. The storekeeper accepts the goods, the system requires you to specify the address. The same when shipped. More complex functionality - this is WMS, which in ordinary companies is not needed. Here you can further develop the topic of data collection terminals, barcode scanners, etc., but I don’t put this functionality as vital, you can survive without it.
The system should give the opportunity, quickly, knowing the product, to see its history of movement in a particular warehouse, in all warehouses. View the history of the balance of goods in a particular warehouse. Maybe something else, but nothing comes to my mind that can be attributed to the necessary functionality. If you have forgotten, write comments, I will add.
Well, first, let's look at the registry of contracts. What should be clear?
1. Who and with whom concluded this contract.
2. This is a contract with a customer or supplier (although, perhaps, it does not matter).
3. Duration, number, signatories.
4. Type (type) of the contract, if they are somehow separated.
5. Delivery nomenclature (if the contract is not a framework).
6. The current status of the contract. Signed, agreed, closed, etc.
7. Scan the contract.
Maybe something else.
If the contract for the supply of a specific product specification or the provision of specific services, then how to understand whether the goods are delivered, whether these services are provided, are all provided, or only a part?
If the contract is a framework agreement, then it means that regular shipments should refer to it. So look in these very shipments, you can see somewhere (except for the comment, of course) that this shipment is for this contract? Look at the bargaining-12, is there a link to the contract?
How is the movement of the contract. If the agreement is simple, typical, then everything is clear. What is there to coordinate? And if not typical, how is the approval procedure? What coordination chains already exist and how are they modified? How, the person responsible for the coordination of a particular stage, learns that he should agree on something at all? It should be some kind of workplace, where only those contracts that need to be approved, or a notice or something else are visible. In short, ask them to show how this is implemented. It is the business process itself.
When a person works in a company, at least three hundred, then finding some kind of contract (in paper to make a copy, for example, or fax it to a client) one and a half years after its conclusion is more difficult than a new one. Try it if you work for such a company.
To solve this problem, the ERP system is obliged to store scanned copies of contracts in the database (as well as pictures of goods, directions to the client, etc.). I think so, I could be wrong. Check it out is easy. Take the file, put it on your desktop computer. Attach it to the contract. Return to the desktop and delete the file from the desktop. Return to the program and open the contract.
How the system of blocking access to change (deletion of attached files) contract parameters is organized. Ask you to explain how this locking system works. Do you understand this principle? Here is a signed agreement. How does the system understand that it can no longer be changed?
Can the system itself form the texts of template contracts? Ask for it. Does the system understand the genitive case of a surname, a position? Does the contract preamble fill in appropriately? Does she know how to properly form the details of the parties in the text of the contract? Is it possible to upload the generated text to any generally accepted formats (pdf, doc, for example)?
If you started the implementation of the ERP system, then your goal, of course, is not to print invoices from it. Although it is also important, but this is not the goal. The goal is to control the company, to understand its effectiveness, condition, to be able to make some decisions. In other words - to control the net profit of the business and to grow it, to engage in the optimization of the product range, customer base, etc. ... These are the goals.
With your permission, I will show a picture here. No logos, just a picture.
Such a picture (or something like that) should be seen daily by the head of the company. This is a profit and loss statement. The whole did not fit, but the essence is clear - there are more indicators below, followed by the figures “Operating profit”, “Profit before tax”, “Net profit”.
To get such a report, you need a clearly working cost management system (and not only).
Here you need to spend money on rent (communication, business trip, etc.). How does this happen? Who and what completes, who and what approves (agrees), etc. Ask to show how exactly this procedure happens.
You were billed for rent in February 2010. But they brought it to you on March 5, 2010. You will pay it on March 10th. Where it can be seen that this money "went to the cost" precisely in February, and according to the movement of money in March? In this situation, this means that in the income statement this amount should be reflected in February, and in the cash flow statement in March.
You can speculate about the system of budgeting costs, but I do not consider this functionality necessary, you can survive without it. Who considers it obligatory, you can write comments therefore about, I will add.
This ends the next part. In the next part we will talk about projects, inventory management, production, range optimization, financial reporting and something else.
We have a new version every month. She undergoes hard testing before being delivered to customers. This is such an instruction on 6 pages. And the version does not come out until everything is type-top. The tester hardly thinks, just tests according to the instructions and that's it. Punctures, of course, happen, but not often, and even then minor ones. After each puncture, the testing card is finalized. This testing, which I am talking about here, should also be carried out on the same principle. There are a number of simple, small, but vital tests. Just do them and look at the result. Passed testing successfully, it means you can continue the conversation about the introduction, development of TK and higher matters. Not tested - goodbye. Everything!
And God forbid you, to think that the testing about which I am writing is some kind of standard. This is just my option. But try to find another.
')
Let me remind you, we look, as in higher mathematics, necessary, but not sufficient functionality. For whom what is sufficient, everyone will finish it himself.
Deliveries "to order".
In the previous part, we stopped at the shipments. However, it dealt with the so-called deliveries to the warehouse, when you simply bring the goods and thus replenish the warehouse stock. These are non-targeted purchases. And there are target. This is when a client comes to you, pays money for what you don’t have, and you deliver this “something” to it. This is called “delivery by order”, a very fashionable (and indeed really necessary) functionality. The main problem is that the customer who ordered the goods from you does not receive any guarantee. He pays you money, you buy and deliver to the warehouse. After that, another manager easily sells this product to another customer. Pretty often this is happening. When you have ten people, you have a chance to agree with each other what to ask before you sell, when you are thirty - there is no longer a chance. The task of this functionality is to provide the client with a 100% guarantee of receiving the goods if he has made an order (and even more so has made an advance payment).
There is another nuance. The customer has ordered 20 items from you. You will buy one item in 2 days, and the second for 20. Question: how will the purchasing manager understand when to start the purchase process for each item?
It is tested simply. We issue an order to the client (or an invoice, no matter how it is arranged in the system). Then we form an application for purchase. Again, a little nuance. We write out two names, one of which is in stock, and the second one should be brought “to order”. The first is reserved, and the second is sent to the purchase. Slowly and slowly ask to show how to send the second item to the purchase (I'm not talking about a more difficult case when this second item has 1 item in stock, and 2 more items need to be purchased). We go further. Where will the purchasing manager see that this particular item needs to be purchased? Ask to show this place. What commodity items fall into this place? All or only those goods, orders for which are prepaid (or received a good guide to the purchase without payment)?
Then we carry out the purchase and take the purchased goods to the warehouse. And now attention! We go to our order (or invoice) and see if the goods are reserved in stock. Not? Well, then we quote the “screen reader” the following phrase: “What the hell ... do you compost my brains?”. Automatic reservation of goods at the end of the procurement process - this is the essence of the supply "on request". No reservation - no functionality.
Once when testing, I was proud to say that the system supports the MRP standard. Here is how it looked in practice:
They showed me a form for planning, where the purchasing manager supposedly sees in one place what he should buy. What was my surprise when I discovered that the planning form includes goods for which customers are simply billed. Those. you simply invoice the client, and the purchasing manager automatically sees this for the purchase. The fact that an invoice can easily be unpaid is not taken into account. The goods will be purchased, brought to the warehouse, but the client will not take it, because change his mind even to pay the bill. Direct path to warehouse overstocking. This is the MRP, you know.
So, when testing a product, get rid of all these terms and simply test the functionality. How it is called is not important.
Stock.
Experiment to start with storekeepers. Get two warehouses. Ask to divide access storekeepers in warehouses. Well, this is an abnormal situation where every storekeeper can easily ship goods from any warehouse, and not just from his own. Otherwise, what's the point in liability? Go to the program under this storekeeper and make sure that he can perform operations only at his warehouse.
In reality, the storekeeper’s functions are extremely simple. He must take the goods to his warehouse and ship it. Everything. But here, unfortunately, there are nuances. How and where does the storekeeper find out what exactly he should ship or take to his warehouse? Let them show you this place. At this place, at a minimum, it should be clear what to accept, from whom, from which document, how much (well, and some other necessary information).
Address storage. I can not say that this is really necessary functionality, but they will accuse me that it is not ERP, since there is no address storage (fashionable thing). This can be useful in several cases:
1. A very, very large warehouse.
2. A great desire not to depend on the storekeepers and on their knowledge of where they lie.
3. A huge number of items and small goods.
4. High discipline of these storekeepers.
If at least one condition is not met, there are concerns that you will not be able to implement address storage. In my practice, managed once. Draconian discipline was the guys.
From the point of view of the functional, there is nothing complicated. There is a warehouse, here are its storage sites, but what products can be put on each storage location. The storekeeper accepts the goods, the system requires you to specify the address. The same when shipped. More complex functionality - this is WMS, which in ordinary companies is not needed. Here you can further develop the topic of data collection terminals, barcode scanners, etc., but I don’t put this functionality as vital, you can survive without it.
The system should give the opportunity, quickly, knowing the product, to see its history of movement in a particular warehouse, in all warehouses. View the history of the balance of goods in a particular warehouse. Maybe something else, but nothing comes to my mind that can be attributed to the necessary functionality. If you have forgotten, write comments, I will add.
Treaties
Well, first, let's look at the registry of contracts. What should be clear?
1. Who and with whom concluded this contract.
2. This is a contract with a customer or supplier (although, perhaps, it does not matter).
3. Duration, number, signatories.
4. Type (type) of the contract, if they are somehow separated.
5. Delivery nomenclature (if the contract is not a framework).
6. The current status of the contract. Signed, agreed, closed, etc.
7. Scan the contract.
Maybe something else.
If the contract for the supply of a specific product specification or the provision of specific services, then how to understand whether the goods are delivered, whether these services are provided, are all provided, or only a part?
If the contract is a framework agreement, then it means that regular shipments should refer to it. So look in these very shipments, you can see somewhere (except for the comment, of course) that this shipment is for this contract? Look at the bargaining-12, is there a link to the contract?
How is the movement of the contract. If the agreement is simple, typical, then everything is clear. What is there to coordinate? And if not typical, how is the approval procedure? What coordination chains already exist and how are they modified? How, the person responsible for the coordination of a particular stage, learns that he should agree on something at all? It should be some kind of workplace, where only those contracts that need to be approved, or a notice or something else are visible. In short, ask them to show how this is implemented. It is the business process itself.
When a person works in a company, at least three hundred, then finding some kind of contract (in paper to make a copy, for example, or fax it to a client) one and a half years after its conclusion is more difficult than a new one. Try it if you work for such a company.
To solve this problem, the ERP system is obliged to store scanned copies of contracts in the database (as well as pictures of goods, directions to the client, etc.). I think so, I could be wrong. Check it out is easy. Take the file, put it on your desktop computer. Attach it to the contract. Return to the desktop and delete the file from the desktop. Return to the program and open the contract.
How the system of blocking access to change (deletion of attached files) contract parameters is organized. Ask you to explain how this locking system works. Do you understand this principle? Here is a signed agreement. How does the system understand that it can no longer be changed?
Can the system itself form the texts of template contracts? Ask for it. Does the system understand the genitive case of a surname, a position? Does the contract preamble fill in appropriately? Does she know how to properly form the details of the parties in the text of the contract? Is it possible to upload the generated text to any generally accepted formats (pdf, doc, for example)?
Expenses
If you started the implementation of the ERP system, then your goal, of course, is not to print invoices from it. Although it is also important, but this is not the goal. The goal is to control the company, to understand its effectiveness, condition, to be able to make some decisions. In other words - to control the net profit of the business and to grow it, to engage in the optimization of the product range, customer base, etc. ... These are the goals.
With your permission, I will show a picture here. No logos, just a picture.
Such a picture (or something like that) should be seen daily by the head of the company. This is a profit and loss statement. The whole did not fit, but the essence is clear - there are more indicators below, followed by the figures “Operating profit”, “Profit before tax”, “Net profit”.
To get such a report, you need a clearly working cost management system (and not only).
Here you need to spend money on rent (communication, business trip, etc.). How does this happen? Who and what completes, who and what approves (agrees), etc. Ask to show how exactly this procedure happens.
You were billed for rent in February 2010. But they brought it to you on March 5, 2010. You will pay it on March 10th. Where it can be seen that this money "went to the cost" precisely in February, and according to the movement of money in March? In this situation, this means that in the income statement this amount should be reflected in February, and in the cash flow statement in March.
You can speculate about the system of budgeting costs, but I do not consider this functionality necessary, you can survive without it. Who considers it obligatory, you can write comments therefore about, I will add.
This ends the next part. In the next part we will talk about projects, inventory management, production, range optimization, financial reporting and something else.
Source: https://habr.com/ru/post/92235/
All Articles