Implementing Business Central, There is a new way to do it?

I read a blog by Bjorgvin Gudmundsson (here the link) on the cost of implementing Business Central quite interesting and let's say I agree on many points but as always, the European world is very different from something outside that continent.

The traditional strategy is the one that continues to prevail in Latin America, where an analysis, design, a very extensive document (or several documents) are made and where it is put down to the last detail what the ERP will do when a key is pressed at 10:23 in the morning.

All this, it's written and logically, quantified. We have the fit / gap document and the project has increased its cost by several thousand dollars more than the initial estimate.

Certainly, one of the main causes of this, is the user's need for the system to do the same as the current one because it is a business requirement that someone, who most likely does not work there anymore, asked for it.

The second most important cause is, since we are going to invest, the system needs to do everything that the current one does not do, no matter if the users know or not know what the new system can do (or how).

The third cause is, I need my current reports exported from the new system to be able to “double cross check” the information regardless of whether the new system does not require “double cross check”.

Here a small digression, recently, I went to an analysis (yes, I plead guilty) and one of the most important requests was the " double cross check " of the accounts receivable information of the client against the accounts receivable general ledger account. I showed the operation, I demonstrated that any movement you make using the client will make an accounting entry against the corresponding accounts, documented that there is no way that if a record is made, it does not make any movement in accounting and still, “I need my report to double cross check”.

Returning to the topic, there are many ways to increase costs and time to an implementation project, any partner knows how to do it.

But how do we reduce the cost of an implementation? That is the interesting part.

In the mentioned blog, the modern way of doing it is explained, the paradigm shift where “the last goal is to win the game” defining these goals as specific steps to be taken or covered before moving on to something else.

Here we begin with the problems for the traditional implementation, what will be the total cost of the project?, what will be the total time of the project?, how much will the partner earn on the project? etc, etc, etc.

When I write this blogpost, I am seeing a client with SL 2011 and SL2015, poorly implemented and a headache for that company. Too much rework, a lot of out-of-the-system operation, very normal.

I went and make a Business Central demo, the users fascinated, the owner interested, everything fine until the following ideas exchange was commented:

• We have just invested in SL2015 for “n” companies and we are leaving “n” in 2011. How can we minimize the cost of leaving Business Central?
• I am very interested in production and projects, but is there any way we can start cheaper and then add those things?

Just what Bjorgvin mentions in his post, the "Modern Way" entered the scene along with "Estimating Agile Implementation Costs."

Assuming that the most important things for the customer is to be able to buy, sell, pay, collect and then everything is posted in the accounting. As Bjorgvin says, we need to identify the smallest set of features to implement (and here comes the difference between Latin America and Europe), that is:

• Financial management
• Sales
• Purchases
• Warehouse

Why these modules specifically?

You need to understand that in Latin America the electronic invoice is being implemented in many countries (and electronic accounting in Mexico), this implies sending information from multiple sales/purchase lines and the header so that the use of purchase and sales journals is discarded, in addition the electronic billing stamp needs to be stored in the archive and in Mexico´s case, same process for payments, transfers between warehouses, advances, etc. (depends on the type and activities of the company).

With those modules in mind and the scope defined by the customer, the current sales (and implementation) process was defined as follows:

• Copy of the SL2015 database in SQL.
• Extracting master catalogs from SQL company 1.
• Master Catalogs upload to Business Central.
• Posting setup.
• RapidStart package to create a new company without customers, suppliers or products.
• Extracting master catalogs from SQL company 2
• RapidStartPackage application.
• Intercompany setup.
• Consolidation company setup.
• RapidStartPackage application.

Total time of these operations 24 hours.

Next phase is tests of operations with customer users and later, we will use the standard electronic invoice of Business Central together with the electronic accounting. Let's think about two weeks of tests and adjustments.

What would follow?

Make operational tests with the customer users to detect where Business Central cannot meet the minimum processes required by the customer (possibly the electronic transfer invoice) and logically, everything related to production and projects (which is not tracked in SL neither).

Document and proceed with the creation of the required processes while training users in the initial balances in addition to the normal operation of the system.

Final tests of developments and then it could be the Go Live.

The project could take about 160 hours without problems thinking about development, training and everything needed to get it going.

Can we make a “modern way” implementations in Latam?

I think the answer is yes, but first, we need to educate the customers decision makers and powerusers to understand this modern way.

This education needs to include the “paperless” project, the “ongoing runs and tests” and the trust relationship between customer and partner because this is the most harsh point in Latam, the trust relationship (and why we need a document with a very well defined project scope).

Another training point is the partner itself and their consultants, usually, they start a new project with the analysis sessions, taking the same notes for the same processes and later, writing the same functional requirements document with the same solutions.

Every company sell in some kind of “same process”, some started from quotes, others with sales orders but the whole bunch, select the customer, the items, prices, quantities and so on, what difference can we find here?

"I need a method to select the lot" someone can ask, you can use the standard lot selection process, "OK with that but I need that the system needs to select those for me and no, we don’t use WMS", OK, this is a stopper because we need to think, the user needs to select more than 10 lot numbers? Maybe we can develop something, the cost/profit relation of this development can help the customer? Maybe, its on the customer side to choose for development or not, but you avoid to use more than 8 hours making your document to reach the same spot, the user asking for the auto lot assignment.

This example show us the difference between the old way and the modern way. In the oldie style, you take notes, make a document, make a document presentation, the user took the document, one week later (or more) you get the complain about the auto lot selection, you need to modify the document again and wait maybe another week until you get the user's OK to the depicted process.

Then you start with the fit/gap analysis, make a development design for the auto lot assignment, check with your developer about the time for this work, maybe create a user test scenarios; finally you go with the customer and present your document, you can get a "Its OK, go ahead" or "what? This is expensive, the user can do the lot assignment in the system standard way" and you get an angry look for the user.

The same scenario in the modern way is, you run some scenarios with the user, and you reach the lot assignment process, you show that process talking about how you can reorder  the lots by date or number (remember, is a test, is a class, is a training session but the most important, is a awareness session about the good things in the system) and the user says that he need the auto lot assignment, but right now, he knows the manual ways, he watched how you did it, so, when you go with the decision maker, you explain both ways manual or development, and the time that you are going to need to make the design document, the expected development time and both users are going to start to think about costs, about time and the manual standard. I'm no saying that the users are going to choose the standard but at least, you are going to work in a development design preapproved (because you say the initial price when you explain the problem) and you saved a lot of time and costs.

Writing this post makes me think that the modern way rocks!

Another problem is the varied tax system, some countries use VAT, others use withholdings (Business Central doesn’t calculate these withholdings in automated way),  fiscal printer, electronic invoicing, and a lots of regulations and laws.

Talking about the customer of the previous paragraphs, in Mexico we need to control something called the import document number and print that number when you sell the imported items; well, this customer import items from other countries and this can be a problem because Business Central doesn’t manage this kind of information, the good news here is that they don´t sell directly the items, they use those items in their projects so the final invoice doesn’t need to show that information and we can jump this problem.

So, there is a new “modern way” to implement?

In a normal project we need to manage or develop extensions to give solutions to usual problems, a good partner should have planned all this and have solutions available to only integrate and get everything functioning and running.

If the answer to the previous statement is Yes, you can go into the modern implementation way and achieve low cost and time consuming projects.

If the answer to the statement is No, well, you have a big problem, you are working in the old fashioned way and maybe this is the problem why your company cannot close new projects and the other gamers can do, you are too expensive for this brave new market.