Система тікетів виглядає доречно лише на папері. Ви отримуєте цифри, черги, дашборди. Але насправді ця модель вимірює біль лише тоді, коли система вже дала збій. Найдорожча частина проблеми зазвичай виникає значно раніше. Все починається, коли працівник втрачає 10 хвилин, потім 20, а зрештою просто здається. Вони пробують знову. Вони запитують колегу. Вони пропускають зустріч або діляться не тим файлом, бо правильний шлях перестав працювати. І це та частина, яку більшість команд підтримки досі не бачать. Найкраща сучасна модель внутрішньої підтримки – це не швидше сортування тікетів. Це повне усунення потреби в сортуванні. Уявіть автономного агента в Microsoft 365, який стежить за контекстом, вчасно помічає перешкоди і діє до того, як людина взагалі подумає відкрити портал. У цьому епізоді я хочу показати вам, чому модель служби підтримки ламається, що приходить її на зміну і як нею керувати, не створюючи хаосу.

Якщо цей сув важливий для вашої роботи, підпишіться на M365FM, бо якщо копнути глибше, справжня проблема не в черзі, а в моделі, що стоїть за нею. Смерть тікета. Старий потік підтримки досі повсюди. Щось ламається. Користувач помічає це. Користувач намагається це пояснити. Потім IT перекладає це пояснення у категорію, пріоритет і, можливо, групу призначення. Проблема потрапляє в чергу. Хтось її сортує. Хтось інший запитує деталі. Долучається інша команда. Час йде, а реальна робота стоїть на місці. Цей процес здається нормальним, бо він знайомий, але знайомий і ефективне. Це не одне й те саме. Тікет – це не підтримка. Тікет – це доказ того, що підтримка запізнилася. До моменту створення тікета працівник уже зіткнувся з труднощами і втратив контекст. Вони вже відволіклися від роботи, яку намагалися виконати. Черга – це не сервіс. Черга – це запис про несправність. У великих середовищах Microsoft 365 ручне сортування стає справжнім вузьким місцем.

Це відбувається не тому, що команди підтримки ліниві. Це відбувається тому, що від людей вимагають робити те, що вже не відповідає масштабам середовища. У вас більше користувачів, більше пристроїв, більше застосунків, більше політик. У вас більше виняткових випадків, що перетинають команди SharePoint Exchange, Intune та Entra одночасно. Обсяг не просто зростає. Зростає кількість комбінацій. Ось де ламається стара модель. Більшість команд реагують на це додаванням структури. Вони будують ще один портал, ще одного бота чи ще одне правило маршрутизації. Але насправді це лише додає ще один рівень між працівником і розв'язанням проблеми. Система досі чекає, поки користувач помітить проблему, опише її та попросить допомоги у правильний спосіб. Робота починається не на порталі підтримки, вона починається в Teams, в Outlook, у документи, який потрібен прямо зараз або на зустрічі, що розпочнеться за 30 секунд.

Саме там насправді виникає потреба в підтримці, а модель тікетів повністю відірвана від того моменту. Приховані витрати значно більші, ніж показують ваші звіти про черги. Люди постійно перемикаються між контекстами. Дублювані інциденти накопичуються під різними мітками. Бази знань старіють. Аналітики витрачають весь день на сортування, маршрутизацію та уточнення замість того, щоб реально вирішувати проблеми. Час вирішення розтягується, бо кожна передача завдання додає затримку, а кожна затримка позбавляє справу початкового контексту. Дослідження агентного щі та IT-операції вказують на ту саму структурну проблему. Принаймні 80% зусиль досі заблоковані в реактивній роботі за моделю ITIL. Це число важливе, бо воно точно показує, куди спрямовуються ресурси. Вони йдуть не на стійкість чи запобігання, вони йдуть на реагування. Як тільки ви це побачите, тікет почне виглядати не як модель роботи, а як симптом.

Це симптом системи, яка реагує лише тоді, коли збитки вже очевидні. Тож наступне питання не в тому, як швидше обробляти тікети, а в тому, що система має робити до того, як тікет взагалі знадобиться. Модель невидимого працівника. Отже, що насправді замінює тікет? Це не просто черговий чат-бот поверх того самого безладу, і це точно не гарніші двері до тієї ж самої старої черги. Зміна набагато глибша, бо невидимий працівник – це оперативний співробітник, який живе всередині вашого середовища Microsoft 365. Цей агент має власну ідентичність, визначений обсяг роботи, пам'ять про те, що він робив учора,

Чат-бот чекає, поки ви введете запит, а невидимий працівник стежить за зміною умов. Він починає з контексту, а не з розмови. Оскільки він бачить стани входу, стан пристроїв, статус ліцензії та те, як надається доступ до файлів, йому не потрібно чекати, поки виникне перешкода. Замість того, щоб питати, чим він може допомогти після поломки, він постійно ставить у фоновому режимі інше питання, що відхиляється від стану, необхідного цьому працівнику для виконання своєї роботи прямо зараз. Саме тут все змінюється. Модель вбудована безпосередньо в саму роботу. Коли хтось приєднується до зустрічі і аудіо не працює, або гість не може відкрити файл, який йому щойно надіслали, старий світ створює звіт і передає задачу далі. У новій моделі агент миттєво розпізнає шаблон, перевіряє, чи відповідає умова відомій проблемі і вживає наступних безпечних дій для її виправлення. Можливо, він скидає шлях або ініціює перевірку політик, або перенаправляє запит і вимагає багатофакторну автентифікацію перед документуванням виправлення.

Суть проста. Перша відповідь більше не потребує людини, яка мала б читати розплив частий опис і вгадувати, що сталося. Це непомітно. Коли все працює добре, бо немає кімнати очікування чи форми, будь ласка, виберіть категорію, яку треба заповнювати. Підтримка проявляється як відновлений робочий процес. Співробітник просто повертається до роботи і в багатьох випадках він навіть не бачить механізмів, що працюють за лаштунками. Ви вже бачите, як це змінює логіку формування вашого штату. Стара модель передбачає наймання людей для обробки обсягів, сортування запитів та виправлення розірваних контекстів між різними командами. Нова модель потребує менше людей для сортування та більше тих, хто створює захисні механізми, визначає бажані стани та контролює поведінку агентів з часом. Люди залишаються в системі, але сама форма їхньої щоденної роботи змінюється. Дослідження агентного щі в підтримці продовжують вказувати на цей напрямок.

Рутинна підтримка може перейти до обробки на основі винятків, що забезпечує значне підвищення ефективності, коли середовище та політики чітко обмежені. Ця остання частина є життєво важливою, тому що це не магія. Якщо ваші дані слабкі або процеси заплутані, агент не стане розумним лише тому, що ви вирішили назвати його автономним. У мене все склалося в єдину картину, коли я перестав думати про агента як про функцію ПЕЗе і почав розглядати його як нелюдського працівника з перепусткою. Справжньому працівнику потрібні ідентифікація, посадова інструкція, права доступу та керівник, якому він звітує. Агенту потрібні рівно ті самі речі, оскільки цінність полягає в надійних діях у середині системи, а не в розумних фразах у вікні чату. Цей невидимий працівник – не просто фокус інтерфейсу. Це новий рівень підтримки, який стежить за проблемами в екосистемі Microsoft 365, діє в межах політик і спрямовує увагу людини на винятки, що дійсно потребують судження.

Коли ця модель стає зрозумілою, наступне питання стає дуже практичним. Як насправді працює превентивність? Архітектура превентивності. Отже, як насправді працює превентивність у Microsoft 365? Відбувається перехід від запиту та відповіді до аналізу подій та оркестрації. Це звучить технічно, але модель проста, як тільки ви її розберете. Спочатку щось змінюється в середовищі, потім система інтерпретує, чи означається зміна ризик або відхилення, і зрештою вживає схвалених дій, використовуючи наявні у вашому стеку інструменти. Почніть із рівня подій. Microsoft 365 вже генерує сигнали всюди, Entra бачить поведінку під час входу, а Intune відстежує стан і відповідність пристрою. DaFenda стежить за підозвілою активністю, а Teams точно показує, коли зустріч зривається або погіршується якість зв'язку. SharePoint та Exchange виявляють схеми доступу та активність із вмістом, а сигнали про стан служб підказують, коли проблема в самій платформі.

Коли ви додаєте до цього дії користувачів, ви отримуєте постійний потік контексту. Більшість організацій збирають ці сигнали, але дуже мало хто використовує їх як систему підтримки. Сері події самі по собі не допомагають, бо їм потрібен рівень логічного аналізу, щоб розібратися в цьому шумі. Саме тут невидимий працівник перестає бути імітацією автоматизації і починає діяти як справжній оператор. Агент аналізує сигнал, порівнює поточний стан із бажаним і вирішує, які дії безпечно вжити. Проблема зі звуком на зустрічі – це не те саме, що ризикований вхід, а не працююче посилання для спільного доступу відрізняється від невідповідності ліцензій. Агент має спочатку класифікувати проблему, бо в життя заходів без класифікації лише пришвидшує припускання помилок. Потім настає оркестрація. Щойно агент розуміє проблему, він може використати потрібний механізм для реагування. Це може бути Pava Otamate для робочих процесів, Co-Pilot Studio для логіки або Microsoft Graph для системних дій та контексту.

Інструменти важливі, але головне, як вони взаємодіють між собою. Ви будуєте не один розумний запит, а цілий ланцюжок, здатний виявляти, вирішувати, діяти та перевіряти. Цю останню частину постійно випускають з уваги. Система самокоригування не зупиняється після виконання дії. Вона запускає цикл, виявляє проблему, перевіряє умови, застосовує виправлення та підтверджує результат, перш ніж записати, що сталося. Дослідження логіки самокоригування чітко показують, що ці системи працюють через зворотний зв'язок та моделі виправлень, а не через одну окрему відповідь мовної моделі. Якщо перша дія виявилася невдалою, системі потрібен спосіб оцінити причину, щоб переглянути наступний крок, залишаючись у визначених межах. Це можна чітко уявити на прикладах із Microsoft 365. Коли користувача блокують через невідповідність ліцензії та політики, агент виявляє це і перевіряє цільовий профіль ролі. Він застосовує дозволене виправлення, підтверджує наявність доступу у користувача та реєструє зміни безсторонньої допомоги.

Якщо вент раз'являється ризикований вхід, агент бачить подію ризику та негайно перевіряє ваші правила умовного доступу. Він запитує додаткову перевірку або блокує доступ згідно з вашою політикою, а потім фіксує результат для подальшого огляду людиною. Коли застаріле посилання для спільного доступу постійно видає помилку, в SharePoint агент порівнює поточний шлях до дозволів із очікуваними правилами доступу. Він замінює пошкоджений корінь на правильний і надсилає виправлене посилання в контексті, що закриває питання ще до того, як аналітик техпідтримки прочитає тікет із заголовком «Термінова проблема з доступом». Підтримка на рад – ще один чудовий приклад. Якщо пристрій у кімнаті виходить із ладу або шлях підключення переривається за секунди до початку дзвінка, агент може виявити цю проблему та перевірити збій. Він виконує кроки для відновлення з низьким рівнем ризику та сповіщає організатора в Teams з оновленням статусу саме там, де відбувається робота.

Цей рівень комунікації є величезною частиною дизайну. Підтримка має бути там, де виникає перерва в роботі. Якщо ваша робота відбувається в Teams, Outlook та робочому просторі М365, то підтримка має відповідати вам також там. Вам не варто перенаправляти користувача кудись інде, якщо можна вирішити проблему в контексті події. Це не означає повну автоматизацію всіх завдань, адже це було б необачно. Дії з низьким ризиком можуть виконуватися автоматично, але для серйозних змін усе ще потрібне схвалення людини. Цей шлях схвалення має бути частиною архітектури від самого початку, а не додаватися згодом. Агент повинен знати, коли діяти, коли запитати і чітко знати, коли зупинитися. І як тільки ви впровадите це у робочий процес, розмова перестане стосуватися лише функцій автоматизації. Вона стане розмовою про контроль, управління, довіру та ідентичність агента. Коли підтримка починає діяти самостійно, негайно виникає складне питання.

Хто насправді виконує цю роботу? Якщо відповідь на нього розмита, уся модель руйнується. Агент не може існувати у вашому середовищі як незрозумілий помічник із широким доступом і без чіткого власника. Він потребує реальної ідентичності Вентра. Він потребує визначеного власника, окресленої сфери дії та життєвого циклу, що має чітку причину для початку та завершення. Якщо цей агент може читати дані, запускати робочі процеси або надсилати повідомлення користувачам, ви повинні керувати ним як активним учасником орендаря Тенан. Ви не можете ставитися до цього як до функції, яку хтось увімкнув і забув. Ось чому ідентичність агента є такою критичною для системи. Ви повинні точно знати, що це за агент, до яких систем він має доступ і хто отримає сповіщення, якщо все почне виходити з ладу. Принцип найменших привілеїв має бути тут базовим стандартом. Не можна погоджуватися на надмірну зручність або тішити себе думкою, що ви обмежите дозволи пізніше.

Оскільки зона впливу агента підтримки повністю залежить від його дозволів, проєктовання цих дозволів є основною частиною побудови системи підтримки. Agent 365 служить необхідним рівнем контролю в цій системі, оскільки забезпечує повновидимість усього середовища агентів. Він надає реєстр, робочі процеси затвердження та шаблони політик, що гарантують безпечну роботу. Хоча ці елементи можуть здаватися адміністративною рутиною, вони вирішують величезну структурну проблему. Більшість організацій мають труднощі не через брак функцій ЩІ, а через неможливість бачити або контролювати те, що вже працює в їхньому середовищі. Дослідження щодо цього питання прямолінійні. Лише невелика меншість великих підприємств можуть повністю інвентаризувати всіх агентів, що зараз працюють у їхній системі. Перш ніж керівники почнуть говорити про масштабування автономної підтримки, вони мають відповісти на значно простіше питання.

Чи взагалі ми знаємо, які агенти існують і що вони роблять прямо зараз? Нагляд також має відповідати рівню ризику. Персональний агент продуктивності, що працює у вузькій сфері – це одне, а агент для спільної роботи, що взаємодіє зі спільним контентом – зовсім інше. Крім того, є корпоративні агенти, які діють у чутливих робочих процесах, що належать до іншої категорії ризику. Ось чому модель зон ризику – персональна, спільна та корпоративна – має таке велике значення. Ваша модель контролю повинна посилюватися відповідно до можливого впливу. Якщо ви ставитеся до всіх агентів однаково, низькоризикова робота потоне в повільних погодженнях, а високоризикова просле з небезналежного нагляду. Щонайменше, ваш стек контролю в Microsoft 365 має виглядати знайомим для вашої команди. Ви використовуєте ідентифікацію вентра, межі даних через перв'ю та моніторинг через дафенда. Ви застосовуєте умови доступу через умовний доступ і забезпечуєте можливість аудиту з самого початку.

Ви повинні мати можливість відтворити все, що сталося, не вдаючись до здогадок після виникнення інциденту. Людський нагляд має бути закладений у логіку, а не імпровізуватися під час кризи. Дії з високим рівнем впливу завжди повинні вимагати підтвердження людиною. Обґрунтування має реєструватися у формі, яку люди можуть реально перевірити та зрозуміти. Шляхи відкату повинні існувати ще до того, як запрацює перша автономна дія. Якщо агент оновлює доступ або змінює політику маршрутизації, хтось повинен мати змогу відстежити це рішення та чітко скасувати його. Існує ще один фактор, який керівники часто пропускають, тому що ранні демонстрації виглядають дуже привабливо. Вартість переробки Якщо агент створює цикли виправлень для вашої команди, прогнозована економія миттєво зникає. Це податок на переробку. Це час, витрачений на виправлення невдалих результатів, скасування неправильних дій або усунення небажаних побічних ефектів.

Якщо ваша команда економить 10 хвилин на виконанні, але витрачає 8 хвилин на прибирання безладу, ви насправді не автоматизували підтримку. Ви просто перемістили труднощі на іншу частину процесу. Довіра не виникає завдяки гарним презентаціям із політиками чи гучним анонсам. Вона виникає завдяки доказам під час роботи. Людям важливо бачити, що саме бачив агент, які рішення він ухвалив і що реально змінилося в системі. Саме так будується довіра до автономної підтримки. Докази мають базуватися на поведінці інструменту, а не на брендингу проєкту. Коли фундамент управління стає міцним, розмова нарешті переходить від безпекового жаргону до мови керівників. Що це насправді змінює для фінансових результатів? Новий показник ROI для невидимої підтримки. Коли лідери приймають модель контролю, фінансові питання починають змінюватися. У старій моделі цінність підтримки вимірюється видимою роботою, закритими тікетами, обробленими дзвінками та дотриманнями селей.

Ці цифри все ще важливі, але вони лише описують реакцію на проблему. Вони не показують, скільки збоїв не дійшло до черги і скільки часу співробітників було збережено завдяки ранньому усуненню проблеми. Це ключова проблема обліку. Невидима підтримка створює цінність завдяки своїй відсутності. Ви бачите цінність тоді, коли немає тікета, ескалації та аналітика, який витрачає 20 хвилин на відновлення проблеми з неповних нотаток. Якщо вимірювати лише видимі зусилля команди підтримки, ви втрачаєте результат, якого насправді прагнули. Ви прагнули стабільної роботи з меншою кількістю переривань. Обсяг тікетів – це слабкий сигнал, якщо розглядати його окремо. Зменшення кількості тікетів може означати падіння попиту, але також те, що середовище стало здоровішим, а рівень підтримки – розумнішим. Це дві зовсім різні історії. Керівникам потрібен набір KPI, який дозволяє відрізнити одне від іншого. Вам варто почати з оцінки рівня автономного вирішення запитів.

Це не про кількість розмов бота, а про те, скільки запитів було вирішено від початку до кінця без втручання людини. Вам також потрібно відстежувати скорочення середнього часу вирішення. У середовищах на базі ЩІ-процеси, де важлива діагностика, часто покращується на від 40 до 60%. Потім можна оцінити вартість одного вирішення та відновлену продуктивність користувачів. Останній показник легко пропустити, оскільки він не вписується у стандартний звіт сервісної служби. Проте саме там часто криється справжня цінність. Людина, яка заблокована на 15 хвилин ще до відкриття тікета, вже створила збитки для компанії. Якщо помножити це на переривання зустрічей та проблеми з доступом у великій організації, приховані втрати значно перевищують показники черги. Ось чому модель вартості бездіяльності така важлива для бізнес-кейсу. Ви розраховуєте години, витрачені наручну працю ще до того, як розпочинається формальна підтримка.

Потім додайте вартість помилок і повторної роботи. Раптом аргумент на користь превентивних заходів перестає звучати як теорія. Ви фінансуєте не просто футуристичний рівень підтримки. Ви усуваєте податок, який роками був частиною вашої щоденної роботи. Економіка вузьких кейсів робить це ще очевиднішим. Дослідження агентної ІТ-підтримки оцінюють обробку людиною приблизно у вісьмох доларів США і 75 центів за запит. Натомість вузька агентна обробка може коштувати менше, ніж 50 центів після розробки системи. Це не означає, що кожна дія підтримки буде такою дешевою і керівникам варто бути обережними із загальними середніми показниками. Якість телеметрії та управління завжди впливатимуть на кінцеву вартість, але напрямок тренду є беззаперечним. Це момент, коли ІТ виходить із застарілого образу центру витрат. Це відбувається не тому, що підтримка зникає, а тому, що вона стає рівнем надійності, який захищає продуктивність працівників у фоновому режимі.

Бізнес відчуває це як більш плавний робочий процес, а не як драматичну подію в підтримці. Ви отримуєте менше перерв, швидше відновлення та менше витраченого часу на маршрутизацію та уточнення. Все ж таки, погані вимірювання можуть легко створити ілюзію прогресу. Якщо ваша телеметрія слабка, агент може просто швидше підсумувати збій замість того, щоб реально його запобігти. Якщо переробка залишається поза межами звітності, ROI виглядатиме набагато кращим, ніж є насправді. Якщо повернений час знову витрачається на низьковартісні завдання, керівники перебільшать досягнення. Фінансове обґрунтування має базуватися на твердих доказах, як-от запобігання інцидентам та зменшення ручного втручання. Ви повинні вимірювати час, реально повернути й до корисної роботи. Коли ви вимірюєте це належним чином, функція підтримки перестає виглядати як накладні витрати, які треба скорочувати. Вона починає виглядати як операційна потужність, яку бізнес нарешті повертає собі.

Що це означає для команди підтримки? Подумайте, що це насправді дає команді на місцях, адже ця зміна не про скорочення штату, а про зміну того, чим люди займаються протягом дня. У старій системі більшість потужностей підтримки витрачається на скидання паролів, маршрути зацію тікетів і нескінченні уточнення. Ваші люди ганяються за оновленнями та переносять дані між системами, які ніколи не були розраховані на взаємодію. Жодна з цих робіт не робить середовище стабільнішим, вона лише запобігає переповненню черги. Коли агенти перебирають цю передбачувану рутинну роботу, людські зусилля нарешті переходять на новий рівень. Інженери підтримки починають витрачати свій час на визначення стану стабільної роботи та налаштування логіки схвалень. Вони зосереджуються на вдосконаленні баз знань, тестуванні політик і забезпеченні того, щоб агент діяв у встановлених межах. Це зовсім інша робота, ніж цілий день вдивлятися в теми листів, намагаючись вгадати, чого насправді хоче користувач.

Саме тут більшість впроваджень і зупиняється. Організації намагаються зберегти свої старі зламані процеси, просто додаючи агента зверху в очікуванні кращого результату. Але процес залишається реактивним, передача завдань не чіткою, а базова база знань – слабкою. Агент стає просто ще одним шаром фарби на стіні, що руйнується. Він може швидше відповісти на запитання, але не виправить модель підтримки, побудовано на затримках. Кращий шлях – спочатку перепроєктувати саму роботу. Ви повинні визначити, які завдання залишаться за людьми, бо вони потребують суджень або чутливого спілкування. Потім ви вирішуєте, яка робота переходить в автономні потоки, оскільки результат передбачуваний, а дії безпечні. Цей поділ життєво важливий, адже команди підтримки нікуди не зникають. Вони просто стають людьми, які розробляють засоби контролю та обробляють винятки. Це означає, що спосіб навчання персоналу також має змінитися.

Команди мають навчитися наглядати за системою, а не просто виконувати ручне завдання. Їм потрібно розуміти логіку відкату, аудиторські перевірки та як тестувати агента перед запуском. Вони також повинні вміти помічати, коли модель дає збій, адже автоматизований поганий робочий процес – це все ще поганий процес. Він просто ламає все швидше. Якщо ви наймаєте людей для цього майбутнього, вам, ймовірно, не потрібен черговий універсальний спеціаліст для сортування тікетів. Вам потрібен той, хто зможе оркеструвати потоки в стеку Microsoft 365 і визначати засоби контролю, які стримують агентів. Вам потрібні люди, які можуть покращити середовище, щоб попит на підтримку падав, а не накопичувався. Отже, як насправді почати це, щоб не перетворити все на масивний багаторічний проєкт трансформації? Найкращий крок – обрати один потік, що викликає постійні тертя у вашому середовищі Microsoft 365. Відновлення доступу зазвичай є чудовим кандидатом, але ви також можете розглянути підтримку на рад або передачу відповідності пристроїв.

Неважливо, що ви оберете, головне, щоб цей шаблон повторювався часто і ви точно знали, як має виглядати успішний результат. Маючи ціль, ви повинні визначити основи з реальною дисципліною. Вам потрібно знати, як виглядає нормальний стан і які саме події свідчать про відхилення від курсу. Вирішіть, які дії безпечно автоматизувати і де саме має починатися залучення людини. Перш ніж запускати щось у роботу, переконайтеся, що у вас є базові показники кількості тікетів, ручних операцій та часу очікування користувачів на виправлення. Ви також повинні впровадити управління з першого ж дня. Надайте агенту конкретну ідентичність, призначте відповідальну людину та встановіть чіткі правила затвердження. Кожна дія, яку виконує агент, має фіксуватися в журналі. Також слід мати план на випадок відключення чи перепризначення агента, щоб він не перетворився на автоматизацію привид. Коли цей перший робочий процес запрацює, уся ваша операційна модель почне змінюватися.

Підтримка перестане діяти як стіл реєстрації, що просто реагує на проблеми. Натомість вона почне працювати як механізм надійності, вбудований безпосередньо в систему. Підтримка переходить від помітної реакції до вбудованого запобігання. Тікет ніколи не був самою послугою. Це було доказом того, що послуга надійшла занадто пізно. Оберіть один процес підтримки цього кварталу та переробіть його для попередження проблем, а не відповіді на них. Якщо хочете дізнатися більше про M365 Co-Pilot, Azure, безпеку та моделі роботи з іщі, підписуйтесь на M365FM і залишайте відгуки. Зв'яжіться зі мною, Мірко Пітером, у LinkedIn і запропонуйте наступну тему для розбору.