One Size Fits All Series: Blog #3 – ‘That’s how dad did it and it’s worked out pretty well so far’
A few months ago I ran a set of articles that helped users look at some of the benefits that can be realised by choosing a software vendor who provides a wide range of complimentary products all based on the same platform. The benefits are clear but equally so are the risks, especially when choosing a long-term partner for a significant amount of the system infrastructure. So what are the other options for those who simply don’t want to deploy full end-to-end? Put simply, adopt the best in breed methodology.
Best in breed solution (“BIBS”) adoption requires no real definition; in basic terms it means segregating your functional systems and IT strategy and choosing the solution that is considered the best (or one of the best) and fits your requirements for that segment. (Note that I am not suggesting that any business buy the best or the biggest system blind; irrespective of which approach you choose, it is still vital that you map the capabilities of the solution to your specific needs.) The best in breed approach usually means running multiple different projects, with multiple teams, across different areas of your business. Straight away you should be thinking, “Why would I want the hassle of undertaking this?” – and you’d be forgiven for this train of thought – but there are some real benefits from adopting the best in breed approach.
Firstly from a functional point of view a BIBS project will ensure that you find a solution that perfectly fits a given process segment. End-to-end solutions are fantastic, but you are hanging your hat on the Out Of The Box (“OOTB”) apparel processes developed by one vendor for a significant area of your business. In practice these processes may ‘roughly’ fit your needs but may not ‘exactly’ meet your unique business requirements. In that situation, the prospective customer would then need to decide (after a careful gap analysis) what the threshold for adoption should be in the latter case – i.e. just how far “roughly” is good enough.
We can be confident that a vendor who deals only in PLM or ERP or CRM will know that particular sector inside out, and that behind the scenes they will be focusing their development efforts on breaking new ground in that particular sector. Companies who choose a solution from such a vendor know that they will have first-to-market opportunity in some specific functions rather than a broad set of functionality that may fall foul of the old adage: ‘jack of all trades but master of none.’
To cite a few examples from our industry: Centric Software are putting significant development into their iPad collection/merchandise book application, and Lectra are ploughing resources into the “smart service” collaborative abilities of their suite of pattern development and CAD applications. When you look at the technology available today, the options on the horizon for apparel and fashion companies are extensive. One current “hot” area of development is the range of solutions designed to make the apparel product lifecycle more ‘visual’; 3D virtual sampling; visual costing; material texture mapping; 3D visual store planograms on so on. Take visual labour costing for example: within a PLM solution you are almost certainly going to have a Bill Of Material (“BOM”) and Bill Of Labour (“BOL”) for a style. You’ll almost certainly also have the concept drawings and technical garment sketches that your designers and garment technicians are actively working on. Broadly speaking these three views should be drawing from the same data sources, and allowing your users to perform advanced analysis of the data. This could mean linking existing BOL and BOM data to that style data at the conception stage, which would allow your product development team (design and garment technicians alike) to design to commercial limits set out in a line plan. For most vendors who provide a broad spectrum of solutions the data will already exist, but it may take some niche and time-consuming development work to allow this particular bi-directional link to work. If you are the developer of a range of end-to-end solutions, are you going to plough resources into focusing on this very narrow area of development? Probably not, as you’ll already have your hands full developing and supporting the basic capabilities and more obvious, “easy” wins in your solution. BIBS suppliers will almost always be the vendors who are pioneering this advanced functionality, rather than vendors of end-to-end solutions.
From a commercial level, how many solution providers who offer end-to-end systems actually started with that product strategy in mind, and how many grew to be cross-industry out of necessity or opportunity? There are very few vendors who have both the expertise and / or investment to be able to develop such a broad solution portfolio at the time of incorporation, let alone to ensure that the wider development strategy stays current. Therefore, in reality, these solutions look appealing on the surface, but if you dig a bit deeper you may begin to see cracks in the product, and discover that what you thought was a fully integrated solution is actually several separate islands of technology with some great middleware in between.
I am aware of a recent project where a customers implemented ERP and PLM from the same vendor (a big vendor at that), which were sold as fully compatible. It transpired that in order to integrate the two solutions it was necessary to put together a bespoke script that would serve as a thin middleware layer between the ERP and PLM solutions and allow for mass updates of costing data. Mass updates are not widely implemented across the vendor landscape at present, but where a customer is purchasing both ERP and PLM from the same vendor, I believe that it’s a legitimate expectation that the structure would allow for this, especially taking account of the fact that both systems should be using the same data source.
As I mentioned in my previous articles integrating a full end-to-end system has its benefits. Being able to drive product development from integrated line plans and merchandise planning (perhaps existing in an ERP solution (or module)), or having purchase ordering fully integrated into PLM are useful capabilities which are not replicated in standalone PLM systems out of the box. But rest assured that a number of well-established and well-supported BIBS do come with very comprehensive interfaces to any number of ERP and supply chain systems, allowing these and similar added value features with a little more integration work.
Thirdly, there is a lot of risk in deploying one vendor’s system across the entire business. You will be able to achieve some significant economies of scale on the licence fees, and you can expect to save costs on implementation and future service agreements, but what if that one vendor goes insolvent or is purchased and the business entities divided? We have recently seen Infor and Lawson merging and Gerber being acquired; through our connections with the vendors we are able to get a reasonably clear picture of the future developments in such situations, but are vendors communicating the same to their clients? Where a single vendor’s system has been rolled out business-wide, are those customers always made aware of their vendor’s structure and development plans? My experience (through discussions with both prospective and existing customers of PLM) is that they are not.
As a prospective customer of PLM, you need to ensure that the data behind the scenes of whichever PLM solutions you shortlist is relatively standardised, or that at least there is a reasonable export function; so that should you need to replace the solutions whatever reason, the migration won’t end up being a potentially resource heavy process i.e. where there is an apparel PDM which utilises a bespoke database.
Of course no matter what system you implement – whether it is a full end-to-end or BIBS – data should be a paramount concern. Where apparel PLM implementations are concerned, we tend to find that, assuming an average implementation period of 150 days, almost 40% of that time will be spent collecting, cleansing and unifying data across all business entities, defining low level field structure to accommodate incumbent systems and consolidating existing libraries. Colour libraries are a great example of this: if you have the colour ‘blue’, this can exist in the business with many different descriptions and codes (‘sea blue’, ‘sky blue’, ‘Blue’, ‘Blue7’, blue_2’, ‘b487’ with a 3 digit code in ERP, 5 digit code in PLM and 6 digits in Pantone). The majority of the time this is actually the same colour on a standard colour chart but just entered multiple different times by different users working with different systems. Identifying and unifying all this data across an entire business is a huge task, and one that requires a significant amount of resources both internal and external. But, once complete, this set of unified data becomes the one master that you can easily control and structure for future operations (saving a significant amount of data migration costs both on the PLM and other foundation IT platforms in the future, and most probably realising a significant amount of internal collaboration and efficiency).
Ultimately there are risks and benefits associated with both types of PLM adoption – whether it’s PLM alone or as part of a wider platform strategy. I have seen businesses of all shapes and sizes adopt PLM in all manners and deployments (in a multitude of system strategies), and the essential strategy c
Apparel PLM is flexible, it can be iterative, it has OOTB functionality and has a great selection of vendors. However it is ultimately an important strategic system which brings about massive business-wide changes both internally and along the extended supply chain. From my experience of apparel PLM projects I know that the best approach is almost always the simplest. Get the core parts properly implemented (whatever type of solution you choose to adopt), working efficiently and returning value and before you know it the rest will fall into place.an always be boiled down to: assessing the key current business needs; looking at the drivers for the future; reviewing the internal resources (both financial and human productivity); and properly assessing the vendor landscape. Apparel PLM can be deployed on a phased approach (I.e. just core tech pack requirements) or it can go live with advanced functionality (such as advanced line planning) in place, jointly with an enterprise resource or supply chain system! No matter what project implementation strategy a customer adopts, there is a fine line between huge, quantifiable returns and six figure losses. Figures from our industry wide customer report in 2010 show that almost 60% of customers’ apparel PLM implementations overran budget and time, with choice consumer quotes being: “We tried to do too much too fast”; “ [We didn’t] monitor the objectives and timelines closely”; and “[Our project overrun is] 30 months and over 10 million dollars”. For me the most important quote there is the first one.
Read the other blogs from this series –
One Size Fits All Series: Blog #1 – The Chicken or the Egg
One Size Fits All Series: Blog #2 – The Greatest Returns Come From Knowledge and Planning
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