The latest WhichPLM Customer Survey 2010 which went out to over 500 apparel PLM customers highlighted some of the real costs of failed projects. We found that almost 60% of respondents’ projects overran time and budget. Some of the more pertinent quotes from respondents highlighted issues with not scoping the project effectively and many customers found that they simply tried to do too much too fast. Let’s not be under any illusions here, both PLM and ERP are huge systems that require a huge amount of man power, time and finances to implement. Of course the benefits allow for returns far in excess of these costs, but still they are systems which touch on all users and departments across the business. Interestingly, some of the respondents mentioned that in retrospect if they were to revisit the project they would have chosen to do both ERP and PLM simultaneously. Surely this means increased costs, increased fragility of your cash flow, reduction of operating capacity and increased risk… Of course the next question is, why?
For a company, implementing just one big enterprise system at a time has a few advantages. Firstly the project itself is far more manageable in that the system capacity won’t be as hard hit as it would if you were implementing two big systems. Downtime whilst the replacements go live, initial go live jitters and unfamiliar users are far easier to plan for when you only have to factor in one system rather than two. As above even single system projects can go wrong so the complexity of managing two concurrent is a much harder sell than just the one.
We know from experience that both ERP and PLM projects follow a similar implementation path of: requirements gathering > process mapping > vendor selection > system scoping > system configuration > system live > system support – Managing a project in this model itself is a learning curve and for immature clients will most probably be a learning curve. Therefore it makes greater sense that you ‘acid test’ the process and learn the pitfalls on just one project rather than having unforeseen circumstances or inexperience hinder two system projects. Ideally you want to utilise consultants to avoid the pitfalls but there is a certain amount of best practice that all clients still need to adopt, consultants or not.
Whilst on the topic of managing the project, what about the impact to business users? With the amount of scoping and process mapping required to implement dual systems, can you guarantee that your business users will give the process mapping and requirements gathering the correct amount of emphasis? In our consulting work with PDP we know first-hand that most people working the supply chain are already pretty much at capacity in most businesses, how do you expect they would respond to being pulled from their duties regularly over a two week period to attend process workshops? Would they be fully engaged, or would they rush through to be able to get back to their roles? Getting the requirement capture correct is paramount to any project and major problems occur when you start an implementation on an understanding only to discover in the pre-live training phase that actually that’s not exactly how it should be.
There is of course the issue of being tied to one vendor for the majority of your many information systems. No matter how many demonstrations you receive or how many workshops you attend, the true test of a software system occurs on go-live. If you start to find bugs in the solution, or errors then it may suggest poor QA from the vendor, which is more than likely to be the same QA process used for another of the vendor’s product. Beyond the system functionality, what about the support for the system? You are buying a system that you hope will still be operational in 3/5 years, so of course you need to ensure the vendor is still around supporting said system. In our industry, the recent acquisition of Lawson by Infor presents a potential risk for customers, as here you have one company now potentially selling two separately branded apparel PLM solutions? I’ve not been in business all that long in the grand scheme of things but I’ve been around long enough to know that competing against yourself, is a fruitless exercise and not a recipe for long-term success. It all comes back to getting the scoping correct (including vendor selection) although the recent financial troubles showed us that in tough economic times, no business is impervious to liquidation or the streamlining of their portfolio.
Reading the above it is easy to see why a business would want to avoid taking on too much too quickly, but for a lot of customers (and certainly more recently) the full end-to-end implementation route is being favoured and working very well.
I spoke above about the impact to resources and users, of course the flip side of this coin is the view that consolidating this downtime will actually be more efficient in the long run. Why engage users in process workshops for a few two week periods over a couple of years when you can pull them all together at one single time? Likewise generally speaking, the more you do something the better at it you become, thus if users are going to be expected to change the way they work, why do this once and let them get accustomed to it, only to change the processes for them again two years down the line? Change management is one of the biggest issues for IT projects, if your users don’t buy into the system(s) then you have no chance to actually reap benefits from the end product. No matter how many changes you make, effectively managing the change management process should be one of your key priorities in any project.
There are of course economies of scale that can be utilised by running dual ERP/PLM projects. You will find greater financial incentives from vendors if you are purchasing two systems concurrently both in terms of the licences and support and once implemented you will end up being one of their preferable clients which can have some slight benefits attached. Equally you’ll tend to find that implementation costs can be reduced as you will bulk together a lot of the carry over work such as process workshops, end user training and if the vendor is well established, you will tend to find implementation partners who can do both implementations, again meaning greater financial incentives from your partners.
Finally and probably most importantly, one of the key benefits of an end-to-end project is that you remove the complexity of inter-operability issues between the two systems. We already saw in the first article that there is a large element of cross over in functionality between ERP and PLM and this is most important at the technical level. Any company who has ERP and PLM will tell you that one of the most challenging parts of either project was getting the two systems to interface. Issues of data coding or DB platform compatibility can lead to an end-to-end solution which is plumbed together by a Microsoft excel export routine (i.e. the very application and manual processing you are trying to remove from the system)! Suffice to say, what is the point of having the POTENTIAL for fantastic benefits if you can’t actually ever realise them? Implementing both ERP and PLM simultaneously will at the very least allow to you to properly scope solution shortlist to ensure it can dynamically interface with the other. If you are savvy enough you will even get the system scope as an element of the software purchase agreement so that the interfacing cannot be misrepresented to you by the vendor. Most new systems do have many different interface routines to accommodate the most widely regarded solutions; however we do still come across issues regularly. If you are just using one vendor for both systems then this becomes purely academic as you would expect that any software vendor had already factored this very firmly into their original development roadmap, (they may not have of course but it is unlikely). Some of the ‘new breed’¹ vendors like New Generation Computing or Computer Generated Solutions (and others) have very smart deployment models in which the full end-to-end process is broken down into business functionalities, and each can be easily activated on a modular basis for full seamless integration.
In summary whether you are going to run a dual project or a single project any project manager needs to be aware that these are truly enterprise systems and no matter which path, should not be undertaken lightly. We know of projects that have been run full end-to-end and succeeded and equally we know of those that have not delivered the ROIs or business objectives. There is of course an increase in demand for end-to-end solutions at present, perhaps as businesses attempt to take advantage of the financial cost savings referenced above. Ultimately it all boils down to business requirements, where are the current weak points and which parts of the business will provide the greatest ROI? The best advice is often the most straight forward; businesses which spend the proper amount of time in scoping and requirements gathering have a significantly greater success rate than those which don’t.
¹ I use the phase simply to represent vendors who move away from the traditional one solution model, both referenced vendors have been in the industry for many years.
Read the first part of this article: WhichPLM Blog: 24 May, 2011 – Once Size Fits All — The Chicken or the Egg.
Rob Smith is the operations manager within the Product Development Partnership Group of companies. He is also a fully qualified commercial solicitor.
Contact Rob at email@example.com