Business in the late nineties is increasingly about identifying what you do best and then concentrating on it. This often means arranging for the things you are less competent at to be done elsewhere. Nowadays, reinventing the wheel seldom makes as much sense as buying one from a specialist wheel manufacturer.
Applying this idea to software development has led to an enormous growth in the use of packaged business application software. Rather than writing or commissioning custom software themselves, companies are increasingly buying in pre-written packages.
Furthermore, they are doing this even for tasks that would appear to be very bound up in the nuts and bolts of their particular business; so, for example, they are using packages for project budgeting, capacity planning, and even process control. This is because modern packaged software from vendors like SAP, Baan and Peoplesoft is configurable ? to some extent you can tweak it to work the way you want.
Partly because of this, packaged business application software is a lot more complicated than PC office automation products like Word or Excel. Just selecting the right product can be a lengthy and involved process, and you then have to configure it so it does what you want in your particular business. The whole thing can end up as a major project taking months or even years.
In this feature we aim to help you get your bearings in the packaged business application market, and to give you some tips about buying and implementation. It is the first of series about such decisions.
The history of packaged software Most computer users are familiar with the package software used for routine tasks like word processing and spreadsheeting. This sort of off-the-shelf office-automation package has always been popular in the PC world, and is now best exemplified by the ubiquitous Microsoft Office.
But the package revolution has not stopped there. It extends well beyond standard office tasks to much larger multi-user applications running across multiple sites on a wide range of computing platforms. Many companies are now using packaged software to run key processes in all areas of their business. Historically, the first area where packaged business application software really took off was accounting, but this was closely followed by systems to help with the difficult logistics and scheduling tasks encountered in the manufacturing industry. Twenty years ago, mainframe systems were already being used for materials resource planning (MRP) and, recently, the more comprehensive manufacturing resource planning (MRP2).
Since then other business applications have progressively come on stream ? notably corporate accounting, distribution and human resources. At the same time there?s been a huge growth in the use of packaged business applications in other sectors, notably in finance, retailing, distribution and the utilities. Today manufacturing remains the biggest single user of packaged business applications but, according to research firm Ovum, other sectors are now responsible for nearly two-thirds of annual expenditure.
The pioneering role of manufacturing industry is still very evident in some of the jargon used. The term Enterprise Resource Planning (ERP), for example, is still often used to describe any of this software, even when it is being used for accounting or human resources tasks.
Whatever you call it, packaged business applications software is now very big business. Ovum estimates that the annual amount users spend on ERP worldwide is $11bn. Forrester Research, using different words to describe basically the same phenomenon, puts the size of the packaged applications market at just under $11.5bn in 1996.
According to Ovum, when you take into account the cost of consultancy and the extra kit necessary to run the packages, current spending on ERP projects accounts for about one-third of the total IT market. And it?s expanding rapidly.
After explosive growth in the early 1990s, concerns about the Year 2000 and EMU compliance are helping to keep it bubbling along. Indeed, Forrester reckons that the packaged applications market will maintain a roughly 30 percent annual growth through to 2000.
Key features of modern ERP software In theory, modern ERP software is designed to be fully integrated. Ideally, all the data is kept in a single unified database, whatever part of the company it comes from. This enables authorised managers and staff to monitor and interact with the entire business ? hopefully using much the same interface.
In reality, ERP software is likely to fall short of achieving this. Different parts of the package may not yet be perfectly integrated and, to get all the functions you want, you may need to buy some modules from different vendors. These may have their own user interfaces and may only be capable of sharing data by rather more clumsy means.
Another thing to remember is that the emphasis in most ERP packages is on doing the job effectively rather than going for fancy presentation ? so, in general, you will get a functional rather than a slick interface. Certainly, if you are expecting the kind of cute user interface found with the top PC office packages you are likely to be disappointed. However, this isn?t surprising. To achieve the performance necessary to support several hundred or several thousand users, the software may have to run on a range of different types of machine distributed around the enterprise in a complex web of processing.
Perhaps the greatest difference between packaged business applications software and the office packages of the PC world is the amount of work it takes to get the software to do something useful. Packaged business applications are normally configured in great detail, both to integrate with existing systems and to match the way you want to do business. Although much quicker than programming your own applications from scratch, this process can still take months or even years, and it may require you to buy in skilled help from people already familiar with the package, your existing software or your business area.
On the other hand, the detailed decisions that have to be taken during implementation can be an opportunity as much as a chore. Many companies combine the adoption of packaged software with a deliberate change in their business methods. This can take various forms. At one extreme are companies that go through a detailed business process re-engineering exercise, often involving outside consultants. They may then put a great deal of effort into configuring and customising the package to work in the desired way. But an increasing number of companies seem now to be going to the other extreme. They are adopting a more rapid approach that concentrates on setting just the key business objectives for the project, followed by a briefer implementation phase that involves less fiddling around with the built-in functionality of the chosen package.
Apart from the time-saving aspect, part of the appeal of this abbreviated approach is that it treats the package itself as a repository of best practice ideas about the way to carry out certain functions. Providing you choose a package that is good enough to support this objective, this can be another valuable way of avoiding the mistake of reinventing the wheel.
Making the choice When considering an ERP system it is normal practice to assemble a team to make the initial package selection and oversee the process of implementation. The average size of the team is between 10 and 15 people. The composition of the team is crucial ? a typical team should have representatives from IT, Finance, and the business units that will be most intimately involved in using the system, for example manufacturing or sales.
It?s important that you don?t allow one department to take over the buying process, otherwise you risk ending up with a system that is inappropriate to the needs of the business as a whole. Simon Bragg of CATN Cambashi considers this a real threat: ?the IT guy will probably choose Oracle, Finance will probably choose SAP, and Production will choose SSA or Baan.?
Normally there will also be at least one Board-level manager attending meetings, probably as chairman. But the person in charge of the day-to-day running of the project should be someone different, perhaps from IT or the department most involved in pushing the project. This split reflects the difference between keeping a focus on the overall business objectives of the project and the need to deliver it to budget and on time.
All major IT projects should have a high-level ? preferably Board-level ? sponsor overseeing things, and this applies particularly to ERP projects. This is because the software will need to be adopted across departments, often in a way that will change established work patterns, so someone with both the authority to knock heads together and the political skills to mend fences behind the scenes is essential.
Many ERP projects spread across multiple sites, which can lead to added complexities in the shape of human cultural differences. You overlook this at your peril ? procedures or incentives that make sense in one environment may be quite simply unworkable in another. Where the success of the project depends on changes being embraced by people from different national or corporate backgrounds, it?s important to involve them at an early stage.
See how it?s done It is worth putting considerable effort into researching the experiences of other organisations using similar ERP projects and packages. This can range from talking for half an hour to a key person on the phone to taking the whole team on a site visit. Surprisingly, users are generally willing to talk as long as you are not a direct competitor. But, even that may not be a problem as, in terms of the fundamental processes involved, there may not be much difference between a company which makes bread and one which makes steel.
Most packaged software vendors have a few favourite customers or pet users they like to put forward as reference sites, but it can be revealing to talk to their other clients. It doesn?t hurt to ask for a complete list of current customers ? some vendors will produce one and you can then choose the customers you talk to according to your own criteria.
You should also avoid canned demonstrations of software ? with ERP these can be particularly misleading because what you are really after is a good fit between the software and your business processes, rather than some kind of abstract functionality. Indeed, Rob Cools of Peoplesoft recommends that, even if you are going for a preliminary evaluation of a product you should take ? or send ahead of you ? a brief outline describing some of your key business processes.
Also, when looking at software, you should pay particular attention to discovering what it does not do. If the missing function is really important to you then this is where you may find yourself spending time and money customising the software or finding a work around. However, the Ovum report warns that finding out what a system doesn?t do is difficult: ?Vendors may not understand your terminology, and the simple answer ?yes? often means only that there is a work around.?
Once it is known that you are in the market for an ERP system, plenty of consultants will be eager to help with selection and implementation. There?s no doubt that they can save you time and bring specialist expertise to the party, but it?s important to be aware that they may have an axe to grind. A particular firm may only have knowledge of a few packages, and so may steer you in that direction; conversely, they may be keen to acquire experience of a product they know little about, and so steer you that way. Also, some consultants may have a vested interest in making things as complex as possible, since greater complexity can mean business for them if they are paid on a time and materials basis.
If you do have doubts about a consultant, the simple answer is that you shouldn?t deal with them. But we all know that, in reality, the appointment of outside partners is often highly political. One approach to keeping your implementation partners honest is to come up with an incentive scheme that rewards the attainment of project objectives rather than simply paying them for having bodies assigned.
Finally, it might be worth taking the trouble to document what you are doing as you go through the selection process. This may be legally required if you are operating in some sectors, countries or industries, and in any case it can help protect you if you get sued by a losing vendor. It can also be helpful politically. There?s a lot at stake in a big ERP project, and it has been known for disgruntled vendors who think they are losing out on a contract to go over the heads of the project team to other members of the Board. Knowing that you can show you?ve made your decision fairly and methodically may be enough to deter people from getting involved in these obnoxious games.
The implementation phase Once the package has been chosen, it is important to retain your focus on the business objectives throughout the implementation process. Don?t ditch key functions that you were relying on to meet important business objectives merely to meet time or budget constraints ? or, if you do, document these changes so the objectives are considered for a later Phase II.
Do check periodically that your original business objectives are still valid. While it?s not a good idea to tweak the goals of the project continually, it makes equally little sense to deliver a spanking new system that is ideal for the business environment as it was eighteen months ago.
A major decision that you have to take early on and which you should probably stick to is how much to customise the package. Graham Oates of KPMG Management Consulting counsels against attempting too much: ?What people shouldn?t do is tailor the core product ? that really is self-defeating if you?re going for a packaged solution. What people can do is build extra functionality around the core product ? there may well be value in that.?
Graham Oates also advises against spending too much time fiddling around with the software, as opposed to getting to grips with the new ways of working that the system implies. ?You really get value from how you integrate the software with the new processes you put in place. People focus too much on the software itself ? on configuring it, on building the interfaces ? rather than making sure that people can work effectively within the new environment.?
A problem that is often overlooked is how you recognise when it is time to end the project and wind up the project team. The key thing to remember is that the project isn?t over until the business benefits are delivered. A common mistake is to end the project prematurely, as soon as the new system goes live. This means that key people often drift away just when their contribution could be most valuable ? either in making small changes and improvements or in specifying a follow-up project.
Right from the earliest days of the project it is worth thinking about how you are going to retain key staff for as long as they are needed. For as your people learn on the job and build up their knowledge of both the particular software package you are using and state-of-the-art business processes, they will become much more attractive to anyone else embarking on a similar project. Attempts at poaching them are only to be expected. Remember too that any partners you are using to help implement the project have to get their staff from somewhere, and they may not be above poaching from you.
Lessons: Purchasing ERP
1 Put together a well-balanced team to make the selection and oversee implementation.
2 Don?t let one department take over the buying process ? remember that you want to meet the needs of the business as a whole.
3 Make sure you have a high-level sponsor with sufficient clout to do political fixing behind the scenes.
4 On multi-site projects, take care to involve people from different national and corporate cultures.
5 Research and learn from the good and bad experiences of organisations attempting similar projects.
6 Make sure that vendors gear their product demonstrations to the specific needs of your business.
7 Clarify what the package can?t do as this may be where you will have to compromise on function or put in extra effort.
8 Use outside consultants wisely. Exploit their knowledge, but be aware that they may have their own biases and business agendas.
9 Document the selection process adequately. Put as much effort into this as the legal and political risks in your neck of the woods warrants.
Lessons: Implementing ERP
1 Keep fully focused on the business objectives throughout the implementation process.
2 Don?t ditch key functions that you need to deliver important business objectives merely to meet time or budget constraints. If you?re forced to compromise, document the changes so they can be implemented later.
3 Check periodically that your original objectives are still valid for the business conditions prevailing now.
4 Don?t tailor too much. If you feel you have to, then you?ve probably chosen the wrong package.
5 Don?t focus too much on the software at the expense of getting the new working methods right.
6 Think carefully about how to retain key staff ? watch out for poaching.
7 Don?t wind up the project too soon and make sure enough of the team are still around to make adjustments after the system goes live.
IBM and Technical University of Munich team demonstrate how Shor's algorithm, which can't be cracked by conventional computers, can be solved quickly with quantum computing
Hubble Space Telescope finds superflares from young red dwarfs could strip away planetary atmosphere
Younger stars are 100 to 1,000 times more energetic than when they're older
Two of the big four supermarkets will use the system to control sales of restricted products
PUBG news and updates: November's Update #23 to bring new Skorpion pistol and changes to blue zone visibility
Genuinely useful side-arm coming to PUBG in Update #23