WIXLIB

Part 2Enterprise Resources Planning (ERP)The core of most enterprise applicationarchitectures since the 1990s, thesestarted life as accounting systems and thenexpanded – often through acquisition – toa suite of business applications that reachinto most parts of the business, usuallydriven by the Finance function.As every supplier is at some point paid, ERPhas at least some data associated witheach supplier and it is likely to be integratedwith the S2P solution. IT and Finance teamsalso often like having ‘one throat to choke’in terms of vendors to manage, but beyondthis, ERP has little in its favour as a supplierrelationship management platform.As with S2P, ERP is built for transactionsand so sub-optimises the managementof data for any other use case. ERPis notoriously inflexible, without largeinvestment in customisation. AP and ITteams almost never allow any changesto the system by end users, and supplieraccess would be unthinkable, so some sortof gateway application is required to satisfydata and security requirements.Even the most ERP suite-friendly CIOs (adying breed) rarely view ERP as a viablemaster data management platform andwhile ERP is an integral part of the suppliermanagement technology infrastructure,it lacks the core flexibility and datamanagement capabilities that are essential.Master Data Management (MDMPlatformsMost commonly adopted as part of anIT-driven project to improve data quality,management and governance, MDMplatforms fall into one of two broadcategories – domain specific or multidomain. The most mature domain-specificMDM solutions are Product InformationManagement (PIM) and Customer MDM –these are both well-established categorieswhich combine an MDM layer to ensurea single source of truth, with applicationfunctionality related to the product orcustomer record. Multi-domain MDMsolutions, in contrast, are essentially datamanagement and governance toolkitswhich in theory can be applied to all, andany number of data types, i.e. domains.Multi-domain MDM by its nature does notusually include application functionalityrelated to any given domain and so israrely considered by business-line buyersfor whom domain context and applicationfunctionality are much more importantthan pure MDM capabilities, and hereinlies the challenge for supplier relationshipmanagement. Buying a generic MDMtoolkit will provide a strong data foundationbut thereafter will require a significantinvestment, which in practical terms is muchcloser to the ‘build’ option defined below.HICX – Supplier Management Platform In summary:The software categories most oftenconsidered for supplier management all fallshort in different, but equally fundamental,ways when assessed against the criteriasummarised in Part 1 of this document.While ERP and S2P solutions alreadyoperate in the supplier domain, alreadyinclude part of the supplier dataset, andare already trusted by those teams that aremost likely to use a supplier relationshipmanagement system, by their very nature –having been built for transactions, not data– they are unable to satisfy the foundationalrequirements. Indeed, there is no realdebate to be had because both categorieshave existed for well over 20 years and bothclaim to address supplier data – yet there iswidespread consensus that supplier data isstill a major challenge for most companies.And on the other hand, MDM solutions tickall of the data management boxes, butnone of the supplier domain functionalityboxes, leaving project teams with thedaunting task of defining the end-to-endrequirements, and a long and expensiveimplementation and roll-out project toendure.Build OptionWhile the idea of a completely bespokesolution tailored to the precise requirementsof the business is appealing, in recent yearsmost large enterprises have tried to avoidthis except in cases where the solution itselfrepresents a clear competitive advantage.Instead, enterprise IT teams, working withtheir major systems integrator partners,have sought to at least start with packagedsoftware and then customise this toaddress any gaps in functionality.Customisation, however, brings with itits own set of drawbacks – custom codeis usually not supported by the softwarevendor and customisations are not includedin vendor regression testing which meansupgrades are either simply not possible ormust be managed very cautiously and onlyafter a great deal of internal testing andreversion planning. Changes to customisedcode usually rely on the 3rd party or inhouse team that developed it, which mayresult in increased costs as the 3rd partiesaren’t able to take advantages of economiesof scale for bespoke applications; andsooner or later the customised code maysimply become uneconomical to support,leaving the customer with limited optionsand a great deal of IP sunk into obsoletecode.Furthermore, a custom-developed solution,even if it manages to address the initialuse cases satisfactorily, will not receivethe same level of investment in R&D.Developments will be limited to minorPage 6

Part 2improvements based on end-user feedbackand there will be none of the innovation thatone can expect from software developed forsale to multiple customers.If customisation, then, is becoming lessand less appealing, developing bespokeapplications from the ground-up suffersfrom many of the same drawbacks –expensive to maintain as teams evolveand individuals move on, and high changemanagement costs. To these can be added: Slow and expensive requirements anddesign phases. While end-users knowwhat they do today, they’re not usuallyfamiliar with software requirementsdevelopment, so the role of businessanalyst and product manager becomescrucial, Difficult roll-out and adoption phases.With the best will in the world, customapplications don’t always start withthe best user experience as pressureto release ‘MVP’ (minimum viableproduct) tends to trump end-user UI. Escalating project costs. Initialestimates of what is required almostalways underestimate the complexityinvolved in large organisations withglobal requirements and a hugenumber of unknowns. Seeminglysimple projects become more and morecomplex, requiring more and moreinvestment and stakeholders are oftenunwilling to stop given the amountsalready sunk into the project. Infrastructure costs for hardware,data centres, redundancy etc. Partlymitigated if developed on cloudplatforms, but still need to be managedand budgeted for by the project team,HICX – Supplier Management Platform Operations, support and roadmap. Veryquickly organizations find themselveshaving to make this a core capability.There is a reason why Google,Microsoft, Facebook, Amazon, etc. stilldon’t build their own ERP systems or,even if like Microsoft they do, they don’tuse what they build. It is very hardachieve the same level for experienceand learning as someone who is doingthis as their core business. Security challenges for custom-builtsoftware. Often only discovered overtime this can create a huge amount ofrisk for organisations handling supplierdata.The point about the requirements anddesign phase warrants a little moreattention, as it is one of the obviousadvantages that is traded when choosing‘build vs. buy.’ Even if a given softwarevendor has only limited knowledge ofa company’s sector, and next to noknowledge of their specific processesand environment, they will still have theadvantage of: Effective requirements gatheringexpertise honed by serving dozens orhundreds of other businesses with atleast similar processes. Templates – either literally a library, orde facto in the production instances ofother clients – that can likely be clonedand edited. Time-to-value – it’s easy tounderestimate the value of theconcentrated real-world experiencethat vendor implementation teams(or their partners) have from multipleprojects and the impact this on timeto-value. They have already made alot of mistakes, iterated a lot of designdecisions, crowd sourced ideas andbattle-tested processes and conceptswith comparably large and complexenvironments. External Perspectives – it is easy forlarge organizations to get caught upin how they have always done things.The ability to see other perspectives,use cases and have constructivechallenging is critical in drivinginnovation. The old saying of ‘we onlyknow what we know,’ still holds trueand often leads large organizationsdown a dead-end road which is too farout to see in the early stages.In summaryIt is perhaps not surprising that fewcompanies in the Global 5,000 have thelevel of control, insight and data qualityneeded to take full advantage of theirsupplier ecosystems as summarised in therequirements presented at the beginning ofthis document, given the limitations of theavailable packaged software in the adjacentS2P, ERP and MDM categories, and giventhe justifiable shift away from buildingmajor enterprise applications in-house inthe last few years.There is emerging, however, a third waythat leading global multi-billion dollarorganizations across multiple sectors,including EDF Energy, BAE Systems,Mondelez, Baker Hughes and more areadopting; a best-of-both-worlds approachwhich provides the genuine flexibilityof a ‘build’ approach, with most of theadvantages of buying a packaged softwaresolution, and it is based on the rapidevolution of low-code development tools inthe last few years.Page 7

Part 3Low codeIn many ways low-code development is not new, but ratherthe latest stage in the evolution of the way in which softwareapplications are built. In simple terms, low-code can be viewedas a series of building blocks – the Lego analogy is often used –that can be assembled to create fully-functioning applications,without the need to write code.This continues a trend which, since the early1980s, has sought to make developmentfaster and more efficient by distributingsome of the work to end-users by providingintuitive interfaces, and which wasaccelerated massively with the adventof cloud platforms which deal with muchof the operational burden of softwaredevelopment – hosting, redundancy andback-up, security, access management etc.In its paper, “Low-code DevelopmentTechnologies Guide” Gartner includes a‘Pyramid of Applications’ which shows theextent to which low-code has worked itsway up different classes of application, fromsimpler and less mission-critical ‘workgroupclass’ and ‘departmental class’, low-code isnow actively being adopted for the secondhighest, ‘enterprise class’ of application,with only ‘Extreme-scale’ above it. In otherwords, low-code as a methodology isnow deemed suitable for highly complex,mission-critical enterprise applications.HICX – Supplier Management Platform Low-code for supplier managementDifferent companies manage their suppliers,and govern their data in vastly differentways based on industry and organisationalhistory. There is no right or wrong, as it iscompletely driven by context. Decisionsaround how much is centralised andhow much is localised have dramaticimplications at the foundations of anysupplier data management approach.How the organisation and the surroundingfunctions that touch suppliers are organized(Quality, Health and Safety, Sustainability,Treasury, Finance, Marketing, Sourcing,Procurement, etc.) will all drive how thosefoundations are laid. Those foundations areultimately what enable your end state visionaround digitalisation, simplification, andautomation of supplier management relatedbusiness processes.Page 8

Part 3The days of IT delivering allapplications for the enterpriseare gone. The present andfuture depend on holistic andcollaborative delivery of digitalproducts by joint businessand IT delivery teams, and onthe elimination of separateenterprise IT and ‘shadow IT.’Low-code development is apivotal enabler for this.GartnerLow-code DevelopmentTechnologies Evaluation GuideHICX – Supplier Management Platform If the above advantages are applicable tomore or less any business application, inthe context of supplier management, thekeyword is ‘flexibility.’ In organizations withtens or even hundreds of thousands ofsuppliers, serving multiple business units, nooff-the-shelf solution can possibly accountfor all variations, so the ability to configureto accommodate any scenario is the secretsauce of low-code.By flexibility, we mean:The data modelAs discussed above, at the core of suppliermanagement is the master data record orsingle version of truth for each supplier,and while there are obvious attributesthat are always needed – supplier name,location, bank details etc. – in practiceno supplier record is the same for everybuying organization. Variety is driven bythe different types of supplier (indirect,direct, government, strategic, tactical), theindustry sector, the ERP(s) used, the S2Psystems and the unique micro-processesused in different businesses. Assumingthat ‘the supplier record’ is fixed and can bedefined up-front to cover all future scenariosis absurd, so it is essential that (ideally)business users can add to the supplier datamodel as new scenarios arise.WorkflowThe term covers a multitude of capabilitiesbut examples in supplier managementinclude the on-boarding approvals process;managing workflow associated with newsupplier types – is there a different setof approvers or a more (or less) rigorousapproval process specifically for thissupplier type; new legislation – for exampleassociated with management of end-oflife of manufacturing waste could requirechanges to the off-boarding process. Aswith the data model, low-code, with itsgraphical interface and building blockapproach enables non-technical staff toassemble individual tasks and rules intoan end-to-end process, without the needto go through a complete change requestcycle with a 3rd party vendor or the ITdepartment.FormsThe most visible part of the solution, and theone most likely to impact adoption. Changesto the underlying data model or workflow,or simply changes needed to improveusability will often require modificationsto the forms used by requestors, suppliersand approvers. These forms may well bein active use by potentially thousands ofusers, so without a low-code approachmaking even a small change can require alengthy request, implementation and testprocess, all performed by a team otherthan the end-user. With low-code, buyingorganizations make changes to forms on analmost daily basis with no negative impacton the system.Automation and alertsSupplier-related events that trigger alerts– such as a new sanctions match, or beingalerted that a business is now singlesourced in a given category – are essentialin businesses with high supplier volumesand, as with workflow and data model,are subject to frequent modification which,ideally, shouldn’t require a change requestinto IT. Using low-code building blocks and‘IFTTT’ (If This Then That) style interfaceenables end-users to configure highlybespoke alerts as needed.Validations and integrationsAs legislation is introduced or changed,supplier compliance is impacted, andsuch change is only increasing. Even inmoderately regulated sectors, stayingcompliant with financial, labour and dataprivacy laws across the entire supplierecosystem is a significant undertakingand integrations to third party sources ofcompliance data – such as D&B, EcoVadis,Maplecroft – automate much of this. Lowcode enables users to configure processflows to include call-outs to these thirdparties at the appropriate point in theprocess and / or when triggered by anevent.Stakeholder surveysWithin performance management,businesses in certain sectors run highvolume stakeholder-based performanceassessment programs which requirecomplex hierarchies in order to filter andorganize assessments based on multiplefactors, including supplier type, product,location, BU, project and more. Low-codeenables business users to configure newsurveys quickly by assembling the buildingblocks – forms, scoring model, assessmentworkflow, KPIs and reporting – into anycombination needed.Page 9

Part 3Domain is kingWhile this paper argues that low-codeis the best option for large organizationswishing to address the challenges ofsupplier management, it’s also worth notingthat not all low-code platforms are thesame. As with other software categorieswhich can loosely be classed as ‘tooling’ –databases, reporting tools, MDM (MasterData Management), for example – whenselecting a low-code solution, there is ageneric versus domain-specific question toconsider.For IT departments assembling atechnology stack in order to supportrequirements from multiple departmentsin the business , emphasis is likely to beplaced on areas such as how wide thetalent pool is, documentation, communitysupport, usability, interoperability, platformand security considerations. This is similarto software companies themselves selectinga technology stack like ‘LAMP’ – how easywill it be to hire developers, will the resultingapp work on the platforms our customersuse, will it enable integration to othertechnology environments etc.We would argue the above are ‘generic’scenarios, and the same principles canapply when selecting a low-code platform.If an IT team wishes to encourage adegree of ‘citizen development’ and / or touse low-code principles to speed up appdevelopment, then it might select a genericlow-code platform.– and yes it should in theory enable nontechnical end-users to make substantialchanges using intuitive UI and a buildingblock approach, but in practice, none of thedomain-specific benefits apply.As discussed earlier, the requirements anddesign phase is crucial and a generic lowcode platform provides no short-cuts orhead-starts.Using a generic low-code platform, domainspecific integrations, which in the world ofsupplier management means ‘punch-outs’to 3rd party data providers for supplier riskand compliance information, do not existby default so those ‘building blocks’ needfirst to be built. Similarly, the data modelmust be defined from the ground up – ormore likely based on the vendor master inthe dominant ERP system, which in turnsub-optimises the data model for all otherapplications. Workflows, including supplieron-boarding and approvals processes donot start with a library of templates basedon other customer implementations and somust all be defined from scratch.Just as in the case of domain-specificmaster data management, therefore,a low-code platform that has suppliermanagement domain context representsa genuine third way that combines thebenefits of speed and existing IP with theflexibility of a bespoke solution.This, however, is almost completing thecircle back to the ‘build’ option which islargely discredited above. Yes, generic lowcode platforms will reduce the operationalburden of development – hosting, security,release management, regression testing etc.HICX – Supplier Management Platform Page 10

Part 4Business case considerationsThe key business case therefore comes down to a comparisonof build versus configure using low-code in order to achieve theflexibility of build, but without the associated cost and resource.There are five key considerations toevaluate in this regard: Scope to be covered within allottedbudget and time. Development costs, including ongoingmaintenance and upgrades. Cloudbased solutions will likely be more costeffective over the life of the project,and will certainly be easier and moreefficient to upgrade. Speed to deployment, with a focus onhow long it would take to build versusconfigure a low-code. Expertise required (cost of mistakesand unknowns). For example, theextent to which end-users can makechanges themselves versus havingto engage a member of the IT or 3rdparty development team will have asignificant impact on costs (see thesection on ‘flexibility’ above for thetypes of changes, in particular withregards to domain specific changesand updates).HICX – Supplier Management Platform Running costs. If a solution is cloudversus hosted, or on premise, theoperational cost model will vary; as itwill if the solution is bought based ondomain-specific low-code platformversus developing a solution in-houseform scratch. Training. The cost of end-user(business user requestors’, suppliers’,approvers’) training might be assumedto be a wash. After all, any solutionmust be ‘easy-to-use,’ but this isn’ttrue in practice. Close attention mustbe paid to training resources andmaterials, learning curve, adoption androll-out, especially if a home-grownsolution is to be developed.Page 11

Part 4The differences in cost and resources relating to the above can therefore be summarised asfollows:ScopecoverTypicalDevelopment time y Low 5-10 mil.3-5 yearsLowcodeMedium 2 mil.DomainspecificLowcodeHigh 500k-1 mil.RunningcostsTrainingcostsHighHigh: 10-20x formaintenance,hosting,integration,service , 1-4FTEs for adminand supportNegligible5 monthsLowNegligibleNegligibleConclusion: The best of build and buyThe success of most multi-national multibillion dollar organisations is to a significantdegree dependent on how they manageand engage with their supplier base. It isno longer realistic to assume suppliers willalways want to work with you, will toleratecontinued price pressure, or will acceptdeeply inefficient or painful processes whendoing business with you. Nor is it realisticto develop digital transformation plans thatin any way involve suppliers if companieshave poor quality and incomplete supplierdata, and are unable to derive insights fromthat data.Some of the largest companies in theworld recognise this and are investingin comprehensive supplier managementcapabilities that will extend across theentire supplier lifecycle. However, theHICX – Supplier Management Platform inability of the ‘usual suspects’ vendorcategories (ERP, S2P and MDM) to addressthese challenges with off-the-shelf solutionsis driving many of these businesses tore-consider a ‘build’ strategy, despite thewell-understood disadvantages.A third way, however, is increasingly beingincluded in the mix and is reaching a levelof market maturity as the early adoptersmove into steady state and are realisingsignificant benefits. Supplier managementplatforms, built on domain-specific MDMand incorporating a low-code developmentmodel combine the convenience ofpackaged software with the flexibility of abespoke solution.Page 12

HICX is a low-code, software-as-a-service platform, that enables seamless digital suppliermanagement. We enable businesses to find, maintain, and re-use trusted supplier dataand information across their enterprise, across any spreadsheet, app or system. We ensureour customers achieve their goals and business outcomes with minimal IT input andexpense using a platform based on an agile, high configuration building block approachand man

Supplier lifecycle Workflow and data management to support other events in the supplier lifecycle, such as new products, extending the supplier to work with new buying entities, managing compliance, performance assessments and off-boarding suppliers. Risk and compliance management Managing risk and ensuring supplier