Blog

The biggest jeopardies often lurk where we least expect them. When implementing an ERP system such as Microsoft Dynamics NAV, what should be one of our best allies, turns out to be our mortal enemy. It has a simple name: The Standard. Standard processes, standard functionality, standard documents, standard system. All these gizmos can turn into gremlins in a blink of an unattentive eye.

Standards are tricky. If during due dilligence, or diagnostic or analysis phase, we hear the prospect or customer utter the word “standard”, what do we instinctively do? Well, in a standard system, it’s pretty obvious what the standard is, and when the customer says that they “just have standard processes” it means that these processes are just covered with such a standard system, right? So we instinctively tend to skip the more detailed analysis of these, because after all, they are standard.

But what is a standard process? It’s a matter of perspective. As a friend of mine likes to illustrate it, when travelling from Boston to New York, how do you do that? What is a standard way of travelling for you? It depends. If you are a multimillionaire, you probably do it by a private jet. If you are poor, standard way of travelling is probably hitchhiking. All those in the middle can travel by a commercial jet, a train, or a car. Getting from point A to point B, a simple process in itself, a standard process, turns out to bear quite a different meaning to different people.

In business, most processes are not standardized, at least not formally by a central authority. Where they do get standardized is within an organization. When an organization is small, it is usually more likely to have random, ad-hoc processes. When it grows, the randomness and agility which were survival mechanisms before, start turning into obstacles, and standard processes tend to develop to achieve predictability, which becomes a necessity as soon as processes get away from the hands of an individual, and become responsibility of departments.

While randomness will not necessarily hinder efficiency if one individual alone is involved in a process (in fact, it might even facilitate it), for a department to be efficient, processes need to be predictable. They get standardized, and what people gradually learn, is that they have standardized processes. But these standards apply on to that organization, other organizations also have standardized processes, which might be completely different. And they usually are.

So, when you are analyzing requirements, you should be alert of the word “standard”. When your customer says that they have standard sales process, it can be all sorts of things ranging from simple invoicing, to full-blown sales process starting with lead generation, prospecting and qualifying, proposing, closing, and account management. Your picture of a “standard sales process” might also be completely different from customer’s, and it is probably closer to what comes out-of-the-box with the “standard” system.

One of common analysis mistakes is omitting detailed analysis of a process just because it is “standard”. This can lead to a disaster later on, when finally you figure out that the reality is way different than what you thought it was. And the later you figure it out, the worse. Sometimes it gets detected as late as deployment has already commenced.

How can it happen that something that should be analyzed, isn’t analyzed? A typical scenario is that when a customer asks for a proposal, usually a short high-level analysis is done to provide a rough estimate of time and cost. At this time, it is extremely likely that when a customer labels a process “standard”, it won’t get analyzed any deeper. Any high-level functional specification which comes out as a result of this high-level analysis will have this issue resolved, it will just label it standard, or exclude it from documentation altogether. If time is short, and budget is tight, to get on with the implementation, whatever was deemed “standard” might get easily overlooked, and missed once again.

With proper methodology the risks that “standard” processes bring along can all be easily mitigated, even if such processes have not been properly analyzed up front. One way to do so is through user training. If you conduct key user training early on, before any design and development has even begun, you will have an opportunity to get valuable feedback, because these key users will quickly spot anything not conforming to their notion of standard. This feedback can alert you to do more proper analysis of those processes that you thought don’t need any, and in the long run, it can save you a lot of time, effort, and money.