Проста автоматизація процесу керування актами про шлюб на SharePoint з прикладами і картинками

Вступ

Ця стаття орієнтована на тих, у кого є SharePoint і хто не знає, що з ним робити. :)

Багато скрізь говорять про бізнес-процесі, але мало хто розуміє під цим дійсно процесний підхід, швидше уявляють собі деякий чорний ящик, де, в кращому випадку, є вхід і вихід, іноді навіть структурований – визначено, що маємо на вході і на виході. Фактично, якщо в ящику відповідають за процес більше двох осіб — легкий хаос вам забезпечений, а із зростанням кількості залучених забезпечений і експонентний зростання ентропії. :)

Процес управління організацією — це сукупність дій, повторюваних у часі, з певним початком і кінцем, метою яких є створення цінності для зовнішніх і внутрішніх клієнтів. По суті – перетворення ресурсів на вході в продукт на виході, продукт може бути будь – як матеріальних, так і невідчутним знанням. Перетворення в ящику може бути гранично простим, не вимагає декомпозиції, а може бути дуже складним, вовлекающим в роботу багато співробітників і часу, мають безліч умов і залежностей. Питання рівня декомпозиції процесу лежить в площині раціональності, доцільності і здорового глузду, мені подобається методологічний принцип «Бритва Оккама», який свідчить, що «Не слід залучати нові сутності без крайньої на те необхідності», там, де можна обійтися без формалізації дії — формалізовивать дія не варто. :)


Суть справи

Легке занурення в теорію закінчилося, повернемося до нашого кейсу. Є у нас виробниче підприємство, яке, як і всі інші, крім основного продукту, виробляє шлюб, куди без нього. Та є на підприємстві Відділ якості (ОК), мета існування якого — шлюб фіксувати, сприяти усуненню, всіляко запобігати і припиняти. Так, що там Відділ якості, ціла Система менеджменту якості (СМЯ), впроваджена на підприємстві, відповідна і сертифікована за стандартами ISO 9001. Здавалося б, ОК є, СМК є, на папері всі процеси прописані, все відповідає міжнародному рівню, працюй — не хочу!

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

Що робити?

— А давайте замість паперових журналів зробимо акти електронними, створимо послідовний процес роботи над актом?
— Давайте!
— У нас є SharePoint, адже він підійде?
— Звичайно!
— Весь процес у нас вже описаний, треба тільки перенести.
— Запросто!
Як бачите, рішення знайшлося швидко і робота закипіла.

Документація!

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

Реінжиніринг!

Ще один момент – не варто повністю покладатися на компетенції власника процесу і чекати, що він стане вашим головним консультантом. Головним вашим консультантом повинен стати ваш здоровий глузд і тільки. Всі дії процесу, всі залежності і умови варто піддавати сумніву – задавати питання «Навіщо?», «Чим це обумовлено?», «Ми можемо від цього відмовитися?». Чим простіше вийде ваш процес – тим більше у нього шансів запуститися і залишитися працездатним в організаційному плані. Також ймовірно, що процесу доведеться трансформуватися з урахуванням технічних особливостей обраної платформи автоматизації. Ваше завдання оптимізувати процес, зробити його максимально человеконезависимым, прозорим, керованим і обмеженим у часі для досягнення максимальної ефективності. Це і називається реінжиніринг. «Бритва Оккама» вам в допомогу!

Поїхали!

Вивчивши процес управління актами про шлюб, описаний у ЗМК та вивчивши процес фізичний, стало зрозуміло, що все не так просто. 
Процес описаний досить бідно і загальними словами, а фізично він виявився дуже складний – на кожному кроці нове умова «ЯКЩО», і кожен новий крок тягне за собою нові залежності.

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

Таких моментів було чимало, попутно про всі зміни ми інформували всіх залучених в процес учасників, і, напевно, після десятого варіанта процесу, ми з власником і спонсором вирішили, що все готово, кінцевий варіант, можна доробляти і запускати.
Вирішили зібрати нараду, запросивши всіх залучених, щоб розповісти та продемонструвати, пройшовшись по всім стадіям, як новий процес буде працювати, де і чия відповідальність. І тут же з'ясували з юрисконсультом, що дуже бажано стадію обробки претензії до постачальника за актом вхідного контролю контролювати і, в разі відмови або часткового відмови, у разі закінчення виділеного терміну – залучати до роботи юрисконсульта залучати тільки в цьому випадку, тому що в інших випадках, обробка претензії – абсолютно рядовий процес. І одразу ж з'ясували, що стадія обробки претензії після переговорів з постачальником може змінити рішення по акту з повернення постачальнику на, припустимо, корекцію своїми силами з частковим відшкодуванням витрат постачальником. Різні дрібниці також були враховані, навроде, вимог і побажань бухгалтерії по друкованій формі акта і живим підписам, побажань головного інженера з автоматичного створення претензії.

То одинадцята, то дванадцята версія виявилася завершальній і ще одну нараду її повністю схвалив. До речі, без схеми ваші наради були б нудними – присутні вас просто не зрозуміли б, покивали б і погодилися, мовляв, «Давайте, робіть, а там видно буде».

Нудна технічна частина

Розповім трохи про те, як процес технічно реалізований.
У вузлі SharePoint створені списки, які використовуються в якості журналів або довідників. Зв'язку між ними забезпечені шляхом використання стовпців підстановки і робочих процесів.

За допомогою SharePoint Designer доопрацьовані стандартні форми і створені нові, наприклад, акумуляція зв'язкових даних у формі перегляду акта про шлюб, друкована форма акта або друкована форма претензії постачальнику.
Кастомізація відображення форм – питання великий і рішень має таке ж безліч. Наприклад, можна просто приховувати певні поля в різних формах параметрами ShowInDisplayForm, ShowInEditForm, ShowInNewForm. Програм для налаштування параметрів багато – наприклад, SharePoint Manager. Для зручності якісь поля можна відобразити в формі редагування, але присвоїти елементу атрибут Disabled допомогою простого Javascript. Взагалі, Javascript завжди рятує, наприклад, потрібно створити коментар, перебуваючи в картці перегляду договору, або виконання за службовою запискою, натискаєте кнопку «Створити», в якій передаєте ID поточного елемента у форму створення нового елемента. Скриптом забираєте ID і вибираєте потрібне значення елемента Input.
Також можна створити з нуля будь-які форми в SharePoint Designer, а комусь може сподобатися InfoPath.
У 2007 і 2010 версіях можна використовувати розширення Office Toolbox, де просто і зручно все налаштовується галочками, у тому числі поле можна відобразити в формі редагування, але Read Only.

Робочі процеси (Workflow) створені за допомогою SharePoint Designer. Робочі процеси забезпечують як сам бізнес-процес, так і узгодженість даних у деяких випадках.
У 2007 версії SharePoint іноді допомагають Useful Sharepoint Designer Custom Workflow Activities, наприклад, коли після редагування потрібно залишити права тільки для читання елемента. У 2010-2013 версіях таких проблем немає – все є з коробки, взагалі, у свіжих версіях наявність кроку уособлення дещо змінює підхід до проектування логіки процесів – значно спрощуючи.
Обмеження стадій за часом організовано шляхом створення додаткового робочого процесу з таймером, який чекає відведений час і після закінчення його перевіряє заповнення необхідних полів. Якщо все погано, встановлює Відхилення одно Так» і надсилає повідомлення всім зацікавленим особам. Для кращої візуалізації можна додати поле типу гіперпосилання в яке записувати посилання на стандартні картинки-індикатори, наприклад, створене, вимагає реакції – жовтий значок, своєчасно заповнений елемент – зелений, і відхилення – відповідно, червоний.

Процес готовий!

Ось так виглядає наша документація, яка наказом введено в дію:

Схема процесу роботи з актами про шлюб
image

Регламент роботи з актами про шлюб
Повний текст

Регламент роботи з актами про шлюб



Терміни та визначення
Контролер – особа, відповідальна за перевірку якості прийнятої у провадження та постачальників готової продукції, матеріалів, сировини (контролер або керівник відділу якості).
Економіст – особа, відповідальна за планування і фактичну калькуляцію матеріальних і трудових витрат (економіст-нормувальник або керівник фінансово-економічного відділу).
Техвідділ – особа, відповідальна за конструкторську і технологічну підготовку виробництва (Головний конструктор, Головний технолог або заступник).
Бухгалтер – особа, відповідальна за облік виробничих витрат і розрахунок заробітної плати (бухгалтер з виробництва, собівартості, зарплати або Головний бухгалтер).
Головний інженер – особа, яка має право підпису документів, за його відсутності – особа, яка виконує обов'язки головного інженера.
Список – електронна таблиця (журнал), має стовпці, де кожен рядок (запис) являє собою окремий елемент.
Елемент списку – рядок списку, що має унікальний ідентифікатор, яка може містити вкладення документів, мати розмежовані права доступу користувачів, запускати робочі процеси.
Робочий процес (РП) – програма, яка визначає логіку дій і виконується автоматично при настанні певних подій, таких як, створення або редагування елемента/документа в списку, настання певної дати.

Загальна інформація
Для організації процесу управління електронними актами про шлюб використовуються списки сайту «Відділ якості» порталу підприємства, що знаходиться за адресою portal.domain.ru/SiteDirectory/quality
Списки можна представити як паперові журнали реєстрації, де є рядки та поля для заповнення, кожен рядок – це унікальна запис, що має атрибути. Відмінність полягає в тому, що запис в електронному списку може мати вкладення, запускати робочі процеси для автоматизації дій, наприклад, відправити повідомлення, змінити будь-яке значення, записи у списку можна динамічно сортувати, групувати, калькулювати будь-які значення атрибутів і підводити підсумки.
Використовуючи зазначені списки, а також автоматизовану логіку дій, налаштовану допомогою застосування програмованих робочих процесів, створені процеси управління електронними актами про шлюб (невідповідність).

Процеси обліку та опрацювання актів про шлюб
1. Створення Акта контролером
Для реєстрації актів створений список «Акти про шлюб» (https://portal.domain.ru/SiteDirectory/quality/Lists/List). Фіксація актів про шлюб здійснюється контролером відділу якості у відповідності з правилами, прийнятими в організації.

При створенні запису в Актах про шлюб» заповнюються такі поля:
Вхідний контроль – вибір Так/Ні (вказується Та у разі якщо реєструється невідповідність вхідного контролю матеріалів і готової продукції від зовнішнього постачальника)
Виявлено вибір цеху, де виявлено невідповідність (обов'язкове)
Виникло – вибір цеху, де виникла невідповідність (обов'язкове)
Контролер – вибір ПІБ відповідального контролера відділу якості (обов'язкове)
Продукція – найменування невідповідної продукції (обов'язкове)
Кількість – числове кількість невідповідної продукції (обов'язкове)
Невідповідність – докладний опис невідповідності продукції (обов'язкове)
Маршрутний лист/Операція/Робітник – перерахування виробничих характеристик (обов'язкове)
Примітка – необов'язкове текстове поле

Запис може також мати вкладення файлів (фотографії, креслення, документи).

При редагуванні запису доступні ті ж поля, що і при створенні.

2. Прийняття рішення ВКК
Після реєстрації акта про шлюб автоматично створюється елемент у списку «Рішення по шлюбу» (https://portal.domain.ru/SiteDirectory/quality/Lists/List6) і відправляється повідомлення у відділ якості.
Керівник відділу якості або відповідальний інженер повинен прийняти рішення.
При зміні запису в списку «Рішення по шлюбу» заповнюються такі поля:
Рішення – вибір значень з довідника «Рішення» (https://portal.domain.ru/SiteDirectory/quality/Lists/List7) Повернення постачальнику/Корекція/Відступ/Утилізація (обов'язкове)
Усуває цех — вибір значень з довідника «Підрозділи» (https://portal.domain.ru/SiteDirectory/quality/Lists/List1) (обов'язкове)
Корекція – опис заходів для усунення невідповідності (обов'язкове)

При перегляді елемента доступні наступні поля:
Прийняв рішення – обліковий запис співробітника відділу якості, який прийняв рішення по невідповідності, поле заповнюється автоматично після збереження елемента
Термін – протягом 4 робочих годин з моменту одержання повідомлення.

3. Визначення коригувальних дій
Після реєстрації акта про шлюб автоматично створюється елемент у списку «Коригувальні дії» (https://portal.domain.ru/SiteDirectory/quality/Lists/List11) і надсилається повідомлення керівнику підрозділу, де виникла невідповідність. Статус Акта змінюється на «Рішення керівника ОКК».

Керівник підрозділу повинен відреагувати, заповнивши обов'язкові поля.

При зміні запису в списку «Рішення по шлюбу» заповнюються такі поля:

Причина невідповідності – вибір значення з довідника «Невідповідності» (https://portal.domain.ru/SiteDirectory/quality/Lists/List5)
Винуватець – ПІБ виконавця або найменування постачальника
Коригуючі дії – заходи, вжиті або заплановані для запобігання виникнення подібних невідповідностей в подальшому

При перегляді елемента доступні наступні поля:
Прийняв рішення – обліковий запис керівника підрозділу, в якому виникла невідповідність, який прийняв рішення по невідповідності, поле заповнюється автоматично після збереження елемента
Термін – протягом 16 робочих годин з моменту одержання повідомлення.

4. Узгодження рішення Техвідділом
Після прийняття рішення по невідповідності керівником відділу якості автоматично створюється елемент у списку «Узгодження рішення» (https://portal.domain.ru/SiteDirectory/quality/Lists/List9) і надсилається повідомлення керівнику Техвідділу. Статус Акта змінюється на «Узгодження Техвідділом».

Керівник Техвідділу повинен погодити або відхилити, запропоноване відділом якості рішення.

При зміні запису в списку заповнюються такі поля:
Погоджено – вибір значення Погоджено/Відхилено (обов'язкове)
Коментар – текстове поле з поясненнями (обов'язкове)

Поля, доступні при перегляді запису:
Погодив – обліковий запис Техвідділу, який погодив або відхилив рішення по невідповідності, поле заповнюється автоматично після збереження елемента.

На стадії узгодження рішення можливі два сценарії:
  • 1. Техвідділ відхилив запропоноване рішення.
    Відбувається повернення на стадію 2 робочого процесу, коли заново створюється рішення для керівника відділу якості. Статус Акта змінюється на «Рішення керівника ОКК». Попереднє рішення зберігається для історії.
  • 2. Техвідділ погодив запропоноване рішення.
    Перехід до стадії 5 процесу.
    Термін – протягом 4 робочих годин з моменту одержання повідомлення.


5. Калькуляція витрат
Після погодження рішення автоматично створюється елемент у списку «Калькуляція» (https://portal.domain.ru/SiteDirectory/quality/Lists/List8) і надсилається повідомлення економісту-нормувальника підрозділу, виділеного керівником відділу якості в якості усуває. Статус Акта змінюється на «Калькуляція витрат».

Співробітник економічного відділу повинен виконати калькуляцію витрат (матеріальних, трудових, прямих і непрямих), пов'язаних з даними невідповідністю, з реалізацією рішення щодо усунення невідповідності.

Запис може також мати вкладення файлів (фотографії, креслення, документи).

При зміні запису в списку заповнюються такі поля:
Напівфабрикати – сума витрат на напівфабрикати в рублях (обов'язкове)
Матеріали – сума витрат на матеріали в рублях (обов'язкове)
Зарплата – сума витрат на заробітну плату в рублях (обов'язкове)
Опис – текстове поле з поясненнями (обов'язкове)
Завершена – логічне поле Так/Ні (Значення Так (галочка) ставиться по завершенню виконання калькуляції)

Поля, доступні при перегляді запису:
Пенсійні – сума витрат на пенсійні страхові внески в рублях (обчислюване поле з формулою «=ROUND((Зарплата*0,321);2)»)
Загальні – сума загальновиробничих витрат у рублях (обчислюване поле з формулою «=ROUND((Зарплата*2,18);2)»)
Сума – сума всіх витрат у рублях (обчислюване поле з формулою «=Напівфабрикати+Матеріали+Зарплата+Пенсійні+Общие»)
Виконав – обліковий запис економічного відділу, який виконав калькуляцію витрат по невідповідності, поле заповнюється автоматично після збереження елемента.

Термін – протягом 8 робочих годин з моменту одержання повідомлення.

5.1 Перевірка умов
Після виконання калькуляції відбувається перевірка умов і очікування визначення коригувальних дій з 3 стадії процесу.

Якщо визначення коригувальних дій зі стадії процесу 3 не виконано, статус Акта змінюється на «Визначення коригувальних дій».

Після виконання визначення коригувальних дій керівником підрозділу, де виникла невідповідність, можливі два сценарії:
  1. Витрати дорівнюють нулю.
    Перехід до стадії 5.2 процесу.
  2. Витрати більше нуля.
    Перехід до стадії 6 процесу.


5.2 Перевірка умов
Після перевірки умов на відповідність типу акта «Вхідний контроль» та рішення ВКК «Повернення постачальнику» можливі 2 сценарії:

  1. Вхідний контроль – Ні.
    Перехід до стадії 9 процесу.
  2. Вхідний контроль – Так.
    Перехід до стадії 8 процесу.


6. Прийняття рішення Головним інженером
Після виконання калькуляції, визначення коригувальних дій і якщо витрати більше нуля автоматично створюється елемент у списку «Узгодження витрат» (https://portal.domain.ru/SiteDirectory/quality/Lists/List10) і надсилається повідомлення Головному інженеру. Статус Акта змінюється на «Погодження Головним інженером».

Головний інженер повинен прийняти рішення куди віднести витрати, пов'язані з невідповідністю.

При зміні запису в списку заповнюються такі поля:
Віднести витрати – вибір значення На винуватця/На виробництво/На постачальника (обов'язкове)
Коментар – текстове поле з поясненнями (обов'язкове)

Поля, доступні при перегляді запису:
Прийняв рішення – обліковий запис Головного інженера, який прийняв рішення щодо віднесення витрат, пов'язаних з невідповідністю, поле заповнюється автоматично після збереження елемента.

На стадії узгодження рішення можливі два сценарії:
  1. Головний інженер прийняв рішення Віднести витрати на виробництво або На винуватця
    Перехід до стадії 7 процесу.
  2. Головний інженер прийняв рішення Віднести витрати на постачальника
    Перехід до стадії 8 процесу.


Термін – протягом 4 робочих годин з моменту одержання повідомлення.

7. Закриття Акту
Після прийняття рішення Головним інженером щодо віднесення витрат на виробництво статус Акта змінюється на «Закрито», надсилаються повідомлення для Відділу якості, Економічного відділу, Бухгалтерії і Керівнику підрозділу, де виникла невідповідність.

Керівник підрозділу повинен роздрукувати Акт, підписати сам, взяти підпис у Винуватця, підписати у головного інженера і передати Акт в бухгалтерію.

Термін – протягом 8 робочих годин з моменту одержання повідомлення.

8. Створення претензії
Після прийняття рішення Головним інженером щодо віднесення витрат на постачальника або при відсутності витрат, але з рішенням вхідного контролю про повернення постачальнику, статус Акта змінюється на «Обробка претензії», автоматично створюється запис в списку «Результати претензії» (https://portal.smz.ru/SiteDirectory/quality/Lists/List12), формується посилання на форму друку претензії, надсилаються повідомлення для Відділу якості, Головного інженера, Економічного відділу та Керівника підрозділу, де виникла невідповідність.

Головний інженер повинен роздрукувати Претензію, підписати, поставити печатку підприємства і передати Претензію Керівнику підрозділу, відповідального за дану поставку невідповідної продукції.

Перехід до стадії 10 процесу.

9. Закриття Акту
Після калькуляції витрат та визначення коригувальних дій статус Акта змінюється на «Закрито», надсилаються повідомлення для Відділу якості, Головного інженера, Економічного відділу та Керівника підрозділу, де виникла невідповідність.

10. Обробка претензії
Керівник підрозділу, відповідального за дану поставку відправляє Претензію постачальнику, проводить всі необхідні заходи, пов'язані з поверненням невідповідної продукції та результатів роботи, вносить зміни у відповідний запис у списку «Результати претензії» (https://portal.domain.ru/SiteDirectory/quality/Lists/List12).

При зміні запису в списку заповнюються такі поля:
Претензія задоволена – вибір значення Так/Ні/Частково/Скасування рішення (обов'язкове)
Коментар – текстове поле з поясненнями (обов'язкове)

Поля, доступні при перегляді запису:
Прийняв рішення – обліковий запис Керівник підрозділу, що відзвітували за результатами обробки Претензії, поле заповнюється автоматично після збереження елемента.

На стадії обробки результатів Претензії можливі три сценарії:
  1. Результат задоволення Претензії — Так
    Перехід до стадії 11 процесу.
  2. Результат задоволення Претензії – Немає або Частково
    Перехід до 12 стадії процесу.
  3. Результат задоволення Претензії – Скасування рішення
    Перехід до стадії 2 процесу. Скасовуються всі зміни і заново створюється рішення для керівника відділу якості. Статус Акта змінюється на «Рішення керівника ОКК». Попереднє рішення, калькуляції і всі узгодження зберігаються для історії.
Термін – протягом 30 днів з моменту отримання повідомлення.

11. Закриття Акту
Претензія задоволена повністю, статус Акта змінюється на «Закрито», надсилаються повідомлення для Відділу якості, Головного інженера, Економічного відділу та Бухгалтерії.

12. Закриття Акту
Претензія задоволена частково або не задоволена, статус Акта змінюється на «Закрито», надсилаються повідомлення для Відділу якості, Головного інженера, Економічного відділу, Бухгалтерії і Юрисконсульта.



Обіцяні картинки

Головна сторінка вузла містить веб-частини, таргетовані на різні групи користувачів. Веб-частини відображають елементи, адресовані користувачеві і вимагають реакції
Головна сторінка сайту SharePoint

Сторінка перегляду акта містить форму перегляду елемента, що відображає необхідні поля, а також веб-частини, зв'язних списків, які відображають всі елементи, що відносяться до даного акту
Сторінка перегляду акта про шлюб

Друкована форма акта (наприклад, необхідна у разі стягнення шкоди з винуватця)
Друкована форма акта про шлюб

Друкована форма претензії постачальнику (формується у разі акта вхідного контролю та віднесення витрат на постачальника)
Друкована форма претензії постачальнику

Резюме

Впровадження такого процесу дозволило скоротити час обробки акта до 1-3 днів. Природно, підвищилася прозорість і керованість процесу. Процес став відчутним, вимірюваним і відповідно контрольованим. Як наслідок, підвищилася особиста відповідальність залучених учасників. Значно скоротилася кількість ручної праці навіть від такої простої речі як друк претензії постачальнику. При обробці претензії юрисконсульт може своєчасно реагувати, скорочуючи втрати, а керівництву доступна будь-яка звітність по процесу у реальному часі.

Обсяг роботи – 2-3 тижні роботи спеціаліста. Вартість впровадження порахуєте самі?

У мене багато є таких кейсів, продовжувати? :)

Джерело: Хабрахабр
  • avatar
  • 0

0 коментарів

Тільки зареєстровані та авторизовані користувачі можуть залишати коментарі.