Ստանկի ինտեգրում ERP–ի հետ՝ ինչ տվյալներ փոխանցել

Որտեղ է հաշվառումը տարաձայնվում ստանկի և ERP–ի միջև

Հաշվառումը սկսում է «խախտվել» այն պահին, երբ ստանկը և ERP–ը «ապրում են» տարբեր ժամերով. ստանկը արդեն կատարել է մասի մի մասը, կանգ է եղել, նորից գործել է, իսկ համակարգում դեռ տեսանելի է հին թիվը։ Գործարքում դա փոքր խնդիր չէ, այլ ամեն օր ներող կորուստ։

Դիմալով հաճախ է օպերատորը մուտքագրում выпускը ճաշի վերջում։ Սա բնական է. օրն ընթացքում նա հետևում է գործիքին, մասի չափին և արդեն պատվերի բեռին։ Բայց երեկոյան մի մասը դեպքերի թվերը ջնջվում են հիշողությունից։ Մանր կանգառները, փորձնական դետալը, վերադասավորումը, մի քանի սխալ տեսք ունեցող մասեր — այս ամենը հեշտ հայտնվում է հաշվետվության դրսում։

Եվ արդյունքում տվյալները ERP–ում գալիս են ուշացումով և նվազեցված տեսքով. պլանավորումը նայում է երեկվա պատկերը և արձագանքում ուշացմամբ։ Դիսպետչերը կարծում է, թե պատվերն մոտ է ավարտին, գնումը չի շարժվում հաջորդ խմբաքանակի համար, մաստերը չի տեսնում, որ ստանկը արդեն երրորդ ժամն է կորցնում ժամանակը։

Կանգառների դեպքում իրավիճակը ավելի վատ է. մեծ փոսը սովորաբար նկատում են բոլորը, բայց տասնավոր 6–8 րոպեների կանգառները հաճախ ոչ ոք ճիշտ չի գրանցում։ Փերովագը ըստ թղթի նորմալ է։ Իրականում ստանկը կորցրել է գրեթե մեկ ժամ։ ERP–ն այդ մասին շատ ուշ է տեղեկանում կամ ընդհանրապես չի տեղեկանում։

Սովորաբար բացվում են նույն ֆակտերը. ցիկլի սկսման և կանգառի պահը, իրական աշխատանքային և կանգառի ժամանակը, պատրաստի և բрак դետալների քանակը, և կանգառի կամ ուշացման պատճառը։ Երբ այս տվյալները բացակայում են կամ գալիս են մեկ անգամ փոխարեն հերթափոխի, թիմը վիճում է ոչ թե պատճառի շուրջ, այլ թվերի։ Մաստերը նայում է ամսագրին, օպերատորը հիշում է հիշողությամբ, պլանավորողը վերցնում է տվյալները ERP–ից. և բոլորն ունեն տարբեր պատկեր։ Այդ պատճառով ինտեգրումը պետք է ոչ միայն գեղեցիկ հաշվետվության համար, այլ որպեսզի բոլորը տեսնեն նույնը։

Մետալոապահովման մեջ սա առանձնահատուկ արագ է երևում. տոքի վրա ՉՊՈւ–ով արտադրությունը կարող է ընթանալ առանց խնդրի մինչ այն պահը, երբ սկսվում են մանր սխալները՝ գործիքի կամ նախապատրաստման պատճառով։ Եթե ERP–ը տեսնում է միայն վերջնական արդյունք ճաշի վերջում, արդեն ուշ է։ Ցանկացած սխալ չի հայտնվում հաշվետվությունում, այլ այն պահին, երբ փաստը միանգամից չի փոխանցվել։

Ի՞նչ տվյալներ են պետք առաջին հերթին

Սկզբում հարկավոր չէ ERP ներմուծել այն ամենը, ինչ ՉՊՈւ–ն կարող է փոխանցել։ Երբ տվյալները շատ են, հաշվառումը արագ վերածվում է աղմուկի։ Լավ է վերցնել փոքր հավաքածու, որը անմիջապես ազդում է պլանին, ժամկետներին և ինքնարժեքին։

Առաջին և բազայինը՝ ստանկի ստատուսը։ ERP–ը պետք է տեսնի երեք պարզ ստատուս՝ ստանկը աշխատում է, ստանկը կանգ է, ստանկը պատահարային (ավարիա) վիճակում է։ Այսքանն արդեն բավական է հասկանալու, թե որքան ժամանակ սարքավորումն իսկապես հանում է մետալը, որքան սպասում է և որտեղ են խժդել հերթափոխի ժամերը։

Երկրորդ բլոկը՝ արտադրական հանձնարարության սկսման և ավարտի մատյանը։ ERP–ին պետք չէ ՉՊՈւ–ի ամբողջ ներքին տրամաբանությունը։ Պետք է պարզ փաստ՝ ինչ աշխատանքով սկսեց ստանկը և երբ ավարտվեց։ Այդպես համակարգը կապում է выпускը կոնկրետ պատվերի, հերթափոխի և օպերատորի հետ։

Երրորդը՝ ցիկլի ժամանակն ու պատրաստ մասերի քանակը։ Ցիկլի տևողությունը ցույց է տալիս, թե որքան ժամանակ է միջինը պահանջվում մեկ դետալի համար կամ մեկ ծրագրային պրոցեսի համար։ Մասերի քանակը պետք է выпускի հաշվառման համար առանց օրային ձեռքի գրառումների։ Իսկ եթե հաշվել չեք ամեն դետալը առանձին, իսկ հաշվել ավարտված ցիկլերը, պատկերը արդեն զգալիորեն ճշգրտվում է։

Համաժամանակ պետք է ունենալ փոքրիկ կանգառների պատճառների ցանկ։ Ոչ տասնյակ ընտրանքներ, այլ 5–7 պարզ տարբերակ՝ «ոչ կա տրամադրված заготовка», «наладка», «փոխել գործիք», «դիմումի սպասում», «ավարիա»։ Այդպիսի ցանկը կարգապահեցնում է հաշվառումը. օպերատորը քանի վայրկյանում ընտրում է պատճառը, իսկ վերադասը հետո տեսնում է ոչ միայն, որ «ստանկը կանգ է», այլ թե ինչ պատճառով։

Սկիզբի համար սովորաբար բավական է այս հավաքածուն՝ ստատուս, հանձնարարության համարը, սկսման ժամանակը, ավարտի ժամանակը, ցիկլի տևողությունը, մասերի հաշվիչը և կանգառի պատճառը։ Այսքանը բավական է հաշվարկել բեռնվածությունը, выпускն ու կորուստները առանց ավելորդ սենսորների և առանց մեծ IT–խմբի։

Պարզ օրինակ. տոքի տոկարի վրա կտրում են խցանների խմբաքանակ։ ERP–ը ստանում է հանձնարարության սկսումը 10:05–ին, տեսնում է 13:00–ին 42 ավարտված ցիկլ և մեկ 18 րոպեանոց կանգառ՝ պատճառը «գործիքի փոփոխություն»։ Այդ տվյալներով մաստերը հասկանում է, որտեղ է կորել ժամանակը և ինչ քանակ կարող է խոստանալ մինչ հերթափոխի վերջը։

Որտեղից վերցնել այդ տվյալները առանց ավելորդ սենսորների

Սկզբնական փուլում ոչ պետք է տեղադրել առանձին սենսորներ ամեն դռան, փրոնտի կամ կոնվեյերի վրա։Ծանր մասը տվյալների արդեն առկա է հենց ստանկի ներսում՝ ՉՊՈւ–ում, PLC–ում և օպերատորի պարզ հաշվառման մեջ։

Ամենից առաջ նայում են ազդանշանները, որոնք ստանկը արդեն բաժանում է աշխատանքի ընթացքում. սովորաբար սա է՝ «աշխատում/կանգ է», ցիկլի սկիզբ, ցիկլի ավարտ, аварիա, նалаդկա ռեժիմ, երբեմն ծրագրի համարը և գործարքի ժամանակը։ Այսքանը արդեն բավարար է բեռը տեսնելու, կանգառները հաշվելու և փաստը համեմատելու պլանთან։

Շատ ստանկերում կա նաև մասերի հաշվիչ։ Կարճ ժամանակ խառնվելու դեպքում այն գտնվում է ՉՊՈւ–ում կամ կցորդիկի/ռոբոտի/ավտոմատիկ գծի մոտ։ Եթե հաշվիչ կա, մի խնդրեք օպերատորին կրկնել այն թղթի վրա։ Լավ է վերցնել մեկ աղբյուր և ընդունել այն որպես հիմնական։

Սովորաբար տվյալները վերցնում են չորս տեղից՝ ՉՊՈւ–ի ազդանշաններ ցիկլի և аварիաների մասին, PLC–ի ազդանշաններ հանգույցների աշխատանքի ու զարկերի վերաբերյալ, պատրաստ մասերի հաշվիչը ստանկից կամ բջիջից և ձեռքի մուտք այն դեպքերի համար, որոնք ստանկը ինքնը չի տեսնում։

Մնալով ձեռքի մուտք անհրաժեշտ է։ Ստանկը չի իմանա, թե ինչ պատճառով է օպերատորը կանգնեցրել աշխատանքը՝ սպասում է գործիքի, փոխում է սեղանը, ստուգում առաջին դետալը կամ սպասում է նալադչիկին։ Եթե օպերատորին չեք տալիս 5–7 պարզ կանգառի պատճառ, ERP–ը ցույց կտա միայն «ստանկը կանգ է», և նման հաշվառումն օգտակար կլինի քիչ։

Լավ ընտրություն սկզբի համար՝ կարճ մուտքագրում տերմինալի, պլանշետի կամ աշխատատեղի էկրանի միջոցով։ Օպերատորը նշում է պատճառը միայն այն դեպքերի համար, որոնք cannot быть зафиксированы ազդանշանով։ Նույնիսկ մնացածը համակարգը վերցնում է sjálf։

Եթե փոխանակումը դեռ պատրաստ չէ, ժամանակավոր աղբյուրը կարող է լինել հերթափոխային հաշվետվությունը։ Դա իդեալը չէ, բայց այդ տարբերակը օգնում է սկսել հաշվառումը առանց մեծ IT–նախագծի։ Սովորաբար հաշվետվությունում նշում են выпускը, բրակը, երկար կանգառները և փոքր մեկնաբանություն հերթափոխի մասին։

Գործարանում մետալոապահովման բաժինը հաճախ սկսում է այսպես. ավտոմատ կերպով վերցնում է ցիկլի ստատուսը և մասերի հաշվիչը, իսկ օպերատորը ձեռքով նշում է նалаդկան, գործիքի սպասումը և առաջին դետալի հսկողությունը։ Արդյունք. տվյալները ERP–ում սկսում են աշխատել պլանավորման համար, այլ ոչ թե պարզապես կուտակվում են աղյուսակում։

Ինչպես հավաքել նվազագույն հավաքածուն սկսելու համար

Առաջին ինտեգրմանը մի փորձեք ընդգրկել ամբողջ участка։ Ընտրեք մեկ ստանկ և մեկ կրկնվող օպերացիա, որը հերթափոխը գրեթե ամեն օր իրականացնում է։ Եթե սկսեք միանգամից մի քանի ստանկերով, տարբեր դետալներով և տասնյակ ստատուսներով, հաշվառումը արագ կհասնի վիճաբանությունների և ձեռքի ուղղարկումների։

Լավ սկա՞բ. մեկ տոքի ստանկ ՉՊՈւ–ով, մեկ դետալ և մեկ օպերացիա, որտեղ պարզ է սկսվելը, ավարտվելը և արդյունքը։ Այդպես արագ կտեսնեք՝ արդյոք տվյալները ստանկի, մաստերի և ERP–ի միջև հիմնականում համընկնու՞մ են։

Սովորաբար առաջին գործարկման համար բավարար է 5–8 դաշտ։ ERP–ին պետք չէ ամբողջ թելեմետրիան. այն պետք է տվյալներ, որոնցով տեսանելի է, ինչ եք անում, որքան արել եք և երբ աշխատանքը կանգ է առել։ Ավելի հաճախ բավական է՝ ստանկի համարը, պատվերի կամ օպերացիայի համարը, սկսման ժամանակը, ավարտի կամ ստատուսի ժամանակը և պատրաստ մասերի քանակը։

Եթե հաճախ վիճում են կանգառների կամ բրակի շուրջ, ավելացրեք 2–3 դաշտ՝ բրակի քանակը, կանգառի պատճառը, հերթափոխը կամ օպերատորը։

Հետո նշանակում եք յուրաքանչյուր դաշտի պատասխանատուն՝ ոչ թե «մասնավորում», այլ կոնկրետ անձ կամ դերը։ Պատվերի համարը սովորաբար պահում է պլանավորողը կամ ERP–ի մասնագետը, մասերի քանակը հաստատում է օպերատորը, կանգառի պատճառը ընտրում է հերթափոխի մաստերը։ Այդպես անհետացվում է, թե ով ուղղի սխալը, եթե համակարգում հայտնվի անհամաձայնություն։

Ինչպես չբարդացնել սկիզբը

Հաճախ սխալը՝ ամենից առաջ հավաքել այն ամենը, ինչը ստանկը կարող է տալ, իսկ հետո մտածել՝ ինչի համար դա պետք է ERP–ին։ Լավ է գնալ հակառակ ճանապարհով. սկսեք ERP–ում բացելով պատվերը և հարցրեք՝ որոնց 5–8 արժեքները իսկապես պետք են դիսպետչերին, մաստերին և հաշվապահությանը ամեն օր։

Միաժամանակ որոշեք թարմացման հաճախականությունը։ Սկզբում պարտադիր չէ տվյալների հոսք յուրաքանչյուր վայրկյանին։ Շատ բաժինների համար բավարար է ռեժիմը՝ ստատուսը ERP ուղարկել 1–5 րոպեի մեկ, մասերի քանակը՝ խմբի ավարտին կամ հերթափոխի վերջում, կանգառը՝ անմիջապես եթե այն տևի ավելի երկար քան սահմանված շեմը (օր. 10 րոպե)։

Չափազանց պարզ մոտեցումը հեշտ է գործարկել նույնիսկ առանց մեծ IT–խմբի։ Դուք նախ ստուգում եք հաշվառման տրամաբանությունը մեկ պարզ տեղում, ապա նորից ավելացնում այլ ստանկեր, օպերացիաներ և ավելի հաճախ փոխանակում։ Եթե պիլոտը չի տալիս մաստերի և պլանավորողի համար հստակ պատկերը մեկ օրվա մեջ, նշանակում է, դաշտերը դեռ շատ են։

Ինչպես կարգավորել փոխանակումը քայլ առ քայլ

Ինտեգրումը հաճախ ջարդվում է ոչ թե կապի վրա, այլ տվյալների իմաստի վրա. եթե ստանկի մի ստատուսը նշանակում է "ցիկլը վազում է", իսկ ERP–ում նույն կոդը հաշվվում է որպես "դOccupied, բայց չի կտրում", հաշվառումը արագ կխեղաթյուրվի։ Ուստի նախ կազմեք պարզ համարժեքների աղյուսակ, ոչ թե գրեք բարդ փոխանակման կանոններ։

Յուրաքանչյուր դաշտի համար գրեք երեք բան՝ ինչպես այն կոչվում է ERP–ում, որտեղից է վերցվում և երբ է թարմացվում։ Օրինակ՝ «ստանկ», «ծրագրի համարը», «ցիկլի սկիզբ», «ցիկլի ավարտ», «մասերի հաշվիչ», «ավարիա»։ Աղբյուրն էլ գրել պետք է ուղղակի՝ ՉՊՈւ, PLC, օպերատոր կամ հերթափոխի մաստեր։ Եթե արժեքը մուտքագրում է մարդը, այդպես էլ նշեք, որպեսզի հետո ոչ ոք վիճաբանության չգործի՝ ով սխալ եզրակացրեց։

Ալագորեն համաձայնեք ստատուսները և կանգառների կոդերը։ Սա ձանձրալի է, բայց տնտեսում է շաբաթներ։ Հաճախ սխալն այն է, որ սարքավորությունում կա մեկ ընդհանուր «կանգ» ազդանշան, իսկ ERP–ն ուզում է տեսնել նалаդկա, հումքի սպասում, փլուզում և օպերատորի բացակայություն։ Մի ազդանշան այդպիսի մանրամասնություն չի տա, հետևաբար որոշ պատճառներ պետք է մուտքագրվեն ձեռքով՝ կարճ կոդով։

Առանձնապես առաջին թեստի համար օգտակարն է պարզ սխեման.

1. Ընտրեք մեկ ստանկ և մեկ հերթափոխ։
2. Միացնեք փոխանակումը փորձարկման բազայում, ոչ թե աշխատանքում։
3. Միաժամանակ վարեք ձեռքի հաշվառումը նույն հերթափոխի համար։
4. Վերջում համեմատեք աշխատանքային ժամանակը, կանգառը, մասերի выпускը և կանգառների պատճառները։

Համեմատել պետք է ոչ միայն հերթափոխի վերջի ամփոփ ոչարը, այլ նաև մի քանի կոնկրետ էպիզոդներ։ Օրինակ, եթե տոկարը կանգ է առել 18 րոպե գործիքի փոփոխության պատճառով, իսկ ERP–ում դա գրանցվել է որպես 25 րոպեանոց аварիա, խնդիրն իրենք չէ հաշվետվության մեջ, այլ ստատուսների տրամաբանության կամ այն կետի, որտեղ համակարգը վերցնում է դեպքի սկիզբն ու վերջը։

Խնդիրները ուղղեք անընդմեջ՝ մեկը մեկից. առաջինը՝ ցիկլի ժամանակը, այնուհետև մասերի հաշվիչը, հետո կանգառները։ Մի փորձեք միանգամից փոխանցել բոլոր այն, ինչ կարող է սարքը։ Սկզբում բավական է այն տվյալները, որոնցով գործարքն ու պլանավորումն կարող են համաձայնվել առանց վիճաբանության։

Երբ թեստը մեկ հերթափոխի համար ուղղակիորեն մոտ է ձեռքի հաշվառմանը, աստիճանաբար ընդլայնեք փաթեթը՝ ևս մեկ ստանկ, ևս մեկ հերթափոխ, ապա ամբողջ участокը։ Այս հերթականությունը ավելի արդյունավետ է, քան ամբողջ участка արագ մեկնարկը գեղեցիկ, բայց սխալ թվերով։

Պարզ օրինակ

Փոքր արտադրամասը մշակում է առանցքների խմբաքանակ մեկ տոկարի վրա։ ERP–ում գրանցված է պատվեր 120 կտոր համար, ժամկետը՝ հաջորդ օրվա վերջում։ Նախկինում մաստերը հետևում էր աշխատանքին զանգերով և թերթիկների վրա գրառումներով, ուստի ուշ էր հասկանում հետընթացը։

Մի պարզ կարգավորելուց հետո ERP–ն սկսեց երեք իրադարձություն ավտոմատ անցկացնել՝ երբ օպերատորը սկսեց պատվերը, քանի դետալ է արդեն պատրաստ և երբ ստանկը կանգ է լինում ավելի երկար սահմանված ժամանակից։ Սկզբում այսքանը բավական է։ Ոչ մի իմաստ չկա բազմաթիվ պարամետրեր հավաքել, եթե գործարքին պետք է պարզ հարցին պատասխանել՝ արդյոք պատվերը գնում է ըստ պլանի։

Երբ հերթափոխը սկսեց 8:00–ին, 8:07–ին համակարգը ստացավ պատվերի սկիզբը։ 11:30–ին ERP–ում արդեն երևաց, որ արտադրվել է 34 առանցք, մինչդեռ պլանը պահանջում էր այդ ժամին 45։ Հետո ստանկը կանգ առավ 22 րոպեով. պատճառը պարզ էր՝ աշխատատեղի մոտ վերջացել էին առաքվող նախապատրաստանքները, և օպերատորը նշեց դա որպեսوقف։

Մաստերը տեսավ ոչ միայն կանգառի փաստը, այլ նաև դրա ազդեցությունը պատվերի վրա։ Միջինում պարզ էր, որ խումբը հետ է մնում, և կարելի էր դեռ նույն օրը շտկել իրավիճակը. տեղափոխել քիչ հրատապ պատվերը հաջորդ օր և վերապահել հաջորդ խումբ նախապատրաստանքների համար, և ստուգել գործիքը հաջորդ հերթափոխից առաջ։ Հաջողվեց հաջորդ առավոտը արդեն տվյալների համաձայն փոխել պլանը։ Կետթվյալներ չպետք է գուշակվեին, թե ինչու երեկ չեն հասել համապատասխան ծավալին։

Մաքրումով տվյալները սկսեցին գործել պրակտիկայում՝ ոչ ինչպես մեծ IT–նախագիծ, այլ որպես պարզ միջոց տեսնել выпускն ու կանգառները ժամանակին։ Սկզբնական քայլերը հաճախ այսպիսի տեսք ունեն՝ մեկ ստանկ, մի քանի իրադարձություններ և ավելի ճշգրիտ պլան արդեն հաջորդ օրն։

Ինչպես չխճճվել ERP–ի տվյալներում

ERP–ում խճճվածությունը հաճախ սկսվում է ոչ թե «մեծ տվյալներից», այլ փոքր անհամաձայնություններից։ Միևնույն ստանկը մեկ համակարգում կոչվում է ET-46, մյուսում՝ «տոկարային 4», իսկ հերթափոխի հաշվետվությունում՝ պարզապես «4-րդ»։ Ճիշտ թե փոխանակումը աշխատում է, բայց հաշվետվությունները տարբեր են և մարդիկ դադարում են վստահել դրանց։

Նախ կարգավորեք անունները։ Յուրաքանչյուր ստանկի համար պետք է լինի մեկ անուն և մեկ կոդ բոլոր վայրերում՝ ERP–ում, արտադրության հաշվառման ծրագրում, մաստերի աղյուսակներում և սպասարկման հաշվետվություններում։ Եթե ունեք երկու նույն տեսակի ստանկ, մի անվանեք դրանք «ձախ» և «աջ». մեկ ամսում ոչ ոք չի հիշի ինչ է դա նշանակում։ Լավ է օգտագործել պարզ ու չփոփոխվող կոդ։

Երկրորդ ռիսկը՝ միասիրել երեք տարբեր էությամբ՝ դետալը, օպերացիան և պատվերը։ Դետալը՝ այն է, ինչ դուք պատրաստում եք։ Оպերացիան՝ ինչ է ստանկը անում, օրինակ՝ սևաճ նշում կամ քորակումը։ Պատվերը՝ ում համար և ինչ քանակով է աշխատանքը գնում։ Եթե ERP–ում այս բաները միավորվել են մեկ դաշտում, տվյալները արագ անօգուտ են դառնում։ Ստանկը կարող է անել մեկ օպերացիա մի քանի պատվերի համար, իսկ մեկ դետալը կարող է անցնել մի քանի օպերացիաներ։

Գործնականում օգնում է պարզ կանոն. մեկ կոդ ստանկի համար, մեկ կոնստանտա դետալների համար, առանձին օպերացիաների ցանկ, առանձին արտադրական պատվերի համարը և մեկ ընդհանուր կանգառների պատճառների ցանկ բոլոր հերթափոխերի համար։

Հարկավոր չէ կանգառների թեմայում բարդանալ։ Եթե պատճառները շատ են, օպերատորները կընտրեն ցանկացածը կամ անգամ չեն նշի։ Եթե պատճառները քիչ և պարզ են, պատկերը ավելի դժվար կխաբի։ Սկզբում բավարար են այսպիսի տարբերակները՝ չկա նախապատրաստում, նալադկա, գործիք, ծրագիր, օպերատորի սպասում, վերանորոգում։ Այս ցանկը հեշտ է պահպանել, քան 40 նման տարր։

Կան ևս մի բարեհաջող, որը հաճախ ուշ են նկատում՝ ժամանակը։ Ստուգեք ժամերը յուրաքանչյուր ստանկի վրա և կտրուկի սահմանները ERP–ում։ Եթե ստանկի ժամը շտապում է 12 րոպեով, կանգառը կարող է ընկնել այլ հերթափոխի։ Այդ պարագայում իսկագործողը տեսնում է մեկ հաշվետվություն, իսկ մաստերը՝ մեկ այլ։ Մարդիկ վիճում են, մինչդեռ սխալը ժամերի մեջ է։

Պարզ օրինակ. ստանկը ավարտեց խմբաքանակը 19:58–ին, իսկ ներքին ժամը ցույց է տալիս 20:11։ ERP–ն отноcит ավարտը արդեն գիշերային հերթափոխին։ Պլանը փակում ոչ ճիշտ մարդիկ, արտադրողականությունը փոխվեց և կանգառների հաշվառումը նույնպես։ Այս բաները հետո կարելի է ուղղել, բայց հեշտ է մեկ անգամ սինխրոնացնել ժամերը և ստուգել, որտեղ իրականում սկսվում և ավարտվում է հերթափոխը։

Փոքր տեսաբանները և խիստ անվանումները նվազեցնում են ձեռքի ուղղացումների պահանջը։ Սկզբում սա բավական է, որպեսզի ERP–ի թվերը այլևս չվիճեն։

Որտեղ чаще սխալներ են լինում

Առաջին հաճախ սխալը՝ միանգամից փորձել բռնել բոլոր ազդանշանները։ Սկզբում դա գրեթե միշտ խոչընդոտում է։ Թիմը խորտակվում է ստատուսներում, կոդերում և իրադարձություններում, իսկ օգուտը փոքր է։ Սկզբնական փուլում բավական է չորս բան՝ աշխատող կամ կանգով ստանկը, ինչ աշխատանք է ընթանում, քանի մաս պատրաստ է և որքան տևել է կանգառը։

Երկրորդ սխալը վերաբերում է բրակին։ Շատերը սպասում են, որ ՉՊՈւ–ից ավտոմատ փոխանցվող տվյալները միանգամից ապահովեն բրակի ճիշտ հաշվառումը։ Բայց ստանկը հազվադեպ գիտի, թե ինչու մի մաս դարձավ բрак և ով դա հաստատեց։ Եթե օպերատորը մնալով գրում է բրակը վերջին հերթափոխում հիշողությամբ, թվերը կմնան վիճելի։ Սկզբում պետք է փոխել բրակի ֆիքսացման վայրը, և միայն հետո ավտոմատացնել հաշվետվությունը։

Խնդիրներ են սկսվում նաև այնտեղ, որտեղ ոչ ոք չի նշանակել պատասխանատու ուղղումների համար. սխալ գրառումներ միշտ կլինեն: ոչ ճիշտ պատվեր, սխալ կանգառի կոդ, կրկնակի ցիկլի մեկնարկ։ Եթե նախապես չորոշեք, ով ուղղի այդ դեպքերը, ERP–ը արագ կվերածվի վիճող տվյալների գրպանի։

Պարզ բաժանումը օգնում է. օպերատորը նշում է փաստն ու պատճառը հերթափոխի պահին, մաստերը ստուգում է վիճելի կանգառներն ու բրակը, պլանավորողը կամ դուրսմշակողը ուղղում է պատվերը ու երթուղին, իսկ համակարգը պահպանում է ուղղումները։

Կան նաև ավելի առօրեական ձախողումներ՝ եթե ժամերը ստանկի և սերվերի միջև տարբերում են նույնիսկ մի քանի րոպեով, հաշվետվությունները սկսում են մոլորեցնել։ Եթե ցանցը 工ջում է, համակարգը պետք է պահի իրադարձությունները և առաքի դրանք հետո։ Якщо փոխանակումը չի աշխատում, հերթափոխին պետք է պահեստային սցենար՝ կանգառների ամսագիր տերմինալում, պլանշետում կամ թղթում։ Վերացնեք դա, հակառակ դեպքում կորցնում եք ոչ միայն տվյալները, այլ նաև մարդկանց վստահությունը համակարգի հանդեպ։

Լավ սկիզբը կարող է ծանոթ լինել և ձանձրալի, և դա նորմալ է. մեկ ստանկ, մի քանիս ստատուսներ, պարզ դերեր և պահուստային պլան ձախողման դեպքում տալիս են ավելի շատ օգուտ, քան մեծ նախագիծ տասնյակ սենսորներով և դատարկ հաշվետվություններով։

Կարճ ստուգում նախքան մեկնարկը

Առաջին աշխատանքային օրվանից առաջ ստուգեք ոչ հաշվետվությունները, այլ ամենապարզ կապերը։ Եթե մեկ մանր բան չի համընկնի, համակարգը սկսի գեներացնել գեղեցիկ, բայց անօգուտ պատկեր։

Նախ դիտեք բառարանները. յուրաքանչյուր ստանկ պետք է նույն կոդը ունենա և ERP–ն պետք է նույնը ընկալի։ Նույնը արագ՝ օպերացիան. եթե տեղամասում այն կոչվում է «տոկարային մշակություն 20 մմ», իսկ ERP–ում այլ անուն ունի, համակարգը կճեղի նույն պրոցեսը երկու տողերի վրա. հերթափոխը վիճի պլանավորողի հետ, թեև սխալը եղել է սկզբում։

Հետո ստուգեք պարզ բաները օպերատորի աչքով. եթե մարդուն պետք է 5 սեղմում՝ կանգառի պատճառ տալու համար, նա կսկսի ընտրել առաջինը կամ թողնել գրառումը։ Նորմալ սխեմա՝ կարճ ցանկ պատճառներով և մի-երկու սեղմումով ընտրությամբ։

Աստիճանային արագ թեստ. թույլ տվեք հերթափոխի մաստերին նույն օրը համեմատել տեսածն участкаում և ERP–ում եկածը։ Եթե ստանկը կանգ է ունեցել 40 րոպե, իսկ համակարգը ցուցում է շարունակական աշխատանք, սխալը պետք է բռնել այստեղ և հիմա, ոչ թե ամսվա վերջում։

Նախնական ստուգումներում սովորաբար բավարար են չորս բաներ.

• ստանկի կոդերը համապատասխանում են ստանկում, MES–ում կամ փոխանակման ֆայլում և ERP–ում
• օպերացիաների կոդերը չեն կրկնվում տարբեր անվանումներով
• օպերատորը կարող է ընտրել կանգառի պատճառը 2–3 սեղմումով
• մաստերը կամ տեխնոլոգը տեսնում են անհամապատասխանությունները հերթափոխի օրը, ոչ թե ավելի ուշ

Առաջին շաբաթվա համար նշանակեք մեկ պատասխանատու. սա պարտադիր չէ IT–մասնագետը լիներ. հաճախ ավելի լավն է տեխնոլոգը կամ մաստերը, ով հասկանում է և տեղամասը, և հաշվառումը։ Նրա պարզ պարտականությունն է ամեն օր նայել, թե ինչ է եկել ERP–ում, որտեղ գրառումները բացակայում են, որոնք պատճառները սխալ են ընտրված և որին պետք է արագ արձագանքել։

Եթե այս կառավարումը դնեք առաջին օրվանից, ստանկի տվյալները սկսում են աշխատել արտադրության համար, ոչ թե պարզապես կուտակվել աղյուսակներում։

Ի՞նչ անել հետագայում

Եթե սխեման արդեն աշխատում է, մի փորձեք միանգամից կապել ամբողջ участка։ Լավ է ձեռնարկել մեկ ստանկ և մեկ դետալ, որը դուք հաճախ եք արտադրում։ Վերահաշվարկով սխալները ավելի արագ երևում են՝ որտեղ է կորում ժամանակը, երբ օպերատորը մոռանում է նշել կանգառի պատճառը, ինչու ERP–ում իջնում է մասերի պակաս պատկեր։

Սովորաբար առաջին ամիսը պետք է ծառայել ոչ թե գեղեցկության համար, այլ տվյալների կարգապահությունը ստուգելու համար։ Այդ ընթացքում պարզ կլինի՝ որ ստատուսներն են իրականում օգտագործվում, որ դաշտերը ERP–ում ոչ մեկը չի լրացնում և ինչ տարբերակներով պետք է ավտոմատ կերպով փոխանցել, իսկ ինչը ավելի լավ է թողնել ձեռքով։ Արդյունքում ցուցանը երբեմն կկրճատվի, և դա նորմալ է։

Հետո տրամաբանությունը պարզ է՝ ամրապնդել մեկ պարզ տվյալների երթուղի պիլոտային ստանկի համար, ստուգել մեկ ամսվա աշխատանքը մեկ կրկնվող դետալով, ապա ավելացնել մյուս սարքավորումների խումբը՝ նման ցիկլով։ Եւ նոր ստանկ գնելիս նախապես պարզել՝ որոնք ազդանշաններն ու ինտերֆեյսները մատչելի են անմիջապես։

Վերջին կետը շատերը բաց թողնում են և հետո սպասում են առնվազն։ Եթե նախապես պարզեք՝իծ ստանկը տալիս է արդյոք աշխատանքի ստատուսները, մասերի հաշվիչը, аварիաները և կանգառների պատճառները, ներդնումը կանցնի հանգիստ։ Ինչպես ոչ, հաշվառումը պետք է սարքավորումների սահմանափակումների շուրջ, ոչ թե արտադրության խնդիրների։

Լավ հաջորդ քայլն է հավաքել կարճ ցանկ 5–7 ազդանշաններից, որոնք պետք են հենց ձեր ERP–ին։ Սա պետք չէ տալ որպես «հասարակություն ապագայում», այլ այն, ինչը դուք կունենաք ու կտեսնեք ամեն օր։ Տոկարային հատվածի համար սա հաճախ է՝ ստացկի վիճակը, ցիկլի սկիզբ-ավարտ, ծրագրի համարը, մասերի հաշվիչը, аварիա և կանգառ։

Եթե ընտրում եք նոր ստանկ կամ պատրաստում գործարկում, այս քննարկումը լավ է անցկացնել մինչև նախնական տեղադրում։ EAST CNC, պաշտոնական ներկայացուցիչը Taizhou Eastern CNC Technology Co., Ltd.–ի Ղազախստանում, ավելի հաճախ խորհուրդ է տալիս այդ հարցերը քննարկել հենց սկզբից՝ որոնք ազդանշաններ մատչելի են, ինչ կարելի է փոխանցել ERP–ին առանց ավելորդ սենսորների և ինչն է նվազագույն տվյալների հավաքածուն, որը կտա իրական օգուտ գործարքին։

Երբ պիլոտը հանգիստ աշխատել է մեկ ամիս, այն մասշտաբավորելն ավելի հեշտ է. դուք փոխանցում եք արդեն պարզեցուցիչ տրամաբանությունը, ոչ թե նոր է՜նգծանքների շարք։