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.
This Post Has 2 Comments
Too right! We used to have a Gap/Fit analysis that consisted of listing the “Gaps”. As I pointed out, that’s not a gap/fit analysis, it’s a list of known gaps. The problem is the only way of ruling out the “standard” enemy is to document the “standard processes” as they exist in NAV and get the customers to agree that this defines the scope of the project. Unfortunately this takes ages and no-one wants to pay for it. I have a dream that one day there will exist a set of well-documented business processes that come with NAV that can just be put in front of the users and form a part of the scope of the project. With the new NAV 2009 modfiications to the Help file that were announced a while ago on the NAV Team blog, it looks like we are heading in the right direction.
Yes, it would be great to have such a documentation out of the box, but there is a good tool, called Sure Step Business Modeller, which helps mapping and modelling the business processes, which can then be used in communication with the customer. It has a lot of standard processes already covered, I am only not sure if they are NAV processes, or some general processes – can’t remember, and can’t make the darn thing run on my Vista machine – it simply stopped working.
But in any case, it is a one-off job to document the standard processes – therefore it can be a worthwile investment to prepare it, then use it on every future project.