Zeppelin International - эксклюзивный дилер всемирно известного производителя промышленной техники Caterpillar, ведет деятельность в 190 филиалах 43 стран мира.
Евгений Осьмак, ИТ директор холдинга Zeppelin International,
разрабатывал функциональные стратегии, ИТ-архитектуры, вводил процессы управления проектами, программами и
портфелями, основанные на гибких методологиях (agile).
1:10 - Что общего у Илона Маска и основателя Zeppelin. История коммунального хозяйства, где работали Порше и Майбах
5:31 Zeppelin изнутри: как построена бизнес-модель. Почему Caterpillar и 1С используют схожие модели
8:58 В составе бизнеса Zeppelin не только Caterpillar. Уникальные технологии для пищевой и нефтеперерабатывающей отраслей
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 отвечать за данные бизнеса
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... Есть целый ряд систем, и в каждом из этих направлений есть человек, который выполняет архитектурную функцию в этих системах. Группа этих людей занимается архитектурным процессом на уровне холдинга. Они встречаются регулярно, решают задачи описания архитектуры, поддержки этого описания в актуальном состоянии, насколько это необходимо, и решают конкретные задачи архитектурного комитета. В частности, есть следующие бизнес требования: какую мы рекомендуем платформу, на которой их реализовывать. Это, разумеется, в зависимости от задачи мы можем реализовывать на тех или иных технологиях.
16:23 Вот есть задача: мы говорили о CRC - Component Rebuild Center - это завод в Горишних Плавнях, который занимается выполнением ремонтов, то есть они делают ремонты крупных агрегатов и компонентов.
Мы на нем сделали достаточно простую систему автоматизации, которая решала основную задачу: рекомендуемая карта процесса Caterpillar, какие технологические операции за сколько времени должен выполнять дилер. Представьте себе автомотив. Есть ТО, есть время и такие операции. Наша задача была автоматизировать выдачу нарядов механикам. То есть механик приходит и говорит: "Получить следующий наряд". Система со всего множества работ подбирает по его квалификации, по отдельным параметрам то, чем он должен заняться. Он не думает, никуда не ходит, ни у кого ничего не спрашивает - это система ему выдает наряд. Далее он получает эту штуку и нажимает кнопку "Пошел работать". И еще есть "Пауза" и "Закончил". Таким образом система автоматически, по его сигналам собирала воедино информацию, сколько он над этим реально работал, с целью понять, где мы сильно отклоняемся от стандарта, и эти конкретные операции оптимизировать.
Система была несложная. Сейчас мы пишем ее вторую версию, которая будет на порядок более функциональной, на порядок более амбициозной, и там со всеми возможными и невозможными элементами автоматизации. Очень важная функция, которая будет в этой новой системе, - это безопасность труда.
17:55 Лет пять назад мы сделали фактически бэкенд с 1С, а фронтенд - это сканер, который вы могли видеть в любом супермаркете - устройство для ввода данных с тачскрином на кассах, где большой экран, и люди выбирают какие-то блюда, выбирают какое-то меню. Соответственно, для такого устройства - это компьютер на базе Windows со специфическим этим интерфейсом...
На бэке УПП стоит или что-то другое?
УТП. И мы на УТП сделали ту функциональность, которая нужна была именно для такого процесса на том уровне зрелости. Сейчас таких CRC уже 3: один есть в России, в Армении и в Украине, и они централизованно управляются...
В Украине первый был открыт?
В Украине был первый из специализированных. Исторически первый проект в России, но он был адаптированный определенный цех под. В Украине это был прямо с нуля построенный под эту задачу первый. Сейчас архитектурный комитет, один из вопросов которого: есть задача, надо написать софт, будет управлять процессами этих трех заводов. И мы решили, что, во-первых, он должен быть один. Значит, он должен быть не в SAP, не в 1С, то есть не на ERP. Потому что нет. В результате мы пришли к выводу, что это будет Web-application, Web-приложение, которое будет централизованно, и централизованно будет управлять этими тремя.
19:37 Web-application без платформы, без привязки? Вы сами с нуля будете его строить? Рационально это с точки зрения архитектуры? Здесь можно, конечно, зацепить теорему Геделя по поводу софта. Как правильно строить собственное приложение по управлению заводом?
Все, что есть commodity - нужно покупать. Это имеется в виду то, что у всех плюс-минус одинаковая бизнес-задача. Например, e-mail вообще должен быть в облаке, и никто из вменяемых айтишников 21 века не должен думать о том, как он там работает и для чего он там работает. Это чистый commodity, его надо покупать по дешевке у тех, кто его производит тоннами. Commodity - это просто зерно, металл, электричество и автономные сервисы в ИТ базового инфраструктурного уровня. Все, что является дифференциатором, нужно все-таки строить. Как, на чем и так далее - это немножко другой вопрос. Вместе с тем есть вещи, которые являются дифференциаторами, которые очень узкие...
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 заключается в том, что мы должны в наиболее вероятных или наиболее очевидных векторах атаки поставить свои стартапы небольшие, для того чтобы просто поднять порог входа для других в отрасли. И плюс мы заодно тестим, насколько эта идея подрывная.
То есть это противодействие внешнему дизрапшену через управляемый внутренний дизрапшн.
IT-стратегия и архитектура предприятия - это как инь и янь. Стратегия - это о переходах, архитектура - о состояниях.
Для того, чтобы построить стратегию, надо определиться с некой стратегической идеей, которая описывается такими понятиями как миссия, видение, ценности. Для чего ты что-то делаешь, видение какое-то долгосрочное и ценности - как ты это делаешь, как ты это не делаешь. А потом надо понять, где мы сейчас.
28:12 Что важнее: как ты это делаешь или как ты это не делаешь?
Конечно, ценности - это о том, что запрещено. Они говорят, как себя вести плохо. Взять стандартные ценности - наш родной встроенный иудо-христианский нравственный императив. Он сводится к 10 заповедям, которые перестали носить религиозный характер. Они разделены всеми. И никто сейчас не будет спорить: "не убий», «не укради»… Ok, «не укради" у нас не все разделяют, но значительная часть ...
Слышали такое? Верховная Рада Украины решила принять 10 заповедей и сейчас работает над поправками... Поправки, дополнения: "не убий" - запятая там и... "Не укради" - запятая и расшифровочка, что же это на практике должно означать.
Соответственно, потом ты начинаешь описывать архитектуру, которая есть, потом ты описываешь целевую архитектуру, а потом описываешь переход. И из всего этого ты получаешь стратегию. Стратегия - это переход, а текущая целевая архитектура - это срезы. Люди пытаются писать стратегию, а значит стратегический план. Ничего общего эти два документа - управленческих инструмента - между собой не имеют. Стратегический план следует из стратегии. Без стратегии стратегический план - это шлак. Это просто перечень проектов, которые мы хотим сделать. Ни о чем. Ничего не дает сам по себе.
29:45 Вторая стандартная ошибка - люди попадают в ловушку паралича анализа (paralysis by analysis), которая заключается в том, что они 90 - 95% времени тратят на описание архитектуры as-is. Полный провал, обнищание, и заговор, и предательство - все неправильно.
10% времени, которые планируется потратить на архитектурный статичныий процесс, надо уделить тому, где ты сейчас, 70% - это архитектура, архитектурное видение на 2-3 года, и примерно 10-15% - это на долгосрочную архитектуру.
Основной фокус должен быть на том, плюс-минус где мы сейчас, но подробно описать, куда мы хотим перейти.
Архитектура - это очень комплексная штука.
Третья основная ошибка, которую люди часто допускают в архитектуре, - они пытаются архитектуру описать полностью. Архитектура - это комплексная штука, которую можно только моделировать, и с которой надо быть крайне осторожным. Фактически документ, у которого нет читателя, не надо писать вообще. Это абсурд. Для чего писать? Люди что-то пишут, чтобы потом прочитать. Если никто не собирается читать, зачем писать?
В результате архитектура становится неподъемной задачей, так как пытаются сгенерировать 50 каких-то артефактов, 50 View или таблиц, диаграмм - неважно. Мрут на этом, бросают и говорят, что это все не нужно. На самом деле стратегия, стратегический процесс, enterprise architecture - это архимощные инструменты. Но они сложные.
31:25 И для того, чтобы сделать так, чтобы они не требовали 30 лет времени, чтобы ими пользоваться, надо их очень хорошо понять. А это непросто.
31:34 Провокационный вопрос: как тогда перейти к to be? Мы об одном и том же говорим? As is-архитектура и as is-процесс во внедрении какого-то программного продукта - это одно и то же или это разные вещи?
As is-процесс... Есть процесс генерации компонентов архитектуры: мы внедряем, допустим, какой-то продукт, он сам по себе должен быть качественным, что-то там показывать хорошее. Все прекрасно знают, что сейчас основная ценность любого приложения, любой программы состоит в том, насколько она хорошо взаимодействует с другими программами. Все, что она делает внутри, все они делают плюс-минус хорошо и создают очень мало ценности. То есть изолированно одна система, одна программа не создает ценности. Только экосистема. Да? Только интегрируясь со всеми другими системами в этой экосистеме, создается общая ценность.
Сам процесс выпуска какого-то компонента, его запуск и обслуживание - это то, что ты говоришь: процесс разработки, внедрения и так далее, и так далее. Но этим архитектура не занимается.
Архитектура - это не о том, как мы делаем. Архитектура - это не о процессах, архитектура - это о компонентах, из которых она состоит.
32:57 Если мы говорим об архитектуре, там одно из основных ключевых понятий - это capability. Capability в бизнес-архитектуре, в архитектуре предприятия - это фактически такой строительный блок всей архитектуры. Capability - это способность или возможность что-то делать на том рынке, на котором мы есть. Например, у нас может быть ряд capabilities по управлению человеческими ресурсами, у нас может быть ряд capabilities, связанных с продажей, с маркетингом, с производством, ряд capabilities, связанных с сервисным обслуживанием и т.д., и т.д. Capability - базовое понятие. Оно состоит из четырех частей.
Для того, чтобы у нас появилось capability, нам нужны, во-первых, люди - это те люди, которые делают бизнес, осуществляют эту capability, реализуют ее.
Операционные люди?
Да. Возьмем IT-компанию...
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 Это не означает, что это одна какая-то система?
Это ничего вообще не означает, это все системы. Еще раз: для того, чтобы быть прагматичным, мы должны делать ценность. Ценность архитектуры не в том, что у тебя все описано впрок - а вдруг это понадобится или так прикольно. Нет, ты прагматично выбираешь только те точки, которые тебе реально нужны. При этом IT сам по себе является стейкхолдером, имеет определенные concern-ы. И IT для себя, но в таком формате, как нам надо, может генерировать определенные артефакты. Но внешне таких артефактов может быть совсем мало. Для меня архитектура - это инструмент, молоток.
Мы для чего-то пишем какие-то регуляции, например, как сходить в отпуск...
40:07 Может быть, все это образовалось из того, что консалтинговые компании, чаще всего... Внутри довольно редко это описывается. Это скорее исключение, чем правило, по крайней мере для нашего рынка, и того, с чем я сталкиваюсь. По крайней мере таких документов, которые ты показывал в презентации, я не видел в Украине в принципе, такого подхода.
Да их и в мире не увидишь.
Да, и, наверное, в мире это единичные компании делают. И, возможно, когда приводят консалтинговую компанию, то они не могут сдать три страницы, и получается 50-страничный талмуд.
Потому что консалтинговые компании не умеют. Даже крупные. Крупные продают просто свои готовые фреймворки. А там... знаешь поговорку: «Нравится - не нравится - спи, моя красавица". Вы Framework купили у IBM - значит, "православная выбрана с Божьей помощью» - значит, все - штамп!
Они не могут объяснить, в чем ценность, потому что это сложно. Компания не может понять, в чем ценность. Сама компания, которая покупает, и она покупает количество вместо качества. Количество легче понять: вот есть столько - 120 000 долларов - О, так это же моща!
41:20 Ты 12 лет в компании и начинал с внедрения систем 1С, а потом стал уже Head of IT. И, выполнив всю эту работу, внешняя компания может это сделать, не находясь внутри, выстроить стратегию?
Я думаю, что ответ немного сложнее. Она может это сделать, вместе с тем эта стратегия не будет выполнена. У компании не будет ownership на этот результат. То есть это будет результат не компании. Компания должна это делать, например, с помощью консультантов, но не консультанты это делают. Компания делает - консультанты помогают. Компания должна стать владельцем этого документа. Они должны его прожить и прочувствовать. Я думаю, что стратегический менеджмент вообще - это не то, что можно отдавать в outsource при любых раскладах. А стратегический менеджмент в наиболее важных направлениях, а это на данный момент какая-то ключевая компетенция, - IT и люди.
42:23 Еще на одном слайде ты показывал, что вы выбрали все трехбуквенные аббревиатуры - ERP, CRM, BI и так далее - и потом согласовывали, что вам нужно для бизнеса. С кем согласовывали? То есть какие-то критерии были?
Мы выбрали те из них, которые в принципе могут быть применены к нашему бизнесу. В частности, у нас нет PLM-систем, или каких-то таких. И мы нарисовали карту всех систем, которые могут быть, их оказалось на самом деле не так много по сравнению с тем, что у нас уже было. И мы это согласовывали с CIO и CFO.
То есть CIO и CFO мы сказали, что наше видение такое: вот такие системы у нас есть, вот такие системы мы сейчас строим, а такие системы мы собираемся не делать. Мы можем их себе брать, но мы считаем, что это нецелесообразно на нашем конкретном этапе жизненного цикла и т.д.
43:14 Ты рассказывал об IT-Enterprise, с которым столкнулся в процессе интеграции, и, я так понимаю, участвовал в постановке ряда задач, которые были для стыковки. Отзыв какой-то о системе, насколько вообще система передовая и соответствует ERP-шному классу, и насколько легко было с ребятами это все делать и интегрировать?
Меня эта система не впечатлила, ничем не впечатлила. Обычная нормальная система. Интегрироваться с ней было непросто. Это было несколько лет назад, надо учитывать, что мы говорим о 4-5 годах тому назад, когда мы выполняли тот проект. На тот момент она не давала нескольких технологических возможностей, которые нам были нужны, но я уже деталей не помню. Общее впечатление могу сказать. Труднее всего было согласовывать с ними постановку задачи там, где сидят люди, и врукопашную что-то делают, это в основном заменялось роботами, заменялось алгоритмами, функции диджитализировались. И было определенное сопротивление у тех, чьи это сотрудники, потому что у них фактически пропадала работа.
44:22 Там тоже выступление было - Enterprise mobility, вы увидели, что это начало... Trend, и вы уже какие-то части сделали. Какие?
Да, электронный заказ-наряд для сервис-инженера и электронный юридически значимый документооборот. Что это означает? Это означает, что механик абсолютно все, что ему нужно, выполняет на планшете, он не пользуется лэптопом. На самом деле пользуется, но немножко другая тема. Он все делает на планшете, клиент расписывается на планшете - прямо ставит подпись. Это автоматически уже превращаются все бухгалтерские документы, и это прорывной проект. До этого между датой "Последняя дата работы с техникой" и оплатой проходило 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 000 человек, теперь там 5 000 человек.
Если эти три фактора есть, то это точно диджитализация настоящая. А если их нет, то дальше можно спорить.
Что такое диджитализация с точки зрения новых бизнес-моделей - это одна тема, диджитализация существующих успешных бизнес-моделей, как их сделать более цифровыми или более спотяпными в цифровое - это совсем другая тема.
То есть ничего лучше, чем 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, и они нормально с помощью 1C:Підприємство, долота, и такой-то матери, с Божьей помощью все там прекрасно закрывают, да? Также там был отдел - 30 человек рассчитывали зарплаты, у нас рассчитывают зарплату трое на 2 000.
После этого с конца 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