Project management / project support
Be honest: do you really have the time to give a new ERP implementation the attention it deserves? In addition to your day-to-day business?
Can you evaluate whether work processes have been mapped as agreed?
Are you able to document your own workflows so reliably that your Navision/Business Central system house can implement them according to your wishes and requirements?
If you have hesitated or even denied even once, an experienced project consultant is worth hard cash for you - even if it costs money. Errors and stumbling blocks are cheaper to eliminate the earlier they are discovered in the project.
The sooner you get me on board, the sooner you can avoid a disaster. And your big advantage: Since you pay me, I work and analyze in your interest - and not in the interest of the system house.
An independent (freelance) Navision or Business Central consultant can save you from the worst .
Why do projects fail?
The reason is simple: projects or, even more generally, purchases very often fail according to the same pattern. That's why I didn't use the word ERP or Navision/Dynamics/Business Central in this headline.
You can find more reasons for failure as well as instructions for successful projects here.
The pattern is always the same
You, the customer, are planning a purchase. A stock management system, a new hall, new network cabling or a new private house. The list could go on for a very long time.
However, this list will not include, for example, a special machine or a very individual vacation. You will understand why this is the case after the following paragraphs.
Two elementary things come together to cause failure
a) A product which is comparable in its characteristics and which is offered by different, independent suppliers
b) A customer who wants to pay as little as possible for such a product.
What happens?
Here I am now going directly into the ERP market, regardless of whether the product is called Navision/Dynamics/Business Central or whether it is called SAP, Concord XAL, Sage KHK, Axapta or whatever. It makes no difference to this pattern.
The customer tries to protect himself by setting a high definition hurdle, often because of previous bad experiences. The most abstruse special cases and exceptions are included in the specifications (often incorrectly referred to as "requirements specification"). No special case is rare enough for the employee making the notes not to receive a pat on the back. It can always be made more complicated, nobody wants to simplify. Because very few people can do it.. Because very few people can.
Competing providers in a dilemma
Various competing providers are now contacted with these specifications. The providers are now in a dilemma:
If the providers approach the topic seriously, they need a lot of time to process the specifications.
A provider would have to separate the wheat from the chaff, the important from the unimportant. Nonsensical claims would have to be elaborately explained as such, proposals for a sensible change to a standard process would have to be developed.
However, the bidder is not paid for this time. At this point in time, he still has to take into account that he will NOT be awarded the contract.
The provider must calculate the costs reasonably. At the same time, he only has a small margin on the ERP license itself.
Good programmers are expensive, so in order to be competitive, he has to calculate and work with less good (=cheaper) programmers. However, this may mean that many requirements cannot be implemented to (at least planned) customer satisfaction. In this article from Heise , this dilemma is illustrated quite clearly from the perspective of recruiting companies.
To make his offer less comparable, he resorts to ready-made additional solutions. These again provides the retailer with the margin needed to survive, but make parts of the range less comprehensible and less comparable.
Why do good programmers only get paid by the hour, never by the line?
As a small digression, a homage to "the past" so to speak: Why can't you find a good programmer today who can be paid by the line of code, which was still commonplace a few decades ago? A good programmer is like a good painter or a good photographer. He (or she) is rarely satisfied with the first result. Improvements are made, database accesses are counted, keys are questioned, program lines are recognized as unnecessary. It's the same with photography: Hundreds of photos are taken only to end up with a few photos that are really worth seeing. Good program code "matures". I often observe this myself: dozens or hundreds of lines of program code are created, helping to transform thoughts into program code. Then this code is scrutinized, shortened, "refined". It is precisely at this crossroads that the wheat is separated from the chaff. For many programmers, "it works" is good enough. The result is unmaintainable program code, which over time devours maintenance and therefore money. Good (and indeed "beautiful") program code , like good wine, takes time. Time that also has to be paid for. When I review a few programs, I easily come up with ratios of 10:1 to well over 25:1: Programs which in the end consist of 10 program lines, for example, have previously had a hundred or 250 or more program lines. Maybe not all at once, but all in all. There are two ways to deal with this as a good programmer: A) To be ashamed of the fact that you take a lot of money for a net 10 lines of program. That's not healthy. Or, my way: B) To be proud that you were able to solve a complex problem in 10 nice lines.
"We solve your problem for X euros"
Now the customer receives various offers from different dealers, all of whom were in the above dilemma. In all offers, he will essentially find: "We will solve your problem for X euros".
Some of these dealers (the more selfish the customer, the more suppliers: Because this way the customer can still get a lot of know-how delivered free of charge) are now invited to a presentation.
In this presentation, a few highlights of the software solution are then shown in as short a time as possible: Real estate sales, share package or insurance sales, truck sales. They all follow a similar pattern.
In the end, the customer realizes that most providers will somehow provide the desired service. The second cheapest provider usually wins. "Somehow" you don't trust the cheapest provider, but you don't want to spend too much more either. "Somehow" all the presentations were "somehow" convincing.
What is the consequence?
The provider puts its - often very new - developers under time pressure and includes a few additional modules in the package. The result for the customer:
-A software product that is more difficult to set up and maintain
-Greater dependency on the provider (due to the additional modules not being freely interchangeable, regardless of whether they are required or not)
-An ERP/software product installed under time pressure
-During the launch, discussions arise about what should be included in the product (From the customer's point of view: A lot! Otherwise extra costs. From the provider's point of view: As little as possible! Better extra costs). This leads to more discussion and less production.
-And a BC developer caught between the fronts, trying to get a job with an end customer as quickly as possible - for better money and better working conditions.
-The fluctuation rate again ensures that new developers are sent on short training courses for little money in order to advance the next projects... or drive them to the wall.
The problem is that the customer is not yet able to scrutinize the product at the time of purchase. And so they try to get as much performance as possible for as little money as possible .
Continuous reduction in quality
It is precisely this (ignorance) ensures a continuous reduction in quality in unregulated markets - caused by the more or less conscious "greed is cool" mentality of the customer.
This was analyzed in more detail by George A. Akerlof as early as 1970 in a work that was only awarded a prize much later and recognized as fundamental. This can also be read more clearly in this advertising link here:
A special provider
Now you also know why, for example, highly individualized vacations or the purchase of special machines do do not usually fail: The supplier market is too small! You often have to buy from a specialist supplier and only they can solve your problem.
He will give you a fair price and you will (have to) accept this price as a given. In the end, you have paid a sum of money for a service and have received the desired service. At this point, the amount of money is no longer so important.
Competing providers
This is the difference to markets with competing suppliers and the need for regulations. Motor vehicles must, for example, demonstrate verifiable braking performance (deceleration). This is tested by the TÜV. You can therefore rely on the fact that cars sold in Germany brake quite well.
There are no regulations for car tires, only a few rules. That is why there are car tires for sale that "grip" incredibly well on a wet road and bring a car (with its tested brakes) to a standstill in a very short distance. And there are very cheap car tires. Often, but not always, from the Far East. They are more likely to make you skid than stop in the rain.
It's no different with your ERP. There is always someone who can offer a service a little worse and a little cheaper. And because quality is not always immediately visible, as a customer you often decide on the price that is always visible.
Buy Navision or Business Central
If you don't want to enter this vicious circle of blame in the first place: You can buy BC (ONLY Business Central, Navision and Dynamics are no longer available. I don't sell SAP and KHK and everything else) via me & my partner. However, this then works differently from the usual patterns explained above..
My "Best Practice„:
- You provide me with your 15 most important documents.
A few of them are already reserved:
I. Sales invoice
II. Sales Delivery Note
III. Sales order confirmation
IV. Offer for sale
V. Purchase order
VI. Representative settlement
VII. Stock valuation
VIII. BWA
If you do not carry out any special stock valuation, e.g. simply stock value = actual stock on the key date x last cost price, or if you do not create any sales offers, then these points will of course be omitted from the list.
Collect the most important evaluations/reports in your company yourself. Also from the shadow EDP, e.g. from Excel lists that are created weekly with a lot of sweat. "15" is not a number set in stone. Decide for yourself in this step what is important to you. If you have been missing an evaluation for a long time, then simply describe it briefly! - You provide me with this list with comprehensible examples. Simply make a note of any additional special features on the examples.
- I analyze these reports. This gives us a basis for conversation.
From here on we have a -very rough- basis for the cost estimate. - You count your employees who are to work with Business Central. This results in the license costs of the solution.
From these values, I will calculate a "pi x thumb" amount for you, without any claim to finality. The time required for this procedure is optional and will be charged to you. Regardless of your subsequent decision.
Project implementation:
I come to you and we get started together. I specify which master and transaction data I need from you and which departments I need to visit.
Each step takes place in dialog, i.e. you can get an estimate (!) of the subsequent effort from me at any time and also decide at any time whether this process is worth this estimated amount to you.
In this way, the requirements are quickly sorted between "essential", "nice to have" and "what idiot came up with that". Yes, the last point is also surprisingly common! If, for example, some work processes have become established in the company that have long since lost their raison d'être. Or have never had one. But which, until I came along, were never questioned.
My projects grow with the paradigm: I'd rather spend 10 hours discussing than one hour programming. That sounds terrible. But I promise you: you will love the result.
As many changes as necessary, as few changes as possible. This ensures low follow-up costs, shorter training times, complete ERP systems from a single source, fast workflows instead of endless click orgies.
Every step, every effort is chargeable. This automatically gives you an appreciation of the work performed. And I get to know your company so well without financial pressure that I can give you well-founded recommendations for process optimization. Without me coming up with blanket "Lay off 10% of your employees". Let's leave that to some management consultants, fresh out of university as business economists.
My experience from almost 30 years of IT implementations: A company that needsa management consultant already has one foot in insolvency.
Requirements and specifications
Also help. If you already have something like this, it is a good working document. We can also run a few workshops together in your company and create a joint working document that sets out important framework conditions.
It is up to you whether we call this a functional specification or a requirement specification. This remains a free planning document for orientation and can be corrected during the course of the project according to the growing experience on both sides.
This effort is of course also optional.
Am I serious about this approach?
Yes.
You don't have to buy Navision and Business Central like this. And you don't have to buy it from me either. I am also happy to come to you when the child has long since fallen into the well. Both as a savior and as a mediator.
English 
Deutsch 
Español