jump to navigation

Test Before Installing an Upgrade 10/29/2010

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

A new risk to your software is coming; it is time for an upgrade.  Remember when your system was new?  Remember that huge project to implement the software?  Now, it seems, you don’t know how you survived without it.  Don’t take unnecessary risks; make sure you are prepared for this upgrade.

An upgrade may just be a small change, it could be a large change, it could be a few patches, it could be a brand new user interface, and it could contain brand new modules.  No matter the size, you want to make sure that this upgrade doesn’t break any critical processes before you install it.  Even if you get experts to put it in, you will want to do some testing first.

There are several ways of getting an upgrade installed.  You can get the software company to do it for you.  This can be included in your support contract, or you might pay extra for it.  You could hire a consultant who is an expert on the software you are using.  If you are going this route it is best when you have a working relationship with the consultants so that they understand your business as well as the specific software.  You can also do it yourself.  Many software companies provide instructions for how to put in the new code.

The first step, however, is always going to be testing.  A good software company will test the upgrades themselves.  The reason you pay money for the software support is so that you can trust the software will do what it is supposed to.  If the software doesn’t do what you want, you can call the company for help.  A good consultant will schedule in plenty of testing before an upgrade.  They should know what the upgrade is meant to improve, and with a good understanding of your company, should know what to test.  Of course, if you do this yourself, then testing should be second nature.

There are several areas to test before upgrading.  Any customization to the software should be at the top of the list.  Since you changed the default behavior of the program, you hope that the underlying logic didn’t change.  If it did, you will need to either remove your customization, or re-create the custom code on the new version of the software.

The next areas to test require a little bit of study.  Usually the software company will publish documentation on the changes.  You should review those changes and mark any functionality that is critical.  Sometimes the documentation can be technical and confusing; if that is the case, simply write down the module, area, functionality, or process that needs to be tested. 

Last on the list of testing is any other area you think should be tested before an upgrade.  I have seen people just do a full validation before any upgrade. 

During the implementation phase for this software, you documented your business processes.  Hopefully, you had a documented test script.  Save those!  If you have good test scripts, they can be used again for this process.  If you don’t have test scripts, then make them now and you can use them for each upgrade.  Spend some time on those scripts, they are valuable.  If you have a good set of test scripts, then you understand your system; you have the ability to validate your system and your data.

Make a list of all the functionalities that are important to you.  Start out with broad categories such as A/P, A/R, Manufacturing, or CRM.  Then narrow the focus to specifics such as returning merchandise, or receiving a complaint from a customer.  If you document the steps you take for each of these specifics, and make screen shots of the results, you are on your way to a great set of test scripts.

Before letting anyone upgrade your software system, make sure you back up all of your data.  Make sure you can restore yourself to the previous version in case catastrophe strikes. 

If you have properly tested the new software, then you shouldn’t run into any surprises.  Remember, it’s a global world out there and Technology makes it happen.

Running a Conference Room Pilot 07/10/2009

Posted by TBoehm30 in CRM, ERP.
Tags: , , , , ,
6 comments

Whenever you are installing a large software system, whether it is CRM or ERP, or any other system, if you are part of a plan to integrate the system, you will need a pilot. The conference room pilot is a time to practice what you will do after go-live. It should be a safe environment to explore options and ask questions. It should be a time to document user processes. The conference room pilot needs to give everyone the confidence that the project will succeed.

My current project includes 2 conference room pilots plus a dry run for each business unit going live with the system. Each pilot is scheduled for a full week, 8 hours per day. The first pilot could have been better. Everyone realized that they were behind in their plans and were not ready. The second pilot went much better. People realized that they needed to work harder, study more and practice every day. They had been motivated by the first pilot to figure out what they needed for success.

The first thing to consider in running a conference room pilot is where to conduct it. As the name implies, you will need a large room. People from different areas will be coming in and out of the pilot, plus a core group who will always be there. You should expect one or more consultants from the software vendor, your implementer, or other companies included in the project. The room needs to be able to accommodate the full compliment of people plus room for storing their things, putting snacks on a table, etc.

Of course you will need the right technology in the room. I suggest having at least 4 computers wired into your network available for general use. Make sure there are enough cables and outlets or wireless for others to use a laptop. Have a projector so everyone can watch what is going on.

If you expect some people to be in the room all day, it might be nice to provide drinks or snacks to help them make it through. Mints or gum can help them stay away during that occasional drowsy period (although most of the day should be very exciting).

I created a general schedule for the first pilot. This included the discipline area and the general tasks to be completed. The schedule was set at four hour intervals or two main sections of the day. This allowed the users to show us what they knew, but allowed plenty of time to ask questions, experiment, and figure out how to run the system.

The schedule for the second pilot contained much more detail. I scheduled events to each hour, expecting people to know what they were doing and how to do it. Each person who needed to run the computer connected to the projector knew exactly when to be in the room and how they needed to prepare.

I also created data in advance so that each step would have the necessary background already in the database. For example, to manufacture a product, they need inventory to consume. I created the inventory in advance. To receive something into the system, they needed to already have a purchase order approved. I created and approved numerous types of POs into the system.

Everybody brought their document business procedures to the room. When it was their turn to ‘drive’ they followed the documented procedures creating each item on the list. We had the vendor’s consultants as well, and there was plenty of time for questions. Predictably, we had some people who needed more help than expected. Those sessions would run over, and delay the entire schedule.

To better accommodate those people, we had a second room setup. That room was just as large as the main room, with computers and a projector as well. We had groups of people meet in that room to go over issues and solve problems. Because we had more than one consultant from the vendor, we could easily split up into functional groups and get the full value of their time.

The write-up from the second pilot included the steps we still need to take for success. We have several groups who will meet more often to practice with the software. Some of them may do ‘mini-pilots’ in the same room already setup. We know that security is still an issue, but hope to practice with that during our dry-run.

Some companies will try to run parallel systems. With the changing technologies, that is becoming less valuable. It is very difficult to compare diverse systems, so people end up spending too much time chasing down issues that are not problems.

With a little preparation the conference room pilots can be very valuable. If people know what to expect and how to prepare, they will be able to show that they are ready for go-live. Seeing their people use the system in a realistic setting will allow the core team to have confidence in their people. This is the environment that will keep the company on the road to a successful system implementation.

We all know that it’s a global world out there and Technology makes it happen.

ERP Implementation Plan 03/16/2009

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

Big Bang or Phased Approach
I firmly believe in the phased in approach to implementing large software systems.

When I was working with HP, it split off part of the company to form Agilent. Part of Agilent got bought by Philips. Suddenly our group had to get off of systems run by HP because we were now competitors. We had no choice but to go big bang. Even then, the project was delayed over a month paying big bucks to HP for the privilege.

Doing everything at once meant that the new system experts were spread very thin. They were needed for all problems spread over multiple departments. If there were problems, it was more difficult to find the root cause because so many different activities were going on. It meant that the new system had to accommodate all of the new users at once, and we could never see how the system looked with fewer people.

The Plan
Now I’ve got to guide the choice on how to implement a new ERP system. The company is going to use it for accounting and manufacturing. There are 4 distinct business units in different cities. I am going to suggest going with accounting first at all locations, and then merge in manufacturing as they are ready. Much of the plan can be done in parallel because the personnel for the different functions are separate.

There are so many questions to answer in creating that plan. How much is the minimum time a phase will take? How many business units can run in parallel? How many people will we need to be systems experts at each location? If we stagger the go-lives, how quickly can we set them up? How much testing is necessary before go-live? How many people will we need for the pilot projects?

We have talked quite a bit about the possibility of running the new system in parallel with the old system. The company has a history of successfully running their upgrades in parallel until they are confident of success. The customer we visited who were already using the new ERP system told us that running parallel was key to their success. My research tells me that running parallel is no longer done.

Running in parallel is where you use both systems for production data during a specified time period. You then compare results from the new system with the old. If they match exactly then you have confidence that you can turn off the old system. If the data doesn’t match, then you have to figure out why. Running parallel is too expensive, too time consuming, and doesn’t add enough value. The results are difficult to compare for different systems. There is too much data to control, where some of the new data wasn’t used in the old or vice versa. Too many people won’t take the new system seriously if they still have the old one to use.

The project plan for the new system will include several ‘conference room pilots’. These are what will replace the process of running in parallel. Hopefully, that will be good enough for this project. It will require serious testing, and significant follow through with any issues.

Next Steps
The project manager from the vendor will be here on Wednesday. I hope that we will be able to setup a timeline then. That is when the interesting stuff begins; because it’s a global world out there and Technology makes it happen.

10,000 hours 03/06/2009

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

I will normally limit this blog to technical issues directly within my experience. I will avoid any long rants about traffic, poorly organized restaurants, spoiled food at the grocery store, and people who talk to much. However, I have just found out the secret of success. Let me say that louder:

The Secret of Success
The secret to becoming an expert in something turns out to be 10,000 hours. That works out to 4 hours a day, 5 days a week, for 10 years.

I am listening to the new book Outliers by Malcolm Gladwell.

Let me digress for a second with a quick talk about listening to books. I am a member of Audible.Com, so that I can cheaply download books to my iPod or iPhone. I listen to them on the way home while fighting traffic (insert your own traffic rant here). It is a fantastic service in that they keep my library as a backup, so I can re-load books on newer computers, or ones that I’ve fixed. I listen to books for self improvement, not the Science Fiction books I normally read.

He describes many people, with different job descriptions, who became successful because of their preparation. He claims that success has less to do with talent than simple repitition. Bill Gates had tremendous opportunities for programming when he was young; he got in his 10,000 hours in time to take advantage of a new technology. The Beatles put in their 10,000 hours on stage. Look at professional piano players, violinists, hockey players, the list goes on.

For anyone out there who still has the ability to focus 10,000 hours of their life on a single activity, I say “Do It”. This has got me incredibly excited. Want to know why I am such a good programmer? I got my first computer at 13. I learned Cobol, Pascal, and RPG in high school. I majored in Computer Science in college, and then got my first real job doing programming support. I easily put in 10,000 hours.

I am encouraging my kids to think about what they want to do. My daughter might be an author, I told her to write. It doesn’t matter what she writes, it will get better over time – 10,000 hours worth of time.

If you are older, have a family, a mortgage, and adult responsibilities, you may not think you have time for that 10,000 hours. It does seem a daunting task. However, in this economy why not try? Even a little preparation has got to be better than none. Who knows where it will take you.