In the second instalment of an exclusive series, business process expert Kilara Le continues to examine the increasingly diverse role that PLM (in both its core and E-PLM forms) plays in the product lifecycle. This month, Kilara covers the benefits (and potential pitfalls) of integrating a variety of systems with PLM in order to optimise the vital planning stage that serves as the spark for what will become retail products.
My last column took a broad overview of the typical processes and software solutions that have become intertwined with product development across the fashion industry – very often overlapping or integrating with PLM. In this and the following few columns, I want to dive deeper into some of those elements and examine how they can be streamlined, further connected and improved as individual pieces of a more cohesive whole.
Although this column will look at product development as a seasonal process (driven by the mercurial changes of fashion), it is worth bearing in mind that these seasons are not as cleanly separated as you might think. Often the tasks associated with separate seasons overlap, and each is likely to be at a different stage of the overall process at any given time. Each season has its own roadblocks and unexpected obstacles, and when those intertwine they can prove difficult to separate – which is why clear visibility throughout the entire product development cycle (seasonal or otherwise) is essential.
We all know that “hindsight is 20/20”, as the saying goes, but the right advance planning and process visualization methods can bring many of the benefits of that kind of retrospection to the present, lending real insight into the day-to-day decisions surrounding seasonal product development.
In my previous column I wrote about systems integration and its impact on product development. The lessons I set out there are nowhere more valid than at the start of that planning process – the time at which the potential for a product truly begins to form. At this early stage there is absolute value to be derived from creating integration points from financial and/or line planning systems to PLM, a Point of Sale (POS) solution to that planning system, POS to PLM, or, indeed, whatever combination makes sense within the established framework of your organisation.
It is important to remember, though, that where systems integration is concerned, I am of the mindset that the simplest strategies are often the best. Unnecessary points of integration typically waste time and money, and sharing data between systems not suited to such integration can actually create inefficiencies in the form of information overload. However, too little information included in the integrated network of systems tends to push end users back, with them retreating to Excel spreadsheets, and you may find that those same end users do not use the system as envisaged or, in some cases, at all, as a result.
To ensure that the large investment made in systems and integration at this stage is not wasted, it is important to map the most essential points of data sharing: soliciting and validating the input of all parties currently using (or likely in future to use) the system. These data points can be reevaluated in future seasons and, if information is missing, it can be easily incorporated, especially if your internal IT team is capable of doing so.
Clearly there is a delicate balancing act when it comes to deciding what data must be shared and integrated. On the one hand we seek to create clarity and understanding by allowing systems to interface with one another – minimising our reliance on single-use reports and Excel spreadsheets. On the other, we must try to replicate as much of the functionality of those reports and spreadsheets as possible, lest users revert to them instead of working with newly installed or newly integrated systems.
In order to retain as much of that original functionality as possible, many organisations resort to the tried and true method of cutting and pasting reports from different systems into new Excel spreadsheets. What many do not realise is that their solutions must allow them to generate new reports from that existing data in order to remain useful. Every organization will at some point (despite the protestations of software providers and programmers) want to report on the data contained within, and shared between, their solutions. If you cannot report on data in an easy and intelligent way, what is the point of entering it in a database in the first place? This is a problem that can be compounded when the required reports rely on data shared between multiple integrated systems and the integration points do not include all of the information needed by the users.
So, how should companies approach integration at this vital stage of product development?
Integration, or the future potential for integration, should be planned and accounted for when implementing any system. A good rule of thumb is to assume some kind of integration will take place in the future – that the data contained within this new system will at some point need to be used by or aligned with another – and at a minimum set up structural synergies that will make this eventual process smoother. Before any actual integration points are created, a lot of essential information can easily be compared and contrasted with current higher level financial goals to help determine future plans for divisions, categories, labels etc., provided the structure of the data they rely upon matches.
For example (and this may sound like a minor detail, but is emblematic of the core difficulty where systems integration is concerned) if your planning system is structured as brand/label/division/category/product type, and your PLM system structured as division/label/product type/category, internal teams may find collaboration difficult, and systems integration could require customization to take account of the differing data structures. In addition to this, each system – not just planning and PLM, but ERP and warehousing – may also have level limitations, such as 3 levels of hierarchy or 10 character identification number limits, all of which must need to be identified ahead of time to speed eventual integration and should have been identified at the time of implementation of each one.
Some PLM solutions incorporate financial and merchandise planning modules or elements, whereas others boast tight integration to leading planning solutions. In both cases the intention is the same – to use sales performance data and consumer metrics gleaned from previous seasons to inform the direction of upcoming ones – but their capabilities differ, and a case can be made that multiple separate, class-leading solutions, boasting seamless integration, will be able to deliver greater insight in a shorter timeframe. With older, legacy systems, a reporting tool that pulls from the systems involved, and acts as a middle layer, may be the best interim solution.
In PLM systems that do have merchandise / financial planning capability, unless additional data entry is undertaken it can often take several seasons or a year to gain useful visibility into that data, and to use it to create meaningful targets. If a separate planning system is in use, the depth of information that is captured may be more detailed or (provided the systems are properly integrated) more closely informed by actual POS data than that available in a standalone PLM system. This improved detail enables a deeper analysis of sell-through and better target market prediction – particularly where carefully chosen aspects of this data flow through PLM. If POS system data (in the case of retailers) or data from an ERP or separate PO system is available, selectively integrating order volume, sell though information and more can be a boon to effective planning and the creation of realistic targets.
After high level financial targets have been set for the upcoming season or delivery cycle, the next step will depend on how your organization works and the typical collaboration between planning, merchandising, trend, and design teams. Product targets may already be set down to the product category level (for example, ten styles of knit short sleeve tops) or they may just be at the division level (for example, 3% margin growth for the entire division). Maybe product ideas have already been created in your PLM or PDM system and need to be married with categories; maybe your product categories need to be separated into bodies, trends, or fits for designers to design towards.
So, how are these individual styles or products then assigned to match these goals? And how does systems integration fit into this picture?
After merchandise planning has begun (informed by the collected data and inspiration collected by the trend and other teams in parallel to financial planning), we arrive at the point at which the association between workflows and calendaring to individual products is assigned in a PLM system. As each company works differently, this could be pre or post initial line review meetings, depending on the sequencing of planning. Whether or not the financial goals are tied to this association depends on the systems and level of permissions: some extended systems will flow financial goals and delivery dates directly into the product irrespective of whether development has already begun, or can be used to indicate that that same development needs to start.
In a typical scenario, workflow tracks the tasks assigned to each responsible party to ensure that the product is developed from point A to Z as well as the estimated duration of each task. This in turn is tied to a development calendar with appropriate lead times and estimated task completion times based on the type of product being developed. As the person responsible completes each task in the list, the workflow should automatically route the product to the person responsible for the following task.
As there are many events happening in parallel, most workflows allow for tasks to be running or completed with some degree of flexibility, but not to go beyond a certain point unless all of the previous tasks have been completed. For example, lab dips and fittings may be happening at the same time, but final garment or wash testing may not be able to be completed until both have been approved. Because the estimated duration of each task is entered, an estimated end date can be calculated. These calendar dates will be continually updated based on when the prior tasks are completed, allowing for more accurate production planning for insurance of on time delivery. Most PLM systems will generate visual or email alerts if any of these milestones are missed, as the risk of on time delivery of the product can obviously be threatened by incomplete tasks at any stage.
This is where the importance of extending PLM’s role (either using a standalone system or via bi-directional systems integration) into planning and design adds true value. The visibility afforded by using a PLM system (or suite of solutions tied to the centralized data repository that is PLM) means that decisions can at this stage be made – decisions that will get the product to market faster, perhaps by changing the shipping method or production location as a result of this insight. If the issue is serious enough, or sales of that trend are declining, perhaps the product should be dropped altogether or planned into another collection for a future season.
We have only scratched the surface of PLM’s potential (integrated or not) for supporting the planning and design process, but already we can begin to see how the trend, merchandising and design activities that give rise to the ideas and concepts that create garments belongs in PLM. Without it, or without properly integrated systems with equivalent capabilities, organising the visual and planning elements of product development can present a sometimes-insurmountable challenge.
Whatever the size or shape of the company, while past season analysis is being conducted and financial goals are being set, on the other side of the collective company brain – the “right side” – trend, color and possibly fabric decisions are being made in parallel to the establishment of those margin goals. Where these two worlds meet depends on the company, but as both rely increasingly upon technology (often separate technological systems) the support and integration potential offered by those systems becomes increasingly vital to allowing the two facets to combine towards the business goal of developing actual products and styles.
In my next column, I will look at how this same ethos is extending PLM’s role ever further, as we move beyond planning and into the next stages of the product development process.