jump to navigation

ERP Training and Power Users 06/28/2012

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

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 – Follow-up Training 04/27/2012

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

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.

Conference Room Pilot Techniques – The Handoff 09/30/2010

Posted by TBoehm30 in ERP.
Tags: , , , , , ,
add a comment

In a Conference Room Pilot the object is to practice the process.  You get a group of people in the same room to use the new software and make sure that you understand how to use the system.  One of the most important aspects of this meeting is to practice the handoff.

There are so many processes at any company that require more than one person to complete.  Many processes take more than one department.  At what point does a person know to start their part of the process?  What does a person do at the end of their job to let someone else know to begin theirs?  That is what the handoff is all about.

A good ERP system will have a screen that a user can go to that will show him all of his current responsibilities.  This needs to be fully tested during the Conference Room Pilot.  You need to make sure that when things go right, the screen shows all that it should.  You also need to test that the screen still shows the next steps when things go wrong.

Some ERP systems will send a notification, most likely email, to let someone know that they are next in line for the process.  Testing email in a software system can be tricky, but definitely worth the extra time.

Sometimes the process will be to run a query showing you what still needs to be done.  The queries are good to test, but also show the user what they will see on a regular basis.  When the process isn’t followed correctly, you will need to know if the right records show up in the query.

If users don’t know how to find their work, then their work won’t get done.  The best time to evaluate whether they know what they are doing is before you go-live with a new system.  The Conference Room Pilot will test the process and test the people.  If the process isn’t as smooth as it could be, then you should have plenty of time to fix it and then have the users practice.

The other side of the coin is important as well.  When a user is done with his work, what do they need to do to make sure the process is completed?  It is not good enough to finish their own tasks, they need to do what is good for the company as a whole.  That means making sure that the processes are finished correctly.  It means that the person creating a payment approval alerts the person printing the checks.  It means that the person receiving material notifies the person who matches the purchase order.  This should be documented and practiced in the Conference Room Pilot.

Take a look at what processes your company uses that include a handoff.  Could the process be improved by better or easier communication?  You’ve got Sales Orders that have to be filled, then invoiced; eventually the payment has to be recorded and possibly finalized to a General ledger.  You’ve got Purchase orders that have to be ordered, received, and then paid for.  You’ve got inventory that has to be moved around and possibly inspected.  For manufacturing plants, you’ve got plenty of processes around the routing of materials.  For distributing companies, you’ve got to get the shipping process exactly right.

Technology should have a good way of notifying users that there is work to be done.  Users should understand the process of making sure that tasks are fully completed.  The Conference Room Pilot is the place to make sure that the process works, it is documented, and that people understand what to do.  It is good practice to be ready for go-live; now is the time to test the process for when things work and when things go wrong.

The Conference Room Pilot is a safe place to get processes in order.  It is the time to get used to the new software system.  Sometimes change can be difficult and users need time to practice without any pressure.  Project Managers should schedule plenty of time for the Conference Room Pilot because they know that it’s a global world out there and Technology makes it happen.

Lessons Learned 06/17/2010

Posted by TBoehm30 in Project Management.
Tags: , , , , ,
add a comment

I recently participated in a meeting to discuss the Lessons Learned during the recent ERP implementation.  Many projects skip this vital step because they don’t have time, or after a successful implementation, what’s the point?  This meeting turned out much better than I thought it would, and we actually documented a list of items to review for the next projects.

The project ended successfully, so we didn’t have to point fingers blaming anyone.  I have been to plenty of those types of meetings where nothing gets done except making people feel bad.  When it was my turn to talk, and I suggested improvements to the way we prepared for the Conference Room Pilots or Dry Run, I prefaced it by reiterating the successful nature of the project.   I couldn’t pin blame on lack of preparation because in the end everyone was prepared enough.

People did listen to the suggestions.  We still have 2 Business Units that will go live on the new ERP system, and they now have on idea of what issues they need to review to improve their chances of success.

The project manager for the software vendor attended the meeting.  During the project, there were times that he became defensive about his software.  He would come up with ‘reasons’ why it wasn’t their fault, or get upset with us about our tone.  During this meeting, however, he listened to everything in the spirit of constructive criticism.  He didn’t get too defensive on the phone and said that he would take our comments to an appropriate resource.  He responded in email with extra documentation that could have helped during the project (we actually had it, but some people didn’t know that), and will definitely help the last 2 Business Units in their project.

We spent some of the time patting ourselves on the back with the things that went well.  We didn’t just talk about the things on the project that went poorly or could have been done better.  We put in extra hours over the weekend before go-live and were totally prepared for that work.  Talking about that work and reminding everyone how great they did felt so much better than focusing only on the problems.  Reviewing the items that went well made everyone feel good about the work they did and prevented deep depression over our faults.

We concentrated on the actions we could have taken, or will take next time, to do better.  We tried to direct the discussions toward constructive criticisms instead of blame or complaints.  When the conversation turned more negative we directed it toward a more positive note.

I think everyone walked away from the meeting feeling good.  We documented a full list of items to keep in mind for the next projects.  Lessons were learned, and they will stick with those who learned them.

Putting in new technology is not easy.  We need to make sure we get better at it by improving each time we do a project.

For your next project, make sure to schedule time for the Lessons Learned meeting.  It will improve future projects, and people will be more comfortable with taking on the responsibilities of the project. 

While we didn’t create a list of questions beforehand, that would have been a good idea.  Send out a list of open-ended questions to prepare people for the meeting.  “What worked best?” “What could have worked better?” “What prevented goals from being achieved?” etc.

If you need to include many people in the Lessons Learned process, then send out a survey.  This could be done over email if you properly include everyone, and make sure that you follow up with summaries.

You may know it, but others may not, so spread the word: It’s a global world out there and Technology makes it happen.

What is a bug? 04/02/2010

Posted by TBoehm30 in Software.
Tags: , , , ,

What is a bug? Of course, I am talking about a software bug, and not the 6 legged variety. To me a bug is any quirk of the program that I find should and could be done better. That puts the entire definition in my hands. I am the one that gets to define what is and isn’t a bug. As the user, I get a say in how I think the program should work.

I don’t always get my way. Recently, I got into an argument over some software that wasn’t performing according to my needs. The problem was minor, the workaround was easy, and the reason for its existence was obvious. That doesn’t change the fact that this was a bug (see the definition above). The software vendor took offense at my criticism and explained that it was not a bug and that the underlying code is, in fact, written correctly.

Wikipedia defines a bug as:

A software bug is the common term used to describe an error, flaw, mistake, failure, or fault in a computer program or system that produces an incorrect or unexpected result, or causes it to behave in unintended ways.

By this definition I have to admit that he was right. Their system was designed by the software company to meet their requirements. Since he insists that the result meets their requirements, then there is no error, flaw, mistake, failure or fault.

So who is right?
This argument goes on all the time. Users often incorrectly think that something is a bug in all kinds of situations:
It is their own fault (PEBKAC).
They haven’t read the manual and therefore don’t understand the software.
They want the software to run better, and suggest an improvement.
They need new functionality in addition to what they’ve got.
They don’t like the output of the system, but they don’t have a way to change it.
The system isn’t as intuitive as it could or should be.
(Yes, some of these overlap; No it is not a complete list. Feel free to add to it in the comments; I’ll add them later if they are good enough.)

The software vendor can reply to almost any “bug” report that it fits into one of the above categories. Unless the bug is something obvious like “the computer crashes when I enter a 10 digit number in the text box prompting me for a phone number”; the vendor can come back to deny that it is a bug.

If the vendor actually does call something a “bug”, then they will be forced to fix it. If they can deny that is a bug then the cost of a fix can be avoided or at least delayed. Vendors have several choices in arguing against calling something a “bug”. They can say that it is not reproducible, so it must have been the computer. They need more information because they can’t reproduce in on their own systems.

My favorite is the SWAD excuse – System Works As Designed. This means that what I am seeing, not liking, and getting frustrated with, is not actually a bug. It means that the software programmers deliberately set out to annoy me. It means that they don’t really care that a simple peon like me has an opinion about their gigantic company. They don’t believe that I could have an inkling of an idea about how hard it is to write enterprise software; how difficult it is to please everybody.

The problem is that I do have a technical background. I do have an idea how hard it is to write large software programs. I do know the difference between a bug, a design flaw, a feature request, and a user problem. I’ve been on both sides of this argument. I’ve been the one who explained that the system works as designed because I designed it. I’ve been the one that denied the bug until it was reproduced in front of my face. I’ve tested software to report bugs. I’ve also used plenty of good and bad software.

If a user was asking for their accounting software to automatically search the internet for recipes, that would be a new feature. It is completely understandable for software vendors to reject those ideas as being too big a project to take on, and too costly an investment.

However, if the software allows the user to re-order the dropdown lists in the system, but ignores the text for some of those lists, that is a bug. Why is it up to the user to know that he shouldn’t use the re-ordering functionality on some lists? The software should either prevent the user from making the change, or allow the change and evaluate the choice in the dropdown correctly and dynamically. The latter suggestion would be my preference. It would make the software more intuitive, easier to customize, and better for everyone.

Reading this, you might get the impression that I recently found a bug in some software, but was rejected by the vendor. I like my software to be usable, intuitive, consistent, and complete. Most of the time software we use works well. Sometimes we have issues with it; and sometimes we report our issues.

All I really want is to be acknowledged. I want the vendor to either explain to me how I can accomplish what I am trying to do with a workaround, or agree to put this bug on a list that will eventually be fixed. I have no illusion that my little problem will ever be important enough to be completed. I don’t expect immediate results. All I want is for the people I am working with to recognize that a bug is defined by the user, and work to resolve the issue, not ignore it. How about you?