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.

Spin Off 07/23/2010

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

How does a company chop it’s IT in order to spin off and sell a part of itself?

I just read an excellent article by Mike Gorsage from Tatum about Integrating IT for Mergers and Acquisitions.  In the second half of the article he talks about “Planning for Separation.”

 This got me thinking about when I was consulting with Agilent as they were getting ready to split the company and sell part of it to Philips.  Agilent had just recently split from HP and some of the IT was still, unofficially, shared.  While HP and Agilent were two different companies, there was a shared culture that allowed people to communicate easily.  People at Agilent had come from HP and were comfortable with how things worked there.  Now some of them were being ‘sold’ to Philips and it had to change.

 Agilent had to figure out what IT the new company would take with it.  Some hardware and software would have to be duplicated, some would have to be given, and some would not be part of the sale.  They had to figure out the same thing with the IT team; however it is much more difficult to duplicate a person.

 I was working on their CRM system for the call center dealing with medical machinery.  HP/Agilent (now Philips) produced monitor type equipment for hospitals and doctors.  When the equipment had problems, they called the response center in Atlanta.  The call center would specifically be part of the sale to Philips.

 The CRM system, Clarify (now owned by Amdocs), was highly integrated with the back office system.  Corporate Agilent decided that the back office system would not be part of the sale.  Since Philips and Agilent, along with HP, are competitors in some arenas, the new company could have no access to proprietary data.

 That meant we had to get all of our data off of the old system, into a new system on a very tight timeline.  We had to update our CRM system to integrate with SAP instead of the old HP system.  With the help of some very smart people, we got the CRM system up to speed within our timeline and on budget.  We figured out how to download master data from SAP: the customers, contacts, products, and contracts.  We figured out how to send back to SAP the data it needed for tracking, billing, etc. 

 During the building move we managed to move all of the hardware over the weekend, so barely anyone knew it happened.  The call center is a 24 by 7 operation, so it had to be done carefully and quickly.

 The biggest problem turned out to be migrating data from the back office system to the new SAP system.  The contracts in the legacy system were confusing, not standardized, and big.  Agilent had a large team of people who came up with a plan to pull the data, clean it up, and then put it into SAP.  It would take weeks of processing the data after it was pulled, to clean it up enough to get into SAP.

 Agilent set up the deadline of when to be out of their system.  If the new company missed that deadline and needed continued access for another month it would cost Philips a lot of money.  We missed that deadline and had to extend.  Agilent doubled their fee the next month and would have doubled it again had we needed another month.

 By that time, I suppose, someone decided enough was enough, and called it done.  We had enough data to proceed and make it work.  Since I was not involved directly with old back end system, I have no idea what data we lost.  I can only imagine it was significant.

 With the new company complete, we worked on better integration with SAP, the politics of the new culture, and improving the call center.  Philips had bought several medical companies that would join us and we had to integrate them next.

 Most of the companies’ call centers were moved into our building and so we eventually shared the CRM system with them all.  We shared the phone system, and the other infrastructure that allowed us connectivity to the internet, intranet, and each other.

 Philips wanted everyone to use SAP in the call center.  We quickly did benchmarks and comparisons to show corporate how much extra it would cost to get rid of the current CRM system.  They acquiesced, at least temporarily, to allow the legacy system.  Their idea was still to get rid of it, and that theme was seen in numerous meetings.  We managed to continue the use of Clarify, even against the wishes of some big-wigs at Philips IT.  Eventually it was expanded to other countries around the world.

 The thing that Philips did right was allow the best technology to continue being used, and even invested in its future.  While they had alternate plans, the old systems worked well and could not easily be changed so they didn’t change it.  Their alternate plans were shelved, and new plans created to better the company as a whole.

 Philips had the people who understand it’s a global world out there and Technology makes it happen.

Do you need multiple databases? 02/19/2010

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

Should you setup multiple databases for the company? No matter what your desire, you will always wind up with multiple databases. Whether they are backup databases, training databases or development databases, they will be needed.

The answer, however, is NO. You do not need multiple production databases for your company.

Using multiple database has its allure because it allows you to separate your data. You might have internal security issues which require separation of data and access. You might have reporting requirements which demand information to be segregated. You might have data issues which cannot exist on the same database. The easy, quick, answer is multiple databases.

There are too many problems with creating multiple databases. Let’s walk through an example that demonstrates the problems with the easy solution. You work at a company that wants a new ERP system for its 3 subsidiaries (it could be any database software – CRM, accounting, manufacturing, etc.). You want to make sure that each subsidiary doesn’t see any data from any of the others. You don’t want them poaching customers, or gathering data about the entire company.

You need a system that will work the same for everyone, but protect your security as well. You want to roll up accounting into corporate from the subsidiaries and have visibility from the top down. Multiple databases sounds ideal for that purpose.

Your company plans on creating or buying more subsidiaries in the future. Your plan for each new subsidiary is simple: Bring up a new database. As an added incentive, your subsidiaries use similar IDs for their data and would have to make significant culture changes if all their IDs had to change. [Think about a customer Id. If they don’t share data, then each of the 3 subsidiaries need a different Id for the same customer.]

Talk to the software vendor. Do you need to purchase extra licenses because of the extra instances of the software? Will they charge more for upgrades when it is not a single project? Will you have to replicate all customizations 3 or 4 times? Will you need extra hardware to handle the different databases? Can they exist on the same server or even the same instance of the database server?

Next look at your needs at corporate. You want visibility from the top which means logging into multiple databases. Are your executives savvy enough to handle that? Will they get confused logging into multiple databases? Is your IT staff savvy enough to handle the extra load? They will have to support all of them – that might mean simple password requests on 4 systems, or data inconsistencies from corporate reports.

Finally, look to the future. Could you combine your purchasing department to get better volume discounts for shared suppliers? How would you do that on multiple databases? How about centralizing the sales department? Could that be done with the setup you’ve chosen? The same goes for most of the functions that could be centralized, but are not today.

How do you solve these problems? Yes, there is extra work in that. You’ve got to setup security around each subsidiary so they don’t see other’s data. You’ve got to figure out a scheme for setting up IDs such as customer IDs and Supplier IDs that won’t conflict and won’t cause too much disruption. You’ve got to create a plan to bring up new subsidiaries within the existing system.

Again, talk to the vendor. You are going to save money on the software by only going with a single integrated system. You should need fewer licenses, and less expensive hardware. Your single database will be able to consolidate corporate data quickly and effectively.

Your IT department will be relieved from all the extra work. They will only need to support one system. They will only need to create 1 set of reports; even if they have extra security around them. They will have one system to have problems with and solve. There will never be integration problems between the systems. They’ll never have incompatible parameters, or global indicators that don’t match.

Talk to your executives and find out what information they need at their fingertips. Can you create real-time dashboards across multiple databases? Can you provide real-time reports on cash, inventory value, A/R, A/P, etc.? Do they need to export data from the system, and would that work if it was exporting from multiple systems?

The bottom line is that a single database makes sense for a single company. Don’t let the easy answer to tough questions change your outlook. It might take more work to set it up, but in the long run, it’s worth it. As we all know by now, it’s a global world out there and Technology makes it happen.

How IT Can Communicate with the Business 09/25/2009

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

I always find it fascinating when people don’t understand tech-speak. Like any specialization, they have their own Three Letter Acronyms (TLAs), terms, and new names for their products. It is impossible to keep up with all of them, even if you are in IT yourself.

The key to communication is explaining those TLAs to business people, or asking for clarification from IT. If either side is deficient in these tasks, then poor understanding will result. This happens all the time and there are many reasons for this problem. Understanding the causes may help both sides to become better communicators.

On the IT side, people probably have had little training or experience in good communication. Their education and beginning job responsibilities have been to solve problems. If you are good at solving the problems, then you have met or exceeded your expectations, and nothing further is needed. At my first job, supporting the West Coast with their software, we had a person who’s full time job was to be the communicator between my solutions and their problems. [Thanks Betsy] She always knew what was going on at the company, talked to the higher ups, and let the rest of us in on the secrets.

On the Business side, communication is probably the number 1 priority for their first jobs. Consultants prove their value with status reports and deliverables; project managers have meetings to keep up with what is going on, and team-leads or first-time managers report to their managers on the status of their people. They have learned the art of communication from the bottom up. However, they still may not be able to effectively communicate with many in IT.

The problem could simply be one of attention. IT people tend to be detail oriented. When they get task focused, they see the details and need to handle them. When asked for status, they will talk about what they are working on, which could be the details. Looking at the details of any project can be confusing if you don’t have the intimate details. It’s probably not what a project manager really wants anyway. They most likely want a quick summary of all the tasks, not just the current trouble.

Another problem could be one of personality. Many IT people are introverted. That could mean that talking to others, especially new people, is draining on them emotionally and physically. Even if an introverted person is good at getting his/her point across, it may be tiring to do so. That person probably won’t seek out the opportunity to talk to people who will need excessive explanations. An extroverted person, however, may just expect people to come to him when needed. If that doesn’t happen then tasks can be lost, and a crisis could occur.

Some IT people focus on the infrastructure. They like to talk about the servers, the network, the bandwidth, etc. Some IT people focus on the software. They like to talk about the programs, the operating system, the customizations, etc. If the person on the receiving end of this conversation is not fluent in the IT-speak of the moment, then this will not be a fun discussion. It is so important to be speaking the same language.

A problem that can occur between beginner IT staff and executives is one of priorities. Many IT staffers are reactive. They will fix things as they break, and then move on to the next problem. Executives, especially higher up executives such as the ones at the C-level, want longer term solutions. They want to talk about pro-active solutions. They want to know what the new system will cost, once they see that the old system has problems. It’s difficult for people with such differing priorities to settle down on one topic.

Finally, there’s the idea of independence. Many IT people are such good problem solvers that they want to work alone. They feel that if they are qualified to reach their goals by themselves, then why do they need interference? Some highly experienced IT people may have gotten where they are by being the hero and getting past any dilemma. They may not want to work with other people. It may even be worse if the other people don’t understand what he/she is doing.

We’ve all seen, or been involved in, bad communication issues between people of differing backgrounds. At work, it can be even worse. People working in different functional departments don’t always understand the other people at the company. We all need to work on our communication skills, take a look at the world from someone else’s viewpoint, and be patient.

I’m not trying to imply that this is the whole of reality, and that all IT people, and business types, fit into these categories. I am simply making observations of my world and trying to write something that might help. Knowing how someone else is thinking just may help you get your point across.

So go out there and communicate!

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.