Connect with us


Enterprise Software Selection, Configuration and Enhancement, On Going Support



On my previous post (ERP System and Enterprise Software) we have talked about the choices, in this post we are going to talk a bit more about Enterprise Software. I’ll take you through our thoughts on Enterprise Software in four steps: Selection, Configuration and Enhancement, Installation, and Ongoing Support. The software selection step is the beginning of the project when the company must decide which software company will best handle the information transactions for its business. Configuration and enhancement are handled by design teams. These are the internal teams that make sure that the right switches are thrown for each decision process and identify needed enhancements and extensions. Installation is probably the most obvious step since whatever is chosen must be put in place. The opportunities and challenges are in maximizing learning during implementation and minimizing crashes. Ongoing support refers to the maintenance and improvement of the system after start-up. Those who have looked at the Enterprise Software initiative as a one-time project with no follow-up care and feeding have been very disappointed.



Enterprise Software Selection

There are lots of so-called enterprise software choices available. The key point here is that there is not a single right software choice. There are good choices and not so good choices for your business.

OK, how to proceed?

First, understand your business and the opportunities for change. Yeah, this sounds insulting. Of course, you know your business. But do you know where the real weaknesses are in the business? Are you having trouble with delivery timeliness and accuracy for your customers? Are cost projections erratic and unreliable? Do customer orders “get lost” inside the system, requiring massive human intervention? Does the supplier interaction become so complex that the supply chain resembles a pretzel? Are human resource systems clogged with massive data that cannot be assessed to answer basic employee demographic questions? Understanding these and other questions will tell you what areas are of most importance to you in choosing a software provider. Each of these questions impacts a different software module and each software provider offers different approaches to those areas. Without this knowledge of the company’s strategic and tactical needs, you’re subjected to sales presentations by the software vendors without knowing which areas of the pitch are most important. You need to know that the vendor you choose has solid offerings in the areas where you have the most need. A good question to ask is this: “If we have software from this provider, can we make a competitive breakthrough?” This question and its answer will typically point you to the ERP related modules that deal with demand management, master scheduling, MRP, plant and supplier scheduling, warehouse management, etc.

Also, you need to consider which vendor’s approach best matches your present environment. Invite them to an extensive tour of your operations and provide a candid appraisal of your business needs. If the software provider seems to have software organized most like your current systems, then they win this part of the sweepstakes for your vote. This would include the possibility that one part of your company has already installed systems from a specific provider. If this unit has a good experience with the software, you are part way home in having a real live test in full operation.

A key deciding point for any software, particularly Enterprise Software, is simplicity. Standardizing on one approach across the company is the big hitter here and not the sophistication of the software. Remember that people are going to use and maintain the software, so make sure that system is as simple as possible.


Warning: Don’t confuse features with functions and don’t assume that more features means easier implementation.


Actually it’s usually the reverse: More features equal more complexity, and more complexity equals more chance for problems. One of the advantages of installing an Enterprise Software today versus ten years ago is that there are many companies in all parts of the world who have installed Enterprise Systems—some are actually using ERP at a Class A or B level. Each vendor should be able to arrange a meeting with some of their customers so you can learn from their experiences. If they can’t provide references, drop them immediately.
Check the business press for articles about failed installations—these always make the press since the business impact is similar to a plane crash. A few calls can get you information about the provider from these troubled installations as well as those being bragged about. There are several excellent sources for information about ES software vendors. You may have others, and certainly there are numerous consultants who can help you locate likely candidates.


ES Configuration and Enhancement

Following the selection of the software vendor, it is time to install the software, right? Well, not exactly. The software will be excellent but it now must be adapted to your operations. Remember, Enterprise Software connects every facet of the company in such a way that every transaction becomes an available piece of data for the corporation. The software is not “one size fits all” but rather “one system adaptable to your business.” Chris Gray says: “ES systems are flexible in the same way that concrete is flexible when it is poured. However once it hardens, it takes a jack hammer to change it.”

Typically, for convenience in programming and use, the software will be in a number of modules that focus on particular parts of the company. Although there is variation among the providers, there will be seven to ten modules with titles like Finance and Accounting,
Master Scheduling, Human Resources, Warehouse Management, and so on. Each of these must be tailored to your particular operations and business needs. Most of this tailoring will involve setting switches to control data flow and processing steps.

However, in some cases, enhancements to the software package are necessary in order to support critical business functions. (We’ll go into more detail on enhancements later in this chapter because what we have to say applies to both ES and to bolt-on). Each module should have an assigned ES design team that reflects the company functions most involved in that area. These groups are different from the ERP project team and task forces. In a combined ERP/ES implementation, one of the challenges is keeping the ES design teams aligned with the ERP teams, and one of the best ways to accomplish this is with some degree of common membership. One or several members of a given ES design team are assigned to the related ERP organization and vice versa. The big difference between an ERP team and an ES team is that the ERP team focuses primarily on people and data integrity while the ES team focuses primarily on the software and hardware. However, both are involved in re-designing business processes, and thus it’s critical that these processes be a joint effort.

So what do the Enterprise Software design teams do? Well, think of the data flow in the company as hundreds or thousands of trains moving along a myriad of tracks toward one station—the central database. You must decide if those trains only go to the final station or if the data can be switched to a different track along the way, in order to serve a particular function. Also, once the train arrives at the station, the passengers or freight can be re-routed to other destinations. Deciding where all these switches should be located and where the data should go is the job of the design team, and it’s a major task requiring knowledgeable people.

Choosing the design team is a delicate but essential task. For some individuals, their expertise will be critical to the design full time, for at least six to eighteen months. Others could be part timers called into meetings to provide their knowledge regarding specific questions.

However, plan to err on the side of greater rather than lesser involvement, as this is very important work. Most units inside the company will resist putting their top people on teams like this. It seems to be too far removed from “real work” and good people are always scarce. Also, they may have become accustomed to having their software custom-written for them, so they will assume that they can rewrite whatever comes from the team later. This obviously is an erroneous assumption, but they won’t know that unless they’re told. We recommend that the CEO/president/general manager take charge of this debate early in the process and let everyone know that the work will be done only once, via the ES design teams. Individual business units will no longer be able to develop software—except as part of the design teams.

A key requirement for membership on these teams is that all individuals must be able to make decisions for their organizations. They can’t simply report back to their business units and ask, “Mother, may I?” on each decision that needs to be made. If you don’t think that a unit is providing sufficiently senior and skillful people, one technique is simply to ask the business unit leader if this individual can speak for the organization on issues important to the leader’s promotion. Obviously, team members must work out a way to keep in touch with their home units and get appropriate advice and counsel, but they must be able to represent that unit completely and make decisions on its behalf. Of course, this raises the question about how big a team should be.

Our response: It depends. The smaller the team the better, but teams have run successfully with up to 20 people. Obviously, the larger the team, the tougher the role for its leader. However, we have seen small teams struggle if the purpose and intent is not clear and leadership from the top is missing. What about the leader? Teams for some of the software modules will have a leader from the IT area, as that is clearly the key business function for corporate software. In other cases, it can be effective to recruit the leader from the key function. For example, someone from sales could be very effective in leading the design team for the Demand Management module. The function in question—Sales, in our example—will have very clear ownership of the design result so it makes sense to put them in charge of the work.

At this point, some of you may have a growing concern about the number of people who will need to be committed to the design teams. This is very perceptive. This work is substantial, critical, and time consuming. In an ERP/ES implementation, if you find that your company can’t staff all the design teams necessary, then you have two choices:

  1. Combine ES design teams with ERP project groups, thus minimizing the head count required.
  2. Decide to go to an ES only project now, with ERP to follow. Let’s consider an ES installation without ERP, but with the inability to staff all the necessary design teams. Your best choice here is to decide how many teams you can staff and do a multi-phase project. Choose the most important two or three modules and set up teams for them alone. The rest of the modules will have to arrive later. It’s far better to do a small number of modules well than a halfhearted job on all.


Software consultants can help with this process, but they simply can’t replace your own knowledgeable people who understand the company so deeply. In fact, there is a danger that consultants can cause a bigger time demand on your people because they do interviews across the company to learn your business. A good middle of-the-road option would be to have a few software consultants involved who can help facilitate the team decision process without having to be complete experts in your operation. Installation Now, let’s consider the task of installing the software. Much of the really heavy-duty work is completed as the design phase has shaped the nature of data flow in the company. Now it’s time to start to run the software, and this is normally a rather intense activity. So here are some hard and fast recommendations from your friendly authors about this installation process:

  1. Be flexible. If the installation is a rigid process to install exactly what the design teams specified, then there may be considerable difficulty. It may not work, because the collective effort of the ES design teams may not be compatible. This incompatibility could exist among the ES design teams, or with the ERP project team. However, if you take the problems that arise as true learning opportunities, then the software configuration can be modified as you go, both to fit your business requirements and to work well. Thus, the seeds are sewn for continued growth and learning in the future.
  2. Pilot the software before going live. An early step here should be to make pilot runs of the software using a typical business unit as a model. These computer and conference room pilots will go a long way to verify that the design teams’ designs are working properly, and we’ll cover them in more detail on my next post. Although these pilot tests cannot confirm everything, don’t even think of going forward without them. Every pilot like this that we’ve seen has turned up major adjustments that need to be made before going live. At this early stage, the software can be readily changed without business results at risk.
  3. Make deliberate haste. Never, ever try to start up the ES across the entire company at one time. Even if the pilot gave everyone great enthusiasm and confidence, do not risk the entire business by cutting over all at once. This so-called “Big Bang” approach could describe the sound made by your business imploding. The best way to install the system is to choose a part of the business as the live pilot because this represents substantially lower risk than doing it all at once. You need an aggressive schedule to keep momentum on the project as a whole, but you need to protect your business at the same time. It is key to develop some early wins that build enthusiasm.
  4. But, in any case, get moving! Some companies attempt to minimize the risk by turning on only one or two modules across the entire company. We don’t think this is the way to go, because the total risk can be very high if even just one module is installed across the entire corporation. For example, installing only the Warehouse or Distribution module for the corporation may seem like low risk. After all, it’s just one module and the full design team can support it. The problem is that errors in the setting of the switches could stop the company from shipping—possibly for an extended time. It goes without saying that this could be devastating.


The business press has reported on companies that did this, found themselves unable to ship the product, alienated many customers, and took a major earning hit for the quarter and possibly the fiscal year. Wow.

The pilot test risk is reduced by several important factors. One is that it is only a piece of the business, and the second is that you put all resources available against the test area. The people in the pilot area may like being guinea pigs, since they get a chance to shape the corporate software to their specifications. Also, there will be a lot more help available for the test installation than there will be later.

The pilot test unit should have been involved in the conference room pilot and their people will be among the most knowledgeable in the company. Even a very risk-averse general manager should understand the value of leading the test.

After the pilot is up and running, the rest of the company rollout of the ES can proceed as with any other project. Some will want to move with consecutive business units, others may do a geographic region, and still others may install by function. There is no magic answer except to understand what was learned from the pilot and apply that learning to the rollout. As is true of any big project, it’s always smart to avoid too big a rollout at the busiest time of the year. What about the design teams? The design teams should stay intact during the entire process from conference room pilot to company rollout. They normally don’t need to be deeply involved during this installation step, but they do need to be available for advice. There is no one who knows more about the functionality of the modules than the teams that designed them. In some cases, the questions or changes are routine enough that they can stay connected via email or conference calls. In others, they may need to meet to review the status.

Regardless, design team members need to realize that they are critical to the success of the total project—not just the design phase. This is another place where a few words from the general manager can make a real difference.


On-Going Support

One big mistake made on major software installations is to consider the project finished once the software is up and running. Although project completion is certainly a time for champagne and parties, this software is now a living, breathing part of the company. As the company changes, so should the software that connects it. As we said earlier, the folks in the IT department have become information managers and not software writers. How do they do this? The big change from old, fragmented systems to this new company-wide, transactional software is that it becomes the central nervous system for the company. As such, it’s hard to think of this system as ever “finished.” Besides the changes in business strategy that need to be reflected, there may be acquisitions, spin-offs, or consolidations that change the nature of data flow. Also, the software provider will routinely release new versions of their software, some of which may be quite worthwhile for your business.

This brings up a critical point about information technology resources. In the old days, many business units had control of their own IT people. This was essential to keep the localized systems alive and well. However, ESs have a central corporate database, and thus the need for high system reliability and clear networks. This certainly speaks to the need for very central direction of IT resources. Let’s not mince words. We strongly favor central control of IT resources to avoid fragmenting this critically important set of software.

If local units have control of their own IT resources, the odds are very high that they will gradually start to chip away at the corporate-wide nature of the ES. Certainly the local units need IT resources to make sure that they’re using the information system effectively and to deal with ever changing business requirements; however, these IT people should have the central IT group as their organizational home.

Click to comment

Leave a Reply

Your email address will not be published. Required fields are marked *

Are you looking for easy accounting tutorial? Established since 2007, hosts more than 1300 articles (still growing), and has helped millions accounting student, teacher, junior accountants and small business owners, worldwide.