1. Branscher
2. Argument för utvecklng
2.1. Lagrapportering
2.1.1. Finns sällan bra stöd i ERP-sytem för detta
2.1.2. "Planerare använder ändå ProMark"
2.1.3. Delvis svar på problemställning nr 7
2.2. Samlingsproduktion
2.2.1. Finns sällan bra stöd i ERP-sytem för detta
2.2.2. "Planerare använder ändå ProMark"
2.2.3. Allt vanligare med avancerade och automatiserade maskiner som tar många operationer samtidigt
2.2.4. Bör kompletteras med maskinuppföljning/övervakning (ProMachine)
2.2.5. Delvis svar på problemställning nr 2, 5, 6 och 7
3. Problemställningar hos kunder idag
3.1. Produktionseffektiviteten
3.1.1. "Borde hinna med mer än vad vi gör"
3.1.2. Var har vi flaskhalsarna idag?
3.2. Önskar planerbarhet
3.3. Hantering av avvikelser från personer och maskiner
3.4. Övervakning av maskiner
3.5. Efterkalkylerna stämmer inte
3.6. Bemanning av "automater"
3.6.1. "Kan inte stämpla på allt"
3.7. Måste ha en enkel och effektiv rapportering från verksamheten
4. Lagrapportering
4.1. Fasta lag
4.1.1. "alltid samma personer i ett arbetslag"
4.1.1.1. Definiera lag i ett lagregister. Laget ska kopplas till ett workcenter som i sin tur är kopplat mot en reg.profil. Förutsättning: Ett lag arbetar mot ett och samma workcenter....
4.1.1.2. Koppla personen till laget (via ProJobknappen på personen?) Där se default avdelning plus aktuell avdelning
4.1.1.3. Vid job-in och job-ut ska man kunna få en fråga om det gäller lag eller person (om man är kopplad mot ett lag). Default LAG.
4.1.1.4. Jobbfunktionstangent med "byta lag" (ref. byte kostställe)
4.1.1.5. Man slipper då extra knappar för in- och utstämpling på lag. ProMark ser då på vilket lag som personen tillhör vid instämpling av tid.
4.1.1.6. Idag ett problem med att antal knappar blir för många på terminalen. (ref. ESBE)
4.2. Halvfasta lag
4.2.1. Man tillhör ett arbetslag men ska enkelt kunna byta arbetslag
4.2.1.1. Under ProJobknappen per person kunna ändra lagtillhörighet. Eller via jobfunktionstangent.
4.2.1.2. Annars samma som för fasta lag.
4.3. Flexibla lag
4.3.1. Inga fördefinierade arbetslag. "alla ska kunna jobba överallt"
4.3.1.1. Slutsats: Här passar sig inte lagrapportering utan man bör rapportera som "vanligt".
5. Samlingsproduktion
5.1. En operatör instämplad på flera operationer på EN maskin
5.1.1. Kodning på operationsnivå om vilken "kaplista" som den tillhör. Om NULL = "ingen kaplista" (normal operation).
5.1.2. Information om kaplista ska finnas i host 140 för att gå tillbaka till ERP.
5.1.3. Planering eller operatör märker upp operationer för kaplista
5.1.3.1. ProPlanning Job kan vara en hjälp här? Kanske kan märka med kapliste nr från ProPlanning Job?
5.1.3.2. Webpart i portalen? Välja ut operationer per datumintervall, per workcenter plus ytterligare X antal parametrar. T ex artnr, material, tjocklek i plåt.
5.1.4. Den rapporterade tiden bör kunna ha följande fördelninsalternativ som hämtas från tillståndet på reg.profilen:
5.1.4.1. Jämn fördelning
5.1.4.2. Standardtid (enligt plan)
5.1.4.3. Relativ fördelning enligt planerad tid (tidsfaktorn på operationen?)
5.1.5. Kaplistan ska vara knuten till ett workcenter som styr över workcentret på operationen vid konflikter.
5.1.6. Tänk på att skilja resurstid från persontid här.
5.1.7. Rapportering av antal och avvikelser?
5.1.7.1. Default: Enligt plan =>endast bekräfta. Annars gå in och justera antal från kaplistan i en översikt.
5.1.8. Stöd för streckkoder och utskrift av kaplistan?
5.1.8.1. Streckkod bör innehålla id för kaplista och bör kunna identifieras från uppsättning av jobbterminaltangenterna. "Kaplistans streckkod" som identifikation. Ref. op. streckkod.
5.2. En operatör instämplad på flera operationer på OLIKA maskiner samtidigt
5.2.1. Olika kaplistor
5.2.2. Samma som ovan med EN maskin och EN kaplista för övrigt.
5.2.3. Vad vill man ha ut?
5.2.4. Vad har verksamheten för input i form av ställtider och körtider?
5.2.5. Hur rapportera bäst här?
6. Serienummerhantering
6.1. För att kunna spåra rapportering och material på individnivå
6.2. Viktigt inom försvars,- olje och fordonsindustrin
6.3. Får en detaljerad efterkalkyl. Svarar delvis på problemställning nr 5 ovan.
6.4. Läggs in nytt fält på ordernivå
6.4.1. Kontroll att antalet på ordern =1 om serienummer är aktivt.
6.4.1.1. Gäller både vid registrering/import och vid varje antalsregistrering.