A great deal of my working time over the past week and a half has been spent with the overseas sales department of my company. I was called in to help with the posting of an invoice from an overseas vendor (goods were supplied for this department) and once I started work on this, I discovered that I was opening something akin to a can of worms. After several preliminary meetings, I wrote a new protocol for this department, then spent another day answering questions which the protocol had raised.
It occurred to me over the weekend that this department was using a feral system, which is why I am writing about it here. The first stage in the process is the receipt of a purchase order from the customer; if the customer is ordering products which we manufacture, then a 'proper' customer order is entered into Priority and everything works correctly. The problems start when the customer orders products which we don't manufacture but rather purchase from another vendor who is also abroad. These goods are sent directly from country A to country B without 'setting foot' here, and because of this, the overseas sales department didn't invest in a proper process. It may be that there have only been one or two cases of orders of this type but their frequency seems to be increasing.
In the above case, the customer's "purchase order" would frequently be a file created by a design program which we - and the vendors - also use. Instead of running a program to import this file into Priority and in so creating a detailed customer order, a one line customer order was created, so that the department could show that it is selling goods. In a similar manner, this file would then be sent to the vendor, with no purchase order being created in Priority.
The problems started with the receipt of an invoice from the vendor: there is no corresponding purchase order thus there is no way of knowing (at least, to the accounts department) whether the invoice is charging us for what we ordered. Apparently some form of invoice is issued to the customer (so that they can pay), but again this is murky and at one stage I was told that the customer was supplied with "an invoice created in Excel".
One aspect of ERP programs is frequently forgotten: the use of such a program improves communications between different departments, especially if those departments are geographically dispersed. The overseas sales department tended to see these orders as a private affair and so reduced the orders' visibility to a minimum; not because they didn't want anyone to see but because they didn't see any need to make the process visible and transparent (isn't that a contradiction?).
In walks Dr ERP (i.e. me) and says that from now on, the file which the customer supplied has to be imported into Priority as a detailed customer order. As the resulting order frequently contains general parts (because the program which does the importing doesn't recognise the parts), I wrote a program which would create parts and update the order with them. I also went two stage further and both connected those parts to a vendor and then added the parts to the vendor's price list. These latter two stages may have to be separated from the first for various reasons. After running this program, we now have a customer order with distinct items; from this order we can create automatically a purchase order which is then sent to the vendor, along with the original design file.
It's hard for me to understand completely the thinking which exists in the overseas sales department; it starts with a basic lack of knowledge of Priority and continues with a lack of awareness of other people/functions within the company. Hopefully these problems have been addressed.
As it happens, yesterday I was also told about another feral system. One department works with external teams who perform the actual work at customer sites and the person in charge was maintaining a list of teams and jobs to be performed in a spreadsheet. The CEO wanted to receive a list of orders which would be installed in the coming week along with their value. As long as half of the data is being maintained within Priority and half outside, the CEO's request can only be attained by no small amount of manual labour. My suggestion is to maintain the list of teams and jobs within Priority. As a result, we can easily know the value of the upcoming jobs; we can easily print a list of jobs for each team in the coming week and we can easily produce a 'sheet', a two dimensional table of teams and dates, showing what each team is doing on each date. It took me about fifteen minutes to develop a prototype for this system, including data entry and two of the three required reports.
The key word here is 'easily': once the data has been entered into Priority, the rest follows automatically. Using Excel means that whilst it might be slightly easier to enter data (and possibly the results can be displayed more clearly), it is much harder to extract data. The major problem as far as I am concerned is the mind-set of the manager who only knows Excel.
The moral of these stories should be clear: when the only tool that one knows is Excel, then every problem looks as if it should be solved with a spreadsheet. There exist other and better tools for solving these problems.
Here is someone else's take on the topic of the spreadsheet mindset. This is the sort of concept that I want to introduce into the doctorate, but I can't find the correct terms for searching in Google Scholar. Hopefully I will write more on this shortly.
No comments:
Post a Comment