Home News WhichPLM Blog: 24 May, 2011 – One Size Fits All Series

WhichPLM Blog: 24 May, 2011 – One Size Fits All Series


The Chicken or the Egg

Within the middle market we have started to see an increase in projects involving end-to-end solutions. Generally speaking ‘end-to-end’ refers to all system that are ‘touched’ by the product either directly or indirectly as it moves through the lifecycle from cradle to gate. This can include: ERP, PLM, EPOS, CRM, e-Commerce, BI and so on…However in the context of this article I am referring to projects which involve the two largest core systems in any apparel company or retail business: Product Lifecycle Management (“PLM”) and Enterprise Resource Planning (“ERP”) systems.

All businesses operating in this industry in the middle market will almost certainly have at least one of these systems (or rather systems which at least provide the basic functionality) already in place. Most probably some ERP functionality will be available either through a first generation ERP project from decades past or perhaps one of the newer accounting software packages which delivers some additional functionality within the ERP remit such as line planning or business intelligence.

Suppliers in both software verticals have predominately stayed within the boundaries of their own vertical, not wishing to offer full proficiencies in both ERP and PLM for the simple reason that:

1. The market hasn’t been ready (or customers not receptive to justify the vendor service diversification); and/or
2. The systems design framework has traditionally been introverted with external systems collaboration always existing as an afterthought.

However around the early part of this decade the landscape for apparel solution vendors changed dramatically; ERP continued its established growth into the 2nd generation; apparel PDM finally became true PLM and realised its value; and technological advances in collaborative information systems along with an increase in cost effective outsourced development meant the scope for systems design could finally be wide encompassing.  That’s not to say there weren’t vendors pushing this end-to-end strategy pre-millennium, but now at least all were recognising a genuine consumer need.

Due to the evolution of the scope of these systems and greatly depending on which sales brochures you read it is hard to establish what business functionalities traditionally belong in PLM and which functionalities belong in ERP. Is it easier or harder now for a vendor operating within just one vertical to clearly say “is this where PLM should end and ERP should start” and discounting the issue of system accountability for a minute (discussed below), at a technical level can you clearly identify the separation?

Let us look at how some of the vendors separate the systems. A quick look at the websites of some of the world’s biggest ERP vendors (Microsoft and Oracle) shows that at a high level ERP roughly covers the following functional areas:

  1. Financial Management;
  2. Planning and Budgeting;
  3. Operations Project Management
  4. Supply Chain Management;
  5. Business Intelligence;
  6. Executive Reporting and Analysis;
  7. HR Management;
  8. HR Systems Collaboration;
  9. Quality Management;
  10. IT Resource Management; and
  11. Web Services Integration Management.

A similar look at some of the websites of Dassault and PTC shows that PLM covers:

  1. Merchandise Planning;
  2. Line Planning;
  3. Creative Design;
  4. Colour Development;
  5. Material Development;
  6. Specification Management;
  7. Sample Management;
  8. Supplier Management;
  9. Sourcing Management;
  10. Quality Management; and
  11. Supply Chain Collaboration.

Straight away you see (where I have highlighted in red) the overlapping common functionality and thus the start of the potential problem for the consumer. Imagine you are a Tier 1 client looking to put in place a new 2nd generation ERP and your growth strategy also includes embracing this new generation of true PLM? You have already identified the high level business case for both systems and at this stage you most probably consider the ERP as the first project because you already have ERP, you know it works and you are familiar with the benefits it brings… (plus it has been an easier sell to the FD). So your next point of call would be assessing the vendor market and making initial contact with suppliers. You go to ERP vendor X who tells you “our ERP can deliver better functionality from our vendor management, supply chain management and line planning functionality than PLM, you should implement (or replace in this case) ERP first and foremost as you already know how to use it and it has been developed with decent APIs and an accessible database so integration with any PLM down the line will be an easy win.” Sounds like a fantastic proposition doesn’t it? However out of curiosity you decide to speak to PLM vendor Y who tells you “why replace ERP at this stage when you already have basic ERP functionality, why not implement PLM now and get the benefits of both solutions within the year? Our line planning, supply chain management and vendor management functionality is far superior to anything that ERP can provide plus our PLM has been developed with decent APIs and an accessible database so integration to both your current ERP and your future system down the line will be an easy win.” Before you start the functional systems design you already feel like Alice in the rabbit hole.

One of the main issues brands face at this juncture is highlighted above… which software comes first, ERP or PLM? Both systems are extremely beneficial to clients and both can easily realise their respective returns. But there are few different scenarios where one should be favoured over the other.

Of course any enterprise level project should be judged on the needs of the business at that time. If you have a business that identifies stock control is spiralling out of control, then of course the business should be looking to resolve the issues within the ERP functionality first and foremost. If you are having problems with quality control or sample processing then equally PLM should be your primary focus. One big different between the two systems is that ERP will make your traditional business processes more efficient; PLM will mature and evolve your business processes.

PLM is essentially a new way of working through making the product your core focus throughout its lifecycle. Any company starting a dual project with ERP would end up moulding PLM to fit in with the way the ERP has been rolled out which (unless you are very experienced with PLM) will make transition to PLM harder and you will end up hindering some of the benefits that PLM can bring. There is no point in going through all the requirements stages to then implement half a PLM system as your business simply will not grow and evolve to the new way of working, which will greatly impact you competitive edge.

At a technical level, before we even start looking at some of the nitty gritty, the product is conceived within creative design which is not touched by ERP. So from a purely logical level, in your business, the product exists before you even start thinking about supply chain, manufacturing or invoicing. The product will also already have product attributes, it will already have digital storage and most importantly it will already be codified and indexed in a way that makes sense to your design team and product managers. Forcing products in a PLM system to try and fit within product information schemes defined within ERP is one of common causes of budget overrun when implementing PLM; and for PLM process experts and implementers it can be extremely tricky to resolve. Changing data structures in either PLM or ERP once established is not easy. It requires technical knowledge of the solution, it requires an amount of system downtime, it requires a support structure to be in place for inadvertent issues and it can be an annoyance for users up the supply chain. The infuriating thing is that on paper is should be easy if scoped correctly at the requirements stage, but due to the wide variety of ERP systems currently in existence, the variation of system platforms and database models and the non-standard accessibility of data structures, ERP interfacing can be brutal for some projects.

It goes without saying that anything that can be done to make PLM and ERP interfacing easier is a big win for all involved. Noted above, scoping both projects correctly at the inception of either project is a big win. Even if you aren’t planning to start looking at PLM for another two years down the line, why not consider its potential impact when going through your ERP replacement and vice versa? Certainly some vendors have started to take notice of this fact and we are now in a generation where although they are still widely regarded as separate systems, the overlap between the two is leading to a flock of end-to-end solutions brought to the market that guarantee full operability without any of the complex interfacing… And a quick look on the WhichPLM website shows that a number of brands are starting to buy into this new movement.

Rob Smith

Rob SmithRob Smith is the head of enterprise projects within the Product Development Partnership Group of companies. He is also a fully qualified commercial solicitor.

Contact Rob at rob.smith@pdplimited.com

Rob Smith Rob Smith is a contributor to WhichPLM. He previously served as Operations Manager to the Product Development Partnership. His expertise range from Fashion/Retail systems to Gaming and his contributions focus on the realities of selecting and implementing PLM and ERP. As a fully qualified commercial solicitor he often writes about the legal and legislative frameworks that affect the way companies in our industry do business. He runs his own consultancy and is editor of a number of iGaming related sites like Return to Player and Lost World Games.