Murmel Murmel... ERP?

What do consultants and programmers do?

Outside of consultants and (interested) project managers, it's very difficult to explain my job. Why do you even need a consultant for ERP integration, and why is it simply so much better when consultants and developers are one and the same person? Why are there so many friction losses and misunderstandings when too many people are involved in the transfer chain? Well... Let's just imagine how a process is mapped out in classic projects, e.g., SAP projects.

Division of labor in ERP projects

A consultant is interviewing an employee about, let's say, order entry. And wants/needs to learn more about pricing.
The employee will often not be able to explain pricing 100%%. And the interviewer / advisor / consultant doesn't know what to ask: they are a stranger to this company themselves. So a gap, a delta, practically always arises between the requested and documented processes, and reality. These gaps naturally occur not only in pricing, but also in approval processes, agent billing, inventory reservation, and so on…

Typically, for reasons of time and cost, the ERP project manager (consultant, advisor) does not conduct all interviews themselves. Therefore, they have support staff who carry out parts of the processes in the same way (interview, documentation). Each individual employee has a certain personal working style, way of asking questions, and of course, their own understanding of the processes (workflows) explained by the employees. And even the employees already have an influence here on the level of detail of the workflows described by the respective employee in the interview and the associated background information.

Process documentation, specifications, requirements specification

Now the interviewer/consultant has a process documentation for 1 to n processes. Some self-created, some from contributions received. These various documentations are now (usually) compiled by the EPR project manager (consultant, whether for Navision/Business Central, SAP, Baan, Great Plains, AS/400 (AS400) or whatever). If this project manager is good, they will notice discrepancies which will be queried. On the other hand, interpretations and misunderstandings of the records will also degrade the quality of the recordings. So, here, for the third time (1st: reproduction of processes by employees. 2nd: understanding and documentation of described processes/workflows), a qualitative change (mostly a deterioration) of the process documentation is taking place.

This process documentation will hopefully be discussed with the client one more time. However, often it is simply handed over to the client (usually for a fee), and the client can then say „yes“ or „no.“ Most of the time, the client says „yes“ because they are overwhelmed by the now documented complexity of the processes within their own company. Feedback from employees typically does not occur. There can be many reasons for this:

Customer feedback

• They won't understand that anyway.. A rather arrogant, but unfortunately often correct assessment.
• There's too much internal information in there; we can't hand that over to all employees as a whole.. Certainly understandable and often correct, but unfortunately counterproductive (harmful) assessment.
• That costs too much time/money if we have to go over all of this again now. This is certainly the most used argument (reasoning).
• It'll be fine, they're the experts.. There is a lot of great respect and hope in this... unfortunately, mostly unfounded. The „experts“ unfortunately have no experience with the processes, they (as a rule) just parrot the customer's employees... as well as they have understood it.

Media break on the way to becoming a developer programmer

If the client says „Yes,“ the resulting pamphlet (thick book, brochure) will be handed over to one or more programmers. And this is usually where the biggest media break occurs. The programmer(s) generally haven't conducted the interviews or seen the original notes. They only know what they find in this specification document. And on top of that, they have time and cost pressure breathing down their necks. „Get it done in 6 weeks, or we'll go into the red!“ is a commonly made statement. So the programmers get to work to translate the requirements found in the specification document into bits and bytes. And these programmers/developers often have a programming background, but in most cases, they have no commercial knowledge whatsoever.

Now let's get back to Navision / Business Central. The process described above is universal and affects nearly all ERP installations, or even most EDP/IT projects in general. The following section is more specific to ERP integrations, often replacements of legacy systems like AS400, SNI Quattro Pro Comet, JD Edwards, Baan, and so many more.

Problem in the special case of ERP/Inventory Management

ERP systems, often integrated (connected) in some way with financial accounting, cover many sub-aspects of business management (ERP = Enterprise Resource Planning). For example, the aforementioned financial accounting, inventory management, procurement (purchasing), tendering (often linked to customer management, CRM (Customer Relationship Management)), pricing, sales representative settlements, price calculations, contribution margin determination, process management with checks, plausibility controls, blocks, access rights, and much more.

These details are often foreign to classic programmers, at least in a usable level of detail. Programmers think in classes, objects, exceptions, declarations, functions. Not in inventories, balance sheets, and balances.

Debit and Credit

These programmers are now, for example, diving into an ERP system like Navision or Business Central, which is essentially finished, and using their programming knowledge to implement everything as they understand it from the documentation provided by advisors/consultants. They will sometimes recreate existing functions simply because they are unaware of them. They will modify existing functions, and occasionally damage them in the process. And they have little background on the actual use of the functions they are requesting – and even less understanding of potential incorrect usage and data entry errors.

And the first rough test naturally takes place with inputs that „make sense.“ But even more important are the tests with „nonsensical“ data!

The programs/customizations created in this way are now handed over to the customers – sometimes by the consultant or advisor, sometimes by the programmer. This is where the users come into play again for the first time.

Developer / Programmer and Consultant in one person

Do you still remember the initial question? It's better when a programmer/developer and a consultant or advisor are the same person because: It leads to a deeper understanding of the client's needs and challenges, as the individual is directly involved in both understanding the problem and implementing the solution. This can result in more effective and tailored solutions. It streamlines communication by reducing the number of intermediaries, which can speed up the development process and minimize misunderstandings. It fosters a sense of ownership and accountability, as the individual is responsible for both the strategic advice and the technical execution.Many of the above loops are simply omitted. This already significantly reduces the effort for capturing, understanding, and implementing requirements. However, even more importantly: in case of ambiguities during implementation, he can directly contact the responsible employee to ask questions. Conversely, during testing, the employee can also directly contact the already known Navision or Business Central developer/programmer for further definitions, changes, or forgotten details to provide specifications that were previously overlooked.

Understanding with a practical example

These feedback loops, trial and error, are very important aspects of agile development. And that is much more difficult for most people to understand than the ancient working method described above. For those who want to delve a little deeper here:
Just look at watch this video here. This is about a marble music machine development that is completely unrelated to ERP. What's interesting in this video, however, is something entirely different: How many details are there to consider in a project, how many subsequent adjustments and subtleties need to be taken into account? And how are these best identified and resolved or improved? What beauties (Yes! Software can be „beautiful“!) can be discovered and incorporated through rework? How detail-oriented can one be? Just let the video have an effect on you...