Spænd dine børn med øjenspænder. Nu ved du, at Onshape startede året med at annoncere Parametrisk modellering 2.0. De fik tilsyneladende en to-til-en-aftale på 2.0 navne, annoncerede i dag Data Management 2.0.
De fik også en to-til-en om kickin' designproblemer IN THE ASS, da, ligesom konfigurationer, multi-part og in-context design i deres Parametric Modeling metodologi, funktionerne i deres Data Management metodologi flytter arbejdet væk fra arbejde- runder og manuelle arbejdsgange til en metode, der holder modellen i sammenhæng med arbejdsgangen i stedet for noget, man jammer ind og ud af et andet system eller i en bindespand ved siden af pauserummet med de fem ødelagte kaffemaskiner.
Der er to komponenter til Data Management 2.0 (DM2.0) – Release Management & Approval Workflow (RAW'er) og Simultaneous Bill of Materials (BOM'er). Lad os kigge på det. Men først…
Hvad er så anderledes ved DM2.0?
Jon Hirschtick nedbryder det. Han påpeger seks principper, som i sig selv ikke nødvendigvis er unikke, men tilsammen danner grundlag for at strømline styklister og RAW'er. De fokuserer på:
- En database, ikke filer
- Sikkert cloud-arbejdsområde, ikke scatter-kopier
- Parallel, ikke seriel
- Øjeblikkeligt samarbejde, ikke møder
- Design og data på ét sted, ikke mange
- Nul IT
Hørt den Sys Admin Frank? NUL DET. Gå og min din krypto på virksomhedens mainframe, overlad os til at designe FREMTIDEN.
Nu er disse egenskaber ikke noget nyt – ingen har dog samlet dem i en CAD-app med en sammenhængende tilgang til del- og revisionsworkflow. Så endnu mere (og det er tydeligt med disse nye funktioner) Onshape har samlet alt i en 3D-modelleringssoftware bygget fra begyndelsen til at strømline produktudviklingsprocessen.
Release Management & Approval Workflow
Der er lige så mange metoder til udgivelsesstyring og godkendelsesworkflow, som der er farver på din skærm. Du arbejder inden for en eller anden hver dag højst sandsynligt. Onshape fanger behovene i kernen af denne proces med en ny tilgang til frigivelsesstyring og arbejdsgange. Sådan siger Jon det:
Som alt andet i Onshape blokerer oprettelse af en udgivelseskandidat og godkendelse af en udgivelse ikke nogen fra at fortsætte deres arbejde – ingen ventetid på check-in og check-out. Vi tillader brugere at oprette en foreslået udgivelse for enhver kombination af dele, samlinger, konfigurationer og andre aktiver som en enkelt udgivelse.
Med dette bevæger den sig gennem en udgivelse eller forældet arbejdsgang med revision, varenummer og udgivelsesbetingelser, som du har angivet. Alle, der bruger Onshape i din virksomhed, ved, hvad der sker med dele og samlinger undervejs. Du må ikke hoppe ud for at tjekke dette system eller det system, tjekke de røde ringbind eller spørge nogen om status for den del, der allerede er to uger forsinket. Selvom det måske ikke passer til din nuværende arbejdsgang, revision eller varenummerskema, er det fleksibelt nok til at håndtere en masse scenarier, og det siger sig selv, at dette kun er begyndelsen.
Samtidig stykliste
Jeg ved, at du kender trickene til at se din stykliste, mens du modellerer. Uanset om det er at eksportere det til et regneark eller indlejre det i en tegning eller konfiguration, er det i bedste fald ineffektivt. Sådan beskriver Jon en samtidig stykliste:
Nu i Onshape oprettes og opdateres din stykliste automatisk, mens samlingen designes. Faktisk holdes det ikke bare synkroniseret, det er også en samtidig måde at redigere samlingen på, ligesom pladebordet i Simultaneous Sheet Metal og konfigurationstabellerne i Simultaneous Configurations. Din Onshape-stykliste er aldrig ude af sync med den samling, den afspejler.
Sammen med dette har de udgivet en BOM API, som giver dig eller deres partnere mulighed for at bygge brugerdefinerede apps (som OpenBOM), der udvider, hvad du kan gøre med disse styklistedata.
Jeg græd ærlig talt lidt, da jeg så disse funktioner, fordi jeg ved, hvor meget tid jeg brugte på andre metoder og systemer, opsætning og dokumentation af andre metoder og systemer og skændes om andre metoder og systemer.
Det er latterligt (på en god måde), hvor meget Onshape har forenklet disse to aspekter af designprocessen. Jeg tror, at den største erkendelse, jeg havde, da jeg så de nye funktioner, er, hvordan vi vænner os til løsninger og ineffektive systemer, til det punkt, vi forsvarer dem, endda retfærdiggør dem baseret på den længere tid, det tager – det er det, der virkelig er latterligt (i en dårlig måde).
Voxel Innovations bruger Onshape, så jeg spørger Michael Bromley, Lead Mechanical Engineer, hvordan de bruger den nye release management og godkendelses workflow. Tidligere havde de en meget manuel og fejltilbøjelig proces, der forsøgte at håndtere release management gennem en udviklingsgren og en frigivet filial. Han fortalte mig:
Den nye udgivelsesstyringsproces binder nu en revisionshistorik til individuelle dele, samlinger og tegninger. Dette er en kritisk funktion til dokumentation og brug af søgefunktionaliteten til at finde en as-built del. Der er nu en diskret dokumenteret tilstand af en del/samling/tegning, der kan placeres i frigivet tilstand. Derfor kan vi sætte en proces på plads, at kun en del/samling/tegning i frigivet tilstand kan fremstilles eller bestilles. Vi vil bruge release management-processen til alle vores projektrelaterede data.
Jeg er virkelig nysgerrig efter at vide, om disse funktioner har ændret noget for dig, om de hjalp dig, som de hjalp Voxel eller ændrede noget andet. Kommenter eller send en e-mail – jeg vil meget gerne høre fra dig.
