CRM/ERP-дегі тапсырмалар мен міндеттер: чатсыз модель мен UX

Неліктен CRM/ERP-дегі тапсырмалар чатқа айналады

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

Екінші жиі себеп — карточкаға бәрін бірден салуға тырысу. Міндет, талқылау және жеке ескертпе араласып, комментарийлер ғана не болып жатқаны түсінуге мүмкіндік береді.

Айырмашылық қарапайым:

• Міндет өлшенетін нәтиже береді (файл, сан, расталған факт) және жауапты адам бар.
• Талқылау келісімге келуге қажет, бірақ өздігінен нәтиже жасамайды.
• Ескертпе бір адамға пайдалы және бақылауды қажет етпейді.

Егер бұл заттар бөлінбесе, карточка әмбебап контейнерге айналады да, бәрі ішіне мессенджердегідей сөйлеседі.

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

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

Тапсырманың негізгі моделі: карточкада не сақтау керек

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

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

Әрқашан толтырылуы тиіс минималды өрістер

Негізгі өрістер тапсырманы нақты түрде қоюға мәжбүр етеді:

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

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

Шекаралар: не тапсырма емес

"Сен қалай ойлайсың?", "Жақсартсақ па?" немесе «Кім кінәлі» деген дау сияқты нәрселерді тапсырма ретінде тіркеудің қажеті жоқ. Мұндайлар ескертпеге, талқылауға немесе кіретін сұранымдарға лайық. Тапсырмаға бұл тек өлшенетін нәтиже мен жауапты пайда болғанда ғана айналады.

Мысалы: «S200 серверінің спецификациясын тексеру» — егер жауапты және «спецификация келісіліп, жіберілді» деген критерий болса, онда тапсырма. Ал «Қарап шығып пікір айт» — комментарий немесе бөлек талқылау болғаны жақсы. Интеграторлық жобаларда мұндай шекараларды енгізу регламентінде бекітеді, сонда карточкалар чатқа шашылмайды.

Рөлдер және жауапкершілік: кім не істейді

Тапсырма шексіз нақтылауларға айналмасын десеңіз, онда оның рөлдері мен құқықтары айқын болуы керек. Сонда комментарийлер детальдер туралы ғана болады, ал басқару карточкада қалады.

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

Міндетті рөлдер жиынтығы

Көбіне төрт рөл жеткілікті:

• Постановщик нәтиже мен қабылдау критерийлерін формулировка жасап, контекст береді.
• Орындаушы (жауапты) орындауды жүзеге асырады, жоспарды жаңартып отырады және статусын түзетеді.
• Қабылдаушы (тексеруші) нәтижені растайды немесе қайта жетілдіруге қайтарады.
• Бақылаушылар өзгерістер туралы хабарландыру алады және көріп отырады, бірақ жауап беруге міндетті емес.

Бақылаушылар ақпараттық тапсырмаларда пайдалы: мысалы, жұмыс станцияларын жинауда инженер орындайды, жоба жетекшісі бақылаушы, ал сатып алу бөлімі талқыластарға қатыспай-ақ хабардар болады.

Қайсы адам жабады және қайсысы қайтарады

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

Қайтару да себеппен тіркелетін әрекет болуы керек: қысқа және нақты түрде не қандай критерийге сәйкес келмегенін көрсету.

Орындаушыны ауыстыру кезінде бақылауды жоғалтпау

Ауыстырулар болады (демалыс, ауру, қайта бөлу). Бақылауды жоғалтпау үшін:

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

Мерзімдер ойланбай шатаспаңыз: мерзімдер, ауыстырулар, кешігулер

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

Үш түсінік жеткілікті:

• Бастау күні — орындаушы нақты қашан бастай алады.
• Орындау дедлайні — нәтиже қашан дайын болу керек.
• Тексеру соңғы мерзімі — тексерушінің «қабылданды/қайтарылды» деген шешімді қашан беруі тиіс.

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

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

Кешігуді «+2 күн» сияқты есептегішпен көрсетіңіз. Тексеру мерзімін бөлек есептеңіз. Егер SLA бар болса, оны да тыныш түрде көрсетіңіз: «SLA: тексеруге 24 сағат». Бұл айыптау емес, жоспарлау фактісі.

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

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

Қайталаулар және тұрақты тапсырмалар: дұрыс баптау

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

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

Қашан келесі тапсырманы жасау керек

Екі анық режим бар:

• Жабылуына қарай: ағымдағы тапсырма жабылғаннан кейін ғана келесі пайда болады. Қызмет көрсету және тексерулер үшін қолайлы.
• Күнтізбеге сай: тапсырмалар алдын ала күндер бойынша жасалады. Есептер мен регламенттер үшін жарайды.

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

Мерекелер, демалыстар және ауыстырулар

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

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

Тәуелділіктер: кімді кім күтіп тұрғаны анық болсын

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

Күрделендірмей үш тип байланыс жеткілікті: тапсырма басқаны блоктайды, басқаға тәуелді немесе параллель түрде орындалуы мүмкін.

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

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

Көрнекі түрде де қарапайым болу керек: карточкада және жалпы тапсырмалар тізімінде "кімнен не күтеміз" тізімі. Диаграммалар сирек қажет.

Статустар мен өтулер: жұмыс істейтін минималды жиынтық

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

Көптеген тапсырмалар үшін мына жиынтық жеткілікті:

• Жаңа — тапсырма жасалды, орындаушы әлі бастамаған.
• Жұмыста — орындаушы жұмыс істеп жатыр және келесі қадам үшін жауапты.
• Тексеруде — нәтиже қабылдаушыға берілген.
• Блокталған — сыртқы шартсыз жалғастыру мүмкін емес.
• Орындау аяқталды — нәтиже қабылданды.
• Бас тартылды — тапсырма өзекті емес, себебі тіркелген.

Статустар тек өтулер ережелерімен бірге жұмыс істейді. Мысалы, «Орындау аяқталды» тек «Тексеруде» мәртебесінен кейін ғана пайда болуы керек, «Жұмыста» күйінен тікелей емес.

Практикалық минималды ережелер:

• "Жаңа" -> "Жұмыста" орындаушы тағайындаған кезде.
• "Жұмыста" -> "Тексеруде" орындаушы нәтижені тіркеп өткізгенде.
• "Тексеруде" -> "Орындау аяқталды" қабылдаушының әрекеті.
• "Тексеруде" -> "Жұмыста" тек қайтару себебі көрсетілгенде рұқсат етіледі.
• Кез келген белсенді статус -> "Блокталған" тек блоктаушы көрсетілгенде ғана өтеді.

"Жауапты күту" деген бөлек статус көбіне қажет емес. Егер жауапсыз жұмыс тоқтаса — бұл "Блокталған" болып, кімнен және қашан күтетініңіз тіркеледі.

Қадам-қадам енгізу: CRM/ERP-ге тапсырма схемасын қалай енгізу

Пилоттан бастаңыз: бір команда, бір процесс, 2-3 апта. Пилоттың мақсаты — әдемі карточкалар емес, ережелер: не есептеледі орындалған деп, кім қабылдайды, қалай мерзімдер ауыстырылатыны тіркеледі.

Енгізудің минималды жоспары

Бес қадамдық схема жинап, оны баптаулар мен команда әдеттерінде бекітіңіз:

• Ағысты түрлерге бөліңіз (бір реттік жұмыс, тұрақты тапсырма, келісім, оқиға) және әрқайсысы үшін финал нәтижені алдын ала анықтаңыз.
• Тапсырманы жұмысқа жібермес бұрын міндетті өрістер жасаңыз: орындаушы, күтілетін нәтиже, мерзім, приоритет, ішкі тапсырыс беруші.
• Ескерту жүйесін осылай баптаңыз: дедлайнға дейін хабарландыру, "кешікті" белгілеу, N сағат/күннен кейін қарапайым эскалация.
• Тәуелділіктерді тек шын мәнінде жұмыс тоқтайтын жерде ғана қосыңыз (мысалы, "монтаж" — "жеткізілімнен кейін").
• Қысқа ережелерді бекітіңіз: кім "тексеруге" өткізеді, кім қабылдайды, мерзімді қалай ауыстырады (міндетті себеппен), нәтижені қайда тіркейміз (нәтиже өрісінде, чатта емес).

Практикада "біреуі істейді, басқасы қабылдайды" принципі жақсы жұмыс істейді. Осы кезде орындауды бақылау процесс бөлігін құрайды, жеке хабарламалар жиынтығы емес.

Жиі қателер: жүйе неге бекімейді

Жүйе "отыра" алмайды, егер карточкалар чат секілді өмір сүрсе: көптеген комментарийлер, жіберілген скриншоттар, даулы детальдар, ал нәтиже көрінбейді.

Ең типтік ақаулар:

• Карточкада "Күтілетін нәтиже" жоқ, және барлық постановка чатқа қарай көшеді.
• Статустар тым көп (12-15), адамдар кездейсоқ таңдайды, және статус сигнал болудан кеналады.
• Бір жауапты жоқ: бірнеше "орындаушылар" және нәтижесінде тапсырма ешкімнің емес.
• Кешігулер себепсіз жиналады, және сондықтан әрі қарай не істеу керек анық емес: эскалация, қайта тағайындау, мерзімді келісу.
• Тапсырмалар шешімдер мен кездесулердің орнына қойылады: оншақты "талқылау/анықтау" жасап, бір тапсырмада "бекітілген ТЗ" деген нәтиже болу керек.

Шуды көрсететін белгілер:

• комментарий көп, ал нәтиже (файл, факт, құжат нөмірі) жоқ;
• статус бойынша тексерушіге не істеу керектігі анық емес;
• тапсырмада 2-3 орындаушы және ешқайсысы нақты жауапты емес;
• мерзім ауыстырулар тіркелмейді және түсіндірілмейді;
• "сөйлесеміз" деген тапсырмалар пайда болады.

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

Қысқа чеклист: 2 минут ішінде тапсырма сапасын тексеру

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

• Орындаушы және нәтиже қабылдайтын адам кім екені анық. Егер қабылдау қажет болмаса, бұл да айқын көрсетілген.
• Мерзім нақты көрсетілген (күні мен уақыты), және ол қатты ма әлде жұмсақ па — түсінікті.
• Дайындық критерийі бар: 1-2 қарапайым белгі, қайсы бойынша кез келген тексеруші "иә, жасалды" деп айта алады. Мысалы: "X файлы бойынша есеп, Y кезеңі үшін, Z-мен келісілді".
• Тәуелділіктер нақты сипатталған: "төлемен кейін бастаймыз", "жүйеге қолжетім күтеміз", "дизайнерден макет қажет". Егер параллель жұмыс істесе, тәуелділік қоймаңыз.
• Мерзім ауыстырылған болса, тарихта себеп пен жаңа дата бар.

Мысал: «Оқу аудиториясы үшін 10 ПК сатып алу» тапсырмасы нақты болуы үшін орындаушы (сатып алушы), қабылдаушы (техпаспортист немесе ИТ), қатты дедлайн (семестр басталғанға дейін), дайындық критерийі (жеткізу, актілер, бейнені орнату) және тәуелділік (бекітілген спецификация) болуы тиіс.

Сценарий мысалы: тапсырма сұраудан нәтижеге дейінгі жолы

Мысалы: ИТ-директор жаңа жобаға жұмыс станциялары мен бірнеше сервер сатып алуды сұрайды. Қатысушылар: ИТ, қауіпсіздік, заң бөлімі, сатып алу, қойма және монтаж мердігері. Егер бәрін чат арқылы жүргізсеңіз, апта ішінде не келісілгенін, не іркіліп қалғанын түсіну қиын болады.

Тапсырмамен жұмыс қысқа тізбек ретінде көрінеді:

• ТЗ дайындау (жауапты: ИТ). Нәтиже: ТЗ файлы және модельдер тізімі.
• ТЗ келісу (қауіпсіздік пен заң бөлімі). Нәтиже: келісім белгісі немесе бас тарту себебі.
• Тапсырыс рәсімдеу (сатып алу). Нәтиже: өтініш/келісім нөмірі және таңдалған жабдықтаушы, мысалы GSE.kz жергілікті өндірілген жабдық үшін.
• Жеткізуді қабылдау (қойма + ИТ). Нәтиже: шоты, қабылдау фактісі, ескертпелер.
• Қызметке енгізу (ИТ). Нәтиже: іске қосу актісі, сериялық нөмірлер, орнату орны.

Тәуелділіктер келесі қадам фактіге тәуелді жерде ғана қажет. "Тапсырыс рәсімдеу" ТЗ келісілмейінше блокталады. "Қызметке енгізу" қабылдау жабылмайынша басталмайды. Жеткізуден 2 күн бұрын ИТ-ны ескерту сияқты жұмсақ байланыстарды хабарландыру арқылы шешкен дұрыс.

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

Басшыға талқылау тарихын оқу қажет емес: оған ағымдағы статус пен келесі қадам, жауапты және мерзім, блоктаулар, соңғы расталған факт және ауыстырулар себептерімен жеткілікті.

Келесі қадамдар: процессті бекіту және масштабтау

Бір процесс (мысалы, шотты келісу немесе коммерциялық ұсынысты дайындау) және 1-2 командаға пилоттан бастаңыз. Барлық ережелерді бірден өзгерткен дұрыс емес: 2-3 аптада қай жерде адамдар шатасатыны және не шынымен көмектесетінін түсінесіз.

Ереже қысқа, бір беттік ескертпеде бекітіңіз: не тапсырма есептеледі, дедлайн қашан қойылады, кім нәтиже қабылдайды, қалай мерзімді ауыстырамыз және нәтижені қайда тіркейміз. Оқыту нақты кейстерге негізделгені жақсы: пилоттан 3-5 тапсырманы алып, не жақсы, не кедергі екенін бірге талдаңыз.

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

Келесі кезеңде CRM/ERP баптаулары жеткілікті ме әлде доработка керек пе — соны түсінесіз. Көбінесе рөлдер мен құқықтар (кім мерзімді ауыстыра алады, кім жаба алады), хабарландырулар, есептер және интеграциялар (почта, күнтізбе, сервис-деск, құжат айналымы) жетіспейді.

Егер процесті жылдам бекіткіңіз келсе, сыртқы контур көмектеседі: CRM/ERP-ні регламентпен және тұрақты жұмыс үшін инфрақұрылыммен (серверлер, жұмыс орындары, қолдау) баптау. Мұндай форматта GSE.kz (gse.kz) жүйелік интегратор ретінде пайдалы болуы мүмкін: CRM/ERP енгізу мен қызмет көрсетуден бастап, инфрақұрылымға дейін көмектеседі.