Once the goals of the project are clear, and when the company knows what they want to accomplish with their brand new ERP, it's time to go into details and write down all the company processes one by one that will have to be done or supported by Microsoft Dynamics NAV.
When you think about your processes, don't just expose what they should theoretically be. Ask the people who are actually carrying out those processes about what they really do. Also ask about the exceptions to the processes, as handling exceptions for a normal process usually requires more time from end users.
You may want to take this opportunity to eliminate exceptions for a normal process by changing how the process works. Exceptions are basically processes that are created to do something that a normal process does not accommodate. So essentially, the user has to pay special attention and spend extra time to handle these exceptions. What's worst if they start building exception processes on top of exception processes, that's when we really talk about wasting time.
If an exception happens a lot, then it should be incorporated into a normal process. If not, then I would try my best to eliminate this exception, either through changing the process or setup company policies so these exceptions do not occur.
For each process, at least the following questions have to be answered:
Take the example of your sales process. What is the start point for your sales orders? Customers pick up the phone, call you, and tell you exactly which items they want in what quantities. Or maybe you receive the orders by e-mail, or customers submit them in a website, or the order is submitted through EDI, or maybe your salesperson visits your customers and gets the sales order, or the customers ask you for sales quotes that finally get accepted (and thus converted into a sales order) or rejected, or you have blanket sales orders for a certain period of time and you do not receive any further sales orders.
In reality, it may be a combination of all of these and other methods to get sales orders into the system. It's your responsibility, not your consultant's, to know and understand how you receive sales orders and properly document them so an 8-year old can read your document and know exactly how you receive orders into the system.
After sales orders are received, you will probably check them for the following: do you have a minimum sales order amount? Do you sell your items per unit or per box? If you sell per box, you probably have to check whether the quantities asked by customers are multiples of quantities per box. Do you establish a credit limit for your customers? If so, before serving the order, you may want to check whether the credit limit has been exceeded. You may also want to check the requested delivery date. Is it possible to serve the customer in time or should you talk to them and negotiate a different delivery date?
Once the sales order has been revised and accepted, it has to be executed. What does this mean? How do you prepare your shipments? Do you group orders per customer so that multiple orders are prepared and served together? Do you pick up items of all the orders of the day together and then pack them separately per order or per customer in the preparation area? Do you attach the sales shipment document to the pack? Which carriers do you use? Do you primarily ship LTL (Less Than Truckload) or small parcel?
And finally, in the sales invoice document, how do you process your invoices: do you post an invoice per sales shipment at the same time the sales shipment is done, a sales invoice per sales order, or a single sales invoice per customer at the end of the month including all the sales orders served in the current month?
Now that we have a bunch of questions and their answers, it is time to write it all down. While writing down your processes, you may come across new questions that have to be asked and answered. For example, you may know that your process has two sequential activities, but you may not have a clear picture of what triggers the beginning of the second activity. This is probably a good question to ask to the people involved in the process.
Writing your processes in a structured way—preferably using any kind of business process modeling diagrams or workflows—will help you and other people to understand them and will also allow you to rapidly measure how simple or complex a process is, identify bottlenecks and redundant work, and basically, where the weakness of the process lies so that it can be improved.
Let's go back to our example of getting a report of costs for a specific service. This process was done in the company before the implementation of Microsoft Dynamics NAV. It wasn't done monthly though, as it took too long and it was done manually. By asking the people involved in the process, we found out the following:
We can write down the activities, their order, and the relations with other activities using a flow chart. It will look similar to the following diagram: