Автоматизація як інструмент закріплення організаційних … — Transcript

Сьогодні ми вас вітаємо на вебінарі "Автоматизація як інструмент закріплення організаційних змін". І ми розкажемо про це на прикладі впровадження CRM-системи.

Причому ми поговоримо про те саме, яким чином це впровадження може допомогти закріпити і досягнути довгострокового результату. Ми будемо про це говорити на прикладі впровадження для компанії ЮріяФРМ, на прикладі еволюції їхніх процесів. І сьогодні я буду проводити цей вебінар не

один, а з представником від компанії ЮріяФарм. Мене звуть Денис Шевчук. Я працюю з CRM вже більше 20 років. Я є менеджером з розвитку бізнесу цього напрямку в компанії SmartБізнес і брав участь у впровадженні для абсолютно різноманітних компаній, в тому числі

ЮріяФарм, Ясно, Нова пошта, Брокар. Сьогоднішній мій співгосподар цього вебінару — це Віталій Коломієць. Він представляє якраз команду ЮріяФарм, є керівником департаменту управління бізнес-процесами.

Крім того, Віталій є віце-президентом організації, яка має таку складну англійську абревіатуру ABPMP Україна. І це Асоціація професіоналів управління бізнес-процесами. Вона є офіційно представлена в Україні. Віталій є якраз віце-президентом в цій організації, яка допомагає бізнесу впроваджувати процесні

підходи, підтримує міжнародні стандарти управління в цій царині. А тож передам слово. Так, дякую, Віталій. Трішки згодом передам Віталію слово. Буквально трішки для тих, хто про нас не знає. А я маю представити і компанію SmartБізнес, і компанію ЮріяФарм. Ми займаємось

цифровізацією бізнесів в Україні і по всьому світу. Є найбільшим партнером Microsoft в Україні, одним із найбільших в центральній і східній Європі. Серед наших клієнтів ЮріяФарм, Ясно, IKEA, McDonald's, Грузія, Johnson and Johnson, Delo, BDO, Porsche і так далі, і так

далі, і так далі. Ми займаємося якраз автоматизацією, цифровізацією абсолютно різних бізнес-функцій від фінансів і управління персоналом до продажу, сервісу, управління різною операційною діяльністю.

А все це робимо на технологіях Microsoft. Ну і зрозуміло зараз обов'язково із використанням штучного інтелекту. Наш співучасник впровадження — компанія ЮріяФарм, замовник цього впровадження, для якого воно було зроблено, який є сьогодні нашим підґрунтям для нашого вебінару, входить в топ-три фармацевтичних компаній в

Україні, веде свою діяльність в 49 країнах світу, є, можна сказати, власником найбільших виробничих потужностей в Україні і має достатньо амбітні цілі ввійти в топ-10000 світових фармацевтичних компаній всього світу, реалізуючи власну затверджену місію. Є одним із лідерів по кількості створення

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

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

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

Інакше компанія ризикує просто перестати існувати, перестати спочатку бути конкурентноздатною, а потім перестати існувати.

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

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

компанія із 30 осіб не може просто збільшитися в масштабі до компанії з 3000 осіб і при цьому не вибудувати всередині себе якусь організаційну, управлінську, процесну структуру для того, щоби бути і залишатись ефективною.

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

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

зрозуміти, як мають перебудуватись, як мають змінитись ось ці наші внутрішні бізнес-процеси, щоб стати відповідними до оцього нашого бажаного, до оцього нашого цільового стану, який ми собі захотіли отримати.

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

Банально між підрозділами мають бути якісь домовленості відносно того, як оформити запит, як отримати результат, які терміни і так далі. Це все дає нам якраз ось цю прозорість взаємодії. Знову ж таки, правила передачі, правила прийняття рішень, вони

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

І ось, власне, весь цей контур від цілей, процесів, даних до IT-систем і конкретних прикладних задач і інтерфейсів виконавців — це все є частиною таких великих органічних трансформаційних, організаційних змін.

А, ну і знову ж таки, у нас можуть траплятися зміни знизу, коли комусь із користувачів якоїсь системи потрібно щось змінити в системі. Зазвичай виникає питання: а чи змінюється при цьому процес?

Моя відповідь — що 100% змінюється. Можливо, дуже мало, дуже легенько, але при цьому навіть додане поле якесь чи змінена кількість знаків після коми в якомусь числі вже призводить до зміни поведінки людини, яка з цим працює в інформаційній системі. А зміна поведінки людини, в свою чергу, — зміна в процесі. І дуже рідко, але може так трапитись, що додане нове поле в систему стопорить людину, бо вона не знає, які дані туди заповнити чи як це зробити правильно.

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

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

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

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

А і

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

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

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

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

Знову ж таки, залежно від зрілості компанії, від зрілості там власників процесів, учасників процесів, ось цей бажаний цільовий стан, він має бути відфіксований, а а в ідеалі ще і оцифрований. Тобто як ми цей цільовий стан потім зможемо поміряти, досягли ми його чи не досягли?

А-а, і знову ж таки, це робиться до того, як ми вибрали спосіб або інструмент для того, щоби вирішувати цю проблему. Бо саме ось цей цільовий інструмент і буде е цільовий стан і буде визначати, а як власне ми можемо до

нього дійти, за допомогою яких кроків, за допомогою яких змін в процесах і в інструментах ми туди будемо рухатись.

Після цього у нас буде наступний, третій крок - це власне визначення, як же ми від поточного стану перейдемо до нашого стану майбутнього. Е, по по суті формування такого верхньорівневого плану проекту і концепту, як ми це будемо вирішувати. Ну

і після того, як ця зміна відбувається, а бажано ще й до того зрозуміти, як ми досягнемо того, щоби ця зміна закріпилася, щоби ми не повернулися до того, як було, щоби не було відкату, опору, е-е намагання повернутися в е-е в

поточний стан. дуже велика кількість змін, дуже велика, давайте навіть не так, кількість проектів, які по результату проекту є успішними.

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

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

зміни, тому що а не так складно захотіти і уявити, ее складніше зробити, а потім ще складніше в цьому зміненому залишитись.

Ее, ну і відповідно для того, щоби ось новий змінений стан залишався, потрібно з цим також плідно і чітко працювати.

Один із таких способів - це автоматизація, але знову ж таки не єдиний. Про це ми також поговоримо трішки трішки пізніше. Ну і власне, якщо знову ж таки повертатись до того, про що ми сьогодні поговоримо, до нашого кейсу, то

на прикладі от одного процесу і його автоматизації власне поговоримо, розкриємо якраз ось цей підхід який лежить в площині, як пройти оцей шлях змін так, щоби потім не було бажання або можливості навіть ее піти реверсом, повернутися назад.

Е-е ось мабуть е так ми більше на цьому сфокусуємося. нашим спільним впровадженням CRM рішення, яке ми здійснили, була якраз одна із проблем, вірніше підгрунтям для цього впровадження було вирішення певної проблеми. І ця проблема, ось вона у нас так була

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

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

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

І знову ж таки призводило до проблему взаємодії і всередині між цими підрозділами оскільки там хтось побіг вперед, а хтось ще не знав, хтось уже зробив свій крок, а хтось свій не зробив і загубили клієнта.

І в результаті це було а-а дуже-дуже-дуже не е несинхронно. Ну і як результат всього цього було незрозуміло, а що власне на цих ринках ми маємо, чим ми оперуємо, які результати у нас там є, з чим ми рухаємось далі. Е-е і єдиним

мірилом результату був лише там факт, е здійснених продажів, який уже такий був, а постфактум зліпок того, що відбулося або не відбулося. але якось а-а ефективно керувати цим процесом. Е-е на тому етапі е-е не було можливості. Як на мене, дуже типова задача для контуру

CRM. Е тут, мабуть, навіть не знаю, чи варто на ній більш детально зупинятися, але ключове, що була знайдена проблема.

І забігаючи наперед скажу, що а у цієї проблеми був конкретний власник, який хотів її вирішити. І ее далі постало питання: "Окей, є проблема, є бажання з нею відпрацювати?

А і що з цим робити?" А, ну і якщо ми говоримо про ось цей цільовий стан, то тут дуже гарно переплітається декілька ее ролей, декілька учасників і декілька відповідей на питання, а-а хто має ось цей цільовий стан сформувати, е, і хто

має його формалізувати. А якщо ми подивимось в процесну методологію, відповідальний за результати процесу і дизайн процесу є власник процесу.

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

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

зробити, чи яким має бути ось цей наш цільовий результат. Для опису проблеми у нас в компанії є власне той підрозділ, який я очолюю, це департамент управління бізнес-процесами.

І власне в департаменті є посада процесний аналітик, який відповідає за аналіз процесу, за визначення проблемних точок процесу і за напрацювання та рекомендацію власнику процесу можливих потенційних варіантів щодо вдосконалення процесу.

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

а BPM, яка може більш системно, більш чітко, більш структуровано виконувати цю роботу, ніж наш власник процесу. власник процесу, він зазвичай в бізнесі, він зайнятий бізнес-проблемами і бізнес-питаннями. І його ключові компетенції - це, власне, е компетенції тієї функції або того процесу, яким він

е-е керує. Ну, наприклад, нелогічно там CRM-директора е саджати, малювати BPMN діаграму або складати раці матрицю.

Ну, це власне більш такі прикладні аналітичні інструменти, які може виконувати спеціалізована людина для цього.

або якщо в компанії немає там якоїсь власної функції, яка могла би це робити там системно і структуровано, а або дефіцит ресурсу його не вистачає, ми зазвичай також розглядаємо варіант пошуку зовнішнього партнера, який розуміється конкретно на цій проблемі, має досвід у

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

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

його хочемо собі реалізувати цього тобі. А-а, ну і власне в нас в процесі, ще раз, е, ее, так трішки занурюся в деталі, е-е, як інструмент ми використовуємо А3 для формалізації проблеми. Це інструмент із, е, lін. Хто з лін знайомий, його знає,

хто не знайомий, раджу познайомитись. Так от, цілі проекту. Нам потрібно було зібрати єдину цілісну інформацію про клієнтів, дистриб'юторів і про наші продукти на наших цільових ринках, куди ми рухаємося. Знову ж таки повторюсь, це про входження на нові ринки нових продуктів. В даному кейсі ми

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

А-а, закласти якісь інструменти автоматизації для того, щоби спростити роботу нашої команди і ее мати змогу заходити заходити на нові ринки і з новими іншими продуктами.

А якщо повернутись до питання зесними аналітиками е будучи частиною асоціації BPMP, ее прийшов до висновку, що не в кожній компанії вони є. Е-е знову ж таки, з різних причин.

Малий і середній бізнес зазвичай не може собі дозволити виділену окрему посаду роль, оскільки це, на мою думку, знову ж таки висококваліфікована а робоча одиниця, яка нуртуватиме недешево на ринку.

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

І що робити? Ее в даному випадку, знову ж таки, є декілька способів. І найкраще, як на мене, це комбінація всіх варіантів можливих. А поясню чому. А-а підхід номер один - це, е, ростити цю компетенцію на базі якогось із

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

бізнес саме так рухається. Тобто вони нарощують компетенцію без виділення е-е її в окрему роль, посаду е чи підрозділ.

Е більші компанії дозволяють собі формувати там людину або підрозділ. Є ті, в кого це там процесний офіс, там бізнес-аналітики, департаменти різні, які займаються аналізом.

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

перебудувати і взаємодію, роботу людей. Ну і, як я вже сказав, найкращий варіант - це коли відбувається комбінація ось цих трьох речей, тому що дуже добре, коли учасник процесу володіє трошки більшими компетенціями щодо розуміння і роботи з цим процесом, ніж просто бути

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

Давайте поговоримо, да, про те, що відбувається наприкінці проектів впровадження і чому це не кінець.

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

проект закінчиться. Тому що е-е там знову ж ми пам'ятаємо за визначенням, проект надає нам унікальний певний результат і все, проект закінчився.

Після цього настає невідоме. А-а так от підходи з управління змінами і власне і підходи з управління бізнес-процесами, вони кажуть, що ні, нічого не закінчилось, все тільки починається.

І власне на етапі підготовки до впровадження і впровадження нам треба чітко розуміти, а як це буде працювати потім, на кого це ляже, як ці люди будуть працювати там, коли проектна команда там пі піде в якісь інші задачі, в інші проекти, чому

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

учасника нашої команди е-е відносно його місця, ролі і способу роботи тоді, коли а це ее цей проект буде завершений.

Власне, по завершенню проекту ми уже маємо чітко переконати, що всі все освоїли, зрозуміли, встали на місця і певний момент ми ще можемо поспостерігати, а чи дійсно це так? Е-е, чи дійсно це дозволяє закріпити той результат і, е, отримати від нього

бізнес-ефект, який ми собі запланували, задали, уявили на початку. Отож, у нас постає питання, яким взагалі які є інструменти для того, щоб цей результат досягнути в сталому його варіанті на тривалий час, не просто на момент завершення проектів, а на достатньо тривале майбутнє.

І я ще хотів додати, колеги, я спонукаю вас теж задавати питання. У нас є панель Q&A. Нам декілька питань надійшло перед вебінаром. Ми на них відповімо наприкінці, але ви можете також задавати свої додаткові питання. Ми спробуємо на них відповісти, якщо зможемо, звісно,

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

До речі, в Україні є так само, як асоціація управління бізнес-процесами, професіоналів управління бізнес-процесами, є асоціація професіоналів управління змінами, і вони дуже чітко і детально ось ці всі інструменти, підходи там е розказують, розбирають. Ми зараз з точки зору е-е

там зміни в бізнес-процесах поговоримо власне про е-е те, як нам в процесі цю зміну закріпити. Ну і ось модель ADCAR, вона декларує там, е-е, п'ять ключових складових для того, щоби наша зміна е відбулася. І як бачите, останній крок

якраз нам декларує про те, а що зміна має е залишитись, існувати стабільно. А але для того, щоби це відбулось на початкових кроках, ми маємо усвідомити невідворотність зміни. Тобто чому не можна не змінюватись? Чому зміна має відбутись?

А власне чому кожен із учасників цієї зміни має прийняти в ній участь? Чому це для нього важливо? Чому це для нього необхідно? Після цього виникає потреба в тому, як власне ця зміна має відбутися, як ми маємо це зробити, як провести і ее

сформуватися спроможність, е здатність її виконати. Тобто знання, навики, ресурси необхідні для того, щоби ця зміна відбулась.

А і це повертає нас ще до одного питання, до глобальності зміни, назвемо це так.

Коли ми зазвичай говоримо про зміни, нам варто розуміти, ми говоримо про еволюцію, тобто там покрокове ітеративне вдосконалення існуючого, чи коли нам потрібно повністю переглянути принципи, підходи, логіку отримання результату, можливо сам результат, який ми маємо отримувати, і заходити в таку глобальну радикальну

трансформацію перебудову або побудову практично з нуля якогось процесу. Тут чітко варто ці речі розмежовувати, тому що вдосконалення - це коли ми крок за кроком трішки краще, трішки краще, трішки краще робимо наш процес. А трансформація, коли нам треба радикально

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

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

А якщо говорити про інструменти, тобто з чим ці зміни мають бути, ее ми повертаємося до до знову ж таки питання трансформації або вдосконалення. А дуже часто виникає питання: "А давайте ось цей процес побудуємо ось так. Буде класно, буде супер. Ее, ну, єдине, що

так ніхто не робить, але ми вважаємо, що так буде, е, найкраще для всіх. Е-е, так от варто розуміти, що, е-е, є речі, які зробили до нас, і зазвичай варто ними користуватись. це зекономить і зусилля, і ее час, і інші ресурси, і

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

найкращий варіант, ніж ви находите якийсь свій велосипед. Аа практика і теорія приводять до того, що а наша унікальність потрібна лише там, де формується конкурентна перевага.

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

бути якісь особливі процеси, особливі підходи до а-а там формування результату, до задоволення потреби клієнта, до формування нашого продукту.

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

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

розуміють, що це нормальний стан нормального процесу, як працює у всіх. Це не щось таке, що там на голову не налазить, не натягується. Це найкращий винайдений на сьогодні і задекларований і автоматизований спосіб отримання цього результату. Тому, власне, тут закликаю

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

незначними відмінностями. І навпаки, якщо ви хочете будувати щось унікальне, то розумійте, що це крім вартості проекту у вас потім ще вартість володіння, підтримки і так далі цього всього.

Це на вас накладає великі зобов'язання, тому що знову ж таки, а змінюючи певний процес, ми завжди повинні давати відповідь на питання: а чи вартує вкладення оцих ресурсів в таку зміну того результату, який ми отримаємо на виході? Тобто при певному зрілості оцінку

ефективності впровадження і оцінку фінансову власне ефективності ніхто не відміняв. Ми не завжди це робимо, не завжди це готові робити, але хоча би там підсвідомо віддавати собі давати собі відповідь на питання, а чи вартує вчинка вичинки, ми повинні завжди.

Ну і власне, е, да, давайте поговоримо, як це працює на практиці, як це працює за допомогою сірм рішення.

що відбулося на практиці. На практиці для даного процесу, ще раз повторю, що це дуже невеликий, дуже маленький і дуже точковий процес, але дуже показовий якраз з точки зору ось всього оцього підходу. А були визначені після того, як був визначений

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

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

нашому партнеру, е в якому стані, в якому статусі зараз ми з ним перегува перебуваємо. Ось тут ми бачимо власне по а-а продуктах на кожній країні, на кожній території. І тут можемо побачити, що там є ті, в яких контракт уже сплив і

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

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

продуктах і партнерах. Уже більш дробно, більш детально. З яким продуктом, з якими партнерами ми де знаходимось.

А-а, дякую. І зміна закріпилася, але зараз мабуть треба, як її закріпити? Реально, от це ж найскладніша задача.

Які для цього є фактично в нас інструменти в реальному житті? Знову ж таки, не знаю, звідки в компанії взявся термін мотиваційні замки.

Можливо, це чийсь, тут на авторство не претендую. Якщо підкажете, кому належить, поставлю знак копірайта авторського права. А, але ми ним послуговуємось. І вони є трьох типів. А перший тип - це організаційні - це коли існують певні внутрішні в компанії

правила, які зобов'язують, а-а, і стимулюють до того, щоби діяти так, як до цього спонукає оновлений процес. Це можуть бути регламенти, там стандартні операційні процедури, які зобов'язують виконувати це там певним чином. А знову ж таки, можуть бути адміністративні, це ее інструменти безпосередньо там

мотивації, стимуляції конкретних учасник конкретних учасників до певної поведінки. Тобто це там KPI е-е або інші інструменти там якогось матеріального чи нематеріального заохочення. Е це обов'язково інструменти контролю. Е-е це е-е підходи до мотивації, тобто заохочення співробітників діяти правильно. І це

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

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

і е-е буде працювати так, як це було заплановано і закладено логікою. А чи працює це окремо? Е-е, швидше ні, мабуть, ніж так. Е, в кожній конкретній зміні, в кожному конкретному процесі доля прояву того чи іншого елемента може різнитися. Але найкраще це працює, коли

існує комбінація цих трьох інструментів, а, тобто чіткі правила, інструменти заохочення і стимуляції до правильної поведінки і прикладні інструменти, які не дозволяють діяти інакше. Тоді ее зміна фіксується.

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

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

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

Але, ну, якщо є мотивація і є інструмент, то уже буде складно діяти якось інакше.

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

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

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

Ну, тут я зараз дуже-дуже коротко скажу. Е-е на слайді написано багато. Е-е, ми бачимо потребу в тому, щоб, е-е, зінтегрувати між собою декілька процесів і отримати такий додатковий буст від того, щоби між ними стики були чітко, е, структуровані, чітко синхронізовані.

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

ключових елементів, ключових результатів входів і виходів. Тому, мабуть, ось так без деталей. Зрозуміло. Добре. Е, ну, тут ми підходимо до завершення. У нас, я дякую Віталію, у нас ідеальний таймінг. Ми планували працювати сьогодні на вебінарі годину 50 хвилин самого контенту і ще 10 хвилин

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

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

Скільки співробітників вашої компанії займаються CRM? Наскільки для вас вигідно використовувати систему CRM в вашій компанії? Як швидко запрацював повний функціонал системи? Ось таке комплексне питання.

Ага. Ну, я почну з останнього. Не запрацював і ніколи не запрацює, тому що, так як я вже казав, треба чітко розуміти, де вам потрібні інструменти автоматизації, які вони потрібні, а де ні. Тобто немає задачі впровадити всю функціональність CRM-системи. Є задача

досягнути певного ефекту від виконання певних процесів. Тому, е, про кількість, мабуть, складно сказати. Так от, сходу, е-е не готовий відповісти там в кількості там учасників, виконавців. А той кейс, який ми говорили, він доволі маленький.

Там кількість людей кілька десятків. А-а, але взагалі в контурі CRM там значно більша кількість людей працює.

Але відповідаючи, от моя мій посил, моя ідея в тому, що не женіться за автоматизацію, женіться за отриманням бізнес-ефекту, де автоматизація є інструментом, не завжди одним єдиним і доступним.

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

Дякую. Наступне питання. Які ви можете дати практичні поради по встановленню сіремкультури в організаціях, котрі від початку налаштовані антигоністично до впровадження системи?

А це класичне питання управління змінами. От як ми з вами говорили, опір зміні - це очевидний дисбаланс. людям комфортніше знаходитись в поточному стані, е, ніж отримати от новий цільовий змінений. Тобто у них баланс, е, страху, зміни і вигоди від поточного стану е

більший, ніж ее е очікування майбутньої вигоди і ризики її реалізації. Вони чітко тяжіють до того, щоби залишатися в поточному стані. Вам потрібно з цим балансом попрацювати. Чому цим учасникам буде краще, якщо там запрацює CRM система, процес буде працювати ось так,

компанія буде працювати ось так. І це така пояснювально-комунікаційно-просвітницька робота. Це не щось інше. Чому ця зміна корисна не тільки компанії? Чому вона також важлива і корисна і кожному учаснику цього питання?

Дякую. Я ще додатково наголошу. Е, кожну зміну треба оцінювати з точки зору кожного її учасника. Для нього, для кожного із учасників має бути якась своя особиста ціль, мета участі і залучення в цю зміну.

Зрозуміло. Дякую. Наступне питання. Хто відігравав ключову роль у впровадженні автоматизації з команди підприємства? А, ну, якщо говорити про там от цілісну зміну, то я буду наголошувати, що в першу чергу це власник процесу, тому що всі ключові рішення за ним. А про бюджет, про цілі,

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

Від початку і до кінця за цим всм стоїть власник процесу. Він же власник проблеми, він же спонсор зміни. Там можна по-різному його називати, але по факту це людина, яка зацікавлена в тому, щоби новий стан настав. Це ключова роль. Без

неї не відбудеться. Зрозуміло, не називаємо конкретні персоналій. Ну, в нашому випадку це був один із топ-менеджерів. Там уже вдаватись в деталі не буду. Чим більше повноважень ця особа має, тим краще для зміни, але, ну, вона має мати бажання і спроможність

цю зміну розгортати, реалізовувати. Зрозуміло. Дякую. І останнє поки що питання, яке ми маємо в списку, це які найефективніші, на вашу думку, кроки були зроблені по спонуканю співробітників до виконання нових бізнес-процесів у системі?

Спонукання таке гарне слово. Е-е, як я вже казав, має бути певний баланс кількох е речей. Е-е перше, розуміння невідворотності зміни. Тобто те, що це буде працювати в будь-якому випадку і це потрібно. А друге, розуміння своєї ролі і я би говорив цінності в даному

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

Чому це важливо? Чому я роблю цю роботу? не буде довго часу переказувати, але є та відома байка, коли два будівельники і один розказував, що моя робота не цікава, бо я щодня кладу цеглу, кожного дня беру цеглину, накладаю розчин і

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

Хоча по факту вони роблять одне і те ж. Тому ось тут варто розуміти. Ну і далі це все має бути підтримано інструментами, ее якоюсь цілісною логікою цього і так далі. Тоді у вас ця картинка складеться.

А не бачу додаткових питань у нас в чаті. Дуже така загальна висока тема. Мабуть, прикладних питань важко задати.

Ну, ми подивимося на відгук, на те, як до нас будуть приходити учасники, можливо, е, вебінару з додатковими якимись питаннями. Можливо, ми будемо розвивати цю тематику. Мені особисто було дуже цікаво. Я вважаю, що ми не ми зачепили, а, я б сказав, ми зачепили достатньо

великий пласт питань, які би я би згрупував. Навіщо під таким великим лозингом, навіщо впроваджувати взагалі хоч якусь інформаційну систему на прикладі СР? Тому дякую вам за щиру і класну розмову.

Навзаєм був радий. І до наступних зустрічей. Особливо чекаю всіх, кого це цікавить там на теренах асоціації, подій, які проводить асоціація. Там можна знайти багато кейсів і однодумців, з якими можна про це поговорити.

PMP Ukrain вірно. Так, хто захоче, знайде. Добро. Тож дякую всім за ваш час. Ми завершуємо. До наступних вебінарів, до наступних зустрічей.

На все добре і хай щастить.