Рейстер үшін TMS әзірлеу: статустар, жоспар‑факт, құжаттар

Рейстерге арналған TMS қандай тапсырмаларды шешуі керек

Егер рейстер кестелерде, чатта және поштада жүргізілсе, әр қатысушының өз дерегі болады. Диспетчер рейсті «жолда» деп есептейді, тасымалдаушы — «жүктеу үстінде», қойма — «әлі келген жоқ», ал бухгалтерияда тек шот қана бар, бірақ растайтын құжаттар жүйесі түсініксіз. Рейстерге арналған TMS керек, сол арқылы барлығы бірдей статус, уақыт және құжаттар көрінісіне ие болады.

Бірінші негізгі міндет — рейс статустарының бірыңғай жүйесі. Оған жоқ болса, қарапайым сұрақтарға тез жауап беру мүмкін емес: жүкті қайда табуға болады, кешіктіру кімнен, қашан келу керек. Статустар тек «сәуір үшін» емес, оқиғаларға және жауапкершілікке байлануы маңызды: кім статусты өзгертеді, қандай шарттар кезде, қандай өрістер міндетті.

Екінші міндет — план‑факт және ашық ауытқулар. Жоспар көбінесе өтініште, ал факт — қоңыраулар мен қағаздарда қалады. Содан да даулар пайда болады: «біз уақтылы келдік», «бірақ кедергіде 3 сағат тұрдық». TMS негізгі нүктелер бойынша жоспарлы және фактілік уақыттарды сақтауы (көлік жіберу, жүктеу/жүк түсіру басталуы мен аяқталуы, шығу, келу) және ауытқуларды түсінікті ережелер бойынша есептеуі керек.

Үшінші міндет — бірнеше тасымалдаушымен хаоссыз жұмыс. Әр тасымалдаушының өз форматтары, жүргізушілері, телефондары мен атаулары болса, справочниктер мен есептер бұзылады. Біртұтас карточкалар — контрагенттер, ТС пен жүргізушілер үшін, қолжетімділік ережелері және өзгерістер тарихы қажет, осылай кім және неге деректі өзгертті көрінеді.

Төртінші міндет — растайтын құжаттарды бақылау. Расталмаған құжаттар қауіпті: төлем уақытынан бұрын жасалуы мүмкін, шағымды дәлелдеу қиын, және есеп айырысу аптаға созылуы ықтимал.

Минималды нұсқада рейстерге арналған TMS келесі тапсырмаларды жабады:

• статус, жауапты және соңғы оқиғасы көрсетілген біріккен рейс журналы;
• бақылау нүктелері бойынша план‑факт және ауытқулар себептері;
• рейсті тасымалдаушыларға бөлу (негізгі, субподряд) және пайдаланушы рөлдері;
• құжаттар реестрі (ТТН/CMR, акт, шот) тексеру статустары бар;
• блоктаулар: міндетті растамаларсыз "рейсті жабуға" немесе төлемге жіберуге болмайды.

Мысал: рейстің статусы «келді» деп тұр, бірақ шын мәнінде жүргізуші әлі КПП-де күтіп тұр. Егер факт тек қоңыраудан алынатын болса, есепте «уақытында» шығады, ал қойма мен клиент қате ETA алады. Егер TMS «КПП-ден өту» оқиғасын уақыт пен растамасымен талап етсе, айырмашылық бірден көрінеді, және дау дерекке айналады, әңгімеге емес.

TMS-ті әзірлегенде алдын‑ала қандай статустар финал саналады және қандай құжаттар төлем мен рейсті жабу үшін міндетті екенін шешкен дұрыс. Бұл әдетте іске қосу мен алғашқы тексерістерде көп уақыт үнемдейді.

Минималды деректер моделі: алғашқы күннен не сақтау керек

Егер рейстерге арналған TMS әзірлеп бастасаңыз, деректер моделінің мақсаты қарапайым: кез келген сәтте үш сұраққа жауап беру — рейс қазір қай жерде, нақты не тасымалданады және факт қандай құжаттармен расталған.

Негізгі объектілер

MVP-де бүкіл логистиканың бәрін суреттемеңіз. Бір‑бірімен қайшылықсыз және оңай кеңейтуге болатын объектілер жеткілікті:

• Рейс (trip): нөмір, даталар, ағымдағы статус, жауапты.
• Заказ (order): клиент, шарттар, рейспен байланыс (1 рейс — көп заказ).
• Аялдама (stop): мекенжай, уақыт терезесі, түрі (жүктеу/түсіру), реттілік.
• Жүк (cargo): орындар/салмақ/көлем, қауіптілік, температура, заказға байланысы.
• ТС, жүргізуші, тасымалдаушы: идентификаторлар, контактілер, рұқсат құжаттары.

Осындай каркас бірнеше нүктеден тұратын маршруттар құруға, заказдарды рейстерге бөлуге және әртүрлі тасымалдаушыларды қосуға мүмкіндік береді, справочниктерде бардақ болмайды.

Оқиғалар мен құжаттар бөлек объект ретінде

Факт көбіне бөліктермен келеді: жүргізушінің қоңырауы, GPS, КПП белгісі, мердігер интеграциясы. Сондықтан рейс оқиғаларын статустан бөлек сақтау тиімді. Оқиға — уақыт, орын және дереккөзі бар жазба (мысалы, диспетчер, мобильді қосымша, телематика). Сол кезде статусты қайта есептеуге немесе растауға болады, тарих сақталады.

Құжаттарды да "рейстегі файл" ретінде емес, объект ретінде сақтаңыз. Минимум керек заттар: түрі (ТТН/CMR/акт), нөмір, даталар, байланысқан рейс/заказ/аялдама, файлдар (оригинал/скан) және тексеру статусы (күтіп тұр, қабылданған, қабылданбаған) себеппен.

Баршаға ыңғайлы болу үшін деректер деңгейінде рольдер мен құқықтарды енгізіңіз. Мысалы, диспетчер рейстерді құрады, аялдамаларды түзетеді және оқиғаларды тіркейді. Бухгалтерия құжаттарды тексереді және төлемге жабады. Қауіпсіздік қызметі жүргізуші/ТС және рұқсаттарды қарайды, сәйкессіздіктерді блоктайды. Клиент статус пен растайтын құжаттарды көре алады, бірақ өңдей алмайды.

Мысал: жүргізуші 10:05 те жүктелді, диспетчер «жүктеу аяқталды» оқиғасын жазды, ал кейін бухгалтерия ТТН сканын қабылдайды. Рейс құжат «қабылданған» статусына келгенше төлемге жіберілмейді.

Рейс статустары: қарапайым әрі сенімді схема қалай жасау керек

TMS-та статустар деңгейлерді шатастырудан құрылады. Бірінші ереже: рейс статусы мен заказ статусы (немесе отгрузка) — түрлі заттар. Рейс көлік қозғалысын және маршруттың орындалуын сипаттайды. Заказ клиент алдындағы міндеттемелерді сипаттайды: не, қайда және қандай көлемде келуі тиіс.

Деңгелерді араластырсаңыз, хаос пайда болады: бір заказ ішінара жеткізілген болуы мүмкін, ал рейс әлі жүріп жатыр. Немесе рейс аяқталған, бірақ заказтың бір бөлігі кем жеткізілген деп жазылған. Сондықтан рейс карточкасында тек рейске қатысты нәрселер болсын, ал заказ күйін бөлек есептеңіз (нүктелер бойынша фактілер, құжат скандары мен ерекшеліктер негізінде).

Жақсы статустар схемасы бірмәнді болуы керек: бір әрекет — бір статус. «В пути/ожидает» немесе «Почти доставлено» сияқты статус қоймаңыз. Пайдаланушы қандай оқиға болғанын және қандай оқиға әлі болмағанын түсінуі тиіс.

Әдетте өміршең кезеңдерді көрсететін қысқа тізбек жеткілікті:

• Жоспарланған
• Тасымалдаушы тағайындалды
• Шығып кетті
• Нүктеге келді
• Аяқталды

Одан кейін жаңа сөздер қосудан гөрі өтулер ережелерін бекіту маңызды. Мысалы, "Шығып кетті" статусын "Тасымалдаушы тағайындалды"-ға себебі көрсетілмей қайта қоюға болмайды. "Аяқталды" деп қоюға болмайды, егер міндетті маршрут нүктелері жабылмаған болса (компанияда осындай логика қабылданған болса). Сонымен бірге ерекшеліктер үшін түсінікті жол болу керек: рейсті жою, машинаны ауыстыру, уақытты кейінге қою.

Статустар «кім дұрыс» деген дауға айналмасын үшін өзгерістер тарихын қатты бекітіңіз. Әр өтуде тіркелуі тиіс:

• кім статусты өзгертті (пайдаланушы немесе интеграция);
• қашан өзгерді (нақты уақыт);
• факт қайдан келген (қолмен енгізу, GPS, EDI, құжат сканы);
• стандартты емес өтулерде себеп (мысалы, «жауын‑шашынға байланысты орын ауыстыру»).

Мысал: екі нүктесі бар рейс (қойма және дүкен). Диспетчер рейс жасап, тасымалдаушы тағайындады — статус «Тасымалдаушы тағайындалды». Жүргізуші мобильді қосымшада стартты белгіледі — «Шығып кетті» дереккөзі «мобильді қосымша». Дүкенде қабылдаушы ТТН сканын жүктеді — рейс «Аяқталды» статусы алады, ал рейстегі заказ нақты позицияларға байланысты «Жеткізілді» немесе «Бөліктеп жеткізілді» болуы мүмкін. Осылай сөздер туралы дау туындамайды: әрекет, дереккөзі және уақыты көрінеді.

Егер TMS ішкі өнім болып немесе интегратор арқылы жасалатын болса, статустар схемасын логистика, бухгалтерия және қауіпсіздік қызметімен келісіңіз. Кейін «Аяқталды» жабу құжаттарына сай келмейтінін түсіндіру одан арзанырақ келеді.

План‑факт: ауытқуларды қалай есептеп, цифрлар туралы таласуды болдырмау

TMS-та план‑факт жиі даулардың көзі емес, «нашар жүргізушілерден» емес, есептеу ережелерінің әр түрлі болуынан пайда болады. Сол себепті алдын‑ала не жоспар, не факт және KPI-ге қандай оқиғалар әсер ететіні анықталуы тиіс.

Жоспарды бір датамен емес, әр нүкте бойынша параметрлер жинағы ретінде сақтау жақсы: уақыт терезесі (бастап/аяқ), нүктеге дейінгі есептелген жол уақыты, есептелген сапар ұзақтығы және нүктедегі жұмыстардың нормативтері (жүктеу/түсіру нормасы). Содан кейін ауытқулар барлығына бірдей есептеледі: факт нақты нормативпен салыстырылады, диспетчердің «күтімімен» емес.

Факт оқиғалар жиынтығынан құралады. «Келді» мен «жұмыс бастады» және «шықты» деп бөлген дұрыс, әйтпесе кешігу мен простаий араласып кетеді. Практикада GPS, мобильді қосымша немесе қолмен енгізуден алынатын қысқа оқиғалар жиынтығы көмектеседі: нүктеге келу, жұмыстардың басталуы, жұмыстардың аяқталуы, нүктеден шығу және күту себебі (бар болса).

Бөлек мәселе — қайта кірулер. Бір нүктеге бірнеше факт жиынтығына рұқсат етіңіз (мысалы, «кіру 1», «кіру 2»), бірақ KPI үшін «негізгі» жиынтықты таңдау ережесін қойыңыз. Көп таралған нұсқа: негізгі — нүктені жабуға әкелген жиынтық, қалғандары қосымша деп белгіленіп, расталған себеп болса айыппұлдарға әсер етпейді.

Цифрлар туралы даулар болмас үшін KPI анық формулалар бойынша есептеліп, шешімі көрсетілуі тиіс. Мысалы: «кешігу» = max(0, келу уақыты - терезе аяқталуы), «простай» = max(0, (жұмыс басталуы - келу) - рұқсат етілген күту), «мерзімде орындау» = иә, егер келу терезеге ілінсе.

Мысал: жоспар бойынша қойма 10:00‑ден 12:00‑ге дейін қабылдайды, рұқсат етілген күту 20 минут. Машина 11:50‑де келді, жұмыстар 12:40‑та басталды. Есепте көрсетілуі тиіс: кешігу 0 минут (терезеде), простай 30 минут (50 минут күту минус 20 рұқсат етілген). Пайдаланушы оқиғаларға бөлінген есепті көрсе, даулар азаяды.

Және тағы: факттердің дереккөзі мен өзгерістер тарихы болуы тиіс (кім және қашан түзеткен), әйтпесе KPI «суреттелген» болып көрінеді.

Бірнеше тасымалдаушы: ережелер, құқықтар және бірыңғай справочниктер

Бірнеше тасымалдаушы қатысатын кезде даулар көбіне бағада емес, деректерде басталады: біреу «тент 13.6» деп жазады, басқа «еврофура», өңірлер әртүрлі, жүргізуші тек «Сергей» деп жазылған. Сондықтан TMS әзірлегенде бір тіл мен кімнің не өзгерте алатынын алдын‑ала келісу маңызды.

Тасымалдаушының бірыңғай карточкасы

Бір анық карточка жасаңыз және онда тасымалдаушыны тағайындау мен төлемдерге әсер ететін барлық нәрсені сақтаңыз. Бастапқыда бұл ақпаратты түрлі модульдерге бөлмеу маңызды — диспетчер тасымалдаушыға рейсті беруге болатынын тез көруі керек.

Көбінесе карточкада болуы тиіс: келісімшарт және статусы (актив, үзілісте, блокталған), тарифтер мен шарттар (маршруттар бойынша, ТС түріне, қосымша қызметтерге), шектеулер (аймақтар, жүк түрлері, температура режімі, рұқсаттар), контактілер мен рөлдер (диспетчер, бухгалтерия, басшылық), құжат талаптары мен мерзімдері.

Оның үстіне сценарийлер ойластырыңыз: өз паркі, тұрақты 3PL және бірреттік мердігерлер. Өз паркі үшін ішкі тарифтер, 3PL үшін тарифтік тор, бірреттік мердігерлер үшін жылдам онбординг пен құжат жоқ болса қатаң блоктаулар.

Бірыңғай справочниктер және сәйкестендіру

Егер тасымалдаушыларға жүйеге қолжетімділік берсеңіз, оларды деректерін әр жолы сіздің атауларыңызға «аударуға» мәжбүрлемеңіз. Жүйеде ішкі справочниктер (құбыр түрлері, аймақтар, өлшем бірліктері, ТС пен жүргізуші статустары) және сәйкестендіру кестесі болсын: «біздің жүйедегі» және «тасымалдаушыдағы» атаулар. Ол кезде есептер бірдей есептеледі, тіпті серіктес өз кодтарын жіберсе де.

Құқықтар маңызды: тасымалдаушы ТС мен жүргізушілерді қоса алады, бірақ справочниктерді, тарифтерді және қабылдау ережелерін өзгерте алмауы керек. Практикалық тәсіл: жаңа ТС, жүргізушілер және реквизиттер «тексеру режиміне» түседі, расталғаннан кейін ғана тағайындауға ашылады.

Қолдану сапасын қолмен іздеусіз бақылау

Тасымалдаушылардың сапасын жазбаларда емес, жүйенің өзі есептейтін көрсеткіштерде сақтау жақсы. Негізгі жинақ жеткілікт: пунктуалдық (жүктеу/түсіру кешігулері), оқиғалар (заң бұзушылық, жетіспеу, айыппұлдар), құжаттарды уақытында беру, тағайындауларды болдырмау және проблемасыз рейстердің үлесі.

Рейтинг төмендесе немесе құжаттар жүйелі түрде кешіктірілсе, TMS нақты әрекет ұсынуы тиіс: жаңа рейстерге қолжетімділікті шектеу, шарттарды қатаңдату немесе қосымша тексеруге жіберу — компания ережелері бойынша.

Растайтын құжаттар: жинау, тексеру, блоктаулар

Рейстерде құжаттар көп жағдайда сөзден маңызды. Егер TMS құжаттарды уақытылы жинап, тексеруді білмесе, факт жөніндегі даулар басталады, шоттар кешігіп, рейстер «іледі». Сондықтан қай құжат керек, қашан және кім жүктейді, дұрыс ережелерді бастапқыдан енгізу керек.

Қандай құжаттар сұрау керек және қашан

Көлік түріне байланысты жиынтық өзгереді, бірақ кезеңдер логикасы бірдей. Шығу алдында келісімшарттық және рұқсат құжаттары (өтініш, маршрут, сенімхат, ТС және жүргізуші деректері) қажет. Жолда оқиғаларды растайтындар (жүктеу белгісі, простай актілері, пломбалар фото) маңызды. Тапсырыс берушіге жеткізгеннен кейін жабу құжаттары: қабылдау растамасы, ақтау актісі, тауарлық сүйемелдеу құжаттары.

Оны қолмен бақылауға айналдырмас үшін TMS «міндеттілік матрицасын» сақтауы керек: құжат міндетті ме, қай типті рейске қажет, қандай кезеңде және не растайды (жүктеу, жеткізу, қосымша қызмет).

Статустар және тексеру

Әр файлда барлық қатысушылар түсінетін статус болуы тиіс. Практикалық минимум:

• Сұралған: жүйе құжатты нақты датаға күтіп тұр.
• Қабылданған: файл жүктелді, бірақ тексерілмеген.
• Тексеруде: құжат жауаптыда.
• Қабылданды: тексеруден өтті, есепте пайдалануға болады.
• Қабылданбады: сәйкессіздік табылды, жаңа файл немесе түзету қажет.

Тексеру екі қабатта тиімдірек. Бірінші — автомат: міндетті өрістер толтырылған ба, файл оқылатын ба (бос немесе «қара» скан емес), даталар рейспен қабыс па, сома мен валюта келісілген ставкалармен сәйкес пе. Екінші — таңдамалы адам тексерісі: даулы жағдайларды қарап, комментариймен ерекшеліктерді растайды.

Мысал: тасымалдаушы жеткізуден кейін накладная фотосын жүктеген, бірақ штамптағы рейс нөмірі сәйкес келмеген. TMS «Қабылданбады» қояды, қайта жүктеуді сұрайды, және құжат «Қабылданған» болмайынша рейс жабылмайды.

Блоктаулар: төлем және рейс жабылуымен байланыс

Негізгі ереже қарапайым: ақша және рейсті жабу құжат статусына тәуелді. Алдын ала анықтаңыз нені блоктайды:

• шотты шығару (жеткізу растамасы қабылданбаған болса);
• қосымша қызметтерді есептеу (простай акты жоқ болса);
• рейсті жабу (кілтті комплект қабылданбаған болса).

Осылайша «ауызша келісімдер» жойылады. Құжаттар әр түрлі жерден жүктелсе де — офис, қойма пункті немесе кенет тегіс моноблок — барлығында бір логика: құжат «Қабылданған» болмайынша процесс аяқталмаған болып саналады.

Интеграциялар және оқиғалар: факт қайдан алынады және кімге керек

Рейс фактісі әдетте бір жүйеден келмейді. Қай көздер сенімді саналатынын, олардың бір форматқа қалай келтірілетінін және даулы жағдайларды кім растайтынын алдын ала келісу маңызды. Олай жасамасаңыз, план‑факт үнемі «айналатын» болады, ал даулар тасымалдаудан да көп уақыт алады.

Факт қайдан пайда болады

Әр түрлі тасымалдаушылардың цифрландыру деңгейі әртүрлі болғандықтан бірнеше фиксация тәсілін қолдау қажет:

• GPS/телематика: координаталар, жылдамдық, геозоналар (зонаны кесіп өткенде келу/кету).
• Қолмен оқиғалар: диспетчер немесе жүргізуші «жетті», «жүктеу аяқталды» деп белгілейді.
• Тасымалдаушыдан растау: серіктестің жеке кабинетінде немесе файл/хабарлама арқылы статус пен уақыт.
• Қойма/өндіріс оқиғалары: «жүктеуге дайын», «рампаға қабылданды», егер осындай жүйелер болса.
• Құжат скандары: растайтын құжаттың жасалу/жүктелу уақыты жанама факт болып саналады.

Әр оқиға үшін тіркеңіз: дереккөзі, нақты уақыт (уақыт белдеуімен), пайдаланушы/жүйе және «сенім деңгейі» (мысалы, телематика қолмен енгізуден жоғары). Қақтығыс болғанда екі мәнді сақтаңыз, бірақ есептеу үшін біреуін алдын ала қабылданған ереже бойынша таңдаңыз.

Құжаттар, хабарламалар және аудит

Құжаттар алмасуын тасымалдаушыға ыңғайлы етіп құрыңыз: рейс карточкасына файл жүктеу, файлдарды e‑mail шлюзі арқылы қабылдау, ал EDI — тек көлем мен талап оправдыса. Канал маңызды емес, бақылау маңызды: міндетті құжат түрлері, оқылымдылық, даталар мен нөмірлер сәйкестігі, анық блоктаулар (мысалы, жеткізу растамасы жоқ кезде рейсті жабуға болмайды).

Хабарламалар белгілі рөлдерге ғана жетсін, «бәріне емес». Әдетте тек ақаулар туралы ескертеді: жүктеу/түсіру терезесіне кешігу, маршруттан ауытқу немесе простай нормадан артық, міндетті құжаттың мерзімге жоқтығы, салмақ/орын немесе мекенжай бойынша сәйкессіздік, толтырылмаған өрістермен рейсті жабуға тырысу.

Және міндетті журнал қажет: кім статусты өзгертті, кім уақытты түзетті, кім файлды алмастырды және бұрын не болған. Өрістер мен құжаттарды версиялау шағымдар мен аудит кезінде өмірді сақтайды. Мысалы, тасымалдаушы POD жүктеген, кейін файлды алмастырған болса, екі нұсқаны, алмастыру уақытын және себебін көру қажет. Әйтпесе «факт» компания ішінде де, қарсы тарап алдында да қорғауға қиын.

Қадамдық әзірлеу жоспары: MVP-ден масштабтауға дейін

TMS әзірлеу жиі кодтан емес, бәрін бірден «жабуға» тырысудан сәтсіздікке ұшырайды. Басқа тәсіл жұмыс істейді: қысқа итерациялар және пайдаланушылар жүйені шынымен қолданатынын тексеру, олар әлі де кестеде ме немесе мессенджерде ме.

Талаптар бойынша таралуын қалай болдырмау

Шынайы жағдайлар тобынан бастаңыз. 10–15 типтік рейсті және сондай-ақ «қолайсыз» сценарийлерді жинаңыз: жүктеудің ауысуы, ішінара жеткізу, машинаны ауыстыру, кешігу, алушының бас тартуы, қосымша нүкте. Бұл оқиғалар статустар моделінің, план‑фактың және құжаттардың тесті болады.

Содан кейін қадамдап жүріңіз, бірақ дайындық критерийлері айқын болсын:

• Сценарийлер мен ерекшеліктерді жазып алыңыз, оларды қадам бойынша ойнауға болатындай (кім, қашан, қандай факт пайда болады және қайда расталады).
• Рейс статус моделін және өтулер ережесін бекітіңіз, кім құқықты, кері қайтару және түзетулер қалай болатынын қосып.
• План‑факті сипаттаңыз: қандай уақыттар мен километрлерді жоспар деп есептейміз, факт қайдан келеді және логисттер мен бухгалтерия қарайтын 3–5 нақты есеп қандай.
• MVP‑ні бір бағыт пен бір тасымалдаушыда іске қосыңыз, ереже айқын және жүйеде жұмыс істеуге мотивация бар жерде.
• Растайтын құжаттарды қосыңыз: міндетті және міндетті емес құжаттар, қалай тексереміз (визуалды немесе деректер бойынша) және қай жағдайда төлем блокталады.

MVP үшін қарапайым мысал: Алматы — Астана бағыты және бір тасымалдаушы. Статустар «жоспарланған», «тағайындалған», «жолда», «жеткізілді», «жабылды» және бір «мәселе» статусы. План‑фактты екі нүкте бойынша (жүктеу және жеткізу) есептеп, құжаттар ретінде тек накладная мен акт жеткілікті.

Қашан масштабтауға болады

MVP-де қолмен айналып өтулер қалмаса масштабтауды бастаңыз: статустар ережелер бойынша өзгереді, план‑факт есептерге сәйкес келеді, құжаттар шынымен жүктеледі және блоктаулар «чаттыласпай» жұмыс істейді. Содан кейін басқа тасымалдаушылар мен филиалдарды қосыңыз: бірыңғай справочниктер (ТС түрлері, құжаттар, ауытқу себептері), рөлдер және минималды SLA — түрлі командалар «фактті» әр түрлі есептемесін үшін.

TMS әзірлеуде типтік қателіктер және олардан қалай аулақ болу

TMS-дегі ең қымбат қателіктер интерфейсте немесе код жылдамдығында емес. Олар деректер мәнінің мағынасында адамдар келіспеген жерден шығады: не факт саналады, кім және қашан ақпаратты өзгерте алады, рейс қандай ережемен жабылады.

1) Статустар тым көп және қолмен басқару көп

Статустары ондап, олардың арасындағы өтулер кез келген бағытта болса, пайдаланушылар «шамамен дұрыс» статусты таңдай бастайды. Соның нәтижесінде бір рейс әр түрлі диспетчерлерде түрлі сценарийде болады, есептер шындықпен сәйкес келмейді.

Схеманы қысқа және бірмәнді ұстаңыз. Жақсы ереже: әр статус бір сұраққа жауап береді және кіріс/шығыс шарттары айқын. Жаңа статус қосқыңыз келсе, алдымен мәселені жеке белгі (мысалы, «құжат күтілуде», «сомаға дау бар») арқылы шешуге болмайтынын тексеріңіз.

2) Факт дереккөзі жоқ немесе дерекке сенім жоқ

Егер «келу фактісі» қайдан алынатыны түсініксіз болса, даулар шексіз болады: жүргізуші бірдей айтады, қойма басқа, бухгалтерия үшінші. Әркім өз құқығында дұрыс.

Алдын‑ала әр факт үшін бастапқы дереккөзді анықтаңыз: тасымалдаушы оқиғасы, нүктедегі қызметкер белгісі, қойма жүйесінің интеграциясы, GPS, құжат сканы. Рейс карточкасында мәннің өзімен қатар «кім/не қойды» және «қашан» деп тіркеңіз. Бұл қақтығыстарды және жағдайларды шешуді азайтады.

3) Құжаттар файл ретінде ғана сақталады

Растайтын құжаттар жай ғана файл ретінде тіркелсе, оларды басқару мүмкін емес: толықтығын тексеру, нұсқаны бақылау, төлем бойынша блоктау қарапайым болмайды.

Құжатты нысан есебінде жасаңыз: түрі (ТТН/CMR/акт/шот), нөмір, дата, тарап, тексеру статусы, кім тексерген, комментарий, байланысқан рейс пен кезең. Файл қалады, бірақ бақылау деректер арқылы жүреді.

4) Құқықтар пен рөлдер бөлінбеген

Көп тасымалдаушы жұмысында тасымалдаушы тіркелген соң кейде қолданбада тым көп өзгерістер жасай алады: жоспар даталарын, километрді немесе бағаларды түзетуге болмауы керек. Кейін «бәрі өздігінен өзгеріп кетті» дейді.

Құқықтарды былай бөліңіз: кім құрастырады, кім өзгеріс ұсынады, кім бекітеді. Қарапайым келісу механикасы енгізіңіз: «өзгеріс сұранысы» тікелей редакцияға қарағанда. Сонымен қатар тарих сақталсын: не өзгертілді, кім және қандай себеппен.

5) Ауытқулар бойынша аналитика жоқ

План‑факт аналитикасы болмаса TMS тез архивке айналады: рейстер жабылған, құжаттар тіркелген, бірақ жүйе қай жерде ақша мен уақыт жоғалып жатқанын көрсетпейді.

Бастапқыдан минималды метрикалар енгізіңіз:

• уақыт бойынша ауытқу (келу/түсіру/рейс жабылуы);
• баға бойынша ауытқу (келісім vs факт);
• қашықтық немесе маршрут бойынша ауытқу (қолданыста болса);
• толық құжаттар жиыны жоқ рейстердің үлесі;
• ауытқулар себептері (қысқа справочник).

Егер осы бес аймақты алдын‑ала жауып қойсаңыз, TMS тек есепке алу кестесі емес, диспетчерлерге, тасымалдаушыларға және қаржы бөліміне сенімді құрал болады.

Бастамас бұрын тез чек‑лист және келесі қадамдар

Экрандар мен интеграцияларға уақыт жұмсамас бұрын негізді тексеріңіз. Көп жобада проблемалар кодтан емес, анықталмаған ережелерден: не факт саналады, рейс қалай жабылады және қандай құжаттар міндетті.

30 минутта өтуге болатын чек‑лист

Төмендегі сұрақтарға жауап беріп, шешімдерді жазып алыңыз. Бұл даулы жағдайлар мен қайта жасауларға апталар үнемдейді.

• Рейс, заказ және құжат статустары бөлінген бе? Егер бәрі бір статусқа тірелсе, нақты не «тұрып қалғанын» түсіну қиын.
• Рейс жабу үшін міндетті оқиғалар анықталған ба (мысалы: шығу, келу, жүктеу басталуы, аяқталу) және оларды кім растайды?
• План‑фактқа бірдей ережелер бар ма: қандай өрістер жоспар саналады, факт қайдан келеді, кешігу үшін бір формула (уақыт белдеулерін және уақытты дөңгелектеуді ескеріп) бар ма?
• Құжаттар расталмаған жағдайда төлем немесе жабу блокталатын ба, және блоктауды кім шешеді, себебін көрсетіп?
• Диспетчер үшін (оператив бақылау) және бухгалтерия үшін (жабу және төлем) екі мысал есеп дайындалды ма? Егер мысалдар жоқ болса, талаптар «айқын» болмайды.

Егер осы сұрақтардың кемінде екісі бойынша нақты жауап болмаса, тоқтап, ережелерді айқындаңыз. Әйтпесе жүйе барлығына таласуға ыңғайлы, бірақ жұмысы қиын болады.

Чек‑листтен кейінгі келесі қадамдар

Ережелер дайын болғанда практикалық қадамдарға көшу керек. Әр қадам өлшенетін нәтиже беруі тиіс.

• Әртүрлі сценарийлерден 10–20 нақты рейс жинаңыз: бір тасымалдаушы және бірнеше, ішінара жеткізу, құжаттардың қайтарылуы, кешігулер. Солар арқылы статустар, план‑факт және жабылуды тексеріңіз.
• Факт көздерін анықтаңыз: қолмен (диспетчер), тасымалдаушыдан, GPS‑тен, қоймадан, ЭДО‑дан. Әр көзге «дерек иесін» тағайындаңыз.
• Инфрақұрылымды шешіңіз: TMS қайда жұмыс істейді (офис, филиалдар), пайдаланушылар саны, шыдамдылық, құжат көлемі. Бұл серверлер мен жұмыс орындарын таңдауға әсер етеді.
• Қолдауды жоспарлаңыз: түнде және демалыста кім жауап береді, интеграцияларды кім түзетеді, справочниктерді кім жаңартады.

Инфрақұрылымды жүктемеге сай таңдау және орналастыруда интегратор көмектесе алады. Мысалы, GSE.kz (gse.kz) жүйелік интегратор ретінде серверлік бөлік пен жұмыс орындарын таңдап, қолдау ұйымдастыруға көмектесе алады, сол арқылы TMS күншоқ күндерде де тоқтамайды.