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.

Advertisements

Why do you need ERP System Testing? 05/23/2012

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

Testing is one of the first items that are removed from a project when time becomes tight.  Many people wonder why they have to spend so much time doing formal testing when they have spent so much time training with informal tests.  They have spent so much time with the new system that they just know it works.  What is the point of spending a large amount of time on formal system testing?

First and foremost, you need to validate that you are getting what you think you are getting.  A new ERP system is a large complicated piece of software.  Just because individual sections are working, doesn’t mean that each module is sharing data the way it should.  A plan for system testing should include many of the core team, so they can see the larger picture.  You also need to be sure that the right communication is happening between team members.

You need to make sure that when a PO is created and received, that the inventory is added correctly and the journal entries are made appropriately.  You should review the documents and reports generated from the process to make sure that everybody is satisfied with the results.  When the PO is tested separately from the accounting module, it seems to work fine.  However, did anyone from accounting notice that the manufacturing group has automated the POs for inventory differently than expected?  This would be found in System testing with good communication between core team members.

You need to be absolutely certain that each process is testing using the same parameters.  There could be hundreds or even thousands of parameters in a good ERP system.  These parameters should be set based on the way your company does business.  For example, FIFO, LIFO, or Standard should be set to account for product costs.  I have seen software fail because no one realized that parameters were different than expected, or were changed during go-live.

The CYA reason for system testing applies for consultants and/or public companies.  A team who delivers a working ERP system takes a large risk of someone coming back with complaints.  Users can always find something to complain about.  A full, well documented, system test will reduce the risk for the implementation team.  If they have tested every scenario possible, then any complaints should already be documented and signed off. 

Auditors may be allowed to review the implementation process, especially if something goes wrong because of the software.  A good system test would be enough to hand over to show that you did everything you could think of to prevent problems.  When problems occur, you should be able to point to the system testing documentation to show that something new or different has occurred to cause the issues. 

Problems that arise after the system has been in use could become very large problems.  It is much better to find them early on.  A small problem could grow into something much bigger over time.  A problem that is found after a time lag will be more difficult to find and could be more difficult to fix.  System testing should be designed to follow all your processes to a logical conclusion.  If you are using the system for accounting, then journal entries and account balances should be watched during system testing.  If the software is used to run a call center, then you need to run rollup reports containing all possible call types.

IT projects are constantly delayed and have scope cut to meet deadlines or budgets.  A user will be much more forgiving of a delay in a project than he would for bugs in the software.  A problem that should have been caught in testing will be remembered far longer than any scope issue or delay.  Users will grumble and gather to complain about the software, keeping the errors at the top of their mind.  Delays, however, will be forgotten as the software finally comes out to make their lives a little easier.

A good system test will prove that you have done your job well and completely.  You can be positive that the system meets the requirements you were given, and you have documentation to back that up.  You will be able to move on to the next phase of the ERP system, or move on to your next project with confidence.  You know that it’s a global world, and Technology makes it happen.

Have you been involved in a project where testing was shortened, or removed, to the detriment of the company?  Leave your comment below.

ERP – Follow-up Training 04/27/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , ,
3 comments

I spent last week in another System Administration class.  There were 9 other people in the class with me.  Most of those 9 had taken the class at the beginning of the project, but now they understand the system so the class actually made sense.

The first time we took the class, it was like drinking from a fire hose.  We saw what the system could do, but there was no possibility that anyone walked away with the ability to fix anything immediately.  We took our notebooks filled with pre-printed material, our extra notes and went home to practice what we learned.   Hopefully, we at least got the big picture.  It would take time to learn the details.

I had taken the class previously as well.  Since I have been heavily involved in the technical issues of this project, I knew most of what we talked about during this round.  I was only there to make sure that when we talked about something that was customized, or company specific, I could lead the discussion.   Several times, I had to interrupt to say that this subject didn’t apply to us, or explain how we had already implemented a particular feature.

During the 4 day class, we covered numerous topics.  Every now and then I would glance around the room to notice how much people were paying attention.  The class was usually divided in their attention since they are the entire technical team for a company covering 4 states.  I expected some division of attention while they had to attend to other duties.

Some topics were easier to understand than others, and some people had more practical experience with some topics.  I hoped that, like me, people were paying extra attention to the few topics that they did not understand completely.  I also hoped that they listened carefully to any topics that seemed new to them.

I walked away from the class with new ideas on how to use the system to improve the flow of information at my client.  For example, the ERP system we work with has a statistical module for storing data over time.  I had created a few dashboards using real-time data, but now I can use the statistical data to show those same dashboards over time.

This is the training model that needs to be followed for a successful ERP implementation.  Like a good presentation, people need to be told what they are going to hear, then they need to hear it, then they should be told what they just heard.  The plan for a new ERP system should include a plenty of training for all users of the system.  They need at least two official training sessions.  The first one gives them the overview of what they will need to learn.  The second one goes over the same material, but this time the users understand the details.

Between the two training classes, people will need to practice with the new system.  Some of them will design and document the new procedures.  A few users will test out the limits of the system by pushing every button, clicking every link, and choosing every option.  Some of them will go back and not think about the new software until the next class.  Obviously, a good implementation plan will optimize the probability of users going back to practice with the new software.

A third class might also be a good idea to plan.  At some point in the future, users will want to see what else they can do.  They will want to go to a new phase where they wring out every improvement possible.  A class scheduled for a year after go-live is a good time for that one.  Users will have a very good idea of what they are doing, some small ideas for what they want to do, and a big appetite for new possibilities.

The good ones go like that because it’s a global world 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.

The Hidden Costs of ERP – Reporting 01/08/2012

Posted by TBoehm30 in ERP.
Tags: , , , , , , , ,
2 comments

Have you figured out when you will get the reports done for your new ERP system?  Who’s going to do them, how long will it take, and what will it cost?

You’ve got the perfect plan for implementing the new software system.  The requirements have been written, your plan includes 2 conference room pilots, and you’ve got time for practice, time for training and time for data migration.  How about reports?   When does that come in?

Your software vendor probably told you that they’ve got plenty of out of the box reports.  Those are probably great if your company used all standard processes and needed totally generic information.  I have yet to see a place where that works.  You probably have lots of reports that you use today, that you’d like to see recreated on the new system.  Maybe you think the reports will be better in the new system, have you allowed time to create them?  Do you know anyone who can create new reports on the new system?

The new software gives you the perfect opportunity to come up with all of the reports that you think will allow you to control your business better.  You can look at your sales orders by month, quarter or year; you can look at purchase orders, at what products are on backorder.  You can see who your most profitable customers are and who costs you the most money.

How do you forecast all of your report needs?  You don’t know what you need until you need it.  That is why the conference room pilots and dry runs are so important.  You need to use the reports to drive the process.  You need to study the reports generated by the practice data to see if they work for you.  You can design new reports based on the results.  Make sure someone has the time to write the reports.  If you go live too soon after your final dry run, you may not have enough time for important reports. 

Do you need the ability to export into Excel?  Will your people need to analyze their own data in a separate program like Excel?  You need to test the exporting function thoroughly before going to a Production environment.  I have seen weird things happen when exporting; the final column of data comes out completely wrong because it was defined as alpha-numeric instead of a date.  I have seen reports completely fail when the parameters don’t match up perfectly.  Testing will decrease the probability of those kinds of problems after go-live.

Will you have a new programming language or environment for your reports?  Does your new system come with Crystal Reports?  Will you get a new way to present dashboards?  All of the reporting needs to be thought out in advance.  After go-live all issues will have to be solved on an emergency basis and cost so much more.  Now is the time to solve the problems when they can be done during regular working hours at a normal pace, without stress.

Have you been in a situation where a report has to be done on an emergency basis?  Leave your story in the comments.