Zeppelin International - ексклюзивний дилер всесвітньо відомого виробника важкої промислової техніки Caterpillar, веде діяльність в 190 філіях 43 країн світу.
Євген Осьмак - ІТ директор холдингу Zeppelin International, розробляв функціональні стратегії, ІТ-архітектури, запроваджував процеси управління проектами, програмами і портфелями, засновані на гнучких методологіях (agile).
і ще багато цікавого читайте в нашому інтерв'ю.
1:10 - Що спільного в Ілона Маска і засновника Zeppelin. Історія компанії
5:31 - Zeppelin зсередини: як побудована бізнес-модель. Чим подібні моделі Caterpillar і 1С:Підприємство
8:58 - У складі бізнесу Zeppelin не тільки Caterpillar. Унікальна технологія Zeppelin: в чому переваги для харчової та нафтопереробної галузей
11:27 - Які галузі в Україні дозріли до стандартів Zeppelin
12:28 - Точне землеробство: як реалізується за допомогою крупної техніки
14:18 - IT-архітектура великого холдингу і плюси централізованого управління. Чому компанії на місцях не управляють своїм IT самостійно
16:23 - Автоматизація системи видачі нарядів на заводі ремонтів CRC в Горішніх Плавнях. Базова система і плани з розробки софту
19:37 - Чи раціонально створювати власні Web-додатки. Що можна купити. Як обрати платформу для додатку
22:51 - Інтеграція із замовником: в чому складність роботи в умовах посттоталітарного суспільства
24:33 - Дизрапшн: як підрив власного бізнесу захищає від конкурентів
27:41 - IT-архітектура - це про стани, стратегія - про переходи. Як побудувати стратегію, а не стратегічний план
29:45 - Paralysis by analysis або скільки часу треба відводити для аналізу поточного стану архітектури, а скільки - плануванню майбутнього
30:30 - Чому опис архітектури часто стає невиконуваною задачею. Як створити архітектури, які насправді оптимізують бізнес
32:57 Що означає Capability в бізнес-архітектурі. Навіщо потрібно визначати потребу в розвитку і як часто це робити
37:21 - View для стейкхолдерів: ключові питання, які треба з’ясувати перед описом архітектури
41:20 - Чи можуть зовнішні консультанти побудувати повноцінну стратегію для вашого бізнесу
42:23 - Рішення щодо стратегії розвитку: що враховувати, яку інформацію зібрати і як узгоджувати
43:14 - Досвід впровадження системи IT-Enterprise
44:22- Все в планшеті – як система пришвидшила обробку документів і скоротила строки оплати
45:14 - Як обрати базовий фреймворк для побудови IT-архітектури Dodaf, Togaf, Zachman. Що застосувала компанія Zeppelin
47:50 - Чи повинні IT долучатися до розробки бізнес-процесів і чому. Як генерувати інновації і хто за це відповідальний
52:06 - SAP і 1С:Підприємство: плюси і мінуси. Як обрати систему ERP-класу
57:16 - Про розвиток корпоративних IT. Як правильно впровадити ERP
59:08 - Опис ідеальної ERP. Її місце в системі мікросервісів
01:01:09 - Методологія впровадження системи автоматизації, не раз перевірена Zeppelin
1:02:27 - Як зрозуміти, що час перевпроваджувати. Як довго система може залишатися актуальною
1:05:24 - Діджиталізація і "3 De", що її описують. Чим діджиталізація відрізняється від автоматизації
1:08:09 - Проблема якості даних. Чи може IT відповідати за дані, які генерує бізнес. Як IT покращує якість даних
1:11:06 - Чому IT - це гігієнічний фактор. Як уникнути паралічу бізнесу
1:14:36 - Заради якісної IT-стратегії: як шукали «больові точки» у відділах. Як дізнатися, в які відділи треба, а в які не треба йти
0:35 Всім привіт! З вами Зосим Максим на каналі Perceptron. Сьогодні у нас цікавий формат і цікавий гість - Євген Осьмак, компанія Цеппелін, Head of IT. Погнали!
1:10 Давайте 3 зелених свистка.
Перший розділ - про компанію: ти розповідав коротку історію в одному з виступів.
Фердинанд фон Цеппелін жив у Баварії на початку ХХ століття. Робив основні якісь свої речі, його називали мрійником з озера Бодензеє. Озеро Бодензеє або Констанц - в залежності від того, в якій країні, воно по-різному називається. Це озеро, до якого примикають Австрія, Швейцарія і Німеччина (південь Баварії). На цьому озері в місті Фрідріхсгафен він тусувався. І цікаво те, що він робив сто років тому, - приблизно те, що зараз робить Ілон Маск. Він сказав: "Я хочу, щоб люди літали". І в нього була ідея з дирижаблями. Тобто Фердинанд фон Цеппелін створив історично першу в світі авіакомпанію. Таку авіакомпанію, куди можна було прийти, купити авіаквиток, сісти у апарат і кудись полетіти. В результаті вся ця ідея з дирижаблями у 1936-му році закінчилася тим, що приземлився трошки не так, як слід, Гінденбург, величезний дирижабль (найбільший у світі із коли-небудь побудованих пасажирських дирижаблів, названий на честь президента Німеччини Пауля фон Гінденбурга – прим. ред.).
Я був у макеті. 100 років тому зайти в таку штуку - це, я впевнений, був просто космос. Вона величезна, з каютами. Всередині вона виглядала як Титанік, але гондола сама ж не дуже велика.
І цей самий Цеппелін відомий тим, що розглядав також тему з автомобілями. І ательє Цеппеліна випускало і автомобілі також. Там працювали такі пани, як Карл Майбах і Фердинанд Порше. Майбах робив підвіску, а Порше - двигуни. Автомобіль називався Maybach Zeppelin DS 8.
То була давня історія компанії, а зараз вже сучасна. В 50-х головою компанії був Екерман, і він разом з менеджментом почав думати, що вони вміють і чим би зайнятися. Вони зрозуміли, що вони дуже круто працюють з металами, що вони вміють обслуговувати складну техніку. А тут якраз на ринок зайшов американський бренд Caterpillar. І Caterpillar шукав дилерів. І в результаті утворився цей стратегічний альянс. Там мова не йде про обмін акціями, тому що, можна сказати, Цеппелін і зараз комунальне підприємство.
3:53 Що це означає?
Це прикольно. Я часто всім говорю, що я у ЖЕКу працюю. Комунальне підприємство “Цеппелін”. Як це працює? У якийсь момент місто Фрідріхсгафен викупило у Цеппеліна всі його активи, бо він був дуже інноваційним і постійно близьким до банкрутства. Тобто місто виступило стратегічним інвестором Цеппеліна. В результаті є Штіфтунг Цеппелін (штіфтунг - це як фундація чи фонд). Цим фондом володіє комуна Фрідріхсгафена.
Головою наглядової ради цього штіфтунга є мер Фрідріхсгафена - це виборна посада, і мер призначає у концерні Zeppelin увесь менеджмент, разом із наглядовою радою. Тобто люди обирають мера. Компанія не котирується на біржах, не має акцій, тобто це не акціонерне товариство. Точніше, бізнес - це вже акціонерне товариство…
4:58 А Zeppelin являє собою монобренд, тобто тільки з Caterpillar техніка?
Ні, в Zeppelin основний напрямок діяльності - це партнерство з Caterpillar, це важка техніка в усіх її формах і видах. А Zeppelin Group складається з бізнес-юнітів, бізнес-одиниць. Більшою мірою вони займаються Caterpillar. Відповідно, Caterpillar - це такий лакшері-бренд в будівельній техніці - номер 1. Такий, як Rolls-Royce у автомобілях.
5:31 Яка основна бізнес-модель компанії Zeppelin і компанії Caterpillar?
Цікава штука: Caterpillar побудував екосистему, дуже подібно до компанії 1С:Підприємство. Caterpillar робить маркетинг і продукт, а дилери встановлюють стосунки з клієнтами, забезпечують поставки, сервіс, підбір цих всіх компонентів, знають, що конкретно потрібно в цих умовах. Дуже велика варіативність, набагато більша, ніж у автомобілі за комплектацією, тому що, залежно від того, яка порода, які умови праці, наскільки там волого, яка абразивність пилу, в якому працює агрегат, - це все відіграє роль в тому, як його правильно підібрати.
Але основна бізнес-модель дуже схожа на "automotive". Якщо абстрагуватися, то із Caterpillar іде дуже тісна процесна інтеграція, тобто дилер натискає на кнопку, автоматично розміщується замовлення і автоматично починає їхати зі складів Caterpillar. Вони працюють як одна компанія в цьому сенсі, в сенсі supply chain (ланцюжка поставок).
6:46 У Caterpillar велика кількість дилерів?
В більшості країн, крім найбільших географічно країн, це монодилери. Наприклад, “Цеппелін Україна”, “Цеппелін Білорусь” і т.д. Може бути один бренд, але у кожній локації, у кожній країні свої компанії. Якщо ми говоримо про великі країни, як Російська Федерація, там кілька дилерів, але в основному в світі одна країна - один дилер. А в Штатах - одна вулиця - один дилер, тобто в Штатах дилерів дуже багато, вони дрібні. Типу: ліва вулиця і права - це наша сім'я, і там сімейні дилери, по 100 років їм. Всього дилерів у світі трохи більше 200.
7:30 При цьому Zeppelin представлений більш ніж в 100 країнах?
Zeppelin представлений у дуже багатьох країнах, але тут треба розуміти: саме за напрямком Caterpillar ми зараз представлені в Німеччині, Австрії, Словаччині і Чехії - в Європі; і Російська Федерація (європейська частина), Білорусь, Україна, Узбекистан, Таджикистан, Туркменістан і Вірменія - пострадянський простір - це наші дилерські території.
4 бізнес-юніти із шести займаються саме Caterpillar в основному - це європейський бізнес-юніт (такі ж, як ми, але вони в Європі працюють) - типу автомотів, але основне - це Caterpillar.
Є пострадянський бізнес-юніт, є бізнес-юніт, який займається силовими установками (це дизелі, дизель-генераторні установки, двигуни, всілякі системи резервного живлення і т.д).
І є 4-й (бізнес-юніт), який займається здачею в оренду. В Німеччині компанія Zeppelin здає в оренду багато чого: від важкої техніки до тимчасових дорожніх знаків, в них основний замовник - держава. Тобто держава тимчасово бере на будівництво доріг ці знаки в оренду, у неї немає їх у власності. І це чотири бізнес-юніти.
8:58 А є ще 5-й бізнес-юніт, який займається конкретно виробництвом. Він взагалі ніяк не пов'язаний із Caterpillar. Це абсолютно окреме виробництво. Те, в чому Zeppelin завжди був дуже сильний, - це обробка алюмінію. Плюс-мінус що робиться? Дуже цікава штука. От дивіться: виробництво пластику. Внаслідок крекінгу і піролізу нафти полімери, які утворюються і вилітають, мають приблизно 1 мм в довжину і кілька мікрометрів у товщину, в результаті утворюється пластикова пилюка. А її треба перетворити в гранули, щоб її можна було засипати у вагони і перевезти китайським діточкам, щоб вони зібрали все, що нам потрібно.
90% продукції.
Zeppelin робить модуль, який на вході отримує цей пил, а на виході - гранули. Це така серія, вони називаються сайлами - вертикальні труби, в них якийсь складний техпроцес всередині.
Або уявіть собі, що є пекарня або виробництво пива: зліва борошно, вода, цукор і сіль, а справа має бути тісто. І Zeppelin виробляє модуль.
У Zeppelin є унікальна технологія потокового тіста. Тісто - це, як правило, такі порції: тут засипав, розколотив, як міксер, тільки міксер там промисловий, на 500 - на 1000 кг. А тут прямо потоковий - потоково засипаються інгредієнти і потоково видається тісто. Це абсолютна інновація, ноу-хау, дуже затребувана великими пекарнями, які тонни перевертають в день. Для них це неперервне виробництво - дуже важливе, набагато краще, ніж цими порціями робити.
І саме ця штука представлена у всьому світі. Це 5-й бізнес-юніт, який займається виробництвом.
Виходить, немає зайвих витрат у виробництві, тому що в міксері 1 маса, і тобі її або не вистачить, або буде багато... Отримуємо зайві wastes (непотрібні витрати).
І ця виробнича частина, цей виробничий стратегічний бізнес-юніт є в усьому світі: є в Штатах, в Китаї, в Бразилії… Багато де він є. І це виробництво - виробництво заводів.
11:27 В Україні виробництво є?
В Україні це все не затребуване.
І дистрибуції самої продукції , цих модулів, теж немає?
Ні, в Україні немає проєктів. В нас немає заводів, потужних настільки, щоб ці штуки були потрібні. В жодній із цих галузей: ні в їжі, ні в гумі, ні в нафтопереробці нічого такого немає.
Якщо говорити про Україну, то у нас дуже сильний напрямок агро - брендів 100: всі можливі, ряд неможливих і пара нереальних. І там нема Caterpillar. Рішення для агро: трактори, комбайни, сівалки, віялки і всі ті штуки, які потрібні для сільського господарства, точного землеробства. Всі вони мають дуже багато різних брендів.
12:28 З точного землеробства що є цікавого? Ми нещодавно брали інтерв'ю у drone.ua. Вони теж називають таке (маленьке) або побільше точним землеробством, цю техніку. Що в твоєму розумінні точне землеробство?
Точне землеробство - це певний технологічний новий підхід до обробки, в ньому є дуже багато всіляких нюансів. Зокрема, точне землеробство - це і зняття телеметрії із комбайна чи трактора, і обробка в реальному часі, це і автопілотування, що також дуже важливо. Бо трактор, щоб він не топтав, має попадати у свою ж колію, він має дуже точно рухатися і повторювати рельєф самим ротором, якщо це роторний комбайн, щоб він залишав мінімум зерна нескошеним. Це проби ґрунту і спостереження дронами, врожайність, куди яких добрив треба засипати. Тобто це картографування, і куди що садити, де що посаджено, і обробка цих всіх даних у реальному часі.
Ми цього, наприклад, не уявляємо, але крупний агрохолдинг має відкриту наукову проблему: що ми посадили в результаті? Що конкретно ми посадили? Ніхто не знає, у них немає бази даних в центрі, де зазначено, що посадили. Коли їм телефонуєш: “Петрович, гречка!” Він: “Ясно!”. А у нього бодун, і він переплутав 2 мішки, і посадив замість гречки просо, чи сою, чи ріпак.
І так само, як знайти толкового архітектора ІТ-шного, це великий челендж.
14:18 Ми плавно підійшли до другого розділу: ІТ-стратегія в холдингу. І почнемо з найпростішого: архітектура.
Треба сказати, що у нас холдинг - це пострадянський простір, і ІТ централізовано відповідає абсолютно за всі країни. Значить, у локальних компаній немає свого ІТ, взагалі ніякого.
ІТ відповідає і локалізоване тут в Україні чи не тільки тут?
Ні, не тільки тут. ІТ-департамент географічно розподілений, але управляється абсолютно централізовано з однієї точки. І стратегія будувалася саме для рівня холдингу.
Управляється вона тобою? Звідси?
Так.
І саме ти розробляв, описував існуючу архітектуру, не тільки ІТ-шну, але і самого бізнесу, і на базі неї будував стратегію?
Правильно, з невеликою поправкою: один в полі не воїн, одна людина нічого не може зробити. Моє завдання було виростити певну культуру роботи з архітектурою, і в нас архітектурою займається архітектурний комітет. Що таке архітектурний комітет? Є ряд платформ: SAP, 1С:Підприємство, Microsoft Dynamics CRM, Sharepoint, і там to name a field... Є цілий ряд систем, і в кожному з цих напрямків є людина, яка виконує архітектурну функцію в цих системах. Група цих людей займається архітектурним процесом на рівні холдингу. Вони зустрічаються регулярно, вирішують задачі опису архітектури, підтримки цього опису в актуальному стані, наскільки це необхідно, і вирішують конкретні задачі архітектурного комітету. Зокрема, є отакі бізнес вимоги: яку ми рекомендуємо платформу, на якій їх реалізовувати. Це, зрозуміло, залежно від задачі ми можемо реалізовувати на тих чи інших технологіях.
От є задача: ми говорили про CRC - Component Rebuild Center - це завод в Горішніх Плавнях, який займається виконанням ремонтів, тобто вони роблять ремонти крупних агрегатів і компонентів.
Ми на ньому зробили досить просту систему автоматизації, яка вирішувала основну задачу: рекомендована карта процесу Caterpillar, які технологічні операції за скільки часу має виконувати дилер. Уявіть собі автомотів. Є ТО, є година і такі операції. Наша задача була:
Автоматизувати видачу нарядів механікам. Тобто механік приходить і говорить: "Отримати наступний наряд". Система з усієї множини робіт підбирає за його кваліфікацією, за окремими параметрами те, чим він має зайнятися. Він не думає, нікуди не ходить, ні в кого нічого не питає - це система йому видає наряд. Далі він отримує цю штуку і натискає кнопку "Пішов працювати". І ще є "Пауза" і "Завершив". Таким чином система автоматично, за його сигналами складала в купу інформацію, скільки він над цим реально працював, з метою зрозуміти, де ми сильно відхиляємося від стандарту, і ці конкретні операції оптимізувати.
Система була нескладна. Зараз ми пишемо її другу версію, яка буде на порядок більш функціональна, на порядок більш амбітна, і там з усіма можливими і неможливими елементами автоматизації. Надзвичайно важлива функція, яка буде в цій новій системі, - це безпека праці.
17:55 Років п'ять тому ми зробили бекенд з 1С, а фронтенд - це сканер, який ви могли бачити у будь-якому супермаркеті - пристрій для введення даних з тачскріном на касах, де великий екран, і люди вибирають якісь страви, вибирають якесь меню. Відповідно, для такого пристрою - це комп'ютер на базі Windows зі специфічним оцим інтерфейсом…
На беку УПП стоїть чи щось інше?
УТП. І ми на УТП зробили ту функціональність, яку треба було саме для такого процесу на тому рівні зрілості. Зараз таких CRC уже 3: один є в Росії, у Вірменії і в Україні, і вони централізовано управляються...
В Україні перший був відкритий?
В Україні був перший зі спеціалізованих. Історично перший проєкт у Росії, але він був, скажемо так, адаптований певний цех під. А в Україні ж це був прямо з нуля побудований під цю задачу перший. Зараз архітектурний комітет, одне з питань якого: є задача, треба написати софт, який буде управляти процесами цих трьох заводів. І ми вирішили, що, по-перше, він має бути один. Значить, він повинен бути не на SAP, не на 1С:Підприємство, тобто не на ERP. Тому що ні. В результаті ми прийшли до висновку, що це буде Web-application, Web-додаток, який буде централізований, i централізовано буде управляти цими трьома.
19:37 Web-application без платформи, без прив'язки? Ви самі з нуля будете його будувати? Чи раціонально це з точки зору архітектури? Тут можна, звичайно, зачепити теорему Геделя з приводу софту. Наскільки раціонально будувати власний додаток з управління заводом?
Все, що є commodity, - треба купувати. Це мається на увазі те, що у всіх плюс-мінус однакова бізнес-задача. Наприклад, e-mail взагалі має бути в хмарі, і ніхто із притомних айтішників 21 століття не повинен думати про те, як він там працює і для чого він там працює. Це чистий commodity, його треба купувати задешево у тих, хто його виробляє тоннами. Commodity - це просто як зерно, метал, електрика і автономні сервіси в IТ базового інфраструктурного рівня. Все, що є диференціатором, треба все-таки будувати. Як, на чому і так далі - це трошки інше питання. Разом з тим є речі, які є диференціаторами, які дуже вузькі...
20:54 Диференціаторами чого?
Бізнес-моделі. Перед тим, як прийняти це рішення, спеціальні хлопці поїхали на конференцію в Штати. Це була конференція Caterpillar саме з CRC. Такі ж заводи є у багатьох дилерів, звичайно. Бо це дуже вигідно, вигідна інвестиція. Якщо в тебе є завод, то там дуже велика економія на тому, що не треба із Caterpillar возити всі компоненти, і ти сам повністю управляєш всім циклом. Там розглядалось питання автоматизації. В результаті стало зрозуміло, що "хто в луг, а хто в плуг" - немає ні одного стандарту, немає рішення. Тобто парадокс: є купа заводів, і немає ніякого рішення, яке можна просто прийти і купити. Значить, його треба робити з нуля. А якщо його треба робити з нуля, то треба правильно зрозуміти, що таке платформа. Це не означає, що ми візьмемо якусь мову програмування, і будемо з нуля конструювати. Звичайно, ми виберемо якусь платформу під веб-додатки, яка буде давати базову функціональність. Для мене платформа - це все-таки галузеве рішення, яке треба кастомізувати і впроваджувати. А тут мова йде про створення такої платформи. Але є платформа нижнього рівня - це саме на чому це робити. Але ми поки що не вибрали, ми в процесі.
22:18 У процесі ви і всі інші дилери? Це буде єдина річ чи тільки ваша?
Ні, це буде тільки для Zeppelin. Zeppelin - наш стратегічний бізнес-юніт. Справа в тому, що гірське видобування, отакі CRC є тільки на пострадянському просторі. Їх немає в Європі, бо там немає гірського видобування. Там нема шахт - вони всі закриті, там немає оцих великих машин, бо вони там просто непотрібні.
22:47 А чому так? Вони всю сировину купують в інших країнах?
Звичайно!
22:51 Ти згадав, що є системи, інтегровані з Caterpillar за процесами, так?
І з основними замовниками теж….
Так. Я так розумію, що в Caterpillar це стикування... Тому що ми робимо проєкт, і я розумію процеси, але ми не беремо участі в тих процесах, які стосуються вашого замовника. В Caterpillar пішло замовлення, ви переходите на API, і воно там комплектується, вам фідбеком скомплектовано, поїхало- приїхало, і далі. Прості речі, які зараз стандартні для великого постачальника. А з клієнтом ключовим це на базі чого? Тобто чи передає техніка, коли її треба ремонтувати? Як вона інтегрована?
Процесна інтеграція із замовником приблизно така: замовник український… В чому дуже велика проблема українського суспільства? Будь-якого посттоталітарного суспільства. Вона називається "Слабкі інститути і низький рівень соціального капіталу". Що таке соціальний капітал? Це дуже проста штука: наскільки люди один одному довіряють. У нас не довіряють. У нас домовитись двом бізнесам між собою - це товстенний контракт, перепихування ризиків туди-сюди... Ми дивуємося, що там (в Європі чи США) прийшли, отак от руки потиснули - і все: бізнес, і слово щось важить. У нас репутація нічого не важить, бо ніхто цій репутації не довіряє, немає довіри. В результаті, так домовитися американська компанія з німецькою можуть, а українська з українською не можуть.
24:33 Про дизрапшн корпоративних єдинорогів - навіщо компанії підривати власні бізнес-моделі?
Основна ідея технології, яку обрала компанія Zeppelin, полягає в цьому: фабрика стартапів діє не за класичною моделлю стартапів, не за кількома класичними моделями стартапів. А саме: у стартапів монетизація, тобто виграш тих, хто це все організовує, буває двох типів. Або це продаж, тобто ти розвиваєш, розвиваєш, розвинуту якусь продав, і в цей момент якраз ти і фіксуєш дохід.
Всі заробляють на виході.
Так. Другий варіант: постійний фандрайзинг. Тобто постійний ріст клієнтської бази, - ти реальним клієнтам нічого не продаєш плюс-мінус. Як Твіттер. Твіттер заробляє небагато, але їм постійно заносять гроші, бо купа користувачів зрозуміла, що це може бути щось корисне у майбутньому.
А може і не бути.
Може й не бути, звичайно. Twitter 2 рази за останні 4 роки був на межі банкрутства. Але поки що не збанкрутувала компанія. І вони все ще думають, як би їм монетизувати і щось зробити.
Так от, жодна з цих двох тем нам не підходить як компанії, у якої успішний бізнес в індустрії. Тобто ми не збираємося робити стартапи на продаж. Ми не збираємося нарощувати базу заради бази, просто фандрайзинг якийсь, тому що ми навіть з чужими інвестиціями дуже обережні. В результаті нам потрібно конкретно виростити бізнес-модель, яка буде давати дивіденди бізнесу. Це дуже нестандартний для стартапів шлях, він реально нестандартний .
26:27 А ось тут є важливий момент: ви просто їх вирощуєте? У дизрапшена є визначення - воно руйнує попередню бізнес-модель.
Ні, це перший компонент. Для чого ми це робимо. Другий компонент - це технологія, яка називається Nightmare Competitor. Уве Грьотте, є такий автор, він навіть книжку написав на цю тему. І там сенс такий, що є технологія стратегічного менеджменту розробки стратегії, яка дозволяє зрозуміти, за яким вектором може бути атака на конкретну галузь, тобто звідки може прийти компанія, яка винесе всіх ногами вперед. І один із сенсів існування компанії Zlab полягає в тому, що ми маємо на найбільш ймовірних або найбільш очевидних векторах атаки поставити свої стартапи невеликі, для того щоб просто підняти поріг входу для інших в галузі. І плюс ми заодно тестимо, наскільки ця ідея є підривною.
Тобто це протидія зовнішньому дизрапшену через керований внутрішній дизрапшн.
IТ-стратегія і архітектура підприємства - це як інь і янь. Стратегія - це про переходи, архітектура - про стани.
Для того, щоб побудувати стратегію, треба визначитися з певною стратегічною ідеєю, яка описується такими поняттями як місія, бачення, цінності. Для чого ти щось робиш, бачення якесь довгострокове і цінності - як ти це робиш, як ти це не робиш. А потім треба зрозуміти, де ми є зараз.
28:12 Що важливіше: як ти це робиш чи як ти це не робиш?
Цінності - це про те, що заборонено. Вони говорять, як себе вести погано. Взяти стандартні цінності - наш рідний вбудований іудо-християнський етичний імператив. Він зводиться до 10 заповідей, які перестали носити релігійний характер. Вони розділені усіма. І ніхто зараз не буде сперечатися: "не убий", "не укради". Ok, "не укради" у нас не всі розділяють, але значна частина...
Чули таке? Верховна Рада України вирішила прийняти 10 заповідей і зараз працює над поправками... Поправки, доповнення: "не убий" - кома там і... "Не укради" - кома і розшифровочка, що ж це на практиці має означати.
То, відповідно, потім ти починаєш описувати архітектуру, яка є, потім ти описуєш цільову архітектуру, а потім описуєш перехід. І з цього всього ти отримуєш стратегію. Стратегія - це перехід, а поточна цільова архітектура - це зрізи. Люди намагаються писати стратегію, а виходить стратегічний план. Нічого спільного ці два документи - управлінських інструменти - між собою не мають. Стратегічний план витікає зі стратегії. Без стратегії стратегічний план - це шлак. Це просто перелік проєктів, які ми хочемо зробити. Ні а чьом. Нічого не дає сам по собі.
29:45 Друга стандартна помилка - люди потрапляють в пастку паралічу аналізу (paralysis by analysis), яка полягає в тому, що вони 90 - 95% часу витрачають на опис архітектури as-is. Повний провал, зубожіння, і змова, і зрада - все неправильно.
10% часу, які планується витратити на архітектурний статичний процес, треба приділити тому, де ти є зараз, 70% - це архітектура, архітектурне бачення на 2-3 роки, і приблизно 10-15% - це на довгострокову архітектуру.
Основний фокус має бути на тому, де ми зараз, але детально описати, куди ми хочемо перейти.
30:30 Архітектура - це дуже комплексна штука.
Третя основна помилка, якої люди часто припускаються в архітектурі, - вони намагаються архітектуру описати повністю. Архітектура - це комплексна штука, яку можна тільки моделювати, і з якою треба бути вкрай обережним. Фактично документ, у якого немає читача, не треба писати взагалі. Це абсурд. Для чого писати? Люди щось пишуть, щоб потім прочитати. Якщо ніхто не збирається читати, навіщо писати?
В результаті архітектура стає непід’ємною задачею, тому що намагаються згенерувати 50 якихось артефактів, 50 View чи таблиць, діаграм - неважливо. Мруть на цьому, кидають і кажуть, що то все непотрібно. Насправді стратегія, стратегічний процес, enterprise architecture - це архіпотужні інструменти. Але вони складні.
І для того, щоб зробити так, щоб вони не вимагали 30 років часу, щоб ними користуватися, треба їх дуже добре зрозуміти. А це непросто.
31:34 Провокаційне питання: як тоді перейти до to be? Ми про одне й те ж говоримо? As is-архітектура і as is-процес у впровадженні якогось програмного продукту - це одне і те ж саме чи це різні речі?
As is-процес... Є процес генерації компонентів архітектури: ми впроваджуємо, припустимо, якийсь продукт, він має сам по собі бути якісним, щось там показувати хороше. Всі прекрасно знають, що зараз основна цінність будь-якого додатку, будь-якої програми полягає у тому, наскільки вона добре взаємодіє з іншими програмами. Все, що вона робить всередині, всі вони роблять плюс-мінус добре і створюють дуже мало цінності. Тобто ізольовано одна система, одна програма не створює цінності. Тільки екосистема. Так? Тільки інтегруючись з усіми іншими системами в цій екосистемі, створюється загальна цінність.
Сам процес випуску якогось компоненту, його запуск і обслуговування - це те, що ти говориш: процес розробки, впровадження і так далі, і так далі. Але цим архітектура не займається. Архітектура - це не про те, як ми робимо.
Архітектура - це не про процеси, архітектура - це про компоненти, з яких вона складається.
32:57 Якщо ми говоримо про архітектуру, там одне із основних ключових понять - це capability. Capability у бізнес-архітектурі, в архітектурі підприємства - це фактично такий будівельний блок всієї архітектури. Capability - це здатність або спроможність щось робити на тому ринку, на якому ми є. Наприклад, у нас може бути ряд capabilities із управління людськими ресурсами, у нас може бути ряд capabilities, пов'язаних з продажем, з маркетингом, з виробництвом, ряд capabilities, пов'язаних із сервісним обслуговуванням і т.д., і т.д. Capability - базове поняття. Воно складається з чотирьох частин.
Для того, щоб у нас з’явилося capability, нам потрібні, по-перше, люди - це саме ті люди, які роблять бізнес, здійснюють цю capability, реалізують її.
Операційні люди?
Так.
34:01 Чи може бути capability без людини?
Так, capability може бути без людини, якщо вона повністю автоматична. Абсолютно таке може бути. Скажемо так: це не є необхідним, але це є компоненти, як треба описувати кожну capability. Значить, у capability є:
З точки зору архітектури підприємства такі 4 частини складають кожну capability. І тут саме не про те, яка capability йде за якою. Ні, це як capability пов'язані між собою. Припустимо, для якоїсь capability потрібно, щоб добре працювали ряд інших capability. І це виходить така мережа із capability, де capability впливають одна на одну.
І далі ми можемо говорити про наступне: якісь capability у нас в нормі, добре працюють, якісь є дискримінаційним фактором, тобто вони гірші, ніж нам потрібно, тобто їх треба дотягувати. Або, наприклад, якісь capability у нас відсутні, тому що ми вирішили розширитись, вийти на якийсь новий ринок, тому нам потрібні нові capability, яких у нас раніше не було. Просте питання: для того, щоб ми просунулись у якомусь новому для нас напрямку, що ми повинні вміти?
35:30 У нас тут несподіваний поворот. До речі, ми їдемо якоюсь неконвенціальною дорогою. Я просто часто їжджу. І це якась інноваційна дорога.
Краща чи гірша? Чи така ж, як інші?
Російською мовою цей жарт звучить так: "Ребята, не расстраивайтесь! Вы не хуже, вы просто жиже". Так що це ті ж абсолютно дороги, тільки в профіль. Як і там.
То капабіліті – це просте поняття. Тільки, як і в кожне таке фундаментальне поняття, в нього треба нормально так голову занурити для того, щоб його реально зрозуміти, щоб його можна було просто пояснити. І фактично все зводиться до того, що бізнес має сказати, які capability слід розвивати.
Просто план розвитку capability: нам потрібні отакі 3 нові і такі дві поремонтувати.
36:34 Як часто ми повинні переглядати, на твою думку, набір цих capabilities?
За зміни бізнес-моделі, за розширення продуктової лінійки, за виходу на новий ринок, за суттєвої зміни в напрямку розвитку компанії.
Якщо цих змін немає, то не треба їх переглядати?
Не треба їх переглядати. Ти маєш слідкувати за тим, щоб у них, у цих самих капабілітіс, була зрілість, яка тебе задовольняє. Тобто ти тоді просто розмічаєш всі ці capabilities на точки вдосконалень і певним чином вибираєш: я зараз вдосконалюю цю, вдосконалюю цю, вдосконалюю цю.. Завжди у кожної компанії є капабілітіс більш слабкі, які генерують так звану pain point, “точку болю”. Якісь більш сильні, їх не треба чіпати.
37:21 В одному з виступів ти говорив про так звані View для певних стейкхолдерів.
Тут важливе розуміння: архітектура - складна для будь-якого середнього розміру підприємства... Архітектура - це складна сутність, її не можна просто так взяти і описати. Ніяк. І це не має ніякої практичної користі. Архітектура - це інструмент прийняття певних рішень і отримання певної інформації. Для того, щоб зрозуміти, як описувати архітектуру в кожному конкретному випадку, алгоритм виглядає таким чином:
Ми не описуємо архітектуру, тому що це прикольно, тому що це красиво, тому що це молодіжно, по-хіпстерськи, елегантно чи айтішникам-задротам подобається навалювати архітектуру тільки тому, що це круто звучить: "Я - архітектор систем". Ні. Ми пишемо View під конкретний viewpoint, який є комбінацією stakeholder + concern. Якщо таких стейкхолдерів у нас 2, а консьорнів у них 2 або 1, значить, вся наша архітектура буде складатися з одного артефакта, який конкретно це описує. І все, і більше нічого. І ми тоді можемо говорити: ага, це такий зріз і такий.
39:27 Це не означає, що це одна система?
Це нічого взагалі не означає, це всі системи. Ще раз: для того, щоб бути прагматичними, ми маємо робити цінність. Цінність архітектури не в тому, що в тебе все описано про запас - а раптом це знадобиться чи так прикольно. Ні, ти прагматично обираєш тільки ті точки, які тобі реально потрібні. При цьому ІТ сам по собі є стейкхолдером, має певні concern-и. І ІТ сам для себе, але в такому форматі, як нам треба, може генерувати певні артефакти. Але зовні таких артефактів може бути зовсім мало. Для мене архітектура - це інструмент, молоток.
Ми ж для чогось пишемо якісь регуляції, наприклад, як сходити у відпустку…
40:07 Можливо, все це утворилося з того, що консалтингові компанії, найчастіше… Всередині досить рідко це описується. Це швидше виняток, ніж правило, принаймні для нашого ринку, і того, з чим я стикаюся. Принаймні таких документів, які ти показував у презентації, я не бачив в Україні в принципі, такого підходу.
Їх і в світі не побачиш.
Так, і в світі це поодинокі компанії роблять. І коли приводять консалтингову компанію, то вони не можуть здати три сторінки, і виходить 50-сторінковий талмуд.
Тому що консалтингові компанії не вміють. Навіть крупні. Крупні продають просто свої готові фреймворки. А там… знаєш приказку: “Нравится - не нравится - спи, моя красавица”. Ви Framework купили у IBM - значить, "православна добрана з Божою поміччю" - значить, все - штамп!
Вони не можуть пояснити, у чому цінність, бо це складно. Компанія не може зрозуміти, в чому цінність. Сама компанія, яка купує, і вона купує кількість замість якості. Кількість легше зрозуміти: от є стільки - 120 тисяч баксів – О, то це ж моща!
41:20 Ти 12 років у компанії і починав з впровадження систем 1С:Підприємство, і потім став вже Head of IT. І, виконавши всю цю роботу, зовнішня компанія може це зробити, не перебуваючи всередині, вибудувати стратегію?
Я думаю, що відповідь трошки складніша. Вона може це зробити, разом з тим ця стратегія не буде виконана. У компанії не буде ownership на цей результат. Тобто це буде результат не компанії. Має компанія це робити, наприклад, за допомогою консультантів, але не консультанти це роблять. Компанія робить - консультанти допомагають. Компанія має стати власником цього документа. Вони мають його прожити і відчути. Я думаю, що стратегічний менеджмент, взагалі, - це не те, що можна віддавати у outsource за будь-яких розкладів. А стратегічний менеджмент в найбільш важливих напрямках, а це на даний момент ключова компетенція, - ІТ і люди.
42:23 Ще на одному слайді ти показував, що ви вибрали всі трибуквенні абревіатури - ERP, CRM, BI і так далі - і потім узгоджували, що вам потрібно для бізнесу. З ким узгоджували? Тобто якісь критерії були?
Ми обрали ті з них, які в принципі можуть бути застосовані до нашого бізнесу. Зокрема у нас немає PLM-систем, чи якихось таких. І ми намалювали карту всіх систем, які можуть бути, їх виявилось насправді не так багато порівняно з тим, що в нас уже було. І ми це узгоджували з CIO і CFO.
Тобто CIO і CFO ми сказали, що наше бачення таке: отакі системи у нас є, отакі системи ми зараз будуємо, а такі системи ми збираємося не робити. Ми можемо їх собі брати, але ми вважаємо, що це недоцільно на нашому конкретному етапі життєвого циклу і т.д.
43:14 Ти розповідав про IT-Enterprise, з яким зіткнувся в процесі інтеграції, і, я так розумію, брав участь у постановці низки завдань, які були для стикування. Відгук якийсь про систему, наскільки взагалі система передова і відповідає ERP-шному класу, і наскільки легко було з хлопцями це все робити та інтегрувати?
Мене ця система не вразила, нічим не вразила. Звичайна нормальна система. Інтегруватися з нею було непросто. Це було кілька років тому, треба враховувати, що ми говоримо про 4-5 років тому, коли ми виконували той проєкт. На той момент вона не давала кількох технологічних можливостей, які нам були потрібні, але я вже деталей не пам'ятаю. Загальне враження можу сказати. Найважче було узгоджувати з ними постановку задачі там, де зараз сидять люди, і врукопашну щось роблять, це здебільшого замінялось роботами, замінялось алгоритмами, функції діджиталізувалися. І був певний супротив у тих, чиї це співробітники, бо у них фактично пропадала робота.
44:22 У виступі Enterprise mobility ви розповідали, що побачили тренд, і ви вже якісь частини зробили. Які?
Так, електронне замовлення-наряд для сервіс-інженера і електронний юридично значимий документообіг. Що це означає? Це означає, що механік абсолютно все, що йому потрібно, виконує на планшеті, він не користується лептопом. Насправді користується, але трошки інша тема. Він все робить на планшеті, клієнт розписується на планшеті - прямо ставить підпис. Це автоматично уже перетворюються всі бухгалтерські документи, і це проривний проєкт. До цього між датою "Остання дата роботи із технікою" і оплатою проходило 23 дні. Зараз 3. І це те, що я називаю результатом. Там нічого не треба міряти - все видно неозброєним оком: було - стало.
45:14 У вас в архітектурі базовий фреймворк Togaf, так? Як ви його обирали, з чим порівнювали і чому на ньому зупинилися?
Я перечитав абсолютно всі, всі, які є: Dodaf, Togaf, Zachman. Togaf найбільш інструментальний, Togaf найбільш методологічний - як його виконати покроково, найкраще розписано у Togaf. Zachman - він прекрасний як теоретична модель. Як практичний інструмент він слабкий. Коли ти береш Zachman, ти потрапляєш в ситуацію, коли "Все зрозуміло, але що конкретно ти мала на увазі?". І далі що? Там все починає ставати досить напруженим. Одним словом, я не хочу сказати, що Togaf найкращий, для нашої задачі ті матеріали, на яких можна було вчитися, як це робити, його стиковка з Кобітом, його стиковка з рядом інших стандартів, які ми використовуємо. І також важливо було те, що у нас була можливість досить дешево придбати інструмент для обліку архітектури. Тобто є програми, в яких описується архітектура. У нас був інструмент конкретний, і через це ми вибрали Togaf.
Я хочу сказати, що Togaf із них всіх, мені здається, найкраще розвивається і найбільш підходить. Хоча консультанти би, напевне, радили щось інше.
46:48 Ти показував на виступі слайдик, в якому таке ось "в світле майбутнє" - сонечко, де проєкти розташовані, і кажеш, що коли ви показали бізнесу, їм дуже сподобався підхід. Це частина якої методології?
Звичайно. Це Togaf, це одна із View, рекомендованих у Togaf.
Їх там багато?
Їх дуже багато.
Togaf - це framework, який описує всю архітектуру. Тобто якщо ти вирішив заморочитися і зробити незрозуміло для чого теоретично-аналітичну роботу... Ні, продукти всі не генерує, звичайно. Це не те, що в тебе є продукти, ти дані заповнив, кнопку натиснув і візуалізував. Ні, там є це все, але там дуже важко поставити задачу на розробку такого продукту, бо все таке дуже різноманітне, всі ці в’юхи, там не все так просто з ними. Через це вони частково автоматизовані, частково ми їх робимо вручну. Але вони оновлюються комфортно часто, для того щоб те, що вони роблять це вручну, не було складністю.
47:50 Чому функція ця пішла в ІТ? Насправді дані, які показуються, суто бізнесові. Чому? І чи повинна ця функція бути у ІТ?
10 років тому я б сказав: "Ні, не повинна". Зараз би я сказав: "Так, повинна". У мене взагалі є таке бачення, що потрібен СDO, як там його не називай. Коротше, в мене бачення таке: business development, IT, digitalization мають бути всі в одному флаконі. Тобто ті, хто методологічно розробляє бізнес-процеси, і ті, хто робить автоматизацію, мають просто бути в одному, і керувати цим повинен C рівня…
Вже не CIO?
Не CIO.
Це движок із розвитку всього підприємства, і це не Continuous improvement, про який ми багато сьогодні говорили, не безперервне вдосконалення, бо воно про рівень все-таки... Це все підлога, це рівень тактики. А те, про що я говорю, це все-таки і рівень стратегії теж. Але воно одне іншому не суперечить абсолютно.
Відверто кажучи, виділяти відділ, який відповідає за розвиток і постійне вдосконалення, я відчуваю, це шлях в нікуди. Поясню. Якщо цей відділ має задачі впровадити культуру постійного вдосконалення у всій компанії, на всіх її розкатати - я це приймаю. Якщо це відділ, який має генерувати ідеї сам і їх реалізовувати, то це мені нагадує, що нам потрібні інновації в компанії. І ми зараз наймемо Сидора Петровича Креативного, і він у нас буде директором із інновацій, і він нам зробить інновації, так? Так воно не працює.
Інновації будуть тоді, коли це культура усієї компанії. Бо там потрібна маса невеличких експериментів, які робляться паралельно. Купа! І вони мають бути в кожному відділі, в кожній кімнаті мають бути ці експерименти, якщо ми хочемо реальних інновацій. Бо ніхто не знає, де вони беруться.
Конкретний приклад: компанія - здається, це був Colgate, хоча можу помилятися, - вони сиділи і думали, як їм підняти продажі. Сиділи там щось, думали-думали... Знаєш цю історію?
Я згадав цю історію. Це про прибиральницю, яка запропонувала зробити більшою дірочку в тюбику?
Так. Вони просто збільшили діаметр вихідного отвору, і в них на 60% виросли продажі, от просто виросли.
Реальні інновації з’являються тоді, коли всі в них задіяні. Абсолютно всі. Це певний елемент культури дуже важливий.
А знаєш, що найбільш гальмує інновації? Людей б'ють за їх помилки. Якщо людей бити за їх помилки, про інновації можна забути як про слово взагалі. А не бити людей за помилки - так це треба їм довіряти. А це складно. Через це: немає довіри на підприємстві - забудьте про інновації. Забудьте таке слово говорити взагалі .
50:59 До речі, дивно... Я ж нічого не роблю зараз.
Це воно самостійно? Автопілот?
Так.
Нічого собі!
Я здивувався. У мене круїз врубив 130, і їдеш, але вона тобі не гальмує. Ця гальмує. Тобто ти взагалі нічого не робиш, я не натискаю нікуди зараз.
Я думаю, якщо б ти ще й кермо пустив зараз, воно б ще й підрулювало. Воно просто не палиться, щоб ти не втратив взагалі відчуття…
О
Воно і відео підзнімає.
І вже викладає кудись.
☺
51:42 Послухайте жарт: дівчина сідає в таксі, а там нема водія. Вона говорить: "Ух ти! Тут що, автопілот?". Він говорить: "Так, я автопілот". Вона: "Як прикольно! Я вперше їду в автомобілі, де автопілот". Робот відповідає: "Тільки ж ви не подумайте, насправді я штучний інтелект для бізнесу, а в таксі це так..".
52:06 Я симпатизую платформі 1С:Підприємство, бо я з нею багато працював, і був розробником 1С:Підприємство у свій час. І PM в 1С:Підприємство, і business в 1С:Підприємство. І вона мені дуже зрозуміла. Якщо порівнювати 1С:Підприємство із SAP, то 1С:Підприємство рухається із нуля вгору, a SAP рухається з неба кудись униз. І десь вони зустрілись, в якомусь середньому сегменті.
10-12 років тому 1С:Підприємство не міг в принципі тягнути тисячу користувачів. От не міг - платформа була не готова. Зараз вона готова, звичайно, це всі знають. Тоді вона була просто не готова. Через це якщо треба було багато всього, то SAP безальтернативний.
Друге: якщо ми говоримо про 1С:Підприємство, то 1С:Підприємство для великих компаній трохи незручний саме тим, що у ньому все можна. Тобто в 1С:Підприємство ти можеш зробити все, що завгодно, причому дешево і швидко. Разом з тим, відстрілювання кінцівок - це просто запросто у процесному сенсі, тому що немає контролів ніяких. Незріла конфігурація, вони ще не знають, як не можна, і цього всього немає.
В SAP же навпаки. В Сапі ніякої гнучкості особливої, але вона дає такий framework, на який ти зразу можеш спиратися.
Що є повним провалом у SAP порівняно із 1С:Підприємство?
У тебе зараз в портфелі проєктів SAP є в тому числі?
Звичайно!
Основна система у нас - це SAP. Другорядна - це 1С:Підприємство. ERP.
Те, що в 1С:Підприємство називається регістрами обліку, і воно абсолютно безшовне і нативне, прямо ось воно: транзакції і регістри, переплетено. В SAP ці регістри в окремому компоненті, який треба окремо програмувати, і вони всі нестандартні... І капець. Тобто є в них регістри... В них в самому SAP всередині немає такого поняття як регістр, там нема можливості дізнатися, що було вчора. Уяви собі: робити звіти з транзакціями без регістрів. Сторно на сторно, оці всі божевільні ланцюжки розкручувати. Тобто великою мірою там будь-яка нестандартна функціональність вимагає дизайну нового контуру з регістрами... Це очманіти просто, як складно.
І в SAP проблема з тими, хто його впроваджує... Там є бізнес. В SAP це серйозний системний бізнес. Разом з тим, через те, що там дуже велика платформа, велике рішення, поріг входження дуже високий, і справжніх спеціалістів теж мало, які можуть реально увімкнути SAP так, як слід. А не як вийде.
І дуже велика проблема, з якою Zeppelin стикнувся… В 1С:Підприємство це менше виявляється, бо це стандартний підхід. Там викликаєш, говориш: “Мені потрібно отаке”. Вони так клавіатуру одразу на стіл: “Зараз запрограмуємо!”. І починається… Розумієш? Нема такого: “Почекайте! А може вам так і отак? Трошки не так, як ви хочете, але три стандартні компоненти, і ми не відкриваємо чорну скриньку?". От такого компонента практично немає в 1С:Підприємство. Зараз він з’являється, але протягом останніх 20 років його була гомеопатична доза. В SAP, на жаль, те саме. Ти розумієш? Вони приходять і говорять: “Зараз ми вам напрограмуємо!”. Навіщо програмувати? Там все є! В SAP є все, хлопці!
В SAP, якщо добре копнути, то там труп Леніна всередині є, я впевнений. Там не можна такого придумати, щоб в SAP не було. Конфігурація вже 50 років як розвивається. І взагалі, ми знаємо, SAP увібрав у себе всі найбільш прогресивні інженерні технічні рішення кінця 70-х - початку 80-х років ХХ-го століття.
56:25 Вибір між SAP і 1С:Підприємство на даний момент абсолютно неочевидний. Там немає відвертого лідера, відвертого аутсайдера, сильно залежить від рівня компанії, рівня зрілості. Є випадки, які я можу добре собі уявити, - там, де без SAP ніяк. Разом з тим 1С:Підприємство - це є, напевно, дефолтна платформа для наших бізнесів, і це не даремно. Дійсно, в більшості випадків, напевно, краще підходить 1С:Підприємство, особливо для середніх і малих компаній. Для крупних компаній там треба дуже добре думати головою.
Взагалі мене дивує: яку ERP не візьми - це все просто шлак і гуано. Воно якесь кострубате, ні а чьом, якесь воно все просто... Я не знаю, начебто з минулого століття.
57:16 Дай свої рекомендації із впровадження ERP-системи для різного рівня компаній. Тобто що мається на увазі? Для різного рівня зрілості і для різного масштабу. Які критерії вибору?
Якщо компанія замислюється зараз про те, щоб впроваджувати ERP-систему, то вже треба подумати про те, як це робити правильно. Що значить “правильно” чи “неправильно”? Давайте подивимося, що було за останні 30 років. Спочатку були мейнфрейми (mainframe) і тонкі клієнти, нагадую. Був mainframe і у кожного по монітору, якась програма виконувалась централізовано на цьому мейнфреймі. Це була повна централізація.
Потім маятник зробив рух у протилежний напрямок, все стало децентралізованим, обчислення перенеслись на клієнта, на його робоче місце користувача, це був персональний комп'ютер. І точно так же децентралізувався софт. В кожному відділі в 90-х роках був свій софт: у збуту - свій, у складу - свій, в результаті ті продали на 10, бухгалтерія - на 5, у всіх якісь різні дані… Погано. Децентралізація дозволила різко наростити рівень автоматизації, але він був таким точковим і роздрібненим.
В кінці 90-х сказали: "Так жити не можна, нам потрібна монолітна система. Монолітна корпоративна інформаційна система”. І всі впроваджували моноліти. Зараз вже монолітами всі наїлись, моноліти негнучкі, моноліти потім перетворюються в дико кастомізовану адаптовану штуку, яку потім все важче і важче підтримувати. Потім ми втрачаємо швидкість доставки необхідних фіч користувачам, воно все стає повільнішим і повільнішим. На даний момент уже це намагаються якось обтікати. Я думаю, що тепер буде крен назад, в бік "роз", тобто розібрати моноліт на шматки.
59:08 Це та стратегія мікросервісів, яка популярна останнім часом.
Стратегія мікросервісів. Для того, щоб усе це трималося купи, фактично моє бачення таке: ERP має стати центральним скелетом для всіх даних, всіх і будь-яких. А всі реальні додатки мають бути певною екосистемою навколо цього ERP, і через неї всі додатки фактично обмінюються між собою. Тобто це не просто шина з даними, а це прямо такий, умовно кажучи, оркестратор всіх додатків, якими користується компанія. І оця ERP має бути велика, стандартна, і її не треба чіпати взагалі, бо вона фактично не є фронтом для користувачів, вона є таким оркестратором.
Якщо говорити про серйозні впровадження, я б уже дивився на таку архітектуру. Дивився би я на відкритість цих систем - наскільки вони відкриті, дивився б я на те, - дуже важливо - хто партнер, і щоб партнер був не один.
Мене, наприклад, лякають системи, у яких 1 чи 2 партнери в Україні. І люди йдуть до них. Для мене це занадто сильна залежність від партнерів, які в сенсі бізнесу абсолютно незрілі і можуть через півроку розпастися - посваритися між собою, наробити дитячих помилок в бізнесі і просто розійтись. Якщо ми говоримо про ERP-системи, то там фактично є цілий ряд партнерів, з якими можна працювати. Щодо решти - їх набагато менше, для мене це стоп-фактор. Тому що ERP не ставиться, її не можна змінювати раз у два роки, і це довгострокове, тому мають бути покриті довгострокові ризики. Я би обирав між SAP і BAS ERP на даний момент. А всі решта просто впроваджують 1С:Підприємство, BAS - зараз ми його так називаємо - і все. І там не йдеться про системи класу ERP.
1:01:09 З точки зору методології, з точки зору вибору продукту, з точки зору методології впровадження самого цього продукту?
З точки зору методології найкращий спосіб, який ми собі придумали, - це те, як ми зараз впроваджуємо в Zeppelin в Україні BAS ERP. Ми сказали, що спочатку ми беремо типовий продукт, і на ньому намагаємося моделювати бізнес-процеси, як вони зараз у нас є, з метою заміряти розрив між тим, як нам треба, і тим, як є зараз. Ми так, до речі, робили і минулого разу, 10 років тому майже. 9 років тому, коли ми впроваджували поточне УТП в Zeppelin Україна.
Після цього система розбивається на великі модулі, і вони реалізовуються більшою мірою каскадним підходом, тобто не гнучкими методологіями, не ітераціями, а каскладним підходом у декілька паралельних потоків. Тобто, умовно кажучи, ряд підпроєктів, які досить близькі до класичного waterfall. Я не фанатію від документації. В мене методологія така, що ми написали трошки документації, трошки коду, трошки потестили. І от вони всі зріють паралельно разом, тобто немає такого, що ми спочатку пишемо всю документацію, технічні завдання...
1:02:27 Перевпровадження ERP - тренд, який є і у нас, і в принципі в світі, але ти кажеш, що жоден новий capabilities компанії не дає, а стане точно так само. Навіщо тоді перевпроваджувати?
І так, і ні. Воно-то стане точно так само, але завдяки перевпровадженню на нову платформу ти отримуєш купу технологічних capabilities, яких до цього не було. Бізнесових ні, але технологічних: мобільний клієнт, веб-клієнт, нові підходи до безпеки і купу всього.
Причиною перевпровадження було накопичення критичної маси технічного боргу - це була основна причина. І ризик того, що систему перестане вендор підтримувати. Ось два основних фактори.
Я вважаю, що ERP-система, CRM-система, взагалі всі елементи ядра, вони як шкарпетки: їх треба періодично змінювати. Тому що всі метафори протікають. Тобто у тебе є реальність і є певна метафора або модель цієї реальності. Між ними є певні проміжки. З часом вони стають ширшими і починають протікати. Ці проміжки покриваються костильками. Як тільки цей шар костилів стає таким, який починає закривати початкову метафору, тут вже система стає некерованою. Тобто ти трошки підкрутив тут - упало в трьох інших місцях. Система перестає бути стабільною і керованою. Через це не можна нічого іншого придумати, як періодично обнуляти технічний борг і починати усе заново.
До речі, у біології це називається діти. Тому що є ДНК, і на ній наростають білки, от такі, як я. От, будь ласка, наросло білків на ДНК. Потім накопичується технічний борг, оцей організм іде в утіль, зате новий організм починає з нуля будувати білки, вже чомусь навчившись, і це еволюція.
Еволюція на системах працює так само: core ERP-систем, ядро ти ще можеш протягнути 7-8 років, до 10, але вся обв’язка буде змінюватися все частіше і частіше.
І взагалі час життя, життєвий цикл систем постійно скорочується, точно так же, як скорочується життєвий цикл побутових пристроїв. Раніше телевізор жив 25 років. Зараз коли телевізору 25 років - це буде вже не телевізор, а якийсь... Ти будеш показувати, а діти твої скажуть: “Що це таке? Оцей пристрій - що воно? Де тут голографія? Як з нього вийти в інтернет?”. А ти такий: ”З нього не можна вийти в інтернет” - “Так для чого він потрібен вам?“. Через це технологічно і технічно система не може відповідати вимогам протягом тривалого часу. Саме через це їх треба змінювати.
І це була перехідна IFRS і необхідність або суттєво доопрацьовувати систему, або вибирати нову. І ми вибрали нову.
1:05:24 В розділ діджиталізації давай. Своє визначення.
Я думаю, що кодифікація цього поняття ще не відбулася. Тобто немає єдиного якогось поняття, правильного визначення, яке б описувало, що таке цифровізація. Якщо говорити те, що нецікаво і всі знають, - це зрозумілий рух, який можна описати трьома словами: це Dematerialize, Demonetize, Dehumanize.
Якщо ми бачимо, що раніше відбувались якісь процеси, і там був матеріальний носій, а зараз він зникає - Dematerialize, тобто немає матеріалів, не застосовується матерія, а тільки якісь цифрові носії.
Якщо ми бачимо, що галузь раніше була в об'ємі 10 млрд, а стала мільярд або півмільярда - Demonetize, тобто це все стає радикально дешевшим.
І Dehumanize - раніше там було 100 тисяч людей, тепер там 5 тисяч людей.
Якщо ці три фактори є, то це точно діджиталізація справжня. А якщо їх немає, то далі можна сперечатися.
Що таке діджиталізація з точки зору нових бізнес-моделей - це одна тема, діджиталізація існуючих успішних бізнес-моделей, як їх зробити більш цифровими, або більш спотяпними в цифрове - це зовсім інша тема.
Тобто нічого кращого, ніж Dehumanize, Dematerialize, Demonetize я, напевне, не скажу. Для мене діджиталізація відрізняється від автоматизації приблизно тим, що процес в результаті його діджиталізації має ставати мінімум в 10 разів швидшим, доступ до нього має бути незалежним від пристрою. Він має бути з будь-якого тостера, - я утрирую трохи, - але з будь-якого пристрою з виходом в інтернет ти маєш можливість до нього доступитися, якось з ним провзаємодіяти. І він має суттєво здешевлювати процес і, можливо, навіть дійсно його автоматизувати повністю .
1:08:09 Ти у виступі говорив, що ІТ може відповідати за дані, а може ні. Наведи якісь приклади обох варіантів. Там був, звичайно, контекст певний.
Це так, здебільшого, класичне ІТ не відповідає за дані. Дані - це відповідальність бізнесу, який їх генерує і обробляє. Одночасно ІТ на певному етапі зрілості може відповідати за дані в двох сенсах: ІТ може за допомогою експертів побудувати певний набір евристик, які тобі діагностують якість твоїх основних даних. Беремо контрагентів - елементарно, так? Значить, ми вважаємо, що якщо у контрагента немає, припустимо, юридичної адреси, не заповнене поле, то значить якість даних там “-1” вже від якогось там значення… Або, якщо у CRM немає номерів телефонів. Є номер телефону – значить, це кращі дані, нема – гірші. А потім там більш складні евристики: якщо отут щось, то тут має бути щось. Прості правила.
А потім елементарний інструмент, який показує здоров'я твоїх ключових мастер-даних. Прямо Health check. І тоді за отакий Health check відповідає ІТ, за його здійснення, моніторинг, видачу нарядів користувачу чи користувачам на дозбирання цих даних. Тобто ІТ може дуже допомогти користувачам досягти вищого здоров'я цих даних, за які фактично відповідають, але тоді це вже стає отака відповідальність ІТ. У моїй практиці я завжди ухиляюсь від відповідальності за дані.
Чому?
Тому що ми цю ідею жодного разу ще не довели до практики. Взагалі в мене таке враження, що якість даних суттєво нижча за якість ERP-систем, які ці дані обробляють. ERP-системи, в цілому, більш високозрілі, ніж дані, і дані є обмеженням…
До речі, про ERP-системи ми говорили, так? Я б набагато більше, ніж у минулому, звернув увагу на дані і їх якість, і на той толк, який ми можемо з цих даних отримати через Data mining. Ми не говоримо про Big data, бо Big data - що це таке? У нас в Zeppelin ми думали: у нас немає ніякого Big data. Де ми його візьмемо? У нас Small data, Regular data, звичайні дані. У нас немає там трильярдів транзакцій. У нас є якісь великі об'єми даних, але вони не такі, які б свідчили про поведінку користувачів чи ще про щось.
Це не означає, що у нас немає цінних даних, у нас є маса даних нормальних, які можна аналізувати і робити над ними Data mining, якісь штуки робити. Через це увага до даних в середньому в компаніях недостатня.
1:11:06 У виступах говориш, що ІТ є гігієнічним фактором. Чому? І що змінюється і чи змінюється?
В 90-х проводили дослідження, там був бум технологій перед бумом .сom. І проводили дослідження дуже масштабні у Сполучених Штатах, інвестиції в ІТ проти EBIT. Нема кореляції. Там нема кореляції. Хоч ти багато навалюй в ІТ - отакий EBIT, мало навалюй - якийсь інший. Нема кореляції, нема абсолютно у нас емпіричних даних, які б говорили про те, що позитивно корелюють інвестиції в ІТ, в усі причому ІТ, від мишки і комп'ютера, лептопа, до якихось надсучасних систем, UIT і всього, що завгодно.
Що таке гігієнічний фактор? Гігієнічний фактор - це означає наступне: якщо він є, то це не значить нічого, якщо його нема, то геть з ринку. Візьмемо е-мейл: якщо на будь-якому сучасному підприємстві виключити е-мейл, то на завтра стануть усі процеси. Це означає, що e-mail гігієнічний, але те, що в тебе якась найкраща поштова система в світі, найкраща пошта з якимись там супер функціями, на бізнес-результат ніяк не впливає, розумієш?
Через це у мене головна гіпотеза, що ІТ - це більшою мірою гігієнічний фактор. Ти маєш переконатися в тому, що в тебе ІТ трошки краще або таке ж саме, як у твоїх конкурентів для традиційних компаній.
Я не знайшов формули, за якою узгодити те, що я чітко відчуваю, що діджиталізація - це не жарти. Це новий тренд, який конкретно на всіх вплине. І роль ІТ постійно росте. Разом з тим, я теж бачу, що це не призводить до реального бізнес-результату.
Конкретний приклад наведу. Коли у бухгалтерію занесли комп’ютер в 90-х, кількість бухгалтерів упала в 10 разів. Реально. Пам'ятаєш, як на заводі було 150 бухгалтерів? А зараз їх 20, і вони нормально за допомогою 1С:Підприємство, долота, і такої-то матері, із Божою поміччю усе там прекрасно закривають, так? Так само там був відділ - 30 чоловік розраховували зарплати, у нас розраховують зарплату троє на 2000.
Після цього з кінця 90-х я не бачив, щоб бухгалтерія зменшувалась, або будь-який відділ, хоча б один, у компаніях системно зменшився, і це можна було б якимось чином атрибувати з технологіями. Тобто мені здається, що оті прориви, які могли бути, - вони уже зроблені.
А далі, коли ти робиш на технологіях бізнес, це інше. Це зовсім інше.
А коли в тебе є бізнес, і ти хочеш його збагатити оцими інформаційними технологіями... Мені дуже сподобався прекрасний подкаст, називається The Skeptics’ Guide to the Universe. Я його кожен раз слухаю, крутий-прекрутий. Про науку, про останні дослідження і критичне мислення, дуже важливе. Він говорить, що штучний інтелект знаходиться від нас на відстані 10 років, і завжди там буде .
Чудово, додамо посилання в опис.
Подкаст The Skeptics' Guide to the Universe
Тобто 10 років, і те саме щодо іншого: ліки від раку - 10 років, і завжди там будуть.
Усі мріяли про експертні системи, які будуть підказувати і допомагати прийняти рішення. І де вони? Я їх не бачу.
1:14:36 Ти на слайді на картах pain points показував свій підхід, яким чином ви пройшлися всіма підрозділами і визначили їх, визначилися, з чим працювати. Це мені не нагадує гігієнічну функцію.
Тому що це не зовсім ІТ робота. Чому я її робив? Тому що мені була потрібна якісна ІТ-стратегія, без цього я не міг взагалі рухатися вперед. На той момент тих, хто би міг це зробити, я не знайшов. Це змушений був робити я. Дуже важливе зауваження, треба сказати. Ми побудували цю модель, але ми не ходили всіма підрозділами, це жахливий waste. Ми вибрали ті з них, стосовно яких у нас було припущення, що там найбільша кількість таких pain points, виправлення яких дасть бізнес-результат. І ми ходили до двох-трьох.
І я би радив великими літерами написати, коли хочеш поговорити про стратегічний менеджмент: “Less is more”, і фокус, який із нього випливає. “Less is more” – не треба обходити всі підрозділи, не треба.
Треба прийти туди, де директор і його зами, менеджмент компанії, і спитати: “У який відділ піти першим?”. Не треба теоретизувати, не треба по всіх. Вони, як правило, і так знають, куди треба в першу чергу йти. І треба так: беремо 3 спочатку - розбираємося із ними, а потім визначимо ще 3. А не: «Давайте ми пройдемся по всіх».
Як правило, компанія сама знає, де в неї болить і куди треба йти. І непотрібно задавати великих питань.
Через це ми ходили, але ми ходили не по всіх, ми ходили в ті напрямки, які: а) вважались стратегічно важливими, б) про які у нас була інформація, що там pain points.
1:16:22 Далі буде...
Дивитися на нашому каналі: Відео інтерв'ю з Євгенієм Осьмаком, Head of SBU IT, Zeppelin international AG >>>
Відео интерв'ю з керівниками IT індустрії на каналі Perceptron: кейси, методики роботи, параметри вибору, нові розробки та можливості.
SaaS сервіси
Програми 1С:Підприємство
CRM
ERP
Node.JS, .NET
1С:Підприємство
API, IPasS
Разработка Web Apps
1С:Підприємство Автоматизація
Аудит IT проектів
Інтеграція 1С:Підприємство
Отримуйте наші інформаційні матеріали:
Працюємо на IT-ринку з 2008 року.
Наша місія - спростити управління даними.
Copyright © 2008-2024 TQMsystems. Всі права захищені. Privacy Policy | Terms of Service