Verantwoordelijkheden en beslissingsbevoegdheid voor afdelingsoverschrijdende samenwerking bij 3D-printen

Inleiding: falende samenwerking is vaak geen houdingsprobleem, maar een gebrek aan gedefinieerde beslissingsbevoegdheid

Bij de uitvoering van 3D-printorders ontstaan vertragingen en herstelwerk zelden doordat iemand niet wil meewerken. Vaker wordt hetzelfde vraagstuk twee keer tussen drie afdelingen doorgestuurd voordat er daadwerkelijk een besluit valt. Ontwerp vindt dat de wanddikte mag worden verruimd, procesengineering stelt dat volgens de oorspronkelijke tekening moet worden geprint, kwaliteit houdt vast aan beoordeling volgens de tekening en sales heeft de levertijd al mondeling aan de klant toegezegd — alle vier werken zij “samen”, maar niemand heeft expliciet de bevoegdheid gekregen om de definitieve afweging te maken. Wanneer een afdelingsoverschrijdend samenwerkingsmechanisme beperkt blijft tot “communicatiekanalen opzetten, regelmatig vergaderen en de afstemming versterken”, kan het de drie belangrijkste vragen niet beantwoorden: wie neemt het besluit, wie moet verplicht worden geraadpleegd en naar welk niveau wordt geëscaleerd bij een conflict.

I. Samenwerking terugbrengen van een communicatievraagstuk naar een vraagstuk van beslissingsbevoegdheid

De eerste engineeringmatige stap bij het inrichten van samenwerking is om elk afdelingsoverschrijdend onderwerp op te delen in delegeerbare beslissingseenheden, in plaats van het globaal aan één afdeling toe te wijzen. Een typische 3D-printorder bevat ten minste zes soorten afdelingsoverschrijdende beslismomenten: beoordeling van technische haalbaarheid (kan deze geometrie worden vervaardigd), keuze van de procesroute (combinatie van materiaal en apparatuur), levertermijntoezegging (inclusief uitbesteedde stappen), acceptatie van wijzigingen (moet na een aangepaste klanttekening opnieuw worden gepland), afhandeling van niet-conforme producten (herstel, acceptatie onder concessie of afkeur) en vrijgave voor levering (al dan niet inclusief inspectierapport). Als voor alle zes beslismomenten standaard “vergaderen en bespreken” geldt, worden beoordelingen die binnen minuten kunnen worden afgerond, vertraagd tot vergaderingen van dagen.

De engineeringmatige aanpak wijst voor elk beslismoment één unieke eindverantwoordelijke aan (Accountable). Let op: één unieke persoon, geen “gezamenlijke verantwoordelijkheid”. Twee gezamenlijk eindverantwoordelijken betekenen in een register feitelijk dat niemand verantwoordelijk is. De eindverantwoordelijke heeft de uiteindelijke beslissingsbevoegdheid; de overige betrokkenen worden verdeeld in geraadpleegden (Consulted, die vóór het besluit input moeten leveren) en geïnformeerden (Informed, die na het besluit de uitkomst ontvangen). Dit is de kern van de RACI-matrix: Responsible (uitvoerend), Accountable (eindverantwoordelijk/beslissend), Consulted (geraadpleegd) en Informed (geïnformeerd).

II. Regels voor het invullen van de RACI-matrix en veelgemaakte fouten

Bij het invullen van een RACI-matrix gelden enkele harde regels. Ten eerste heeft de A-kolom voor iedere beslissingseenheid precies één markering. Twee A's duiden op een ontwerpfout; de beslissingseenheid moet dan verder worden opgesplitst. Zo kan “afhandeling van niet-conforme producten” worden verdeeld in “classificatie van defecten” (kwaliteit A) en “keuze van de afhandelingsmethode” (procesengineering A, kwaliteit C). Ten tweede kunnen er meerdere R's zijn, maar de hoofduitvoerder moet worden aangeduid, meestal tussen haakjes. Ten derde mogen er niet te veel C's zijn: meer dan drie C's voor één beslissingseenheid wijst erop dat de kwestie te breed is verspreid en moet worden beperkt tot de twee à drie partijen die het besluit werkelijk beïnvloeden. Ten vierde betekent I niet dat iemand niet deelneemt: bij een mijlpaal zoals vrijgave voor levering moet sales als I de klantzijde binnen één uur na de uitkomst informeren.

De meest voorkomende fout is afdelingsnamen in de matrix zetten in plaats van rollen. Een afdeling is een organisatorische eenheid, terwijl een rol de drager van verantwoordelijkheid is. De rol van dezelfde afdeling kan per beslismoment volledig verschillen: de kwaliteitsafdeling is A bij “defectclassificatie”, maar slechts C bij “keuze van de procesroute”. De rijen van de matrix moeten rollen bevatten, zoals procesingenieur, projecteigenaar en kwaliteitsingenieur, en de kolommen de beslismomenten.

III. Interfacelijst: overdrachten tussen afdelingen formuleren als toetsbare items

Nadat de beslissingsbevoegdheid is vastgelegd, is de tweede stap het definiëren van interfaces. Veel afdelingsoverschrijdende frictie ontstaat doordat overdrachtsitems onvolledig zijn: een model dat ontwerp aan procesengineering overdraagt bevat geen materiaalaanduiding, een werkinstructie van procesengineering aan productie vermeldt niet hoe steunen moeten worden verwijderd, of een proefstuk van productie aan kwaliteit heeft geen printbatchnummer. Een interfacelijst moet drie velden expliciet vastleggen: naam van het overdrachtsitem, overdrachtsmoment en acceptatiecriteria. De acceptatiecriteria moeten objectief beoordeelbaar zijn, bijvoorbeeld: “het modelbestand bevat materiaalsoort, nabewerkingseisen, kritische maatvoering en versienummer”, en niet simpelweg “documentatie compleet”.

Het is raadzaam om voor elk overdrachtsitem in de interfacelijst een verplichte veldenset vast te leggen. Voor een werkinstructie die procesengineering aan productie overdraagt, moeten de verplichte velden ten minste omvatten: apparatuur-ID, materiaalbatchnummer, oriëntatie en ondersteuningsplan, laagdikte en bereik van kritische parameters, warmtebehandelingscurve, methode voor steunverwijdering en reiniging, en steekproefpercentage voor inspectie. Als ook maar één veld ontbreekt, mag de volgende schakel de overdracht weigeren; de weigeringstijd telt niet mee in de doorlooptijd van de ontvangende afdeling. Deze regel verdringt mondelinge instructies en documentatie die pas achteraf wordt aangevuld uit het proces.

IV. Escalatieregels: meningsverschillen mogen niet door herhaald vergaderen worden opgelost

Ook bij heldere beslissingsbevoegdheden blijven meningsverschillen mogelijk. Daarom zijn vooraf vastgelegde escalatieregels nodig, in plaats van ad hoc een leidinggevende te zoeken. Het is aan te bevelen escalatieregels op twee activeringsvoorwaarden te baseren: tijd en impact. Tijdactivering betekent dat een beslismoment na het afgesproken tijdvenster, bijvoorbeeld 24 uur voor een beoordeling van technische haalbaarheid, nog niet is afgerond en automatisch naar een hoger niveau wordt geëscaleerd. Impactactivering betekent dat het meningsverschil een levertermijnwijziging boven een drempelwaarde veroorzaakt, bijvoorbeeld meer dan twee dagen invloed op de leverdatum, of een kostenwijziging boven een drempelwaarde, bijvoorbeeld meer dan 5% van de stukprijs. In dat geval wordt onmiddellijk geëscaleerd en worden tegelijk de projecteigenaar en de klantcontactpersoon geïnformeerd.

Een geëscaleerd besluit moet een duidelijke uiterste termijn en een standaardactie hebben. Na escalatie naar de projecteigenaar moet bijvoorbeeld binnen acht uur een schriftelijke conclusie worden gegeven. Blijft een besluit uit, dan wordt standaard de “conservatieve optie” uitgevoerd: werken volgens de oorspronkelijke tekening en procesroute, met verlenging van de levertijd. Zo blijft het project niet hangen in een wachtstand. Het bestaan van een standaardactie vormt op zichzelf een drukmechanisme, omdat alle partijen er belang bij hebben binnen de termijn tot een conclusie te komen.

V. Het samenwerkingsmechanisme vastleggen in controleerbare registraties

Of een samenwerkingsmechanisme werkelijk functioneert, mag niet op gevoel worden beoordeeld. Er moeten drie soorten registraties zijn: beslisregistraties (conclusie, verantwoordelijke en tijdstip van elk beslismoment), interface-overdrachtsregistraties (overdrachtsitem, ontvanger en acceptatieresultaat) en escalatieregistraties (activeringsvoorwaarde, escalatieniveau en eindconclusie). Deze drie registraties kunnen zeer eenvoudig zijn — één regel in een gedeeld spreadsheet is voldoende — maar ze moeten bestaan. Tel maandelijks ten minste twee indicatoren: de gemiddelde doorlooptijd voor het afronden van beslismomenten en het percentage interfaces dat in één keer wordt geaccepteerd. De eerste indicator toont of bevoegdheden helder zijn; de tweede toont of de interfacedefinities volledig zijn.

Het is raadzaam om iedere maand vijf afgeronde projecten te selecteren voor een samenwerkingsevaluatie. Het doel is niet primair om schuldigen aan te wijzen, maar om de matrix zelf te corrigeren: bij welke beslismomenten is de A-markering in de praktijk nooit benut, wat wijst op te gedetailleerde mandatering; welke beslismomenten escaleren vaak, wat wijst op een te laag bevoegdheidsniveau of onduidelijke criteria; en welke interfaces worden herhaaldelijk geweigerd, wat betekent dat de verplichte veldenset moet worden aangepast. De matrix en lijsten moeten met veranderende bedrijfsactiviteiten worden herzien, met behoud van versienummer en ingangsdatum.

Conclusie

De engineeringmatige route voor afdelingsoverschrijdende samenwerking kan in vier stappen worden samengevat: verdeel samenwerkingsonderwerpen in delegeerbare beslissingseenheden, wijs voor elke eenheid één unieke eindverantwoordelijke aan en vul de RACI-matrix in, beschrijf overdrachten tussen afdelingen als toetsbare items in een interfacelijst, en behandel meningsverschillen met escalatieregels op basis van tijd en impact, aangevuld met een standaardactie als vangnet. Gebruik ten slotte de drie soorten registraties — beslissingen, overdrachten en escalaties — voor maandelijkse metingen en herzie op basis daarvan de matrix. Een zo ingericht samenwerkingsmechanisme is niet afhankelijk van de bereidheid van individuen om mee te werken, maar blijft functioneren door heldere mandaten, toetsbare interfaces en automatisch werkende escalatiepaden.