Бөгжний сканнер бүхий Zebra WT-40 мэдээлэл цуглуулах терминал. Энэ нь хайрцгийг тавиур дээр (гар чөлөөтэй) овоолох үед барааг хурдан сканнердах чадвартай байхын тулд шаардлагатай.
Хэдэн жилийн хугацаанд бид дэлгүүрүүдээ маш хурдан нээж, томорсон. Одоо манай агуулахууд өдөрт 20 мянга орчим тавиур хүлээн авч, илгээдэг болсноор энэ нь дууссан. Мэдээжийн хэрэг, өнөөдөр бид илүү олон агуулахтай болсон: Москвад хоёр том - 100 ба 140 мянган хавтгай дөрвөлжин метр, гэхдээ бусад хотод жижиг агуулахууд бас байдаг.
Ийм хэмжээний барааг хүлээн авах, угсрах, тээвэрлэх явцад хэмнэгдсэн секунд бүр нь үйл ажиллагааны цагийг хэмнэх боломж юм. Мөн энэ нь асар их хэмнэлт юм.
Тийм ч учраас үр ашгийн хоёр гол хүчин зүйл бол сайн бодож боловсруулсан үйлдлийн алгоритм (үйл явц) ба тусгайлсан мэдээллийн технологийн систем юм. "Цаг шиг" байвал илүү тохиромжтой, гэхдээ "төгсөөс арай бага ажиллах" нь бас тохиромжтой. Гэсэн хэдий ч бид бодит ертөнцөд байна.
Зургаан жилийн өмнө ханган нийлүүлэгчид манай агуулахад ачааны машиныг хэрхэн буулгаж байсныг нарийвчлан судалснаар түүх эхэлсэн юм. Энэ нь маш логикгүй боловч танил байсан тул ажилчид оновчтой бус үйл явцыг анзаарсангүй. Түүгээр ч барахгүй тухайн үед бид аж үйлдвэрийн агуулахын удирдлагын системгүй байсан бөгөөд үндсэндээ бид логистикийн үйл ажиллагаанд зориулж процесс бүтээхэд өөрсдийн програм хангамж, туршлагаа ашигласан 3PL операторуудад итгэдэг байсан.
Бараа хүлээн авах
Бидний хэлснээр манай компани тухайн үед (зарчмын хувьд одоо) олон дэлгүүр нээхийг хичээж байсан тул нэвтрүүлэх чадварыг нэмэгдүүлэхийн тулд агуулахын үйл явцыг оновчтой болгох шаардлагатай болсон (бага хугацаанд илүү их бараа). Энэ нь тийм ч амар ажил биш бөгөөд энэ бүх хүмүүс бие биедээ саад учруулдаг учраас боловсон хүчнийг нэмэгдүүлэх замаар шийдэх боломжгүй байсан. Тиймээс бид WMS (агуулах удирдлагын систем) мэдээллийн системийг хэрэгжүүлэх талаар бодож эхэлсэн. Хүлээгдэж байсанчлан бид агуулахын зорилтот үйл явцын тодорхойлолтоос эхэлж, бараа хүлээн авах үйл явцыг сайжруулахын тулд тариалангүй талбайг аль хэдийн олж мэдсэн. Агуулахын аль нэг дэх процессыг боловсруулж, дараа нь үлдсэн хэсэгт шилжүүлэх шаардлагатай байв.
Хүлээн авах нь агуулахын хамгийн анхны томоохон үйл ажиллагааны нэг юм. Энэ нь хэд хэдэн төрөл байж болно: бид зүгээр л багцын тоог дахин тооцоолж, шаардлагатай үед тавиур тус бүр дээр хэдэн, ямар нийтлэл байгааг тооцоолох хэрэгтэй. Манай бараа бүтээгдэхүүний ихэнх нь хөндлөн залгах урсгалаар дамждаг. Энэ нь бараа нийлүүлэгчээс агуулахад ирэх бөгөөд агуулах нь чиглүүлэгчийн үүрэг гүйцэтгэж, эцсийн хүлээн авагч (дэлгүүр) руу нэн даруй дахин илгээхийг оролддог. Бусад урсгалууд байдаг, жишээлбэл, агуулах нь кэш эсвэл дэлгүүрийн үүрэг гүйцэтгэдэг (та нийлүүлэлтийг нөөцөд хийж, хэсэг болгон хувааж, аажмаар дэлгүүрт гаргах хэрэгтэй). Үлдэгдэлийг оновчтой болгох математик загварчлалын чиглэлээр ажилладаг миний хамт олон хувьцаатай ажиллах талаар илүү сайн ярих байх. Гэхдээ энд гэнэтийн зүйл байна! Зөвхөн гар ажиллагаатай холбоотой асуудал үүсч эхлэв.
Үйл явц нь иймэрхүү харагдаж байв: ачааны машин ирсэн, жолооч агуулахын администратортой бичиг баримтаа солилцсон, администратор тэнд юу ирсэн, хаашаа илгээхийг ойлгосон, дараа нь ачигчаа бараагаа авахаар явуулсан. Энэ бүхэн гурван цаг орчим үргэлжилсэн (Мэдээжийн хэрэг, хүлээн авах хугацаа нь бид ямар төрлийн логистикийн урсгалыг хүлээн авахаас ихээхэн хамаардаг: хаа нэгтээ багц доторх дахин тооцоолол хийх шаардлагатай байдаг, гэхдээ хаа нэгтээ тийм биш). Нэг ачааны машинд илүү олон хүнийг илгээх боломжгүй: тэд бие биедээ саад болно.
Ямар алдагдал хүлээсэн бэ? Тэд далай байсан. Эхлээд агуулахын ажилчид цаасан бичиг баримтыг хүлээн авсан. Өөрсдийнх нь хэлснээр нийлүүлэлтээ хэрхэх талаар удирдан чиглүүлж, шийдвэр гаргасан. Хоёрдугаарт, тавиуруудыг гараар тоолж, ижил замын хуудсан дээр тоо хэмжээг тэмдэглэв. Дараа нь бөглөсөн хүлээн авах маягтуудыг компьютерт аваачиж, өгөгдлийг XLS файлд оруулсан болно. Дараа нь энэ файлын өгөгдлийг ERP-д импортолсон бөгөөд зөвхөн дараа нь манай мэдээллийн технологийн цөм уг бүтээгдэхүүнийг бодитоор харсан. Бидэнд тээвэрлэлтийн ирэх цаг гэх мэт захиалгын талаар маш бага мета өгөгдөл байсан эсвэл энэ өгөгдөл буруу байсан.
Бидний хийсэн хамгийн эхний зүйл бол агуулахуудыг өөрсдөө автоматжуулж, процессын дэмжлэгтэй болох явдал байв (энэ нь олон тооны програм хангамж, гар утасны бар код сканнер гэх мэт техник хангамж, энэ бүхний дэд бүтцийг байрлуулах шаардлагатай байсан). Дараа нь тэд эдгээр системийг ERP-тэй автобусаар холбосон. Эцсийн эцэст, ачигч ирж буй ачааны машин дээрх тавиур дээр бар код сканнер ажиллуулж байх үед бэлэн байдлын мэдээлэл системд шинэчлэгддэг.
Энэ нь иймэрхүү болсон:
- Нийлүүлэгч өөрөө бидэнд юу, хэзээ илгээсэн тухай мэдээллийг бөглөдөг. Үүнд зориулсан олон тооны SWP болон EDI порталууд байдаг. Өөрөөр хэлбэл, дэлгүүр нь захиалгыг нийтэлж, ханган нийлүүлэгчид өргөдлийг биелүүлж, шаардлагатай хэмжээгээр бараа нийлүүлэх үүрэгтэй. Барааг илгээхдээ ачааны машин дахь тавиурын найрлага, логистикийн бүх шаардлагатай мэдээллийг зааж өгдөг.
- Машин нь ханган нийлүүлэгчийг орхисон үед бид ямар бараа ирж байгааг аль хэдийн мэддэг; Мөн ханган нийлүүлэгчидтэй цахим баримт бичгийн менежментийг бий болгосон тул UPD-д аль хэдийн гарын үсэг зурсан гэдгийг бид мэднэ. Энэ бүтээгдэхүүнийг оновчтой шилжүүлэх схемийг бэлтгэж байна: хэрэв энэ нь хөндлөн залгах юм бол бид бараагаа тооцож агуулахаас тээвэрлэлт захиалсан бөгөөд бүх логистикийн урсгалын хувьд бид агуулахын нөөцийг хэр их байлгахаа аль хэдийн тодорхойлсон. хүргэлтийг боловсруулах шаардлагатай. Хөндлөн залгах дэлгэрэнгүй мэдээлэлд агуулахаас тээвэрлэх урьдчилсан төлөвлөгөөг ханган нийлүүлэгчтэй нэгтгэсэн агуулахын хаалганы удирдлагын системд (YMS - хашааны менежментийн систем) хүргэлтийн зайг дөнгөж нөөцөлсөн үед агуулахаас тээвэрлэх урьдчилсан төлөвлөгөөг гаргадаг. портал. Мэдээлэл YMS-д шууд ирдэг.
- YMS нь ачааны машины дугаарыг (илүү нарийвчлалтай, SWP-ээс ачааны дугаар) хүлээн авч, жолоочийг хүлээн авахаар бүртгэдэг, өөрөөр хэлбэл түүнд шаардлагатай цагийг хуваарилдаг. Өөрөөр хэлбэл, одоо цагтаа ирсэн жолооч шууд дараалал хүлээх шаардлагагүй бөгөөд түүний хууль ёсны хугацаа, буулгах зогсоол түүнд зориулагдсан болно. Энэ нь ачааны машиныг нутаг дэвсгэр даяар оновчтой хуваарилж, буулгах нүхийг илүү үр ашигтай ашиглах боломжийг бидэнд олгосон. Бас хэн, хаана, хэзээ ирэхийг урьдчилан хуваарь гаргадаг болохоор хэдэн хүн, хаана хэрэгтэйг мэддэг. Энэ нь агуулахын ажилчдын ажлын хуваарьтай холбоотой юм.
- Энэхүү ид шидийн үр дүнд ачигчид нэмэлт чиглүүлэлт хийх шаардлагагүй болж, зөвхөн машин буулгахыг хүлээх болжээ. Үнэн хэрэгтээ тэдний хэрэгсэл - терминал нь юу хийх, хэзээ хийхийг хэлж өгдөг. Хийсвэрлэлийн түвшинд энэ нь дуудагч API-тай адил боловч хүн-компьютерийн харилцан үйлчлэлийн загварт байдаг. Ачааны машинаас эхний тавиурыг сканнердах мөч нь хүргэлтийн мета өгөгдлийн бүртгэл юм.
- Буулгах ажлыг гараар хийдэг хэвээр байгаа боловч тавиур бүрийн хувьд ачигч нь бар код сканнер ажиллуулж, шошгоны өгөгдөл эмх цэгцтэй байгааг баталгаажуулдаг. Энэ нь бидний хүлээж буй зөв тавиур мөн эсэхийг систем хянадаг. Буулгах төгсгөлд систем нь бүх багцын үнэн зөв дахин тооцоололтой болно. Энэ үе шатанд гэрлэлтийг арилгасан хэвээр байна: хэрэв тээвэрлэх саванд илт гэмтэл гарсан бол буулгах явцад үүнийг тэмдэглэхэд л хангалттай, эсвэл бүрэн ашиглах боломжгүй бол энэ бүтээгдэхүүнийг огт хүлээж авахгүй.
- Өмнө нь хүн бүрийг машинаас буулгасны дараа тавиурыг буулгах хэсэгт тоолдог байсан. Одоо физик буулгах үйл явц нь дахин тооцоолол юм. Хэрэв энэ нь тодорхой бол бид гэрлэлтийг шууд буцааж өгдөг. Хэрэв энэ нь тодорхойгүй бөгөөд дараа нь олдвол бид үүнийг агуулах дахь тусгай буферт хуримтлуулдаг. Уг процесст тавиур хаяж, хэдэн арван ширхэгийг цуглуулж, ханган нийлүүлэгчид нэг удаа очиж бүгдийг нь авах нь хамаагүй хурдан юм. Зарим төрлийн согогийг дахин боловсруулах бүсэд шилжүүлдэг (энэ нь ихэвчлэн гадаадын ханган нийлүүлэгчдэд хамаатай бөгөөд тэд хилээр буцааж авахаас илүү зураг авч, шинэ бүтээгдэхүүн илгээхэд хялбар байдаг).
- Буулгах ажил дууссаны дараа баримт бичигт гарын үсэг зурж, жолооч өөрийн ажлаар явна.
Хуучин процесст тавиуруудыг ихэвчлэн тусгай хамгаалалтын бүсэд шилжүүлдэг байсан бөгөөд тэнд аль хэдийн ажиллаж байсан: тэдгээрийг тоолж, гэрлэлтийг бүртгэсэн гэх мэт. Энэ нь дараагийн машинд докыг суллахад шаардлагатай байсан. Одоо бүх процессууд нь энэ буфер бүс шаардлагагүй байхаар тохируулагдсан. Сонгомол дахин тооцоолол байдаг (жишээний нэг нь Светофор төсөлд хэрэгжсэн агуулахад хөндлөн залгах зориулалттай сав доторх сонгомол дахин тооцооллын үйл явц юм), гэхдээ ихэнх барааг хүлээн авсны дараа шууд боловсруулдаг бөгөөд энэ нь усан онгоцны зогсоол юм. Энэ нь агуулахын хамгийн тохиромжтой газар эсвэл агуулахаас ачих тээвэр аль хэдийн ирсэн бол ачих өөр зогсоол руу очно. Энэ нь танд бага зэрэг эгэлгүй сонсогдож байгааг би мэдэж байна, гэхдээ таван жилийн өмнө асар том агуулахад өөр ачааны машин ачих цэг шиг ачааг шууд эцсийн цэгүүд рүү боловсруулах боломжтой болсон нь бидэнд сансрын хөтөлбөр мэт санагдсан.
Бүтээгдэхүүний дараа юу болох вэ?
Цаашилбал, хэрэв энэ нь хөндлөн залгаагүй бол (мөн барааг тээвэрлэхээс өмнө буферт эсвэл шууд усан онгоцны зогсоолд үлдээгээгүй бол) хадгалахад зориулж нөөцлөх ёстой.
Энэ бүтээгдэхүүн хаашаа явах, аль хадгалах үүр рүү явахыг тодорхойлох шаардлагатай. Хуучин үйл явцад тухайн төрлийн барааг аль бүсэд хадгалахаа нүдээр тодорхойлж, дараа нь тэнд байрлах газрыг сонгоод, юу тавьсан, авч, тавьж, бичих шаардлагатай байв. Одоо бид топологийн дагуу бүтээгдэхүүн бүрийн байршуулах маршрутыг тохируулсан. Бид ямар бүтээгдэхүүн аль бүс, аль эс рүү орох ёстойг мэддэг, хэрвээ том хэмжээтэй байвал хажууд нь хэдэн эс нэмж авахыг мэддэг. Нэг хүн тавиур дээр ойртож, TSD ашиглан SSCC-ээр сканнердаж байна. Сканнер нь: "Үүнийг A101-0001-002 руу аваач." Дараа нь тэр тийшээ явж, юу тавьсанаа тэмдэглэж, сканнерыг код руу нь оруулав. Систем бүх зүйл зөв эсэхийг шалгаж, тэмдэглэнэ. Та юу ч бичих шаардлагагүй.
Энэ нь бүтээгдэхүүнтэй хийх ажлын эхний хэсгийг дуусгаж байна. Дараа нь дэлгүүр агуулахаас авахад бэлэн болно. Энэ нь хангамжийн хэлтсийн хамт олон илүү сайн хэлэх дараагийн үйл явцыг бий болгож байна.
Тиймээс системд захиалга хүлээн авах үед хувьцаа шинэчлэгддэг. Мөн үүрний хангамж нь тавиурыг дотор нь байрлуулсан мөчид байна. Өөрөөр хэлбэл, нийт хэчнээн бараа, аль нь хаана байрлаж байгааг бид үргэлж мэддэг.
Маш олон урсгалууд төвүүд рүү (бүс нутгийн шилжүүлэн ачих агуулахууд) шууд ажилладаг, учир нь манай бүс нутаг бүрт олон орон нутгийн ханган нийлүүлэгчид байдаг. Воронежийн ижил агааржуулагчийг холбооны агуулахад биш, харин хурдан бол орон нутгийн төвүүд дээр суулгахад илүү тохиромжтой.
Татгалзах урвуу урсгалыг мөн бага зэрэг оновчтой болгосон: хэрэв барааг хөндлөн суурилуулсан бол нийлүүлэгч нь Москва дахь агуулахаас авч болно. Хэрэв тээврийн багцыг нээсний дараа гэрлэлтийг нээсэн бол (мөн энэ нь гаднаас нь тодорхойгүй байсан, өөрөөр хэлбэл тээврийн ажилчдын буруугаас болж гараагүй) дэлгүүр бүрт буцах бүс байдаг. Гэрлэлтийг холбооны агуулахад хаяж болно, эсвэл та дэлгүүрээс шууд нийлүүлэгчид өгч болно. Хоёр дахь нь илүү олон удаа тохиолддог.
Яг одоо боловсронгуй болгох шаардлагатай өөр нэг үйл явц бол борлуулагдаагүй улирлын чанартай бараа бүтээгдэхүүнтэй харьцах явдал юм. Бидэнд шинэ жил, цэцэрлэгийн цаг гэсэн хоёр чухал улирал бий. Өөрөөр хэлбэл, XNUMX-р сард бид ДЦС-д зарагдаагүй хиймэл гацуур мод, зүүлтийг хүлээн авдаг бол өвөл гэхэд зүлэгжүүлэгч болон бусад улирлын чанартай барааг дахин нэг жил хадгалах шаардлагатай болдог. Онолын хувьд та улирлын төгсгөлд тэдгээрийг бүрэн зарах эсвэл өөр хүнд өгөх хэрэгтэй бөгөөд тэдгээрийг агуулах руу чирэх ёсгүй - энэ бол бидний гарт хараахан хүрч амжаагүй хэсэг юм.
Таван жилийн хугацаанд бид бараа хүлээн авах (машин буулгах) хугацааг XNUMX дахин багасгаж, бусад хэд хэдэн процессыг хурдасгаж, нийтдээ хөндлөн залгах эргэлтийг хоёр дахин нэмэгдүүлсэн. Бидний даалгавар бол агуулах дахь мөнгийг "царцаахгүй" байхын тулд нөөцийг багасгахын тулд оновчтой болгох явдал юм. Мөн тэд дэлгүүрүүдэд тохирсон бараагаа цаг тухайд нь авах боломжтой болгосон.
Агуулах үйл явцын хувьд өмнө нь цаас байсан зүйлийг автоматжуулж, тоног төхөөрөмж, зөв тохируулсан үйл явцаас шалтгаалж үйл явцын шаардлагагүй алхамуудаас ангижрах, компанийн бүх мэдээллийн технологийн системийг нэг цогц болгон холбох зэрэг томоохон сайжруулалтууд байв. ERP (жишээлбэл, дэлгүүрийн зүүн талын гурав дахь тавиур дээр ямар нэгэн зүйл дутагдаж байна) эцэст нь агуулахын систем, тээвэрлэлтийг захиалах гэх мэт тодорхой үйлдлүүд болж хувирав. Одоо оновчлол нь бидний хараахан хүрч амжаагүй байгаа үйл явц, урьдчилан таамаглах математикийн тухай юм. Өөрөөр хэлбэл, хурдацтай хэрэгжүүлэх эрин үе дуусч, 30 хувийн үр дүнг өгсөн ажлын 60 хувийг хийсэн, дараа нь бусад бүх зүйлийг аажмаар хамрах ёстой. Эсвэл өөр газар руу нүүж, хэрэв тэнд илүү их зүйл хийх боломжтой бол.
За, хэрэв бид хадгалсан модыг тооцвол нийлүүлэгчдийг EDI портал руу шилжүүлэх нь бас их зүйлийг өгсөн. Одоо бараг бүх ханган нийлүүлэгчид менежертэй утсаар холбогддоггүй, гэхдээ тэд өөрсдөө хувийн дансанд байгаа захиалгыг харж, баталгаажуулж, бараагаа хүргэж өгдөг. Боломжтой бол бид цааснаас татгалздаг; 2014 оноос хойш ханган нийлүүлэгчдийн 98% нь цахим баримт бичгийн менежментийг ашиглаж байна. Нийтдээ эдгээр нь шаардлагатай бүх цаасыг хэвлэхээс татгалзсанаар л жилд 3 модыг хэмнэдэг. Гэхдээ энэ нь процессорын дулааныг тооцохгүйгээр, мөн утсан дээрх ижил менежерүүд шиг хүмүүсийн хэмнэлттэй ажлын цагийг харгалзаагүй явдал юм.
Таван жилийн хугацаанд бид дэлгүүрийн тоог XNUMX дахин, янз бүрийн баримт бичгийн тоог XNUMX дахин нэмэгдүүлж, EDI байхгүй байсан бол нягтлан бодогчдын тоог XNUMX дахин нэмэгдүүлэх байсан.
Бид амжилтад хүрэхгүй байгаа бөгөөд EDI-д шинэ мессежүүд, шинэ ханган нийлүүлэгчид цахим баримт бичгийн менежментэд үргэлжлүүлэн холбогдож байна.
Өнгөрсөн жил бид Европ дахь хамгийн том түгээлтийн төвийг нээсэн - 140 м.кв. м - мөн механикжуулалтаа авчээ. Би энэ тухай өөр нийтлэлд ярих болно.
Эх сурвалж: www.habr.com