Rant: Frustration with vendor

seckpin

Padron me for posting a rant because it is getting more upsetting as days go by. I wonder if anyone is having the same frustration with their vendor as well.

I am very disappointed at the professionalism (or the lack thereof) of our vendor, who rolled out NAV for our companies in the entire Asia region and ended up with lots of problem in the various systems.

To list a few "classic" examples:

- They did not bother to teach the users how to tally the sub-ledgers and G/L for new implementation, e.g. where to get the reports for reconcilation. Their reason: the users should know what to do and what/where to check.

- They simply make use of the database of the first country that they implemented as "template" and then roll out to the other countries, without making sure the database is properly set up. For instance, we see user names of the first country exist in another country because they simply did a copy and paste.

- For some Asian countries with small currencies, there will never be decimals for the figures. This is common sense. Yet, as they simply did copy and paste, they rolled out the system with two decimals to all countries without considering the currency. Problem arises after lots of entries had been posted and the figures totalling up with rounding problem. Their reason: the business never told them that there should be no decimal.

- To tie up sub-ledgers and G/L figures are never one of the reconciliation or checking criteria before go-live. All countries went live with unreconciled figures, and with all controlled accounts still with "direct posting" activated. Users continue to post directly to the G/L accounts, bypassing the subledgers and making the discrepancies between ledgers even bigger.

- They even suggested to users to conduct "trial run" with posting directly to G/L only, and subledgers can come in a few months later, but without telling the users how to handle the differences between the two ledgers when the subledgers do come into the picture. Basically, they simply do not care. Their reason: it is the business who made the decision.

- All the coding in their customisations do not contain "VALIDATE". All values are assigned to fields without validation, and hence resulting in data inconsistencies sometimes. Their reason: it is common to have program bugs in coding. Even big companies like Microsoft and IBM also have it.

- When they designed the system, they did not consider about the fact that we are a MNC providing services and the service equipments are part of FA. They simply made use of the standard FA module, and this lacks of foresight resulted in us having >800K FA Cards in just 2 years time, rendering system having serious performance issue.

- They impelemented a lot of dimensions (about 15 or more) in every system, and this in turn resulted in performance issue, especially problem with Analysis by Dimension and Account Schedule.

- There was no sign-off or proper documentation for UAT, go-live, etc., until our auditors requested for it and they scrambled to do "back-dated" sign-off with each country.

The list can go on and on and on, but then i may end up writing a thesis on it. For almost all problems, they always point it back to our business units, who "agreed" to the process or design in the first place, hence denying any responsibility. Even though that is true to a certain degree, it gets back to the basic question of whether or not they highlighted the implications to the businesses for them to make an informed decision. And what is the role of a "consultant"? Aren't they supposed to "consult" and make the best recommendations?!

Our internal IS team is spending a lot of our time each day wrestling with them, rectifying problems, making sure things are done correctly... rather than doing more constructive work. A lot of people told me that this is usual for NAV partners and they are not the only one who is like this. However, to me, it is more about the attitude towards our work and responsibility -- whether or not we are willing to go the extra mile to get the job done with the best results.

David_Singleton

seckpin wrote:

Padron me for posting a rant because it is getting more upsetting as days go by. I wonder if anyone is having the same frustration with their vendor as well.

I am very disappointed at the professionalism (or the lack thereof) of our vendor, who rolled out NAV for our companies in the entire Asia region and ended up with lots of problem in the various systems.

To list a few "classic" examples:
...

Where to start?

Basically my business, and most of my work over the past years has been fixing up implementations exactly like this. Its what I do for a living, so its hard for me to take an unbiased view of this, but I do try. Important to remember is that there are probably 70,000-80,000 Navision implementations out there, and though I often see problems, in reality its a very small percentage of those implementations that go wrong.

Of course when its yours that went bad you don't care about 99% of implementations that go perfectly, which of course is why I will always have work.


So back to the start. The first thing I need to point out is that I have never seen a failed Navision implementation that was 100% the vendors fault. It is always a combination of vendor/customer relationships, and most specifically expectation management. In more than half of all failures I see, it can be clearly identified that the project failed at or before the contract was signed. A bad contract is in most cases the reason for a Navision implementation failure. And the customer has to accept responsibility for due diligence in signing a contract that delivers what they need. Of course a core issue at contract signing is that the client at this point really does not Know Navision and thus is not really qualified to sign a contract. Yet they do.

Sadly there are regional differences also. There are some countries where Navision just seems prone to problems. Singapore is one of those. Singapore has a relatively high cost of living, yet it has a large very highly qualified work force and where this seem like an ideal, Singapore also has a very strong culture of competitiveness, which means that in the sales process, a lot of concessions need to be made to make the deal. I recently was asked to help a partner in Singapore with major issues on a multi-country roll out. The situation was not a lot unlike yours, many countries run from a head office in Singapore, a smallish roll out that was about to be expanded dramatically, they also had huge issues with dimension handling and performance. In fact the issue was bad design from the ground up, but that is digressing. Anyway because of the competitive nature of the Singapore market, the vendor had made a lot of promises that were not realistic, and now needed help to resolve them. They now needed help to sort it out. The project was still save able at that stage, (this was one year ago) but needed immediate action, which the partner agreed to. But we reached a stumbling block where no one understood who was paying for the recovery. The partner seemed to feel that the cost had to fit in the initial budget, since the client would not pay more money. And the partner was not willing to eat into their profit. But again that is digressing.

The point is that I have been called in to a number of recovery projects in Singapore going back more than 10 years. Yet I have NEVER actually done any work there, and always it was because no one could agree on who should pay to fix it up.

I know it sounds bad, but you need to look at your contract and see what you signed and agreed to. If you Vendor has not delivered on what they agreed, then take them to task and have them deliver. If they have delivered, then you need to figure out if maybe something was missing from the contract.

It is disappointing that in this day of being able to "buy" certifications, that there is no way to know if a company has the skills they need to do the job, so you must make a good effort to review references and make sure that the vendor is capable of delivering what is promised. In 99% of cases they are, but no one wants to get caught with that other 1%. You also need to look at what was proposed to you, and see if you didn't cut items out to bring the budget down. All the issues you mention below are valid, but take training for example. Was this budgeted in the project? If so then get the partner to come in and do the training. If not then get the budget for it and get it done.

As to the design issues, like 14 dimensions, well unfortunately that is the sign of inexperience. Unfortunately the literature says "Unlimited dimensions" and sadly many partners believe that. Those with experience know what is realistic and what is not.



So in summary, there is a situation here that needs to be fixed. It is going to cost money and a decision needs to be made who is going to pay. And the longer you delay that decision the worse your system will get. The best solution is to get together with your partner and work out a plan. If they don't have the skills in house to solve this (which does seem the case) then get them, there are plenty of people like me out there that do this sort of work, put together a plan and fix it. But make sure you define clearly how this will be paid for, or in a years time you will be in the same position with no progress.

seckpin

David, you provided great insight to the issue, as always. Probably we should just hire you to solve our problems.

I agree that when a project goes wrong, it never is entirely one party's fault. I recognise that our business users have no experience in ERP and do not understand NAV, and hence they may have different expectation or understanding of what they will get. Adding in a vendor that does not ensure all implications are properly highlighted, the business units may make all the wrong decisions.

I can also fully understand why our vendor is behaving in such manner sometimes. It may not be because they do not know they have made mistakes, but admitting it will mean they have to absorb the cost of fixing it. Hence the best approach is always to push away responsibilty to protect their own business. It is all about profit-making anyway.

(By the way, we are using a Malaysian vendor even though our regional head office is in Singapore)

The vendor implemented 11 countries for us, starting from year 2007. I think they are inexperience in regional or even global roll-out and hence resulting in the many mistakes or design flaws. All these happened before our team came into the picture.

Our internal team was only set up last year, as our boss recognised the need to better manage the system. All of us in the team had worked with one or more NAV partners before, yet we are all appalled at the way the system was implemented and the working attitude from the consultants.

Now, the countries that were implemented the earliest got the worst hit, having to live with huge volume of data that gives performance issue. For those recently implemented, as they need to abide to the "template" so that all countries can have a consistent system, they will have to live with the flawed design and implementation, and our team knows that those are just time bombs -- it's just a matter of time when they will get into the exact situation as the earlier implementations.

All we can do and are doing now day-in and day-out are just fire fighting. Sometimes it just makes us wonder how an otherwise good and sound system can go so wrong. It's just sad.

Anyway, thanks for reading my rant!

Alex_Chow

seckpin wrote:

A lot of people told me that this is usual for NAV partners ...

:shock: :shock: :shock:

Whoever told you this is grossly misinformed.

You don't go into a heart surgery, have problems, and say "yeah, that's how it is". Demand better, because you're customers demand the same from you.

rdebath

seckpin wrote:

Padron me for posting a rant because it is getting more upsetting as days go by. I wonder if anyone is having the same frustration with their vendor as well.

I may be wrong; but I'd like to play devils advocate here for a bit.

This story sounds like the common problem of the vendor who cannot say no.

Lack of training because it'll cost money and the business says it's an Office application and the users are already trained with Office.

The business says we do the same thing in every country, so we won't give you any money to make conversions for the next country. This one is a bit of a sore point; but for us the consultants were eventually able to convince the business that it was a REALLY STUPID IDEA and their business was NOT the same in each country. But for that period the WIP (Work in progress) went way up.

Reconciliation, the vendor can only help here. There WILL be differences and we can't know what's a significant difference and what's safe to sweep up into the miscellaneous account without spending a lot of time (and money!) hunting around the business.

Hmmm, "Trial run", that sounds like the phrase "Parallel Run" as filtered through a 'dumb manager'. And yes a proper parallel run would have shown it was a REALLY STUPID IDEA.

The FA can do the job; we can do some performance tuning later, when there's some data; if they'll pay for it, it not in the budget now.

"NO lots of dims are NOT a good idea." ... "But, but, but it's essential to the business we must have them!" ... "You can't need all these." ... "Prove it." ... "Proving it will cost X"

"FRD whats that? Oh Documentation. Oh okay. What, you want more money for it! You're not getting any more money!"

The simple fact is that the business has to put a lot of time and money into a go-live, this isn't MS-Excel, ie: stick it on a computer and it'll be fine in the end. We generally say that the business should try to allocate THREE days of internal time for every day a consultant is with them. Not everybody manages, but the closer you get to it the better the results.

And remember you're employing the vendor to advise you how to do the upgrade. A vendor can only do so much to get you to actually listen. We try to work at that by making sure that we can walk out at any time, but we don't want to leave it's a lot of work getting new customers. From what David said the vendors in Singapore don't have that option.

Alex Chow wrote:

Demand better, because you're customers demand the same from you.

Demand away, but there's a price...