Юров Владислав Вячеславович, Директор по цифровой трансформации (CDTO) Трак Моторс. Магистр техники и технологий связи и информатики, MBA CIO, сертифицированный Scrum Master, сертифицированный инженер Microsoft.
Автор книги «Elastix — общайся свободно»
Выступление на онлайн-конференции Уральского Клуба Цифровизации 14 октября 2022 #UralsDigitalMachinery
РАСШИФРОВКА ВИДЕО:
00:14
хочу представить всем Юрова Владислава Вячеславовича. И это легендарный человек, не постесняюсь так сказать, потому что у этого вопроса есть предыстория. В двух словах. Когда-то я встречался с этим решением, которое было очень развито, но тогда мне его представили как решение "барыжье", чисто, что это рассчитано все на продажу, на автоматизацию касс, вот это все неинтересные для меня, то есть история из второй Варны, а мы из третьей.
00:41
что это все коммерческая история и к производству не имеет отношения. Потом было наоборот, что приходил человек, который адепт Оду, и он сказал, что вот я вот на этом решении готов показать какая-то классная система. Говорит, решение не мое, но это вот такое вот грандиозное решение, что можно ли мне выступить на кейсе iCraft? Был такой запрос не очень давно. И потом так случилось, что мы разыскали Владислава Вячеславовича, который внедрял этот iCraft. Причем, что интересно,
01:11
Три момента. Первое, что он не внедрял ODA, а пришли наоборот. От задачи, которая стояла в трансформации производственной системы, пришли к какому-то решению. Он расскажет, как это было. Второй вопрос по методологии внедрения, так как это крупное решение с большой историей, он участвовал в других внедрениях. Мы с ним говорили о роли CDO и SEO. Как должны IT-директор уживаться с главным цифровизатором? То есть это кто? Это коллеги, конкуренты?
01:41
или это две стороны одного человека, так сказать, такая вот цифровая шизофрения. Так вот, у него есть свое мнение и свой опыт, который, я надеюсь, он нам расскажет. Ну и вопрос, какие были самые опыты, какие перспективы в этом есть для других предприятий, я думаю, он нам тоже поделится. Пожалуйста, давайте презентация будет. Кстати, я не соврал ли, можно предэтод. Это было действительно крупнейшее внедрение в России на тот момент? Насколько я знаю, это крупнейшее внедрение до сих пор.
02:09
Я надеюсь на самом деле сказать не столько о самоубнедрении, сколько о подходе. IT-специалисты пытаются уже около полувета найти серебряную пулю, как называется для успешного... Да-да-да, не буду вас перебивать, но еще есть волшебные таблетки и ключ от всех дверей. Так что я отключаюсь, а вы продолжайте. Хорошо. Серебряной пули у меня тоже нет, но я надеюсь, смогу поделиться рецептом, как ее изготавливать на конкретный проект.
02:38
Есть подходы, которые разработаны за полвека, как реализовывать проекты. Это PMBOOK, PRINCE2, WATERFLOW. Все эти методологи опираются на треугольных проектах. Сроки, стоимость и содержание. В этих методологиях считается, что все эти элементы невозможно изменять. И если какой-то из них существенно меняется, это уже совсем не тот проект.
03:04
При этом, например, по методологии PMBOOK считается нормальным на старте ошибка оценок проектов двое. То есть от сказанного бюджета можно ошибиться в минус на 25% плюс на 75%. И согласно методологии такой проект считается реализованным успешно вписавшимся в треугольник. Есть альтернативные подходы, которые еще появились с 80-х и названы были инте подходами.
03:32
Самый популярный из них сейчас это Scrum. Их основная суть в том, что они управляют не прое а только двумя параметрами. Это управление целями проекта и управление рисками проекта. А Scrum для управления целями выделен владелец продукта. Его задача каждый раз, при каждой итерации держать фокус на важных элементах создаваемого решения. Задача Scrum Master – управлять рисками проекта.
04:01
они вплотную коррелируют с целями. Корректируя цели, можно корректировать риски. Мои подходы к внедрению проектов, это скорее не скрам, а просто инте подходы. Что это означает? Начну с примера, который очень не любят IT-шники, говоря о скрам. Говорят, что по скраму нельзя построить мост. Я с ними не совсем согласен. Почему? Потому что задача скрама не в том, чтобы построить мост.
04:31
а в том, чтобы понять, мост ли нам нужен, какой нам нужен мост, нужен ли мост именно здесь, где мы его запланировали, и для чего нам, собственно, нужен мост. Например, нужен ли нам мост, возможно, нам достаточно поставить паром, может быть, нам стоит протянуть фаникулёр, может быть, стоит положить понтон. И эти решения вполне могут покрыть наши потребности, ради которых мы изначально думали о непостроителе на мост, второй, когда помогает скрам.
05:01
Для чего нам нужен мост? Может быть нам нужен пеший мост, велосипедный мост, автомобильный мост, железнодорожный мост. Скрам подключается на том моменте, когда мы еще не знаем мост, и нам нужен, и какой собственно нужен мост, и кто его будет исполнять. Нужен ли мост здесь? Представим, что у нас город разделен рекой, две части города, трассы сейчас пролегают в 20 километрах через узкий мост.
05:28
и люди для того, чтобы проделать маршрут из одной половины в другой, тратят по три часа. Если мы запланировали строить мост, возможно мы его запланировали по центру города, географическому. СКРА может помочь в поиске оптимального места. Для этого могут помочь парон, фоникулёр, понтон. И вот когда мы поиграли с этими более дешёвыми вариантами, мы можем понять, а здесь ли нам нужен мост, и такой ли нужен мост. Следующее, когда может помочь.
05:56
Нужен ли нам мост для того, чтобы связать город, или нам нужен мост для имиджа? Может быть, мы хотим, как возле Сочи, построить стеклянный мост и привлекать просто туристов в наш регион. Следующий, чем помогает страна, он помогает бороться с рисками. Когда нам может помочь бороться с рисками в случае постройки моста? Возможно, наша команда никогда не строила такие мосты, как мы запланировали. И тогда нам лучше делать строительство моста итеративно.
06:27
Например, мы умеем строить колонны, умеем строить колонны на реги. С них и начнем. С ними закончили, пока мы строили, мы начинаем думать о том, как нам класть полотно. Либо мы раньше не строили мосты вовсе, строили дома. Тогда с крамм поможет в том, что мы попробуем поставить одну колонну. У нас одна колонна не смыта потоком. Замечательно, начинаем строить другие. Возможно, мы не строили раньше таких масштабов. Может быть, раньше мы... Единственное, что мы строили, небольшой частный дом.
06:56
А здесь нам нужно построить огромный мост длиной, скажем, в 2 километра. Тогда мы можем при помощи Scrum попытаться, ну, учиться, справляться и с такими сложными проектами, сдавая все свои работы итеративно. Следующее может быть место сложное для моста. Мы не смогли найти на рынке готовых решений, как бороться, например, с лесенними потопами, когда идет огромная струя воды и нужно, чтобы мост удержался. Может быть, у нас там сложный грунт. Вот в таких ситуациях Scrum поможет.
07:24
Если же мы нашли подрядчик, который знает, как построить именно такой мост, как нам нужно, и мы уверены, что нужно строить именно мост именно здесь, конечно, с кром использовать нет смысла. Лучше заплатить подрядчику и получить готовые решения. Вот примерно по такому подходу мы реализовали Вайкрафт в большую часть нашего проекта. Впервые, когда пришел Вайкрафт, стал вопрос следующим. Стоял станок, один из тех, что изображен на картинке. Это был первый станок в России.
07:53
он теоретически позволяет работать станков без участия человеком. Но как это сделать, итальянцы не сказали. Когда мы стали выяснять, как они могут нам помочь, выяснилось это удвоить стоимость нашего решения. И два года оккупаемости оптимистично превратятся в 4-5 лет. Мы спросили у французов, как они свои 18 таких же станков автоматизировали, и они стали работать без участия человеком.
08:19
Они были без понятия, им это делали в рамках внедрения ERP-системы. ERP-система стоила примерно половину стоимости станков. Они внедрили 18 станков. У нас один. Поэтому каким бы ни было их решение, оно бы не подошло. Мы попробовали обратиться к нашему подрядчику, который поддерживал информационную систему. Это тоже как минимум удвоило стоимость станка. При этом не гарантировало полезного результата ни помощи итальянцев.
08:47
не помощью нашего местного партнера. Поэтому мы попробовали подойти к вопросу с того, чтобы понять, а в чем же для нас цель избавиться от участия человеком в работе станка. Сначала нам казалось, что основная цель – это сократить расходы. Когда мы стали рассматривать, в чем же истинная цель, выяснилось, что дело не в этом. Дело в том, чтобы компания имела возможность к кратному росту. И здесь для нас самое важное – это стабильность качества.
09:17
неважно низкое качество или высокое качество, оно должно быть стабильным, оно должно быть предсказуемым, то есть мы должны формализовать процессы настолько, чтобы мы могли им управлять в будущем. Сокращение затрат, оно конечно тоже важно, но оказалось, что оно вторично. Какие риски перед нами стояли? Как я сказал, штатные пути были очень дорогими, нам пришлось их отмести. Итальянцы сказали, что система документирована, оказалось, что документация это...
09:46
к нашим роботам имеет отношение только на 50%, потому что другие 50% параметра, они не описаны. Их назначений и как их заполнять никому не известно. Для нас это был черный ящик, который требовалось вскрыть. Мы не были уверены, что мы в принципе сможем управлять станком, потому что итальянцы на это нам тоже отказывались раскрывать какие-либо подробности. Мы не знали, сможем ли мы формализовать процесс настроек, потому что на тот момент у нас уже было три инженера,
10:14
и каждый из этих трех инженеров один и тот же заказ настраивал для станка по-разному. И у каждого были весомые аргументы сделать именно такие настройки. И мы не были уверены, что мы сможем систематизировать каталог. У нас на тот момент, если переложить нашу матрицу оправ, она требовала около 5 миллионов скоюй. При этом система была забита около 5000 скоюй. И когда мы взялись за процесс систематизации, удалось ужать с 5 миллионов
10:44
до 30 тысяч скою и всех их внести в систему. Это были те 30 тысяч скою, которые позволили управлять алгоритмами, которые нам потребовались для управления станками. Начали мы с самого простого. Мы просто взяли файл, который получает робот и попытались в нём сформированной программе изменить параметр, который нам проще всего было вытащить из Герпи системы, в межцентровое расстояние, расстояние между глазами.
11:12
поменяли, убедились, что файл в таком виде может быть нами заменен, и робот его исправно съест и выполнит инструкции так, как мы предполагали. Поначалу у нас был один единственный параметр, который мы с грехом Пала могли вытащить из ERP-системы, но мы сделали первый шаг, и мы автоматизировали создание такого файла. Сотрудник на производстве загружал этот файл, когда он начинал работать заказом, и вносил все остальные параметры, кроме межсенто-расстояния.
11:42
следующий шаг был. В этом же файле описана форма оправы, как ее следует выточить. Мы не были уверены, что сможем с этим разобраться. Алгоритм оказалось тоже не описанным, описание мы нашли через пару лет, оно оказалось весьма запутанным, умудренным, и оказалось, что там около пяти форматов, и конкретно наш сканер выдавал три из них. В каких случаях, какой формат файла он выбирал, мы разбираться не стали. Удалось решить это как черный ящик,
12:12
файла, которые мы могли гарантированно вставлять и получать нужным нам результат. Кроме этого фрагмента выяснилось еще полтора десятка параметров, которые нужно было сохранять, и десятка три параметров, которые нужно было исключать. Мы стали готовить файл, который сокращал трудозатрат оператора раза в два. Ему не требовалось уже сканировать каждое оправы для изготовления каждого заказа. На эти две интерации у нас ушло, наверное, недели две.
12:40
то есть через две недели мы сократили трудозатраты вдвое. Но цель у нас изначально стояла стабилизировать качество. Мы продолжали к ней двигаться. Мы прошлись тогда по каталогу, когда мы поняли, что мы успешно прошли эти итерации. Формализовали каталог оправ, и мы смогли добавить еще около 5 параметров, которые настраивал оператор. С этого момента мы стали фиксировать, какие параметры каждый из мастеров устанавливает в заказе и почему. Стали следить за тем, как меняется файл.
13:09
разбираться какие параметры файлы меняются и пытались построить свой алгоритм. Сначала мы выдавали файл, который заполняет наш скрип и задача инженера была только править в том случае, если он считает, что станок не сможет изготовить заказ правильно. Эта часть длилась у нас, наверное, около месяца. После этого мы сказали, ребята, вы должны теперь записывать, что вы правите в нашем файле. И мы стали смотреть, как изменять алгоритм.
13:39
привели к тому, что все три инженера, требования всех трех инженеров смогли свести к одному алгоритму. После этого мы приняли ситуацию на обратную. Что вы вправе править файл только в том случае, если считаете, что первые попытки мы линзы испортим. И вы обязаны сохранять запись в журнале, если ее не будет, а вы поправили настройки, брак будет за ваш счет. Если вы ничего не правили, брак будет за счет компании.
14:09
Таковым режимом поработали еще месяца полтора и успешно исключили всех инженеров из участия в этом процессе. Спустя где-то пять месяцев у нас станок работал уже без участия инженера. Суммарная окупаемость этого проекта получилась в районе трех месяцев, потому что реальные технические вопросы, которые возникали, они были несущественны на фоне всего остального. Технические вопросы мы решили легко. Забыл, что у меня был вот этот слайд.
14:39
Это как раз перечислены были примерные веки того проекта. Другой проект, о котором говорил Игорь, это проект с розницей. Изначально наша цель была в следующем. Компания стала активно увеличивать количество магазинов и сложно оказалось искать в регионах автометристов. И сложно было искать продавцов, которые могли бы работать с нашей системой, которая выглядела как досовская программа. Даже опытные специалисты спустя год работы продолжали совершать большое количество ошибок ежемесячно.
15:09
Документация краткая по основным задачам занимала более 40 листов без картин. Это создавало сложности. Обучение требовалось недели обучения в офисе и месяц стажировки в магазине. Значительная часть штата, который мы привлекали, посмотрев на то, с чем им предстоит работать, убегали. Под предлогом, что пойду-ка я работаю в ту компанию, где используется 1S. Там привычнее. Потребовалось сократить тревогу персонала и сократить с участием.
15:37
Второе требование, которое мы хотели заодно реализовать, это упростить обслуживание клиента. На момент, когда мы начинали, мы один заказ оформляли от 5 до 15 минут, в зависимости от ситуации. Когда мы внедрили воду, мы смогли сократить сроки оформления заказа до 1-2 минут. Инструкция стала занимать всего 2 страницы, и большинство персонала пересело на новую систему, даже не читая инструкции, просто кликая в интерфейс.
16:06
риски, которые нам предстояло преодолеть. Подходящих подрядчиков в 2016 году не оказалось. Мы попробовали, по-моему, четырех подрядчиков, и все эти попытки провалились. Нам пришлось сформировать собственную команду. Забыл сказать, что мы, естественно, начали не с ОДА, мы перед этим рассмотрели семь, по-моему, систем для оптики. И выяснилось, что наше неказистое, которое нам не нравилось, оказалось среди них технологически лучшей.
16:32
и единственно интергьюрована с нашими станками. В любой другой нам пришлось повторять интеграцию. Дальше. Пришлось сформировать собственных программистов, научить программистов работать с ОДО. Мы не были уверены, сможем ли мы разработать нужные нам решения практически с нуля, потому что ОДО для оптики мы не нашли. И мы не были уверены, сможем ли мы сделать решение лучше, чем те семь, которые мы нашли на рынке, и лучше, чем то, которое мы использовали сейчас на тот момент. Однако мы взялись за проект, потому что сочли, что
17:02
Овчинка выделки стоит. Мы практически договорились с текущим поставщиком решения о плане B, но решили его оставить на потом, если у нас не получится реализовать СОДО. Первый шаг был перенести с бумаги на планшет обследование зрения, на которую потом будут опираться создания заказов начков. Этот процесс у нас занял месяц или два. Через пару месяцев все магазины работали на планшетах и оформляли обследование зрения в электронном виде.
17:32
маркетники ликовали, потому что они могли тут же начинать спамить наших потенциальных клиентов. Запуск кассы мы тоже разделили на три этапа. Первое, мы решили, что нужно запустить хотя бы одну кассу в самом простом магазине. Самый простой оказался с отдельным торговой маркетом, работающим по упрощенности на налоговложение. С ассортиментом, наверное, 5% от ассортимента iCraft. В этой части проект длился достаточно долго, по-моему, 7 или 8 месяцев.
18:01
потребовались на реализацию этого этапа. Первый магазин мы смогли запустить и смогли понять, что следующие новые открывающиеся магазины, уже под марк iCraft, мы сможем подключать без аппаратных кассов кулатор, без старой системы, которую требовало лицензирование, нами разработанной кассе ввода. Чтобы переход был простым, мы сделали интеграцию со старой системой. Эта интеграция работает до сих пор, работает в обе стороны. То есть можно оформить чек в старой системе,
18:30
и пробить его на новой кассе. Можно пробить чек на новую кассе, он появится в старой системе. Можно создать заказ в старой программе и пробить по нему чек по новой кассе. И заказ, оформленный в новой системе, будет выведен в старой системе. После того, как мы запустили первый магазин, через пару месяцев мы на него перевели больше 100 франшиз. Почему франшиз? Потому что у них тоже упрощенное налоговложение. И еще через 3 месяца мы запустили
18:59
наверное, треть собственных магазинов, те, где у нас возникало больше всего проблем с аппаратным обеспечением, и те, на которых нам хватило первых планшетов. Еще через полгода мы перевели всю сеть iCraft на работу с новыми кассами. К этому времени мы успели создать решение, в котором мы могли уже заводить заказы на очки. Изначально нам достаточно было реализовать хотя бы процентов 10 заказов и оправлять в новую систему.
19:26
И мы сотрудникам разрешали оформлять на их усмотрение. Где им удобнее, где у них получается, там и оформляют. Девочки помоложе обычно используют планшеты. Если обследование зрения было заведено на планшете, они чаще всего там же создавали заказ. Первый результат был около 5-10% заказов создавались на планшетах. Дальше мы постепенно разбирались, почему люди не используют планшет, и постепенно устраняли преграды, о которых нам говорили сотрудники.
19:57
Когда с этим мы успешно разбрались, мы добавили возможность создавать запасный ремонт, мы создали систему BI-отчетности вместо портального решения, где сотрудники могли видеть в табличном виде расчета своих бонусов. Сейчас Вайкрафт видит каждым сотрудник на своем личном телефоне свои показатели и как он может увеличить свои продажи. Видит свои планы, видит, насколько он их достиг и как этих планов достигают его коллеги.
20:26
интегрировали электронные кассовые отчетности. Все это каждый раз отдельная итерация, и каждый раз, каждая итерация заканчивалась новым функционалом. Это не оказалось такой подход, не уникален для iCraft. Была компания, через которую меня как раз и нашли коллеги, занимается молочной продукцией, один из проектов их называется CROSDOT. Компания к этому подходила, пыталась подойти, загрузка в том, что они пытаются одновременно...
20:55
перейти с ADNs на ODA ERP и при этом проект CrossDocking запустить сразу весь. Этот проект CrossDocking и по сути можно разделить на следующие подпроекты. Это приходы, размещение товара, комплектация, доставка и корректировки при доставках. Если рассмотреть эти элементы как вехи, это радикально снижает риски проекта. Поэтому если...
21:22
исключить комплектацию доставки и корректировки, сложность проекта уменьшается более чем в два раза. Для того, чтобы сделать кросс-докинг, у нас все равно есть необходимость, пригнав машину, хотя бы часть товара разместить на складе, ждать, пока приедут машины кенны, которые мы перегрузим. Поэтому без этих двух этапов кросс-докинг реализовать все равно не вы. Значит, можно сократить первую веху до этой части. Следующая проблема, которая возникает, это
21:52
ассортимент. 80% продаж компании составляет собственное производство. Это товары, которые имеют малый срок годности, у которых высокая оборачиваемость и высокие риски задержки бизнес-процессов. В то же время есть несколько десятков внешних поставщиков, и один из поставщиков имеет продукцию, которая занимает лишь несколько процентов продажах, имеет большой срок годности,
22:22
и достаточно простые параметры товара для хранения. Поэтому если первую часть, первую веху ограничить только до этого ассортимента, это существенно упрощает решение. Почему? Потому что для того, чтобы реализовать для собственных товаров, требуется еще завершить внедрение на производстве. А там компания купила новые станки, которые позволяют автоматизировать изготовление молочной продукции, его нужно интегрировать, нужно систематизировать каталог
22:51
каталог рецептов и это процесс не на один месяц. В течение всего этого времени непонятно, как реализовывается проект CrossDocking. Если же ограничиться до тех самых товаров одного поставщика, можно отладить все процессы. Сначала отладить процессы прихода и размещения, потом отладить процессы комплектации, доставки и корректировки. Следующий риск. Компания работает уже на терминалах сбора данных, работает в EDNS, хочет перейти на кода.
23:20
Для ODA нужны другие планшеты. Желательно использовать другие планшеты. Идея компании стояла в том, чтобы создать методом большого взрыва разработать новые системы, в которые сразу запустятся все процессы. И приходы, и размещения, и отгрузка, и учет тара, и учет оборотной тара. И многие другие процессы. Эти риски снимаются в том случае, если обеспечить на первом же этапе интеграцию CDNS. Идея кажется глупой.
23:46
Зачем тратить ресурсы на интеграцию, которая потом будет выброшена? Но когда мы спросили разработчиков, а сколько это будет стоить, оказалось, это всего лишь неделю трудозатрат. За неделю трудозатрат мы смогли еще примерно пятикратно уменьшить риски. И если первый ответ на реализацию кросс-докинга, команда IT говорила, что меньше года реализовывать не сможем, реализовать быстрее, чем за год невозможно, скорее всего займет года полтора-два. Если реализовывать итерациями, которыми я рассказал,
24:17
Команда была готова выдать первые результаты, если не через месяц, то через два. И в этом случае при таком подходе общий срок такого проекта команда оценивала практически гарантированно на год реализации. Это за счет итеративного, интриментного подхода. Здесь картинка как было разделено на этапы. Пример из iCraft. Лет 8 назад компания стала активно расти, собственного штата стало не хватать.
24:44
стали перед ситуацией, что нужно увеличивать штат. Мы чувствовали, что можем повысить эффективность. Сначала мы, естественно, стали смотреть на сторону. Все люди используют ВМС. Мы тоже пошли смотреть ВМС. Кратко резюмируя, решение, которое могло нам дать надежду на то, что сработает, было около 5 миллионов. И если перечислять сроки окупаемости, оно превышало 7 лет для тогдашнего бизнеса iCraft. Решение, которое было предложено нашим партнером...
25:14
с которым работал iCraft было около полутора миллионов, но ничего не гарантировано, кроме целой кучи проблем, с которыми столкнулись. И это решение пришлось бы интегрировать в существующие их же ERP-системы. Поэтому, рассмотрев вариант нанимать новых сотрудников или попробовать сделать что-то самим, мы попробовали сделать что-то самим. На экране изображено то, что мы хотели реализовать, но потом мы поняли, что часть…
25:40
функционалом можно выбросить и для этого нам не придется использовать воемную систему. Мы решили, что для нас принципиально безбумажная комплектация, но зонирование по типу хранения можно упростить. Требования снизили в несколько раз, мы грубо разделили на три зоны. Причем разделили просто организационно, административно, не требовали как-либо в системе отражать, как она должна управлять размещением. Мы отказались от того, что система обязана автоматически обеспечивать размещение товара. Мы формализовали сами процессы.
26:10
формирование складских задач мы тоже возложили частично на людей и без колласфикации стали проводить просто периодически вручную отказались от того чтобы система нам давала команды на частичные или событийные инвентаризации когда какой-то товар надо было например не найден ячейки мы стали проводить так же как проводили раньше раз месяц раз квартал в зависимости от ситуации мы пошли на то что готовы были разместить в одной ячейке только один товар
26:40
Когда мы это сделали, такое решение на текущей ERP системе нам смогли реализовать меньше, чем за три месяца. И в итоге наши инвестиции окупились меньше, чем за полгода. iCraft на этом решении проработала больше восьми лет, прежде чем переросла его и перешла на ВМС решение со стороны. На что хочу обратить внимание. Компания очень часто, очень много внимания уделяют проектам, которые я бы отнес к операционным и техническим. С чем это связано?
27:10
очень немного рисков и способны внедрить практически любая команда. Почему? Потому что когда идет борьба с рисками, нужно подключать руководство, нужно пересматривать цели, нужно пересматривать требования, нужно пересматривать сроки, нужно пересматривать стоимость. Уже на тактическом этапе невозможно не управлять этими процессами. На стратегическом этапе реализовать такие проекты практически нереально. Как можно отнести задачи к тому или иному уровню? Грубо можно отнести, например, по срокам.
27:39
Если реализуется проект за месяц, дни или недели, это либо операционный, либо технический. Технический, который может быть реализован без участия сотрудников отделов, кроме технического отдела. Тактический – это проекты, которые могут существенно повлиять на продажи и на сокращение расходов. Существенно настолько, что на порядке перекроют стоимость разработки. Стратегический, который на десятки процентов, хотя бы если не в разы, отразится на бизнесе компании.
28:09
Обычно у таких проектов срок реализации ближе к 3-5 годам. И вот на стратегическом и тактическом уровнях нужно либо использовать PMBOOK, но обязательно с разделением на вехи, на итерации, когда после каждой итерации мы получаем готовый и используем бизнесом продукт, либо подход Scrum, который нас вынуждает выпускать готовый функционал либо каждую неделю, либо каждые две, либо каждый месяц. Неправильно использовать подход Scrum, если после каждой итерации...
28:38
мы не получаем готовый продукт. Называть Scrum только то, что мы каждый день проводим стандап встречи с разработчиками, или то, что мы раз в неделю обсуждаем, какие задачи будем делать на следующий, и они не заканчиваются готовым продуктом, это не Scrum. Все что угодно, но это даже не икаративный процесс. И если этого не делать, то как раз реализуются все риски. За счет того, что Scrum предлагает ограничивать месяцом, если наш проект годовой, мы в 12 раз, как минимум,
29:08
уменьшаем риски, если попытаемся за месяц выпустить готовый продукт. Неважно, насколько он будет сырой, насколько он будет функциональным. Если мы выбираем итерацию недели и можем каждую неделю выпускать релиз, мы сокращаем наши риски еще в четыре раза, даже если мы этого не хотим. Это произойдет само собой, иначе мы не сможем выпустить готовый продукт. То, что Игорь упомянул про разные видения роли IT-директора и роли директора подсыщенного трансформации,
29:37
Внимание Игоря, директа подсовывающей трансформации, это скорее руководители проектного офиса, чья задача – систематизировать процессы, автоматизировать и уйти. В моем понимании, к чему это ведет для компании? При таком подходе мы планируем задачи не на слишком большой интервал вперед, на год, на два. Когда мы вниманием человека в штат, планирование можно ожидать на годы вперед.
30:03
когда я делал разработку для iCraft, я думал о решении, каким они будут лет через 5-10. Сейчас решение, которое оставлено в iCraft с розницей, работает с 500 магазинами, но технически способно справиться и с 5000, и не только в пределах России. И мое видение, роли директора пост это человек, который стоит над IT-директором, когда IT-директор выбирать не обязательно, он помогает IT-директор работать не только с тактическими проектами, но и помогает реализовывать...
30:33
стратегические проекты. На операционном уровне можно увидеть руководителя IT, а на техническом просто специалистов IT. Если есть какие-то вопросы, буду рад ответить. Господа, давайте вопросы. Вопрос в чате по поводу методологических по Scrum. Что такое New Product Development и управление требованиями? Вопрос про Scrum. Давайте его опустим, потому что нас время поджимает.
31:00
Я, во-первых, хочу всем сказать, так как тут Владислав, он спалил Михаила, про его молочные задачи, я скажу про его задачи. Он сейчас работает над очень крупным проектом, и так мы время почти исчерпали. Будем просить его, чтобы он пришел еще и рассказал нам о каких-то вещах. В частности, мы с ним говорили, он сейчас пытается автоматизировать еще более крупную структуру, чем iCraft, и мы говорили с ним о двух ключевых вещах.
31:30
Первое – это балансирование нагрузки серверной. Второй вопрос – это об унификации процессов. И вот это хотелось бы подробнее. А сейчас вот скажите, вот данные с оборудованием, вы сказали ту проблему, которую я видел много раз, что когда поставщик оборудования утратил контроль над ЧПУ. У нас та же история, что мы видим с контроллера 400 сигналов, а поставщик знает оборудование, а зачем 75?
31:56
и нам пришлось расшифровать 150 вместе с заказчиком, с заводом эксплуатантового оборудования. Почему такое, особенно у итальянцев и французов? Ну, конкретно потому, что станку есть стандарт Omo версия 1.2. Он описывает, как должно работать между собой медицинское оборудование. Но такой станок, который сделали итальянцы, он был первым на этом рынке. Чтобы не делиться своим рынком, который эти итальянцы разработали...
32:23
они не стали раскрывать часть параметров, которые добавили в систему. Поэтому они на вход могут принимать данные от других систем, но как эти данные передать другой системе, они раскрывать не стали. Еще вопрос, который у нас обсуждался ранее. Вот я всем рекомендую вместо того, чтобы обсуждать, что такое МС, выучить продавцы букв модных. Сейчас говорят CGM, что это важнее. Вот прокомментируйте подробнее, надо ли вот разрабатывать систему, которая управляет производством.
32:52
Я считаю, что мы должны управлять потоком потребности и, собственно, то, что мы видели в предыдущем докладе. Прокомментируйте, пожалуйста, вот CGM и MES. Как эти буквы с вашей точки зрения между собой живут? Я обычно начинаю с того, что выясняю, какую сроку купаемости в первом случае и во втором. И если я нахожу большую разницу, имеет смысл разбираться дальше. Если ответов нет, говорю, давайте оставим все, как есть, пусть работает.
33:18
Еще вопрос. Когда вам пришлось выращивать своих одушников, что важнее? Как человек разбирается в системе или насколько хорошо он питонит? Насколько я помню, все ребята, которые имели опыт воду, не прошли испытательный. Все программисты, которые сейчас работают воду в iCraft, в Соду раньше не работали. Большая часть из них не работала даже с питоном и не работала с POSGRS SQL. Подробнее можно? Не прошли? Почему? Что в Соду работают только наркоманы или у них аллергия на 1С?
33:48
Почему не прошли? Не прошли из своих подходов. Это ребята, увлекающиеся самим процессом, а не результатом. Поэтому куда важнее было найти людей, которые ориентированы на результат. Научить их разрабатывать в нужной системе оказалось не столь большой проблемой. Само вот это противостояние 1С и Odu, как оно выглядит с вашей точки зрения? Я сейчас работаю в компании, в которой всего лишь 400 пользователей 1С.
34:16
серверы, которые наши айтишники говорят, нужно отправить в мусор, отправляют их на склад работать в качестве видеорегистратора, в два раза мощнее, чем в iCraft, сервер, который обслуживает 500 магазинов и примерно 400 рабочих мест на производстве в OVC по регионам. Сервер, который обслуживает 1S в текущей компании, дороже в 30 раз. За счет чего такая разница? То есть это архитектурная, это технологическая, это методологическая?
34:45
Архитектурная разница 1С, если посмотреть через сэскори по профайлер, видно, что 1С работает с базой данных, так же, как она в 90-х работала в своем. Это просто жуткая технически неоптимизированная система. Ну, насколько прочно вы в этой системе Odu? Все-таки второй раз это было уже из опыта, что это показало свой опыт.
35:07
или вы опять перебирали какой-то стек решение и пришли к ODA? Стек решения на этот раз я не перебирал, исходило из того, что у нас имеется под рукой. Под рукой у нас имеется 1S, Bitrex и самодельные решения. Поэтому там, где Bitrex нам подходит, мы продолжим использовать Bitrex. Все остальные системы самодельные мы постепенно перенесем в ODA. Интересно, а вот вообще какие шансы у ODA именно в CRM? То есть выбить AMOCRM или с точки зрения… ведь многие начинают с CRM.
35:36
Многие, к сожалению, в текущей компании уже куплены рабочие места для BIT.REX CRM, поэтому продолжим работать на ней, но с большой вероятностью года через три весь этот функционал перейдет в воду CRM. Касаемо от того, насколько эффективно или неэффективно, пример в следующем дала весна в iCraft. В SubSuccess Factor компания вложила больше 10 миллионов рублей. Весной пришлось расстаться с этим продуктом, похоронить все эти инвестиции и за два месяца перевести тоже функционал года.
36:06
Насколько вероятность о том, что ODA начнут препятствовать, или что кто-то, пользуясь открытостью кода, насуёт туда жучков какие-то, хакеры как бы? Когда код закрыт, засунуть жучков ещё проще. С открытым кодом у тебя есть возможность изучать, нет ли там жучков, если тебе нечем больше заняться. Бояться того, что ODA перестанет однажды выпускать свой продукт, мне кажется, не стоит, потому что оставить себе копию той версии, с которой ты работал.
36:35
ты можешь продолжать развивать ее. iCraft до скорой работает на O до 10 версии, а сейчас на рынке 15. Тестично iCraft перешел на 13 в некоторых функциональных, но это не принципиально. Хорошо, а я думал наоборот, что надо вот сейчас подождать чуть-чуть, и 16 уже же вышла, вот-вот будет комьюнити версия. Насколько интересно обновляться? Любое обновление, на мой взгляд, должно быть экономически обоснованно. Находим новый функционал, который принесет пользу бизнесу, надо делать.
37:04
А то, что мы можем утратить на следование версий, ну, условно пропустим столько времени, что потом условно на 25-ую захотим обновиться, а уже нельзя. По моему опыту это не самая страшная вещь. Какая самая страшная? Чего боится CDTO? Не договориться с руководством о цели полагания о борьбе с рисковым. Сейчас борюсь с нашей командой разработки, которая не хочет перестраивать свои процессы. Поэтому у них один с другим проекты тормозятся.
37:33
Кто самые капризные пользователи? Да нет на самом деле таких пользователей. Изначально кажется, что самая сложная это техническая часть решения. На деле оказывается, что это совсем не так. И если взглянуть на проект с другой стороны, можно разложить его на этапы, на вехи. И люди с удовольствием принимают такой подход. В текущей компании уже три проекта по такому подходу переделаны. И мы по каждому из них идем успешно.
38:01
Хорошо, а вот индийский форк Odu это вообще хорошо или плохо? Именно с точки зрения вот нас, вот мои русские заводы. Для нас это хорошо или плохо? Почему они решили форкнуть его и вот в двух словах вообще нам это чем грозит? Насколько я помню, они его разделили на этапе Odu 11 версии. И последнее, что я видел внутри, флектор внутри не развивался относительно 11 версии Odu.
38:28
Odo 15 версия, она капитально отличается по производительности и по функционалу от 11 версии Odo. Идутся вот эти куда-то в джунгли, и нам за ними не надо, я правильно понял? Мне кажется, да. Тем более, что они все равно, в составе переходить по идеологии Odo, разделили версии на бесплатную и платную. Урезав функционал бесплатный. Еще вопрос, с чем еще надо интегрироваться, кроме 1S и Bittrex? Я бы сказал по ситуации.
38:54
Главная угроза перейти на Оду. Вот у меня есть, мы перенесли одну систему в Оду и заказчик никак не решается, хотя, ну я бы мог ему вообще не говорить, что это сделано на Оду. Ну то есть выпилить локотипчик и он бы об этом не знал. Но вот сам вот эта сакральность принятия решений, она его как бы останавливает. В iCraft мне пришлось убеждать руководство около двух или трех лет.
39:22
на то, что вы не должны перейти на УДА, а перейти на самостоятельную разработку. Только когда переговоры зашли в тупик, и когда мы рассмотрели другие варианты и вариантов не нашли, а Ксанира согласилась с тем, что да, это не варианты, мы стали рассматривать только два сценария. Работать со старой системой и согласиться на недостатки, с которыми пришлось вмириться, либо попытать счастье с ОДА. Мы попытались счастья.
39:45
А MVP тут насколько помогает? Вот мы сейчас пытаемся выделить, с Михаилом тем же, выделить какие-то локальные задачи. То есть вот вопрос, ребята, не говорим про Odu, вот вам TAIR, не говорим про Odu, вот вам передельные балансы. А дальше типа, ну что, в любой момент вы нас можете выпилить, когда сделаете свою супер-мега-систему, которую вы задумали. И в надежде на то, что временное решение станет постоянным. Насколько вот MVP-шки, вот эти они могут помочь?
40:13
Это самая важная часть. Это как раз есть атеративный, инкрементный подход. Каждую новую версию это такой самый MVP. Вот вопрос с производством предприятия. Вы бы, вот если вам выбирать, с какого процесса вы бы начинали автоматизацию и, допустим, внедрение? По ситуации, в декабре прошлого года имел опыт общения с одной крупной производственной компанией. Их основная проблема была не в производстве, а в том, что их собственные производства выполняют планы только на 40%. В то время, когда азиаты выполняют…
40:42
как минимум на 80% прописывают в ГОРА к 90% и чаще всего не исполняют 90%. Поэтому там ключевой вопрос был в том, как добиться в кратчайшие сроки исполнения на 80-90% на 99% собственных планов. И это было очень далеко от автоматизации производства. Там первые шаги можно было выполнить за месяц. Ну у меня та же кровь, я готов подписаться. Насколько перспективна интеграция в технологической
41:12
с поставщиками, с подразрячиками пытаться объединиться в единую IT-систему. Я такие системы видел, особенно в производстве. Насколько это перспективная история с вашей точки зрения? Я бы сказал, что самый главный ужас для интеграции это количество интеграций. Нужно помнить, что сложность интеграции растет примерно как количество связей между собеседниками, профессионально квадрату. Чем больше систем, тем сложнее.
41:37
А выделять отдельный брокер сообщений, выделять шину данных, какие-то вещи? Я бы сказал все по ситуации. iCraft, например, не делал свою собственную систему работы с электронными документами. Мы использовали ContourDiadoc и BIS, вторая называется, что-то вылетелось головой. Вопрос, а BI какую-то прикручивали? Аналитику Odo-вскую допиливали или использовали внешнюю? Мы сделали в интерфейсе Odo, делали ее с нуля.
42:06
Вы сами написали дажборды для тех ролей, которые вам нужны? Да. Понятно, интересно, вдохновляюще, скажем так, потому что мы сейчас в этом приблизительно. Ладно, большое спасибо, спасибо, что пришел, очень-очень полезный, во всяком случае, для меня доклад. Ребята, у кого-то есть, может, вопросы, давайте это быстренько, очень, потому что нам надо двигаться дальше.
42:31
Вот опять вопрос один и тот же мы поднимаем он уже по Odu 10 было полностью бесплатно Odu 15 полностью платное и потом думаю разработчики уже сделали свою Odu им уже другие не нужны. Вообще кто-то использует в России Odu Enterprise? Это вопрос из чата кто-то использует Odu Enterprise платные? А понятно это вопрос ко мне. Мы несколько раз просчитывали Odu Enterprise. Мне показалось бы что это выгодно тогда когда у тебя компания человек 10-20 ну может быть 30.
42:58
Тогда есть шанс, что это будет дешевле, чем использовать собственного программиста. В случае iCraft, даже в 2016 году покупка Enterprise версии, даже с сильным сокращением количества лицензий была дороже, чем содержание штата из шести программистов. Штатом шести программистов мы сошли, что мы за год без проблем перепишем весь платный функционал под себя. А какой функционал в Enterprise, которого тебе не хватает в комьюнити? Его не нашлось, поэтому это мы так рассматривали.
43:29
Понятно. Мы тоже не нашли, мы думали, мы плохо искали. Ладно, большое спасибо. Что-то хочешь добавить от себя? Нет, спасибо вам. Интересный доклад был этот, извинишь, и мы так вот паразитируем как бы. Ну в России принято красного ухау, что оно ничего не стоит, поэтому вот паразитируем как бы на более опытных товарищах. Большое спасибо. Заходи еще. Где-то тут должен быть твой коллега, конкурент, соратник, союзник. Михаил Константинович, ты с нами? Да, я здесь.
43:58
Очень с большим удовольствием послушал Влада. Понятно, он все твои молочные секреты продал. Для меня главный секрет был из чего делают молоко. Я теперь не могу решиться. Я всегда раньше два шоколадных коктейля брал, проходя в Ашане, это был секретуал. Надо два этих выпить, а теперь не могу решиться. Ты же помнишь, когда я Simplex Method натравил на рецептуре, ты видел, что там стеорим, машинное масло, там все это.
44:26
В ответ на вероятности добавления.
IT_InBIT
14 октября 2022 г.