LPM
  • Home
  • Basics
    • Waarom
    • de 1-product company
    • high mix/low volume
    • CTO/ETO
  • Kern
    • Benamingen
    • Wat vs. Hoe
    • Modulariteit
    • Modules
    • Standaardisatie
  • Commercie
    • Opties 1: Principes
    • Opties 2: Prijzen
  • Operatie
    • Stuklijst
    • Kostprijs
    • CoCoS
  • Contact

De Stuklijst

Binnen de 'Hoe'-dimensie van de  LPM methodiek is een centrale rol weggelegd voor de 'stuklijst.' 
Niet omdat deze stuklijst een doel op zich is maar omdat ze een middel is om de verschillende onderdelen van de operatie aan elkaar te verbinden: engineering, inkoop, logistiek, productie, service en finance. Dat gegeven leidt ook direct tot verschillende belangen en perspectieven - en daarmee niet zelden tot spanningen of compromissen.

De Gebruikers: One size fits none

Laten we eerst eens starten met een overzicht van de verschillende belangen van de diverse disciplines (zonder compleet te willen zijn) :
  • Engineering: Technische samenhang en structuur van het product, functionele logica en onderhoudbaarheid.
  • Inkoop: Afbakening van uitbestedingsscope t.b.v. make/buy beslissingen, onderliggende artikelgegevens nodig voor inkoop afspraken.
  • Logistiek: Relatie tussen productgroepen en voorraad locaties, besluiten m.b.t. replenishment en safety stock.
  • Productie: Inrichting van het productieproces, koppelen van werkinhoud aan samenstellingsniveaus, voorbereiden van werkinstructies.
  • Service: Terugvindbaarheid en toepassing van artikelen, aanmaak van service kits, as-built gegevens, voorbereiden van terugroepacties.
  • ​Finance: Analyseren van productkosten, marges, toekenning van verdeelsleutels over kostengroepen, bepalen van work in process.
Voor niemand zal een enkelvoudige stuklijst het perfecte antwoord op iedere vraag zijn en dat leidt ertoe dat er vaak verschillende varianten van de stuklijst naast elkaar bestaan, of beter gezegd verschillende 'views' op de basis stuklijst. Hoewel er veel softwarepakketten zijn die dit tegenwoordig ondersteunen betekent dit wel altijd een toename aan complexiteit en onderhoud inspanning, dus die afweging moet kritisch gemaakt worden.
Foto

Artikel types

Wanneer we ons even beperken tot de fysieke artikelen in het product kan het zinvol zijn om deze te categoriseren. Hierbij kunnen verschillende invalshoeken genomen worden, zoals bijvoorbeeld: 
  • wie maakt het? > make / buy
  • wie definieert het? > OEM / leverancier
  • wat is het samenstellingsniveau? > assembly / monodeel
  • wat is het producttype? > mechanisch / hydrauliek / electronica / ...
  • wat is de relatie naar de order? > generiek / orderspecifiek
  • hoe wordt het ontworpen? > eenmalig / parametrisch / customized
  • hoe wordt het verworven? > kanban / shelf / per order
  • wat is de besteleenheid? > stuks / meter / liters / ...
Deze onderverdelingen sluiten elkaar niet uit maar overlappen vaak; als hiermee geen rekening wordt gehouden in het gebruikte IT systeem kan dit leiden tot een onvolledig overzicht en veel zoekwerk. De grote achilleshiel is hier ook weer onderhoudbaarheid en discipline.
Voorbeeld : Een framebalk voor een machine met producttype plaatwerk kan door de OEMer ontworpen zijn met een parametrisch bepaalde lengte en plaatdikte, gemaakt worden door de leverancier die 2x per week orderspecifiek een batch van 10 onderdelen aanlevert. Het samenstellingsniveau is assembly maar het bevat ook door de leverancier ontworpen en via kanban  opgeslagen monodelen.
Foto
Picture
Picture

De inhoud van de stuklijst

Gezien het voorgaande is het niet verbazingwekkend dat de inhoud van de stuklijst verschillende vormen aan kan nemen, afhankelijk van bedrijfstype, product of productieproces. In zijn meest eenvoudige vorm bevat de stuklijst uitsluitend fysieke hoofdassemblages of artikelen zonder aanvullende onderdelen zoals bevestigingsmiddelen e.d. en ook geen productie-arbeid informatie. Bij meer uitvoerige toepassingen van stuklijsten kunnen daar de volgende elementen (weer niet uitputtend) aan toegevoegd worden:
  • alle gedetailleerde fysieke onderdelen
  • referenties naar bijbehorende of embedded software code 
  • uren-informatie gerelateerd aan fabricage- & assemblagestappen
  • codes en documentatie t.b.v. bewerkingsstappen in productie (bijv. lasbewerkingen, verbindingstechnieken, oppervlaktebehandelingen, reinigingsstappen)
  • kwaliteit-borgings documentatie
  • serienummer informatie
  • ontwerpverantwoording
  • leveranciers documentatie
  • calibrate instructies
  • productielijn gegevens

Hoewel het mooi lijkt om dit allemaal compleet bij elkaar te hebben in een enkele stuklijst kan het opzetten en onderhouden wel erg complex worden. Al deze componenten hebben immers hun eigen life-cycle, versionerings-methode en relaties naar andere afdelingen of zelfs externe partijen. Ook zullen ze voorkomen in vele andere stuklijsten met ieder hun eigen dynamiek.
Er is hier geen eenduidige 'best practice' aan te geven: wel is het altijd verstandig te zorgen voor zoveel mogelijk ontkoppeling van al deze elementen met het liefst ook hier een modulaire aanpak.
Foto

Wat is de ware stuklijst?

De zojuist genoemde artikelinformatie ligt meestal vast in een IT systeem met ERP-achtige functionaliteit. Uiteindelijk wordt daar ook de stuklijst in vastgelegd. Maar de oorsprong van de stuklijst komt in de meeste gevallen vanuit engineering en daarmee uit een CAD omgeving. Daar ligt gelijk een spanningsveld:  wat is nu de 'ware' en geldige stuklijst? Voor de engineer is dit duidelijk, dat is 'zijn' CAD stuklijst. Voor de productiemanager is het ook duidelijk, 'ERP is de enige waarheid'.
​Naar goed gebruik wordt de CAD stuklijst conform een vastgelegd goedkeurproces vrijgegeven naar productie om vervolgens deze stuklijst te verrijken met specifieke gegevens die niet onder verantwoording vallen van engineering maar van de operationele afdelingen. Hierbij kunnen PLM  pakketten (Product Lifecycle Management) behulpzaam zijn. En toch treden hier vaak problemen op in de praktijk, zeker bij de minder grote bedrijven.

Die problemen kunnen liggen op het gebied van de inhoud (wat moet er nu wel of niet in zitten), de kwaliteit, de structuur, het versiebeheer; maar ook op het gebied van het proces: wie is voor welke stappen verantwoordelijk en wanneer wordt welke informatie vastgelegd en 'bevroren', hoe verloopt de communicatie in het voortraject en op welke manier wordt de kwaliteit getoetst.
Hoewel het te ver voert om hier op al deze aspecten in te gaan kunnen wel een aantal algemene 'best practices' vermeld worden:
  • Leg ondubbelzinnig vast wie waarvoor verantwoordelijk is
  • Volg een vaste structuur voor de (verschillende typen) stuklijst(en)
  • Kies een passende methodiek voor versiebeheer (voor alles!)
  • Zorg dat duidelijk is wat er wel/niet in de CAD vs ERP stuklijst hoort
  • Pas consequent een robuust en niet te complex vrijgifteproces toe
  • Toets dit proces op het gemak om verstoringen te verwerken
  • Laat 'afkortingen' in het proces authoriseren op het hoogste niveau
  • Organiseer effectief vooroverleg tussen de verschillende afdelingen
  • Zorg dat de IT tools de mensen ondersteunen en niet andersom

En dan is er natuurlijk de kostprijs

Een belangrijke functie van de stuklijst is het kunnen bepalen van de kostprijs van het product.
Dat is het volgende thema in deze reeks.
Kostprijs
NB: Deze site is in ontwikkeling en zal aangevuld worden met nieuwe artikelen. Toch al nieuwsgierig naar meer? Klik voor contact!
Powered by Maak je eigen unieke website met aanpasbare sjablonen.
  • Home
  • Basics
    • Waarom
    • de 1-product company
    • high mix/low volume
    • CTO/ETO
  • Kern
    • Benamingen
    • Wat vs. Hoe
    • Modulariteit
    • Modules
    • Standaardisatie
  • Commercie
    • Opties 1: Principes
    • Opties 2: Prijzen
  • Operatie
    • Stuklijst
    • Kostprijs
    • CoCoS
  • Contact