Поэтому я и хотел Вначале узнать мнение хабр-сообщества на эту проблему. Возможно я что-то не нашел и согласование ФСБ "вот оно" или я не так прочитал OID, а нужно было иначе, т.е. вдруг мне тут покажут, что с №472 "полный порядок". Зачем тогда лишний раз беспокоить "наших занятых ЭПчиновников"?
Кстати, на каких форумах можно задать вопрос по №472?
Пояснения по Вопросу 1 добавил в FAQ2 (как типовой вопрос).
Вопрос 2 (ключевой вопрос): Определен ли в 63-ФЗ формат электронной подписи?
Утвердительный ответ на этот вопрос требует публикации согласования этого приказа (№472) от ФСБ. Если отлагательное условие не выполнено, то утвержденного Формата - нет, а МинЦифры грубо нарушило требование 63-ФЗ, выдав свой №472 за утвержденный.
Вопрос 3. Существует ли опубликованное или секретное согласование со стороны ФСБ формата, разработанного МинЦифрой (№472)?
"Как бы" Доказательства:
Однако факт регистрации приказа в Минюсте подразумевает наличие такого согласования!
Это неявное доказательство. Я тоже уверен, что согласование есть, но раз в 63-ФЗ указали явно на наличие такого согласования как важное отлагательное условие, то выполнение этого условия должно быть подтверждено Явно. Ответ кого-либо (МинЮста, МинЦифры, ФСБ) в адрес одной компании (автора запроса) – это «не в счет», т.е. должно быть публично подтверждено выполнение или невыполнение столь критически важного отлагательного условия.
Перечень того из них, что действует - смотрите на сайте ТК 26.
Там указано много чего (к сожалению, вместо прямых ссылок на документы стоят ссылки «в корзину»), но непонятен сам статус рекомендаций: они обязательны? Что значит «Действуют». Для кого и в каких случаях? Кто их использует и как они связаны с постановлениями, приказами, например, той же МинЦифры (с тем же №472)?
Что сегодня (не когда-то давно) есть ТК26? «Частная лавочка» ИнфоТеКС как подразделение РОССТАНДАРТа?
Как «это вообще работает» сегодня? Нужен не формальный ответ из «Язык дан чтобы скрывать свои мысли» (см. FAQ1), а именно неформальный и точный (прямой) ответ. Чтобы понять всю эту крипто-механику\политику изнутри.
В технических ваших дебрях я ничего не могу сказать - не моя компетенция,
Если совсем просто: 63-ФЗ через №472 определил обязательный формат ЭП, т.е. все подписи вне этого формата - не законные (не по закону № 63-ФЗ).
Этому формату (№472) не соответствует ни одна из существующих подписей. Чтобы это проверить нужно погружаться в "технические дебри" (показано как погрузиться и это не так сложно, как просто страшно или лениво, т.к. проверка простая), чтобы в это поверить нужно подождать мнений иных специалистов.
Конечно размыто, впрочем как и размыт в PMBOK сам бизнес-процесс проектного управления. Тем не менее общая концепция понятна из самой книжки, не уверен, что 7 (ее не читал, но полагаю, что она мало чем отличается от предыдущих).
В русском языке слово «управлять» - не конкретное. Предлагаю заменить на другие: руководить и манагерить. Руководить проектом – это Главный конструктор / Главный инженер проекта (как в ГОСТах), т.е. реальный руководитель, т.е. руководитель проекта. Королев в ракетах или Берия в атомном проекте – это про руководить. Есть полномочия и ответственность и не важно при этом, что Королев хорошо знал про устройство ракет, а Берия плохо как устроен атом.
Манегер - это менеджер по PMBOK, точнее администратор проекта (ведет регистры проектного учета, примерно как регистры бухгалтерского, складского и т.п.) + методолог и «проводник». Методолог не прикладной области, а PM-бучной.
Например, тут идут споры: Жуткий сценарий использования ChatGPT
должен ли менеджер быть спецом в прикладной (по теме проекта) области? Там говорят, что «да», но PMBOK говорит, что нет.
Задача менеджера проекта (в рамках PMBOK) представить и формализовать проект как процесс. Это не ответственность за выбор проектных решений, это про показать, какие формальные стадии должны быть (методолог), «за руку» провести проектную команду по этим стадиям (проводник) и формализовать результаты каждой стадии (учетная часть, включая сроки и бюджет). Отдельная роль - менеджер портфеля проектов (не рассматриваем).
Это позволяет достичь главного результата проектного менеджера – формализовать результат проекта и документально подтвердить, кто «завалил проект» (если такое случилось). Т.е. на упрек: «как ты завалил проект», проектный менеджер показывает на «крайнего» с фактурой, т.е. доказательствами. Конечно ТОПы уклоняются от такого контроля, но искусство менеджера - такой контроль обеспечить. В РФ могут изредка под названием менеджера проекта давать власть и обеспечить тем самым роль Главного конструктора (руководителя проекта), тогда это «два в одном».
В РФ обычно не понимают классического образа Манагера, его не стимулируют как требуется, например, если зарплата манагера не будет зависеть от сроков проекта, то это уже не эффективный проектный менеджмент. Манагеру должно быть выгодно неэффективный проект закрыть (и переключиться на другой), нежели его годами "волочить до победного".
Итого: Главные конструктора – в ТОМ-менеджменте (поиск и принятие проектных решений), а секретари проектов – в PMBOKах (организация проектных работ как процесс). В зрелых проектных компаниях изначально проекты организованы как процесса, но вот в проектных командах заказчика (внедрение своими силами, с привлечением вендора или интегратора) – проекты редко организованы как процесс (выстроенный процесс, когда понятно чем закончится конкретная стадия и что делать далее, как все это оформлять и т.п.).
хороший менеджер - это тот, который смог выстроить структуру работающую самостоятельно, без его участия. Эволюционная цель ПМа, которая мне откликается - сделать так, чтобы роли ПМа больше не понадобилось.
Да. Это и есть конечная цель управления процессами. Только вначале нужно из проекта сделать процесс.
что одним и тем же словом в разных предметных областях, ... обозначаться принципиально разные понятия"
это Омонимы. Слово одно, но его проекция в сознании на образы, ассоциированные с этим словом, - разная.
Это во многом то, что мы прямо сейчас в переписке демонстрируем. У нас разные ключи осмысления этих данных, т.е. перевода по табличке из набора слов в наборы смыслов. Таблички ключевые разные, хотя частично ключики совпадают, а частично нет. Мы конечно пытаемся использовать разные ключики (подбирать ключики, т.е. пытаться угадать ключевую табличку собеседника), пытаясь угадать "смысловое поле" (направление мысли, алгоритм интерпретации заложенных в данные\коды смыслов), понять "как думает" собеседник, но получается только частично.
Так вот в общем случае данные, чтобы быть данными не требуют шифрования.
Данные при любой процедуре извлечения требуют преобразования (читай кодирование). Этот текст проходит через преобразования различных физических сред (электрические сигналы в проводах, световое излучение монитора и т.п.). Даже чтобы «черпануть» данные из своей же памяти (взять из сознания для их анализа, осознания) нужны преобразования (кодирование). Передавать данные из памяти одного человека в память другого "напрямую" (ментально) пока человечество не научилось.
Я подозреваю, что данные в памяти человека тоже хранятся в зашифрованном виде (как данные на зашифрованном HDD), и уж точно человеческая память организована как RAID массив (можем восстановить информацию при ее частичной утрате), т.е. тоже кодирована.
При кодирование исходному знаку, например произнесенной или нажатой на клавиатуре букве ставится в однозначное соответствие некий код, который любой может декодировать опять в буквы естественного языка.
Шифр Атбаша, Шифр Цезаря - это что? Разве там не «в однозначное соответствие некий код»?
А расшифровка древних письменностей, которую до сих пор не осилили, – это что? Вы считаете, что древние народы хотели скрыть от потомков смысл своих записей, предварительно их гарантировано зашифровав?
Но текст ведь не про данные, информацию, знания, а про понятия и определения, то есть из области эпистемологии методологии.
Почему? И про данные и про информацию и про знания и про их определения, классификацию, взаимосвязь и т.п. Много умных слов придумали, включая онтологию и таксономию и кучу похожих терминов. Слова типа "эпистемология" - туда же, а "область эпистемологии методологии" - вообще режет слух. Стараюсь более "по рабоче-крестьянски" выражаться.
Например, не зная точного значения "эпистемология" по стыковке «знание» и logos — «учение», логично было бы предположить, что это и есть метаЗнание (знание об знаниях, т.е. что собой представляют знания). Впрочем как и Информацию об информации - МетаИнформация.
Вот мы сейчас с вами передам друг другу незашифрованные данные. Вы, наверное, хотели написать "Данные – это нечто закодированное".
Если уж совсем строго, то видимо все-же передаем зашифрованные данные.
SSL, Protocol Secure (https://habr.com/), кодировка страниц, кодирование на физическом и канальном уровне (сетевые протоколы в локальной и глобальной сети, включая шифрованный абонентский канал 4G) и т.п. Попадая на экран текст расшифровывается, но если Ваш текст на экране увидит китаец, не знающий русского, то он скажет, что Ваше сообщение зашифровано и ключа к расшифровке он не знает.
Мы с Вами ровно также как протоколы информационного взаимодействия умеем на лету кодировать и раскодировать, т.е. буквы с экрана переводим в слова и далее в ментальные образы. Причем все равно смысл этих кодированных \ шифрованных данных (текста) у нас в общем случае - разный.
Кодировать и раскодировать - это ровно тоже, что шифровать и расшифровывать, т.к. все основано на "ключе кодирования", что в простом случае - таблица, устанавливающая соответствие между кодированной и исходной информацией. В данном случае, ключ - это русский алфавит и правила чтения, позволяющие получать (считывать) с экрана уже не "набор шифра как данные", а информацию (и далее ее упаковывать в знания, т.е. в триплеты).
Разница в шифровании и кодировании на мой взгляд лишь в том, что при шифровании ключ всегда прячут (ключ секретный), а при кодировании обычно нет. При электронной подписи также применяется термин "алгоритмы шифрования", но там везде данные, которые можно прочитать и интерпретировать. Если ключ не прячут, а его все равно у пользователя нет (китайца), то границы этих понятий условны.
Шифрование на прикладном ментальном уровне. Смысл прочитанного текста у нас с Вами разный, потому что у нас разные ключи для расшифровки уже не букв, а именно смыслов. Это я уже условно про прикладной уровень, где нужно расшифровывать именно смыслы (знания). Это тоже требует своего "смыслового алфавита" (как аналог русского алфавита, но на более высоком уровне модели взаимодействия) и своих "бизнес-правил", точнее "правил упаковки смыслов" (как аналог правила чтения). Т.е. знания, чтобы понять другие знания - я про этот ключ. Понятно, что шифруем свои сообщения мы не по злому умыслу.
В целом, ключи для этого у нас с Вами разные и физически такими ключами обменяться видимо не получится, поэтому в любом случае и я и Вы расшифруете (раскодируете) только часть информации (часть знаний, смыслов) из нашей переписки, т.к. часть будет просто неверно расшифрована, т.к. был использован не совсем нужный ключ (вроде подошел, но расшифровал иначе). Часть информации будет вообще не расшифрована на прикладном ментальном уровне (не понята собеседнику или вообще утеряна, как в канале с помехами). Следовательно, даже без учета шифрования в сети, то мы с Вами обмениваемся тоже шифрами (шифровками), при этом у нас ключи совпадают только частично.
Написано видимо неструктурированно, но стался шифровать-кодировать мысль "простым ключом", без умных и научных (чаще околонаучных) терминов.
использованием слова «информация» для обозначения многих разных понятий (в нашем примере ‘данные’, ‘сообщение’, ‘сведения’, ‘знания’). И каждое из этих понятий не является сложным и достаточно однозначно определяется:
данные – это набор знаков, предназначенный для обработки и передачи по каналам связи;
сообщение – последовательность знаков, созданная отправителем для передачи некоторых сведений получателю;
сведения – мысль, которая фиксируется в сообщении отправителем или понимается получателем;
знание – фиксированная мысль, используемая для однозначного воспроизведения действий.
конец цитаты.
про «Данные, информация, сообщения, знания» думаю так:
Данные – это нечто зашифрованное, но или реально-осязаемое (воспринимаемое органами чувств) или ментально-ощутимое (данные в ментальном хранилище, памяти человека, контейнере сознание или подсознание).
Сообщения (сигналы) – это «транспортный» контейнер с данными. Человек или устройства получают данные через сообщения. Сообщения может генерить ментальный генератор человека, устройства, окружающая среда и т.п.
Информация (или Сведения) – это если я (сознание) эти данные могу расшифровать и интерпретировать (с какой – то степенью полноты и достоверностью). Это фактически отдельный набор объектов («объектных» сущностей, узлов) и отдельный набор связей (отношений между «объектными сущностями», ребер). Конечно какая-то связность между разными блоками информации всегда есть (уже выделение из данных и идентификация в объекты требует этого), но это логическая цепочка "нижнего уровня". Вся взаимосвязь информации на уровне подсознания также не считается знанием.
Знания – это уже триплеты из «объектных» сущностей и связей, причем "верхнего уровня". Совсем не важно, истинные знания или ложные, объективные или субъективные и т.п., т.е. вообще неважно насколько верно проставлены типы связей. Главное, что это «связанная информация» (пусть и неправильно связанная, но есть какая - то логика, ассоциации и т.п.), т.е., это не связанные данные (не путать с linked data, там как раз про связанную информацию, а не данные).
Итого четыре уровня, как в TCP/IP DOD, но при желании некоторые уровни можно далее декомпозировать по типу OSI. Отличие от строгой разбивки на уровни, по сравнению с сетевым взаимодействием в том, что, нет такой строгости.
Например, если человек хранит (не обязательно в памяти) текст на китайском, но китайский не знает, то это просто данные. Если он понимает текст на 50%, то получает 50% данных и 50% информации.
Ровно также и Знания vs Информация: все зависит от веса (мощности) взаимосвязей объектов с Информацией.
Транспортный уровень «человек – человек» обычно включает этапы:
1 Знания или Информация преобразуется в ментальные данные Петрова
2 кодировка и передача данных в передатчик, например, голос
3 среда распространения (канал связи), кстати он может видимо быть и ментальным, т.е. возможен "прямой линк"
4 приемник органов чувств Петрова, прием, раскодировка и обработка сигнала, включая использование корректирующих кодов (домысливание неразложенных слов), это фактически получение из сообщения данных и их конвертация в Информацию (или просто хранение как данные)
5 передача в процессор для преобразования Информации в Знания. Или если "лежат просто данные", то можно неожиданно вспомнить о них и мгновенно получить из них Информацию или даже Знания.
Далее можно опуститься на единицы измерения каждой величины (понятия). Минимум будет видимо не бит. Можно вспомнить кубит и кудит, но проще сказать, что есть три состояния (трёхзначная логика): да, нет, неизвестно, например, NaN, Not-a-Number или NULL в oracle (никак не определено). Точнее разрядность неопределенности выше, т.е. каждому утверждению (применительно как к информации, так и Знанию) соответствует уровень истинности.
Ожидал от Вас увидеть на эту тему что-то более конкретное с использованием инструментов семантики, онтологий и т.п., но все равно спасибо, плюсую.
Изменения должны были вступить в силу с 1 января 2022 года. Но всё перенесли на 1 января 2023, а потом на 1 сентября 2023. Ждём-с…
Так уже трижды же переносили (с 01.01.22) сроки внедрения МЧД: 01.03.22, 01.01.23, 01.09.23. Неужели снова не перенесут?
Электронный документооборот становится не только выгодным, но и безопасным с точки зрения рисков судебных споров.
Очень смешно. Например, требований к формату самой ЭП (электронная подпись) в кадровом ЭДО вообще не установлено.
Можно использовать разные-разные алгоритмы хеширования (десятки), алгоритмы шифрования (сотни начиная от RSA и EGSA до малоизвестных), кодировки (не обязательно DER или BASE64), можно древние CMS (еще до CAdES) или новые CAdES-E, а можно и свой формат придумать. Любой формат можно брать в разных сочетаниях и подписывать документы. Зоопарк никем не ограничен. Кстати, а где запрет на использовании в кадровом ЭДО электронной подписи на симметричном шифровании?
Можно лепить свои сервисы TSP (OCSP) самим и «как попало» (не требуется сертификации, во всяком случае, при использовании в рамках кадрового ЭДО) и даже другим предоставлять такие услуги такого как бы «доверенного» времени ("доверенного" on-line ответа).
В итоге уже сегодня есть гора фантиков (документов, которые или не прочитать или в которых не проверить подпись ввиду нестандартных форматов), т.к. внедренный кадровой ЭДО уже у многих работает и они вынуждены его менять наполовину после приказа Минтруда №578н, например, кто использовал не открепляемую подпись, например, PADES.
Будет быстро расти эта гора фантиков и после ввода №578н (1 марта 23), т.к. он ничего особо и не регламентирует. Фантики (документы с ЭП разного формата) вроде как по закону "юридически значимые" (де юре), только вот проверить подпись (де факто) во многих случаях - будет сложнейшая задача, точнее целое кропотливое исследование, требующее массу времени и стендов, и без гарантии.
Поэтому судебные споры просто гарантированы. Сегодня кадровый ЭДО – это откровенная общегосударственная профанация и массовая (все сотрудники, подписавшие кадровые документы ЭП) мина замедленного действия (читай оружие массового поражения). Но это не значит, что кадровый ЭДО будет не популярным, т.к. мина не особо видна и рванет позже (когда накопит критическую массу), если конечно ранее законодатели ее не обезвредят, но эти гос-саперы особо "не чешутся".
Community Edition
Советую docsvision подумать над Community Edition (open source) в целом, а в частности предложить free версию Кадрового ЭДО. Не столь многофункционального, как в коммерческой версии, но минимально достаточного чтобы вести кадровый документооборот в соответствии с приказом Минтруда №578н. Сейчас рынок кадрового ЭДО подогрет, есть большой интерес (большие деньги) и кто первым положит кусочек вкусного (рабочего, т.е. удовлетворяющего требованиям №578н и от которого сразу "не стошнит") «бесплатного» сыра (free кадровый ЭДО), того и «тапки».
Но пока электронной подписи в таком открытом рус-СЭД (Community Edition) ни у кого нет, поэтому у docsvision есть шанс стать первыми и использовать такое Community как хорошую рекламу и продвижение своей флагманской (коммерческой) версии. Это предложение относится не только к docsvision.
Повторюсь: Как это проверить? Какие хотя бы косвенные доказательства Вашей логики (такой интерпретации ПДД со "сдвоенными" категориями \ типами ТС) можете предложить? Или просто "второе мнение" (как в медицине), но более подробно. Логика интересная, но странная (даже чудовищная), поэтому плохо воспринимается и проецируется на реальность.
Ранее, человек, покупающий мощный самокат с сиделкой, считал себя мотопедистом (брал права, шлем, доказательства не превышения 4 кВт) и выезжал на проезжую часть как на мопеде (соблюдая ПДД для мопеда). Теперь он оказался "СИМ и одновременно мопед" и имеет все ограничения по нижней планке, т.е. минимум по обоим категориям: ограничение в 25 км/ч (СИМ) и на тротуар выехать нельзя (мопед) и т.п. Полагаю, что до такой ахинеи законодатели все же не додумались. Еще более абсурдным выглядит ситуация с е-самокатами от 4 кВт (DUALTRON X2 и т.п.).
Велосипедом СИМ быть не может
Определение педали обычно начинается со слов "это рычаг ...". Почему ногу нельзя считать рычагом? Тем более сказано: "и приводится в движение как правило мускульной энергией лиц, находящихся на этом транспортном средстве".
На электросамокате можно ехать (не так комфортно конечно) как и на простом самокате.
Поэтому я и хотел Вначале узнать мнение хабр-сообщества на эту проблему. Возможно я что-то не нашел и согласование ФСБ "вот оно" или я не так прочитал OID, а нужно было иначе, т.е. вдруг мне тут покажут, что с №472 "полный порядок". Зачем тогда лишний раз беспокоить "наших занятых ЭПчиновников"?
Кстати, на каких форумах можно задать вопрос по №472?
Это был юмор? Тогда не хватает третьего: "письма всевышнему" на ул. Ильинка подъезд 11.
"Это Россия, детка!" (мем).
Полагаю, что Вопрос должен быть принципиален каждому, кто проставляет на документах или проверяет электронную подпись.
Пояснения по Вопросу 1 добавил в FAQ2 (как типовой вопрос).
Утвердительный ответ на этот вопрос требует публикации согласования этого приказа (№472) от ФСБ. Если отлагательное условие не выполнено, то утвержденного Формата - нет, а МинЦифры грубо нарушило требование 63-ФЗ, выдав свой №472 за утвержденный.
"Как бы" Доказательства:
Это неявное доказательство. Я тоже уверен, что согласование есть, но раз в 63-ФЗ указали явно на наличие такого согласования как важное отлагательное условие, то выполнение этого условия должно быть подтверждено Явно. Ответ кого-либо (МинЮста, МинЦифры, ФСБ) в адрес одной компании (автора запроса) – это «не в счет», т.е. должно быть публично подтверждено выполнение или невыполнение столь критически важного отлагательного условия.
https://tc26.ru/
Там указано много чего (к сожалению, вместо прямых ссылок на документы стоят ссылки «в корзину»), но непонятен сам статус рекомендаций: они обязательны? Что значит «Действуют». Для кого и в каких случаях? Кто их использует и как они связаны с постановлениями, приказами, например, той же МинЦифры (с тем же №472)?
Что сегодня (не когда-то давно) есть ТК26? «Частная лавочка» ИнфоТеКС как подразделение РОССТАНДАРТа?
Как «это вообще работает» сегодня? Нужен не формальный ответ из «Язык дан чтобы скрывать свои мысли» (см. FAQ1), а именно неформальный и точный (прямой) ответ. Чтобы понять всю эту крипто-механику\политику изнутри.
Типовой вопрос. Добавил в FAQ.
Если совсем просто: 63-ФЗ через №472 определил обязательный формат ЭП, т.е. все подписи вне этого формата - не законные (не по закону № 63-ФЗ).
Этому формату (№472) не соответствует ни одна из существующих подписей. Чтобы это проверить нужно погружаться в "технические дебри" (показано как погрузиться и это не так сложно, как просто страшно или лениво, т.к. проверка простая), чтобы в это поверить нужно подождать мнений иных специалистов.
Иллюстрация к
https://habrastorage.org/r/w1560/getpro/habr/upload_files/67d/a0e/052/67da0e0528da47729c53664448d66709.png
Не знаю как сейчас, но 15 лет назад на всех проектах, которые через меня проходили на титуле (титульный лист проекта) была надпись:
я ГИП этого проекта несу Уголовную ответственность за то что тут написано (что то типа того) и роспись.
Сейчас "среднестатистический" менеджер проекта, как правило, ни за что не отвечает, т.к. ответственность требует наличия полномочий.
Это Windows Embedded?
Конечно размыто, впрочем как и размыт в PMBOK сам бизнес-процесс проектного управления. Тем не менее общая концепция понятна из самой книжки, не уверен, что 7 (ее не читал, но полагаю, что она мало чем отличается от предыдущих).
Во многих гос-компаниях (в т.ч. военных НИИ) и ИТ-шники даже с большим стажем получают гроши.
Мы говорим про "профессионального манагера", а не "жадного неадекватного хамла".
К вопросу: должен ли менеджер быть спецом в прикладной (по теме проекта) области? Тут говорят, что «да», но PMBOK говорит, что нет. Пояснения:
https://habr.com/ru/post/715256/#comment_25200666
В русском языке слово «управлять» - не конкретное. Предлагаю заменить на другие: руководить и манагерить. Руководить проектом – это Главный конструктор / Главный инженер проекта (как в ГОСТах), т.е. реальный руководитель, т.е. руководитель проекта. Королев в ракетах или Берия в атомном проекте – это про руководить. Есть полномочия и ответственность и не важно при этом, что Королев хорошо знал про устройство ракет, а Берия плохо как устроен атом.
Манегер - это менеджер по PMBOK, точнее администратор проекта (ведет регистры проектного учета, примерно как регистры бухгалтерского, складского и т.п.) + методолог и «проводник». Методолог не прикладной области, а PM-бучной.
Например, тут идут споры: Жуткий сценарий использования ChatGPT
https://habr.com/ru/post/714792/
должен ли менеджер быть спецом в прикладной (по теме проекта) области? Там говорят, что «да», но PMBOK говорит, что нет.
Задача менеджера проекта (в рамках PMBOK) представить и формализовать проект как процесс. Это не ответственность за выбор проектных решений, это про показать, какие формальные стадии должны быть (методолог), «за руку» провести проектную команду по этим стадиям (проводник) и формализовать результаты каждой стадии (учетная часть, включая сроки и бюджет). Отдельная роль - менеджер портфеля проектов (не рассматриваем).
Это позволяет достичь главного результата проектного менеджера – формализовать результат проекта и документально подтвердить, кто «завалил проект» (если такое случилось). Т.е. на упрек: «как ты завалил проект», проектный менеджер показывает на «крайнего» с фактурой, т.е. доказательствами. Конечно ТОПы уклоняются от такого контроля, но искусство менеджера - такой контроль обеспечить. В РФ могут изредка под названием менеджера проекта давать власть и обеспечить тем самым роль Главного конструктора (руководителя проекта), тогда это «два в одном».
В РФ обычно не понимают классического образа Манагера, его не стимулируют как требуется, например, если зарплата манагера не будет зависеть от сроков проекта, то это уже не эффективный проектный менеджмент. Манагеру должно быть выгодно неэффективный проект закрыть (и переключиться на другой), нежели его годами "волочить до победного".
Итого: Главные конструктора – в ТОМ-менеджменте (поиск и принятие проектных решений), а секретари проектов – в PMBOKах (организация проектных работ как процесс). В зрелых проектных компаниях изначально проекты организованы как процесса, но вот в проектных командах заказчика (внедрение своими силами, с привлечением вендора или интегратора) – проекты редко организованы как процесс (выстроенный процесс, когда понятно чем закончится конкретная стадия и что делать далее, как все это оформлять и т.п.).
Да. Это и есть конечная цель управления процессами. Только вначале нужно из проекта сделать процесс.
это Омонимы. Слово одно, но его проекция в сознании на образы, ассоциированные с этим словом, - разная.
Это во многом то, что мы прямо сейчас в переписке демонстрируем. У нас разные ключи осмысления этих данных, т.е. перевода по табличке из набора слов в наборы смыслов. Таблички ключевые разные, хотя частично ключики совпадают, а частично нет. Мы конечно пытаемся использовать разные ключики (подбирать ключики, т.е. пытаться угадать ключевую табличку собеседника), пытаясь угадать "смысловое поле" (направление мысли, алгоритм интерпретации заложенных в данные\коды смыслов), понять "как думает" собеседник, но получается только частично.
Данные при любой процедуре извлечения требуют преобразования (читай кодирование). Этот текст проходит через преобразования различных физических сред (электрические сигналы в проводах, световое излучение монитора и т.п.). Даже чтобы «черпануть» данные из своей же памяти (взять из сознания для их анализа, осознания) нужны преобразования (кодирование). Передавать данные из памяти одного человека в память другого "напрямую" (ментально) пока человечество не научилось.
Я подозреваю, что данные в памяти человека тоже хранятся в зашифрованном виде (как данные на зашифрованном HDD), и уж точно человеческая память организована как RAID массив (можем восстановить информацию при ее частичной утрате), т.е. тоже кодирована.
Шифр Атбаша, Шифр Цезаря - это что? Разве там не «в однозначное соответствие некий код»?
А расшифровка древних письменностей, которую до сих пор не осилили, – это что? Вы считаете, что древние народы хотели скрыть от потомков смысл своих записей, предварительно их гарантировано зашифровав?
Почему? И про данные и про информацию и про знания и про их определения, классификацию, взаимосвязь и т.п. Много умных слов придумали, включая онтологию и таксономию и кучу похожих терминов. Слова типа "эпистемология" - туда же, а "область эпистемологии методологии" - вообще режет слух. Стараюсь более "по рабоче-крестьянски" выражаться.
Например, не зная точного значения "эпистемология" по стыковке «знание» и logos — «учение», логично было бы предположить, что это и есть метаЗнание (знание об знаниях, т.е. что собой представляют знания). Впрочем как и Информацию об информации - МетаИнформация.
Если уж совсем строго, то видимо все-же передаем зашифрованные данные.
SSL, Protocol Secure (https://habr.com/), кодировка страниц, кодирование на физическом и канальном уровне (сетевые протоколы в локальной и глобальной сети, включая шифрованный абонентский канал 4G) и т.п. Попадая на экран текст расшифровывается, но если Ваш текст на экране увидит китаец, не знающий русского, то он скажет, что Ваше сообщение зашифровано и ключа к расшифровке он не знает.
Мы с Вами ровно также как протоколы информационного взаимодействия умеем на лету кодировать и раскодировать, т.е. буквы с экрана переводим в слова и далее в ментальные образы. Причем все равно смысл этих кодированных \ шифрованных данных (текста) у нас в общем случае - разный.
Кодировать и раскодировать - это ровно тоже, что шифровать и расшифровывать, т.к. все основано на "ключе кодирования", что в простом случае - таблица, устанавливающая соответствие между кодированной и исходной информацией. В данном случае, ключ - это русский алфавит и правила чтения, позволяющие получать (считывать) с экрана уже не "набор шифра как данные", а информацию (и далее ее упаковывать в знания, т.е. в триплеты).
Разница в шифровании и кодировании на мой взгляд лишь в том, что при шифровании ключ всегда прячут (ключ секретный), а при кодировании обычно нет. При электронной подписи также применяется термин "алгоритмы шифрования", но там везде данные, которые можно прочитать и интерпретировать. Если ключ не прячут, а его все равно у пользователя нет (китайца), то границы этих понятий условны.
Шифрование на прикладном ментальном уровне. Смысл прочитанного текста у нас с Вами разный, потому что у нас разные ключи для расшифровки уже не букв, а именно смыслов. Это я уже условно про прикладной уровень, где нужно расшифровывать именно смыслы (знания). Это тоже требует своего "смыслового алфавита" (как аналог русского алфавита, но на более высоком уровне модели взаимодействия) и своих "бизнес-правил", точнее "правил упаковки смыслов" (как аналог правила чтения). Т.е. знания, чтобы понять другие знания - я про этот ключ. Понятно, что шифруем свои сообщения мы не по злому умыслу.
В целом, ключи для этого у нас с Вами разные и физически такими ключами обменяться видимо не получится, поэтому в любом случае и я и Вы расшифруете (раскодируете) только часть информации (часть знаний, смыслов) из нашей переписки, т.к. часть будет просто неверно расшифрована, т.к. был использован не совсем нужный ключ (вроде подошел, но расшифровал иначе). Часть информации будет вообще не расшифрована на прикладном ментальном уровне (не понята собеседнику или вообще утеряна, как в канале с помехами). Следовательно, даже без учета шифрования в сети, то мы с Вами обмениваемся тоже шифрами (шифровками), при этом у нас ключи совпадают только частично.
Написано видимо неструктурированно, но стался шифровать-кодировать мысль "простым ключом", без умных и научных (чаще околонаучных) терминов.
данные – это набор знаков, предназначенный для обработки и передачи по каналам связи;
сообщение – последовательность знаков, созданная отправителем для передачи некоторых сведений получателю;
сведения – мысль, которая фиксируется в сообщении отправителем или понимается получателем;
знание – фиксированная мысль, используемая для однозначного воспроизведения действий.
конец цитаты.
про «Данные, информация, сообщения, знания» думаю так:
Данные – это нечто зашифрованное, но или реально-осязаемое (воспринимаемое органами чувств) или ментально-ощутимое (данные в ментальном хранилище, памяти человека, контейнере сознание или подсознание).
Сообщения (сигналы) – это «транспортный» контейнер с данными. Человек или устройства получают данные через сообщения. Сообщения может генерить ментальный генератор человека, устройства, окружающая среда и т.п.
Информация (или Сведения) – это если я (сознание) эти данные могу расшифровать и интерпретировать (с какой – то степенью полноты и достоверностью). Это фактически отдельный набор объектов («объектных» сущностей, узлов) и отдельный набор связей (отношений между «объектными сущностями», ребер). Конечно какая-то связность между разными блоками информации всегда есть (уже выделение из данных и идентификация в объекты требует этого), но это логическая цепочка "нижнего уровня". Вся взаимосвязь информации на уровне подсознания также не считается знанием.
Знания – это уже триплеты из «объектных» сущностей и связей, причем "верхнего уровня". Совсем не важно, истинные знания или ложные, объективные или субъективные и т.п., т.е. вообще неважно насколько верно проставлены типы связей. Главное, что это «связанная информация» (пусть и неправильно связанная, но есть какая - то логика, ассоциации и т.п.), т.е., это не связанные данные (не путать с linked data, там как раз про связанную информацию, а не данные).
Итого четыре уровня, как в TCP/IP DOD, но при желании некоторые уровни можно далее декомпозировать по типу OSI. Отличие от строгой разбивки на уровни, по сравнению с сетевым взаимодействием в том, что, нет такой строгости.
Например, если человек хранит (не обязательно в памяти) текст на китайском, но китайский не знает, то это просто данные. Если он понимает текст на 50%, то получает 50% данных и 50% информации.
Ровно также и Знания vs Информация: все зависит от веса (мощности) взаимосвязей объектов с Информацией.
Транспортный уровень «человек – человек» обычно включает этапы:
1 Знания или Информация преобразуется в ментальные данные Петрова
2 кодировка и передача данных в передатчик, например, голос
3 среда распространения (канал связи), кстати он может видимо быть и ментальным, т.е. возможен "прямой линк"
4 приемник органов чувств Петрова, прием, раскодировка и обработка сигнала, включая использование корректирующих кодов (домысливание неразложенных слов), это фактически получение из сообщения данных и их конвертация в Информацию (или просто хранение как данные)
5 передача в процессор для преобразования Информации в Знания. Или если "лежат просто данные", то можно неожиданно вспомнить о них и мгновенно получить из них Информацию или даже Знания.
Далее можно опуститься на единицы измерения каждой величины (понятия). Минимум будет видимо не бит. Можно вспомнить кубит и кудит, но проще сказать, что есть три состояния (трёхзначная логика): да, нет, неизвестно, например, NaN, Not-a-Number или NULL в oracle (никак не определено). Точнее разрядность неопределенности выше, т.е. каждому утверждению (применительно как к информации, так и Знанию) соответствует уровень истинности.
Ожидал от Вас увидеть на эту тему что-то более конкретное с использованием инструментов семантики, онтологий и т.п., но все равно спасибо, плюсую.
Так уже трижды же переносили (с 01.01.22) сроки внедрения МЧД: 01.03.22, 01.01.23, 01.09.23. Неужели снова не перенесут?
Очень смешно. Например, требований к формату самой ЭП (электронная подпись) в кадровом ЭДО вообще не установлено.
Можно использовать разные-разные алгоритмы хеширования (десятки), алгоритмы шифрования (сотни начиная от RSA и EGSA до малоизвестных), кодировки (не обязательно DER или BASE64), можно древние CMS (еще до CAdES) или новые CAdES-E, а можно и свой формат придумать. Любой формат можно брать в разных сочетаниях и подписывать документы. Зоопарк никем не ограничен. Кстати, а где запрет на использовании в кадровом ЭДО электронной подписи на симметричном шифровании?
Можно лепить свои сервисы TSP (OCSP) самим и «как попало» (не требуется сертификации, во всяком случае, при использовании в рамках кадрового ЭДО) и даже другим предоставлять такие услуги такого как бы «доверенного» времени ("доверенного" on-line ответа).
В итоге уже сегодня есть гора фантиков (документов, которые или не прочитать или в которых не проверить подпись ввиду нестандартных форматов), т.к. внедренный кадровой ЭДО уже у многих работает и они вынуждены его менять наполовину после приказа Минтруда №578н, например, кто использовал не открепляемую подпись, например, PADES.
Будет быстро расти эта гора фантиков и после ввода №578н (1 марта 23), т.к. он ничего особо и не регламентирует. Фантики (документы с ЭП разного формата) вроде как по закону "юридически значимые" (де юре), только вот проверить подпись (де факто) во многих случаях - будет сложнейшая задача, точнее целое кропотливое исследование, требующее массу времени и стендов, и без гарантии.
Поэтому судебные споры просто гарантированы. Сегодня кадровый ЭДО – это откровенная общегосударственная профанация и массовая (все сотрудники, подписавшие кадровые документы ЭП) мина замедленного действия (читай оружие массового поражения). Но это не значит, что кадровый ЭДО будет не популярным, т.к. мина не особо видна и рванет позже (когда накопит критическую массу), если конечно ранее законодатели ее не обезвредят, но эти гос-саперы особо "не чешутся".
Community Edition
Советую docsvision подумать над Community Edition (open source) в целом, а в частности предложить free версию Кадрового ЭДО. Не столь многофункционального, как в коммерческой версии, но минимально достаточного чтобы вести кадровый документооборот в соответствии с приказом Минтруда №578н. Сейчас рынок кадрового ЭДО подогрет, есть большой интерес (большие деньги) и кто первым положит кусочек вкусного (рабочего, т.е. удовлетворяющего требованиям №578н и от которого сразу "не стошнит") «бесплатного» сыра (free кадровый ЭДО), того и «тапки».
Привел два примера отечественного open source с поддержкой конфигурации СЭД в Открытый проект Электронного подписания внутренних документов компании на примере кадровых
Но пока электронной подписи в таком открытом рус-СЭД (Community Edition) ни у кого нет, поэтому у docsvision есть шанс стать первыми и использовать такое Community как хорошую рекламу и продвижение своей флагманской (коммерческой) версии. Это предложение относится не только к docsvision.
Варианты рассмотрел тут:
3. Основной «подводный камень» КЭДО и иного ЭДО
https://habr.com/ru/post/703388/
как приманка - чтобы вернулись, пока границы открыты.
и границы уже закрыты (мышеловка \ it-ловка)
Вы не туда ответили. Продолжу тут.
Повторюсь: Как это проверить? Какие хотя бы косвенные доказательства Вашей логики (такой интерпретации ПДД со "сдвоенными" категориями \ типами ТС) можете предложить? Или просто "второе мнение" (как в медицине), но более подробно. Логика интересная, но странная (даже чудовищная), поэтому плохо воспринимается и проецируется на реальность.
Ранее, человек, покупающий мощный самокат с сиделкой, считал себя мотопедистом (брал права, шлем, доказательства не превышения 4 кВт) и выезжал на проезжую часть как на мопеде (соблюдая ПДД для мопеда). Теперь он оказался "СИМ и одновременно мопед" и имеет все ограничения по нижней планке, т.е. минимум по обоим категориям: ограничение в 25 км/ч (СИМ) и на тротуар выехать нельзя (мопед) и т.п. Полагаю, что до такой ахинеи законодатели все же не додумались. Еще более абсурдным выглядит ситуация с е-самокатами от 4 кВт (DUALTRON X2 и т.п.).
Определение педали обычно начинается со слов "это рычаг ...". Почему ногу нельзя считать рычагом? Тем более сказано: "и приводится в движение как правило мускульной энергией лиц, находящихся на этом транспортном средстве".
На электросамокате можно ехать (не так комфортно конечно) как и на простом самокате.
прямо так и открытый?
Для чего тогда пишут: "... позволяет «взламывать» ключи A5/1 \А5/3, используемые для шифрования вызовов GSM 2G и SMS".
Можно конечно использовать A5/0 (без шифрования), а как настроено у основных операторов?