jump to navigation

ERP Training and Power Users 06/28/2012

Posted by TBoehm30 in Trainiing.
Tags: , , , , , ,
4 comments

A full ERP implementation project will contain plenty of training.  All the members of the company need to start from scratch to learn the use of the new system.  I’ve scheduled classes where we have 10 days of classes plus three alternates a week or two later for anyone who missed it.  The thing to remember is that is just for the basics; you will spend much more time with the people destined to become your ‘Power Users’.

The main classes that will be scheduled are for beginning 101, learn how to navigate type instruction.  When users logon for the first time, they need an idea of what to expect, how to get what they need and what they are allowed to do.  Everyone will need that class so it will be the biggest or most offered class.

After the beginning class, you will need some specific classes.  The Accounting group will need to go into detail on the accounting screens.  The Manufacturing groups will need specifics on how to run MRP, use Work Orders, order Supplies, etc.  The Customer service group will need to understand Sales Orders, Cases, how to change documents, and update notes.  The point is that these classes will be smaller and need to include only the groups that focus on the topic being taught.

Most project managers and organizers will stop there.  They will teach what is needed and then allow the users to figure out if they need further functionality or further help.  It has been my experience that users don’t know to ask for more.  They will start using the system in the way that they are taught and not try to branch out for better, more efficient processes.  Usually a new employee, or outside consultant will bring in ideas on how to use the software better.  It’s rare that someone just figures out better functionality, communicates the process with their manager and gets the company to adopt the new process.

As I wrote in a previous article, follow-up training is necessary.  Once users become familiar enough with the software, they need a time to go back to ask questions.  They will want the details on why they do what they do.  They need to know how it impacts the company and what the big picture looks like.

That full process will take care of most of your users.  Beyond that, however, are the ‘Power Users’.  These are the people who seriously want to take advantage of the system and use it to the fullest extent possible.  These are the people who currently have massive spreadsheets that they download to understand the data.  They need to understand what is going on at a basic level and make decisions based on that information.

These are the people who will try your patience once the new software is going strong.  They will need one-on-one guidance for their crazy projects.  They will stretch your understanding of the software to its limits and force you to call the vendor.

Now is the time to plan for their training.  They know what they do, and will be able to explain what they need.  You will be able to schedule one class for a bunch of them, or several classes if needed.  Getting them together may even work in your favor, giving them other resources to go to and other further ideas on how to improve the status quo.  You need to be at the top of your game and have good backup support for these classes.  You might want managers included in the room so that if ideas get out of hand, they can be cooled down.

Watch the beginning classes for the people who ask the most questions in the most detail.  Figure out who you think will become your ‘Power Users’ to include in the new classes.  Talk to them in advance to get an idea of what they will need.  Figure out how many of them can go into the same class.

These are the people that will figure out how to drag the last penny of profit out of what you currently have.  They will need data; all they can get, and more if possible.  They will need access to the system; more than the IT department currently provides for them on the standard templates.  They will need instruction on what other departments do, and how that relates to what they do. 

We spend so much time on teaching the basics.  Many classes have to go at the speed of the slowest user.  This won’t allow the best use of the software, and won’t create that immediate ROI that was the biggest reason for the software.  Spend a little more time and attention on the best and the brightest.  They are the ones who will have the biggest return on your investment.  They are the ones who know that it’s a global world and Technology makes it happen.

Comment with your stories of how users stretched the possibilities of your new software and how you had to develop new training to keep up.

ERP Access – Getting Things Done 03/26/2012

Posted by TBoehm30 in Database.
Tags: , , , ,
1 comment so far

I need 20,000 products changed.  Can that be done this week?

If you went through the normal ERP screens, that would take forever (at 5 seconds each, that is almost 28 hours, or 3 ½ working days).  Who could spare that much time to get an important, but non-priority, project done?  Who would even have the patience to do that.

For most ERP systems, you wouldn’t have to worry about it taking up over 3 days.  This can be done reasonably easily using an import/export process.  You export the existing data and put it on a spreadsheet so that the new data can be entered easily.  Then, you save the spreadsheet in a format that can be used by the ERP system.  Importing the new data should be simple from there.  It can be done in just a few hours.

Even better would be someone who has direct access to the database.  Give him the raw data and let him create a quick query or program to insert the right data into the correct fields and tables.  That could be done in under an hour with the correct knowledge, skills, and access.

Who do you give that type of access to?  Who do you trust with the ability to make any type of change they want, without additional passwords and auditing?  Who would have both the access to make the change plus the knowledge of the risks of performing the change?

I have worked with many SMBs where the IT groups are great at some problems.  They can reset your password, diagnose network issues, and sometimes even troubleshoot the ERP.  Some problems, however, require more assistance than the IT department can provide.  Changing data in the database requires the knowledge of how fields are linked together and why.  You don’t want to permanently screw up the database because of integrity issues.  Normal databases have tables that should be linked together so that no data is repeated.  Most Normal databases don’t actually follow that to its final conclusion where absolutely no data is repeated (1NF to 6NF), so changing one table without the other might do some serious damage.

There is also a security issue.  If they can make any changes they want, what else can they do?  Would they be good enough to create new records?  Could they create the necessary records that would automatically pay someone some money?  Could they redirect money to themselves?  Some of those rules to separate duties are just for that purpose.  This project would definitely break those rules.

But, now we are back to having to manually update 20,000 records.  What do you do?  This won’t be a one-time occurrence.  You know that next week, someone is going to find another tweak for 20,000 records.

This is where you need someone trustworthy to work outside some of the rules.  You need someone who understands the data, has the access, and has the confidence to make changes to a production database.  Without that person, you are stuck with manually updating 20,000 records. 

You need someone who is good enough to say ‘no’.  If he can say ‘no’ to the boss when asked to make a dangerous change, then you can trust him with the access to make the important changes.  That is the deciding factor in trusting someone with access outside the rules.

Sometimes someone will ask for a change that seems logical, but could produce serious side effects to the system.  You need someone who can stand up, even to the boss, to say ‘no’ that won’t work.  Hopefully they are good enough to find a workaround, but the key is saying ‘no’.  I have worked with too many IT people who have a little knowledge, want to look good to the boss, and end up wrecking everything.

Another helpful tip is to test everything in a testing environment.  Don’t test in Production.  When you are hacking into the database to make a change, you need to double check everything.  Make the change in a test environment and then use the data.  Create some Work Orders, or Purchase Orders; solve some cases, or redirect calls.  You need to do regression testing on those changes.

If you don’t have someone at your company who is that good and that trustworthy, then good luck fixing the products by hand.  It should only take a couple of days without sleep. 

Tell me about your large tedious project; did you hack the system to fix it quickly, or have to spend days doing it the hard way.  I’d like to hear your stories, because it’s a global world out there and technology makes it happen.

Building an ERP team 02/29/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , , , ,
1 comment so far

Half the team wanted to delay, half the team wanted to move forward with the existing schedule.  What could we do?  We didn’t want to make anybody so mad that they would quit the project, or worse yet, quit their job.  If the team as a whole couldn’t agree, who would stand up and be the bad guy to delay the project?

This was the dilemma I was in recently.  We were doing a dry run for the go-live of an ERP implementation.  Corporate was already using the system, as well as a few other locations.  This last team to join the system was not ready; they were way behind schedule.  However, they didn’t understand what they were missing.  They felt like they had more important projects to concentrate on and the ERP project was getting in their way.  They just wanted it to be over; put them on the live system and work out the bugs later.

All of the meetings with this company so far had been as a team.  We made positive decisions with everyone’s input where everyone could agree at the conclusion of the meeting.  The other locations had seen some setbacks, but everyone had seen the need for a delay or change in the project.  We had always been a solid team who understood the decisions made.

This was different.  The on-site team wanted to go-live, no matter the consequences.  There are always problems at go-live; we should just handle them as we get them.  So what if we didn’t understand all of the setup codes now, we can change them later when we figure them out.  All of the reports won’t be ready, but every group had needed new reports after go-live.

The problem, of course, was one of risk.  If this one group couldn’t close their accounting in a timely manner, corporate wouldn’t keep the books open just for them.  They had several other sites to think about, and they can close their books on time.  Closing the books quickly, each month, is important to a public company, and it is one of the reasons we were implementing the ERP system.

The on-site team thought that if something went extremely wrong, we could just figure out everything on paper.  They actually said that.  A multi-million dollar public company writing their monthly reports using paper and a calculator.  I can see it now.

The manager on-site wanted to know what problems would cause them to not be able to close the books at the end of the month.  If we could list out all the glitches, difficulties, snags, hitches, or complications, then they would just avoid those and be successful.  It was a great strategy for him.  We would come up with a list of problems and then if we missed one, the problem would not be his fault.  He wanted to put the blame on everyone else if there was a problem.  Let’s just go-live now and get this stupid project behind us.

The rest of us in the room wanted to delay the project.  Give them more time to figure out what is going on.  Extend the schedule so that they can keep the doors of the factory open, and still spend some quality time on the ERP project. 

The problem is that we needed to work as a team.  How do we come to an agreement when we are on completely different sides of the same coin?

We gave them another couple of weeks to ‘catch up’ on what had already been scheduled.  To their credit, they worked extremely hard to get it all done.  I was getting emails at 3 in the morning.  Unfortunately it was too little, too late.  When the new deadline passed we were at the exact same spot.  Most of us wanted to delay the project, but the team on-site didn’t understand why they couldn’t just proceed.

I actually practiced my bad-cop speech.  I stood in front of the mirror and explained why proceeding down this path was a bad idea.  When we came to go-live and had to give a thumbs-up thumbs-down vote in front of the CFO, I would have to vote thumbs-down.  That is what I would have said had we gotten to that point.

The director of IT beat me to it.  He said in plain language that the deadline was missed; it’s time to change the schedule.  Thank goodness.  Everyone agreed at that point, even if the on-site manager only agreed under protest.

Going forward, I need to get them to understand that their job is to convince me that they are ready.  It isn’t just to go through the steps needed to finish the project.  There are people who are going to evaluate their readiness at the end of this project.  We will have help in deciding whether or not to go-live, based on their performance.  If they can understand that, then we have a shot at once again working as a team and getting the job done.

Anyone else have some fun stories about getting a team to work together?  Tell the world about the time you worked with a group to come to the conclusion that It’s a global world and Technology makes it happen.

ERP implementation can be successful if… 08/27/2011

Posted by TBoehm30 in ERP.
Tags: , , , , , ,
1 comment so far

This is a special contribution from one of my Tatum colleagues.  See below for a short bio on Dan Gingras.

If there are three letters which can wreak fear in the “c suite” it’s the letters ERP.   Enterprise Resource Planning will bring visions of costs overruns, schedule delays and general havoc to most company officers, and with good reason;  most ERP Implementations fail to deliver the benefits promised in the sales cycle according to numerous studies into the success of these projects. 

It doesn’t have to be that way though.   We’ve studied these implementations for decades, and the causes for these substandard implementations are well known and widely documented, so why do we still have unsuccessful implementations.    The key to these failures is that there is a disconnect between what we know and what we actually do.  So let’s review what we’ve seen in the ERP implementation marketplace over the past few years.

•  Lack of Top Management Commitment

Clearly this is the most significant contributor to project success, and unless the top officers are part of the project from the beginning it’s a sign that you’ll have problems.  The litmus test for commitment is whether the top officers are willing to demand that the top salespeople change to best practices as part of the implementation.  When the salespeople say “our customers won’t support that change” the CEO usually will cave.   Unless there’s significant pushback by the CEO, you can rate the commitment as “lukewarm”     It’s easy to say, but it’s difficult to execute change.

•  Inadequate Requirements Definition

Failing to understand the detailed requirements accounts for nearly 60% of ERP implementation failures, based on our experience.  Creating an adequate Requirements definition document for a system selection is an effort that takes months and involves most of the company.  There are dozens of functions within most companies, and within these functions there are hundreds of processes.  Each of these processes can have hundreds of elements, so the requirements can be extremely complex, and unless each feature/function is properly defined, you will not find out until you well into the implementation, and generally this will require some pain (read: customization) to fix.  It’s important to understand not only what is done, but what is possible, and this requires a thorough understanding of the ERP marketplace.

•  Poor ERP Package Selection

How many ERP packages are selected based on a demo or set of demos done by the software vendor?   Too many, because unless the demo scripts are based on the requirements definition study, and scripted to follow the desired processes of the company then they’re not of much value.   A demonstration of a system should represent the business process of the company exactly.  If you make cement, than watching a demonstration of the software make a bicycle isn’t going to show you how the system will work in your business, and users who see the demo will be distracted by features, functions and the user interface, which may not be applicable to your business.   The script of a demo must reflect the requirements gathered in the requirements gathering phase of the selection.  If not, then don’t waste your time.

•  Inadequate Resources

Implementing a new ERP system involves re-designing processes, sometime from scratch.  Do you really want your processes designed by anyone less than the best person in your company?  Most ERP implementations involve creating a core team of full time employees to design, test and train.  Unless you pick your “best and brightest” you are short-changing the organization.  We like to tell our clients that they should pick the future leaders of the company, because this core team is going to completely re-engineer the company and it will be the group who knows all the new processes the best since they designed them.   Taking the ‘best and brightest’ out of the company for a significant period of time is expensive and painful, but it’s the way to succeed.  Short change the resources, or select less that the best at your own peril.   Easy to say, but tough to do.

•  Resistance to Change/Lack of Buy-in

“Paving Cow Paths” as Michael Hammer of “Reengineering the Corporation” is pretty easy to do, and it generally involves getting the new software to do what is being done now.   It’s difficult to comprehend why a company would buy a new system to improve its processes, and then try to get it to work exactly like the old system, but it happens every day.  Remember that the “institutional knowledge” or best practices of hundreds or thousands of other companies are  “baked into”  the new software, and you should take advantage of that knowledge by changing your processes to fit the new system.  Yes, it’s painful, but it’s the best way to succeed.

There are a number of other keys to success in implementing a new ERP system, but these are the ones we see most often, and the ones which are most troubling since they’re so well known.  The difference between knowing and doing is surprising and troubling, but it continues.    Share this list with your team and discuss how you can avoid the gap between knowing and doing.

A special thanks to Dan Gingras for this article: 

Gingras is a Partner in the New England practice of Tatum.

He has 25 years of experience as a technology executive with extensive qualifications in all facets of project life cycle, from initial feasibility analysis and conceptual design through documentation, implementation, user training and enhancement. He is well know as the author of numerous articles in trade magazines and writes a regular column for CIO Update.

Conference Room Pilot Techniques – The Dry Run 01/25/2011

Posted by TBoehm30 in Project Management.
Tags: , , , , , , ,
1 comment so far

The final practice run through that you perform when getting ready to implement your new software system is called the Dry Run.  This is when you make sure that there are going to be no surprises.  You make sure that you’ve crossed all your ‘T’s and dotted all the ‘I’s.  Everybody knows what they are doing and when to do it.

 Order Matters

The order in which you proceed could make a big difference to the success of the project.  I recently practiced a process to load inventory into a system that already had work orders loaded.  Because the system was supposed to automatically allocate inventory when work orders are created, the inventory was allocated as it was loaded.  This was not what the client wanted.  Because they had only practiced loading inventory and work orders separately, they never saw the interaction of the two processes until I helped them test.  We determined that we always needed to load inventory first to avoid the issue.  Later, we found the checkbox to turn off the auto-allocation during the load.

Had they never done a full Dry Run, they might not have seen this problem until it was too late.  Once the data gets loaded into a Production environment it gets difficult to remove without starting over completely.

Practice

The people involved in the implementation need to have hands on practice performing their responsibilities.  They need to have demonstrated to the team that they know what they are doing.  One time I watched a lady using the new system who had no idea what she was doing.  She had previously reported practicing with the system and putting the time in to learn her job.  The difference at the Dry Run was that nothing was scripted out for her.  She had to figure out where to go to find work to do; no one had written down the order numbers for her to easily find.

The important thing about practicing for a go-live on a new software system is to demonstrate your knowledge.  You need to be able to perform under pressure while others watch you.

Is it fully setup?

There are numerous parameters and setup data that will need to be transferred from the test environment into Production.  You need to make sure that you understand that process, that you’ve covered all the parameters or setup data, and that those items have been tested.  A full Dry Run will ensure that the entire process to copy data has been practiced and can be done again successfully at go-live.

Balance the Reports

The Dry Run is a time when you should run actual data through the new system.  You can compare reports from your old system with the reports from the new system.  Can you make them balance to the penny?  Does the data go to the general ledger correctly?  Does the new system handle the one-off exceptions correctly?

Communication

Management should be involved in the Dry Run.  You can prove to them that the project will be a success.  You can gain the confidence of management. 

You probably worked with a core team on the project.  That core team should know all about the new software system.  If there are others who need to understand or learn about the system, then they can be included as well.  You may have scheduled training for another time, but the Dry Run is a time when all modules of the software should be shown on the big screen.

What else can go wrong?

There are far too many ways that an IT project can go wrong.  The Dry Run is the final opportunity to prove that you have covered all the risks.  Try to think about what could go wrong and mitigate the problems.

Have your Pilots gone well, or have they spiraled out of control?  I’d love to hear your stories – especially if you understand that it’s a global world out there and Technology makes it happen.