Category Archives: Self Sabotage

Why you should build a healthy relationship with your data

Overview

Having worked with Dynamics 365 Business Central (Dynamics NAV) for years, one of the biggest concerns I have when working with clients is receiving a really big Excel file with a message saying “my numbers don’t match! Please match it up for me!”

While I always love a good challenge on solving complex problems, after some time, these types of questions concern me. Most of the time, the client did not do their work on looking through the spreadsheet and did not try to figure out where the numbers went wrong before sending them to me.

Part of the challenge with working with anything new is to put in your own work and your own time. You can see the process as a time investment, but also the understanding of how to diligently figure out where the numbers are going when you perform certain actions within Business Central.

Being Young and…Not so Wise

Back in the days when I was a young consultant, I would always solve these big Excel sheet problems myself and help customers make sense of the numbers in the huge spreadsheet.

However, a few months later, the clients would inevitably come back with another big spreadsheet asking me to figure it out for them again…And again and again.

Hey, these were free billable hours, so why not?

Over the years, I realized what I was doing was wrong.

All the knowledge that I’ve built analyzing the data and tracing the transactions through Business Central was almost impossible to transfer to my clients. While I can tell them where to go to do the tracing, knowing how to do it, what tools to use, and what fields to look at is really the key.

More often than not, when I was telling the clients where to do the tracing, the clients kind of nodded, acknowledged what I said, but in the end just took my answer as is, without really understanding how to get there.

These hours I spent getting to know my clients systems and data, in the end, was lost – and that’s something they could have benefited from if they did it themselves.

Knowledge Lost

Effectively what I was doing was showing the client how to fish, but in the end, I was giving the client the fish. By doing all the work myself, I was robbing my clients of the ability to gain further understanding of their own data and how they relate to Business Central (Dynamics NAV). More importantly, they wouldn’t grasp the key understanding of what tools to use so they can navigate their data within their system.

Even if I figured out the mystery, the client did not get the key knowledge of how to figure it out themselves the next time their numbers don’t match. All the knowledge about reconciling between their Excel sheet and Business Central (Dynamics NAV) was then lost.

Instead, I realized that the smarter thing to do was to teach the users how to fish and insist on the clients to do the fishing themselves! In the first few tries, I would walk through with the user on the data they’re looking at, then assign them the tasks that I would do if I was doing the work. They would come back with the results from the first lists of tasks then I would guide them to the next set of tasks, and so forth, until the conclusion is reached.

Conclusion

We all need help with what we do. We grow up with the tradition of transfer of knowledge, by learning from someone more knowledgeable. With more knowledge about your surroundings, life will inevitably get easier because then, all complex problems can be solved without too much effort.

One big part of having an easier work life is to understand what’s going on with your operation and how it translates into your system. There’s no way to build this knowledge without doing your work yourself beforehand. You need to understand your tools and understand your data.

I find that the users that are able to pick up the system the quickest are the ones that come to me with specific questions confirming their suspicion.

For example, if my clients asks whether they can change an account setting on the General Posting Setup to affect certain sales transactions because they want their financial reporting to look a certain way – rather than asking me why their revenue accounts don’t match the financial reports they want – that’s a sign that eventually, they’ll be able to figure everything out by themselves.

Building an understanding of your data and your system can take more time at the beginning, but it pays off in the long-term, and in the meantime, AP Commerce is there to get to know them!

How to Avoid a Mutually Assured Destruction While Implementing a New ERP System

Overview

While working with companies on ERP implementation (in our case, Microsoft Dynamics 365 Business Central), what I tend to notice more often than not is that companies know what they want to get out of ERPs, but not how to do it. The result is that managers create their own chaos that makes people go in different directions. It also means that internal managers often sabotage their own ERP implementations.

This article is part of a series regarding how internal managers can implement better new ERP systems.

All roads lead to Rome; but some of them are more steady than the others.

Common System for a Common Goal

It’s not rocket science: when companies decide to switch to a new ERP/accounting software to address specific problems they’re facing, it’s for a specific reason. Usually, it’s because they have reached the limits of their current software, or it would be too expansive to do otherwise.


While the new ERP offers a positive cost-benefit outcome, managers need to come up with common goals when implementing the new system to ensure a successful implementation if they want to avoid a mutually assured destruction

After companies shop and find the perfect system for them, the steps that follow typically are planning, configuring and then implementing the software.

One modest but extremely important goal, in most cases, is to just go live with the system. Even though this is a simple and vague goal, it allows parties involved to be working on the same objective, which is to go from the old, legacy software to the new one. It also means transfering crucial information to the new system the way that fits your company’s culture and ways of working.

Here are the do’s and don’t when it comes to implementing a new ERP system.

Too Much Potential is like Too Little

There’s one thing managers need to keep in mind while implementing a new ERP system: time is money. The potential offered by the new software may appear limitless; but while this perception of infinite improvement may prenail for a while, having too high expectations from this change could have the very opposite effect.

This is why a strategy is necessary.

A new ERP could help your company with (but is not limited to):

  • Automation
  • Better information for customers
  • Accuracy
  • Process re-engineering
  • Better analysis/reporting for management

While the ultimate goal of going to a new software is to make everything better, too much of a good thing may turn out to be bad. 

Think about it: more often than not, vendors promise the moon to their clients. When a manager watches the software’s demo, he/she will think the possibilities are infinite. But often, the honeymoon phase doesn’t last. But keep in mind that these people are salespeople, and your company needs to have a down-to-earth, strategic approach on how to implement the software. Make sure you know from the beginning what your company wants to get from the system, so you know what to prioritize.

This is when the software genius comes in, and the learning curve starts to go up. Shortly after the product is acquired, the manager will look at it, learn about the new features to figure out how they can benefit the company. Suddenly, so many problems the company had with the new system are going to be solved. Suddenly, a whole new world is going to be opened to your company. Then, an infinite list of ideas will come out of the manager’s expectation of this new system.

One thing to keep in mind when implementing a new ERP is that when working with developers, they are likely to say yes to most of your requests. Developers tend to see every request from a customer as a challenge, without necessarily thinking about budgets.

The result: developers overpromise and managers run wild.

To avoid this situation, having a specific end goal in mind, with specific areas to improve is the solution.

Most people do cost-benefit analysis based on the cost and the improvements that it would bring. However, the time to get it up and running is often overlooked.

When you start a bunch of projects, especially during a period of high stress such as moving to a new system, you end up stretching your resources very thin. Too often, resources are stretched indefinitely and the end goal is so evasive that even the manager tends to forget it.

This is why successful ERP implementations begin with specific, realistic goals that fit your company’s culture and needs, and will save you time and money.

Conclusion

I’ve worked with many companies in the process of implementing new software. While I have a complete confidence that they improve the companies’ efficiency and in the long-run make everybody’s life better, my experience has shown that not having a full-length implementation strategy can cost time and energy; and since time is money, investing in time-saving strategies is the way to go.

It’s simple: focus on the main task at hand. Go one step at the time. While it may take slightly more time, the end result will be less confusion and better results.

The last thing you want, when implementing a new system, is to yield fear and uncertainty.

Fear and uncertainty lead to failure.

Strategy, coherence, and preparedness lead to success.

Ways You Are Sabotaging Your ERP Implementation. Going Parallel.

Overview

A continuation of an article published last time.

This is another one of the biggest causes of the owners/management causing the demise of their own ERP projects.

Going Parallel

Most proponents will state that going parallel is the safest way to ensure that if the new system doesn’t work, you can safely go back to the old system and not have any loss of data.

This sounds really good on paper, it’s actually abominable in practice!

Here are a couple of reasons why:

  1. Not enough time in the work day for the user to do twice the work. Imagine your work day, now do it twice with the same amount of time. Notwithstanding the time restriction, you’ll also be bored as out of your mind. Twice.
  2. The process is different from the new system vs the old system. When you implement a new system, processes will change. Keeping 2 separate processes using 2 different software systems will confuse the crap out of anyone.
  3. If anything is missed, which there always will be, reconciliation is a nightmare. Oh your number is off by $89.42? Good luck finding that.
  4. People will always work in an environment where they feel safe. Not because the old system is better, but because it’s familiar.

From my experience, when companies go parallel, they fail.

BURN THE SHIPS

In 1519, Captain Cortes told him men to “Burn the Ships” after he landed in North America. He knew that if his men (and himself probably) had a means to go back, they would not be committed on giving their all to survive in the new land.

The same thought can be applied to your ERP implementation. Telling your people that implementing a new ERP is important, but give them an option to do things the way they did before, they will always go back and do things they feel more comfortable.

Now you may be asking “but Alex, what if the new system doesn’t work?” The answer is simple, don’t go live until you’re ready. If your preparation is crap, you will fail anyway.

The next question you may be asking is “but Alex, what if we encounter problems with the new system?” There’s no instance where there are not problems when you go live. As long as you make proper preparation, the problems that arise should not be major. Any competent Dynamics 365 Business Central (AKA Dynamics NAV) partner or developer should be able to knock them out quickly.

Preparation

Before you burn the ship, it’s your job to ensure every business process can be, at the very least, replicated in the new system. This is part of your preparation before going live.

Having a smooth transition to a new ERP software can’t be completed with just thoughts and prayers, it needs meticulous testing, simulations, and feedbacks.

Be aware that it’s not going to be 100% smooth when you cut over to the new system. There will always be problems after go live. The important things are the major known kinks are resolved.

There shouldn’t be an instance where major problems that comes up when you turn on the switch, then someone seriously messed up.

Conclusion

Take the page out of Cortes’ playbook. Burn the Ships. Have your people focus all of their attention and resource into making the new software work in your organization.

Ways You Are Sabotaging Your ERP Implementation. Setting Unrealistic Live Dates

Setting Unrealistic Live Dates

Overview

Typically in an implementation, there will be a lot of moving parts. A lot of things has to go right for a successful implementation. If any of the key tasks don’t go right, no matter how small the task is, will cause havoc or delays for a company trying to go live.

I can assure you that every Dynamics 365 Business Central (aka Dynamics NAV) consultant/company will tell you that they’re an expert at Dynamics 365 Business Central / Dynamics NAV. Whether that’s true or not and how to detect if they’re full of hot air is probably a subject for another article.

Even if you have the most qualified and reliable NAV partner, projects may still go wrong because of the decisions made by the company that’s implementing the software.

I Want It Now

It’s unfortunate (or fortunate) that we live in a society where instant gratification is the norm. You want something? Order it on Amazon in the morning and get it delivered in the afternoon. These type of service puts a lot of burden on the supplier on making sure everything goes right.

When the owners of a company is often under pressure to make the necessary changes so they can meet the demands (realistic or not) of their customers, they often want to see the same turnaround time (realistic or not) from the projects they initiate.

Setting Unrealistic Live Dates

For some managers, the idea seem to be to set a high expectation for the project. Even if the project doesn’t get to the expectation, at least we’ll be better than the original expectations should be.

One of these types of decision is deciding on a live date. In an effort to make people place a sense of urgency on the implementation, management will set an unrealistic (or optimistic) go live date. The employees or consultants will often be too polite, shy, scared, etc to call out this decision.

As I mentioned earlier on this article, going live requires a lot of precise tasks to be completed, we can hurry those tasks or skip them. But shortcuts will often come back and haunt you. This is especially true in an ERP software implementation.

What always ends up happening is one of the following:

  1. The company goes live without being ready
  2. The live date gets postponed

Of the 2 scenarios that can happen, if #1 happens, the implementation will always lead to failure. From my personal experience, rescuing customers that went live before they’re ready never really recovers. We end up having to re-implement them to get the company back on track.

Hopefully, the management has the courage to decide on option #2 and call a stop and re-evaluate.

In either of those 2 cases, the damage would’ve already been done.

Culture of Expecting Failure

Usually, when a company misses their first go live date, they will miss their subsequent go-live dates as well.

Why? Because the people are already used to failure. Their consultants or the management has promised them that they’re going to go-live, you can almost hear the employees say “Yeah… Right…”.

When I walk into companies that has missed their go-live date a couple of time, it’s almost like walking into a vacuum of demotivation. When you even talk about going live again, you’re just met with an overload of cynicism and doubt.

Prevention

Set realistic live dates and stick to it. It’s your responsibility to call out BS if someone tries to talk crazy about a live date.

How we typically plan out a customer go-live is to pick a date the customer would like to go live, then work backwards to see if that’s feasible; considering holidays, vacations, buffer time, etc. If it’s not feasible, we tell them right away, even if we get scolded at.

Of you’re in charge of the implementation, be ready to say no to unrealistic requests to go live or hitting certain milestones; even in front of a team of management. Yes, they will question your expertise, your resources, your abilities, even your character.

Just remember hurting one person’s feeling is better than having the whole company suffer.