На переработку 1С под нормальную работу уйдёт вся жизнь, потому что норма постоянно меняется.
Я уверен, что во всех компаниях, где внедрен SAP, перед его внедрением говорили точно такие же слова.. Но SAP у многих внедрен.
У всех у них 1С есть на отдельных участках. Где-то финансы, где-то обработка заказов.
Не у всех. А у кого сосуществует с крупными ERP, то чаще всего именно бухучет.
Финансы и заказы - много интеграций, в том числе (и это самое неприятное) - обратных, т.е. и из 1С в систему. А вот бухучет обратки не требует и сам по себе посмертный.
В теории Вы правы, но лучше уточнить: не перешли бы, потому что их всех могут и не спросить на самом деле, а просто "принять политическое холдинговое" решение. И это не домыслы, такое в России уже происходит с рядом компаний, входящих в холдинги.
Да и с поддержкой SAP и ERP подобного уровня (а их в России не одна) рано или поздно будет не очень. Компетенции интеграторов в России, без поддержки извне, будут снижаться - тут вариантов нет.
Крупняк сидит на последних обновлениях своих ERP, доступа к исходникам нет никакого, разделение систем на модули с интеграцией, в сравнении с более старыми версиями-монолитами - это ещё одна проблема.
А жизнь идет, доработки требуются, одно только законодательство и новшества от государства в России дают столько почвы для изменений, что порой до свих бизнес-процессов добраться не всегда успеваешь.
Но и 1С для крупного бизнеса тоже не лучший вариант. Если посмотреть на рынок труда, можно заметить довольно сильно добавившихся вакансий по 1С, где требуются специалисты, умеющие работать с высоконагруженными системами... Полагаю, это обратка от влезания 1С в не свой сегмент обработки и управления данными. Конечно со временем научатся и всё сделают, если жизнь заставит, но думаю все ведь понимают, что это переработка ядра.
По итогу, у меня в голове сложилась такая примерно картина (на гладкой бумаге, без оврагов):
на уход с любой крупной ERP крупному бизнесу надо не один год (ну вот как Норникель будет переходить ума не приложу, а вот Росатом, с их принципами внедрения жесткой внутниотраслевой конфигурации сверху-вниз, с этой задачей вполне может справится лет за 5 по всему холдингу)
на переработку 1С под нормальную работу крупного производственного, добывающего, логистического бизнеса уйдет тоже 3-5 лет
По уму бы им договориться до какого-то консорциума и под грант от государства сделать пилоты на паре крупняков из разных отраслей. Глядишь через 5 лет мы получили бы российского игрока мирового уровня по классу ERP с готовыми отраслевыми конфигурациями, которые уже хотя бы 50-60% нужного хорошо накрывали и минимизировали затраты на железо при ускоренном росте данных.
Но как им всем эти 5 лет прожить, если поддержка кончится как северные потоки... Это загадка, а для них - это реальный головняк.
Складские задачи - в том виде, как используются на производстве, не решаются по принципу запланировать поступление на склад. В то время как производство - именно так и работает: запланировать деталь-операцию в работу.
Но даже самый совершенный план не может учесть ошибочных сроков кооперации и логистики, поэтому - нейросети и хорошие математики дадут эффект только тогда, когда весь ринок окажется вовлечен.
А до этого момента от математиков и программистов, как и от нейросетей ждут умения научить систему планирования реагировать на отставание или несостоявшиеся поставки - оперативно и с минимальными затратами для предприятия.
А эта задача - куда сложнее, чем прямое планирование, даже с учетом зависимых ресурсов.
Вы пропустили очень важный шаг эволюции - это планирование.
Я не знаю, как Вы замените наладчика и человека, который пишет и корректирует программы ЧПУ (допустим) под переточенный инструмент с измененной геометрией - опустим эти "мелочи".
Но, станок с ЧПУ просто не получит никакого заказа, если система планирования не будет совершенна:
деталь готовы делать, но не поступила заготовка
деталь готовы делать, но не поступил инструмент
деталь готовы делать, но не поступила оснастка
деталь готовы делать, но не поступил материал
деталь готовы делать, но программа выдала отладочную партию после переналадки с браком
и... вишенка - деталь на станок на данный отрезок времени не запланирована.
и ещё одна вышенка - ваша деталь запланирована к производству на... вчера (в недодел), потому что цикл изготовления с учетом циклов готовности сопутствующих ресурсов длиннее, чем согласованный в договоре срок сдачи изделия (невидимая рука рынка - в котором мы все живем).
Приведенный Вами пример с заказом и просмотром через web камеру, как делается деталь - это "гаражный" вариант предприятия. Но предприятия со станками ЧПУ всегда имеют планы загрузки на месяцы вперед.
И... - нет норм для загрузки ЧПУ в 100 или 90% - такое возможно только на "короткой дистанции производства".
Я работаю в отрасли, где присутствует секретка. Могу Вам сказать, что все предприятия одной и смежных отраслей, готовы встречаться для обмена опытом даже без компаний внедренцев и такие встречи проходят регулярно.
В нашей отрасли есть четкое понимание, что одна встреча многих участников по сложной задаче, может сократить сроки её успешной реализации для всех на месяцы, а то и годы, особенно если у кого-то есть задел или неудачный опыт - это, кстати, тоже очень ценно.
Пищевые и сельхофермы - я не знаю, не сталкивался, НО виноделы и сыровары также собираются, а у них требований санитарных и внутренних по системах хранения и созревания - не меньше.
Другой вопрос, что не все компании готовы показывать результат своего внедрения, поскольку не редко бывает, что желаемое на словах выдают за действительное, а встреча, на которую приедут спецы с другого предприятия, которые точно понимают, что ищут и что хотят увидеть - всё это вскроет.
Именно по этой причине многие крупные компании заказчики и просят показать результат внедрения на других предприятиях. Логика: если у внедренца получилось сделать у других, значит помехой во внедрении можем быть либо мы сами, либо наши неразумные или завышенные требования к системе.
Организация командировок на места, где Вы уже внедрились и возможность потенциальному заказчику поговорить напрямую с сотрудниками предприятия, куда Вы привозите на показ - чаще всего снимают 90% вопросов к "рабочей модели".
Давайте я попробую высказаться от имени потенциального заказчика - тем более, что по сути, именно потенциальным представителем его я и являюсь.
Вы абсолютно правы в том, что бизнесу, т.е. ТОПам представляющим компанию и подписывающим документы (договора), на самом деле не нужно знать всех этих АСУповских и ИТшных терминов и перегружать их деталями.
В "недоразвитых" организациях (а таких по стране очень много) руководству достаточно показать красивые графики (читай бусы), чтобы они начали нажимать на свои службы о проработке вопроса.
Проработка вопроса!
Крупный заказчик, как правило, внутри себя уже имеет службу ИТ, которая, в 2022 году, уже по любому имела дело и со SCADA и с датчиками напрямую, и имеет свои информационные системы.
Помимо службы ИТ - есть ещё служба, которая будет непосредственно работать с этими графиками и что-то на их основе менять ("улучшать").
Как минимум две эти службы выдвинут технические требования к системе, по интеграции и обратной связи.
Помимо них в процесс обязательно будет включена хотя бы одна экономическая служба, задача которой определить целевое назначение и окупаемость.
Три эти составляющие:
техническая прозрачность, интеграция и поддержка;
наглядность, управляемость и доступность по требованию;
экономическая целесообразность и окупаемость;
и лягут в основу принятия решения по проекту.
Как Вы понимаете, Ваша задача увеличения стоимости проекта, для увеличения заработной платы сотрудников напрямую влияет на последний показатель - окупаемости.
Таким образом, для поднятия стоимости проекта, крайне мало красивых слов и громких названий. Куда продуктивнее предоставить в продукте метрики сравнения или улучшение нового решения относительно чего бы то ни было.
Как в ОС - система очистки от ненужных файлов показывает сколько места было сэкономлено, что напрямую может трансформироваться в сэкономленные средства на системы хранения, которые не надо было покупать.
Помимо этого, в современных условиях система для крупного заказчика не должна быть черным ящиком, который невозможно обслуживать без привлечения компании разработчика или посредника.
Система должна иметь очень развитый API на чтение и запись (если есть необходимость) - для обратной связи и управляемости.
Система должна быть кросплатформенной и адаптированной под разные устройства, а также способной работать под разными СУБД.
Всё перечисленное выше добавляет стоимости системе и абсолютно адекватно понимается и службами и руководством предприятия.
Отсутствие чего бы то ни было из перечисленного, говорит о том, что продукт будет дорабатываться на живую и существует огромное число рисков, как ошибок проектирования и реализации, так и в дальнейшей интеграции. Это означает длительную привязку к исполнителю (в том числе и финансовую) и растянутую во времени опытную эксплуатацию. Всё это снижает стоимость проекта, для того, чтобы снизить риски. Выход из этой ситуации есть, для того - для увеличения стоимости проекта надо, чтобы сторона исполнителя готовая была разделить с заказчиком риски, в том числе и финансовые, на период опытной эксплуатации. И вот на этом ломаются все, а риски срабатывают - всегда.
В процессе поиска и общения с теми, кто уже написал, пришел к двум выводам:
без глубокой исторической аналитики хорошего бота не получить, а для реализации аналитики с приемлемой скоростью реакции нужны вычислительные ресурсы, которые бот может не окупить :)
В бибанс сидят специалисты, которые тоже пишут ботов и имеют ресурсы кратно превосходящие ресурсы любого специалиста и даже компании, только задача их ботов сделать так, чтобы выигрывала площадка - что означает, что цена любой валюты в следующую секунду подчинена не только логике рынка, но и логике площадки, где работает рынок.
Затею отложил до лучших времен. Глядя на состояние рынка - времена эти наступят не скоро :)
Это вариант просчитан - результатом будет "оправданное и необходимое введение суверенного интернета для защиты и обеспечения гражданский свобод по свободному доступу к информации вопреки козням супостата".
В этой игре у Российских властей пока не просматривается проигрышныго варианта.
Я внимательно прочитал статью, на которую в данной строке Вы дали ссылку. На самом деле она не имеет никакой технической составляющей, показывающей слабость блокчейна, смартконтрактов или алгоритмов криптовалют... Но вообще Вам не показалось самому, что вся она была написана только вот из-за этого предложения
Yet all of these technical arguments circle around a deeper truth: a technology which is purpose built to circumvent and arbitrage the regulatory perimeter cannot be brought within the perimeter without destroying its core claim to value or irreparably crippling it.
Если кто-то сегодня будет утверждать, а в статье это утверждается, что алгоритмы и ПО банков куда более совершенны, чем алгоритмы блокчейна и смартконтрактов, то можно прямо сказать, что это неправда. Алгоритмы банков несовершенны и судя по нежелательным перемещениям средств в офшоры во всех странах мира, имеют алгоритмические дыры, позволяющие такие операции просто с колоссальными суммами, доходящими в кумулятиве за стандартный отчетный период до сотен миллиардов долларов.
Но суть даже не в этом. Revolut не может войти в Россию, потому что российские банки понимают свою слабость перед иной системой - а револют, это не крипта, это просто иной подход к управлению финансами.
FaceBook и Telegram долго не получали права на запуск своих блокчейн и своих криптовалют именно потому, что банковская система США абсолютно не готова конкурировать с новыми финансовыми инструментами, подкрепленными огромными капиталами этих компаний.
А если посмотреть на действия и позицию Morgan Stanley по криптовалютам за последние 3 года, то станет понятно и почему позиция по предыдущим компаниям немного смягчилась и как американская банковская система, помимо цифровых номиналов доллара (стабильной криптовалюты - по терминам статьи) готовилась и готовится не к своей трансформации, а к своей миграции.
Азиаты тоже, кстати - готовятся, но в отличие от американцев не каждый сам по себе.
И я соглашусь с предыдущим комментарием - технология ещё не раскрылась, не стабилизировалась, а потому и рыночные ниши ещё путью не осознаны.
Спасибо за развернутый комментарий. Данная тема, ИМХО, надолго актуальна, потому что, опять же ИМХО, находится только в зародыше и мы все дружно, и неизбежно туда придем.
По третьей статье -
Есть ещё статья 4, но я разместил их все, объединив в 2-е на Хабре.
Собственно - ключевых мыслей, которые я пытался отразить для обсуждения всего две
нужность и соответствие тенденциям развития ИТ сквозного паспорта материалов?
как сделать так, чтобы внедрение сквозного паспорта на материал, читай изделие не стало неподъемным финансовым обременением для целого ряда предприятий в цепочке производителей.
И если первый вопрос я лишь пытался раскрыть и показать с разных сторон (как сумел), то именно по второму вопросу мне хотелось обсуждения - конструктивного.
Поскольку уже сейчас я вижу целый ряд существенных препятствий, которые не позволяют многим компаниям даже думать в эту сторону.
Сам по себе цифровой паспорт - очень удобный инструмент не только для заказчика
Когда мы проводили анализ потенциальной интеграции и строили свою модель предложения, для тех у кого есть данные, но они не знают в какой вид их привести, чтобы они могли быть интересны, ну конкретно нам - стало очевидно, что в случае отсутствия унификации по реквизитам между производителями вся идея лишена глобального смысла и внутренний заказчик, которых Вы перечислили, будет основным потребителем этих данных. Конечно и это хорошо и нужно, но это конечный ресурс окупаемости проекта, который его однозначно не окупит.
Поясню мысль по унификации. Вы наверняка пользуетесь услугами какого-либо поставщика ЮЗДО. Во всех юр и фин документах ключевым реквизитом является договор - во всяком случае всё крутится вокруг него. НО, далеко не у всех поставщиков такой услуги, даже очень крупных, наименование и код этого реквизита унифицирован между документами. Возможно это произошло из-за внутреннего роуминга и самостоятельного развития каждого поставщика этой услуги в предыдущие годы. НО, для нашего предприятия, Вашего и т.д. - для потребителя это означает постоянную подстройку интеграции под каждый новый документ. Когда такой реквизит один - это не страшно, НО затраты порождает всегда. А когда их много - встает реальный вопрос, а сколько я от этого выигрываю относительно того, что трачу на сопряжение, поддержание и обслуживание.
На мой взгляд, сквозной паспорт, не получив такой унификации на ранней стадии на уровне ГОСТа имеет очень туманные перспективы на развитие и принятие многими предприятиями. Европа - пытается сдвинуть весь процесс по DMP и DPP именно в эту сторону.
Серьёзно, где действительно сильные аргументы в пользу битка?
У меня к Вам всего два вопроса по этому поводу:
Что для Вас есть "сильные аргументы"? Поскольку полагаю, что 191 млн к 7 млрд для Вас не будет убедительно, как и прирост дураков в 20 раз за 4 года...
А для чего дуракам, давать умным в руки какие-либо аргументы, будучи уверенными, что умные итак знают всё лучше других...?
Но ведь и про банки можно сказать тоже самое и про акции.
Я именно поэтому и написал - альтернативный. Нужен ли он? Да, далеко не факт. Как далеко не факт, что кому то нужен банк и кому то акции. А кому то нужно сразу всё + системы типа Револют. В этом и есть прелесть множества альтернатив - хуже, когда их нет или когда все они контролируются единой структурой или страной.
Я уверен, что во всех компаниях, где внедрен SAP, перед его внедрением говорили точно такие же слова.. Но SAP у многих внедрен.
Не у всех. А у кого сосуществует с крупными ERP, то чаще всего именно бухучет.
Финансы и заказы - много интеграций, в том числе (и это самое неприятное) - обратных, т.е. и из 1С в систему. А вот бухучет обратки не требует и сам по себе посмертный.
В теории Вы правы, но лучше уточнить: не перешли бы, потому что их всех могут и не спросить на самом деле, а просто "принять политическое холдинговое" решение. И это не домыслы, такое в России уже происходит с рядом компаний, входящих в холдинги.
Да и с поддержкой SAP и ERP подобного уровня (а их в России не одна) рано или поздно будет не очень. Компетенции интеграторов в России, без поддержки извне, будут снижаться - тут вариантов нет.
Крупняк сидит на последних обновлениях своих ERP, доступа к исходникам нет никакого, разделение систем на модули с интеграцией, в сравнении с более старыми версиями-монолитами - это ещё одна проблема.
А жизнь идет, доработки требуются, одно только законодательство и новшества от государства в России дают столько почвы для изменений, что порой до свих бизнес-процессов добраться не всегда успеваешь.
Но и 1С для крупного бизнеса тоже не лучший вариант. Если посмотреть на рынок труда, можно заметить довольно сильно добавившихся вакансий по 1С, где требуются специалисты, умеющие работать с высоконагруженными системами... Полагаю, это обратка от влезания 1С в не свой сегмент обработки и управления данными. Конечно со временем научатся и всё сделают, если жизнь заставит, но думаю все ведь понимают, что это переработка ядра.
По итогу, у меня в голове сложилась такая примерно картина (на гладкой бумаге, без оврагов):
на уход с любой крупной ERP крупному бизнесу надо не один год (ну вот как Норникель будет переходить ума не приложу, а вот Росатом, с их принципами внедрения жесткой внутниотраслевой конфигурации сверху-вниз, с этой задачей вполне может справится лет за 5 по всему холдингу)
на переработку 1С под нормальную работу крупного производственного, добывающего, логистического бизнеса уйдет тоже 3-5 лет
По уму бы им договориться до какого-то консорциума и под грант от государства сделать пилоты на паре крупняков из разных отраслей. Глядишь через 5 лет мы получили бы российского игрока мирового уровня по классу ERP с готовыми отраслевыми конфигурациями, которые уже хотя бы 50-60% нужного хорошо накрывали и минимизировали затраты на железо при ускоренном росте данных.
Но как им всем эти 5 лет прожить, если поддержка кончится как северные потоки... Это загадка, а для них - это реальный головняк.
Вот это
конечно улыбнуло для B2B рынка...
Я думал это в 90-х осталось: поесть, побухать и программа развлечений на халяву... потом откат по проекту, потом закат проекта..
и.. новый стартап, новая волна удовольствий...
Извините, не смог удержаться от комментария. Просто видел всё это своими глазами в своё время.
Складские задачи - в том виде, как используются на производстве, не решаются по принципу запланировать поступление на склад. В то время как производство - именно так и работает: запланировать деталь-операцию в работу.
Но даже самый совершенный план не может учесть ошибочных сроков кооперации и логистики, поэтому - нейросети и хорошие математики дадут эффект только тогда, когда весь ринок окажется вовлечен.
А до этого момента от математиков и программистов, как и от нейросетей ждут умения научить систему планирования реагировать на отставание или несостоявшиеся поставки - оперативно и с минимальными затратами для предприятия.
А эта задача - куда сложнее, чем прямое планирование, даже с учетом зависимых ресурсов.
Вы пропустили очень важный шаг эволюции - это планирование.
Я не знаю, как Вы замените наладчика и человека, который пишет и корректирует программы ЧПУ (допустим) под переточенный инструмент с измененной геометрией - опустим эти "мелочи".
Но, станок с ЧПУ просто не получит никакого заказа, если система планирования не будет совершенна:
деталь готовы делать, но не поступила заготовка
деталь готовы делать, но не поступил инструмент
деталь готовы делать, но не поступила оснастка
деталь готовы делать, но не поступил материал
деталь готовы делать, но программа выдала отладочную партию после переналадки с браком
и... вишенка - деталь на станок на данный отрезок времени не запланирована.
и ещё одна вышенка - ваша деталь запланирована к производству на... вчера (в недодел), потому что цикл изготовления с учетом циклов готовности сопутствующих ресурсов длиннее, чем согласованный в договоре срок сдачи изделия (невидимая рука рынка - в котором мы все живем).
Приведенный Вами пример с заказом и просмотром через web камеру, как делается деталь - это "гаражный" вариант предприятия. Но предприятия со станками ЧПУ всегда имеют планы загрузки на месяцы вперед.
И... - нет норм для загрузки ЧПУ в 100 или 90% - такое возможно только на "короткой дистанции производства".
Замечание более чем корректное и добавлю https://habr.com/ru/post/578104/
Я работаю в отрасли, где присутствует секретка. Могу Вам сказать, что все предприятия одной и смежных отраслей, готовы встречаться для обмена опытом даже без компаний внедренцев и такие встречи проходят регулярно.
В нашей отрасли есть четкое понимание, что одна встреча многих участников по сложной задаче, может сократить сроки её успешной реализации для всех на месяцы, а то и годы, особенно если у кого-то есть задел или неудачный опыт - это, кстати, тоже очень ценно.
Пищевые и сельхофермы - я не знаю, не сталкивался, НО виноделы и сыровары также собираются, а у них требований санитарных и внутренних по системах хранения и созревания - не меньше.
Другой вопрос, что не все компании готовы показывать результат своего внедрения, поскольку не редко бывает, что желаемое на словах выдают за действительное, а встреча, на которую приедут спецы с другого предприятия, которые точно понимают, что ищут и что хотят увидеть - всё это вскроет.
Именно по этой причине многие крупные компании заказчики и просят показать результат внедрения на других предприятиях. Логика: если у внедренца получилось сделать у других, значит помехой во внедрении можем быть либо мы сами, либо наши неразумные или завышенные требования к системе.
Организация командировок на места, где Вы уже внедрились и возможность потенциальному заказчику поговорить напрямую с сотрудниками предприятия, куда Вы привозите на показ - чаще всего снимают 90% вопросов к "рабочей модели".
Давайте я попробую высказаться от имени потенциального заказчика - тем более, что по сути, именно потенциальным представителем его я и являюсь.
Вы абсолютно правы в том, что бизнесу, т.е. ТОПам представляющим компанию и подписывающим документы (договора), на самом деле не нужно знать всех этих АСУповских и ИТшных терминов и перегружать их деталями.
В "недоразвитых" организациях (а таких по стране очень много) руководству достаточно показать красивые графики (читай бусы), чтобы они начали нажимать на свои службы о проработке вопроса.
Проработка вопроса!
Крупный заказчик, как правило, внутри себя уже имеет службу ИТ, которая, в 2022 году, уже по любому имела дело и со SCADA и с датчиками напрямую, и имеет свои информационные системы.
Помимо службы ИТ - есть ещё служба, которая будет непосредственно работать с этими графиками и что-то на их основе менять ("улучшать").
Как минимум две эти службы выдвинут технические требования к системе, по интеграции и обратной связи.
Помимо них в процесс обязательно будет включена хотя бы одна экономическая служба, задача которой определить целевое назначение и окупаемость.
Три эти составляющие:
техническая прозрачность, интеграция и поддержка;
наглядность, управляемость и доступность по требованию;
экономическая целесообразность и окупаемость;
и лягут в основу принятия решения по проекту.
Как Вы понимаете, Ваша задача увеличения стоимости проекта, для увеличения заработной платы сотрудников напрямую влияет на последний показатель - окупаемости.
Таким образом, для поднятия стоимости проекта, крайне мало красивых слов и громких названий. Куда продуктивнее предоставить в продукте метрики сравнения или улучшение нового решения относительно чего бы то ни было.
Как в ОС - система очистки от ненужных файлов показывает сколько места было сэкономлено, что напрямую может трансформироваться в сэкономленные средства на системы хранения, которые не надо было покупать.
Помимо этого, в современных условиях система для крупного заказчика не должна быть черным ящиком, который невозможно обслуживать без привлечения компании разработчика или посредника.
Система должна иметь очень развитый API на чтение и запись (если есть необходимость) - для обратной связи и управляемости.
Система должна быть кросплатформенной и адаптированной под разные устройства, а также способной работать под разными СУБД.
Всё перечисленное выше добавляет стоимости системе и абсолютно адекватно понимается и службами и руководством предприятия.
Отсутствие чего бы то ни было из перечисленного, говорит о том, что продукт будет дорабатываться на живую и существует огромное число рисков, как ошибок проектирования и реализации, так и в дальнейшей интеграции. Это означает длительную привязку к исполнителю (в том числе и финансовую) и растянутую во времени опытную эксплуатацию. Всё это снижает стоимость проекта, для того, чтобы снизить риски. Выход из этой ситуации есть, для того - для увеличения стоимости проекта надо, чтобы сторона исполнителя готовая была разделить с заказчиком риски, в том числе и финансовые, на период опытной эксплуатации. И вот на этом ломаются все, а риски срабатывают - всегда.
Год назад была мысль писать бота под бинанс.
Полез искать таких же "лентяев" :)
В процессе поиска и общения с теми, кто уже написал, пришел к двум выводам:
без глубокой исторической аналитики хорошего бота не получить, а для реализации аналитики с приемлемой скоростью реакции нужны вычислительные ресурсы, которые бот может не окупить :)
В бибанс сидят специалисты, которые тоже пишут ботов и имеют ресурсы кратно превосходящие ресурсы любого специалиста и даже компании, только задача их ботов сделать так, чтобы выигрывала площадка - что означает, что цена любой валюты в следующую секунду подчинена не только логике рынка, но и логике площадки, где работает рынок.
Затею отложил до лучших времен. Глядя на состояние рынка - времена эти наступят не скоро :)
Это вариант просчитан - результатом будет "оправданное и необходимое введение суверенного интернета для защиты и обеспечения гражданский свобод по свободному доступу к информации вопреки козням супостата".
В этой игре у Российских властей пока не просматривается проигрышныго варианта.
Я внимательно прочитал статью, на которую в данной строке Вы дали ссылку. На самом деле она не имеет никакой технической составляющей, показывающей слабость блокчейна, смартконтрактов или алгоритмов криптовалют... Но вообще Вам не показалось самому, что вся она была написана только вот из-за этого предложения
Если кто-то сегодня будет утверждать, а в статье это утверждается, что алгоритмы и ПО банков куда более совершенны, чем алгоритмы блокчейна и смартконтрактов, то можно прямо сказать, что это неправда. Алгоритмы банков несовершенны и судя по нежелательным перемещениям средств в офшоры во всех странах мира, имеют алгоритмические дыры, позволяющие такие операции просто с колоссальными суммами, доходящими в кумулятиве за стандартный отчетный период до сотен миллиардов долларов.
Но суть даже не в этом. Revolut не может войти в Россию, потому что российские банки понимают свою слабость перед иной системой - а револют, это не крипта, это просто иной подход к управлению финансами.
FaceBook и Telegram долго не получали права на запуск своих блокчейн и своих криптовалют именно потому, что банковская система США абсолютно не готова конкурировать с новыми финансовыми инструментами, подкрепленными огромными капиталами этих компаний.
А если посмотреть на действия и позицию Morgan Stanley по криптовалютам за последние 3 года, то станет понятно и почему позиция по предыдущим компаниям немного смягчилась и как американская банковская система, помимо цифровых номиналов доллара (стабильной криптовалюты - по терминам статьи) готовилась и готовится не к своей трансформации, а к своей миграции.
Азиаты тоже, кстати - готовятся, но в отличие от американцев не каждый сам по себе.
И я соглашусь с предыдущим комментарием - технология ещё не раскрылась, не стабилизировалась, а потому и рыночные ниши ещё путью не осознаны.
Спасибо за развернутый комментарий. Данная тема, ИМХО, надолго актуальна, потому что, опять же ИМХО, находится только в зародыше и мы все дружно, и неизбежно туда придем.
Есть ещё статья 4, но я разместил их все, объединив в 2-е на Хабре.
Всё писалось лишь для 4-й статьи - вторая половина второй статьи на Хабре.
Собственно - ключевых мыслей, которые я пытался отразить для обсуждения всего две
нужность и соответствие тенденциям развития ИТ сквозного паспорта материалов?
как сделать так, чтобы внедрение сквозного паспорта на материал, читай изделие не стало неподъемным финансовым обременением для целого ряда предприятий в цепочке производителей.
И если первый вопрос я лишь пытался раскрыть и показать с разных сторон (как сумел), то именно по второму вопросу мне хотелось обсуждения - конструктивного.
Поскольку уже сейчас я вижу целый ряд существенных препятствий, которые не позволяют многим компаниям даже думать в эту сторону.
Когда мы проводили анализ потенциальной интеграции и строили свою модель предложения, для тех у кого есть данные, но они не знают в какой вид их привести, чтобы они могли быть интересны, ну конкретно нам - стало очевидно, что в случае отсутствия унификации по реквизитам между производителями вся идея лишена глобального смысла и внутренний заказчик, которых Вы перечислили, будет основным потребителем этих данных. Конечно и это хорошо и нужно, но это конечный ресурс окупаемости проекта, который его однозначно не окупит.
Поясню мысль по унификации. Вы наверняка пользуетесь услугами какого-либо поставщика ЮЗДО. Во всех юр и фин документах ключевым реквизитом является договор - во всяком случае всё крутится вокруг него. НО, далеко не у всех поставщиков такой услуги, даже очень крупных, наименование и код этого реквизита унифицирован между документами. Возможно это произошло из-за внутреннего роуминга и самостоятельного развития каждого поставщика этой услуги в предыдущие годы. НО, для нашего предприятия, Вашего и т.д. - для потребителя это означает постоянную подстройку интеграции под каждый новый документ. Когда такой реквизит один - это не страшно, НО затраты порождает всегда. А когда их много - встает реальный вопрос, а сколько я от этого выигрываю относительно того, что трачу на сопряжение, поддержание и обслуживание.
На мой взгляд, сквозной паспорт, не получив такой унификации на ранней стадии на уровне ГОСТа имеет очень туманные перспективы на развитие и принятие многими предприятиями. Европа - пытается сдвинуть весь процесс по DMP и DPP именно в эту сторону.
показать не могу, ну вот я например, а ещё
в 2020 году этот показатель составил 101 млн человек (число аккаунтов в криптосервисах при этом почти вдвое больше — 191 млн). Это на 189% больше, чем годом ранее (35 млн человек), и в 20 раз больше, чем в 2016 году.
У меня к Вам всего два вопроса по этому поводу:
Что для Вас есть "сильные аргументы"? Поскольку полагаю, что 191 млн к 7 млрд для Вас не будет убедительно, как и прирост дураков в 20 раз за 4 года...
А для чего дуракам, давать умным в руки какие-либо аргументы, будучи уверенными, что умные итак знают всё лучше других...?
Согласен.
Но ведь и про банки можно сказать тоже самое и про акции.
Я именно поэтому и написал - альтернативный. Нужен ли он? Да, далеко не факт. Как далеко не факт, что кому то нужен банк и кому то акции. А кому то нужно сразу всё + системы типа Револют. В этом и есть прелесть множества альтернатив - хуже, когда их нет или когда все они контролируются единой структурой или страной.
Не могу сказать, но могу предположить, что во всех странах, где криптовалюта признана биржевым активом, из статьи к примеру Норвегия.
Альтернативный свободный источник сбережения, обмена, накопления, управления своими активами.
Вы в крипте видите крипту - посмотрите на неё лучше как на свободную рыночную единицу, а на биржи - как на альтернативный финансовый инструмент
Страны где криптовалюта признана валютой - со всеми вытекающими
На любой криптобирже
https://www.binance.com/ru/nft
Надеюсь, что это риторический вопрос? :)